From pemboa at gmail.com  Wed Oct  1 01:45:17 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 30 Sep 2008 20:45:17 -0500
Subject: make mail go somewhere by default
In-Reply-To: <200809301659.12364.jarod@redhat.com>
References: <20080924212236.GJ1414283@hiwaay.net> <48DBED58.3040307@gmail.com>
	<48DBF3F5.3080806@redhat.com> <200809301659.12364.jarod@redhat.com>
Message-ID: <16de708d0809301845o13c5e1ax898f29d5745387e9@mail.gmail.com>

On Tue, Sep 30, 2008 at 3:59 PM, Jarod Wilson <jarod at redhat.com> wrote:
> On Thursday 25 September 2008 16:26:29 Jarod Wilson wrote:
>> Les Mikesell wrote:
>> > Matthew Miller wrote:
>> >> On Wed, Sep 24, 2008 at 04:39:26PM -0700, Jesse Keating wrote:
>> >>> Which is why we shouldn't be using local delivery for this stuff.
>> >>> Instead we should ask in firstboot where you'd want the mail delivered
>> >>> to.
>> >>
>> >> Ooh! And do it this way!
>> >>
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=143437
>> >
>> > That's a good technique, but wouldn't it follow the system style more
>> > closely to put install/firstboot setting snippets somewhere under
>> > /etc/sysconfig with the stock alias file including from there?
>>
>> Hm... I wrote a firstboot patch ages ago (almost 3 years ago?) that let you
>> say "send root mail to this user" when you added a user in firstboot... Its
>> even in bz somewhere, iirc...
>
> Thar she blows:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=135592
>

Should I consider this a dupe?
https://bugzilla.redhat.com/show_bug.cgi?id=463864

Mine is a bit more broad.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mattdm at mattdm.org  Wed Oct  1 02:24:58 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 30 Sep 2008 22:24:58 -0400
Subject: tab completion less useful now, due to sbin in path
Message-ID: <20081001022458.GA14186@jadzia.bu.edu>

Grumble grumble.

I'm finding having sbin in my user path really annoying. I go to type
'killall firefox' using tab completion, and killall5 (which says in its man
page "Its primary (only) use is in the rc scripts"!) is in the way. I go to
run firefox again, and I'm impeded by firstboot. Etc., etc., etc.

This change is not for the better, and doesn't fit the stated goal of "sbin
sanity".

The sudo change was good, and helped out. Moving useful binaries out of sbin
and into bin would have been a good path. Throwing everything into one pot
is a regression.


Now, I hear you saying already: "stop whining, Matthew. Just put it the way
you want in your dotfiles". Well, okay, I have. But I don't want to just set
a static path since I want /etc/profile.d to still work. So I've got to do
an active munging sed script. Ugh.

We've just made the command line a lot less user friendly for common use in
exchange for an ugly fix to a small inconvenience. *Any* chance of putting
this back and working at fixing the problem the hard but correct way?


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From konrad at tylerc.org  Wed Oct  1 02:38:44 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 30 Sep 2008 19:38:44 -0700
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081001022458.GA14186@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
Message-ID: <200809301938.44849.konrad@tylerc.org>

On Tuesday 30 September 2008 07:24:58 pm Matthew Miller wrote:
> Grumble grumble.
>
> I'm finding having sbin in my user path really annoying. I go to type
> 'killall firefox' using tab completion, and killall5 (which says in its man
> page "Its primary (only) use is in the rc scripts"!) is in the way. I go to
> run firefox again, and I'm impeded by firstboot. Etc., etc., etc.
>
> This change is not for the better, and doesn't fit the stated goal of "sbin
> sanity".
>
> The sudo change was good, and helped out. Moving useful binaries out of
> sbin and into bin would have been a good path. Throwing everything into one
> pot is a regression.
>
> Now, I hear you saying already: "stop whining, Matthew. Just put it the way
> you want in your dotfiles". Well, okay, I have. But I don't want to just
> set a static path since I want /etc/profile.d to still work. So I've got to
> do an active munging sed script. Ugh.
>
> We've just made the command line a lot less user friendly for common use in
> exchange for an ugly fix to a small inconvenience. *Any* chance of putting
> this back and working at fixing the problem the hard but correct way?

This seems more a complaint that tab completion is different from what you're 
used to. Many users feel the opposite (they add sbin to PATH in their 
dotfiles) and won't notice the change. For users new to linux and Fedora, 
sbin being in PATH gives them a better user experience than 'bash: foo: 
command not found' errors when they try to follow some guide on the web.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From smooge at gmail.com  Wed Oct  1 02:52:10 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 30 Sep 2008 20:52:10 -0600
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081001022458.GA14186@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
Message-ID: <80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>

On Tue, Sep 30, 2008 at 8:24 PM, Matthew Miller <mattdm at mattdm.org> wrote:
> Grumble grumble.
>
> I'm finding having sbin in my user path really annoying. I go to type
> 'killall firefox' using tab completion, and killall5 (which says in its man
> page "Its primary (only) use is in the rc scripts"!) is in the way. I go to
> run firefox again, and I'm impeded by firstboot. Etc., etc., etc.
>
> This change is not for the better, and doesn't fit the stated goal of "sbin
> sanity".
>
> The sudo change was good, and helped out. Moving useful binaries out of sbin
> and into bin would have been a good path. Throwing everything into one pot
> is a regression.
>
>
> Now, I hear you saying already: "stop whining, Matthew. Just put it the way
> you want in your dotfiles". Well, okay, I have. But I don't want to just set
> a static path since I want /etc/profile.d to still work. So I've got to do
> an active munging sed script. Ugh.
>
> We've just made the command line a lot less user friendly for common use in
> exchange for an ugly fix to a small inconvenience. *Any* chance of putting
> this back and working at fixing the problem the hard but correct way?
>

I won't say you are whining.. but you are the first systems
administrator I have met in several years who hasn't had
/usr/sbin:/sbin in their default path. You sure they didn't make you a
manager and didn't tell you?

I think the chance for putting it back is still there.. if someone is
willing to do the work on the hard but correct way? I think it was
crickets the last couple of times when volunteers were asked for that.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From dev at nigelj.com  Wed Oct  1 03:06:02 2008
From: dev at nigelj.com (Nigel Jones)
Date: Wed, 01 Oct 2008 16:06:02 +1300
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
Message-ID: <1222830362.3674.3.camel@fantail.jnet.net.nz>

On Tue, 2008-09-30 at 20:52 -0600, Stephen John Smoogen wrote:
> On Tue, Sep 30, 2008 at 8:24 PM, Matthew Miller <mattdm at mattdm.org> wrote:
> > Grumble grumble.
> >
> > I'm finding having sbin in my user path really annoying. I go to type
> > 'killall firefox' using tab completion, and killall5 (which says in its man
> > page "Its primary (only) use is in the rc scripts"!) is in the way. I go to
> > run firefox again, and I'm impeded by firstboot. Etc., etc., etc.
> >
> > This change is not for the better, and doesn't fit the stated goal of "sbin
> > sanity".
> >
> > The sudo change was good, and helped out. Moving useful binaries out of sbin
> > and into bin would have been a good path. Throwing everything into one pot
> > is a regression.
> >
> >
> > Now, I hear you saying already: "stop whining, Matthew. Just put it the way
> > you want in your dotfiles". Well, okay, I have. But I don't want to just set
> > a static path since I want /etc/profile.d to still work. So I've got to do
> > an active munging sed script. Ugh.
> >
> > We've just made the command line a lot less user friendly for common use in
> > exchange for an ugly fix to a small inconvenience. *Any* chance of putting
> > this back and working at fixing the problem the hard but correct way?
> >
> 
> I won't say you are whining.. but you are the first systems
> administrator I have met in several years who hasn't had
> /usr/sbin:/sbin in their default path. You sure they didn't make you a
> manager and didn't tell you?
> 
> I think the chance for putting it back is still there.. if someone is
> willing to do the work on the hard but correct way? I think it was
> crickets the last couple of times when volunteers were asked for that.

I personally have come to like typing the full paths for /sbin /usr/sbin
stuff, only problem is, sometimes things that one would feel is more
appropriate in /sbin isn't there (setenforce etc).

I haven't added such to my . files for such a long time it's not funny,
to the point where just typing 'ifconfig' before felt unnatural...

I can however live with either, I literally don't give a damn and it
doesn't bother me... :)
-- 
Nigel Jones <dev at nigelj.com>



From mattdm at mattdm.org  Wed Oct  1 03:51:16 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 30 Sep 2008 23:51:16 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
Message-ID: <20081001035116.GA21890@jadzia.bu.edu>

On Tue, Sep 30, 2008 at 08:52:10PM -0600, Stephen John Smoogen wrote:
> I won't say you are whining.. but you are the first systems
> administrator I have met in several years who hasn't had
> /usr/sbin:/sbin in their default path. You sure they didn't make you a
> manager and didn't tell you?


Heh. Well, I also have had sudo compiled with /sbin and /usr/sbin in its
secure path, so sudo command (and sudo com[tab] with bash_completion) has
worked correctly for me for years. And if there's an admin command that I'm
for some reason running not as root it should a) be moved out of sbin or b)
I probably at least want to think about it and so typing the path doesn't
hurt.

> I think the chance for putting it back is still there.. if someone is
> willing to do the work on the hard but correct way? I think it was
> crickets the last couple of times when volunteers were asked for that.

Sure, I'm willing to work on it.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mattdm at mattdm.org  Wed Oct  1 03:52:55 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 30 Sep 2008 23:52:55 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081001023752.GO5093@duckland.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<20081001023752.GO5093@duckland.org>
Message-ID: <20081001035255.GB21890@jadzia.bu.edu>

On Tue, Sep 30, 2008 at 09:37:52PM -0500, Don Harper wrote:
> Open a bug to put sbin *after* bin?  I have had sbin in my path for
> years, and I do not have those issues, and I always set bin dirs before
> the sbin dirs.

Putting sbin after bin does not change anything.

Since you've had your own system set this way for years, you don't know what
you're missing with bash_completion.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From fedora at leemhuis.info  Wed Oct  1 04:57:03 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 01 Oct 2008 06:57:03 +0200
Subject: Please recompile GStreamer codecs -- AKA: how to make things
 just work with PackageKit
In-Reply-To: <gbtr8l$6ie$1@ger.gmane.org>
References: <1222771953.3291.12.camel@hughsie-laptop>	<48E209E5.5070705@leemhuis.info>	<15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com>	<48E251BE.2090209@leemhuis.info>
	<gbtr8l$6ie$1@ger.gmane.org>
Message-ID: <48E3031F.5060408@leemhuis.info>

On 30.09.2008 20:30, Matthew Woehlke wrote:
> Thorsten Leemhuis wrote:
>> [...]eveyone please use this command to get the repo files from now on:
>>
>> == Fedora 8 and 9  ==
>>
>> rpm -ivh
>> http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm 
>> http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm 
> 
> Given the recent security scare, is this information (along with keys, I 
> hope!) also posted somewhere "trustworthy"?

Not yet, sorry. It's a whole lot of work to get a new repo running and 
nobody thought of the above yet afaics. So if you want to help with this 
join the mailing list
http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-developers

> Would it be possible to drop a new-release rpm into livna so that livna 
> users can get the new repo rpm from livna rather than having to trust 
> the URL in (if you'll pardon me) some random e-mail?

Yes, exactly that is the plan (that was already mentioned two mails 
earlier in this thread) ;-)

CU
knurd



From rjones at redhat.com  Wed Oct  1 07:58:29 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 1 Oct 2008 08:58:29 +0100
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <20080930193559.GA12982@amd.home.annexia.org>
References: <20080930171332.GB12353@amd.home.annexia.org>
	<loom.20080930T190837-765@post.gmane.org>
	<20080930193559.GA12982@amd.home.annexia.org>
Message-ID: <20081001075829.GA13065@amd.home.annexia.org>

On Tue, Sep 30, 2008 at 08:35:59PM +0100, Richard W.M. Jones wrote:
> It's a bit worse than that as well because I've just discovered that
> this package [openssl] needs Wine to build as well as to run the
> tests :-(

Dan ^^ ?

I can see two possible fixes for this issue in general:

(a) Set BuildArch i386, so it only builds on i386.  This is nasty
because the output package ends up as i386, which it isn't (rpm
doesn't know the difference between build architecture and host
architecture).

[What's the difference between BuildArch and ExclusiveArch?]

Or:

(b) Work with upstream to remove the need to run executables during
the build.

This (b) seems like a rare case where this project will benefit
cross-compilers in general, because with cross-compilation you should
never need to run built executables during a build.  For example if
the target architecture was some ARM embedded chipset, there might not
even exist an emulator to run the executables.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From kevin.kofler at chello.at  Wed Oct  1 08:25:53 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 1 Oct 2008 08:25:53 +0000 (UTC)
Subject: Running Xvfb during a package build -- good idea?
References: <20080930171332.GB12353@amd.home.annexia.org>
	<loom.20080930T190837-765@post.gmane.org>
	<20080930193559.GA12982@amd.home.annexia.org>
	<20081001075829.GA13065@amd.home.annexia.org>
Message-ID: <loom.20081001T082455-473@post.gmane.org>

Richard W.M. Jones <rjones <at> redhat.com> writes:
> (b) Work with upstream to remove the need to run executables during
> the build.

This really sounds like the right solution to me.

And if upstream is unwilling to add cross-compilation support, then 
cross-compilation patches will have to be maintained elsewhere.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct  1 08:29:31 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 1 Oct 2008 08:29:31 +0000 (UTC)
Subject: Running Xvfb during a package build -- good idea?
References: <20080930171332.GB12353@amd.home.annexia.org>
	<loom.20080930T190837-765@post.gmane.org>
	<20080930193559.GA12982@amd.home.annexia.org>
	<20081001075829.GA13065@amd.home.annexia.org>
Message-ID: <loom.20081001T082713-134@post.gmane.org>

Oh, and I forgot:

Richard W.M. Jones <rjones <at> redhat.com> writes:
> (b) Work with upstream to remove the need to run executables during
> the build.

You don't have to actually remove the need to run executables entirely, you 
just have to make sure the executables are built with the correct compiler: 
executables which run at build time have to be built with the native host 
compiler, not the target cross-compiler. If the executables are needed both at 
build time and at run time, they have to be built twice, once with the native 
compiler and once with the cross-compiler.

But if the executables are part of configure checks, then the correct solution 
is to provide a sane default for those checks for the cross-compilation case.

        Kevin Kofler



From pertusus at free.fr  Wed Oct  1 08:40:57 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 1 Oct 2008 10:40:57 +0200
Subject: Fedora rawhide rebuild in mock status 2008-09-30 i386
In-Reply-To: <20080930190158.GA28271@mock.linuxdev.us.dell.com>
References: <20080930190158.GA28271@mock.linuxdev.us.dell.com>
Message-ID: <20081001084057.GA3094@free.fr>

On Tue, Sep 30, 2008 at 02:01:58PM -0500, Matt Domsch wrote:
> 
> pertusus: cernlib,cernlib-g77,fltk,hdf,w3lib

cernlib,cernlib-g77,w3lib are fixed.

I'll look at the other I comaintain after bugs are filled.

--
Pat



From berrange at redhat.com  Wed Oct  1 09:17:49 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 1 Oct 2008 10:17:49 +0100
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <20081001075829.GA13065@amd.home.annexia.org>
References: <20080930171332.GB12353@amd.home.annexia.org>
	<loom.20080930T190837-765@post.gmane.org>
	<20080930193559.GA12982@amd.home.annexia.org>
	<20081001075829.GA13065@amd.home.annexia.org>
Message-ID: <20081001091749.GB26567@redhat.com>

On Wed, Oct 01, 2008 at 08:58:29AM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 30, 2008 at 08:35:59PM +0100, Richard W.M. Jones wrote:
> > It's a bit worse than that as well because I've just discovered that
> > this package [openssl] needs Wine to build as well as to run the
> > tests :-(
> 
> Dan ^^ ?
> 
> I can see two possible fixes for this issue in general:
> 
> (a) Set BuildArch i386, so it only builds on i386.  This is nasty
> because the output package ends up as i386, which it isn't (rpm
> doesn't know the difference between build architecture and host
> architecture).
> 
> [What's the difference between BuildArch and ExclusiveArch?]
> 
> Or:
> 
> (b) Work with upstream to remove the need to run executables during
> the build.
> 
> This (b) seems like a rare case where this project will benefit
> cross-compilers in general, because with cross-compilation you should
> never need to run built executables during a build.  For example if
> the target architecture was some ARM embedded chipset, there might not
> even exist an emulator to run the executables.

What exactly is required to be run during build ?

As an example, GTK / GLib have a requirement to run glib-genmarshal 
during their build process. The upstream source explicitly deals with
this in a cross-compile environment by running the native version
to generate the data for the cross-compile.  As such the mingw-gtk
package BuildRequires  the same version of the native 'gtk' RPM.

I'd imagine a similar solution would be sensible for openssl, though
without knowing what its doing I can't say for sure.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From david at hlacik.eu  Wed Oct  1 09:23:36 2008
From: david at hlacik.eu (=?ISO-8859-2?Q?David_Hl=E1=E8ik?=)
Date: Wed, 1 Oct 2008 11:23:36 +0200
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <20080930193705.GB12982@amd.home.annexia.org>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
Message-ID: <cba415ca0810010223n25c41169tebe604d12f81eff0@mail.gmail.com>

Guys, and what about RedHat policy. Which virtualization technology
will they officially use for RedHat 6?

Thanks,

David

On Tue, Sep 30, 2008 at 9:37 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Tue, Sep 30, 2008 at 09:25:45PM +0200, David Hl??ik wrote:
>> Hi , guys, I have found in Fedora 10 Features , that there is still a
>> lot of work to provide xen kernel with dom0 support to Fedora 10 GA.
>> For my future project, which at 90 percent depends on virtualization
>> technology I am deciding between XEN or KVM virtualization. I am
>> experienced XEN user, KVM is new for me. But as I am aware of,
>> Qumranet was bought by RedHat which predicts something ...
>
> Yup, KVM is cool, much easier to use, and with virtio-enabled guests
> it's about the same speed as Xen.  So what was your question :-?
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://et.redhat.com/~rjones/virt-top
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From berrange at redhat.com  Wed Oct  1 09:31:05 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 1 Oct 2008 10:31:05 +0100
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <cba415ca0810010223n25c41169tebe604d12f81eff0@mail.gmail.com>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<cba415ca0810010223n25c41169tebe604d12f81eff0@mail.gmail.com>
Message-ID: <20081001093105.GC26567@redhat.com>

On Wed, Oct 01, 2008 at 11:23:36AM +0200, David Hl??ik wrote:
> Guys, and what about RedHat policy. Which virtualization technology
> will they officially use for RedHat 6?

Red Hat policy is for our developers to not speculate on tech details of
products before they're officially announced ;-P

Unofficially, of course it is no secret that RHEL releases are derived from
the state of the art Fedora releases at time of each RHEL development cycle.
So looking at best practice in Fedora is a possible guide to the future...

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From denis at poolshark.org  Wed Oct  1 10:23:08 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 01 Oct 2008 12:23:08 +0200
Subject: F10 beta: live img boot vs installed boot
Message-ID: <48E34F8C.5000305@poolshark.org>

This is on a T61 (nVidia Quadro NVS 140M).

The Live i686 image works SUPERBLY from a 4G USB stick. I can even 
hot-plug a external monitor, run the screen resolution and voila monitor 
is auto-detected and dual-head can be configured dynamically. Holy Wayne 
Lord of the Malt Beverages, it just works! I ran into a few bugs, but 
nothing too drastic (live img won't boot when external monitor is 
plugged in, changing the desktop font size doesn't update existing 
desktop icons).

I successfully installed the live image onto a 8G USB stick. However 
booting the 8G stick does not work. The boot behaviour is very 
different: it's booting in a text mode with a bottom text "progress 
bar". Once the progress bar becomes all white, the system just hangs 
there. No mingetty to escape to, no error messages. How can I provide 
more information ?

-denis



From dominik at greysector.net  Wed Oct  1 10:40:24 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 1 Oct 2008 12:40:24 +0200
Subject: Fedora rawhide rebuild in mock status 2008-09-30 x86_64
In-Reply-To: <20080930190134.GA28051@mock.linuxdev.us.dell.com>
References: <20080930190134.GA28051@mock.linuxdev.us.dell.com>
Message-ID: <20081001104024.GB27277@mokona.greysector.net>

On Tuesday, 30 September 2008 at 21:01, Matt Domsch wrote:
> Fedora Rawhide-in-Mock Build Results for x86_64
[...]
> Of those expected to have worked...
> Without a bug filed: 173
> ----------------------------------
[...]
> freefem++-2.24-4.2.fc10 (build/make) rathann

What? Built fine in koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=64519

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From rawhide at fedoraproject.org  Wed Oct  1 10:55:58 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed,  1 Oct 2008 10:55:58 +0000 (UTC)
Subject: rawhide report: 20081001 changes
Message-ID: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>

New package elfinfo
        ELF file parser a subset of eu-readelf
New package freedink
        Adventure and role-playing game
New package freedink-data
        Adventure and role-playing game (game data)
New package freedink-dfarc
        Frontend and .dmod installer for GNU FreeDink
New package greadelf
        Wrapper tool for eu-readelf
New package hunspell-be
        Belarusian hunspell dictionaries
New package numptyphysics
        A crayon-drawing based physics puzzle game
New package perl-Wx-Perl-Dialog
        Wx::Perl::Dialog Perl module
New package pypop
        Python for Population Genomics
New package rubber
        An automated system for building LaTeX documents
New package sim
        SIM - Multiprotocol Instant Messenger
Updated Packages:

NetworkManager-0.7.0-0.11.svn4022.3.fc10
----------------------------------------
* Tue Sep 30 18:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.11.svn4022.3
- Fix handling of VPN settings on upgrade (rh #460730, bgo #553465)


NetworkManager-openvpn-0.7.0-16.svn4027.fc10
--------------------------------------------
* Tue Sep 30 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-16.svn4027
- Fix order of Password TLS certificate choosers (rh #464765)
- Use /usr/lib/rpm/find-lang.sh /builddir/build/BUILDROOT/NetworkManager-openvpn-0.7.0-16.svn4027.fc10.ppc for locale-specific files (rh #448551)
- Fix --script-security issues with OpenVPN 2.1-rc9 and later (rh #460754)


PackageKit-0.3.5-3.fc10
-----------------------
* Tue Sep 30 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.5-3
- Fix a bug where the daemon could crash when cancelling a lot of transactions.
- Fix installing codecs with a 64 bit machine

* Tue Sep 30 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.5-2
- Obsolete more releases of codeina to fix upgrades on rawhide.


bluez-gnome-1.7-1.fc10
----------------------
* Tue Sep 30 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.7-1
- Update to 1.7


bodhi-0.5.3-1.fc10
------------------
* Wed Sep 10 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.3-1
- Latest upstream release

* Wed Sep  3 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.2-2
- Add the masher deps to BuildRequires, since it now resides
  on the turbogears.extensions entry point and will be
  imported by pkg_resources at build time.

* Wed Sep  3 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.2-1
- Latest upstream bugfix release

* Fri Aug 29 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.1-3
- Fix some setuptools issues with our client subpackage

* Mon Aug 25 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.1-2
- Include the egg-info in the client subpackage.

* Fri Aug 22 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.1-1
- Latest upstream release


cdparanoia-10.2-2.fc10
----------------------
* Tue Sep 30 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 10.2-2
- fix cdda_interface.h C++ incompatibility (patch from upstream) (#463009)


cjkunifonts-0.2.20080216.1-5.fc10
---------------------------------
* Wed Oct  1 18:00:00 2008 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-5.fc10
- Resolves: rhbz#459680 (Unsymlinked 25-ttf-arphic-uming-bitmaps.conf.)


control-center-2.24.0.1-2.fc10
------------------------------
* Tue Sep 30 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0.1-2
- Fix a schema mistranslation


dhcp-4.0.0-28.fc10
------------------
* Tue Sep 30 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-28
- Forgot to actually include <errno.h> (#438149)

* Tue Sep 30 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-27
- Fix patch fuzziness and include errno.h in includes/dhcpd.h (#438149)

* Tue Sep 30 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-26
- Validate port numbers for dhclient, dhcpd, and dhcrelay to ensure
  that are within the correct range (#438149)


dosfstools-3.0.0-1.fc10
-----------------------
* Tue Sep 30 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.0.0-1
- update to 3.0.0


esc-1.0.1-11.fc10
-----------------
* Tue Sep 30 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.1-11
- xulrunner still broken for sparc64

* Tue Sep 30 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.1-10
- fix esc for sparc/sparc64


gdal-1.5.2-4.fc10
-----------------
* Tue Sep 30 18:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 1.5.2-4
- enable gdal_array for python subpackage
- require numpy


gdm-2.24.0-7.fc10
-----------------
* Tue Sep 30 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 1:2.24.0-7
- Make panel slide in initially like the gnome panel

* Tue Sep 30 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 1:2.24.0-6
- drop background priority change.  Choppyiness in -3 ended up
  being a bug in gnome-settings-daemon.
- pull patch from upstream to scale face icons with fontsize


gnome-settings-daemon-2.24.0-3.fc10
-----------------------------------
* Tue Sep 30 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-3
- Fix the picking up of the gdm keyboard layout


gnucash-2.2.7-1.fc10
--------------------
* Tue Sep 30 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 2.2.7-1
- update to 2.2.7


goocanvas-0.10-2.fc10
---------------------
* Tue Sep 30 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.10-2
- demo application does not build; remove it


gvfs-1.0.1-3.fc10
-----------------

hunspell-ca-0.20080918-1.fc10
-----------------------------
* Tue Sep 30 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20080918-1
- latest version


hunspell-tn-0.20060123-2.fc10
-----------------------------
* Tue Sep 30 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20060123-2
- add Botswana alias


hunspell-uk-1.5.5-1.fc10
------------------------
* Tue Sep 30 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.5.5-1
- latest version


ibus-0.1.1.20081001-1.fc10
--------------------------
* Wed Oct  1 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081001-1
- Update to 0.1.1.20081001.


initscripts-8.83-1
------------------
* Tue Sep 30 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 8.83-1
- various merge review fixes (#225900)
  Notably: init scripts/network scripts are no longer %config
- remove some extraneous device-mapper initialization
- use pidfile in status before calling pidof (#463205)
- use plymouth directly, not the rhgb-client wrapper
- move bridging after bonding (#449950, <djuran at redhat.com>)
- use alsactl to save sound settings. (#462677, <jkysela at redhat.com>)
- quit plymouth differently (<rstrode at redhat.com>)
- make sure we don't try and spawn a repair shell when there's no
  tty (#463161)
- move udev rules to /lib
- stateless updates (#433702, <harald at redhat.com>)
- call logger with a full path (#447928, <harald at redhat.com>)
- translation updates: as, bn_IN, ca, cz, de, es, fi, fr, gu, it, ja,
  lv, mr, nl, or, pa, pl, pt_BR, ru, te, zh_TW


kdebase-runtime-4.1.2-3.fc10
----------------------------
* Tue Sep 30 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-3
- add missing icons


kdemultimedia-4.1.2-2.fc10
--------------------------
* Mon Sep 29 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-2
- make VERBOSE=1
- respin against new(er) kde-filesystem

* Fri Sep 26 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-1
- 4.1.2

* Wed Sep 17 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.1-2
- backport from trunk to fix dragon kpart crash in the embedding application


kernel-2.6.27-0.372.rc8.fc10
----------------------------

kpackagekit-0.1-1.fc10
----------------------
* Mon Sep 29 18:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 0.1-1
Official 0.1 release

* Sun Aug 24 18:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 0.1-0.3.b4
- Excluded underdevelopment binaries and associated files


libdrm-2.4.0-0.21.fc10
----------------------
* Tue Sep 30 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.4.0-0.21
- move intel bufmgr code around - update patches

* Tue Sep  9 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.4.0-0.20
- add gtt mapping for intel modesetting


libgnome-2.24.1-4.fc10
----------------------
* Tue Sep 30 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-4
- Fix multilib conflicts with touch


libselinux-2.0.73-1.fc10
------------------------
* Tue Sep 30 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.73-1
- Update to Upstream
	* New man pages from Dan Walsh.
	* Update flask headers from refpolicy trunk from Dan Walsh.


libsepol-2.0.33-1.fc10
----------------------
* Tue Sep 30 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.33-1
- Upgrade to latest from NSA
	* Revert patch that removed expand_rule.


libtasn1-1.5-1.fc10
-------------------
* Tue Sep 30 18:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 1.5-1
- updated to new upstream version
- fix license tag
- fix spurious rpath in the tool binaries


lyx-1.6.0-0.9.rc3.fc10
----------------------
* Tue Sep 30 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.6.0-0.9.rc3
- lyx-1.6.0rc3


machineball-1.0-6.fc10
----------------------
* Mon Sep 15 18:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 1.0-6
- Rebuild for new ode


mailgraph-1.14-3.fc10
---------------------
* Tue Sep 30 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 1.14-3
- fix patch fuzz


malaga-suomi-voikko-1.2-0.1.rc1.fc10
------------------------------------
* Wed Oct  1 18:00:00 2008 - Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> 1.2-0.1.rc1
- New release candidate


maniadrive-1.2-10.fc10
----------------------
* Mon Sep 15 18:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 1.2-10
- Rebuild for new ode


nspluginwrapper-1.1.0-9.fc10
----------------------------
* Tue Sep 30 18:00:00 2008 Martin Stransky <stransky at redhat.com> 1.1.0-9
- Updated fix for #456432 -(Windowless Crash) Flash 10 w/ Firefox 3


nspr-4.7.1-3.fc10
-----------------
* Tue Sep 30 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 4.7.1-3
- add sparc64 to the list of 64 bit arches


nss-mdns-0.10-6.fc10
--------------------
* Tue Sep 30 18:00:00 2008 Stepan Kasal <skasal at redhat.com> - 0.10-6
- use sed instead of perl in %post and %preun (#462996),
  fixing two bugs in the scriptlets:
  1) the backup file shall be nsswitch.conf.bak, not nsswitch.confbak
  2) the first element after host: shall be subject to removal, too
- consequently, removed the Requires(..): perl
- removed the reqires for things that are granted
- a better BuildRoot


packagekit-qt-0.1-1.fc10
------------------------
* Mon Sep 29 18:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 0.1-1
- New upstream release  Official .1 release


pdfedit-0.4.1-2.fc10
--------------------
* Tue Sep 30 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.4.1-2
- fix patch fuzz


perl-PDF-API2-0.69-6.fc10
-------------------------
* Tue Sep 30 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.69-6
- fix patch fuzz
- change patch numbering


phonon-4.2.0-7.fc10
-------------------
* Tue Sep 30 18:00:00 2008 Than Ngo <than at redhat.com> 4.2.0-7
- fix tranparent issue by convert

* Tue Sep 30 18:00:00 2008 Than Ngo <than at redhat.com> 4.2.0-6
- add missing icon


php-pear-PHP-CompatInfo-1.8.1-1.fc10
------------------------------------
* Tue Sep 30 18:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 1.8.1-1
- update to 1.8.1


php-pear-XML-Parser-1.3.1-1.fc10
--------------------------------
* Tue Sep 30 18:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 1.3.1-1
- fix in package.xml (license)


plymouth-0.6.0-0.2008.09.25.2.fc10
----------------------------------
* Tue Sep 30 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.09.25.2
- Remove mkinitrd requires to break the dep loop and ensure things
  get installed in the right order


ppl-0.9-25.fc10
---------------
* Tue Sep 30 18:00:00 2008 Roberto Bagnara <bagnara at cs.unipr.it> 0.9-25
- The `swiprolog' package now requires pl >= 5.6.57-2.


python-2.5.2-1.fc10
-------------------
* Tue Sep 30 18:00:00 2008 James Antill <katzj at redhat.com> - 2.5.2-1
- Move to 2.5.2
- Fix CVE-2008-2316 hashlib overflow.


python-pyblock-0.32-1.fc10
--------------------------
* Tue Sep 30 18:00:00 2008 Peter Jones <pjones at redhat.com> - 0.32-1
- Update for libdmraid 1.0.0.rc15 .


python-webob-0.9.3-2.fc10
-------------------------
* Tue Sep 30 18:00:00 2008 Ricky Zhou <ricky at fedoraproject.org> 0.9.3-1
- Upstream released new version.

* Tue Sep 30 18:00:00 2008 Ricky Zhou <ricky at fedoraproject.org> 0.9.3-1
- Add BuildRequires on python-tempita.


queuegraph-1.1-4.fc10
---------------------
* Tue Sep 30 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 1.1-4
- fix patch fuzz


selinux-policy-3.5.9-2.fc10
---------------------------
* Mon Sep 29 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.9-2
- Change all user tmpfs_t files to be labeled user_tmpfs_t
- Allow radiusd to create sock_files


slrn-0.9.9p1-1.fc10
-------------------
* Tue Sep 30 18:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> 0.9.9p1-1
- update to 0.9.9p1


squashfs-tools-3.4-1
--------------------
* Tue Sep 30 18:00:00 2008 Jeremy Katz <katzj at redhat.com> - 3.4-1
- update to 3.4


subversion-1.5.2-3
------------------
* Tue Sep 30 18:00:00 2008 Joe Orton <jorton at redhat.com> 1.5.2-3
- enable SASL support (#464267)

* Fri Sep 12 18:00:00 2008 Joe Orton <jorton at redhat.com> 1.5.2-2
- update to 1.5.2


vim-7.2.022-1.fc10
------------------
* Tue Sep 30 18:00:00 2008 Karsten Hopp <karsten at redhat.com> 7.2.022-1
- patchlevel 22


wxPython-2.8.9.1-1.fc10
-----------------------
* Tue Sep 30 18:00:00 2008 Dan Horak <dan[at]danny.cz> - 2.8.9.1-1
- update to 2.8.9.1
- fix libdir for additional wx libraries (#306761)


xmoto-0.4.2-3.fc10
------------------
* Tue Sep 30 18:00:00 2008 Jon Ciesla <limb at jcomserv.net> 0.4.2-3
- Patch for new ode version.


xorg-x11-drv-nv-2.1.12-5.fc10
-----------------------------
* Tue Sep 30 18:00:00 2008 Dan Williams <dcbw at redhat.com> 2.1.12-5
- Port Toshiba Tecra M2 NV34 panel tweak to pciaccess


xorg-x11-server-1.5.1-4.fc10
----------------------------
* Tue Sep 30 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.5.1-4
- fix typo. :P

* Tue Sep 30 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.5.1-3
- add xvfb-run helper script to Xvfb package


zabbix-1.6-1.1.fc10
-------------------
* Tue Sep 30 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6-1.1
- Bump release because forgot to add some new files.

* Tue Sep 30 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6-1
- Update to final 1.6


Summary:
Added Packages: 11
Removed Packages: 0
Modified Packages: 61
Broken deps for i386
----------------------------------------------------------
	ant-manual-1.7.1-7.1.fc10.i386 requires perl(the)
	beagle-evolution-0.3.8-6.fc10.i386 requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	python-docs-2.5.1-2.fc9.noarch requires python = 0:2.5.1
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	stormbaancoureur-2.1.4-1.fc10.i386 requires libode.so.0



Broken deps for x86_64
----------------------------------------------------------
	ant-manual-1.7.1-7.1.fc10.x86_64 requires perl(the)
	beagle-evolution-0.3.8-6.fc10.x86_64 requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	python-docs-2.5.1-2.fc9.noarch requires python = 0:2.5.1
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	stormbaancoureur-2.1.4-1.fc10.x86_64 requires libode.so.0()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ant-manual-1.7.1-7.1.fc10.ppc requires perl(the)
	beagle-evolution-0.3.8-6.fc10.ppc requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	python-docs-2.5.1-2.fc9.noarch requires python = 0:2.5.1
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so
	stormbaancoureur-2.1.4-1.fc10.ppc requires libode.so.0



Broken deps for ppc64
----------------------------------------------------------
	ant-manual-1.7.1-7.1.fc10.ppc64 requires perl(the)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit)
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	python-docs-2.5.1-2.fc9.noarch requires python = 0:2.5.1
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	stormbaancoureur-2.1.4-1.fc10.ppc64 requires libode.so.0()(64bit)





From berrange at redhat.com  Wed Oct  1 11:03:26 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 1 Oct 2008 12:03:26 +0100
Subject: rawhide report: 20081001 changes
In-Reply-To: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
Message-ID: <20081001110326.GK26567@redhat.com>

On Wed, Oct 01, 2008 at 10:55:58AM +0000, Rawhide Report wrote:
> 
> Summary:
> Added Packages: 11
> Removed Packages: 0
> Modified Packages: 61
> Broken deps for i386
> ----------------------------------------------------------
> 	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
> 	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
> 	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0

What's going on with this package ?  In CVS devel/ it has just been
removed  with a terse commit message "Marking pyclutter as dead.package",
but it is not orphaned in pkgdb. Was it killed because it not longer works
with clutter / not maintained upstream, or because the Fedora maintainer
lost interest, or something else ? In any case if it is not going to be
resurrected, the F9 packages need to be blocked from rawhide repos since
their deps are  no longer satisfied, and i guess orphaned in pkgdb

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From Matt_Domsch at dell.com  Wed Oct  1 12:34:37 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 1 Oct 2008 07:34:37 -0500
Subject: Fedora rawhide rebuild in mock status 2008-09-30 x86_64
In-Reply-To: <20081001104024.GB27277@mokona.greysector.net>
References: <20080930190134.GA28051@mock.linuxdev.us.dell.com>
	<20081001104024.GB27277@mokona.greysector.net>
Message-ID: <20081001123437.GA11784@auslistsprd01.us.dell.com>

On Wed, Oct 01, 2008 at 12:40:24PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 30 September 2008 at 21:01, Matt Domsch wrote:
> > Fedora Rawhide-in-Mock Build Results for x86_64
> [...]
> > Of those expected to have worked...
> > Without a bug filed: 173
> > ----------------------------------
> [...]
> > freefem++-2.24-4.2.fc10 (build/make) rathann
> 
> What? Built fine in koji:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=64519

%check failed in my build, but only on x86_64, not i386.

--------- file : convect.edp -----------------
  --  mesh:  Nb of Triangles =    882, Nb of Vertices 477
FAIL: ../regtests.sh
=====================================
1 of 1 tests failed
Please report to hecht at ann.jussieu.fr
=====================================
make[2]: Leaving directory `/builddir/build/BUILD/freefem++-2.24-2/examples++-tutorial'
make[2]: *** [check-TESTS] Error 1
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/freefem++-2.24-2/examples++-tutorial'
make: *** [check-recursive] Error 1
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.6Tfn7L (%check)
    Bad exit status from /var/tmp/rpm-tmp.6Tfn7L (%check)


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



From jeevanullas at gmail.com  Wed Oct  1 11:21:28 2008
From: jeevanullas at gmail.com (Deependra Singh Shekhawat)
Date: Wed, 01 Oct 2008 16:51:28 +0530
Subject: F10 beta: live img boot vs installed boot
In-Reply-To: <48E34F8C.5000305@poolshark.org>
References: <48E34F8C.5000305@poolshark.org>
Message-ID: <1222860088.5978.2.camel@station1.example.com>

Hi,

Can you see /var/log/boot.log somehow ?

Probably /var/log/boot.log and /var/log/messages will have more info.

I don't see any plymouth loading for me too either but it boots just
fine. I somehow managed to install nvidia driver too but still no
graphical boot. :)

Regards
Deependra Singh Shekhawat

On Wed, 2008-10-01 at 12:23 +0200, Denis Leroy wrote:
> This is on a T61 (nVidia Quadro NVS 140M).
> 
> The Live i686 image works SUPERBLY from a 4G USB stick. I can even 
> hot-plug a external monitor, run the screen resolution and voila monitor 
> is auto-detected and dual-head can be configured dynamically. Holy Wayne 
> Lord of the Malt Beverages, it just works! I ran into a few bugs, but 
> nothing too drastic (live img won't boot when external monitor is 
> plugged in, changing the desktop font size doesn't update existing 
> desktop icons).
> 
> I successfully installed the live image onto a 8G USB stick. However 
> booting the 8G stick does not work. The boot behaviour is very 
> different: it's booting in a text mode with a bottom text "progress 
> bar". Once the progress bar becomes all white, the system just hangs 
> there. No mingetty to escape to, no error messages. How can I provide 
> more information ?
> 
> -denis
> 
-- 
-----------------------------
Type bits /keyID Date User ID
pub 1024D/483B234C 2007/06/29 Deependra Singh Shekhawat (Fedora Project)
<jeevanullas at gmail.com>
Key fingerprint = ED45 62EA A4D7 53FB 44C7 774A D55B F3F0 483B 234C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/2db8399d/attachment.sig>

From cmadams at hiwaay.net  Wed Oct  1 13:02:05 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 1 Oct 2008 08:02:05 -0500
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081001035255.GB21890@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<20081001023752.GO5093@duckland.org>
	<20081001035255.GB21890@jadzia.bu.edu>
Message-ID: <20081001130205.GA1366481@hiwaay.net>

Once upon a time, Matthew Miller <mattdm at mattdm.org> said:
> Since you've had your own system set this way for years, you don't know what
> you're missing with bash_completion.

Complaining about "fir<TAB>" not exclusively tab completing to "firefox"
is a bit silly IMHO.  What if you have firestarter or firstaidkit (just
to name a couple) installed?  Would you complain if either was added to
the desktop install because you couldn't type "fir<TAB>" and get
firefox?

Yes, tab completion is great, and I've used it for many years in many
incarnations.  I've learned to adapt to a changing set of installed
programs.  Also, I consider completion more useful for arguments than
commands.

-- 
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 msolberg at redhat.com  Wed Oct  1 13:09:04 2008
From: msolberg at redhat.com (Michael Solberg)
Date: Wed, 01 Oct 2008 09:09:04 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <200809301938.44849.konrad@tylerc.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200809301938.44849.konrad@tylerc.org>
Message-ID: <1222866544.22856.49.camel@localhost.localdomain>


On Tue, 2008-09-30 at 19:38 -0700, Conrad Meyer wrote:
> On Tuesday 30 September 2008 07:24:58 pm Matthew Miller wrote:
> > We've just made the command line a lot less user friendly for common use in
> > exchange for an ugly fix to a small inconvenience. *Any* chance of putting
> > this back and working at fixing the problem the hard but correct way?
> 
> This seems more a complaint that tab completion is different from what you're 
> used to. Many users feel the opposite (they add sbin to PATH in their 
> dotfiles) and won't notice the change. For users new to linux and Fedora, 
> sbin being in PATH gives them a better user experience than 'bash: foo: 
> command not found' errors when they try to follow some guide on the web.

I guess I missed the first round of this discussion - but I agree with
Matthew.  Having commands on the path that a user can't execute:

[msolberg at localhost ~]$ iptables -nL
iptables v1.4.1.1: can't initialize iptables table `filter': Permission
denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

Is a worse experience than having to remember to type /sbin/ifconfig
because it's normally a "rootly" command.  This is Linux, after all.

Michael.




From mattdm at mattdm.org  Wed Oct  1 13:08:15 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 1 Oct 2008 09:08:15 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081001130205.GA1366481@hiwaay.net>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<20081001023752.GO5093@duckland.org>
	<20081001035255.GB21890@jadzia.bu.edu>
	<20081001130205.GA1366481@hiwaay.net>
Message-ID: <20081001130815.GA8025@jadzia.bu.edu>

On Wed, Oct 01, 2008 at 08:02:05AM -0500, Chris Adams wrote:
> > Since you've had your own system set this way for years, you don't know what
> > you're missing with bash_completion.
> Complaining about "fir<TAB>" not exclusively tab completing to "firefox"
> is a bit silly IMHO.  What if you have firestarter or firstaidkit (just
> to name a couple) installed?  Would you complain if either was added to
> the desktop install because you couldn't type "fir<TAB>" and get
> firefox?

I'd be annoyed if $( ls /sbin/ /usr/sbin/|wc -l ) 671 binaries were added to
the default path of desktop install by any means.


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From jarod at redhat.com  Wed Oct  1 13:23:06 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Wed, 1 Oct 2008 09:23:06 -0400
Subject: make mail go somewhere by default
In-Reply-To: <16de708d0809301845o13c5e1ax898f29d5745387e9@mail.gmail.com>
References: <20080924212236.GJ1414283@hiwaay.net>
	<200809301659.12364.jarod@redhat.com>
	<16de708d0809301845o13c5e1ax898f29d5745387e9@mail.gmail.com>
Message-ID: <200810010923.07413.jarod@redhat.com>

On Tuesday 30 September 2008 21:45:17 Arthur Pemberton wrote:
> On Tue, Sep 30, 2008 at 3:59 PM, Jarod Wilson <jarod at redhat.com> wrote:
> > On Thursday 25 September 2008 16:26:29 Jarod Wilson wrote:
> >> Les Mikesell wrote:
> >> > Matthew Miller wrote:
> >> >> On Wed, Sep 24, 2008 at 04:39:26PM -0700, Jesse Keating wrote:
> >> >>> Which is why we shouldn't be using local delivery for this stuff.
> >> >>> Instead we should ask in firstboot where you'd want the mail
> >> >>> delivered to.
> >> >>
> >> >> Ooh! And do it this way!
> >> >>
> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=143437
> >> >
> >> > That's a good technique, but wouldn't it follow the system style more
> >> > closely to put install/firstboot setting snippets somewhere under
> >> > /etc/sysconfig with the stock alias file including from there?
> >>
> >> Hm... I wrote a firstboot patch ages ago (almost 3 years ago?) that let
> >> you say "send root mail to this user" when you added a user in
> >> firstboot... Its even in bz somewhere, iirc...
> >
> > Thar she blows:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=135592
>
> Should I consider this a dupe?
> https://bugzilla.redhat.com/show_bug.cgi?id=463864
>
> Mine is a bit more broad.

If I'm reading my old patch correctly and your bz, they actually cover pretty 
much the same things, the only difference really was your suggestion that it 
be mandatory or at least strongly suggested to set up forwarding of some sort. 
I left it optional, but did provide means to 1) forward root mail to a user on 
the system and 2) forward mail along to an email account external to the 
system (via a .forward file in the user's home directory). So yeah, I'd say 
dupe it.

-- 
Jarod Wilson
jarod at redhat.com



From dominik at greysector.net  Wed Oct  1 13:30:23 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 1 Oct 2008 15:30:23 +0200
Subject: Fedora rawhide rebuild in mock status 2008-09-30 x86_64
In-Reply-To: <20081001123437.GA11784@auslistsprd01.us.dell.com>
References: <20080930190134.GA28051@mock.linuxdev.us.dell.com>
	<20081001104024.GB27277@mokona.greysector.net>
	<20081001123437.GA11784@auslistsprd01.us.dell.com>
Message-ID: <20081001133022.GC27277@mokona.greysector.net>

On Wednesday, 01 October 2008 at 14:34, Matt Domsch wrote:
> On Wed, Oct 01, 2008 at 12:40:24PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > On Tuesday, 30 September 2008 at 21:01, Matt Domsch wrote:
> > > Fedora Rawhide-in-Mock Build Results for x86_64
> > [...]
> > > Of those expected to have worked...
> > > Without a bug filed: 173
> > > ----------------------------------
> > [...]
> > > freefem++-2.24-4.2.fc10 (build/make) rathann
> > 
> > What? Built fine in koji:
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=64519
> 
> %check failed in my build, but only on x86_64, not i386.

Yes, I saw it afterwards, but I can't reproduce it.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From fedora at camperquake.de  Wed Oct  1 14:13:43 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 1 Oct 2008 16:13:43 +0200
Subject: rawhide report: 20081001 changes
In-Reply-To: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
Message-ID: <20081001161343.6efb564a@dhcp03.addix.net>

Hi.

On Wed,  1 Oct 2008 10:55:58 +0000 (UTC), Rawhide Report wrote:

> libdrm-2.4.0-0.21.fc10
> ----------------------

If you're running an Intel graphics chip you may want to skip this one.



From sundaram at fedoraproject.org  Wed Oct  1 14:20:30 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 01 Oct 2008 19:50:30 +0530
Subject: rawhide report: 20081001 changes
In-Reply-To: <20081001161343.6efb564a@dhcp03.addix.net>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
	<20081001161343.6efb564a@dhcp03.addix.net>
Message-ID: <48E3872E.8050602@fedoraproject.org>

Ralf Ertzinger wrote:
> Hi.
> 
> On Wed,  1 Oct 2008 10:55:58 +0000 (UTC), Rawhide Report wrote:
> 
>> libdrm-2.4.0-0.21.fc10
>> ----------------------
> 
> If you're running an Intel graphics chip you may want to skip this one.

Can you tell us why?

Rahul



From fedora at camperquake.de  Wed Oct  1 14:28:57 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 1 Oct 2008 16:28:57 +0200
Subject: rawhide report: 20081001 changes
In-Reply-To: <48E3872E.8050602@fedoraproject.org>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
	<20081001161343.6efb564a@dhcp03.addix.net>
	<48E3872E.8050602@fedoraproject.org>
Message-ID: <20081001162857.44e09e53@dhcp03.addix.net>

Hi.

On Wed, 01 Oct 2008 19:50:30 +0530, Rahul Sundaram wrote:

> > If you're running an Intel graphics chip you may want to skip this
> > one.
> 
> Can you tell us why?

Because you'll end up with an X that crashes after/during DRM init.
Unfortunately I don't have a complete log anymore, so the bug will have to
make do with an incomplete one.



From darrellpf at gmail.com  Wed Oct  1 14:32:58 2008
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 1 Oct 2008 07:32:58 -0700
Subject: rawhide report: 20081001 changes
In-Reply-To: <20081001162857.44e09e53@dhcp03.addix.net>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
	<20081001161343.6efb564a@dhcp03.addix.net>
	<48E3872E.8050602@fedoraproject.org>
	<20081001162857.44e09e53@dhcp03.addix.net>
Message-ID: <f6e5806f0810010732y634054a4gfe9c766e5dd8c3f6@mail.gmail.com>

On Wed, Oct 1, 2008 at 07:28, Ralf Ertzinger <fedora at camperquake.de> wrote:

> Hi.
>
> On Wed, 01 Oct 2008 19:50:30 +0530, Rahul Sundaram wrote:
>
> > > If you're running an Intel graphics chip you may want to skip this
> > > one.
> >
> > Can you tell us why?
>
> Because you'll end up with an X that crashes after/during DRM init.
> Unfortunately I don't have a complete log anymore, so the bug will have to
> make do with an incomplete one.
>
>
The current working intel driver for me is  2.4.2-1.fc10. Anything since
then has failed on multiple machines.

The newer kernels have also failed to boot (don't know if they require a
newer intel driver) so I'm using 2.6.27-0.323.rc6.fc10.i686.

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

From selinux at gmail.com  Wed Oct  1 14:34:49 2008
From: selinux at gmail.com (Tom London)
Date: Wed, 1 Oct 2008 07:34:49 -0700
Subject: rawhide report: 20081001 changes
In-Reply-To: <20081001162857.44e09e53@dhcp03.addix.net>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
	<20081001161343.6efb564a@dhcp03.addix.net>
	<48E3872E.8050602@fedoraproject.org>
	<20081001162857.44e09e53@dhcp03.addix.net>
Message-ID: <4c4ba1530810010734g5277b788vf59f20fe18fdabbd@mail.gmail.com>

On Wed, Oct 1, 2008 at 7:28 AM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Hi.
>
> On Wed, 01 Oct 2008 19:50:30 +0530, Rahul Sundaram wrote:
>
>> > If you're running an Intel graphics chip you may want to skip this
>> > one.
>>
>> Can you tell us why?
>
> Because you'll end up with an X that crashes after/during DRM init.
> Unfortunately I don't have a complete log anymore, so the bug will have to
> make do with an incomplete one.
>

Uhhh.... seems to work for me on Thinkpad X60 (Intel 945) with
xorg-x11-drv-i810-2.4.2-9.fc10.i386.

I see this (new?) message at the end of /var/log/Xorg.0.log however:

exaCopyDirty: Pending damage region empty!

tom
-- 
Tom London



From ajax at redhat.com  Wed Oct  1 14:38:35 2008
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 01 Oct 2008 10:38:35 -0400
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <20080930171332.GB12353@amd.home.annexia.org>
References: <20080930171332.GB12353@amd.home.annexia.org>
Message-ID: <1222871915.17250.2.camel@localhost.localdomain>

On Tue, 2008-09-30 at 18:13 +0100, Richard W.M. Jones wrote:
> We have a package (mingw32-openssl) which has some tests that run
> under Wine.  Strictly speaking, running the tests isn't necessary, but
> because it's such an important package I feel that we should run the
> tests.
> 
> Anyhow, Wine needs an X server, although it doesn't really use it for
> anything.  To provide one, I'm using Xvfb like this:
> 
>   BuildRequires:  wine
>   BuildRequires:  xorg-x11-server-Xvfb
> 
>   #...
> 
>   display=:21
>   Xvfb $display & xpid=$!
>   trap "kill -TERM $xpid ||:" EXIT
>   sleep 3
>   DISPLAY=$display
>   export DISPLAY
>   make -C test tests
> 
> This works, but there are two problems.  Firstly there isn't a good
> way to choose a free display number, so I'm just picking one at random
> here.  This assumes that port 6021 is free, also disallows any builds
> that happen in parallel.  Secondly, will Koji let me do such a thing
> at all?  Is there another / a better way?

Orthogonal to whether koji can or should let you do it, this came up in
the context of another discussion today.  I think what we'll end up
doing is something like:

Xvfb -displayfd 3 3>& /tmp/whatever

to give the server a way of both picking a free display number, and
communicating it back to the launching process.  Does that sound like
it'd work for you?

- ajax



From fedora at camperquake.de  Wed Oct  1 14:58:06 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 1 Oct 2008 16:58:06 +0200
Subject: rawhide report: 20081001 changes
In-Reply-To: <4c4ba1530810010734g5277b788vf59f20fe18fdabbd@mail.gmail.com>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
	<20081001161343.6efb564a@dhcp03.addix.net>
	<48E3872E.8050602@fedoraproject.org>
	<20081001162857.44e09e53@dhcp03.addix.net>
	<4c4ba1530810010734g5277b788vf59f20fe18fdabbd@mail.gmail.com>
Message-ID: <20081001165806.6aebd7ea@dhcp03.addix.net>

Hi.

On Wed, 1 Oct 2008 07:34:49 -0700, Tom London wrote:

> Uhhh.... seems to work for me on Thinkpad X60 (Intel 945) with
> xorg-x11-drv-i810-2.4.2-9.fc10.i386.

That seems to be rather newish, I've got .8.fc10. Same hardware here, btw.

> I see this (new?) message at the end of /var/log/Xorg.0.log however:
> 
> exaCopyDirty: Pending damage region empty!

Fun. The last thing I see is

(**) intel(0): Framebuffer compression enabled
(**) intel(0): Tiling enabled



From tcallawa at redhat.com  Wed Oct  1 15:15:24 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 01 Oct 2008 11:15:24 -0400
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <1222871915.17250.2.camel@localhost.localdomain>
References: <20080930171332.GB12353@amd.home.annexia.org>
	<1222871915.17250.2.camel@localhost.localdomain>
Message-ID: <1222874124.3618.31.camel@localhost.localdomain>

On Wed, 2008-10-01 at 10:38 -0400, Adam Jackson wrote:

> Orthogonal to whether koji can or should let you do it, this came up in
> the context of another discussion today.  I think what we'll end up
> doing is something like:
> 
> Xvfb -displayfd 3 3>& /tmp/whatever
> 
> to give the server a way of both picking a free display number, and
> communicating it back to the launching process.  Does that sound like
> it'd work for you?

The xvfb-run helper I added to Xvfb in rawhide might also be useful for
this purpose, depending on the number of things that need to launch.

~spot



From orion at cora.nwra.com  Wed Oct  1 15:27:32 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 01 Oct 2008 09:27:32 -0600
Subject: rawhide report: 20081001 changes
In-Reply-To: <20081001165806.6aebd7ea@dhcp03.addix.net>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>	<20081001161343.6efb564a@dhcp03.addix.net>	<48E3872E.8050602@fedoraproject.org>	<20081001162857.44e09e53@dhcp03.addix.net>	<4c4ba1530810010734g5277b788vf59f20fe18fdabbd@mail.gmail.com>
	<20081001165806.6aebd7ea@dhcp03.addix.net>
Message-ID: <48E396E4.4010904@cora.nwra.com>

Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 1 Oct 2008 07:34:49 -0700, Tom London wrote:
> 
>> Uhhh.... seems to work for me on Thinkpad X60 (Intel 945) with
>> xorg-x11-drv-i810-2.4.2-9.fc10.i386.
> 
> That seems to be rather newish, I've got .8.fc10. Same hardware here, btw.
> 
>> I see this (new?) message at the end of /var/log/Xorg.0.log however:
>>
>> exaCopyDirty: Pending damage region empty!
> 
> Fun. The last thing I see is
> 
> (**) intel(0): Framebuffer compression enabled
> (**) intel(0): Tiling enabled
> 

Me too.

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ 
Integrated Graphics Controller (rev 02)

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

-- 
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 vonbrand at inf.utfsm.cl  Wed Oct  1 15:27:55 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 01 Oct 2008 11:27:55 -0400
Subject: unfrozen repo somewhere?
In-Reply-To: <48E166C4.10600@gmail.com>
References: <20080926091109.GF3149@free.fr>
	<1222425353.3564.248.camel@beck.corsepiu.local>
	<200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl>
	<1222651165.3564.314.camel@beck.corsepiu.local>
	<200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl>
	<25665.1222660262@sss.pgh.pa.us>
	<1222663773.3564.355.camel@beck.corsepiu.local>
	<200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl>
	<1222667193.3564.406.camel@beck.corsepiu.local>
	<200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl>
	<48E12763.6020200@gmail.com>
	<200809292257.m8TMvxJC016686@laptop14.inf.utfsm.cl>
	<48E166C4.10600@gmail.com>
Message-ID: <200810011529.m91FSpBo004671@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Horst H. von Brand wrote:

[...]

> >> You probably can't match RHEL's QA for free, but testing - and not
> >> shipping things that don't pass - is the only way things can get
> >> better.

> > Pray tell us, exactly how do we /do/ that? I think we all agree that
> > that is the ideal, but I strongly believe it is unatainable in pratice.

> The big problem for me is that it's a package deal.  I wouldn't mind
> beta testing a few apps at a time on my working system with a stable
> OS and libraries, but to run them you also have to take an
> experimental kernel and device drivers.  And my history with those on
> fedora is that I waste too much time getting the hardware to work with
> new versions. Maybe that's changed...   If you had a way to separate
> the apps from the OS, you might find people more willing to test the
> parts that interested them.

Many problems are integration problems, i.e., package version foo doesn't
work with library version bar. It also happens that to run the very
latest-and-greatest version of the package you need experimental(ish)
versions of other stuff.

> >> I've heard the term used as in "an instrument's tuning is 'good
> >> enough' for folk music" or "an approximation is 'good enough' for
> >> government work".  What's 'good enough' for an operating system?

> > Works mostly. Doesn't crash too often. Doesn't destroy valuable data
> > except under extremely unlikely circumstances.

> Kernels that don't boot on machines where the last version worked

Keep the next-to-last one around just in case. Have a LiveCD of the lastest
stable/beta at hand for the case it gets too screwed up. Yes, it's a
nuisance.

>                                                                   or
> lose the ability to access devices like firewire drives isn't 'mostly'
> enough for me.

Ditto.

> > This is engineering, not mathematics. And even in mathematics there have
> > been mistakes...

> But would you want to test a plane where the engineers said it was
> probably good enough and didn't crash too often?

So you have never heard of plane crashes? Or other failures? In the end, as
100% perfect is not realistically doable, you have to make do with "good
enough", and what /that/ means depends on the circumstances: The kernel of
a game console (a crash means a minor inconvenience or at most a lost game)
has /very/ different safety/security requirements than software controlling
a radiation therapy aparatus (which could very well be lethal to the
patient).
-- 
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 2340000       Fax:  +56 32 2797513



From mattdm at mattdm.org  Wed Oct  1 15:48:03 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 1 Oct 2008 11:48:03 -0400
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <1222871915.17250.2.camel@localhost.localdomain>
References: <20080930171332.GB12353@amd.home.annexia.org>
	<1222871915.17250.2.camel@localhost.localdomain>
Message-ID: <20081001154803.GA25230@jadzia.bu.edu>

On Wed, Oct 01, 2008 at 10:38:35AM -0400, Adam Jackson wrote:
> Orthogonal to whether koji can or should let you do it, this came up in
> the context of another discussion today.  I think what we'll end up
> doing is something like:
> Xvfb -displayfd 3 3>& /tmp/whatever

Make sure /tmp/whatever is randomly generated and that you clean it up when
you're done. 

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From pjones at redhat.com  Wed Oct  1 15:54:57 2008
From: pjones at redhat.com (Peter Jones)
Date: Wed, 01 Oct 2008 11:54:57 -0400
Subject: Do we care about /sbin /bin linked to /usr/lib ?
In-Reply-To: <48DC34B4.9080407@redhat.com>
References: <200809251328.01886.sgrubb@redhat.com>
	<48DC34B4.9080407@redhat.com>
Message-ID: <48E39D51.2070804@redhat.com>

Chris Snook wrote:

>> /sbin/nash uses something in /usr
> 
> That sounds bad.

Why?  When it's running during boot, it's on its own filesystem in ram anyway.


-- 
         Peter

In computer science, about the only thing we can prove is that traveling
salesmen can't find their way from one place to another effeciently, and
that unix hackers can't really decode 40-bit keys by harnessing all the
computers in the lab.  And the hackers do it anyway, and the salesmen still
make their rounds.
		-- Ron Jeffries, WikiWikiWeb



From jkeating at redhat.com  Wed Oct  1 15:54:38 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 01 Oct 2008 08:54:38 -0700
Subject: unfrozen repo somewhere?
In-Reply-To: <200810011529.m91FSpBo004671@laptop14.inf.utfsm.cl>
References: <20080926091109.GF3149@free.fr>
	<1222425353.3564.248.camel@beck.corsepiu.local>
	<200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl>
	<1222651165.3564.314.camel@beck.corsepiu.local>
	<200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl>
	<25665.1222660262@sss.pgh.pa.us>
	<1222663773.3564.355.camel@beck.corsepiu.local>
	<200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl>
	<1222667193.3564.406.camel@beck.corsepiu.local>
	<200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl>
	<48E12763.6020200@gmail.com>
	<200809292257.m8TMvxJC016686@laptop14.inf.utfsm.cl>
	<48E166C4.10600@gmail.com>
	<200810011529.m91FSpBo004671@laptop14.inf.utfsm.cl>
Message-ID: <1222876478.6265.15.camel@luminos.localdomain>

On Wed, 2008-10-01 at 11:27 -0400, Horst H. von Brand wrote:
> has /very/ different safety/security requirements than software controlling
> a radiation therapy aparatus (which could very well be lethal to the
> patient).

Yet the patient still has to (at least in my country) sign a waiver
stating that they understand the procedure may in fact kill them,
because it's not perfect, it's good enough.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/6d5037fc/attachment.sig>

From selinux at gmail.com  Wed Oct  1 16:12:26 2008
From: selinux at gmail.com (Tom London)
Date: Wed, 1 Oct 2008 09:12:26 -0700
Subject: rawhide report: 20081001 changes
In-Reply-To: <48E396E4.4010904@cora.nwra.com>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
	<20081001161343.6efb564a@dhcp03.addix.net>
	<48E3872E.8050602@fedoraproject.org>
	<20081001162857.44e09e53@dhcp03.addix.net>
	<4c4ba1530810010734g5277b788vf59f20fe18fdabbd@mail.gmail.com>
	<20081001165806.6aebd7ea@dhcp03.addix.net>
	<48E396E4.4010904@cora.nwra.com>
Message-ID: <4c4ba1530810010912vf6d3670sdbc23c7d9fc54b93@mail.gmail.com>

On Wed, Oct 1, 2008 at 8:27 AM, Orion Poplawski <orion at cora.nwra.com> wrote:
> Ralf Ertzinger wrote:
>>
>> Hi.
>>
>> On Wed, 1 Oct 2008 07:34:49 -0700, Tom London wrote:
>>
>>> Uhhh.... seems to work for me on Thinkpad X60 (Intel 945) with
>>> xorg-x11-drv-i810-2.4.2-9.fc10.i386.
>>
>> That seems to be rather newish, I've got .8.fc10. Same hardware here, btw.
>>
>>> I see this (new?) message at the end of /var/log/Xorg.0.log however:
>>>
>>> exaCopyDirty: Pending damage region empty!
>>
>> Fun. The last thing I see is
>>
>> (**) intel(0): Framebuffer compression enabled
>> (**) intel(0): Tiling enabled
>>
>
> Me too.
>
> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
> Graphics Controller (rev 02)
>
> https://bugzilla.redhat.com/show_bug.cgi?id=464944
>
> --
> Orion Poplawski

Change log for xorg-x11-drv-i810-2.4.2-9.fc10.i386 says:

* Wed Oct 01 2008 Dave Airlie <airlied at redhat.com> 2.4.2-9
- rebase to upstream for new libdrm interfaces

tom
-- 
Tom London



From overholt at redhat.com  Wed Oct  1 16:30:47 2008
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 1 Oct 2008 12:30:47 -0400
Subject: Maintainer wanted for Eclipse Graphical Editing Framework (GEF ...
	eclipse-gef)
Message-ID: <20081001163046.GB14391@redhat.com>

Hi,

Does anyone want to maintain GEF?  I don't have time for it and haven't
updated it recently.  It needs to be updated to the latest (Ganymede
train) release.  Nothing depends upon it so if no one wants it and we
remove it it's probably not the end of the world.

I've given up ownership in FAS so feel free to take it there if you want
it.

Andrew



From jakub at redhat.com  Wed Oct  1 16:52:15 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 1 Oct 2008 18:52:15 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
Message-ID: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>

Hi!

Given the recent 5sec boot efforts http://lwn.net/Articles/299483/
and Mandriva follow-ups on that http://lwn.net/Articles/300873/,
I thought I'd share my modprobe and MAKEDEV speedup patches with
a wider community so folks can experiment with them, especially seeing
Mandriva folks playing with turning modprobe into a daemon because of its
slowness.

modprobe is quite slow, as it on every invocation sources a ~ 7500
line long modules.alias file from which it calls fnmatch on the wildcards
from every line, and a ~ 350KB modules.dep file which it searches through
for module dependencies, but usually those files are just generated by
depmod -a and never modified by humans afterwards.  This patch in depmod -a
in addition to generation of the text files writes more compact binary files
which are only used if the text file hasn't been modified and allow much
faster searching for aliases or dependencies.
MAKEDEV sources almost 500KB of config files on every invocation, and the
inner loop is terribly inefficient.  The second patch allows it to shrink
the files to 55KB while expressing the same info and makes the inner loop
more efficient.  Depending on how many modprobe and MAKEDEV invocations
are done on your box during bootup, this can or might not make meassurable
difference.

The modprobe patch has been actually posted almost a year ago privately,
but nothing has been changed upstream, below is an updated version, retested
against latest rawhide module-init-tools, the MAKEDEV patch is actually from
last week.  IMHO the binary caches for modprobe are better than
having thousands of symlinks around (given 7500 wildcards where for many of
them a few dozens of symlinks would be needed), especially if the symlinks
would be included in rpm package, but I can be of course convinced
otherwise.  In any case, the module-init-tools contains a bunch of speedups
that are IMHO desirable anyway, even without the modules.{dep,alias}cache
files.

	Jakub
-------------- next part --------------
For modules.dep depmod -a also creates modules.depcache which is just  
a simple hash table with chains and a dumb fast compression of strings,
so that modules.depcache is roughly 3 times smaller than modules.dep.
The hash function already makes no difference between _ and -, so for dep
lookups all it needs is compute the hash, walk the chain, comparing full
32-bit hash value and if that hits, compare also modname string, on success
just return that and its dependencies.

For modules.alias it creates modules.aliascache, which contains a tree.
Each tree node has 0 or more associated fnmatch wildcards that need to be
fnmatched at that level unconditionally, then some fixed number of
characters and prefixes of up to that length can be binary searched to
find further node.  The further node can be of 3 types - either again
a normal range node, or just a pointer to a result (if all chars have been
already compared), or an entry containing remaining chars to strncmp and
pointer to result.  Guess better is just to read the algorithm in modprobe.c
for details.  When reading modules.alias, modprobe always calls fnmatch
on all patterns in there and fnmatch is quite expensive.  With
modules.aliascache, for some strings which don't have any wildcards in it,
fnmatch isn't called at all, otherwise it is called only on wildcards where
its prefix consisting of non-wildcard chars matches the input.

Both modules.depcache and modules.aliascache contain a file header, which
embeds a version number, endianity and mtime/ino/size of the corresponding
modules.{dep,alias} file - in case it is hand edited later, modprobe won't
use the cache which will be stale in that case, until regenerated.

In addition to these changes there are some small cleanups here and there,
e.g. as modprobe and depmod aren't threaded we can speed things up quite a
lot by using _unlocked functions, or there is no point for every
getline_wrapped to malloc new chunk of memory and let the caller free it
(almost) immediately again.

vanilla, modules.dep (time to handle ~ 1600 dep searches):
real    0m6.554s
user    0m6.424s
sys     0m0.128s

patched + modules.depcache
real    0m0.042s
user    0m0.008s
sys     0m0.034s

vanilla, modules.alias (time to handle ~ 6400 alias searches):
real    1m22.548s
user    1m21.554s
sys     0m0.965s

patched + modules.aliascache
real    0m0.552s
user    0m0.438s
sys     0m0.114s

time of modprobe pci:v0000EA60d00009897svAsdBbcCscDiE
real    0m0.034s
user    0m0.028s
sys     0m0.006s
vs.
real    0m0.007s
user    0m0.004s
sys     0m0.003s

--- module-init-tools-3.4.1/depmod.c.jj	2008-10-01 17:31:35.000000000 +0200
+++ module-init-tools-3.4.1/depmod.c	2008-10-01 17:32:14.000000000 +0200
@@ -24,6 +24,7 @@
 #include "depmod.h"
 #include "moduleops.h"
 #include "tables.h"
+#include "cache.h"
 
 #include "testing.h"
 
@@ -503,6 +504,443 @@ static void output_deps(struct module *m
 	}
 }
 
+static const char *base_dirname;
+
+struct depcache_dir
+{
+	const char *name;
+	struct depcache_dir *next, *same_dir;
+	unsigned int count, len;
+	int idx;
+};
+
+struct depcache_string
+{
+	struct depcache_string *next;
+	unsigned int hash;
+	unsigned int offset;
+	unsigned int size;
+	struct depcache_dir dir;
+	char name[];
+};
+
+struct depcache_strings
+{
+	struct depcache_string *hash[251];
+	struct depcache_dir *dirs[256];
+	struct depcache_dir dir0;
+	unsigned int dircount;
+	unsigned int count;
+	unsigned int offset;
+};
+
+static void
+depcache_add_string(struct depcache_strings *strings, const char *name)
+{
+	size_t len = strlen(name);
+	unsigned int hash = dep_cache_hash(name, len);
+	struct depcache_string **string = &strings->hash[hash % 251], *s;
+
+	while (*string != NULL) {
+		if ((*string)->hash == hash
+		    && strcmp((*string)->name, name) == 0)
+			return;
+		string = &(*string)->next;
+	}
+
+	s = NOFAIL(malloc(sizeof(struct depcache_string) + len + 1));
+	s->next = NULL;
+	s->hash = hash;
+	s->offset = -1;
+	s->size = len + 1;
+	memcpy(s->name, name, len + 1);
+	strings->count++;
+	*string = s;
+}
+
+static int
+depcache_dir_cmp(const void *a, const void *b)
+{
+	const struct depcache_dir *dira = a;
+	const struct depcache_dir *dirb = b;
+
+	if (dira->count > dirb->count)
+		return -1;
+	if (dira->count < dirb->count)
+		return 1;
+	if (dira->len > dirb->len)
+		return -1;
+	if (dira->len < dirb->len)
+		return 1;
+	return 0;
+}
+
+static void
+depcache_finalize_strings(struct depcache_strings *strings)
+{
+	unsigned int hash, dhash, offset, k, l;
+	size_t dircount = 0;
+	struct depcache_dir *dirhash[251], **dh, **dhs, *d;
+	int count;
+
+	memset (dirhash, '\0', sizeof (dirhash));
+	for (hash = 0; hash < 251; hash++) {
+		struct depcache_string *string = strings->hash[hash];
+
+		while (string != NULL) {
+			char *p = strrchr(string->name, '/');
+			if (p != NULL) {
+				dhash = dep_cache_hash(string->name,
+						       p - string->name + 1);
+				for (dh = &dirhash[dhash % 251];
+				     *dh; dh = &(*dh)->next) {
+					if ((*dh)->len != p - string->name + 1)
+						continue;
+					if (memcmp(string->name, (*dh)->name,
+						   (*dh)->len) != 0)
+						continue;
+					string->dir.same_dir = (*dh)->same_dir;
+					(*dh)->same_dir = &string->dir;
+					++(*dh)->count;
+					break;
+				}
+				if (*dh == NULL) {
+					string->dir.name = string->name;
+					string->dir.next = *dh;
+					string->dir.count = 1;
+					string->dir.len = p - string->name + 1;
+					string->dir.idx = -1;
+					string->dir.same_dir = NULL;
+					*dh = &string->dir;
+					++dircount;
+				}
+			}
+			string = string->next;
+		}
+	}
+
+	/* Compute the length of directory prefix common to
+	   all entries.  */
+	strings->dircount = 1;
+	strings->dirs[0] = &strings->dir0;
+	strings->dir0.len = -1;
+	for (dhash = 0, k = 0; dhash < 251; dhash++) {
+		d = dirhash[dhash];
+		while (d != NULL) {
+			if (strings->dir0.len == -1) {
+				strings->dir0.name = d->name;
+				strings->dir0.len = d->len;
+			} else {
+				int i;
+				for (i = 0; i < d->len
+					    && i < strings->dir0.len; ++i) {
+					if (strings->dir0.name[i]
+					    != d->name[i])
+						break;
+				}
+				if (i < strings->dir0.len) {
+					while (i > 0
+					       && strings->dir0.name[i - 1]
+						  != '/')
+						--i;
+					strings->dir0.len = i;
+					if (i == 0)
+						goto no_dir0;
+				}
+			}
+			d = d->next;
+		}
+	}
+no_dir0:;
+	/* Assign the remaining up to 255 directory table
+	   entries, starting with most often used ones.  */
+	dhs = NOFAIL(malloc(sizeof(*dhs) * dircount));
+	count = 128;
+	while (strings->dircount < 256) {
+		for (dhash = 0, k = 0; dhash < 251; dhash++) {
+			d = dirhash[dhash];
+			while (d != NULL) {
+				if (d->idx == -1)
+					dhs[k++] = d;
+				d = d->next;
+			}
+		}
+
+		qsort(dhs, k, sizeof(*dhs), depcache_dir_cmp);
+
+		for (l = 0; l < count && l < k; ++l) {
+			strings->dirs[strings->dircount] = dhs[l];
+			dhs[l]->idx = strings->dircount++;
+			for (d = dhs[l]->same_dir; d; d = d->same_dir) {
+				d->len = dhs[l]->len;
+				d->idx = dhs[l]->idx;
+			}
+			if (strings->dircount == 256)
+				goto idx_done;
+		}
+		if (l == k)
+			goto idx_done;
+		count /= 2;
+		memset(dirhash, '\0', sizeof(dirhash));
+		for (; l < k; ++l) {
+			unsigned m = dhs[l]->len;
+			if (m != 0) {
+				--m;
+				while (m > 0)
+					if (dhs[l]->name[m - 1] == '/')
+						break;
+					else
+						--m;
+			}
+			if (m == 0) {
+				dhs[l]->len = 0;
+				dhs[l]->idx = 0;
+				for (d = dhs[l]->same_dir; d;
+				     d = d->same_dir) {
+					d->len = dhs[l]->len;
+					d->idx = dhs[l]->idx;
+				}
+				continue;
+			} else {
+				dhs[l]->len = m;
+				dhash = dep_cache_hash(dhs[l]->name,
+						       dhs[l]->len);
+				for (dh = &dirhash[dhash % 251];
+				     *dh; dh = &(*dh)->next) {
+					if ((*dh)->len != dhs[l]->len)
+						continue;
+					if (memcmp((*dh)->name, dhs[l]->name,
+						   (*dh)->len) != 0)
+						continue;
+					(*dh)->count += dhs[l]->count;
+					for (dh = &(*dh)->same_dir;
+					     *dh; dh = &(*dh)->same_dir);
+					*dh = dhs[l];
+					break;
+				}
+				if (*dh == NULL) {
+					*dh = dhs[l];
+					dhs[l]->next = NULL;
+				}
+			}
+		}
+	}
+idx_done:;
+	free(dhs);
+	offset = strings->dircount * sizeof(unsigned int) * 2;
+	offset += strings->dir0.len;
+	for (k = 1; k < strings->dircount; ++k)
+		offset += strings->dirs[k]->len - strings->dir0.len;
+	for (hash = 0; hash < 251; hash++) {
+		struct depcache_string *string = strings->hash[hash];
+
+		while (string != NULL) {
+			if (string->dir.idx == -1)
+				string->dir.idx = 0;
+			string->size -= string->dir.len - 1;
+			string->offset = offset;
+			offset += string->size;
+			string = string->next;
+		}
+	}
+}
+
+static void
+depcache_output_strings(struct depcache_strings *strings, unsigned int offset,
+			FILE *out)
+{
+	unsigned int hash, k;
+
+	offset += strings->dircount * sizeof(unsigned int) * 2;
+	fwrite_unlocked(&offset, 1, sizeof(offset), out);
+	fwrite_unlocked(&strings->dir0.len, 1, sizeof(strings->dir0.len), out);
+	offset += strings->dir0.len;
+	for (k = 1; k < strings->dircount; ++k) {
+		fwrite_unlocked(&offset, 1, sizeof(offset), out);
+		fwrite_unlocked(&strings->dirs[k]->len, 1,
+				sizeof(strings->dirs[k]->len), out);
+		offset += strings->dirs[k]->len - strings->dir0.len;
+	}
+	fwrite_unlocked(strings->dir0.name, strings->dir0.len, 1, out);
+	for (k = 1; k < strings->dircount; ++k)
+		fwrite_unlocked(strings->dirs[k]->name + strings->dir0.len,
+				strings->dirs[k]->len - strings->dir0.len,
+				1, out);
+	for (hash = 0; hash < 251; hash++) {
+		struct depcache_string *string = strings->hash[hash];
+
+		while (string != NULL) {
+			unsigned int len = strings->dirs[string->dir.idx]->len;
+			fputc_unlocked(string->dir.idx, out);
+			fwrite_unlocked(string->name + len, string->size - 1,
+					1, out);
+			string = string->next;
+		}
+	}
+}
+
+static unsigned int
+depcache_string_offset(struct depcache_strings *strings, const char *name,
+		       unsigned int *end)
+{
+	size_t len = strlen(name);
+	unsigned int hash = dep_cache_hash(name, len);
+	struct depcache_string *string = strings->hash[hash % 251];
+
+	while (string != NULL) {
+		if (string->hash == hash
+		    && strcmp(string->name, name) == 0) {
+			if (end)
+				*end = string->offset + string->size - 1;
+			return string->offset;
+		}
+		string = string->next;
+	}
+	abort();
+}
+
+static int primes[] = { 61, 127, 251, 509, 1021, 2039, 4093, 8191,
+			16381, 32749, 65521, 131071 };
+
+static void output_depcache(struct module *modules, FILE *out)
+{
+	struct module *i;
+	unsigned int count, n;
+	struct dep_cache_entry **dce;
+	struct dep_cache header;
+	unsigned int *dce_offsets, offset;
+	unsigned int *hashtab, *hashtab_idx;
+	struct depcache_strings strings;
+	size_t base_dirname_len = strlen(base_dirname);
+	char dep_filename[base_dirname_len + sizeof "/modules.dep"];
+	struct stat st;
+
+	/* Don't output a binary file to stdout.  */
+	if (out == stdout)
+		return;
+
+	memcpy(dep_filename, base_dirname, base_dirname_len);
+	strcpy(dep_filename + base_dirname_len, "/modules.dep");
+	if (stat(dep_filename, &st) < 0)
+		return;
+
+	memset(&strings, 0, sizeof(strings));
+
+	for (i = modules, count = 0; i; i = i->next) {
+		depcache_add_string(&strings, i->pathname + skipchars);
+		count++;
+	}
+	depcache_finalize_strings(&strings);
+
+	dce = NOFAIL(malloc((sizeof(*dce) + sizeof(*dce_offsets)) * count));
+	dce_offsets = (unsigned int *) (dce + count);
+
+	for (i = modules, n = 0; i; i = i->next, n++) {
+		unsigned int ndependencies = 0, k, end;
+		struct list_head *j, *tmp;
+		const char *modname, *p;
+
+		order_dep_list(i, i);
+
+		list_for_each_safe(j, tmp, &i->dep_list)
+			ndependencies++;
+
+		dce[n] = NOFAIL(malloc(sizeof(struct dep_cache_entry)
+				       + ndependencies * sizeof(int)));
+		modname = strrchr(i->pathname + skipchars, '/');
+		if (modname == NULL)
+			modname = i->pathname + skipchars;
+		else
+			modname++;
+		p = strchr(modname, '.');
+		dce[n]->modname_len = p ? p - modname : strlen(modname);
+		dce[n]->hash = dep_cache_hash(modname, dce[n]->modname_len);
+		dce[n]->next = 0xffffffff;
+		dce[n]->fullname
+		  = depcache_string_offset(&strings, i->pathname + skipchars,
+					   &end);
+		dce[n]->modname = end - strlen(modname);
+		k = 0;
+		list_for_each_safe(j, tmp, &i->dep_list) {
+			struct module *dep
+				= list_entry(j, struct module, dep_list);
+			dce[n]->dependencies[k++]
+			  = depcache_string_offset(&strings,
+						   dep->pathname + skipchars,
+						   NULL);
+			list_del_init(j);
+		}
+		dce[n]->num_dependencies = k;
+	}
+
+	memset(&header, 0, sizeof(header));
+	memcpy(header.magic, "mod-dep-cache", sizeof(header.magic));
+	header.version = 1;
+	header.endian = 0x12345678;
+	for (n = 0; n < (sizeof(primes) / sizeof(primes[0])) - 1; n++)
+		if (count < primes[n])
+			break;
+	header.hash_size = primes[n];
+	header.hash_offset = sizeof(header);
+	header.moddep_mtime_high = (st.st_mtime >> 16) >> 16;
+	header.moddep_mtime_low = st.st_mtime;
+	header.moddep_size = st.st_size;
+	header.moddep_ino = st.st_ino;
+	hashtab = NOFAIL(malloc(2 * header.hash_size * sizeof(*hashtab)));
+	hashtab_idx = hashtab + header.hash_size;
+	memset(hashtab_idx, 0xff, header.hash_size * sizeof(*hashtab));
+	for (n = 0; n < count; n++) {
+		unsigned int *p
+		  = &hashtab_idx[dce[n]->hash % header.hash_size];
+
+		while (*p != 0xffffffff)
+			p = &dce[*p]->next;
+		*p = n;
+	}
+
+	offset = sizeof(header) + header.hash_size * sizeof(*hashtab);
+	memset(dce_offsets, 0xff, sizeof(*dce_offsets) * count);
+	for (n = 0; n < header.hash_size; n++) {
+		unsigned int p = hashtab_idx[n];
+		if (p == 0xffffffff)
+			hashtab[n] = p;
+		else
+			hashtab[n] = offset;
+		while (p != 0xffffffff) {
+			dce_offsets[p] = offset;
+			offset += sizeof(**dce)
+				  + dce[p]->num_dependencies
+				    * sizeof(dce[p]->dependencies[0]);
+			p = dce[p]->next;
+		}
+	}
+
+	header.dir_table_offset = offset;
+	fwrite_unlocked(&header, sizeof(header), 1, out);
+	fwrite_unlocked(hashtab, sizeof(*hashtab), header.hash_size, out);
+
+	for (n = 0; n < header.hash_size; n++) {
+		unsigned int p = hashtab_idx[n];
+		while (p != 0xffffffff) {
+			unsigned int nextp = dce[p]->next, k;
+			if (nextp != 0xffffffff)
+				dce[p]->next = dce_offsets[dce[p]->next];
+			dce[p]->modname += offset;
+			dce[p]->fullname += offset;
+			for (k = 0; k < dce[p]->num_dependencies; k++)
+				dce[p]->dependencies[k] += offset;
+			fwrite_unlocked(dce[p],
+					sizeof(**dce)
+					+ dce[p]->num_dependencies
+					  * sizeof(dce[p]->dependencies[0]),
+					1, out);
+			p = nextp;
+		}
+	}
+
+	depcache_output_strings(&strings, header.dir_table_offset, out);
+}
+
 static int smells_like_module(const char *name)
 {
 	return ends_in(name,".ko") || ends_in(name, ".ko.gz");
@@ -744,11 +1182,65 @@ static const char *next_string(const cha
 	return string;
 }
 
+struct aliascache_ent
+{
+	const char *wildcard;
+	unsigned int modname_idx;
+};
+
+struct aliascache_ent *aliascache;
+size_t aliascache_allocated;
+size_t aliascache_count;
+
+/* Careful!  Don't munge - in [ ] as per Debian Bug#350915 */
+static char *underscores(char *string)
+{
+	if (string) {
+		unsigned int i;
+		int inbracket = 0;
+		for (i = 0; string[i]; i++) {
+			switch (string[i]) {
+			case '[':
+				inbracket++;
+				break;
+			case ']':
+				inbracket--;
+				break;
+			case '-':
+				if (!inbracket)
+					string[i] = '_';
+			}
+		}
+		if (inbracket)
+			warn("Unmatched bracket in %s\n", string);
+	}
+	return string;
+}
+
+static void aliascache_add(const char *wildcard, unsigned int modname_idx)
+{
+	char *p;
+	if (aliascache_allocated == aliascache_count) {
+		if (aliascache_allocated)
+			aliascache_allocated *= 2;
+		else
+			aliascache_allocated = 128;
+		aliascache = NOFAIL(realloc(aliascache,
+					    aliascache_allocated
+					    * sizeof(*aliascache)));
+	}
+	p = NOFAIL(strdup(wildcard));
+	underscores(p);
+	aliascache[aliascache_count].wildcard = p;
+	aliascache[aliascache_count++].modname_idx = modname_idx;
+}
+
 static void output_aliases(struct module *modules, FILE *out)
 {
 	struct module *i;
 	const char *p;
 	unsigned long size;
+	unsigned int modname_idx = 0;
 
 	fprintf(out, "# Aliases extracted from modules themselves.\n");
 	for (i = modules; i; i = i->next) {
@@ -759,17 +1251,401 @@ static void output_aliases(struct module
 		/* Grab from old-style .modalias section. */
 		for (p = i->ops->get_aliases(i, &size);
 		     p;
-		     p = next_string(p, &size))
+		     p = next_string(p, &size)) {
 			fprintf(out, "alias %s %s\n", p, modname);
+			aliascache_add(p, modname_idx);
+		}
 
 		/* Grab form new-style .modinfo section. */
 		for (p = i->ops->get_modinfo(i, &size);
 		     p;
 		     p = next_string(p, &size)) {
-			if (strncmp(p, "alias=", strlen("alias=")) == 0)
+			if (strncmp(p, "alias=", strlen("alias=")) == 0) {
 				fprintf(out, "alias %s %s\n",
 					p + strlen("alias="), modname);
+				aliascache_add(p + strlen("alias="),
+					       modname_idx);
+			}
+		}
+
+		modname_idx += strlen(modname) + 1;
+	}
+}
+
+static int aliascache_cmp(const void *p1, const void *p2)
+{
+	const struct aliascache_ent *ac1 = p1;
+	const struct aliascache_ent *ac2 = p2;
+	return strcmp(ac1->wildcard, ac2->wildcard);
+}
+
+struct aliascache_range
+{
+	struct alias_cache_range header;
+	unsigned int first, last, offset, depth;
+	unsigned int wild_size;
+	struct aliascache_range *array[];
+};
+
+static struct aliascache_range *aliascache_create_range(unsigned int depth,
+							unsigned int first,
+							unsigned int last,
+							unsigned int *offset,
+							unsigned int *singles)
+{
+	unsigned int wild[10] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+	unsigned int ends[10] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+	unsigned int dups[10] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+	unsigned int i, j, k, l, wildc, endc, size, normc, nodups;
+	struct aliascache_range *ret;
+
+	for (i = first; i <= last; i++) {
+		for (j = 0; j < 10; j++) {
+			switch (aliascache[i].wildcard[depth + j]) {
+			case '\0':
+				ends[j]++;
+				if (i != first
+				    && strcmp(&aliascache[i].wildcard[depth],
+					      &aliascache[i - 1].wildcard[depth])
+				       == 0)
+					dups[j]++;
+				j = 51;
+				break;
+			case '\\':
+			case '?':
+			case '*':
+			case '[':
+				wild[j]++;
+				j = 52;
+				break;
+			default:
+				break;
+			}
+			if (i != first && j < 51
+			    && strncmp(&aliascache[i].wildcard[depth],
+				       &aliascache[i - 1].wildcard[depth],
+				       j + 1) == 0)
+				dups[j]++;
+		}
+	}
+
+	if (ends[0] == last + 1 - first) {
+		nodups = 1;
+		normc = last + 1 - first;
+		wildc = 0;
+		i = 0;
+	} else {
+		nodups = 0;
+		for (j = 0; j < 10; j++)
+			if (wild[j] != 0 || ends[j] != 0)
+				break;
+		wildc = 0;
+		endc = 0;
+		for (i = j; i < 10; i++) {
+			endc += ends[i];
+			if (wildc + wild[i] > 5 + wild[j])
+				break;
+			if (last + 1 - first - wildc < endc * 2)
+				break;
+			wildc += wild[i];
+		}
+		if (i == 0) {
+			i = 1;
+			wildc += wild[0];
+		}
+		normc = last + 1 - first - dups[i - 1] - wildc;
+	}
+	if (i == 10 && wildc == 0 && normc == 1) {
+		for (; i < 50; i++) {
+			if (aliascache[first].wildcard[depth + i]
+			    != aliascache[last].wildcard[depth + i])
+				break;
+			switch (aliascache[first].wildcard[depth + i]) {
+			case '\0':
+			case '\\':
+			case '?':
+			case '*':
+			case '[':
+				break;
+			default:
+				continue;
+			}
+			break;
+		}
+	}
+	size = sizeof(struct alias_cache_range);
+	size += (normc + wildc) * sizeof(unsigned int);
+	size += normc * i;
+	ret = NOFAIL(calloc(sizeof(*ret)
+			    + normc * sizeof(ret->array[0]), 1));
+	ret->header.nchars = i;
+	ret->header.count_normal = normc;
+	ret->header.count_wild = wildc;
+	ret->first = first;
+	ret->last = last;
+	ret->offset = *offset;
+	ret->depth = depth;
+	*offset += size;
+	for (i = first; i <= last; i++) {
+		for (j = 0; j < ret->header.nchars; j++) {
+			switch (aliascache[i].wildcard[depth + j]) {
+			case '\0':
+				j = 51;
+				break;
+			case '\\':
+			case '?':
+			case '*':
+			case '[':
+				j = 52;
+				ret->wild_size += strlen(aliascache[i].wildcard
+							 + depth) + 1;
+				break;
+			default:
+				break;
+			}
+		}
+	}
+	*offset = (*offset + ret->wild_size + 3) & ~3;
+	for (i = first, k = 0; i <= last; i++) {
+		for (j = 0; j < ret->header.nchars; j++) {
+			switch (aliascache[i].wildcard[depth + j]) {
+			case '\0':
+				j = 51;
+				break;
+			case '\\':
+			case '?':
+			case '*':
+			case '[':
+				j = 52;
+				break;
+			default:
+				break;
+			}
+		}
+		if (j == 52 + 1)
+			continue;
+		for (l = i; l < last; l++)
+			if (strncmp(&aliascache[i].wildcard[depth],
+				    &aliascache[l + 1].wildcard[depth],
+				    ret->header.nchars) != 0)
+				break;
+		if ((j == 51 + 1 && i == l) || j == 0) {
+			ret->array[k] = (void *) 1UL;
+			l = i;
+		} else if (i == l
+			 && !aliascache[l].wildcard[depth
+						    + ret->header.nchars])
+			/* One string, exactly nchars long.  */
+			ret->array[k] = (void *) 1UL;
+		else if (i == l) {
+			const char *p;
+			/* Only one entry.  If it has no wildcards,
+			   create the special singles entry.  */
+			for (j = ret->header.nchars;
+			     ret->array[k] == NULL; j++)
+				switch (aliascache[i].wildcard[depth + j]) {
+				case '\0':
+					p = aliascache[i].wildcard;
+					p += depth + ret->header.nchars;
+					*singles += sizeof(unsigned int);
+					*singles += strlen(p) + 1;
+					*singles = (*singles + 3) & ~3;
+					ret->array[k] = (void *) 2UL;
+					break;
+				case '\\':
+				case '?':
+				case '*':
+				case '[':
+					goto create_range;
+				default:
+					break;
+			}
+		} else if (j == 51 + 1) {
+			size_t len = strlen(aliascache[i].wildcard);
+			ret->array[k]
+			  = aliascache_create_range(len, i, l, offset,
+						    singles);
+		}
+		if (ret->array[k] == NULL) {
+create_range:
+			ret->array[k]
+			  = aliascache_create_range(depth + ret->header.nchars,
+						    i, l, offset, singles);
+		}
+		k++;
+		i = l;
+	}
+	if (k != normc)
+		abort();
+
+	return ret;
+}
+
+struct aliascache_write_info
+{
+	FILE *out;
+	unsigned int singles, offset;
+	char *singles_buf;
+};
+
+static void aliascache_write_range(struct aliascache_write_info *info,
+				   struct aliascache_range *range)
+{
+	size_t size;
+	char *buf, *strings, *wildcards;
+	unsigned int *arr, i, j, k, l, m;
+
+	size = sizeof(range->header);
+	size += (range->header.count_normal + range->header.count_wild)
+		* sizeof(unsigned int);
+	size += range->header.count_normal * range->header.nchars;
+	size += range->wild_size;
+	size = (size + 3) & ~3;
+	buf = NOFAIL(malloc(size));
+	memcpy(buf, &range->header, sizeof(range->header));
+	arr = (unsigned int *) (buf + sizeof(range->header));
+	strings = (char *) (arr + (range->header.count_normal
+				   + range->header.count_wild));
+	wildcards = strings
+		    + range->header.count_normal * range->header.nchars;
+	memset (wildcards + range->wild_size, '\0',
+		(buf + size) - (wildcards + range->wild_size));
+
+	m = range->header.count_normal;
+	for (i = range->first, k = 0; i <= range->last; i++) {
+		const char *p = &aliascache[i].wildcard[range->depth];
+		for (j = 0; j < range->header.nchars; j++) {
+			switch (p[j]) {
+			case '\0':
+				j = 51;
+				break;
+			case '\\':
+			case '?':
+			case '*':
+			case '[':
+				j = 52;
+				break;
+			default:
+				break;
+			}
 		}
+		if (j == 52 + 1) {
+			size_t len = strlen(p);
+			memcpy(wildcards, p, len + 1);
+			wildcards += len + 1;
+			arr[m++] = aliascache[i].modname_idx + info->offset;
+		} else if (j == 0) {
+			if (range->array[k] != (void *) 1UL)
+				abort();
+			arr[k++] = aliascache[i].modname_idx + info->offset;
+		} else {
+			strncpy(strings, p, range->header.nchars);
+			strings += range->header.nchars;
+			for (l = i; l < range->last; l++)
+				if (strncmp(p,
+					    &aliascache[l + 1].wildcard[range->depth],
+					    range->header.nchars) != 0)
+					break;
+			if (range->array[k] == (void *) 1UL) {
+				if (i != l)
+					abort();
+				arr[k] = aliascache[i].modname_idx
+					 + info->offset;
+			} else if (range->array[k] == (void *) 2UL) {
+				size_t len = strlen(p + range->header.nchars);
+				char *r;
+				if (i != l)
+					abort();
+				*(unsigned int *) info->singles_buf
+				  = aliascache[i].modname_idx + info->offset;
+				r = info->singles_buf + sizeof(unsigned int);
+				memcpy(r, p + range->header.nchars, len + 1);
+				r += len + 1;
+				arr[k] = info->singles;
+				len += sizeof(unsigned int) + 1;
+				len = (len + 3) & ~3;
+				memset(r, '\0', (info->singles_buf + len) - r);
+				info->singles_buf += len;
+				info->singles += len;
+			} else
+				arr[k] = range->array[k]->offset;
+			k++;
+			i = l;
+		}
+	}
+
+	if (k != range->header.count_normal
+	    || m != k + range->header.count_wild)
+		abort();
+	fwrite_unlocked(buf, size, 1, info->out);
+	free(buf);
+
+	for (k = 0; k < range->header.count_normal; k++)
+		if (range->array[k] != (void *) 1UL
+		    && range->array[k] != (void *) 2UL)
+			aliascache_write_range(info, range->array[k]);
+}
+
+static void output_aliascache(struct module *modules, FILE *out)
+{
+	struct module *i;
+	struct aliascache_range *root;
+	struct alias_cache header;
+	unsigned int offset = sizeof (header), singles = 0;
+	struct aliascache_write_info info;
+	char *singles_buf;
+	size_t base_dirname_len = strlen(base_dirname);
+	char alias_filename[base_dirname_len + sizeof "/modules.alias"];
+	struct stat st;
+
+	/* Don't output a binary file to stdout.  */
+	if (out == stdout || aliascache_count == 0)
+		return;
+
+	memcpy(alias_filename, base_dirname, base_dirname_len);
+	strcpy(alias_filename + base_dirname_len, "/modules.alias");
+	if (stat(alias_filename, &st) < 0)
+		return;
+
+	qsort(aliascache, aliascache_count, sizeof(*aliascache),
+	      aliascache_cmp);
+
+	root = aliascache_create_range(0, 0, aliascache_count - 1,
+				       &offset, &singles);
+
+	memset(&header, 0, sizeof(header));
+	memcpy(header.magic, "mod-alias-cache", sizeof(header.magic));
+	header.version = 1;
+	header.endian = 0x12345678;
+	header.modalias_mtime_high = (st.st_mtime >> 16) >> 16;
+	header.modalias_mtime_low = st.st_mtime;
+	header.modalias_size = st.st_size;
+	header.modalias_ino = st.st_ino;
+	header.singles = offset;
+	offset += singles;
+	header.strings = offset;
+	fwrite_unlocked(&header, sizeof(header), 1, out);
+
+	singles_buf = NOFAIL(malloc(singles));
+	info.out = out;
+	info.singles = header.singles;
+	info.offset = header.strings;
+	info.singles_buf = singles_buf;
+	aliascache_write_range(&info, root);
+	if (info.singles != header.strings
+	    || info.singles_buf != singles_buf + singles)
+		abort();
+
+	fwrite_unlocked(singles_buf, singles, 1, out);
+
+	for (i = modules; i; i = i->next) {
+		char modname[strlen(i->pathname)+1];
+		size_t len;
+
+		filename2modname(modname, i->pathname);
+		underscores(modname);
+		len = strlen(modname);
+		fwrite_unlocked(modname, len + 1, 1, out);
 	}
 }
 
@@ -790,6 +1666,8 @@ static struct depfile depfiles[] = {
 	{ "modules.seriomap", output_serio_table },
 	{ "modules.alias", output_aliases },
 	{ "modules.symbols", output_symbols },
+	{ "modules.depcache", output_depcache },
+	{ "modules.aliascache", output_aliascache },
 };
 
 /* If we can't figure it out, it's safe to say "true". */
@@ -841,10 +1719,10 @@ static int depfile_out_of_date(const cha
 static int fgetc_wrapped(FILE *file, unsigned int *linenum)
 {
 	for (;;) {
-		int ch = fgetc(file);
+		int ch = fgetc_unlocked(file);
 		if (ch != '\\')
 			return ch;
-		ch = fgetc(file);
+		ch = fgetc_unlocked(file);
 		if (ch != '\n')
 			return ch;
 		if (linenum)
@@ -854,24 +1732,23 @@ static int fgetc_wrapped(FILE *file, uns
 
 static char *getline_wrapped(FILE *file, unsigned int *linenum)
 {
-	int size = 1024;
+	static int size;
 	int i = 0;
-	char *buf = NOFAIL(malloc(size));
+	static char *buf;
 	for(;;) {
 		int ch = fgetc_wrapped(file, linenum);
 		if (i == size) {
-			size *= 2;
+			size = size ? size * 2 : 1024;
 			buf = NOFAIL(realloc(buf, size));
 		}
 		if (ch < 0 && i == 0) {
-			free(buf);
 			return NULL;
 		}
 		if (ch < 0 || ch == '\n') {
 			if (linenum)
 				(*linenum)++;
 			buf[i] = '\0';
-			return NOFAIL(realloc(buf, i+1));
+			return buf;
 		}
 		buf[i++] = ch;
 	}
@@ -983,8 +1860,6 @@ static int read_config_file(const char *
                         }
                 } else
                         grammar(cmd, filename, linenum);
-
-                free(line);
         }
         fclose(cfile);
         return 1;
@@ -1176,6 +2051,8 @@ int main(int argc, char *argv[])
 	}
 	parse_modules(list);
 
+	base_dirname = dirname;
+
 	for (i = 0; i < sizeof(depfiles)/sizeof(depfiles[0]); i++) {
 		FILE *out;
 		struct depfile *d = &depfiles[i];
@@ -1201,6 +2078,7 @@ int main(int argc, char *argv[])
 		}
 	}
 
+	base_dirname = NULL;
 	free(dirname);
 	free(version);
 	
--- module-init-tools-3.4.1/modprobe.c.jj	2008-10-01 17:31:35.000000000 +0200
+++ module-init-tools-3.4.1/modprobe.c	2008-10-01 17:32:14.000000000 +0200
@@ -38,6 +38,7 @@
 #include <asm/unistd.h>
 #include <sys/wait.h>
 #include <syslog.h>
+#include "cache.h"
 
 #define streq(a,b) (strcmp((a),(b)) == 0)
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
@@ -66,16 +67,14 @@ static int log;
 
 static void message(const char *prefix, const char *fmt, va_list *arglist)
 {
-	char *buf, *buf2;
+	char *buf;
 
 	vasprintf(&buf, fmt, *arglist);
-	asprintf(&buf2, "%s%s", prefix, buf);
 
 	if (log)
-		syslog(LOG_NOTICE, "%s", buf2);
+		syslog(LOG_NOTICE, "%s%s", prefix, buf);
 	else
-		fprintf(stderr, "%s", buf2);
-	free(buf2);
+		fprintf(stderr, "%s%s", prefix, buf);
 	free(buf);
 }
 
@@ -129,10 +128,10 @@ static void print_usage(const char *prog
 static int fgetc_wrapped(FILE *file, unsigned int *linenum)
 {
 	for (;;) {
-	  	int ch = fgetc(file);
+	  	int ch = fgetc_unlocked(file);
 		if (ch != '\\')
 			return ch;
-		ch = fgetc(file);
+		ch = fgetc_unlocked(file);
 		if (ch != '\n')
 			return ch;
 		if (linenum)
@@ -142,24 +141,23 @@ static int fgetc_wrapped(FILE *file, uns
 
 static char *getline_wrapped(FILE *file, unsigned int *linenum)
 {
-	int size = 1024;
+	static int size;
 	int i = 0;
-	char *buf = NOFAIL(malloc(size));
+	static char *buf;
 	for(;;) {
 		int ch = fgetc_wrapped(file, linenum);
 		if (i == size) {
-			size *= 2;
+			size = size ? size * 2 : 1024;
 			buf = NOFAIL(realloc(buf, size));
 		}
 		if (ch < 0 && i == 0) {
-			free(buf);
 			return NULL;
 		}
 		if (ch < 0 || ch == '\n') {
 			if (linenum)
 				(*linenum)++;
 			buf[i] = '\0';
-			return NOFAIL(realloc(buf, i+1));
+			return buf;
 		}
 		buf[i++] = ch;
 	}
@@ -281,9 +279,10 @@ static int add_modules_dep_line(char *li
 	else
 		modname = line;
 
-	len = strlen(modname);
 	if (strchr(modname, '.'))
 		len = strchr(modname, '.') - modname;
+	else
+		len = strlen(modname);
 	if (!modname_equal(modname, name, len))
 		return 0;
 
@@ -303,29 +302,107 @@ static int add_modules_dep_line(char *li
 	return 1;
 }
 
+static void add_depcache_module(struct dep_cache *header, const char *depcache,
+			        unsigned int stroff, struct list_head *list)
+{
+	unsigned int diridx = (unsigned char) depcache[stroff];
+	unsigned int *dirtab
+	  = (unsigned int *) (depcache + header->dir_table_offset);
+	size_t len = strlen(depcache + stroff + 1);
+	char name[dirtab[2 * diridx + 1] + len + 1], *p;
+	memcpy(name, depcache + dirtab[0], dirtab[1]);
+	p = name + dirtab[1];
+	if (diridx != 0) {
+		memcpy(p, depcache + dirtab[2 * diridx],
+		       dirtab[2 * diridx + 1] - dirtab[1]);
+		p += dirtab[2 * diridx + 1] - dirtab[1];
+	}
+	memcpy(p, depcache + stroff + 1, len + 1);
+	add_module(name, (p - name) + len, list);
+}
+
 static void read_depends(const char *dirname,
 			 const char *start_name,
+			 int avoid_cache,
 			 struct list_head *list)
 {
-	char *modules_dep_name;
+	char *modules_dep_name, *modules_depcache_name;
 	char *line;
 	FILE *modules_dep;
-	int done = 0;
+	int depcache_fd;
+	const char *depcache = MAP_FAILED;
+	struct stat dep_st, depcache_st;
 
 	asprintf(&modules_dep_name, "%s/%s", dirname, "modules.dep");
-	modules_dep = fopen(modules_dep_name, "r");
-	if (!modules_dep)
-		fatal("Could not load %s: %s\n",
-		      modules_dep_name, strerror(errno));
-
-	/* Stop at first line, as we can have duplicates (eg. symlinks
-           from boot/ */
-	while (!done && (line = getline_wrapped(modules_dep, NULL)) != NULL) {
-		done = add_modules_dep_line(line, start_name, list);
-		free(line);
+	asprintf(&modules_depcache_name, "%s/%s", dirname, "modules.depcache");
+	if (avoid_cache)
+		depcache_fd = -1;
+	else
+		depcache_fd = open(modules_depcache_name, O_RDONLY);
+	if (depcache_fd != -1) {
+		struct dep_cache *header;
+		unsigned int *hashtab, hash, entoff;
+		struct dep_cache_entry *ent;
+
+		if (stat(modules_dep_name, &dep_st) < 0
+		    || fstat(depcache_fd, &depcache_st) < 0
+		    || depcache_st.st_size < sizeof(struct dep_cache))
+			goto use_modules_dep;
+		depcache = mmap(NULL, depcache_st.st_size, PROT_READ,
+				MAP_PRIVATE, depcache_fd, 0);
+		if (depcache == MAP_FAILED)
+			goto use_modules_dep;
+		header = (struct dep_cache *) depcache;
+		if (memcmp(header->magic, "mod-dep-cache",
+			   sizeof(header->magic)) != 0
+		    || header->version != 1
+		    || header->endian != 0x12345678
+		    || header->moddep_mtime_high
+		       != (unsigned int) ((dep_st.st_mtime >> 16) >> 16)
+		    || header->moddep_mtime_low
+		       != (unsigned int) dep_st.st_mtime
+		    || header->moddep_size != dep_st.st_size
+		    || header->moddep_ino != dep_st.st_ino)
+			goto use_modules_dep;
+		hashtab = (unsigned int *) (depcache
+					    + header->hash_offset);
+		hash = dep_cache_hash(start_name, strlen(start_name));
+		for (entoff = hashtab[hash % header->hash_size];
+		     entoff != 0xffffffff; entoff = ent->next) {
+			ent = (struct dep_cache_entry *)
+			      (depcache + entoff);
+			if (modname_equal(depcache + ent->modname, start_name,
+					  ent->modname_len)) {
+				int i;
+				add_depcache_module(header, depcache,
+						    ent->fullname, list);
+				for (i = 0; i < ent->num_dependencies; ++i)
+					add_depcache_module(header, depcache,
+							    ent->dependencies[i],
+							    list);
+				break;
+			}
+		}
+	} else {
+use_modules_dep:
+		modules_dep = fopen(modules_dep_name, "r");
+		if (!modules_dep)
+			fatal("Could not load %s: %s\n",
+			      modules_dep_name, strerror(errno));
+
+		/* Stop at first line, as we can have duplicates (eg. symlinks
+		   from boot/ */
+		while ((line = getline_wrapped(modules_dep, NULL)) != NULL)
+			if (add_modules_dep_line(line, start_name, list))
+				break;
+		fclose(modules_dep);
 	}
-	fclose(modules_dep);
+	if (depcache != MAP_FAILED)
+		munmap((char *) depcache, depcache_st.st_size);
+	if (depcache_fd != 0)
+		close(depcache_fd);
 	free(modules_dep_name);
+	free(modules_depcache_name);
 }
 
 /* We use error numbers in a loose translation... */
@@ -391,18 +468,15 @@ again:
 				if (streq(entry, "Loading")
 				    || streq(entry, "Unloading")) {
 					usleep(100000);
-					free(line);
 					fclose(proc_modules);
 					goto again;
 				}
 			}
 
 		out:
-			free(line);
 			fclose(proc_modules);
 			return 1;
 		}
-		free(line);
 	}
 	fclose(proc_modules);
 	return 0;
@@ -1106,7 +1180,7 @@ static int do_wildcard(const char *dirna
 		/* Ignore lines without : or which start with a # */
 		ptr = strchr(line, ':');
 		if (ptr == NULL || line[strspn(line, "\t ")] == '#')
-			goto next;
+			continue;
 		*ptr = '\0';
 
 		/* "type" must match complete directory component(s). */
@@ -1117,8 +1191,6 @@ static int do_wildcard(const char *dirna
 			if (fnmatch(wcard, modname, 0) == 0)
 				printf("%s\n", line);
 		}
-	next:
-		free(line);
 	}
 
 	free(wcard);
@@ -1240,8 +1312,6 @@ static int read_config_file(const char *
 			}
 		} else
 			grammar(cmd, filename, linenum);
-
-		free(line);
 	}
 	fclose(cfile);
 	return 1;
@@ -1290,6 +1360,148 @@ static int read_config(const char *filen
 	return ret;
 }
 
+static int find_aliascache(const struct alias_cache *header,
+			   const char *name,
+			   const struct alias_cache_range *range,
+			   struct module_alias **aliases)
+{
+	unsigned int i, lo, hi, mid;
+	int r;
+	const char *str, *str2, *strtab, *wild, *realname;
+	const unsigned int *table;
+	size_t len;
+	
+	table = (const unsigned int *) (range + 1);
+	strtab = (const char *) (table + range->count_normal
+				 + range->count_wild);
+	wild = strtab + (range->count_normal * range->nchars);
+
+	/* First, run fnmatch on all wildcards at this level.  */
+	for (i = 0; i < range->count_wild; i++) {
+		if (fnmatch(wild, name, 0) == 0) {
+			realname = ((const char *) header)
+				   + table[range->count_normal + i];
+			*aliases = add_alias(realname, *aliases);
+		}
+		wild = strchr(wild, '\0') + 1;
+	}
+
+	/* nchars == 0 is special, there are multiple non-wildcard
+	   symbols with the same wildcard.  Either all of them
+	   match, or none.  */
+	if (range->nchars == 0) {
+		if (name[0] != '\0')
+			return 0;
+		for (i = 0; i < range->count_normal; i++) {
+			realname = ((const char *) header) + table[i];
+			*aliases = add_alias(realname, *aliases);
+		}
+		return 0;
+	}
+
+	/* Binary search.  */
+	lo = 0;
+	str = NULL;
+	hi = range->count_normal;
+	r = 1;
+	mid = lo;
+	while (lo < hi) {
+		mid = (lo + hi) / 2;
+		str = strtab + mid * range->nchars;
+		r = strncmp(str, name, range->nchars);
+		if (r == 0)
+			break;
+		else if (r > 0)
+			hi = mid;
+		else
+			lo = mid + 1;
+	}
+	if (r != 0)
+		return 0;
+
+	if (table[mid] >= header->strings) {
+		len = strlen(name);
+		if (len <= range->nchars) {
+			realname = ((const char *) header) + table[mid];
+			*aliases = add_alias(realname, *aliases);
+		}
+	} else if (table[mid] >= header->singles) {
+		str2 = ((const char *) header) + table[mid]
+		       + sizeof(unsigned int);
+		if (strcmp (str2, name + range->nchars) == 0) {
+			realname = ((const char *) header)
+				   + *(const unsigned int *)
+				      (((const char *) header) + table[mid]);
+			*aliases = add_alias(realname, *aliases);
+		}
+	} else {
+		const struct alias_cache_range *range2;
+		range2 = (const struct alias_cache_range *)
+			 (((const char *) header) + table[mid]);
+		len = strlen(name);
+		return find_aliascache(header,
+				       name + (len > range->nchars
+					       ? range->nchars : len),
+				       range2, aliases);
+	}
+	return 0;
+}
+
+static int read_aliases(const char *aliasfilename,
+			const char *name,
+			int removing,
+			struct module_options **options,
+			struct module_command **commands,
+			struct module_alias **aliases,
+			struct module_blacklist **blacklist)
+{
+	char *aliascache_name;
+	int aliascache_fd;
+	const char *aliascache = MAP_FAILED;
+	struct stat alias_st, aliascache_st;
+	int ret;
+
+	asprintf(&aliascache_name, "%scache", aliasfilename);
+	aliascache_fd = open(aliascache_name, O_RDONLY);
+	if (aliascache_fd != -1) {
+		struct alias_cache *header;
+		struct alias_cache_range *range;
+
+		if (stat(aliasfilename, &alias_st) < 0
+		    || fstat(aliascache_fd, &aliascache_st) < 0
+		    || aliascache_st.st_size < sizeof(struct alias_cache))
+			goto use_modules_alias;
+		aliascache = mmap(NULL, aliascache_st.st_size, PROT_READ,
+				  MAP_PRIVATE, aliascache_fd, 0);
+		if (aliascache == MAP_FAILED)
+			goto use_modules_alias;
+		header = (struct alias_cache *) aliascache;
+		if (memcmp(header->magic, "mod-alias-cache",
+			   sizeof(header->magic)) != 0
+		    || header->version != 1
+		    || header->endian != 0x12345678
+		    || header->modalias_mtime_high
+		       != (unsigned int) ((alias_st.st_mtime >> 16) >> 16)
+		    || header->modalias_mtime_low
+		       != (unsigned int) alias_st.st_mtime
+		    || header->modalias_size != alias_st.st_size
+		    || header->modalias_ino != alias_st.st_ino)
+			goto use_modules_alias;
+		range = (struct alias_cache_range *) (void *) (header + 1);
+		ret = find_aliascache(header, name, range, aliases);
+	} else {
+use_modules_alias:
+		ret = read_config(aliasfilename, name, 0, removing, options,
+				  commands, aliases, blacklist);
+	}
+	if (aliascache != MAP_FAILED)
+		munmap((void *) aliascache, aliascache_st.st_size);
+	if (aliascache_fd != -1)
+		close(aliascache_fd);
+	free(aliascache_name);
+	return ret;
+}
+
 static const char *default_configs[] = 
 {
 	"/etc/modprobe.conf",
@@ -1355,8 +1567,6 @@ static int read_kcmdline(int dump_only, 
 						       opt, *options);
 			}
 		}
-
-		free(line);
 	}
 	fclose(kcmdline);
 	return 1;
@@ -1745,14 +1955,14 @@ int main(int argc, char *argv[])
 
 		if (!aliases) {
 			/* We only use canned aliases as last resort. */
-			read_depends(dirname, modulearg, &list);
+			read_depends(dirname, modulearg, 0, &list);
 
 			if (list_empty(&list)
 			    && !find_command(modulearg, commands))
 			{
-				read_config(aliasfilename, modulearg, 0,
-					    remove, &modoptions, &commands,
-					    &aliases, &blacklist);
+				read_aliases(aliasfilename, modulearg,
+					     remove, &modoptions, &commands,
+					     &aliases, &blacklist);
 			}
 		}
 
@@ -1769,7 +1979,8 @@ int main(int argc, char *argv[])
 				opts = add_extra_options(modulearg,
 							 opts, modoptions);
 
-				read_depends(dirname, aliases->module, &list);
+				read_depends(dirname, aliases->module,
+					     0, &list);
 				handle_module(aliases->module, &list, newname,
 					      remove, opts, first_time, err,
 					      dry_run, verbose, modoptions,
--- module-init-tools-3.4.1/cache.h.jj	2008-10-01 17:32:14.000000000 +0200
+++ module-init-tools-3.4.1/cache.h	2008-10-01 17:32:14.000000000 +0200
@@ -0,0 +1,57 @@
+#ifndef MODINITTOOLS_CACHE_H
+#define MODINITTOOLS_CACHE_H
+
+struct dep_cache {
+	char magic[sizeof "mod-dep-cache"];
+	unsigned char version;
+	unsigned char pad;
+	unsigned int endian;
+	unsigned int moddep_mtime_high;
+	unsigned int moddep_mtime_low;
+	unsigned int moddep_size;
+	unsigned int moddep_ino;
+	unsigned int hash_size;
+	unsigned int hash_offset;
+	unsigned int dir_table_offset;
+};
+
+struct dep_cache_entry {
+	unsigned int hash;
+	unsigned int next;
+	unsigned int modname;
+	unsigned int modname_len;
+	unsigned int fullname;
+	unsigned int num_dependencies;
+	unsigned int dependencies[];
+};
+
+static inline unsigned int dep_cache_hash (const char *str, size_t len)
+{
+  size_t n = 0;
+  unsigned int r = 0;
+
+  for (n = 0; n < len; n++, str++)
+    r = r * 67 + (*str == '-' ? '_' : *str) - 113;
+  return r + len;
+}
+
+struct alias_cache {
+	char magic[sizeof "mod-alias-cache"];
+	unsigned char version;
+	unsigned char pad[3];
+	unsigned int endian;
+	unsigned int modalias_mtime_high;
+	unsigned int modalias_mtime_low;
+	unsigned int modalias_size;
+	unsigned int modalias_ino;
+	unsigned int singles;
+	unsigned int strings;
+};
+
+struct alias_cache_range {
+	unsigned int nchars;
+	unsigned int count_normal;
+	unsigned int count_wild;
+};
+
+#endif /* MODINITTOOLS_CACHE_H */
-------------- next part --------------
On i686, if I run 64 times /sbin/MAKEDEV, vanilla time is:
real    0m3.100s
user    0m2.925s
sys     0m0.164s
the patched MAKEDEV with original /etc/makedev.d is:
real    0m0.897s
user    0m0.746s
sys     0m0.152s
and finally patched MAKEDEV with the new /etc/makedev.d config files is:
real    0m0.195s
user    0m0.116s
sys     0m0.069s

--- MAKEDEV-3.23/MAKEDEV.c.jj	2008-09-19 03:03:54.000000000 +0200
+++ MAKEDEV-3.23/MAKEDEV.c	2008-09-27 08:33:15.000000000 +0200
@@ -17,6 +17,7 @@
  * Red Hat Author(s): Nalin Dahyabhai <nalin at redhat.com>
  */
 
+#define _GNU_SOURCE
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/socket.h>
@@ -78,6 +79,11 @@ struct device_entry {
 				   * which will not change for any device which
 				   * this entry will create */
 	unsigned int base;        /* number to start formatting names with */
+	unsigned int modulo;	  /* if using two format specifiers, number
+				     of second number increases before first
+				     number is increased */
+	unsigned int base2;	  /* base for the second number if two format
+				     specifiers are used */
 	const char *link_target;  /* target for a symlink, if it is one */
 	struct device_entry *next;
 };
@@ -89,6 +95,7 @@ struct dirlist_entry {
 
 struct macro {
 	const char *name, *expansion;
+	unsigned int name_len, expansion_len;
 	struct macro *next;
 };
 
@@ -141,7 +148,7 @@ makenodes(const char *directory, const c
 	char path[PATH_MAX], pattern[PATH_MAX], tmp[PATH_MAX], ctx[PATH_MAX];
 	mode_t mode;
 	dev_t dev;
-	unsigned int mul, frlen, dirlen, i;
+	unsigned int mul, num1, num2, frlen, dirlen, i;
 	int ret = 0;
 
 	/* Compute the lengths of our fixed-length strings, because we'll be
@@ -150,26 +157,44 @@ makenodes(const char *directory, const c
 	dirlen = strlen(directory);
 
 	/* Limit the number of devices we'll create per entry. */
+	num1 = 0;
+	num2 = 0;
 	for (mul = 0; (max != 0) && (mul < entry->num); max--, mul++) {
-		memset(pattern, '\0', sizeof(pattern));
-		memset(path, '\0', sizeof(path));
-		memset(tmp, '\0', sizeof(tmp));
-		memset(ctx, '\0', sizeof(ctx));
-
 		/* Build the file name. */
-		snprintf(pattern, sizeof(pattern), "%s/%s", directory,
-			 entry->name);
+		snprintf(pattern, sizeof(pattern), "%%s/%s", entry->name);
 
 		/* If this is not the first device, and there's not some format
 		 * specifier in there, append a "%d", which makes things like
 		 * hda/hda1 really easy to do. */
 		if (mul > 0) {
-			if (strchr(pattern, '%') == NULL) {
+			if (strchr(pattern + 3, '%') == NULL) {
 				strncat(pattern, "%d",
 					sizeof(pattern) - 1 - strlen(pattern));
 			}
 		}
-		snprintf(path, sizeof(path), pattern, mul + entry->base);
+		if (entry->modulo) {
+			/* Similarly, when using 2 format specifiers and
+			   the string contains %|, ignore everything afterwards
+			   if num1 is 0.  */
+			char *p = pattern + 2;
+			while ((p = strchr (p + 1, '%')) != NULL
+			       && p[1] != '|')
+				;
+			if (p) {
+				if (num1 == 0)
+					*p = '\0';
+				else
+					memmove (p, p + 2, strlen(p + 2) + 1);
+			}
+		}
+		snprintf(path, sizeof(path), pattern, directory,
+			 num2 + entry->base, num1 + entry->base2);
+
+		num1++;
+		if (entry->modulo && num1 == entry->modulo) {
+			num1 = 0;
+			num2++;
+		}
 
 		/* Check if the target matches the fragment. */
 		if (strncmp(fragment, path + dirlen + 1, frlen) != 0) {
@@ -183,7 +208,7 @@ makenodes(const char *directory, const c
 			if ((i == 0) || (path[i] != '/')) {
 				continue;
 			}
-			strncpy(tmp, path, i);
+			memcpy(tmp, path, i);
 			tmp[i] = '\0';
 			if ((lstat(tmp, &st) != -1) || (errno != ENOENT)) {
 				snprintf(ctx, sizeof(ctx), "%s",
@@ -416,13 +441,14 @@ makenodes(const char *directory, const c
 
 		/* We're creating symlinks today. */
 		if (entry->type == LINK) {
+			ssize_t len;
 			/* Check that we aren't trying anything unnecessary. */
-			memset(tmp, '\0', sizeof(tmp));
-			if (lstat(path, &st) == 0)
-			if (S_ISLNK(st.st_mode))
-			if (readlink(path, tmp, sizeof(tmp) - 1) != -1)
-			if (strcmp(tmp, entry->link_target) == 0)
-			if (secontextverify("MAKEDEV", ctx, st.st_mode) == 0) {
+			if (lstat(path, &st) == 0
+			    && S_ISLNK(st.st_mode)
+			    && (len = readlink(path, tmp, sizeof(tmp) - 1)) != -1
+			    && (tmp[len] = '\0',
+				strcmp(tmp, entry->link_target)) == 0
+			    && secontextverify("MAKEDEV", ctx, st.st_mode) == 0) {
 				/* We know how to create this, but didn't need
 				 * to, as it was already there. */
 				ret = 1;
@@ -577,20 +603,26 @@ makedevices(const char *directory, const
 			if (((flags & NOFOLLOW) == 0) &&
 			    (entry->type == LINK)) {
 				char *p = buf;
+				size_t len = strlen(entry->name);
 				/* Build the link target's name. */
-				memset(buf, '\0', sizeof(buf));
-				strncpy(buf, entry->name, sizeof(buf) - 1);
-				if (strrchr(buf, '/') != NULL) {
-					p = strrchr(buf, '/') + 1;
-					strncpy(p, entry->link_target,
-						sizeof(buf) - 1 - (p - buf));
-				} else {
-					strncpy(buf, entry->link_target,
-						sizeof(buf) - 1);
-				}
+				if (len >= sizeof(buf)) {
+					memcpy(buf, entry->name, sizeof(buf) - 1);
+					buf[sizeof(buf) - 1] = '\0';
+				} else
+					memcpy(buf, entry->name, len + 1);
+				if ((p = strrchr(buf, '/')) != NULL)
+					p++;
+				else
+					p = buf;
+				len = strlen(entry->link_target);
+				if ((p - buf) + len >= sizeof(buf)) {
+					memcpy(p, entry->link_target,
+					       sizeof(buf) - 1 - (p - buf));
+					buf[sizeof(buf) - 1] = '\0';
+				} else
+					memcpy(p, entry->link_target, len + 1);
 				/* Strip out empty path components. */
-				while (strstr(buf, "//") != NULL) {
-					p = strstr(buf, "//");
+				while ((p = strstr(buf, "//")) != NULL) {
 					memmove(p, p + 1, strlen(p));
 				}
 				/* Replace "/foo/../" with "/" by removing the
@@ -669,33 +701,37 @@ makedevices(const char *directory, const
 	}
 }
 
+static char *
+stralloc (const char *p, const char *q)
+{
+	char *ret;
+	if (q == p)
+		return NULL;
+	ret = malloc(q - p + 1);
+	if (ret == NULL)
+		return NULL;
+	memcpy(ret, p, q - p);
+	ret[q - p] = '\0';
+	return ret;
+}
+
 static void
-read_config_line(const char *path, const char *pline)
+read_config_line(const char *path, const char *pline, size_t pline_len)
 {
-	char *p, *q;
-	char buf[LINE_MAX], line[LINE_MAX];
+	const char *p, *q;
+	char *tmp, *r;
+	char buf[LINE_MAX], buf2[LINE_MAX];
 	struct device_entry *entry = NULL;
 	struct macro *macro = NULL;
 	enum entry_type type = -1;
 
 	/* Expand macros. This is not as elegant as it could be, but it should
 	 * suffice for our use here. */
-	strncpy(line, pline, sizeof(line) - 1);
-	line[sizeof(line) - 1] = '\0';
-	while (strchr(line, '$') != NULL) {
-		strncpy(buf, line, sizeof(buf) - 1);
-		buf[sizeof(buf) - 1] = '\0';
-		p = strchr(buf, '$');
+	tmp = buf;
+	p = pline;
+	while ((p = strchr(p, '$')) != NULL) {
 		for (macro = macros; macro != NULL; macro = macro->next) {
-			if (!strncmp(p + 1, macro->name, strlen(macro->name))) {
-				q = p + strlen(p) + strlen(macro->expansion) -
-				   (1 + strlen(macro->name));
-				memmove(p + strlen(macro->expansion),
-					p + 1 + strlen(macro->name),
-					strlen(p + 1 + strlen(macro->name)));
-				memcpy(p, macro->expansion,
-				       strlen(macro->expansion));
-				q[0] = '\0';
+			if (!strncmp(p + 1, macro->name, macro->name_len)) {
 				break;
 			}
 		}
@@ -704,13 +740,37 @@ read_config_line(const char *path, const
 				pline);
 			exit(6);
 		}
-		macro = NULL;
-		strncpy(line, buf, sizeof(line) - 1);
-		line[sizeof(line) - 1] = '\0';
+		memcpy(tmp, pline, p - pline);
+		r = tmp + (p - pline);
+		if ((p - pline) + macro->expansion_len > sizeof(buf)) {
+			memcpy(r, macro->expansion,
+			       sizeof(buf) - (p - pline) - 1);
+			tmp[sizeof(buf) - 1] = '\0';
+		} else {
+			memcpy(r, macro->expansion, macro->expansion_len);
+			r += macro->expansion_len;
+			if (pline_len - (1 + macro->name_len)
+			    + macro->expansion_len > sizeof(buf)) {
+				memcpy(r, p + 1 + macro->name_len,
+				       sizeof(buf) - (r - tmp) - 1);
+				tmp[sizeof(buf) - 1] = '\0';
+			} else
+				memcpy(r, p + 1 + macro->name_len,
+				       pline_len - (p - pline) - 1);
+		}
+		pline_len += macro->expansion_len - macro->name_len - 1;
+		if (pline_len >= sizeof(buf))
+			pline_len = sizeof(buf) - 1;
+		p = tmp + (p - pline);
+		pline = tmp;
+		if (tmp == buf)
+			tmp = buf2;
+		else
+			tmp = buf;
 	}
 
 	/* First, skip leading whitespace. */
-	for (p = line; (*p != '\0') && isspace(*p); p++) {
+	for (p = pline; (*p != '\0') && isspace(*p); p++) {
 		continue;
 	}
 
@@ -759,6 +819,7 @@ read_config_line(const char *path, const
 		memset(entry, 0, sizeof(struct device_entry));
 		entry->type = type;
 		entry->name_prefix_length = -1;
+		macro = NULL;
 		break;
 	case MACRO:
 		macro = malloc(sizeof(struct macro));
@@ -775,15 +836,14 @@ read_config_line(const char *path, const
 		for (p++; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		macro->name = strdup(buf);
-		if ((macro->name == NULL) || (strlen(macro->name) == 0)) {
+		macro->name_len = q - p;
+		macro->name = stralloc(p, q);
+		if (macro->name == NULL) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"bad macro name in \"%s\"\n", path, line);
+				"bad macro name in \"%s\"\n", path, pline);
 			exit(7);
 		}
 		p = q;
@@ -792,18 +852,14 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
-		strncpy(buf, p, sizeof(buf) - 1);
-		buf[sizeof(buf) - 1] = '\0';
-		macro->expansion = strdup(buf);
+		macro->expansion = strdup(p);
 
 		if ((macro->expansion == NULL) ||
-		    (strlen(macro->expansion) == 0)) {
+		    ((macro->expansion_len = strlen(macro->expansion)) == 0)) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"bad expansion in \"%s\"\n", path, line);
+				"bad expansion in \"%s\"\n", path, pline);
 			exit(7);
 		}
-		p = q;
 
 		macro->next = macros;
 		macros = macro;
@@ -811,7 +867,7 @@ read_config_line(const char *path, const
 		return;
 	}
 
-	if ((entry->type == BLOCK) || (entry->type == CHAR)) {
+	else if ((entry->type == BLOCK) || (entry->type == CHAR)) {
 		/* Now read the permissions. */
 		for (p++; (*p != '\0') && isspace(*p); p++) {
 			continue;
@@ -826,15 +882,13 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->user = strdup(buf);
-		if ((entry->user == NULL) || (strlen(entry->user) == 0)) {
+		entry->user = stralloc(p, q);
+		if (entry->user == NULL) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"unknown user in \"%s\"\n", path, line);
+				"unknown user in \"%s\"\n", path, pline);
 			exit(7);
 		}
 		p = q;
@@ -843,15 +897,13 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->group = strdup(buf);
-		if ((entry->group == NULL) || (strlen(entry->group) == 0)) {
+		entry->group = stralloc(p, q);
+		if (entry->group == NULL) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"unknown group in \"%s\"\n", path, line);
+				"unknown group in \"%s\"\n", path, pline);
 			exit(7);
 		}
 		p = q;
@@ -867,7 +919,7 @@ read_config_line(const char *path, const
 		}
 		if (entry->major <= 0) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"bad major in \"%s\"\n", path, line);
+				"bad major in \"%s\"\n", path, pline);
 			exit(7);
 		}
 
@@ -882,7 +934,7 @@ read_config_line(const char *path, const
 		}
 		if (entry->minor < 0) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"bad minor in \"%s\"\n", path, line);
+				"bad minor in \"%s\"\n", path, pline);
 			exit(7);
 		}
 
@@ -897,7 +949,7 @@ read_config_line(const char *path, const
 		}
 		if (entry->minor_step < 0) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"bad step in \"%s\"\n", path, line);
+				"bad step in \"%s\"\n", path, pline);
 			exit(7);
 		}
 
@@ -912,7 +964,7 @@ read_config_line(const char *path, const
 		}
 		if (entry->num <= 0) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"bad count in \"%s\"\n", path, line);
+				"bad count in \"%s\"\n", path, pline);
 			exit(7);
 		}
 
@@ -920,12 +972,15 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->name = strdup(buf);
+		entry->name = stralloc(p, q);
+		if (entry->name == NULL) {
+			fprintf(stderr, "error parsing \"%s\": "
+				"unknown name in \"%s\"\n", path, pline);
+			exit(7);
+		}
 		p = q;
 
 		entry->name_prefix_length = strcspn(entry->name, "%");
@@ -934,75 +989,82 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		if (strstr(entry->name, "%c")) {
-			entry->base = buf[0];
-		} else {
-			entry->base = atoi(buf);
-		}
-	}
 
-	if (entry->type == LINK) {
-		/* Read the link's name. */
-		for (p++; (*p != '\0') && isspace(*p); p++) {
-			continue;
-		}
-		memset(buf, '\0', sizeof(buf));
-		for (q = p; (*q != '\0') && !isspace(*q); q++) {
-			continue;
-		}
-		memcpy(buf, p, q - p);
-		entry->name = strdup(buf);
-		p = q;
+		if (strncmp(entry->name + entry->name_prefix_length, "%c", 2)
+		    == 0)
+			entry->base = p[0];
+		else
+			entry->base = atoi(p);
 
-		/* Read the link's target's name. */
-		for (; (*p != '\0') && isspace(*p); p++) {
-			continue;
-		}
-		memset(buf, '\0', sizeof(buf));
-		for (q = p; (*q != '\0') && !isspace(*q); q++) {
-			continue;
-		}
-		memcpy(buf, p, q - p);
-		entry->link_target = strdup(buf);
-		p = q;
+		if (q != p) {
+			p = q;
 
-		entry->num = 1;
+			/* Now read the (optional) modulo. */
+			for (; (*p != '\0') && isspace(*p); p++) {
+				continue;
+			}
+			for (q = p; (*q != '\0') && !isspace(*q); q++) {
+				continue;
+			}
+			entry->modulo = atoi(p);
+
+			if (entry->modulo) {
+				p = q;
+
+				/* Now read the (optional) second base. */
+				for (; (*p != '\0') && isspace(*p); p++) {
+					continue;
+				}
+				for (q = p; (*q != '\0') && !isspace(*q); q++) {
+					continue;
+				}
+
+				if (strstr(entry->name
+					   + entry->name_prefix_length + 1,
+					   "%c"))
+					entry->base2 = p[0];
+				else
+					entry->base2 = atoi(p);
+			}
+		}
 	}
 
-	if (entry->type == ALIAS) {
-		/* Read the alias's name. */
+	else if (entry->type == LINK || entry->type == ALIAS) {
+		/* Read the link's (or alias') name. */
 		for (p++; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->name = strdup(buf);
+		entry->name = stralloc(p, q);
+		if (entry->name == NULL) {
+			fprintf(stderr, "error parsing \"%s\": "
+				"unknown name in \"%s\"\n", path, pline);
+			exit(7);
+		}
 		p = q;
 
-		/* Read the target's name. */
+		/* Read the link's (or alias') target's name. */
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->link_target = strdup(buf);
-		p = q;
-
+		entry->link_target = stralloc(p, q);
+		if (entry->link_target == NULL) {
+			fprintf(stderr, "error parsing \"%s\": "
+				"unknown link target in \"%s\"\n", path, pline);
+			exit(7);
+		}
 		entry->num = 1;
 	}
 
-	if (entry->type == SOCKET) {
+	else if (entry->type == SOCKET) {
 		/* Now read the permissions. */
 		for (p++; (*p != '\0') && isspace(*p); p++) {
 			continue;
@@ -1017,15 +1079,13 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->user = strdup(buf);
-		if ((entry->user == NULL) || (strlen(entry->user) == 0)) {
+		entry->user = stralloc(p, q);
+		if (entry->user == NULL) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"unknown user in \"%s\"\n", path, line);
+				"unknown user in \"%s\"\n", path, pline);
 			exit(7);
 		}
 		p = q;
@@ -1034,15 +1094,13 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->group = strdup(buf);
-		if ((entry->group == NULL) || (strlen(entry->group) == 0)) {
+		entry->group = stralloc(p, q);
+		if (entry->group == NULL) {
 			fprintf(stderr, "error parsing \"%s\": "
-				"unknown group in \"%s\"\n", path, line);
+				"unknown group in \"%s\"\n", path, pline);
 			exit(7);
 		}
 		p = q;
@@ -1051,14 +1109,15 @@ read_config_line(const char *path, const
 		for (; (*p != '\0') && isspace(*p); p++) {
 			continue;
 		}
-		memset(buf, '\0', sizeof(buf));
 		for (q = p; (*q != '\0') && !isspace(*q); q++) {
 			continue;
 		}
-		memcpy(buf, p, q - p);
-		entry->name = strdup(buf);
-		p = q;
-
+		entry->name = stralloc(p, q);
+		if (entry->name == NULL) {
+			fprintf(stderr, "error parsing \"%s\": "
+				"unknown name in \"%s\"\n", path, pline);
+			exit(7);
+		}
 		entry->num = 1;
 	}
 
@@ -1085,8 +1144,8 @@ read_config_single_file(const char *path
 		exit(4);
 	}
 
-	while (fgets(buf, sizeof(buf), fp) != NULL) {
-		int l = strlen(buf);
+	while (fgets_unlocked(buf, sizeof(buf), fp) != NULL) {
+		size_t l = strlen(buf);
 
 		while ((l > 0) &&
 		       ((buf[l - 1] == '\n') || (buf[l - 1] == '\r'))) {
@@ -1094,7 +1153,7 @@ read_config_single_file(const char *path
 			buf[l] = '\0';
 		}
 
-		read_config_line(path, buf);
+		read_config_line(path, buf, l);
 	}
 
 	fclose(fp);
--- MAKEDEV-3.23/gendac960.jj	2008-09-19 03:03:54.000000000 +0200
+++ MAKEDEV-3.23/gendac960	2008-09-27 09:20:39.000000000 +0200
@@ -1,14 +1,9 @@
 #!//bin/sh
 for ctr in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
-if [ $ctr -lt 8 ] ; then
-maj=`expr $ctr + 48`
-else
-maj=`expr $ctr - 8 + 136`
-fi
-for ld in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ; do
-for part in 0 1 2 3 4 5 6 7; do
-	min=`expr $ld \* 8 + $part`
-	printf 'b $STORAGE            %4s %3s  1   1 rd/c%sd%sp%s\n' $maj $min $ctr $ld $part | sed 's/p0$//g'
-done
-done
+	if [ $ctr -lt 8 ] ; then
+		maj=`expr $ctr + 48`
+	else
+		maj=`expr $ctr - 8 + 136`
+	fi
+	printf 'b $STORAGE            %4s 0    1 256 rd/c%sd%%d%%|p%%d 0 8\n' $maj $ctr
 done
--- MAKEDEV-3.23/gencciss.jj	2008-09-19 03:03:54.000000000 +0200
+++ MAKEDEV-3.23/gencciss	2008-09-27 09:15:16.000000000 +0200
@@ -1,10 +1,5 @@
 #!//bin/sh
 for ctr in 0 1 2 3 4 5 6 7; do
-maj=`expr $ctr + 104`
-for ld in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
-for part in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
-	min=`expr $ld \* 16 + $part`
-	printf 'b $STORAGE            %4s %3s  1   1 cciss/c%sd%sp%s\n' $maj $min $ctr $ld $part | sed 's/p0$//g'
-done
-done
+	maj=`expr $ctr + 104`
+	printf 'b $STORAGE            %4s 0    1 256 cciss/c%sd%%d%%|p%%d 0 16\n' $maj $ctr
 done
--- MAKEDEV-3.23/genida.jj	2008-09-19 03:03:54.000000000 +0200
+++ MAKEDEV-3.23/genida	2008-09-27 09:16:26.000000000 +0200
@@ -1,10 +1,5 @@
 #!//bin/sh
 for ctr in 0 1 2 3 4 5 6 7; do
-maj=`expr $ctr + 72`
-for ld in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
-for part in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
-	min=`expr $ld \* 16 + $part`
-	printf 'b $STORAGE            %4s %3s  1   1 ida/c%sd%sp%s\n' $maj $min $ctr $ld $part | sed 's/p0$//g'
-done
-done
+	maj=`expr $ctr + 72`
+	printf 'b $STORAGE            %4s 0    1 256 ida/c%sd%%d%%|p%%d 0 16\n' $maj $ctr
 done
--- MAKEDEV-3.23/makedev.d/02linux-2.6.x.jj	2008-09-19 03:03:54.000000000 +0200
+++ MAKEDEV-3.23/makedev.d/02linux-2.6.x	2008-09-27 09:10:57.000000000 +0200
@@ -7,40 +7,40 @@
 
 c $KMEM                  1   2  1   1 kmem
 
-b $FLOPPY                2   0  1   4 fd%d 0
+b $FLOPPY                2   0  1   4 fd%d
 b $FLOPPY                2 128  1   4 fd%d 4
 
-b $FLOPPY                2   4  1   4 fd%dd360  0
-b $FLOPPY                2  20  1   4 fd%dh360  0
-b $FLOPPY                2  48  1   4 fd%dh410  0
-b $FLOPPY                2  64  1   4 fd%dh420  0
-b $FLOPPY                2  24  1   4 fd%dh720  0
-b $FLOPPY                2  80  1   4 fd%dh880  0
-b $FLOPPY                2   8  1   4 fd%dh1200 0
-b $FLOPPY                2  40  1   4 fd%dh1440 0
-b $FLOPPY                2  56  1   4 fd%dh1476 0
-b $FLOPPY                2  72  1   4 fd%dh1494 0
-b $FLOPPY                2  92  1   4 fd%dh1660 0
-
-b $FLOPPY                2  12  1   4 fd%du360  0
-b $FLOPPY                2  16  1   4 fd%du720  0
-b $FLOPPY                2 120  1   4 fd%du800  0
-b $FLOPPY                2  52  1   4 fd%du820  0
-b $FLOPPY                2  68  1   4 fd%du830  0
-b $FLOPPY                2  84  1   4 fd%du1040 0
-b $FLOPPY                2  88  1   4 fd%du1120 0
-b $FLOPPY                2  28  1   4 fd%du1440 0
-b $FLOPPY                2 124  1   4 fd%du1660 0
-b $FLOPPY                2  44  1   4 fd%du1680 0
-b $FLOPPY                2  60  1   4 fd%du1722 0
-b $FLOPPY                2  76  1   4 fd%du1743 0
-b $FLOPPY                2  96  1   4 fd%du1760 0
-b $FLOPPY                2 116  1   4 fd%du1840 0
-b $FLOPPY                2 100  1   4 fd%du1920 0
-b $FLOPPY                2  32  1   4 fd%du2880 0
-b $FLOPPY                2 104  1   4 fd%du3200 0
-b $FLOPPY                2 108  1   4 fd%du3520 0
-b $FLOPPY                2 112  1   4 fd%du3840 0
+b $FLOPPY                2   4  1   4 fd%dd360
+b $FLOPPY                2  20  1   4 fd%dh360
+b $FLOPPY                2  48  1   4 fd%dh410
+b $FLOPPY                2  64  1   4 fd%dh420
+b $FLOPPY                2  24  1   4 fd%dh720
+b $FLOPPY                2  80  1   4 fd%dh880
+b $FLOPPY                2   8  1   4 fd%dh1200
+b $FLOPPY                2  40  1   4 fd%dh1440
+b $FLOPPY                2  56  1   4 fd%dh1476
+b $FLOPPY                2  72  1   4 fd%dh1494
+b $FLOPPY                2  92  1   4 fd%dh1660
+
+b $FLOPPY                2  12  1   4 fd%du360
+b $FLOPPY                2  16  1   4 fd%du720
+b $FLOPPY                2 120  1   4 fd%du800
+b $FLOPPY                2  52  1   4 fd%du820
+b $FLOPPY                2  68  1   4 fd%du830
+b $FLOPPY                2  84  1   4 fd%du1040
+b $FLOPPY                2  88  1   4 fd%du1120
+b $FLOPPY                2  28  1   4 fd%du1440
+b $FLOPPY                2 124  1   4 fd%du1660
+b $FLOPPY                2  44  1   4 fd%du1680
+b $FLOPPY                2  60  1   4 fd%du1722
+b $FLOPPY                2  76  1   4 fd%du1743
+b $FLOPPY                2  96  1   4 fd%du1760
+b $FLOPPY                2 116  1   4 fd%du1840
+b $FLOPPY                2 100  1   4 fd%du1920
+b $FLOPPY                2  32  1   4 fd%du2880
+b $FLOPPY                2 104  1   4 fd%du3200
+b $FLOPPY                2 108  1   4 fd%du3520
+b $FLOPPY                2 112  1   4 fd%du3840
 
 b $FLOPPY                2 132  1   4 fd%dd360  4
 b $FLOPPY                2 148  1   4 fd%dh360  4
@@ -74,7 +74,7 @@ b $FLOPPY                2 232  1   4 fd
 b $FLOPPY                2 236  1   4 fd%du3520 4
 b $FLOPPY                2 240  1   4 fd%du3840 4
 
-b $FLOPPY                2   4  1   4 fd%dCompaQ 0
+b $FLOPPY                2   4  1   4 fd%dCompaQ
 b $FLOPPY                2 132  1   4 fd%dCompaQ 4
 
 c $CONSOLE              10   4  1   1 amigamouse
@@ -139,7 +139,7 @@ b $STORAGE              23   0  1   1 mc
 
 b $STORAGE              24   0  1   1 cdu535
 
-b $STORAGE              25   0  1   4 sbpcd%d 0
+b $STORAGE              25   0  1   4 sbpcd%d
 
 b $STORAGE              26   0  1   4 sbpcd%d 4
 
@@ -158,22 +158,7 @@ c $ROOT                 41   0  1   1 ya
 b $STORAGE              41   0  1   1 bpcd
 
 c $SERIAL               44   0  1  64 cui%d
-b $STORAGE              44   0  1  16 ftla
-b $STORAGE              44  16  1  16 ftlb
-b $STORAGE              44  32  1  16 ftlc
-b $STORAGE              44  48  1  16 ftld
-b $STORAGE              44  64  1  16 ftle
-b $STORAGE              44  80  1  16 ftlf
-b $STORAGE              44  96  1  16 ftlg
-b $STORAGE              44 112  1  16 ftlh
-b $STORAGE              44 128  1  16 ftli
-b $STORAGE              44 144  1  16 ftlj
-b $STORAGE              44 160  1  16 ftlk
-b $STORAGE              44 176  1  16 ftll
-b $STORAGE              44 192  1  16 ftlm
-b $STORAGE              44 208  1  16 ftln
-b $STORAGE              44 224  1  16 ftlo
-b $STORAGE              44 240  1  16 ftlp
+b $STORAGE              44   0  1 256 ftl%c%|%d a 16
 
 c $ROOT                 45   0  1  64 isdn%d
 c $ROOT                 45  64  1  64 isdnctrl%d
@@ -183,265 +168,47 @@ c $ROOT                 53   3  1   3 ic
 c $ROOT                 55   0  1   1 dsp56k
 
 # Here there be dragons.
-b $STORAGE              65   0  1  16 sdq
-b $STORAGE              65  16  1  16 sdr
-b $STORAGE              65  32  1  16 sds
-b $STORAGE              65  48  1  16 sdt
-b $STORAGE              65  64  1  16 sdu
-b $STORAGE              65  80  1  16 sdv
-b $STORAGE              65  96  1  16 sdw
-b $STORAGE              65 112  1  16 sdx
-b $STORAGE              65 128  1  16 sdy
-b $STORAGE              65 144  1  16 sdz
-b $STORAGE              65 160  1  16 sdaa
-b $STORAGE              65 176  1  16 sdab
-b $STORAGE              65 192  1  16 sdac
-b $STORAGE              65 208  1  16 sdad
-b $STORAGE              65 224  1  16 sdae
-b $STORAGE              65 240  1  16 sdaf
-
-b $STORAGE              66   0  1  16 sdag
-b $STORAGE              66  16  1  16 sdah
-b $STORAGE              66  32  1  16 sdai
-b $STORAGE              66  48  1  16 sdaj
-b $STORAGE              66  64  1  16 sdak
-b $STORAGE              66  80  1  16 sdal
-b $STORAGE              66  96  1  16 sdam
-b $STORAGE              66 112  1  16 sdan
-b $STORAGE              66 128  1  16 sdao
-b $STORAGE              66 144  1  16 sdap
-b $STORAGE              66 160  1  16 sdaq
-b $STORAGE              66 176  1  16 sdar
-b $STORAGE              66 192  1  16 sdas
-b $STORAGE              66 208  1  16 sdat
-b $STORAGE              66 224  1  16 sdau
-b $STORAGE              66 240  1  16 sdav
-
-b $STORAGE              67   0  1  16 sdaw
-b $STORAGE              67  16  1  16 sdax
-b $STORAGE              67  32  1  16 sday
-b $STORAGE              67  48  1  16 sdaz
-b $STORAGE              67  64  1  16 sdba
-b $STORAGE              67  80  1  16 sdbb
-b $STORAGE              67  96  1  16 sdbc
-b $STORAGE              67 112  1  16 sdbd
-b $STORAGE              67 128  1  16 sdbe
-b $STORAGE              67 144  1  16 sdbf
-b $STORAGE              67 160  1  16 sdbg
-b $STORAGE              67 176  1  16 sdbh
-b $STORAGE              67 192  1  16 sdbi
-b $STORAGE              67 208  1  16 sdbj
-b $STORAGE              67 224  1  16 sdbk
-b $STORAGE              67 240  1  16 sdbl
-
-b $STORAGE              68   0  1  16 sdbm
-b $STORAGE              68  16  1  16 sdbn
-b $STORAGE              68  32  1  16 sdbo
-b $STORAGE              68  48  1  16 sdbp
-b $STORAGE              68  64  1  16 sdbq
-b $STORAGE              68  80  1  16 sdbr
-b $STORAGE              68  96  1  16 sdbs
-b $STORAGE              68 112  1  16 sdbt
-b $STORAGE              68 128  1  16 sdbu
-b $STORAGE              68 144  1  16 sdbv
-b $STORAGE              68 160  1  16 sdbw
-b $STORAGE              68 176  1  16 sdbx
-b $STORAGE              68 192  1  16 sdby
-b $STORAGE              68 208  1  16 sdbz
-b $STORAGE              68 224  1  16 sdca
-b $STORAGE              68 240  1  16 sdcb
-
-b $STORAGE              69   0  1  16 sdcc
-b $STORAGE              69  16  1  16 sdcd
-b $STORAGE              69  32  1  16 sdce
-b $STORAGE              69  48  1  16 sdcf
-b $STORAGE              69  64  1  16 sdcg
-b $STORAGE              69  80  1  16 sdch
-b $STORAGE              69  96  1  16 sdci
-b $STORAGE              69 112  1  16 sdcj
-b $STORAGE              69 128  1  16 sdck
-b $STORAGE              69 144  1  16 sdcl
-b $STORAGE              69 160  1  16 sdcm
-b $STORAGE              69 176  1  16 sdcn
-b $STORAGE              69 192  1  16 sdco
-b $STORAGE              69 208  1  16 sdcp
-b $STORAGE              69 224  1  16 sdcq
-b $STORAGE              69 240  1  16 sdcr
-
-b $STORAGE              70   0  1  16 sdcs
-b $STORAGE              70  16  1  16 sdct
-b $STORAGE              70  32  1  16 sdcu
-b $STORAGE              70  48  1  16 sdcv
-b $STORAGE              70  64  1  16 sdcw
-b $STORAGE              70  80  1  16 sdcx
-b $STORAGE              70  96  1  16 sdcy
-b $STORAGE              70 112  1  16 sdcz
-b $STORAGE              70 128  1  16 sdda
-b $STORAGE              70 144  1  16 sddb
-b $STORAGE              70 160  1  16 sddc
-b $STORAGE              70 176  1  16 sddd
-b $STORAGE              70 192  1  16 sdde
-b $STORAGE              70 208  1  16 sddf
-b $STORAGE              70 224  1  16 sddg
-b $STORAGE              70 240  1  16 sddh
-
-b $STORAGE              71   0  1  16 sddi
-b $STORAGE              71  16  1  16 sddj
-b $STORAGE              71  32  1  16 sddk
-b $STORAGE              71  48  1  16 sddl
-b $STORAGE              71  64  1  16 sddm
-b $STORAGE              71  80  1  16 sddn
-b $STORAGE              71  96  1  16 sddo
-b $STORAGE              71 112  1  16 sddp
-b $STORAGE              71 128  1  16 sddq
-b $STORAGE              71 144  1  16 sddr
-b $STORAGE              71 160  1  16 sdds
-b $STORAGE              71 176  1  16 sddt
-b $STORAGE              71 192  1  16 sddu
-b $STORAGE              71 208  1  16 sddv
-b $STORAGE              71 224  1  16 sddw
-b $STORAGE              71 240  1  16 sddx
-
-
-b $STORAGE              80   0  1  16 i2o/hda
-b $STORAGE              80  16  1  16 i2o/hdb
-b $STORAGE              80  32  1  16 i2o/hdc
-b $STORAGE              80  48  1  16 i2o/hdd
-b $STORAGE              80  64  1  16 i2o/hde
-b $STORAGE              80  80  1  16 i2o/hdf
-b $STORAGE              80  96  1  16 i2o/hdg
-b $STORAGE              80 112  1  16 i2o/hdh
-b $STORAGE              80 128  1  16 i2o/hdi
-b $STORAGE              80 144  1  16 i2o/hdj
-b $STORAGE              80 160  1  16 i2o/hdk
-b $STORAGE              80 176  1  16 i2o/hdl
-b $STORAGE              80 192  1  16 i2o/hdm
-b $STORAGE              80 208  1  16 i2o/hdn
-b $STORAGE              80 224  1  16 i2o/hdo
-b $STORAGE              80 240  1  16 i2o/hdp
-
-b $STORAGE              81   0  1  16 i2o/hdq
-b $STORAGE              81  16  1  16 i2o/hdr
-b $STORAGE              81  32  1  16 i2o/hds
-b $STORAGE              81  48  1  16 i2o/hdt
-b $STORAGE              81  64  1  16 i2o/hdu
-b $STORAGE              81  80  1  16 i2o/hdv
-b $STORAGE              81  96  1  16 i2o/hdw
-b $STORAGE              81 112  1  16 i2o/hdx
-b $STORAGE              81 128  1  16 i2o/hdy
-b $STORAGE              81 144  1  16 i2o/hdz
-b $STORAGE              81 160  1  16 i2o/hdaa
-b $STORAGE              81 176  1  16 i2o/hdab
-b $STORAGE              81 192  1  16 i2o/hdac
-b $STORAGE              81 208  1  16 i2o/hdad
-b $STORAGE              81 224  1  16 i2o/hdae
-b $STORAGE              81 240  1  16 i2o/hdaf
+b $STORAGE              65   0  1 160 sd%c%|%d q 16
+b $STORAGE              65 160  1  96 sda%c%|%d a 16
+
+b $STORAGE              66   0  1 256 sda%c%|%d g 16
+
+b $STORAGE              67   0  1  64 sda%c%|%d w 16
+b $STORAGE              67  64  1 192 sdb%c%|%d a 16
+
+b $STORAGE              68   0  1 224 sdb%c%|%d m 16
+b $STORAGE              68 224  1  32 sdc%c%|%d a 16
+
+b $STORAGE              69   0  1 256 sdc%c%|%d c 16
+
+b $STORAGE              70   0  1 128 sdc%c%|%d s 16
+b $STORAGE              70 128  1 128 sdd%c%|%d a 16
+
+b $STORAGE              71   0  1 256 sdd%c%|%d i 16
+
+b $STORAGE              80   0  1 256 i2o/hd%c%|%d a 16
+
+b $STORAGE              81   0  1 160 i2o/hd%c%|%d q 16
+b $STORAGE              81 160  1  96 i2o/hda%c%|%d a 16
 
 c $CONSOLE              82   0  1   4 winradio%d
 
-b $STORAGE              82   0  1  16 i2o/hdag
-b $STORAGE              82  16  1  16 i2o/hdah
-b $STORAGE              82  32  1  16 i2o/hdai
-b $STORAGE              82  48  1  16 i2o/hdaj
-b $STORAGE              82  64  1  16 i2o/hdak
-b $STORAGE              82  80  1  16 i2o/hdal
-b $STORAGE              82  96  1  16 i2o/hdam
-b $STORAGE              82 112  1  16 i2o/hdan
-b $STORAGE              82 128  1  16 i2o/hdao
-b $STORAGE              82 144  1  16 i2o/hdap
-b $STORAGE              82 160  1  16 i2o/hdaq
-b $STORAGE              82 176  1  16 i2o/hdar
-b $STORAGE              82 192  1  16 i2o/hdas
-b $STORAGE              82 208  1  16 i2o/hdat
-b $STORAGE              82 224  1  16 i2o/hdau
-b $STORAGE              82 240  1  16 i2o/hdav
+b $STORAGE              82   0  1 256 i2o/hda%c%|%d g 16
 
 c $CONSOLE              83   0  1  16 mga_vid%d
 
-b $STORAGE              83   0  1  16 i2o/hdaw
-b $STORAGE              83  16  1  16 i2o/hdax
-b $STORAGE              83  32  1  16 i2o/hday
-b $STORAGE              83  48  1  16 i2o/hdaz
-b $STORAGE              83  64  1  16 i2o/hdba
-b $STORAGE              83  80  1  16 i2o/hdbb
-b $STORAGE              83  96  1  16 i2o/hdbc
-b $STORAGE              83 112  1  16 i2o/hdbd
-b $STORAGE              83 128  1  16 i2o/hdbe
-b $STORAGE              83 144  1  16 i2o/hdbf
-b $STORAGE              83 160  1  16 i2o/hdbg
-b $STORAGE              83 176  1  16 i2o/hdbh
-b $STORAGE              83 192  1  16 i2o/hdbi
-b $STORAGE              83 208  1  16 i2o/hdbj
-b $STORAGE              83 224  1  16 i2o/hdbk
-b $STORAGE              83 240  1  16 i2o/hdbl
-
-b $STORAGE              84   0  1  16 i2o/hdbm
-b $STORAGE              84  16  1  16 i2o/hdbn
-b $STORAGE              84  32  1  16 i2o/hdbo
-b $STORAGE              84  48  1  16 i2o/hdbp
-b $STORAGE              84  64  1  16 i2o/hdbq
-b $STORAGE              84  80  1  16 i2o/hdbr
-b $STORAGE              84  96  1  16 i2o/hdbs
-b $STORAGE              84 112  1  16 i2o/hdbt
-b $STORAGE              84 128  1  16 i2o/hdbu
-b $STORAGE              84 144  1  16 i2o/hdbv
-b $STORAGE              84 160  1  16 i2o/hdbw
-b $STORAGE              84 176  1  16 i2o/hdbx
-b $STORAGE              84 192  1  16 i2o/hdby
-b $STORAGE              84 208  1  16 i2o/hdbz
-b $STORAGE              84 224  1  16 i2o/hdca
-b $STORAGE              84 240  1  16 i2o/hdcb
-
-b $STORAGE              85   0  1  16 i2o/hdcc
-b $STORAGE              85  16  1  16 i2o/hdcd
-b $STORAGE              85  32  1  16 i2o/hdce
-b $STORAGE              85  48  1  16 i2o/hdcf
-b $STORAGE              85  64  1  16 i2o/hdcg
-b $STORAGE              85  80  1  16 i2o/hdch
-b $STORAGE              85  96  1  16 i2o/hdci
-b $STORAGE              85 112  1  16 i2o/hdcj
-b $STORAGE              85 128  1  16 i2o/hdck
-b $STORAGE              85 144  1  16 i2o/hdcl
-b $STORAGE              85 160  1  16 i2o/hdcm
-b $STORAGE              85 176  1  16 i2o/hdcn
-b $STORAGE              85 192  1  16 i2o/hdco
-b $STORAGE              85 208  1  16 i2o/hdcp
-b $STORAGE              85 224  1  16 i2o/hdcq
-b $STORAGE              85 240  1  16 i2o/hdcr
-
-b $STORAGE              86   0  1  16 i2o/hdcs
-b $STORAGE              86  16  1  16 i2o/hdct
-b $STORAGE              86  32  1  16 i2o/hdcu
-b $STORAGE              86  48  1  16 i2o/hdcv
-b $STORAGE              86  64  1  16 i2o/hdcw
-b $STORAGE              86  80  1  16 i2o/hdcx
-b $STORAGE              86  96  1  16 i2o/hdcy
-b $STORAGE              86 112  1  16 i2o/hdcz
-b $STORAGE              86 128  1  16 i2o/hdda
-b $STORAGE              86 144  1  16 i2o/hddb
-b $STORAGE              86 160  1  16 i2o/hddc
-b $STORAGE              86 176  1  16 i2o/hddd
-b $STORAGE              86 192  1  16 i2o/hdde
-b $STORAGE              86 208  1  16 i2o/hddf
-b $STORAGE              86 224  1  16 i2o/hddg
-b $STORAGE              86 240  1  16 i2o/hddh
-
-b $STORAGE              87   0  1  16 i2o/hddi
-b $STORAGE              87  16  1  16 i2o/hddj
-b $STORAGE              87  32  1  16 i2o/hddk
-b $STORAGE              87  48  1  16 i2o/hddl
-b $STORAGE              87  64  1  16 i2o/hddm
-b $STORAGE              87  80  1  16 i2o/hddn
-b $STORAGE              87  96  1  16 i2o/hddo
-b $STORAGE              87 112  1  16 i2o/hddp
-b $STORAGE              87 128  1  16 i2o/hddq
-b $STORAGE              87 144  1  16 i2o/hddr
-b $STORAGE              87 160  1  16 i2o/hdds
-b $STORAGE              87 176  1  16 i2o/hddt
-b $STORAGE              87 192  1  16 i2o/hddu
-b $STORAGE              87 208  1  16 i2o/hddv
-b $STORAGE              87 224  1  16 i2o/hddw
-b $STORAGE              87 240  1  16 i2o/hddx
+b $STORAGE              83   0  1  64 i2o/hda%c%|%d w 16
+b $STORAGE              83  64  1 192 i2o/hdb%c%|%d a 16
+
+b $STORAGE              84   0  1 224 i2o/hdb%c%|%d m 16
+b $STORAGE              84 224  1  32 i2o/hdc%c%|%d a 16
+
+b $STORAGE              85   0  1 256 i2o/hdc%c%|%d c 16
+
+b $STORAGE              86   0  1 128 i2o/hdc%c%|%d s 16
+b $STORAGE              86 128  1 128 i2o/hdd%c%|%d a 16
+
+b $STORAGE              87   0  1 256 i2o/hdd%c%|%d i 16
 
 # devices.txt gives us 64 numbered dasd devices, with apparently up to three
 # lettered partitions on each; the older s390-specific file used 64 lettered
@@ -452,315 +219,46 @@ b $STORAGE              94   1  4  64 da
 b $STORAGE              94   2  4  64 dasd%db
 b $STORAGE              94   3  4  64 dasd%dc
 
-b $STORAGE              96   0  1  16 inftla
-b $STORAGE              96  16  1  16 inftlb
-b $STORAGE              96  32  1  16 inftlc
-b $STORAGE              96  48  1  16 inftld
-b $STORAGE              96  64  1  16 inftle
-b $STORAGE              96  80  1  16 inftlf
-b $STORAGE              96  96  1  16 inftlg
-b $STORAGE              96 112  1  16 inftlh
-b $STORAGE              96 128  1  16 inftli
-b $STORAGE              96 144  1  16 inftlj
-b $STORAGE              96 160  1  16 inftlk
-b $STORAGE              96 176  1  16 inftll
-b $STORAGE              96 192  1  16 inftlm
-b $STORAGE              96 208  1  16 inftln
-b $STORAGE              96 224  1  16 inftlo
-b $STORAGE              96 240  1  16 inftlp
-
-b $STORAGE             101   0  1   1 amiraid/ar0
-b $STORAGE             101   1  1  15 amiraid/ar0p%d
-b $STORAGE             101  16  1   1 amiraid/ar1
-b $STORAGE             101  17  1  15 amiraid/ar1p%d
-b $STORAGE             101  32  1   1 amiraid/ar2
-b $STORAGE             101  33  1  15 amiraid/ar2p%d
-b $STORAGE             101  48  1   1 amiraid/ar3
-b $STORAGE             101  49  1  15 amiraid/ar3p%d
-b $STORAGE             101  64  1   1 amiraid/ar4
-b $STORAGE             101  65  1  15 amiraid/ar4p%d
-b $STORAGE             101  80  1   1 amiraid/ar5
-b $STORAGE             101  81  1  15 amiraid/ar5p%d
-b $STORAGE             101  96  1   1 amiraid/ar6
-b $STORAGE             101  97  1  15 amiraid/ar6p%d
-b $STORAGE             101 112  1   1 amiraid/ar7
-b $STORAGE             101 113  1  15 amiraid/ar7p%d
-b $STORAGE             101 128  1   1 amiraid/ar8
-b $STORAGE             101 129  1  15 amiraid/ar8p%d
-b $STORAGE             101 144  1   1 amiraid/ar9
-b $STORAGE             101 145  1  15 amiraid/ar9p%d
-b $STORAGE             101 160  1   1 amiraid/ar10
-b $STORAGE             101 161  1  15 amiraid/ar10p%d
-b $STORAGE             101 176  1   1 amiraid/ar11
-b $STORAGE             101 177  1  15 amiraid/ar11p%d
-b $STORAGE             101 192  1   1 amiraid/ar12
-b $STORAGE             101 193  1  15 amiraid/ar12p%d
-b $STORAGE             101 208  1   1 amiraid/ar13
-b $STORAGE             101 209  1  15 amiraid/ar13p%d
-b $STORAGE             101 224  1   1 amiraid/ar14
-b $STORAGE             101 225  1  15 amiraid/ar14p%d
-b $STORAGE             101 240  1   1 amiraid/ar15
-b $STORAGE             101 241  1  15 amiraid/ar15p%d
-
-b $STORAGE             112   0  1   8 iseries/vda
-b $STORAGE             112   8  1   8 iseries/vdb
-b $STORAGE             112  16  1   8 iseries/vdc
-b $STORAGE             112  24  1   8 iseries/vdd
-b $STORAGE             112  32  1   8 iseries/vde
-b $STORAGE             112  40  1   8 iseries/vdf
-b $STORAGE             112  48  1   8 iseries/vdg
-b $STORAGE             112  56  1   8 iseries/vdh
-b $STORAGE             112  64  1   8 iseries/vdi
-b $STORAGE             112  72  1   8 iseries/vdj
-b $STORAGE             112  80  1   8 iseries/vdk
-b $STORAGE             112  88  1   8 iseries/vdl
-b $STORAGE             112  96  1   8 iseries/vdm
-b $STORAGE             112 104  1   8 iseries/vdn
-b $STORAGE             112 112  1   8 iseries/vdo
-b $STORAGE             112 120  1   8 iseries/vdp
-b $STORAGE             112 128  1   8 iseries/vdq
-b $STORAGE             112 136  1   8 iseries/vdr
-b $STORAGE             112 144  1   8 iseries/vds
-b $STORAGE             112 152  1   8 iseries/vdt
-b $STORAGE             112 160  1   8 iseries/vdu
-b $STORAGE             112 168  1   8 iseries/vdv
-b $STORAGE             112 176  1   8 iseries/vdw
-b $STORAGE             112 184  1   8 iseries/vdx
-b $STORAGE             112 192  1   8 iseries/vdy
-b $STORAGE             112 200  1   8 iseries/vdz
-b $STORAGE             112 208  1   8 iseries/vdaa
-b $STORAGE             112 216  1   8 iseries/vdab
-b $STORAGE             112 224  1   8 iseries/vdac
-b $STORAGE             112 232  1   8 iseries/vdad
-b $STORAGE             112 240  1   8 iseries/vdae
-b $STORAGE             112 248  1   8 iseries/vdaf
+b $STORAGE              96   0  1 256 inftl%c%|%d a 16
+
+b $STORAGE             101   0  1 256 amiraid/ar%d%|p%d 0 16
+
+b $STORAGE             112   0  1 208 iseries/vd%c%|%d a 8
+b $STORAGE             112 208  1  48 iseries/vda%c%|%d a 8
 
 b $STORAGE             113   0  1   8 iseries/vcd%c a
 
 b $STORAGE             115   0  1 256 nwfs/v%d
 
-b $STORAGE             116   0 16  16 umem/d%d
-b $STORAGE             116   1  1  15 umem/d0p%d
-b $STORAGE             116  17  1  15 umem/d1p%d
-b $STORAGE             116  33  1  15 umem/d2p%d
-b $STORAGE             116  49  1  15 umem/d3p%d
-b $STORAGE             116  65  1  15 umem/d4p%d
-b $STORAGE             116  81  1  15 umem/d5p%d
-b $STORAGE             116  97  1  15 umem/d6p%d
-b $STORAGE             116 113  1  15 umem/d7p%d
-b $STORAGE             116 129  1  15 umem/d8p%d
-b $STORAGE             116 145  1  15 umem/d9p%d
-b $STORAGE             116 161  1  15 umem/d10p%d
-b $STORAGE             116 177  1  15 umem/d11p%d
-b $STORAGE             116 193  1  15 umem/d12p%d
-b $STORAGE             116 209  1  15 umem/d13p%d
-b $STORAGE             116 225  1  15 umem/d14p%d
-b $STORAGE             116 241  1  15 umem/d15p%d
-
-b $STORAGE             128   0  1  16 sddy
-b $STORAGE             128  16  1  16 sddz
-b $STORAGE             128  32  1  16 sdea
-b $STORAGE             128  48  1  16 sdeb
-b $STORAGE             128  64  1  16 sdec
-b $STORAGE             128  80  1  16 sded
-b $STORAGE             128  96  1  16 sdee
-b $STORAGE             128 112  1  16 sdef
-b $STORAGE             128 128  1  16 sdeg
-b $STORAGE             128 144  1  16 sdeh
-b $STORAGE             128 160  1  16 sdei
-b $STORAGE             128 176  1  16 sdej
-b $STORAGE             128 192  1  16 sdek
-b $STORAGE             128 208  1  16 sdel
-b $STORAGE             128 224  1  16 sdem
-b $STORAGE             128 240  1  16 sden
-
-b $STORAGE             129   0  1  16 sdeo
-b $STORAGE             129  16  1  16 sdep
-b $STORAGE             129  32  1  16 sdeq
-b $STORAGE             129  48  1  16 sder
-b $STORAGE             129  64  1  16 sdes
-b $STORAGE             129  80  1  16 sdet
-b $STORAGE             129  96  1  16 sdeu
-b $STORAGE             129 112  1  16 sdev
-b $STORAGE             129 128  1  16 sdew
-b $STORAGE             129 144  1  16 sdex
-b $STORAGE             129 160  1  16 sdey
-b $STORAGE             129 176  1  16 sdez
-b $STORAGE             129 192  1  16 sdfa
-b $STORAGE             129 208  1  16 sdfb
-b $STORAGE             129 224  1  16 sdfc
-b $STORAGE             129 240  1  16 sdfd
-
-b $STORAGE             130   0  1  16 sdfe
-b $STORAGE             130  16  1  16 sdff
-b $STORAGE             130  32  1  16 sdfg
-b $STORAGE             130  48  1  16 sdfh
-b $STORAGE             130  64  1  16 sdfi
-b $STORAGE             130  80  1  16 sdfj
-b $STORAGE             130  96  1  16 sdfk
-b $STORAGE             130 112  1  16 sdfl
-b $STORAGE             130 128  1  16 sdfm
-b $STORAGE             130 144  1  16 sdfn
-b $STORAGE             130 160  1  16 sdfo
-b $STORAGE             130 176  1  16 sdfp
-b $STORAGE             130 192  1  16 sdfq
-b $STORAGE             130 208  1  16 sdfr
-b $STORAGE             130 224  1  16 sdfs
-b $STORAGE             130 240  1  16 sdft
-
-b $STORAGE             131   0  1  16 sdfu
-b $STORAGE             131  16  1  16 sdfv
-b $STORAGE             131  32  1  16 sdfw
-b $STORAGE             131  48  1  16 sdfx
-b $STORAGE             131  64  1  16 sdfy
-b $STORAGE             131  80  1  16 sdfz
-b $STORAGE             131  96  1  16 sdga
-b $STORAGE             131 112  1  16 sdgb
-b $STORAGE             131 128  1  16 sdgc
-b $STORAGE             131 144  1  16 sdgd
-b $STORAGE             131 160  1  16 sdge
-b $STORAGE             131 176  1  16 sdgf
-b $STORAGE             131 192  1  16 sdgg
-b $STORAGE             131 208  1  16 sdgh
-b $STORAGE             131 224  1  16 sdgi
-b $STORAGE             131 240  1  16 sdgj
-
-b $STORAGE             132   0  1  16 sdgk
-b $STORAGE             132  16  1  16 sdgl
-b $STORAGE             132  32  1  16 sdgm
-b $STORAGE             132  48  1  16 sdgn
-b $STORAGE             132  64  1  16 sdgo
-b $STORAGE             132  80  1  16 sdgp
-b $STORAGE             132  96  1  16 sdgq
-b $STORAGE             132 112  1  16 sdgr
-b $STORAGE             132 128  1  16 sdgs
-b $STORAGE             132 144  1  16 sdgt
-b $STORAGE             132 160  1  16 sdgu
-b $STORAGE             132 176  1  16 sdgv
-b $STORAGE             132 192  1  16 sdgw
-b $STORAGE             132 208  1  16 sdgx
-b $STORAGE             132 224  1  16 sdgy
-b $STORAGE             132 240  1  16 sdgz
-
-b $STORAGE             133   0  1  16 sdha
-b $STORAGE             133  16  1  16 sdhb
-b $STORAGE             133  32  1  16 sdhc
-b $STORAGE             133  48  1  16 sdhd
-b $STORAGE             133  64  1  16 sdhe
-b $STORAGE             133  80  1  16 sdhf
-b $STORAGE             133  96  1  16 sdhg
-b $STORAGE             133 112  1  16 sdhh
-b $STORAGE             133 128  1  16 sdhi
-b $STORAGE             133 144  1  16 sdhj
-b $STORAGE             133 160  1  16 sdhk
-b $STORAGE             133 176  1  16 sdhl
-b $STORAGE             133 192  1  16 sdhm
-b $STORAGE             133 208  1  16 sdhn
-b $STORAGE             133 224  1  16 sdho
-b $STORAGE             133 240  1  16 sdhp
-
-b $STORAGE             134   0  1  16 sdhq
-b $STORAGE             134  16  1  16 sdhr
-b $STORAGE             134  32  1  16 sdhs
-b $STORAGE             134  48  1  16 sdht
-b $STORAGE             134  64  1  16 sdhu
-b $STORAGE             134  80  1  16 sdhv
-b $STORAGE             134  96  1  16 sdhw
-b $STORAGE             134 112  1  16 sdhx
-b $STORAGE             134 128  1  16 sdhy
-b $STORAGE             134 144  1  16 sdhz
-b $STORAGE             134 160  1  16 sdia
-b $STORAGE             134 176  1  16 sdib
-b $STORAGE             134 192  1  16 sdic
-b $STORAGE             134 208  1  16 sdid
-b $STORAGE             134 224  1  16 sdie
-b $STORAGE             134 240  1  16 sdif
-
-b $STORAGE             135   0  1  16 sdig
-b $STORAGE             135  16  1  16 sdih
-b $STORAGE             135  32  1  16 sdii
-b $STORAGE             135  48  1  16 sdij
-b $STORAGE             135  64  1  16 sdik
-b $STORAGE             135  80  1  16 sdil
-b $STORAGE             135  96  1  16 sdim
-b $STORAGE             135 112  1  16 sdin
-b $STORAGE             135 128  1  16 sdio
-b $STORAGE             135 144  1  16 sdip
-b $STORAGE             135 160  1  16 sdiq
-b $STORAGE             135 176  1  16 sdir
-b $STORAGE             135 192  1  16 sdis
-b $STORAGE             135 208  1  16 sdit
-b $STORAGE             135 224  1  16 sdiu
-b $STORAGE             135 240  1  16 sdiv
-
-b $STORAGE             153   0 16  16 emd/%d
-b $STORAGE             153   1  1  15 emd/0p%d 1
-b $STORAGE             153  17  1  15 emd/1p%d 1
-b $STORAGE             153  33  1  15 emd/2p%d 1
-b $STORAGE             153  49  1  15 emd/3p%d 1
-b $STORAGE             153  65  1  15 emd/4p%d 1
-b $STORAGE             153  81  1  15 emd/5p%d 1
-b $STORAGE             153  97  1  15 emd/6p%d 1
-b $STORAGE             153 113  1  15 emd/7p%d 1
-b $STORAGE             153 129  1  15 emd/8p%d 1
-b $STORAGE             153 145  1  15 emd/9p%d 1
-b $STORAGE             153 161  1  15 emd/10p%d 1
-b $STORAGE             153 177  1  15 emd/11p%d 1
-b $STORAGE             153 193  1  15 emd/12p%d 1
-b $STORAGE             153 209  1  15 emd/13p%d 1
-b $STORAGE             153 225  1  15 emd/14p%d 1
-b $STORAGE             153 241  1  15 emd/15p%d 1
-
-b $STORAGE             160   0  1   1 sx8/0
-b $STORAGE             160   1  1  31 sx8/0p%d 1
-b $STORAGE             160  32  1   1 sx8/1
-b $STORAGE             160  33  1  31 sx8/1p%d 1
-b $STORAGE             160  64  1   1 sx8/2
-b $STORAGE             160  65  1  31 sx8/2p%d 1
-b $STORAGE             160  96  1   1 sx8/3
-b $STORAGE             160  97  1  31 sx8/3p%d 1
-b $STORAGE             160 128  1   1 sx8/4
-b $STORAGE             160 129  1  31 sx8/4p%d 1
-b $STORAGE             160 160  1   1 sx8/5
-b $STORAGE             160 161  1  31 sx8/5p%d 1
-b $STORAGE             160 192  1   1 sx8/6
-b $STORAGE             160 193  1  31 sx8/6p%d 1
-b $STORAGE             160 224  1   1 sx8/7
-b $STORAGE             160 225  1  31 sx8/7p%d 1
-
-b $STORAGE             161   0  1   1 sx8/8
-b $STORAGE             161   1  1  31 sx8/8p%d 1
-b $STORAGE             161  32  1   1 sx8/9
-b $STORAGE             161  33  1  31 sx8/9p%d 1
-b $STORAGE             161  64  1   1 sx8/10
-b $STORAGE             161  65  1  31 sx8/10p%d 1
-b $STORAGE             161  96  1   1 sx8/11
-b $STORAGE             161  97  1  31 sx8/11p%d 1
-b $STORAGE             161 128  1   1 sx8/12
-b $STORAGE             161 129  1  31 sx8/12p%d 1
-b $STORAGE             161 160  1   1 sx8/13
-b $STORAGE             161 161  1  31 sx8/13p%d 1
-b $STORAGE             161 192  1   1 sx8/14
-b $STORAGE             161 193  1  31 sx8/14p%d 1
-b $STORAGE             161 224  1   1 sx8/15
-b $STORAGE             161 225  1  31 sx8/15p%d 1
-
-b $STORAGE             180   0  1   8 uba
-b $STORAGE             180   8  1   8 ubb
-b $STORAGE             180  16  1   8 ubc
-b $STORAGE             180  24  1   8 ubd
-b $STORAGE             180  32  1   8 ube
-b $STORAGE             180  40  1   8 ubf
-b $STORAGE             180  48  1   8 ubg
-b $STORAGE             180  56  1   8 ubh
-b $STORAGE             180  64  1   8 ubi
-b $STORAGE             180  72  1   8 ubj
-b $STORAGE             180  80  1   8 ubk
-b $STORAGE             180  88  1   8 ubl
-b $STORAGE             180  96  1   8 ubm
-b $STORAGE             180 104  1   8 ubn
-b $STORAGE             180 112  1   8 ubo
-b $STORAGE             180 120  1   8 ubp
+b $STORAGE             116   0  1 256 umem/d%d%|p%d 0 16
+
+b $STORAGE             128   0  1  32 sdd%c%|%d y 16
+b $STORAGE             128  32  1 224 sde%c%|%d a 16
+
+b $STORAGE             129   0  1 192 sde%c%|%d o 16
+b $STORAGE             129 192  1  64 sdf%c%|%d a 16
+
+b $STORAGE             130   0  1 256 sdf%c%|%d e 16
+
+b $STORAGE             131   0  1  96 sdf%c%|%d u 16
+b $STORAGE             131  96  1 160 sdg%c%|%d a 16
+
+b $STORAGE             132   0  1 256 sdg%c%|%d k 16
+
+b $STORAGE             133   0  1 256 sdh%c%|%d a 16
+
+b $STORAGE             134   0  1 160 sdh%c%|%d q 16
+b $STORAGE             134 160  1  96 sdi%c%|%d a 16
+
+b $STORAGE             135   0  1 256 sdi%c%|%d g 16
+
+b $STORAGE             153   0  1 256 emd/%d%|p%d 0 16
+
+b $STORAGE             160   0  1 256 sx8/%d%|p%d 0 16
+
+b $STORAGE             161   0  1 256 sx8/%d%|p%d 8 16
+
+b $STORAGE             180   0  1 128 ub%c%|%d a 8
 
 c $CONSOLE             195   0  1 255 nvidia%d
 c $CONSOLE             195 255  1   1 nvidiactl
@@ -774,22 +272,7 @@ c $STORAGE             200   5  1   1 vx
 
 # We can skip 201 because Veritas user-land handles it.
 
-b $STORAGE             202   0  1  16 xvda
-b $STORAGE             202  16  1  16 xvdb
-b $STORAGE             202  32  1  16 xvdc
-b $STORAGE             202  48  1  16 xvdd
-b $STORAGE             202  64  1  16 xvde
-b $STORAGE             202  80  1  16 xvdf
-b $STORAGE             202  96  1  16 xvdg
-b $STORAGE             202 112  1  16 xvdh
-b $STORAGE             202 128  1  16 xvdi
-b $STORAGE             202 144  1  16 xvdj
-b $STORAGE             202 160  1  16 xvdk
-b $STORAGE             202 176  1  16 xvdl
-b $STORAGE             202 192  1  16 xvdm
-b $STORAGE             202 208  1  16 xvdn
-b $STORAGE             202 224  1  16 xvdo
-b $STORAGE             202 240  1  16 xvdp
+b $STORAGE             202   0  1 256 xvd%c%|%d a 16
 
 c $ROOT                207   0  1   1 cpqhealth/cpqw
 c $ROOT                207   1  1   1 cpqhealth/crom
@@ -804,14 +287,14 @@ c $ROOT                207   9  1   1 cp
 c $ROOT                207  10  1   1 cpqhealth/cram
 c $ROOT                207  11  1   1 cpqhealth/cpci
 
-c $ROOT                230   0  1  32 iseries/vt%d 0
-c $ROOT                230  32  1  32 iseries/vt%dl 0
-c $ROOT                230  64  1  32 iseries/vt%dm 0
-c $ROOT                230  96  1  32 iseries/vt%da 0
-c $ROOT                230 128  1  32 iseries/nvt%d 0
-c $ROOT                230 160  1  32 iseries/nvt%dl 0
-c $ROOT                230 192  1  32 iseries/nvt%dm 0
-c $ROOT                230 224  1  32 iseries/nvt%da 0
+c $ROOT                230   0  1  32 iseries/vt%d
+c $ROOT                230  32  1  32 iseries/vt%dl
+c $ROOT                230  64  1  32 iseries/vt%dm
+c $ROOT                230  96  1  32 iseries/vt%da
+c $ROOT                230 128  1  32 iseries/nvt%d
+c $ROOT                230 160  1  32 iseries/nvt%dl
+c $ROOT                230 192  1  32 iseries/nvt%dm
+c $ROOT                230 224  1  32 iseries/nvt%da
 
 c $ROOT                231   0  1  64 infiniband/umad%d
 c $ROOT                231  64  1  64 infiniband/issm%d
--- MAKEDEV-3.23/makedev.d/linux-2.6.x.jj	2008-09-19 03:03:54.000000000 +0200
+++ MAKEDEV-3.23/makedev.d/linux-2.6.x	2008-09-27 08:47:59.000000000 +0200
@@ -19,39 +19,11 @@ c $ROOT                  1  11  1   1 km
 b $STORAGE               1   0  1 128 ram%d
 b $STORAGE               1 250  1   1 initrd
 
-c $PTY                   2   0  1  16 ptyp%x
-c $PTY                   2  16  1  16 ptyq%x
-c $PTY                   2  32  1  16 ptyr%x
-c $PTY                   2  48  1  16 ptys%x
-c $PTY                   2  64  1  16 ptyt%x
-c $PTY                   2  80  1  16 ptyu%x
-c $PTY                   2  96  1  16 ptyv%x
-c $PTY                   2 112  1  16 ptyw%x
-c $PTY                   2 128  1  16 ptyx%x
-c $PTY                   2 144  1  16 ptyy%x
-c $PTY                   2 160  1  16 ptyz%x
-c $PTY                   2 176  1  16 ptya%x
-c $PTY                   2 192  1  16 ptyb%x
-c $PTY                   2 208  1  16 ptyc%x
-c $PTY                   2 224  1  16 ptyd%x
-c $PTY                   2 240  1  16 ptye%x
-
-c $PTY                   3   0  1  16 ttyp%x
-c $PTY                   3  16  1  16 ttyq%x
-c $PTY                   3  32  1  16 ttyr%x
-c $PTY                   3  48  1  16 ttys%x
-c $PTY                   3  64  1  16 ttyt%x
-c $PTY                   3  80  1  16 ttyu%x
-c $PTY                   3  96  1  16 ttyv%x
-c $PTY                   3 112  1  16 ttyw%x
-c $PTY                   3 128  1  16 ttyx%x
-c $PTY                   3 144  1  16 ttyy%x
-c $PTY                   3 160  1  16 ttyz%x
-c $PTY                   3 176  1  16 ttya%x
-c $PTY                   3 192  1  16 ttyb%x
-c $PTY                   3 208  1  16 ttyc%x
-c $PTY                   3 224  1  16 ttyd%x
-c $PTY                   3 240  1  16 ttye%x
+c $PTY                   2   0  1 176 pty%c%x p 16
+c $PTY                   2 176  1  80 pty%c%x a 16
+
+c $PTY                   3   0  1 176 tty%c%x p 16
+c $PTY                   3 176  1  80 tty%c%x a 16
 
 # See fs/partitions/check.c in the kernel sources for the source of this
 # limitation.
@@ -75,22 +47,7 @@ c $VCSA                  7 128  1  64 vc
 
 b $STORAGE               7   0  1 256 loop%d
 
-b $STORAGE               8   0  1  16 sda
-b $STORAGE               8  16  1  16 sdb
-b $STORAGE               8  32  1  16 sdc
-b $STORAGE               8  48  1  16 sdd
-b $STORAGE               8  64  1  16 sde
-b $STORAGE               8  80  1  16 sdf
-b $STORAGE               8  96  1  16 sdg
-b $STORAGE               8 112  1  16 sdh
-b $STORAGE               8 128  1  16 sdi
-b $STORAGE               8 144  1  16 sdj
-b $STORAGE               8 160  1  16 sdk
-b $STORAGE               8 176  1  16 sdl
-b $STORAGE               8 192  1  16 sdm
-b $STORAGE               8 208  1  16 sdn
-b $STORAGE               8 224  1  16 sdo
-b $STORAGE               8 240  1  16 sdp
+b $STORAGE               8   0  1 256 sd%c%|%d a 16
 
 c $STORAGE               9   0  1  32 st%d
 c $STORAGE               9  32  1  32 st%dl
@@ -183,10 +140,7 @@ c $ROOT                 10 208  1   1 co
 c $ROOT                 10 209  1   1 compaq/cpqrid
 c $ROOT                 10 210  1   1 impi/bt
 c $ROOT                 10 211  1   1 impi/smic
-c $ROOT                 10 212  1   1 watchdogs/0
-c $ROOT                 10 213  1   1 watchdogs/1
-c $ROOT                 10 214  1   1 watchdogs/2
-c $ROOT                 10 215  1   1 watchdogs/3
+c $ROOT                 10 212  1   4 watchdogs/%d
 c $ROOT                 10 216  1   1 fujitsu/apanel
 c $ROOT                 10 217  1   1 ni/natmotn
 c $ROOT                 10 218  1   1 kchuid
@@ -214,8 +168,7 @@ c $CONSOLE              13  32  1  31 in
 c $CONSOLE              13  63  1   1 input/mice
 c $CONSOLE              13  64  1  32 input/event%d
 
-b $STORAGE              13   0  1  64 xda
-b $STORAGE              13  64  1  64 xdb
+b $STORAGE              13   0  1 128 xd%c%|%d a 16
 
 c $CONSOLE              14   0  1   1 mixer
 c $CONSOLE              14   1  1   1 sequencer
@@ -377,10 +330,7 @@ b $STORAGE              43   0  1 128 nb
 c $SERIAL               44   0  1  64 cui%d
 c $ROOT                 45 128  1  64 ippp%d
 c $ROOT                 45 255  1   1 isdninfo
-b $STORAGE              45   0  1  16 pda
-b $STORAGE              45  16  1  16 pdb
-b $STORAGE              45  32  1  16 pdc
-b $STORAGE              45  48  1  16 pdd
+b $STORAGE              45   0  1  64 pd%c%|%d a 16
 
 c $SERIAL               46   0  1  16 ttyR%d
 b $STORAGE              46   0  1   4 pcd%d
@@ -512,22 +462,7 @@ c $STORAGE              97   0  1   4 pg
 
 c $ROOT                 98   0  1   4 comedi%d
 
-b $STORAGE              98   0  1  16 ubda
-b $STORAGE              98  16  1  16 ubdb
-b $STORAGE              98  32  1  16 ubdc
-b $STORAGE              98  48  1  16 ubdd
-b $STORAGE              98  64  1  16 ubde
-b $STORAGE              98  80  1  16 ubdf
-b $STORAGE              98  96  1  16 ubdg
-b $STORAGE              98 112  1  16 ubdh
-b $STORAGE              98 128  1  16 ubdi
-b $STORAGE              98 144  1  16 ubdj
-b $STORAGE              98 160  1  16 ubdk
-b $STORAGE              98 176  1  16 ubdl
-b $STORAGE              98 192  1  16 ubdm
-b $STORAGE              98 208  1  16 ubdn
-b $STORAGE              98 224  1  16 ubdo
-b $STORAGE              98 240  1  16 ubdp
+b $STORAGE              98   0  1 256 ubd%c%|%d a 16
 
 c $PRINTER              99   0  1   8 parport%d
 b $STORAGE              99   0  1   1 jsfd
@@ -539,22 +474,7 @@ c $ROOT                101   1  1  16 md
 
 c $ROOT                102   0  1   4 tlk%d
 
-b $STORAGE             102   0  1  16 cbd/a
-b $STORAGE             102  16  1  16 cbd/b
-b $STORAGE             102  32  1  16 cbd/c
-b $STORAGE             102  48  1  16 cbd/d
-b $STORAGE             102  64  1  16 cbd/e
-b $STORAGE             102  80  1  16 cbd/f
-b $STORAGE             102  96  1  16 cbd/g
-b $STORAGE             102 112  1  16 cbd/h
-b $STORAGE             102 128  1  16 cbd/i
-b $STORAGE             102 144  1  16 cbd/j
-b $STORAGE             102 160  1  16 cbd/k
-b $STORAGE             102 176  1  16 cbd/l
-b $STORAGE             102 192  1  16 cbd/m
-b $STORAGE             102 208  1  16 cbd/n
-b $STORAGE             102 224  1  16 cbd/o
-b $STORAGE             102 240  1  16 cbd/p
+b $STORAGE             102   0  1 256 cbd/%c%|%d a 16
 
 c $STORAGE             103   0  1   2 nnpfs%d
 b $ROOT                103   0  1   1 audit
@@ -704,9 +624,9 @@ c $SERIAL              189   0  1  16 cu
 c $CONSOLE             190   0  1  16 kctt%d
 
 c $ROOT                192   0  1   1 profile
-c $ROOT                192   1  1  16 profile%d 0
+c $ROOT                192   1  1  16 profile%d
 c $ROOT                193   0  1   1 trace
-c $ROOT                193   1  1  16 trace%d 0
+c $ROOT                193   1  1  16 trace%d
 
 c $CONSOLE             194   0 16  16 mvideo/status%d
 c $CONSOLE             194   1 16  16 mvideo/stream%d
@@ -734,13 +654,13 @@ c $ROOT                203   0  1  16 cp
 
 b $ROOT                203   0  1  16 cpu/%d/cpuid
 
-c $SERIAL              204   0  1   4 ttyLU%d 0
-c $SERIAL              204   4  1   1 ttyFB%d 0
-c $SERIAL              204   5  1   3 ttySA%d 0
-c $SERIAL              204   8  1   4 ttySC%d 0
-c $SERIAL              204  12  1   4 ttyFW%d 0
-c $SERIAL              204  16  1  16 ttyAM%d 0
-c $SERIAL              204  32  1   8 ttyDB%d 0
+c $SERIAL              204   0  1   4 ttyLU%d
+c $SERIAL              204   4  1   1 ttyFB%d
+c $SERIAL              204   5  1   3 ttySA%d
+c $SERIAL              204   8  1   4 ttySC%d
+c $SERIAL              204  12  1   4 ttyFW%d
+c $SERIAL              204  16  1  16 ttyAM%d
+c $SERIAL              204  32  1   8 ttyDB%d
 c $TTY                 204  40  1   1 ttySG0
 c $SERIAL              204  41  1   3 ttySMX%d
 c $SERIAL              204  44  1   2 ttyMM%d
@@ -754,41 +674,41 @@ c $SERIAL              204 154  1  16 tt
 c $SERIAL              204 170  1  16 ttyNX%d
 c $SERIAL              204 186  1   1 ttyJ0
 
-c $SERIAL              205   0  1   4 culu%d 0
-c $SERIAL              205   4  1   1 cufb%d 0
-c $SERIAL              205   5  1   3 cusa%d 0
-c $SERIAL              205   8  1   4 cusc%d 0
-c $SERIAL              205  12  1   4 cufw%d 0
-c $SERIAL              205  16  1  16 cuam%d 0
-c $SERIAL              205  32  1   8 cudb%d 0
+c $SERIAL              205   0  1   4 culu%d
+c $SERIAL              205   4  1   1 cufb%d
+c $SERIAL              205   5  1   3 cusa%d
+c $SERIAL              205   8  1   4 cusc%d
+c $SERIAL              205  12  1   4 cufw%d
+c $SERIAL              205  16  1  16 cuam%d
+c $SERIAL              205  32  1   8 cudb%d
 c $TTY                 205  40  1   1 cusg0
-c $SERIAL              205  41  1   3 ttycusmx%d 0
+c $SERIAL              205  41  1   3 ttycusmx%d
 c $SERIAL              205  44  1   5 cucpm%d
 c $SERIAL              205  50  1  32 cuioc4%d
 c $SERIAL              205  82  1   2 cuvr%d
 
-c $STORAGE             206   0  1  32 osst%d 0
-c $STORAGE             206  32  1  32 osst%dl 0
-c $STORAGE             206  64  1  32 osst%dm 0
-c $STORAGE             206  96  1  32 osst%da 0
-c $STORAGE             206 128  1  32 nosst%d 0
-c $STORAGE             206 160  1  32 nosst%dl 0
-c $STORAGE             206 196  1  32 nosst%dm 0
-c $STORAGE             206 224  1  32 nosst%da 0
+c $STORAGE             206   0  1  32 osst%d
+c $STORAGE             206  32  1  32 osst%dl
+c $STORAGE             206  64  1  32 osst%dm
+c $STORAGE             206  96  1  32 osst%da
+c $STORAGE             206 128  1  32 nosst%d
+c $STORAGE             206 160  1  32 nosst%dl
+c $STORAGE             206 196  1  32 nosst%dm
+c $STORAGE             206 224  1  32 nosst%da
 
 c $SERIAL              208   0  1 256 ttyU%d
 c $SERIAL              209   0  1 256 cuu%d
 
-c $SERIAL              210   0 10   4 sbei/wxcfg%d 0
-c $SERIAL              210   1 10   4 sbei/dld%d 0
-c $SERIAL              210   2  1   4 sbei/wan0%d 0
-c $SERIAL              210   6  1   4 sbei/wanc0%d 0
-c $SERIAL              210  12  1   4 sbei/wan1%d 0
-c $SERIAL              210  16  1   4 sbei/wanc1%d 0
-c $SERIAL              210  22  1   4 sbei/wan2%d 0
-c $SERIAL              210  26  1   4 sbei/wanc2%d 0
-c $SERIAL              210  32  1   4 sbei/wan3%d 0
-c $SERIAL              210  36  1   4 sbei/wanc3%d 0
+c $SERIAL              210   0 10   4 sbei/wxcfg%d
+c $SERIAL              210   1 10   4 sbei/dld%d
+c $SERIAL              210   2  1   4 sbei/wan0%d
+c $SERIAL              210   6  1   4 sbei/wanc0%d
+c $SERIAL              210  12  1   4 sbei/wan1%d
+c $SERIAL              210  16  1   4 sbei/wanc1%d
+c $SERIAL              210  22  1   4 sbei/wan2%d
+c $SERIAL              210  26  1   4 sbei/wanc2%d
+c $SERIAL              210  32  1   4 sbei/wan3%d
+c $SERIAL              210  36  1   4 sbei/wanc3%d
 
 c $SERIAL              211   0  1   8 addinum/cpci1500/%d
 
@@ -835,22 +755,22 @@ c $SERIAL              217   0  1  16 cu
 c $ROOT                218   0  1  16 logicalco/bci/%d
 c $ROOT                219   0  1  16 logicalco/dci1300/%d
 
-c $ROOT                220   0  2  16 myricom/gm%d 0
-c $ROOT                220   1  2  16 myricom/gmp%d 0
+c $ROOT                220   0  2  16 myricom/gm%d
+c $ROOT                220   1  2  16 myricom/gmp%d
 
-c $ROOT                221   0  1   4 bus/vme/m%d 0
-c $ROOT                221   4  1   4 bus/vme/s%d 0
+c $ROOT                221   0  1   4 bus/vme/m%d
+c $ROOT                221   4  1   4 bus/vme/s%d
 c $ROOT                221   8  1   1 bus/vme/ctl
 
 c $SERIAL              224   0  1 255 ttyY%d
 c $SERIAL              225   0  1 255 cuy%d
 
-c $CONSOLE             226   0  1   4 dri/card%d 0
+c $CONSOLE             226   0  1   4 dri/card%d
 
 c $ROOT                227   1  1  32 3270/tty%d 1
 c $ROOT                228   0  1  33 3270/tub
 
-c $ROOT                229   0  1  32 iseries/vtty%d 0
+c $ROOT                229   0  1  32 iseries/vtty%d
 
 c $ROOT                232   0 10   3 biometric/sensor%d/fingerprint
 c $ROOT                232   1 10   3 biometric/sensor%d/iris
@@ -860,27 +780,12 @@ c $ROOT                232   4 10   3 bi
 c $ROOT                232   5 10   3 biometric/sensor%d/hand
 
 c $ROOT                233   0  1   1 ipath
-c $ROOT                233   1  1   4 ipath%d 0
+c $ROOT                233   1  1   4 ipath%d
 c $ROOT                233 129  1   1 ipath_sma
 c $ROOT                233 130  1   1 ipath_diag
 
-c $ROOT                256   0  1 1028 ttyEQ%d
+c $ROOT                256   0  1 128 ttyEQ%d
 
-b $ROOT                256   0  1  16 rfda
-b $ROOT                256  16  1  16 rfdb
-b $ROOT                256  32  1  16 rfdc
-b $ROOT                256  48  1  16 rfdd
-b $ROOT                256  64  1  16 rfde
-b $ROOT                256  80  1  16 rfdf
-b $ROOT                256  96  1  16 rfdg
-b $ROOT                256 112  1  16 rfdh
-b $ROOT                256 128  1  16 rfdi
-b $ROOT                256 144  1  16 rfdj
-b $ROOT                256 160  1  16 rfdk
-b $ROOT                256 176  1  16 rfdl
-b $ROOT                256 192  1  16 rfdm
-b $ROOT                256 208  1  16 rfdn
-b $ROOT                256 224  1  16 rfdo
-b $ROOT                256 240  1  16 rfdp
+b $ROOT                256   0  1 256 rfd%c%|%d a 16
 
 c $ROOT                257   0  1   1 ptlsec
 

From fedora at camperquake.de  Wed Oct  1 15:48:51 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 1 Oct 2008 17:48:51 +0200
Subject: rawhide report: 20081001 changes
In-Reply-To: <48E396E4.4010904@cora.nwra.com>
References: <20081001105558.3706F1F825C@releng2.fedora.phx.redhat.com>
	<20081001161343.6efb564a@dhcp03.addix.net>
	<48E3872E.8050602@fedoraproject.org>
	<20081001162857.44e09e53@dhcp03.addix.net>
	<4c4ba1530810010734g5277b788vf59f20fe18fdabbd@mail.gmail.com>
	<20081001165806.6aebd7ea@dhcp03.addix.net>
	<48E396E4.4010904@cora.nwra.com>
Message-ID: <20081001174851.762a35cc@dhcp03.addix.net>

Hi.

On Wed, 01 Oct 2008 09:27:32 -0600, Orion Poplawski wrote:

> > (**) intel(0): Framebuffer compression enabled
> > (**) intel(0): Tiling enabled
> > 
> 
> Me too.
> 
> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ 
> Integrated Graphics Controller (rev 02)
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=464944

Updating to the i810 driver Tom mentioned fixes this, too.

http://koji.fedoraproject.org/packages/xorg-x11-drv-i810/2.4.2/9.fc10/i386/xorg-x11-drv-i810-2.4.2-9.fc10.i386.rpm
http://koji.fedoraproject.org/packages/xorg-x11-drv-i810/2.4.2/9.fc10/x86_64/xorg-x11-drv-i810-2.4.2-9.fc10.x86_64.rpm



From ville.skytta at iki.fi  Wed Oct  1 17:19:53 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 1 Oct 2008 20:19:53 +0300
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081001035116.GA21890@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
	<20081001035116.GA21890@jadzia.bu.edu>
Message-ID: <200810012019.53814.ville.skytta@iki.fi>

On Wednesday 01 October 2008, Matthew Miller wrote:
> On Tue, Sep 30, 2008 at 08:52:10PM -0600, Stephen John Smoogen wrote:
> > I think the chance for putting it back is still there.. if someone is
> > willing to do the work on the hard but correct way? I think it was
> > crickets the last couple of times when volunteers were asked for that.
>
> Sure, I'm willing to work on it.

Count me in, too.



From kyle at mcmartin.ca  Wed Oct  1 17:20:38 2008
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Wed, 1 Oct 2008 13:20:38 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20081001172038.GG10632@phobos.i.cabal.ca>

On Wed, Oct 01, 2008 at 06:52:15PM +0200, Jakub Jelinek wrote:
> Given the recent 5sec boot efforts http://lwn.net/Articles/299483/
> and Mandriva follow-ups on that http://lwn.net/Articles/300873/,
> I thought I'd share my modprobe and MAKEDEV speedup patches with
> a wider community so folks can experiment with them, especially seeing
> Mandriva folks playing with turning modprobe into a daemon because of its
> slowness.
> 

Ah, I'm glad to see others working on this! I'd not seen the Mandriva
efforts, but I should really poke at them as I'd turned modprobe into
a library and started integrating it into udev.

> MAKEDEV sources almost 500KB of config files on every invocation, and the
> inner loop is terribly inefficient.  The second patch allows it to shrink
> the files to 55KB while expressing the same info and makes the inner loop
> more efficient.  Depending on how many modprobe and MAKEDEV invocations
> are done on your box during bootup, this can or might not make meassurable
> difference.
> 

Definitely. The biggest win by far for MAKEDEV is profiling the often
hit devices, and prioritizing things. Dave Airlie moved a bunch of the
cciss and other almost never-seen devices to be sourced last and ended
up with a huge win.

> IMHO the binary caches for modprobe are better than
> having thousands of symlinks around (given 7500 wildcards where for many of
> them a few dozens of symlinks would be needed), especially if the symlinks
> would be included in rpm package, but I can be of course convinced
> otherwise.  In any case, the module-init-tools contains a bunch of speedups
> that are IMHO desirable anyway, even without the modules.{dep,alias}cache
> files.
> 

This sounds like a better idea than what I was working on, especially
since I hadn't tackled speeding up the alias issue yet. Big +1 from me
on integrating this. (It also solves a few other issues, like making
things work properly in the cpio initrd...)

Have you tested things on a big endian machine? In any case, this looks
really good. Hopefully Jon will apply this upstream soon so we can get
it in F10.

regards, Kyle

> 	Jakub

> For modules.dep depmod -a also creates modules.depcache which is just  
> a simple hash table with chains and a dumb fast compression of strings,
> so that modules.depcache is roughly 3 times smaller than modules.dep.
> The hash function already makes no difference between _ and -, so for dep
> lookups all it needs is compute the hash, walk the chain, comparing full
> 32-bit hash value and if that hits, compare also modname string, on success
> just return that and its dependencies.
> 
> For modules.alias it creates modules.aliascache, which contains a tree.
> Each tree node has 0 or more associated fnmatch wildcards that need to be
> fnmatched at that level unconditionally, then some fixed number of
> characters and prefixes of up to that length can be binary searched to
> find further node.  The further node can be of 3 types - either again
> a normal range node, or just a pointer to a result (if all chars have been
> already compared), or an entry containing remaining chars to strncmp and
> pointer to result.  Guess better is just to read the algorithm in modprobe.c
> for details.  When reading modules.alias, modprobe always calls fnmatch
> on all patterns in there and fnmatch is quite expensive.  With
> modules.aliascache, for some strings which don't have any wildcards in it,
> fnmatch isn't called at all, otherwise it is called only on wildcards where
> its prefix consisting of non-wildcard chars matches the input.
> 
> Both modules.depcache and modules.aliascache contain a file header, which
> embeds a version number, endianity and mtime/ino/size of the corresponding
> modules.{dep,alias} file - in case it is hand edited later, modprobe won't
> use the cache which will be stale in that case, until regenerated.
> 
> In addition to these changes there are some small cleanups here and there,
> e.g. as modprobe and depmod aren't threaded we can speed things up quite a
> lot by using _unlocked functions, or there is no point for every
> getline_wrapped to malloc new chunk of memory and let the caller free it
> (almost) immediately again.
> 
> vanilla, modules.dep (time to handle ~ 1600 dep searches):
> real    0m6.554s
> user    0m6.424s
> sys     0m0.128s
> 
> patched + modules.depcache
> real    0m0.042s
> user    0m0.008s
> sys     0m0.034s
> 
> vanilla, modules.alias (time to handle ~ 6400 alias searches):
> real    1m22.548s
> user    1m21.554s
> sys     0m0.965s
> 
> patched + modules.aliascache
> real    0m0.552s
> user    0m0.438s
> sys     0m0.114s
> 
> time of modprobe pci:v0000EA60d00009897svAsdBbcCscDiE
> real    0m0.034s
> user    0m0.028s
> sys     0m0.006s
> vs.
> real    0m0.007s
> user    0m0.004s
> sys     0m0.003s
> 



From notting at redhat.com  Wed Oct  1 17:26:24 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 1 Oct 2008 13:26:24 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001172038.GG10632@phobos.i.cabal.ca>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
Message-ID: <20081001172624.GA28817@nostromo.devel.redhat.com>

Kyle McMartin (kyle at mcmartin.ca) said: 
> > MAKEDEV sources almost 500KB of config files on every invocation, and the
> > inner loop is terribly inefficient.  The second patch allows it to shrink
> > the files to 55KB while expressing the same info and makes the inner loop
> > more efficient.  Depending on how many modprobe and MAKEDEV invocations
> > are done on your box during bootup, this can or might not make meassurable
> > difference.
> 
> Definitely. The biggest win by far for MAKEDEV is profiling the often
> hit devices, and prioritizing things. Dave Airlie moved a bunch of the
> cciss and other almost never-seen devices to be sourced last and ended
> up with a huge win.

Well, the biggest win for MAKEDEV would be to not run it at all on boot -
we shouldn't have to.

Bill



From kyle at mcmartin.ca  Wed Oct  1 17:28:57 2008
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Wed, 1 Oct 2008 13:28:57 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001172624.GA28817@nostromo.devel.redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
	<20081001172624.GA28817@nostromo.devel.redhat.com>
Message-ID: <20081001172857.GH10632@phobos.i.cabal.ca>

On Wed, Oct 01, 2008 at 01:26:24PM -0400, Bill Nottingham wrote:
> Kyle McMartin (kyle at mcmartin.ca) said: 
> > > MAKEDEV sources almost 500KB of config files on every invocation, and the
> > > inner loop is terribly inefficient.  The second patch allows it to shrink
> > > the files to 55KB while expressing the same info and makes the inner loop
> > > more efficient.  Depending on how many modprobe and MAKEDEV invocations
> > > are done on your box during bootup, this can or might not make meassurable
> > > difference.
> > 
> > Definitely. The biggest win by far for MAKEDEV is profiling the often
> > hit devices, and prioritizing things. Dave Airlie moved a bunch of the
> > cciss and other almost never-seen devices to be sourced last and ended
> > up with a huge win.
> 
> Well, the biggest win for MAKEDEV would be to not run it at all on boot -
> we shouldn't have to.
> 

Agreed. ;-)



From ajax at redhat.com  Wed Oct  1 17:32:05 2008
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 01 Oct 2008 13:32:05 -0400
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <1222874124.3618.31.camel@localhost.localdomain>
References: <20080930171332.GB12353@amd.home.annexia.org>
	<1222871915.17250.2.camel@localhost.localdomain>
	<1222874124.3618.31.camel@localhost.localdomain>
Message-ID: <1222882325.20834.5.camel@atropine.boston.devel.redhat.com>

On Wed, 2008-10-01 at 11:15 -0400, Tom "spot" Callaway wrote:
> On Wed, 2008-10-01 at 10:38 -0400, Adam Jackson wrote:
> 
> > Orthogonal to whether koji can or should let you do it, this came up in
> > the context of another discussion today.  I think what we'll end up
> > doing is something like:
> > 
> > Xvfb -displayfd 3 3>& /tmp/whatever
> > 
> > to give the server a way of both picking a free display number, and
> > communicating it back to the launching process.  Does that sound like
> > it'd work for you?
> 
> The xvfb-run helper I added to Xvfb in rawhide might also be useful for
> this purpose, depending on the number of things that need to launch.

That was actually the trigger for the "other discussion".  Kristian was
a bit miffed about adding a few thousand lines of shell to achieve what
ought to be done directly in the server in like twenty lines of C.

So, expect that script to go away.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/5a2f3194/attachment.sig>

From dbn.lists at gmail.com  Wed Oct  1 17:39:07 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Wed, 1 Oct 2008 10:39:07 -0700
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001172038.GG10632@phobos.i.cabal.ca>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
Message-ID: <91705d080810011039k16a3f9cfo873e325955033f09@mail.gmail.com>

On Wed, Oct 1, 2008 at 10:20 AM, Kyle McMartin <kyle at mcmartin.ca> wrote:
>
> Ah, I'm glad to see others working on this! I'd not seen the Mandriva
> efforts, but I should really poke at them as I'd turned modprobe into
> a library and started integrating it into udev.

By coincidence, I'd been thinking about doing the same thing the past
few days and kicking around how it might be accomplished. Do you have
any patches around? I'd like to help out if your progress is stalled.
It would be nice to just do the configuration parsing once.

--
Dan



From rdieter at math.unl.edu  Wed Oct  1 17:43:09 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 01 Oct 2008 12:43:09 -0500
Subject: orphaning: glib, gtk+
Message-ID: <gc0crd$v90$1@ger.gmane.org>

Don't have much personal interest glib/gtk+ anymore, so I'll let them go
free to a new loving home.

Mostly, I didn't have much incentive or energy to fix a recent FTBFS gtk+
bug,
http://bugzilla.redhat.com/465033

-- Rex



From mattg at assembly.state.ny.us  Wed Oct  1 17:39:14 2008
From: mattg at assembly.state.ny.us (Matt Garretson)
Date: Wed, 01 Oct 2008 13:39:14 -0400
Subject: Cambridge (F-10) Beta release announcement
In-Reply-To: <200809302243.05507.opensource@till.name>
References: <1222783934.3985.2.camel@luminos.localdomain>
	<200809302243.05507.opensource@till.name>
Message-ID: <gc0cks$ubt$1@ger.gmane.org>

Till Maas wrote:
> I am probably the only one trying to do this, but how can I verify the SHA1SUM 
> files for the i686 Live iso? I did not investigate it completely, but it 
> seems that it is only signed with some new key, that is not listed here:


You're not the only one!  I couldn't find the key ID (0B86274E for
Fedora-10-Beta-x86_64) in any key servers, or anywhere under
/etc/pki , either. 


-Matt



From fedora at matbooth.co.uk  Wed Oct  1 17:59:52 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Wed, 1 Oct 2008 18:59:52 +0100
Subject: Maintainer wanted for Eclipse Graphical Editing Framework (GEF
	... eclipse-gef)
In-Reply-To: <20081001163046.GB14391@redhat.com>
References: <20081001163046.GB14391@redhat.com>
Message-ID: <9497e9990810011059j23fb6237p635cf242d37c13aa@mail.gmail.com>

On Wed, Oct 1, 2008 at 5:30 PM, Andrew Overholt <overholt at redhat.com> wrote:
> Hi,
>
> Does anyone want to maintain GEF?  I don't have time for it and haven't
> updated it recently.  It needs to be updated to the latest (Ganymede
> train) release.  Nothing depends upon it so if no one wants it and we
> remove it it's probably not the end of the world.
>
> I've given up ownership in FAS so feel free to take it there if you want
> it.
>
> Andrew
>

I'd be willing to take this since I'd like to eventually get the Data
Tools into Fedora. This is one of the prerequisites.

Regards,
Mat

-- 
Mat Booth
www.matbooth.co.uk



From jakub at redhat.com  Wed Oct  1 18:27:10 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 1 Oct 2008 20:27:10 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001172038.GG10632@phobos.i.cabal.ca>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
Message-ID: <20081001182710.GB32682@tyan-ft48-01.lab.bos.redhat.com>

On Wed, Oct 01, 2008 at 01:20:38PM -0400, Kyle McMartin wrote:
> On Wed, Oct 01, 2008 at 06:52:15PM +0200, Jakub Jelinek wrote:
> > MAKEDEV sources almost 500KB of config files on every invocation, and the
> > inner loop is terribly inefficient.  The second patch allows it to shrink
> > the files to 55KB while expressing the same info and makes the inner loop
> > more efficient.  Depending on how many modprobe and MAKEDEV invocations
> > are done on your box during bootup, this can or might not make meassurable
> > difference.
> > 
> 
> Definitely. The biggest win by far for MAKEDEV is profiling the often
> hit devices, and prioritizing things. Dave Airlie moved a bunch of the
> cciss and other almost never-seen devices to be sourced last and ended
> up with a huge win.

If the ordering makes significant difference, then there is further work on
it.  My patch was mainly about speeding up the read_configs part, although
the more compact config files mean several times less entries as well.

makedevices then does a linear search through the entries.  What we could do
is put the entries into a hash table, hashed by the name_prefix_len bytes
long prefix, or skip the entries that don't match any command line
arguments.  I guess for many command line arguments the hash table could be
a win, for very few the skipping.  Even just separate chains for each
starting letter could cut the number of entries down a lot (only 3 letters
with more than 100 entries), though they aren't evenly distributed; just
computing a hash and using 256 buckets with chains would be probably enough
though.

> Have you tested things on a big endian machine?

I have not, can easily do that tomorrow on ppc64.  That said, the file
format has an endian 4byte word in the header to verify depmod and modprobe
agree on endianity, if they don't, the *cache files just aren't used and the
slower (still somewhat faster wrt. vanilla modprobe) reading of the text
config files is used, similarly to the case where used hand modifies them.

> really good. Hopefully Jon will apply this upstream soon so we can get
> it in F10.

That's where I don't have such high hopes, as I've mailed the patch to Jon
already more than 10 months ago.

	Jakub



From lesmikesell at gmail.com  Wed Oct  1 18:28:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 01 Oct 2008 13:28:34 -0500
Subject: unfrozen repo somewhere?
In-Reply-To: <200810011529.m91FSpBo004671@laptop14.inf.utfsm.cl>
References: <20080926091109.GF3149@free.fr>
	<1222425353.3564.248.camel@beck.corsepiu.local>
	<200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl>
	<1222651165.3564.314.camel@beck.corsepiu.local>
	<200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl>
	<25665.1222660262@sss.pgh.pa.us>
	<1222663773.3564.355.camel@beck.corsepiu.local>
	<200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl>
	<1222667193.3564.406.camel@beck.corsepiu.local>
	<200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl>
	<48E12763.6020200@gmail.com>
	<200809292257.m8TMvxJC016686@laptop14.inf.utfsm.cl>
	<48E166C4.10600@gmail.com>
	<200810011529.m91FSpBo004671@laptop14.inf.utfsm.cl>
Message-ID: <48E3C152.8070600@gmail.com>

Horst H. von Brand wrote:
> 
>> The big problem for me is that it's a package deal.  I wouldn't mind
>> beta testing a few apps at a time on my working system with a stable
>> OS and libraries, but to run them you also have to take an
>> experimental kernel and device drivers.  And my history with those on
>> fedora is that I waste too much time getting the hardware to work with
>> new versions. Maybe that's changed...   If you had a way to separate
>> the apps from the OS, you might find people more willing to test the
>> parts that interested them.
> 
> Many problems are integration problems, i.e., package version foo doesn't
> work with library version bar. It also happens that to run the very
> latest-and-greatest version of the package you need experimental(ish)
> versions of other stuff.

Hence my initial suggestion of a ready-to-run, fully integrated vmware 
image that anyone with a working mac, windows, or linux can fire up 
nondestructively with no install or prep work.

>> Kernels that don't boot on machines where the last version worked
> 
> Keep the next-to-last one around just in case. Have a LiveCD of the lastest
> stable/beta at hand for the case it gets too screwed up. Yes, it's a
> nuisance.

If you want lots of testers, make it not a nuisance, safe, and 
non-destructive.

>> But would you want to test a plane where the engineers said it was
>> probably good enough and didn't crash too often?
> 
> So you have never heard of plane crashes?

Yes, have you heard of simulators where you can do the preliminary 
testing without danger?  That's what vmware provides.

> Or other failures? In the end, as
> 100% perfect is not realistically doable, you have to make do with "good
> enough", and what /that/ means depends on the circumstances: The kernel of
> a game console (a crash means a minor inconvenience or at most a lost game)
> has /very/ different safety/security requirements than software controlling
> a radiation therapy aparatus (which could very well be lethal to the
> patient).

The circumstances are that vmware server/player is free, as is a timed 
demo of fusion for the mac.  A crash inside of vmware isn't even a minor 
inconvenience to the host.  And as fast as fedora betas change, it would 
probably take less bandwidth and certainly less user time to keep fully 
updated ready-to-run images available instead of making users download 
isos than need installation and then updates.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Wed Oct  1 18:42:47 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 01 Oct 2008 11:42:47 -0700
Subject: Cambridge (F-10) Beta release announcement
In-Reply-To: <200809302243.05507.opensource@till.name>
References: <1222783934.3985.2.camel@luminos.localdomain>
	<200809302243.05507.opensource@till.name>
Message-ID: <1222886567.6265.21.camel@luminos.localdomain>

On Tue, 2008-09-30 at 22:43 +0200, Till Maas wrote:
> I am probably the only one trying to do this, but how can I verify the SHA1SUM 
> files for the i686 Live iso? I did not investigate it completely, but it 
> seems that it is only signed with some new key, that is not listed here:
> https://fedoraproject.org/keys

That has been updated, thanks.

> 
> The os dir of a nearby mirror contains several gpg key files with different 
> sizes and names, that are also not mentioned in above webpage. 

Many of these are symlinks so that secondary arches can use our
fedora-release package but their own gpg key.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/ba516076/attachment.sig>

From kevin.kofler at chello.at  Wed Oct  1 18:49:30 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 1 Oct 2008 18:49:30 +0000 (UTC)
Subject: kdepim updates "pushed to stable" according to Bodhi,
	but tag not moved?
Message-ID: <loom.20081001T184622-51@post.gmane.org>

Hi,

Bodhi claims the following updates (submitted by me) have been pushed to 
stable:
kdepim-3.5.10-2.fc8
kdepim-3.5.10-2.fc9

Yet they are still in dist-f8-updates-candidate resp. dist-f9-updates-candidate 
and thus do not show up in the repo. So what's up with these? Aren't the tag 
moves supposed to happen _before_ Bodhi says the update got pushed?

        Kevin Kofler



From paul at all-the-johnsons.co.uk  Wed Oct  1 19:34:48 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 01 Oct 2008 20:34:48 +0100
Subject: Mono 2.0 RC3 for rawhide
Message-ID: <1222889688.7159.26.camel@PB3.Linux>

Hi,

I'm going to be building RC3 of Mono 2.0 for release tomorrow. It's not
broken anything big time here, but it's worth mentioning that I've
backported a few extra patches into RC3 which haven't made it to the RC3
release, but are due in 2.1 (I think that's due end of 2008/start of
2009).

Updated : libgdiplus, mono, mono-basic, xsp, mod_mono, monodoc,
mono-tools

Please let me know if it kills anything big style!

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/bfed0b58/attachment.sig>

From pertusus at free.fr  Wed Oct  1 19:43:29 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 1 Oct 2008 21:43:29 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <gc0crd$v90$1@ger.gmane.org>
References: <gc0crd$v90$1@ger.gmane.org>
Message-ID: <20081001194329.GA2775@free.fr>

On Wed, Oct 01, 2008 at 12:43:09PM -0500, Rex Dieter wrote:
> Don't have much personal interest glib/gtk+ anymore, so I'll let them go
> free to a new loving home.
> 
> Mostly, I didn't have much incentive or energy to fix a recent FTBFS gtk+
> bug,
> http://bugzilla.redhat.com/465033

You've already fixed it. I'll sign as co-maintainer, though.

--
Pat



From choeger at cs.tu-berlin.de  Wed Oct  1 19:53:41 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Wed, 01 Oct 2008 21:53:41 +0200
Subject: Bug in fedora 10 beta installer, but what package to file against?
Message-ID: <1222890821.20938.3.camel@choeger6>

Hi,

I'm currently trying to install fedora 10 beta on my f8 desktop. The
first bug I encountered was a file conflict between
system-config-firewall and system-config-firewall-tui which both want to
bring in system-config-firewall.mo. Clearly a bug, but who shall I
blame? system-config-firewall system-config-firewall-tui, anaconda or
even the new rpm? 

regards

christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/0e96a6bf/attachment.sig>

From rdieter at math.unl.edu  Wed Oct  1 19:54:55 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 01 Oct 2008 14:54:55 -0500
Subject: orphaning: glib, gtk+
References: <gc0crd$v90$1@ger.gmane.org> <20081001194329.GA2775@free.fr>
Message-ID: <gc0kif$uhc$1@ger.gmane.org>

Patrice Dumas wrote:

> On Wed, Oct 01, 2008 at 12:43:09PM -0500, Rex Dieter wrote:
>> Don't have much personal interest glib/gtk+ anymore, so I'll let them go
>> free to a new loving home.
>> 
>> Mostly, I didn't have much incentive or energy to fix a recent FTBFS gtk+
>> bug,
>> http://bugzilla.redhat.com/465033
> 
> You've already fixed it. I'll sign as co-maintainer, though.

it's still broken,
https://koji.fedoraproject.org/koji/buildinfo?buildID=64955

-- Rex




From bpepple at fedoraproject.org  Wed Oct  1 19:55:17 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 01 Oct 2008 15:55:17 -0400
Subject: FESCo Meeting Summary for 2008-10-01
Message-ID: <1222890917.30446.6.camel@kennedy>

=== Members Present ===
* Brian Pepple		(bpepple)
* Kevin Fenzi		(nirik)
* Bill Nottingham       (notting)
* Jon Stanley		(jds2001)
* Dennis Gilmore        (dgilmore)
* Josh Boyer		(jwb)
* David Woodhouse       (dwmw2)

=== Members Absent ===
* Karsten Hopp		(kick_)
* Jarod Wilson		(j-rod)

== Summary ==
=== Fedora Packaging Committee Guideline Proposals ===
* FESCo had no objections to the guideline proposals approved by the
FPC.
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02133.html

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-01.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/25c1a5ab/attachment.sig>

From rjones at redhat.com  Wed Oct  1 19:57:00 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 1 Oct 2008 20:57:00 +0100
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <1222871915.17250.2.camel@localhost.localdomain>
References: <20080930171332.GB12353@amd.home.annexia.org>
	<1222871915.17250.2.camel@localhost.localdomain>
Message-ID: <20081001195700.GA20463@amd.home.annexia.org>

On Wed, Oct 01, 2008 at 10:38:35AM -0400, Adam Jackson wrote:
> Orthogonal to whether koji can or should let you do it, this came up in
> the context of another discussion today.  I think what we'll end up
> doing is something like:
> 
> Xvfb -displayfd 3 3>& /tmp/whatever
> 
> to give the server a way of both picking a free display number, and
> communicating it back to the launching process.  Does that sound like
> it'd work for you?

Yes, really useful..

It's also worth noting that Debian ship something called Xvfb-run:

  http://www.penguin-soft.com/penguin/man/1/xvfb-run.html

  DESCRIPTION

  xvfb-run is a wrapper for the Xvfb (1x) command which simplifies the
  task of running commands (typically an X client, or a script
  containing a list of clients to be run) within a virtual X server
  environment.

  xvfb-run sets up an X authority file (or uses an existing
  user-specified one), writes a cookie to it (see xauth (1x)) and then
  starts the Xvfb X server as a background process. The process ID of
  Xvfb is stored for later use. The specified command is then run using
  the X display corresponding to the Xvfb server just started and the X
  authority file created earlier.

  When the command exits, its status is saved, the Xvfb server is killed
  (using the process ID stored earlier), the X authority cookie removed,
  and the authority file deleted (if the user did not specify one to
  use). xvfb-run then exits with the exit status of command .

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From pertusus at free.fr  Wed Oct  1 19:59:13 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 1 Oct 2008 21:59:13 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <gc0kif$uhc$1@ger.gmane.org>
References: <gc0crd$v90$1@ger.gmane.org> <20081001194329.GA2775@free.fr>
	<gc0kif$uhc$1@ger.gmane.org>
Message-ID: <20081001195913.GB2775@free.fr>

On Wed, Oct 01, 2008 at 02:54:55PM -0500, Rex Dieter wrote:
> Patrice Dumas wrote:
> 
> > On Wed, Oct 01, 2008 at 12:43:09PM -0500, Rex Dieter wrote:
> >> Don't have much personal interest glib/gtk+ anymore, so I'll let them go
> >> free to a new loving home.
> >> 
> >> Mostly, I didn't have much incentive or energy to fix a recent FTBFS gtk+
> >> bug,
> >> http://bugzilla.redhat.com/465033
> > 
> > You've already fixed it. I'll sign as co-maintainer, though.
> 
> it's still broken,
> https://koji.fedoraproject.org/koji/buildinfo?buildID=64955

Ok, I'll look at it.

--
Pat



From Jochen at herr-schmitt.de  Wed Oct  1 20:02:01 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 01 Oct 2008 22:02:01 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <gc0kif$uhc$1@ger.gmane.org>
References: <gc0crd$v90$1@ger.gmane.org> <20081001194329.GA2775@free.fr>
	<gc0kif$uhc$1@ger.gmane.org>
Message-ID: <48E3D739.9060809@herr-schmitt.de>

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

Rex Dieter schrieb:
> Patrice Dumas wrote:
>
>> On Wed, Oct 01, 2008 at 12:43:09PM -0500, Rex Dieter wrote:
>>> Don't have much personal interest glib/gtk+ anymore, so I'll let them go
>>> free to a new loving home.
>>>
>>> Mostly, I didn't have much incentive or energy to fix a recent FTBFS gtk+
>>> bug,
>>> http://bugzilla.redhat.com/465033
>> You've already fixed it. I'll sign as co-maintainer, though.
>
> it's still broken,
> https://koji.fedoraproject.org/koji/buildinfo?buildID=64955
Yes, it's very difficuilt. I have try to fix it, but I will got a
error message about
a missing AM_LC_MESSAGES macro. AFAIK this is a issue which is caused
by libstdc++.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjj1xsACgkQT2AHK6txfgx4PACg9G5FrVvyIYvRhjwU1EzgCsUO
vKYAoMxq0EDT8h8hpKkVqZZXAtCEohsT
=/8hj
-----END PGP SIGNATURE-----



From pertusus at free.fr  Wed Oct  1 20:08:02 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 1 Oct 2008 22:08:02 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <48E3D739.9060809@herr-schmitt.de>
References: <gc0crd$v90$1@ger.gmane.org> <20081001194329.GA2775@free.fr>
	<gc0kif$uhc$1@ger.gmane.org> <48E3D739.9060809@herr-schmitt.de>
Message-ID: <20081001200802.GD2775@free.fr>

On Wed, Oct 01, 2008 at 10:02:01PM +0200, Jochen Schmitt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Yes, it's very difficuilt. I have try to fix it, but I will got a
> error message about
> a missing AM_LC_MESSAGES macro. AFAIK this is a issue which is caused
> by libstdc++.

There is 
Invalid configuration `x86_64-redhat-linux-gnu': machine `x86_64-redhat'
not recognized
in the log, maybe it is also linked with the failure? It may be caused
by the use of a config.{guess,sub} that is too old.

--
Pat



From j.w.r.degoede at hhs.nl  Wed Oct  1 20:13:41 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 01 Oct 2008 22:13:41 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <20081001200802.GD2775@free.fr>
References: <gc0crd$v90$1@ger.gmane.org>
	<20081001194329.GA2775@free.fr>	<gc0kif$uhc$1@ger.gmane.org>
	<48E3D739.9060809@herr-schmitt.de> <20081001200802.GD2775@free.fr>
Message-ID: <48E3D9F5.2050709@hhs.nl>

Patrice Dumas wrote:
> On Wed, Oct 01, 2008 at 10:02:01PM +0200, Jochen Schmitt wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Yes, it's very difficuilt. I have try to fix it, but I will got a
>> error message about
>> a missing AM_LC_MESSAGES macro. AFAIK this is a issue which is caused
>> by libstdc++.
> 
> There is 
> Invalid configuration `x86_64-redhat-linux-gnu': machine `x86_64-redhat'
> not recognized
> in the log, maybe it is also linked with the failure? It may be caused
> by the use of a config.{guess,sub} that is too old.
> 

Ah that one, yes %configure is no longer replacing config.{guess,sub} with more 
recent copies from /var/lib/rpm as it used too, if you do that replacement 
manually things might just work.

Regards,

Hans



From pertusus at free.fr  Wed Oct  1 20:14:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 1 Oct 2008 22:14:36 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <48E3D9F5.2050709@hhs.nl>
References: <gc0crd$v90$1@ger.gmane.org> <20081001194329.GA2775@free.fr>
	<gc0kif$uhc$1@ger.gmane.org> <48E3D739.9060809@herr-schmitt.de>
	<20081001200802.GD2775@free.fr> <48E3D9F5.2050709@hhs.nl>
Message-ID: <20081001201436.GE2775@free.fr>

On Wed, Oct 01, 2008 at 10:13:41PM +0200, Hans de Goede wrote:
> Patrice Dumas wrote:
>> On Wed, Oct 01, 2008 at 10:02:01PM +0200, Jochen Schmitt wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Yes, it's very difficuilt. I have try to fix it, but I will got a
>>> error message about
>>> a missing AM_LC_MESSAGES macro. AFAIK this is a issue which is caused
>>> by libstdc++.
>>
>> There is Invalid configuration `x86_64-redhat-linux-gnu': machine 
>> `x86_64-redhat'
>> not recognized
>> in the log, maybe it is also linked with the failure? It may be caused
>> by the use of a config.{guess,sub} that is too old.
>>
>
> Ah that one, yes %configure is no longer replacing config.{guess,sub} 
> with more recent copies from /var/lib/rpm as it used too, if you do that 
> replacement manually things might just work.

I have launched a scratch build with that change, hoping that it will
solve the issue.

http://koji.fedoraproject.org/koji/taskinfo?taskID=855267
--
Pat



From metherid at gmail.com  Wed Oct  1 19:59:02 2008
From: metherid at gmail.com (Rahul Sundaram)
Date: Thu, 02 Oct 2008 01:29:02 +0530
Subject: Bug in fedora 10 beta installer,
	but what package to file against?
In-Reply-To: <1222890821.20938.3.camel@choeger6>
References: <1222890821.20938.3.camel@choeger6>
Message-ID: <48E3D686.4000103@gmail.com>

Christoph H?ger wrote:
> Hi,
>
> I'm currently trying to install fedora 10 beta on my f8 desktop. The
> first bug I encountered was a file conflict between
> system-config-firewall and system-config-firewall-tui which both want to
> bring in system-config-firewall.mo. Clearly a bug, but who shall I
> blame? system-config-firewall system-config-firewall-tui, anaconda or
> even the new rpm? 
>   
File it against s-c-firewall. Bugzilla only lists source components.

Rahul



From j.w.r.degoede at hhs.nl  Wed Oct  1 20:22:45 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 01 Oct 2008 22:22:45 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <20081001201436.GE2775@free.fr>
References: <gc0crd$v90$1@ger.gmane.org>
	<20081001194329.GA2775@free.fr>	<gc0kif$uhc$1@ger.gmane.org>
	<48E3D739.9060809@herr-schmitt.de>	<20081001200802.GD2775@free.fr>
	<48E3D9F5.2050709@hhs.nl> <20081001201436.GE2775@free.fr>
Message-ID: <48E3DC15.2090003@hhs.nl>

Patrice Dumas wrote:
> On Wed, Oct 01, 2008 at 10:13:41PM +0200, Hans de Goede wrote:
>> Patrice Dumas wrote:
>>> On Wed, Oct 01, 2008 at 10:02:01PM +0200, Jochen Schmitt wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Yes, it's very difficuilt. I have try to fix it, but I will got a
>>>> error message about
>>>> a missing AM_LC_MESSAGES macro. AFAIK this is a issue which is caused
>>>> by libstdc++.
>>> There is Invalid configuration `x86_64-redhat-linux-gnu': machine 
>>> `x86_64-redhat'
>>> not recognized
>>> in the log, maybe it is also linked with the failure? It may be caused
>>> by the use of a config.{guess,sub} that is too old.
>>>
>> Ah that one, yes %configure is no longer replacing config.{guess,sub} 
>> with more recent copies from /var/lib/rpm as it used too, if you do that 
>> replacement manually things might just work.
> 
> I have launched a scratch build with that change, hoping that it will
> solve the issue.
> 

Erm, crap that should ofcourse have read "from /usr/lib/rpm", I hope you got 
that right for your scratchbuild?

Regards,

Hans



From choeger at cs.tu-berlin.de  Wed Oct  1 20:32:11 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Wed, 01 Oct 2008 22:32:11 +0200
Subject: Bug in fedora 10 beta installer, but what package to file
	against?
In-Reply-To: <48E3D686.4000103@gmail.com>
References: <1222890821.20938.3.camel@choeger6> <48E3D686.4000103@gmail.com>
Message-ID: <1222893131.20938.5.camel@choeger6>

Strangely, that breaks f10-beta installation completely for me, but why
not for every one else?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/87068305/attachment.sig>

From tcallawa at redhat.com  Wed Oct  1 20:37:32 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 01 Oct 2008 16:37:32 -0400
Subject: Running Xvfb during a package build -- good idea?
In-Reply-To: <20081001195700.GA20463@amd.home.annexia.org>
References: <20080930171332.GB12353@amd.home.annexia.org>
	<1222871915.17250.2.camel@localhost.localdomain>
	<20081001195700.GA20463@amd.home.annexia.org>
Message-ID: <1222893452.3685.2.camel@localhost.localdomain>

On Wed, 2008-10-01 at 20:57 +0100, Richard W.M. Jones wrote:
> On Wed, Oct 01, 2008 at 10:38:35AM -0400, Adam Jackson wrote:
> > Orthogonal to whether koji can or should let you do it, this came up in
> > the context of another discussion today.  I think what we'll end up
> > doing is something like:
> > 
> > Xvfb -displayfd 3 3>& /tmp/whatever
> > 
> > to give the server a way of both picking a free display number, and
> > communicating it back to the launching process.  Does that sound like
> > it'd work for you?
> 
> Yes, really useful..
> 
> It's also worth noting that Debian ship something called Xvfb-run:

Yep. I added it to the Xvfb rawhide package yesterday, but as Adam
pointed out, krh is implementing that set of functionality in the Xvfb
server itself.

~spot



From denis at poolshark.org  Wed Oct  1 20:42:08 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 01 Oct 2008 22:42:08 +0200
Subject: F10 beta: live img boot vs installed boot
In-Reply-To: <1222860088.5978.2.camel@station1.example.com>
References: <48E34F8C.5000305@poolshark.org>
	<1222860088.5978.2.camel@station1.example.com>
Message-ID: <48E3E0A0.3070401@poolshark.org>

Deependra Singh Shekhawat wrote:
> Hi,
> 
> Can you see /var/log/boot.log somehow ?
> 
> Probably /var/log/boot.log and /var/log/messages will have more info.
> 
> I don't see any plymouth loading for me too either but it boots just
> fine. I somehow managed to install nvidia driver too but still no
> graphical boot. :)

My problem was a race condition in the initialization of the usb-storage 
module in the initrd image. After initrd loads usb-storage, it doesn't 
way enough for the usb disk to actuall appear, then root mount fails and 
everything dies horribly. Did anyone have success installing F10 beta 
onto a USB stick or external enclosure ?



From mschwendt at gmail.com  Wed Oct  1 20:44:41 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 1 Oct 2008 22:44:41 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <48E3D739.9060809@herr-schmitt.de>
References: <gc0crd$v90$1@ger.gmane.org> <20081001194329.GA2775@free.fr>
	<gc0kif$uhc$1@ger.gmane.org> <48E3D739.9060809@herr-schmitt.de>
Message-ID: <20081001224441.4a104edd.mschwendt@gmail.com>

On Wed, 01 Oct 2008 22:02:01 +0200, Jochen Schmitt wrote:

> Yes, it's very difficuilt. I have try to fix it, but I will got a
> error message about
> a missing AM_LC_MESSAGES macro. AFAIK this is a issue which is caused
> by libstdc++.

It's been renamed to gt_LC_MESSAGES (hint: gettext-devel).



From pertusus at free.fr  Wed Oct  1 20:24:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 1 Oct 2008 22:24:06 +0200
Subject: orphaning: glib, gtk+
In-Reply-To: <48E3DC15.2090003@hhs.nl>
References: <gc0crd$v90$1@ger.gmane.org> <20081001194329.GA2775@free.fr>
	<gc0kif$uhc$1@ger.gmane.org> <48E3D739.9060809@herr-schmitt.de>
	<20081001200802.GD2775@free.fr> <48E3D9F5.2050709@hhs.nl>
	<20081001201436.GE2775@free.fr> <48E3DC15.2090003@hhs.nl>
Message-ID: <20081001202406.GF2775@free.fr>

On Wed, Oct 01, 2008 at 10:22:45PM +0200, Hans de Goede wrote:
> Patrice Dumas wrote:
>> On Wed, Oct 01, 2008 at 10:13:41PM +0200, Hans de Goede wrote:
>>> Patrice Dumas wrote:
>>>> On Wed, Oct 01, 2008 at 10:02:01PM +0200, Jochen Schmitt wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Yes, it's very difficuilt. I have try to fix it, but I will got a
>>>>> error message about
>>>>> a missing AM_LC_MESSAGES macro. AFAIK this is a issue which is caused
>>>>> by libstdc++.
>>>> There is Invalid configuration `x86_64-redhat-linux-gnu': machine  
>>>> `x86_64-redhat'
>>>> not recognized
>>>> in the log, maybe it is also linked with the failure? It may be caused
>>>> by the use of a config.{guess,sub} that is too old.
>>>>
>>> Ah that one, yes %configure is no longer replacing config.{guess,sub} 
>>> with more recent copies from /var/lib/rpm as it used too, if you do 
>>> that replacement manually things might just work.
>>
>> I have launched a scratch build with that change, hoping that it will
>> solve the issue.
>>
>
> Erm, crap that should ofcourse have read "from /usr/lib/rpm", I hope you 
> got that right for your scratchbuild?

I used a snipet from another package I own that had the same issue, so
no problem. The build succeeded, I'll launch a normal rebuild in koji.

--
Pat



From nathanael at gnat.ca  Wed Oct  1 21:56:19 2008
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Wed, 1 Oct 2008 15:56:19 -0600
Subject: F10 Live CD possible bug
Message-ID: <5F66C9D7-C19A-47F4-8783-F7E29992310B@gnat.ca>

Hello,
   I downloaded the live cd of F10 beta. Booted and added the live_ram  
option to the boot params. After copying the image to RAM I get the  
following error on two machines, (Apple Mac Book, and Acer 3680).

Done copying live image to RAM.
eject: did not find a device /dev/root in /sys/block
Bug in initramfs /init detected. Dropping to a shell. Good luck!

sbin/real-init: line 7: plymouth: command not found

I know I used that param for F9. Is it depreciated or is this a bug  
needing filling?

-- 
Nathanael d. Noblet



From csnook at redhat.com  Wed Oct  1 22:08:41 2008
From: csnook at redhat.com (Chris Snook)
Date: Wed, 01 Oct 2008 18:08:41 -0400
Subject: F10 Live CD possible bug
In-Reply-To: <5F66C9D7-C19A-47F4-8783-F7E29992310B@gnat.ca>
References: <5F66C9D7-C19A-47F4-8783-F7E29992310B@gnat.ca>
Message-ID: <48E3F4E9.6000805@redhat.com>

Nathanael Noblet wrote:
> Hello,
>   I downloaded the live cd of F10 beta. Booted and added the live_ram 
> option to the boot params. After copying the image to RAM I get the 
> following error on two machines, (Apple Mac Book, and Acer 3680).
> 
> Done copying live image to RAM.
> eject: did not find a device /dev/root in /sys/block
> Bug in initramfs /init detected. Dropping to a shell. Good luck!
> 
> sbin/real-init: line 7: plymouth: command not found
> 
> I know I used that param for F9. Is it depreciated or is this a bug 
> needing filling?

Assuming it does something different when you omit the option, that's a bug.  If 
we don't intend for it to work in F10, the option should be removed entirely, 
and ignored if passed by the user.

-- Chris



From opensource at till.name  Wed Oct  1 22:16:44 2008
From: opensource at till.name (Till Maas)
Date: Thu, 02 Oct 2008 00:16:44 +0200
Subject: Cambridge (F-10) Beta release announcement
In-Reply-To: <1222886567.6265.21.camel@luminos.localdomain>
References: <1222783934.3985.2.camel@luminos.localdomain>
	<200809302243.05507.opensource@till.name>
	<1222886567.6265.21.camel@luminos.localdomain>
Message-ID: <200810020017.00424.opensource@till.name>

On Wed October 1 2008, Jesse Keating wrote:
> On Tue, 2008-09-30 at 22:43 +0200, Till Maas wrote:
> > I am probably the only one trying to do this, but how can I verify the
> > SHA1SUM files for the i686 Live iso? I did not investigate it completely,
> > but it seems that it is only signed with some new key, that is not listed
> > here: https://fedoraproject.org/keys
>
> That has been updated, thanks.
>
> > The os dir of a nearby mirror contains several gpg key files with
> > different sizes and names, that are also not mentioned in above webpage.
>
> Many of these are symlinks so that secondary arches can use our
> fedora-release package but their own gpg key.

There are also some fingerprints of the gpg keys at:
https://admin.fedoraproject.org/fingerprints

Can you please sync them too?

Also these keys are install without the "-primary" suffix from 
fedora-release-8-6.transition, but mentioned with the "-primary" suffix on 
the keys page:

RPM-GPG-KEY-fedora-8-and-9-primary
RPM-GPG-KEY-fedora-test-8-and-9-primary

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/20081002/9debdc0e/attachment.sig>

From nathanael at gnat.ca  Wed Oct  1 22:49:33 2008
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Wed, 1 Oct 2008 16:49:33 -0600
Subject: F10 Live CD possible bug
In-Reply-To: <48E3F4E9.6000805@redhat.com>
References: <5F66C9D7-C19A-47F4-8783-F7E29992310B@gnat.ca>
	<48E3F4E9.6000805@redhat.com>
Message-ID: <4F549021-DD11-4A51-8F43-CA3C3F263CE2@gnat.ca>


On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:

> Nathanael Noblet wrote:
>> Hello,
>>  I downloaded the live cd of F10 beta. Booted and added the  
>> live_ram option to the boot params. After copying the image to RAM  
>> I get the following error on two machines, (Apple Mac Book, and  
>> Acer 3680).
>> Done copying live image to RAM.
>> eject: did not find a device /dev/root in /sys/block
>> Bug in initramfs /init detected. Dropping to a shell. Good luck!
>> sbin/real-init: line 7: plymouth: command not found
>> I know I used that param for F9. Is it depreciated or is this a bug  
>> needing filling?
>
> Assuming it does something different when you omit the option,  
> that's a bug.  If we don't intend for it to work in F10, the option  
> should be removed entirely, and ignored if passed by the user.
>

Yeah if you remove the live_ram from the boot options. It boots...


Is there a rationale for removing the option? It came in super useful  
for me a month or so back. I can't remember the exact issue but saved  
the day for me when I finally found it.



From tmz at pobox.com  Wed Oct  1 22:51:28 2008
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 1 Oct 2008 18:51:28 -0400
Subject: Cambridge (F-10) Beta release announcement
In-Reply-To: <200810020017.00424.opensource@till.name>
References: <1222783934.3985.2.camel@luminos.localdomain>
	<200809302243.05507.opensource@till.name>
	<1222886567.6265.21.camel@luminos.localdomain>
	<200810020017.00424.opensource@till.name>
Message-ID: <20081001225128.GA10172@inocybe.teonanacatl.org>

Till Maas wrote:
> There are also some fingerprints of the gpg keys at:
> https://admin.fedoraproject.org/fingerprints
> 
> Can you please sync them too?

https://fedorahosted.org/fedora-infrastructure/ticket/814

I think that page should just direct folks to /keys for the gpg key
info rather than keeping it in two places (or both pages should
include the same source so the data only ever needs to be updated in
one place).

I don't know where the source is kept for /fingerprints or I'd have
submitted a patch to at least sync them when I filed the trac ticket a
few weeks ago.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If everything seems to be going well, you have obviously overlooked
something.

-------------- 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/20081001/1978b270/attachment.sig>

From jmtaylor90 at gmail.com  Wed Oct  1 23:01:18 2008
From: jmtaylor90 at gmail.com (Jason Taylor)
Date: Wed, 01 Oct 2008 19:01:18 -0400
Subject: Fedora 10 Release Notes
Message-ID: <1222902078.3251.21.camel@bruiser.localdomain>

Greetings,

The Fedora 10 launch is right around the corner and we over at the Docs
Project need a hand with some of your beats[1] for the F10 release
notes.  A beat[2] is covering a part of the distro, such as GUI office
productivity apps, the kernel, or developer tools.

[1] https://fedoraproject.org/wiki/Docs/Beats#Beat_Assignments

We are looking to fedora-devel-list as we figure you all know the most
about the F10 packages and F10 feature(s) functionality. The beats
marked with an "Open" are the ones we need help with, either with
content contributions or owning the beat. You can put your name in for
the beat on the wiki, or reply to this email, to fedora-docs-list, or
catch one of the folks in #fedora-docs with what you want to help with.

Many thanks from the Docs folks.

[2] https://fedoraproject.org/wiki/Docs/Beats/HowTo

-Jason Taylor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/7d2774de/attachment.sig>

From jkeating at redhat.com  Wed Oct  1 23:54:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 01 Oct 2008 16:54:12 -0700
Subject: Post-beta bugfix phase
Message-ID: <1222905252.6265.43.camel@luminos.localdomain>

We're now entering our post-beta phase of Fedora 10 development.  It is
during this time that Feature development should be done with, and
concentration should be put on bugfixing and polish.  As the reports
roll in from our Beta testers, please keep a mind toward stability with
the changes you introduce to the Fedora tree.  We now allow for early
branching of your packages so that you can keep the Fedora 10 changes to
a minimal and continue development of future software.

After this week we will be doing weekly snapshot attempts of the
distribution every Thursday/Friday.  These will be in the form of Live
images as well as traditional install images, when possible.  Due to the
amount of churn and the speed at which we need to make these available,
they will likely only be available via bittorrent, although I will be
looking into some limited mirror access.  Targetting these snapshots for
broader testing is a good idea, as it gives our users something to look
forward to and test more seriously than the day to day rawhide, and it
gives developers a good target.

Lets all work together and bring Fedora 10 forward, making it a great
release.

Some important upcoming dates.

Fri 2008-10-10: Documentation String Freeze
Mon 2008-10-20: Documentation Translation Deadline (PO Files complete)

Tue 2008-10-28: Final Development Freeze

Thanks!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/7bcfe608/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 jkeating at redhat.com  Wed Oct  1 23:45:56 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 01 Oct 2008 16:45:56 -0700
Subject: Fedora 10 early branch now available.
Message-ID: <1222904756.6265.34.camel@luminos.localdomain>

For those of you that wish to separate Fedora 10 stabalization work from
future development, we are now ready to process branch requests for
F-10.

If you branch your package early, builds from your new F-10 branch will
continue to go to the Fedora 10 targets.  dist-f10 for now, and
eventually dist-f10-updates-candidate.  Builds from devel/ will be sent
to dist-f11 and will be held for the Fedora 11 rawhide once we get
Fedora 10 out the door.

To request a branch, please continue to use the cvsadmin request method:
https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/1af7b04d/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 bernie at codewiz.org  Thu Oct  2 03:06:30 2008
From: bernie at codewiz.org (Bernie Innocenti)
Date: Thu, 02 Oct 2008 05:06:30 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001172038.GG10632@phobos.i.cabal.ca>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
Message-ID: <48E43AB6.9000607@codewiz.org>

Kyle McMartin wrote:
> Ah, I'm glad to see others working on this! I'd not seen the Mandriva
> efforts, but I should really poke at them as I'd turned modprobe into
> a library and started integrating it into udev.

What an un-unixish design!

One could achieve the same performance with a trivial change that would 
keep modprobe and udev independent and simple:

   cat | modprobe --stdin
   radeon
   drm
   foo
   FATAL: Module foo not found.
   e1000
   ^D

Well, you get the idea... :-)

-- 
    \___/  Bernie Innocenti - http://www.codewiz.org/
   _| X |  Sugar Labs Team  - http://www.sugarlabs.org/
   \|_O_|  "It's an education project, not a laptop project!"



From davehoz at gmail.com  Thu Oct  2 03:14:52 2008
From: davehoz at gmail.com (David Hunter)
Date: Thu, 2 Oct 2008 13:14:52 +1000
Subject: Post-beta bugfix phase
In-Reply-To: <1222905252.6265.43.camel@luminos.localdomain>
References: <1222905252.6265.43.camel@luminos.localdomain>
Message-ID: <6bb886180810012014q40ad878bv957f018714efa3@mail.gmail.com>

GNOME desktop effects is broken on my system.

2008/10/2 Jesse Keating <jkeating at redhat.com>

> We're now entering our post-beta phase of Fedora 10 development.  It is
> during this time that Feature development should be done with, and
> concentration should be put on bugfixing and polish.  As the reports
> roll in from our Beta testers, please keep a mind toward stability with
> the changes you introduce to the Fedora tree.  We now allow for early
> branching of your packages so that you can keep the Fedora 10 changes to
> a minimal and continue development of future software.
>
> After this week we will be doing weekly snapshot attempts of the
> distribution every Thursday/Friday.  These will be in the form of Live
> images as well as traditional install images, when possible.  Due to the
> amount of churn and the speed at which we need to make these available,
> they will likely only be available via bittorrent, although I will be
> looking into some limited mirror access.  Targetting these snapshots for
> broader testing is a good idea, as it gives our users something to look
> forward to and test more seriously than the day to day rawhide, and it
> gives developers a good target.
>
> Lets all work together and bring Fedora 10 forward, making it a great
> release.
>
> Some important upcoming dates.
>
> Fri 2008-10-10: Documentation String Freeze
> Mon 2008-10-20: Documentation Translation Deadline (PO Files complete)
>
> Tue 2008-10-28: Final Development Freeze
>
> Thanks!
>
> --
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
>
> _______________________________________________
> Fedora-devel-announce mailing list
> Fedora-devel-announce at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-announce
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
David Hunter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081002/9fca09f1/attachment.htm>

From poelstra at redhat.com  Thu Oct  2 04:06:24 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 01 Oct 2008 21:06:24 -0700
Subject: Fedora Release Engineering Meeting Recap 2008-09-29
Message-ID: <48E448C0.1010509@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-sep-29

Please make corrections and clarifications to the wiki page.

== Fedora 10 Beta ==
* Good to go for beta on 2008-09-30
* Export control submitted

== Signing Server ==
* gnupg smartcards have arrived
* need to put specs on wiki

== IRC Transcript ==



From poelstra at redhat.com  Thu Oct  2 04:27:16 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 01 Oct 2008 21:27:16 -0700
Subject: Fedora Spins Process Meeting 2008-10-01
Message-ID: <48E44DA4.7060202@redhat.com>

2008-10-01
Fedora Spins Process Meeting

Attendees: Mo Duffy (mizmo), Bryan Kearney (bkearney) , Jeroen van 
Meeuwen (kanarip), John Poelstra (poelcat), Jesse Keating (f13), Paul 
Frields (stickster)

* Everyone was connected to a public gobby session and contributed to 
the minutes

== Background ==

https://fedoraproject.org/wiki/Image:Spins-developers-workflow2.png
https://fedoraproject.org/wiki/Websites/Spins <= main wiki page (for 
diagrams 'n stuffs)
https://fedoraproject.org/wiki/Websites/Spins/Mockups <= mockup
https://fedoraproject.org/wiki/Image:Spinsfpo-sitemap.png
http://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess ("former" 
spins process)
https://fedoraproject.org/wiki/User:Bkearney/ProposedSpinProcess 
(proposed process)
http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=tree;h=04a876635ff4608f7dc0b9d5780a840f16c4d604;hb=04a876635ff4608f7dc0b9d5780a840f16c4d604
http://spinner.fedoraunity.org/revisor/ (automated "daily" spin creation 
no cronjob, started manually)
https://fedoraproject.org/wiki/QA/ReleaseCriteria (spins must meet for 
release)


== Meeting Goals ==
1) Know what spins are we composing for Fedora 10
   BrOffice
   Education-Math
   XFCE
   Developer
   Electronic-Lab
   Games
   AOS
   (Desktop and KDE are part of the main release, not spins)

2) Set forth process to make Fedora 11 run smoothly


== Unanswered Questions (so far) ==
1) How will we track the workflow?
    a) custom built tool?
    b) wiki pages?

2) How will we track board approval?

3) How will we track trademark approval?

4) Can we create "daily spins"?
    a) How often should they be downloadable?
    b) How often would people really download them?

5) Can comps.xml be modified for a spin?

6) What flags (checkpoints? approvals?) do we want?
  (Requires FESCO document technical requirements and delegate to SPIN Sig \
  Board and FESCo does not have technical review)
  Spin sig approval
  Trademark approval
  releng capacity

7) Where have clearly described and explained exactly what a "spin" is?
   --can this be done? or is it too complicated?

== Releng Process ==
o Releng will try at Alpha, and Beta--if building spin fails twice, 
release engineering will stop trying to build
o Weekly snapshots can be made for torrents, along with weekly snapshots 
of other release material.

== Daily Spins ==
o ISOs are not "rsync friendly"
o Spins can be attempted daily, output from the tool and size will be 
listed.

== Next Actions ==
1) Jesse looking at kanarip's scripts to build daily spins
2) Kanarip to better document on the wiki "what a spin is"
3)Jon Stanley to collect a list of technical requirements and work with 
kanarip to add to a wiki page



From kwhiskerz at gmail.com  Thu Oct  2 04:30:27 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Wed, 1 Oct 2008 22:30:27 -0600
Subject: No X in F10 beta, rawhide...
Message-ID: <200810012230.27292.kwhiskerz@gmail.com>

I had installed F10 alpha on both of my computers and have been using it for a 
while. All has been very good and I am very pleased with it.

This Wednesday morning I yum updated both systems. I noticed that there was a 
new X server, version 1.5.1-4 among the many 100s of MB of downloads. Sadly, 
there was an absence of the new Intel drivers that will enable the use of i915 
modesetting with this great new X server. Oh well, it will come when it's 
ready.

This evening, I booted my desktop computer and the computer locked up at the 
point where plymouth ends and the X server starts to log in, via kdm. I could 
not even change to another virtual terminal. There was nothing I could do but 
Alt-SysRq.

I tried many times, using a slew of kernel options, like removing rhgb, 
appending vga=0x318, using nomodeset and enforcing=0. All variations failed. 
There was no way I could boot into X.

Then I tired the other computer. The same story. No X. Just a dark grey 
screen.

I tried switching to gdm. I tried reverting to X server 1..5.1-2, which worked 
just fine last night and this morning. I tried using the previous kernel. I 
tried using a full xorg.conf instead of the minimal xorg.conf that has been 
recommended recently (and worked great on both computers). I tried no 
xorg.conf at all. Still no X.

The problem appears not to be selinux, the usual culprit, nor the new kernel, 
nor the most recent X server. It is something else in this morning's spate of 
updates.

I can telinit 3, but not startx. What to do?

(The only way I am even able to write this message at all is that I still have 
Fedora 9 on a spare partition on the desktop computer. The laptop is now 
useless.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081001/0bf1e94e/attachment.htm>

From sflaniga at redhat.com  Thu Oct  2 04:55:49 2008
From: sflaniga at redhat.com (Sean Flanigan)
Date: Thu, 02 Oct 2008 14:55:49 +1000
Subject: Pseudo-locales for i18n testing by English speakers
Message-ID: <48E45455.7000203@redhat.com>

(Apologies for the double post on fedora-i18n-list, but I want to keep
the thread together.  Please reply to this message, not the first one.)

G'day all,

I think we should make use of pseudo-locales to test Fedora.

[--- I ????? ?? ?????? ???? ??? ?? ??????-??????? ?? ???? F?????.
  ---]

(In case UTF-8 doesn't make it to everyone's mail client intact, the
above sentence should like similar to the first one, except that the
lower case characters have been replaced by other similar-looking
Unicode characters.  A couple of the characters don't fit into 16 bits,
and really gave my text editors some trouble!)

See http://en.wikipedia.org/wiki/Pseudo-translation and
http://blogs.msdn.com/shawnste/archive/2006/06/27/647915.aspx for more
about pseudo-locales.  Microsoft actually used three different
pseudo-locales to test Vista, with things like reverse sorting,
right-to-left characters, and large character sets.

To me, the main advantages of pseudo-localisation are the ability to
test some aspects of i18n without having to wait for translations to be
turned around, and allowing English-only speakers to test i18n areas,
which is otherwise extremely difficult.

I have a simple Ant task which can generate pseudo-translations like the
one above from a gettext POT files, but I'm not suggesting that we
should integrate my humble Ant task into the makefiles of thousands of
Fedora packages. If the gettext runtime code that fetches translations
from .mo files (in glibc?) were to recognise a pseudo-locale id, it
could generate pseudo-translations on the fly from the English text.

Admittedly, there's a little more to it than simple character
substitution.  The pseudo-translator has to avoid changing things like
variable names and html tags, but a few rules (eg don't modify anything
between angle/square/curly brackets, don't touch %d/%s/etc) would cover
95% of cases.  In the other cases, you might mess up some HTML or fail
to expand a variable, but only users who choose to use a pseudo-locale
would ever see these problems.

Would there be any interest in getting something like this into glibc?

[--- S??? ---]


PS this could make sense for the OpenJDK too, but that's another story.
-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

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

From fedoraproject at cyberpear.com  Thu Oct  2 04:56:42 2008
From: fedoraproject at cyberpear.com (James Cassell)
Date: Thu, 02 Oct 2008 00:56:42 -0400
Subject: No X in F10 beta, rawhide...
In-Reply-To: <200810012230.27292.kwhiskerz@gmail.com>
References: <200810012230.27292.kwhiskerz@gmail.com>
Message-ID: <op.uidr0slg4bfjir@cassej2t61>

On Thu, 02 Oct 2008 00:30:27 -0400, kwhiskerz <kwhiskerz at gmail.com> wrote:

>
> This evening, I booted my desktop computer and the computer locked up at  
> the point where plymouth ends and the X server starts to log in, via  
> kdm. I could not even change to another virtual terminal.

I had this problem today as well.  My solution was to boot to runlevel 3  
and download the latest stuff directly from koji (which I guess will be in  
rawhide tomorrow), and it worked fine after that.  I don't know which of  
the updates I grabbed from koji fixed it, as I just grabbed all of them.

-- 
James Cassell



From ascii79 at gmail.com  Thu Oct  2 05:00:31 2008
From: ascii79 at gmail.com (Sachin)
Date: Thu, 2 Oct 2008 00:00:31 -0500
Subject: No X in F10 beta, rawhide...
In-Reply-To: <op.uidr0slg4bfjir@cassej2t61>
References: <200810012230.27292.kwhiskerz@gmail.com>
	<op.uidr0slg4bfjir@cassej2t61>
Message-ID: <a3c040240810012200q2bbbd399k1f5381994a93d435@mail.gmail.com>

for me this worked.

http://koji.fedoraproject.org/koji/buildinfo?buildID=64880

It was broken because of the libdrm

On Wed, Oct 1, 2008 at 11:56 PM, James Cassell
<fedoraproject at cyberpear.com>wrote:

> On Thu, 02 Oct 2008 00:30:27 -0400, kwhiskerz <kwhiskerz at gmail.com> wrote:
>
>
>> This evening, I booted my desktop computer and the computer locked up at
>> the point where plymouth ends and the X server starts to log in, via kdm. I
>> could not even change to another virtual terminal.
>>
>
> I had this problem today as well.  My solution was to boot to runlevel 3
> and download the latest stuff directly from koji (which I guess will be in
> rawhide tomorrow), and it worked fine after that.  I don't know which of the
> updates I grabbed from koji fixed it, as I just grabbed all of them.
>
> --
> James Cassell
>
> --
> 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/20081002/a22e7009/attachment.htm>

From fedoraproject at cyberpear.com  Thu Oct  2 04:56:42 2008
From: fedoraproject at cyberpear.com (James Cassell)
Date: Thu, 02 Oct 2008 00:56:42 -0400
Subject: No X in F10 beta, rawhide...
In-Reply-To: <200810012230.27292.kwhiskerz@gmail.com>
References: <200810012230.27292.kwhiskerz@gmail.com>
Message-ID: <op.uidr0slg4bfjir@cassej2t61>

On Thu, 02 Oct 2008 00:30:27 -0400, kwhiskerz <kwhiskerz at gmail.com> wrote:

>
> This evening, I booted my desktop computer and the computer locked up at  
> the point where plymouth ends and the X server starts to log in, via  
> kdm. I could not even change to another virtual terminal.

I had this problem today as well.  My solution was to boot to runlevel 3  
and download the latest stuff directly from koji (which I guess will be in  
rawhide tomorrow), and it worked fine after that.  I don't know which of  
the updates I grabbed from koji fixed it, as I just grabbed all of them.

-- 
James Cassell



From airlied at redhat.com  Thu Oct  2 06:11:44 2008
From: airlied at redhat.com (Dave Airlie)
Date: Thu, 02 Oct 2008 16:11:44 +1000
Subject: No X in F10 beta, rawhide...
In-Reply-To: <200810012230.27292.kwhiskerz@gmail.com>
References: <200810012230.27292.kwhiskerz@gmail.com>
Message-ID: <1222927905.3380.11.camel@clockmaker.usersys.redhat.com>

On Wed, 2008-10-01 at 22:30 -0600, kwhiskerz wrote:
> I had installed F10 alpha on both of my computers and have been using
> it for a while. All has been very good and I am very pleased with it.
> 
> This Wednesday morning I yum updated both systems. I noticed that
> there was a new X server, version 1.5.1-4 among the many 100s of MB of
> downloads. Sadly, there was an absence of the new Intel drivers that
> will enable the use of i915 modesetting with this great new X server.
> Oh well, it will come when it's ready.
> 
> This evening, I booted my desktop computer and the computer locked up
> at the point where plymouth ends and the X server starts to log in,
> via kdm. I could not even change to another virtual terminal. There
> was nothing I could do but Alt-SysRq.
> 
> I tried many times, using a slew of kernel options, like removing
> rhgb, appending vga=0x318, using nomodeset and enforcing=0. All
> variations failed. There was no way I could boot into X.
> 
> Then I tired the other computer. The same story. No X. Just a dark
> grey screen.
> 
> I tried switching to gdm. I tried reverting to X server 1..5.1-2,
> which worked just fine last night and this morning. I tried using the
> previous kernel. I tried using a full xorg.conf instead of the minimal
> xorg.conf that has been recommended recently (and worked great on both
> computers). I tried no xorg.conf at all. Still no X.
> 
> The problem appears not to be selinux, the usual culprit, nor the new
> kernel, nor the most recent X server. It is something else in this
> morning's spate of updates.
> 
> I can telinit 3, but not startx. What to do?
> 
> (The only way I am even able to write this message at all is that I
> still have Fedora 9 on a spare partition on the desktop computer. The
> laptop is now useless.)

You need to get the newest intel driver from koji or wait until rawhide
catches up.

I got caught by the rawhide compose happening between a libdrm and intel
driver update.

I think I needed more conflicts/requires.

Dave.




From dchen at redhat.com  Thu Oct  2 06:41:10 2008
From: dchen at redhat.com (Ding-Yi Chen)
Date: Thu, 02 Oct 2008 16:41:10 +1000
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E45455.7000203@redhat.com>
References: <48E45455.7000203@redhat.com>
Message-ID: <1222929670.4697.31.camel@localhost.localdomain>

The pseudo locale is intriguing, and I assume it helps at some degree.
However, this approach does have its own limitation:

1. Lack of font support: as the attachment "lack_of_font.png" shows, the
pseudo locale might be rendered useless if all developers can see are
unicode boxes. :-P Perhaps we should specifiy the minimal font set as
remedy.

2. It doesn't really solve the language specific problem. Take Chinese
characters sorting for example, they can be sorted by
Pinyin, Zhuyin, radical, number of strokes, and "natural" order such as
numberial characters. The sorting is impossible to verify without the
knowledge.

Still, the idea itself is good. And surely it filters out some of the
bugs without the help of translaters.

Since the main purpose of pseudo locale is for testing, shall we agree
on a list of pseudo locales which have their own specified behaviour?

Regards,
Ding-Yi Chen


? ??2008-10-02 ? 14:55 +1000?Sean Flanigan ???
> (Apologies for the double post on fedora-i18n-list, but I want to keep
> the thread together.  Please reply to this message, not the first one.)
> 
> G'day all,
> 
> I think we should make use of pseudo-locales to test Fedora.
> 
> [--- I ????? ?? ?????? ???? ??? ?? ??????-??????? ?? ???? F?????.
>   ---]
> 
> (In case UTF-8 doesn't make it to everyone's mail client intact, the
> above sentence should like similar to the first one, except that the
> lower case characters have been replaced by other similar-looking
> Unicode characters.  A couple of the characters don't fit into 16 bits,
> and really gave my text editors some trouble!)
> 
> See http://en.wikipedia.org/wiki/Pseudo-translation and
> http://blogs.msdn.com/shawnste/archive/2006/06/27/647915.aspx for more
> about pseudo-locales.  Microsoft actually used three different
> pseudo-locales to test Vista, with things like reverse sorting,
> right-to-left characters, and large character sets.
> 
> To me, the main advantages of pseudo-localisation are the ability to
> test some aspects of i18n without having to wait for translations to be
> turned around, and allowing English-only speakers to test i18n areas,
> which is otherwise extremely difficult.
> 
> I have a simple Ant task which can generate pseudo-translations like the
> one above from a gettext POT files, but I'm not suggesting that we
> should integrate my humble Ant task into the makefiles of thousands of
> Fedora packages. If the gettext runtime code that fetches translations
> from .mo files (in glibc?) were to recognise a pseudo-locale id, it
> could generate pseudo-translations on the fly from the English text.
> 
> Admittedly, there's a little more to it than simple character
> substitution.  The pseudo-translator has to avoid changing things like
> variable names and html tags, but a few rules (eg don't modify anything
> between angle/square/curly brackets, don't touch %d/%s/etc) would cover
> 95% of cases.  In the other cases, you might mess up some HTML or fail
> to expand a variable, but only users who choose to use a pseudo-locale
> would ever see these problems.
> 
> Would there be any interest in getting something like this into glibc?
> 
> [--- S??? ---]
> 
> 
> PS this could make sense for the OpenJDK too, but that's another story.
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lack_of_font.png
Type: image/png
Size: 31853 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081002/abb589e7/attachment.png>

From sflaniga at redhat.com  Thu Oct  2 08:01:55 2008
From: sflaniga at redhat.com (Sean Flanigan)
Date: Thu, 02 Oct 2008 18:01:55 +1000
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <1222929670.4697.31.camel@localhost.localdomain>
References: <48E45455.7000203@redhat.com>
	<1222929670.4697.31.camel@localhost.localdomain>
Message-ID: <48E47FF3.5060600@redhat.com>

Ding-Yi Chen wrote:
> The pseudo locale is intriguing, and I assume it helps at some degree.
> However, this approach does have its own limitation:

Of course, pseudo-localisation testing is not the same as localisation
testing in every Fedora language, but it's something!

> 1. Lack of font support: as the attachment "lack_of_font.png" shows, the
> pseudo locale might be rendered useless if all developers can see are
> unicode boxes. :-P 

That tells me that the developers should install better fonts, or how
else can they test an internationalised application?  But to be honest,
I probably shouldn't have used
http://en.wikipedia.org/wiki/Mathematical_alphanumeric_symbols since
they're only guaranteed to be available in certain mathematical fonts
such as Code2001.  I really need to find some latinesque characters that
don't come from the BMP, nor from the maths section!

Apparently Zimbra loses (without trace) the 'e' characters in my
pseudotranslation.  Bad Zimbra!

As long as it's only a couple of characters, I think having some unusual
characters is okay, since you can still work out what's going on, at
least enough to resolve the problem by installing more fonts.

> Perhaps we should specifiy the minimal font set as
> remedy.

Before running pseudo-localised apps, you mean?  Good idea.  I found a
webapp that gives the names of unicode characters -
<http://rishida.net/scripts/uniview/uniview.php>.  Just paste text into
the "cut & paste" field and hit enter.

But how can I find the name of the font which provides a given
character?  I can tell you that all my pseudo-characters are readable on
my computer, but I can't tell you where they come from.

Once I work out what fonts my pseudo-locale requires, I'd be happy to
share the info as a dependency list.

Perhaps it would make sense to define a small Fedora package which
specified certain Unicode fonts as dependencies, as well as enabling the
hypothetical pseudo-locale support in glibc.

> 2. It doesn't really solve the language specific problem. Take Chinese
> characters sorting for example, they can be sorted by
> Pinyin, Zhuyin, radical, number of strokes, and "natural" order such as
> numberial characters. The sorting is impossible to verify without the
> knowledge.

True, but a pseudo-locale which uses reverse sorting can at least show
up whether an app is using internationalised sorting, or plain old ASCII
ordering.

And we're not limited to what Microsoft did - I don't know much about
Chinese character sorting, but we could probably come up with a couple
of alternative sorts that could be understood by an English-speaking
developer.  But I don't want to tackle that just yet!

> Still, the idea itself is good. And surely it filters out some of the
> bugs without the help of translaters.

I expect a lot of i18n/L10n bugs are not picked up until someone tests
one of the affected languages.  Some of those bugs could show up in a
pseudo-locale much earlier, which has to be an improvement.

For instance, I've already found bugs where Eclipse and joe mess up the
cursor position when editing SMP characters, without personally knowing
any SMP languages.

As an English-only developer I think it's also pretty cool to see if my
code is at least partly internationalised, which otherwise I can't see
for myself at all, except in a foreign language.   I think some
English-only developers might take more interest in i18n issues if they
could easily see the results for themselves.

And for those i18n issues which can be demonstrated with a
pseudo-locale, it can be easier for multiple developers to talk about
something which is in "English", since most developers speak English,
even if they have differing native languages.

> Since the main purpose of pseudo locale is for testing, shall we agree
> on a list of pseudo locales which have their own specified behaviour?

I think it would be good if we could fit in with Vista's chosen
pseudo-locale IDs, as listed here:
http://blogs.msdn.com/shawnste/archive/2006/06/27/647915.aspx

As I said, we certainly don't have to emulate MS completely, but I think
 we should use qps for the language code.  See
http://blogs.msdn.com/michkap/archive/2007/02/04/1596987.aspx

As for the behaviours, I expect that they will change as we learn more
from testing feedback, but here are some ideas:

a. simple character substitution, rendered text to be about the same size
b. character substitution with expansion (eg "[--- original text ---]")
to make strings longer
c. maybe swapping upper and lower case.  Sometimes it's handy to have
more than one pseudo-locale, eg to make sure a web client is not seeing
the server's locale, so having spare locales might be handy.

And we could have options like different sort orders.  But I'd be happy
to start with (a) or (b) and leave sort orders until a bit later.  At
least with (a) and (b) it's easy to see whether someone forgot to call
gettext(), because the plain English strings will stick out.

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

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

From kanarip at kanarip.com  Thu Oct  2 08:04:03 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 02 Oct 2008 10:04:03 +0200
Subject: Fedora 10 early branch now available.
In-Reply-To: <1222904756.6265.34.camel@luminos.localdomain>
References: <1222904756.6265.34.camel@luminos.localdomain>
Message-ID: <48E48073.9060905@kanarip.com>

Jesse Keating wrote:
> For those of you that wish to separate Fedora 10 stabalization work from
> future development, we are now ready to process branch requests for
> F-10.
> 
> If you branch your package early, builds from your new F-10 branch will
> continue to go to the Fedora 10 targets.  dist-f10 for now, and
> eventually dist-f10-updates-candidate.  Builds from devel/ will be sent
> to dist-f11 and will be held for the Fedora 11 rawhide once we get
> Fedora 10 out the door.
> 
> To request a branch, please continue to use the cvsadmin request method:
> https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
> 

Awesome! Is this something that is considered to become the de-facto 
standard (as in mass-early-branching) sooner or later?

-Jeroen



From kulbirsaini at students.iiit.ac.in  Thu Oct  2 08:36:17 2008
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Thu, 02 Oct 2008 14:06:17 +0530
Subject: [F10-Beta]Keyboard event doesn't wake up screen
Message-ID: <48E48801.9000600@students.iiit.ac.in>

Hi list,

    I fetched F10-Beta-x86_64 Live ISO. While I was installing this live 
ISO to hdd, the screen went to sleep because there were no event. But 
when I tried to wake it up by hitting random keys on my keyboard, it 
never woke up. Tried it several times. But a single mouse event was able 
to wake it up. I am not sure whether bug should be filed against 
gnome-screensaver or some other package.

    Hardware - Wireless Keyboard (USB), Wired Mouse (USB).

---------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Web-Blog: http://fedora.co.in/

IRC nick : generalBordeaux
Channels : #fedora, #fedora-devel, #yum on freenode

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From kulbirsaini at students.iiit.ac.in  Thu Oct  2 09:01:56 2008
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Thu, 02 Oct 2008 14:31:56 +0530
Subject: Uniform Proxy Settings
Message-ID: <48E48E04.1080906@students.iiit.ac.in>

Hi list,

    Whenever I try a new version of Fedora, the first problem I face is 
setting the proxy. It seems for almost every application, I have to 
specify proxy at a different place. We have this "System -> Preferences 
-> Internet and Network -> Network Proxy" app to specify proxy settings. 
But I wonder if there is some application which obeys these settings.

Examples:

    1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above 
specified location. It has to be set via proxy option in yum.conf or 
http_proxy/ftp_proxy env variable.
    2. Codeina (0.10.1-9.fc10) will behave the same.
    3. Revisor (2.1.0-1rc7.fc9) will not even obey http_proxy/ftp_proxy 
env variable settings. It has to be set in revisor.conf via proxy option.
    .... and the list continues.

    Do we have any plans in near future to force a single location where 
proxy will be set and all other applications must read/write settings 
from/to that location? so that we can set different proxies (in case 
somebody needs) for different applications at that particular location.

---------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Web-Blog: http://fedora.co.in/

IRC nick : generalBordeaux
Channels : #fedora, #fedora-devel, #yum on freenode

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From kwizart at gmail.com  Thu Oct  2 09:07:03 2008
From: kwizart at gmail.com (KH KH)
Date: Thu, 2 Oct 2008 11:07:03 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <48E48E04.1080906@students.iiit.ac.in>
References: <48E48E04.1080906@students.iiit.ac.in>
Message-ID: <e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>

2008/10/2 Kulbir Saini <kulbirsaini at students.iiit.ac.in>:
> Hi list,
>
>   Whenever I try a new version of Fedora, the first problem I face is
> setting the proxy. It seems for almost every application, I have to specify
> proxy at a different place. We have this "System -> Preferences -> Internet
> and Network -> Network Proxy" app to specify proxy settings. But I wonder if
> there is some application which obeys these settings.
There is one: http://code.google.com/p/libproxy/
https://bugzilla.redhat.com/show_bug.cgi?id=457035

I was waiting for upstream to answear to the patch before importing.
(i will import soon)

Nicolas (kwizart)

> Examples:
>
>   1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above specified
> location. It has to be set via proxy option in yum.conf or
> http_proxy/ftp_proxy env variable.
>   2. Codeina (0.10.1-9.fc10) will behave the same.
>   3. Revisor (2.1.0-1rc7.fc9) will not even obey http_proxy/ftp_proxy env
> variable settings. It has to be set in revisor.conf via proxy option.
>   .... and the list continues.
>
>   Do we have any plans in near future to force a single location where proxy
> will be set and all other applications must read/write settings from/to that
> location? so that we can set different proxies (in case somebody needs) for
> different applications at that particular location.
>
> ---------------------------------------------------
> Thank you,
> Kulbir Saini,
> Computer Science and Engineering,
> International Institute of Information Technology,
> Hyderbad, India - 500032.
>
> My Home-Page: http://saini.co.in/
> My Web-Blog: http://fedora.co.in/
>
> IRC nick : generalBordeaux
> Channels : #fedora, #fedora-devel, #yum on freenode
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From twoerner at redhat.com  Thu Oct  2 09:40:42 2008
From: twoerner at redhat.com (Thomas Woerner)
Date: Thu, 02 Oct 2008 11:40:42 +0200
Subject: Bug in fedora 10 beta installer,
	but what package to file against?
In-Reply-To: <1222890821.20938.3.camel@choeger6>
References: <1222890821.20938.3.camel@choeger6>
Message-ID: <48E4971A.8070907@redhat.com>

Christoph H?ger wrote:
> Hi,
> 
> I'm currently trying to install fedora 10 beta on my f8 desktop. The
> first bug I encountered was a file conflict between
> system-config-firewall and system-config-firewall-tui which both want to
> bring in system-config-firewall.mo. Clearly a bug, but who shall I
> blame? system-config-firewall system-config-firewall-tui, anaconda or
> even the new rpm? 
> 
> regards
> 
> christoph
> 

The files in the main and sub-package are identical. RPM should not 
report a file conflict. The content and even the file flags are the same.

Please verify that the packages you are using are ok and report to
https://bugzilla.redhat.com/show_bug.cgi?id=465155

Thanks,
Thomas



From nils at redhat.com  Thu Oct  2 10:46:05 2008
From: nils at redhat.com (Nils Philippsen)
Date: Thu, 02 Oct 2008 12:46:05 +0200
Subject: Do we care about /sbin /bin linked to /usr/lib ?
In-Reply-To: <48E39D51.2070804@redhat.com>
References: <200809251328.01886.sgrubb@redhat.com>
	<48DC34B4.9080407@redhat.com>  <48E39D51.2070804@redhat.com>
Message-ID: <1222944365.9061.1.camel@gibraltar.str.redhat.com>

On Wed, 2008-10-01 at 11:54 -0400, Peter Jones wrote:
> Chris Snook wrote:
> 
> >> /sbin/nash uses something in /usr
> > 
> > That sounds bad.
> 
> Why?  When it's running during boot, it's on its own filesystem in ram anyway.

Given its very limited use, one could argue that the nash binary doesn't
belong into any *bin directory, but e.g. /usr/libexec or
even /usr/lib[64]. Or does somebody use it in a running system outside
of the initrd?

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From jonathan at jonmasters.org  Thu Oct  2 10:48:45 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 02 Oct 2008 06:48:45 -0400
Subject: serial console config
Message-ID: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>

Hi folks,

What's the recommended way to configure a serial console in Fedora 9
with upstart? /etc/event.d/serial requires some fedora-centric event to
be emitted but I'm not sure where this is supposed to be generated.

<aside> time was, you could just setup a serial console in 3 seconds, I
guess I'm pining for the good old days...or some documentation.

Jon.




From rawhide at fedoraproject.org  Thu Oct  2 10:50:04 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu,  2 Oct 2008 10:50:04 +0000 (UTC)
Subject: rawhide report: 20081002 changes
Message-ID: <20081002105004.B5F701F8263@releng2.fedora.phx.redhat.com>

New package hunspell-fur
        Friulian hunspell dictionaries
New package hunspell-fy
        Frisian hunspell dictionaries
New package hunspell-mi
        Maori hunspell dictionaries
New package pymssql
        A simple database interface to MS-SQL for Python
New package python-rdflib
        Python library for working with RDF
New package rubygem-git
        A package for using Git in Ruby code
New package rubygem-highline
        HighLine is a high-level command-line IO library
Removed package bluez-libs
Removed package bluez-utils
Removed package nail
Updated Packages:

NetworkManager-0.7.0-0.11.svn4022.4.fc10
----------------------------------------
* Wed Oct  1 18:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.11.svn4022.4
- Fix connection comparison that could cause changes to get overwritten (rh #464417)


PackageKit-0.3.5-4.fc10
-----------------------
* Wed Oct  1 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.5-4
- Rename the subpackages before David blows a blood vessel.
- yum-packagekit  -> PackageKit-yum-plugin
- udev-packagekit -> PackageKit-udev-helper


anaconda-11.4.1.42-1
--------------------
* Wed Oct  1 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.42-1
- Revert "Finally controlled the plural issue at #508  in Japanese"
  (dcantrell)

* Wed Oct  1 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.41-1
- Fix text inconsistency (#465165). (clumens)
- If there's an error running Xvnc, also print it to the console. (clumens)
- Set the installation repo when using the askmethod UI (#463472). (clumens)
- Fix a segfault when the wrong HDISO repo parameter is given. (clumens)
- Remove the 'Installation Repo' cache directory after install (#464853).
  (clumens)
- If there aren't any usable NICs, don't write out a config (#465127).
  (clumens)
- It helps to specify what the method string should be split on (#464855).
  (clumens)
- Gateway and nameserver are optional for static network configuration.
  (dcantrell)
- Store nameserver in NetworkDevice object. (dcantrell)
- Fix a traceback calling enableNetwork (#464849). (clumens)
- Enable groups when creating new repos since yum doesn't do that now.
  (clumens)
- Update FQDN patch to fix a couple tracebacks (#464191). (clumens)
- Fix static network configuration from boot.iso installs. (dcantrell)
- Use all caps naming for the netdev keys. (dcantrell)
- Left justify text in ui/netconfig.glade interface. (dcantrell)
- Use the right attribute for repo URLs. (clumens)
- Use fullscreen for small screens (#444943) (katzj)
- Another try at fixing up reading errors from mount. (clumens)
- Don't traceback if no baseurl has been set yet. (clumens)
- Allow users to enter a hostname or FQDN during installation (#464191)
  (dcantrell)
- Whitespace cleanups. (dcantrell)
- Fix mk-s390-cdboot on s390x (#184648) (dcantrell)
- Run all text through unicode() before putting it into the TextBuffer.
  (clumens)
- Add reverse chap iscsi bits for kickstart (hans)
- Properly center the passphrase entry dialog. (clumens)
- Fix test for an empty hostname. (clumens)
- Support installs to SD via MMC (#461884) (katzj)
- Set ANACONDA_PRODUCTNAME, etc from /etc/system-release (#464120) (alsadi)
- Reduce code duplication by moving methods into backend (katzj)
- Select packages after repos are set up (#457583) (katzj)
- Add a basic reset method (katzj)
- Cleanups and simplifications to repo setup (clumens) (katzj)
- Revert "Revert "lang-names should really only depend on lang-table""
  (katzj)
- Fix lang-name generation + fix traceback with LANG=C (katzj)
- Allow going back to the method selection screen on error (#463473).
  (clumens)
- Make the boot loader device dialog less ugly (#463489). (clumens)
- Look in images/ for install.img on HDISO (#463474). (clumens)
- Sort Installation Repo to the top of the repo list. (clumens)
- Fuzzy string to fix translation build (katzj)


ant-1.7.1-7.2.fc10
------------------
* Wed Oct  1 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0:1.7.1-7.2
- Exclude bogus perl(the) Requires
- Exclude bogus perl(oata), perl(examples) Provides


arora-0.4-1.fc10
----------------
* Wed Oct  1 18:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> - 0.4-1
- Updated to version 0.4


axis-1.2.1-4.1.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Permaine Cheung <pcheung at redhat.com> 0:1.2.1-4.1
- Specify source=1.4 for javac


azureus-3.0.4.2-17.fc10
-----------------------
* Wed Oct  1 18:00:00 2008 Lillian Angel <langel at redhat.com> - 3.0.4.2-17
- Updated release.
- Changed swt-gtk-3.3.jar links to swt.jar.
- Updated libswt3-gtk2 requirements to eclipse-swt.
- Resolves: rhbz#465051


beldi-0.9.21-1.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.9.21-1
- Upgrade to 0.9.21
- Add new manpage


bigloo-3.1b-3.fc10
------------------
* Tue Sep 30 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 3.1b-3
- add BR openssl-devel
- add missing Req. gmp-devel


cernlib-2006-31.fc10
--------------------
* Wed Oct  1 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 2006-31
- correct 702-patch-Imakefiles-for-packlib-mathlib to apply with fuzz 0


cernlib-g77-2006-31.fc10
------------------------
* Wed Oct  1 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 2006-31
- correct 702-patch-Imakefiles-for-packlib-mathlib to apply with fuzz 0


crystalspace-1.2.1-1.fc10
-------------------------

cwrite-0.1.24-3.fc9
-------------------

dhcp-4.0.0-29.fc10
------------------
* Wed Oct  1 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-29
- Make sure /etc/resolv.conf has restorecon run on it (#451560)


eel2-2.24.0-3.fc10
------------------
* Wed Oct  1 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-3
- When a crossfade is in progress and another is requested,
  don't cancel the first but instead just change the
  pixmap that's getting faded to.  Might help with a flicker
  problem Matthias is encountering


ejabberd-2.0.2-3.fc10
---------------------
* Thu Oct  2 18:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 2.0.2-3
- Fixed broken ejabberdctl (BZ# 465196)

* Sat Aug 30 18:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 2.0.2-2
- Added missing Requires


elfutils-0.137-3.fc10
---------------------
* Wed Oct  1 18:00:00 2008 Roland McGrath <roland at redhat.com> - 0.137-3
- fix libdwfl regression (#462689)


elinks-0.12-0.6.pre2.fc10
-------------------------
* Wed Oct  1 18:00:00 2008 Kamil Dudka <kdudka at redhat.com> 0.12-0.6.pre2
- port elinks to use NSS library for cryptography (#346861)


expendable-0.0.3-3.fc10
-----------------------
* Wed Oct  1 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 0.0.3-3
- 0.0.3.
- Don't run 'make check' as it requires an X display.
- Requires pygtk2.


fltk-1.1.9-1.fc10
-----------------
* Wed Oct  1 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.1.9-1
- fltk-1.1.9


galeon-2.0.7-1.fc10
-------------------
* Sat Sep 27 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.0.7-1
- Update to 2.0.7
- Reworked plugins patch, added nspr test config patch
- Other patches upstreamed


gambas-1.0.19-7.fc10
--------------------
* Wed Oct  1 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.19-7
- fix gcc4 patch to apply without fuzz


ghc-6.8.3-6.fc10
----------------
* Wed Oct  1 18:00:00 2008 Bryan O'Sullivan <bos at serpentine.com> 6.8.3-6.fc10
* Rename hsc2hs to hsc2hs-ghc so the alternatives symlink to it will work


glade2-2.12.2-5.fc10
--------------------
* Wed Oct  1 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.12.2-5
- Make it build

* Mon Jul 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.12.2-3
- fix license tag


glib-1.2.10-30.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 1:1.2.10-30
- copy config.* from rpm directory, those shipped are too old. Should
  fix #462650.


glib2-2.18.1-2.fc10
-------------------
* Wed Oct  1 18:00:00 2008 David Zeuthen <davidz at redhat.com> - 2.18.1-2
- Update the patch to always pass FUSE POSIX URI's


gmpc-0.15.5.0-4.fc10
--------------------
* Wed Oct  1 18:00:00 2008 Adrian Reber <adrian at lisas.de> - 0.15.5.0-4
- re-created patch to apply cleanly (fixes #465008)


grep-2.5.1a-61.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 2.5.1a-61
- Fix pcre-mode (-P) line wrapping (bug #324781)
- Match the version with upstream
- Recode AUTHORS to utf8


gtk+-1.2.10-64.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1:1.2.10-63
- patch_fuzz, fix build (#465033)

* Wed Oct  1 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 1:1.2.10-64
- copy config.* from rpm directory, those shpped with gtk+ are too old

* Mon Mar 10 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1:1.2.10-62
- Provides: gtk1(-devel)


gvfs-1.0.1-4.fc10
-----------------
* Wed Oct  1 18:00:00 2008 David Zeuthen <davidz at redhat.com>  - 1.0.1-4
- Add patch for reverse mapping FUSE paths (bgo #530654)


gweled-0.7-12.1
---------------
* Tue Sep  2 18:00:00 2008 Thorsten Leemhuis <fedora[AT]leemhuis[DOT]info> - 0.7-12
- define _default_patch_fuzz 2


hal-0.5.12-0.20081001git.fc10
-----------------------------
* Wed Oct  1 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-0.20081001git
- Update to git snapshot 20081001git


hal-info-20081001-2.fc10
------------------------
* Wed Oct  1 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 20081001-2
- Bump for rebuild

* Wed Oct  1 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 20081001-1
- Update to latest upstream release


hdf-4.2r3-4.fc10
----------------
* Wed Oct  1 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> 4.2.r3-4
- Rebase maxavailfiles patch

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 4.2r3-3
- Fix Patch0:/%patch mismatch.


iksemel-1.3-6.fc10
------------------
* Wed Oct  1 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 1.3-6
- disable "make check" on sparcv9


imsettings-0.104.1-3.fc10
-------------------------
* Wed Oct  1 18:00:00 2008 Than Ngo <than at redhat.com> 0.104.1-3
- add workaround for KDE


jakarta-commons-net-1.4.1-4.3.fc10
----------------------------------
* Wed Oct  1 18:00:00 2008 Permaine Cheung <pcheung at redhat.com> - 0:1.4.1-4.3
- Fix commons-net-1.4.1-project_xml.patch


jna-3.0.4-9.svn729.fc10
-----------------------
* Wed Oct  1 18:00:00 2008 Colin Walters <walters at redhat.com> - 3.0.4-9.svn729
- Add new patch to support NativeMapped[] which I want

* Wed Oct  1 18:00:00 2008 Colin Walters <walters at redhat.com> - 3.0.4-8.svn729
- Update to svn r729
- drop upstreamed typemapper patch

* Thu Sep 18 18:00:00 2008 Colin Walters <walters at redhat.com> - 3.0.4-7.svn700
- Add patch to make typemapper always accessible
- Add patch to skip cracktastic X11 test bits which currently fail


k3b-1.0.5-6.fc10
----------------
* Wed Oct  1 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0:1.0.5-6
- revert libdvdread header changes, fix build (#465115)
- (re)enable -devel on f9


kernel-2.6.27-0.377.rc8.git1.fc10
---------------------------------
* Wed Oct  1 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- nvidia-agp support for TTM

* Tue Sep 30 18:00:00 2008 Jeremy Katz <katzj at redhat.com>
- update to squashfs 3.4

* Tue Sep 30 18:00:00 2008 Dave Jones <davej at redhat.com>
- Disable debugging options in default builds. Enable kernel-debug.

* Tue Sep 30 18:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.27-rc8-git1

* Tue Sep 30 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- drm modesetting - radeon add some fixes


libaio-0.3.107-5.fc10
---------------------
* Wed Oct  1 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.3.107-5
- remove ExclusiveArch line


libgnomecups-0.2.3-4.fc10
-------------------------
* Wed Oct  1 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.2.3-4
- Make it build


libkexif-0.2.5-5.fc10
---------------------
* Wed Oct  1 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.2.5-5
- fix build (#465007)


libraw1394-2.0.0-2.fc10
-----------------------
* Wed Oct  1 18:00:00 2008 Jarod Wilson <jarod at redhat.com> - 2.0.0-2
- Misc fixes from Erik Hovland, based on coverity prevent analysis


linuxwacom-0.8.0.3-2.fc10
-------------------------
* Wed Oct  1 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> 0.8.0.3-1
- build sparcv9

* Wed Oct  1 18:00:00 2008 Aristeu Rozanski <arozansk at redhat.com> 0.8.1.4-1
- updating to last upstream version

* Wed Oct  1 18:00:00 2008 Aristeu Rozanski <arozansk at redhat.com> 0.8.0.3-1
- using the production version for f10

* Wed May 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.7.9.8-8
- fix license tag


lirc-0.8.4-0.2.pre1.fc10
------------------------
* Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.8.4-0.2.pre1
- Don't create a backup for the keycodes patch, or all the original files
  will also get installed, and get used in gnome-lirc-properties


lybniz-1.3.2-2.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Stewart Adam <s.adam at diffingo.com> 1.3.2-2
- Update .desktop patch for FTBFS (bz#464956)


mail-notification-5.4-3.fc10
----------------------------
* Wed Oct  1 18:00:00 2008 Dmitry Butskoy <Dmitry at Butskoy.name> - 5.4-3
- add patch for evolution >= 2.23.5 (#464779)


mesa-7.2-0.5.fc10
-----------------
* Wed Oct  1 18:00:00 2008 Dave Airlie <airlied at redhat.com> 7.2-0.5
- fix drm requires

* Wed Oct  1 18:00:00 2008 Dave Airlie <airlied at redhat.com> 7.2-0.4
- rebase to new upstream + r300 bufmgr code - openarena under kms works now


mysql-5.0.67-2.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Tom Lane <tgl at redhat.com> 5.0.67-2
- Build the "embedded server" library, and package it in a new sub-RPM
  mysql-embedded, along with mysql-embedded-devel for devel support files.
Resolves: #149829


netbeans-6.1-6.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Victor G. Vasilyev <victor.vasilyev at sun.com> 6.1-6
- Showing an incorrect EULA at startup is disabled (#464820). The netbeans-6.1-50-ide-launcher.patch is modified.


nss_compat_ossl-0.9.4-1.fc10
----------------------------
* Wed Oct  1 18:00:00 2008 Rob Crittenden <rcritten at redhat.com> - 0.9.4-1
- update to 0.9.4
- change Source0 to use fedoraproject.org


ocsinventory-agent-0.0.9.2-2.fc10
---------------------------------
* Mon Oct 20 18:00:00 2008 Remi Collet <Fedora at famillecollet.com> 0.0.9.2-2
- fix FTBFS (#465073)


openoffice.org-3.0.0-9.1.fc10
-----------------------------
* Wed Oct  1 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.1
- next candidate


ovaldi-5.5.3-1.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 5.5.3-1
- New upstream release


pam_krb5-2.3.2-1.fc10
---------------------
* Wed Oct  1 18:00:00 2008 Nalin Dahyabhai <nalin at redhat.com> - 2.3.2-1
- fix ccache permissions bypass when the "existing_ticket" option is used
  (CVE-2008-3825)
- add build requirement on "gettext" so that xgettext is available at build-time


pcre-7.8-1.fc10
---------------
* Wed Oct  1 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 7.8-1
- Update to 7.8, drop upstreamed patches
- Fix destination of documentation (#427763)
- Use buildroot macro consistently
- Separate the static library, as per current Guidelines
- Satisfy rpmlint


perl-5.10.0-46.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 4:5.10.0-45
- give Changes*.gz the same datetime to avoid multilib conflict

* Wed Oct  1 18:00:00 2008 Stepan Kasal <skasal at redhat.com> - 4:5.10.0-46
- also preserve the timestamp of AUTHORS; move the fix to the recode
  function, which is where the stamps go wrong


perl-Catalyst-Plugin-ConfigLoader-0.21-2.fc10
---------------------------------------------
* Wed Oct  1 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.21-2
- drop _with_network_tests bit

* Thu Sep 25 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.21-1
- update to 0.21


perl-Config-IniHash-3.00.00-2.fc10
----------------------------------
* Wed Oct  1 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 3.00.00-2
- add requires on Hash::Case, Hash::WithDefaults (rhbz#465164)


perl-DBIx-Class-0.08010-7.fc10
------------------------------
* Wed Oct  1 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.08010-7
- fix patch fuzz


perl-PDL-2.4.3-15.fc10
----------------------
* Wed Oct  1 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 2.4.3-15
- rebuilt for F-10


php-manual-en-20080919-1.fc10
-----------------------------
* Wed Sep 24 18:00:00 2008 Tim Jackson <rpm at timj.co.uk> 20080919-1
- Update to 2008-09-19 version
- License is now Creative Commons Attribution License


php-pear-propel_generator-1.3.0-1.fc10
--------------------------------------
* Wed Oct  1 18:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.3.0-1
- update to 1.3.0 stable


php-pear-propel_runtime-1.3.0-1.fc10
------------------------------------
* Wed Oct  1 18:00:00 2008 Alexander Kahl <akahl at iconmobile.com> - 1.3.0-1
- update to 1.3.0 stable


pigment-0.3.10-1.fc10
---------------------
* Tue Sep 30 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.10-1
- Update to 0.3.10.

* Tue Sep 16 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.9-1
- Update to 0.3.9.


pigment-python-0.3.8-1.fc10
---------------------------
* Tue Sep 30 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.8-1
- Update to 0.3.8.

* Tue Sep 16 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.7-1
- Update to 0.3.7.


python-docs-2.5.2-1.fc10
------------------------
* Wed Oct  1 18:00:00 2008 Jame Antill <james.antill at redhat.com> - 2.5.2-1
- Move to 2.5.2 like python itself.

* Wed Sep  3 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.5.1-3
- fix license tag


python-simplejson-2.0.1-1.fc10
------------------------------
* Wed Oct  1 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 2.0.1-1
- Update to 2.0.1, which contains many optimizations and bugfixes


qosmic-1.4.2-1.fc10
-------------------
* Wed Oct  1 18:00:00 2008 Ian Weller <ianweller at gmail.com> 1.4.2-1
- Updated upstream


rhythmbox-0.11.6-11.5957.fc10
-----------------------------
* Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> 0.11.6-r5956
- Update to latest trunk version, with GIO support and very many
  bug fixes
- Remove obsoleted patches, autotools and xulrunner-devel BRs

* Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-9.r5956
- Update release version

* Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-11.r5957
- Update source name

* Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-10.r5957
- Update to latest trunk
- Fixes lirc plugin never finishing loading


rpm-4.5.90-0.git8514.1
----------------------
* Wed Oct  1 18:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- update to official 4.5.90 alpha tarball 
- a big pile of misc bugfixes + translation updates
- isa-macro generation fix for ppc (#464754)
- avoid pulling in pile of perl dependencies for an unused script
- handle both "invalid argument" and clear env version mismatch on posttrans


rt3-3.8.1-1.fc10
----------------
* Wed Oct  1 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 3.8.1-1
- 1st rawhide release.

* Tue Sep 23 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 3.8.1-0
- First try at public release.
- Completely rework the spec.
- Upstream update.

* Tue Sep 23 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org>
- Don't package %{_sysconfdir}/rt3/upgrade/*.in
- Cleanup Requires, __perl_requires, __perl_provides.

* Tue Sep 23 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org>
- Add Provides for perl-deps rpm doesn't catch.
- Treat Spamassassin optional


ruby-RMagick-2.7.0-1.fc10
-------------------------
* Wed Oct  1 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.7.0-1
- 2.7.0


ruby-mechanize-0.8.3-1.fc10
---------------------------
* Wed Oct  1 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.8.3-1
- 0.8.3


seahorse-plugins-2.24.0-3.fc10
------------------------------
* Wed Oct  1 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.24.0-3
- Fix the build


selinux-policy-3.5.9-4.fc10
---------------------------
* Wed Oct  1 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.9-4
- Fix labeling for oracle

* Wed Oct  1 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.9-3
- Allow nsplugin to comminicate with xdm_tmp_t sock_file


sepostgresql-8.3.4-2.1076.fc10
------------------------------
* Thu Oct  2 18:00:00 2008 <kaigai at kaigai.gr.jp> - 8.3.3-2.1076
- bugfix: "(null)" audit logs for non-cached decision making.
- A hook is added for "COPY TO/FROM <file>" cases.


stormbaancoureur-2.1.5-1.fc10
-----------------------------

sunbird-0.9-3.fc10
------------------
* Thu Oct  2 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 0.9-3
- Attempt to fix the libical patch's timezone problem


swarp-2.17.1-3.fc10
-------------------
* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 2.17.1-3
- Include unowned /usr/share/swarp directory


tla-1.3.5-6.fc10
----------------
* Thu Oct  2 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 1.3.5-6
- Fixed build failure due to change in definition of %{_cc}. Closes Red Hat
  Bugzilla bug #465028.


totem-2.24.1-1.fc10
-------------------
* Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.1-1
- Update to 2.24.1


uw-imap-2007b-2.fc10
--------------------
* Wed Oct  1 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 2007b-2
- fix build (patch fuzz) (#464985)


vtk-5.0.4-25.fc10
-----------------
* Wed Oct  1 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 5.0.2-25
- Fix patch fuzz


w3lib-1.6-4.fc10
----------------
* Wed Oct  1 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 1.6-4
- quote %{__cc} since now the macro also holds compiler options


wcstools-3.7.0-3.fc10
---------------------
* Wed Oct  1 18:00:00 2008 Sergio Pascual <sergiopr at fedoraproject.org> 3.7.0-3
- Fails to build from source bz#465061


wp_tray-0.5.3-8.fc10
--------------------
* Wed Oct  1 18:00:00 2008 Denis <denis at poolshark.org> - 0.5.3-8
- Fixed boost patch


xfce4-mailwatch-plugin-1.1.0-1.fc10
-----------------------------------
* Wed Oct  1 18:00:00 2008 Christoph Wickert <fedora christoph-wickert de> - 1.1.0-1
- Update to 1.1.0 fixes crash due to obscure GTK hash error (#463412)


xfce4-panel-4.4.2-5.fc10
------------------------
* Thu Oct  2 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.2-5
- Fix FTBFS (#465058)
- Update defaults patch to include mailwatch plugin
- Remove old xfce4-iconbox and xftaskbar dummy files


xfce4-xkb-plugin-0.5.1-1.fc10
-----------------------------
* Thu Oct  2 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.1-1
- Update to 0.5.1


xkeyboard-config-1.4-2.fc10
---------------------------
* Wed Oct  1 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1.4-2
- Update to 1.4


xorg-x11-drv-ati-6.9.0-21.fc10
------------------------------
* Wed Oct  1 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-21
- rebase for latest fixes and new libdrm


xorg-x11-drv-i810-2.4.2-9.fc10
------------------------------
* Wed Oct  1 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.4.2-9
- rebase to upstream for new libdrm interfaces


Summary:
Added Packages: 7
Removed Packages: 3
Modified Packages: 94
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	beagle-evolution-0.3.8-6.fc10.i386 requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2
	openobex-apps-1.3-13.fc10.i386 requires libbluetooth.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	beagle-evolution-0.3.8-6.fc10.x86_64 requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit)
	openobex-apps-1.3-13.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	beagle-evolution-0.3.8-6.fc10.ppc requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2
	openobex-apps-1.3-13.fc10.ppc requires libbluetooth.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit)
	openobex-apps-1.3-13.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From jonathan at jonmasters.org  Thu Oct  2 11:03:35 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 02 Oct 2008 07:03:35 -0400
Subject: NetworkManager vs. sysconfig
Message-ID: <1222945415.26632.35.camel@perihelion.int.jonmasters.org>

Hi folks,

I just installed a test server running F9. For once, I let
NetworkManager run and left the install fairly alone. I statically
configured a set of network settings in anaconda and those are present
in the sysconfig network scripts. But NetworkManager decides it knows
better and reconfigures the interface with DHCP anyway[0].

How is static interface config supposed to work with NetworkManager?
Does this actually work in F9 today?

Jon.

[0] It actually does this even when you create a new "wired network" in
NetworkManager with the correct config (so now you have it in two
places) - it always wants to use its own "Auto eth0" regardless.




From jakub at redhat.com  Thu Oct  2 11:37:50 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Thu, 2 Oct 2008 13:37:50 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <48E43AB6.9000607@codewiz.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
	<48E43AB6.9000607@codewiz.org>
Message-ID: <20081002113750.GD32682@tyan-ft48-01.lab.bos.redhat.com>

On Thu, Oct 02, 2008 at 05:06:30AM +0200, Bernie Innocenti wrote:
> Kyle McMartin wrote:
>> Ah, I'm glad to see others working on this! I'd not seen the Mandriva
>> efforts, but I should really poke at them as I'd turned modprobe into
>> a library and started integrating it into udev.
>
> What an un-unixish design!
>
> One could achieve the same performance with a trivial change that would  
> keep modprobe and udev independent and simple:
>
>   cat | modprobe --stdin
>   radeon
>   drm
>   foo
>   FATAL: Module foo not found.
>   e1000
>   ^D
>
> Well, you get the idea... :-)

The way modprobe is written, just changing it to a library or handling
multiple requests from one command doesn't help much, as for every argument
modprobe reads all config files again anyway and for alias handling the most
costly is the search among the aliases anyway and searching the deps is
somewhat costly too.  Reading the config files just once is of course fixable
(both in the library and --stdin models) but the searching would still be
an issue.  Either modprobe can create the hash tables or search tree for
aliases on the fly, or, what I've done in my patch, let depmod create it
ahead of time and modprobe just use it.

	Jakub



From paul at all-the-johnsons.co.uk  Thu Oct  2 11:40:43 2008
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Thu, 2 Oct 2008 12:40:43 +0100
Subject: Evolution has thrown a wobbler!
Message-ID: <20081002113906.M86097@all-the-johnsons.co.uk>

Hi,

After updating from yesterday's rawhide (1st Oct), Evolution seems to have 
died. It will load, but is unable to store the inbox file (it also can't 
resync on the inbox file). This means the software is completely inoperative.

Any ideas on how to fix this?

TTFN

Paul

--
It's only me, only me and no-one else.



From jwboyer at gmail.com  Thu Oct  2 11:38:09 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 2 Oct 2008 07:38:09 -0400
Subject: Fedora 10 early branch now available.
In-Reply-To: <48E48073.9060905@kanarip.com>
References: <1222904756.6265.34.camel@luminos.localdomain>
	<48E48073.9060905@kanarip.com>
Message-ID: <20081002113809.GA2227@yoda.jdub.homelinux.org>

On Thu, Oct 02, 2008 at 10:04:03AM +0200, Jeroen van Meeuwen wrote:
> Jesse Keating wrote:
>> For those of you that wish to separate Fedora 10 stabalization work from
>> future development, we are now ready to process branch requests for
>> F-10.
>>
>> If you branch your package early, builds from your new F-10 branch will
>> continue to go to the Fedora 10 targets.  dist-f10 for now, and
>> eventually dist-f10-updates-candidate.  Builds from devel/ will be sent
>> to dist-f11 and will be held for the Fedora 11 rawhide once we get
>> Fedora 10 out the door.
>>
>> To request a branch, please continue to use the cvsadmin request method:
>> https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
>>
>
> Awesome! Is this something that is considered to become the de-facto  
> standard (as in mass-early-branching) sooner or later?

To my knowledge, no.  We did this same thing in the F9 timeframe, but no
mass early branching.

josh



From P at draigBrady.com  Thu Oct  2 11:44:05 2008
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Thu, 2 Oct 2008 12:44:05 +0100
Subject: Boot speedup with readahead
In-Reply-To: <20080906212125.27b9b3bb@infradead.org>
References: <g9tne8$dt0$1@ger.gmane.org>
	<20080906212125.27b9b3bb@infradead.org>
Message-ID: <48E4B405.8040300@draigBrady.com>

Arjan van de Ven wrote:
> for those who are going to the plumbers conference... Auke Kok and I
> will present there on how to make a Fedora based system boot in 5
> seconds...
> 
> and yes a form of readahead was needed to achieve that ;-)

There is some public info on this now:
http://lwn.net/Articles/299483/



From sundaram at fedoraproject.org  Thu Oct  2 11:50:56 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 02 Oct 2008 17:20:56 +0530
Subject: Boot speedup with readahead
In-Reply-To: <48E4B405.8040300@draigBrady.com>
References: <g9tne8$dt0$1@ger.gmane.org>	<20080906212125.27b9b3bb@infradead.org>
	<48E4B405.8040300@draigBrady.com>
Message-ID: <48E4B5A0.5000905@fedoraproject.org>

P?draig Brady wrote:
> Arjan van de Ven wrote:
>> for those who are going to the plumbers conference... Auke Kok and I
>> will present there on how to make a Fedora based system boot in 5
>> seconds...
>>
>> and yes a form of readahead was needed to achieve that ;-)
> 
> There is some public info on this now:
> http://lwn.net/Articles/299483/

You are late. Check

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

Rahul



From kraxel at redhat.com  Thu Oct  2 12:03:31 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Thu, 02 Oct 2008 14:03:31 +0200
Subject: serial console config
In-Reply-To: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
Message-ID: <48E4B893.5060003@redhat.com>

Jon Masters wrote:
> Hi folks,
> 
> What's the recommended way to configure a serial console in Fedora 9
> with upstart? /etc/event.d/serial requires some fedora-centric event to
> be emitted but I'm not sure where this is supposed to be generated.

I've no idea who generates that event.  But it works for me simply by
booting the kernel with "console=ttyS0".  Gives you (as usual) all boot
messages on the serial line, and additionally it somehow triggers the
mentioned event so you'll have a getty for login too.  Works with the
xen console (aka console=hvc0) too, probably anything != virtual terminal.

For just an additional getty on the serial line, without also moving the
console it it, I've simply copyed tty1 to ttyS0 and adapted it.  Keep in
mind though that booting with console=ttyS0 then is a real bad idea
then.  In that case both serial and ttyS0 start a getty on your serial
line, they fight for your keystrokes then, making it almost impossible
to login because you never know which of the two actually gets what you
type ...

cheers,
  Gerd




From hughsient at gmail.com  Thu Oct  2 12:01:59 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 02 Oct 2008 13:01:59 +0100
Subject: rawhide report: 20081002 changes
In-Reply-To: <20081002105004.B5F701F8263@releng2.fedora.phx.redhat.com>
References: <20081002105004.B5F701F8263@releng2.fedora.phx.redhat.com>
Message-ID: <1222948919.10716.7.camel@hughsie-laptop>

On Thu, 2008-10-02 at 10:50 +0000, Rawhide Report wrote:
> totem-2.24.1-1.fc10
> -------------------
> * Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.1-1
> - Update to 2.24.1

Note, you'll need this if you are testing the codec auto install thing,
as Bastien fixed a bug where the wrong XID was being sent to the
gstreamer helper, and thus gnome-packagekit's dialog did not go modal
and focus stealing prevention did not work as it should. With this
update, everything should be good to go.

Richard




From hughsient at gmail.com  Thu Oct  2 12:01:59 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 02 Oct 2008 13:01:59 +0100
Subject: rawhide report: 20081002 changes
In-Reply-To: <20081002105004.B5F701F8263@releng2.fedora.phx.redhat.com>
References: <20081002105004.B5F701F8263@releng2.fedora.phx.redhat.com>
Message-ID: <1222948919.10716.7.camel@hughsie-laptop>

On Thu, 2008-10-02 at 10:50 +0000, Rawhide Report wrote:
> totem-2.24.1-1.fc10
> -------------------
> * Wed Oct  1 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.1-1
> - Update to 2.24.1

Note, you'll need this if you are testing the codec auto install thing,
as Bastien fixed a bug where the wrong XID was being sent to the
gstreamer helper, and thus gnome-packagekit's dialog did not go modal
and focus stealing prevention did not work as it should. With this
update, everything should be good to go.

Richard




From buc at odusz.so-cdu.ru  Thu Oct  2 12:27:20 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 02 Oct 2008 16:27:20 +0400
Subject: serial console config
In-Reply-To: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
Message-ID: <48E4BE28.7070905@odu.neva.ru>

Jon Masters wrote:
> Hi folks,
>
> What's the recommended way to configure a serial console in Fedora 9
> with upstart?


Do you mean the serial "console" (where kernel writes to), or just a 
serial tty (similar to Ctrl-Alt-F1 "consoles")?

In a case of "serial tty", the common approach is to do things the same 
way as mingetty is done...


~buc



From ml at deadbabylon.de  Thu Oct  2 12:49:31 2008
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Thu, 2 Oct 2008 14:49:31 +0200
Subject: KDE-SIG weekly report (40/2008)
Message-ID: <200810021449.36562.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: 40/2008

Time: 2008-09-30 16:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-09-30

Meeting log: https://fedoraproject.org/w/uploads/6/6d/KDE-SIG-2008-09-30.txt

----------------------------------------------------------------------------------

= Participants =

ArthurPemberton 
JaroslavReznik 
KevinKolfer 
PavelShevchuk 
RexDieter 
StevenParrish 
ThanNgo

----------------------------------------------------------------------------------

= Agenda =

- kde-4.1.2 status 
- mysql-embedded for amarok2, bug #149829 [1]
- libkipi framework: kdegraphics, Digikam in F10 
- kpackagekit status 
- knetworkmanager status 
- F-10/kde artwork, theme. 
- echo-icon-theme status report

= Summary =

kde-4.1.2 status: 
-------------------------
* All packages are already imported and built for F9 and F10. 
* kde-settings in F9 will be updated and the F10 version will be bumped to 
don't overlap anymore. 

echo-icon-theme status report: 
--------------------------------------------
* The default icon theme in F10 will still be Oxygen/Fedora-KDE. 
* There will be likely not enough time to fix all the missing icons for F10. 
* A report of echo-icon-theme in KDE lists many missing icons. [2]
* A wiki page about missing icons in KDE was set up. [3]

mysql-embedded for amarok2: 
--------------------------------------------
* The next beta of amarok2 will use mysql-embedded which isn't available in 
Fedora. 
* An old RFE also requests this enhancement (#149829). [1]
* We'll need to talk to the mysql-maintainers to make it possible to ship a 
mysql-embedded package in F10. 
* In a worst-case-scenario we'll have to fall back to amarok1 in F10. 

libkipi framework: kdegraphics, Digikam in F10: 
--------------------------------------------------------------------
* The respins of kdegraphics-4.1.2 removed the updated libkipi framework which 
is needed by the latest Digikam beta. 
* If this won't be reverted upstream we'll have to use the older beta version 
of digikam or or patch in the libkipi framework from kdegraphics' trunk. 

kpackagekit status: 
-----------------------------
*kpackagekit-0.1 was released on 29 Sep 2008 and should now provide the same 
functionality as gnome-packagekit. [4]
* kpackagekit will be added to kde-desktop group in comps as default to get 
some testing. 
* At this time there were no conclusion about replacing gnome-packagekit also 
on the live media. 
* Packages for F9 could be provided when PackageKit-0.3 is available as an 
update. 

knetworkmanager status: 
------------------------------------
* The latest svn version of knetworkmanager in Rawhide is now able to build 
and is at least basically working. 
* Though, it won't be installed by default and @kde-desktop will still use 
Networkmanager-gnome as default 
* But the release notes for F10 will mention the existence of knetworkmanager 
as a technology preview. 

F-10/kde artwork, theme: 
-------------------------------------
* We'll need at least a KDM theme and a KSplash for the Artwork of Fedora 10. 
* KushalDas is working on a KDM theme based on SamueleStorari's mockup. 
* SamueleStorari will also provide a mockup for KSplash.


----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-07

----------------------------------------------------------------------------------

= Links =

[1] https://bugzilla.redhat.com/show_bug.cgi?id=149829
[2] 
http://sourceforge.net/mailarchive/forum.php?thread_name=16de708d0809292221j54d041f8w9d85b127d2bc6552%40mail.gmail.com&forum_name=kde-redhat-users
[3] https://fedoraproject.org/wiki/SIGs/KDE/Branding/Echo
[4] 
http://www.kde-apps.org/content/show.php/KPackageKit?content=84745&PHPSESSID=6395e0f083a05b4c673a4ab58e054a32

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081002/c9eecd6f/attachment.sig>

From skvidal at fedoraproject.org  Thu Oct  2 12:54:29 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 02 Oct 2008 08:54:29 -0400
Subject: serial console config
In-Reply-To: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
Message-ID: <1222952069.17545.2.camel@rosebud>

On Thu, 2008-10-02 at 06:48 -0400, Jon Masters wrote:
> Hi folks,
> 
> What's the recommended way to configure a serial console in Fedora 9
> with upstart? /etc/event.d/serial requires some fedora-centric event to
> be emitted but I'm not sure where this is supposed to be generated.
> 
> <aside> time was, you could just setup a serial console in 3 seconds, I
> guess I'm pining for the good old days...or some documentation.

here's what worked for me
make a file named /etc/event.d/ttyS0 (or whatever serial port you want)

start on runlevel 1
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5

stop on runlevel 0
stop on runlevel 6

respawn
exec /sbin/agetty ttyS0 9600 vt100-nav


-sv





From bnocera at redhat.com  Thu Oct  2 13:47:53 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 02 Oct 2008 14:47:53 +0100
Subject: Codeina orphaned in devel
Message-ID: <1222955273.3236.28.camel@cookie.hadess.net>

Heya,

As we know have a replacement for Codeina, in the shape of the
PackageKit helper, I relinquished my ownership of Codeina in devel.

If somebody wants to take it over, please talk to Thomas about it.

Cheers



From notting at redhat.com  Thu Oct  2 13:56:47 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 2 Oct 2008 09:56:47 -0400
Subject: serial console config
In-Reply-To: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
Message-ID: <20081002135647.GA2859@nostromo.devel.redhat.com>

Jon Masters (jonathan at jonmasters.org) said: 
> What's the recommended way to configure a serial console in Fedora 9
> with upstart? /etc/event.d/serial requires some fedora-centric event to
> be emitted but I'm not sure where this is supposed to be generated.

>From udev.

> <aside> time was, you could just setup a serial console in 3 seconds, I
> guess I'm pining for the good old days...or some documentation.

cp /etc/event.d/tty1 /etc/event.d/my_serial_console. Edit as appropriate.

Bill



From skvidal at fedoraproject.org  Thu Oct  2 13:58:19 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 02 Oct 2008 09:58:19 -0400
Subject: serial console config
In-Reply-To: <20081002135647.GA2859@nostromo.devel.redhat.com>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
	<20081002135647.GA2859@nostromo.devel.redhat.com>
Message-ID: <1222955899.18687.1.camel@rosebud>

On Thu, 2008-10-02 at 09:56 -0400, Bill Nottingham wrote:
> Jon Masters (jonathan at jonmasters.org) said: 
> > What's the recommended way to configure a serial console in Fedora 9
> > with upstart? /etc/event.d/serial requires some fedora-centric event to
> > be emitted but I'm not sure where this is supposed to be generated.
> 
> >From udev.
> 
> > <aside> time was, you could just setup a serial console in 3 seconds, I
> > guess I'm pining for the good old days...or some documentation.
> 
> cp /etc/event.d/tty1 /etc/event.d/my_serial_console. Edit as appropriate.
> 

and you'll probably want to make sure the serial console is enabled in
runlevel 1 - which tty1 doesn't seem to be.

-sv




From drepper at redhat.com  Thu Oct  2 14:00:42 2008
From: drepper at redhat.com (Ulrich Drepper)
Date: Thu, 02 Oct 2008 07:00:42 -0700
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E45455.7000203@redhat.com>
References: <48E45455.7000203@redhat.com>
Message-ID: <48E4D40A.6000402@redhat.com>

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

Sean Flanigan wrote:
> Would there be any interest in getting something like this into glibc?

Hell, no.  There is no room for testing code in the runtime.  And I see
absolutely no need whatsoever to have it there.  It seems to be the
wrong place altogether.  For PO files you create appropriate
translations.  For the locales themselves you derive a file from the
existing locales, compile it using localedef, and just use it.

None of the locale code is hardcoded in glibc.  Why should this?

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjk1AoACgkQ2ijCOnn/RHSsQACeOh7RbXv10iIoE8H1V1R25LK3
edEAnR0GYkEMrJ1j+riFqvM8O61PIW6O
=CGyu
-----END PGP SIGNATURE-----



From jeevanullas at gmail.com  Thu Oct  2 14:01:59 2008
From: jeevanullas at gmail.com (Deependra Singh Shekhawat)
Date: Thu, 02 Oct 2008 19:31:59 +0530
Subject: NetworkManager vs. sysconfig
In-Reply-To: <1222945415.26632.35.camel@perihelion.int.jonmasters.org>
References: <1222945415.26632.35.camel@perihelion.int.jonmasters.org>
Message-ID: <1222956119.12632.0.camel@station1.example.com>

Hi,

Yes it works with the latest updates till today.

On Thu, 2008-10-02 at 07:03 -0400, Jon Masters wrote:
> Hi folks,
> 
> I just installed a test server running F9. For once, I let
> NetworkManager run and left the install fairly alone. I statically
> configured a set of network settings in anaconda and those are present
> in the sysconfig network scripts. But NetworkManager decides it knows
> better and reconfigures the interface with DHCP anyway[0].
> 
> How is static interface config supposed to work with NetworkManager?
> Does this actually work in F9 today?
> 
> Jon.
> 
> [0] It actually does this even when you create a new "wired network" in
> NetworkManager with the correct config (so now you have it in two
> places) - it always wants to use its own "Auto eth0" regardless.
> 
> 
-- 
-----------------------------
Type bits /keyID Date User ID
pub 1024D/483B234C 2007/06/29 Deependra Singh Shekhawat (Fedora Project)
<jeevanullas at gmail.com>
Key fingerprint = ED45 62EA A4D7 53FB 44C7 774A D55B F3F0 483B 234C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081002/5d31fe73/attachment.sig>

From notting at redhat.com  Thu Oct  2 14:07:05 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 2 Oct 2008 10:07:05 -0400
Subject: serial console config
In-Reply-To: <1222955899.18687.1.camel@rosebud>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
	<20081002135647.GA2859@nostromo.devel.redhat.com>
	<1222955899.18687.1.camel@rosebud>
Message-ID: <20081002140705.GB2859@nostromo.devel.redhat.com>

seth vidal (skvidal at fedoraproject.org) said: 
> > cp /etc/event.d/tty1 /etc/event.d/my_serial_console. Edit as appropriate.
> 
> and you'll probably want to make sure the serial console is enabled in
> runlevel 1 - which tty1 doesn't seem to be.

Runlevel 1 already starts a shell on /dev/console. If your serial console
isn't the primary /dev/console, yes, you'll want this.

Bill



From mcrha at redhat.com  Thu Oct  2 14:18:14 2008
From: mcrha at redhat.com (Milan Crha)
Date: Thu, 02 Oct 2008 16:18:14 +0200
Subject: Evolution has thrown a wobbler!
In-Reply-To: <20081002113906.M86097@all-the-johnsons.co.uk>
References: <20081002113906.M86097@all-the-johnsons.co.uk>
Message-ID: <1222957094.2969.3.camel@madtux.englab.brq.redhat.com>

On Thu, 2008-10-02 at 12:40 +0100, Paul F. Johnson wrote:
> Hi,
> 
> After updating from yesterday's rawhide (1st Oct), Evolution seems to have 
> died. It will load, but is unable to store the inbox file (it also can't 
> resync on the inbox file). This means the software is completely inoperative.
> 
> Any ideas on how to fix this?
> 
> TTFN
> 
> Paul

	Hi Paul,
try to close all evolution processes, like with this command:

   $ evolution --force-shutdown

and then run evolution from the console and see what's there. It's
possible there will be some error message(s) what's going wrong.

Please file bug for your issue, in Fedora's bugzilla, it'll be easier to
track the problem. Thanks.
	Bye,
	Milan



From katzj at redhat.com  Thu Oct  2 14:29:04 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 02 Oct 2008 10:29:04 -0400
Subject: Do we care about /sbin /bin linked to /usr/lib ?
In-Reply-To: <1222944365.9061.1.camel@gibraltar.str.redhat.com>
References: <200809251328.01886.sgrubb@redhat.com>
	<48DC34B4.9080407@redhat.com>  <48E39D51.2070804@redhat.com>
	<1222944365.9061.1.camel@gibraltar.str.redhat.com>
Message-ID: <1222957744.16255.9.camel@aglarond.local>

On Thu, 2008-10-02 at 12:46 +0200, Nils Philippsen wrote:
> Given its very limited use, one could argue that the nash binary doesn't
> belong into any *bin directory, but e.g. /usr/libexec or
> even /usr/lib[64]. Or does somebody use it in a running system outside
> of the initrd?

In the past, it was used by rc.sysinit for a few things but hasn't been
for quite a while.  So yes, it probably could be moved at this point

Jeremy



From hbasava at yahoo.com  Thu Oct  2 14:22:42 2008
From: hbasava at yahoo.com (Basavaraj Hiremath)
Date: Thu, 2 Oct 2008 07:22:42 -0700 (PDT)
Subject: Fedora Core 3 kernel source..
Message-ID: <813944.77284.qm@web36107.mail.mud.yahoo.com>

Hi,
I am looking for Fedora Core 3 Kernel source, whenever I go to any link not finding Core 3 kernel source.
I can find later versions, could any one help it.
Thanks in advance.

http://download.fedora.redhat.com/pub/fedora/linux/core/3/SRPMS/kernel-2.6.9-1.667.src.rpm

Above link is not working, not found anywhere kernel-2.6.9-1.667.src.rpm.

-
Thanks & regards,
Basavaraj



      



From paul at city-fan.org  Thu Oct  2 14:56:58 2008
From: paul at city-fan.org (Paul Howarth)
Date: Thu, 02 Oct 2008 15:56:58 +0100
Subject: Fedora Core 3 kernel source..
In-Reply-To: <813944.77284.qm@web36107.mail.mud.yahoo.com>
References: <813944.77284.qm@web36107.mail.mud.yahoo.com>
Message-ID: <48E4E13A.5010903@city-fan.org>

Basavaraj Hiremath wrote:
> Hi,
> I am looking for Fedora Core 3 Kernel source, whenever I go to any link not finding Core 3 kernel source.
> I can find later versions, could any one help it.
> Thanks in advance.
> 
> http://download.fedora.redhat.com/pub/fedora/linux/core/3/SRPMS/kernel-2.6.9-1.667.src.rpm
> 
> Above link is not working, not found anywhere kernel-2.6.9-1.667.src.rpm.

http://archives.fedoraproject.org/pub/archive/fedora/linux/core/3/SRPMS/kernel-2.6.9-1.667.src.rpm

Paul.



From thomas.moschny at gmail.com  Thu Oct  2 14:58:40 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 2 Oct 2008 16:58:40 +0200
Subject: Fedora Core 3 kernel source..
In-Reply-To: <813944.77284.qm@web36107.mail.mud.yahoo.com>
References: <813944.77284.qm@web36107.mail.mud.yahoo.com>
Message-ID: <a9d183c80810020758m710c7728v9a2162eaff5e96b7@mail.gmail.com>

2008/10/2 Basavaraj Hiremath <hbasava at yahoo.com>:
> I am looking for Fedora Core 3 Kernel source, whenever I go to any link not finding Core 3 kernel source.
> I can find later versions, could any one help it.
> Thanks in advance.
>
> http://download.fedora.redhat.com/pub/fedora/linux/core/3/SRPMS/kernel-2.6.9-1.667.src.rpm
>
> Above link is not working, not found anywhere kernel-2.6.9-1.667.src.rpm.

The Fedora Legacy project has these files, see http://fedoralegacy.org/.

The src rpm you are looking for can for example be found here:
http://ftp-stud.fht-esslingen.de/pub/Mirrors/download.fedoralegacy.org/fedora/3/os/SRPMS/kernel-2.6.9-1.667.src.rpm
. You might want to choose another mirror, see
http://fedoralegacy.org/download/fedoralegacy-mirrors.php .

- Thomas



From nicolas.mailhot at laposte.net  Thu Oct  2 15:34:46 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 2 Oct 2008 17:34:46 +0200 (CEST)
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E47FF3.5060600@redhat.com>
References: <48E45455.7000203@redhat.com>
	<1222929670.4697.31.camel@localhost.localdomain>
	<48E47FF3.5060600@redhat.com>
Message-ID: <dc4a4b079288836c1efc2bda99e4939d.squirrel@arekh.dyndns.org>



Le Jeu 2 octobre 2008 10:01, Sean Flanigan a ?crit :
> Ding-Yi Chen wrote:
>> The pseudo locale is intriguing, and I assume it helps at some
>> degree.
>> However, this approach does have its own limitation:
>
> Of course, pseudo-localisation testing is not the same as localisation
> testing in every Fedora language, but it's something!
>
>> 1. Lack of font support: as the attachment "lack_of_font.png" shows,
>> the
>> pseudo locale might be rendered useless if all developers can see
>> are
>> unicode boxes. :-P
>
> That tells me that the developers should install better fonts, or how
> else can they test an internationalised application?

Install the distro default font set, it should cover most everything

> But to be
> honest,
> I probably shouldn't have used
> http://en.wikipedia.org/wiki/Mathematical_alphanumeric_symbols since
> they're only guaranteed to be available in certain mathematical fonts
> such as Code2001.

We have stix

> But how can I find the name of the font which provides a given
> character?

Answer in the fonts SIG wiki
http://fedoraproject.org/wiki/Category:Fonts_SIG

Looking at your interests and questions, you should really read it and
join the SIG (same for other interested people)


-- 
Nicolas Mailhot



From jkeating at redhat.com  Thu Oct  2 15:42:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 02 Oct 2008 08:42:17 -0700
Subject: Fedora 10 early branch now available.
In-Reply-To: <48E48073.9060905@kanarip.com>
References: <1222904756.6265.34.camel@luminos.localdomain>
	<48E48073.9060905@kanarip.com>
Message-ID: <1222962137.6265.53.camel@luminos.localdomain>

On Thu, 2008-10-02 at 10:04 +0200, Jeroen van Meeuwen wrote:
> Awesome! Is this something that is considered to become the de-facto 
> standard (as in mass-early-branching) sooner or later?

Likely not.  There are two sets of folks we're trying to satisfy, those
that actually continue on with future development, and those that need
the entire development cycle for the current release.  Early branching
the latter folks just adds more work for them every time they do a build
as to not have upgrade path issues and to not forget to build for the
next rawhide.  By letting maintainers choose for themselves when to
branch we can satisfy both sets of maintainers.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081002/41b2f7dd/attachment.sig>

From buc at odusz.so-cdu.ru  Thu Oct  2 15:49:13 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 02 Oct 2008 19:49:13 +0400
Subject: Strange repodata/other.xml issue...
Message-ID: <48E4ED79.8010907@odu.neva.ru>

Sometimes the changelog entries contain "<" and/or ">" symbols. For 
example, a fragment of the changelog of "k3b" package:

> * Wed Oct  6 02:00:00 2004 Harald Hoyer <harald at redhat.com> 0:0.11.17-1
> - version 0.11.17
> - revert the dao -> tao change
> - add the suid feature to every app automatically

note the "->" in the line:

> - revert the dao -> tao change

When I create my local repodata ("cd somewhere; createrepo ."), the 
correspond fragment appears in the "repodata/other.xml.gz" file, in the 
form of:

> - revert the dao -&gt; tao change

Then, when I update my repodata by "createrepo --update .", I receive an 
error:

> Scanning old repo data
> Indexed 2997 base nodes
> Indexed 3001 filelist nodes
> /var/ftp/.4/fedora-8/fedora/i386/./repodata/other.xml.gz:118813: 
> parser error : Detected an entity reference loop
> - revert the dao -&gt; tao change
>                       ^
> Traceback (most recent call last):
>   File "/usr/share/createrepo/genpkgmetadata.py", line 722, in <module>
>     main(sys.argv[1:])
>   File "/usr/share/createrepo/genpkgmetadata.py", line 645, in main
>     mdgen.doPkgMetadata(directory)
>   File "/usr/share/createrepo/genpkgmetadata.py", line 161, in 
> doPkgMetadata
>     basefile, flfile, otherfile, opts)
>   File "/usr/share/createrepo/readMetadata.py", line 41, in __init__
>     self.scan()
>   File "/usr/share/createrepo/readMetadata.py", line 64, in scan
>     root = libxml2.parseFile(self.files['other']).getRootElement()
>   File "/usr/lib/python2.5/site-packages/libxml2.py", line 1279, in 
> parseFile
>     if ret is None:raise parserError('xmlParseFile() failed')
> libxml2.parserError: xmlParseFile() failed

IOW, the initial "full" createrepo run seems OK, the subsequent run with 
"--update" is failed.

Any comments? Whether it is some bug in createrepo, or in some yum 
components?


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From buc at odusz.so-cdu.ru  Thu Oct  2 16:17:55 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 02 Oct 2008 20:17:55 +0400
Subject: Strange repodata/other.xml issue...
In-Reply-To: <48E4ED79.8010907@odu.neva.ru>
References: <48E4ED79.8010907@odu.neva.ru>
Message-ID: <48E4F433.7080108@odu.neva.ru>

Dmitry Butskoy wrote:
>> Scanning old repo data
>> Indexed 2997 base nodes
>> Indexed 3001 filelist nodes
>> /var/ftp/.4/fedora-8/fedora/i386/./repodata/other.xml.gz:118813: 
>> parser error : Detected an entity reference loop
>> - revert the dao -&gt; tao change
>>                       ^
>> Traceback (most recent call last):
>>   File "/usr/share/createrepo/genpkgmetadata.py", line 722, in <module>
>>     main(sys.argv[1:])
>>   File "/usr/share/createrepo/genpkgmetadata.py", line 645, in main
>>     mdgen.doPkgMetadata(directory)
>>   File "/usr/share/createrepo/genpkgmetadata.py", line 161, in 
>> doPkgMetadata
>>     basefile, flfile, otherfile, opts)
>>   File "/usr/share/createrepo/readMetadata.py", line 41, in __init__
>>     self.scan()
>>   File "/usr/share/createrepo/readMetadata.py", line 64, in scan
>>     root = libxml2.parseFile(self.files['other']).getRootElement()
>>   File "/usr/lib/python2.5/site-packages/libxml2.py", line 1279, in 
>> parseFile
>>     if ret is None:raise parserError('xmlParseFile() failed')
>> libxml2.parserError: xmlParseFile() failed

It seems to be fixed in the latest update of libxml2 (libxml2-2.7.1) .


~buc



From skvidal at fedoraproject.org  Thu Oct  2 15:56:11 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 02 Oct 2008 11:56:11 -0400
Subject: Strange repodata/other.xml issue...
In-Reply-To: <48E4ED79.8010907@odu.neva.ru>
References: <48E4ED79.8010907@odu.neva.ru>
Message-ID: <1222962971.18687.3.camel@rosebud>

On Thu, 2008-10-02 at 19:49 +0400, Dmitry Butskoy wrote:
> Sometimes the changelog entries contain "<" and/or ">" symbols. For 
> example, a fragment of the changelog of "k3b" package:
> 
> > * Wed Oct  6 02:00:00 2004 Harald Hoyer <harald at redhat.com> 0:0.11.17-1
> > - version 0.11.17
> > - revert the dao -> tao change
> > - add the suid feature to every app automatically
> 
> note the "->" in the line:
> 
> > - revert the dao -> tao change
> 
> When I create my local repodata ("cd somewhere; createrepo ."), the 
> correspond fragment appears in the "repodata/other.xml.gz" file, in the 
> form of:
> 
> > - revert the dao -&gt; tao change
> 
> Then, when I update my repodata by "createrepo --update .", I receive an 
> error:
> 
> > Scanning old repo data
> > Indexed 2997 base nodes
> > Indexed 3001 filelist nodes
> > /var/ftp/.4/fedora-8/fedora/i386/./repodata/other.xml.gz:118813: 
> > parser error : Detected an entity reference loop
> > - revert the dao -&gt; tao change
> >                       ^
> > Traceback (most recent call last):
> >   File "/usr/share/createrepo/genpkgmetadata.py", line 722, in <module>
> >     main(sys.argv[1:])
> >   File "/usr/share/createrepo/genpkgmetadata.py", line 645, in main
> >     mdgen.doPkgMetadata(directory)
> >   File "/usr/share/createrepo/genpkgmetadata.py", line 161, in 
> > doPkgMetadata
> >     basefile, flfile, otherfile, opts)
> >   File "/usr/share/createrepo/readMetadata.py", line 41, in __init__
> >     self.scan()
> >   File "/usr/share/createrepo/readMetadata.py", line 64, in scan
> >     root = libxml2.parseFile(self.files['other']).getRootElement()
> >   File "/usr/lib/python2.5/site-packages/libxml2.py", line 1279, in 
> > parseFile
> >     if ret is None:raise parserError('xmlParseFile() failed')
> > libxml2.parserError: xmlParseFile() failed
> 
> IOW, the initial "full" createrepo run seems OK, the subsequent run with 
> "--update" is failed.
> 
> Any comments? Whether it is some bug in createrepo, or in some yum 
> components?
> 

it's a bug in createrepo and it has been fixed in upstream but not put
into a release, yet.

-sv




From csnook at redhat.com  Thu Oct  2 17:37:01 2008
From: csnook at redhat.com (Chris Snook)
Date: Thu, 02 Oct 2008 13:37:01 -0400
Subject: F10 Live CD possible bug
In-Reply-To: <4F549021-DD11-4A51-8F43-CA3C3F263CE2@gnat.ca>
References: <5F66C9D7-C19A-47F4-8783-F7E29992310B@gnat.ca>	<48E3F4E9.6000805@redhat.com>
	<4F549021-DD11-4A51-8F43-CA3C3F263CE2@gnat.ca>
Message-ID: <48E506BD.6020002@redhat.com>

Nathanael Noblet wrote:
> 
> On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:
> 
>> Nathanael Noblet wrote:
>>> Hello,
>>>  I downloaded the live cd of F10 beta. Booted and added the live_ram 
>>> option to the boot params. After copying the image to RAM I get the 
>>> following error on two machines, (Apple Mac Book, and Acer 3680).
>>> Done copying live image to RAM.
>>> eject: did not find a device /dev/root in /sys/block
>>> Bug in initramfs /init detected. Dropping to a shell. Good luck!
>>> sbin/real-init: line 7: plymouth: command not found
>>> I know I used that param for F9. Is it depreciated or is this a bug 
>>> needing filling?
>>
>> Assuming it does something different when you omit the option, that's 
>> a bug.  If we don't intend for it to work in F10, the option should be 
>> removed entirely, and ignored if passed by the user.
>>
> 
> Yeah if you remove the live_ram from the boot options. It boots...
> 
> 
> Is there a rationale for removing the option? It came in super useful 
> for me a month or so back. I can't remember the exact issue but saved 
> the day for me when I finally found it.

If it had been removed, it wouldn't do anything.  The fact that it's doing 
something indicates that it's expected to still work, but broken.  Please file a BZ.

-- Chris



From kwhiskerz at gmail.com  Thu Oct  2 17:54:32 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Thu, 02 Oct 2008 11:54:32 -0600
Subject: No X in F10 beta, rawhide...
References: <200810012230.27292.kwhiskerz@gmail.com>
	<op.uidr0slg4bfjir@cassej2t61>
	<a3c040240810012200q2bbbd399k1f5381994a93d435@mail.gmail.com>
Message-ID: <gc31sp$j12$1@ger.gmane.org>

This morning's updates fixed everything. I don't know whether it was the xorg i810 intel driver or what, but I am back to having 2 usable computers.

I tried putting i915.modeset=1 on the grub kernel boot line, but that gave me a moveable mouse pointer, no mouse buttons and no keyboard, and nothing was displayed in the plasma folder view widget. The system accepted no input whatsoever (not even Alt-SysRq - no keyboard).

I had to put nomodeset on the kernel boot line and now I am up and running again.

Thanks




From triad at df.lth.se  Thu Oct  2 19:33:06 2008
From: triad at df.lth.se (Linus Walleij)
Date: Thu, 2 Oct 2008 21:33:06 +0200 (CEST)
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <Pine.GSO.4.64.0810022130590.3191@igloo.df.lth.se>

On Wed, 1 Oct 2008, Jakub Jelinek wrote:

> I thought I'd share my modprobe and MAKEDEV speedup patches with
> a wider community so folks can experiment with them, especially seeing
> Mandriva folks playing with turning modprobe into a daemon because of its
> slowness.

GOOD WORK.

A common approach in the embedded community is to let go of modprobe 
altogether and only use compiled-in modules and the occasional insmod to 
speed things up. (Which is quite easy when you know your hardware, but 
also messy to maintain.)

With a sufficiently fast modprobe that need should go away. I hope we'll 
soon be there with these patches and perhaps a few more jumping in.

Linus



From dcbw at redhat.com  Thu Oct  2 19:34:54 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 02 Oct 2008 15:34:54 -0400
Subject: NetworkManager vs. sysconfig
In-Reply-To: <1222945415.26632.35.camel@perihelion.int.jonmasters.org>
References: <1222945415.26632.35.camel@perihelion.int.jonmasters.org>
Message-ID: <1222976094.12505.22.camel@72-58-93-37.area3.spcsdns.net>

On Thu, 2008-10-02 at 07:03 -0400, Jon Masters wrote:
> Hi folks,
> 
> I just installed a test server running F9. For once, I let
> NetworkManager run and left the install fairly alone. I statically
> configured a set of network settings in anaconda and those are present
> in the sysconfig network scripts. But NetworkManager decides it knows
> better and reconfigures the interface with DHCP anyway[0].

What version of NM are you running?  You'll want whatever is in
F9-updates, which should be svn4022 or later.

> How is static interface config supposed to work with NetworkManager?
> Does this actually work in F9 today?

nm-system-settings reads ifcfg files and if those files are minimally
valid provides those connections to NM, which uses them.

If that's not working for you and you have latest F9 updates installed
(again, svn4022 or later) then I'd love to see your ifcfg-eth0 file.
Please send and I'll be sure to fix whatever's wrong!

> [0] It actually does this even when you create a new "wired network" in
> NetworkManager with the correct config (so now you have it in two
> places) - it always wants to use its own "Auto eth0" regardless.

Looks like the system settings service can't parse the ifcfg file; and
if there aren't any valid ethernet connections on the system (unmanaged
devices are counted as valid) then nm-system-settings provides an "auto
ethernet" connection so that you'll at least get some connectivity when
you plug in the cable.

Dan




From vonbrand at inf.utfsm.cl  Thu Oct  2 21:20:50 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 02 Oct 2008 17:20:50 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
Message-ID: <200810022120.m92LKo3B006975@laptop14.inf.utfsm.cl>

Stephen John Smoogen <smooge at gmail.com> wrote:

[...]

> I won't say you are whining.. but you are the first systems
> administrator I have met in several years who hasn't had
> /usr/sbin:/sbin in their default path.

So you've never met me (or one of the lots of people that I've trained over
the years)...

>                                        You sure they didn't make you a
> manager and didn't tell you?

They did, but had the good taste to ask me nicely ;-)
-- 
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 2340000       Fax:  +56 32 2797513



From vonbrand at inf.utfsm.cl  Thu Oct  2 21:21:52 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 02 Oct 2008 17:21:52 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081001035116.GA21890@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
	<20081001035116.GA21890@jadzia.bu.edu>
Message-ID: <200810022121.m92LLqIn006989@laptop14.inf.utfsm.cl>

Matthew Miller <mattdm at mattdm.org> wrote:
> On Tue, Sep 30, 2008 at 08:52:10PM -0600, Stephen John Smoogen wrote:
> > I won't say you are whining.. but you are the first systems
> > administrator I have met in several years who hasn't had
> > /usr/sbin:/sbin in their default path. You sure they didn't make you a
> > manager and didn't tell you?

> Heh. Well, I also have had sudo compiled with /sbin and /usr/sbin in its
> secure path, so sudo command (and sudo com[tab] with bash_completion) has
> worked correctly for me for years. And if there's an admin command that I'm
> for some reason running not as root it should a) be moved out of sbin or b)
> I probably at least want to think about it and so typing the path doesn't
> hurt.
> 
> > I think the chance for putting it back is still there.. if someone is
> > willing to do the work on the hard but correct way? I think it was
> > crickets the last couple of times when volunteers were asked for that.
> 
> Sure, I'm willing to work on it.

Thanks!
-- 
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 2340000       Fax:  +56 32 2797513



From dchen at redhat.com  Thu Oct  2 23:29:24 2008
From: dchen at redhat.com (Ding-Yi Chen)
Date: Fri, 03 Oct 2008 09:29:24 +1000
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E47FF3.5060600@redhat.com>
References: <48E45455.7000203@redhat.com>
	<1222929670.4697.31.camel@localhost.localdomain>
	<48E47FF3.5060600@redhat.com>
Message-ID: <1222990164.4354.8.camel@dhcp-0-207.bne.redhat.com>


? ??2008-10-02 ? 18:01 +1000?Sean Flanigan ???
> Ding-Yi Chen wrote:
> > The pseudo locale is intriguing, and I assume it helps at some degree.
> > However, this approach does have its own limitation:
> 
> Of course, pseudo-localisation testing is not the same as localisation
> testing in every Fedora language, but it's something!
> 
> > 1. Lack of font support: as the attachment "lack_of_font.png" shows, the
> > pseudo locale might be rendered useless if all developers can see are
> > unicode boxes. :-P 
> 
> That tells me that the developers should install better fonts, or how
> else can they test an internationalised application?  But to be honest,
> I probably shouldn't have used
> http://en.wikipedia.org/wiki/Mathematical_alphanumeric_symbols since
> they're only guaranteed to be available in certain mathematical fonts
> such as Code2001.  I really need to find some latinesque characters that
> don't come from the BMP, nor from the maths section!
> 
> Apparently Zimbra loses (without trace) the 'e' characters in my
> pseudotranslation.  Bad Zimbra!
> 
Other blames should go to Evolution. I re-open the message with web
client (Mine-field) and there is no boxes. 

Ah, it is a good example that pseudo locale do find a bug in
Evolution. :-)

> As long as it's only a couple of characters, I think having some unusual
> characters is okay, since you can still work out what's going on, at
> least enough to resolve the problem by installing more fonts.
> 
> > Perhaps we should specifiy the minimal font set as
> > remedy.
> 
> Before running pseudo-localised apps, you mean?  Good idea.  I found a
> webapp that gives the names of unicode characters -
> <http://rishida.net/scripts/uniview/uniview.php>.  Just paste text into
> the "cut & paste" field and hit enter.

gucharmap can do that as well. :-)




From sflaniga at redhat.com  Fri Oct  3 00:12:44 2008
From: sflaniga at redhat.com (Sean Flanigan)
Date: Fri, 03 Oct 2008 10:12:44 +1000
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E4D40A.6000402@redhat.com>
References: <48E45455.7000203@redhat.com> <48E4D40A.6000402@redhat.com>
Message-ID: <48E5637C.7040901@redhat.com>

Ulrich Drepper wrote:
> Sean Flanigan wrote:
>> Would there be any interest in getting something like this into glibc?
> 
> Hell, no.  There is no room for testing code in the runtime.  

I find it hard to believe that there is no testing code in the runtime.
 Even OS kernels have functions for debug messages.

> And I see
> absolutely no need whatsoever to have it there.  It seems to be the
> wrong place altogether.  

Perhaps it is; I'm mostly a Java programmer, but in Java I'd be looking
to hook into the ResourceBundle class, which is responsible for fetching
translated strings.

I'd much prefer to keep my grubby mitts out of glibc, but I was given to
understand that the gettext() calls at runtime are actually implemented
in glibc (rather than say "libgettext").  If that's wrong, please
enlighten me!

> For PO files you create appropriate
> translations.  For the locales themselves you derive a file from the
> existing locales, compile it using localedef, and just use it.
> 
> None of the locale code is hardcoded in glibc.  Why should this?

Is the implementation of "fetch translations from MO files under
/usr/share/locale/" hard-coded?  If there's already a nice programmatic
hook I could use, even better.  If I could register locale-specific
overrides of gettext(), I could add any number of dynamically generated
locales.

A gettext() hook could also be used to fetch translations from other
sources, such as a shared, up-to-date, translation database.  I think
that has the potential to be useful to a lot of people, not just
developers and testers.

It doesn't really make sense to generate thousands of pseudo PO files,
and compile them into static MOs, when all the required data (ie English
text) is available at runtime.

Let me change my question then.  How would people feel about having a
hook to override the behaviour of gettext() in a system-wide fashion?

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

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

From sflaniga at redhat.com  Fri Oct  3 01:05:01 2008
From: sflaniga at redhat.com (Sean Flanigan)
Date: Fri, 03 Oct 2008 11:05:01 +1000
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <dc4a4b079288836c1efc2bda99e4939d.squirrel@arekh.dyndns.org>
References: <48E45455.7000203@redhat.com>	<1222929670.4697.31.camel@localhost.localdomain>	<48E47FF3.5060600@redhat.com>
	<dc4a4b079288836c1efc2bda99e4939d.squirrel@arekh.dyndns.org>
Message-ID: <48E56FBD.4020305@redhat.com>

Nicolas Mailhot wrote:

>> But how can I find the name of the font which provides a given
>> character?
> 
> Answer in the fonts SIG wiki
> http://fedoraproject.org/wiki/Category:Fonts_SIG
> 
> Looking at your interests and questions, you should really read it and
> join the SIG (same for other interested people)

Thanks Nicolas, but I can't make much sense of that wiki.  I gather that
it covers the problem of "where can I find a font with character X?",
which would be useful, but in this case I want to know "which of my
current fonts is providing the character X?"  Or when I choose the font
"Monospace 10", which font *really* provides the character X?  (Which
probably depends on whether I'm using an X application, a Java Swing app
or a Java SWT app...)

I guess I should be reading up on font substitution.

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

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

From jonathan at jonmasters.org  Fri Oct  3 04:58:09 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Fri, 03 Oct 2008 00:58:09 -0400
Subject: serial console config
In-Reply-To: <20081002135647.GA2859@nostromo.devel.redhat.com>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
	<20081002135647.GA2859@nostromo.devel.redhat.com>
Message-ID: <1223009889.28226.5.camel@perihelion.int.jonmasters.org>

On Thu, 2008-10-02 at 09:56 -0400, Bill Nottingham wrote:
> Jon Masters (jonathan at jonmasters.org) said: 
> > What's the recommended way to configure a serial console in Fedora 9
> > with upstart? /etc/event.d/serial requires some fedora-centric event to
> > be emitted but I'm not sure where this is supposed to be generated.
> 
> >From udev.
> 
> > <aside> time was, you could just setup a serial console in 3 seconds, I
> > guess I'm pining for the good old days...or some documentation.
> 
> cp /etc/event.d/tty1 /etc/event.d/my_serial_console. Edit as appropriate.

Ah, thanks for the replies guys but I'm not sure my original point was
clear. I can fudge this as much as the next guy but there's a designated
serial file in that event.d directory that is clearly supposed to be
getting some kind of event trigger to start the console. Consequently,
there's supposedly some new "Fedora way" to do serial consoles that
isn't locatable in Google, nobody here has mentioned, and is
undocumented. If nobody knows, why does that file exist?

So my question was more of a WTF about that serial file.

Jon.




From jonathan at jonmasters.org  Fri Oct  3 05:03:44 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Fri, 03 Oct 2008 01:03:44 -0400
Subject: SELinux - copying ISO file content
Message-ID: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>

Hi folks,

I'm not *exactly* ranting about SELinux again, but I have a question...

Suppose one mounts an ISO image (let's say the Fedora 9 DVDs) via
loopback and wants to copy the content to a local disk directory. One
might do something like:

$ mount -o loop Fedora-9-i386-DVD.iso /mnt

And then one might legitimately expect to be able to copy the content
of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
suppose that one is running SELinux in enforcing mode, then this will
fail because the contexts differ in this operation. Then, one will
likely quickly become severely annoyed and frustrated with SELinux,
simply setting it permissive for the duration of the operation...

...but how is the *average* user supposed to do this copy?

Jon.




From tim.lauridsen at googlemail.com  Fri Oct  3 05:26:31 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Fri, 03 Oct 2008 07:26:31 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <48E48E04.1080906@students.iiit.ac.in>
References: <48E48E04.1080906@students.iiit.ac.in>
Message-ID: <48E5AD07.2030508@googlemail.com>

Kulbir Saini wrote:
> Hi list,
>
>    Whenever I try a new version of Fedora, the first problem I face is 
> setting the proxy. It seems for almost every application, I have to 
> specify proxy at a different place. We have this "System -> 
> Preferences -> Internet and Network -> Network Proxy" app to specify 
> proxy settings. But I wonder if there is some application which obeys 
> these settings.
>
> Examples:
>
>    1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above 
> specified location. It has to be set via proxy option in yum.conf or 
> http_proxy/ftp_proxy env variable.
The problem is that the above is Gnome thing, so it make sense for gnome 
apps to use it, but yum a low level app there should work on all 
systems, also sytems with no GUI. 

Tim



From Christian.Iseli at unil.ch  Fri Oct  3 07:15:11 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Fri, 3 Oct 2008 09:15:11 +0200
Subject: SELinux - copying ISO file content
In-Reply-To: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
Message-ID: <20081003091511.73410983@ludwig-alpha.unil.ch>

On Fri, 03 Oct 2008 01:03:44 -0400, Jon Masters wrote:
> ...but how is the *average* user supposed to do this copy?

I have a Fedora 9 running under VirtualBox and am basically wondering
the same thing about the SharedFolder thing.  When one simply does a
$ mount -t vboxsf VMShared /mnt
then a subsequent attempt to copy something in there yields:
$ mv gr.078212.108v2.pdf /mnt
mv: cannot create regular file `/mnt/gr.078212.108v2.pdf': Permission denied
and selinuxtroubleshootd pops up (which is nice).

And then there are further hickups if you leave the filesystem mounted
overnight: updatedb and (I think) logwatch cron jobs are also getting
denials.

This can all be fixed using audit2allow etc., as explained in the
setroubleshootd output, but...

Maybe some nice little script, to do selinux tweaks, that could be run
after mounting a new filesystem would help ?

Cheers,
					Christian



From nicolas.mailhot at laposte.net  Fri Oct  3 07:20:30 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 3 Oct 2008 09:20:30 +0200 (CEST)
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E56FBD.4020305@redhat.com>
References: <48E45455.7000203@redhat.com>
	<1222929670.4697.31.camel@localhost.localdomain>
	<48E47FF3.5060600@redhat.com>
	<dc4a4b079288836c1efc2bda99e4939d.squirrel@arekh.dyndns.org>
	<48E56FBD.4020305@redhat.com>
Message-ID: <4bd55c7bfea1743577e7c148154072ef.squirrel@arekh.dyndns.org>



Le Ven 3 octobre 2008 03:05, Sean Flanigan a ?crit :
> Nicolas Mailhot wrote:
>
>>> But how can I find the name of the font which provides a given
>>> character?
>>
>> Answer in the fonts SIG wiki
>> http://fedoraproject.org/wiki/Category:Fonts_SIG
>>
>> Looking at your interests and questions, you should really read it
>> and
>> join the SIG (same for other interested people)
>
> Thanks Nicolas, but I can't make much sense of that wiki.  I gather
> that
> it covers the problem of "where can I find a font with character X?",
> which would be useful, but in this case I want to know "which of my
> current fonts is providing the character X?"

I guess you didn't spend the time to read it all. Please do.
http://fedoraproject.org/wiki/Identifying_fonts

-- 
Nicolas Mailhot



From asgeirf at redhat.com  Fri Oct  3 07:54:26 2008
From: asgeirf at redhat.com (Asgeir Frimannsson)
Date: Fri, 3 Oct 2008 03:54:26 -0400 (EDT)
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <28741995.3551223019840423.JavaMail.asgeirf@localhost.localdomain>
Message-ID: <31390880.3571223020324059.JavaMail.asgeirf@localhost.localdomain>

----- "Sean Flanigan" <sflaniga at redhat.com> wrote:
> Ulrich Drepper wrote:
> > Sean Flanigan wrote:
> >> Would there be any interest in getting something like this into
> glibc?
> > 
> > Hell, no.  There is no room for testing code in the runtime.  
> 
<snip>
> Is the implementation of "fetch translations from MO files under
> /usr/share/locale/" hard-coded?  If there's already a nice
> programmatic
> hook I could use, even better.  If I could register locale-specific
> overrides of gettext(), I could add any number of dynamically
> generated
> locales.

It is set by bindtextdomain().

Somewhat related, look at a previous discussion relating to Ubuntu's patched glibc for supporting language-packs:
http://sources.redhat.com/ml/libc-alpha/2005-03/msg00105.html

> A gettext() hook could also be used to fetch translations from other
> sources, such as a shared, up-to-date, translation database.  I think
> that has the potential to be useful to a lot of people, not just
> developers and testers.
> 
> It doesn't really make sense to generate thousands of pseudo PO
> files,
> and compile them into static MOs, when all the required data (ie
> English
> text) is available at runtime.
> 
> Let me change my question then.  How would people feel about having a
> hook to override the behaviour of gettext() in a system-wide fashion?

I guess you could experiment with LD_PRELOAD for this. Tim Foster experimented with this a while a go. 
http://blogs.sun.com/timf/entry/how_much_translation_do_you

cheers,
asgeir



From hughsient at gmail.com  Fri Oct  3 08:15:36 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 03 Oct 2008 09:15:36 +0100
Subject: Uniform Proxy Settings
In-Reply-To: <48E5AD07.2030508@googlemail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com>
Message-ID: <1223021736.3243.7.camel@hughsie-laptop>

On Fri, 2008-10-03 at 07:26 +0200, Tim Lauridsen wrote:
> >    1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above 
> > specified location. It has to be set via proxy option in yum.conf
> or 
> > http_proxy/ftp_proxy env variable.
> The problem is that the above is Gnome thing, so it make sense for
> gnome 
> apps to use it, but yum a low level app there should work on all 
> systems, also sytems with no GUI. 

If you're using PackageKit and gnome-packagekit, the this will pass the
proxy settings down from your session to yum.

Richard.




From pertusus at free.fr  Fri Oct  3 08:31:31 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 3 Oct 2008 10:31:31 +0200
Subject: proposal for make help chain-build text
In-Reply-To: <20080928122103.GA2728@free.fr>
References: <20080928122103.GA2728@free.fr>
Message-ID: <20081003083131.GC3270@free.fr>

On Sun, Sep 28, 2008 at 02:21:03PM +0200, Patrice Dumas wrote:
> Hello,
> 
> Here is a proposal for the result of make help for the chain-build
> target, what I changed relates with : and prallel builds:
> 
>         chain-build             Build current package in order with
> other packages
>                 example:  make chain-build CHAIN='libwidget libgizmo'
>                 The current package is added to the end of the CHAIN list.
>                 Colons (:) can be used in the CHAIN parameter to define 
>                 parallely built package groups.
>                 Packages in a single group will be built in parallel,
>                 and all packages in a group must build successfully and 
>                 populate the repository before the next group will begin building. 
>                 For example
>                 make chain-build CHAIN='libwidget libaselib : libgizmo
> :'
>                 will cause libwidget and libaselib to be build in parallel, 
>                 followed by libgizmo and then the current directory package.
>                 If no groups are defined, packages will be built sequentially.

There were no negative nor positive comments. Who's in charge here?

--
Pat



From paul at city-fan.org  Fri Oct  3 08:36:58 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 03 Oct 2008 09:36:58 +0100
Subject: proposal for make help chain-build text
In-Reply-To: <20081003083131.GC3270@free.fr>
References: <20080928122103.GA2728@free.fr> <20081003083131.GC3270@free.fr>
Message-ID: <48E5D9AA.9060505@city-fan.org>

Patrice Dumas wrote:
> On Sun, Sep 28, 2008 at 02:21:03PM +0200, Patrice Dumas wrote:
>> Hello,
>>
>> Here is a proposal for the result of make help for the chain-build
>> target, what I changed relates with : and prallel builds:
>>
>>         chain-build             Build current package in order with
>> other packages
>>                 example:  make chain-build CHAIN='libwidget libgizmo'
>>                 The current package is added to the end of the CHAIN list.
>>                 Colons (:) can be used in the CHAIN parameter to define 
>>                 parallely built package groups.
>>                 Packages in a single group will be built in parallel,
>>                 and all packages in a group must build successfully and 
>>                 populate the repository before the next group will begin building. 
>>                 For example
>>                 make chain-build CHAIN='libwidget libaselib : libgizmo
>> :'
>>                 will cause libwidget and libaselib to be build in parallel, 
>>                 followed by libgizmo and then the current directory package.
>>                 If no groups are defined, packages will be built sequentially.
> 
> There were no negative nor positive comments. Who's in charge here?

Test looks good to me, and certainly explains things better than the 
existing text.

Paul.



From pertusus at free.fr  Fri Oct  3 08:45:26 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 3 Oct 2008 10:45:26 +0200
Subject: rpmbuild post install checks
In-Reply-To: <200809261113.44281.sgrubb@redhat.com>
References: <200809261113.44281.sgrubb@redhat.com>
Message-ID: <20081003084526.GD3270@free.fr>

On Fri, Sep 26, 2008 at 11:13:44AM -0400, Steve Grubb wrote:
> Hi,
> 
> can look for problems at build time. The intent is to find problems in local 
> builds before pushing it out to Koji for an official build.
> 
> Comments?

You should make sure that you don't overlap with what rpmlint does, that
it only add checks that rpmlint doesn't achieve itself.


In the manpage encodings check, it seems that you don't take into
account the encoding specification that appears in some man page
directories, like
/usr/share/man/it.ISO8859-1/
Maybe these doesn't make sense, however.

--
Pat



From forum at hubbitus.com.ru  Fri Oct  3 09:57:26 2008
From: forum at hubbitus.com.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Fri, 03 Oct 2008 13:57:26 +0400
Subject: Uniform Proxy Settings
In-Reply-To: <48E5AD07.2030508@googlemail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com>
Message-ID: <48E5EC86.8050508@ru.bir.ru>

Tim Lauridsen ?????:
> Kulbir Saini wrote:
>> Hi list,
>>
>> Whenever I try a new version of Fedora, the first problem I face is 
>> setting the proxy. It seems for almost every application, I have to 
>> specify proxy at a different place. We have this "System -> 
>> Preferences -> Internet and Network -> Network Proxy" app to specify 
>> proxy settings. But I wonder if there is some application which obeys 
>> these settings.
>>
>> Examples:
>>
>> 1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above 
>> specified location. It has to be set via proxy option in yum.conf or 
>> http_proxy/ftp_proxy env variable.
> The problem is that the above is Gnome thing, so it make sense for 
> gnome apps to use it, but yum a low level app there should work on all 
> systems, also sytems with no GUI.
> Tim
>
Yes, but it is no problem for yum optionally check this settings if it 
is available in system, right?



From kulbirsaini at students.iiit.ac.in  Fri Oct  3 10:45:44 2008
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Fri, 03 Oct 2008 16:15:44 +0530
Subject: Uniform Proxy Settings
In-Reply-To: <48E5AD07.2030508@googlemail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com>
Message-ID: <48E5F7D8.8040104@students.iiit.ac.in>



Tim Lauridsen wrote:
> Kulbir Saini wrote:
>> Hi list,
>>
>> Whenever I try a new version of Fedora, the first problem I face is 
>> setting the proxy. It seems for almost every application, I have to 
>> specify proxy at a different place. We have this "System -> 
>> Preferences -> Internet and Network -> Network Proxy" app to specify 
>> proxy settings. But I wonder if there is some application which obeys 
>> these settings.
>>
>> Examples:
>>
>> 1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above specified 
>> location. It has to be set via proxy option in yum.conf or 
>> http_proxy/ftp_proxy env variable.
> The problem is that the above is Gnome thing, so it make sense for gnome 
> apps to use it, but yum a low level app there should work on all 
> systems, also sytems with no GUI.

    My objective was not to blame Yum or revisor or whatever else. I was 
blaming the proxy setting system we have.

> Tim
> 

-- 
---------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Web-Blog: http://fedora.co.in/

IRC nick : generalBordeaux
Channels : #fedora, #fedora-devel, #yum on freenode

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From rawhide at fedoraproject.org  Fri Oct  3 10:50:54 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri,  3 Oct 2008 10:50:54 +0000 (UTC)
Subject: rawhide report: 20081003 changes
Message-ID: <20081003105054.963611F8263@releng2.fedora.phx.redhat.com>

New package DeviceKit-power
        Power Management Service
New package liveusb-creator
        A liveusb creator
New package mirrormanager
        Fedora mirror management system
New package perl-Module-Math-Depends
        Convenience object for manipulating module dependencies
New package perl-PAR
        Perl Archive Toolkit
Updated Packages:

Macaulay2-1.1-2.fc10
--------------------
* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.1-2
- respin (factory/libfac)


amarok-1.92-2.fc10
------------------
* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.92-2
- BR: gtk2-devel (gdk-pixbuf ipod artwork support)

* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.92-1
- amarok-1.92 (amarok2 beta2)


amqp-1.0.700546-1.fc10
----------------------
* Thu Oct  2 18:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0:1.0.700546-1
- Rebased to svn rev 700546


arm-gp2x-linux-gcc-4.1.2-9.fc10
-------------------------------
* Thu Oct  2 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 4.1.2-8
- Fix FTBFS (rh 464988)


automake15-1.5-25
-----------------
* Thu Oct  2 18:00:00 2008 Karsten Hopp <karsten at redhat.com> 1.5-25 
- fix build error

* Mon Jul 14 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.5-24
- fix patch2 to apply with fuzz=0
- fix license tag


bluez-gnome-1.7-2.fc10
----------------------
* Thu Oct  2 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.7-2
- Remove the X-GNOME-NetworkSettings category from the
  preferences' desktop file, it makes the prefs show up in
  two places in the menus (#465180)


bouncycastle-1.41-1.fc10
------------------------
* Thu Oct  2 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1.41-1
- Import Bouncy Castle 1.41.
- Resolves: rhbz#465203


cairo-dock-1.6.3-0.1.svn1329_trunk.fc10
---------------------------------------
* Thu Oct  2 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1329


chess-1.0-19.fc10
-----------------
* Fri Sep 19 18:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 1.0-19
- Port to OGRE 1.6


deskbar-applet-2.24.0-2.fc10
----------------------------
* Thu Oct  2 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 2.24.0-2
- Add gnome-python2-gnome{desktop,keyring} to the Requires.
  This fixes #465146 and #460026.


e2fsprogs-1.41.2-1.fc10
-----------------------
* Thu Oct  2 18:00:00 2008 Eric Sandeen <sandeen at redhat.com> 1.41.2-1
- New upstream version
- Updated default dir hash (half_md4) for better perf & fewer collisions
- Fixed ext4 online resizing with flex_bg
- ext4 journal now in extents format and in middle of filesystem
- fix unreadable e2image files
- fix file descriptor leak in libcom_err (#464689)

* Sat Aug 23 18:00:00 2008 Eric Sandeen <sandeen at redhat.com> 1.41.0-2
- Don't check the group checksum when !GDT_CSUM (#459875)


ekiga-3.0.0-3.fc10
------------------
* Thu Oct  2 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.0-3
- require dbus


ember-0.5.4-2.fc10
------------------
* Thu Oct  2 18:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.4-2
- Update for new OGRE


ember-media-0.5.4-3
-------------------
* Thu Oct  2 18:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.4-3
- Update for new OGRE


expendable-0.0.3-4.fc10
-----------------------
* Thu Oct  2 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 0.0.3-4
- Fixed accounts tree view packing.


f-spot-0.4.4-5.fc10
-------------------
* Thu Oct  2 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.4.4-5
- Use a standard icon name instead of a non-existing one


factory-3.0.4-1.fc10
--------------------
* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 3.0.4-1
- factory-3.0.4


fedora-logos-9.99.4-2.fc10
--------------------------
* Thu Oct  2 18:00:00 2008 Matthias Clasen  <mclasen at redaht.com> - 9.99.4-2
- Don't ship the screensaver desktop file thats in fedora-screensaver-theme


fedora-release-9.92-1
---------------------
* Thu Oct  2 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 9.92-1
- Make the release version correct for 10-Beta.


fedora-screensaver-theme-1.0.0-3.fc10
-------------------------------------
* Thu Oct  2 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1.0.0-3
- require system-logos


fet-5.7.0-1.fc10
----------------
* Thu Oct  2 18:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 5.7.0-1
- new upstream release
- some UTF-8 fixes now upstream


foomatic-3.0.2-67.fc10
----------------------
* Thu Oct  2 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 3.0.2-67
- Rebuilt (bug #465298).


fwbackups-1.43.2-2.fc10
-----------------------
* Thu Oct  2 18:00:00 2008 Stewart Adam <s.adam at diffingo.com> 1.43.2-2
- Bump for retag

* Thu Oct  2 18:00:00 2008 Stewart Adam <s.adam at diffingo.com> 1.43.2-1
- Update to 1.43.2 final


gdm-2.24.0-8.fc10
-----------------
* Fri Oct  3 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1:2.24.0-8
- Don't show a non-functional help menuitem


gkrellm-2.3.1-6.fc10
--------------------
* Thu Oct  2 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.3.1-6
- Fix a small memory leak (which would accumulate over time) thanks to
  Daniel Colascione for the patch (rh 464040)


gnome-session-2.24.0-6.fc10
---------------------------
* Fri Oct  3 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-6
- Fix missing translations in the capplet
- Fix small UI issues in the capplet


grip-3.2.0-23.fc10
------------------
* Thu Oct  2 18:00:00 2008 Adrian Reber <adrian at lisas.de> - 1:3.2.0-23
- fixed "German Umlauts are shown incorrectly" (#459394)
  (not converting de.po and fr.po to UTF-8 anymore)


gtk+-1.2.10-66.fc10
-------------------
* Thu Oct  2 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 1:1.2.10-66
- rebase the ahiguti patch

* Thu Oct  2 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 1:1.2.10-65
- remove x_ldflags from gtk-config (#462650)


gwibber-0.7-6.102bzr.fc10
-------------------------
* Thu Oct  2 18:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.7-6.102bzr
- Use the system python-simplejson rather than the one included in the 
  tarball (#464727)


ifplugd-0.28-12.fc10
--------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.28-12
- Fix Patch0:/%patch mismatch.


indent-2.2.10-2.fc10
--------------------
* Thu Oct  2 18:00:00 2008 Roman Rakus <rrakus at redhat.com> - 2.2.10-2
- Cleared man patch to comply with fuzz=0
  Resolves: #465015


isdn4k-utils-3.2-60.fc10
------------------------
* Thu Oct  2 18:00:00 2008 Than Ngo <than at redhat.com> 3.2-60
- rebuild

* Tue Aug  5 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 3.2-59
- fix license tag


kernel-2.6.27-0.382.rc8.git4.fc10
---------------------------------
* Thu Oct  2 18:00:00 2008 Kyle McMartin <kyle at redhat.com>
- Linux 2.6.27-rc8-git3
- Re-enable e1000e driver, corruption prevention fix is upstream

* Thu Oct  2 18:00:00 2008 Dave Jones <davej at redhat.com>
- Add the ability to turn FIPS-compliant mode on or off at boot.

* Thu Oct  2 18:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.27-rc8-git4


lftp-3.7.4-1.fc10
-----------------
* Mon Sep 29 18:00:00 2008 Jiri Skala <jskala at redhat.com> - 3.7.4-1
- Resolves: #464420 re-base to 3.7.4
- replaced usage of OpenSSL by GNUTLS due to license conflict


libaio-0.3.107-4.fc10
---------------------

libcapseo-0.2.0-0.2.20080603gita6ec446.fc10
-------------------------------------------
* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.2.0-0.2.20080603gita6ec446
- increment Release (#465297)

* Tue Jul  1 18:00:00 2008 Shawn Starr <spstarr at fedoraproject.org> 0.2.0-0.1.20080603gita6ec446
- Upstream snapshot, change GPLv2 to GPLv3. 
- Fix minor configure script issue.


libcdio-0.80-4.fc10
-------------------
* Thu Oct  2 18:00:00 2008 Adrian Reber <adrian at lisas.de> - 0.80-4
- fixed #462125 (Multilib conflict) - this time for real


libfac-3.0.4-1.fc10
-------------------
* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 3.0.4-1
- libfac-3.0.4


libgdiplus-2.0-4.fc10
---------------------
* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
- Bump to RC4

* Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-3
- Bump to RC3


libpciaccess-0.10.3-3.fc10
--------------------------
* Thu Aug 28 18:00:00 2008 Adam Jackson <ajax at redhat.com> 0.10.3-3
- Rediff for --fuzz=0


libxfcegui4-4.4.2-3.fc10
------------------------
* Fri Oct  3 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.2-3
- Make xfce-exec use Thunar


libxml2-2.7.1-2.fc10
--------------------
* Thu Oct  2 18:00:00 2008 Daniel Veillard <veillard at redhat.com> 2.7.1-2.fc10
- fix a nasty bug in 2.7.x, http://bugzilla.gnome.org/show_bug.cgi?id=554660


liferea-1.4.19-1.fc10
---------------------
* Thu Oct  2 18:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 1.4.19-1
- New upstream release


lout-3.37-3.fc10
----------------
* Thu Oct  2 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.37-3
- don't build the docs in koji due to random ps2pdf segfault

* Wed Oct  1 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.37-2
- try using ps2pdf

* Wed Oct  1 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 3.37-1
- update to 3.37


malaga-suomi-voikko-1.2-1.fc10
------------------------------
* Thu Oct  2 18:00:00 2008 - Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> 1.2-1
- Suomi-malaga 1.2
  - RC1 released as stable


maxima-5.16.3-3.fc10
--------------------
* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 5.16.3-3
- respin (sbcl)


mod_mono-2.0-4.fc10
-------------------
* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
- bump to RC4

* Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-3
- bump to RC3


mono-2.0-10.fc10
----------------
* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-10
- bump to RC4

* Sun Sep 28 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-9
- backported binaryserialisation and datatable patches
- backported stringreplace optimisation
- bump to RC3


mono-basic-2.0-4.fc10
---------------------
* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
- bump to RC4

* Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-3
- bump to RC3
- alter excludearch to exclusivearch
- alter version number in pc file


mono-tools-2.0-7.fc10
---------------------
* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.0-7
- bump to rc3

* Wed Oct  1 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.0-6
- bump to rc3


monodoc-2.0-5.fc10
------------------
* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-5
- bump to RC4

* Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
- bump to RC 3


ncurses-5.6-20.20080927.fc10
----------------------------
* Thu Oct  2 18:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> 5.6-20.20080927
- update to patch 20080927


ogre-1.6.0-0.1.rc1.fc10
-----------------------
* Sun Sep 21 18:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 1.6.0-0.1.rc1
- New upstream release 1.6.0rc1
- Disabling broken OpenEXR plugin, it is not updated for long time and doesn't
  compile. FreeImage now have EXR support
- Updated private GLEW sources to 1.5.0 due to license issues and compiling
  against it instead of system ones, as it is patched by upstream


openbox-3.4.7.2-6.fc10
----------------------
* Thu Oct  2 18:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> - 3.4.7.2-6
- Drop gnome session script (gnome-session no longer supports $WINDOW_MANAGER)
- Add application desktop file to allow starting openbox in gnome-session
  when configured in gconf


openobex-1.3-15.fc10
--------------------
* Thu Oct  2 18:00:00 2008 Jiri Moskovcak <jmoskovc at redhat.com> 1.3.14
- bump release

* Thu Oct  2 18:00:00 2008 Jiri Moskovcak <jmoskovc>@redhat.com> 1.3.15
- rebuilt against new bluez-libs


perl-PAR-Dist-0.34-2.fc10
-------------------------
* Thu Sep 25 18:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> 0.34-2
- forgot apply source

* Thu Sep 25 18:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> 0.34-1
- update to 0.34 -> it was needed for perl-PAR


perl-Test-AutoBuild-1.2.2-6.fc10
--------------------------------
* Thu Oct  2 18:00:00 2008 Daniel P. Berrange <berrange at redhat.com> - 1.2.2-6.fc10
- Avoid empty debuginfo file (rhbz #465136)


preupgrade-0.9.8-2.fc10
-----------------------
* Thu Oct  2 18:00:00 2008 Will Woods <wwoods at redhat.com> - 0.9.8-2
- Clear cache after user decides not to resume an old run
- Add Fedora 10 Beta to releases.list


python-Coherence-0.5.8-1.fc10
-----------------------------
* Tue Jul 15 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.5.8-1
- Update to 0.5.8.
- Don't include new "misc" directory, as its location is ugly!
- Don't include applet-coherence as it probably requires the "misc" directory.
- Remove all reqs but python-configobj, as it seems to be the only one left.


python-imaging-1.1.6-12.fc10
----------------------------
* Thu Oct  2 18:00:00 2008 Jos?? Matos <jamatos[AT]fc.up.pt> - 1.1.6-12
- all patches are applied with -p1

* Thu Oct  2 18:00:00 2008 Jos?? Matos <jamatos[AT]fc.up.pt> - 1.1.6-11
- rebuild to avoid the patches fuzziness (#464984)


python-markdown2-1.0.1.11-1.fc10
--------------------------------
* Wed Oct  1 18:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 1.0.1.11-1
- Update to 1.0.11, also fixes the syntax_color test for the latest
  Pygments (should fix FTBFS bug 465049).

* Fri Sep 26 18:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 1.0.1.10-1
- Update to 1.0.1.10.


python-qpid-0.3.700546-1.fc10
-----------------------------
* Thu Oct  2 18:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.700546-1
- Rebased to svn revision 700546


qpidc-0.3.700546-1.fc10
-----------------------
* Thu Oct  2 18:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.3.700546-1
- Rebased to svn revision 700546

* Thu Sep 11 18:00:00 2008 Andrew Stitcher <astitcher at redhat.com> - 0.3.694455-1
- Add new packages for client & broker rdma
- Move cluster plugin into its own package
- Reflect new naming of plugins


sbcl-1.0.21-1.fc10
------------------
* Thu Oct  2 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0.21-1
- sbcl-1.0.21
- common-lisp-controller bits f10+ only (for now)
- drop never-used min_bootstrap crud


shared-mime-info-0.51-3.fc10
----------------------------
* Thu Oct  2 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.51-3
- Use evince, not tetex-xdvi.desktop for DVI files (#465242)


vegastrike-0.5.0-5.fc10
-----------------------
* Thu Oct  2 18:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 0.5.0-5
- Rebuild for new ogre


veusz-1.1-3.fc10
----------------
* Thu Oct  2 18:00:00 2008 Jeremy Sanders <jeremy at jeremysanders.net> - 1.1-3
- Got email address wrong - bumping again

* Thu Oct  2 18:00:00 2008 Jeremy Sanders <jeremy at jeremysanders.net> - 1.1-2
- Forgot to add changelog for previous entry. Bumping.

* Thu Oct  2 18:00:00 2008 Jeremy Sanders <jeremy at jeremysanders.net> - 1.1-1
- Updated to Veusz 1.1


warzone2100-2.1.0-0.6.beta5.fc10
--------------------------------
* Thu Oct  2 18:00:00 2008 Karol Trzcionka <karlikt at gmail.com> - 2.1.0-0.6.beta5
- Update to v2.1.0-beta2


wxMaxima-0.7.5-2.fc10
---------------------
* Thu Oct  2 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> 0.7.5-2
- build sparcv9


x3270-3.3.6-6.fc10
------------------
* Thu Oct  2 18:00:00 2008 Karsten Hopp <karsten at redhat.com> 3.3.6-6
- update redhat patch for fuzz=0 (#465087)


xfce4-taskmanager-0.4.1-1.fc10
------------------------------
* Tue Sep 30 18:00:00 2008 Christoph Wickert <fedora christoph-wickert de> - 0.4.1-1
- Update to 0.4.1
- Remove patches (fixed upstream)


xsp-2.0-4.fc10
--------------
* Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
- bump to RC 4

* Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-3
- bump to RC 3


Summary:
Added Packages: 5
Removed Packages: 0
Modified Packages: 72
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	beagle-evolution-0.3.8-6.fc10.i386 requires mono(evolution-sharp) = 0:3.0.0.0
	chess-1.0-19.fc10.i386 requires libOgreMain-1.4.9.so
	chess-1.0-19.fc10.i386 requires libCEGUIOgreRenderer-1.4.9.so
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	beagle-evolution-0.3.8-6.fc10.x86_64 requires mono(evolution-sharp) = 0:3.0.0.0
	chess-1.0-19.fc10.x86_64 requires libOgreMain-1.4.9.so()(64bit)
	chess-1.0-19.fc10.x86_64 requires libCEGUIOgreRenderer-1.4.9.so()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	beagle-evolution-0.3.8-6.fc10.ppc requires mono(evolution-sharp) = 0:3.0.0.0
	chess-1.0-19.fc10.ppc requires libOgreMain-1.4.9.so
	chess-1.0-19.fc10.ppc requires libCEGUIOgreRenderer-1.4.9.so
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	liveusb-creator-3.0-1.fc10.noarch requires syslinux
	lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	chess-1.0-19.fc10.ppc64 requires libOgreMain-1.4.9.so()(64bit)
	chess-1.0-19.fc10.ppc64 requires libCEGUIOgreRenderer-1.4.9.so()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	liveusb-creator-3.0-1.fc10.noarch requires syslinux
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From giallu at gmail.com  Fri Oct  3 11:26:20 2008
From: giallu at gmail.com (Gianluca Sforna)
Date: Fri, 3 Oct 2008 13:26:20 +0200
Subject: rawhide report: 20081003 changes
In-Reply-To: <20081003105054.963611F8263@releng2.fedora.phx.redhat.com>
References: <20081003105054.963611F8263@releng2.fedora.phx.redhat.com>
Message-ID: <d5ad21470810030426t5763ea9dw76905991ef010fe4@mail.gmail.com>

On Fri, Oct 3, 2008 at 12:50 PM, Rawhide Report
<rawhide at fedoraproject.org> wrote:
> mod_mono-2.0-4.fc10
> -------------------
> * Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
> - bump to RC4
>
> * Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-3
> - bump to RC3
>
>
> mono-2.0-10.fc10
> ----------------
> * Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-10
> - bump to RC4
>
> * Sun Sep 28 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-9
> - backported binaryserialisation and datatable patches
> - backported stringreplace optimisation
> - bump to RC3
>
>
> mono-basic-2.0-4.fc10
> ---------------------
> * Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
> - bump to RC4
>
> * Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-3
> - bump to RC3
> - alter excludearch to exclusivearch
> - alter version number in pc file
>
>
> mono-tools-2.0-7.fc10
> ---------------------
> * Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.0-7
> - bump to rc3
>
> * Wed Oct  1 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.0-6
> - bump to rc3
>
>
> monodoc-2.0-5.fc10
> ------------------
> * Fri Oct  3 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-5
> - bump to RC4
>
> * Mon Sep 29 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-4
> - bump to RC 3
>
>

Shouldn't all these be using the pre-release naming scheme (-0.X.rcY
instead of plain -X) ?


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From paul at all-the-johnsons.co.uk  Fri Oct  3 12:03:48 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 03 Oct 2008 13:03:48 +0100
Subject: rawhide report: 20081003 changes
In-Reply-To: <d5ad21470810030426t5763ea9dw76905991ef010fe4@mail.gmail.com>
References: <20081003105054.963611F8263@releng2.fedora.phx.redhat.com>
	<d5ad21470810030426t5763ea9dw76905991ef010fe4@mail.gmail.com>
Message-ID: <1223035428.6325.21.camel@PB3.Linux>

Hi,

> Shouldn't all these be using the pre-release naming scheme (-0.X.rcY
> instead of plain -X) ?

D'oh!

Oh well, I'll know for future releases!

TTFN

Paul
(two thirds asleep)
-- 
?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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081003/2ca72c02/attachment.sig>

From dwalsh at redhat.com  Fri Oct  3 13:13:34 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 03 Oct 2008 09:13:34 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
Message-ID: <48E61A7E.8010404@redhat.com>

Jon Masters wrote:
> Hi folks,
> 
> I'm not *exactly* ranting about SELinux again, but I have a question...
> 
> Suppose one mounts an ISO image (let's say the Fedora 9 DVDs) via
> loopback and wants to copy the content to a local disk directory. One
> might do something like:
> 
> $ mount -o loop Fedora-9-i386-DVD.iso /mnt
> 
> And then one might legitimately expect to be able to copy the content
> of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
> suppose that one is running SELinux in enforcing mode, then this will
> fail because the contexts differ in this operation. Then, one will
> likely quickly become severely annoyed and frustrated with SELinux,
> simply setting it permissive for the duration of the operation...
> 
> ...but how is the *average* user supposed to do this copy?
> 
> Jon.
> 
> 

Why would the copy fail?  cp should just work and set the files to the
context of the destination directory.  If this fails it is a bug.



From dwalsh at redhat.com  Fri Oct  3 13:16:12 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Fri, 03 Oct 2008 09:16:12 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <20081003091511.73410983@ludwig-alpha.unil.ch>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<20081003091511.73410983@ludwig-alpha.unil.ch>
Message-ID: <48E61B1C.70603@redhat.com>

Christian Iseli wrote:
> On Fri, 03 Oct 2008 01:03:44 -0400, Jon Masters wrote:
>> ...but how is the *average* user supposed to do this copy?
> 
> I have a Fedora 9 running under VirtualBox and am basically wondering
> the same thing about the SharedFolder thing.  When one simply does a
> $ mount -t vboxsf VMShared /mnt
> then a subsequent attempt to copy something in there yields:
> $ mv gr.078212.108v2.pdf /mnt
Well first this is not a copy it is a move.  The problem here is the mv
command is attempting to retain the file context of gr.078212.108v2.pdf,
 if you did a cp it would work.

What avc are you seeing?
> mv: cannot create regular file `/mnt/gr.078212.108v2.pdf': Permission denied
> and selinuxtroubleshootd pops up (which is nice).
> 
> And then there are further hickups if you leave the filesystem mounted
> overnight: updatedb and (I think) logwatch cron jobs are also getting
> denials.
> 
AVC?
> This can all be fixed using audit2allow etc., as explained in the
> setroubleshootd output, but...
> 
> Maybe some nice little script, to do selinux tweaks, that could be run
> after mounting a new filesystem would help ?
> 
> Cheers,
> 					Christian
> 



From skvidal at fedoraproject.org  Fri Oct  3 13:21:14 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 03 Oct 2008 09:21:14 -0400
Subject: serial console config
In-Reply-To: <1223009889.28226.5.camel@perihelion.int.jonmasters.org>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
	<20081002135647.GA2859@nostromo.devel.redhat.com>
	<1223009889.28226.5.camel@perihelion.int.jonmasters.org>
Message-ID: <1223040074.18687.11.camel@rosebud>

On Fri, 2008-10-03 at 00:58 -0400, Jon Masters wrote:
> On Thu, 2008-10-02 at 09:56 -0400, Bill Nottingham wrote:
> > Jon Masters (jonathan at jonmasters.org) said: 
> > > What's the recommended way to configure a serial console in Fedora 9
> > > with upstart? /etc/event.d/serial requires some fedora-centric event to
> > > be emitted but I'm not sure where this is supposed to be generated.
> > 
> > >From udev.
> > 
> > > <aside> time was, you could just setup a serial console in 3 seconds, I
> > > guess I'm pining for the good old days...or some documentation.
> > 
> > cp /etc/event.d/tty1 /etc/event.d/my_serial_console. Edit as appropriate.
> 
> Ah, thanks for the replies guys but I'm not sure my original point was
> clear. I can fudge this as much as the next guy but there's a designated
> serial file in that event.d directory that is clearly supposed to be
> getting some kind of event trigger to start the console. Consequently,
> there's supposedly some new "Fedora way" to do serial consoles that
> isn't locatable in Google, nobody here has mentioned, and is
> undocumented. If nobody knows, why does that file exist?
> 
> So my question was more of a WTF about that serial file.

+1. I don't know wtf about that serial file, either.

I read it a couple of times before giving up and doing it my own way.

-sv




From drepper at redhat.com  Fri Oct  3 13:37:52 2008
From: drepper at redhat.com (Ulrich Drepper)
Date: Fri, 03 Oct 2008 06:37:52 -0700
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E5637C.7040901@redhat.com>
References: <48E45455.7000203@redhat.com> <48E4D40A.6000402@redhat.com>
	<48E5637C.7040901@redhat.com>
Message-ID: <48E62030.7080801@redhat.com>

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

Sean Flanigan wrote:
> Let me change my question then.  How would people feel about having a
> hook to override the behaviour of gettext() in a system-wide fashion?

You don't understand the issue.  There is no hook needed.  Just create
appropriate translations which go with your pseudo locale.  It's as
trivial as running sed over a text file (the .po files).

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjmIDAACgkQ2ijCOnn/RHSwjACgoyJz8yIn932z94YVNtrJzDwd
Y8AAn3DdRM/GT+5z+FwLUnGfT6r+0oyc
=4Hsz
-----END PGP SIGNATURE-----



From skvidal at fedoraproject.org  Fri Oct  3 13:34:58 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 03 Oct 2008 09:34:58 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48E5EC86.8050508@ru.bir.ru>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com>  <48E5EC86.8050508@ru.bir.ru>
Message-ID: <1223040898.18687.17.camel@rosebud>

On Fri, 2008-10-03 at 13:57 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
> Tim Lauridsen ?????:
> > Kulbir Saini wrote:
> >> Hi list,
> >>
> >> Whenever I try a new version of Fedora, the first problem I face is 
> >> setting the proxy. It seems for almost every application, I have to 
> >> specify proxy at a different place. We have this "System -> 
> >> Preferences -> Internet and Network -> Network Proxy" app to specify 
> >> proxy settings. But I wonder if there is some application which obeys 
> >> these settings.
> >>
> >> Examples:
> >>
> >> 1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above 
> >> specified location. It has to be set via proxy option in yum.conf or 
> >> http_proxy/ftp_proxy env variable.
> > The problem is that the above is Gnome thing, so it make sense for 
> > gnome apps to use it, but yum a low level app there should work on all 
> > systems, also sytems with no GUI.
> > Tim
> >
> Yes, but it is no problem for yum optionally check this settings if it 
> is available in system, right?

Rather than instrument all apps so they can follow all desktop systems'
mechanism for setting a proxy, wouldn't it make more sense to have a
common way that all the desktops set?

-sv




From simon.andrews at bbsrc.ac.uk  Fri Oct  3 13:59:35 2008
From: simon.andrews at bbsrc.ac.uk (Simon Andrews)
Date: Fri, 03 Oct 2008 14:59:35 +0100
Subject: Uniform Proxy Settings
In-Reply-To: <48E48E04.1080906@students.iiit.ac.in>
References: <48E48E04.1080906@students.iiit.ac.in>
Message-ID: <gc58g8$ho8$1@ger.gmane.org>

Kulbir Saini wrote:
> Hi list,
> 
>    Whenever I try a new version of Fedora, the first problem I face is 
> setting the proxy. It seems for almost every application, I have to 
> specify proxy at a different place. We have this "System -> Preferences 
> -> Internet and Network -> Network Proxy" app to specify proxy settings. 
> But I wonder if there is some application which obeys these settings.

This has come up before and it's a messy subject.  I can throw into the 
debate the problem of NetworkManager and proxies - since I have to use a 
proxy at work, but not at home, and unsetting all the various places you 
can put a proxy is a royal pain.

The big problems are:

1) There is no common place to set a proxy variable.  Some programs (eg 
wget) look for the http_proxy environment variable.  Many Gnome programs 
look for the gconf setting, some programs (firefox) have their own 
internal setting.

2) Many programs won't update proxy settings on the fly so there's no 
way to transparently change a proxy without closing down and reopening 
the program.

One suggestion to get around this would be to run a proxy on localhost 
and make all proxy aware applications use that in their default install. 
  This wouldn't actually have to do any caching - just act as a common 
point at which behaviour could actually be changed without the 
cooperation of the programs.

We could then put hooks into NetworkManager to change the behaviour of 
the local proxy so that it either sends its requests directly to the 
internet, or routes them via a secondary proxy.

This all feels a bit icky to me - but I can't think of a nicer way of 
doing this which doesn't require the cooperation of the authors of every 
proxy-aware application.

Simon.



From dwmw2 at infradead.org  Fri Oct  3 14:03:34 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 03 Oct 2008 15:03:34 +0100
Subject: serial console config
In-Reply-To: <1223009889.28226.5.camel@perihelion.int.jonmasters.org>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
	<20081002135647.GA2859@nostromo.devel.redhat.com>
	<1223009889.28226.5.camel@perihelion.int.jonmasters.org>
Message-ID: <1223042614.3328.99.camel@macbook.infradead.org>

On Fri, 2008-10-03 at 00:58 -0400, Jon Masters wrote:
> So my question was more of a WTF about that serial file.

I think it's supposed to be triggered by the udev event when the serial
port appears. We run /lib/udev/console_check on it (from a udev rule, of
course), and if it seems to be the console then _that_ will start the
serial service in upstart.

Hence, the answer "just boot with console=ttyS0 and it should work" was,
at least in theory, correct. It doesn't always work properly, though.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From notting at redhat.com  Fri Oct  3 12:56:13 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 3 Oct 2008 08:56:13 -0400
Subject: serial console config
In-Reply-To: <1223009889.28226.5.camel@perihelion.int.jonmasters.org>
References: <1222944525.26632.16.camel@perihelion.int.jonmasters.org>
	<20081002135647.GA2859@nostromo.devel.redhat.com>
	<1223009889.28226.5.camel@perihelion.int.jonmasters.org>
Message-ID: <20081003125613.GA1788@nostromo.devel.redhat.com>

Jon Masters (jonathan at jonmasters.org) said: 
> Ah, thanks for the replies guys but I'm not sure my original point was
> clear. I can fudge this as much as the next guy but there's a designated
> serial file in that event.d directory that is clearly supposed to be
> getting some kind of event trigger to start the console. Consequently,
> there's supposedly some new "Fedora way" to do serial consoles that
> isn't locatable in Google, nobody here has mentioned, and is
> undocumented. If nobody knows, why does that file exist?
> 
> So my question was more of a WTF about that serial file.

As said, it's triggered via udev. /{etc,lib}/udev/rules.d/10-console.rules
runs a command that checks out /dev/console - if it responds to the
proper serial ioctl, then it's determined to be a serial console. The
event is then emitted, and /etc/event.d/serial is triggered on that
event.

It only triggers if the serial console is the primary console. This is
in line with the automatic /etc/inittab writing that was there in
prior releases.

Bill



From arjan at infradead.org  Fri Oct  3 14:17:28 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Fri, 3 Oct 2008 07:17:28 -0700
Subject: Uniform Proxy Settings
In-Reply-To: <1223040898.18687.17.camel@rosebud>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
Message-ID: <20081003071728.1a69b725@infradead.org>

On Fri, 03 Oct 2008 09:34:58 -0400
seth vidal <skvidal at fedoraproject.org> wrote:
> > >
> > Yes, but it is no problem for yum optionally check this settings if
> > it is available in system, right?
> 
> Rather than instrument all apps so they can follow all desktop
> systems' mechanism for setting a proxy, wouldn't it make more sense
> to have a common way that all the desktops set?
>

.... like http_proxy environment variable that everyone and their dog
(except firefox) uses ?


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From skvidal at fedoraproject.org  Fri Oct  3 14:20:25 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 03 Oct 2008 10:20:25 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <20081003071728.1a69b725@infradead.org>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
	<20081003071728.1a69b725@infradead.org>
Message-ID: <1223043625.18687.19.camel@rosebud>

On Fri, 2008-10-03 at 07:17 -0700, Arjan van de Ven wrote:
> On Fri, 03 Oct 2008 09:34:58 -0400
> seth vidal <skvidal at fedoraproject.org> wrote:
> > > >
> > > Yes, but it is no problem for yum optionally check this settings if
> > > it is available in system, right?
> > 
> > Rather than instrument all apps so they can follow all desktop
> > systems' mechanism for setting a proxy, wouldn't it make more sense
> > to have a common way that all the desktops set?
> >
> 
> .... like http_proxy environment variable that everyone and their dog
> (except firefox) uses ?

The original complaint here is that the gnome proxy setting doesn't seem
to set this as well.

B/c yum does follow http_proxy env variable.

-sv




From adellam at sevenseas.org  Fri Oct  3 14:45:10 2008
From: adellam at sevenseas.org (Andrea Dell'Amico)
Date: Fri, 03 Oct 2008 16:45:10 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <1223043625.18687.19.camel@rosebud>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
	<20081003071728.1a69b725@infradead.org>
	<1223043625.18687.19.camel@rosebud>
Message-ID: <1223045110.22330.16.camel@altrove.masaccio.sevenseas.org>

On Fri, 2008-10-03 at 10:20 -0400, seth vidal wrote:

> The original complaint here is that the gnome proxy setting doesn't seem
> to set this as well.

And often gnome applications don't learn the new settings.

I'm using a local privoxy instance to work around that (it's even more
flexible, so that I can use different proxies for different
destinations).

> -sv

ciao
andrea
-- 
"In six days God created the heaven and the earth. On the seventh day,
Stanley Kubrick sent everything back for modifications."
- http://www.jonhs.com/freemovies/dark_side_of_the_moon.htm




From kulbirsaini at students.iiit.ac.in  Fri Oct  3 14:53:13 2008
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Fri, 03 Oct 2008 20:23:13 +0530
Subject: Uniform Proxy Settings
In-Reply-To: <gc58g8$ho8$1@ger.gmane.org>
References: <48E48E04.1080906@students.iiit.ac.in> <gc58g8$ho8$1@ger.gmane.org>
Message-ID: <48E631D9.6040301@students.iiit.ac.in>



Simon Andrews wrote:
> Kulbir Saini wrote:
>> Hi list,
>>
>> Whenever I try a new version of Fedora, the first problem I face is 
>> setting the proxy. It seems for almost every application, I have to 
>> specify proxy at a different place. We have this "System -> 
>> Preferences -> Internet and Network -> Network Proxy" app to specify 
>> proxy settings. But I wonder if there is some application which obeys 
>> these settings.
> 
> This has come up before and it's a messy subject. I can throw into the 
> debate the problem of NetworkManager and proxies - since I have to use a 
> proxy at work, but not at home, and unsetting all the various places you 
> can put a proxy is a royal pain.
> 
> The big problems are:
> 
> 1) There is no common place to set a proxy variable. Some programs (eg 
> wget) look for the http_proxy environment variable. Many Gnome programs 
> look for the gconf setting, some programs (firefox) have their own 
> internal setting.
> 
> 2) Many programs won't update proxy settings on the fly so there's no 
> way to transparently change a proxy without closing down and reopening 
> the program.
> 
> One suggestion to get around this would be to run a proxy on localhost 
> and make all proxy aware applications use that in their default install. 
> This wouldn't actually have to do any caching - just act as a common 
> point at which behaviour could actually be changed without the 
> cooperation of the programs.

   This sounds good but some work environments doesn't allow you to run 
proxy on your own machine. e.g. Consider an office env in a 
multinational or a university where running proxy on every single 
machine violates the computer usage policy.

> We could then put hooks into NetworkManager to change the behaviour of 
> the local proxy so that it either sends its requests directly to the 
> internet, or routes them via a secondary proxy.
> 
> This all feels a bit icky to me - but I can't think of a nicer way of 
> doing this which doesn't require the cooperation of the authors of every 
> proxy-aware application.
> 
> Simon.
> 

-- 
---------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Web-Blog: http://fedora.co.in/

IRC nick : generalBordeaux
Channels : #fedora, #fedora-devel, #yum on freenode

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From mmcgrath at redhat.com  Fri Oct  3 14:57:14 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 3 Oct 2008 09:57:14 -0500 (CDT)
Subject: Outage Notification - 2008-10-05 07:00 UTC
Message-ID: <alpine.LFD.1.10.0810030956530.31374@laptop.mmcgrath.net>

There will be an outage starting at 2008-10-05 07:00 UTC, which will last
approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-10-05 07:00 UTC'

Affected Services:

Buildsystem
CVS / Source Control
Database
DNS
Fedora Hosted
Fedora People
Fedora Talk
Mail
Mirror System
Torrent
Websites

Unaffected Services:

All

Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/875

Reason for Outage:

Doing our monthly updates to our systems, there's a kernel update this
time around and we'll be rebooting everything.  In theory most systems
won't go down at all.  But many will be down for a few minutes at a time
during our 2 hour outage window.

Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.


_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From kulbirsaini at students.iiit.ac.in  Fri Oct  3 15:10:34 2008
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Fri, 03 Oct 2008 20:40:34 +0530
Subject: Uniform Proxy Settings
In-Reply-To: <1223040898.18687.17.camel@rosebud>
References: <48E48E04.1080906@students.iiit.ac.in>	<48E5AD07.2030508@googlemail.com>
	<48E5EC86.8050508@ru.bir.ru> <1223040898.18687.17.camel@rosebud>
Message-ID: <48E635EA.1010908@students.iiit.ac.in>



seth vidal wrote:
> On Fri, 2008-10-03 at 13:57 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
> wrote:
>> Tim Lauridsen ?????:
>>> Kulbir Saini wrote:
>>>> Hi list,
>>>>
>>>> Whenever I try a new version of Fedora, the first problem I face is
>>>> setting the proxy. It seems for almost every application, I have to
>>>> specify proxy at a different place. We have this "System ->
>>>> Preferences -> Internet and Network -> Network Proxy" app to specify
>>>> proxy settings. But I wonder if there is some application which obeys
>>>> these settings.
>>>>
>>>> Examples:
>>>>
>>>> 1. Yum (3.2.19-3.fc10) won't fetch proxy settings from above
>>>> specified location. It has to be set via proxy option in yum.conf or
>>>> http_proxy/ftp_proxy env variable.
>>> The problem is that the above is Gnome thing, so it make sense for
>>> gnome apps to use it, but yum a low level app there should work on all
>>> systems, also sytems with no GUI.
>>> Tim
>>>
>> Yes, but it is no problem for yum optionally check this settings if it
>> is available in system, right?
> 
> Rather than instrument all apps so they can follow all desktop systems'
> mechanism for setting a proxy, wouldn't it make more sense to have a
> common way that all the desktops set?

   Can we make this a part of the packaging policy that if your package 
sets/gets or do anything with the proxy settings, then it should always 
set/unset/access the env variables like http_proxy, ftp_proxy, 
gopher_proxy so that we can achieve some uniform system?

> -sv
> 
> 

-- 
---------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Web-Blog: http://fedora.co.in/

IRC nick : generalBordeaux
Channels : #fedora, #fedora-devel, #yum on freenode

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From paul at city-fan.org  Fri Oct  3 15:13:40 2008
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 03 Oct 2008 16:13:40 +0100
Subject: Outage Notification - 2008-10-05 07:00 UTC
In-Reply-To: <alpine.LFD.1.10.0810030956530.31374@laptop.mmcgrath.net>
References: <alpine.LFD.1.10.0810030956530.31374@laptop.mmcgrath.net>
Message-ID: <48E636A4.60500@city-fan.org>

Mike McGrath wrote:
> There will be an outage starting at 2008-10-05 07:00 UTC, which will last
> approximately 2 hours.
> 
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
> 
> date -d '2008-10-05 07:00 UTC'
> 
> Affected Services:
> 
> Buildsystem
> CVS / Source Control
> Database
> DNS
> Fedora Hosted
> Fedora People
> Fedora Talk
> Mail
> Mirror System
> Torrent
> Websites
> 
> Unaffected Services:
> 
> All

Surely that's "none" ... ?

Paul.



From cra at WPI.EDU  Fri Oct  3 15:15:16 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 3 Oct 2008 11:15:16 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <1223043625.18687.19.camel@rosebud>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
	<20081003071728.1a69b725@infradead.org>
	<1223043625.18687.19.camel@rosebud>
Message-ID: <20081003151516.GH24829@angus.ind.WPI.EDU>

On Fri, Oct 03, 2008 at 10:20:25AM -0400, seth vidal wrote:
> B/c yum does follow http_proxy env variable.

Correct me if I'm wrong, but you can't set the environment of another 
process unless it is a child.  This makes env vars unappealing for 
system settings.



From cra at WPI.EDU  Fri Oct  3 15:16:53 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 3 Oct 2008 11:16:53 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48E631D9.6040301@students.iiit.ac.in>
References: <48E48E04.1080906@students.iiit.ac.in> <gc58g8$ho8$1@ger.gmane.org>
	<48E631D9.6040301@students.iiit.ac.in>
Message-ID: <20081003151653.GI24829@angus.ind.WPI.EDU>

On Fri, Oct 03, 2008 at 08:23:13PM +0530, Kulbir Saini wrote:
>> One suggestion to get around this would be to run a proxy on localhost  
>> and make all proxy aware applications use that in their default 
>> install. This wouldn't actually have to do any caching - just act as a 
>> common point at which behaviour could actually be changed without the  
>> cooperation of the programs.
>
>   This sounds good but some work environments doesn't allow you to run  
> proxy on your own machine. e.g. Consider an office env in a  
> multinational or a university where running proxy on every single  
> machine violates the computer usage policy.

I don't see how it would matter.  The proxy would be an internal-only 
abstraction of how the system talks to the rest of the net.  It 
wouldn't be visible or usable from outside the local system.



From kulbirsaini at students.iiit.ac.in  Fri Oct  3 15:36:54 2008
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Fri, 03 Oct 2008 21:06:54 +0530
Subject: Uniform Proxy Settings
In-Reply-To: <20081003151653.GI24829@angus.ind.WPI.EDU>
References: <48E48E04.1080906@students.iiit.ac.in>
	<gc58g8$ho8$1@ger.gmane.org>	<48E631D9.6040301@students.iiit.ac.in>
	<20081003151653.GI24829@angus.ind.WPI.EDU>
Message-ID: <48E63C16.4080004@students.iiit.ac.in>



Chuck Anderson wrote:
> On Fri, Oct 03, 2008 at 08:23:13PM +0530, Kulbir Saini wrote:
>>> One suggestion to get around this would be to run a proxy on localhost
>>> and make all proxy aware applications use that in their default
>>> install. This wouldn't actually have to do any caching - just act as a
>>> common point at which behaviour could actually be changed without the
>>> cooperation of the programs.
>>   This sounds good but some work environments doesn't allow you to run
>> proxy on your own machine. e.g. Consider an office env in a
>> multinational or a university where running proxy on every single
>> machine violates the computer usage policy.
> 
> I don't see how it would matter.  The proxy would be an internal-only
> abstraction of how the system talks to the rest of the net.  It
> wouldn't be visible or usable from outside the local system.
> 

   I think its not fair enough to introduce a proxy server (even if its 
minimal and local) just because we can't figure out a uniform system to 
set and retrieve the proxy settings. And even if we have this proxy 
minimal and local proxy server, there is no guarantee that all the apps 
will use it. So, IMHO its best to force applications to use a uniform 
location like http_proxy for setting/getting the proxy settings.

-- 
---------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Web-Blog: http://fedora.co.in/

IRC nick : generalBordeaux
Channels : #fedora, #fedora-devel, #yum on freenode

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



From nathanael at gnat.ca  Fri Oct  3 15:49:36 2008
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Fri, 3 Oct 2008 09:49:36 -0600
Subject: F10 Live CD possible bug
In-Reply-To: <48E506BD.6020002@redhat.com>
References: <5F66C9D7-C19A-47F4-8783-F7E29992310B@gnat.ca>	<48E3F4E9.6000805@redhat.com>
	<4F549021-DD11-4A51-8F43-CA3C3F263CE2@gnat.ca>
	<48E506BD.6020002@redhat.com>
Message-ID: <EC237C34-66CE-4316-8266-94AF105BA3A2@gnat.ca>


On Oct 2, 2008, at 11:37 AM, Chris Snook wrote:

> Nathanael Noblet wrote:
>> On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:
>>> Nathanael Noblet wrote:
>>>> Hello,
>>>> I downloaded the live cd of F10 beta. Booted and added the  
>>>> live_ram option to the boot params. After copying the image to  
>>>> RAM I get the following error on two machines, (Apple Mac Book,  
>>>> and Acer 3680).
>>>> Done copying live image to RAM.
>>>> eject: did not find a device /dev/root in /sys/block
>>>> Bug in initramfs /init detected. Dropping to a shell. Good luck!
>>>> sbin/real-init: line 7: plymouth: command not found
>>>> I know I used that param for F9. Is it depreciated or is this a  
>>>> bug needing filling?
>>>
>>> Assuming it does something different when you omit the option,  
>>> that's a bug.  If we don't intend for it to work in F10, the  
>>> option should be removed entirely, and ignored if passed by the  
>>> user.
>>>
>> Yeah if you remove the live_ram from the boot options. It boots...
>> Is there a rationale for removing the option? It came in super  
>> useful for me a month or so back. I can't remember the exact issue  
>> but saved the day for me when I finally found it.
>
> If it had been removed, it wouldn't do anything.  The fact that it's  
> doing something indicates that it's expected to still work, but  
> broken.  Please file a BZ.

Against? mkinitrd? this is in the init in the initrd but I'm not sure  
if it is for installed systems or not...



From walters at verbum.org  Fri Oct  3 16:13:22 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 3 Oct 2008 12:13:22 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <20081003071728.1a69b725@infradead.org>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
	<20081003071728.1a69b725@infradead.org>
Message-ID: <faa16b610810030913u5df5d8f3g726333dff82c15f4@mail.gmail.com>

On Fri, Oct 3, 2008 at 10:17 AM, Arjan van de Ven <arjan at infradead.org> wrote:
> On Fri, 03 Oct 2008 09:34:58 -0400
> seth vidal <skvidal at fedoraproject.org> wrote:
>> > >
>> > Yes, but it is no problem for yum optionally check this settings if
>> > it is available in system, right?
>>
>> Rather than instrument all apps so they can follow all desktop
>> systems' mechanism for setting a proxy, wouldn't it make more sense
>> to have a common way that all the desktops set?
>>
>
> .... like http_proxy environment variable that everyone and their dog
> (except firefox) uses ?

The problem is that to change an environment variable you have to log
out, which is a pretty sucky user experience.



From jkeating at redhat.com  Fri Oct  3 16:40:31 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 03 Oct 2008 09:40:31 -0700
Subject: SELinux - copying ISO file content
In-Reply-To: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
Message-ID: <1223052031.6265.81.camel@luminos.localdomain>

On Fri, 2008-10-03 at 01:03 -0400, Jon Masters wrote:
> ...but how is the *average* user supposed to do this copy?

The average user double clicks on the iso in Nautilus, which mounts it
for them.  Then they click/drag the fileset to where they want it and
Nautilus copies it for them.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081003/cace0f05/attachment.sig>

From csnook at redhat.com  Fri Oct  3 16:44:06 2008
From: csnook at redhat.com (Chris Snook)
Date: Fri, 03 Oct 2008 12:44:06 -0400
Subject: F10 Live CD possible bug
In-Reply-To: <EC237C34-66CE-4316-8266-94AF105BA3A2@gnat.ca>
References: <5F66C9D7-C19A-47F4-8783-F7E29992310B@gnat.ca>	<48E3F4E9.6000805@redhat.com>	<4F549021-DD11-4A51-8F43-CA3C3F263CE2@gnat.ca>	<48E506BD.6020002@redhat.com>
	<EC237C34-66CE-4316-8266-94AF105BA3A2@gnat.ca>
Message-ID: <48E64BD6.3040902@redhat.com>

Nathanael Noblet wrote:
> 
> On Oct 2, 2008, at 11:37 AM, Chris Snook wrote:
> 
>> Nathanael Noblet wrote:
>>> On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:
>>>> Nathanael Noblet wrote:
>>>>> Hello,
>>>>> I downloaded the live cd of F10 beta. Booted and added the live_ram 
>>>>> option to the boot params. After copying the image to RAM I get the 
>>>>> following error on two machines, (Apple Mac Book, and Acer 3680).
>>>>> Done copying live image to RAM.
>>>>> eject: did not find a device /dev/root in /sys/block
>>>>> Bug in initramfs /init detected. Dropping to a shell. Good luck!
>>>>> sbin/real-init: line 7: plymouth: command not found
>>>>> I know I used that param for F9. Is it depreciated or is this a bug 
>>>>> needing filling?
>>>>
>>>> Assuming it does something different when you omit the option, 
>>>> that's a bug.  If we don't intend for it to work in F10, the option 
>>>> should be removed entirely, and ignored if passed by the user.
>>>>
>>> Yeah if you remove the live_ram from the boot options. It boots...
>>> Is there a rationale for removing the option? It came in super useful 
>>> for me a month or so back. I can't remember the exact issue but saved 
>>> the day for me when I finally found it.
>>
>> If it had been removed, it wouldn't do anything.  The fact that it's 
>> doing something indicates that it's expected to still work, but 
>> broken.  Please file a BZ.
> 
> Against? mkinitrd? this is in the init in the initrd but I'm not sure if 
> it is for installed systems or not...

Since it's livecd-specific, I would blame livecd-tools for setting it up 
incorrectly.  When in doubt, file the bug and let the developers pass the blame 
if needed.

-- Chris



From pjones at redhat.com  Fri Oct  3 17:10:10 2008
From: pjones at redhat.com (Peter Jones)
Date: Fri, 03 Oct 2008 13:10:10 -0400
Subject: Broken dependencies: liveusb-creator
In-Reply-To: <20081003101036.5C5F31F8267@releng2.fedora.phx.redhat.com>
References: <20081003101036.5C5F31F8267@releng2.fedora.phx.redhat.com>
Message-ID: <48E651F2.7050202@redhat.com>

buildsys at fedoraproject.org wrote:
> liveusb-creator has broken dependencies in the development tree:
> On ppc:
> 	liveusb-creator-3.0-1.fc10.noarch requires syslinux
> On ppc64:
> 	liveusb-creator-3.0-1.fc10.noarch requires syslinux

This is certainly a liveusb-creator bug, as syslinux has not ever, and probably 
will not ever, build on ppc or ppc64.

-- 
   Peter



From qralston+ml.redhat-fedora-devel at andrew.cmu.edu  Fri Oct  3 17:11:11 2008
From: qralston+ml.redhat-fedora-devel at andrew.cmu.edu (James Ralston)
Date: Fri, 03 Oct 2008 13:11:11 -0400
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <20080930193705.GB12982@amd.home.annexia.org>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
Message-ID: <F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>

On 2008-09-30 at 20:37+01 Richard W.M. Jones <rjones at redhat.com> wrote:

> Yup, KVM is cool, much easier to use, and with virtio-enabled guests
> it's about the same speed as Xen.

I really have to beg to differ about "easier to use", for two reasons:

    1.  Xen's network subsystem bypasses netfilter.

        (One could argue there's a benefit to protecting public
        bridged guests with netfilter, but I think from a philsophical
        viewpoint, public bridged guests really should have unfettered
        network access.)

    2.  Setting up a public bridge is a snap in Xen.  In KVM, it is
        massively complex (i.e., virt-manager can't do it), and
        requires tools (tunctl) Fedora doesn't even provide:

        http://kvm.qumranet.com/kvmwiki/Networking

IMHO, KVM's big win is that it doesn't interfere with ACPI functions,
so features like CPU frequency throttling work even if you're running
a KVM guest.

But man oh man, is public bridge networking in KVM a nightmare...

-- 
STABILIZATION = CHAOS; END THE FED!
The Bailout Reader - <http://mises.org/story/3128>
The Rescue Package Will Delay Recovery - <http://mises.org/story/3131>
Taking Money Back - <http://mises.org/story/2882>



From berrange at redhat.com  Fri Oct  3 17:17:21 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 3 Oct 2008 18:17:21 +0100
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
Message-ID: <20081003171721.GU18995@redhat.com>

On Fri, Oct 03, 2008 at 01:11:11PM -0400, James Ralston wrote:
> On 2008-09-30 at 20:37+01 Richard W.M. Jones <rjones at redhat.com> wrote:
> 
> > Yup, KVM is cool, much easier to use, and with virtio-enabled guests
> > it's about the same speed as Xen.
> 
> I really have to beg to differ about "easier to use", for two reasons:
> 
>     1.  Xen's network subsystem bypasses netfilter.
> 
>         (One could argue there's a benefit to protecting public
>         bridged guests with netfilter, but I think from a philsophical
>         viewpoint, public bridged guests really should have unfettered
>         network access.)

That has got absolutely nothing todo with Xen. Whether bridged
traffic bypasses netfilter or not is controlled by the kernel
sysctls

  net.bridge.bridge-nf-call-arptables = 1
  net.bridge.bridge-nf-call-iptables = 1
  net.bridge.bridge-nf-call-ip6tables = 1

If those are set to '1', then bridge traffic hits netfilter, if they
are set to '0', it is bypassed. 

>     2.  Setting up a public bridge is a snap in Xen.  In KVM, it is
>         massively complex (i.e., virt-manager can't do it), and
>         requires tools (tunctl) Fedora doesn't even provide:
> 
>         http://kvm.qumranet.com/kvmwiki/Networking

That is just plain wrong. Both KVM and Xen can use bridging in 
exactly the same way, and it works just fine with standard  tools
and initscripts provided in Fedora

  http://wiki.libvirt.org/page/Networking

> 
> IMHO, KVM's big win is that it doesn't interfere with ACPI functions,
> so features like CPU frequency throttling work even if you're running
> a KVM guest.
> 
> But man oh man, is public bridge networking in KVM a nightmare...

No, it is utterly trivial

  # cd /etc/sysconfig/network-script

  # cat > ifcfg-eth0 <<EOF
  DEVICE=eth0
  HWADDR=00:16:76:D6:C9:45
  ONBOOT=yes
  BRIDGE=br0
  EOF

  # cat > ifcfg-br0 <<EOF
  DEVICE=br0
  TYPE=Bridge
  BOOTPROTO=dhcp
  ONBOOT=yes
  EOF

  # service network restart

Job done, virt-manager will show you that br0 bridge and allow you to
attach a guest to it, or out of the box you can use the 'virbr0' for
NAT based connectivity that works even with wifi + network manager.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From sundaram at fedoraproject.org  Fri Oct  3 18:19:11 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 03 Oct 2008 23:49:11 +0530
Subject: KDE-SIG weekly report (40/2008)
In-Reply-To: <200810021449.36562.ml@deadbabylon.de>
References: <200810021449.36562.ml@deadbabylon.de>
Message-ID: <48E6621F.9030908@fedoraproject.org>

Sebastian Vahl wrote:

> 
> mysql-embedded for amarok2: 
> --------------------------------------------
> * The next beta of amarok2 will use mysql-embedded which isn't available in 
> Fedora. 
> * An old RFE also requests this enhancement (#149829). [1]
> * We'll need to talk to the mysql-maintainers to make it possible to ship a 
> mysql-embedded package in F10. 
> * In a worst-case-scenario we'll have to fall back to amarok1 in F10. 

IIRC, this has already been fixed in rawhide.

Rahul



From robert at marcanoonline.com  Fri Oct  3 18:23:08 2008
From: robert at marcanoonline.com (Robert Marcano)
Date: Fri, 03 Oct 2008 13:53:08 -0430
Subject: Uniform Proxy Settings
In-Reply-To: <20081003071728.1a69b725@infradead.org>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
	<20081003071728.1a69b725@infradead.org>
Message-ID: <1223058188.3386.13.camel@localhost.localdomain>

On Fri, 2008-10-03 at 07:17 -0700, Arjan van de Ven wrote:
> On Fri, 03 Oct 2008 09:34:58 -0400
> seth vidal <skvidal at fedoraproject.org> wrote:
> > > >
> > > Yes, but it is no problem for yum optionally check this settings if
> > > it is available in system, right?
> > 
> > Rather than instrument all apps so they can follow all desktop
> > systems' mechanism for setting a proxy, wouldn't it make more sense
> > to have a common way that all the desktops set?
> >
> 
> .... like http_proxy environment variable that everyone and their dog
> (except firefox) uses ?
> 
> 

http_proxy is too limited to be the standard way to set a global proxy,
do not forget about
http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol

> -- 
> Arjan van de Ven 	Intel Open Source Technology Centre
> For development, discussion and tips for power savings, 
> visit http://www.lesswatts.org
> 



From smooge at gmail.com  Fri Oct  3 18:39:46 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Fri, 3 Oct 2008 12:39:46 -0600
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <200810022120.m92LKo3B006975@laptop14.inf.utfsm.cl>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
	<200810022120.m92LKo3B006975@laptop14.inf.utfsm.cl>
Message-ID: <80d7e4090810031139je423253v7a8ec101d513fa7@mail.gmail.com>

On Thu, Oct 2, 2008 at 3:20 PM, Horst H. von Brand
<vonbrand at inf.utfsm.cl> wrote:
> Stephen John Smoogen <smooge at gmail.com> wrote:
>
> [...]
>
>> I won't say you are whining.. but you are the first systems
>> administrator I have met in several years who hasn't had
>> /usr/sbin:/sbin in their default path.
>
> So you've never met me (or one of the lots of people that I've trained over
> the years)...
>
>>                                        You sure they didn't make you a
>> manager and didn't tell you?
>
> They did, but had the good taste to ask me nicely ;-)

Heh.. as I have gotten a lot of off list ribbing about this.. I am
removing /sbin:/usr/sbin from my path and learning to type /usr/sbin
for the commands I have 'shortcutted' over the years. Next I will be
removing the bad habit of '/sbin/sudo bash' :).


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From qralston+ml.redhat-fedora-devel at andrew.cmu.edu  Fri Oct  3 18:41:05 2008
From: qralston+ml.redhat-fedora-devel at andrew.cmu.edu (James Ralston)
Date: Fri, 03 Oct 2008 14:41:05 -0400
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <20081003171721.GU18995@redhat.com>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>	<20080930193705.GB12982@amd.home.annexia.org>	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
	<20081003171721.GU18995@redhat.com>
Message-ID: <4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>

On 2008-10-03 at 18:17+01 Daniel P Berrange <berrange at redhat.com> wrote:

> Whether bridged traffic bypasses netfilter or not is controlled by
> the kernel sysctls
> 
>   net.bridge.bridge-nf-call-arptables = 1
>   net.bridge.bridge-nf-call-iptables = 1
>   net.bridge.bridge-nf-call-ip6tables = 1
> 
> If those are set to '1', then bridge traffic hits netfilter, if they
> are set to '0', it is bypassed.

Aha; I did not know that.  Thanks for the correction.

> No, [setting up KBM bridge networking] is utterly trivial
> 
>   # cd /etc/sysconfig/network-script
> 
>   # cat > ifcfg-eth0 <<EOF
>   DEVICE=eth0
>   HWADDR=00:16:76:D6:C9:45
>   ONBOOT=yes
>   BRIDGE=br0
>   EOF
> 
>   # cat > ifcfg-br0 <<EOF
>   DEVICE=br0
>   TYPE=Bridge
>   BOOTPROTO=dhcp
>   ONBOOT=yes
>   EOF
> 
>   # service network restart

You have a very strange definition of "utterly trivial", then.  :p

First, you have to *know* that you need to do this.  One's first clue
is an empty drop-down box in virt-manager's network configuration
options when you're creating a new guest.  After much Googling, if
you're lucky, you'll stumble across the KVM wiki and read the
networking section.  Then you have to figure out how much of that is
actually appropriate to Fedora + virt-manager.  Then you have to make
the above changes (and possibly reconfigure any iptables rules you had
set up).

How many end users (or, for that matter, unseasoned system
administrators) do you realistically think are going to make it through
that whole process?

To claim "out of the box" support for KVM bridge networking,
virt-manager has to be able to do all of this automatically.  That
means that either virt-manager itself needs to know how to turn a
physical device into a bridged device, or anaconda needs to do this at
system install time.  (E.g., any physical device configured with a
fixed IP address is automatically created as a bridge.)

> Job done, virt-manager will show you that br0 bridge and allow you
> to attach a guest to it

Actually, that *didn't* work for quite a while (the guest would
launch, but networking was non-functional).  However, I just now
re-tested, and you're right; virt-manager will Do The Right Thing (as
long as you've manually configured the bridge, that is).

> or out of the box you can use the 'virbr0' for NAT based
> connectivity that works even with wifi + network manager.

That's the best solution for mobile devices, for sure, but for
virtualizing a server, bridge networking is the only realistic option.
And right now, user-friendly support for that is sorely lacking.

-- 
STABILIZATION = CHAOS; END THE FED!
The Bailout Reader - <http://mises.org/story/3128>
The Rescue Package Will Delay Recovery - <http://mises.org/story/3131>
Taking Money Back - <http://mises.org/story/2882>



From mclasen at redhat.com  Fri Oct  3 18:44:29 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 03 Oct 2008 14:44:29 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <faa16b610810030913u5df5d8f3g726333dff82c15f4@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
	<20081003071728.1a69b725@infradead.org>
	<faa16b610810030913u5df5d8f3g726333dff82c15f4@mail.gmail.com>
Message-ID: <1223059469.3621.0.camel@localhost.localdomain>

On Fri, 2008-10-03 at 12:13 -0400, Colin Walters wrote:
> On Fri, Oct 3, 2008 at 10:17 AM, Arjan van de Ven <arjan at infradead.org> wrote:
> > On Fri, 03 Oct 2008 09:34:58 -0400
> > seth vidal <skvidal at fedoraproject.org> wrote:
> >> > >
> >> > Yes, but it is no problem for yum optionally check this settings if
> >> > it is available in system, right?
> >>
> >> Rather than instrument all apps so they can follow all desktop
> >> systems' mechanism for setting a proxy, wouldn't it make more sense
> >> to have a common way that all the desktops set?
> >>
> >
> > .... like http_proxy environment variable that everyone and their dog
> > (except firefox) uses ?
> 
> The problem is that to change an environment variable you have to log
> out, which is a pretty sucky user experience.

Dan Winship did some research into desktop wide sharing of various
http-related things, including proxies. See
http://live.gnome.org/LibSoup/DesktopWideHttp


Matthias



From katzj at redhat.com  Fri Oct  3 18:46:59 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 03 Oct 2008 14:46:59 -0400
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
	<20081003171721.GU18995@redhat.com>
	<4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>
Message-ID: <1223059619.19348.6.camel@aglarond.local>

On Fri, 2008-10-03 at 14:41 -0400, James Ralston wrote:
> To claim "out of the box" support for KVM bridge networking,
> virt-manager has to be able to do all of this automatically.  That
> means that either virt-manager itself needs to know how to turn a
> physical device into a bridged device, or anaconda needs to do this at
> system install time.  (E.g., any physical device configured with a
> fixed IP address is automatically created as a bridge.)

anaconda is certainly not going to do this.  Changing a device to be
bridged has some interesting consequences in a lot of networking
environments.  Not to mention that anaconda is getting out of the
business of the network setup as everything should be being handled by
NetworkManager

Jeremy



From dwinship at redhat.com  Fri Oct  3 19:05:24 2008
From: dwinship at redhat.com (Dan Winship)
Date: Fri, 03 Oct 2008 15:05:24 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
Message-ID: <48E66CF4.3010209@redhat.com>

KH KH wrote:
> 2008/10/2 Kulbir Saini <kulbirsaini at students.iiit.ac.in>:
>> Hi list,
>>
>>   Whenever I try a new version of Fedora, the first problem I face is
>> setting the proxy. It seems for almost every application, I have to specify
>> proxy at a different place. We have this "System -> Preferences -> Internet
>> and Network -> Network Proxy" app to specify proxy settings. But I wonder if
>> there is some application which obeys these settings.
>
> There is one: http://code.google.com/p/libproxy/
> https://bugzilla.redhat.com/show_bug.cgi?id=457035
> 
> I was waiting for upstream to answear to the patch before importing.
> (i will import soon)

To clarify, libproxy has multiple backends, so if it detects that you're
running in a GNOME session, it will look up proxy settings in GConf, and
if it detects that you're running in a KDE session, it will use kconfig,
and if none of those are set it will look at $http_proxy, or files in
/etc, or whatever else has been configured by your distro and/or
administrator.

And, it handles WPAD (Web Proxy Auto-Discovery) and PAC (Proxy
Auto-Configuration), which are the two annoying javascript-based proxy
configuration mechanisms.

And, for backends that support it (like GConf), it handles exception
lists ("use the proxy except when connecting to *.example.com and
192.168.0.0/24").

So it's generally a good thing. The catch is that not many apps are
using it yet. But the author is planning to propose it as a blessed
dependency for GNOME 2.26 (and have it be used in gvfs and libsoup), and
if that happens then that will pretty much guarantee that other distros
have to ship it too, at which point it becomes easier for more apps to
decide to depend on it, and eventually we might just reach uniform proxy
setting nirvana.

-- Dan



From katzj at redhat.com  Fri Oct  3 19:07:53 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 03 Oct 2008 15:07:53 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48E66CF4.3010209@redhat.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
Message-ID: <1223060873.19348.17.camel@aglarond.local>

On Fri, 2008-10-03 at 15:05 -0400, Dan Winship wrote:
> So it's generally a good thing. The catch is that not many apps are
> using it yet. But the author is planning to propose it as a blessed
> dependency for GNOME 2.26 (and have it be used in gvfs and libsoup), and
> if that happens then that will pretty much guarantee that other distros
> have to ship it too, at which point it becomes easier for more apps to
> decide to depend on it, and eventually we might just reach uniform proxy
> setting nirvana.

Most apps doing HTTP end up doing so via a library (I'd hope).  So the
next step would be getting support into libcurl and neon.  And possibly
some thought into, eg, urllib in python but urllib really needs to die
in favor of something nicer like urlgrabber on top of libcurl

Jeremy



From cra at WPI.EDU  Fri Oct  3 19:09:48 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 3 Oct 2008 15:09:48 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <80d7e4090810031139je423253v7a8ec101d513fa7@mail.gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<80d7e4090809301952sfc8882ckc41cd88652958238@mail.gmail.com>
	<200810022120.m92LKo3B006975@laptop14.inf.utfsm.cl>
	<80d7e4090810031139je423253v7a8ec101d513fa7@mail.gmail.com>
Message-ID: <20081003190948.GR24829@angus.ind.WPI.EDU>

On Fri, Oct 03, 2008 at 12:39:46PM -0600, Stephen John Smoogen wrote:
> Heh.. as I have gotten a lot of off list ribbing about this.. I am
> removing /sbin:/usr/sbin from my path and learning to type /usr/sbin
> for the commands I have 'shortcutted' over the years. Next I will be
> removing the bad habit of '/sbin/sudo bash' :).

Man, you've been typing those extra two characters all this time?

sudo -s



From walters at verbum.org  Fri Oct  3 19:23:19 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 3 Oct 2008 15:23:19 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <1223060873.19348.17.camel@aglarond.local>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
Message-ID: <faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>

On Fri, Oct 3, 2008 at 3:07 PM, Jeremy Katz <katzj at redhat.com> wrote:
> On Fri, 2008-10-03 at 15:05 -0400, Dan Winship wrote:
>> So it's generally a good thing. The catch is that not many apps are
>> using it yet. But the author is planning to propose it as a blessed
>> dependency for GNOME 2.26 (and have it be used in gvfs and libsoup), and
>> if that happens then that will pretty much guarantee that other distros
>> have to ship it too, at which point it becomes easier for more apps to
>> decide to depend on it, and eventually we might just reach uniform proxy
>> setting nirvana.
>
> Most apps doing HTTP end up doing so via a library (I'd hope).  So the
> next step would be getting support into libcurl and neon.  And possibly
> some thought into, eg, urllib in python but urllib really needs to die
> in favor of something nicer like urlgrabber on top of libcurl

Just a note, I'd like to see the desktop standardize around libsoup,
for two primary reasons:

1) Mainloop integration
2) Hopefully forthcoming support for reading Firefox cookies

There are some custom Python bindings in progress now if you swing
that way, and the introspection work in progress will bring access to
libsoup from a greater number of runtimes.



From lmacken at redhat.com  Fri Oct  3 19:24:11 2008
From: lmacken at redhat.com (Luke Macken)
Date: Fri, 3 Oct 2008 15:24:11 -0400
Subject: kdepim updates "pushed to stable" according to Bodhi, but tag
	not moved?
In-Reply-To: <loom.20081001T184622-51@post.gmane.org>
References: <loom.20081001T184622-51@post.gmane.org>
Message-ID: <20081003192411.GA5535@x300>

On Wed, Oct 01, 2008 at 06:49:30PM +0000, Kevin Kofler wrote:
> Hi,
> 
> Bodhi claims the following updates (submitted by me) have been pushed to 
> stable:
> kdepim-3.5.10-2.fc8
> kdepim-3.5.10-2.fc9
> 
> Yet they are still in dist-f8-updates-candidate resp. dist-f9-updates-candidate 
> and thus do not show up in the repo. So what's up with these? Aren't the tag 
> moves supposed to happen _before_ Bodhi says the update got pushed?

They seem to be tagged properly now, and should appear in the push that
is happening as we speak.

luke



From rdieter at math.unl.edu  Fri Oct  3 19:26:03 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 03 Oct 2008 14:26:03 -0500
Subject: KDE-SIG weekly report (40/2008)
References: <200810021449.36562.ml@deadbabylon.de>
	<48E6621F.9030908@fedoraproject.org>
Message-ID: <gc5rk2$lb1$1@ger.gmane.org>

Rahul Sundaram wrote:

> Sebastian Vahl wrote:
> 
>> 
>> mysql-embedded for amarok2:
>> --------------------------------------------
>> * The next beta of amarok2 will use mysql-embedded which isn't available
>> in Fedora.
>> * An old RFE also requests this enhancement (#149829). [1]
>> * We'll need to talk to the mysql-maintainers to make it possible to ship
>> a mysql-embedded package in F10.
>> * In a worst-case-scenario we'll have to fall back to amarok1 in F10.
> 
> IIRC, this has already been fixed in rawhide.

Yep, many thanks Tom Lane for making mysql-embedded a reality.

-- Rex




From lmacken at redhat.com  Fri Oct  3 19:28:16 2008
From: lmacken at redhat.com (Luke Macken)
Date: Fri, 3 Oct 2008 15:28:16 -0400
Subject: Broken dependencies: liveusb-creator
In-Reply-To: <48E651F2.7050202@redhat.com>
References: <20081003101036.5C5F31F8267@releng2.fedora.phx.redhat.com>
	<48E651F2.7050202@redhat.com>
Message-ID: <20081003192816.GB5535@x300>

On Fri, Oct 03, 2008 at 01:10:10PM -0400, Peter Jones wrote:
> buildsys at fedoraproject.org wrote:
>> liveusb-creator has broken dependencies in the development tree:
>> On ppc:
>> 	liveusb-creator-3.0-1.fc10.noarch requires syslinux
>> On ppc64:
>> 	liveusb-creator-3.0-1.fc10.noarch requires syslinux
>
> This is certainly a liveusb-creator bug, as syslinux has not ever, and 
> probably will not ever, build on ppc or ppc64.

Fixed.

luke



From berrange at redhat.com  Fri Oct  3 19:38:34 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 3 Oct 2008 20:38:34 +0100
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
	<20081003171721.GU18995@redhat.com>
	<4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>
Message-ID: <20081003193834.GD23876@redhat.com>

On Fri, Oct 03, 2008 at 02:41:05PM -0400, James Ralston wrote:
> On 2008-10-03 at 18:17+01 Daniel P Berrange <berrange at redhat.com> wrote:
> > No, [setting up KBM bridge networking] is utterly trivial
> > 
> >   # cd /etc/sysconfig/network-script
> > 
> >   # cat > ifcfg-eth0 <<EOF
> >   DEVICE=eth0
> >   HWADDR=00:16:76:D6:C9:45
> >   ONBOOT=yes
> >   BRIDGE=br0
> >   EOF
> > 
> >   # cat > ifcfg-br0 <<EOF
> >   DEVICE=br0
> >   TYPE=Bridge
> >   BOOTPROTO=dhcp
> >   ONBOOT=yes
> >   EOF
> > 
> >   # service network restart
> 
> You have a very strange definition of "utterly trivial", then.  :p

It is trival from an implementation POV. If you have the skills to 
configure a regular network interface, it is no harder to do bridging.

I accept it is badly documented though, hence why we created that
wiki page.

> First, you have to *know* that you need to do this.  One's first clue
> is an empty drop-down box in virt-manager's network configuration
> options when you're creating a new guest.  After much Googling, if
> you're lucky, you'll stumble across the KVM wiki and read the
> networking section.  Then you have to figure out how much of that is
> actually appropriate to Fedora + virt-manager.  Then you have to make
> the above changes (and possibly reconfigure any iptables rules you had
> set up).
> 
> How many end users (or, for that matter, unseasoned system
> administrators) do you realistically think are going to make it through
> that whole process?

There's two different audiences really - people who are serious
server administrators used to setting up crazy stuff like bonding,
vlans, bridging. This is not hard for them. Then, there is casual
deskop user / developer who aren't familiar with more complex
networking configs. The long term goal is that network manager 
should be addressing their needs. We don't want to implement
bridging control APIs in libvirt, because that's just a short term
hack - when people should really be focused on making NetworkManager
better

> To claim "out of the box" support for KVM bridge networking,
> virt-manager has to be able to do all of this automatically.  That
> means that either virt-manager itself needs to know how to turn a
> physical device into a bridged device, or anaconda needs to do this at
> system install time.  (E.g., any physical device configured with a
> fixed IP address is automatically created as a bridge.)

It works out of the box for NAT based networking. That's the only
config you can reasonably expect to configure out of the box without
any user interaction, because anything else requires an understanding
of the deployment environment we simply can't get right.

> > Job done, virt-manager will show you that br0 bridge and allow you
> > to attach a guest to it
> 
> Actually, that *didn't* work for quite a while (the guest would
> launch, but networking was non-functional).  However, I just now
> re-tested, and you're right; virt-manager will Do The Right Thing (as
> long as you've manually configured the bridge, that is).

Thta was a bug when DBus became more strict in how it wanted to be
called, and virt-manager was accidentally violating its rules. 

> > or out of the box you can use the 'virbr0' for NAT based
> > connectivity that works even with wifi + network manager.
> 
> That's the best solution for mobile devices, for sure, but for
> virtualizing a server, bridge networking is the only realistic option.
> And right now, user-friendly support for that is sorely lacking.

We aim NAT'ing at desktop/laptop users, while briding is for server
admins who are usually familiar with configuring network devices 
from sysconfig scripts

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From berrange at redhat.com  Fri Oct  3 19:40:26 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 3 Oct 2008 20:40:26 +0100
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <1223059619.19348.6.camel@aglarond.local>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
	<20081003171721.GU18995@redhat.com>
	<4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>
	<1223059619.19348.6.camel@aglarond.local>
Message-ID: <20081003194026.GE23876@redhat.com>

On Fri, Oct 03, 2008 at 02:46:59PM -0400, Jeremy Katz wrote:
> On Fri, 2008-10-03 at 14:41 -0400, James Ralston wrote:
> > To claim "out of the box" support for KVM bridge networking,
> > virt-manager has to be able to do all of this automatically.  That
> > means that either virt-manager itself needs to know how to turn a
> > physical device into a bridged device, or anaconda needs to do this at
> > system install time.  (E.g., any physical device configured with a
> > fixed IP address is automatically created as a bridge.)
> 
> anaconda is certainly not going to do this.  Changing a device to be
> bridged has some interesting consequences in a lot of networking
> environments.  Not to mention that anaconda is getting out of the
> business of the network setup as everything should be being handled by
> NetworkManager

I wouldn't expect anaconda todo this either - there's simply too many
complications with bridging to expect any tool to automatically get it
right. Ultimately networkmanager needs a capability optionally enable
sharing of a physical device between host & guest. It is getting much
closer to being ready for this type of capability with its recent
releases.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From james at fedoraproject.org  Fri Oct  3 20:35:22 2008
From: james at fedoraproject.org (James Antill)
Date: Fri, 03 Oct 2008 16:35:22 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
Message-ID: <1223066122.9470.68.camel@code.and.org>

On Fri, 2008-10-03 at 15:23 -0400, Colin Walters wrote:
> On Fri, Oct 3, 2008 at 3:07 PM, Jeremy Katz <katzj at redhat.com> wrote:
> > On Fri, 2008-10-03 at 15:05 -0400, Dan Winship wrote:
> >> So it's generally a good thing. The catch is that not many apps are
> >> using it yet. But the author is planning to propose it as a blessed
> >> dependency for GNOME 2.26 (and have it be used in gvfs and libsoup), and
> >> if that happens then that will pretty much guarantee that other distros
> >> have to ship it too, at which point it becomes easier for more apps to
> >> decide to depend on it, and eventually we might just reach uniform proxy
> >> setting nirvana.
> >
> > Most apps doing HTTP end up doing so via a library (I'd hope).  So the
> > next step would be getting support into libcurl and neon.  And possibly
> > some thought into, eg, urllib in python but urllib really needs to die
> > in favor of something nicer like urlgrabber on top of libcurl
> 
> Just a note, I'd like to see the desktop standardize around libsoup,
> for two primary reasons:
>
> 1) Mainloop integration

 Why do "desktop people" keep proposing things that are _only_
acceptable in a monolithic desktop application?

 Or do you seriously expect yum/anaconda/wget/whatever to use APIs that
work by directly hooking into the glib main loop?

 Also SSL support doesn't use NSS, and ftp support is non-existant.
NTLM/GSS support is also non-existant.

> 2) Hopefully forthcoming support for reading Firefox cookies
> 
> There are some custom Python bindings in progress now if you swing
> that way

 Ohh ... _in progress_ python bindings

-- 
James Antill -- <james at fedoraproject.org>
"Please, no.  Let's not pull in a dependency for something as simple as a
string library." -- Kristian H?gsberg <krh at redhat.com>



From walters at verbum.org  Fri Oct  3 20:42:04 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 3 Oct 2008 16:42:04 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <1223066122.9470.68.camel@code.and.org>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
	<1223066122.9470.68.camel@code.and.org>
Message-ID: <faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>

On Fri, Oct 3, 2008 at 4:35 PM, James Antill <james at fedoraproject.org> wrote:
>
>  Why do "desktop people" keep proposing things that are _only_
> acceptable in a monolithic desktop application?
>
>  Or do you seriously expect yum/anaconda/wget/whatever to use APIs that
> work by directly hooking into the glib main loop?

I didn't suggest that!  I was saying what direction I would like the
*desktop* to take.  Whether libsoup is appropriate for system
components is another discussion.

>> 2) Hopefully forthcoming support for reading Firefox cookies
>>
>> There are some custom Python bindings in progress now if you swing
>> that way
>
>  Ohh ... _in progress_ python bindings

I'm not sure why you're reacting with such hostility.



From james.antill at redhat.com  Fri Oct  3 20:53:40 2008
From: james.antill at redhat.com (James Antill)
Date: Fri, 03 Oct 2008 16:53:40 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
	<1223066122.9470.68.camel@code.and.org>
	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
Message-ID: <1223067220.9470.76.camel@code.and.org>

On Fri, 2008-10-03 at 16:42 -0400, Colin Walters wrote:
> On Fri, Oct 3, 2008 at 4:35 PM, James Antill <james at fedoraproject.org> wrote:
> >
> >  Why do "desktop people" keep proposing things that are _only_
> > acceptable in a monolithic desktop application?
> >
> >  Or do you seriously expect yum/anaconda/wget/whatever to use APIs that
> > work by directly hooking into the glib main loop?
> 
> I didn't suggest that!  I was saying what direction I would like the
> *desktop* to take.  Whether libsoup is appropriate for system
> components is another discussion.

 So I'm going to assume that we're, again, ignoring a bunch of real
Fedora users who use gnome-terminal on the desktop ... for all those 60+
year olds who don't, and are about to be a majority of our users RSN.

 But I have to ask, is gnome-PackageKit part of the desktop?
 Assuming so, are you suggesting that gnome-PackageKit override all yum
downloads that happen from as soon as a user logs into the desktop?
 Or maybe that some yum related downloads will happen with the "desktop"
proxy settings, and some with the "system" proxy settings?

 The desktop is more than just large _monolithic_ applications using the
glib main loop.

-- 
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/20081003/a84d28de/attachment.sig>

From walters at verbum.org  Fri Oct  3 20:59:13 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 3 Oct 2008 16:59:13 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
	<1223066122.9470.68.camel@code.and.org>
	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
Message-ID: <faa16b610810031359k159203a1o2c76d5d416b13a3e@mail.gmail.com>

On Fri, Oct 3, 2008 at 4:42 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, Oct 3, 2008 at 4:35 PM, James Antill <james at fedoraproject.org> wrote:
>>
>>  Why do "desktop people" keep proposing things that are _only_
>> acceptable in a monolithic desktop application?
>>
>>  Or do you seriously expect yum/anaconda/wget/whatever to use APIs that
>> work by directly hooking into the glib main loop?
>
> I didn't suggest that!  I was saying what direction I would like the
> *desktop* to take.  Whether libsoup is appropriate for system
> components is another discussion.

Though just for reference, I do think that an event loop is the right
way to structure many different kinds of programs, even those which do
not use GTK+.  It's unfortunate that most programming languages (and
consequently, libraries like urllib or java.net.URLConnection) are not
designed around the concept of a mainloop, but that's where we are.

But to do the Firefox cookies right, libsoup is going to require both
SQLite (to read the cookies file) and DBus (to get notifications from
Firefox of changes).  Now, these dependencies may not be suitable for
all applications or system components, and the basic built-in HTTP
functionality that comes with runtimes like urllib or
java.net.URLConnection are going to be more familar to programmers,
and if you don't need the extra functionality it will continue to make
sense to use those.



From walters at verbum.org  Fri Oct  3 21:02:24 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 3 Oct 2008 17:02:24 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <1223067220.9470.76.camel@code.and.org>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
	<1223066122.9470.68.camel@code.and.org>
	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
	<1223067220.9470.76.camel@code.and.org>
Message-ID: <faa16b610810031402q26a06ce6i8f56ffda70480e67@mail.gmail.com>

2008/10/3 James Antill <james.antill at redhat.com>:
>
>  So I'm going to assume that we're, again, ignoring a bunch of real
> Fedora users who use gnome-terminal on the desktop ... for all those 60+
> year olds who don't, and are about to be a majority of our users RSN.
>
>  But I have to ask, is gnome-PackageKit part of the desktop?
>  Assuming so, are you suggesting that gnome-PackageKit override all yum
> downloads that happen from as soon as a user logs into the desktop?
>  Or maybe that some yum related downloads will happen with the "desktop"
> proxy settings, and some with the "system" proxy settings?

I think it would make sense for things like "yum install foo" *when
invoked as nonroot* to call pkcon to accomplish the task.



From mw_triad at users.sourceforge.net  Fri Oct  3 21:14:51 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 03 Oct 2008 16:14:51 -0500
Subject: Please recompile GStreamer codecs -- AKA: how to make things
 just work with PackageKit
In-Reply-To: <48E3031F.5060408@leemhuis.info>
References: <1222771953.3291.12.camel@hughsie-laptop>	<48E209E5.5070705@leemhuis.info>	<15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com>	<48E251BE.2090209@leemhuis.info>	<gbtr8l$6ie$1@ger.gmane.org>
	<48E3031F.5060408@leemhuis.info>
Message-ID: <gc620b$f8i$1@ger.gmane.org>

Thorsten Leemhuis wrote:
> On 30.09.2008 20:30, Matthew Woehlke wrote:
>> Given the recent security scare, is this information (along with keys, 
>> I hope!) also posted somewhere "trustworthy"?
> 
> Not yet, sorry. It's a whole lot of work to get a new repo running and 
> nobody thought of the above yet afaics.

Ok.

>> Would it be possible to drop a new-release rpm into livna so that 
>> livna users can get the new repo rpm from livna rather than having to 
>> trust the URL in (if you'll pardon me) some random e-mail?
> 
> Yes, exactly that is the plan (that was already mentioned two mails 
> earlier in this thread) ;-)

Ah, seems I missed that the first time, thanks!

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Warning: prolonged exposure to GNU/Linux may cause addiction.



From schristley at mac.com  Sat Oct  4 03:11:10 2008
From: schristley at mac.com (Scott Christley)
Date: Fri, 03 Oct 2008 20:11:10 -0700
Subject: GNUstep
Message-ID: <E4C9AE8F-FDC7-48D1-A5B1-FA0856B4B2AB@mac.com>

Greetings,

I'm new to Fedora and am interested in helping get GNUstep included  
into Fedora.  I'm one of the original developers of GNUstep but have  
long since moved up into user space, so I have the ulterior motive  
that I can get my own free software research tools (which depend on  
GNUstep) packaged into Fedora too some day!

Anyways, I discovered that the topic has come up recently and the  
discussion summarized in Fedora weekly news:

http://fedoraproject.org/wiki/FWN/Issue140#GNUstep_Filesystem_Layout_Discussion

so I've read through the emails and tried as much as I could to  
understand the issues related to the GNUstep directory structure  
fitting with the FHS. I'm not an expert in FSH, so don't think I can  
say straight out what I think the best solution, but I offer some  
opinions.

Development using GNUstep can produce a number of different products,  
the core ones being:

tools
libraries
applications
frameworks
bundles

Now tools and libraries are well-known concepts, a tool is a command- 
line program typically self-contained, and a library is a binary  
object with some header files.  The other products are different in  
that they are wrappers for a directory structure and a set of files.   
Applications are graphical programs, frameworks are library wrappers  
and bundles are executable code to be dynamically loaded at runtime.   
They are wrappers because there are many files involved, take an  
application, beside the executable object it has files for GUI  
elements, configuration, localized strings, localized GUI elements,  
images, sounds, other media, etc. etc., all kinds of resources as they  
are called.  A sophisticated application could easily have hundreds of  
such resource files, frameworks and bundles can have any set of  
resources files as well.

So my suggestion would be:

* tools mostly but also sometimes libraries can have clear role  
outside GNUstep, so it is appropriate to treat them as such.  My  
suggestion would be FHS and flattened, so that they get install in  
expected places like ${_bindir} and %{_libdir}.

* let applications, frameworks and bundles live within the pure  
GNUstep layout.

I'm sure I didn't touch on many of the issues that were brought up, so  
I look forward to your comments!

cheers
Scott



From tim.lauridsen at googlemail.com  Sat Oct  4 06:03:07 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sat, 04 Oct 2008 08:03:07 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <faa16b610810031402q26a06ce6i8f56ffda70480e67@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>	<48E66CF4.3010209@redhat.com>	<1223060873.19348.17.camel@aglarond.local>	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>	<1223066122.9470.68.camel@code.and.org>	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>	<1223067220.9470.76.camel@code.and.org>
	<faa16b610810031402q26a06ce6i8f56ffda70480e67@mail.gmail.com>
Message-ID: <48E7071B.5050507@googlemail.com>

Colin Walters wrote:
> 2008/10/3 James Antill <james.antill at redhat.com>:
>   
>>  So I'm going to assume that we're, again, ignoring a bunch of real
>> Fedora users who use gnome-terminal on the desktop ... for all those 60+
>> year olds who don't, and are about to be a majority of our users RSN.
>>
>>  But I have to ask, is gnome-PackageKit part of the desktop?
>>  Assuming so, are you suggesting that gnome-PackageKit override all yum
>> downloads that happen from as soon as a user logs into the desktop?
>>  Or maybe that some yum related downloads will happen with the "desktop"
>> proxy settings, and some with the "system" proxy settings?
>>     
>
> I think it would make sense for things like "yum install foo" *when
> invoked as nonroot* to call pkcon to accomplish the task.
>
>   
Hmmm.
1.  yum-cli -> yum-api -> pk-con -> pk -> DBUS -> pk-backend -> 
yum-backend -> yum-api -> install the package

compare to

2. yum-cli -> yum-api -> install the package

here is kind og chicken and egg problem here.

take this user case.

ssh to some server
yum install foo
how would that work.

Dont forget that PackageKit is a highlevel abstraction to the low level 
package management system, making the low level system use the highlevel 
abstraction of it self, is kind of crazy. IMHO.

Tim


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

From mschwendt at gmail.com  Sat Oct  4 07:49:50 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 4 Oct 2008 09:49:50 +0200
Subject: Fedora 10 early branch now available.
In-Reply-To: <1222962137.6265.53.camel@luminos.localdomain>
References: <1222904756.6265.34.camel@luminos.localdomain>
	<48E48073.9060905@kanarip.com>
	<1222962137.6265.53.camel@luminos.localdomain>
Message-ID: <20081004094950.e2c8b6cc.mschwendt@gmail.com>

On Thu, 02 Oct 2008 08:42:17 -0700, Jesse Keating wrote:

> On Thu, 2008-10-02 at 10:04 +0200, Jeroen van Meeuwen wrote:
> > Awesome! Is this something that is considered to become the de-facto 
> > standard (as in mass-early-branching) sooner or later?
> 
> Likely not.  There are two sets of folks we're trying to satisfy, those
> that actually continue on with future development, and those that need
> the entire development cycle for the current release.  Early branching
> the latter folks just adds more work for them every time they do a build
> as to not have upgrade path issues and to not forget to build for the
> next rawhide.  By letting maintainers choose for themselves when to
> branch we can satisfy both sets of maintainers.

Unconvincing and not helpful IMO.

Upgrade path issues between soon-to-be-F10 and F11-development are pretty
much irrelevant. Those with no interest in F11-development may commit
to F-10 only and ignore devel for now. They may sync updates later or
on demand.

And as soon as some people ask for an early branch, they may go on with
future development and break ABI/API/whatever, which in turn needs
rebuilds and activity from other maintainers. Affected maintainers can
only catch up if they request an early branch themselves. Else rawhide
breaks into more and more pieces until F-10 is branched officially.
However, the new development packages cannot be installed anyway as long
as it still targets F10. Please branch fully or let it be. Bureaucracy
added on top of private repos in koji is not good.



From jonathan at jonmasters.org  Sat Oct  4 08:25:38 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Sat, 04 Oct 2008 04:25:38 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <48E61A7E.8010404@redhat.com>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
Message-ID: <1223108738.9328.40.camel@perihelion.int.jonmasters.org>

On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:

> > $ mount -o loop Fedora-9-i386-DVD.iso /mnt
> > 
> > And then one might legitimately expect to be able to copy the content
> > of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
> > suppose that one is running SELinux in enforcing mode, then this will
> > fail because the contexts differ in this operation. Then, one will
> > likely quickly become severely annoyed and frustrated with SELinux,
> > simply setting it permissive for the duration of the operation...

> Why would the copy fail?  cp should just work and set the files to the
> context of the destination directory.  If this fails it is a bug.

Ok, so there's a bug there then. Copying files from within an ISO image
was kind of the last straw in my willingness to keep SELinux enabled. It
hinders me at almost every turn from doing useful things with a Linux
desktop - I'm constantly amazed that Fedora persists in defaulting it
enabled, but that's a whole other rant.

Jon.



From rawhide at fedoraproject.org  Sat Oct  4 10:58:54 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat,  4 Oct 2008 10:58:54 +0000 (UTC)
Subject: rawhide report: 20081004 changes
Message-ID: <20081004105854.2DA521B8001@releng2.fedora.phx.redhat.com>

New package gedit-latex-plugin
        Gedit plugin for composing and compiling LaTeX documents
New package hunspell-hy
        Armenian hunspell dictionaries
New package hunspell-km
        Khmer hunspell dictionaries
New package hunspell-mg
        Malagasy hunspell dictionaries
New package libmicrohttpd
        Lightweight library for embedding a webserver in applications
New package perl-Software-License
        Package that provides templated software licenses
New package tuxguitar
        A multitrack tablature editor and player written in Java-SWT
Removed package akode
Updated Packages:

afflib-3.3.4-4.fc10
-------------------
* Fri Oct  3 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.3.4-4
- Fix release mismatch

* Fri Oct  3 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.3.4-3
- Update to 3.3.4


anaconda-11.4.1.43-1
--------------------
* Fri Oct  3 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.43-1
- Disable IPv6 interface widgets in loader for now. (dcantrell)
- Start NetworkManager earlier (#462083) (hans)
- Work around gtk2 bug (#465541) (hans)
- Move our yum.conf out of /etc (#465160) (katzj)
- Correctly display the IP address a vnc viewer should connect to (#465353).
  (clumens)
- lohit-fonts-malayam has been replaced by smc-fonts-meera (#456449).
  (clumens)
- Fix a typo in cleaning up repos. (clumens)
- Fix the mount error reading for real this time (pjones, #465250). (clumens)
- Support ksdevice=link when booting from boot.iso. (dcantrell)
- Automatically select NIC based on ksdevice= boot parameter. (dcantrell)


at-spi-1.24.0-4.fc10
--------------------
* Fri Oct  3 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.24.0-4
- Prevent at-spi module from being unloaded


bluez-4.10-1.fc10
-----------------
* Fri Oct  3 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.10-1
- Update to 4.10


bug-buddy-2.24.0-2.fc10
-----------------------
* Fri Oct  3 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.0-2
- Make the gtk module resident, since unloading it is not good


cairo-dock-1.6.3-0.1.svn1336_trunk.fc10
---------------------------------------
* Sat Oct  4 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1336


chess-1.0-20.fc10
-----------------
* Fri Oct  3 18:00:00 2008 Alexey Torkhov <atorkhov at gmail.com> 1.0-20
- Fixing broken deps


collectd-4.4.3-1.fc10
---------------------
* Fri Oct  3 18:00:00 2008 Alan Pevec <apevec at redhat.com> 4.4.3-1
- new upstream bugfix release 4.4.3 http://collectd.org/news.shtml#news57


control-center-2.24.0.1-3.fc10
------------------------------
* Sat Oct  4 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0.1-3
- Fix help buttons in the appearance capplet


dosbox-0.72-5.fc10
------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.72-5
- Fix Patch0:/%patch mismatch.


dump-0.4b41-9.fc10
------------------
* Fri Oct  3 18:00:00 2008 Adam Tkac <atkac redhat com> 0.4b41-9
- dump-0.4b37-2TB.patch is no longer needed
- rebuild (#464989)


eclipse-rpm-editor-0.4.0-3.fc10
-------------------------------
* Fri Oct  3 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 0.4.0-3
- Rebuild for #465109.

* Wed Jul 30 18:00:00 2008 Andrew Overholt <overholt at redhat.com> 0.4.0-2
- Update for Eclipse SDK 3.4
- Remove noarch potential since CDT is arch-specific and we
  ExclusiveArch


gc-7.1-4.fc10
-------------
* Fri Oct  3 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 7.1-4
- BR: libatomic_ops-devel


gdesklets-0.36-2.fc10
---------------------
* Fri Oct  3 18:00:00 2008 Luya Tshimbalanga <luya_tfz at thefinalzone.com> - 0.36-2
- Cleaned up spec
- Minor fixes


gnu-efi-3.0e-2.fc10
-------------------
* Fri Oct  3 18:00:00 2008 Peter Jones <pjones at redhat.com> - 3.0e-2
- Fix install paths on x86_64.

* Thu Oct  2 18:00:00 2008 Peter Jones <pjones at redhat.com> - 3.0e-1
- Update to 3.0e
- Fix relocation bug in 3.0e


gstreamer-0.10.21-1.fc10
------------------------
* Fri Oct  3 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.10.21-1
- Update to 0.10.21


gstreamer-plugins-base-0.10.21-2.fc10
-------------------------------------
* Fri Oct  3 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.10.21-2
- Update the gstreamer requirement
- Add a gtk2-devel BR, so that the test-colorkey program will be built

* Fri Oct  3 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.10.21-1
- Update to 0.10.21


gtk2-2.14.3-5.fc10
------------------
* Fri Oct  3 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.3-5
- Prevent unloading of the gail module


guidance-power-manager-4.1.2-1.fc10
-----------------------------------
* Fri Oct  3 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-1
- 4.1.2


hunspell-ku-0.21-3.fc10
-----------------------
* Fri Oct  3 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.21-3
- add aliases for OOo


ibus-0.1.1.20081004-1.fc10
--------------------------
* Sat Oct  4 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081004-1
- Update to 0.1.1.20081004.


ibus-pinyin-0.1.1.20081004-1.fc10
---------------------------------
* Sat Oct  4 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081004-1
- Update version to 0.1.1.20081004.


kdesvn-1.2.1-1.fc10
-------------------
* Fri Oct  3 18:00:00 2008 - Orion Poplawski <orion at cora.nwra.com> - 1.2.1-1
- Update to 1.2.1


kiconedit-4.1.2-1.fc10
----------------------
* Fri Oct  3 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-1
- 4.1.2


libgdamm-3.0.1-1.fc10
---------------------
* Fri Oct  3 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 3.0.1-1
- Update to upstream 3.0.1, bugfix release


libtheora-1.0rc1-2.fc10
-----------------------
* Fri Oct  3 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 1.0rc1-2
- Fix build on x86_64

* Fri Oct  3 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 1.0rc1-1
- Update to 1.0rc1


libusb-0.1.12-17.fc10
---------------------
* Sat Aug  2 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 0.1.12-17
- apply patch from Graeme Gill to fix concurrency timeout
  handling (#456811)

* Fri Apr 18 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 0.1.12-16
- rebuild to fix broken ppc build


libxml2-2.7.2-1.fc10
--------------------
* Fri Oct  3 18:00:00 2008 Daniel Veillard <veillard at redhat.com> 2.7.2-1.fc10
- new release 2.7.2
- Fixes the known problems in 2.7.1
- increase the set of options when saving documents


liveusb-creator-3.0-2.fc10
--------------------------
* Fri Oct  3 18:00:00 2008 Luke Macken <lmacken at redhat.com> 3.0-2
- Exclude ppc and ppc64, as syslinux will not work on those architectures.


lxsplit-0.2.4-1.fc10
--------------------
* Fri Oct  3 18:00:00 2008 Rahul Sundaram <sundaram at fedoraproject.org> - 0.2.4-1
- new upstream release


maven-wagon-1.0-0.1.a5.3.4.fc10
-------------------------------
* Fri Oct  3 18:00:00 2008 Matt Wringe <mwringe at redhat.com> - 0:1.0-0.1.a5.3.4
- added patch to make it compatible with the newer version of jsch


mtools-3.9.11-5.fc10
--------------------
* Fri Oct  3 18:00:00 2008 Adam Tkac <atkac redhat com> 3.9.11-5
- mtools-3.9.9-noargs.patch and mtools-3.9.6-paths.patch are not needed
- rebuild (#465040)


netbsd-iscsi-20080207-1.fc10
----------------------------
* Fri Oct  3 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 20080207-1
- Update to more recent upstream code
- Remove the silly prealocation code (#465533)


nntpgrab-0.3.92-2.fc10
----------------------
* Fri Oct  3 18:00:00 2008 Erik van Pienbroek <info at nntpgrab.nl> - 0.3.92-2
- Tarball was respun by upstream

* Fri Oct  3 18:00:00 2008 Erik van Pienbroek <info at nntpgrab.nl> - 0.3.92-1
- Update to 0.3.92
- Drop upstreamed patch


packagekit-qt-0.1-2.fc10
------------------------
* Fri Oct  3 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1-2
- Properly split into main and -devel package, not just -devel
- Run ldconfig in %post and %postun


paraview-3.4.0-0.20081002.1.fc10
--------------------------------
* Thu Oct  2 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 3.4.0-0.20081002.1
- Update 3.4.0 CVS snapshot
- Update gcc43 patch
- Drop qt patch, upstream now allows compiling against Qt 4.4.*


perl-Module-CPANTS-Analyse-0.82-2.fc10
--------------------------------------
* Fri Oct  3 18:00:00 2008 Daniel P. Berrange <berrange at redhat.com> - 0.82-2
- Added more new & missing BRs

* Fri Sep  5 18:00:00 2008 Daniel P. Berrange <berrange at redhat.com> - 0.82-1
- Update to 0.82 release


revelation-0.4.11-5.1
---------------------
* Fri Oct  3 18:00:00 2008 Jef Spaleta <jspaleta at fedoraproject.org> - 0.4.11-5.1
- Depchain fix.

* Fri Oct  3 18:00:00 2008 Jef Spaleta <jspaleta at fedoraproject.org> - 0.4.11-5
- Minor patch to ui.py to fix broken menu generation.


rhm-0.2.2578-1.fc10
-------------------
* Fri Oct  3 18:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0.2.2578-1
- Rebased to svn revision 2578


rhythmbox-0.11.6-12.5966.fc10
-----------------------------
* Fri Oct  3 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-12.r5966
- Update to latest trunk
- Fix license info to match that of upstream


roundup-1.4.6-1.fc10
--------------------
* Fri Oct  3 18:00:00 2008 Paul P. Komkoff Jr <i at stingr.net> - 1.4.6-1
- new upstream version


rsh-0.17-51.fc10
----------------
* Fri Oct  3 18:00:00 2008 Adam Tkac <atkac redhat com> 0.17-51
- updated ipv6 patch due rpm 4.6 (#465053)
- make in.rshd working on kernels without audit support (#448904)


scipy-0.6.0-7.fc10
------------------
* Fri Oct  3 18:00:00 2008 Jef Spaleta <jspaleta at fedoraproject.org> - 0.6.0-7
- fix the stsci fix

* Thu Oct  2 18:00:00 2008 Jef Spaleta <jspaleta at fedoraproject.org> - 0.6.0-6
- include missing setup files for stsci module


selinux-policy-3.5.10-2.fc10
----------------------------
* Fri Oct  3 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.10-2
- Allow confined users and xdm to exec wm
- Allow nsplugin to talk to fifo files on nfs

* Fri Oct  3 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.10-1
- Allow NetworkManager to transition to avahi and iptables
- Allow domains to search other domains keys, coverup kernel bug


sim-0.9.5-0.10.20080923svn2261rev.fc10
--------------------------------------
* Sat Oct  4 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.9.20080923svn2261rev
- Add %{?dist} into Release!
- Add icon-update-code into %post/%postun. (thanks to Patrice Dumas)

* Sat Oct  4 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.8.20080923svn2261rev
- Add BR desktop-file-utils

* Sat Oct  4 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.10.20080923svn2261rev
- Replace %post -p /sbin/ldconfig by simlply:
	%post
	/sbin/ldconfig
	And accodingly in %postun due tu rpmlint warning:
	sim.i386: E: postin-without-ldconfig /usr/lib/libsim.so.0.0.0
	(I not found what mean -p key, but appologise what it designed to run 1 command only)

* Fri Oct  3 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.7.20080923svn2261rev
- By suggestion of Patrice Dumas use macros bcond_with instead of manual define with_kde
- For Fedora8 BR kdebase changed to kdebase-devel for fedora > 8 add BR kdebase3-devel >= 3.0.0 (Patrice Dumas)
- Remove CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" and $LOCALFLAGS
	in configure, and "rm -rf $RPM_BUILD_DIR/%{name}-%{version}" in %clean,
	gcc and gcc-c++ from BR (Patrice Dumas)
- Use make %{?_smp_mflags} instead of manually determine number of CPUs (Patrice Dumas)
- Remove Distribution: Fedora. (Patrice Dumas)


slapi-nis-0.8.1-1.fc10
----------------------
* Fri Oct  3 18:00:00 2008 Nalin Dahyabhai <nalin at redhat.com> - 0.8.1-1
- update to 0.8.1 to fix a heap corruption (Rich Megginson)


sleuthkit-3.0.0-0.1.b4.fc10
---------------------------
* Fri Oct  3 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.0-0.1.b4
- Update to 3.0.0b4


tuxcmd-0.6.50-1.fc10
--------------------
* Fri Oct  3 18:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 0.6.50-1
- Update to v0.6.50


xdelta-1.1.4-4.fc10
-------------------
* Fri Oct  3 18:00:00 2008 Adam Tkac <atkac redhat com> 1.1.4-4
- updated patches due rpm 4.6 (#465102)


xorg-x11-drv-evdev-2.0.6-1.fc10
-------------------------------
* Fri Oct  3 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 2.0.6-1
- update to 2.0.6
- remove patches merged upstream.


Summary:
Added Packages: 7
Removed Packages: 1
Modified Packages: 50
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	beagle-evolution-0.3.8-6.fc10.i386 requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	beagle-evolution-0.3.8-6.fc10.x86_64 requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	beagle-evolution-0.3.8-6.fc10.ppc requires mono(evolution-sharp) = 0:3.0.0.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From Christian.Iseli at unil.ch  Sat Oct  4 13:38:56 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Sat, 4 Oct 2008 15:38:56 +0200
Subject: SELinux - copying ISO file content
In-Reply-To: <48E61B1C.70603@redhat.com>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<20081003091511.73410983@ludwig-alpha.unil.ch>
	<48E61B1C.70603@redhat.com>
Message-ID: <20081004153856.22483543@ludwig-alpha.unil.ch>

On Fri, 03 Oct 2008 09:16:12 -0400, Daniel J Walsh wrote:
> Well first this is not a copy it is a move.  The problem here is the
> mv command is attempting to retain the file context of
> gr.078212.108v2.pdf, if you did a cp it would work.

IIRC, cp failed too.

> What avc are you seeing?

Below are those I used to feed to audit2allow

Cheers,
					Christian

host=Rivendell type=AVC msg=audit(1222961359.881:97): avc: denied { associate }for pid=3116 comm="mv" name="gr.078212.108v2.pdf" scontext=unconfined_u:object_r:user_home_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
host=Rivendell type=SYSCALL msg=audit(1222961359.881:97): arch=40000003 syscall=5 success=no exit=-13 a0=92aa3f0 a1=80c1 a2=180 a3=80c1 items=0 ppid=2778 pid=3116 auid=2890 uid=2890 gid=2890 euid=2890 suid=2890 fsuid=2890 egid=2890 sgid=2890 fsgid=2890 tty=pts2 ses=2 comm="mv" exe="/bin/mv" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
host=Rivendell type=AVC msg=audit(1223001293.211:917): avc: denied { getattr } for pid=5913 comm="updatedb" path="/home/chris/VMShared" dev=vboxsf ino=0 scontext=system_u:system_r:locate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
host=Rivendell type=SYSCALL msg=audit(1223001293.211:917): arch=40000003 syscall=196 success=no exit=-13 a0=9a1f6b5 a1=bfcf70a8 a2=9e4ff4 a3=9a1f6b5 items=0 ppid=5907 pid=5913 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=199 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0-s0:c0.c1023 key=(null)
host=Rivendell type=AVC msg=audit(1223001183.679:916): avc: denied { getattr } for pid=5580 comm="df" name="/" dev=vboxsf ino=0 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
host=Rivendell type=SYSCALL msg=audit(1223001183.679:916): arch=40000003 syscall=268 success=no exit=-13 a0=86b24f0 a1=54 a2=bf9c0958 a3=0 items=0 ppid=5578 pid=5580 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)ses=199 comm="df" exe="/bin/df" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)



From walters at verbum.org  Sat Oct  4 15:34:21 2008
From: walters at verbum.org (Colin Walters)
Date: Sat, 4 Oct 2008 11:34:21 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48E7071B.5050507@googlemail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
	<1223066122.9470.68.camel@code.and.org>
	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
	<1223067220.9470.76.camel@code.and.org>
	<faa16b610810031402q26a06ce6i8f56ffda70480e67@mail.gmail.com>
	<48E7071B.5050507@googlemail.com>
Message-ID: <faa16b610810040834l474e69dfv59cadb2fe6adcac1@mail.gmail.com>

2008/10/4 Tim Lauridsen <tim.lauridsen at googlemail.com>:
>
> Hmmm.
> 1.  yum-cli -> yum-api -> pk-con -> pk -> DBUS -> pk-backend -> yum-backend
> -> yum-api -> install the package
>
> compare to
>
> 2. yum-cli -> yum-api -> install the package

You could also use the python dbus bindings directly, or python
bindings for libpk.

> here is kind og chicken and egg problem here.

There's no chicken-egg - the patch would look like this:

if 'DBUS_SESSION_BUS_ADDRESS' in os.environ:
  if cmd == 'install':
   execv(['pkcon', 'install', sys.argv[1:]])
  elif cmd == 'search':
   execv(['pkcon', 'search', 'name', sys.argv[1:])
  # ..and maybe a total of 3-4 more commands.  Personally, I only use those two.

> take this user case.
>
> ssh to some server
> yum install foo
> how would that work.

With a change like the above, it would be unaffected, at least for now.

> Dont forget that PackageKit is a highlevel abstraction to the low level
> package management system, making the low level system use the highlevel
> abstraction of it self, is kind of crazy. IMHO.

The (first) lower level system is yum-api, yum-cli and pkcon are
really at the same level. It would make sense long term to having them
be more merged.



From drago01 at gmail.com  Sat Oct  4 16:32:22 2008
From: drago01 at gmail.com (drago01)
Date: Sat, 4 Oct 2008 18:32:22 +0200
Subject: Post-beta bugfix phase
In-Reply-To: <6bb886180810012014q40ad878bv957f018714efa3@mail.gmail.com>
References: <1222905252.6265.43.camel@luminos.localdomain>
	<6bb886180810012014q40ad878bv957f018714efa3@mail.gmail.com>
Message-ID: <f6ca9fed0810040932u343c6d85se45f76592a833a3a@mail.gmail.com>

2008/10/2 David Hunter <davehoz at gmail.com>:
> GNOME desktop effects is broken on my system.

Please be more verbose (broken in which way? what kind of hardware?
etc.) and file a bug.



From skvidal at fedoraproject.org  Sat Oct  4 16:51:30 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 04 Oct 2008 12:51:30 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <faa16b610810040834l474e69dfv59cadb2fe6adcac1@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>
	<48E66CF4.3010209@redhat.com>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
	<1223066122.9470.68.camel@code.and.org>
	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
	<1223067220.9470.76.camel@code.and.org>
	<faa16b610810031402q26a06ce6i8f56ffda70480e67@mail.gmail.com>
	<48E7071B.5050507@googlemail.com>
	<faa16b610810040834l474e69dfv59cadb2fe6adcac1@mail.gmail.com>
Message-ID: <1223139090.21327.0.camel@rosebud>

On Sat, 2008-10-04 at 11:34 -0400, Colin Walters wrote:
> 2008/10/4 Tim Lauridsen <tim.lauridsen at googlemail.com>:
> >
> > Hmmm.
> > 1.  yum-cli -> yum-api -> pk-con -> pk -> DBUS -> pk-backend -> yum-backend
> > -> yum-api -> install the package
> >
> > compare to
> >
> > 2. yum-cli -> yum-api -> install the package
> 
> You could also use the python dbus bindings directly, or python
> bindings for libpk.
> 
> > here is kind og chicken and egg problem here.
> 
> There's no chicken-egg - the patch would look like this:
> 
> if 'DBUS_SESSION_BUS_ADDRESS' in os.environ:
>   if cmd == 'install':
>    execv(['pkcon', 'install', sys.argv[1:]])
>   elif cmd == 'search':
>    execv(['pkcon', 'search', 'name', sys.argv[1:])
>   # ..and maybe a total of 3-4 more commands.  Personally, I only use those two.
> 
> > take this user case.
> >
> > ssh to some server
> > yum install foo
> > how would that work.
> 
> With a change like the above, it would be unaffected, at least for now.
> 
> > Dont forget that PackageKit is a highlevel abstraction to the low level
> > package management system, making the low level system use the highlevel
> > abstraction of it self, is kind of crazy. IMHO.
> 
> The (first) lower level system is yum-api, yum-cli and pkcon are
> really at the same level. It would make sense long term to having them
> be more merged.

They're not at the same level.

yum-cli talks directly to the api.

pkcon talks to the pk dbus interface which then talks to the yum-module
for pk which then talks to the yum api.


-sv




From pertusus at free.fr  Sat Oct  4 17:02:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 4 Oct 2008 19:02:39 +0200
Subject: proposal for make help chain-build text
In-Reply-To: <48E5D9AA.9060505@city-fan.org>
References: <20080928122103.GA2728@free.fr> <20081003083131.GC3270@free.fr>
	<48E5D9AA.9060505@city-fan.org>
Message-ID: <20081004170238.GA31243@free.fr>

On Fri, Oct 03, 2008 at 09:36:58AM +0100, Paul Howarth wrote:
>
> Test looks good to me, and certainly explains things better than the  
> existing text.

Can you apply it?

--
Pat



From pertusus at free.fr  Sat Oct  4 17:23:03 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 4 Oct 2008 19:23:03 +0200
Subject: procedure for renaming a package
Message-ID: <20081004172303.GB31243@free.fr>

Hello,

I'd like to rename tetex-tex4ht to tex-tex4ht together with
texlivisation. However I cannot find in the wiki the procedure that can
be used to rename a package without changing anything else. There are a
lot of information somehow related but nothing really appropriate -- or
I didn't found it.

More precisely, it doesn't seems to be on
http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
There are elements on
http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife
but it isn't really appropriate (in my opinion appropriate informations
should go here).
I found nothing relevant in
http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo
http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb
http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq

Did I missed something? If not, what is the procedure?

--
Pat



From debarshi.ray at gmail.com  Sat Oct  4 17:48:48 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sat, 4 Oct 2008 23:18:48 +0530
Subject: procedure for renaming a package
In-Reply-To: <20081004172303.GB31243@free.fr>
References: <20081004172303.GB31243@free.fr>
Message-ID: <3170f42f0810041048m7205986bi483e98b0dae1d16e@mail.gmail.com>

https://www.redhat.com/archives/fedora-packaging/2008-October/msg00004.html

Happy hacking,
Debarshi



From walters at verbum.org  Sat Oct  4 18:13:09 2008
From: walters at verbum.org (Colin Walters)
Date: Sat, 4 Oct 2008 14:13:09 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <1223139090.21327.0.camel@rosebud>
References: <48E48E04.1080906@students.iiit.ac.in>
	<1223060873.19348.17.camel@aglarond.local>
	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>
	<1223066122.9470.68.camel@code.and.org>
	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>
	<1223067220.9470.76.camel@code.and.org>
	<faa16b610810031402q26a06ce6i8f56ffda70480e67@mail.gmail.com>
	<48E7071B.5050507@googlemail.com>
	<faa16b610810040834l474e69dfv59cadb2fe6adcac1@mail.gmail.com>
	<1223139090.21327.0.camel@rosebud>
Message-ID: <faa16b610810041113k5878d4c2nb89ed6300cc0222f@mail.gmail.com>

On Sat, Oct 4, 2008 at 12:51 PM, seth vidal <skvidal at fedoraproject.org> wrote:
>
> They're not at the same level.
>
> yum-cli talks directly to the api.
>
> pkcon talks to the pk dbus interface which then talks to the yum-module
> for pk which then talks to the yum api.

I guess the level I was referring to was more the user experience
level - they are both the interface to the system, regardless of
implementation details.



From kevin.kofler at chello.at  Sat Oct  4 18:33:19 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 4 Oct 2008 18:33:19 +0000 (UTC)
Subject: rawhide report: 20081004 changes
References: <20081004105854.2DA521B8001@releng2.fedora.phx.redhat.com>
Message-ID: <loom.20081004T183230-110@post.gmane.org>

Rawhide Report <rawhide <at> fedoraproject.org> writes:
> Removed package akode

Hmmm, I don't remember this having been discussed in a KDE SIG meeting. Are we 
sure this is not used/needed by anything anymore?

        Kevin Kofler



From rdieter at math.unl.edu  Sat Oct  4 19:07:09 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sat, 04 Oct 2008 14:07:09 -0500
Subject: rawhide report: 20081004 changes
References: <20081004105854.2DA521B8001@releng2.fedora.phx.redhat.com>
	<loom.20081004T183230-110@post.gmane.org>
Message-ID: <gc8esj$84i$1@ger.gmane.org>

Kevin Kofler wrote:

> Rawhide Report <rawhide <at> fedoraproject.org> writes:
>> Removed package akode
> 
> Hmmm, I don't remember this having been discussed in a KDE SIG meeting.

My apologies, I "just did it".

> Are we sure this is not used/needed by anything anymore?

I'm sure (according to repoquery) :)  Afaik, It was only ever used in kdemultimedia v3 

-- Rex




From paul at all-the-johnsons.co.uk  Sat Oct  4 22:41:25 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sat, 04 Oct 2008 23:41:25 +0100
Subject: Oddball packaging question (Tao framework)
Message-ID: <1223160085.6325.40.camel@PB3.Linux>

Hi,

The Tao framework is a C# framework which has bindings for most popular
libraries (such as OpenGL, OpenAl, SDL). I've build glfw and will be
submitting it for review soonish. However, I have a question about
packaging Tao.

Currently, it will build Tao.FFmpeg - a binder for the ffmpeg library
which is not part of Fedora (currently). The code will build without
ffmpeg being present, but the other libraries require the binding.

Can Tao.ffmpeg be allowed in as it doesn't need ffmpeg to be present
when building or in use?

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081004/1055c970/attachment.sig>

From lokthare at gmail.com  Sat Oct  4 23:10:06 2008
From: lokthare at gmail.com (=?ISO-8859-1?Q?Jean-Fran=E7ois?= Martin)
Date: Sun, 05 Oct 2008 01:10:06 +0200
Subject: trash-cli : Looking for a reviewer
Message-ID: <1223161806.9727.8.camel@abel>

Hi,

I m looking for a reviewer for trash-cli
(https://bugzilla.redhat.com/show_bug.cgi?id=448122).

Patrice Dumas had already done a partial review but don't want to accept
the package because he think that executables are too generic (trash,
empty-trash, list-trash, restore-trash).

Does any reviewer would accept this package with this scripts or should
i try persuade upstream to change them?
-- 
Jean-Fran?ois Martin
https://fedoraproject.org/wiki/User:Lokthare
https://lokthare.wordpress.com/
GPG: 3876DB6B
-------------- 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/20081005/2556fba5/attachment.sig>

From pertusus at free.fr  Sat Oct  4 23:36:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 5 Oct 2008 01:36:20 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <1223161806.9727.8.camel@abel>
References: <1223161806.9727.8.camel@abel>
Message-ID: <20081004233620.GB2670@free.fr>

On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
> 
> Patrice Dumas had already done a partial review but don't want to accept
> the package because he think that executables are too generic (trash,
> empty-trash, list-trash, restore-trash).

There is only trash that I find too generic...

--
Pat



From lokthare at gmail.com  Sun Oct  5 01:16:42 2008
From: lokthare at gmail.com (=?ISO-8859-1?Q?Jean-Fran=E7ois?= Martin)
Date: Sun, 05 Oct 2008 03:16:42 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081004233620.GB2670@free.fr>
References: <1223161806.9727.8.camel@abel>  <20081004233620.GB2670@free.fr>
Message-ID: <1223169402.10547.3.camel@abel>

Le dimanche 05 octobre 2008 ? 01:36 +0200, Patrice Dumas a ?crit :
> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
> > 
> > Patrice Dumas had already done a partial review but don't want to accept
> > the package because he think that executables are too generic (trash,
> > empty-trash, list-trash, restore-trash).
> 
> There is only trash that I find too generic...

If this command is really a problem can't we rename it "to-trash" for
example and add a file in doc, README.fedora that tell that for
packaging policy, we decide to change this command?



From sundaram at fedoraproject.org  Sun Oct  5 02:22:58 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 05 Oct 2008 07:52:58 +0530
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <1223169402.10547.3.camel@abel>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<1223169402.10547.3.camel@abel>
Message-ID: <48E82502.6020601@fedoraproject.org>

Jean-Fran?ois Martin wrote:
> Le dimanche 05 octobre 2008 ? 01:36 +0200, Patrice Dumas a ?crit :
>> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
>>> Patrice Dumas had already done a partial review but don't want to accept
>>> the package because he think that executables are too generic (trash,
>>> empty-trash, list-trash, restore-trash).
>> There is only trash that I find too generic...
> 
> If this command is really a problem can't we rename it "to-trash" for
> example and add a file in doc, README.fedora that tell that for
> packaging policy, we decide to change this command?

If you are going to rename, I would recommend posting to

http://lists.freedesktop.org/mailman/listinfo/distributions

Also consult

http://distributions.freedesktop.org/wiki/

Rahul



From jkeating at j2solutions.net  Sun Oct  5 06:09:14 2008
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 4 Oct 2008 23:09:14 -0700
Subject: procedure for renaming a package
In-Reply-To: <20081004172303.GB31243@free.fr>
References: <20081004172303.GB31243@free.fr>
Message-ID: <9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>

On Sat, Oct 4, 2008 at 10:23 AM, Patrice Dumas <pertusus at free.fr> wrote:

> Hello,
>
> I'd like to rename tetex-tex4ht to tex-tex4ht together with
> texlivisation. However I cannot find in the wiki the procedure that can
> be used to rename a package without changing anything else. There are a
> lot of information somehow related but nothing really appropriate -- or
> I didn't found it.
>
> More precisely, it doesn't seems to be on
> http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
> There are elements on
> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife
> but it isn't really appropriate (in my opinion appropriate informations
> should go here).
> I found nothing relevant in
> http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo
> http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb
> http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq
>
> Did I missed something? If not, what is the procedure?
>  <https://www.redhat.com/mailman/listinfo/fedora-devel-list>


Renaming a package is just bringing in the new package, getting it reviewed,
particularly for correct Provides/Obsoletes, and then requesting that the
old named package be removed.

--
Jes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081004/7dee8245/attachment.htm>

From tim.lauridsen at googlemail.com  Sun Oct  5 08:06:31 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sun, 05 Oct 2008 10:06:31 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <faa16b610810040834l474e69dfv59cadb2fe6adcac1@mail.gmail.com>
References: <48E48E04.1080906@students.iiit.ac.in>	<e1760170810020207h6de16f73p5895a5958f960e4a@mail.gmail.com>	<48E66CF4.3010209@redhat.com>	<1223060873.19348.17.camel@aglarond.local>	<faa16b610810031223t7d67801ag9cb2a68685b9a306@mail.gmail.com>	<1223066122.9470.68.camel@code.and.org>	<faa16b610810031342r6aaa77efw8d320006a8d1b1ca@mail.gmail.com>	<1223067220.9470.76.camel@code.and.org>	<faa16b610810031402q26a06ce6i8f56ffda70480e67@mail.gmail.com>	<48E7071B.5050507@googlemail.com>
	<faa16b610810040834l474e69dfv59cadb2fe6adcac1@mail.gmail.com>
Message-ID: <48E87587.9070603@googlemail.com>

Colin Walters wrote:
> 2008/10/4 Tim Lauridsen <tim.lauridsen at googlemail.com>:
>   
>> Hmmm.
>> 1.  yum-cli -> yum-api -> pk-con -> pk -> DBUS -> pk-backend -> yum-backend
>> -> yum-api -> install the package
>>
>> compare to
>>
>> 2. yum-cli -> yum-api -> install the package
>>     
>
> You could also use the python dbus bindings directly, or python
> bindings for libpk.
>
>   
>> here is kind og chicken and egg problem here.
>>     
>
> There's no chicken-egg - the patch would look like this:
>
> if 'DBUS_SESSION_BUS_ADDRESS' in os.environ:
>   if cmd == 'install':
>    execv(['pkcon', 'install', sys.argv[1:]])
>   elif cmd == 'search':
>    execv(['pkcon', 'search', 'name', sys.argv[1:])
>   # ..and maybe a total of 3-4 more commands.  Personally, I only use those two.
>
>   
>> take this user case.
>>
>> ssh to some server
>> yum install foo
>> how would that work.
>>     
>
> With a change like the above, it would be unaffected, at least for now.
>
>   
>> Dont forget that PackageKit is a highlevel abstraction to the low level
>> package management system, making the low level system use the highlevel
>> abstraction of it self, is kind of crazy. IMHO.
>>     
>
> The (first) lower level system is yum-api, yum-cli and pkcon are
> really at the same level. It would make sense long term to having them
> be more merged.
>
>   
Another problem is that yum install and pkcon dont have the same features.
yum install foo\* bar\* --enablerepo=rawhide --disableplugin=forbar 
--exclude=kernel\*

how do you what to do that in pkcon ?

It is like letting 'OpenOffice' call 'vi'.

pkcon is not a full blown package manager cli, it is a cli tool to do 
call the PK api, it need a lot of extra voodo magic to a full blown cli 
and i to think this is the idea of pkcon.

if you what to use 'pkcon install foo' then type it, and if you want to 
use 'yum install foo' then type that, like you would type 'vi' to use 
'vi' and not 'openoffice'.

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

From Juha.Tuomala at iki.fi  Sun Oct  5 09:19:31 2008
From: Juha.Tuomala at iki.fi (Juha Tuomala)
Date: Sun, 5 Oct 2008 12:19:31 +0300
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081004233620.GB2670@free.fr>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
Message-ID: <200810051219.31882.Juha.Tuomala@iki.fi>



On Sunday 05 October 2008 02:36:20 Patrice Dumas wrote:
> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
> > the package because he think that executables are too generic (trash,

> There is only trash that I find too generic...

speaking of too generic... how about:

% rpm -qf `which testparm`
samba-common-3.2.3-0.20.fc9.x86_64


-- 
Varo hattup?isi? autoilijoita.



From mschwendt at gmail.com  Sun Oct  5 10:00:44 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 5 Oct 2008 12:00:44 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <200810051219.31882.Juha.Tuomala@iki.fi>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>
Message-ID: <20081005120044.c64a2758.mschwendt@gmail.com>

On Sun, 5 Oct 2008 12:19:31 +0300, Juha Tuomala wrote:

> 
> 
> On Sunday 05 October 2008 02:36:20 Patrice Dumas wrote:
> > On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
> > > the package because he think that executables are too generic (trash,
> 
> > There is only trash that I find too generic...
> 
> speaking of too generic... how about:
> 
> % rpm -qf `which testparm`
> samba-common-3.2.3-0.20.fc9.x86_64

Without a doubt, there are examples of poor naming of files. You've found
one. It would better be called "samba-testparm". The samba-common package
contains more such poorly named files: /usr/bin/net, /usr/bin/profiles
samba-client contains: /usr/bin/rpcclient

It's no justification for letting more such files into the distribution,
however. The more packages like that, the higher the risk of implicit
conflicts between existing packages or packages to be added in the future.



From fedora at leemhuis.info  Sun Oct  5 10:15:32 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 05 Oct 2008 12:15:32 +0200
Subject: procedure for renaming a package
In-Reply-To: <9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
Message-ID: <48E893C4.9080300@leemhuis.info>

On 05.10.2008 08:09, Jesse Keating wrote:
> On Sat, Oct 4, 2008 at 10:23 AM, Patrice Dumas <pertusus at free.fr 
> <mailto:pertusus at free.fr>> wrote:
>     I'd like to rename tetex-tex4ht to tex-tex4ht together with
>     texlivisation. However I cannot find in the wiki the procedure that can
>     be used to rename a package without changing anything else. There are a
>     lot of information somehow related but nothing really appropriate -- or
>     I didn't found it.
> 
>     More precisely, it doesn't seems to be on
>     http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
>     There are elements on
>     http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife
>     but it isn't really appropriate (in my opinion appropriate informations
>     should go here).
>     I found nothing relevant in
>     http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo
>     http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb
>     http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq
> 
>     Did I missed something? If not, what is the procedure?
>     <https://www.redhat.com/mailman/listinfo/fedora-devel-list>

Google found this for me:
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061207

Quoting:
"""
>   Free Discussion
> 
>     * Renaming packages
>     * When a package is renamed, the package owner is allowed to import the 
> 
> renamed package as a new module, mark the old module as a dead.package and request branches. Referring to the old package and the fact that this is a rename helps people know what's going on in regards to the branches.
> 
>     * Part of this policy is listed here: 
> 
> http://www.fedoraproject.org/wiki/Extras/PackageEndOfLife and we can link to that as a reference.
> 
>     * awjb will document this. 
"""

But:

> Renaming a package is just bringing in the new package, getting it 
> reviewed, particularly for correct Provides/Obsoletes, and then 
> requesting that the old named package be removed.

That's how i remember it as well; the FESCo decision above was IIRC 
changed to "review renamed package" later. But seems neither of the two 
decisions were properly documented in the wiki afaics :-/

Cu
knurd



From alexl at users.sourceforge.net  Sun Oct  5 10:41:33 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sun, 05 Oct 2008 03:41:33 -0700
Subject: rawhide report: 20081004 changes
In-Reply-To: <20081004105854.2DA521B8001@releng2.fedora.phx.redhat.com>
	(Rawhide Report's message of "Sat\,
	4 Oct 2008 10\:58\:54 +0000 \(UTC\)")
References: <20081004105854.2DA521B8001@releng2.fedora.phx.redhat.com>
Message-ID: <wqiqs7wcgy.fsf@allele2.eebweb.arizona.edu>

[...]

Trying to do a quick audit/triage of the remaining broken deps (some
of which have lingered for >2 months!  (I will also repeat my request
to move the "broken deps" section to the top of the rawhide report so
that it gets more regular attention from all developers).

Alex

> Broken deps for i386
> ----------------------------------------------------------
>	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2

 Failed a rebuild:
 
 https://koji.fedoraproject.org/koji/taskinfo?taskID=820346
 
 Opened a bug: http://bugzilla.redhat.com/465661
 
 Looks like official 1.6.0 has been released as well...

>	beagle-evolution-0.3.8-6.fc10.i386 requires mono(evolution-sharp) = 0:3.0.0.0

 Just recently rebuilt.

>	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1

 This appears to be orphaned in CVS (dead.package) but it hasn't been
 properly blocked by rel-eng.  Owner according to:
 
 https://admin.fedoraproject.org/pkgdb/packages/name/gtkmozembedmm
 
 is hguemar.  Was this intentional?  Is gtkmozembedmm supposed to be
 removed from rawhide?  Has it been superceded by other packages?
 Can't find any bug about this.

>	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
>	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2

 Last attempted rebuild failed:

 https://koji.fedoraproject.org/koji/buildinfo?buildID=64052

 Appears to be a patch on: http://bugzilla.redhat.com/465249 which may
 fix it, but I can't apply it because of the #@1!* ACLs. Owner: please
 consider removing ACLs.

>	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
>	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
>	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)

 Recently rebuilt correctly, but may provides some bogus provides?
 Opened bug: http://bugzilla.redhat.com/465663

>	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
>	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
>	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
>	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
>	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
>	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
>	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0

 Fails to rebuild:

 https://koji.fedoraproject.org/koji/buildinfo?buildID=62714

 Also brought up in earlier thread on f-d-l:

 http://www.redhat.com/archives/fedora-devel-list/2008-October/msg00020.html

 but no response.  There is an open FTBFS bug: http://bugzilla.redhat.com/465096

>	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
>	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
>	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
>	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so

 This won't build until it is ported to use RPM 4.6.  Is this
 underway?  Looking at upstream
 http://rubyforge.org/projects/ruby-rpm/ there hasn't been a new
 release since May 2007, so I'm guessing the project may be dead.
 Could the maintainer have a look at this, or otherwise block it from
 rawhide if it can't be ported.  There is an existing FTBFS bug:
 http://bugzilla.redhat.com/465103



From rawhide at fedoraproject.org  Sun Oct  5 12:13:24 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun,  5 Oct 2008 12:13:24 +0000 (UTC)
Subject: rawhide report: 20081005 changes
Message-ID: <20081005121324.90CB61F825C@releng2.fedora.phx.redhat.com>

Updated Packages:

beagle-0.3.8-7.fc10
-------------------
* Sat Oct  4 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-7
- Update epiphany patch


bluez-4.11-1.fc10
-----------------
* Sat Oct  4 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.11-1
- Update to 4.11


bluez-gnome-1.8-1.fc10
----------------------
* Sat Oct  4 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-1
- Update to 1.8 and update obex-data-server patch


cairo-dock-1.6.3-0.1.svn1337_trunk.fc10
---------------------------------------
* Sun Oct  5 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1337


claws-mail-3.6.0-1.fc10
-----------------------
* Sat Oct  4 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.6.0-1
- version upgrade
- transition smime from claws-mail-plugins to claws-mail package


claws-mail-plugins-3.6.0-1.fc10
-------------------------------
* Sat Oct  4 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.6.0-1
- version upgrade
- transition smime from plugins to main package

* Mon Sep  8 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.5.0-2
- rebuild

* Mon Jun 30 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.5.0-1
- version upgrade
- upstream dropped pdf plugin
- new archive plugin


control-center-2.24.0.1-4.fc10
------------------------------

cppunit-1.12.1-1.fc10
---------------------
* Thu Sep 18 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 1.12.1-1
- Update to 1.12.1


eel2-2.24.0-4.fc10
------------------
* Sat Oct  4 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-4
- Fix problem in last patch that was preventing crossfades
  in appearance capplet


fwknop-1.9.8-1.fc10
-------------------
* Sat Oct  4 18:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 1.9.8-1
- Update to fwknop-1.9.8
- Add missing Requires:
- Use the "nodeps" tarball


gimmix-0.5.1-1.fc10
-------------------
* Sat Oct  4 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.5.1
- version upgrade


guitone-0.9-1.fc10
------------------
* Sat Oct  4 18:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 0.9-1
- Update to version 0.9.


hardinfo-0.4.2.3-8.fc10
-----------------------
* Sat Oct  4 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.4.2.3-8
- Apply the patch

* Sat Oct  4 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.4.2.3-7
- Fix build RH #465047


kcoloredit-4.1.2-1.fc10
-----------------------
* Sat Oct  4 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-1
- 4.1.2


kernel-2.6.27-0.391.rc8.git7.fc10
---------------------------------
* Sat Oct  4 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
- Update to the latest git (2 patches.)

* Sat Oct  4 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
- Support building -stable RC kernels.

* Sat Oct  4 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
- Make applesmc driver stop spewing messages. (#463756)

* Sat Oct  4 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
- 2.6.27-rc8-git7

* Sat Oct  4 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
- 2.6.27-rc8-git6

* Fri Oct  3 18:00:00 2008 Kyle McMartin <kyle at redhat.com>
- 2.6.27-rc8-git5

* Fri Oct  3 18:00:00 2008 David Woodhouse <David.Woodhouse at intel.com>
- Include arch/$ARCH/include/ directories in kernel-devel (#465486)
- Include arch/powerpc/lib/crtsavres.[So] too (#464613)

* Fri Oct  3 18:00:00 2008 Dave Jones <davej at redhat.com>
- Demodularise some of the devicemapper modules that always get loaded.

* Fri Oct  3 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
- specfile: don't use the latest stable update for the vanilla directory.


kgrab-0.1.1-10.fc10
-------------------
* Sat Oct  4 18:00:00 2008 Than Ngo <than at redhat.com> 0.1.1-10
- 4.1.2

* Fri Aug 29 18:00:00 2008 Than Ngo <than at redhat.com> 0.1.1-9
- 4.1.1


koffice-langpack-1.6.3-2.fc10
-----------------------------
* Sun Dec  9 17:00:00 2007 Rex Dieter <rdieter[AT]fedoraproject.org>
1.6.3-2
- BR: kdelibs3-devel
- License: GPLv2+


konq-plugins-4.1.2-1.fc10
-------------------------
* Sat Oct  4 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-1
- 4.1.2


libAfterImage-1.18-1.fc10
-------------------------
* Sat Oct  4 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.18-1
- version upgrade


lock-keys-applet-1.0-15.fc10
----------------------------
* Sat Oct  4 18:00:00 2008 Jorge Torres <jtorresh at gmail.com> - 1.0-15
- Remove use of deprecated GTK+ functions
- Rebuild to fix FTBFS (bug #464994)


openoffice.org-3.0.0-9.2.fc10
-----------------------------
* Sat Oct  4 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.2
- Resolves: rhbz#465427 wrong order of seds
- Resolves: rhbz#465515 use --force to avoid any potential problems where
  upgrading a hand-added extension


pam_mysql-0.7-0.6.rc1.fc10
--------------------------
* Fri Oct  3 18:00:00 2008 Paul P. Komkoff Jr <i at stingr.net> - 0.7-0.6.rc1
- Fix bz#465186 (credits go to: Philippe Troin)


system-switch-displaymanager-1.2-2.fc10
---------------------------------------
* Sat Oct  4 18:00:00 2008 Than Ngo <than at redhat.com> 1.2-2
- add %dist


tetex-tex4ht-1.0.2008_09_16_1413-1.fc10
---------------------------------------
* Sat Oct  4 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 1.0.2008_09_16_1413-1
- update to 2008_09_16_1413
- adapt to texlive


xastir-1.9.4-3.fc10
-------------------
* Sat Oct  4 18:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.9.4-3
- fix for RH #435762


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 25
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	gnuradio-3.1.2-2.fc9.i386 requires libcppunit-1.12.so.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	syncevolution-0.7-3.fc10.i386 requires libcppunit-1.12.so.0
	tomcat6-jsp-2.1-api-6.0.18-1.1.fc10.noarch requires tomcat6-servlet-2.5-api = 0:6.0.18-1.1.fc10
	tomcat6-lib-6.0.18-1.1.fc10.noarch requires tomcat6-servlet-2.5-api = 0:6.0.18-1.1.fc10



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	gnuradio-3.1.2-2.fc9.i386 requires libcppunit-1.12.so.0
	gnuradio-3.1.2-2.fc9.x86_64 requires libcppunit-1.12.so.0()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	syncevolution-0.7-3.fc10.x86_64 requires libcppunit-1.12.so.0()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	gnuradio-3.1.2-2.fc9.ppc requires libcppunit-1.12.so.0
	gnuradio-3.1.2-2.fc9.ppc64 requires libcppunit-1.12.so.0()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so
	syncevolution-0.7-3.fc10.ppc requires libcppunit-1.12.so.0



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	gnuradio-3.1.2-2.fc9.ppc64 requires libcppunit-1.12.so.0()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Actor)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Film)
	perl-DBIx-Class-0.08010-7.fc10.noarch requires perl(Director)
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	syncevolution-0.7-3.fc10.ppc64 requires libcppunit-1.12.so.0()(64bit)





From dtimms at iinet.net.au  Sun Oct  5 13:28:23 2008
From: dtimms at iinet.net.au (David Timms)
Date: Mon, 06 Oct 2008 00:28:23 +1100
Subject: rawhide report: 20081004 changes
In-Reply-To: <wqiqs7wcgy.fsf@allele2.eebweb.arizona.edu>
References: <20081004105854.2DA521B8001@releng2.fedora.phx.redhat.com>
	<wqiqs7wcgy.fsf@allele2.eebweb.arizona.edu>
Message-ID: <48E8C0F7.9010001@iinet.net.au>

Alex Lancaster wrote:
> [...]
> 
> Trying to do a quick audit/triage of the remaining broken deps (some
> of which have lingered for >2 months!  (I will also repeat my request
> to move the "broken deps" section to the top of the rawhide report so
> that it gets more regular attention from all developers).
I think it would simplify the report if each package was mentioned just 
once, with a leader or trailer stating the arch(s) that it failed on. 
This assists to quickly determine if the issue is likely to be arch 
specific, or cross platform. What do you think ?

DaveT.



From pertusus at free.fr  Sun Oct  5 14:06:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 5 Oct 2008 16:06:18 +0200
Subject: procedure for renaming a package
In-Reply-To: <9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
Message-ID: <20081005140618.GA2755@free.fr>

On Sat, Oct 04, 2008 at 11:09:14PM -0700, Jesse Keating wrote:
> 
> Renaming a package is just bringing in the new package, getting it reviewed,
> particularly for correct Provides/Obsoletes, and then requesting that the
> old named package be removed.

A review for the sake of a rename seems a complete waste of time to me.
I won't rename it, then, the benefits are not worth the costs.

--
Pat



From vonbrand at inf.utfsm.cl  Sun Oct  5 15:49:02 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 05 Oct 2008 11:49:02 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48E635EA.1010908@students.iiit.ac.in>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>
	<48E635EA.1010908@students.iiit.ac.in>
Message-ID: <200810051549.m95Fn2ZF007826@laptop14.inf.utfsm.cl>

Kulbir Saini <kulbirsaini at students.iiit.ac.in> wrote:

[...]

>   Can we make this a part of the packaging policy that if your package
> sets/gets or do anything with the proxy settings, then it should
> always set/unset/access the env variables like http_proxy, ftp_proxy,
> gopher_proxy so that we can achieve some uniform system?

No use, as the variables get read only when the program starts up.



From vonbrand at inf.utfsm.cl  Sun Oct  5 15:53:01 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 05 Oct 2008 11:53:01 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <gc58g8$ho8$1@ger.gmane.org>
References: <48E48E04.1080906@students.iiit.ac.in> <gc58g8$ho8$1@ger.gmane.org>
Message-ID: <200810051553.m95Fr1fe007853@laptop14.inf.utfsm.cl>

Simon Andrews <simon.andrews at bbsrc.ac.uk> wrote:
> Kulbir Saini wrote:
> > Hi list,
> >    Whenever I try a new version of Fedora, the first problem I face
> > is setting the proxy. It seems for almost every application, I have
> > to specify proxy at a different place. We have this "System ->
> > Preferences -> Internet and Network -> Network Proxy" app to specify
> > proxy settings. But I wonder if there is some application which
> > obeys these settings.
> 
> This has come up before and it's a messy subject.  I can throw into
> the debate the problem of NetworkManager and proxies - since I have to
> use a proxy at work, but not at home, and unsetting all the various
> places you can put a proxy is a royal pain.
> 
> The big problems are:
> 
> 1) There is no common place to set a proxy variable.  Some programs
> (eg wget) look for the http_proxy environment variable.  Many Gnome
> programs look for the gconf setting, some programs (firefox) have
> their own internal setting.
>
> 2) Many programs won't update proxy settings on the fly so there's no
> way to transparently change a proxy without closing down and reopening
> the program.

Nodz!

> One suggestion to get around this would be to run a proxy on localhost
> and make all proxy aware applications use that in their default
> install. This wouldn't actually have to do any caching - just act as a
> common point at which behaviour could actually be changed without the
> cooperation of the programs.

Icky.

> We could then put hooks into NetworkManager to change the behaviour of
> the local proxy so that it either sends its requests directly to the
> internet, or routes them via a secondary proxy.
> 
> This all feels a bit icky to me - but I can't think of a nicer way of
> doing this which doesn't require the cooperation of the authors of
> every proxy-aware application.

This is papering over the (very real) bugs in the applications (Yes, I do
consider not getting and resetting proxy and other network settings
transparently a bug), at a very real cost for all users.
-- 
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 2340000       Fax:  +56 32 2797513



From behdad at behdad.org  Sun Oct  5 17:03:47 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Sun, 05 Oct 2008 13:03:47 -0400
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <1223169402.10547.3.camel@abel>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<1223169402.10547.3.camel@abel>
Message-ID: <48E8F373.20101@behdad.org>

Jean-Fran?ois Martin wrote:
> Le dimanche 05 octobre 2008 ? 01:36 +0200, Patrice Dumas a ?crit :
>> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
>>> Patrice Dumas had already done a partial review but don't want to accept
>>> the package because he think that executables are too generic (trash,
>>> empty-trash, list-trash, restore-trash).
>> There is only trash that I find too generic...
> 
> If this command is really a problem can't we rename it "to-trash" for
> example and add a file in doc, README.fedora that tell that for
> packaging policy, we decide to change this command?

If renaming, please consider renaming them all to trash-* from the current
*-trash.

behdad



From schristley at mac.com  Sun Oct  5 17:06:14 2008
From: schristley at mac.com (Scott Christley)
Date: Sun, 05 Oct 2008 10:06:14 -0700
Subject: GNUstep
In-Reply-To: <E4C9AE8F-FDC7-48D1-A5B1-FA0856B4B2AB@mac.com>
References: <E4C9AE8F-FDC7-48D1-A5B1-FA0856B4B2AB@mac.com>
Message-ID: <CD1B1D1D-048C-401D-B618-90360B918E03@mac.com>


The conflict between libFoundation and gnustep-base is akin to having  
(say) two libc libraries on the same system.  They provide the same  
functionality and conflict in filename space, so they cannot both be  
supported on the same system without jumping through some hoops.   
gnustep-make was originally designed through library-combo to support  
different foundation libraries, primarily as a concession to the  
libFoundation guys, but this capability was never truly utilized by  
developers.  Today these foundation libraries are not truly  
interchangeable, the gnustep-gui and other libraries are coupled  
tightly with gnustep-base and do not work with libFoundation or  
Apple's.  Therefore, applications that use libFoundation are not going  
to use any of the GNUstep functionality above the foundation library.

So my suggestion is to handle libFoundation as though it was a  
separate library outside of the GNUstep environment, to prevent  
conflict with the GNUstep headers, have it be installed in its own  
subdirectory.

/usr/include/libFoundation

and applications which require libFoundation just need to insert an  
include flag during compilation so that its header are found in front  
of GNUstep's.  These applications like opengroupware are free to use  
gnustep-make unchanged for their build process, they just need to add  
an additional line in their makefile.

cheers
Scott



From email.ahmedkamal at googlemail.com  Sun Oct  5 17:48:46 2008
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Sun, 5 Oct 2008 19:48:46 +0200
Subject: preUpgrade F9->F10 on LVM snapshot
Message-ID: <3da3b5b40810051048w28c6b435va39696d9f3bca35c@mail.gmail.com>

Hi everyone,I wanna help by testing F10 on my laptop. I am currently running
F9 perfectly fine. Here's what I want to do:
- Take a lvm snapshot of my F9 (if that won't work, make a new LV and dd
over the file system)
- boot that .. preUpgrade that into F10 beta (or rawhide). Does preUpgrade
see F10 beta by itself ?
- Post back the results

Since that is not the "usual" upgrade path to say the least, I just want to
know if you guys see any caveats or hoops ? Is that LVM remerging work now
in F10, i.e. if I work with a snapshot and it upgrades fine, can I merge it
back into the "real" LV?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081005/8080476d/attachment.htm>

From jkeating at redhat.com  Sun Oct  5 17:49:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 05 Oct 2008 10:49:22 -0700
Subject: procedure for renaming a package
In-Reply-To: <20081005140618.GA2755@free.fr>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081005140618.GA2755@free.fr>
Message-ID: <1223228962.9987.13.camel@luminos.localdomain>

On Sun, 2008-10-05 at 16:06 +0200, Patrice Dumas wrote:
> A review for the sake of a rename seems a complete waste of time to me.
> I won't rename it, then, the benefits are not worth the costs.

The review gives us an opportunity to ensure that the package hasn't
drifted too far from it's original state when it was first brought in,
and it gets a second pair of eyes on the proper setup of
Provides/Obsoletes, which can go wrong and often does.  Since we have no
other formal re-review system, renames offer a little bit toward that.

Given the vast number of improper Provides/Obsoletes I've ran across, I
feel strongly that I'd like a second pair of eyes on any such additions.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081005/6a81b169/attachment.sig>

From jkeating at redhat.com  Sun Oct  5 17:50:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 05 Oct 2008 10:50:41 -0700
Subject: rawhide report: 20081004 changes
In-Reply-To: <48E8C0F7.9010001@iinet.net.au>
References: <20081004105854.2DA521B8001@releng2.fedora.phx.redhat.com>
	<wqiqs7wcgy.fsf@allele2.eebweb.arizona.edu>
	<48E8C0F7.9010001@iinet.net.au>
Message-ID: <1223229041.9987.14.camel@luminos.localdomain>

On Mon, 2008-10-06 at 00:28 +1100, David Timms wrote:
> I think it would simplify the report if each package was mentioned just 
> once, with a leader or trailer stating the arch(s) that it failed on. 
> This assists to quickly determine if the issue is likely to be arch 
> specific, or cross platform. What do you think ?
> 

I think patches will be reviewed (:

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081005/4c201899/attachment.sig>

From mmcgrath at redhat.com  Sun Oct  5 18:14:13 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sun, 5 Oct 2008 13:14:13 -0500 (CDT)
Subject: Outage Notification - 2008-10-05 07:00 UTC (fwd)
Message-ID: <alpine.LFD.1.10.0810051313550.570@laptop.mmcgrath.net>

FYI.  The actual service interuptions should be very short.

---------- Forwarded message ----------
Date: Sun, 5 Oct 2008 11:45:33 -0500 (CDT)
From: Mike McGrath <mmcgrath at redhat.com>
Reply-To: Fedora Infrastructure <fedora-infrastructure-list at redhat.com>
To: Fedora Infrastructure <fedora-infrastructure-list at redhat.com>
Subject: Re: Outage Notification - 2008-10-05 07:00 UTC

On Fri, 3 Oct 2008, Mike McGrath wrote:

> There will be an outage starting at 2008-10-05 07:00 UTC, which will last
> approximately 2 hours.
>
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
>
> date -d '2008-10-05 07:00 UTC'
>

Sorry everyone, I forgot to convert my PM time to 24 hour time.  I'm still
going to do this outage but it will be at:

date -d '2008-10-05 19:00 UTC'

        -Mike

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list



From ville.skytta at iki.fi  Sun Oct  5 18:54:14 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Sun, 5 Oct 2008 21:54:14 +0300
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <200810012019.53814.ville.skytta@iki.fi>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<20081001035116.GA21890@jadzia.bu.edu>
	<200810012019.53814.ville.skytta@iki.fi>
Message-ID: <200810052154.15443.ville.skytta@iki.fi>

On Wednesday 01 October 2008, Ville Skytt? wrote:
> On Wednesday 01 October 2008, Matthew Miller wrote:
> > On Tue, Sep 30, 2008 at 08:52:10PM -0600, Stephen John Smoogen wrote:
> > > I think the chance for putting it back is still there.. if someone is
> > > willing to do the work on the hard but correct way? I think it was
> > > crickets the last couple of times when volunteers were asked for that.
> >
> > Sure, I'm willing to work on it.
>
> Count me in, too.

So... what can we do in order to make this happen?  Now that we have 
volunteers, I suppose the best way forward would be to revert the change for 
F-10 and start working on "the correct way" so that the default PATH wouldn't 
need to be changed again in F-11.



From adam at spicenitz.org  Sun Oct  5 18:56:03 2008
From: adam at spicenitz.org (Adam Goode)
Date: Sun, 05 Oct 2008 14:56:03 -0400
Subject: looking for co-maintainers
Message-ID: <48E90DC3.5010709@spicenitz.org>

Hi,

My life is about to get very busy (twins on the way), so I want to make 
sure I at least have co-maintainers for all (or most) of my packages. 
Anyone interested?


escape -- puzzle game

fvwm -- window manager

gkrellm-weather -- plugin for gkrellm

htmldoc -- converts html into ps or pdf

minirpc -- a new RPC library

mlton -- optimizing compiler for Standard ML

vips -- image library, prereq for nip2

nip2 -- non-destructive lazy image editor



Thanks,

Adam

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

From pertusus at free.fr  Sun Oct  5 19:36:48 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 5 Oct 2008 21:36:48 +0200
Subject: procedure for renaming a package
In-Reply-To: <1223228962.9987.13.camel@luminos.localdomain>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081005140618.GA2755@free.fr>
	<1223228962.9987.13.camel@luminos.localdomain>
Message-ID: <20081005193648.GA3361@free.fr>

On Sun, Oct 05, 2008 at 10:49:22AM -0700, Jesse Keating wrote:
> On Sun, 2008-10-05 at 16:06 +0200, Patrice Dumas wrote:
> > A review for the sake of a rename seems a complete waste of time to me.
> > I won't rename it, then, the benefits are not worth the costs.
> 
> The review gives us an opportunity to ensure that the package hasn't
> drifted too far from it's original state when it was first brought in,
> and it gets a second pair of eyes on the proper setup of
> Provides/Obsoletes, which can go wrong and often does.  Since we have no
> other formal re-review system, renames offer a little bit toward that.

I don't need a rereview of this package, currently. It is a (rather)
unusual package, and I'd prefer if reviewer interested in TeX/LaTeX used
their time differently, we seem to be very few in fedora, since reviewing 
it carefully is certainly very time-consuming.

> Given the vast number of improper Provides/Obsoletes I've ran across, I
> feel strongly that I'd like a second pair of eyes on any such additions.

Sure, but a re-review is much more than that.

--
Pat



From pertusus at free.fr  Sun Oct  5 19:39:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 5 Oct 2008 21:39:11 +0200
Subject: looking for co-maintainers
In-Reply-To: <48E90DC3.5010709@spicenitz.org>
References: <48E90DC3.5010709@spicenitz.org>
Message-ID: <20081005193911.GB3361@free.fr>

On Sun, Oct 05, 2008 at 02:56:03PM -0400, Adam Goode wrote:
> Hi,
>
> fvwm -- window manager
> htmldoc -- converts html into ps or pdf

I will apply for co-maintainership for these 2, but don't count on me, I
already am maintainer or co-mainaintaier of too much packages to be able
to act timely on new packages.

--
Pat



From paul at all-the-johnsons.co.uk  Sun Oct  5 19:49:46 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 05 Oct 2008 20:49:46 +0100
Subject: Mono 2.0
Message-ID: <1223236186.24836.7.camel@PB3.Linux>

Hi,

I've been told from Novell that Mono rc4 (currently in rawhide) will be
released as the real 2.0 version tomorrow (Monday).

As there is no difference between RC4 and the release version, I'm not
intending to repackage them just for the sake of it as it seems an
exercise in futility to be honest.

My plan is to roll out the full mono 2.0 stack to F9 as soon as F10 is
released. This will mean that for the first time, both the current and
previous versions of Fedora will be running on the same version of mono.
What will then happen is this

Mono releases version 2.1, rawhide gets this plus any bug fixes. After a
month, this is rolled down to release and after 2 months, release - 1.
This will also apply to Monodevelop. As I don't have control over other
Mono packages (or mono-based packages), can I ask that if you do have a
mono package that you also adopt this system. Currently things in F8 and
F9 are a mess and they need a good clean up.

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081005/10096ef8/attachment.sig>

From konrad at tylerc.org  Sun Oct  5 19:54:07 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sun, 5 Oct 2008 12:54:07 -0700
Subject: Mono 2.0
In-Reply-To: <1223236186.24836.7.camel@PB3.Linux>
References: <1223236186.24836.7.camel@PB3.Linux>
Message-ID: <200810051254.07906.konrad@tylerc.org>

On Sunday 05 October 2008 12:49:46 pm Paul wrote:
> Hi,
>
> I've been told from Novell that Mono rc4 (currently in rawhide) will be
> released as the real 2.0 version tomorrow (Monday).
>
> As there is no difference between RC4 and the release version, I'm not
> intending to repackage them just for the sake of it as it seems an
> exercise in futility to be honest.

What if the release version ends up being RC5? Isn't that the point of release 
candidates?

> My plan is to roll out the full mono 2.0 stack to F9 as soon as F10 is
> released. This will mean that for the first time, both the current and
> previous versions of Fedora will be running on the same version of mono.
> What will then happen is this

Sounds good so far.

> Mono releases version 2.1, rawhide gets this plus any bug fixes. After a
> month, this is rolled down to release and after 2 months, release - 1.
> This will also apply to Monodevelop. As I don't have control over other
> Mono packages (or mono-based packages), can I ask that if you do have a
> mono package that you also adopt this system. Currently things in F8 and
> F9 are a mess and they need a good clean up.

Why wait a month between F10 and F9? I can see waiting between pushing to 
updates-testing or rawhide and then to a stable release, but this just seems 
an artificial delay in pushing the latest and greatest, as well as bugfixes.

> TTFN
>
> Paul

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From wwoods at redhat.com  Sun Oct  5 20:01:13 2008
From: wwoods at redhat.com (Will Woods)
Date: Sun, 05 Oct 2008 16:01:13 -0400
Subject: preUpgrade F9->F10 on LVM snapshot
In-Reply-To: <3da3b5b40810051048w28c6b435va39696d9f3bca35c@mail.gmail.com>
References: <3da3b5b40810051048w28c6b435va39696d9f3bca35c@mail.gmail.com>
Message-ID: <1223236873.5190.5.camel@zebes.localdomain>

On Sun, 2008-10-05 at 19:48 +0200, Ahmed Kamal wrote:
> Hi everyone,
> I wanna help by testing F10 on my laptop. I am currently running F9
> perfectly fine. Here's what I want to do:
> - Take a lvm snapshot of my F9 (if that won't work, make a new LV and
> dd over the file system)
> - boot that .. preUpgrade that into F10 beta (or rawhide). Does
> preUpgrade see F10 beta by itself ?

I don't really have any info about the LVM snapshot stuff, but
preupgrade-0.9.8-2.fc9 (in updates-testing) should have Fedora 10 Beta
in its list of (unstable) upgrade targets. If it doesn't, file a bug.

-w




From paul at all-the-johnsons.co.uk  Sun Oct  5 20:04:05 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 05 Oct 2008 21:04:05 +0100
Subject: Mono 2.0
In-Reply-To: <200810051254.07906.konrad@tylerc.org>
References: <1223236186.24836.7.camel@PB3.Linux>
	<200810051254.07906.konrad@tylerc.org>
Message-ID: <1223237045.24836.15.camel@PB3.Linux>

Hi,

> > As there is no difference between RC4 and the release version, I'm not
> > intending to repackage them just for the sake of it as it seems an
> > exercise in futility to be honest.
> 
> What if the release version ends up being RC5? Isn't that the point of release 
> candidates?

The point of release candidates is for a final try out. As RC4 ==
mono-2.0 release, the Novell engineers have obviously come to the
conclusion that it's of sufficiently high quality to make it the actual
release rather than a candidate. I can certainly repackage them and bump
the number up by .1, but the only difference is the .1 and an extra line
in the spec file

> > Mono releases version 2.1, rawhide gets this plus any bug fixes. After a
> > month, this is rolled down to release and after 2 months, release - 1.
> > This will also apply to Monodevelop. As I don't have control over other
> > Mono packages (or mono-based packages), can I ask that if you do have a
> > mono package that you also adopt this system. Currently things in F8 and
> > F9 are a mess and they need a good clean up.
> 
> Why wait a month between F10 and F9? I can see waiting between pushing to 
> updates-testing or rawhide and then to a stable release, but this just seems 
> an artificial delay in pushing the latest and greatest, as well as bugfixes.

Mono relies on a pile of other things, so I'm giving the release -1 time
to play catch up.

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081005/86d6fd1c/attachment.sig>

From forum at ru.bir.ru  Sun Oct  5 20:35:41 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 06 Oct 2008 00:35:41 +0400
Subject: looking for co-maintainers
In-Reply-To: <48E90DC3.5010709@spicenitz.org>
References: <48E90DC3.5010709@spicenitz.org>
Message-ID: <gcb8et$7b6$1@ger.gmane.org>

Adam Goode ?????:
> Hi,
> 
> My life is about to get very busy (twins on the way), so I want to make 
> sure I at least have co-maintainers for all (or most) of my packages. 
> Anyone interested?
> 
> 
> escape -- puzzle game
I add himself. I believe can be helpfully.



From mszpak at wp.pl  Sun Oct  5 21:10:32 2008
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Sun, 05 Oct 2008 23:10:32 +0200
Subject: pyxattr 0.4.0 license change
Message-ID: <gcbag9$d3u$1@ger.gmane.org>

Hello all,


pyxattr 0.4.0 has changed its license from GPLv2+ (in 0.2.2) to LGPLv2+
(in fact LGPLv2.1+). I plan to update it in rawhide this week. I don't
see any possible problems related to that, but if any please let me know.


Regards
Marcin



From andrea at andreafrancia.it  Sun Oct  5 21:34:04 2008
From: andrea at andreafrancia.it (Andrea Francia)
Date: Sun, 05 Oct 2008 23:34:04 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E8F373.20101@behdad.org>
References: <1223161806.9727.8.camel@abel>
	<20081004233620.GB2670@free.fr>	<1223169402.10547.3.camel@abel>
	<48E8F373.20101@behdad.org>
Message-ID: <48E932CC.8050607@andreafrancia.it>

Behdad Esfahbod wrote:
> Jean-Fran?ois Martin wrote:
>   
>> Le dimanche 05 octobre 2008 ? 01:36 +0200, Patrice Dumas a ?crit :
>>     
>>> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
>>>       
>>>> Patrice Dumas had already done a partial review but don't want to accept
>>>> the package because he think that executables are too generic (trash,
>>>> empty-trash, list-trash, restore-trash).
>>>>         
>>> There is only trash that I find too generic...
>>>       
>> If this command is really a problem can't we rename it "to-trash" for
>> example and add a file in doc, README.fedora that tell that for
>> packaging policy, we decide to change this command?
>>     
>
> If renaming, please consider renaming them all to trash-* from the current
> *-trash.
>   
What are the advantages of doing this?

-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html



From behdad at behdad.org  Sun Oct  5 21:38:10 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Sun, 05 Oct 2008 17:38:10 -0400
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E932CC.8050607@andreafrancia.it>
References: <1223161806.9727.8.camel@abel>	<20081004233620.GB2670@free.fr>	<1223169402.10547.3.camel@abel>	<48E8F373.20101@behdad.org>
	<48E932CC.8050607@andreafrancia.it>
Message-ID: <48E933C2.9020608@behdad.org>

Andrea Francia wrote:
> Behdad Esfahbod wrote:
>> Jean-Fran?ois Martin wrote:
>>  
>>> Le dimanche 05 octobre 2008 ? 01:36 +0200, Patrice Dumas a ?crit :
>>>    
>>>> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
>>>>      
>>>>> Patrice Dumas had already done a partial review but don't want to
>>>>> accept
>>>>> the package because he think that executables are too generic (trash,
>>>>> empty-trash, list-trash, restore-trash).
>>>>>         
>>>> There is only trash that I find too generic...
>>>>       
>>> If this command is really a problem can't we rename it "to-trash" for
>>> example and add a file in doc, README.fedora that tell that for
>>> packaging policy, we decide to change this command?
>>>     
>>
>> If renaming, please consider renaming them all to trash-* from the
>> current
>> *-trash.
>>   
> What are the advantages of doing this?

Eh, thought it's obvious.  One can type "trash" then use tab completion to see
what commands are available.  For example when I install a package, say
bittorrent, I naturally try "bittorrent<TAB><TAB>" before having to fall back
to "rpm -ql bittorrent".  It's simple namespacing too.

behdad



From denis at poolshark.org  Sun Oct  5 21:45:53 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sun, 05 Oct 2008 23:45:53 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E933C2.9020608@behdad.org>
References: <1223161806.9727.8.camel@abel>	<20081004233620.GB2670@free.fr>	<1223169402.10547.3.camel@abel>	<48E8F373.20101@behdad.org>	<48E932CC.8050607@andreafrancia.it>
	<48E933C2.9020608@behdad.org>
Message-ID: <48E93591.3030201@poolshark.org>

Behdad Esfahbod wrote:
> Eh, thought it's obvious.  One can type "trash" then use tab completion to see
> what commands are available.  For example when I install a package, say
> bittorrent, I naturally try "bittorrent<TAB><TAB>" before having to fall back
> to "rpm -ql bittorrent".  It's simple namespacing too.

Now that wouldn't help you find, say, transmission or azureus, if you 
didn't know about them beforehand. Or "agave" for colorscheme designer, 
or "ekiga" for a video-conferencing service :-)

-denis



From behdad at behdad.org  Sun Oct  5 21:51:36 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Sun, 05 Oct 2008 17:51:36 -0400
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E93591.3030201@poolshark.org>
References: <1223161806.9727.8.camel@abel>	<20081004233620.GB2670@free.fr>	<1223169402.10547.3.camel@abel>	<48E8F373.20101@behdad.org>	<48E932CC.8050607@andreafrancia.it>	<48E933C2.9020608@behdad.org>
	<48E93591.3030201@poolshark.org>
Message-ID: <48E936E8.1010108@behdad.org>

Denis Leroy wrote:
> Behdad Esfahbod wrote:
>> Eh, thought it's obvious.  One can type "trash" then use tab
>> completion to see
>> what commands are available.  For example when I install a package, say
>> bittorrent, I naturally try "bittorrent<TAB><TAB>" before having to
>> fall back
>> to "rpm -ql bittorrent".  It's simple namespacing too.
> 
> Now that wouldn't help you find, say, transmission or azureus, if you
> didn't know about them beforehand. Or "agave" for colorscheme designer,
> or "ekiga" for a video-conferencing service :-)

If you install RPM package "bittorrent" and it installs a binary named
"azureus", you really need to get a better distro...

behdad

> -denis
> 



From andrea at andreafrancia.it  Sun Oct  5 22:10:34 2008
From: andrea at andreafrancia.it (Andrea Francia)
Date: Mon, 06 Oct 2008 00:10:34 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E933C2.9020608@behdad.org>
References: <1223161806.9727.8.camel@abel>	<20081004233620.GB2670@free.fr>	<1223169402.10547.3.camel@abel>	<48E8F373.20101@behdad.org>	<48E932CC.8050607@andreafrancia.it>
	<48E933C2.9020608@behdad.org>
Message-ID: <48E93B5A.5000302@andreafrancia.it>

Behdad Esfahbod wrote:
> Andrea Francia wrote:
>   
>> Behdad Esfahbod wrote:
>>     
>>> Jean-Fran?ois Martin wrote:
>>>  
>>>       
>>>> Le dimanche 05 octobre 2008 ? 01:36 +0200, Patrice Dumas a ?crit :
>>>>    
>>>>         
>>>>> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
>>>>>      
>>>>>           
>>>>>> Patrice Dumas had already done a partial review but don't want to
>>>>>> accept
>>>>>> the package because he think that executables are too generic (trash,
>>>>>> empty-trash, list-trash, restore-trash).
>>>>>>         
>>>>>>             
>>>>> There is only trash that I find too generic...
>>>>>       
>>>>>           
>>>> If this command is really a problem can't we rename it "to-trash" for
>>>> example and add a file in doc, README.fedora that tell that for
>>>> packaging policy, we decide to change this command?
>>>>     
>>>>         
>>> If renaming, please consider renaming them all to trash-* from the
>>> current
>>> *-trash.
>>>   
>>>       
>> What are the advantages of doing this?
>>     
>
> Eh, thought it's obvious.  One can type "trash" then use tab completion to see
> what commands are available.  
So the commands names could became:
 - trashcan-put
 - trashcan-empty
 - trashcan-list
 - trashcan-restore

My English is not so good, is the 'trashcan-put' a good choice?

-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html



From icon at fedoraproject.org  Sun Oct  5 22:18:26 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Sun, 5 Oct 2008 18:18:26 -0400
Subject: Rawhide booting troubles (plymouthd)
Message-ID: <f8f6300f0810051518v8764j60816b101be66574@mail.gmail.com>

With the latest rawhide, I get:

could not start boot splash: No such device
/bin/plymouthd: symbol lookup error: /bin/plymouthd: undefined symbol:
ply_answer_new

I can still boot if I select "Fedora-Base" or another older entry from
the grub screen. In fact, there are the following entries in
grub.conf:

title Fedora (2.6.27-0.382.rc8.git4.fc10.i686)
	root (hd0,0)
	kernel /vmlinuz-2.6.27-0.382.rc8.git4.fc10.i686 ro
root=/dev/protee_vg/root_lv rhgb quiet
	initrd /initrd-2.6.27-0.382.rc8.git4.fc10.i686.img
title Fedora (2.6.27-0.352.rc7.git1.fc10.i686)
	root (hd0,0)
	kernel /vmlinuz-2.6.27-0.352.rc7.git1.fc10.i686 ro
root=UUID=5956dd1c-1eab-4487-91ca-e4c3bbc0fee6 rhgb quiet
	initrd /initrd-2.6.27-0.352.rc7.git1.fc10.i686.img
title Fedora-base (2.6.27-0.352.rc7.git1.fc10.i686)
	root (hd0,0)
	kernel /vmlinuz-2.6.27-0.352.rc7.git1.fc10.i686 ro
root=UUID=5956dd1c-1eab-4487-91ca-e4c3bbc0fee6 rhgb quiet
	initrd /initrd-2.6.27-0.352.rc7.git1.fc10.i686.img

If it helps, I installed 10-Beta and upgraded in place to rawhide.
Replacing root=/dev/protee_vg/root_lv with the UUID as in earlier
entries doesn't make any difference.

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From email.ahmedkamal at googlemail.com  Sun Oct  5 22:56:09 2008
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Mon, 6 Oct 2008 00:56:09 +0200
Subject: preUpgrade F9->F10 on LVM snapshot
In-Reply-To: <1223236873.5190.5.camel@zebes.localdomain>
References: <3da3b5b40810051048w28c6b435va39696d9f3bca35c@mail.gmail.com>
	<1223236873.5190.5.camel@zebes.localdomain>
Message-ID: <3da3b5b40810051556k5ece40dq7ca00662b019c052@mail.gmail.com>

Installed preupgrade from testing, and yes it sees F10beta once I check the
box for unstable distros.
preupgrade-cli --help results in a spectacular crash btw :D

On Sun, Oct 5, 2008 at 10:01 PM, Will Woods <wwoods at redhat.com> wrote:

> On Sun, 2008-10-05 at 19:48 +0200, Ahmed Kamal wrote:
> > Hi everyone,
> > I wanna help by testing F10 on my laptop. I am currently running F9
> > perfectly fine. Here's what I want to do:
> > - Take a lvm snapshot of my F9 (if that won't work, make a new LV and
> > dd over the file system)
> > - boot that .. preUpgrade that into F10 beta (or rawhide). Does
> > preUpgrade see F10 beta by itself ?
>
> I don't really have any info about the LVM snapshot stuff, but
> preupgrade-0.9.8-2.fc9 (in updates-testing) should have Fedora 10 Beta
> in its list of (unstable) upgrade targets. If it doesn't, file a bug.
>
> -w
>
>
> --
> 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/20081006/d684d9ac/attachment.htm>

From dominik at greysector.net  Sun Oct  5 23:22:54 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 6 Oct 2008 01:22:54 +0200
Subject: GNUstep
In-Reply-To: <CD1B1D1D-048C-401D-B618-90360B918E03@mac.com>
References: <E4C9AE8F-FDC7-48D1-A5B1-FA0856B4B2AB@mac.com>
	<CD1B1D1D-048C-401D-B618-90360B918E03@mac.com>
Message-ID: <20081005232253.GA15022@mokona.greysector.net>

On Sunday, 05 October 2008 at 19:06, Scott Christley wrote:
[...]
> So my suggestion is to handle libFoundation as though it was a  
> separate library outside of the GNUstep environment, to prevent  
> conflict with the GNUstep headers, have it be installed in its own  
> subdirectory.
> 
> /usr/include/libFoundation
> 
> and applications which require libFoundation just need to insert an  
> include flag during compilation so that its header are found in front  
> of GNUstep's.  These applications like opengroupware are free to use  
> gnustep-make unchanged for their build process, they just need to add  
> an additional line in their makefile.

If you can work on the necessary changes (if any) to opengroupware,
that's beginning to sound like a plan.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jonathan at jonmasters.org  Mon Oct  6 00:29:36 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Sun, 05 Oct 2008 20:29:36 -0400
Subject: pulse-rt by default?
Message-ID: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>

Hi,

Can I suggest that we consider adding new desktop users on a fresh
install to pulse-rt by default? Or, put another way, does anyone think
this is a particularly bad idea to be doing?

Jon.




From mzerqung at 0pointer.de  Mon Oct  6 00:48:46 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Mon, 6 Oct 2008 02:48:46 +0200
Subject: pulse-rt by default?
In-Reply-To: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
Message-ID: <20081006004846.GA13327@tango.0pointer.de>

On Sun, 05.10.08 20:29, Jon Masters (jonathan at jonmasters.org) wrote:

> Hi,
> 
> Can I suggest that we consider adding new desktop users on a fresh
> install to pulse-rt by default? Or, put another way, does anyone think
> this is a particularly bad idea to be doing?

It's a security issue.

If you add a user to pulse-rt he basically got the power to block the
CPU indefinitely and thus freeze the machine.

Unfortunately on Linux we don't have anything in place that would
allow "safe" usage of realtime features. There have been steps in the
right direction (like real-time group scheduling, RLIMIT_RTTIME), but
that is still a royal PITA to use or trivial to circumvent.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From arjan at infradead.org  Mon Oct  6 00:56:36 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Sun, 5 Oct 2008 17:56:36 -0700
Subject: pulse-rt by default?
In-Reply-To: <20081006004846.GA13327@tango.0pointer.de>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
	<20081006004846.GA13327@tango.0pointer.de>
Message-ID: <20081005175636.2d6bd8e3@infradead.org>

On Mon, 6 Oct 2008 02:48:46 +0200
Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Sun, 05.10.08 20:29, Jon Masters (jonathan at jonmasters.org) wrote:
> 
> > Hi,
> > 
> > Can I suggest that we consider adding new desktop users on a fresh
> > install to pulse-rt by default? Or, put another way, does anyone
> > think this is a particularly bad idea to be doing?
> 
> It's a security issue.
> 
> If you add a user to pulse-rt he basically got the power to block the
> CPU indefinitely and thus freeze the machine.
> 
> Unfortunately on Linux we don't have anything in place that would
> allow "safe" usage of realtime features. There have been steps in the
> right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> that is still a royal PITA to use or trivial to circumvent.
> 

yeah it's better to not need realtime, and just have a good enough
scheduler instead ;-)



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From sflaniga at redhat.com  Mon Oct  6 01:17:12 2008
From: sflaniga at redhat.com (Sean Flanigan)
Date: Mon, 06 Oct 2008 11:17:12 +1000
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <31390880.3571223020324059.JavaMail.asgeirf@localhost.localdomain>
References: <31390880.3571223020324059.JavaMail.asgeirf@localhost.localdomain>
Message-ID: <48E96718.4040905@redhat.com>

Asgeir Frimannsson wrote:
> ----- "Sean Flanigan" <sflaniga at redhat.com> wrote:
>> A gettext() hook could also be used to fetch translations from other
>> sources, such as a shared, up-to-date, translation database.  I think
>> that has the potential to be useful to a lot of people, not just
>> developers and testers.
>>
>> It doesn't really make sense to generate thousands of pseudo PO
>> files,
>> and compile them into static MOs, when all the required data (ie
>> English
>> text) is available at runtime.
>>
>> Let me change my question then.  How would people feel about having a
>> hook to override the behaviour of gettext() in a system-wide fashion?
> 
> I guess you could experiment with LD_PRELOAD for this. Tim Foster experimented with this a while a go. 
> http://blogs.sun.com/timf/entry/how_much_translation_do_you

Thank you, Asgeir, that's just the information I needed.  Looks like
LD_PRELOAD won't work on suid binaries, but it should be possible to
pseudo-localise 95% of packages without touching their build processes.

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

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

From mzerqung at 0pointer.de  Mon Oct  6 01:42:08 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Mon, 6 Oct 2008 03:42:08 +0200
Subject: pulse-rt by default?
In-Reply-To: <20081005175636.2d6bd8e3@infradead.org>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
	<20081006004846.GA13327@tango.0pointer.de>
	<20081005175636.2d6bd8e3@infradead.org>
Message-ID: <20081006014208.GA17900@tango.0pointer.de>

On Sun, 05.10.08 17:56, Arjan van de Ven (arjan at infradead.org) wrote:

> > If you add a user to pulse-rt he basically got the power to block the
> > CPU indefinitely and thus freeze the machine.
> > 
> > Unfortunately on Linux we don't have anything in place that would
> > allow "safe" usage of realtime features. There have been steps in the
> > right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> > that is still a royal PITA to use or trivial to circumvent.
>
> yeah it's better to not need realtime, and just have a good enough
> scheduler instead ;-)

I'd love to see something like SCHED_ISO implemented: i.e. where a
process could specify how much CPU time it needs and how often. Would
be ideal for everything that requires a fixed amount of CPU but not
the entire CPU all the time. Would be perfect for video playback,
audio stuff, animations, and everything else.

And that same information would be useful as a replacement for all the
different latency APIs we have on Linux -- if a process says it needs
a bit of CPU every 30th of a second to bring a new movie frame to the
screen then this same information can be used to let the CPU sleep in
some deep sleep state for the rest of the time.

SCHED_ISO wuldn't just solve the security issue. It would also be
immensly useful and a nice API on top.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From seg at haxxed.com  Mon Oct  6 01:46:18 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 05 Oct 2008 20:46:18 -0500
Subject: pulse-rt by default?
In-Reply-To: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
Message-ID: <1223257578.26341.7.camel@localhost.localdomain>

On Sun, 2008-10-05 at 20:29 -0400, Jon Masters wrote:
> Hi,
> 
> Can I suggest that we consider adding new desktop users on a fresh
> install to pulse-rt by default? Or, put another way, does anyone think
> this is a particularly bad idea to be doing?

Seems kind of pointless. If you're running low on CPU time, giving
pulseaudio priority will likely just result in client buffers running
dry anyway. Is there anything in place to take care of the priority
inversion problem? I know jackd/jacklib has some scheduling magic in
it...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081005/6353d645/attachment.sig>

From mattdm at mattdm.org  Mon Oct  6 02:18:09 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 5 Oct 2008 22:18:09 -0400
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E93B5A.5000302@andreafrancia.it>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<1223169402.10547.3.camel@abel> <48E8F373.20101@behdad.org>
	<48E932CC.8050607@andreafrancia.it> <48E933C2.9020608@behdad.org>
	<48E93B5A.5000302@andreafrancia.it>
Message-ID: <20081006021809.GA24675@jadzia.bu.edu>

On Mon, Oct 06, 2008 at 12:10:34AM +0200, Andrea Francia wrote:
>> Eh, thought it's obvious.  One can type "trash" then use tab completion to see
>> what commands are available.  
> So the commands names could became:
> - trashcan-put
> - trashcan-empty
> - trashcan-list
> - trashcan-restore
> My English is not so good, is the 'trashcan-put' a good choice?

It's not as good as just 'trash'.

Are there multiple "trash" programs out there? Is this likely to be a real
problem?

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mzerqung at 0pointer.de  Mon Oct  6 02:18:38 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Mon, 6 Oct 2008 04:18:38 +0200
Subject: pulse-rt by default?
In-Reply-To: <1223257578.26341.7.camel@localhost.localdomain>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
	<1223257578.26341.7.camel@localhost.localdomain>
Message-ID: <20081006021838.GA21214@tango.0pointer.de>

On Sun, 05.10.08 20:46, Callum Lerwick (seg at haxxed.com) wrote:

> On Sun, 2008-10-05 at 20:29 -0400, Jon Masters wrote:
> > Hi,
> > 
> > Can I suggest that we consider adding new desktop users on a fresh
> > install to pulse-rt by default? Or, put another way, does anyone think
> > this is a particularly bad idea to be doing?
> 
> Seems kind of pointless. If you're running low on CPU time, giving
> pulseaudio priority will likely just result in client buffers running
> dry anyway. Is there anything in place to take care of the priority
> inversion problem? I know jackd/jacklib has some scheduling magic in
> it...

I am not sure you fully understand what real-time is about. It is not
about giving some process "priority". That's what nice levels are for.

Taking care of the "priority inversion problem"? There is no need for
anyone to work around that, since we have PTHREAD_PRIO_INHERIT which
PA has been using for quite a while (although we are mostly lock-less
now).

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From jonathan at jonmasters.org  Mon Oct  6 02:20:24 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Sun, 05 Oct 2008 22:20:24 -0400
Subject: pulse-rt by default?
In-Reply-To: <20081005175636.2d6bd8e3@infradead.org>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
	<20081006004846.GA13327@tango.0pointer.de>
	<20081005175636.2d6bd8e3@infradead.org>
Message-ID: <1223259624.12064.13.camel@perihelion.int.jonmasters.org>

On Sun, 2008-10-05 at 17:56 -0700, Arjan van de Ven wrote:
> On Mon, 6 Oct 2008 02:48:46 +0200
> Lennart Poettering <mzerqung at 0pointer.de> wrote:
> 
> > On Sun, 05.10.08 20:29, Jon Masters (jonathan at jonmasters.org) wrote:
> > 
> > > Hi,
> > > 
> > > Can I suggest that we consider adding new desktop users on a fresh
> > > install to pulse-rt by default? Or, put another way, does anyone
> > > think this is a particularly bad idea to be doing?
> > 
> > It's a security issue.

It's not a security issue if you're on a single user desktop/laptop, and
therefore something that could be configured up during installation. One
idea I had was to suggest having install "profiles" available - I'd love
to have an anaconda option I can click that will:

* Add me to sudoers automatically (first thing I do on every Fedora/RHEL
system, and the most annoying thing missing from a standard install)
* Add me to various groups useful to desktop self-admin, etc.
* (Disable SELinux policy with a vengeance :P)

> > Unfortunately on Linux we don't have anything in place that would
> > allow "safe" usage of realtime features.

That's not true. You already have PolicyKit support and even look to see
if you have a policy. So that authorization could just be setup in
advance for pulseaudio if it's running on a desktop system.

> There have been steps in the
> > right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> > that is still a royal PITA to use or trivial to circumvent.

> yeah it's better to not need realtime, and just have a good enough
> scheduler instead ;-)

I agree about the longer term.

Jon.




From roopesh.majeti at gmail.com  Mon Oct  6 02:33:19 2008
From: roopesh.majeti at gmail.com (Roopesh Majeti)
Date: Mon, 6 Oct 2008 08:03:19 +0530
Subject: looking for co-maintainers
In-Reply-To: <gcb8et$7b6$1@ger.gmane.org>
References: <48E90DC3.5010709@spicenitz.org> <gcb8et$7b6$1@ger.gmane.org>
Message-ID: <599059470810051933o34f88c90g3ca6e85b6e651b3e@mail.gmail.com>

Hi,

 I would be interested for the following :

1) minirpc
2) htmldoc [ if available ].

I am a newebie member of fedora dev, but could not contribute till now, due
to my professional work load. Guess this would be a good chance, if given.

Please let me know, if any concerns. If possible, please let me know the
wiki link for the same, so that i can start.


Regards
Roopesh.


On Mon, Oct 6, 2008 at 2:05 AM, Pavel Alexeev (aka Pahan-Hubbitus) <
forum at ru.bir.ru> wrote:

> Adam Goode ?????:
>
>> Hi,
>>
>> My life is about to get very busy (twins on the way), so I want to make
>> sure I at least have co-maintainers for all (or most) of my packages. Anyone
>> interested?
>>
>>
>> escape -- puzzle game
>>
> I add himself. I believe can be helpfully.
>
>
> --
> 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/20081006/9b1a1e11/attachment.htm>

From bashton at brennanashton.com  Mon Oct  6 03:01:50 2008
From: bashton at brennanashton.com (Brennan Ashton)
Date: Sun, 05 Oct 2008 20:01:50 -0700
Subject: pulse-rt by default?
In-Reply-To: <1223259624.12064.13.camel@perihelion.int.jonmasters.org>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
	<20081006004846.GA13327@tango.0pointer.de>
	<20081005175636.2d6bd8e3@infradead.org>
	<1223259624.12064.13.camel@perihelion.int.jonmasters.org>
Message-ID: <1223262110.3009.2.camel@localhost.localdomain>

On Sun, 2008-10-05 at 22:20 -0400, Jon Masters wrote:
> On Sun, 2008-10-05 at 17:56 -0700, Arjan van de Ven wrote:
> > On Mon, 6 Oct 2008 02:48:46 +0200
> > Lennart Poettering <mzerqung at 0pointer.de> wrote:
> > 
> > > On Sun, 05.10.08 20:29, Jon Masters (jonathan at jonmasters.org) wrote:
> > > 
> > > > Hi,
> > > > 
> > > > Can I suggest that we consider adding new desktop users on a fresh
> > > > install to pulse-rt by default? Or, put another way, does anyone
> > > > think this is a particularly bad idea to be doing?
> > > 
> > > It's a security issue.
> 
> It's not a security issue if you're on a single user desktop/laptop, and
> therefore something that could be configured up during installation. One
> idea I had was to suggest having install "profiles" available - I'd love
> to have an anaconda option I can click that will:
> 
> * Add me to sudoers automatically (first thing I do on every Fedora/RHEL
> system, and the most annoying thing missing from a standard install)
> * Add me to various groups useful to desktop self-admin, etc.
> * (Disable SELinux policy with a vengeance :P)
> 
> > > Unfortunately on Linux we don't have anything in place that would
> > > allow "safe" usage of realtime features.
> 
> That's not true. You already have PolicyKit support and even look to see
> if you have a policy. So that authorization could just be setup in
> advance for pulseaudio if it's running on a desktop system.
> 
> > There have been steps in the
> > > right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> > > that is still a royal PITA to use or trivial to circumvent.
> 
> > yeah it's better to not need realtime, and just have a good enough
> > scheduler instead ;-)
> 
> I agree about the longer term.
> 
> Jon.
> 
> 
I have been fighting to get realtime working for a while on my computer
I use for composition, the normal scheduler just does not cut it for
this.  While I agree that in the long run fixing that is the solution,
in the sort term it would be nice not to leave these type of users out
on a limb, or looking at other distros that do it by default.

just my $0.02




From adrian at lisas.de  Mon Oct  6 05:27:32 2008
From: adrian at lisas.de (Adrian Reber)
Date: Mon, 6 Oct 2008 07:27:32 +0200
Subject: Strange multilib conflict
Message-ID: <20081006052732.GA7669@lisas.de>


Maybe somebody from this list can see the problem in this bug report,
because I am out of ideas:

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

A user is installing libcdio on rawhide and gets a file conflict on the
man pages when installing the x86_64 and i386 version at the same time.

I fixed it on my F8 test system and verified it by installing the libcdio
version from rawhide on that F8 system.

On the system of the bug reporter it still fails with the same error
message about a file conflict.

I think I have verified that the man pages in the x86_64 and i386
version of the package have the same time. If somebody knows why this
still fails or if there are any other ideas how to fix this, I would be
happy to hear it. Thanks.

		Adrian



From j.w.r.degoede at hhs.nl  Mon Oct  6 06:57:50 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 06 Oct 2008 08:57:50 +0200
Subject: Strange multilib conflict
In-Reply-To: <20081006052732.GA7669@lisas.de>
References: <20081006052732.GA7669@lisas.de>
Message-ID: <48E9B6EE.5030909@hhs.nl>

Adrian Reber wrote:
> Maybe somebody from this list can see the problem in this bug report,
> because I am out of ideas:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=462125
> 
> A user is installing libcdio on rawhide and gets a file conflict on the
> man pages when installing the x86_64 and i386 version at the same time.
> 
> I fixed it on my F8 test system and verified it by installing the libcdio
> version from rawhide on that F8 system.
> 
> On the system of the bug reporter it still fails with the same error
> message about a file conflict.
> 
> I think I have verified that the man pages in the x86_64 and i386
> version of the package have the same time. If somebody knows why this
> still fails or if there are any other ideas how to fix this, I would be
> happy to hear it. Thanks.
> 

For the cause, see attachment.

The best solution is probably to split libcdio in libcdio and libcdio-progs, 
with the utilities and the man-pages in -progs, then on x86_64 there will only 
be both an x86_64 and i386 version of libcdio and libcdio-devel but not of 
libcdio-progs. Added advantages of this approach are some saved diskspace for 
the 99% of users who only want the lib (mostly relevant for livecd's) and the 
rpm people want to get rid of the filecolor hack, where elf binaries may differ 
and this is not a file conflict but instead the 64 bits version gets used, in 
the future, so all packages will need a split between libs and progs in the 
future anyways.

Regards,

Hans



From j.w.r.degoede at hhs.nl  Mon Oct  6 06:58:28 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 06 Oct 2008 08:58:28 +0200
Subject: Strange multilib conflict
In-Reply-To: <20081006052732.GA7669@lisas.de>
References: <20081006052732.GA7669@lisas.de>
Message-ID: <48E9B714.1050705@hhs.nl>

<now with the promised attachment>

Adrian Reber wrote:
> Maybe somebody from this list can see the problem in this bug report,
> because I am out of ideas:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=462125
> 
> A user is installing libcdio on rawhide and gets a file conflict on the
> man pages when installing the x86_64 and i386 version at the same time.
> 
> I fixed it on my F8 test system and verified it by installing the libcdio
> version from rawhide on that F8 system.
> 
> On the system of the bug reporter it still fails with the same error
> message about a file conflict.
> 
> I think I have verified that the man pages in the x86_64 and i386
> version of the package have the same time. If somebody knows why this
> still fails or if there are any other ideas how to fix this, I would be
> happy to hear it. Thanks.
> 

For the cause, see attachment.

The best solution is probably to split libcdio in libcdio and libcdio-progs,
with the utilities and the man-pages in -progs, then on x86_64 there will only
be both an x86_64 and i386 version of libcdio and libcdio-devel but not of
libcdio-progs. Added advantages of this approach are some saved diskspace for
the 99% of users who only want the lib (mostly relevant for livecd's) and the
rpm people want to get rid of the filecolor hack, where elf binaries may differ
and this is not a file conflict but instead the 64 bits version gets used, in
the future, so all packages will need a split between libs and progs in the
future anyways.

Regards,

Hans

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/52a5489a/attachment.ksh>

From yaneti at declera.com  Mon Oct  6 07:20:44 2008
From: yaneti at declera.com (Yanko Kaneti)
Date: Mon, 06 Oct 2008 10:20:44 +0300
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <200810051219.31882.Juha.Tuomala@iki.fi>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>
Message-ID: <1223277645.18676.2.camel@d2>

On Sun, 2008-10-05 at 12:19 +0300, Juha Tuomala wrote:
> 
> On Sunday 05 October 2008 02:36:20 Patrice Dumas wrote:
> > On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
> > > the package because he think that executables are too generic (trash,
> 
> > There is only trash that I find too generic...
> 
> speaking of too generic... how about:
> 
> % rpm -qf `which testparm`
> samba-common-3.2.3-0.20.fc9.x86_64

$ repoquery -f /usr/bin/player
player-0:2.1.1-5.fc10.i386

careless on so many levels...




From martin.langhoff at gmail.com  Mon Oct  6 07:34:48 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 6 Oct 2008 20:34:48 +1300
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <48E45455.7000203@redhat.com>
References: <48E45455.7000203@redhat.com>
Message-ID: <46a038f90810060034y2ac8de3pf535bc057f97a3ed@mail.gmail.com>

2008/10/2 Sean Flanigan <sflaniga at redhat.com>:
> I have a simple Ant task which can generate pseudo-translations like the
> one above from a gettext POT files,

I am after a few sets of "latin-lookalike" character tables I can use.
Have you (or anyone) got pointers to good tables?

The simple example phrase you provided hit a bug in moodle (php
webapp) straight away - I think a few webapps have trouble with that
funny 'e' (U+1D5BE). Interestingly, it's also present in Jira
(Java-based webapp). Might be an iconv issue.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From z.kota at gmx.net  Mon Oct  6 07:37:35 2008
From: z.kota at gmx.net (Zoltan Kota)
Date: Mon, 6 Oct 2008 09:37:35 +0200 (CEST)
Subject: koji problem
Message-ID: <Pine.LNX.4.58.0810060927001.11523@venus.brc>

Hi,

My build of pybliographer for devel yesterday around 21:00 UTC failed 
with the result:
"BuildrootError: could not init mock buildroot, mock exited with status 
30"

http://koji.fedoraproject.org/koji/buildinfo?buildID=65374

I tried to resubmit the job without success. Is it a buildsys issue or my 
fault?

And now I cannot login to Koji, it says:
"Could not establish an encrypted connection with koji.fedoraproject.org 
because your certificate has been revoked."

What to do with this? Could anybody help?

Thanks!
Zoltan



From mcepl at redhat.com  Mon Oct  6 07:37:03 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 06 Oct 2008 09:37:03 +0200
Subject: trash-cli : Looking for a reviewer
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>
	<20081005120044.c64a2758.mschwendt@gmail.com>
Message-ID: <vpror5x7m2.ln2@ppp1053.in.ipex.cz>

On 2008-10-05, 10:00 GMT, Michael Schwendt wrote:
> The samba-common package contains more such poorly named files: 
> /usr/bin/net

I would slightly defend this one -- Windows central net command 
(of which this is emulation) is called so. And yes, other ones 
are absolutely horrible.

Mat?j



From kzak at redhat.com  Mon Oct  6 07:46:43 2008
From: kzak at redhat.com (Karel Zak)
Date: Mon, 6 Oct 2008 09:46:43 +0200
Subject: Boot speedup with readahead
In-Reply-To: <48E4B5A0.5000905@fedoraproject.org>
References: <g9tne8$dt0$1@ger.gmane.org>
	<20080906212125.27b9b3bb@infradead.org>
	<48E4B405.8040300@draigBrady.com>
	<48E4B5A0.5000905@fedoraproject.org>
Message-ID: <20081006074643.GA2991@nb.net.home>

On Thu, Oct 02, 2008 at 05:20:56PM +0530, Rahul Sundaram wrote:
> P?draig Brady wrote:
>> Arjan van de Ven wrote:
>>> for those who are going to the plumbers conference... Auke Kok and I
>>> will present there on how to make a Fedora based system boot in 5
>>> seconds...
>>>
>>> and yes a form of readahead was needed to achieve that ;-)
>>
>> There is some public info on this now:
>> http://lwn.net/Articles/299483/
>
> You are late. Check
>
> https://bugzilla.redhat.com/show_bug.cgi?id=464045

 Well, on first glance the package is not ready for real distribution
 (for example see how filelist.c checks argv[1]...).

 I have a few questions,

  * sreadahead depends on Arjan's EXT3_IOC_INODE_JIFFIES ioctl, does
    Fedora kernel support this ioctl?

  * what generates the list of files?

  * shouldn't be better to add EXT3_IOC_INODE_JIFFIES support to
    standard Fedora readahead?

        Karel

-- 
 Karel Zak  <kzak at redhat.com>



From ricky at fedoraproject.org  Mon Oct  6 07:52:03 2008
From: ricky at fedoraproject.org (Ricky Zhou)
Date: Mon, 6 Oct 2008 03:52:03 -0400
Subject: koji problem
In-Reply-To: <Pine.LNX.4.58.0810060927001.11523@venus.brc>
References: <Pine.LNX.4.58.0810060927001.11523@venus.brc>
Message-ID: <20081006075203.GC4622@sphe.res.cmu.edu>

On 2008-10-06 09:37:35 AM, Zoltan Kota wrote:
> My build of pybliographer for devel yesterday around 21:00 UTC failed 
> with the result:
> "BuildrootError: could not init mock buildroot, mock exited with status 
> 30"
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=65374
> 
> I tried to resubmit the job without success. Is it a buildsys issue or my 
> fault?
Hi, there was an infrastructure outage
(https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00236.html)
today, which took that down.  It should work if you try again.

> And now I cannot login to Koji, it says:
> "Could not establish an encrypted connection with koji.fedoraproject.org 
> because your certificate has been revoked."
Whenever you generate a new cert at
https://admin.fedoraproject.org/accounts/user/gencert, your old one gets
revoked, so you can only have one cert at any given time.  This error
usually happens when somebody downloads a new cert and tries to use
their old one again.  Try removing all of your old certs and
downloading/using a new one, and it should work.  

Thanks,
Ricky
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/65af37a7/attachment.sig>

From mcepl at redhat.com  Mon Oct  6 07:48:22 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 06 Oct 2008 09:48:22 +0200
Subject: procedure for renaming a package
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081005140618.GA2755@free.fr>
	<1223228962.9987.13.camel@luminos.localdomain>
	<20081005193648.GA3361@free.fr>
Message-ID: <6fsor5x7m2.ln2@ppp1053.in.ipex.cz>

On 2008-10-05, 19:36 GMT, Patrice Dumas wrote:
> I don't need a rereview of this package, currently. It is 
> a (rather) unusual package, and I'd prefer if reviewer 
> interested in TeX/LaTeX used their time differently,

for example ???

Mat?j



From markmc at redhat.com  Mon Oct  6 08:10:47 2008
From: markmc at redhat.com (Mark McLoughlin)
Date: Mon, 06 Oct 2008 09:10:47 +0100
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <20081003194026.GE23876@redhat.com>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
	<20081003171721.GU18995@redhat.com>
	<4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>
	<1223059619.19348.6.camel@aglarond.local>
	<20081003194026.GE23876@redhat.com>
Message-ID: <1223280647.4182.11.camel@blaa>

On Fri, 2008-10-03 at 20:40 +0100, Daniel P. Berrange wrote:
> On Fri, Oct 03, 2008 at 02:46:59PM -0400, Jeremy Katz wrote:
> > On Fri, 2008-10-03 at 14:41 -0400, James Ralston wrote:
> > > To claim "out of the box" support for KVM bridge networking,
> > > virt-manager has to be able to do all of this automatically.  That
> > > means that either virt-manager itself needs to know how to turn a
> > > physical device into a bridged device, or anaconda needs to do this at
> > > system install time.  (E.g., any physical device configured with a
> > > fixed IP address is automatically created as a bridge.)
> > 
> > anaconda is certainly not going to do this.  Changing a device to be
> > bridged has some interesting consequences in a lot of networking
> > environments.  Not to mention that anaconda is getting out of the
> > business of the network setup as everything should be being handled by
> > NetworkManager
> 
> I wouldn't expect anaconda todo this either - there's simply too many
> complications with bridging to expect any tool to automatically get it
> right. Ultimately networkmanager needs a capability optionally enable
> sharing of a physical device between host & guest. It is getting much
> closer to being ready for this type of capability with its recent
> releases.

Yeah, here's the feature request:

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

Talking to dcbw, the thing he seemed most concerned about was how this
"physical interface sharing" could be confused with NetworkManager's new
"connection sharing" feature.

Since the latter concept isn't really exposed in the UI now - i.e. you
just do "Create New Wireless Network" and traffic on that network will
be automatically forwarded/NAT-ed via the default route - then I don't
think that's such an issue any more.

Cheers,
Mark.



From joshuacov at googlemail.com  Mon Oct  6 08:23:12 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 6 Oct 2008 10:23:12 +0200
Subject: Cannot recompile x86_64 kernel on installed F9 i686
Message-ID: <5f6f8c5f0810060123s35930ddxc46ba1003c52b722@mail.gmail.com>

I tried to recompile the x86_64 version of the F10beta kernel on my F9
i686. And this is the error message I got

------
+ perl -p -i -e 's/^EXTRAVERSION.*/EXTRAVERSION =
-0.352.rc7.git1.fc10.x86_64/' Makefile
+ make -s mrproper
+ cp configs/kernel-2.6.27-x86_64.config .config
++ head -1 .config
++ cut -b 3-
+ Arch=x86_64
+ echo USING ARCH=x86_64
USING ARCH=x86_64
+ make -s ARCH=x86_64 nonint_oldconfig
+ make -s ARCH=x86_64 V=1 -j3 bzImage
#
# configuration written to .config
#
  SYMLINK include/asm -> include/asm-x86
scripts/mod/empty.c:1: error: code model 'kernel' not supported in the
32 bit mode
scripts/mod/empty.c:1: sorry, unimplemented: 64-bit mode not compiled in
make[2]: *** [scripts/mod/empty.o] Error 1
make[1]: *** [scripts/mod] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [scripts] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.7836 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.7836 (%build)
---------

Recompiling the i686 kernel works fine but not the x86_64. Tried also
the lastes kernel in koji and got the same error. How to recompile it?



From pertusus at free.fr  Mon Oct  6 08:44:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 6 Oct 2008 10:44:43 +0200
Subject: procedure for renaming a package
In-Reply-To: <6fsor5x7m2.ln2@ppp1053.in.ipex.cz>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081005140618.GA2755@free.fr>
	<1223228962.9987.13.camel@luminos.localdomain>
	<20081005193648.GA3361@free.fr> <6fsor5x7m2.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081006084443.GA2829@free.fr>

On Mon, Oct 06, 2008 at 09:48:22AM +0200, Matej Cepl wrote:
> On 2008-10-05, 19:36 GMT, Patrice Dumas wrote:
> > I don't need a rereview of this package, currently. It is 
> > a (rather) unusual package, and I'd prefer if reviewer 
> > interested in TeX/LaTeX used their time differently,
> 
> for example ???

Nobody stepped up to review chktex, so Tibbs is doing it, and I begun
reviewing lcdf-typetools after some weeks because nobody else did it,
although this is now more or less a required component of texlive.
I also review ttf2pt1 although I left 2 weeks to pass hoping for
somebody else to step in.

And some time ago I posted all the packages that are in texlive but have
a separate upstream, and it is only now that they are posted for review
(chktex, ttf2pt1 and lcdf-typetools), by people needing sponsors.

I may be wrong, maybe the TeX/LaTeX community in fedora is healthy, but
this is not my impression.

Another thing that, in my opinion, shows that we are not really very
active is the lack of guidelines for TeX. It is also linked with the
rapid pace of changes linked with switching to texlive 2007 and now 2008
is already there and completly different, but I don't think this is the
only reason.

--
Pat



From alan at redhat.com  Mon Oct  6 08:54:50 2008
From: alan at redhat.com (Alan Cox)
Date: Mon, 6 Oct 2008 04:54:50 -0400
Subject: pulse-rt by default?
In-Reply-To: <1223257578.26341.7.camel@localhost.localdomain>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
	<1223257578.26341.7.camel@localhost.localdomain>
Message-ID: <20081006085450.GA29528@shell.devel.redhat.com>

On Sun, Oct 05, 2008 at 08:46:18PM -0500, Callum Lerwick wrote:
> pulseaudio priority will likely just result in client buffers running
> dry anyway. Is there anything in place to take care of the priority
> inversion problem? I know jackd/jacklib has some scheduling magic in
> it...

And on a lot of hardware the problem in the X server locking the bus up
anyway not the kernel scheduler. The intel driver developed that bad habit
between FC8 and FC9. Nothing the kernel can do if the PCI bus is being
hogged by another device so much the buffers drain.

Alan



From simon.andrews at bbsrc.ac.uk  Mon Oct  6 08:59:45 2008
From: simon.andrews at bbsrc.ac.uk (Simon Andrews)
Date: Mon, 06 Oct 2008 09:59:45 +0100
Subject: Uniform Proxy Settings
In-Reply-To: <200810051553.m95Fr1fe007853@laptop14.inf.utfsm.cl>
References: <48E48E04.1080906@students.iiit.ac.in> <gc58g8$ho8$1@ger.gmane.org>
	<200810051553.m95Fr1fe007853@laptop14.inf.utfsm.cl>
Message-ID: <gcck21$98b$1@ger.gmane.org>

Horst H. von Brand wrote:
> Simon Andrews <simon.andrews at bbsrc.ac.uk> wrote: 
>> One suggestion to get around this would be to run a proxy on localhost
>> and make all proxy aware applications use that in their default
>> install. This wouldn't actually have to do any caching - just act as a
>> common point at which behaviour could actually be changed without the
>> cooperation of the programs.
> 
> Icky.

No arguement from me - however it's pretty analagous to the situation we 
shipped with NetorkManager installing bind so that DNS settings could be 
changed on the fly, so there is some precendent here.

>> We could then put hooks into NetworkManager to change the behaviour of
>> the local proxy so that it either sends its requests directly to the
>> internet, or routes them via a secondary proxy.
>>
>> This all feels a bit icky to me - but I can't think of a nicer way of
>> doing this which doesn't require the cooperation of the authors of
>> every proxy-aware application.
> 
> This is papering over the (very real) bugs in the applications (Yes, I do
> consider not getting and resetting proxy and other network settings
> transparently a bug), at a very real cost for all users.

The trouble is that any cleaner solution requires the cooperation of all 
application developers to implement.  Also, speaking as an application 
developer who writes network aware applications why the hell should this 
be my problem?  Surely the presence/absence of a proxy is something 
which should be handled at a lower level that the application.  My 
application doesn't care about the routing tables on your machine so 
long as my connections get through, so why should it have to care about 
whether you're running a proxy?

Simon.



From hughsient at gmail.com  Mon Oct  6 09:29:14 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 06 Oct 2008 10:29:14 +0100
Subject: Obsoletes question: codeina
Message-ID: <1223285354.6012.33.camel@hughsie-laptop>

In the PackageKit-gstreamer-plugins package, I've currently got:

Obsoletes: codeina < 0.10.1
Provides:  codeina = 0.10.1

The version in rawhide is codeina-0.10.1-9.fc10

Looking at bug https://bugzilla.redhat.com/show_bug.cgi?id=465723 it
looks like I've got this wrong.

Should I just do:

Obsoletes: codeina
Provides:  codeina

Thanks,

Richard.




From tim at niemueller.de  Mon Oct  6 09:39:52 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Mon, 06 Oct 2008 11:39:52 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <1223277645.18676.2.camel@d2>
References: <1223161806.9727.8.camel@abel>
	<20081004233620.GB2670@free.fr>	<200810051219.31882.Juha.Tuomala@iki.fi>
	<1223277645.18676.2.camel@d2>
Message-ID: <48E9DCE8.6050500@niemueller.de>

Yanko Kaneti schrieb:
> On Sun, 2008-10-05 at 12:19 +0300, Juha Tuomala wrote:
>> On Sunday 05 October 2008 02:36:20 Patrice Dumas wrote:
>>> On Sun, Oct 05, 2008 at 01:10:06AM +0200, Jean-Fran?ois Martin wrote:
>>>> the package because he think that executables are too generic (trash,
>>> There is only trash that I find too generic...
>> speaking of too generic... how about:
>>
>> % rpm -qf `which testparm`
>> samba-common-3.2.3-0.20.fc9.x86_64
> 
> $ repoquery -f /usr/bin/player
> player-0:2.1.1-5.fc10.i386
> 
> careless on so many levels...

That has been discussed during the review and the reasoning was that the
project chose that name and renaming it would only cause unexpected
hassles for people who install this software. Upstream chose that name,
so if we want that package we should stick to it, if only to allow users
to reproduce commands given in documentation, wikis, blogs etc.
Additionally your very repoquery shows that there are in fact no
conflicts, so why bother?

I also don't see a problem why binary in the package for which this
thread was initiated should be renamed. There is no trash command, it
provides functionality which clearly fits the name, so why the heck
should it be renamed? Just because someone might as well add such a
command later? It's like not using your roller skates to keep them in a
nice new condition, until you have grown out of them...

What I would suggest to the trash tool besides that is that it should
provide a single executable with a command syntax like "trash add",
"trash empty" etc. Much like git or svn do it. I'd say git switched to
the single entry point for a good reason...

My two cents for the samba files like net and profiles: they are too
generic because they suggest to provide functionality beyond the bounds
of samba, the trash command does not do this in my opinion.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From simon.andrews at bbsrc.ac.uk  Mon Oct  6 09:44:22 2008
From: simon.andrews at bbsrc.ac.uk (Simon Andrews)
Date: Mon, 06 Oct 2008 10:44:22 +0100
Subject: Uniform Proxy Settings
In-Reply-To: <48E63C16.4080004@students.iiit.ac.in>
References: <48E48E04.1080906@students.iiit.ac.in>	<gc58g8$ho8$1@ger.gmane.org>	<48E631D9.6040301@students.iiit.ac.in>	<20081003151653.GI24829@angus.ind.WPI.EDU>
	<48E63C16.4080004@students.iiit.ac.in>
Message-ID: <gccmln$i11$1@ger.gmane.org>

Kulbir Saini wrote:
> 
> 
> Chuck Anderson wrote:
>> On Fri, Oct 03, 2008 at 08:23:13PM +0530, Kulbir Saini wrote:
>>>> One suggestion to get around this would be to run a proxy on localhost
>>>   This sounds good but some work environments doesn't allow you to run
>>> proxy on your own machine.
>>
>> I don't see how it would matter.  The proxy would be an internal-only
>> abstraction of how the system talks to the rest of the net.  It
>> wouldn't be visible or usable from outside the local system.
> 
>   I think its not fair enough to introduce a proxy server (even if its 
> minimal and local) just because we can't figure out a uniform system to 
> set and retrieve the proxy settings. And even if we have this proxy 
> minimal and local proxy server, there is no guarantee that all the apps 
> will use it. So, IMHO its best to force applications to use a uniform 
> location like http_proxy for setting/getting the proxy settings.

I don't see the problem with this.  Although you might call this a proxy 
it would only be listening on localhost and wouldn't do any caching so I 
can't see what an IT department would object to.

Having thought about this some more I'd even be tempted to make this 
local proxy transparent so you need no support at all from any application.

In principle this is absolutely the right way to do things so that you 
don't have to enforce special behaviour in all applications.

Environment variables are not a great answer to this.  You can't 
externally change the environment of a running process so updates 
mid-session aren't possible.  Also even now I often find problems with 
things like sudo wiping out the proxy from the environment.

Simon.



From paul at city-fan.org  Mon Oct  6 09:49:13 2008
From: paul at city-fan.org (Paul Howarth)
Date: Mon, 06 Oct 2008 10:49:13 +0100
Subject: Obsoletes question: codeina
In-Reply-To: <1223285354.6012.33.camel@hughsie-laptop>
References: <1223285354.6012.33.camel@hughsie-laptop>
Message-ID: <48E9DF19.60909@city-fan.org>

Richard Hughes wrote:
> In the PackageKit-gstreamer-plugins package, I've currently got:
> 
> Obsoletes: codeina < 0.10.1
> Provides:  codeina = 0.10.1
> 
> The version in rawhide is codeina-0.10.1-9.fc10
> 
> Looking at bug https://bugzilla.redhat.com/show_bug.cgi?id=465723 it
> looks like I've got this wrong.
> 
> Should I just do:
> 
> Obsoletes: codeina
> Provides:  codeina

Unversioned obsoletes are bad and should be avoided like the plague.

How about this?

Obsoletes: codeina < 0.10.1-10
Provides:  codeina = 0.10.1-10

Paul.



From hughsient at gmail.com  Mon Oct  6 10:19:52 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 06 Oct 2008 11:19:52 +0100
Subject: Obsoletes question: codeina
In-Reply-To: <48E9DF19.60909@city-fan.org>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<48E9DF19.60909@city-fan.org>
Message-ID: <1223288392.6012.37.camel@hughsie-laptop>

On Mon, 2008-10-06 at 10:49 +0100, Paul Howarth wrote:
> How about this?
> 
> Obsoletes: codeina < 0.10.1-10
> Provides:  codeina = 0.10.1-10

Yup, I'll do this, thanks.

Richard.




From Juha.Tuomala at iki.fi  Mon Oct  6 10:45:57 2008
From: Juha.Tuomala at iki.fi (Juha Tuomala)
Date: Mon, 6 Oct 2008 13:45:57 +0300
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E9DCE8.6050500@niemueller.de>
References: <1223161806.9727.8.camel@abel> <1223277645.18676.2.camel@d2>
	<48E9DCE8.6050500@niemueller.de>
Message-ID: <200810061345.57871.Juha.Tuomala@iki.fi>




On Monday 06 October 2008 12:39:52 Tim Niemueller wrote:
> That has been discussed during the review and the reasoning was that the
> project chose that name and renaming it would only cause unexpected
> hassles for people who install this software. 

> Upstream chose that name, 

Perhaps this discussion should be taken in upstream like
other enhancements.

> so if we want that package we should stick to it, if only to allow users
> to reproduce commands given in documentation, wikis, blogs etc.

That's true and gives another good reason for upstream.


> Additionally your very repoquery shows that there are in fact no
> conflicts, so why bother?

Because it confuses new users, logical naming would make it
easier to learn new tools.

> My two cents for the samba files like net and profiles: they are too
> generic because they suggest to provide functionality beyond the bounds
> of samba, 

Postgresql has this problem too:

/usr/bin/createdb
/usr/bin/createlang
/usr/bin/createuser
/usr/bin/dropdb
/usr/bin/droplang
/usr/bin/dropuser
/usr/bin/pg_dump
/usr/bin/pg_dumpall
/usr/bin/pg_restore
/usr/bin/psql
/usr/bin/reindexdb
/usr/bin/vacuumdb

I think all those should have pg_ prefix. Samba could 
have smb_, whatever.

/usr/bin/msql2mysql
/usr/bin/my_print_defaults
/usr/bin/mysql
/usr/bin/mysql_config
/usr/bin/mysql_find_rows
/usr/bin/mysql_tableinfo
/usr/bin/mysql_waitpid
/usr/bin/mysqlaccess
/usr/bin/mysqladmin
/usr/bin/mysqlbinlog
/usr/bin/mysqlcheck
/usr/bin/mysqldump
/usr/bin/mysqlimport
/usr/bin/mysqlshow

I've many times writen my<tab> to see what's available. With
pgsql you need to do rpm -ql postgresql|less. So it's also 
an usability issue.

Another naming mess is the /etc/init.d/ names.
Some end to 'd', some doesn't.


Tuju

-- 
Varo hattup?isi? autoilijoita.



From pertusus at free.fr  Mon Oct  6 10:48:42 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 6 Oct 2008 12:48:42 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48E9DCE8.6050500@niemueller.de>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>
	<1223277645.18676.2.camel@d2> <48E9DCE8.6050500@niemueller.de>
Message-ID: <20081006104842.GB2751@free.fr>

On Mon, Oct 06, 2008 at 11:39:52AM +0200, Tim Niemueller wrote:
> 
> That has been discussed during the review and the reasoning was that the
> project chose that name and renaming it would only cause unexpected
> hassles for people who install this software. Upstream chose that name,
> so if we want that package we should stick to it, if only to allow users
> to reproduce commands given in documentation, wikis, blogs etc.
> Additionally your very repoquery shows that there are in fact no
> conflicts, so why bother?
> 
> I also don't see a problem why binary in the package for which this
> thread was initiated should be renamed. There is no trash command, it
> provides functionality which clearly fits the name, so why the heck
> should it be renamed? Just because someone might as well add such a
> command later? It's like not using your roller skates to keep them in a
> nice new condition, until you have grown out of them...

The issue is that many upstream don't care about using names that are
not prone to future conflicts, and use generic names. In my opinion,
generic names should be reserved to standardized programs (like
sendmail, ls, ...). Upstream don't care and selfishly choose the name
that suits them most, but at the distro level, and for the long-term, 
I think that we should try to regulate a bit those namings such
that projects don't take these precious names carelessly. To put it
otherwise, the generic names (like trash, player, record, convert, ...)
and the short names (like ls, qpd, fjk, tgn...) are scarce and a first
come first serve is certainly a bad way of choosing them. In theory,
upstream should think about those issues when choosing a name and avoid
misusing these scarce words, but this is not what happens.

--
Pat



From rjones at redhat.com  Mon Oct  6 10:48:54 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 6 Oct 2008 11:48:54 +0100
Subject: looking for co-maintainers
In-Reply-To: <48E90DC3.5010709@spicenitz.org>
References: <48E90DC3.5010709@spicenitz.org>
Message-ID: <20081006104854.GA2241@amd.home.annexia.org>

On Sun, Oct 05, 2008 at 02:56:03PM -0400, Adam Goode wrote:
> My life is about to get very busy (twins on the way), so I want to make  

Good luck :-)

> mlton -- optimizing compiler for Standard ML

I added myself to F9 and devel (not much interested in F8 at the
moment since it's about to go out of support).

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From rc040203 at freenet.de  Mon Oct  6 11:12:51 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 06 Oct 2008 13:12:51 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081006104842.GB2751@free.fr>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi> <1223277645.18676.2.camel@d2>
	<48E9DCE8.6050500@niemueller.de>  <20081006104842.GB2751@free.fr>
Message-ID: <1223291571.3564.1025.camel@beck.corsepiu.local>

On Mon, 2008-10-06 at 12:48 +0200, Patrice Dumas wrote:
> On Mon, Oct 06, 2008 at 11:39:52AM +0200, Tim Niemueller wrote:
> > 
> > That has been discussed during the review and the reasoning was that the
> > project chose that name and renaming it would only cause unexpected
> > hassles for people who install this software. Upstream chose that name,
> > so if we want that package we should stick to it, if only to allow users
> > to reproduce commands given in documentation, wikis, blogs etc.
> > Additionally your very repoquery shows that there are in fact no
> > conflicts, so why bother?
> > 
> > I also don't see a problem why binary in the package for which this
> > thread was initiated should be renamed. There is no trash command, it
> > provides functionality which clearly fits the name, so why the heck
> > should it be renamed? Just because someone might as well add such a
> > command later? It's like not using your roller skates to keep them in a
> > nice new condition, until you have grown out of them...
> 
> The issue is that many upstream don't care about using names that are
> not prone to future conflicts, and use generic names. In my opinion,
> generic names should be reserved to standardized programs (like
> sendmail, ls, ...). 

ACK.

> Upstream don't care and selfishly choose the name
> that suits them most, but at the distro level, and for the long-term, 
> I think that we should try to regulate a bit those namings such
> that projects don't take these precious names carelessly.
Right. In particular in cases where packages can easily be modified to
better suite into distribution (Think --program-prefix).

>  To put it otherwise, the generic names (like trash, player, record,
> convert, ...) and the short names (like ls, qpd, fjk, tgn...) are
> scarce and a first come first serve is certainly a bad way of choosing
> them.

ACK. Also consider there may exist applicable standards, which may
interfere on such common names and may force/overrule such upstream
choices.

>  In theory, upstream should think about those issues when choosing a
> name and avoid misusing these scarce words, but this is not what
> happens.
Well, we are having a review quality problem.

Ralf




From rawhide at fedoraproject.org  Mon Oct  6 11:51:46 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon,  6 Oct 2008 11:51:46 +0000 (UTC)
Subject: rawhide report: 20081006 changes
Message-ID: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>

New package mediawiki-imagemap
        The ImageMap extension for MediaWiki
New package php-laconica
        PHP tool for microblogging
New package vldocking
        A Java ??? docking system for JFC Swing applications
Updated Packages:

NetworkManager-pptp-0.7.0-0.11.svn4027.fc10
-------------------------------------------
* Sun Oct  5 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 1:0.7.0-11.svn4027
- Add pptp dependency (#465644)


abcm2ps-5.9.1-1.fc10
--------------------
* Sun Oct  5 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 5.9.1-1
- new release 5.9.1


expendable-0.0.4-2.fc10
-----------------------
* Sun Oct  5 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 0.0.4-2
- 0.0.4.  No longer need packing patch.


fakechroot-2.8-15.fc10
----------------------
* Sun Oct  5 18:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 2.8-15
- Fix getpeername/getsockname socklen initialization.


fakeroot-1.9.7-18.fc10
----------------------
* Fri Oct  3 18:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 1.9.7-18
- Update to 1.9.7.


freedink-1.08.20080920-4.fc10
-----------------------------
* Sun Oct  5 18:00:00 2008 Sylvain Beucler <beuc at beuc.net> - 1.08.20080920-4
- Use liberation-fonts in all distro versions


glibmm24-2.18.0-3.fc10
----------------------
* Sun Oct  5 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 2.18.0-3
- Patch error.h directly rather than error.hg

* Sun Oct  5 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 2.18.0-2
- Backport upstream fix that resolves HOST_NOT_FOUND
  symbol conflicts (GNOME #529496)


gstreamer-plugins-good-0.10.10-5.fc10
-------------------------------------
* Sun Oct  5 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 0.10.10-5
- Fix gst-plugins-good-0.10.9-libv4l.patch to also patch config.in and
  Makefile.in so that the libv4l code actually gets enabled for real this time
  and remove plenty of egg from face for not fixing this properly in 0.10.10-2
  (rh465599)
- Explicitly disable pulse plugin so the spec builds even if you
  have the pulse devel packages installed.


hunspell-ca-0.20081005-1.fc10
-----------------------------
* Sun Oct  5 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081005-1
- latest version


ibus-0.1.1.20081005-1.fc10
--------------------------
* Sun Oct  5 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081005-1
- Update to 0.1.1.20081005.


kernel-2.6.27-0.392.rc8.git7.fc10
---------------------------------
* Sun Oct  5 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- drm-fix-drm-mode-h.patch - fix drm mode .h header


libcanberra-0.10-1.fc10
-----------------------
* Mon Oct  6 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.10-1
- New version


linkage-0.2.0-3.fc10
--------------------
* Sun Oct  5 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.2.0-3
- Rebuild


ltsp-5.1.26-1.fc10
------------------
* Sun Oct  5 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.26-1
- Fix copying of mkinitrd config file within chroot

* Sun Oct  5 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.25-1
- Bug #462228 Prevent bogus mkinitrd config from landing on systems who
  accidentally install ltsp-client for no good reason. (Thanks John Ellson)
- Remove irrelevant plugins from package


mediawiki-1.13.2-41.fc10
------------------------
* Sun Oct  5 18:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 1.13.2-41
- Update to 1.13.2.


obex-data-server-0.3.99-2.fc10
------------------------------
* Mon Oct  6 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.99-2
- Update to rev 1998
- Use gdk-pixbuf instead of ImageMagick for BIP support


perl-DBIx-Class-0.08010-8.fc10
------------------------------
* Sun Oct  5 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.08010-8
- filter all prov/req from anything under _docdir
- note we still filter perl(DBD::Multi), at least until review bug bz#465690
  is completed...
- ...and perl(DBD::Pg) will always be filtered


pulseaudio-0.9.13-1.fc10
------------------------
* Mon Oct  6 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.9.13-1
- New release


renrot-1.1-0.3.rc3.fc10
-----------------------
* Mon Oct  6 18:00:00 2008 Andy Shevchenko <andy at smile.org.ua> - 1.1-0.3.rc3
- update to 1.1rc3
- change License to Artistic 2.0 accordingly to mainstream
- update URLs
- require (optional) Image::Magick


revisor-2.1.2-2.fc10
--------------------
* Sun Oct  5 18:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.1.2-2
- Fix anaconda removing splittree.py
- Latest rebuild
- Minor bugfixes (#344 pkgorder traceback)
- Add SELinux Check


scim-1.4.7-33.fc10
------------------
* Sun Oct  5 18:00:00 2008 Huang Peng <phuang at redhat.com> - 1.4.7-33
- Add ICON="/usr/share/scim/icons/trademark.png" in xinput-scim


sepostgresql-8.3.4-2.1077.fc10
------------------------------

slim-1.3.0-7.fc10
-----------------
* Sun Oct  5 18:00:00 2008 Anders F Bjorklund <afb at users.sourceforge.net> 1.3.0-7
- add compat req (#465631)


smart-1.1-56.fc10
-----------------
* Sun Oct  5 18:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net> - 1.1-56
- Update to 1.1.


xastir-1.9.4-4.fc10
-------------------
* Sun Oct  5 18:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.9.4-4
- misc cleanups


xdoclet-1.2.3-9.4.fc10
----------------------
* Sun Oct  5 18:00:00 2008 Matt Wringe <mwringe at redhat.com> - 0:1.2.3-9.4
- Update xdoclet-ant.not-required.patch to apply with fuzz=0.

* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0:1.2.3-9.3
- include /usr/share/doc/xdoclet-1.2.3 directory


Summary:
Added Packages: 3
Removed Packages: 0
Modified Packages: 26
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	gnuradio-3.1.2-2.fc9.i386 requires libcppunit-1.12.so.0
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2
	1:openoffice.org-langpack-ta_IN-3.0.0-9.2.fc10.i386 requires lohit-fonts-tamil
	publican-0.37-0.fc10.noarch requires lohit-fonts-tamil
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	syncevolution-0.7-3.fc10.i386 requires libcppunit-1.12.so.0



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	gnuradio-3.1.2-2.fc9.i386 requires libcppunit-1.12.so.0
	gnuradio-3.1.2-2.fc9.x86_64 requires libcppunit-1.12.so.0()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	syncevolution-0.7-3.fc10.x86_64 requires libcppunit-1.12.so.0()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	gnuradio-3.1.2-2.fc9.ppc requires libcppunit-1.12.so.0
	gnuradio-3.1.2-2.fc9.ppc64 requires libcppunit-1.12.so.0()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so
	stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so
	syncevolution-0.7-3.fc10.ppc requires libcppunit-1.12.so.0



Broken deps for ppc64
----------------------------------------------------------
	TurboGears-1.0.7-2.fc10.noarch requires python-decoratortools >= 0:1.4
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	gnuradio-3.1.2-2.fc9.ppc64 requires libcppunit-1.12.so.0()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit)
	mock-0.9.11-1.fc10.noarch requires python-decoratortools
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	python-peak-rules-0.5a1.dev-0.2569.fc10.noarch requires python-decoratortools >= 0:1.7
	python-peak-util-addons-0.6-1.fc10.noarch requires python-decoratortools >= 0:1.5
	python-peak-util-assembler-0.5-1.fc10.noarch requires python-decoratortools >= 0:1.2
	rt3-3.8.1-1.fc10.noarch requires perl(Locale::Maketext::Fuzzy)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	syncevolution-0.7-3.fc10.ppc64 requires libcppunit-1.12.so.0()(64bit)





From hughsient at gmail.com  Mon Oct  6 11:59:00 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 06 Oct 2008 12:59:00 +0100
Subject: Icons and relative path of comps icons
Message-ID: <1223294340.6012.61.camel@hughsie-laptop>

On the PackageKit mailing list we're discussing dynamic groups and icons
so that the full comps groups can be supported if the client wants the
same menus as in anaconda.

The exact methods and signals we are adding hasn't been decided yet, but
we are making progress as this needs to be cross compatible with all
distros and all group conventions.

It's been proposed we return a absolute path for icon names, which I
think is a bad idea. It does not allow the icons to be themed, and
doesn't seem portable between environments. Icons should be returned as
named icons rather than full paths.

The icons for fedora comps groups are shipped
into /usr/share/pixmaps/comps by the comps-extras package.

gnome-packagekit will by default look in /usr/share/icons/$foo and
also /usr/share/gnome-packagekit/icons/hicolor for named icons.

I really don't want to symlink everything in /usr/share/pixmaps/comps
to /usr/share/gnome-packagekit/icons in the gnome-packagekit rpm, as
kpackagekit won't be able to use these icons and it seems a bodge.

I don't think comps-extras should be installing
into /usr/share/icons/hicolor/24x24/categories as it's not a theme,
although this would fix a lot of problems.

Anyone got any ideas?

Richard.




From adam at spicenitz.org  Mon Oct  6 12:05:22 2008
From: adam at spicenitz.org (Adam Goode)
Date: Mon, 06 Oct 2008 08:05:22 -0400
Subject: looking for co-maintainers
In-Reply-To: <20081006104854.GA2241@amd.home.annexia.org>
References: <48E90DC3.5010709@spicenitz.org>
	<20081006104854.GA2241@amd.home.annexia.org>
Message-ID: <48E9FF02.8040108@spicenitz.org>

Richard W.M. Jones wrote:
> On Sun, Oct 05, 2008 at 02:56:03PM -0400, Adam Goode wrote:
>> My life is about to get very busy (twins on the way), so I want to make  
> 
> Good luck :-)
> 
>> mlton -- optimizing compiler for Standard ML
> 
> I added myself to F9 and devel (not much interested in F8 at the
> moment since it's about to go out of support).
> 
> Rich.
> 

Thanks! F9 + devel seems to be what everyone is doing.


Adam




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

From adam at spicenitz.org  Mon Oct  6 12:10:01 2008
From: adam at spicenitz.org (Adam Goode)
Date: Mon, 06 Oct 2008 08:10:01 -0400
Subject: looking for co-maintainers
In-Reply-To: <599059470810051933o34f88c90g3ca6e85b6e651b3e@mail.gmail.com>
References: <48E90DC3.5010709@spicenitz.org> <gcb8et$7b6$1@ger.gmane.org>
	<599059470810051933o34f88c90g3ca6e85b6e651b3e@mail.gmail.com>
Message-ID: <48EA0019.1020401@spicenitz.org>

Roopesh Majeti wrote:
> 1) minirpc
> 2) htmldoc [ if available ].
>  
> I am a newebie member of fedora dev, but could not contribute till now, 
> due to my professional work load. Guess this would be a good chance, if 
> given.
>  
> Please let me know, if any concerns. If possible, please let me know the 
> wiki link for the same, so that i can start.
>  

Hi,

Are you a sponsored maintainer? You'll need to be sponsored to comaintain.
http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored

If so, please review this:
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility

And then follow these instructions:
http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb#How_do_I_sign_up_for_a_package.3F


Thanks,

Adam


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

From rc040203 at freenet.de  Mon Oct  6 12:15:10 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 06 Oct 2008 14:15:10 +0200
Subject: rawhide report: 20081006 changes
In-Reply-To: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
Message-ID: <1223295310.3564.1037.camel@beck.corsepiu.local>

On Mon, 2008-10-06 at 11:51 +0000, Rawhide Report wrote:

> Broken deps for ppc64
> ----------------------------------------------------------

> 	rt3-3.8.1-1.fc10.noarch requires perl(Locale::Maketext::Fuzzy)

What is going on here?

perl-Locale-Maketext-Fuzzy is a noarch package and should be available
on all architectures.

It also is present in:
http://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/os/Packages/perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch.rpm

Examining the contents also shows this package is providing what the
report is complaining above:

# rpm -q --provides -p perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch.rpm 
warning: perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch.rpm: Header V3 DSA
signature: NOKEY, key ID 0b86274e
perl(Locale::Maketext::Fuzzy) = 0.10
perl-Locale-Maketext-Fuzzy = 0.10-2.fc9

Ralf




From kraxel at redhat.com  Mon Oct  6 12:33:12 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Mon, 06 Oct 2008 14:33:12 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <1223043625.18687.19.camel@rosebud>
References: <48E48E04.1080906@students.iiit.ac.in>	<48E5AD07.2030508@googlemail.com>
	<48E5EC86.8050508@ru.bir.ru>	<1223040898.18687.17.camel@rosebud>	<20081003071728.1a69b725@infradead.org>
	<1223043625.18687.19.camel@rosebud>
Message-ID: <48EA0588.9080802@redhat.com>

seth vidal wrote:
> The original complaint here is that the gnome proxy setting doesn't seem
> to set this as well.
> 
> B/c yum does follow http_proxy env variable.

It ignores no_proxy though ...

cheers,
  Gerd



From lokthare at gmail.com  Mon Oct  6 13:07:44 2008
From: lokthare at gmail.com (=?ISO-8859-1?Q?Jean-Fran=E7ois?= Martin)
Date: Mon, 06 Oct 2008 15:07:44 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081006021809.GA24675@jadzia.bu.edu>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<1223169402.10547.3.camel@abel> <48E8F373.20101@behdad.org>
	<48E932CC.8050607@andreafrancia.it> <48E933C2.9020608@behdad.org>
	<48E93B5A.5000302@andreafrancia.it>
	<20081006021809.GA24675@jadzia.bu.edu>
Message-ID: <1223298464.2782.6.camel@abel>

Le dimanche 05 octobre 2008 ? 22:18 -0400, Matthew Miller a ?crit :
> On Mon, Oct 06, 2008 at 12:10:34AM +0200, Andrea Francia wrote:
> >> Eh, thought it's obvious.  One can type "trash" then use tab completion to see
> >> what commands are available.  
> > So the commands names could became:
> > - trashcan-put
> > - trashcan-empty
> > - trashcan-list
> > - trashcan-restore
> > My English is not so good, is the 'trashcan-put' a good choice?
> 
> It's not as good as just 'trash'.
> 
> Are there multiple "trash" programs out there? Is this likely to be a real
> problem?

There is another program that allow to manage the trash from FreeDesktop
spec. but i can't find it, and it doesn't use the "trash" command.
-- 
Jean-Fran?ois Martin
https://fedoraproject.org/wiki/User:Lokthare
https://lokthare.wordpress.com/
GPG: 3876DB6B
-------------- 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/20081006/df91d7bc/attachment.sig>

From mike at miketc.net  Mon Oct  6 13:33:19 2008
From: mike at miketc.net (Mike Chambers)
Date: Mon, 06 Oct 2008 08:33:19 -0500
Subject: rsyslog errors on rawhide
Message-ID: <1223299999.2802.9.camel@scrappy.miketc.net>

I keep seeing the below error when anacron is running..

/etc/cron.daily/epylog.cron:

Invalid syslog format string in /var/log/secure: rsyslogd:  [origin
software="rsyslogd" swVersion="3.21.3" x-pid="1779"
x-info="http://www.rsyslog.com"] exiting on signal 15.

Invalid syslog format string in /var/log/secure: rsyslogd:  [origin
software="rsyslogd" swVersion="3.21.3" x-pid="1774"
x-info="http://www.rsyslog.com"] restart

I see the error a couple of times in my /var/log/secure file.

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From icon at fedoraproject.org  Mon Oct  6 13:40:47 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Mon, 6 Oct 2008 09:40:47 -0400
Subject: rsyslog errors on rawhide
In-Reply-To: <1223299999.2802.9.camel@scrappy.miketc.net>
References: <1223299999.2802.9.camel@scrappy.miketc.net>
Message-ID: <f8f6300f0810060640j1e28de40i9afc65121f475e3f@mail.gmail.com>

On Mon, Oct 6, 2008 at 9:33 AM, Mike Chambers <mike at miketc.net> wrote:
> I keep seeing the below error when anacron is running..
>
> /etc/cron.daily/epylog.cron:
>
> Invalid syslog format string in /var/log/secure: rsyslogd:  [origin
> software="rsyslogd" swVersion="3.21.3" x-pid="1779"
> x-info="http://www.rsyslog.com"] exiting on signal 15.
>
> Invalid syslog format string in /var/log/secure: rsyslogd:  [origin
> software="rsyslogd" swVersion="3.21.3" x-pid="1774"
> x-info="http://www.rsyslog.com"] restart
>
> I see the error a couple of times in my /var/log/secure file.

Yeah, this is new with rsyslog. I don't have an immediate suggestion
on how to fix this, unfortunately -- I'll try to patch up epylog for
F10.

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From skvidal at fedoraproject.org  Mon Oct  6 13:49:10 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 06 Oct 2008 09:49:10 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48EA0588.9080802@redhat.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>	<20081003071728.1a69b725@infradead.org>
	<1223043625.18687.19.camel@rosebud>  <48EA0588.9080802@redhat.com>
Message-ID: <1223300950.14054.0.camel@rosebud>

On Mon, 2008-10-06 at 14:33 +0200, Gerd Hoffmann wrote:
> seth vidal wrote:
> > The original complaint here is that the gnome proxy setting doesn't seem
> > to set this as well.
> > 
> > B/c yum does follow http_proxy env variable.
> 
> It ignores no_proxy though ...


please file a bug about that.

thanks,
-sv




From james at fedoraproject.org  Mon Oct  6 14:04:12 2008
From: james at fedoraproject.org (James Antill)
Date: Mon, 06 Oct 2008 10:04:12 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48EA0588.9080802@redhat.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>	<20081003071728.1a69b725@infradead.org>
	<1223043625.18687.19.camel@rosebud>  <48EA0588.9080802@redhat.com>
Message-ID: <1223301852.9470.137.camel@code.and.org>

On Mon, 2008-10-06 at 14:33 +0200, Gerd Hoffmann wrote:
> seth vidal wrote:
> > The original complaint here is that the gnome proxy setting doesn't seem
> > to set this as well.
> > 
> > B/c yum does follow http_proxy env variable.
> 
> It ignores no_proxy though ...

 Actually, it doesn't, it's just that the API for
urlgrabber/urilib2/etc. only have "no proxy configured" ... not "no
proxy desired" options.
 In theory we could also unset os.environ, but it should just be fixed
when we move to curl

-- 
James Antill <james at fedoraproject.org>
Fedora



From dwalsh at redhat.com  Mon Oct  6 14:05:00 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 06 Oct 2008 10:05:00 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <20081004153856.22483543@ludwig-alpha.unil.ch>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<20081003091511.73410983@ludwig-alpha.unil.ch>	<48E61B1C.70603@redhat.com>
	<20081004153856.22483543@ludwig-alpha.unil.ch>
Message-ID: <48EA1B0C.8050702@redhat.com>

Christian Iseli wrote:
> On Fri, 03 Oct 2008 09:16:12 -0400, Daniel J Walsh wrote:
>> Well first this is not a copy it is a move.  The problem here is the
>> mv command is attempting to retain the file context of
>> gr.078212.108v2.pdf, if you did a cp it would work.
> 
> IIRC, cp failed too.
> 
>> What avc are you seeing?
> 
> Below are those I used to feed to audit2allow
> 
> Cheers,
> 					Christian
> 
> host=Rivendell type=AVC msg=audit(1222961359.881:97): avc: denied { associate }for pid=3116 comm="mv" name="gr.078212.108v2.pdf" scontext=unconfined_u:object_r:user_home_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
> host=Rivendell type=SYSCALL msg=audit(1222961359.881:97): arch=40000003 syscall=5 success=no exit=-13 a0=92aa3f0 a1=80c1 a2=180 a3=80c1 items=0 ppid=2778 pid=3116 auid=2890 uid=2890 gid=2890 euid=2890 suid=2890 fsuid=2890 egid=2890 sgid=2890 fsgid=2890 tty=pts2 ses=2 comm="mv" exe="/bin/mv" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> host=Rivendell type=AVC msg=audit(1223001293.211:917): avc: denied { getattr } for pid=5913 comm="updatedb" path="/home/chris/VMShared" dev=vboxsf ino=0 scontext=system_u:system_r:locate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
> host=Rivendell type=SYSCALL msg=audit(1223001293.211:917): arch=40000003 syscall=196 success=no exit=-13 a0=9a1f6b5 a1=bfcf70a8 a2=9e4ff4 a3=9a1f6b5 items=0 ppid=5907 pid=5913 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=199 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0-s0:c0.c1023 key=(null)
> host=Rivendell type=AVC msg=audit(1223001183.679:916): avc: denied { getattr } for pid=5580 comm="df" name="/" dev=vboxsf ino=0 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem
> host=Rivendell type=SYSCALL msg=audit(1223001183.679:916): arch=40000003 syscall=268 success=no exit=-13 a0=86b24f0 a1=54 a2=bf9c0958 a3=0 items=0 ppid=5578 pid=5580 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)ses=199 comm="df" exe="/bin/df" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)
> 
I don't know what vmshared is> It is beling labeled as a unlabeled_t
which means the kernel policy does not know what this file system is.

If you run restorecon -R -v ~/

Does it change the context on this file system?






From dwalsh at redhat.com  Mon Oct  6 14:05:23 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 06 Oct 2008 10:05:23 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <1223108738.9328.40.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
Message-ID: <48EA1B23.1090708@redhat.com>

Jon Masters wrote:
> On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:
> 
>>> $ mount -o loop Fedora-9-i386-DVD.iso /mnt
>>>
>>> And then one might legitimately expect to be able to copy the content
>>> of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
>>> suppose that one is running SELinux in enforcing mode, then this will
>>> fail because the contexts differ in this operation. Then, one will
>>> likely quickly become severely annoyed and frustrated with SELinux,
>>> simply setting it permissive for the duration of the operation...
> 
>> Why would the copy fail?  cp should just work and set the files to the
>> context of the destination directory.  If this fails it is a bug.
> 
> Ok, so there's a bug there then. Copying files from within an ISO image
> was kind of the last straw in my willingness to keep SELinux enabled. It
> hinders me at almost every turn from doing useful things with a Linux
> desktop - I'm constantly amazed that Fedora persists in defaulting it
> enabled, but that's a whole other rant.
> 
> Jon.
> 
What error messages did you see when you did the cp command?



From dwalsh at redhat.com  Mon Oct  6 14:05:38 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 06 Oct 2008 10:05:38 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <1223108738.9328.40.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
Message-ID: <48EA1B32.1010008@redhat.com>

Jon Masters wrote:
> On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:
> 
>>> $ mount -o loop Fedora-9-i386-DVD.iso /mnt
>>>
>>> And then one might legitimately expect to be able to copy the content
>>> of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
>>> suppose that one is running SELinux in enforcing mode, then this will
>>> fail because the contexts differ in this operation. Then, one will
>>> likely quickly become severely annoyed and frustrated with SELinux,
>>> simply setting it permissive for the duration of the operation...
> 
>> Why would the copy fail?  cp should just work and set the files to the
>> context of the destination directory.  If this fails it is a bug.
> 
> Ok, so there's a bug there then. Copying files from within an ISO image
> was kind of the last straw in my willingness to keep SELinux enabled. It
> hinders me at almost every turn from doing useful things with a Linux
> desktop - I'm constantly amazed that Fedora persists in defaulting it
> enabled, but that's a whole other rant.
> 
> Jon.
> 
What avc messages I should say?



From mschwendt at gmail.com  Mon Oct  6 14:22:09 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 6 Oct 2008 16:22:09 +0200
Subject: rawhide report: 20081006 changes
In-Reply-To: <1223295310.3564.1037.camel@beck.corsepiu.local>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
Message-ID: <20081006162209.9984d1cd.mschwendt@gmail.com>

On Mon, 06 Oct 2008 14:15:10 +0200, Ralf Corsepius wrote:

> On Mon, 2008-10-06 at 11:51 +0000, Rawhide Report wrote:
> 
> > Broken deps for ppc64
> > ----------------------------------------------------------
> 
> > 	rt3-3.8.1-1.fc10.noarch requires perl(Locale::Maketext::Fuzzy)
> 
> What is going on here?
> 
> perl-Locale-Maketext-Fuzzy is a noarch package and should be available
> on all architectures.
> 
> It also is present in:
> http://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/os/Packages/perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch.rpm

Compare with the 20081005 report, where this was not listed as a broken
dep. Package is not listed as removed and wasn't updated in this report
either. First I thought probably some other package introduced bad
Obsoletes, but "python-decoratortools" is also reported as breaking
deps although it is present:

    TurboGears-1.0.7-2.fc10.noarch requires python-decoratortools >= 0:1.4
	mock-0.9.11-1.fc10.noarch requires python-decoratortools
	python-peak-rules-0.5a1.dev-0.2569.fc10.noarch requires python-decoratortools >= 0:1.7
	python-peak-util-addons-0.6-1.fc10.noarch requires python-decoratortools >= 0:1.5
	python-peak-util-assembler-0.5-1.fc10.noarch requires python-decoratortools >= 0:1.2

Package is there:

http://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/os/Packages/python-decoratortools-1.7-1.fc9.noarch.rpm



From opensource at till.name  Mon Oct  6 14:39:55 2008
From: opensource at till.name (Till Maas)
Date: Mon, 6 Oct 2008 16:39:55 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <1223300950.14054.0.camel@rosebud>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48EA0588.9080802@redhat.com> <1223300950.14054.0.camel@rosebud>
Message-ID: <200810061640.07926.opensource@till.name>

On Monday 06 October 2008 15:49:10 seth vidal wrote:
> On Mon, 2008-10-06 at 14:33 +0200, Gerd Hoffmann wrote:
> > seth vidal wrote:
> > > The original complaint here is that the gnome proxy setting doesn't
> > > seem to set this as well.
> > >
> > > B/c yum does follow http_proxy env variable.
> >
> > It ignores no_proxy though ...
>
> please file a bug about that.

I was already mentioned here, which is a bug request about yum ignoring 
proxy=_none_

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

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/20081006/0ce66675/attachment.sig>

From kevin at scrye.com  Mon Oct  6 15:06:25 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Mon, 6 Oct 2008 09:06:25 -0600
Subject: Cannot recompile x86_64 kernel on installed F9 i686
In-Reply-To: <5f6f8c5f0810060123s35930ddxc46ba1003c52b722@mail.gmail.com>
References: <5f6f8c5f0810060123s35930ddxc46ba1003c52b722@mail.gmail.com>
Message-ID: <20081006090625.076dcc2f@ohm.scrye.com>

On Mon, 6 Oct 2008 10:23:12 +0200
joshuacov at googlemail.com ("Joshua C.") wrote:

> I tried to recompile the x86_64 version of the F10beta kernel on my F9
> i686. And this is the error message I got

You cannot do that.

You would need a cross compiler (no idea if thats possible in this
case), or a real x86_64 processor, or a x86_64 compiler running under
something like qemu. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/5cf2a620/attachment.sig>

From kraxel at redhat.com  Mon Oct  6 15:06:58 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Mon, 06 Oct 2008 17:06:58 +0200
Subject: Uniform Proxy Settings
In-Reply-To: <1223301852.9470.137.camel@code.and.org>
References: <48E48E04.1080906@students.iiit.ac.in>	<48E5AD07.2030508@googlemail.com>
	<48E5EC86.8050508@ru.bir.ru>	<1223040898.18687.17.camel@rosebud>	<20081003071728.1a69b725@infradead.org>	<1223043625.18687.19.camel@rosebud>
	<48EA0588.9080802@redhat.com>
	<1223301852.9470.137.camel@code.and.org>
Message-ID: <48EA2992.2030709@redhat.com>

James Antill wrote:
> On Mon, 2008-10-06 at 14:33 +0200, Gerd Hoffmann wrote:
>> seth vidal wrote:
>>> The original complaint here is that the gnome proxy setting doesn't seem
>>> to set this as well.
>>>
>>> B/c yum does follow http_proxy env variable.
>> It ignores no_proxy though ...
> 
>  Actually, it doesn't, it's just that the API for
> urlgrabber/urilib2/etc. only have "no proxy configured" ... not "no
> proxy desired" options.
>  In theory we could also unset os.environ, but it should just be fixed
> when we move to curl

unset doesn't cut it.  no_proxy isn't about disabling proxying
altogether, but about disabling the proxy for certain domains.

Usually you stick there "localhost,$localdomain".  I also have
redhat.com listed there.  The box running squid has no vpn access to the
internal network, thus internal repos are not accessible via proxy ...

cheers,
  Gerd



From jarod at redhat.com  Mon Oct  6 15:08:59 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Mon, 6 Oct 2008 11:08:59 -0400
Subject: Cannot recompile x86_64 kernel on installed F9 i686
In-Reply-To: <5f6f8c5f0810060123s35930ddxc46ba1003c52b722@mail.gmail.com>
References: <5f6f8c5f0810060123s35930ddxc46ba1003c52b722@mail.gmail.com>
Message-ID: <200810061108.59329.jarod@redhat.com>

On Monday 06 October 2008 04:23:12 Joshua C. wrote:
> I tried to recompile the x86_64 version of the F10beta kernel on my F9
> i686. And this is the error message I got
[...]
> scripts/mod/empty.c:1: error: code model 'kernel' not supported in the
> 32 bit mode
> scripts/mod/empty.c:1: sorry, unimplemented: 64-bit mode not compiled in
> make[2]: *** [scripts/mod/empty.o] Error 1
> make[1]: *** [scripts/mod] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [scripts] Error 2
[...]
> Recompiling the i686 kernel works fine but not the x86_64. Tried also
> the lastes kernel in koji and got the same error. How to recompile it?

x86_64 is backwards-compatible with i686. i686 is not forwards-compatible with 
x86_64. Might be doable with a cross-compiler env., but certainly not doable 
the way you're trying to do it.

-- 
Jarod Wilson
jarod at redhat.com



From tim at niemueller.de  Mon Oct  6 15:09:36 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Mon, 06 Oct 2008 17:09:36 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081006104842.GB2751@free.fr>
References: <1223161806.9727.8.camel@abel>
	<20081004233620.GB2670@free.fr>	<200810051219.31882.Juha.Tuomala@iki.fi>	<1223277645.18676.2.camel@d2>
	<48E9DCE8.6050500@niemueller.de> <20081006104842.GB2751@free.fr>
Message-ID: <48EA2A30.2070903@niemueller.de>

Patrice Dumas schrieb:
>> I also don't see a problem why binary in the package for which this
>> thread was initiated should be renamed. There is no trash command, it
>> provides functionality which clearly fits the name, so why the heck
>> should it be renamed? Just because someone might as well add such a
>> command later? It's like not using your roller skates to keep them in a
>> nice new condition, until you have grown out of them...
> 
> The issue is that many upstream don't care about using names that are
> not prone to future conflicts, and use generic names. In my opinion,
> generic names should be reserved to standardized programs (like
> sendmail, ls, ...). Upstream don't care and selfishly choose the name
> [...]

In general, I agree that a good naming scheme helps in keeping things
clean and simple. We should communicate this so that upcoming projects
choose wisely from the very beginning and can ask existing projects to
consider such a change. However, it is not the duty of an upstream
project to foresee any possible conflict or animosity in this regard.

I can understand that the trash tool chose that command name. It makes
sense, it's short and clear, and for a command line tool that's
something that makes users use it -- or not if done badly. It is likely
that if another application provides another trash command the
functionality will be equal or similar. Then it would be a matter for
the alternatives system to sort this out. In general this is the very
reason why the alternatives system is there. In case of the trash
command the thing that probably makes many feel uncomfortable is that
there is no such de-facto standard like sendmail, yet. And thus one
might bet on the wrong horse.

The allegation projects choose the name "selfishly" is besides the
point. An upstream project does not and should not have to please all or
even "only" the major distros. Again, if upstream projects act careful
and have this in mind, perfect, and let us encourage them to do so. But
now renaming it in a package and thus diverting only in this distro is
not a good idea.
In the case of player the name was chosen after a Shakespeare citation
(cf.
http://playerstage.sourceforge.net/wiki/Basic_FAQ#Why_are_Player_and_Stage_.28etc.29_so_named.3F)
which is related to the functionality of the programs. So saying they
chose it selfishly as if they did it to eliminate competition or
whatever doesn't sound convincing, and they definitely didn't want to
block media players or whatever I'm sure.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From kevin at scrye.com  Mon Oct  6 15:10:34 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Mon, 6 Oct 2008 09:10:34 -0600
Subject: procedure for renaming a package
In-Reply-To: <9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
Message-ID: <20081006091034.5176d484@ohm.scrye.com>

On Sat, 4 Oct 2008 23:09:14 -0700
jkeating at j2solutions.net ("Jesse Keating") wrote:

> Renaming a package is just bringing in the new package, getting it
> reviewed, particularly for correct Provides/Obsoletes, and then
> requesting that the old named package be removed.

Note, that I don't think we should remove the old package, we should
simply follow the normal end of life procedure for it. 

Then, people looking for it under the old name will see a dead.package
in cvs and that will point them to the new package. History will be
preserved, etc. 

I guess we should have a clear guideline on this. I will see about
submitting one to the packaging folks. 

> Jes

kevin

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

From james at fedoraproject.org  Mon Oct  6 15:22:53 2008
From: james at fedoraproject.org (James Antill)
Date: Mon, 06 Oct 2008 11:22:53 -0400
Subject: Uniform Proxy Settings
In-Reply-To: <48EA2992.2030709@redhat.com>
References: <48E48E04.1080906@students.iiit.ac.in>
	<48E5AD07.2030508@googlemail.com> <48E5EC86.8050508@ru.bir.ru>
	<1223040898.18687.17.camel@rosebud>	<20081003071728.1a69b725@infradead.org>
	<1223043625.18687.19.camel@rosebud> <48EA0588.9080802@redhat.com>
	<1223301852.9470.137.camel@code.and.org> <48EA2992.2030709@redhat.com>
Message-ID: <1223306573.9470.141.camel@code.and.org>

On Mon, 2008-10-06 at 17:06 +0200, Gerd Hoffmann wrote:
> James Antill wrote:
> > On Mon, 2008-10-06 at 14:33 +0200, Gerd Hoffmann wrote:
> >> seth vidal wrote:
> >>> The original complaint here is that the gnome proxy setting doesn't seem
> >>> to set this as well.
> >>>
> >>> B/c yum does follow http_proxy env variable.
> >> It ignores no_proxy though ...
> > 
> >  Actually, it doesn't, it's just that the API for
> > urlgrabber/urilib2/etc. only have "no proxy configured" ... not "no
> > proxy desired" options.
> >  In theory we could also unset os.environ, but it should just be fixed
> > when we move to curl
> 
> unset doesn't cut it.  no_proxy isn't about disabling proxying
> altogether, but about disabling the proxy for certain domains.
> 
> Usually you stick there "localhost,$localdomain".  I also have
> redhat.com listed there.  The box running squid has no vpn access to the
> internal network, thus internal repos are not accessible via proxy ...

 Ahh, right ... that no_proxy support (called ignore_hosts in GNOME).
Yeh, as Seth said, open a BZ against python-urlgrabber (but it'll have
to wait until the above fix is there, obviously).

-- 
James Antill <james at fedoraproject.org>
Fedora



From joshuacov at googlemail.com  Mon Oct  6 15:24:07 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 6 Oct 2008 17:24:07 +0200
Subject: Cannot recompile x86_64 kernel on installed F9 i686
In-Reply-To: <200810061108.59329.jarod@redhat.com>
References: <5f6f8c5f0810060123s35930ddxc46ba1003c52b722@mail.gmail.com>
	<200810061108.59329.jarod@redhat.com>
Message-ID: <5f6f8c5f0810060824o219835fag13ad09493da189c@mail.gmail.com>

2008/10/6 Jarod Wilson <jarod at redhat.com>:
> On Monday 06 October 2008 04:23:12 Joshua C. wrote:
>> I tried to recompile the x86_64 version of the F10beta kernel on my F9
>> i686. And this is the error message I got
> [...]
>> scripts/mod/empty.c:1: error: code model 'kernel' not supported in the
>> 32 bit mode
>> scripts/mod/empty.c:1: sorry, unimplemented: 64-bit mode not compiled in
>> make[2]: *** [scripts/mod/empty.o] Error 1
>> make[1]: *** [scripts/mod] Error 2
>> make[1]: *** Waiting for unfinished jobs....
>> make: *** [scripts] Error 2
> [...]
>> Recompiling the i686 kernel works fine but not the x86_64. Tried also
>> the lastes kernel in koji and got the same error. How to recompile it?
>
> x86_64 is backwards-compatible with i686. i686 is not forwards-compatible with
> x86_64. Might be doable with a cross-compiler env., but certainly not doable
> the way you're trying to do it.
>
> --
> Jarod Wilson
> jarod at redhat.com
>
 I have a x86_64 processor (Turion 64 X2 TL-60) but I've installed the
x86 version of fedora. Any ideas how is this going to work with qemu?
What should I install? Any cross-compilers?



From jarod at redhat.com  Mon Oct  6 15:45:49 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Mon, 6 Oct 2008 11:45:49 -0400
Subject: Cannot recompile x86_64 kernel on installed F9 i686
In-Reply-To: <5f6f8c5f0810060824o219835fag13ad09493da189c@mail.gmail.com>
References: <5f6f8c5f0810060123s35930ddxc46ba1003c52b722@mail.gmail.com>
	<200810061108.59329.jarod@redhat.com>
	<5f6f8c5f0810060824o219835fag13ad09493da189c@mail.gmail.com>
Message-ID: <200810061145.49122.jarod@redhat.com>

On Monday 06 October 2008 11:24:07 Joshua C. wrote:
> 2008/10/6 Jarod Wilson <jarod at redhat.com>:
> > On Monday 06 October 2008 04:23:12 Joshua C. wrote:
> >> I tried to recompile the x86_64 version of the F10beta kernel on my F9
> >> i686. And this is the error message I got
> >
> > [...]
> >
> >> scripts/mod/empty.c:1: error: code model 'kernel' not supported in the
> >> 32 bit mode
> >> scripts/mod/empty.c:1: sorry, unimplemented: 64-bit mode not compiled in
> >> make[2]: *** [scripts/mod/empty.o] Error 1
> >> make[1]: *** [scripts/mod] Error 2
> >> make[1]: *** Waiting for unfinished jobs....
> >> make: *** [scripts] Error 2
> >
> > [...]
> >
> >> Recompiling the i686 kernel works fine but not the x86_64. Tried also
> >> the lastes kernel in koji and got the same error. How to recompile it?
> >
> > x86_64 is backwards-compatible with i686. i686 is not forwards-compatible
> > with x86_64. Might be doable with a cross-compiler env., but certainly
> > not doable the way you're trying to do it.
> >
>
>  I have a x86_64 processor (Turion 64 X2 TL-60) but I've installed the
> x86 version of fedora.

The 32-bit compiler can't build 64-bit binaries. Doesn't matter that your cpu 
is 64-bit if you're running it in 32-bit mode. Apparently, the 32-bit compiler 
*can* somehow be made to build 64-bit binaries too, but the Fedora gcc isn't 
set up for it.

> Any ideas how is this going to work with qemu?

Very slowly?

> What should I install? Any cross-compilers?

I'd just install x86_64 Fedora. Not aware of anyone packaging a cross-compiler 
for x86_64 builds on i686. Most people just run x86_64 if they want to build 
both x86_64 and i686.

-- 
Jarod Wilson
jarod at redhat.com



From jkeating at redhat.com  Mon Oct  6 16:01:43 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 09:01:43 -0700
Subject: procedure for renaming a package
In-Reply-To: <20081006091034.5176d484@ohm.scrye.com>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081006091034.5176d484@ohm.scrye.com>
Message-ID: <1223308903.9987.25.camel@luminos.localdomain>

On Mon, 2008-10-06 at 09:10 -0600, Kevin Fenzi wrote:
> 
> Note, that I don't think we should remove the old package, we should
> simply follow the normal end of life procedure for it. 
> 
> Then, people looking for it under the old name will see a dead.package
> in cvs and that will point them to the new package. History will be
> preserved, etc. 

That's what I meant by 'removing' it.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/0cbfcc51/attachment.sig>

From pertusus at free.fr  Mon Oct  6 16:06:27 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 6 Oct 2008 18:06:27 +0200
Subject: procedure for renaming a package
In-Reply-To: <20081006091034.5176d484@ohm.scrye.com>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081006091034.5176d484@ohm.scrye.com>
Message-ID: <20081006160627.GD2751@free.fr>

On Mon, Oct 06, 2008 at 09:10:34AM -0600, Kevin Fenzi wrote:
> On Sat, 4 Oct 2008 23:09:14 -0700
> jkeating at j2solutions.net ("Jesse Keating") wrote:
> 
> > Renaming a package is just bringing in the new package, getting it
> > reviewed, particularly for correct Provides/Obsoletes, and then
> > requesting that the old named package be removed.
> 
> Note, that I don't think we should remove the old package, we should
> simply follow the normal end of life procedure for it. 

Indeed, and I think that that part of the procedure is already correctly
documented in
http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife

How to create th enew package is undocumented, however if it is a
regular review, it shouldn't be hard to document it.

--
Pat



From rc040203 at freenet.de  Mon Oct  6 16:12:45 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 06 Oct 2008 18:12:45 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48EA2A30.2070903@niemueller.de>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>	<1223277645.18676.2.camel@d2>
	<48E9DCE8.6050500@niemueller.de> <20081006104842.GB2751@free.fr>
	<48EA2A30.2070903@niemueller.de>
Message-ID: <1223309565.3564.1061.camel@beck.corsepiu.local>

On Mon, 2008-10-06 at 17:09 +0200, Tim Niemueller wrote:

> The allegation projects choose the name "selfishly" is besides the
> point. An upstream project does not and should not have to please all or
> even "only" the major distros.
A careful upstream can not avoid to do so, and a careful package
maintainer must do so - In case of "player", both failed.

>  Again, if upstream projects act careful
> and have this in mind, perfect, and let us encourage them to do so. But
> now renaming it in a package and thus diverting only in this distro is
> not a good idea.
> In the case of player the name was chosen after a Shakespeare citation
> (cf.
> http://playerstage.sourceforge.net/wiki/Basic_FAQ#Why_are_Player_and_Stage_.28etc.29_so_named.3F)
> which is related to the functionality of the programs. So saying they
> chose it selfishly as if they did it to eliminate competition or
> whatever doesn't sound convincing, and they definitely didn't want to
> block media players or whatever I'm sure.
A matter of perspective: It's only the fact that this package so far had
not been of any importance, which had let this upstream get away with
their choice. They jumped into the gap, conscious, more careful
upstreams had left open.




From jkeating at redhat.com  Mon Oct  6 16:12:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 09:12:41 -0700
Subject: pulse-rt by default?
In-Reply-To: <1223259624.12064.13.camel@perihelion.int.jonmasters.org>
References: <1223252976.12064.2.camel@perihelion.int.jonmasters.org>
	<20081006004846.GA13327@tango.0pointer.de>
	<20081005175636.2d6bd8e3@infradead.org>
	<1223259624.12064.13.camel@perihelion.int.jonmasters.org>
Message-ID: <1223309561.9987.26.camel@luminos.localdomain>

On Sun, 2008-10-05 at 22:20 -0400, Jon Masters wrote:
> It's not a security issue if you're on a single user desktop/laptop, and
> therefore something that could be configured up during installation. One
> idea I had was to suggest having install "profiles" available - I'd love
> to have an anaconda option I can click that will:
> 
> * Add me to sudoers automatically (first thing I do on every Fedora/RHEL
> system, and the most annoying thing missing from a standard install)
> * Add me to various groups useful to desktop self-admin, etc.
> * (Disable SELinux policy with a vengeance :P)

Most of these require a user already created, which would mean this
should go in Firstboot instead.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/532a827a/attachment.sig>

From paul at city-fan.org  Mon Oct  6 16:19:16 2008
From: paul at city-fan.org (Paul Howarth)
Date: Mon, 06 Oct 2008 17:19:16 +0100
Subject: proposal for make help chain-build text
In-Reply-To: <20081004170238.GA31243@free.fr>
References: <20080928122103.GA2728@free.fr>
	<20081003083131.GC3270@free.fr>	<48E5D9AA.9060505@city-fan.org>
	<20081004170238.GA31243@free.fr>
Message-ID: <48EA3A84.7020405@city-fan.org>

Patrice Dumas wrote:
> On Fri, Oct 03, 2008 at 09:36:58AM +0100, Paul Howarth wrote:
>> Test looks good to me, and certainly explains things better than the  
>> existing text.
> 
> Can you apply it?

I don't think I have any higher commit privileges than you do? Or was 
the question addressed to the infrastructure team?

Paul.



From jkeating at redhat.com  Mon Oct  6 16:20:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 09:20:41 -0700
Subject: rawhide report: 20081006 changes
In-Reply-To: <20081006162209.9984d1cd.mschwendt@gmail.com>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
Message-ID: <1223310041.9987.28.camel@luminos.localdomain>

On Mon, 2008-10-06 at 16:22 +0200, Michael Schwendt wrote:
> Compare with the 20081005 report, where this was not listed as a broken
> dep. Package is not listed as removed and wasn't updated in this report
> either. First I thought probably some other package introduced bad
> Obsoletes, but "python-decoratortools" is also reported as breaking
> deps although it is present:
> 
>     TurboGears-1.0.7-2.fc10.noarch requires python-decoratortools >= 0:1.4
>         mock-0.9.11-1.fc10.noarch requires python-decoratortools
>         python-peak-rules-0.5a1.dev-0.2569.fc10.noarch requires python-decoratortools >= 0:1.7
>         python-peak-util-addons-0.6-1.fc10.noarch requires python-decoratortools >= 0:1.5
>         python-peak-util-assembler-0.5-1.fc10.noarch requires python-decoratortools >= 0:1.2
> 
> Package is there:
> 
> http://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/os/Packages/python-decoratortools-1.7-1.fc9.noarch.rpm

This seems to be from a bug we've been chasing in createrepo for a
while, at least in the way that we use it to make rawhide.

Error Packages/perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch.rpm: No
Package ID found for package
perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch, not going to add it
Error Packages/lohit-fonts-tamil-2.3.1-1.fc10.noarch.rpm: No Package ID found for package lohit-fonts-tamil-2.3.1-1.fc10.noarch, not going to add it
Error Packages/python-decoratortools-1.7-1.fc9.noarch.rpm: No Package ID found for package python-decoratortools-1.7-1.fc9.noarch, not going to add it

Those are the error messages we get from createrepo, so those packages
just don't make it into the repodata, which trips the spam-o-matic
script.  The problem is that it's not easily reproducible, it's not
always the same packages, and it doesn't always happen.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/70a386d0/attachment.sig>

From a.badger at gmail.com  Mon Oct  6 16:19:47 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 06 Oct 2008 09:19:47 -0700
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48EA2A30.2070903@niemueller.de>
References: <1223161806.9727.8.camel@abel>	<20081004233620.GB2670@free.fr>	<200810051219.31882.Juha.Tuomala@iki.fi>	<1223277645.18676.2.camel@d2>	<48E9DCE8.6050500@niemueller.de>
	<20081006104842.GB2751@free.fr> <48EA2A30.2070903@niemueller.de>
Message-ID: <48EA3AA3.4030209@gmail.com>

Tim Niemueller wrote:
> I can understand that the trash tool chose that command name. It makes
> sense, it's short and clear, and for a command line tool that's
> something that makes users use it -- or not if done badly. It is likely
> that if another application provides another trash command the
> functionality will be equal or similar. Then it would be a matter for
> the alternatives system to sort this out. In general this is the very
> reason why the alternatives system is there. In case of the trash
> command the thing that probably makes many feel uncomfortable is that
> there is no such de-facto standard like sendmail, yet. And thus one
> might bet on the wrong horse.
> 
This is not what alternatives is for.  I've said many times that
alternatives should only be used when the following criteria are met:

1) System administrator choice; not end-user choice.

2) Command line compatible

A trash command does not follow #1 (no matter what happens if someone
implements a #2).  The environment-modules package might be a better
choice for doing something alternatives-like for end-user apps.

-Toshio

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

From jkeating at redhat.com  Mon Oct  6 16:28:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 09:28:13 -0700
Subject: proposal for make help chain-build text
In-Reply-To: <48EA3A84.7020405@city-fan.org>
References: <20080928122103.GA2728@free.fr> <20081003083131.GC3270@free.fr>
	<48E5D9AA.9060505@city-fan.org> <20081004170238.GA31243@free.fr>
	<48EA3A84.7020405@city-fan.org>
Message-ID: <1223310493.9987.29.camel@luminos.localdomain>

On Mon, 2008-10-06 at 17:19 +0100, Paul Howarth wrote:
> Patrice Dumas wrote:
> > On Fri, Oct 03, 2008 at 09:36:58AM +0100, Paul Howarth wrote:
> >> Test looks good to me, and certainly explains things better than the  
> >> existing text.
> > 
> > Can you apply it?
> 
> I don't think I have any higher commit privileges than you do? Or was 
> the question addressed to the infrastructure team?
> 
> Paul.
> 

Probably the best way to get this remembered or looked at is to file a
ticket with the Infrastructure or rel-eng trac space.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/d9fbce02/attachment.sig>

From jkeating at redhat.com  Mon Oct  6 16:31:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 09:31:07 -0700
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <200810052154.15443.ville.skytta@iki.fi>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<20081001035116.GA21890@jadzia.bu.edu>
	<200810012019.53814.ville.skytta@iki.fi>
	<200810052154.15443.ville.skytta@iki.fi>
Message-ID: <1223310667.9987.30.camel@luminos.localdomain>

On Sun, 2008-10-05 at 21:54 +0300, Ville Skytt? wrote:
> So... what can we do in order to make this happen?  Now that we have 
> volunteers, I suppose the best way forward would be to revert the change for 
> F-10 and start working on "the correct way" so that the default PATH wouldn't 
> need to be changed again in F-11.

Do you really need to revert the current change just to work on
something better?  Why can't the something better be worked on, and we
could move to something better when it's ready.  In the mean time, we
can continue to use the current setting.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/a6a4e53b/attachment.sig>

From mclasen at redhat.com  Mon Oct  6 16:35:14 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 06 Oct 2008 12:35:14 -0400
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081006021809.GA24675@jadzia.bu.edu>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<1223169402.10547.3.camel@abel> <48E8F373.20101@behdad.org>
	<48E932CC.8050607@andreafrancia.it> <48E933C2.9020608@behdad.org>
	<48E93B5A.5000302@andreafrancia.it>
	<20081006021809.GA24675@jadzia.bu.edu>
Message-ID: <1223310914.3944.2.camel@localhost.localdomain>

On Sun, 2008-10-05 at 22:18 -0400, Matthew Miller wrote:
> On Mon, Oct 06, 2008 at 12:10:34AM +0200, Andrea Francia wrote:
> >> Eh, thought it's obvious.  One can type "trash" then use tab completion to see
> >> what commands are available.  
> > So the commands names could became:
> > - trashcan-put
> > - trashcan-empty
> > - trashcan-list
> > - trashcan-restore
> > My English is not so good, is the 'trashcan-put' a good choice?
> 
> It's not as good as just 'trash'.
> 
> Are there multiple "trash" programs out there? Is this likely to be a real
> problem?

There is a gvfs-trash binary in gvfs, but it uses proper namespacing.



From pertusus at free.fr  Mon Oct  6 16:46:54 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 6 Oct 2008 18:46:54 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48EA2A30.2070903@niemueller.de>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>
	<1223277645.18676.2.camel@d2> <48E9DCE8.6050500@niemueller.de>
	<20081006104842.GB2751@free.fr> <48EA2A30.2070903@niemueller.de>
Message-ID: <20081006164654.GE2751@free.fr>

On Mon, Oct 06, 2008 at 05:09:36PM +0200, Tim Niemueller wrote:
> 
> In general, I agree that a good naming scheme helps in keeping things
> clean and simple. We should communicate this so that upcoming projects
> choose wisely from the very beginning and can ask existing projects to
> consider such a change. However, it is not the duty of an upstream
> project to foresee any possible conflict or animosity in this regard.

I disagree. In my opinion, it is the duty of upstream projects to choose
first a name that is unique, and only after a mainstream set of
capability is determined and synced accross implementation and there is 
sufficient history that the command is indeed something that should
belong to the 'core' commands that the generic name could be used.

> I can understand that the trash tool chose that command name. It makes

Me too, the point is not here. It is better from a strict and short term 
usability point of view.

> that if another application provides another trash command the
> functionality will be equal or similar. Then it would be a matter for

Not necessarily.

> the alternatives system to sort this out. In general this is the very
> reason why the alternatives system is there. In case of the trash
> command the thing that probably makes many feel uncomfortable is that
> there is no such de-facto standard like sendmail, yet. And thus one
> might bet on the wrong horse.

Exactly, and it is very problematic.

> The allegation projects choose the name "selfishly" is besides the
> point. 

Please note that I don't use "selfishly" in a negative way, but to
describe how upstream certainly do when choosing a name.

> An upstream project does not and should not have to please all or
> even "only" the major distros. Again, if upstream projects act careful
> and have this in mind, perfect, and let us encourage them to do so. But
> now renaming it in a package and thus diverting only in this distro is
> not a good idea.

There is the distribution list where this can be discussed. Debian
already makes much more renaming than fedora -- debian is still bigger
;-).

> In the case of player the name was chosen after a Shakespeare citation
> (cf.
> http://playerstage.sourceforge.net/wiki/Basic_FAQ#Why_are_Player_and_Stage_.28etc.29_so_named.3F)
> which is related to the functionality of the programs. So saying they
> chose it selfishly as if they did it to eliminate competition or
> whatever doesn't sound convincing, and they definitely didn't want to
> block media players or whatever I'm sure.

It isn't selfish in that sense. It is not agressively selfish but
neutrally selfish. This is a coordination issue not the war of names, I
am by no way implying that 'they did it to eliminate competition or
whatever', it was a name that sounds good to them. But they don't look
at the biggest usability and compatibility picture.

--
Pat



From a.badger at gmail.com  Mon Oct  6 16:52:22 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 06 Oct 2008 09:52:22 -0700
Subject: proposal for make help chain-build text
In-Reply-To: <48EA3A84.7020405@city-fan.org>
References: <20080928122103.GA2728@free.fr>	<20081003083131.GC3270@free.fr>	<48E5D9AA.9060505@city-fan.org>	<20081004170238.GA31243@free.fr>
	<48EA3A84.7020405@city-fan.org>
Message-ID: <48EA4246.5000406@gmail.com>

Paul Howarth wrote:
> Patrice Dumas wrote:
>> On Fri, Oct 03, 2008 at 09:36:58AM +0100, Paul Howarth wrote:
>>> Test looks good to me, and certainly explains things better than the 
>>> existing text.
>>
>> Can you apply it?
> 
> I don't think I have any higher commit privileges than you do? Or was
> the question addressed to the infrastructure team?
> 
Thanks Patrice!

I've just committed this:

chain-build		Build current package in order with other packages
	    example:  make chain-build CHAIN='libwidget libgizmo'
	The current package is added to the end of the CHAIN list.
	Colons (:) can be used in the CHAIN parameter to define
	groups of packages.  Packages in any single group will be
	built in parallel and all packages in a group must build
	successfully and populate the repository before the next
	group will begin building.  For example:
	    make chain-build CHAIN='libwidget libaselib : libgizmo :'
	will cause libwidget and libaselib to be built in parallel,
	followed by libgizmo and then the currect directory package.
	If no groups are defined, packages will be built sequentially.

If you need a change to something I've put in there, feel free to send
it my way.

Probably the best way to make sure requests like this aren't lost in the
future is to open a ticket on the fedora-infrastructure trac instance.
(You can still post here for comments but having a trac ticket means
people who are able to do it will see it and have it assigned to them.)

-Toshio

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

From hughsient at gmail.com  Mon Oct  6 16:50:49 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 06 Oct 2008 17:50:49 +0100
Subject: Live CD failure
Message-ID: <1223311849.6012.86.camel@hughsie-laptop>

Today I tried to create a live cd, without much success:

sudo livecd-creator --config=fedora-livecd-desktop-default.ks

Then I booted the ISO in qemu using KVM. This gives:

FATAL: Module sr_mod not found
FATAL: Module loop not found
FATAL: Module dm_snapshot not found
Bug in initramfs /init detected. Dropping to a shell. Good luck!

and then it hangs.

Am I missing a trick? I'm trying to debug
https://bugzilla.redhat.com/show_bug.cgi?id=461825

Richard.




From andrea at andreafrancia.it  Mon Oct  6 17:00:27 2008
From: andrea at andreafrancia.it (Andrea Francia)
Date: Mon, 06 Oct 2008 19:00:27 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <1223298464.2782.6.camel@abel>
References: <1223161806.9727.8.camel@abel>
	<20081004233620.GB2670@free.fr>	<1223169402.10547.3.camel@abel>
	<48E8F373.20101@behdad.org>	<48E932CC.8050607@andreafrancia.it>
	<48E933C2.9020608@behdad.org>	<48E93B5A.5000302@andreafrancia.it>	<20081006021809.GA24675@jadzia.bu.edu>
	<1223298464.2782.6.camel@abel>
Message-ID: <48EA442B.5070207@andreafrancia.it>

Jean-Fran?ois Martin wrote:
> Le dimanche 05 octobre 2008 ? 22:18 -0400, Matthew Miller a ?crit :
>   
>> On Mon, Oct 06, 2008 at 12:10:34AM +0200, Andrea Francia wrote:
>>     
>>>> Eh, thought it's obvious.  One can type "trash" then use tab completion to see
>>>> what commands are available.  
>>>>         
>>> So the commands names could became:
>>> - trashcan-put
>>> - trashcan-empty
>>> - trashcan-list
>>> - trashcan-restore
>>> My English is not so good, is the 'trashcan-put' a good choice?
>>>       
>> It's not as good as just 'trash'.
>>
>> Are there multiple "trash" programs out there? Is this likely to be a real
>> problem?
>>     
>
> There is another program that allow to manage the trash from FreeDesktop
> spec. but i can't find it, and it doesn't use the "trash" command.
>   
This page contains all trash projects that i know, AFAIK none of them 
has a "trash" command.
http://code.google.com/p/trash-cli/wiki/OtherTrashProjects

-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html



From jwboyer at gmail.com  Mon Oct  6 16:59:05 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 6 Oct 2008 12:59:05 -0400
Subject: Live CD failure
In-Reply-To: <1223311849.6012.86.camel@hughsie-laptop>
References: <1223311849.6012.86.camel@hughsie-laptop>
Message-ID: <20081006165905.GA31771@yoda.jdub.homelinux.org>

On Mon, Oct 06, 2008 at 05:50:49PM +0100, Richard Hughes wrote:
>Today I tried to create a live cd, without much success:
>
>sudo livecd-creator --config=fedora-livecd-desktop-default.ks
>
>Then I booted the ISO in qemu using KVM. This gives:
>
>FATAL: Module sr_mod not found
>FATAL: Module loop not found
>FATAL: Module dm_snapshot not found
>Bug in initramfs /init detected. Dropping to a shell. Good luck!
>
>and then it hangs.
>
>Am I missing a trick? I'm trying to debug

Those aren't modules anymore.  They are built into the
kernel.

josh



From bkearney at redhat.com  Mon Oct  6 16:57:33 2008
From: bkearney at redhat.com (Bryan Kearney)
Date: Mon, 06 Oct 2008 12:57:33 -0400
Subject: Live CD failure
In-Reply-To: <1223311849.6012.86.camel@hughsie-laptop>
References: <1223311849.6012.86.camel@hughsie-laptop>
Message-ID: <48EA437D.8060503@redhat.com>

Richard Hughes wrote:
> Today I tried to create a live cd, without much success:
> 
> sudo livecd-creator --config=fedora-livecd-desktop-default.ks
> 
> Then I booted the ISO in qemu using KVM. This gives:
> 
> FATAL: Module sr_mod not found
> FATAL: Module loop not found
> FATAL: Module dm_snapshot not found
> Bug in initramfs /init detected. Dropping to a shell. Good luck!
> 
> and then it hangs.
> 
> Am I missing a trick? I'm trying to debug
> https://bugzilla.redhat.com/show_bug.cgi?id=461825


I hit the same issue.

-- bk



From jkeating at redhat.com  Mon Oct  6 17:03:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 10:03:40 -0700
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48EA442B.5070207@andreafrancia.it>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<1223169402.10547.3.camel@abel> <48E8F373.20101@behdad.org>
	<48E932CC.8050607@andreafrancia.it> <48E933C2.9020608@behdad.org>
	<48E93B5A.5000302@andreafrancia.it>	<20081006021809.GA24675@jadzia.bu.edu>
	<1223298464.2782.6.camel@abel>  <48EA442B.5070207@andreafrancia.it>
Message-ID: <1223312621.9987.32.camel@luminos.localdomain>

On Mon, 2008-10-06 at 19:00 +0200, Andrea Francia wrote:
> This page contains all trash projects that i know, AFAIK none of them 
> has a "trash" command.
> http://code.google.com/p/trash-cli/wiki/OtherTrashProjects


Which means all of them were smart enough to avoid falling into the
generic trap.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/8a7d4c0f/attachment.sig>

From schaiba at gmail.com  Mon Oct  6 17:06:59 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Mon, 06 Oct 2008 20:06:59 +0300
Subject: Live CD failure
In-Reply-To: <1223311849.6012.86.camel@hughsie-laptop>
References: <1223311849.6012.86.camel@hughsie-laptop>
Message-ID: <48EA45B3.6090908@gmail.com>

Richard Hughes wrote:
> Today I tried to create a live cd, without much success:
>
> sudo livecd-creator --config=fedora-livecd-desktop-default.ks
>
> Then I booted the ISO in qemu using KVM. This gives:
>
> FATAL: Module sr_mod not found
> FATAL: Module loop not found
> FATAL: Module dm_snapshot not found
> Bug in initramfs /init detected. Dropping to a shell. Good luck!
>
> and then it hangs.
>
> Am I missing a trick? I'm trying to debug
> https://bugzilla.redhat.com/show_bug.cgi?id=461825
>
> Richard.
>
>
>   
I encountered the

FATAL: Module sr_mod not found
FATAL: Module loop not found

behaviour also in the beta livecd for x86, but it booted just fine.



From mschwendt at gmail.com  Mon Oct  6 17:10:01 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 6 Oct 2008 19:10:01 +0200
Subject: rawhide report: 20081006 changes
In-Reply-To: <1223310041.9987.28.camel@luminos.localdomain>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
	<1223310041.9987.28.camel@luminos.localdomain>
Message-ID: <20081006191001.2955ac34.mschwendt@gmail.com>

On Mon, 06 Oct 2008 09:20:41 -0700, Jesse Keating wrote:

> This seems to be from a bug we've been chasing in createrepo for a
> while, at least in the way that we use it to make rawhide.
> 
> Error Packages/perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch.rpm: No
> Package ID found for package
> perl-Locale-Maketext-Fuzzy-0.10-2.fc9.noarch, not going to add it
> Error Packages/lohit-fonts-tamil-2.3.1-1.fc10.noarch.rpm: No Package ID found for package lohit-fonts-tamil-2.3.1-1.fc10.noarch, not going to add it
> Error Packages/python-decoratortools-1.7-1.fc9.noarch.rpm: No Package ID found for package python-decoratortools-1.7-1.fc9.noarch, not going to add it
> 
> Those are the error messages we get from createrepo, so those packages
> just don't make it into the repodata, which trips the spam-o-matic
> script.  The problem is that it's not easily reproducible, it's not
> always the same packages, and it doesn't always happen.

Hmmm, an error message should be very good for somebody who is familiar
with the createrepo/Yum code:

         if po.checksum in (None, ""):
            raise MDError, "No Package ID found for package %s, not going to add it" % po
        

I wanted to have a brief look at where that checksum value comes from
(here with F9), but the Yum package objects use self._checksum
instead. That's weird and doesn't make sense to me yet.



From mschwendt at gmail.com  Mon Oct  6 17:19:24 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 6 Oct 2008 19:19:24 +0200
Subject: rawhide report: 20081006 changes
In-Reply-To: <20081006191001.2955ac34.mschwendt@gmail.com>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
	<1223310041.9987.28.camel@luminos.localdomain>
	<20081006191001.2955ac34.mschwendt@gmail.com>
Message-ID: <20081006191924.8553d2f9.mschwendt@gmail.com>

On Mon, 6 Oct 2008 19:10:01 +0200, Michael Schwendt wrote:

>          if po.checksum in (None, ""):
>             raise MDError, "No Package ID found for package %s, not going to add it" % po
>         
> I wanted to have a brief look at where that checksum value comes from
> (here with F9), but the Yum package objects use self._checksum
> instead. That's weird and doesn't make sense to me yet.

OMG, it's using properties further down in the same file. =:-O
So much about readability...



From jkeating at redhat.com  Mon Oct  6 17:19:46 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 10:19:46 -0700
Subject: rawhide report: 20081006 changes
In-Reply-To: <20081006191001.2955ac34.mschwendt@gmail.com>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
	<1223310041.9987.28.camel@luminos.localdomain>
	<20081006191001.2955ac34.mschwendt@gmail.com>
Message-ID: <1223313586.9987.33.camel@luminos.localdomain>

On Mon, 2008-10-06 at 19:10 +0200, Michael Schwendt wrote:
> 
> Hmmm, an error message should be very good for somebody who is
> familiar
> with the createrepo/Yum code:
> 
>          if po.checksum in (None, ""):
>             raise MDError, "No Package ID found for package %s, not
> going to add it" % po
>         
> 
> I wanted to have a brief look at where that checksum value comes from
> (here with F9), but the Yum package objects use self._checksum
> instead. That's weird and doesn't make sense to me yet.

The yum folks are still looking into it.  The really bizarre thing is
that there is no problem with the package itself, in fact it's seen in
other arches, and in those other arch directories it's a hardlink back
to the actual file somewhere else on the filesystem.  That's the way it
is for each of those arch trees.  It's a real headscratcher of a
problem.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/11188d1f/attachment.sig>

From Christian.Iseli at unil.ch  Mon Oct  6 17:39:28 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Mon, 6 Oct 2008 19:39:28 +0200
Subject: SELinux - copying ISO file content
In-Reply-To: <48EA1B0C.8050702@redhat.com>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<20081003091511.73410983@ludwig-alpha.unil.ch>
	<48E61B1C.70603@redhat.com>
	<20081004153856.22483543@ludwig-alpha.unil.ch>
	<48EA1B0C.8050702@redhat.com>
Message-ID: <20081006193928.1c896a4b@ludwig-alpha.unil.ch>

On Mon, 06 Oct 2008 10:05:00 -0400, Daniel J Walsh wrote:
> I don't know what vmshared is> It is beling labeled as a unlabeled_t
> which means the kernel policy does not know what this file system is.

Yes, vmshared is a special filesystem provided by the VirtualBox.  It
gets compiled and installed as a kernel module when you install the
VirtualBox tools on the client machine.  It allows one folder/directory
of the host machine to be seen as a filesystem on the client, allowing
file sharing.

> If you run restorecon -R -v ~/
> 
> Does it change the context on this file system?

No

I tried mounting it under /mnt, but the results are the same.  I did
not try to mount it through dolphin or other GUI.  I have no idea what
the GUI does that a simple command-line mount does not.

Cheers,
					Christian



From kwade at redhat.com  Mon Oct  6 17:44:15 2008
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Mon, 06 Oct 2008 10:44:15 -0700
Subject: Your release notes are looking =?utf-8?b?4oCm?= thin
Message-ID: <1223315055.3452.416.camel@calliope.phig.org>


FREEZE
        :: Release notes content is freezing on the wiki for the Fedora
        10 Preview Release on 08 October at 23:59 UTC. ::
FREEZE

If you take a look at the wiki pages that are the source for the release
notes (Docs/Beats), note the list of content areas (beats) that remain
unassigned[1]. What?s going on there? Why hasn?t the Docs Project
assigned someone?

FLASH
        :: If you don?t assign someone from your sub-project or SIG to
        cover that content, that area will be empty for the Fedora 10
        Preview and possibly final releases. ::
FLASH

Yep, it?s our job to remind you, edit, convert, get translated, package,
and deliver. But only you can fill in the content that is missing. One
thing we will do for you is hunt through your feature page and pull in
any release notes content that you put there. But you have to put it
there first, we cannot divine it.

There are also some beats that are assigned but no content has been
inserted. Here is your chance (about 2.25 days worth from the moment of
this writing.)

Here is a list of unassigned beats that are in danger of being dropped
for the Preview Release, meaning zero content appears:

      * Live media
      * Kernel
      * Package notes (misc. package changes) ? possibly deprecated
      * Printing
      * Mail servers
      * Developer features (not tools) ? i.e., not Haskell, NetBeans,
        etc.
      * Eclipse
      * Java
      * Samba
      * System daemons
      * Multimedia
      * Entertainment
      * Networking
      * Database servers
      * Backwards compatibility ? catch-all for backwards compat notes
        that don?t fit elsewhere

[1] https://fedoraproject.org/wiki/Docs/Beats#Beat_Assignments
-- 
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- 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/20081006/aacfc1e6/attachment.sig>

From ville.skytta at iki.fi  Mon Oct  6 17:51:09 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 6 Oct 2008 20:51:09 +0300
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <1223310667.9987.30.camel@luminos.localdomain>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
Message-ID: <200810062051.09666.ville.skytta@iki.fi>

On Monday 06 October 2008, Jesse Keating wrote:
> On Sun, 2008-10-05 at 21:54 +0300, Ville Skytt? wrote:
> > So... what can we do in order to make this happen?  Now that we have
> > volunteers, I suppose the best way forward would be to revert the change
> > for F-10 and start working on "the correct way" so that the default PATH
> > wouldn't need to be changed again in F-11.
>
> Do you really need to revert the current change just to work on
> something better?  Why can't the something better be worked on, and we
> could move to something better when it's ready.  In the mean time, we
> can continue to use the current setting.

It _can_ be done without reverting the current setting, but I think it's much, 
_much_ worse than not reverting.  After thinking about it a bit more, up to 
the point where I most likely wouldn't be interested in helping out with it 
any more.

If we work from a setup where */sbin are not in the default PATH, we only have 
to worry about existing full paths to executables we think should be in PATH 
in order to not cause regressions, most likely by providing compatibility 
symlinks or wrappers.  This way, work done results in incremental 
improvements.

If on the other hand */sbin are in the default PATH when we start the work, in 
addition to full paths and the compat symlinks/wrappers, we need to worry 
about the default PATH as well.  This is a problem because what we want to 
achieve is PATH which is kept clean of things that are not useful to have 
there, but now we can no longer remove them from it because doing so would 
inevitably break everything that has learned to expect these to be in PATH, 
or to use a full non-sbin path to it.  This way, work done accomplishes 
practically nothing (actually, we'd be making things worse by leaving behind 
a forest of compat symlinks/wrappers that shouldn't have existed in the first 
place), or we are generating regressions as we proceed.

So, I think not reverting the current setting compared to reverting it results 
in more work, harder work, worse results, and generally unnecessary default 
PATH churn (which in addition to the above is especially bad for things 
outside our control, such as /usr/local/sbin) between distro releases.



From dwalsh at redhat.com  Mon Oct  6 18:16:50 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 06 Oct 2008 14:16:50 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <20081006193928.1c896a4b@ludwig-alpha.unil.ch>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<20081003091511.73410983@ludwig-alpha.unil.ch>	<48E61B1C.70603@redhat.com>	<20081004153856.22483543@ludwig-alpha.unil.ch>	<48EA1B0C.8050702@redhat.com>
	<20081006193928.1c896a4b@ludwig-alpha.unil.ch>
Message-ID: <48EA5612.3010709@redhat.com>

Christian Iseli wrote:
> On Mon, 06 Oct 2008 10:05:00 -0400, Daniel J Walsh wrote:
>> I don't know what vmshared is> It is beling labeled as a unlabeled_t
>> which means the kernel policy does not know what this file system is.
> 
> Yes, vmshared is a special filesystem provided by the VirtualBox.  It
> gets compiled and installed as a kernel module when you install the
> VirtualBox tools on the client machine.  It allows one folder/directory
> of the host machine to be seen as a filesystem on the client, allowing
> file sharing.
> 
>> If you run restorecon -R -v ~/
>>
>> Does it change the context on this file system?
> 
> No
> 
> I tried mounting it under /mnt, but the results are the same.  I did
> not try to mount it through dolphin or other GUI.  I have no idea what
> the GUI does that a simple command-line mount does not.
> 
> Cheers,
> 					Christian
> 
I think if you mount it with a context option it would work.

mount -o context="system_u:object_r:vmblock:s0"  -t vboxsf VMShared /mnt

Does this fix it?




From mschwendt at gmail.com  Mon Oct  6 18:33:35 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 6 Oct 2008 20:33:35 +0200
Subject: rawhide report: 20081006 changes
In-Reply-To: <1223313586.9987.33.camel@luminos.localdomain>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
	<1223310041.9987.28.camel@luminos.localdomain>
	<20081006191001.2955ac34.mschwendt@gmail.com>
	<1223313586.9987.33.camel@luminos.localdomain>
Message-ID: <20081006203335.c31510fe.mschwendt@gmail.com>

On Mon, 06 Oct 2008 10:19:46 -0700, Jesse Keating wrote:

> The yum folks are still looking into it.  The really bizarre thing is
> that there is no problem with the package itself, in fact it's seen in
> other arches, and in those other arch directories it's a hardlink back
> to the actual file somewhere else on the filesystem.  That's the way it
> is for each of those arch trees.  It's a real headscratcher of a
> problem.

Unless I'm misreading the code, it's a race-condition. mash creates the
metadata for all architectures in parallel. One process per arch. The
createrepo checksum cache file I/O [1] is not protected against concurrent
access. With odd timing, it can happen that one process reads an empty
checksum file that has just been opened for writing by another process.
Give it a try. Add a safety check after reading a checksum file.



From jkeating at redhat.com  Mon Oct  6 18:41:19 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 06 Oct 2008 11:41:19 -0700
Subject: rawhide report: 20081006 changes
In-Reply-To: <20081006203335.c31510fe.mschwendt@gmail.com>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
	<1223310041.9987.28.camel@luminos.localdomain>
	<20081006191001.2955ac34.mschwendt@gmail.com>
	<1223313586.9987.33.camel@luminos.localdomain>
	<20081006203335.c31510fe.mschwendt@gmail.com>
Message-ID: <1223318479.9987.35.camel@luminos.localdomain>

On Mon, 2008-10-06 at 20:33 +0200, Michael Schwendt wrote:
> On Mon, 06 Oct 2008 10:19:46 -0700, Jesse Keating wrote:
> 
> > The yum folks are still looking into it.  The really bizarre thing is
> > that there is no problem with the package itself, in fact it's seen in
> > other arches, and in those other arch directories it's a hardlink back
> > to the actual file somewhere else on the filesystem.  That's the way it
> > is for each of those arch trees.  It's a real headscratcher of a
> > problem.
> 
> Unless I'm misreading the code, it's a race-condition. mash creates the
> metadata for all architectures in parallel. One process per arch. The
> createrepo checksum cache file I/O [1] is not protected against concurrent
> access. With odd timing, it can happen that one process reads an empty
> checksum file that has just been opened for writing by another process.
> Give it a try. Add a safety check after reading a checksum file.
> 

That tickles a part of my brain, I think I speculated that this was the
problem while in the shower or something, and then completely forgot to
pursue it once I got ready to work.  It is a possibility.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081006/72c6005c/attachment.sig>

From jvonau at shaw.ca  Mon Oct  6 20:17:34 2008
From: jvonau at shaw.ca (Jerry Vonau)
Date: Mon, 06 Oct 2008 15:17:34 -0500
Subject: SELinux - copying ISO file content
In-Reply-To: <48EA1B32.1010008@redhat.com>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<48E61A7E.8010404@redhat.com>	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com>
Message-ID: <48EA725E.2050908@shaw.ca>

Daniel J Walsh wrote:
> Jon Masters wrote:
>> On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:
>>
>>>> $ mount -o loop Fedora-9-i386-DVD.iso /mnt
>>>>
>>>> And then one might legitimately expect to be able to copy the content
>>>> of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
>>>> suppose that one is running SELinux in enforcing mode, then this will
>>>> fail because the contexts differ in this operation. Then, one will
>>>> likely quickly become severely annoyed and frustrated with SELinux,
>>>> simply setting it permissive for the duration of the operation...

I've seen this...

>>> Why would the copy fail?  cp should just work and set the files to the
>>> context of the destination directory.  If this fails it is a bug.
>> Ok, so there's a bug there then. Copying files from within an ISO image
>> was kind of the last straw in my willingness to keep SELinux enabled. It
>> hinders me at almost every turn from doing useful things with a Linux
>> desktop - I'm constantly amazed that Fedora persists in defaulting it
>> enabled, but that's a whole other rant.
>>
>> Jon.
>>
> What avc messages I should say?
> 

Here is a sample:

################
Summary:

SELinux is preventing cp from creating a file with a context of 
iso9660_t on a
filesystem.

Detailed Description:

SELinux is preventing cp from creating a file with a context of 
iso9660_t on a
filesystem. Usually this happens when you ask the cp command to maintain the
context of a file when copying between file systems, "cp -a" for 
example. Not
all file contexts should be maintained between the file systems. For 
example, a
read-only file type like iso9660_t should not be placed on a r/w system. 
"cp -P"
might be a better solution, as this will adopt the default file context 
for the
destination.

Allowing Access:

Use a command like "cp -P" to preserve all permissions except SELinux 
context.

Additional Information:

Source Context                system_u:object_r:iso9660_t:s0
Target Context                system_u:object_r:fs_t:s0
Target Objects                fedora.css [ filesystem ]
Source                        cp
Source Path                   /bin/cp
Port                          <Unknown>
Host                          schoolserver
Source RPM Packages           coreutils-6.10-30.fc9
Target RPM Packages
Policy RPM                    selinux-policy-3.3.1-84.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   filesystem_associate
Host Name                     schoolserver
Platform                      Linux schoolserver 2.6.25.14-108.fc9.i686 
#1 SMP
                               Mon Aug 4 14:08:11 EDT 2008 i686 i686
Alert Count                   21
First Seen                    Fri 12 Sep 2008 07:27:12 PM CDT
Last Seen                     Fri 12 Sep 2008 11:18:01 PM CDT
Local ID                      90f4d968-0a9b-42df-9982-fd0bdf284859
Line Numbers

Raw Audit Messages

host=schoolserver type=AVC msg=audit(1221279481.164:576): avc:  denied { 
associate } for  pid=12289 comm="cp" name="fedora.css" dev=dm-0 
ino=1835383 scontext=system_u:object_r:iso9660_t:s0 
tcontext=system_u:object_r:fs_t:s0 tclass=filesystem

host=schoolserver type=SYSCALL msg=audit(1221279481.164:576): 
arch=40000003 syscall=228 success=no exit=-13 a0=4 a1=df435d a2=9d566f0 
a3=1f items=0 ppid=12279 pid=12289 auid=500 uid=0 gid=0 euid=0 suid=0 
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="cp" exe="/bin/cp" 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

#######

Hope it helps,

Jerry



From pertusus at free.fr  Mon Oct  6 20:24:46 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 6 Oct 2008 22:24:46 +0200
Subject: proposal for make help chain-build text
In-Reply-To: <48EA4246.5000406@gmail.com>
References: <20080928122103.GA2728@free.fr> <20081003083131.GC3270@free.fr>
	<48E5D9AA.9060505@city-fan.org> <20081004170238.GA31243@free.fr>
	<48EA3A84.7020405@city-fan.org> <48EA4246.5000406@gmail.com>
Message-ID: <20081006202446.GA3243@free.fr>

On Mon, Oct 06, 2008 at 09:52:22AM -0700, Toshio Kuratomi wrote:
> 
> chain-build		Build current package in order with other packages
> 	    example:  make chain-build CHAIN='libwidget libgizmo'
> 	The current package is added to the end of the CHAIN list.
> 	Colons (:) can be used in the CHAIN parameter to define
> 	groups of packages.  Packages in any single group will be
> 	built in parallel and all packages in a group must build
> 	successfully and populate the repository before the next
> 	group will begin building.  For example:
> 	    make chain-build CHAIN='libwidget libaselib : libgizmo :'
> 	will cause libwidget and libaselib to be built in parallel,
> 	followed by libgizmo and then the currect directory package.
> 	If no groups are defined, packages will be built sequentially.

Looks good.

> Probably the best way to make sure requests like this aren't lost in the
> future is to open a ticket on the fedora-infrastructure trac instance.
> (You can still post here for comments but having a trac ticket means
> people who are able to do it will see it and have it assigned to them.)

Yep, it is indeed the best place, but I am not used to it still...

--
Pat



From z.kota at gmx.net  Mon Oct  6 20:32:33 2008
From: z.kota at gmx.net (Zoltan Kota)
Date: Mon, 6 Oct 2008 22:32:33 +0200 (CEST)
Subject: bug #464192 - help needed
Message-ID: <Pine.LNX.4.58.0810062228320.14270@venus.brc>

Hi,

Could anybody help with the following recode bug?
https://bugzilla.redhat.com/show_bug.cgi?id=464192

Thanks
Zoltan



From notting at redhat.com  Mon Oct  6 17:57:43 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 6 Oct 2008 13:57:43 -0400
Subject: Live CD failure
In-Reply-To: <20081006165905.GA31771@yoda.jdub.homelinux.org>
References: <1223311849.6012.86.camel@hughsie-laptop>
	<20081006165905.GA31771@yoda.jdub.homelinux.org>
Message-ID: <20081006175743.GA16284@nostromo.devel.redhat.com>

Josh Boyer (jwboyer at gmail.com) said: 
> Those aren't modules anymore.  They are built into the
> kernel.

So, presumably the livecd initramfs needs to be made less fragile.

Bill



From katzj at redhat.com  Mon Oct  6 23:49:13 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 06 Oct 2008 19:49:13 -0400
Subject: Live CD failure
In-Reply-To: <1223311849.6012.86.camel@hughsie-laptop>
References: <1223311849.6012.86.camel@hughsie-laptop>
Message-ID: <1223336953.754.7.camel@aglarond.local>

On Mon, 2008-10-06 at 17:50 +0100, Richard Hughes wrote:
> Then I booted the ISO in qemu using KVM. This gives:
> 
> FATAL: Module sr_mod not found
> FATAL: Module loop not found
> FATAL: Module dm_snapshot not found
> Bug in initramfs /init detected. Dropping to a shell. Good luck!
> 
> and then it hangs.

*sigh*  'set -e' strikes again... I'm quite tempted to remove it from
the /init.  But in any case, fixed up in mkinitrd and will be in
tomorrow's rawhide

Jeremy



From sflaniga at redhat.com  Tue Oct  7 00:04:35 2008
From: sflaniga at redhat.com (Sean Flanigan)
Date: Tue, 07 Oct 2008 10:04:35 +1000
Subject: Pseudo-locales for i18n testing by English speakers
In-Reply-To: <46a038f90810060034y2ac8de3pf535bc057f97a3ed@mail.gmail.com>
References: <48E45455.7000203@redhat.com>
	<46a038f90810060034y2ac8de3pf535bc057f97a3ed@mail.gmail.com>
Message-ID: <48EAA793.8010606@redhat.com>

Martin Langhoff wrote:
> 2008/10/2 Sean Flanigan <sflaniga at redhat.com>:
>> I have a simple Ant task which can generate pseudo-translations like the
>> one above from a gettext POT files,
> 
> I am after a few sets of "latin-lookalike" character tables I can use.
> Have you (or anyone) got pointers to good tables?

Well, I've made up a couple of simple ones (also attached as UTF-8):
ASCII:
"abcdefghijklmnopqrstuvwxyz"
BMP only:
"??????????????????????????"
BMP+SMP:
"??????????????????????????"

You could also try googling for "LATIN SMALL LETTER {A,B,C,...} WITH",
which should turn up all sorts of modified latin characters, such as
LATIN SMALL LETTER V WITH RIGHT HOOK.

Another option is the Wikipedia Unicode pages
http://en.wikipedia.org/wiki/List_of_Unicode_characters
has several sections for extended latin scripts, and the Unicode mapping
tables down the bottom are handy if you want to go directly to a certain
Unicode range (eg to get away from the BMP).

> The simple example phrase you provided hit a bug in moodle (php
> webapp) straight away - I think a few webapps have trouble with that
> funny 'e' (U+1D5BE). Interestingly, it's also present in Jira
> (Java-based webapp). Might be an iconv issue.

I chose that 'e' specifically because it wasn't part of the BMP, but
apparently the mathematical alphanumeric symbols are a bit of a special
case - I'm not sure if systems are expected to provide font substitution
for them.

Zimbra (written in Java) had trouble with the 'e' too - it just removed
it entirely.  I think a lot of programs have trouble with characters
that don't fit into 16-bit Unicode.  My text editors and Thunderbird can
show the 'e' character, but the cursor handling is all wrong on those lines.


-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: latinesque_table_utf8.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/dcfac116/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/dcfac116/attachment.sig>

From james.antill at redhat.com  Tue Oct  7 02:22:08 2008
From: james.antill at redhat.com (James Antill)
Date: Mon, 06 Oct 2008 22:22:08 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <200810062051.09666.ville.skytta@iki.fi>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
Message-ID: <1223346128.3889.17.camel@code.and.org>

On Mon, 2008-10-06 at 20:51 +0300, Ville Skytt? wrote:

> If we work from a setup where */sbin are not in the default PATH, we only have 
> to worry about existing full paths to executables we think should be in PATH 
> in order to not cause regressions, most likely by providing compatibility 
> symlinks or wrappers.  This way, work done results in incremental 
> improvements.

 We already _had_ this discussion, just providing a few symlinks from
sbin to bin isn't a good solution. Please read the thread from May.

>   This is a problem because what we want to 
> achieve is PATH which is kept clean of things that are not useful to have 
> there

 Again, read the thread from May, deciding which things only "normal"
people want in the path to keep it "clean" is very non-trivial.
 Apparently Matthew doesn't want firstboot in his path, that's nice ...
but what about if someone else does want it, do we start voting, for
each binary?

 If we are going to decide that Fedora can't even manage to change the
PATH to include sbin? without 100 people painting the bikeshed different
colours, so be it ... but please, please, please, don't let everyone
paint the thing for the next N years.


? And, yes, I've always hacked /etc/profile on every box I've used to
make sbin be part of the path, I'm obviously far from alone, but meh.

-- 
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/20081006/12cef7de/attachment.sig>

From mattdm at mattdm.org  Tue Oct  7 03:36:33 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 6 Oct 2008 23:36:33 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <1223346128.3889.17.camel@code.and.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
Message-ID: <20081007033633.GA5776@jadzia.bu.edu>

On Mon, Oct 06, 2008 at 10:22:08PM -0400, James Antill wrote:
>  If we are going to decide that Fedora can't even manage to change the
> PATH to include sbin? without 100 people painting the bikeshed different
> colours, so be it ... but please, please, please, don't let everyone
> paint the thing for the next N years.

Awesome. Accusing-people-of-bikeshed painting again. It's like tne Godwin's
Law of Fedora Devel or something. You get to be all snarky sounding and
dismissive at the same time. "Ooooh, the people who don't agree with me are
BIKESHED PAINTING! Zing!"

I've been actually working (not as a top priority, but still) on this "shed"
for quite a long time -- see the sudo bug referenced earlier (the key piece
in my mind), but also things like bug #18313.

So, if you insist on using the analogy: I'm sorry a buncha hooligans came
and painted graffiti all over the bikeshed. I'd like to put it back to its
former utilitarian finish even if it's a bit ugly, then from there you can
argue about colors all you like while we slowly actually get it into shape.


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mattdm at mattdm.org  Tue Oct  7 04:09:08 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 7 Oct 2008 00:09:08 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <1223346128.3889.17.camel@code.and.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
Message-ID: <20081007040908.GA9815@jadzia.bu.edu>

On Mon, Oct 06, 2008 at 10:22:08PM -0400, James Antill wrote:
>  Apparently Matthew doesn't want firstboot in his path, that's nice ...
> but what about if someone else does want it, do we start voting, for
> each binary?

And speaking of bikeshed painting. If you can't even bother to inform
yourself about your simple example, then you're really not contributing to
the discussion in any way. The answer to your rhetorical question is simple:
*no one* wants firstboot in their path:

  $ /usr/sbin/firstboot 
  firstboot ERROR: You must be root to run firstboot.

That can pretty much stand in analogy for the entire rest of whatever you
had to say. 

No, we don't start voting. We put things where it's sensible. That's usually
incredibly obvious, and where it's a more difficult case, we make a decision
based on a reasonable policy. Like with, say, "does it even work as
non-root" as one element. Crazy talk, I know, but there you have it.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From alexl at users.sourceforge.net  Tue Oct  7 04:33:29 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Mon, 06 Oct 2008 21:33:29 -0700
Subject: rawhide report: 20081006 changes
In-Reply-To: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	(Rawhide Report's message of "Mon\,
	6 Oct 2008 11\:51\:46 +0000 \(UTC\)")
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
Message-ID: <56myhhxbvq.fsf@allele2.eebweb.arizona.edu>

[...]

Quick update on broken deps investigation with latest rawhide:

> Broken deps for i386
> ----------------------------------------------------------
> 	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2

Already a response on:

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

looks like some new packages need a review before asterisk 1.6.0 will
build properly.

> 	gnuradio-3.1.2-2.fc9.i386 requires libcppunit-1.12.so.0

I took the liberty of rebuilding this package for broken deps because
of libcppunit soname bump:

https://koji.fedoraproject.org/koji/buildinfo?buildID=52252

it had been rebuilt for F-10 before, but for some reason the build was
cancelled:

https://koji.fedoraproject.org/koji/buildinfo?buildID=52252

> 	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1

Opened up a new bug requesting clarification:

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

I suspect the maintainer simply wanted to orphan the package but
didn't really know how.

> 	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
> 	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2

Looking at a my own scratch build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=865866

this actually is a simple spec file mistake, the build error is:

error: File not found: /builddir/build/BUILDROOT/lvm2-1.02.27-5.fc10.x86_64/usr/sbin/lvmconf

and the spec file says:

%files cluster
%defattr(-,root,root,-)
%attr(755,root,root) /usr/sbin/clvmd
%{_sbindir}/lvmconf
%{_mandir}/man8/clvmd.8.gz
/etc/rc.d/init.d/clvmd

but the %install part of the spec file is placing lvmconf in /usr/sbin:

install -m 0755 scripts/lvmconf.sh $RPM_BUILD_ROOT/sbin/lvmconf

I would fix this, but there are ACLs.

> 	1:openoffice.org-langpack-ta_IN-3.0.0-9.2.fc10.i386 requires lohit-fonts-tamil
> 	publican-0.37-0.fc10.noarch requires lohit-fonts-tamil

Not sure about these, was lohit-fonts-tamil removed from rawhide?

> 	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
> 	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
> 	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
> 	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0

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

> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
> 	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so

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

> 	syncevolution-0.7-3.fc10.i386 requires libcppunit-1.12.so.0

Again, just rebuild for new libcppunit:

https://koji.fedoraproject.org/koji/buildinfo?buildID=65549



From rodd at clarkson.id.au  Tue Oct  7 05:02:50 2008
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 07 Oct 2008 16:02:50 +1100
Subject: Evolution junk failures
In-Reply-To: <1218554844.3777.1.camel@scrappy.miketc.net>
References: <1218552060.19308.8.camel@scrappy.miketc.net>
	<1218554844.3777.1.camel@scrappy.miketc.net>
Message-ID: <1223355771.21379.140.camel@moose>

On Tue, 2008-08-12 at 10:27 -0500, Mike Chambers wrote:
> On Tue, 2008-08-12 at 09:41 -0500, Mike Chambers wrote:
> > On an F9 system upgraded to Rawhide, it seems evolution shows (not sure
> > if all the time, or at certain times/conditions) a "Check junk mail"
> > failed message when emails arrive.  And this worked just fine on F9,
> > using bogofilter as my spam program.
> > 
> > Also, (not sure this is evo though), as I am typing this, I can see the
> > whole email (body and signature) flashing in 2-3 different places on my
> > screen in the body of the email.  Below is a URL  with a screenshot of
> > it....
> > 
> > http://www.miketc.net/Screenshot.png
> 
> Don't know if related to any of the above, also noticed that sometimes,
> while using the message preview option, that when clicked on an email
> the body of the email doesn't show up (don't know whether this is just
> for html and/or text formatted emails).  If I close evo and reopen, most
> of the time that fixes it.

I see this a lot too.  Not sure what triggers it.  Haven't got around to
trying to get a back trace on it (as it doesn't trigger bug-buddy) and
it only happens every now and then.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jonstanley at gmail.com  Tue Oct  7 05:25:26 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Tue, 7 Oct 2008 01:25:26 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081007033633.GA5776@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
Message-ID: <da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>

On Mon, Oct 6, 2008 at 11:36 PM, Matthew Miller <mattdm at mattdm.org> wrote:

> Awesome. Accusing-people-of-bikeshed painting again. It's like tne Godwin's
> Law of Fedora Devel or something. You get to be all snarky sounding and
> dismissive at the same time. "Ooooh, the people who don't agree with me are
> BIKESHED PAINTING! Zing!"

I really don't think so.  This is painting the bike shed more than any
other thread in recent memory. I don't personally use the term that
often, and had been avoiding weighing in on this thread for precisely
that reason, but this has now gone too far. We already decided the
color of the bike shed, and it's blue. Reference below:

https://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080820

The proper time to voice objections to this would have been there, 6
weeks ago now.

> So, if you insist on using the analogy: I'm sorry a buncha hooligans came
> and painted graffiti all over the bikeshed. I'd like to put it back to its
> former utilitarian finish even if it's a bit ugly, then from there you can
> argue about colors all you like while we slowly actually get it into shape.

Again, if you insist on using the analogy, then this particular
bikeshed is currently in good repair and very attractive.

To make it clear, I'm 110% in favor of this feature, as are a number
of people, Let me explain why.

1) I've been admin'ing Linux (and Solaris, in the interest of full
disclosure, and occasionally some AIX or HP-UX thrown in for good
measure) boxen in some form for about 10 years now.  One of the first
things that I do in my user profile is to put these exact directories
in my PATH. It makes my job easier. This particular reasoning is not
good enough

2) I support alot of newbie users. Let me try and explain this in a
format that everyone will understand:

<new_user> OMG, ifconfig doesn't work, it's not installed!
<helper> you have to be root to do that.
<new_user> I am
<helper> how did you obtain root?
<new_user> why, su of course!
<helper> you need to type su -
<new_user> why's that?
<helper> because 'su -' gives you a login shell
<new_user> but I'm already logged in, do I need to open another window
or something?
<helper> no, just trust me here
<new_user> all this Linux stuff is just too complicated
* new_user has quit: installing Vista

If you think that nearly this exact interaction doesn't happen on a
daily basis, feel free to join #fedora and I'm sure one of the nice
folks there will inform you (I see it in #rhel where I help out all
the time).

So yes, this feature is necessary in order to make the distro more
accessible to new users. For the small minority that don't agree with
this change, it's highly likely that you know what you're doing and
are using puppet or something similar, and can revert the change
locally with a trivial amount of effort.

In regard to the point in your second mail, are there commands that
only root can execute in those locations? Absolutely. Have I
personally ever entered a command that can only be executed as root as
a normal user? Almost daily. Simple enough to press the home key and
type sudo in front of them.

And to belabor the point even more, are there commands in the CURRENT
default path that can't be executed by normal users? You better
believe it! Following is from my F8 system:

$ ping -f 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
ping: cannot flood; minimal interval, allowed for user, is 200ms
$

Following your reasoning, I propose we move ping to /sbin. Not a very
sound course of reasoning, is it?



From ville.skytta at iki.fi  Tue Oct  7 06:09:39 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Tue, 7 Oct 2008 09:09:39 +0300
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <1223346128.3889.17.camel@code.and.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
Message-ID: <200810070909.39906.ville.skytta@iki.fi>

On Tuesday 07 October 2008, James Antill wrote:
> On Mon, 2008-10-06 at 20:51 +0300, Ville Skytt? wrote:
> > If we work from a setup where */sbin are not in the default PATH, we only
> > have to worry about existing full paths to executables we think should be
> > in PATH in order to not cause regressions, most likely by providing
> > compatibility symlinks or wrappers.  This way, work done results in
> > incremental improvements.
>
>  We already _had_ this discussion, just providing a few symlinks from
> sbin to bin isn't a good solution. Please read the thread from May.

I have read the "Adding /sbin and /usr/sbin to everyone's path in F10" thread 
from April, not sure if that's what you mean but apart from one message I 
didn't find a related thread from May.  In the April thread I see several 
people advocating the symlink approach, and some people having reservations 
about it, most of whom seem to be hesitant about the amount of work involved 
in general with doing this right (ie. not the symlinking per se), and one or 
two who dismissed symlinking without providing any rationale.  If I missed 
something, please provide exact pointers.



From fedora at leemhuis.info  Tue Oct  7 06:37:58 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 07 Oct 2008 08:37:58 +0200
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
Message-ID: <48EB03C6.9080300@leemhuis.info>

On 07.10.2008 07:25, Jon Stanley wrote:
> On Mon, Oct 6, 2008 at 11:36 PM, Matthew Miller <mattdm at mattdm.org> wrote:
> 
>> Awesome. Accusing-people-of-bikeshed painting again. It's like tne Godwin's
>> Law of Fedora Devel or something. You get to be all snarky sounding and
>> dismissive at the same time. "Ooooh, the people who don't agree with me are
>> BIKESHED PAINTING! Zing!"
> 
> I really don't think so.  This is painting the bike shed more than any
> other thread in recent memory. I don't personally use the term that
> often, and had been avoiding weighing in on this thread for precisely
> that reason, but this has now gone too far. We already decided the
> color of the bike shed, and it's blue. Reference below:
> 
> https://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080820
> 
> The proper time to voice objections to this would have been there, 6
> weeks ago now.

Afaics and iirc it was announced just 24 hours before the meeting in 
question that the sbin feature is going to be discussed:
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00806.html

Do you consider that enough time to voice objections? I don't. But 
that's IMHO not a problem in our workflow, as we afaics always can make 
adjustments even when things got decided.

And it would definitely not the first time that features or improvements 
need to be adjusted or even reverted once the majority of users get 
aware of them in a beta. That's normal and shooting those discussion 
down with "The proper time to voice objections to this would have been 
there, 6 weeks ago now." is not going to bring Fedora forward.

CU
knurd



From enrico.scholz at informatik.tu-chemnitz.de  Tue Oct  7 07:22:54 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 07 Oct 2008 09:22:54 +0200
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <48EB03C6.9080300@leemhuis.info> (Thorsten Leemhuis's message of
	"Tue, 07 Oct 2008 08:37:58 +0200")
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info>
Message-ID: <87d4iczx69.fsf@sheridan.bigo.ensc.de>

Thorsten Leemhuis <fedora at leemhuis.info> writes:

> Afaics and iirc it was announced just 24 hours before the meeting in
> question that the sbin feature is going to be discussed:

Perhaps, Fedora should get a fishing and agrarian committee where things
can be accepted which were declined in previous discussions.


Enrico



From pertusus at free.fr  Tue Oct  7 07:27:44 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 7 Oct 2008 09:27:44 +0200
Subject: rawhide report: 20081006 changes
In-Reply-To: <56myhhxbvq.fsf@allele2.eebweb.arizona.edu>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<56myhhxbvq.fsf@allele2.eebweb.arizona.edu>
Message-ID: <20081007072744.GA2667@free.fr>

On Mon, Oct 06, 2008 at 09:33:29PM -0700, Alex Lancaster wrote:
> 
> > 	gnuradio-3.1.2-2.fc9.i386 requires libcppunit-1.12.so.0
> 
> I took the liberty of rebuilding this package for broken deps because
> of libcppunit soname bump:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=52252

Umh, I didn't announced cppunit soname bump because I thought that
nothing ended up being linked at runtime with cppunit... Looks like I
was wrong:
# repoquery  --whatrequires libcppunit-1.12.so.0
syncevolution-0:0.7-3.fc10.i386
gnuradio-0:3.1.2-2.fc9.i386

However these may be spurious deps, I'll have a look.

--
Pat



From fedora at camperquake.de  Tue Oct  7 07:49:12 2008
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 7 Oct 2008 09:49:12 +0200
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <87d4iczx69.fsf@sheridan.bigo.ensc.de>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info>
	<87d4iczx69.fsf@sheridan.bigo.ensc.de>
Message-ID: <20081007094912.4e49c8de@dhcp03.addix.net>

Hi.

On Tue, 07 Oct 2008 09:22:54 +0200, Enrico Scholz wrote:

> Perhaps, Fedora should get a fishing and agrarian committee where
> things can be accepted which were declined in previous discussions.

I think you may have to explain that one to the non-EU people here :)



From mschwendt at gmail.com  Tue Oct  7 08:37:50 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 7 Oct 2008 10:37:50 +0200
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081007040908.GA9815@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007040908.GA9815@jadzia.bu.edu>
Message-ID: <20081007103750.9001f04a.mschwendt@gmail.com>

On Tue, 7 Oct 2008 00:09:08 -0400, Matthew Miller wrote:

>   $ /usr/sbin/firstboot 
>   firstboot ERROR: You must be root to run firstboot.
> 
> That can pretty much stand in analogy for the entire rest of whatever you
> had to say. 
> 
> No, we don't start voting. We put things where it's sensible.

We do have a committee that's supposed to make sensible decisions, don't
we? Superuser executables in standard user's path is a crack idea.
Feel free to count that as one objection to those plans.



From tim at niemueller.de  Tue Oct  7 09:32:27 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Tue, 07 Oct 2008 11:32:27 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081006164654.GE2751@free.fr>
References: <1223161806.9727.8.camel@abel>
	<20081004233620.GB2670@free.fr>	<200810051219.31882.Juha.Tuomala@iki.fi>	<1223277645.18676.2.camel@d2>
	<48E9DCE8.6050500@niemueller.de>	<20081006104842.GB2751@free.fr>
	<48EA2A30.2070903@niemueller.de> <20081006164654.GE2751@free.fr>
Message-ID: <48EB2CAB.500@niemueller.de>

Patrice Dumas schrieb:
> 
>> I can understand that the trash tool chose that command name. It makes
> 
> Me too, the point is not here. It is better from a strict and short term 
> usability point of view.

And usability should be a very high priority goal. Even if you structure
it in beauty and perfection, if it does not solve the task efficiently
and easily (and to the user's liking) you have killed the feature.

>> that if another application provides another trash command the
>> functionality will be equal or similar. Then it would be a matter for
> 
> Not necessarily.

No, but I could also write a program called mail that is meant to label
snail mail. It's not about guarantees, but about what's likely.

>> An upstream project does not and should not have to please all or
>> even "only" the major distros. Again, if upstream projects act careful
> 
> There is the distribution list where this can be discussed. Debian
> already makes much more renaming than fedora -- debian is still bigger
> ;-).

That Debian does it doesn't make renaming any better. For some things it
causes confusion and for some things it shows disrespect to upstream.
Things look different if that is communicated with upstream and agreed upon.

>> In the case of player the name was chosen after a Shakespeare citation
> 
> It isn't selfish in that sense. It is not agressively selfish but
> neutrally selfish. This is a coordination issue not the war of names, I
> am by no way implying that 'they did it to eliminate competition or
> whatever', it was a name that sounds good to them. But they don't look
> at the biggest usability and compatibility picture.

And they should not have to. Why should distros dictate that? It's in
every project's own interest to choose a name which does not collide
with the name of another project. But besides that the project is free
to chose a name that fits the project best. Probably I'm slightly
missing the point because it's more about naming binaries, not whole
projects. But for the two examples of binary names (trash and player) I
feel that it wouldn't be a good idea to "just rename" it in Fedora.
Especially since there is no evident conflict, only maybe if you
actively look for a potential one on the web...

Just my two cents,
	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From fedora at shmuelhome.mine.nu  Tue Oct  7 09:34:25 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Tue, 07 Oct 2008 11:34:25 +0200
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
Message-ID: <48EB2D21.2080209@shmuelhome.mine.nu>

Jon Stanley wrote:
> ....
> The proper time to voice objections to this would have been there, 6
> weeks ago now.
>
>   
That statement would be correct if you were being criticized for trying 
the change. But the criticism is about the consequence of the change and 
that is always an open issue. Especially since there are many people who 
are affected by this change who aren't subscribed to this particular list.
> ....
> And to belabor the point even more, are there commands in the CURRENT
> default path that can't be executed by normal users? You better
> believe it! Following is from my F8 system:
>
> $ ping -f 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> ping: cannot flood; minimal interval, allowed for user, is 200ms
> $
>
> Following your reasoning, I propose we move ping to /sbin. Not a very
> sound course of reasoning, is it?
>
>   

Please respond to the objection itself. There is a big difference 
between "program can't be run" and "parameter can't be used". The latter 
is not a path issue. You would have made a better point with "yum" whose 
primary functionality needs root privileges but has user level options 
like list.

BTW, I am very surprised that there are people out there who know how to 
use "ifconfig" but don't know how to use "locate ifconfig | grep bin " 
to see if the command really exists. I would expect to have the issue 
show up more for people who expect to use ipconfig. So if you are 
worried about scaring away newbies by making them think about system 
admin functions, I suggest that you implement ipconfig.

If opinions count in this thread, I would personally want to see command 
completion limited to what I have in my path. And I don't want "/sbin" 
in my default path when I am not acting as a sys-admin.



From pertusus at free.fr  Tue Oct  7 09:44:58 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 7 Oct 2008 11:44:58 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48EB2CAB.500@niemueller.de>
References: <1223161806.9727.8.camel@abel> <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>
	<1223277645.18676.2.camel@d2> <48E9DCE8.6050500@niemueller.de>
	<20081006104842.GB2751@free.fr> <48EA2A30.2070903@niemueller.de>
	<20081006164654.GE2751@free.fr> <48EB2CAB.500@niemueller.de>
Message-ID: <20081007094458.GC3310@free.fr>

On Tue, Oct 07, 2008 at 11:32:27AM +0200, Tim Niemueller wrote:
> 
> And usability should be a very high priority goal. Even if you structure
> it in beauty and perfection, if it does not solve the task efficiently
> and easily (and to the user's liking) you have killed the feature.

Choosing a non-generic name will never 'kill a feature' otherwise we
would have a very limited set of packages...

> That Debian does it doesn't make renaming any better. For some things it
> causes confusion and for some things it shows disrespect to upstream.
> Things look different if that is communicated with upstream and agreed upon.

I am certainly not saying that what debian does is good for fedora, but
debian has always have more packages than fedora and they are facing
this issue since more time.

> > neutrally selfish. This is a coordination issue not the war of names, I
> > am by no way implying that 'they did it to eliminate competition or
> > whatever', it was a name that sounds good to them. But they don't look
> > at the biggest usability and compatibility picture.
> 
> And they should not have to. Why should distros dictate that? It's in

It is not distros who should dictate that. It is collective benefits.
A point relevant to fedora is that distros are more likely to be aware 
about these coordination failures because in a sense they are 
coordinating collections of softwares, but upstreams should also be
proactively working to avoid those coordination failures linked with
misused names.

> every project's own interest to choose a name which does not collide
> with the name of another project. But besides that the project is free
> to chose a name that fits the project best. 

No, there is also a responsibility in not misusing scarce words.

> Probably I'm slightly
> missing the point because it's more about naming binaries, not whole
> projects. But for the two examples of binary names (trash and player) I
> feel that it wouldn't be a good idea to "just rename" it in Fedora.
> Especially since there is no evident conflict, only maybe if you
> actively look for a potential one on the web...

The fact that there is no conflict is irrelevant. It shows that other
project providing such functionalities (especially for player) were
responsible enough not to use a generic word without caution.

--
Pat



From tim at niemueller.de  Tue Oct  7 10:10:49 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Tue, 07 Oct 2008 12:10:49 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <20081007094458.GC3310@free.fr>
References: <1223161806.9727.8.camel@abel>
	<20081004233620.GB2670@free.fr>	<200810051219.31882.Juha.Tuomala@iki.fi>	<1223277645.18676.2.camel@d2>
	<48E9DCE8.6050500@niemueller.de>	<20081006104842.GB2751@free.fr>
	<48EA2A30.2070903@niemueller.de>	<20081006164654.GE2751@free.fr>
	<48EB2CAB.500@niemueller.de> <20081007094458.GC3310@free.fr>
Message-ID: <48EB35A9.1080303@niemueller.de>

Patrice Dumas schrieb:
> On Tue, Oct 07, 2008 at 11:32:27AM +0200, Tim Niemueller wrote:
>> And usability should be a very high priority goal. Even if you structure
>> it in beauty and perfection, if it does not solve the task efficiently
>> and easily (and to the user's liking) you have killed the feature.
> 
> Choosing a non-generic name will never 'kill a feature' otherwise we
> would have a very limited set of packages...

>From my very personal and lazy perspective I might use a "trash"
command, but "trashcan" is already on the edge.

> It is not distros who should dictate that. It is collective benefits.
> A point relevant to fedora is that distros are more likely to be aware 
> about these coordination failures because in a sense they are 
> coordinating collections of softwares, but upstreams should also be
> proactively working to avoid those coordination failures linked with
> misused names.

Agreed, though I wouldn't name it misused names but rather unfortunate
chosen names.

>> every project's own interest to choose a name which does not collide
>> with the name of another project. But besides that the project is free
>> to chose a name that fits the project best. 
> 
> No, there is also a responsibility in not misusing scarce words.

I can't see how that is misused for the trash tool. It's used, in a
sensible way.

>> Probably I'm slightly
>> missing the point because it's more about naming binaries, not whole
>> projects. But for the two examples of binary names (trash and player) I
>> feel that it wouldn't be a good idea to "just rename" it in Fedora.
>> Especially since there is no evident conflict, only maybe if you
>> actively look for a potential one on the web...
> 
> The fact that there is no conflict is irrelevant. It shows that other

It's all about a conflict. I see that we want to make sure that what we
do today makes sense tomorrow. But for these particular words I don't
see a problem, it's a valid reason to use them.

> project providing such functionalities (especially for player) were
> responsible enough not to use a generic word without caution.

The whole project is named Player, why shouldn't they be "eligible" to
have a binary named player!? Is it possibly because you are used to
player implicating "media player"?

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From pertusus at free.fr  Tue Oct  7 10:18:57 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 7 Oct 2008 12:18:57 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <48EB35A9.1080303@niemueller.de>
References: <20081004233620.GB2670@free.fr>
	<200810051219.31882.Juha.Tuomala@iki.fi>
	<1223277645.18676.2.camel@d2> <48E9DCE8.6050500@niemueller.de>
	<20081006104842.GB2751@free.fr> <48EA2A30.2070903@niemueller.de>
	<20081006164654.GE2751@free.fr> <48EB2CAB.500@niemueller.de>
	<20081007094458.GC3310@free.fr> <48EB35A9.1080303@niemueller.de>
Message-ID: <20081007101857.GD3310@free.fr>

On Tue, Oct 07, 2008 at 12:10:49PM +0200, Tim Niemueller wrote:
> 
> > It is not distros who should dictate that. It is collective benefits.
> > A point relevant to fedora is that distros are more likely to be aware 
> > about these coordination failures because in a sense they are 
> > coordinating collections of softwares, but upstreams should also be
> > proactively working to avoid those coordination failures linked with
> > misused names.
> 
> Agreed, though I wouldn't name it misused names but rather unfortunate
> chosen names.

Once again when I say 'misused' I am not pointing a finger on upstreams.
The misuse is relevant from a collective point of view.

> >> every project's own interest to choose a name which does not collide
> >> with the name of another project. But besides that the project is free
> >> to chose a name that fits the project best. 
> > 
> > No, there is also a responsibility in not misusing scarce words.
> 
> I can't see how that is misused for the trash tool. It's used, in a
> sensible way.

trash is a generic name, and I think that it should not be chosen by a
specific project, but be part of a standard that defines command line
args. If it is used by a specific project now, it will become very hard to
revert to genericity.

> It's all about a conflict. I see that we want to make sure that what we
> do today makes sense tomorrow. But for these particular words I don't
> see a problem, it's a valid reason to use them.
> 
> > project providing such functionalities (especially for player) were
> > responsible enough not to use a generic word without caution.
> 
> The whole project is named Player, why shouldn't they be "eligible" to
> have a binary named player!? Is it possibly because you are used to
> player implicating "media player"?

Because there should be agreement on what the command 'player' provides,
on the command line arguments before it is used.

--
Pat



From opensource at till.name  Tue Oct  7 10:55:04 2008
From: opensource at till.name (Till Maas)
Date: Tue, 07 Oct 2008 12:55:04 +0200
Subject: proposal for make help chain-build text
In-Reply-To: <48EA4246.5000406@gmail.com>
References: <20080928122103.GA2728@free.fr> <48EA3A84.7020405@city-fan.org>
	<48EA4246.5000406@gmail.com>
Message-ID: <200810071255.05370.opensource@till.name>

On Mon October 6 2008, Toshio Kuratomi wrote:

> Probably the best way to make sure requests like this aren't lost in the
> future is to open a ticket on the fedora-infrastructure trac instance.
> (You can still post here for comments but having a trac ticket means
> people who are able to do it will see it and have it assigned to them.)

What is the Component one should use for it? I used CVS and it was only 
assigned to the owner of the FAS account notting, but not to you. And afaik 
Dennis Gilmore can update Makefile.common, too. Therefore it looks like the 
trac ticket is not as visible to the people with commit access as one would 
wish it is.

Here is the ticket:
https://fedorahosted.org/fedora-infrastructure/ticket/884

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/20081007/380f1e65/attachment.sig>

From rawhide at fedoraproject.org  Tue Oct  7 12:21:39 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue,  7 Oct 2008 12:21:39 +0000 (UTC)
Subject: rawhide report: 20081007 changes
Message-ID: <20081007122139.32DA01F81CF@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct  7 06:01:27 UTC 2008

New package OmegaT
        Computer Aid Translation tool
New package htmlparser
        HTML Parser, a Java library used to parse HTML
New package hunspell-hsb
        Upper Sorbian hunspell dictionaries
New package hunspell-nds
        Lowlands Saxon hunspell dictionaries
New package hunspell-rw
        Kinyarwanda hunspell dictionaries
New package mediawiki-Cite
        An extension to provide Citation tools for Mediawiki
New package opticalraytracer
        Utility that analyzes systems of lenses
New package perl-Mouse
        Moose minus the antlers
New package spu-binutils
        A GNU collection of binary utilities
Updated Packages:

FlightGear-1.0.0-4.fc10
-----------------------
* Sun Oct  5 18:00:00 2008 Fabrice Bellet <fabrice at bellet.info> 1.0.0-4
- fixed category of the menu entry (rh#465698)


PackageKit-0.3.6-2.fc10
-----------------------
* Mon Oct  6 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.6-2
- Upload new sources. Ooops.

* Mon Oct  6 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.6-1
- New upstream version
- Renice the spawned process so that we don't hog the system when doing updates


anaconda-11.4.1.44-1
--------------------
* Mon Oct  6 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.44-1
- Do not rely on loaderData->noDns to tell if we have DNS configured.
  (dcantrell)
- Skip askmethod dialog if user passes repo= and stage2= (dcantrell)
- Reset resolver in get_connection() (dcantrell)
- Fix problems dealing with PXE boot and the ksdevice= parameter. (dcantrell)
- Disable more IPv6 code in loader for now. (dcantrell)
- Write BOOTPROTO=static for manual IPv4 config. (dcantrell)
- Disable IPv6 widgets for F-10. (dcantrell)
- Add iwlagn driver firmware (#465508). (clumens)
- Move starting HAL to after we've probed for hardware. (clumens)
- Don't try to load a couple modules that no longer exist. (clumens)
- The Chinese font package has changed names (#465290). (clumens)
- Fix a traceback when there's no ksdevice given (#465638). (clumens)
- Fix traceback in post install configuration (hans)


anyremote-4.10-1.fc10
---------------------
* Mon Oct  6 18:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 4.10-1
- Fixed issue with non-correct handling of files and directories names with 
   braces and brackets in some configuration files. A lot of changes in 
   documentation. Several small changes in code.


arora-0.4-2.fc10
----------------
* Mon Oct  6 18:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> - 0.4-2
- Fedora Project & Red Hat bookmarks
- Fedora Project homepage
- GIT version patch


asymptote-1.44-2.fc10
---------------------
* Mon Oct  6 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.44-2
- add missing BuildRequires

* Mon Oct  6 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.44-1
- update to 1.44


bluez-4.12-1.fc10
-----------------
* Mon Oct  6 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.12-1
- Update to 4.12


bodhi-0.5.5-1.fc10
------------------
* Mon Oct  6 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.5-1
- Latest upstream release.

* Sat Oct  4 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.4-2
- Make our masher extension point less obtrusive.

* Tue Sep 16 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.4-1
- Latest upstream release, containing various bugfixes
- Make our python-fedora requirement explicit (#461518)


boost-1.34.1-17.fc10
--------------------
* Mon Oct  6 18:00:00 2008 Petr Machata <pmachata at redhat.com> - 1.34.1-17
- Fix gcc43 patch to apply cleanly under --fuzz=0
- Resolves: #465003


cjkunifonts-0.2.20080216.1-6.fc10
---------------------------------
* Tue Oct  7 18:00:00 2008 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-6.fc10
- Resolves: rhbz#465900 (Symlinks of fontconfig .conf files are inaccurated.)
- Macro'ed all 'ln -s'.


clustermon-0.15.0-5.fc10
------------------------
* Mon Oct  6 18:00:00 2008 Ryan McCabe <rmccabe at redhat.com> 0.15.0-5
- Update the cman configuration version when propagating a new cluster.conf
  via "ccs_sync"


clutter-0.8.2-1.fc10
--------------------
* Mon Oct  6 18:00:00 2008 Allisson Azevedo <allisson at gmail.com> 0.8.2-1
- Update to 0.8.2
- Removed clutter-0.8.0-clutter-fixed.patch


conman-0.2.2-2.fc10
-------------------
* Mon Oct  6 18:00:00 2008 Jarod Wilson <jarod at redhat.com> 0.2.2-2
- The console option in conman.conf is case-insensitive, so relax
  defined consoles check in initscript (Mark McLoughlin, #465777)


coreutils-6.12-12.fc10
----------------------
* Mon Oct  6 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 6.12-11
- added requires for libattr (#465569)

* Mon Oct  6 18:00:00 2008 Jarod Wilson <jarod at redhat.com> - 6.12-12
- fix up potential test failures when building in certain
  slightly quirky environments (part of bz#442352)


dbus-1.2.4-1.fc10
-----------------
* Mon Oct  6 18:00:00 2008 Colin Walters <walters at redhat.com> - 1.2.4-1
- New upstream 1.2.4


digikam-0.10.0-0.5.beta4.fc10
-----------------------------
* Mon Oct  6 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.10.0-0.5.beta4
- update to 0.10.0 beta 4
- build against latest kdegraphics


doxygen-1.5.7.1-1.fc10
----------------------
* Mon Oct  6 18:00:00 2008 Than Ngo <than at redhat.com> 1.5.7.1-1
- 1.5.7.1


echo-icon-theme-0.3.89.0-0.11.20081003gitcc6da5b.fc10
-----------------------------------------------------
* Mon Oct  6 18:00:00 2008 Martin Sourada <martin.sourada at gmail.com>
- 0.3.89.0-0.11.20081003gitcc6da5b
- New git snapshot


ecl-0.9l-3.fc10
---------------
* Mon Oct  6 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 0.9l-2
- disable ppc64 (fails to build)

* Wed Aug  6 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 0.9l-1
- new release 0.9l


ecryptfs-utils-58-0.fc10
------------------------
* Mon Oct  6 18:00:00 2008 Mike Halcrow <mhalcrow at us.ibm.com> 58-0
- TSPI key module update to avoid flooding TrouSerS library with requests
- OpenSSL key module parameter fixes
- Updates to mount-on-login utilities


expendable-0.0.5-1.fc10
-----------------------
* Mon Oct  6 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 0.0.5-1
- 0.0.5.


ext3grep-0.9.0-2.fc10
---------------------
* Mon Oct  6 18:00:00 2008 Milos Jakubicek <xjakub at fi.muni.cz> - 0.9.0-2
- Added ExcludeArch for sparcv9 and sparc64


gimp-2.6.0-1.fc10
-----------------
* Thu Oct  2 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.0-1
- version 2.6.0
- remove obsolete htmlview patch
- remove obsolete distro version dependent defaults
- don't use custom CFLAGS


gnokii-0.6.27-2.fc10
--------------------
* Mon Oct  6 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.6.27-2
- Fix htmlview patch

* Mon Oct  6 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.6.27-1
- Update to 0.6.27


gnome-packagekit-0.3.6-2.fc10
-----------------------------
* Mon Oct  6 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.6-2
- Upload new sources. Ooops.

* Mon Oct  6 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.6-1
- New upstream version
- Show vendor specific messages when we fail to find packages
- Turn off hardware HAL integration


gnuradio-3.1.2-2.fc10
---------------------

guitone-0.9_1-1.fc10
--------------------
* Tue Oct  7 18:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 0.9_1-1
- Upstream updated the tarfile.
- Added README.driver to %doc.


hal-0.5.12-1.20081001git.fc10
-----------------------------
* Mon Oct  6 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-1.20081001git
- Add a patch from the mailing list to try and fix rh#442457


hunspell-id-0.20040812-1.fc10
-----------------------------
* Fri Oct  6 18:00:00 2006 Caolan McNamara <caolanm at redhat.com> - 0.20040812-1
- latest version


hunspell-mg-0.20050109-1.fc10
-----------------------------
* Mon Oct  6 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20050109-1
- out-by-one


hyphen-da-0.20070903-1.fc10
---------------------------
* Mon Oct  6 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20070903-1
- latest version


ibus-0.1.1.20081006-3.fc10
--------------------------
* Tue Oct  7 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.1.1.20081006-3
- remove the empty %doc file entries

* Tue Oct  7 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.1.1.20081006-2
- add xinputrc alternative when installing or uninstalling

* Mon Oct  6 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081006-1
- Update to 0.1.1.20081006.


isomaster-1.3.3-2.fc10
----------------------
* Sun Oct  5 18:00:00 2008 Marcin Zajaczkowski <mszpak ATT wp DOTT pl> - 1.3.3-2
- fixed problem with building when --fuzzy=0 in patch command (#465088)


kdebase-4.1.2-4.fc10
--------------------
* Mon Oct  6 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-3
- bz#465451, backport konsole session management, thanks to Stefan Becker

* Mon Oct  6 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-4
- updated konsole session management patch from Stefan Becker


kdegraphics-4.1.2-3.fc10
------------------------
* Mon Oct  6 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-3
- respun tarball
- backport latest libkexiv2 and libkdcraw from trunk


kernel-2.6.27-0.398.rc9.fc10
----------------------------
* Mon Oct  6 18:00:00 2008 Jarod Wilson <jarod at redhat.com>
- Don't BUG_ON when iwl4695 gets packets in the wrong queue,
  just WARN. Slight leak w/kerneloops report is better than
  simply panicking, Intel working on root-cause (#457154).

* Mon Oct  6 18:00:00 2008 Jarod Wilson <jarod at redhat.com>
- Add driver for Hauppauge HD PVR

* Mon Oct  6 18:00:00 2008 Dave Jones <davej at redhat.com>
- Add cpufreq.git bits queued for 2.6.28.

* Mon Oct  6 18:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.27-rc9

* Mon Oct  6 18:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.27-rc8-git8

* Mon Oct  6 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- drm-modesetting-radeon.patch - fix drm mode header + Xv alignment issue


kipi-plugins-0.2.0-0.3.beta2.fc10
---------------------------------
* Mon Oct  6 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.2.0-0.3.beta2
- update to 0.2.0 beta 2
- build against latest kdegraphics
- don't require dcraw, libkdcraw includes its own RAW decoding code


kphotoalbum-3.2-0.3.20081007svn.fc10
------------------------------------
* Mon Oct  6 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.2-0.2.20081007svn
- new snapshot (20081007svn)
- use create_tarball.rb (includes translations)
- build against latest kdegraphics
- fix typos in description


ksplice-0.9.1-2.fc10
--------------------
* Mon Oct  6 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 0.9.1-2
- Fix typo in config patch

* Sun Oct  5 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 0.9.1-1
- New upstream release


libUnihan-0.5.2-0.fc10
----------------------
* Mon Oct  6 18:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.5.2-0
- New Features:
  + New pseudo field 'ZhuYin'.
  + allocate.h is in API.
  + New unihan_query options: -O -P -T -Z -z
  + Scalar String (U+XXXXX) is now be able to use in the input of Field query.
  + New functions: unihanField_is_case_no_change() and unihanField_is_lowercase()
- Fixed:
  + Behavior of unihan_query -U is now corrected.
  + Descriptions about pseudo field are corrected.
  + Handle NULL of str in stringList_insert(StringList *sList, const char *str).
- Changed:
  + In document, "simply query" is replaced by "field query".
  + unihanField_is_scalar_value() is renamed as unihanField_is_ucs4().
  + pinyin_strip_tone() and zhuYin_strip_tone()  now return 0 if tone of pinyin/zhuyin is not specified.
  + Doxyfile is renamed as Doxygen.in, so no need to manually modified the  version number.


libprelude-0.9.21.1-1.fc10
--------------------------
* Mon Oct  6 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> - 0.9.21.1-1
- New upstream bugfix release
- resolves: #465228 - prelude-admin is looking for tls.conf in /usr


libusb-0.1.12-18.fc10
---------------------
* Mon Oct  6 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 0.1.12-18
- fix multiarch conflict in libusb-devel (#465209)


lirc-0.8.4-0.4.pre2.fc10
------------------------
* Mon Oct  6 18:00:00 2008 - Jarod Wilson <jarod at redhat.com> - 0.8.4-0.4.pre2
- Update to 0.8.4pre2

* Mon Oct  6 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.8.4-0.3.pre1
- Fix more keycodes for the streamzap remote


lockdev-1.0.1-13.fc10
---------------------
* Mon Oct  6 18:00:00 2008 Karel Zak <kzak at redhat.com> - 1.0.1-13
- refresh patches (due --fuzz=0)
- fix compiler warnings


m2crypto-0.19-1
---------------
* Mon Oct  6 18:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 0.19-1
- Update to m2crypto-0.19
- Fix some rpmlint warnings

* Thu Sep 18 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.18.2-8
- enable sparc arches


man-pages-ja-20080915-1.fc10
----------------------------
* Tue Oct  7 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 20080915-1
- updates to 20080915.


mkinitrd-6.0.65-1.fc10
----------------------
* Mon Oct  6 18:00:00 2008 Jeremy Katz <katzj at redhat.com> - 6.0.65-1
- More built-in modules + live initrd fixup


nagios-plugins-1.4.13-5.fc10
----------------------------
* Mon Oct  6 18:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.4.13-5
- Fixing patch, missing semicolon


nspluginwrapper-1.1.0-11.fc10
-----------------------------
* Mon Oct  6 18:00:00 2008 Warren Togami <wtogami at redhat.com> 1.1.0-11
- Unrevert patch from -7 because Warren was wrong
- Concurrent rpc_method_invoke() patch

* Fri Oct  3 18:00:00 2008 Warren Togami <wtogami at redhat.com> 1.1.0-10
- Revert libcurl requires because it was done in an incorrect way
- Revert patch from -7 because it made things worse


openoffice.org-voikko-3.0-2.fc10
--------------------------------
* Mon Oct  6 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 3.0-2
- add --force to protect against installing by rpm an extension which was
  previously installed manually


openswan-2.6.18-1.fc10
----------------------
* Mon Oct  6 18:00:00 2008 Avesh Agarwal <avagarwa at redhat.com> - 2.6.18-1
- new upstream release
- modified default ipsec.conf to address rhbz#463931


perl-Crypt-SSLeay-0.57-9.fc10
-----------------------------
* Mon Oct  6 18:00:00 2008 Marcela Maslanova <mmaslano at redhat.com> - 0.57-9
- add examples into doc


perl-Hook-LexWrap-0.20-6.fc10
-----------------------------
* Mon Oct  6 18:00:00 2008 Ralf Corsepius <corsepiu at fedoraproject.org> - 0.20-6
- Add Hook-LexWrap-0.20-cpan-rt-38892.diff to fix
  http://rt.cpan.org/Public/Bug/Display.html?id=38892
  (Bugs shows while building rt3).


perl-Test-SubCalls-1.08-1.fc10
------------------------------
* Sun Oct  5 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1.08-1
- Upstream update.
- Activate AUTOMATED_TESTING.


plymouth-0.6.0-0.2008.10.06.1.fc10
----------------------------------
* Mon Oct  6 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.10.06.1
- Add "Solar" plugin from Charles Brej
- Move things around so computers with separate /usr boot
  (hopefully this won't break things, but it probably will)
- Make GDM show up on vt1 for all plugins


policycoreutils-2.0.57-1.fc10
-----------------------------
* Wed Oct  1 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-1
- Update to upstream
	* Update po files from Dan Walsh.


pybliographer-1.2.11-4.fc10
---------------------------
* Mon Oct  6 18:00:00 2008 Zoltan Kota <z.kota at gmx.net> - 1.2.11-4
- we need gnome-python2-gnome for building as well,
  added to buildreqs

* Sun Oct  5 18:00:00 2008 Zoltan Kota <z.kota at gmx.net> - 1.2.11-3
- fix gnome-python2 requirements (bug #465563)


pysvn-1.6.1-1.fc10
------------------
* Mon Oct  6 18:00:00 2008 Caitlyn O'Hanna <ravenoak at virtualxistenz.com> - 1.6.1-1
- Update to 1.6.1, fix F10 FBFS
- Disabled tests, might be because of subversion 1.5


python-paste-script-1.6.3-3.fc10
--------------------------------
* Mon Oct  6 18:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 1.6.3-3
- Require python-setuptools
- BuildRequire python-paste-deploy

* Sat Jun 14 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 1.6.3-1
- Update to Paste 1.6.3


python-tftpy-0.4.6-1.fc10
-------------------------
* Mon Oct  6 18:00:00 2008 John A. Khvatov <ivaxer at fedoraproject.org> 0.4.6-1
- Update to 0.4.6


redhat-menus-8.9.11-7.fc10
--------------------------
* Mon Oct  6 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 8.9.11-7
- Remove obsolete no translation (#465673)


ricci-0.15.0-5.fc10
-------------------
* Mon Oct  6 18:00:00 2008 Ryan McCabe <rmccabe at redhat.com> 0.15.0-5
- Generate the ricci NSS certificate database at startup if it doesn't exist
- By default, set the "propagate" attribute to true when setting a new cluster
  configuration file with "ccs_sync"


rrdtool-1.3.4-1.fc10
--------------------
* Mon Oct  6 18:00:00 2008 Jarod Wilson <jarod at redhat.com> 1.3.4-1
- Update to rrdtool 1.3.4


rtpproxy-1.2-0.2.alpha.200807211.fc10
-------------------------------------
* Mon Oct  6 18:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> - 1.2-0.2.alpha.200807211
- Added missing BuildRequires
- Added init-script


ruby-cairo-1.8.0-1.fc10
-----------------------
* Sun Oct  5 18:00:00 2008 Allisson Azevedo <allisson at gmail.com> 1.8.0-1
- Update to 1.8.0


ruby-gnome2-0.18.0-1.fc10
-------------------------
* Mon Oct  6 18:00:00 2008 Allisson Azevedo <allisson at gmail.com> 0.18.0-1
- Update to 0.18.0
- Removed ruby-gnome2-0.17.0-bz456816.patch


rubygem-gem2rpm-0.6.0-1.fc10
----------------------------
* Mon Oct  6 18:00:00 2008 David Lutterkort <dlutter at redhat.com> - 0.6.0-1
- New version


scim-anthy-1.2.6-1.fc10
-----------------------
* Tue Oct  7 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 1.2.6-1
- New upstream release.

* Tue Mar  4 17:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 1.2.5-1
- New upstream release.


selinux-policy-3.5.10-3.fc10
----------------------------
* Mon Oct  6 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.10-3
- Fixes for confined xwindows and xdm_t


sim-0.9.5-0.11.20080923svn2261rev.fc10
--------------------------------------
* Mon Oct  6 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.11.20080923svn2261rev
- Install /usr/share/mimelnk/application/x-icq.desctop only for fedora > 8. In fedora 8 it is conflicts with same file from kdenetworks
	( https://admin.fedoraproject.org/updates/sim-0.9.5-0.10.20080923svn2261rev.fc8 ).
- Add Requires: kdenetwork >= 3.0.0 for Fedora 8


stapitrace-1.0.0-18.20080622cvs_alpha.fc10
------------------------------------------

syncevolution-0.7-4.fc10
------------------------
* Mon Oct  6 18:00:00 2008 Alex Lancaster <alexlan[AT] fedoraproject.org> - 0.7-4
- Rebuild against new libcppunit to fix broken deps


taglib-1.5-2.fc10
-----------------
* Mon Oct  6 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.5-2
- Encrypted frames taglib/Amarok crash (kde#161721)


util-linux-ng-2.14.1-3.fc10
---------------------------
* Mon Oct  6 18:00:00 2008 Karel Zak <kzak at redhat.com> 2.14.1-3
- fix #465761 -  mount manpage is missing uid/gid mount options for tmpfs
- refresh util-linux-ng-2.14-mount-file_t.patch (fuzz=0)


vnc-4.1.2-35.fc10
-----------------
* Fri Oct  3 18:00:00 2008 Adam Tkac <atkac redhat com> 4.1.2-35
- updated patches due rpm 4.6 (#465099)
- build with -O2

* Mon Jul 28 18:00:00 2008 Adam Tkac <atkac redhat com> 4.1.2-34.2
- removed initscript %config attribute

* Fri Jul 18 18:00:00 2008 Adam Tkac <atkac redhat com> 4.1.2-34.1
- removed buildroot


writer2latex-0.5.0.2-2.fc10
---------------------------
* Mon Oct  6 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> 0.5.0.2-2
- update for guidelines


xastir-1.9.4-5.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Lucian Langa <cooly at gnome.eu.org> - 1.9.4-5
- upstream patch, fix for #435762


xautolock-2.2-6.fc10
--------------------
* Mon Oct  6 18:00:00 2008 Ian Weller <ianweller at gmail.com> 2.2-6
- Fix build section from FTFBS (bug 464962)


xorg-x11-drv-mutouch-1.2.1-1.fc10
---------------------------------
* Tue Oct  7 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.2.1-1
- mutouch 1.2.1


xorg-x11-server-1.5.1-6.fc10
----------------------------
* Tue Oct  7 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.1-6
- xserver-1.5.0-xkb-core-kbd-map-fix.patch: don't invent groups when mapping
  from xkb to core and back, and squash canonical types into explicit ones on
  core reconstruction (2 patches). #460545

* Mon Oct  6 18:00:00 2008 Dave Airlie <airlied at redhat.com> 1.5.1-5
- xserver-1.5.1-exa-fix-glyph-segfault.patch - fix EXA rects crash (462447)


Summary:
Added Packages: 9
Removed Packages: 0
Modified Packages: 80
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	gnome-phone-manager-0.60-2.fc10.i386 requires libgnokii.so.3
	gnome-phone-manager-telepathy-0.60-2.fc10.i386 requires libgnokii.so.3
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	6:kdepim-4.1.2-1.fc10.i386 requires libgnokii.so.3
	libopensync-plugin-gnokii-0.36-1.fc10.i386 requires libgnokii.so.3
	lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	gnome-phone-manager-0.60-2.fc10.x86_64 requires libgnokii.so.3()(64bit)
	gnome-phone-manager-telepathy-0.60-2.fc10.x86_64 requires libgnokii.so.3()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1
	6:kdepim-4.1.2-1.fc10.x86_64 requires libgnokii.so.3()(64bit)
	libopensync-plugin-gnokii-0.36-1.fc10.x86_64 requires libgnokii.so.3()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	gnome-phone-manager-0.60-2.fc10.ppc requires libgnokii.so.3
	gnome-phone-manager-telepathy-0.60-2.fc10.ppc requires libgnokii.so.3
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	6:kdepim-4.1.2-1.fc10.ppc requires libgnokii.so.3
	libopensync-plugin-gnokii-0.36-1.fc10.ppc requires libgnokii.so.3
	lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2
	lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	gnome-phone-manager-0.60-2.fc10.ppc64 requires libgnokii.so.3()(64bit)
	gnome-phone-manager-telepathy-0.60-2.fc10.ppc64 requires libgnokii.so.3()(64bit)
	gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1
	6:kdepim-4.1.2-1.fc10.ppc64 requires libgnokii.so.3()(64bit)
	libopensync-plugin-gnokii-0.36-1.fc10.ppc64 requires libgnokii.so.3()(64bit)
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit)
	lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit)
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From kevin.kofler at chello.at  Tue Oct  7 12:29:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 7 Oct 2008 12:29:04 +0000 (UTC)
Subject: Mysterious cmake failure on ppc64
Message-ID: <loom.20081007T122616-52@post.gmane.org>

I get this while trying to build kdepim-4.1.2-2.fc10 for dist-f10 on ppc64:
-- Looking for include files SYS_INOTIFY_H_FOUND - found
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::erase
/var/tmp/rpm-tmp.SsHcUA: line 47: 26805 
Aborted                 /usr/bin/cmake -DLIB_SUFFIX=64 [...]
error: Bad exit status from /var/tmp/rpm-tmp.SsHcUA (%build)

This is reproducible (I tried resubmitting it twice, all 3 builds failed).

The only change with respect to kdepim-4.1.2-1.fc10, which built successfully, 
is that this is a rebuild against the new libgnokii, but I don't see how that 
can be responsible. Maybe some other package changed in the buildroot, causing 
this?

        Kevin Kofler



From mattdm at mattdm.org  Tue Oct  7 12:33:07 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 7 Oct 2008 08:33:07 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
Message-ID: <20081007123307.GA19618@jadzia.bu.edu>

On Tue, Oct 07, 2008 at 01:25:26AM -0400, Jon Stanley wrote:
> The proper time to voice objections to this would have been there, 6
> weeks ago now.

Well, as I thought the discussion had been left before that meeting, fixing
the general problem of user-level commands in the wrong places was the
feature and it was going to be solved properly. The feature is called "sbin
sanity", and I'm 100% in support of that. The "ah, hell, just put everything
in the path and call that sane" change came as a surprise to me.


> 1) I've been admin'ing Linux (and Solaris, in the interest of full
> disclosure, and occasionally some AIX or HP-UX thrown in for good
> measure) boxen in some form for about 10 years now.  One of the first
> things that I do in my user profile is to put these exact directories
> in my PATH. It makes my job easier. This particular reasoning is not
> good enough

You're doing this because either 
 
 1) You're not used to using sudo for admin commands (and now sudo works
    right by default -- a change that predated )
 2) There's a few user-level commands in the wrong place.


> 2) I support alot of newbie users. Let me try and explain this in a
> format that everyone will understand:

So, again, this makes it clear to me that most people who are chiming in in
support of the path change haven't been paying attention. Arrgh. Like I
said, talk about bike painting!

I support a lot of new users too. That's why I've been concerned about this.

Tell the user "sudo ifconfig". It's better than having them "su -" and *does
the right thing the right way*. (Although arguably ifconfig is one of the
commands that could be moved to /bin -- it's one of the few tricky cases so
it's a bad example.)


> So yes, this feature is necessary in order to make the distro more
> accessible to new users. For the small minority that don't agree with
> this change, it's highly likely that you know what you're doing and
> are using puppet or something similar, and can revert the change
> locally with a trivial amount of effort.

Or, maybe I've been working for years on getting into Fedora a better
solution that's better for new users and for heavy command-line users alike,
and am frustrated that it's been undermined.




> $ ping -f 192.168.1.1
[...]
> Following your reasoning, I propose we move ping to /sbin. Not a very
> sound course of reasoning, is it?

*rolls eyes*

Obviously your reasoning is not very sound. There's a CLEAR difference
between commands which can't or don't work at all without root, and those
which have additional features which work as root. Again, one of the easy
cases and we can both see where it belongs, so it's ridiculous to pick it as
an example.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From benny+usenet at amorsen.dk  Tue Oct  7 13:18:59 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Tue, 07 Oct 2008 15:18:59 +0200
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081007040908.GA9815@jadzia.bu.edu> (Matthew Miller's message
	of "Tue\, 7 Oct 2008 00\:09\:08 -0400")
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007040908.GA9815@jadzia.bu.edu>
Message-ID: <m3ljx01r24.fsf@ursa.amorsen.dk>

Matthew Miller <mattdm at mattdm.org> writes:

> No, we don't start voting. We put things where it's sensible. That's usually
> incredibly obvious, and where it's a more difficult case, we make a decision
> based on a reasonable policy. Like with, say, "does it even work as
> non-root" as one element. Crazy talk, I know, but there you have it.

If it is so incredibly obvious, how did tcpdump end up in /sbin? Once
you have moved all the networking utilities and all the disk utilities
from /sbin, is there really anything left?


/Benny



From valent.turkovic at gmail.com  Tue Oct  7 13:27:38 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 7 Oct 2008 15:27:38 +0200
Subject: looking for a few good reviewers :)
Message-ID: <64b14b300810070627n7f1a1420lf24a36268d612add@mail.gmail.com>

https://bugzilla.redhat.com/show_bug.cgi?id=429590
http://kernelreloaded.blog385.com/index.php/archives/fur-elise-not-on-fedora/

As there are not many (any?) media center packages on Fedora this one
package gives Fedora a great abbility so that Fedora could be used as
a Media Center.

Any reviewers interested?

Cheers,
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 luca at foppiano.org  Tue Oct  7 13:28:56 2008
From: luca at foppiano.org (Luca Foppiano)
Date: Tue, 07 Oct 2008 15:28:56 +0200
Subject: [Fedora-packaging] looking for a sponsor and review ;)
Message-ID: <1223386136.3900.33.camel@sboing.byte-code.lan>

hi all ;-)
	I don't know if this is the right place to ask, but I submitted a
package request review and I'm looking for a sponsor.

The package is symbolic (https://fedorahosted.org/symbolic) and my
request is here [1].

I think the spec file is pretty good, but I'm not sure it's perfect.

Thanks in advance.
Luca

[1] https://bugzilla.redhat.com/show_bug.cgi?id=465478
-- 
Today is Setting Orange, the 61st day of Bureaucracy in the YOLD 3174

You will be married within a year.

--
Fedora-packaging mailing list
Fedora-packaging at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging



From rjones at redhat.com  Tue Oct  7 13:35:18 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 7 Oct 2008 14:35:18 +0100
Subject: How to package code compiled with 'gcc -m32'?
Message-ID: <20081007133518.GA10140@amd.home.annexia.org>

I've got a nasty program I'm trying to package for Fedora.  To cut a
very long story short, this C/C++ mixed program started out on Windows
and makes lots of 32 bit assumptions.  So it's compiled with 'gcc -m32'.

Expressing the build requirements so it can build on a 64 bit platform
is proving troublesome.  (It builds fine on i386).

First problem is that it uses <gnu/stubs.h> which includes
<gnu/stubs-[WORDSIZE].h> (ie. <gnu/stubs-32.h>).  That file isn't in
glibc-devel.x86_64, but only in glibc-devel.i386.

I've expressed that with a file dependency which breaks Fedora
packaging guidelines:

  BuildRequires:  /usr/include/gnu/stubs-32.h

The second and much larger problem is that the code uses wxGTK-devel,
and (because it's being compiled with gcc -m32) it has to have the 32
bit version.

This should work (on x86-64 at least, not ppc64):

  BuildRequires:  wxGTK-devel.i386

but in fact even with the latest version of rpmbuild in Rawhide it
doesn't work.  So I have to write:

  BuildRequires:  wxGTK-devel

which doesn't express the dependency correctly, or:

  BuildRequires:  /usr/lib/libwx_baseu-2.8.so

which doesn't work on platforms which don't have the lib/lib64 split.

Any ideas?  I'm sure others must have hit this problem before ...

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From bkearney at redhat.com  Tue Oct  7 13:37:09 2008
From: bkearney at redhat.com (Bryan Kearney)
Date: Tue, 07 Oct 2008 09:37:09 -0400
Subject: Live CD failure
In-Reply-To: <1223336953.754.7.camel@aglarond.local>
References: <1223311849.6012.86.camel@hughsie-laptop>
	<1223336953.754.7.camel@aglarond.local>
Message-ID: <48EB6605.3040008@redhat.com>

Jeremy Katz wrote:
> On Mon, 2008-10-06 at 17:50 +0100, Richard Hughes wrote:
>> Then I booted the ISO in qemu using KVM. This gives:
>>
>> FATAL: Module sr_mod not found
>> FATAL: Module loop not found
>> FATAL: Module dm_snapshot not found
>> Bug in initramfs /init detected. Dropping to a shell. Good luck!
>>
>> and then it hangs.
> 
> *sigh*  'set -e' strikes again... I'm quite tempted to remove it from
> the /init.  But in any case, fixed up in mkinitrd and will be in
> tomorrow's rawhide
> 
> Jeremy
> 
This morning I get past this error, and I get a small blue progress bar 
along the bottom.. but the running machine seems to hang after the blue bar.

Running an updated F9 machine.

-- bk



From hughsient at gmail.com  Tue Oct  7 13:36:21 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 07 Oct 2008 14:36:21 +0100
Subject: Live CD failure
In-Reply-To: <1223336953.754.7.camel@aglarond.local>
References: <1223311849.6012.86.camel@hughsie-laptop>
	<1223336953.754.7.camel@aglarond.local>
Message-ID: <1223386581.25444.0.camel@hughsie-laptop>

On Mon, 2008-10-06 at 19:49 -0400, Jeremy Katz wrote:
> *sigh*  'set -e' strikes again... I'm quite tempted to remove it from
> the /init.  But in any case, fixed up in mkinitrd and will be in
> tomorrow's rawhide

Legend, thanks. Ill try again this afternoon.

Richard.




From jonathan at jonmasters.org  Tue Oct  7 13:42:25 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Tue, 07 Oct 2008 09:42:25 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <48EA725E.2050908@shaw.ca>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com>  <48EA725E.2050908@shaw.ca>
Message-ID: <1223386945.10179.6.camel@londonpacket.bos.redhat.com>

On Mon, 2008-10-06 at 15:17 -0500, Jerry Vonau wrote:
> Daniel J Walsh wrote:
> > Jon Masters wrote:
> >> On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:
> >>
> >>>> $ mount -o loop Fedora-9-i386-DVD.iso /mnt
> >>>>
> >>>> And then one might legitimately expect to be able to copy the content
> >>>> of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
> >>>> suppose that one is running SELinux in enforcing mode, then this will
> >>>> fail because the contexts differ in this operation. Then, one will
> >>>> likely quickly become severely annoyed and frustrated with SELinux,
> >>>> simply setting it permissive for the duration of the operation...
> 
> I've seen this...

Indeed. I have too, one too many times.

> SELinux is preventing cp from creating a file with a context of 
> iso9660_t on a
> filesystem.

Ah yes, I probably used the standard "cp -ax blah /blah" command. I
guess I'll need to learn not to use such standard commands in future and
adapt everything around SELinux. Because that's very non-obtrusive, and
won't cause regular users any anguish at all.

Jon.




From a.badger at gmail.com  Tue Oct  7 14:35:02 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 07 Oct 2008 07:35:02 -0700
Subject: proposal for make help chain-build text
In-Reply-To: <200810071255.05370.opensource@till.name>
References: <20080928122103.GA2728@free.fr>
	<48EA3A84.7020405@city-fan.org>	<48EA4246.5000406@gmail.com>
	<200810071255.05370.opensource@till.name>
Message-ID: <48EB7396.6070309@gmail.com>

Till Maas wrote:
> On Mon October 6 2008, Toshio Kuratomi wrote:
> 
>> Probably the best way to make sure requests like this aren't lost in the
>> future is to open a ticket on the fedora-infrastructure trac instance.
>> (You can still post here for comments but having a trac ticket means
>> people who are able to do it will see it and have it assigned to them.)
> 
> What is the Component one should use for it? I used CVS and it was only 
> assigned to the owner of the FAS account notting, but not to you. And afaik 
> Dennis Gilmore can update Makefile.common, too. Therefore it looks like the 
> trac ticket is not as visible to the people with commit access as one would 
> wish it is.
> 
I've opened a ticket to change the default assignee.  An alternative is
to assign to buildsys for these changes.

https://fedorahosted.org/fedora-infrastructure/ticket/886

> Here is the ticket:
> https://fedorahosted.org/fedora-infrastructure/ticket/884
> 
Done.

-Toshio

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

From orion at cora.nwra.com  Tue Oct  7 14:35:32 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 07 Oct 2008 08:35:32 -0600
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <20081007133518.GA10140@amd.home.annexia.org>
References: <20081007133518.GA10140@amd.home.annexia.org>
Message-ID: <48EB73B4.3070504@cora.nwra.com>

Richard W.M. Jones wrote:
> I've expressed that with a file dependency which breaks Fedora
> packaging guidelines:
> 
>   BuildRequires:  /usr/include/gnu/stubs-32.h

Don't know about guidelines, but:

mknbi/mknbi.spec:BuildRequires: /usr/include/gnu/stubs-32.h
nbd/nbd.spec:BuildRequires:  /usr/include/gnu/stubs-32.h
syslinux/syslinux.spec:BuildRequires: /usr/include/gnu/stubs-32.h
xenner/xenner.spec:BuildRequires: /usr/include/gnu/stubs-32.h
xen/xen.spec:BuildRequires: /usr/include/gnu/stubs-32.h


-- 
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 pemboa at gmail.com  Tue Oct  7 14:41:37 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 7 Oct 2008 09:41:37 -0500
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <m3ljx01r24.fsf@ursa.amorsen.dk>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007040908.GA9815@jadzia.bu.edu> <m3ljx01r24.fsf@ursa.amorsen.dk>
Message-ID: <16de708d0810070741ga6a82fesa88d33208242ab@mail.gmail.com>

On Tue, Oct 7, 2008 at 8:18 AM, Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> Matthew Miller <mattdm at mattdm.org> writes:
>
>> No, we don't start voting. We put things where it's sensible. That's usually
>> incredibly obvious, and where it's a more difficult case, we make a decision
>> based on a reasonable policy. Like with, say, "does it even work as
>> non-root" as one element. Crazy talk, I know, but there you have it.
>
> If it is so incredibly obvious, how did tcpdump end up in /sbin? Once
> you have moved all the networking utilities and all the disk utilities
> from /sbin, is there really anything left?


What system/specification is fedora following?

According to the FHS [1]:
/sbin is for "Utilities used for system administration (and other
root-only commands)"


[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jdieter at gmail.com  Tue Oct  7 14:54:52 2008
From: jdieter at gmail.com (Jonathan Dieter)
Date: Tue, 07 Oct 2008 17:54:52 +0300
Subject: looking for a few good reviewers :)
In-Reply-To: <64b14b300810070627n7f1a1420lf24a36268d612add@mail.gmail.com>
References: <64b14b300810070627n7f1a1420lf24a36268d612add@mail.gmail.com>
Message-ID: <1223391292.3585.5.camel@jdlaptop>

On Tue, 2008-10-07 at 15:27 +0200, Valent Turkovic wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=429590
> http://kernelreloaded.blog385.com/index.php/archives/fur-elise-not-on-fedora/
> 
> As there are not many (any?) media center packages on Fedora this one
> package gives Fedora a great abbility so that Fedora could be used as
> a Media Center.

It really isn't obvious *which* packages still need review.  As far as I
can see, the real blocker is the review for python-twisted-web2 (which
is assigned), but I could be reading it completely wrong.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/f9d194c2/attachment.sig>

From pemboa at gmail.com  Tue Oct  7 14:46:43 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 7 Oct 2008 09:46:43 -0500
Subject: SELinux - copying ISO file content
In-Reply-To: <1223108738.9328.40.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
Message-ID: <16de708d0810070746t5186592cw535d363a7223fcff@mail.gmail.com>

On Sat, Oct 4, 2008 at 3:25 AM, Jon Masters <jonathan at jonmasters.org> wrote:
> On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:
>
>> > $ mount -o loop Fedora-9-i386-DVD.iso /mnt
>> >
>> > And then one might legitimately expect to be able to copy the content
>> > of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
>> > suppose that one is running SELinux in enforcing mode, then this will
>> > fail because the contexts differ in this operation. Then, one will
>> > likely quickly become severely annoyed and frustrated with SELinux,
>> > simply setting it permissive for the duration of the operation...
>
>> Why would the copy fail?  cp should just work and set the files to the
>> context of the destination directory.  If this fails it is a bug.
>
> Ok, so there's a bug there then. Copying files from within an ISO image
> was kind of the last straw in my willingness to keep SELinux enabled. It
> hinders me at almost every turn from doing useful things with a Linux
> desktop - I'm constantly amazed that Fedora persists in defaulting it
> enabled, but that's a whole other rant.


You can copy files from within an ISO mount. You cannot serve the
files directly in the mount from HTTPd though.

But copying definitely works.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mschwendt at gmail.com  Tue Oct  7 15:11:35 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 7 Oct 2008 17:11:35 +0200
Subject: looking for a few good reviewers :)
In-Reply-To: <1223391292.3585.5.camel@jdlaptop>
References: <64b14b300810070627n7f1a1420lf24a36268d612add@mail.gmail.com>
	<1223391292.3585.5.camel@jdlaptop>
Message-ID: <20081007171135.cd2c0d95.mschwendt@gmail.com>

On Tue, 07 Oct 2008 17:54:52 +0300, Jonathan Dieter wrote:

> On Tue, 2008-10-07 at 15:27 +0200, Valent Turkovic wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=429590
> > http://kernelreloaded.blog385.com/index.php/archives/fur-elise-not-on-fedora/
> > 
> > As there are not many (any?) media center packages on Fedora this one
> > package gives Fedora a great abbility so that Fedora could be used as
> > a Media Center.
> 
> It really isn't obvious *which* packages still need review.  As far as I
> can see, the real blocker is the review for python-twisted-web2 (which
> is assigned), but I could be reading it completely wrong.

https://bugzilla.redhat.com/438608 ("good" plugins)
https://bugzilla.redhat.com/438609 ("bad" plugins)

and their dependencies (see list of tickets they depend on).

python-cssutils
python-twisted-web2

and it needs  pigment-python >= 0.3.8 (only in F10 devel).



From hughsient at gmail.com  Tue Oct  7 15:09:20 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 07 Oct 2008 16:09:20 +0100
Subject: No dynamic groups in PackageKit : Solved
In-Reply-To: <48D897E6.4090600@googlemail.com>
References: <48D542A9.1070600@leemhuis.info>
	<48D5552C.1000700@fedoraproject.org>
	<loom.20080920T195843-984@post.gmane.org>	<48D63D1E.4070806@leemhuis.info>
	<48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com>
	<loom.20080921T212341-346@post.gmane.org>	<48D726C0.4060208@leemhuis.info>
	<1222066065.19471.6.camel@rousalka.okg>
	<1222072903.3330.3.camel@hughsie-work>
	<1222107615.4108.23.camel@luminos.localdomain>
	<1222115665.24063.14.camel@hughsie-work>
	<1222150606.30758.65.camel@code.and.org>
	<48D897E6.4090600@googlemail.com>
Message-ID: <1223392160.25444.12.camel@hughsie-laptop>

On Tue, 2008-09-23 at 09:16 +0200, Tim Lauridsen wrote:
> I think this discussion is getting a little heated and it is not the 
> most constructive, if you want something to change IMHO.

Tim is spot on, and a good example of someone that does things properly
rather than just ranting about how broken $something is. I really can't
believe how rude some people are on this list.

We spent a few hours over the last week or so on the upstream PackageKit
mailing list, designing a new method and signal to allow us to return
custom groups in a cross distro way.

Tim wrote the initial patch, which I then rewrote a little, and then the
very next day Tim committed a simple yum implementation of the new
method call. All in all it was a few hundred lines added.

> I agree in there is some issues with the static groups currently in
> pk.so i have made this proposal on the upstream packagekit list.
> 
> http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html

And the end result is something like this:
http://rhughes.fedorapeople.org/gpk-groups-comps.png

It needs some UI review and testing, but it shows how quickly we could
add a feature. The "simple" menu will be show by default, but it'll be
simple to turn on the "advanced" group selector.

Richard.




From katzj at redhat.com  Tue Oct  7 15:12:09 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 07 Oct 2008 11:12:09 -0400
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <20081007133518.GA10140@amd.home.annexia.org>
References: <20081007133518.GA10140@amd.home.annexia.org>
Message-ID: <1223392329.754.16.camel@aglarond.local>

On Tue, 2008-10-07 at 14:35 +0100, Richard W.M. Jones wrote:
> I've got a nasty program I'm trying to package for Fedora.  To cut a
> very long story short, this C/C++ mixed program started out on Windows
> and makes lots of 32 bit assumptions.  So it's compiled with 'gcc -m32'.
> 
> Expressing the build requirements so it can build on a 64 bit platform
> is proving troublesome.  (It builds fine on i386).

In general, for these situations the right answer is to ExcludeArch and
file the appropriate tracking bugs rather than trying to do 32-bit
builds on a 64-bit arch.  The latter is only done in a few special cases
(bootloaders mainly) which don't have any external deps

Jeremy



From a.badger at gmail.com  Tue Oct  7 15:12:30 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 07 Oct 2008 08:12:30 -0700
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <48EB73B4.3070504@cora.nwra.com>
References: <20081007133518.GA10140@amd.home.annexia.org>
	<48EB73B4.3070504@cora.nwra.com>
Message-ID: <48EB7C5E.5090508@gmail.com>

Orion Poplawski wrote:
> Richard W.M. Jones wrote:
>> I've expressed that with a file dependency which breaks Fedora
>> packaging guidelines:
>>
>>   BuildRequires:  /usr/include/gnu/stubs-32.h
> 
Note: The particular Guideline is a SHOULD rather than MUST.  It also
applies to Requires, rather than BuildRequires, although that might not
be so obvious.  The intention as stated in the Guideline is to save
end-user time by allowing the depsolver to skip downloading of the large
filelists metadata file.

-Toshio


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

From denis at poolshark.org  Tue Oct  7 15:21:48 2008
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 07 Oct 2008 17:21:48 +0200
Subject: bug #464192 - help needed
In-Reply-To: <Pine.LNX.4.58.0810062228320.14270@venus.brc>
References: <Pine.LNX.4.58.0810062228320.14270@venus.brc>
Message-ID: <48EB7E8C.8030703@poolshark.org>

Zoltan Kota wrote:
> Hi,
> 
> Could anybody help with the following recode bug?
> https://bugzilla.redhat.com/show_bug.cgi?id=464192

According to the character tables of recode (as shown by 'recode -l 
cp1252'), character 0x9e does not exist. If you replace 0x9e by 0x9f, 
for example, things work. So the table is incomplete. Recode seems to 
use a reverse hash-table generated by a python script, there's probably 
a bug there somewhere in the table generation. I would file a bug upstream.



From paul at city-fan.org  Tue Oct  7 15:23:20 2008
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 07 Oct 2008 16:23:20 +0100
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <48EB7C5E.5090508@gmail.com>
References: <20081007133518.GA10140@amd.home.annexia.org>	<48EB73B4.3070504@cora.nwra.com>
	<48EB7C5E.5090508@gmail.com>
Message-ID: <48EB7EE8.4020006@city-fan.org>

Toshio Kuratomi wrote:
> Orion Poplawski wrote:
>> Richard W.M. Jones wrote:
>>> I've expressed that with a file dependency which breaks Fedora
>>> packaging guidelines:
>>>
>>>   BuildRequires:  /usr/include/gnu/stubs-32.h
> Note: The particular Guideline is a SHOULD rather than MUST.  It also
> applies to Requires, rather than BuildRequires, although that might not
> be so obvious.  The intention as stated in the Guideline is to save
> end-user time by allowing the depsolver to skip downloading of the large
> filelists metadata file.

I also had the impression (I may be wrong) that this applied more to 
runtime dependencies than build-time dependencies, for which downloading 
of the file lists is less of an issue.

Paul.



From opensource at till.name  Tue Oct  7 15:26:38 2008
From: opensource at till.name (Till Maas)
Date: Tue, 07 Oct 2008 17:26:38 +0200
Subject: Remove a branch directory completely from cvs
Message-ID: <200810071726.44086.opensource@till.name>

Hiyas,

according to the UsingCvsFaq[1] one can remove a branch directory from cvs 
with "cvs remove". I tried this, but it seems not to work. I removed 
the "FC-1" directory from pam_mount, but when I cvs co'ed the pam_mount 
directory again, an empty "FC-1" directory appeared. Is there some parameter 
I can pass to "cvs remove" to get the directory removed, too?

Regards,
Till

 [1] 
https://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#How_do_I_remove_a_branch_I_no_longer_want_or_need.3F
-------------- 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/20081007/5e3f191e/attachment.sig>

From Christian.Iseli at unil.ch  Tue Oct  7 15:43:46 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Tue, 7 Oct 2008 17:43:46 +0200
Subject: SELinux - copying ISO file content
In-Reply-To: <48EA5612.3010709@redhat.com>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<20081003091511.73410983@ludwig-alpha.unil.ch>
	<48E61B1C.70603@redhat.com>
	<20081004153856.22483543@ludwig-alpha.unil.ch>
	<48EA1B0C.8050702@redhat.com>
	<20081006193928.1c896a4b@ludwig-alpha.unil.ch>
	<48EA5612.3010709@redhat.com>
Message-ID: <20081007174346.44acda97@ludwig-alpha.unil.ch>

On Mon, 06 Oct 2008 14:16:50 -0400, Daniel J Walsh wrote:
> mount -o context="system_u:object_r:vmblock:s0"  -t vboxsf
> VMShared /mnt
> 
> Does this fix it?

Hmm, despite what is said in the manpage of mount, the option context=
appears to not be accepted in this case:
# mount -o context=system_u:object_r:vmblock:s0 -t vboxsf VMShared /mnt
unknown mount option `context="system_u:object_r:vmblock:s0"'
valid options:
  rw         mount read write (default)
  ro         mount read only
  uid       =<arg> default file owner user id
  gid       =<arg> default file owner group id
  ttl       =<arg> time to live for dentry
  iocharset =<arg> i/o charset (default utf8)
  convertcp =<arg> convert share name from given charset to utf8
  dmode     =<arg> mode of all directories
  fmode     =<arg> mode of all regular files
  umask     =<arg> umask of directories and regular files
  dmask     =<arg> umask of directories
  fmask     =<arg> umask of regular files

I suppose this is a problem of the mount.vboxfs utility rather than of
mount itself ?  In this case, I guess I'll look into filing a bug
report.

Cheers,
					Christian



From tim at niemueller.de  Tue Oct  7 15:49:49 2008
From: tim at niemueller.de (Tim Niemueller)
Date: Tue, 07 Oct 2008 17:49:49 +0200
Subject: Remove a branch directory completely from cvs
In-Reply-To: <200810071726.44086.opensource@till.name>
References: <200810071726.44086.opensource@till.name>
Message-ID: <48EB851D.4060102@niemueller.de>

Till Maas schrieb:
> Hiyas,
> 
> according to the UsingCvsFaq[1] one can remove a branch directory from cvs 
> with "cvs remove". I tried this, but it seems not to work. I removed 
> the "FC-1" directory from pam_mount, but when I cvs co'ed the pam_mount 
> directory again, an empty "FC-1" directory appeared. Is there some parameter 
> I can pass to "cvs remove" to get the directory removed, too?

That is a general problem with CVS, it cannot completely remove empty
directories, as they are needed in the repository to hold the version
information for the deleted files in the directory.

You can however prevent your checkout from creating these directories by
using "cvs checkout -P", where "-P" stands for "Prune empty directories".

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From thomas.moschny at gmail.com  Tue Oct  7 15:49:58 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Tue, 7 Oct 2008 17:49:58 +0200
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <20081007133518.GA10140@amd.home.annexia.org>
References: <20081007133518.GA10140@amd.home.annexia.org>
Message-ID: <a9d183c80810070849l7721e4f9s7dd2b82794b7b957@mail.gmail.com>

2008/10/7 Richard W.M. Jones <rjones at redhat.com>:
> I've got a nasty program I'm trying to package for Fedora.  To cut a
> very long story short, this C/C++ mixed program started out on Windows
> and makes lots of 32 bit assumptions.  So it's compiled with 'gcc -m32'.
> [...]
> The second and much larger problem is that the code uses wxGTK-devel,
> and (because it's being compiled with gcc -m32) it has to have the 32
> bit version.

Beware - the buildsystems on koji are strictly non-multilib (as
opposed to mock, the standard fedora cfg files of which once made it
non-multilib, but don't anymore).

So, even if you manage to massage the buildreqs so it builds fine
locally, it will never build on koji.

> Any ideas?  I'm sure others must have hit this problem before ...

Yes, learned that yesterday when trying to build an app that includes
a ix86-only binary.

- Thomas



From billcrawford1970 at gmail.com  Tue Oct  7 15:51:37 2008
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Tue, 7 Oct 2008 16:51:37 +0100
Subject: Remove a branch directory completely from cvs
In-Reply-To: <200810071726.44086.opensource@till.name>
References: <200810071726.44086.opensource@till.name>
Message-ID: <200810071651.37563.billcrawford1970@gmail.com>

On Tuesday 07 October 2008 16:26:38 Till Maas wrote:
> Hiyas,
>
> according to the UsingCvsFaq[1] one can remove a branch directory from cvs
> with "cvs remove". I tried this, but it seems not to work. I removed
> the "FC-1" directory from pam_mount, but when I cvs co'ed the pam_mount
> directory again, an empty "FC-1" directory appeared. Is there some
> parameter I can pass to "cvs remove" to get the directory removed, too?
>
> Regards,
> Till
>
>  [1]
> https://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#How_do_I_remo
>ve_a_branch_I_no_longer_want_or_need.3F

The way CVS works, the directory still exists in the repository. What you need 
to do is run "cvs update" with the -P option (to "prune" the empty directory).



From a.badger at gmail.com  Tue Oct  7 15:52:14 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 07 Oct 2008 08:52:14 -0700
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <48EB7EE8.4020006@city-fan.org>
References: <20081007133518.GA10140@amd.home.annexia.org>	<48EB73B4.3070504@cora.nwra.com>	<48EB7C5E.5090508@gmail.com>
	<48EB7EE8.4020006@city-fan.org>
Message-ID: <48EB85AE.5020306@gmail.com>

Paul Howarth wrote:
> Toshio Kuratomi wrote:
>> Orion Poplawski wrote:
>>> Richard W.M. Jones wrote:
>>>> I've expressed that with a file dependency which breaks Fedora
>>>> packaging guidelines:
>>>>
>>>>   BuildRequires:  /usr/include/gnu/stubs-32.h
>> Note: The particular Guideline is a SHOULD rather than MUST.  It also
>> applies to Requires, rather than BuildRequires, although that might not
>> be so obvious.  The intention as stated in the Guideline is to save
>> end-user time by allowing the depsolver to skip downloading of the large
>> filelists metadata file.
> 
> I also had the impression (I may be wrong) that this applied more to
> runtime dependencies than build-time dependencies, for which downloading
> of the file lists is less of an issue.
> 
You are correct.

-Toshio

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

From kevin at scrye.com  Tue Oct  7 16:05:36 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Tue, 7 Oct 2008 10:05:36 -0600
Subject: Remove a branch directory completely from cvs
In-Reply-To: <200810071726.44086.opensource@till.name>
References: <200810071726.44086.opensource@till.name>
Message-ID: <20081007100536.0ccb5ea5@ohm.scrye.com>

On Tue, 07 Oct 2008 17:26:38 +0200
opensource at till.name (Till Maas) wrote:

> Hiyas,
> 
> according to the UsingCvsFaq[1] one can remove a branch directory
> from cvs with "cvs remove". I tried this, but it seems not to work. I
> removed the "FC-1" directory from pam_mount, but when I cvs co'ed the
> pam_mount directory again, an empty "FC-1" directory appeared. Is
> there some parameter I can pass to "cvs remove" to get the directory
> removed, too?  

Why are you needing to do this?

Granted, not many people should need to look at what was in FC-1 much,
but it's possible there could be something there someone would want to
look at, and now all the files in there are marked dead, so it's more
of a chore to get them to look at. 

Perhaps we could look at archiving off all those old branches if they
are causing a problem?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/1dd7626c/attachment.sig>

From bpepple at fedoraproject.org  Tue Oct  7 16:12:27 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 07 Oct 2008 12:12:27 -0400
Subject: Plan for tomorrows (20081008) FESCO meeting
Message-ID: <1223395947.20446.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, Wednesday at 17:00
UTC in #fedora-meeting on irc.freenode.org (NOTE: Please note that we've
moved our start time an hour earlier):

/topic FESCo meeting -- Any objection to last week's report from FPC at
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02133.html

/topic FESCo-Meeting -- Features - all

/topic FESCo-Meeting -- MinGW follow-up? - all

/topic FESCo meeting -- Free discussion around Fedora

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.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/a506b948/attachment.sig>

From paul at city-fan.org  Tue Oct  7 16:14:13 2008
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 07 Oct 2008 17:14:13 +0100
Subject: SELinux - copying ISO file content
In-Reply-To: <20081007174346.44acda97@ludwig-alpha.unil.ch>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<20081003091511.73410983@ludwig-alpha.unil.ch>	<48E61B1C.70603@redhat.com>	<20081004153856.22483543@ludwig-alpha.unil.ch>	<48EA1B0C.8050702@redhat.com>	<20081006193928.1c896a4b@ludwig-alpha.unil.ch>	<48EA5612.3010709@redhat.com>
	<20081007174346.44acda97@ludwig-alpha.unil.ch>
Message-ID: <48EB8AD5.3020707@city-fan.org>

Christian Iseli wrote:
> On Mon, 06 Oct 2008 14:16:50 -0400, Daniel J Walsh wrote:
>> mount -o context="system_u:object_r:vmblock:s0"  -t vboxsf
>> VMShared /mnt
>>
>> Does this fix it?
> 
> Hmm, despite what is said in the manpage of mount, the option context=
> appears to not be accepted in this case:
> # mount -o context=system_u:object_r:vmblock:s0 -t vboxsf VMShared /mnt
> unknown mount option `context="system_u:object_r:vmblock:s0"'
> valid options:
>   rw         mount read write (default)
>   ro         mount read only
>   uid       =<arg> default file owner user id
>   gid       =<arg> default file owner group id
>   ttl       =<arg> time to live for dentry
>   iocharset =<arg> i/o charset (default utf8)
>   convertcp =<arg> convert share name from given charset to utf8
>   dmode     =<arg> mode of all directories
>   fmode     =<arg> mode of all regular files
>   umask     =<arg> umask of directories and regular files
>   dmask     =<arg> umask of directories
>   fmask     =<arg> umask of regular files
> 
> I suppose this is a problem of the mount.vboxfs utility rather than of
> mount itself ?  In this case, I guess I'll look into filing a bug
> report.

You want a context of system_u:object_r:vmblock_t:s0 rather than 
system_u:object_r:vmblock:s0 methinks.

Paul.



From qralston+ml.redhat-fedora-devel at andrew.cmu.edu  Tue Oct  7 16:27:22 2008
From: qralston+ml.redhat-fedora-devel at andrew.cmu.edu (James Ralston)
Date: Tue, 07 Oct 2008 12:27:22 -0400
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <20081003193834.GD23876@redhat.com>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>	<20080930193705.GB12982@amd.home.annexia.org>	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>	<20081003171721.GU18995@redhat.com>	<4F1832471BC83478D4F140D2@shieldbreaker.sei.cmu.edu>
	<20081003193834.GD23876@redhat.com>
Message-ID: <B810ED3D7B602A8EB79756D5@shieldbreaker.sei.cmu.edu>

On 2008-10-03 at 20:38+01 Daniel P Berrange <berrange at redhat.com> wrote:

> [Turning a physical network interface into a bridge] is trival from
> an implementation POV.

True--once you know you need to do so.

> I accept it is badly documented though, hence why we created that
> wiki page.

I think it would be very helpful if the "Connect to host network"
configuration screen in virt-manager mentioned this, though.  E.g.,
instead of this:

    Tip: Choose this option if your host is statically connected to
    wired ethernet, to gain the ability to migrate the virtual system.

It said this:

    Tip: Choose this option if your host is statically connected to
    wired ethernet, to gain the ability to migrate the virtual system.
    (To share a physical device, configure it as a bridge.)

Unless I hear objections, I'll BZ this against virt-manager.

> There's two different audiences really - people who are serious
> server administrators used to setting up crazy stuff like bonding,
> vlans, bridging.

Agreed.  But I think it could be a lot more obvious (even to seasoned
system administrators) that the shared physical device must be a
bridge.

> The long term goal is that network manager should be addressing
> their needs.  We don't want to implement bridging control APIs in
> libvirt, because that's just a short term hack - when people should
> really be focused on making NetworkManager better

Agreed; that seems to be a reasonable position.

-- 
STABILIZATION = CHAOS; END THE FED!
The Bailout Reader - <http://mises.org/story/3128>
Economic Depressions: Their Cause and Cure - <http://mises.org/story/3127>
Taking Money Back - <http://mises.org/story/2882>



From rjones at redhat.com  Tue Oct  7 16:56:09 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 7 Oct 2008 17:56:09 +0100
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <1223392329.754.16.camel@aglarond.local>
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
Message-ID: <20081007165609.GA10665@amd.home.annexia.org>

On Tue, Oct 07, 2008 at 11:12:09AM -0400, Jeremy Katz wrote:
> On Tue, 2008-10-07 at 14:35 +0100, Richard W.M. Jones wrote:
> > I've got a nasty program I'm trying to package for Fedora.  To cut a
> > very long story short, this C/C++ mixed program started out on Windows
> > and makes lots of 32 bit assumptions.  So it's compiled with 'gcc -m32'.
> > 
> > Expressing the build requirements so it can build on a 64 bit platform
> > is proving troublesome.  (It builds fine on i386).
> 
> In general, for these situations the right answer is to ExcludeArch and
> file the appropriate tracking bugs rather than trying to do 32-bit
> builds on a 64-bit arch.  The latter is only done in a few special cases
> (bootloaders mainly) which don't have any external deps

The issues is actually weirder / more complicated than I thought.
(But hey, Windows software, what do you expect :-)

It turns out that it's not just built for 32 bit because of the
general hideousness of the code, but because it builds Windows 32 bit
plugins.  Somehow -- and I've no idea how it does this -- the Windows
plugins get loaded into the native Fedora binary at runtime.  Even
though the main binary is Fedora native, it still has to be built as
32 bit to achieve this minor miracle.

The package is NSIS, in case you were wondering ...

http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=d9257c5046c7e63b8c00d01528031f14cf6fc319;path=/nsis/

http://www.annexia.org/tmp/mingw/fedora-9/x86_64/RPMS/mingw32-nsis-2.39-3.fc9.x86_64.rpm

$ file /usr/bin/makensis 
/usr/bin/makensis: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
$ file /usr/share/nsis/Stubs/zlib
/usr/share/nsis/Stubs/zlib: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
$ strace makensis --help 2>&1 | egrep '(Plugins|Stubs)'
open("/usr/share/nsis/Stubs/zlib", O_RDONLY) = 3
open("/usr/share/nsis/Stubs/uninst", O_RDONLY) = 3

I guess if we ExcludeArch we'll still be OK because x86-64 users will
be able to install and use the i386 version?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From jkeating at redhat.com  Tue Oct  7 16:58:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 07 Oct 2008 09:58:13 -0700
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <20081007165609.GA10665@amd.home.annexia.org>
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
Message-ID: <1223398693.4410.0.camel@luminos.localdomain>

On Tue, 2008-10-07 at 17:56 +0100, Richard W.M. Jones wrote:
> I guess if we ExcludeArch we'll still be OK because x86-64 users will
> be able to install and use the i386 version?

Not without having to hardcode this package as "multilib" to make it
show up in the x86_64 repo.  This is something we really really really
don't like doing, as hardcoded crud like this tends to break over time.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/2a44fef7/attachment.sig>

From aph at redhat.com  Tue Oct  7 17:01:35 2008
From: aph at redhat.com (Andrew Haley)
Date: Tue, 07 Oct 2008 18:01:35 +0100
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <20081007165609.GA10665@amd.home.annexia.org>
References: <20081007133518.GA10140@amd.home.annexia.org>	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
Message-ID: <48EB95EF.3060400@redhat.com>

Richard W.M. Jones wrote:
> On Tue, Oct 07, 2008 at 11:12:09AM -0400, Jeremy Katz wrote:
>> On Tue, 2008-10-07 at 14:35 +0100, Richard W.M. Jones wrote:
>>> I've got a nasty program I'm trying to package for Fedora.  To cut a
>>> very long story short, this C/C++ mixed program started out on Windows
>>> and makes lots of 32 bit assumptions.  So it's compiled with 'gcc -m32'.
>>>
>>> Expressing the build requirements so it can build on a 64 bit platform
>>> is proving troublesome.  (It builds fine on i386).
>> In general, for these situations the right answer is to ExcludeArch and
>> file the appropriate tracking bugs rather than trying to do 32-bit
>> builds on a 64-bit arch.  The latter is only done in a few special cases
>> (bootloaders mainly) which don't have any external deps
> 
> The issues is actually weirder / more complicated than I thought.
> (But hey, Windows software, what do you expect :-)
> 
> It turns out that it's not just built for 32 bit because of the
> general hideousness of the code, but because it builds Windows 32 bit
> plugins.  Somehow -- and I've no idea how it does this -- the Windows
> plugins get loaded into the native Fedora binary at runtime.  Even
> though the main binary is Fedora native, it still has to be built as
> 32 bit to achieve this minor miracle.
> 
> The package is NSIS, in case you were wondering ...
> 
> http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=d9257c5046c7e63b8c00d01528031f14cf6fc319;path=/nsis/
> 
> http://www.annexia.org/tmp/mingw/fedora-9/x86_64/RPMS/mingw32-nsis-2.39-3.fc9.x86_64.rpm
> 
> $ file /usr/bin/makensis 
> /usr/bin/makensis: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
> $ file /usr/share/nsis/Stubs/zlib
> /usr/share/nsis/Stubs/zlib: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
> $ strace makensis --help 2>&1 | egrep '(Plugins|Stubs)'
> open("/usr/share/nsis/Stubs/zlib", O_RDONLY) = 3
> open("/usr/share/nsis/Stubs/uninst", O_RDONLY) = 3
> 
> I guess if we ExcludeArch we'll still be OK because x86-64 users will
> be able to install and use the i386 version?

Weirder still.  How does zlib get built anyway?

Andrew.



From seg at haxxed.com  Tue Oct  7 17:24:34 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 07 Oct 2008 12:24:34 -0500
Subject: SELinux - copying ISO file content
In-Reply-To: <1223386945.10179.6.camel@londonpacket.bos.redhat.com>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com>  <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
Message-ID: <1223400274.26341.15.camel@localhost.localdomain>

On Tue, 2008-10-07 at 09:42 -0400, Jon Masters wrote:
> Ah yes, I probably used the standard "cp -ax blah /blah" command. I
> guess I'll need to learn not to use such standard commands in future and
> adapt everything around SELinux. Because that's very non-obtrusive, and
> won't cause regular users any anguish at all.

If I understand correctly, the root of the problem here is you're using
kernel modules that we do not ship and are not merged upstream. You
chose to play with fire, and you got burned. I think it is very unfair
to solely blame SELinux for this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/337c3cf1/attachment.sig>

From dimi at lattica.com  Tue Oct  7 17:33:22 2008
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 07 Oct 2008 13:33:22 -0400
Subject: No dynamic groups in PackageKit : Solved
In-Reply-To: <1223392160.25444.12.camel@hughsie-laptop>
References: <48D542A9.1070600@leemhuis.info>
	<48D5552C.1000700@fedoraproject.org>
	<loom.20080920T195843-984@post.gmane.org>	<48D63D1E.4070806@leemhuis.info>
	<48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com>
	<loom.20080921T212341-346@post.gmane.org>	<48D726C0.4060208@leemhuis.info>
	<1222066065.19471.6.camel@rousalka.okg>
	<1222072903.3330.3.camel@hughsie-work>
	<1222107615.4108.23.camel@luminos.localdomain>
	<1222115665.24063.14.camel@hughsie-work>
	<1222150606.30758.65.camel@code.and.org>
	<48D897E6.4090600@googlemail.com>
	<1223392160.25444.12.camel@hughsie-laptop>
Message-ID: <1223400802.5270.7.camel@dimi.lattica.com>


On Tue, 2008-10-07 at 16:09 +0100, Richard Hughes wrote:
> And the end result is something like this:
> http://rhughes.fedorapeople.org/gpk-groups-comps.png

Nice. But I would get rid of "Window Managers" from under
"Desktop Environments" if we can, it's at the wrong abstraction
level and no regular user will figure out what the heck it
means. It just complicates the options.


In this day and age, customizing the window manager is something that
the hard-core hacker would do...

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From kevin.kofler at chello.at  Tue Oct  7 17:40:15 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 7 Oct 2008 17:40:15 +0000 (UTC)
Subject: How to package code compiled with 'gcc -m32'?
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
Message-ID: <loom.20081007T173256-441@post.gmane.org>

Richard W.M. Jones <rjones <at> redhat.com> writes:
> It turns out that [NSIS is] not just built for 32 bit because of the
> general hideousness of the code, but because it builds Windows 32 bit
> plugins.  Somehow -- and I've no idea how it does this -- the Windows
> plugins get loaded into the native Fedora binary at runtime.

Those plugins don't actually get loaded into the Fedora binary. They get packed 
into the generated installer image.

> Even though the main binary is Fedora native, it still has to be built as
> 32 bit to achieve this minor miracle.

The Debian folks worked hard on making NSIS build as a true 64-bit binary, not 
with -m32, and as far as I know their patches got merged upstream already.

The W32 plugins need to be built with the MinGW cross-compiler of course, not 
the native compiler, so they aren't affected by this problem at all.

I can have a try at making a proper x86_64 package with the plugins actually 
built from source. What I know is that my hack (packaging the binary plugins 
from the prebuilt ZIP and rebuilding makensis from source as 64-bit) worked.

What's clear is that 32-bit binaries on a 64-bit system are not a solution, you 
have to be very special like WINE to get away with this (and even WINE is not 
built with -m32, it's simply copied from the i386 repo by a multilib whitelist 
entry; fake x86_64 packages with 32-bit stuff in it are a bad idea), NSIS has 
really no valid reason to use 32-bit binaries.

        Kevin Kofler



From jkeating at redhat.com  Tue Oct  7 17:52:01 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 07 Oct 2008 10:52:01 -0700
Subject: No dynamic groups in PackageKit : Solved
In-Reply-To: <1223400802.5270.7.camel@dimi.lattica.com>
References: <48D542A9.1070600@leemhuis.info>
	<48D5552C.1000700@fedoraproject.org>
	<loom.20080920T195843-984@post.gmane.org>	<48D63D1E.4070806@leemhuis.info>
	<48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com>
	<loom.20080921T212341-346@post.gmane.org>	<48D726C0.4060208@leemhuis.info>
	<1222066065.19471.6.camel@rousalka.okg>
	<1222072903.3330.3.camel@hughsie-work>
	<1222107615.4108.23.camel@luminos.localdomain>
	<1222115665.24063.14.camel@hughsie-work>
	<1222150606.30758.65.camel@code.and.org>
	<48D897E6.4090600@googlemail.com>
	<1223392160.25444.12.camel@hughsie-laptop>
	<1223400802.5270.7.camel@dimi.lattica.com>
Message-ID: <1223401921.4410.17.camel@luminos.localdomain>

On Tue, 2008-10-07 at 13:33 -0400, Dimi Paun wrote:
> 
> Nice. But I would get rid of "Window Managers" from under
> "Desktop Environments" if we can, it's at the wrong abstraction
> level and no regular user will figure out what the heck it
> means. It just complicates the options.
> 
> 
> In this day and age, customizing the window manager is something that
> the hard-core hacker would do...

That would be a change necessary at the Fedora comps level.  Patches?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/dd354cae/attachment.sig>

From jkeating at redhat.com  Tue Oct  7 17:55:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 07 Oct 2008 10:55:07 -0700
Subject: SELinux - copying ISO file content
In-Reply-To: <1223400274.26341.15.camel@localhost.localdomain>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com>  <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
	<1223400274.26341.15.camel@localhost.localdomain>
Message-ID: <1223402107.4410.20.camel@luminos.localdomain>

On Tue, 2008-10-07 at 12:24 -0500, Callum Lerwick wrote:
> If I understand correctly, the root of the problem here is you're using
> kernel modules that we do not ship and are not merged upstream. You
> chose to play with fire, and you got burned. I think it is very unfair
> to solely blame SELinux for this one.

Pardon?  What module is he using here that we don't ship?  He mounted
the iso, and copied files.  Where is he using a 3rd party module?

Somebody else jumped on the thread and steered the conversation toward a
virtualbox problem, which somewhat related to Jon's issue, it's not the
same issue.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/e6f4e60e/attachment.sig>

From orion at cora.nwra.com  Tue Oct  7 18:04:00 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 07 Oct 2008 12:04:00 -0600
Subject: Mysterious cmake failure on ppc64
In-Reply-To: <loom.20081007T122616-52@post.gmane.org>
References: <loom.20081007T122616-52@post.gmane.org>
Message-ID: <48EBA490.2060702@cora.nwra.com>

Kevin Kofler wrote:
> I get this while trying to build kdepim-4.1.2-2.fc10 for dist-f10 on ppc64:
> -- Looking for include files SYS_INOTIFY_H_FOUND - found
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  basic_string::erase
> /var/tmp/rpm-tmp.SsHcUA: line 47: 26805 
> Aborted                 /usr/bin/cmake -DLIB_SUFFIX=64 [...]
> error: Bad exit status from /var/tmp/rpm-tmp.SsHcUA (%build)
> 
> This is reproducible (I tried resubmitting it twice, all 3 builds failed).
> 
> The only change with respect to kdepim-4.1.2-1.fc10, which built successfully, 
> is that this is a rebuild against the new libgnokii, but I don't see how that 
> can be responsible. Maybe some other package changed in the buildroot, causing 
> this?
> 
>         Kevin Kofler
> 

Well, cmake changed:

< DEBUG util.py:250:   cmake                   ppc64 
2.6.2-0.rc3.1.fc10  build             6.3 M 

--- 

 > DEBUG util.py:250:   cmake                   ppc64      2.6.2-1.fc10 
     build

I submitted a scratch build here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=867010

with:

%{cmake_kde4} --debug-output ..

in an attempt to diagnose.  Low and behold it got farther.  If it 
completes successfully then you might use that as a work around for the 
time being.  Next step is to debug using David Woodhouse's machine...


-- 
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 ffesti at redhat.com  Tue Oct  7 18:07:55 2008
From: ffesti at redhat.com (Florian Festi)
Date: Tue, 07 Oct 2008 20:07:55 +0200
Subject: Remove a branch directory completely from cvs
In-Reply-To: <200810071726.44086.opensource@till.name>
References: <200810071726.44086.opensource@till.name>
Message-ID: <48EBA57B.9020203@redhat.com>

  *** Insert thread about "CVS vs YourFavouriteVCS" here ***



From fedora at leemhuis.info  Tue Oct  7 18:07:56 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 07 Oct 2008 20:07:56 +0200
Subject: Proposed discussion point (Re: Plan for tomorrows (20081008) FESCO
 meeting)
In-Reply-To: <1223395947.20446.2.camel@kennedy>
References: <1223395947.20446.2.camel@kennedy>
Message-ID: <48EBA57C.7000309@leemhuis.info>

On 07.10.2008 18:12, Brian Pepple wrote:
 >
> /topic FESCo meeting -- Free discussion around Fedora
> 
> 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.

Seems we are about to get proper suppose for comps.xml in PK sooner or 
later; for details see
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00381.html

Which brings us back to the following mail from last month (which 
resulted in a long discussion that afaics indirectly was one of the 
reasons for the new PK enhancements we'll get...)
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01813.html

The main two questions, where I'd really like to see advice from FESCo 
(or whatever committee feels responsible for this kind of task) how to 
move on:

- Which packages should be in comps.xml and which not? (?)

- How do we make packagers add all their packages to comps.xml?

(?) https://fedoraproject.org/wiki/PackageMaintainers/CompsXml reads 
right now:
"""
If you maintain an application which makes sense for a user to select 
during installation, check out the comps module and make sure that your 
package is listed in a reasonable group in the comps-fn.xml.in files.
"""
A exacter definition of "makes sense to select" afaics really is needed; 
one example: Do users want to select command line app? I'd say the 
answer is "yes", but others will disagree. Same for -devel packages.

Further: I think the "during installation" part needs to be removed again.

(?)  According to
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus/CompsF10Missing
"We have 2866 packages in comps-f10 file."
"We have 1711 packages missing"

I'm not sure those stats are correct, as we afaik have way more source 
and binary packages:

$ repoquery --repoid=rawhide -a | wc -l ; repoquery \
         --repoid=rawhide-source --arch=src -a | wc -l
14139
6300

CU
knurd

P.S.: There is a old FESCo schedule task that dealt with the same topic, 
but was forgotten during the Core and Extras merge:
http://fedoraproject.org/wiki/Extras/Schedule/UseCompsProperly
http://fedoraproject.org/wiki/Extras/Schedule/ExtrasCompsXml

There is also a comps.xml SIG
https://fedoraproject.org/wiki/Category:Comps_SIG
Is that SIG still active?



From opensource at till.name  Tue Oct  7 18:31:49 2008
From: opensource at till.name (Till Maas)
Date: Tue, 07 Oct 2008 20:31:49 +0200
Subject: Remove a branch directory completely from cvs
In-Reply-To: <20081007100536.0ccb5ea5@ohm.scrye.com>
References: <200810071726.44086.opensource@till.name>
	<20081007100536.0ccb5ea5@ohm.scrye.com>
Message-ID: <200810072032.03794.opensource@till.name>

On Tue October 7 2008, Kevin Fenzi wrote:
> On Tue, 07 Oct 2008 17:26:38 +0200
>
> (Till Maas) wrote:

> > according to the UsingCvsFaq[1] one can remove a branch directory
> > from cvs with "cvs remove". I tried this, but it seems not to work. I
> > removed the "FC-1" directory from pam_mount, but when I cvs co'ed the
> > pam_mount directory again, an empty "FC-1" directory appeared. Is
> > there some parameter I can pass to "cvs remove" to get the directory
> > removed, too?
>
> Why are you needing to do this?
>
> Granted, not many people should need to look at what was in FC-1 much,
> but it's possible there could be something there someone would want to
> look at, and now all the files in there are marked dead, so it's more
> of a chore to get them to look at.

Using the viewcvs webinterface, it is pretty easy to get the dead files:
http://cvs.fedoraproject.org/viewvc/rpms/pam_mount/FC-1/?hideattic=0

I guess there is also some commandline option that allows to easily access 
these files.

> Perhaps we could look at archiving off all those old branches if they
> are causing a problem?

After I got this working, the next step was to suggest to remove all old 
branches (F-7 and older) for every package in the near future.

The reason why I want this done, is that they mess up some packages, where 
there are now 10 or more branch directories. Also it takes unecessarily long 
for to checkout packages. Especially packages that not only have many 
branches, but also a lot of patches.

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/20081007/b9657722/attachment.sig>

From christoph.wickert at googlemail.com  Tue Oct  7 18:37:50 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 07 Oct 2008 20:37:50 +0200
Subject: Disappointed: My feature was removed without noticing me
Message-ID: <1223404671.24360.51.camel@wicktop.localdomain>

I have been informed that my LXDE feature [1] has been removed from F10
and delayed fore F11. I'm very disappointed about that, especially
because nobody cared to inform me about this decision.

I knew my feature was late, but I did everything I could to rescue it. I
followed all the advice from the feature wrangler, what more could I do?
Upon this question the feature wrangler told my that I had to watch
fedora-devel-announce and especially the meeting minutes. But this won't
help because no announcement has been made on the list and the latest
meeting minutes were published on September 10th. (BTW: Meeting minutes
seem to be published only sporadic recently.)

Looking through the IRC log [2] I find only very little information
about the LXDE removal. The topic was discussed very shortly and the
decision was made by only 2 people. And I think it was based on wrong
information. wwoods incorrectly assumed there were _no_ LXDE packages
ready yet, nirik corrected him the _some_ are ready, but in fact _all_
except two are.
The only argument that's sounds convincing to me (although I don't
really understand it) is nottings concerns about the breaking the string
freeze. Can somebody please explain this a little more in depth to me?
Looking at the F10 schedule i see string freeze was on September 11, so
why did nobody realize that my feature collided with string freeze
anyway?

So my questions are:
     1. If we could finish the reviews within the next two days, is
        there still a chance left to get this feature into F10?
     2. If we can't get it ready as a feature, can I at least get the
        missing packages into F10 and make rel-eng tag them final?
     3. Why did nobody (ether someone from FesCO or the feature
        wrangler) cared to inform me? If they have a question, why
        didn't they ask me instead of making incorrect assumptions?
     4. Why have I not been notified about the wiki edit of the feature
        wrangler, although the page is on my watchlist?

To be honest: I feel I have been bilked of my work by people who did not
even read the feature page or the reviews in bugzilla completely and
therefor were not informed properly.

I'm very disappointed :(
Christoph


[1] https://fedoraproject.org/w/index.php?title=Features/LXDE
[2] http://bpepple.fedorapeople.org/fesco/FESCo-2008-09-24.html



From dpquigl at tycho.nsa.gov  Tue Oct  7 18:23:11 2008
From: dpquigl at tycho.nsa.gov (David P. Quigley)
Date: Tue, 07 Oct 2008 14:23:11 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <1223386945.10179.6.camel@londonpacket.bos.redhat.com>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com>  <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
Message-ID: <1223403791.31539.135.camel@moss-terrapins.epoch.ncsc.mil>

On Tue, 2008-10-07 at 09:42 -0400, Jon Masters wrote:
> On Mon, 2008-10-06 at 15:17 -0500, Jerry Vonau wrote:
> > Daniel J Walsh wrote:
> > > Jon Masters wrote:
> > >> On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:
> > >>
> > >>>> $ mount -o loop Fedora-9-i386-DVD.iso /mnt
> > >>>>
> > >>>> And then one might legitimately expect to be able to copy the content
> > >>>> of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
> > >>>> suppose that one is running SELinux in enforcing mode, then this will
> > >>>> fail because the contexts differ in this operation. Then, one will
> > >>>> likely quickly become severely annoyed and frustrated with SELinux,
> > >>>> simply setting it permissive for the duration of the operation...
> > 
> > I've seen this...
> 
> Indeed. I have too, one too many times.
> 
> > SELinux is preventing cp from creating a file with a context of 
> > iso9660_t on a
> > filesystem.
> 
> Ah yes, I probably used the standard "cp -ax blah /blah" command. I
> guess I'll need to learn not to use such standard commands in future and
> adapt everything around SELinux. Because that's very non-obtrusive, and
> won't cause regular users any anguish at all.
> 
> Jon.
> 
> 

I think the main question here is should archive try to retain the
SELinux context. From what I've heard from people here, initially the
idea was to try to preserve the context and if that failed fall back to
labeling based on the parent. That doesn't seem to be what cp is trying
to do. If we removed the retain the context part from the archive switch
of cp you would get labeling based on the parent but then you would be
required to explicitly specify preserve the context when you wanted to
archive that as well. 

It doesn't seem like anyone is actually depending on the associate
permission so it might be worth someone looking into removing it if no
one is really using it. It has its applications but I don't believe Red
Hat is using it at this time.

Dave



From email.ahmedkamal at googlemail.com  Tue Oct  7 18:44:46 2008
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Tue, 7 Oct 2008 20:44:46 +0200
Subject: Upgrading to F10 was a bad experience
Message-ID: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>

Hi,
I just upgraded a perfectly fine F9 installation into F10-beta. And
the experience was not too good! Please find issues below

1- Right after anaconda starts, I switched back to tty1, and noticed
the following somehow scary messages "DB4 error database envrionment
version mismatch" "Cannot open packages database"! Please find a
screensot attached "rpmdb-ver-mismatch.jpg"

2- Anaconda does not start in the correct wide screen resolution
1280x800. Nothing major, but still looks bad

3- At the end of the upgrade, the tiny message window before the
reboot button appears kept flickering very heavily for 5 minutes+. I
took a video snapshot if anyone is interested!

4- After the first restart, noticed so many file system and sendmail
notes of "File modification time in the future .. fixing" ?!

5- Then a major bumper, X startx, the mouse is there with the circles
running around it, however GDM does not appear ... I wait and wait ...
nothing. I log into text mode, and find this message
"Oct  7 19:48:01 kamal-lappy gdm-simple-slave[3100]: WARNING: Could
not spawn command: Failed to execute child process
"/usr/bin/gnome-session" (No such file
or directory)
Oct  7 19:48:01 kamal-lappy gdm-simple-slave[3100]: WARNING: Could not
start command '/usr/bin/gnome-session
--autostart=/usr/share/gdm/autostart/LoginWindow
/': Failed to execute child process "/usr/bin/gnome-session" (No such
file or directory)"
I am primarily a KDE user, and I did check and gnome-session is not
there. Don't know why it is in this endless loop though as F9 was
working fine. Anyway, I logged into text mode, switched to runlevel 3,
and used startkde to start KDE and it worked fine

6- Once KDE is started, its fonts look extremely jaggy and bad!
Perhaps this is because I am now not on the closed nvidia driver!

7- Another major bumper, firefox does not start. Starting it from a
terminal, and I get this
[root at kamal-lappy ~]# firefox
Couldn't load XPCOM.
Nothing more!!

8-  Well, right now I am writing this in konqueror, the arrow keys are
not working as well ! Perhaps because of the way I started X


I upgraded to beta in order to test since the devs requested such
tests. I did not expect so many issues though! And I really wouldn't
mind quick fixes and work arounds to get myself back in shape :D
All the best of luck
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpmdb-ver-mismatch.jpg
Type: image/jpeg
Size: 37167 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/c1bcc5e8/attachment.jpg>

From rjones at redhat.com  Tue Oct  7 18:46:02 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 7 Oct 2008 19:46:02 +0100
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <48EB95EF.3060400@redhat.com>
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
	<48EB95EF.3060400@redhat.com>
Message-ID: <20081007184602.GA11246@amd.home.annexia.org>

On Tue, Oct 07, 2008 at 06:01:35PM +0100, Andrew Haley wrote:
> Weirder still.  How does zlib get built anyway?

>From source using the MinGW cross-compiler.

  http://fedoraproject.org/wiki/MinGW

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From notting at redhat.com  Tue Oct  7 18:46:26 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 7 Oct 2008 14:46:26 -0400
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223404671.24360.51.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
Message-ID: <20081007184626.GB4377@nostromo.devel.redhat.com>

Christoph Wickert (christoph.wickert at googlemail.com) said: 
> The only argument that's sounds convincing to me (although I don't
> really understand it) is nottings concerns about the breaking the string
> freeze. Can somebody please explain this a little more in depth to me?
> Looking at the F10 schedule i see string freeze was on September 11, so
> why did nobody realize that my feature collided with string freeze
> anyway?

Groups in comps (and their descriptions) are translatable strings; adding
or changing them breaks the string freeze.

Bill



From rjones at redhat.com  Tue Oct  7 18:51:27 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 7 Oct 2008 19:51:27 +0100
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <loom.20081007T173256-441@post.gmane.org>
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
	<loom.20081007T173256-441@post.gmane.org>
Message-ID: <20081007185127.GB11246@amd.home.annexia.org>

On Tue, Oct 07, 2008 at 05:40:15PM +0000, Kevin Kofler wrote:
> Richard W.M. Jones <rjones <at> redhat.com> writes:
> > It turns out that [NSIS is] not just built for 32 bit because of the
> > general hideousness of the code, but because it builds Windows 32 bit
> > plugins.  Somehow -- and I've no idea how it does this -- the Windows
> > plugins get loaded into the native Fedora binary at runtime.
> 
> Those plugins don't actually get loaded into the Fedora binary. They get packed 
> into the generated installer image.

Aha ... I'm glad someone knows what's going on here (not me :-)

I thought that the Stubs were copied into the output binary, but the
Plugins got loaded into the executable, but I seem to be wrong about
that.

> > Even though the main binary is Fedora native, it still has to be built as
> > 32 bit to achieve this minor miracle.
>
> The Debian folks worked hard on making NSIS build as a true 64-bit
> binary, not with -m32, and as far as I know their patches got merged
> upstream already.  The W32 plugins need to be built with the MinGW
> cross-compiler of course, not the native compiler, so they aren't
> affected by this problem at all.

I'm actually using Debian's patch, but I rebased them against 2.39.
Debian is on 2.19 for reasons I can't determine, but 2.19 doesn't
build on Fedora (it looked like a gcc error, but I didn't examine it
in great detail, because the newer version builds fine).

> I can have a try at making a proper x86_64 package with the plugins
> actually built from source. What I know is that my hack (packaging
> the binary plugins from the prebuilt ZIP and rebuilding makensis
> from source as 64-bit) worked.

Please, and if you can supply patches against our repository, or I can
get you commit access, then all the better.

Of course, building anything from binaries isn't acceptable.  It has
to be all built from source.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From christoph.wickert at googlemail.com  Tue Oct  7 18:51:27 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 07 Oct 2008 20:51:27 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <20081007184626.GB4377@nostromo.devel.redhat.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
Message-ID: <1223405487.24360.55.camel@wicktop.localdomain>

Am Dienstag, den 07.10.2008, 14:46 -0400 schrieb Bill Nottingham:
> Christoph Wickert (christoph.wickert at googlemail.com) said: 
> > The only argument that's sounds convincing to me (although I don't
> > really understand it) is nottings concerns about the breaking the string
> > freeze. Can somebody please explain this a little more in depth to me?
> > Looking at the F10 schedule i see string freeze was on September 11, so
> > why did nobody realize that my feature collided with string freeze
> > anyway?
> 
> Groups in comps (and their descriptions) are translatable strings; adding
> or changing them breaks the string freeze.

Ok then, but why did nobody from FeSCo or rel-eng realize that before?

And are translations really that important? It's only two strings and I
remember that we had not-translated comps before.

> 
> Bill
> 

Regards,
Christoph



From opensource at till.name  Tue Oct  7 18:50:23 2008
From: opensource at till.name (Till Maas)
Date: Tue, 07 Oct 2008 20:50:23 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223404671.24360.51.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
Message-ID: <200810072050.37778.opensource@till.name>

On Tue October 7 2008, Christoph Wickert wrote:

>      4. Why have I not been notified about the wiki edit of the feature
>         wrangler, although the page is on my watchlist?

The problem with the watchlist is, that you get only one notification after 
the last time you visited the page while you were logged in. If you only 
click on the link provided in the notification and to not care to login, 
because you do not need to edit something, you will still get no further 
notification. The best workaround I currently now, is to use an rss reader 
and add a feed for each page you want to look at, e.g.
https://fedoraproject.org/w/index.php?title=Features/LXDE&action=history&feed=atom

Afaik, these feeds may still aggregate some changes into one news item, but I 
guess this may not be a big problem.

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/20081007/de1fc9a4/attachment.sig>

From rjones at redhat.com  Tue Oct  7 18:55:13 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 7 Oct 2008 19:55:13 +0100
Subject: Plan for tomorrows (20081008) FESCO meeting
In-Reply-To: <1223395947.20446.2.camel@kennedy>
References: <1223395947.20446.2.camel@kennedy>
Message-ID: <20081007185513.GC11246@amd.home.annexia.org>

On Tue, Oct 07, 2008 at 12:12:27PM -0400, Brian Pepple wrote:
> /topic FESCo-Meeting -- MinGW follow-up? - all

We're still waiting on infrastructure to make a decision regarding
this ticket:

  https://hosted.fedoraproject.org/fedora-infrastructure/ticket/807

so unless something happens tomorrow, there's not much point talking
about this at FESCo tomorrow night.

Technically speaking, things are coming along well though.  The latest
work is available here:

  http://hg.et.redhat.com/misc/fedora-mingw--devel
  http://www.annexia.org/tmp/mingw/fedora-9/

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From rjones at redhat.com  Tue Oct  7 18:56:05 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 7 Oct 2008 19:56:05 +0100
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <20081007185127.GB11246@amd.home.annexia.org>
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
	<loom.20081007T173256-441@post.gmane.org>
	<20081007185127.GB11246@amd.home.annexia.org>
Message-ID: <20081007185605.GD11246@amd.home.annexia.org>

On Tue, Oct 07, 2008 at 07:51:27PM +0100, Richard W.M. Jones wrote:
> Please, and if you can supply patches against our repository, 

http://hg.et.redhat.com/misc/fedora-mingw--devel

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From christoph.wickert at googlemail.com  Tue Oct  7 18:57:03 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 07 Oct 2008 20:57:03 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <200810072050.37778.opensource@till.name>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<200810072050.37778.opensource@till.name>
Message-ID: <1223405823.24360.59.camel@wicktop.localdomain>

Am Dienstag, den 07.10.2008, 20:50 +0200 schrieb Till Maas:
> On Tue October 7 2008, Christoph Wickert wrote:
> 
> >      4. Why have I not been notified about the wiki edit of the feature
> >         wrangler, although the page is on my watchlist?
> 
> The problem with the watchlist is, that you get only one notification after 
> the last time you visited the page while you were logged in. 

This can't be the reason in my case: Poelstra edited the page and before
I was the last one who did. So "only one" notification should have been
sufficient, I should have gotten that one.

Regards,
Christoph



From notting at redhat.com  Tue Oct  7 19:00:53 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 7 Oct 2008 15:00:53 -0400
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223405487.24360.55.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<1223405487.24360.55.camel@wicktop.localdomain>
Message-ID: <20081007190053.GA4882@nostromo.devel.redhat.com>

Christoph Wickert (christoph.wickert at googlemail.com) said: 
> > > The only argument that's sounds convincing to me (although I don't
> > > really understand it) is nottings concerns about the breaking the string
> > > freeze. Can somebody please explain this a little more in depth to me?
> > > Looking at the F10 schedule i see string freeze was on September 11, so
> > > why did nobody realize that my feature collided with string freeze
> > > anyway?
> > 
> > Groups in comps (and their descriptions) are translatable strings; adding
> > or changing them breaks the string freeze.
> 
> Ok then, but why did nobody from FeSCo or rel-eng realize that before?

I'm not sure what you mean. The feature is supposed to be testable by
the feature freeze, which is the same time as the string freeze. So it
doesn't need called out specifically unless it *doesn't* make the feature
freeze.

Bill



From rjones at redhat.com  Tue Oct  7 19:06:54 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 7 Oct 2008 20:06:54 +0100
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223404671.24360.51.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
Message-ID: <20081007190654.GE11246@amd.home.annexia.org>

On Tue, Oct 07, 2008 at 08:37:50PM +0200, Christoph Wickert wrote:
> Looking through the IRC log [2] I find only very little information
> about the LXDE removal. The topic was discussed very shortly and the
> decision was made by only 2 people. And I think it was based on wrong
> information. wwoods incorrectly assumed there were _no_ LXDE packages
> ready yet, nirik corrected him the _some_ are ready, but in fact _all_
> except two are.

Yes, I think it's disappointing that hard work gets dropped like this.
It's verging on deletionism, which was the reason I left wikipedia.

The Haskell feature was dropped at the same meeting just because the
guy maintaining it wasn't there.  Probably he didn't know the meeting
was happening because he didn't read some announcement in one of the
multitude of mailing lists that we need to keep up with.  Or being in
Europe, he might have been busy at 7/8pm in the evening.

As a positive take from this, I think that the meeting organizer
should CC all people who should be at the meeting, when sending the
announcement.  I also think that FESCo members shouldn't comment on
proposals unless they are technically au fait with them.  This means
FESCo members taking some time each week to do technical work with the
projects.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From jamatos at fc.up.pt  Tue Oct  7 19:07:51 2008
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Tue, 7 Oct 2008 20:07:51 +0100
Subject: Upgrading to F10 was a bad experience
In-Reply-To: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
References: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
Message-ID: <200810072007.52451.jamatos@fc.up.pt>

On Tuesday 07 October 2008 19:44:46 Ahmed Kamal wrote:
> 8- ?Well, right now I am writing this in konqueror, the arrow keys are
> not working as well ! Perhaps because of the way I started X

Go to systemsettings and see if you have a keyboard selected there:

Country/Region & Language -> keyboard layout

and select "disabled keyboard layouts". That should work. The same happened to 
me before FWIW.

-- 
Jos? Ab?lio



From christoph.wickert at googlemail.com  Tue Oct  7 19:11:45 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 07 Oct 2008 21:11:45 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <20081007190053.GA4882@nostromo.devel.redhat.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<1223405487.24360.55.camel@wicktop.localdomain>
	<20081007190053.GA4882@nostromo.devel.redhat.com>
Message-ID: <1223406705.24360.67.camel@wicktop.localdomain>

Am Dienstag, den 07.10.2008, 15:00 -0400 schrieb Bill Nottingham:
> Christoph Wickert (christoph.wickert at googlemail.com) said: 
> > > > The only argument that's sounds convincing to me (although I don't
> > > > really understand it) is nottings concerns about the breaking the string
> > > > freeze. Can somebody please explain this a little more in depth to me?
> > > > Looking at the F10 schedule i see string freeze was on September 11, so
> > > > why did nobody realize that my feature collided with string freeze
> > > > anyway?
> > > 
> > > Groups in comps (and their descriptions) are translatable strings; adding
> > > or changing them breaks the string freeze.
> > 
> > Ok then, but why did nobody from FeSCo or rel-eng realize that before?
> 
> I'm not sure what you mean. The feature is supposed to be testable by
> the feature freeze, which is the same time as the string freeze. So it
> doesn't need called out specifically unless it *doesn't* make the feature
> freeze.

Ok, agreed, but when feature freeze was on Sept. 11th, then they could
have told me _much_earlier_ that my feature was out of luck anyway.
Maybe we would have find a way cope with that, for example already make
the comps changes so the strings are there for translation.

> Bill
> 
Christoph



From christoph.wickert at googlemail.com  Tue Oct  7 19:16:46 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 07 Oct 2008 21:16:46 +0200
Subject: [Correction] Disappointed: My feature was removed without noticing
	me
In-Reply-To: <1223404671.24360.51.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
Message-ID: <1223407006.24360.73.camel@wicktop.localdomain>

Am Dienstag, den 07.10.2008, 20:37 +0200 schrieb Christoph Wickert:
> I have been informed that my LXDE feature [1] has been removed from F10
> and delayed fore F11. I'm very disappointed about that, especially
> because nobody cared to inform me about this decision.
> 
> I knew my feature was late, but I did everything I could to rescue it. I
> followed all the advice from the feature wrangler, what more could I do?
> Upon this question the feature wrangler told my that I had to watch
> fedora-devel-announce and especially the meeting minutes. But this won't
> help because no announcement has been made on the list and the latest
> meeting minutes were published on September 10th. (BTW: Meeting minutes
> seem to be published only sporadic recently.)

Just for the record: I just found the missing meeting summaries, they
were published correctly. My bad :(
Nevertheless I do not feel informed properly and I think FeSCo meeting
summaries should go over fedora-devel-announce.

Christoph



From mike at miketc.net  Tue Oct  7 19:23:24 2008
From: mike at miketc.net (Mike Chambers)
Date: Tue, 07 Oct 2008 14:23:24 -0500
Subject: rawhide report: 20081007 changes
In-Reply-To: <20081007122139.32DA01F81CF@releng2.fedora.phx.redhat.com>
References: <20081007122139.32DA01F81CF@releng2.fedora.phx.redhat.com>
Message-ID: <1223407404.4482.7.camel@scrappy.miketc.net>

On Tue, 2008-10-07 at 12:21 +0000, Rawhide Report wrote:

> anaconda-11.4.1.44-1
> --------------------
> * Mon Oct  6 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.44-1
> - Do not rely on loaderData->noDns to tell if we have DNS configured.
>   (dcantrell)
> - Skip askmethod dialog if user passes repo= and stage2= (dcantrell)
> - Reset resolver in get_connection() (dcantrell)
> - Fix problems dealing with PXE boot and the ksdevice= parameter. (dcantrell)
> - Disable more IPv6 code in loader for now. (dcantrell)
> - Write BOOTPROTO=static for manual IPv4 config. (dcantrell)
> - Disable IPv6 widgets for F-10. (dcantrell)
> - Add iwlagn driver firmware (#465508). (clumens)
> - Move starting HAL to after we've probed for hardware. (clumens)
> - Don't try to load a couple modules that no longer exist. (clumens)
> - The Chinese font package has changed names (#465290). (clumens)
> - Fix a traceback when there's no ksdevice given (#465638). (clumens)
> - Fix traceback in post install configuration (hans)

Tried a rawhide install this morning after I got it sync'd..

1 - Language selection screen wouldn't pull in any languages (this
happened before) and therefore nothing to select.

2 - When using the "askmethod" option, when configuring a static
network, after putting in ipv4 info (IP, netmask, etc.) and hitting
ok/next/continue/forward button, get some type of error bout ipv6 but
cant' remember what it said.  Either I hit a button or it did it on it's
own and continued on.

3 - This next step from above, may or may not be related, but when I put
in my server name and path to rawhide, it said couldn't find
image(s)/stage2.img or install.img or something like that.  And I know
the dir is mounted and works fine.  Couldn't go any further at this
point.

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From loganjerry at gmail.com  Tue Oct  7 18:20:16 2008
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 7 Oct 2008 12:20:16 -0600
Subject: Proposed discussion point (Re: Plan for tomorrows (20081008)
	FESCO meeting)
In-Reply-To: <48EBA57C.7000309@leemhuis.info>
References: <1223395947.20446.2.camel@kennedy> <48EBA57C.7000309@leemhuis.info>
Message-ID: <870180fe0810071120p788101a6yd0ffb1b394409f90@mail.gmail.com>

On Tue, Oct 7, 2008 at 12:07 PM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> - How do we make packagers add all their packages to comps.xml?

Here's something to consider during this discussion.  I haven't added
all of my packages to comps.xml because there is no group which is
really appropriate for several of them.  I don't want to add them to
some group that is only peripherally related to the function of the
package, and I'm too lazy to figure out how to add new groups [1].  I
suspect other package maintainers may have similar reasons for
dragging their feet.

Footnotes:
[1] Well, not really lazy, but I recognize that adding groups is a
significant step, and so it needs to be well justified.  I am very
busy with Real Life right now, so time spent putting together such a
justification means no time for other activities that I'm more eager
to engage in [2].
[2] Like watching the value of my retirement account fall.
-- 
Jerry James
http://loganjerry.googlepages.com/



From opensource at till.name  Tue Oct  7 18:16:59 2008
From: opensource at till.name (Till Maas)
Date: Tue, 07 Oct 2008 20:16:59 +0200
Subject: Remove a branch directory completely from cvs
In-Reply-To: <48EB851D.4060102@niemueller.de>
References: <200810071726.44086.opensource@till.name>
	<48EB851D.4060102@niemueller.de>
Message-ID: <200810072017.14239.opensource@till.name>

On Tue October 7 2008, Tim Niemueller wrote:

> You can however prevent your checkout from creating these directories by
> using "cvs checkout -P", where "-P" stands for "Prune empty directories".

Thank you, this works.

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/20081007/5e4dba69/attachment.sig>

From a.badger at gmail.com  Tue Oct  7 19:48:21 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 07 Oct 2008 12:48:21 -0700
Subject: Plan for tomorrows (20081008) FESCO meeting
In-Reply-To: <20081007185513.GC11246@amd.home.annexia.org>
References: <1223395947.20446.2.camel@kennedy>
	<20081007185513.GC11246@amd.home.annexia.org>
Message-ID: <48EBBD05.6030706@gmail.com>

Richard W.M. Jones wrote:
> On Tue, Oct 07, 2008 at 12:12:27PM -0400, Brian Pepple wrote:
>> /topic FESCo-Meeting -- MinGW follow-up? - all
> 
> We're still waiting on infrastructure to make a decision regarding
> this ticket:
> 
>   https://hosted.fedoraproject.org/fedora-infrastructure/ticket/807
> 
Note: dgilmore is the guy in charge of this.  dgilmore, do you think
you'll have an update on this for the meeting tomorrow?

-Toshio

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

From ajax at redhat.com  Tue Oct  7 20:10:44 2008
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 07 Oct 2008 16:10:44 -0400
Subject: Upgrading to F10 was a bad experience
In-Reply-To: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
References: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
Message-ID: <1223410244.3674.18.camel@atropine.boston.devel.redhat.com>

On Tue, 2008-10-07 at 20:44 +0200, Ahmed Kamal wrote:

> 2- Anaconda does not start in the correct wide screen resolution
> 1280x800. Nothing major, but still looks bad

Anaconda's UI is not scalable.  We try to start at 800x600 because
that's a conservative size and is therefore what the UI is designed for.

There is a corner case where we'll accept whatever resolution the X
server gives us, but it's not guaranteed.

> 8-  Well, right now I am writing this in konqueror, the arrow keys are
> not working as well ! Perhaps because of the way I started X

Something changed your XKB keyboard model away from evdev.  Don't do
that.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/c03f6c0a/attachment.sig>

From orion at cora.nwra.com  Tue Oct  7 20:29:35 2008
From: orion at cora.nwra.com (orion at cora.nwra.com)
Date: Tue, 7 Oct 2008 14:29:35 -0600 (MDT)
Subject: Mysterious cmake failure on ppc64
In-Reply-To: <48EBA490.2060702@cora.nwra.com>
References: <loom.20081007T122616-52@post.gmane.org>
	<48EBA490.2060702@cora.nwra.com>
Message-ID: <1882.71.208.51.222.1223411375.squirrel@www.cora.nwra.com>

> Kevin Kofler wrote:
>> I get this while trying to build kdepim-4.1.2-2.fc10 for dist-f10 on
>> ppc64:
>> -- Looking for include files SYS_INOTIFY_H_FOUND - found
>> terminate called after throwing an instance of 'std::out_of_range'
>>   what():  basic_string::erase
>> /var/tmp/rpm-tmp.SsHcUA: line 47: 26805
>> Aborted                 /usr/bin/cmake -DLIB_SUFFIX=64 [...]
>> error: Bad exit status from /var/tmp/rpm-tmp.SsHcUA (%build)
>>
>> This is reproducible (I tried resubmitting it twice, all 3 builds
>> failed).
>>
>> The only change with respect to kdepim-4.1.2-1.fc10, which built
>> successfully,
>> is that this is a rebuild against the new libgnokii, but I don't see how
>> that
>> can be responsible. Maybe some other package changed in the buildroot,
>> causing
>> this?
>>
>>         Kevin Kofler
>>
>
> Well, cmake changed:
>
> < DEBUG util.py:250:   cmake                   ppc64
> 2.6.2-0.rc3.1.fc10  build             6.3 M
>
> ---
>
>  > DEBUG util.py:250:   cmake                   ppc64      2.6.2-1.fc10
>      build
>
> I submitted a scratch build here:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=867010
>
> with:
>
> %{cmake_kde4} --debug-output ..
>
> in an attempt to diagnose.  Low and behold it got farther.  If it
> completes successfully then you might use that as a work around for the
> time being.  Next step is to debug using David Woodhouse's machine...

Can't reproduce on David's machine.  Looks like it does fail in different
locations in the koji builds (although always in some test).  Not sure
what to check now...

- Orion




From Christian.Iseli at unil.ch  Tue Oct  7 20:34:09 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Tue, 7 Oct 2008 22:34:09 +0200
Subject: SELinux - copying ISO file content
In-Reply-To: <1223402107.4410.20.camel@luminos.localdomain>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com> <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
	<1223400274.26341.15.camel@localhost.localdomain>
	<1223402107.4410.20.camel@luminos.localdomain>
Message-ID: <20081007223409.19bc8223@ludwig-alpha.unil.ch>

On Tue, 07 Oct 2008 10:55:07 -0700, Jesse Keating wrote:
> Somebody else jumped on the thread and steered the conversation
> toward a virtualbox problem, which somewhat related to Jon's issue,
> it's not the same issue.

Right, mea culpa and sorry about that.  I thought my problem had the
same root as the OP's problem, but it now appears I was wrong...

Cheers,
					Christian



From dex.mbox at googlemail.com  Tue Oct  7 20:40:59 2008
From: dex.mbox at googlemail.com (dexter)
Date: Tue, 7 Oct 2008 21:40:59 +0100
Subject: Upgrading to F10 was a bad experience
In-Reply-To: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
References: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
Message-ID: <200810072140.59743.dex.mbox@gmail.com>

On Tue October 7 2008 19:44:46 Ahmed Kamal wrote:
> Hi,
>
> 6- Once KDE is started, its fonts look extremely jaggy and bad!
> Perhaps this is because I am now not on the closed nvidia driver!
>
confirmed with ati driver also ...

> 8-  Well, right now I am writing this in konqueror, the arrow keys are
> not working as well ! Perhaps because of the way I started X
>
confirmed with X out the box ...
OTOH kubuntu beta (ibex) comes up with opengl bling from the getgo, F10 
freeeeezes when switched (ati 9200se) 
>
> I upgraded to beta in order to test since the devs requested such
> tests. I did not expect so many issues though! And I really wouldn't
> mind quick fixes and work arounds to get myself back in shape :D
> All the best of luck
file bugz sit back and wait ...

...dex



From Christian.Iseli at unil.ch  Tue Oct  7 20:45:14 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Tue, 7 Oct 2008 22:45:14 +0200
Subject: Proposed discussion point (Re: Plan for tomorrows (20081008)
 FESCO meeting)
In-Reply-To: <48EBA57C.7000309@leemhuis.info>
References: <1223395947.20446.2.camel@kennedy> <48EBA57C.7000309@leemhuis.info>
Message-ID: <20081007224514.53161f84@ludwig-alpha.unil.ch>

On Tue, 07 Oct 2008 20:07:56 +0200, Thorsten Leemhuis wrote:
> (?)  According to
> http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus/CompsF10Missing
> "We have 2866 packages in comps-f10 file."
> "We have 1711 packages missing"
> 
> I'm not sure those stats are correct, as we afaik have way more
> source and binary packages:
> 
> $ repoquery --repoid=rawhide -a | wc -l ; repoquery \
>          --repoid=rawhide-source --arch=src -a | wc -l
> 14139
> 6300

The discrepancy can be (at least partly) explained by the fact that the
script producing the missing stats has some heuristics about packages
to ignore.  Package names matching these regexps are not flagged as
missing:
    next if $k =~ /plugin/i;
    next if $k =~ /^(lib|compat-|xfce4-|gtk-|kmod-|fonts?-)/i;
    next if $k =~ /(-devel|lib[s0-9]*|-python|-perl|-servers?|-clients?|-tools?)$/i;
    next if $k =~ /(-contribs?|-docs?|-x?emacs|-utils?|-fonts?)$/i;
Package having a summary containing this regexp:
      next if $BZOWN->{$k}->{'summary'} =~ /(binding|library|module|utilit)/i;
And there is a short blacklist:
  "autodownloader" => 1,
  "theora-exp" => 1,
  "freetype1" => 1,
  "paragui" => 1

HTH...

Cheers,
					Christian



From email.ahmedkamal at googlemail.com  Tue Oct  7 20:57:47 2008
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Tue, 7 Oct 2008 22:57:47 +0200
Subject: Upgrading to F10 was a bad experience
In-Reply-To: <200810072140.59743.dex.mbox@gmail.com>
References: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
	<200810072140.59743.dex.mbox@gmail.com>
Message-ID: <3da3b5b40810071357x2b59858jf6e4b5c5e9ab4118@mail.gmail.com>

Seems like we need upgrades in rawhide fixes most issues. So upgrade
everything first
I hope I can still use KDE to switch keyboard languages, not so sure if that
moves off evdev!

On Tue, Oct 7, 2008 at 10:40 PM, dexter <dex.mbox at googlemail.com> wrote:

> On Tue October 7 2008 19:44:46 Ahmed Kamal wrote:
> > Hi,
> >
> > 6- Once KDE is started, its fonts look extremely jaggy and bad!
> > Perhaps this is because I am now not on the closed nvidia driver!
> >
> confirmed with ati driver also ...
>
> > 8-  Well, right now I am writing this in konqueror, the arrow keys are
> > not working as well ! Perhaps because of the way I started X
> >
> confirmed with X out the box ...
> OTOH kubuntu beta (ibex) comes up with opengl bling from the getgo, F10
> freeeeezes when switched (ati 9200se)
> >
> > I upgraded to beta in order to test since the devs requested such
> > tests. I did not expect so many issues though! And I really wouldn't
> > mind quick fixes and work arounds to get myself back in shape :D
> > All the best of luck
> file bugz sit back and wait ...
>
> ...dex
>
> --
> 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/20081007/9209c13e/attachment.htm>

From wolfy at nobugconsulting.ro  Tue Oct  7 21:34:46 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Wed, 08 Oct 2008 00:34:46 +0300
Subject: Plan for tomorrows (20081008) FESCO meeting
In-Reply-To: <1223395947.20446.2.camel@kennedy>
References: <1223395947.20446.2.camel@kennedy>
Message-ID: <48EBD5F6.4080306@nobugconsulting.ro>

On 10/07/2008 07:12 PM, 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, Wednesday at 17:00
> UTC in #fedora-meeting on irc.freenode.org (NOTE: Please note that we've
> moved our start time an hour earlier):
>
> /topic FESCo meeting -- Any objection to last week's report from FPC at
> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02133.html
>
> /topic FESCo-Meeting -- Features - all
>
> /topic FESCo-Meeting -- MinGW follow-up? - all
>
> /topic FESCo meeting -- Free discussion around Fedora
>
> 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.
>
> Later,
> /B
could you guys also take a decision regarding the vendor_id for desktop 
files?
http://fedoraproject.org/wiki/Packaging/Minutes20080603#t12:15 suggests 
one thing, but the Guidelines page still insists on enforcing it. I 
would like to have it cleared so that we can go on with 
https://bugzilla.redhat.com/show_bug.cgi?id=462381

Thanks
    manuel



From a.badger at gmail.com  Tue Oct  7 21:50:07 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 07 Oct 2008 14:50:07 -0700
Subject: Plan for tomorrows (20081008) FESCO meeting
In-Reply-To: <48EBD5F6.4080306@nobugconsulting.ro>
References: <1223395947.20446.2.camel@kennedy>
	<48EBD5F6.4080306@nobugconsulting.ro>
Message-ID: <48EBD98F.9090202@gmail.com>

Manuel Wolfshant wrote:
> On 10/07/2008 07:12 PM, 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, Wednesday at 17:00
>> UTC in #fedora-meeting on irc.freenode.org (NOTE: Please note that we've
>> moved our start time an hour earlier):
>>
>> /topic FESCo meeting -- Any objection to last week's report from FPC at
>> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02133.html
>>
>>
>> /topic FESCo-Meeting -- Features - all
>>
>> /topic FESCo-Meeting -- MinGW follow-up? - all
>>
>> /topic FESCo meeting -- Free discussion around Fedora
>>
>> 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.
>>
>> Later,
>> /B
> could you guys also take a decision regarding the vendor_id for desktop
> files?
> http://fedoraproject.org/wiki/Packaging/Minutes20080603#t12:15 suggests
> one thing, but the Guidelines page still insists on enforcing it. I
> would like to have it cleared so that we can go on with
> https://bugzilla.redhat.com/show_bug.cgi?id=462381
> 
IIRC, this is waiting on Matthias to let us know that the menu tools can
handle the switch.

If that's going to take a while, I'd like to see us drop the vendor
recomendation for new packages (but we'll have to keep it for old
packages until the tools can handle it.)

Note that this is an FPC item rather than a FESCo item.

-Toshio

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

From bpepple at fedoraproject.org  Tue Oct  7 23:04:14 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 07 Oct 2008 19:04:14 -0400
Subject: Proposed discussion point (Re: Plan for tomorrows (20081008)
	FESCO meeting)
In-Reply-To: <48EBA57C.7000309@leemhuis.info>
References: <1223395947.20446.2.camel@kennedy> <48EBA57C.7000309@leemhuis.info>
Message-ID: <1223420654.32021.5.camel@kennedy>

On Tue, 2008-10-07 at 20:07 +0200, Thorsten Leemhuis wrote:
> On 07.10.2008 18:12, Brian Pepple wrote:
> > 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.
> 
> Seems we are about to get proper suppose for comps.xml in PK sooner or 
> later; for details see
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00381.html
> 
> Which brings us back to the following mail from last month (which 
> resulted in a long discussion that afaics indirectly was one of the 
> reasons for the new PK enhancements we'll get...)
> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01813.html
> 
> The main two questions, where I'd really like to see advice from FESCo 
> (or whatever committee feels responsible for this kind of task) how to 
> move on:
> 
> - Which packages should be in comps.xml and which not? (?)
> 
> - How do we make packagers add all their packages to comps.xml?

Added to the schedule.  Thanks.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081007/22917b3a/attachment.sig>

From poelstra at redhat.com  Tue Oct  7 23:11:21 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 07 Oct 2008 16:11:21 -0700
Subject: Fedora Release Engineering Meeting Recap 2008-10-06
Message-ID: <48EBEC99.3020204@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-oct-06

Please make corrections and clarifications to the wiki page.

== Ticket Review ==
* (spins for Fedora 9) - Fedora Release Engineering - Trac - 
https://fedorahosted.org/rel-eng/ticket/24
** Need feedback from spin owners
* (Add a time stamp to the rawhide info) - Fedora Release Engineering - 
Trac - https://fedorahosted.org/rel-eng/ticket/25
* (F9 Postmortem follow-up) - Fedora Release Engineering - Trac - 
https://fedorahosted.org/rel-eng/ticket/106
** f13 to add updates
* (infrastructure for creating desktop live cds daily) - Fedora Release 
Engineering - Trac - https://fedorahosted.org/rel-eng/ticket/764
* (Resign everything) - Fedora Release Engineering - Trac - 
https://fedorahosted.org/rel-eng/ticket/767
** progressing--almost done
** see IRC log for details
* (spam-o-matic uses provides rather than package name in some 
instances) - Fedora Release Engineering - Trac - 
https://fedorahosted.org/rel-eng/ticket/832

== Fedora 10 Snapshot 1 ==
* Coming this week
* Concerns about stability of anaconda

== IRC Transcript ==



From fedora at leemhuis.info  Wed Oct  8 05:32:08 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 08 Oct 2008 07:32:08 +0200
Subject: No dynamic groups in PackageKit : Solved
In-Reply-To: <1223392160.25444.12.camel@hughsie-laptop>
References: <48D542A9.1070600@leemhuis.info>	<48D5552C.1000700@fedoraproject.org>	<loom.20080920T195843-984@post.gmane.org>	<48D63D1E.4070806@leemhuis.info>	<48D63F92.8000608@leemhuis.info>
	<48D67ED6.6040405@googlemail.com>	<loom.20080921T212341-346@post.gmane.org>	<48D726C0.4060208@leemhuis.info>	<1222066065.19471.6.camel@rousalka.okg>	<1222072903.3330.3.camel@hughsie-work>	<1222107615.4108.23.camel@luminos.localdomain>	<1222115665.24063.14.camel@hughsie-work>	<1222150606.30758.65.camel@code.and.org>	<48D897E6.4090600@googlemail.com>
	<1223392160.25444.12.camel@hughsie-laptop>
Message-ID: <48EC45D8.3010303@leemhuis.info>

On 07.10.2008 17:09, Richard Hughes wrote:
> On Tue, 2008-09-23 at 09:16 +0200, Tim Lauridsen wrote:
>> I think this discussion is getting a little heated and it is not the 
>> most constructive, if you want something to change IMHO.
> Tim is spot on, 

Tim, Richard, many thanks for your great work! Much appreciated!

> and a good example of someone that does things properly
> rather than just ranting about how broken $something is.

Remember, we have a lot of skilled people here on the list -- not all of
them are programmers (disclaimer: I'm one of them), but nevertheless
they afaics do a lot of important work for Fedora (art, bugtracking,
getting things organized and dozens of other areas...); they of course
sometimes want to share there option on things that happen in area they
are normally not working -- I think that's a good think and you are IMHO
discouraging those people way to much with sentences like that.

> I really can't believe how rude some people are on this list.

I would not call it rude. Most if not all of us that participate in
discussions care of Fedora and want to see it improved. But the people
of course disagree about how that is done -- that sometimes lead to hot
discussions, just like two people that are married for a quite a while
(and what to stay married) sometimes have a heated conflict ;-)

And communicating by mail makes things a whole lot more complicated and
worse afaics, as that form of communication sometimes simply doesn't
work well -- especially if people are not very careful (and all of us
sometimes are not careful enough afaics).

   > [...]
>> I agree in there is some issues with the static groups currently in
>> pk.so i have made this proposal on the upstream packagekit list.
>> http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html
> And the end result is something like this:
> http://rhughes.fedorapeople.org/gpk-groups-comps.png

Looks great. BTW, is this targeted for 0.3.x or 0.4.x?.

But nevertheless please allow me to ask one thing: You said "Tri-state
checkboxes are a disaster" last month on this list. I don't doubt that.
But nevertheless they in Pirut make something possible that is (afaics
from the screenshot; it was not obvious where that code lives, otherwise 
I#d taken a closer look myself) not possible with PK: get a whole bunch 
of apps (e.g. get KDE with one click if you installed the Gnome spin) 
installed  or uninstalled by (de)selecting just one checkbox.

It IMHO would be nice to have such kind of function in PK as well. Is
that still there somewhere? Maybe something like the additional "Package
Collections" ( http://www.packagekit.org/img/gpk-application-search.png
; second entry on the left side) could still work together with the new 
scheme? Then users can select  the default set of a group there; most 
will not even notive that the  collection names are the same as the 
names for the package group.

   > [...]

CU
knurd



From fedora at leemhuis.info  Wed Oct  8 05:36:20 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 08 Oct 2008 07:36:20 +0200
Subject: Proposed discussion point (Re: Plan for tomorrows (20081008)
 FESCO meeting)
In-Reply-To: <20081007224514.53161f84@ludwig-alpha.unil.ch>
References: <1223395947.20446.2.camel@kennedy> <48EBA57C.7000309@leemhuis.info>
	<20081007224514.53161f84@ludwig-alpha.unil.ch>
Message-ID: <48EC46D4.1030103@leemhuis.info>

On 07.10.2008 22:45, Christian Iseli wrote:
> On Tue, 07 Oct 2008 20:07:56 +0200, Thorsten Leemhuis wrote:
>> (?)  According to
>> http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus/CompsF10Missing
>> "We have 2866 packages in comps-f10 file."
>> "We have 1711 packages missing"
>>
>> I'm not sure those stats are correct, as we afaik have way more
>> source and binary packages:
>>
>> $ repoquery --repoid=rawhide -a | wc -l ; repoquery \
>>          --repoid=rawhide-source --arch=src -a | wc -l
>> 14139
>> 6300
> 
> The discrepancy can be (at least partly) explained by the fact that the
> script producing the missing stats has some heuristics about packages
> to ignore.  Package names matching these regexps are not flagged as
> missing:
>     next if $k =~ /plugin/i;
>     next if $k =~ /^(lib|compat-|xfce4-|gtk-|kmod-|fonts?-)/i;
>     next if $k =~ /(-devel|lib[s0-9]*|-python|-perl|-servers?|-clients?|-tools?)$/i;
>     next if $k =~ /(-contribs?|-docs?|-x?emacs|-utils?|-fonts?)$/i;
> Package having a summary containing this regexp:
>       next if $BZOWN->{$k}->{'summary'} =~ /(binding|library|module|utilit)/i;
> And there is a short blacklist:
>   "autodownloader" => 1,
>   "theora-exp" => 1,
>   "freetype1" => 1,
>   "paragui" => 1
> 
> HTH...

Yes, it does, as this seems to be quite relevant for the "Which packages 
should be in comps.xml and which not?" question.

CU
knurd



From gilboad at gmail.com  Wed Oct  8 08:12:38 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 08 Oct 2008 10:12:38 +0200
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
Message-ID: <1223453558.10878.2.camel@gilboa-home-dev.localdomain>

On Fri, 2008-10-03 at 13:11 -0400, James Ralston wrote:
>     2.  Setting up a public bridge is a snap in Xen.  In KVM, it is
>         massively complex (i.e., virt-manager can't do it), and
>         requires tools (tunctl) Fedora doesn't even provide:
> 
>         http://kvm.qumranet.com/kvmwiki/Networking

tunctl is provided by Fedora. (Using it right now to run Windows under
qemu-kvm)
Yes, setting up a bridged network is a huge pain in the back side, but I
don't remember Xen being any different. (Though, in Xen's defense,
pciback.hide is a -great- feature if you want to virtualize firewalls
and web servers)

- Gilboa



From hughsient at gmail.com  Wed Oct  8 08:12:45 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 08 Oct 2008 09:12:45 +0100
Subject: No dynamic groups in PackageKit : Solved
In-Reply-To: <48EC45D8.3010303@leemhuis.info>
References: <48D542A9.1070600@leemhuis.info>
	<48D5552C.1000700@fedoraproject.org>
	<loom.20080920T195843-984@post.gmane.org>	<48D63D1E.4070806@leemhuis.info>
	<48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com>
	<loom.20080921T212341-346@post.gmane.org>	<48D726C0.4060208@leemhuis.info>
	<1222066065.19471.6.camel@rousalka.okg>
	<1222072903.3330.3.camel@hughsie-work>
	<1222107615.4108.23.camel@luminos.localdomain>
	<1222115665.24063.14.camel@hughsie-work>
	<1222150606.30758.65.camel@code.and.org>	<48D897E6.4090600@googlemail.com>
	<1223392160.25444.12.camel@hughsie-laptop>
	<48EC45D8.3010303@leemhuis.info>
Message-ID: <1223453565.3415.8.camel@hughsie-laptop>

On Wed, 2008-10-08 at 07:32 +0200, Thorsten Leemhuis wrote:
> On 07.10.2008 17:09, Richard Hughes wrote:
> > I really can't believe how rude some people are on this list.
> And communicating by mail makes things a whole lot more complicated and
> worse afaics, as that form of communication sometimes simply doesn't
> work well -- especially if people are not very careful (and all of us
> sometimes are not careful enough afaics).

Sure, I totally agree. When writing an email my rule of thumb is to read
the sentence aloud and think "would I say this to someone on the phone"?
-- It's very easy to call software a piece of crap on a mailing list,
but not so easy when you're talking to the author in person :-)

> Looks great. BTW, is this targeted for 0.3.x or 0.4.x?.

0.3.7, should be in rawhide on Monday.

> But nevertheless please allow me to ask one thing: You said "Tri-state
> checkboxes are a disaster" last month on this list. I don't doubt that.
> But nevertheless they in Pirut make something possible that is (afaics
> from the screenshot; it was not obvious where that code lives, otherwise 
> I#d taken a closer look myself) not possible with PK: get a whole bunch 
> of apps (e.g. get KDE with one click if you installed the Gnome spin) 
> installed  or uninstalled by (de)selecting just one checkbox.

Sure, I still think tri-state checkboxes are a disaster.

> It IMHO would be nice to have such kind of function in PK as well. Is
> that still there somewhere? Maybe something like the additional "Package
> Collections" ( http://www.packagekit.org/img/gpk-application-search.png
> ; second entry on the left side) could still work together with the new 
> scheme?

Yes, good idea. Collections should be installable for both menu types.

> Then users can select  the default set of a group there; most 
> will not even notive that the  collection names are the same as the 
> names for the package group.

Right.

Thanks for the feedback,

Richard.




From gilboad at gmail.com  Wed Oct  8 08:12:38 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 08 Oct 2008 10:12:38 +0200
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
Message-ID: <1223453558.10878.2.camel@gilboa-home-dev.localdomain>

On Fri, 2008-10-03 at 13:11 -0400, James Ralston wrote:
>     2.  Setting up a public bridge is a snap in Xen.  In KVM, it is
>         massively complex (i.e., virt-manager can't do it), and
>         requires tools (tunctl) Fedora doesn't even provide:
> 
>         http://kvm.qumranet.com/kvmwiki/Networking

tunctl is provided by Fedora. (Using it right now to run Windows under
qemu-kvm)
Yes, setting up a bridged network is a huge pain in the back side, but I
don't remember Xen being any different. (Though, in Xen's defense,
pciback.hide is a -great- feature if you want to virtualize firewalls
and web servers)

- Gilboa



From ml at deadbabylon.de  Wed Oct  8 09:00:04 2008
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Wed, 8 Oct 2008 11:00:04 +0200
Subject: KDE-SIG weekly report (41/2008)
Message-ID: <20081008110004.18268edf@moorgarten.schwarmsted>

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: 41/2008

Time: 2008-10-07 16:00 UTC

Meeting page:
https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-07

Meeting log:
http://fedoraproject.org/w/uploads/c/c3/KDE-SIG-2008-10-07.txt

----------------------------------------------------------------------------------

= Participants =

* JaroslavReznik
* KevinKofler
* LorenzoVillani
* LukasTinkl
* RexDieter
* SebastianVahl
* StevenParrish
* ThanNgo 

----------------------------------------------------------------------------------

= Agenda =

* Replacing gnome-packagekit with kpackagekit on KDE live images?
* Mysterious cmake failure on ppc64 [1]
* Plasma backports? (see also plasma-4.1-openSUSE [2])
* KMix multimedia key support (Kubuntu patch)
* find-lang-like macro for KDE documentation 

= Summary =

kpackagekit:
------------
* The decision of making kpackagekit the default on the live images
was postponed to next week.
* So there will be some extra time to test kpackagekit. 

Mysterious cmake failure on ppc64:
----------------------------------
* ppc64 builds of kdepim always fail with various cmake errors. [1]
* This also prevents us from fixing the broken libgnokii.so.3
dependency.
* It's unclear what's going wrong there. 

Plasma backports?:
-------------------------------------------------
* OpenSUSE did some backports of plasma features in their KDE-4.1
version. [2]
* At least the autohide functionality [3] of the plasma panel is also
interesting for us (and was also frequently requested).
* A problem will be that all these backports will be (mostly)
untranslated until KDE-4.2.
* We'll try to backport the autohide functionality with avoiding
the unnecessary string changes in it's translation.
* Another intersting one is the folderview backport [4] with the
ability to save icon positions across sessions.
* But here these changes aren't properly isolated and don't worth
the trouble of a backport. 

KMix multimedia key support:
----------------------------
* Kubuntu has implemented support for multimedia keys in kmix.
* KevinKofler isolated the needed changes. [5]
* One big disadvantage is that the volume slider is always
hardcoded to "Master:0".
* It also introduces some new strings that aren't translated yet.
* Another disadvantage is that Kubuntu's patch isn't send to
upstream yet.
* We'll talk to the responsible Kubuntu maintainer first before
making further decisions. 


find-lang-like macro for KDE documentation:
-------------------------------------------
*  %find_lang doesn't has proper support for KDE documentation at
the moment.
* It should be patched to better support the "--kde" parameter
* The currently used copy&pasted scripts could be avoided then.
* Another solution could be a macro in kde-filesystem.
* The advantage here will be that we could implement this earlier
(though %find_lang is the better place for this). 

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-14

----------------------------------------------------------------------------------

= Links =

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00366.html
[2] http://websvn.kde.org/branches/work/plasma-4.1-openSUSE/?view=log
[3] http://websvn.kde.org/?view=rev&revision=864493
[4] http://websvn.kde.org/?view=rev&revision=863348
[5]
http://repo.calcforge.org/f10/kubuntu_02_kmix_keyboard_shortcuts.diff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/9dae0fce/attachment.sig>

From mcepl at redhat.com  Wed Oct  8 09:01:58 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 08 Oct 2008 11:01:58 +0200
Subject: Obsoletes question: codeina
References: <1223285354.6012.33.camel@hughsie-laptop>
	<48E9DF19.60909@city-fan.org> <1223288392.6012.37.camel@hughsie-laptop>
Message-ID: <6h9ur5x3a4.ln2@ppp1053.in.ipex.cz>

On 2008-10-06, 10:19 GMT, Richard Hughes wrote:
> On Mon, 2008-10-06 at 10:49 +0100, Paul Howarth wrote:
>> How about this?
>> 
>> Obsoletes: codeina < 0.10.1-10
>> Provides:  codeina = 0.10.1-10
>
> Yup, I'll do this, thanks.

Or probably even better is:

Obsoletes: codeina < 0.10.1-10
Provides:  codeina = %{version}-%{release}

Or maybe not, you have to decide whether the codeina name has any 
meaning aside from being the older package (like for example 
gecko-libs even aside from xulrunner).

Mat?j




From kevin.kofler at chello.at  Wed Oct  8 09:25:18 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 09:25:18 +0000 (UTC)
Subject: Disappointed: My feature was removed without noticing me
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
Message-ID: <loom.20081008T092258-152@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
> Groups in comps (and their descriptions) are translatable strings; adding
> or changing them breaks the string freeze.

Does "LXDE" really need to be translated? Can't we just use "LXDE" as the 
category name? We could also easily write a script which takes the translations 
for "KDE desktop" (or "XFCE desktop"), does a s/KDE/LXDE/ and puts that as the 
translation of "LXDE desktop" (and refuses the translation with a warning 
if "KDE" doesn't appear, just in case it has been transliterated).

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct  8 09:36:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 09:36:44 +0000 (UTC)
Subject: How to package code compiled with 'gcc -m32'?
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
	<loom.20081007T173256-441@post.gmane.org>
	<20081007185127.GB11246@amd.home.annexia.org>
Message-ID: <loom.20081008T092911-618@post.gmane.org>

Richard W.M. Jones <rjones <at> redhat.com> writes:
> I'm actually using Debian's patch, but I rebased them against 2.39.
> Debian is on 2.19 for reasons I can't determine, but 2.19 doesn't
> build on Fedora (it looked like a gcc error, but I didn't examine it
> in great detail, because the newer version builds fine).

Hmmm, I've looked at the Debian experimental package (which is 2.39 - stable 
works mostly like RHEL, with even stricter policies about version upgrades; 
unstable and experimental are where all their development happens), but they 
now switched to building with -m32 like upstream. :-(

The patch you used, on the other hand, is outdated, it was for a version before 
upstream added the -m32, so it doesn't remove the -m32.

Try the 64bit-fixes patch in:
http://repo.calcforge.org/fedora/9/SRPMS/nsis-2.34-1.src.rpm
I also have a patch there to use the RPM_OPT_FLAGS, which is also important, 
but might need fixing to not try to pass the RPM_OPT_FLAGS to the plugin 
builds. (As I said, I haven't tried actually building the plugins yet.)

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct  8 09:44:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 09:44:02 +0000 (UTC)
Subject: Disappointed: My feature was removed without noticing me
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
Message-ID: <loom.20081008T094231-77@post.gmane.org>

I wrote:
> Does "LXDE" really need to be translated? Can't we just use "LXDE" as the 
> category name?

Looking at it, that's exactly what XFCE already does, so why can't LXDE just do 
the same? A proper noun needs no translation.

> We could also easily write a script which takes the translations for "KDE
> desktop" (or "XFCE desktop"), does a s/KDE/LXDE/ and puts that as the
> translation of "LXDE desktop" (and refuses the translation with a warning 
> if "KDE" doesn't appear, just in case it has been transliterated).

This turns out not to make sense, as KDE's string is "KDE (K Desktop 
Environment)" and XFCE's string is just "XFCE".

        Kevin Kofler



From rawhide at fedoraproject.org  Wed Oct  8 10:21:50 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed,  8 Oct 2008 10:21:50 +0000 (UTC)
Subject: rawhide report: 20081008 changes
Message-ID: <20081008102150.CD4491F81CF@releng2.fedora.phx.redhat.com>

Compose started at Wed Oct  8 06:01:09 UTC 2008

New package bouncycastle-mail
        S/MIME and CMS libraries for Bouncy Castle
New package hulahop
        A pygtk widget for embedding mozilla
New package hunspell-mk
        Macedonian hunspell dictionaries
New package hunspell-tl
        Tagalog hunspell dictionaries
New package libss7
        SS7 protocol services to applications
New package nagios-plugins-check_sip
        A Nagios plugin to check SIP servers and devices
New package obexd
        D-Bus service for Obex Client access
New package perl-Text-SpellChecker
        OO interface for spell-checking a block of text
Removed package gtkmozembedmm
Updated Packages:

R2spec-2.5.1-1.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Pingou <pingou-at-pingoured.fr> 2.5.1-1
- New upstream release


Xaw3d-1.5E-12.fc10
------------------
* Mon Oct  6 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.5E-12
- Remove obsolete PreReq and Prefix stuff from specfile
- Fix BuildRoot to match the guidelines
- Require base package by full EVR from devel package
- Drop non relevant Patches and Sources
- Rebase the still relevant patches
- Actually apply the still relevant patches
- Add a patch from Debian fixing an infinite loop (rh436998)
- Add patches from Debian fixes various potential bufferoverflows


aqsis-1.4.1-3.fc10
------------------
* Wed Oct  8 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.1-3
- backport gcc43 fix for bake.cpp

* Wed Oct  8 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.1-2
- backport patch for intsize problem

* Mon Sep 29 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.1-1
- Update to 1.4.1

* Fri Jul 25 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.0-1
- Update to 1.4.0


bind-9.5.1-0.8.b2.fc10
----------------------
* Tue Oct  7 18:00:00 2008 Adam Tkac <atkac redhat com> 32:9.5.1-0.8.b2
- removed bind-9.4.0-dnssec-directory.patch, it is wrong


blender-2.47-5.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 2.47-5
- Reorganisation directory structure to fix sysinfo.py issue

* Tue Oct  7 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 2.47-4
- Avoid duplicate python script (#465810)


ecryptfs-utils-59-1.fc10
------------------------
* Tue Oct  7 18:00:00 2008 Mike Halcrow <mhalcrow at us.ibm.com> 59-1
- Put attr declaration in the right spot

* Tue Oct  7 18:00:00 2008 Mike Halcrow <mhalcrow at us.ibm.com> 59-0
- Make /sbin/*ecryptfs* files setuid
- Add /sbin path to ecryptfs-setup-private


eric-4.2.2a-1.fc10
------------------
* Wed Oct  8 18:00:00 2008 Johan Cwiklinski <johan AT x-tnd DOT be> 4.2.2a-1
- 4.2.2a


file-4.26-2.fc10
----------------
* Tue Oct  7 18:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 4.26-2
- fix #463809: rpmbuild rpmfcClassify: Assertion fails on some binary files
  (false positive test on "DOS device driver" crashed file(1)
   and rpmbuild(8) failed)


galeon-2.0.7-2.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.0.7-2
- Added patches to fix default font (#212616) and printing (#449806). Yay.


gcompris-8.4.7-1.fc10
---------------------
* Tue Oct  7 18:00:00 2008 Johan Cwiklinski <johan AT x-tnd DOT be> 8.4.7-1
- New upstream bugfix release 8.4.7


gegl-0.0.20-1.fc10
------------------
* Tue Oct  7 18:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 0.0.20-1
- Update to latest release


ghdl-0.27-0.105svn.0.fc10
-------------------------
* Tue Oct  7 18:00:00 2008 Thomas Sailer <t.sailer at alumni.ethz.ch> - 0.27-0.105svn.0
- update to svn105


gimp-2.6.0-2.fc10
-----------------
* Tue Oct  7 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.0-2
- move gimptool to devel subpackage
- make gimp-plugin-mgr not require gimptool/pkg-config (#465869)


gnome-phone-manager-0.60-3.fc10
-------------------------------
* Tue Oct  7 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.60-3
- Rebuild for new libgnokii


gpicview-0.1.10-1.fc10
----------------------
* Sun Sep 14 18:00:00 2008 Marc Wiriadisastra <marc at mwiriadi.id.au> - 0.1.10-1
- New upstream release


gvfs-1.0.1-5.fc10
-----------------
* Tue Oct  7 18:00:00 2008 Tomas Bzatek <tbzatek at redhat.com>  - 1.0.1-5
- Don't make warnings fatal (resolves #465693)


jd-2.0.3-0.1.svn2379_trunk.fc10
-------------------------------
* Wed Oct  8 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2379


kdepim-4.1.2-2.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-2
- rebuild for new gnokii


latencytop-0.4-2.fc10
---------------------
* Tue Oct  7 18:00:00 2008 Michal Schmidt <mschmidt at redhat.com> - 0.4-2
- Add an upstream patch to update the translation table.


libbonobo-2.24.0-2.fc10
-----------------------
* Tue Oct  7 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-2
- Own /usr/lib/bonobo for noarch packages (bug 463054)


libcdio-0.80-5.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Adrian Reber <adrian at lisas.de> - 0.80-5
- fixed #462125 (Multilib conflict) - really, really, really
  (also remove architecture information from man pages)


libvirt-cim-0.5.2-1.fc10
------------------------
* Mon Oct  6 18:00:00 2008 Kaitlin Rupert <kaitlin at us.ibm.com> - 0.5.2-1
- Updated to latest upstream source


ltrace-0.5-12.45svn.fc10
------------------------
* Tue Oct  7 18:00:00 2008 Petr Machata <pmachata at redhat.com> - 0.5-12.45svn
- Fix fork & exec patches to apply cleanly under --fuzz=0
- Resolves: #465036


lvm2-2.02.39-6.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Alasdair Kergon <agk at redhat.com>> - 2.02.39-6
- Only set exec_prefix once and configure explicit directories to work with
  new version of rpm.

* Fri Sep 26 18:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.cm> - 2.02.39-5
- Add BuildRequires on cmanlib-devel. This is required after libcman split
  from cman and cman-devel into cmanlib and cmanlib-devel.
- Make versioned BuildRequires on cman-devel and cmanlib-devel more strict
  to guarantee to get the right version.

* Thu Sep 25 18:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.cm> - 2.02.39-5
- Add versioned BuildRequires on new cman-devel.

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 2.02.39-5
- Change %patch to %patch0 to match Patch0 as required by RPM package update.

* Thu Aug  7 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.02.39-4
- Fix license tag.


mediatomb-0.11.0-3.fc10
-----------------------
* Tue Oct  7 18:00:00 2008 Marc Wiriadisastra <marc at mwiriadi.id.au> 0.11.0-3
- Added the line change for xulrunner

* Tue Oct  7 18:00:00 2008 Marc Wiriadisastra <marc at mwiriadi.id.au> 0.11.0-2
- Added patch from upstream for Curl


mod_python-3.3.1-8
------------------
* Tue Oct  7 18:00:00 2008 Joe Orton <jorton at redhat.com> 3.3.1-8
- fix build failure, thanks to Tomo Vuckovic (#465246)


netbeans-6.1-7.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Victor G. Vasilyev <victor.vasilyev at sun.com> 6.1-7
- Dependency upon java-sdk is added instead of java-1.6.0-openjdk (#464558, # 465891)


perl-5.10.0-47.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 4:5.10.0-47.fc10
- rt#33242, rhbz#459918. Segfault after reblessing objects in Storable.
- rhbz#465728 upgrade Simple::Pod to 3.07


perl-Math-GMP-2.05-1.fc10
-------------------------
* Tue Oct  7 18:00:00 2008 Paul Howarth <paul at city-fan.org> 2.05-1
- New upstream maintainer, new upstream version 2.05
- 64-bit test suite compatibility issues fixed upstream, patch removed
- Run tests in verbose mode
- Add buildreq perl(Test::More) for basic test suite
- Add buildreqs perl(Module::Signature), perl(Perl::Critic), perl(Pod::Spell),
  perl(Test::Pod), perl(Test::YAML::Meta), and perl(Text::SpellChecker) for
  additional test suite functionality


perl-libwww-perl-5.816-1.fc10
-----------------------------
* Tue Oct  7 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 5.816-1
- update to 5.816
- fix #465855 - add --aliases into INSTALLDIRS
- use upstream patch for previous problem (see rt 38736)


php-pear-Cache-1.5.5-1.fc10
---------------------------
* Tue Oct  7 18:00:00 2008 Remi Collet <Fedora at FamilleCollet.com> 1.5.5-1
- finale 1.5.5


pigment-0.3.11-1.fc10
---------------------
* Tue Oct  7 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.3.11-1
- Update to 0.3.11.


purple-plugin_pack-2.4.0-1.fc10
-------------------------------
* Tue Oct  7 18:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 2.4.0-1
- Upstream update
- Extract inner function in switchspell (#462822)


python-genshi-0.5.1-1.fc10
--------------------------
* Tue Oct  7 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.5.1-1
- Version 0.5.1
- http://svn.edgewall.org/repos/genshi/tags/0.5.1/
- (Jul 9 2008, from branches/stable/0.5.x)
- 
-  * Fix problem with nested match templates not being applied when buffering
-    on the outer `py:match` is disabled. Thanks to Erik Bray for reporting the
-    problem and providing a test case!
-  * Fix problem in `Translator` filter that would cause the translation of
-    text nodes to fail if the translation function returned an object that was
-    not directly a string, but rather something like an instance of the
-    `LazyProxy` class in Babel (ticket #145).
-  * Fix problem with match templates incorrectly being applied multiple times.
-  * Includes from templates loaded via an absolute path now include the correct
-    file in nested directories as long if no search path has been configured
-    (ticket #240).
-  * Unbuffered match templates could result in parts of the matched content
-    being included in the output if the match template didn't actually consume
-    it via one or more calls to the `select()` function (ticket #243).


renrot-1.1-1.fc10
-----------------
* Tue Oct  7 18:00:00 2008 Andy Shevchenko <andy at smile.org.ua> - 1.1-1
- update to 1.1


rubygem-zoom-0.4.1-3.fc10
-------------------------
* Wed Oct  8 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.1-3
- Split out unneeded files in better way


system-config-firewall-1.2.12-1.fc10
------------------------------------
* Tue Oct  7 18:00:00 2008 Thomas Woerner <twoerner at redhat.com> 1.2.12-1
- only provide lang files in tui sub-package (rhbz#465572)
- updated translations for: as, bn_IN, ca, cs, es, fr, gu, it, ja, kn, mr, nl,
                            pa, or, pl, pt_BR, sk, zh_CN, zh_TW


totem-2.24.2-1.fc10
-------------------
* Tue Oct  7 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.2-1
- Update to 2.24.2


totem-pl-parser-2.24.1-1.fc10
-----------------------------
* Tue Oct  7 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.1-1
- Update to 2.24.1


tuxcmd-0.6.50-2.fc10
--------------------
* Tue Oct  7 18:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 0.6.50-2
- Hide '0' and NULL mount points
- GVFS plugin: supply proper user/pass for anonymous FTP login


tzdata-2008g-1.fc10
-------------------
* Tue Oct  7 18:00:00 2008 Petr Machata <pmachata at redhat.com> - 2008g-1
- Upstream 2008g
  - Fixed future DST transitions for Brazil


xesam-glib-0.5.0-1.fc10
-----------------------
* Tue Oct  7 18:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 0.5.0-1
- Update to 0.5.0


xorg-x11-drv-evdev-2.0.6-2.fc10
-------------------------------
* Wed Oct  8 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 2.0.6-2
- evdev-2.0.6-force-rules-evdev.patch: force keyboard to use the evdev rules,
  not model. requires xkeyboard-config 1.4. (#457512)


xorg-x11-server-1.5.1-10.fc10
-----------------------------

xulrunner-1.9.0.2-4.fc10
------------------------
* Tue Oct  7 18:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com> 1.9.0.2-4
- Add missing dependency on python-devel

* Sun Oct  5 18:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.0.2-3
- Enable PyXPCOM


Summary:
Added Packages: 8
Removed Packages: 1
Modified Packages: 45
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	libopensync-plugin-gnokii-0.36-1.fc10.i386 requires libgnokii.so.3
	pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	libopensync-plugin-gnokii-0.36-1.fc10.x86_64 requires libgnokii.so.3()(64bit)
	pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	libopensync-plugin-gnokii-0.36-1.fc10.ppc requires libgnokii.so.3
	pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0
	pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0
	pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0
	pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	libopensync-plugin-gnokii-0.36-1.fc10.ppc64 requires libgnokii.so.3()(64bit)
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From mcepl at redhat.com  Wed Oct  8 10:48:54 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 08 Oct 2008 12:48:54 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info>
Message-ID: <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>

On 2008-10-07, 06:37 GMT, Thorsten Leemhuis wrote:
> Afaics and iirc it was announced just 24 hours before the 
> meeting in question that the sbin feature is going to be 
> discussed:
> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00806.html
>
> Do you consider that enough time to voice objections? I don't. But 
> that's IMHO not a problem in our workflow, as we afaics always can make 
> adjustments even when things got decided.

And I think, this is much more important than the matter here 
itself. Last year there was another huge flamewar about replacing 
sysvinit with upstart. Lot and lot of well argued arguments were 
thrown against upstart (it doesn't make much difference, only 
trouble) so I thought that this idea is safely in the grave.  
Except couple of weeks after the last flames were vanquished, yum 
brought me upstart replacing sysvinit.

Does anybody from FESCO cares about what's discussed here, or do 
they let us waste our time and decide whatever they wanted all 
the time anyway?

(sorry for offended tone of the message, but I am offended by 
this),

Mat?j



From mcepl at redhat.com  Wed Oct  8 10:56:16 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 08 Oct 2008 12:56:16 +0200
Subject: procedure for renaming a package
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081005140618.GA2755@free.fr>
	<1223228962.9987.13.camel@luminos.localdomain>
	<20081005193648.GA3361@free.fr> <6fsor5x7m2.ln2@ppp1053.in.ipex.cz>
	<20081006084443.GA2829@free.fr>
Message-ID: <g7gur5xrg8.ln2@ppp1053.in.ipex.cz>

On 2008-10-06, 08:44 GMT, Patrice Dumas wrote:
> I may be wrong, maybe the TeX/LaTeX community in fedora is 
> healthy, but this is not my impression.

Coming from the academia myself, I was quite surprised how 
irrelevant TeX/LaTeX is outside of academia.

Anyway, is there any tex-fedora-friends list somewhere (if
possible available at gmane.org)? I refuse to plow through
fedora-reviews firehose.

Best,

Mat?j



From pertusus at free.fr  Wed Oct  8 11:18:28 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 8 Oct 2008 13:18:28 +0200
Subject: procedure for renaming a package
In-Reply-To: <g7gur5xrg8.ln2@ppp1053.in.ipex.cz>
References: <20081004172303.GB31243@free.fr>
	<9339c38c0810042309t7ab6babcuf6df149cf4d97160@mail.gmail.com>
	<20081005140618.GA2755@free.fr>
	<1223228962.9987.13.camel@luminos.localdomain>
	<20081005193648.GA3361@free.fr> <6fsor5x7m2.ln2@ppp1053.in.ipex.cz>
	<20081006084443.GA2829@free.fr> <g7gur5xrg8.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081008111828.GA3413@free.fr>

On Wed, Oct 08, 2008 at 12:56:16PM +0200, Matej Cepl wrote:
> On 2008-10-06, 08:44 GMT, Patrice Dumas wrote:
> > I may be wrong, maybe the TeX/LaTeX community in fedora is 
> > healthy, but this is not my impression.
> 
> Coming from the academia myself, I was quite surprised how 
> irrelevant TeX/LaTeX is outside of academia.

Agreed. That's very strange that this is not used more for publication.
Maybe people prefer docbook and xml in general.

> Anyway, is there any tex-fedora-friends list somewhere (if
> possible available at gmane.org)? I refuse to plow through
> fedora-reviews firehose.

As far as I can tell, no. No SIG, nothing. At the same time, I think
that waiting for texlive-2008 to know how many packages should be
packaged to have texlive coverage (400? 2000?), how we agregate stuff
would make sense.

Some reviews, but waiting for reviewer move:
https://bugzilla.redhat.com/show_bug.cgi?id=458430
https://bugzilla.redhat.com/show_bug.cgi?id=462446
https://bugzilla.redhat.com/show_bug.cgi?id=456582

I am willing to sponsor Vasile and G?ran as soon as they have a package
in.

--
Pat



From dev at nigelj.com  Wed Oct  8 11:25:40 2008
From: dev at nigelj.com (Nigel Jones)
Date: Thu, 09 Oct 2008 00:25:40 +1300
Subject: Taking fedora-devel into consideration [Was: Re: tab
 completion less useful now, due to sbin in path]
In-Reply-To: <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info>  <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
Message-ID: <1223465140.3242.913.camel@fantail.jnet.net.nz>

On Wed, 2008-10-08 at 12:48 +0200, Matej Cepl wrote:
> On 2008-10-07, 06:37 GMT, Thorsten Leemhuis wrote:
> > Afaics and iirc it was announced just 24 hours before the 
> > meeting in question that the sbin feature is going to be 
> > discussed:
> > https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00806.html
> >
> > Do you consider that enough time to voice objections? I don't. But 
> > that's IMHO not a problem in our workflow, as we afaics always can make 
> > adjustments even when things got decided.
> 
> And I think, this is much more important than the matter here 
> itself. Last year there was another huge flamewar about replacing 
> sysvinit with upstart. Lot and lot of well argued arguments were 
> thrown against upstart (it doesn't make much difference, only 
> trouble) so I thought that this idea is safely in the grave.  
> Except couple of weeks after the last flames were vanquished, yum 
> brought me upstart replacing sysvinit.
> 
> Does anybody from FESCO cares about what's discussed here, or do 
> they let us waste our time and decide whatever they wanted all 
> the time anyway?
> 
> (sorry for offended tone of the message, but I am offended by 
> this),
No problem, now I've got a solution, not one that would solve this
problem, but would help prevent it in the future...


Within 30 days of F10 shipping you'll have an opportunity to change
this...  So does everyone else really... VOTE (only 8% of the eligible
voters voted for the current FESCo).  If you or anyone else feel that
they can do a better job, then stand for FESCo too.

And in case people are ignoring Jef and Me on Fedora Planet, this time
round, hopefully we'll have Community Q&A type thing setup to help you
make your mind up...
> 
> Mat?j
> 
-- 
Nigel Jones <dev at nigelj.com>



From rjones at redhat.com  Wed Oct  8 13:37:54 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 8 Oct 2008 14:37:54 +0100
Subject: How to package code compiled with 'gcc -m32'?
In-Reply-To: <loom.20081008T092911-618@post.gmane.org>
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
	<loom.20081007T173256-441@post.gmane.org>
	<20081007185127.GB11246@amd.home.annexia.org>
	<loom.20081008T092911-618@post.gmane.org>
Message-ID: <20081008133754.GA14995@amd.home.annexia.org>

On Wed, Oct 08, 2008 at 09:36:44AM +0000, Kevin Kofler wrote:
> Try the 64bit-fixes patch in:
> http://repo.calcforge.org/fedora/9/SRPMS/nsis-2.34-1.src.rpm

That patch builds a 64 bit makensis, which is definitely an
improvement.  However something still wants to link with the 32 bit
wxGTK-devel.i386 library and include <gnu/stubs-32.h>.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From dwalsh at redhat.com  Wed Oct  8 14:43:08 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 08 Oct 2008 10:43:08 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <1223403791.31539.135.camel@moss-terrapins.epoch.ncsc.mil>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<48E61A7E.8010404@redhat.com>	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>	<48EA1B32.1010008@redhat.com>
	<48EA725E.2050908@shaw.ca>	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
	<1223403791.31539.135.camel@moss-terrapins.epoch.ncsc.mil>
Message-ID: <48ECC6FC.8080000@redhat.com>

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

David P. Quigley wrote:
> On Tue, 2008-10-07 at 09:42 -0400, Jon Masters wrote:
>> On Mon, 2008-10-06 at 15:17 -0500, Jerry Vonau wrote:
>>> Daniel J Walsh wrote:
>>>> Jon Masters wrote:
>>>>> On Fri, 2008-10-03 at 09:13 -0400, Daniel J Walsh wrote:
>>>>>
>>>>>>> $ mount -o loop Fedora-9-i386-DVD.iso /mnt
>>>>>>>
>>>>>>> And then one might legitimately expect to be able to copy the content
>>>>>>> of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs. But
>>>>>>> suppose that one is running SELinux in enforcing mode, then this will
>>>>>>> fail because the contexts differ in this operation. Then, one will
>>>>>>> likely quickly become severely annoyed and frustrated with SELinux,
>>>>>>> simply setting it permissive for the duration of the operation...
>>> I've seen this...
>> Indeed. I have too, one too many times.
>>
>>> SELinux is preventing cp from creating a file with a context of 
>>> iso9660_t on a
>>> filesystem.
>> Ah yes, I probably used the standard "cp -ax blah /blah" command. I
>> guess I'll need to learn not to use such standard commands in future and
>> adapt everything around SELinux. Because that's very non-obtrusive, and
>> won't cause regular users any anguish at all.
>>
>> Jon.
>>
>>
> 
> I think the main question here is should archive try to retain the
> SELinux context. From what I've heard from people here, initially the
> idea was to try to preserve the context and if that failed fall back to
> labeling based on the parent. That doesn't seem to be what cp is trying
> to do. If we removed the retain the context part from the archive switch
> of cp you would get labeling based on the parent but then you would be
> required to explicitly specify preserve the context when you wanted to
> archive that as well. 
> 
> It doesn't seem like anyone is actually depending on the associate
> permission so it might be worth someone looking into removing it if no
> one is really using it. It has its applications but I don't believe Red
> Hat is using it at this time.
> 
> Dave
> 

That is fine with me but I would like to get the opinion of upstream
coreutils.

Jim what do you think?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjsxvwACgkQrlYvE4MpobN3ugCeKH/NjySwoZBcLgGpek+ZDLDq
Zj8An1Qg6H/gH+IjmDNEdy6emhzjpWkO
=WQA3
-----END PGP SIGNATURE-----



From notting at redhat.com  Wed Oct  8 15:12:04 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 8 Oct 2008 11:12:04 -0400
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <loom.20081008T094231-77@post.gmane.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
Message-ID: <20081008151204.GA5629@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> I wrote:
> > Does "LXDE" really need to be translated? Can't we just use "LXDE" as the 
> > category name?
> 
> Looking at it, that's exactly what XFCE already does, so why can't LXDE just do 
> the same? A proper noun needs no translation.

There are descriptions which are translated as well....

Bill



From kevin.kofler at chello.at  Wed Oct  8 15:12:14 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 15:12:14 +0000 (UTC)
Subject: How to package code compiled with 'gcc -m32'?
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
	<loom.20081007T173256-441@post.gmane.org>
	<20081007185127.GB11246@amd.home.annexia.org>
	<loom.20081008T092911-618@post.gmane.org>
	<20081008133754.GA14995@amd.home.annexia.org>
Message-ID: <loom.20081008T150800-294@post.gmane.org>

Richard W.M. Jones <rjones <at> redhat.com> writes:
> That patch builds a 64 bit makensis, which is definitely an
> improvement.  However something still wants to link with the 32 bit
> wxGTK-devel.i386 library and include <gnu/stubs-32.h>.

That's the menu stuff. I haven't tried building that one yet (it's disabled in 
that SRPM - it's not essential to be able to use NSIS). Presumably there's also 
a -m32 switch somewhere there which also has to be patched out? There may also 
be 64-bit safety issues, I can help you with those. (I have some experience 
with that sort of stuff, I had my own 64-bit patchset for NSIS originally, but 
Debian eventually fixed the same stuff too so I used theirs, I was also the one 
who fixed z88dk for 64-bit architectures.) The gist of it is to build on x86_64 
with as many GCC warnings as possible and fix everything GCC complains about, 
usually those are all the offending places, only rarely there is some stuff 
which has to be noticed by hand (during runtime testing).

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct  8 15:38:53 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 15:38:53 +0000 (UTC)
Subject: rawhide report: 20081008 changes
References: <20081008102150.CD4491F81CF@releng2.fedora.phx.redhat.com>
Message-ID: <loom.20081008T153656-507@post.gmane.org>

Rawhide Report <rawhide <at> fedoraproject.org> writes:
> 	libopensync-plugin-gnokii-0.36-1.fc10.i386 requires libgnokii.so.3

I just rebuilt this one. It was a straight rebuild, no patches needed.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct  8 15:43:15 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 15:43:15 +0000 (UTC)
Subject: Disappointed: My feature was removed without noticing me
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
Message-ID: <loom.20081008T153926-770@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:
> There are descriptions which are translated as well....

Well, leave it blank, leave it in English (untranslated), put just a URL for 
the upstream web page as the description, write just "LXDE" as the description 
too, ... - anything is better than having a set of packages all packaged and 
reviewed, but hidden from users (not listed in comps, and rejected as a feature 
on the ground that it isn't in comps).

       Kevin Kofler



From opensource at till.name  Wed Oct  8 15:57:27 2008
From: opensource at till.name (Till Maas)
Date: Wed, 08 Oct 2008 17:57:27 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223404671.24360.51.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
Message-ID: <200810081757.37512.opensource@till.name>

On Tue October 7 2008, Christoph Wickert wrote:

>      2. If we can't get it ready as a feature, can I at least get the
>         missing packages into F10 and make rel-eng tag them final?

I just tried to find out and it seems that there is no freeze currently, so if 
you import and build your packages soon, they will show up in Fedora 10 
Everything. Please correct me if I am wrong, because then I need to open a 
ticket at releng. ;-)

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/20081008/f47a9f3c/attachment.sig>

From jim at meyering.net  Wed Oct  8 16:10:26 2008
From: jim at meyering.net (Jim Meyering)
Date: Wed, 08 Oct 2008 18:10:26 +0200
Subject: SELinux - copying ISO file content
In-Reply-To: <48ECC6FC.8080000@redhat.com> (Daniel J. Walsh's message of "Wed, 
	08 Oct 2008 10:43:08 -0400")
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com> <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
	<1223403791.31539.135.camel@moss-terrapins.epoch.ncsc.mil>
	<48ECC6FC.8080000@redhat.com>
Message-ID: <87skr73w5p.fsf@rho.meyering.net>

Daniel J Walsh <dwalsh at redhat.com> wrote:
> David P. Quigley wrote:
...
>> I think the main question here is should archive try to retain the
>> SELinux context. From what I've heard from people here, initially the
>> idea was to try to preserve the context and if that failed fall back to
>> labeling based on the parent. That doesn't seem to be what cp is trying
>> to do. If we removed the retain the context part from the archive switch
>> of cp you would get labeling based on the parent but then you would be
>> required to explicitly specify preserve the context when you wanted to
>> archive that as well.
>>
>> It doesn't seem like anyone is actually depending on the associate
>> permission so it might be worth someone looking into removing it if no
>> one is really using it. It has its applications but I don't believe Red
>> Hat is using it at this time.
>>
>> Dave
>
> That is fine with me but I would like to get the opinion of upstream
> coreutils.
>
> Jim what do you think?

Hi Dan,

Since I merged SELinux support into upstream coreutils,
(for coreutils-6.9.91, released 2007-12-15; latest is coreutils-7.0,
  http://article.gmane.org/gmane.comp.gnu.core-utils.announce/47 )
its cp -a has *not* attempted to preserve SELinux context.
There was some debate about changing that, since cp -a has
always been equivalent to "cp -dpR", and some were reluctant
to change that.

To get SELinux-context-preserving behavior, you currently have two options:

    use --preserve=context to require that cp preserve each
    file's context.  Failure to do so makes cp end up exiting nonzero.

    use --preserve=all to make cp _attempt_ to preserve context.
    Failure gets a diagnostic, but does not evoke nonzero exit status.

Just yesterday, Ond?ej Va??k proposed a patch to change cp -a
from being equivalent to "cp -dpR" to being equivalent to
"cp -dR --preserve=all", which would be in line with this year-old
description from NEWS:

    * "cp -a" works with SELinux:
    Now, cp -a attempts to preserve context, but failure to do so does
    not change cp's exit status.  However "cp --preserve=context" is
    similar, but failure *does* cause cp to exit with nonzero status.

I'll have to run some tests before deciding on this,
to see if such a change would result in many new diagnostics
about failure to preserve context.



From james at fedoraproject.org  Wed Oct  8 16:13:04 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 08 Oct 2008 12:13:04 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <1223403791.31539.135.camel@moss-terrapins.epoch.ncsc.mil>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com>  <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
	<1223403791.31539.135.camel@moss-terrapins.epoch.ncsc.mil>
Message-ID: <1223482384.3889.128.camel@code.and.org>

On Tue, 2008-10-07 at 14:23 -0400, David P. Quigley wrote:

> I think the main question here is should archive try to retain the
> SELinux context. From what I've heard from people here, initially the
> idea was to try to preserve the context and if that failed fall back to
> labeling based on the parent.

 The context is a permission, it's like saying "when using -a try and
preserve the chmod/ownership/acl value, but if that fails just make a
new one up ... what could possibly go wrong!?".

>  That doesn't seem to be what cp is trying
> to do. If we removed the retain the context part from the archive switch
> of cp you would get labeling based on the parent but then you would be
> required to explicitly specify preserve the context when you wanted to
> archive that as well. 

 We differ from upstream by adding the -c behaviour to -a ... but unless
we want to turn SELinux off that's the right thing to do, IMO.
 The fact that this is another case of "SeLinux telling you in a really
weird way, that what you asked for is wrong" is annoying, but that
doesn't mean we should change what people asked for.

> It doesn't seem like anyone is actually depending on the associate
> permission so it might be worth someone looking into removing it if no
> one is really using it. It has its applications but I don't believe Red
> Hat is using it at this time.

 -ENOPARSE

-- 
James Antill <james at fedoraproject.org>
Fedora



From notting at redhat.com  Wed Oct  8 16:38:52 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 8 Oct 2008 12:38:52 -0400
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <loom.20081008T153926-770@post.gmane.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
Message-ID: <20081008163852.GB5629@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> Bill Nottingham <notting <at> redhat.com> writes:
> > There are descriptions which are translated as well....
> 
> Well, leave it blank, leave it in English (untranslated), put just a URL for 
> the upstream web page as the description

... or, actually follow the string freeze, and the string freeze break
policy.

> too, ... - anything is better than having a set of packages all packaged and 
> reviewed, but hidden from users (not listed in comps, and rejected as a feature 
> on the ground that it isn't in comps).

I'm sorry, but I'm missing the outrage - the feature page listed the
following things, under 'Scope':
  
  * Package Reviews  (were not fully done)
  
  * Comps: new group with id "lxde-desktop", name "LXDE"...
	o mandatory: lxde-common, lxpanel, openbox, pcmanfm
	o default: gpicview, leafpad, lxappearance, lxtask, lxterminal, obconf, xarchiver
	... (wasn't done)


and, under 'Test Plan':
  
  As most of the packages are already in fedora they are proven to be stable. So we need to
  
  1. get the 2 missing packages into rawhide ASAP so they are included in the F10 Beta
  2. add packages to comps
  3. test that installation with yum-groupinstall works correctly
  4. test fresh installs with the beta 

It wasn't even to having step 1 completed. So, exactly what else is there to
do when even the basic scope and test plan of the feature isn't ready?

Bill



From christoph.wickert at googlemail.com  Wed Oct  8 16:40:53 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 08 Oct 2008 18:40:53 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <200810081757.37512.opensource@till.name>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<200810081757.37512.opensource@till.name>
Message-ID: <1223484053.3434.18.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 17:57 +0200 schrieb Till Maas:
> On Tue October 7 2008, Christoph Wickert wrote:
> 
> >      2. If we can't get it ready as a feature, can I at least get the
> >         missing packages into F10 and make rel-eng tag them final?
> 
> I just tried to find out and it seems that there is no freeze currently, so if 
> you import and build your packages soon, they will show up in Fedora 10 
> Everything. Please correct me if I am wrong, because then I need to open a 
> ticket at releng. ;-)

I can not import the 2 missing packages without review and the comps
problem is still not fixed. I don't see _any_ support and not even
feedback from FeSCo here, at least nobody (except notting) cared to
respond to my mail. So I think me and the LXDE users (yes, there are
quite a few) are out of luck.

> Regards,
> Till

Regards,
Christoph



From james at fedoraproject.org  Wed Oct  8 16:44:35 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 08 Oct 2008 12:44:35 -0400
Subject: rawhide report: 20081006 changes
In-Reply-To: <1223318479.9987.35.camel@luminos.localdomain>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
	<1223310041.9987.28.camel@luminos.localdomain>
	<20081006191001.2955ac34.mschwendt@gmail.com>
	<1223313586.9987.33.camel@luminos.localdomain>
	<20081006203335.c31510fe.mschwendt@gmail.com>
	<1223318479.9987.35.camel@luminos.localdomain>
Message-ID: <1223484275.3889.130.camel@code.and.org>

On Mon, 2008-10-06 at 11:41 -0700, Jesse Keating wrote:
> On Mon, 2008-10-06 at 20:33 +0200, Michael Schwendt wrote:
> > On Mon, 06 Oct 2008 10:19:46 -0700, Jesse Keating wrote:
> > 
> > > The yum folks are still looking into it.  The really bizarre thing is
> > > that there is no problem with the package itself, in fact it's seen in
> > > other arches, and in those other arch directories it's a hardlink back
> > > to the actual file somewhere else on the filesystem.  That's the way it
> > > is for each of those arch trees.  It's a real headscratcher of a
> > > problem.
> > 
> > Unless I'm misreading the code, it's a race-condition. mash creates the
> > metadata for all architectures in parallel. One process per arch. The
> > createrepo checksum cache file I/O [1] is not protected against concurrent
> > access. With odd timing, it can happen that one process reads an empty
> > checksum file that has just been opened for writing by another process.
> > Give it a try. Add a safety check after reading a checksum file.
> > 
> 
> That tickles a part of my brain, I think I speculated that this was the
> problem while in the shower or something, and then completely forgot to
> pursue it once I got ready to work.  It is a possibility.

 This should fix it:

http://koji.fedoraproject.org/koji/taskinfo?taskID=868762

...the patch being basically:

-            csumo = open(csumfile, 'w')
+
+            #  This is atomic cache creation via. rename, so we can have two
+            # tasks using the same cachedir ... mash does this.
+            csumo = tempfile.NamedTemporaryFile(mode='w', dir=self.crp_cachedir
             csumo.write(checksum)
             csumo.close()
+            os.rename(csumo.name, csumfile)


...it'll get upstream as soon as I can push :).

-- 
James Antill <james at fedoraproject.org>
Fedora



From ville.skytta at iki.fi  Wed Oct  8 16:49:23 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 8 Oct 2008 19:49:23 +0300
Subject: Obsoletes question: codeina
In-Reply-To: <6h9ur5x3a4.ln2@ppp1053.in.ipex.cz>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<1223288392.6012.37.camel@hughsie-laptop>
	<6h9ur5x3a4.ln2@ppp1053.in.ipex.cz>
Message-ID: <200810081949.23586.ville.skytta@iki.fi>

On Wednesday 08 October 2008, Matej Cepl wrote:

> Obsoletes: codeina < 0.10.1-10
> Provides:  codeina = %{version}-%{release}
>
> Or maybe not, you have to decide whether the codeina name has any
> meaning aside from being the older package (like for example
> gecko-libs even aside from xulrunner).

Is the Provides: above appropriate in the first place, or should only the 
Obsoletes: be there?  The only thing PackageKit-gstreamer-plugin and codeina 
appear to have in common is /usr/libexec/gst-install-plugins-helper.

More info:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages



From kevin.kofler at chello.at  Wed Oct  8 16:52:39 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 16:52:39 +0000 (UTC)
Subject: Upgrading to F10 was a bad experience
References: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
	<200810072007.52451.jamatos@fc.up.pt>
Message-ID: <loom.20081008T165049-236@post.gmane.org>

Jos? Matos <jamatos <at> fc.up.pt> writes:
> Country/Region & Language -> keyboard layout
> 
> and select "disabled keyboard layouts".

Actually, don't disable layouts altogether, set model to "Evdev-managed 
keyboard" instead. The latest kde-settings sets that up as the default, but if 
you previously changed the model to something else, you'll have to change it by 
hand.

If a better solution can't be found (some patch just went into 
xorg-x11-drv-evdev which might help there), we could add a kconf_update script 
to kde-settings to forcefully change your existing configuration to the working 
one.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Oct  8 16:53:53 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 16:53:53 +0000 (UTC)
Subject: Upgrading to F10 was a bad experience
References: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
	<200810072140.59743.dex.mbox@gmail.com>
	<3da3b5b40810071357x2b59858jf6e4b5c5e9ab4118@mail.gmail.com>
Message-ID: <loom.20081008T165255-860@post.gmane.org>

Ahmed Kamal <email.ahmedkamal <at> googlemail.com> writes:
> I hope I can still use KDE to switch keyboard languages, not so sure if that
> moves off evdev!

KDE has always supported evdev, it was just not the default.

Select "Evdev-managed keyboard" as the keyboard model.

        Kevin Kofler



From orion at cora.nwra.com  Wed Oct  8 16:58:52 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 08 Oct 2008 10:58:52 -0600
Subject: Status of libtool 2.2.X?
Message-ID: <48ECE6CC.6030001@cora.nwra.com>

Should we get libtool 2.2.X into F-11 now?

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

-- 
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 jkeating at redhat.com  Wed Oct  8 17:01:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 08 Oct 2008 10:01:00 -0700
Subject: Obsoletes question: codeina
In-Reply-To: <200810081949.23586.ville.skytta@iki.fi>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<1223288392.6012.37.camel@hughsie-laptop>
	<6h9ur5x3a4.ln2@ppp1053.in.ipex.cz>
	<200810081949.23586.ville.skytta@iki.fi>
Message-ID: <1223485260.4410.67.camel@luminos.localdomain>

On Wed, 2008-10-08 at 19:49 +0300, Ville Skytt? wrote:
> Is the Provides: above appropriate in the first place, or should only the 
> Obsoletes: be there?  The only thing PackageKit-gstreamer-plugin and codeina 
> appear to have in common is /usr/libexec/gst-install-plugins-helper.
> 
> More info:
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages

In this case, people who currently have codeina installed, but not the
pk-gstreamer-plugin, would get pk-gstreamer-plugin as an upgrade to
their installed codeina.  They wouldn't get pk-plugin automatically any
other way, unless something else they have installed requires it.  It's
somewhat fuzzy use of Provides, but it is in a way that is favorable to
our users.  Note that the provides is only on the package name, not on
any files or libraries, so if you had something that depended on codeina
files or libraries this wouldn't satisfy it.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/96856c50/attachment.sig>

From jkeating at redhat.com  Wed Oct  8 17:06:52 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 08 Oct 2008 10:06:52 -0700
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223484053.3434.18.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<200810081757.37512.opensource@till.name>
	<1223484053.3434.18.camel@wicktop.localdomain>
Message-ID: <1223485612.4410.71.camel@luminos.localdomain>

On Wed, 2008-10-08 at 18:40 +0200, Christoph Wickert wrote:
> I can not import the 2 missing packages without review and the comps
> problem is still not fixed. I don't see _any_ support and not even
> feedback from FeSCo here, at least nobody (except notting) cared to
> respond to my mail. So I think me and the LXDE users (yes, there are
> quite a few) are out of luck.

I'm not in FESCo anymore, however isn't this exactly what happens when
you miss the deadlines?  Isn't that why there is a contingency plan
section in the feature pages, to give yourself and others guidance as to
what to do if you don't complete the feature in time?

Given your situation, I think you're in a unique position to work with
FESCo and the Feature Wrangler to offer improvement suggestions to the
current system, particularly in the notification realm.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/2e5edcb5/attachment.sig>

From notting at redhat.com  Wed Oct  8 17:14:28 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 8 Oct 2008 13:14:28 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <48ECE6CC.6030001@cora.nwra.com>
References: <48ECE6CC.6030001@cora.nwra.com>
Message-ID: <20081008171428.GA7911@nostromo.devel.redhat.com>

Orion Poplawski (orion at cora.nwra.com) said: 
> Should we get libtool 2.2.X into F-11 now?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=435737

After beta freeze seems like a bad time to add a package that's going
to cause other things not to build. If it can be added as an additional
package that won't get int the way of builds that aren't expecting it,
it would be more palatable.

Bill



From ville.skytta at iki.fi  Wed Oct  8 17:16:27 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 8 Oct 2008 20:16:27 +0300
Subject: Obsoletes question: codeina
In-Reply-To: <1223485260.4410.67.camel@luminos.localdomain>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<200810081949.23586.ville.skytta@iki.fi>
	<1223485260.4410.67.camel@luminos.localdomain>
Message-ID: <200810082016.27599.ville.skytta@iki.fi>

On Wednesday 08 October 2008, Jesse Keating wrote:
> On Wed, 2008-10-08 at 19:49 +0300, Ville Skytt? wrote:
> > Is the Provides: above appropriate in the first place, or should only the
> > Obsoletes: be there?  The only thing PackageKit-gstreamer-plugin and
> > codeina appear to have in common is
> > /usr/libexec/gst-install-plugins-helper.
> >
> > More info:
> > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Frepla
> >cing_existing_packages
>
> In this case, people who currently have codeina installed, but not the
> pk-gstreamer-plugin, would get pk-gstreamer-plugin as an upgrade to
> their installed codeina.  They wouldn't get pk-plugin automatically any
> other way, unless something else they have installed requires it.  It's
> somewhat fuzzy use of Provides, but it is in a way that is favorable to
> our users.

I think the Obsoletes alone accomplishes auto-upgrading from codeina to 
pk-gstreamer-plugin.   I hope that's what you meant as desirable in the 
above, I'm having a bit of a problem parsing it.

Dropping the Provides would mean that if something had a depdendency on 
codeina, that dep would be broken, and that pk-gstreamer-plugin couldn't be 
installed with "yum install codeina".  I don't think it'd have any effect on 
whether pk-gstreamer-plugin would/wouldn't be applied as an upgrade over 
installed codeina e.g. by yum (assuming the Obsoletes is left there).



From jkeating at redhat.com  Wed Oct  8 17:19:38 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 08 Oct 2008 10:19:38 -0700
Subject: Obsoletes question: codeina
In-Reply-To: <200810082016.27599.ville.skytta@iki.fi>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<200810081949.23586.ville.skytta@iki.fi>
	<1223485260.4410.67.camel@luminos.localdomain>
	<200810082016.27599.ville.skytta@iki.fi>
Message-ID: <1223486378.4410.73.camel@luminos.localdomain>

On Wed, 2008-10-08 at 20:16 +0300, Ville Skytt? wrote:
> I think the Obsoletes alone accomplishes auto-upgrading from codeina to 
> pk-gstreamer-plugin.   I hope that's what you meant as desirable in the 
> above, I'm having a bit of a problem parsing it.

With an obsolete alone, 'yum update' would never see that it needs to
bring in pk-gstreamer-plugin.  Codeina would be left alone.  IMHO that's
not the scenario we want played out.  We /want/ Codeina replaced by the
packagekit solution, and the only way to make that happen for people
already with codeina installed is to add the Provides.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/5b1e70e2/attachment.sig>

From paul at xelerance.com  Wed Oct  8 17:16:12 2008
From: paul at xelerance.com (Paul Wouters)
Date: Wed, 8 Oct 2008 13:16:12 -0400 (EDT)
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <1223453558.10878.2.camel@gilboa-home-dev.localdomain>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
	<1223453558.10878.2.camel@gilboa-home-dev.localdomain>
Message-ID: <Pine.LNX.4.64.0810081315170.24905@newtla.xelerance.com>

On Wed, 8 Oct 2008, Gilboa Davara wrote:

> Yes, setting up a bridged network is a huge pain in the back side, but I
> don't remember Xen being any different. 

The difference was Fedora did it all for us. I didn't need to know my
eth0 got renamed into peth0 and xen got slapped in my networking.

Paul



From mclasen at redhat.com  Wed Oct  8 17:26:54 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 08 Oct 2008 13:26:54 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081008171428.GA7911@nostromo.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
Message-ID: <1223486815.3787.16.camel@localhost.localdomain>

On Wed, 2008-10-08 at 13:14 -0400, Bill Nottingham wrote:
> Orion Poplawski (orion at cora.nwra.com) said: 
> > Should we get libtool 2.2.X into F-11 now?
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=435737
> 
> After beta freeze seems like a bad time to add a package that's going
> to cause other things not to build. If it can be added as an additional
> package that won't get int the way of builds that aren't expecting it,
> it would be more palatable.

Note that Orion was not asking to break F10, but F11.



From berrange at redhat.com  Wed Oct  8 17:27:10 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 8 Oct 2008 18:27:10 +0100
Subject: xen kernel with dom0 in Fedora 10?
In-Reply-To: <Pine.LNX.4.64.0810081315170.24905@newtla.xelerance.com>
References: <cba415ca0809301225p79d76efbm9d2a023933c18a7d@mail.gmail.com>
	<20080930193705.GB12982@amd.home.annexia.org>
	<F07E02D30FEE3B474A4F998B@shieldbreaker.sei.cmu.edu>
	<1223453558.10878.2.camel@gilboa-home-dev.localdomain>
	<Pine.LNX.4.64.0810081315170.24905@newtla.xelerance.com>
Message-ID: <20081008172710.GT19052@redhat.com>

On Wed, Oct 08, 2008 at 01:16:12PM -0400, Paul Wouters wrote:
> On Wed, 8 Oct 2008, Gilboa Davara wrote:
> 
> > Yes, setting up a bridged network is a huge pain in the back side, but I
> > don't remember Xen being any different. 
> 
> The difference was Fedora did it all for us. I didn't need to know my
> eth0 got renamed into peth0 and xen got slapped in my networking.

It used todo that for you. We disabled that functionality by default
in F8 because it utterly failed for anyone whose ethX was a wifi device,
or anyone using bonding, vlans, or any other non-trivial config, giving
them 'out of the box'  broken networking.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From jwboyer at gmail.com  Wed Oct  8 17:16:07 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 8 Oct 2008 13:16:07 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081008171428.GA7911@nostromo.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
Message-ID: <20081008171607.GE3447@yoda.jdub.homelinux.org>

On Wed, Oct 08, 2008 at 01:14:28PM -0400, Bill Nottingham wrote:
>Orion Poplawski (orion at cora.nwra.com) said: 
>> Should we get libtool 2.2.X into F-11 now?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=435737
>
>After beta freeze seems like a bad time to add a package that's going
>to cause other things not to build. If it can be added as an additional
>package that won't get int the way of builds that aren't expecting it,
>it would be more palatable.

He said F-11.  I would extrapolate that to mean "branch libtool
for F-10 now, and have devel be libtool 2.2.x."  That would have
no bearing on rawhide/F-10.

josh



From notting at redhat.com  Wed Oct  8 17:30:25 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 8 Oct 2008 13:30:25 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223486815.3787.16.camel@localhost.localdomain>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<1223486815.3787.16.camel@localhost.localdomain>
Message-ID: <20081008173017.GA8129@nostromo.devel.redhat.com>

Matthias Clasen (mclasen at redhat.com) said: 
> On Wed, 2008-10-08 at 13:14 -0400, Bill Nottingham wrote:
> > Orion Poplawski (orion at cora.nwra.com) said: 
> > > Should we get libtool 2.2.X into F-11 now?
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=435737
> > 
> > After beta freeze seems like a bad time to add a package that's going
> > to cause other things not to build. If it can be added as an additional
> > package that won't get int the way of builds that aren't expecting it,
> > it would be more palatable.
> 
> Note that Orion was not asking to break F10, but F11.

That's what I get for not reading closely. Go for it!

Bill



From opensource at till.name  Wed Oct  8 17:32:21 2008
From: opensource at till.name (Till Maas)
Date: Wed, 08 Oct 2008 19:32:21 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223484053.3434.18.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<200810081757.37512.opensource@till.name>
	<1223484053.3434.18.camel@wicktop.localdomain>
Message-ID: <200810081932.31695.opensource@till.name>

On Wed October 8 2008, Christoph Wickert wrote:

> I can not import the 2 missing packages without review and the comps
> problem is still not fixed. I don't see _any_ support and not even

It always helps to provide links to review requests, if you still need a 
reviewer. Do you mean these two reviews?

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

Both look to me like there is some actim from you required.

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/20081008/7129039a/attachment.sig>

From karsten at redhat.com  Wed Oct  8 17:36:57 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Wed, 08 Oct 2008 19:36:57 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081008171607.GE3447@yoda.jdub.homelinux.org>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
Message-ID: <48ECEFB9.1080600@redhat.com>

Josh Boyer schrieb:
> On Wed, Oct 08, 2008 at 01:14:28PM -0400, Bill Nottingham wrote:
>> Orion Poplawski (orion at cora.nwra.com) said: 
>>> Should we get libtool 2.2.X into F-11 now?
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=435737
>> After beta freeze seems like a bad time to add a package that's going
>> to cause other things not to build. If it can be added as an additional
>> package that won't get int the way of builds that aren't expecting it,
>> it would be more palatable.
> 
> He said F-11.  I would extrapolate that to mean "branch libtool
> for F-10 now, and have devel be libtool 2.2.x."  That would have
> no bearing on rawhide/F-10.
> 
> josh
> 

Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
prepare a Wiki page with details about that.

     Karsten



From ville.skytta at iki.fi  Wed Oct  8 17:39:46 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 8 Oct 2008 20:39:46 +0300
Subject: Obsoletes question: codeina
In-Reply-To: <1223486378.4410.73.camel@luminos.localdomain>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<200810082016.27599.ville.skytta@iki.fi>
	<1223486378.4410.73.camel@luminos.localdomain>
Message-ID: <200810082039.46921.ville.skytta@iki.fi>

On Wednesday 08 October 2008, Jesse Keating wrote:
> On Wed, 2008-10-08 at 20:16 +0300, Ville Skytt? wrote:
> > I think the Obsoletes alone accomplishes auto-upgrading from codeina to
> > pk-gstreamer-plugin.   I hope that's what you meant as desirable in the
> > above, I'm having a bit of a problem parsing it.
>
> With an obsolete alone, 'yum update' would never see that it needs to
> bring in pk-gstreamer-plugin.  Codeina would be left alone.

That's not how any depsolver I'm aware of behaves - I think it'd be a bug.

> IMHO that's 
> not the scenario we want played out.  We /want/ Codeina replaced by the
> packagekit solution, and the only way to make that happen for people
> already with codeina installed is to add the Provides.

As said, the Obsoletes should be enough for that.  And is for me (on F-9):

----

# rpm -q codeina
codeina-0.10.1-8.fc9.noarch

# cat <<EOF > /etc/yum.repos.d/tmp2.repo
[tmp2]
name=tmp2
gpgcheck=0
baseurl=http://scop.fedorapeople.org/tmp2/
EOF

# repoquery --provides pk-gstreamer-plugin-fake
pk-gstreamer-plugin-fake = 1.0-1

# repoquery --obsoletes pk-gstreamer-plugin-fake
codeina < 0.10.1-10

# yum update
[...]
Installing:
 pk-gstreamer-plugin-fake        noarch        1.0-1        tmp2          1.4k
     replacing  codeina.noarch 0.10.1-8.fc9
[...]
Running Transaction
  Installing     : pk-gstreamer-plugin-fake                          [1/2]
  Erasing        : codeina                                           [2/2]

Installed: pk-gstreamer-plugin-fake.noarch 0:1.0-1
Replaced: codeina.noarch 0:0.10.1-8.fc9
Complete!

----

The specfile for the test package is at 
http://scop.fedorapeople.org/tmp2/pk-gstreamer-plugin-fake.spec



From james at fedoraproject.org  Wed Oct  8 17:43:14 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 08 Oct 2008 13:43:14 -0400
Subject: Obsoletes question: codeina
In-Reply-To: <1223486378.4410.73.camel@luminos.localdomain>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<200810081949.23586.ville.skytta@iki.fi>
	<1223485260.4410.67.camel@luminos.localdomain>
	<200810082016.27599.ville.skytta@iki.fi>
	<1223486378.4410.73.camel@luminos.localdomain>
Message-ID: <1223487794.3889.138.camel@code.and.org>

On Wed, 2008-10-08 at 10:19 -0700, Jesse Keating wrote:
> On Wed, 2008-10-08 at 20:16 +0300, Ville Skytt? wrote:
> > I think the Obsoletes alone accomplishes auto-upgrading from codeina to 
> > pk-gstreamer-plugin.   I hope that's what you meant as desirable in the 
> > above, I'm having a bit of a problem parsing it.
> 
> With an obsolete alone, 'yum update' would never see that it needs to
> bring in pk-gstreamer-plugin.

 That's not true, obsoletes alone would be enough for "yum update". As
Ville says, the Provides is needed if anything has a "Requires:
codina" ... but that shouldn't be true, in Fedora.

-- 
James Antill <james at fedoraproject.org>
Fedora



From kevin at scrye.com  Wed Oct  8 17:48:33 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 8 Oct 2008 11:48:33 -0600
Subject: Remove a branch directory completely from cvs
In-Reply-To: <200810072032.03794.opensource@till.name>
References: <200810071726.44086.opensource@till.name>
	<20081007100536.0ccb5ea5@ohm.scrye.com>
	<200810072032.03794.opensource@till.name>
Message-ID: <20081008114833.6dda4ea7@ohm.scrye.com>

On Tue, 07 Oct 2008 20:31:49 +0200
opensource at till.name (Till Maas) wrote:

> On Tue October 7 2008, Kevin Fenzi wrote:
> > On Tue, 07 Oct 2008 17:26:38 +0200
> >
> > (Till Maas) wrote:
> 
> > > according to the UsingCvsFaq[1] one can remove a branch directory
> > > from cvs with "cvs remove". I tried this, but it seems not to
> > > work. I removed the "FC-1" directory from pam_mount, but when I
> > > cvs co'ed the pam_mount directory again, an empty "FC-1"
> > > directory appeared. Is there some parameter I can pass to "cvs
> > > remove" to get the directory removed, too?
> >
> > Why are you needing to do this?
> >
> > Granted, not many people should need to look at what was in FC-1
> > much, but it's possible there could be something there someone
> > would want to look at, and now all the files in there are marked
> > dead, so it's more of a chore to get them to look at.
> 
> Using the viewcvs webinterface, it is pretty easy to get the dead
> files:
> http://cvs.fedoraproject.org/viewvc/rpms/pam_mount/FC-1/?hideattic=0
> 
> I guess there is also some commandline option that allows to easily
> access these files.

I suppose. 

> > Perhaps we could look at archiving off all those old branches if
> > they are causing a problem?
> 
> After I got this working, the next step was to suggest to remove all
> old branches (F-7 and older) for every package in the near future.

Why not ask infrastructure to see about moving those all off to a
archive site/location? 

> The reason why I want this done, is that they mess up some packages,
> where there are now 10 or more branch directories. 

Oh? how? 

> Also it takes
> unecessarily long for to checkout packages. Especially packages that
> not only have many branches, but also a lot of patches.

That shouldn't be a function of how many branches there are, but how
many files/revisions are in CVS for the files you are checking out. 

Wouldn't it be better to look at moving to a newer VCS that can handle
this case better? You might look and add that as a desired feature for
the next VCS. 

> Regards,
> Till

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/49593dae/attachment.sig>

From jkeating at redhat.com  Wed Oct  8 17:48:50 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 08 Oct 2008 10:48:50 -0700
Subject: Obsoletes question: codeina
In-Reply-To: <1223487794.3889.138.camel@code.and.org>
References: <1223285354.6012.33.camel@hughsie-laptop>
	<200810081949.23586.ville.skytta@iki.fi>
	<1223485260.4410.67.camel@luminos.localdomain>
	<200810082016.27599.ville.skytta@iki.fi>
	<1223486378.4410.73.camel@luminos.localdomain>
	<1223487794.3889.138.camel@code.and.org>
Message-ID: <1223488130.4410.75.camel@luminos.localdomain>

On Wed, 2008-10-08 at 13:43 -0400, James Antill wrote:
> 
>  That's not true, obsoletes alone would be enough for "yum update". As
> Ville says, the Provides is needed if anything has a "Requires:
> codina" ... but that shouldn't be true, in Fedora.

I stand corrected.  Don't know what was giving me the previous
assumption.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/b045588b/attachment.sig>

From christoph.wickert at googlemail.com  Wed Oct  8 18:09:12 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 08 Oct 2008 20:09:12 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <20081008163852.GB5629@nostromo.devel.redhat.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
Message-ID: <1223489352.3434.94.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 12:38 -0400 schrieb Bill Nottingham:
> Kevin Kofler (kevin.kofler at chello.at) said: 
> > Bill Nottingham <notting <at> redhat.com> writes:
> > > There are descriptions which are translated as well....
> > 
> > Well, leave it blank, leave it in English (untranslated), put just a URL for 
> > the upstream web page as the description
> 
> ... or, actually follow the string freeze, and the string freeze break
> policy.

The first constructive statement I hear from a FeSCo member. In fact you
are the _only_ FeSCo member who responded to my mail at all.
> 
> > too, ... - anything is better than having a set of packages all packaged and 
> > reviewed, but hidden from users (not listed in comps, and rejected as a feature 
> > on the ground that it isn't in comps).
> 
> I'm sorry, but I'm missing the outrage -

I will try to explain it to you, please read below.

>  the feature page listed the
> following things, under 'Scope':
>   
>   * Package Reviews  (were not fully done)

But that's not my fault I guess.
>   
>   * Comps: new group with id "lxde-desktop", name "LXDE"...
> 	o mandatory: lxde-common, lxpanel, openbox, pcmanfm
> 	o default: gpicview, leafpad, lxappearance, lxtask, lxterminal, obconf, xarchiver
> 	... (wasn't done)

Wasn't done because
      * of the missing reviews
      * I expected someone from FeSCo to give me a go.

> 
> and, under 'Test Plan':
>   
>   As most of the packages are already in fedora they are proven to be stable.

Sorry to interrupt here, but this is important: It was well documented
that there already LXDE packages in Fedora for quite a while. There also
is a detailed list of which package is available for what release(s).

>  So we need to
>   
>   1. get the 2 missing packages into rawhide ASAP so they are included in the F10 Beta
>   2. add packages to comps
>   3. test that installation with yum-groupinstall works correctly
>   4. test fresh installs with the beta 
> 
> It wasn't even to having step 1 completed. So, exactly what else is there to
> do when even the basic scope and test plan of the feature isn't ready?

Bill, I _do_ understand that my feature has been dropped because it
is/was not testable and it breaks the string freeze, but I can not
accept the way _how_ this decision was made. Let me quote the complete
discussion about LXDE:

> bpepple: Feature: https://fedoraproject.org/wiki/Features/LXDE
> nirik: for lxde, sadly 2 packages are still in review... so I think it needs to go to 11 (ha ha).
> dgilmore: so not testable
> bpepple: nirik: do we know what's holding up those 2 reviews?
> nirik: unless those packages aren't critical for testing, but I think they are.
> nirik: bpepple: I glanced at them and there was a lot of discussion about what should be a subpackage, etc.
> wwoods: none of the LXDE packages are even built, AFAICT
> nirik: wwoods: some are, but thats because they were already in... like openbox is the windowmanager.
> notting: well, if they try and add the comps group now, they'll be breaking the string freeze
> nirik: yeah, so I think this should move back to next release... if they get it sooner great, we can trumpet it in 11
> bpepple: nirik: +1
> notting: +1
> bpepple: anyone disagree with pushing LXDE, otherwise we can move on.

Obviously the only one who was at least a little informed is nirik, he's
also the only one who apologized for "the lack of communication" in a
conversation we had yesterday. But nirik is wrong too: Those LXDE
packages that are already in Fedora are not there because they have been
forever but because they were part of my feature (lxtask, lxterminal,
lxlauncher, ...).
 
So the decision was made under the assumption that _none_ of the LXDE
packages has ever passed a review. How can somebody who has read the
feature page claim that? Why did nobody answer him back?

Summing it all up: My outrage is because
      * nobody contacted my to ask me for status or to tell me the
        feature was dropped. Nobody contacted me at all.
      * the wiki says [1]: "The feature owner is responsible for
        watching any owned pages for state changes, using the wiki watch
        feature." That's what I did, nevertheless I did not get
        notified.
      * I think I did everything I could to rescue my feature. I someone
        contacted me I would have responded.
      * the decision was made by people who obviously did not read the
        feature page and have no interest in the feature. If somebody
        has not read the page he should not speak up on that topic or
        decide about it, and if he has further question he should ask.
      * no FeSCo member except from Bill reacted to my previous mails.

> 
> Bill
> 

Once again: I accept that my feature is delayed, but I can not accept
the way it was done.

Regards,
Christoph

[1] http://fedoraproject.org/wiki/Features/Policy/Governance



From a.badger at gmail.com  Wed Oct  8 18:25:37 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 11:25:37 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <48ECEFB9.1080600@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
Message-ID: <48ECFB21.7060301@gmail.com>

Karsten Hopp wrote:

> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get
> that through
> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm
> going to
> prepare a Wiki page with details about that.
> 
It doesn't need FESCo approval.  It does need discussion, wide
publication, and possibly an offer to help packagers who are affected by
the change.  A wiki page is definitely a good place to start.

If you feel the change is too disruptive to land in the main repo until
some things have been fixed (even in the earliest period of the F-11
rawhide cycle) you can coordinate with rel-eng to have a separate build
tag where you work on fixing the packages that break before turning it
loose on the masses.

-Toshio

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

From opensource at till.name  Wed Oct  8 18:30:04 2008
From: opensource at till.name (Till Maas)
Date: Wed, 08 Oct 2008 20:30:04 +0200
Subject: Remove a branch directory completely from cvs
In-Reply-To: <20081008114833.6dda4ea7@ohm.scrye.com>
References: <200810071726.44086.opensource@till.name>
	<200810072032.03794.opensource@till.name>
	<20081008114833.6dda4ea7@ohm.scrye.com>
Message-ID: <200810082030.14249.opensource@till.name>

On Wed October 8 2008, Kevin Fenzi wrote:
> On Tue, 07 Oct 2008 20:31:49 +0200
>
> opensource at till.name (Till Maas) wrote:
> > On Tue October 7 2008, Kevin Fenzi wrote:

> > > Perhaps we could look at archiving off all those old branches if
> > > they are causing a problem?
> >
> > After I got this working, the next step was to suggest to remove all
> > old branches (F-7 and older) for every package in the near future.
>
> Why not ask infrastructure to see about moving those all off to a
> archive site/location?

I created a ticket:
https://fedorahosted.org/fedora-infrastructure/ticket/893

> > The reason why I want this done, is that they mess up some packages,
> > where there are now 10 or more branch directories.
>
> Oh? how?

I meant, that they mess up the package directory, i.e. harder to see which 
branches are there.

> > Also it takes
> > unecessarily long for to checkout packages. Especially packages that
> > not only have many branches, but also a lot of patches.
>
> That shouldn't be a function of how many branches there are, but how
> many files/revisions are in CVS for the files you are checking out.
>
> Wouldn't it be better to look at moving to a newer VCS that can handle
> this case better? You might look and add that as a desired feature for
> the next VCS.

Iirc Jesse Keating asked for features for the next VCS some time ago, I 
already proposed it back then and it was added to the list.

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/20081008/00f18003/attachment.sig>

From Jochen at herr-schmitt.de  Wed Oct  8 18:31:18 2008
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 08 Oct 2008 20:31:18 +0200
Subject: gcc-4.3.2 related buiid issue
Message-ID: <48ECFC76.7080706@herr-schmitt.de>

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

Hallo,

I have try to build the most recent release of highlight-2.6.13 on koji.

Unfortunately, I have got the following error messages:

main.o: In function
`HighlightApp::printDebugInfo(highlight::LanguageDefinition const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&)':
/builddir/build/BUILD/highlight-2.6.13/src/main.cpp:107: undefined
reference to `Pattern::getPattern() const'
main.o: In function
 `HighlightApp::analyzeFile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)':
/builddir/build/BUILD/highlight-2.6.13/src/main.cpp:266: undefined
reference to `Pattern::matches(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, unsigned long)'
./libhighlight.a(codegenerator.o): In function
`highlight::CodeGenerator::matchRegex(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)':
/builddir/build/BUILD/highlight-2.6.13/src/codegenerator.cpp:381:
undefined reference to `Pattern::createMatcher(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)'
./libhighlight.a(codegenerator.o): In function
`highlight::CodeGenerator::checkSpecialCmd()':
/builddir/build/BUILD/highlight-2.6.13/src/codegenerator.cpp:1520:
undefined reference to `Pattern::compile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/builddir/build/BUILD/highlight-2.6.13/src/codegenerator.cpp:1521:
undefined reference to `Pattern::createMatcher(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)'
./libhighlight.a(codegenerator.o): In function `~auto_ptr':
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../include/c++/4.3.2/bits/basic_string.h:286:
undefined reference to `Pattern::~Pattern()'
./libhighlight.a(codegenerator.o): In function `~auto_ptr':
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../include/c++/4.3.2/backward/auto_ptr.h:173:
undefined reference to `Pattern::~Pattern()'
./libhighlight.a(languagedefinition.o): In function
`highlight::LanguageDefinition::extractRegex(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:80:
undefined reference to `Pattern::createMatcher(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)'
./libhighlight.a(languagedefinition.o): In function `~RegexElement':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.h:239:
undefined reference to `Pattern::~Pattern()'
./libhighlight.a(languagedefinition.o): In function
`highlight::LanguageDefinition::addSymbol(std::basic_stringstream<char,
std::char_traits<char>, std::allocator<char> >&, highlight::State,
highlight::State, bool, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, unsigned int)':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:64:
undefined reference to `Pattern::compile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
./libhighlight.a(languagedefinition.o): In function
`highlight::LanguageDefinition::addKeywords(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
highlight::State, highlight::State, int)':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:147:
undefined reference to `Pattern::compile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
./libhighlight.a(languagedefinition.o): In function
`highlight::LanguageDefinition::load(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, bool)':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:253:
undefined reference to `Pattern::compile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:255:
undefined reference to `
make[1]: Leaving directory `/builddir/build/BUILD/highlight-2.6.13/src'
RPM build errors:
Pattern::compile(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, unsigned long)'
./libhighlight.a(languagedefinition.o): In function `LanguageDefinition':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:41:
undefined reference to `Pattern::compile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
./libhighlight.a(languagedefinition.o):/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:41:
more undefined references to `Pattern::compile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
follow
./libhighlight.a(languagedefinition.o): In function `~RegexElement':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.h:239:
undefined reference to `Pattern::~Pattern()'
./libhighlight.a(languagedefinition.o): In function `~LanguageDefinition':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:48:
undefined reference to `Pattern::~Pattern()'
./libhighlight.a(languagedefinition.o): In function `~RegexElement':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.h:239:
undefined reference to `Pattern::~Pattern()'
./libhighlight.a(languagedefinition.o): In function `~LanguageDefinition':
/builddir/build/BUILD/highlight-2.6.13/src/languagedefinition.cpp:48:
undefined reference to `Pattern::~Pattern()'
collect2: ld returned 1 exit status
make[1]: *** [compile] Error 1

Beause this issue doesn't occurs on F-9, I will ask, if anyone have a
hint to solveing
this issue.

The full build log may be find at:

http://koji.fedoraproject.org/koji/getfile?taskID=868972&name=build.log

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjs/GMACgkQT2AHK6txfgxIMQCcDlUz3oA9RRhuWsJ+PwEgd24P
39AAoKyuFfEeeggL9aIcB1vwgJEH76f8
=R71/
-----END PGP SIGNATURE-----



From mschwendt at gmail.com  Wed Oct  8 18:31:30 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 8 Oct 2008 20:31:30 +0200
Subject: rawhide report: 20081006 changes
In-Reply-To: <1223484275.3889.130.camel@code.and.org>
References: <20081006115146.968411F81C8@releng2.fedora.phx.redhat.com>
	<1223295310.3564.1037.camel@beck.corsepiu.local>
	<20081006162209.9984d1cd.mschwendt@gmail.com>
	<1223310041.9987.28.camel@luminos.localdomain>
	<20081006191001.2955ac34.mschwendt@gmail.com>
	<1223313586.9987.33.camel@luminos.localdomain>
	<20081006203335.c31510fe.mschwendt@gmail.com>
	<1223318479.9987.35.camel@luminos.localdomain>
	<1223484275.3889.130.camel@code.and.org>
Message-ID: <20081008203130.763a0f34.mschwendt@gmail.com>

On Wed, 08 Oct 2008 12:44:35 -0400, James Antill wrote:

[race in mash+createrepo]

> This should fix it:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=868762
> 
> ...the patch being basically:
> 
> -            csumo = open(csumfile, 'w')
> +
> +            #  This is atomic cache creation via. rename, so we can have two
> +            # tasks using the same cachedir ... mash does this.
> +            csumo = tempfile.NamedTemporaryFile(mode='w', dir=self.crp_cachedir
>              csumo.write(checksum)
>              csumo.close()
> +            os.rename(csumo.name, csumfile)
> 
> 
> ...it'll get upstream as soon as I can push :).

Looks good. It's the most you can do in createrepo without adding locks.
A small penalty remains, because the same checksum may be generated more
than once in a race-condition. Neglectable IMO.



From myfedora at richip.dhs.org  Wed Oct  8 18:32:32 2008
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 08 Oct 2008 12:32:32 -0600
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
In-Reply-To: <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>	<48EB03C6.9080300@leemhuis.info>
	<mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
Message-ID: <48ECFCC0.4020907@richip.dhs.org>

Matej Cepl wrote:
> On 2008-10-07, 06:37 GMT, Thorsten Leemhuis wrote:
>   
>> Afaics and iirc it was announced just 24 hours before the 
>> meeting in question that the sbin feature is going to be 
>> discussed:
>> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00806.html
>>
>> Do you consider that enough time to voice objections? I don't. But 
>> that's IMHO not a problem in our workflow, as we afaics always can make 
>> adjustments even when things got decided.
>>     
>
> And I think, this is much more important than the matter here 
> itself. Last year there was another huge flamewar about replacing 
> sysvinit with upstart. Lot and lot of well argued arguments were 
> thrown against upstart (it doesn't make much difference, only 
> trouble) so I thought that this idea is safely in the grave.  
> Except couple of weeks after the last flames were vanquished, yum 
> brought me upstart replacing sysvinit.
>
> Does anybody from FESCO cares about what's discussed here, or do 
> they let us waste our time and decide whatever they wanted all 
> the time anyway?
>
> (sorry for offended tone of the message, but I am offended by 
> this),
>   

Boils down to voting for individual decisions versus voting for your 
representative (FESCo, in this case). In the age of the Internet (where 
creating a poll on a bb is soo easy), I'm not even sure why the 
community isn't more involved, but hey. Anyway, as I understand it, the 
people in FESCo are who you voted for. I'm not sure if the type of 
democracy we have here makes them liable to who voted for them (and 
should therefore justify their decisions). Just vote for your candidates 
wisely and if there are any arguments not to vote for a person, put that 
on the wiki-for-candidates somewhere, ;).
--

Richi Plana



From luca at foppiano.org  Wed Oct  8 18:38:51 2008
From: luca at foppiano.org (Luca Foppiano)
Date: Wed, 08 Oct 2008 20:38:51 +0200
Subject: [Fedora-packaging] looking for a sponsor and review ;)
In-Reply-To: <1223386136.3900.33.camel@sboing.byte-code.lan>
References: <1223386136.3900.33.camel@sboing.byte-code.lan>
Message-ID: <1223491131.4016.21.camel@sboing.byte-code.lan>

On Tue, 2008-10-07 at 15:28 +0200, Luca Foppiano wrote:
> hi all ;-)
> 	I don't know if this is the right place to ask, but I submitted a
> package request review and I'm looking for a sponsor.
> 
> The package is symbolic (https://fedorahosted.org/symbolic) and my
> request is here [1].
> 
> I think the spec file is pretty good, but I'm not sure it's perfect.
> 
> Thanks in advance.
> Luca
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=465478

the spec file is just checked with rpmlint and IMHO respect the fedora
packaging guidelines.

Anybody interested?

Luca


-- 
Today is Sweetmorn, the 62nd day of Bureaucracy in the YOLD 3174

May all your PUSHes be POPped.



From limb at jcomserv.net  Wed Oct  8 18:46:30 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 8 Oct 2008 13:46:30 -0500 (CDT)
Subject: [Fedora-packaging] looking for a sponsor and review ;)
In-Reply-To: <1223491131.4016.21.camel@sboing.byte-code.lan>
References: <1223386136.3900.33.camel@sboing.byte-code.lan>
	<1223491131.4016.21.camel@sboing.byte-code.lan>
Message-ID: <56203.198.175.55.5.1223491590.squirrel@mail.jcomserv.net>


> On Tue, 2008-10-07 at 15:28 +0200, Luca Foppiano wrote:
>> hi all ;-)
>> 	I don't know if this is the right place to ask, but I submitted a
>> package request review and I'm looking for a sponsor.
>>
>> The package is symbolic (https://fedorahosted.org/symbolic) and my
>> request is here [1].
>>
>> I think the spec file is pretty good, but I'm not sure it's perfect.
>>
>> Thanks in advance.
>> Luca
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=465478
>
> the spec file is just checked with rpmlint and IMHO respect the fedora
> packaging guidelines.
>
> Anybody interested?

I'll take a peek.

> Luca
>
>
> --
> Today is Sweetmorn, the 62nd day of Bureaucracy in the YOLD 3174
>
> May all your PUSHes be POPped.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From paul at all-the-johnsons.co.uk  Wed Oct  8 19:11:25 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 08 Oct 2008 20:11:25 +0100
Subject: Building mono-tools on f9
Message-ID: <1223493085.15158.16.camel@PB3.Linux>

Hi,

I'm trying to get mono-tools to build for f9 on koji and keep hitting a
problem that gnome-desktop-sharp-devel isn't available. It is in
f9-updates-testing currently.

Am I missing something which is totally different between building for
rawhide (build a new package, wait a few hours for it to hit properly,
then build against it) and f9? I need to get this sorted so I can get
monodevelop-1.07 into f9

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/00f10912/attachment.sig>

From a.badger at gmail.com  Wed Oct  8 19:20:30 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 12:20:30 -0700
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223489352.3434.94.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>	<20081007184626.GB4377@nostromo.devel.redhat.com>	<loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
Message-ID: <48ED07FE.4080604@gmail.com>

Christoph Wickert wrote:
> Am Mittwoch, den 08.10.2008, 12:38 -0400 schrieb Bill Nottingham:
>> Kevin Kofler (kevin.kofler at chello.at) said: 
>>> Bill Nottingham <notting <at> redhat.com> writes:
>>>> There are descriptions which are translated as well....
>>> Well, leave it blank, leave it in English (untranslated), put just a URL for 
>>> the upstream web page as the description
>> ... or, actually follow the string freeze, and the string freeze break
>> policy.
> 
> The first constructive statement I hear from a FeSCo member. In fact you
> are the _only_ FeSCo member who responded to my mail at all.
>>> too, ... - anything is better than having a set of packages all packaged and 
>>> reviewed, but hidden from users (not listed in comps, and rejected as a feature 
>>> on the ground that it isn't in comps).
>> I'm sorry, but I'm missing the outrage -
> 
> I will try to explain it to you, please read below.
> 
>>  the feature page listed the
>> following things, under 'Scope':
>>   
>>   * Package Reviews  (were not fully done)
> 
> But that's not my fault I guess.

There is no fault here... there is only work done or not done.  If the
Feature says that the packages are needed for the feature to be complete
and they are not reviewed then the feature is incomplete.

Steps you could take:
  * Get other lxde interested packagers to perform reviews
  * Trade reviews with people
  * If the packages are "very nice to have but not truly required" you
could drop them from the list of packages that must be in for the
feature to be complete.

>>   
>>   * Comps: new group with id "lxde-desktop", name "LXDE"...
>> 	o mandatory: lxde-common, lxpanel, openbox, pcmanfm
>> 	o default: gpicview, leafpad, lxappearance, lxtask, lxterminal, obconf, xarchiver
>> 	... (wasn't done)
> 
> Wasn't done because
>       * of the missing reviews
>       * I expected someone from FeSCo to give me a go.
> 
This would be miscommunication, then.  AFAIK, comps is open to
maintainers to make changes to.  Maintainers are expected to do that.

>> and, under 'Test Plan':
>>   
>>   As most of the packages are already in fedora they are proven to be stable.
> 
> Sorry to interrupt here, but this is important: It was well documented
> that there already LXDE packages in Fedora for quite a while. There also
> is a detailed list of which package is available for what release(s).
> 
>>  So we need to
>>   
>>   1. get the 2 missing packages into rawhide ASAP so they are included in the F10 Beta
>>   2. add packages to comps
>>   3. test that installation with yum-groupinstall works correctly
>>   4. test fresh installs with the beta 
>>
>> It wasn't even to having step 1 completed. So, exactly what else is there to
>> do when even the basic scope and test plan of the feature isn't ready?
> 
> Bill, I _do_ understand that my feature has been dropped because it
> is/was not testable and it breaks the string freeze, but I can not
> accept the way _how_ this decision was made. Let me quote the complete
> discussion about LXDE:
> 
>> bpepple: Feature: https://fedoraproject.org/wiki/Features/LXDE
>> nirik: for lxde, sadly 2 packages are still in review... so I think it needs to go to 11 (ha ha).
>> dgilmore: so not testable
>> bpepple: nirik: do we know what's holding up those 2 reviews?
>> nirik: unless those packages aren't critical for testing, but I think they are.
>> nirik: bpepple: I glanced at them and there was a lot of discussion about what should be a subpackage, etc.
>> wwoods: none of the LXDE packages are even built, AFAICT
>> nirik: wwoods: some are, but thats because they were already in... like openbox is the windowmanager.
>> notting: well, if they try and add the comps group now, they'll be breaking the string freeze
>> nirik: yeah, so I think this should move back to next release... if they get it sooner great, we can trumpet it in 11
>> bpepple: nirik: +1
>> notting: +1
>> bpepple: anyone disagree with pushing LXDE, otherwise we can move on.
> 
> Obviously the only one who was at least a little informed is nirik, he's
> also the only one who apologized for "the lack of communication" in a
> conversation we had yesterday. But nirik is wrong too: Those LXDE
> packages that are already in Fedora are not there because they have been
> forever but because they were part of my feature (lxtask, lxterminal,
> lxlauncher, ...).
>  
> So the decision was made under the assumption that _none_ of the LXDE
> packages has ever passed a review. How can somebody who has read the
> feature page claim that? Why did nobody answer him back?
> 
> Summing it all up: My outrage is because
>       * nobody contacted my to ask me for status or to tell me the
>         feature was dropped. Nobody contacted me at all.

There's definitely a need for better communication.  There have also
been features dropped as not-a-feature this year that I thought shouold
have been better communicated so that there was a chance to rewrite the
proposal so it was a feature.

We should have a rule like:
 Communication happens on the Feature Discussion Page
or:
  Communication happens via private email between the feature owner and
the feature wrangler
or:
  Communication happens via the FESCo Meeting Summary

so that everyone knows that there's a one-stop shop to put out and
receive information.

>       * the wiki says [1]: "The feature owner is responsible for
>         watching any owned pages for state changes, using the wiki watch
>         feature." That's what I did, nevertheless I did not get
>         notified.

I've heard that mediawiki doesn't work like people expect for watching
pages.  I'll admit that I haven't watched pages since the change to
mediawiki so I'm not sure how this works.

>       * I think I did everything I could to rescue my feature. I someone
>         contacted me I would have responded.
>       * the decision was made by people who obviously did not read the
>         feature page and have no interest in the feature. If somebody
>         has not read the page he should not speak up on that topic or
>         decide about it, and if he has further question he should ask.

These are a bit unfair.  The Feature Page shows that the feature is not
done.  Checking bugzilla shows that the page is up-to-date in regards to
the package review status.  Beta is a deadline for features and that has
come and gone.  So the Feature is plainly not completed whether you were
contacted or not; whether the people who commented knew all the
particulars or only some.

Can you be angry that communication wasn't good enough?  Sure.  But it
works both ways -- if the packages can't be reviewed in time but they
aren't necessary why not be proactive and take them off the list?  If
you feel you need them and they can be reviewed after Beta but before
final, why not ask for an extension?  If you're waiting for FESCo to
approve the new comps group, why not ask FESCo if you can move ahead on
that portion?

FESCo members should be reading the feature page but they will never be
able to be intimately familiar with all the Features being proposed.  In
other words, we can't expect them to know any more about a feature than
what is written on the Feature Page.  If you look at the Feature Page
and it looks like the Feature is not completed or doesn't express what
the Feature really is or leaves out something that might lead FESCo to
think it's not a feature it needs to be clarifies on the feature page so
they can understand it better.

>       * no FeSCo member except from Bill reacted to my previous mails.

heh.  I interpret that as a bunch of polite people not jumping in to say
 "Me too" but it could be frustrating.

-Toshio

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

From rjones at redhat.com  Wed Oct  8 19:23:08 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 8 Oct 2008 20:23:08 +0100
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223489352.3434.94.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
Message-ID: <20081008192308.GA3483@amd.home.annexia.org>

On Wed, Oct 08, 2008 at 08:09:12PM +0200, Christoph Wickert wrote:
>  * the decision was made by people who obviously did not read the
>    feature page and have no interest in the feature. If somebody
>    has not read the page he should not speak up on that topic or
>    decide about it, and if he has further question he should ask.

Fully agreed with you on this point.  If FESCo members would volunteer
to package up even some tiny MinGW package[1], then I think the
standard of debate on the MinGW issue would be hugely improved.

Rich.

[1] Something relatively uncomplicated like curl or expat.  Patches
welcome.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From kevin at scrye.com  Wed Oct  8 19:24:36 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 8 Oct 2008 13:24:36 -0600
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223489352.3434.94.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
Message-ID: <20081008132436.74d0a075@ohm.scrye.com>

On Wed, 08 Oct 2008 20:09:12 +0200
christoph.wickert at googlemail.com (Christoph Wickert) wrote:

> Am Mittwoch, den 08.10.2008, 12:38 -0400 schrieb Bill Nottingham:
> > Kevin Kofler (kevin.kofler at chello.at) said: 
> > > Bill Nottingham <notting <at> redhat.com> writes:
> > > > There are descriptions which are translated as well....
> > > 
> > > Well, leave it blank, leave it in English (untranslated), put
> > > just a URL for the upstream web page as the description
> > 
> > ... or, actually follow the string freeze, and the string freeze
> > break policy.
> 
> The first constructive statement I hear from a FeSCo member. In fact
> you are the _only_ FeSCo member who responded to my mail at all.

Sorry, I can't speak for the rest of the FESCo members, but I have been
really busy with my regular job and also I have been mostly in
agreement with the posts by Bill. To expect everyone to respond to a
post on a busy list in under 24 hours can be a bit much. 

> >   * Package Reviews  (were not fully done)
> 
> But that's not my fault I guess.

No it's not. I feel partially to blame, as I looked at those reviews
and they looked to be in progress, but it looks like no one is formally
reviewing them after all. ;( 

> >   * Comps: new group with id "lxde-desktop", name "LXDE"...
> > 	o mandatory: lxde-common, lxpanel, openbox, pcmanfm
> > 	o default: gpicview, leafpad, lxappearance, lxtask,
> > lxterminal, obconf, xarchiver ... (wasn't done)
> 
> Wasn't done because
>       * of the missing reviews
>       * I expected someone from FeSCo to give me a go.

A go for what? Adding the comps group? 

...snipp...

> Obviously the only one who was at least a little informed is nirik,
> he's also the only one who apologized for "the lack of communication"
> in a conversation we had yesterday. 

Yes, and I am sad there was a lack of communication, and I hope things
can be done better next time around. 

> But nirik is wrong too: Those LXDE
> packages that are already in Fedora are not there because they have
> been forever but because they were part of my feature (lxtask,
> lxterminal, lxlauncher, ...).

I'm not sure I understand this sentence... ? 
Yes, there are other lxde packages that have passed review and are
in, I understand that. 

> So the decision was made under the assumption that _none_ of the LXDE
> packages has ever passed a review. How can somebody who has read the
> feature page claim that? Why did nobody answer him back?

No, I never claimed that. I claimed that because 2 of them are missing
then the feature must wait. Is that incorrect? 

> Summing it all up: My outrage is because
>       * nobody contacted my to ask me for status or to tell me the
>         feature was dropped. Nobody contacted me at all.

I am very sorry for that. ;( 

>       * the wiki says [1]: "The feature owner is responsible for
>         watching any owned pages for state changes, using the wiki
> watch feature." That's what I did, nevertheless I did not get
>         notified.

That needs to be changed/fixed. The wiki page watch is not sufficent
here I don't think. 

>       * I think I did everything I could to rescue my feature. I
> someone contacted me I would have responded.
>       * the decision was made by people who obviously did not read the
>         feature page and have no interest in the feature. If somebody
>         has not read the page he should not speak up on that topic or
>         decide about it, and if he has further question he should ask.

I don't understand this. I like the feature, I was using it on my phone
for a while. it's a nice DE. I would love to see it in Fedora. 

It was not testable by Beta, so it shouldn't be advertised as a feature
this time. I'm sorry that that is due to communication problems. ;( 
I find it very unfortunate.  

It's after string freeze, but you can get an exception for that: 
https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy

So, you can get things in place, and we can advertise this as a Feature
for F11. 

>       * no FeSCo member except from Bill reacted to my previous mails.

Sorry. 

> Once again: I accept that my feature is delayed, but I can not accept
> the way it was done.
> 
> Regards,
> Christoph

kevin

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

From gnomeuser at gmail.com  Wed Oct  8 19:25:53 2008
From: gnomeuser at gmail.com (David Nielsen)
Date: Wed, 8 Oct 2008 21:25:53 +0200
Subject: Building mono-tools on f9
In-Reply-To: <1223493085.15158.16.camel@PB3.Linux>
References: <1223493085.15158.16.camel@PB3.Linux>
Message-ID: <1dedbbfc0810081225h31a8bd76tdaa8b875c17f63a1@mail.gmail.com>

Den 8. okt. 2008 21.11 skrev Paul <paul at all-the-johnsons.co.uk>:

> Hi,
>
> I'm trying to get mono-tools to build for f9 on koji and keep hitting a
> problem that gnome-desktop-sharp-devel isn't available. It is in
> f9-updates-testing currently.
>
> Am I missing something which is totally different between building for
> rawhide (build a new package, wait a few hours for it to hit properly,
> then build against it) and f9? I need to get this sorted so I can get
> monodevelop-1.07 into f9
>

I suspect you would need to push the requirements to F9 proper before you
could build mono stuff.. rel-eng/luke?

I don't know if we can currently do a seperate branch build all the mono
stuff then push it to stable in one swift motion without having to wait fo
such things.. anyone care to enlighten me?

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/45b7ef96/attachment.htm>

From kevin at scrye.com  Wed Oct  8 19:31:15 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 8 Oct 2008 13:31:15 -0600
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
In-Reply-To: <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info>
	<mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081008133115.0c164ef8@ohm.scrye.com>

On Wed, 08 Oct 2008 12:48:54 +0200
mcepl at redhat.com (Matej Cepl) wrote:

> On 2008-10-07, 06:37 GMT, Thorsten Leemhuis wrote:
> > Afaics and iirc it was announced just 24 hours before the 
> > meeting in question that the sbin feature is going to be 
> > discussed:
> > https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00806.html
> >
> > Do you consider that enough time to voice objections? I don't. But 
> > that's IMHO not a problem in our workflow, as we afaics always can
> > make adjustments even when things got decided.
> 
> And I think, this is much more important than the matter here 
> itself. Last year there was another huge flamewar about replacing 
> sysvinit with upstart. Lot and lot of well argued arguments were 
> thrown against upstart (it doesn't make much difference, only 
> trouble) so I thought that this idea is safely in the grave.  
> Except couple of weeks after the last flames were vanquished, yum 
> brought me upstart replacing sysvinit.

Did this email come from the past? Do we really want to talk about
upstart again? 

> Does anybody from FESCO cares about what's discussed here, or do 
> they let us waste our time and decide whatever they wanted all 
> the time anyway?

I don't speak for FESCo, but I do care what gets discussed here. 
I however don't think it should just be a majority rule or 'he who
shouts loudest' or even 'who we think "won" the discussion. 

There were good reasons for Upstart, and a majority of FESCo decided
the feature was worth it. I think the mailing lists (and the FUDcon
session on upstart) were both valuable input into this decision making. 

> (sorry for offended tone of the message, but I am offended by 
> this),

I'm sorry you're offended. We can't please everyone all the time with
every decision. If you don't like the decisions, feel free to run for
FESCo and/or vote/not vote for people who you disagree with.  

> Mat?j

kevin

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

From opensource at till.name  Wed Oct  8 19:39:05 2008
From: opensource at till.name (Till Maas)
Date: Wed, 08 Oct 2008 21:39:05 +0200
Subject: Building mono-tools on f9
In-Reply-To: <1223493085.15158.16.camel@PB3.Linux>
References: <1223493085.15158.16.camel@PB3.Linux>
Message-ID: <200810082139.16223.opensource@till.name>

On Wed October 8 2008, Paul wrote:

> I'm trying to get mono-tools to build for f9 on koji and keep hitting a
> problem that gnome-desktop-sharp-devel isn't available. It is in
> f9-updates-testing currently.
>
> Am I missing something which is totally different between building for
> rawhide (build a new package, wait a few hours for it to hit properly,
> then build against it) and f9? I need to get this sorted so I can get
> monodevelop-1.07 into f9

You need to kindly ask rel-eng to move a package from updates-testing into the 
buildroot at:

https://fedorahosted.org/rel-eng/newticket
In case the package you want to get moved is not yours, you better ask the 
maintainer first.

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/20081008/b1babc06/attachment.sig>

From a.badger at gmail.com  Wed Oct  8 19:47:02 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 12:47:02 -0700
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <20081007190654.GE11246@amd.home.annexia.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007190654.GE11246@amd.home.annexia.org>
Message-ID: <48ED0E36.9030701@gmail.com>

Richard W.M. Jones wrote:
> The Haskell feature was dropped at the same meeting just because the
> guy maintaining it wasn't there.  Probably he didn't know the meeting
> was happening because he didn't read some announcement in one of the
> multitude of mailing lists that we need to keep up with.  Or being in
> Europe, he might have been busy at 7/8pm in the evening.
> 
Just to clarify, the feature wasn't dropped because loupgaroublond
wasn't there.  It was dropped because the feature page was incomplete.
loupgaroublond was pinged because people knew he was in charge of the
feature and wanted to see if he could clarify the remaining points.

> As a positive take from this, I think that the meeting organizer
> should CC all people who should be at the meeting, when sending the
> announcement.  I also think that FESCo members shouldn't comment on
> proposals unless they are technically au fait with them.  This means
> FESCo members taking some time each week to do technical work with the
> projects.
> 
I think this is coming at it wrong but then I haven't been involved with
 FESCo or the Feature process since it was first proposed and voted on.
 at that time we envisioned FESCo having the following reasons to review:

1) Is this legal for Fedora?
2) Is this a feature?
3) Can this feature be finished in time?
4) Does this feature need coordination with packagers not directly a
part of the feature?
  a) If so, is it something Fedora wants to do?
  b) If so, how do we help inform other packagers of what to do?

The amount of technical knowledge needed for 1 and 2 is not large.  For
3 there's some technical knowledge but also non-tecnhnical concerns like
how much time the Feature owner has to devote to the process.  #4 does
require a technical evaluation.

In this round, #3 was the predominant reason for dropping a feature.
(#1, 2, and 4 are worked through early in the process when the feature
is first proposed).  Beta is here.  If the feature cannot be tested at
this time (because packages aren't, code hasn't been written, or it's
not clear what has been done) then it's probably going to get dropped as
a feature.  Otherwise, beta is a meaningless term.

-Toshio

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

From rjones at redhat.com  Wed Oct  8 20:13:28 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 8 Oct 2008 21:13:28 +0100
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <48ED0E36.9030701@gmail.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007190654.GE11246@amd.home.annexia.org>
	<48ED0E36.9030701@gmail.com>
Message-ID: <20081008201328.GA3770@amd.home.annexia.org>

On Wed, Oct 08, 2008 at 12:47:02PM -0700, Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
> > [...]  I also think that FESCo members shouldn't comment on
> > proposals unless they are technically au fait with them.  This means
> > FESCo members taking some time each week to do technical work with the
> > projects.
> > 
> I think this is coming at it wrong but then I haven't been involved with
>  FESCo or the Feature process since it was first proposed and voted on.
>  at that time we envisioned FESCo having the following reasons to review:
[.. feature stuff ..]
> The amount of technical knowledge needed for 1 and 2 is not large.  For
> 3 there's some technical knowledge but also non-tecnhnical concerns like
> how much time the Feature owner has to devote to the process.  #4 does
> require a technical evaluation.

My point above maybe doesn't refer only to the feature process, but it
is important for the MinGW acceptance process.

There have been all sorts of claims flying around about MinGW.  From
my point of view, as an "expert" or at least as someone who has done a
lot of practical work packaging stuff for MinGW, those claims look ...
well ... detached from reality.

So I'm convinced that if members of the 'Fedora hierarchy', FESCo,
board, etc., would actually take the time to do some work in MinGW
packaging, then at least they'd be speaking from a position of
knowledge.  It needn't be a lot of technical work, but some would
help.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From a.badger at gmail.com  Wed Oct  8 20:22:12 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 13:22:12 -0700
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <20081008201328.GA3770@amd.home.annexia.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>	<20081007190654.GE11246@amd.home.annexia.org>	<48ED0E36.9030701@gmail.com>
	<20081008201328.GA3770@amd.home.annexia.org>
Message-ID: <48ED1674.6090201@gmail.com>

Richard W.M. Jones wrote:
> On Wed, Oct 08, 2008 at 12:47:02PM -0700, Toshio Kuratomi wrote:
>> Richard W.M. Jones wrote:
>>> [...]  I also think that FESCo members shouldn't comment on
>>> proposals unless they are technically au fait with them.  This means
>>> FESCo members taking some time each week to do technical work with the
>>> projects.
>>>
>> I think this is coming at it wrong but then I haven't been involved with
>>  FESCo or the Feature process since it was first proposed and voted on.
>>  at that time we envisioned FESCo having the following reasons to review:
> [.. feature stuff ..]
>> The amount of technical knowledge needed for 1 and 2 is not large.  For
>> 3 there's some technical knowledge but also non-tecnhnical concerns like
>> how much time the Feature owner has to devote to the process.  #4 does
>> require a technical evaluation.
> 
> My point above maybe doesn't refer only to the feature process, but it
> is important for the MinGW acceptance process.
> 
> There have been all sorts of claims flying around about MinGW.  From
> my point of view, as an "expert" or at least as someone who has done a
> lot of practical work packaging stuff for MinGW, those claims look ...
> well ... detached from reality.
> 
> So I'm convinced that if members of the 'Fedora hierarchy', FESCo,
> board, etc., would actually take the time to do some work in MinGW
> packaging, then at least they'd be speaking from a position of
> knowledge.  It needn't be a lot of technical work, but some would
> help.
> 
Looking at things the other way, a lot of the things that you claim are
specific for MinGW whereas FESCo is designing something that applies to
cross-compilation in general.  So far, I've liked what danpb and dwmw2
have had to say on the issues....  Maybe they should be on the
presidential ticket :-)

-Toshio

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

From jlaska at redhat.com  Wed Oct  8 20:22:09 2008
From: jlaska at redhat.com (James Laska)
Date: Wed, 08 Oct 2008 16:22:09 -0400
Subject: 2008-08-09 - Fedora Test Day - F10 Beta and GlitchFreeAudio
	(pulseaudio)
Message-ID: <1223497329.20394.8.camel@flatline>

Greetings folks,

I'd like to invite testers and users to join #fedora-qa this Thursday,
October 9, 2008.  Testing efforts will focus on gathering Fedora 10 Beta
feedback and exercising GlitchFreeAudio (aka pulseaudio).

Come with questions, bug reports, and/or suggested test areas.

More details will be posted to
https://fedoraproject.org/wiki/QA/Test_Days/2008-10-09.

Additionally, bring your XO running Fedora
(https://fedoraproject.org/wiki/QA/TestPlans/Fedora10_On_XO) and share
your findings/pain_points.

See you there,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/b633cfe2/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 rjones at redhat.com  Wed Oct  8 20:45:02 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 8 Oct 2008 21:45:02 +0100
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <48ED1674.6090201@gmail.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007190654.GE11246@amd.home.annexia.org>
	<48ED0E36.9030701@gmail.com>
	<20081008201328.GA3770@amd.home.annexia.org>
	<48ED1674.6090201@gmail.com>
Message-ID: <20081008204502.GB3770@amd.home.annexia.org>

On Wed, Oct 08, 2008 at 01:22:12PM -0700, Toshio Kuratomi wrote:
> Looking at things the other way, a lot of the things that you claim are
> specific for MinGW whereas FESCo is designing something that applies to
> cross-compilation in general.

This just backs up what I said.

If you'd spent time porting a package to MinGW you'd see that
cross-compilation is a minor and rather insignificant part of the
whole process.  You just do './configure --host=i686-pc-mingw32' and
that does the whole cross-compilation thing.  The complicated stuff is
when you get 20 pages of compiler errors because the program assumes
it can make POSIX calls on a system which only has a Win32 API (no
libc for you).

So this whole business of MinGW being "applicable to cross-compilation
in general" seems (from my point of view) to be detached from reality.

If you want to do a package or two and then come back from a position
of knowledge on this subject, I'd appreciate it, because FESCo and the
other committees _ought_ to be approaching these decisions from a
position of technical excellence.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From jwboyer at gmail.com  Wed Oct  8 20:47:11 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 8 Oct 2008 16:47:11 -0400
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223489352.3434.94.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
Message-ID: <20081008204711.GA10613@yoda.jdub.homelinux.org>

On Wed, Oct 08, 2008 at 08:09:12PM +0200, Christoph Wickert wrote:
>Bill, I _do_ understand that my feature has been dropped because it
>is/was not testable and it breaks the string freeze, but I can not
>accept the way _how_ this decision was made. Let me quote the complete
>discussion about LXDE:
>
>> bpepple: Feature: https://fedoraproject.org/wiki/Features/LXDE
>> nirik: for lxde, sadly 2 packages are still in review... so I think it needs to go to 11 (ha ha).
>> dgilmore: so not testable
>> bpepple: nirik: do we know what's holding up those 2 reviews?
>> nirik: unless those packages aren't critical for testing, but I think they are.
>> nirik: bpepple: I glanced at them and there was a lot of discussion about what should be a subpackage, etc.
>> wwoods: none of the LXDE packages are even built, AFAICT
>> nirik: wwoods: some are, but thats because they were already in... like openbox is the windowmanager.
>> notting: well, if they try and add the comps group now, they'll be breaking the string freeze
>> nirik: yeah, so I think this should move back to next release... if they get it sooner great, we can trumpet it in 11
>> bpepple: nirik: +1
>> notting: +1
>> bpepple: anyone disagree with pushing LXDE, otherwise we can move on.
>
>Obviously the only one who was at least a little informed is nirik, he's
>also the only one who apologized for "the lack of communication" in a
>conversation we had yesterday. But nirik is wrong too: Those LXDE
>packages that are already in Fedora are not there because they have been
>forever but because they were part of my feature (lxtask, lxterminal,
>lxlauncher, ...).
> 
>So the decision was made under the assumption that _none_ of the LXDE
>packages has ever passed a review. How can somebody who has read the
>feature page claim that? Why did nobody answer him back?

The decision was made under the _fact_ that the Feature lacked packages
that had not passed review.  If they aren't all there, it can't be tested
by Beta.  It's really that simple.

josh



From christoph.wickert at googlemail.com  Wed Oct  8 20:49:46 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 08 Oct 2008 22:49:46 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <48ED07FE.4080604@gmail.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<48ED07FE.4080604@gmail.com>
Message-ID: <1223498986.23034.41.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 12:20 -0700 schrieb Toshio Kuratomi:
> Christoph Wickert wrote:
> > 
> > Wasn't done because
> >       * of the missing reviews
> >       * I expected someone from FeSCo to give me a go.
> > 
> This would be miscommunication, then.  AFAIK, comps is open to
> maintainers to make changes to.  Maintainers are expected to do that.

Wait: I'm expected to introduce a new group in comps without previous
discussion and without explicit permission from FeSCo? I remember
endless discussions about new groups here. If everybody was allowed to
make new groups whenever he wants I'm sure that comps will be hosed
pretty soon.

> We should have a rule like:
>  Communication happens on the Feature Discussion Page
> or:
>   Communication happens via private email between the feature owner and
> the feature wrangler
> or:
>   Communication happens via the FESCo Meeting Summary
> 
> so that everyone knows that there's a one-stop shop to put out and
> receive information.

+1.

> >       * the wiki says [1]: "The feature owner is responsible for
> >         watching any owned pages for state changes, using the wiki watch
> >         feature." That's what I did, nevertheless I did not get
> >         notified.
> 
> I've heard that mediawiki doesn't work like people expect for watching
> pages.  I'll admit that I haven't watched pages since the change to
> mediawiki so I'm not sure how this works.

Well, I got previous notifications from the wiki so I expect it to work.
Obviously my case was special: I think we are seeing both technical and
human failure here (I'm not excluding myself from the human failures).

> >       * I think I did everything I could to rescue my feature. I someone
> >         contacted me I would have responded.
> >       * the decision was made by people who obviously did not read the
> >         feature page and have no interest in the feature. If somebody
> >         has not read the page he should not speak up on that topic or
> >         decide about it, and if he has further question he should ask.
> 
> These are a bit unfair.  The Feature Page shows that the feature is not
> done.  Checking bugzilla shows that the page is up-to-date in regards to
> the package review status.  Beta is a deadline for features and that has
> come and gone.  So the Feature is plainly not completed whether you were
> contacted or not; whether the people who commented knew all the
> particulars or only some.

Agreed, but my point is: They don't need to know all details, but they
need to read the feature page. And if the page says that 9 out of 11
packages are done I expect FeSCo members to know that, not more, not
less, but I expect somebody to not incorrectly state that none of the
packages is available.

> Can you be angry that communication wasn't good enough?  Sure.  But it
> works both ways -- if the packages can't be reviewed in time but they
> aren't necessary why not be proactive and take them off the list?  

I could not take any of the missing packages off the list because they
all are necessary.

> If
> you feel you need them and they can be reviewed after Beta but before
> final, why not ask for an extension?  

Extension of what - the Beta? I think LXDE is not Gnome or Mozilla, so
we are not giving up our schedule for it.

> If you're waiting for FESCo to
> approve the new comps group, why not ask FESCo if you can move ahead on
> that portion?

I did not yet add the new group because it does not make sense without
the mandatory lxde-common package, but I'm afraid we are going into
details here.
I wasn't aware of the fact that my comps changes are affecting string
freeze, but the FeSCo members were. They accepted my feature only one
week before feature/string freeze, so somebody could have told me.

> FESCo members should be reading the feature page but they will never be
> able to be intimately familiar with all the Features being proposed.  In
> other words, we can't expect them to know any more about a feature than
> what is written on the Feature Page.  

Completely agreed, but obviously this was not the case here. From what I
read in the IRC log I even doubt that everybody knew the feature page.

> If you look at the Feature Page
> and it looks like the Feature is not completed or doesn't express what
> the Feature really is or leaves out something that might lead FESCo to
> think it's not a feature it needs to be clarifies on the feature page so
> they can understand it better.

The feature page was accepted both by the feature wrangler and FeSCo, so
I assume that the page is ok and doesn't leave anything out.

> >       * no FeSCo member except from Bill reacted to my previous mails.
> 
> heh.  I interpret that as a bunch of polite people not jumping in to say
>  "Me too" but it could be frustrating.

Although I don't subscribe to Bills point of view I honor that he
answered and I have to admit that he made valid points. From the rest of
the FeSCo members I'd like to know if they had really read the feature
page and - if so - how someone could state something incorrect then. I
don't mind a couple of "me too"s and if any of the members has criticism
on my behavior I'm surely going to take that into account.

> -Toshio
> 
Regards,
Christoph



From paul at all-the-johnsons.co.uk  Wed Oct  8 20:56:00 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 08 Oct 2008 21:56:00 +0100
Subject: A call for programmers...
Message-ID: <1223499360.15158.41.camel@PB3.Linux>

Hi,

Firstly, please excuse this massive cross post. Those who aren't
familiar with each other...

Association of C and C++ Users, this is Fedora
Fedora, Association of C and C++ Users
Association of C and C++ USers, this is Mono
Mono, Association of C and C++ Users.

I'm sure Fedora and Mono know each other ;-)

Every 2 years in the UK we have a fund raising event called Comic
Relief[1]. Comedians, singers and generally everyone gets together to
raise money which is used for grass roots programmes (in other words,
they build the infrastructure, teach people to be self-sufficient etc)
in the developing nations around the world as well as at home (home
being the UK).

Next year is one such year and in a moment of insanity, thought it would
be kind of cool to not only raise money for Comic Relief but also have a
world record attempt for the most number of programmed hours in a
day[2].

The idea is this. Everyone codes for an hour on a project and gets
sponsored for this hour. I'm sure any coder worth their salt can spare
an hour in a day for this and even if the sponsorship is in pennies, if
enough people do it, then pennies mount up to pounds.

Put it this way, if 744 do this then that will be the equivalent of a
months programming in a day. If they each raise 10UKP, that becomes 7440
UKP raised - all for just working for an hour!!!

I'm not sure yet of the full details (all work on one project, submit to
svn etc), but would certainly welcome ideas.

I will now return you to your scheduled things.

TTFN

Paul
[1] http://www.comicrelief.com
[2] The day being the 13th March
-- 
?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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/2d5bd567/attachment.sig>

From christoph.wickert at googlemail.com  Wed Oct  8 20:56:12 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 08 Oct 2008 22:56:12 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <20081008204711.GA10613@yoda.jdub.homelinux.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
Message-ID: <1223499372.23034.47.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 16:47 -0400 schrieb Josh Boyer:
> On Wed, Oct 08, 2008 at 08:09:12PM +0200, Christoph Wickert wrote:
>
> >So the decision was made under the assumption that _none_ of the LXDE
> >packages has ever passed a review. How can somebody who has read the
> >feature page claim that? Why did nobody answer him back?
> 
> The decision was made under the _fact_ that the Feature lacked packages
> that had not passed review.  If they aren't all there, it can't be tested
> by Beta.  It's really that simple.

As I wrote in a previous mail: I don't challenge that, but for me it not
"really that simple" but "really that disappointing". I've put a lot of
work into the feature and when I see that people hardly seem to read the
feature page or don't care about informing the feature owner is just
disappointing.

> josh
> 
Regards,
Christoph



From jwboyer at gmail.com  Wed Oct  8 20:59:51 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 8 Oct 2008 16:59:51 -0400
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <20081008192308.GA3483@amd.home.annexia.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008192308.GA3483@amd.home.annexia.org>
Message-ID: <20081008205951.GB10613@yoda.jdub.homelinux.org>

On Wed, Oct 08, 2008 at 08:23:08PM +0100, Richard W.M. Jones wrote:
>On Wed, Oct 08, 2008 at 08:09:12PM +0200, Christoph Wickert wrote:
>>  * the decision was made by people who obviously did not read the
>>    feature page and have no interest in the feature. If somebody
>>    has not read the page he should not speak up on that topic or
>>    decide about it, and if he has further question he should ask.
>
>Fully agreed with you on this point.  If FESCo members would volunteer
>to package up even some tiny MinGW package[1], then I think the
>standard of debate on the MinGW issue would be hugely improved.

If FESCo has to go and be an intimate part of a Feature in order
for it to get approved or discussed, then that is what I would
consider to be a very large failure.  Reality dictates that the
9 people in FESCo do not have infinite time to do explicit
things with every single Feature that gets presented.
FESCo is a steering committee. We rely on you, the developers,
to do your part for Features.

It's the Feature owners responsibility to present clear and 
concise information on the Feature.  You did that rather well
for MinGW.  Debate on things will naturally happen.  You also
did a good job participating there.  I believe I can honestly
say that you were the most active Feature owner for this release
in making sure your Feature was understood and completed.

And I'd like to point out that LXDE (and Haskell, and others)
were _approved_ for F10.  They were dropped later for nothing
more than lack of following the Feature process.  Not out of
spite, or lack of interest, or some evil desire to promote
only things that some Cabal cares about.

josh

(Btw, to your specific point, I cross compile packages all the
time.  A large majority of the discussion was generated by me.
So I don't think your axiom holds true at all.)



From seg at haxxed.com  Wed Oct  8 21:01:26 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 08 Oct 2008 16:01:26 -0500
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <20081007123307.GA19618@jadzia.bu.edu>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
Message-ID: <1223499686.26341.35.camel@localhost.localdomain>

On Tue, 2008-10-07 at 08:33 -0400, Matthew Miller wrote:
> On Tue, Oct 07, 2008 at 01:25:26AM -0400, Jon Stanley wrote:
> > The proper time to voice objections to this would have been there, 6
> > weeks ago now.
> 
> Well, as I thought the discussion had been left before that meeting, fixing
> the general problem of user-level commands in the wrong places was the
> feature and it was going to be solved properly. The feature is called "sbin
> sanity", and I'm 100% in support of that. The "ah, hell, just put everything
> in the path and call that sane" change came as a surprise to me.

https://fedoraproject.org/wiki/Features/SbinSanity

And under Scope it says: "Change the default PATH to
include /usr/local/sbin:/usr/sbin:/sbin for all users. Note that it must
come at the end of the path for normal users, or consolehelper will
break." According to the history, it's been there since at least May 24
2008, when it was imported from MoinMoin. A period of ~5 months.

If you're surprised by this, you simply aren't paying attention to the
feature process. I've seen many emails go out on fedora-announce about
the status of features, in which checking up on features you are
interested in is a single click away.

Also notable, in the discussion section of the May 24 revision, since
moved to the Talk page:

"Alternate approach: couldn't we just symlink commonly-used binaries
into /bin or /usr/bin?

Yes, but this requires editing and rebuilding dozens of RPMs and
constant argument about which binaries deserve special treatment. Lots
more work for very little actual improvement."

No one in this thread is making any point that hasn't already been
considered.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/da10fed0/attachment.sig>

From jwboyer at gmail.com  Wed Oct  8 21:08:34 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 8 Oct 2008 17:08:34 -0400
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223499372.23034.47.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
Message-ID: <20081008210834.GC10613@yoda.jdub.homelinux.org>

On Wed, Oct 08, 2008 at 10:56:12PM +0200, Christoph Wickert wrote:
>Am Mittwoch, den 08.10.2008, 16:47 -0400 schrieb Josh Boyer:
>> On Wed, Oct 08, 2008 at 08:09:12PM +0200, Christoph Wickert wrote:
>>
>> >So the decision was made under the assumption that _none_ of the LXDE
>> >packages has ever passed a review. How can somebody who has read the
>> >feature page claim that? Why did nobody answer him back?
>> 
>> The decision was made under the _fact_ that the Feature lacked packages
>> that had not passed review.  If they aren't all there, it can't be tested
>> by Beta.  It's really that simple.
>
>As I wrote in a previous mail: I don't challenge that, but for me it not
>"really that simple" but "really that disappointing". I've put a lot of
>work into the feature and when I see that people hardly seem to read the
>feature page or don't care about informing the feature owner is just
>disappointing.

I'm in FESCo.  I read the Feature page.  It was/is quite detailed.  It
still, unfortunately, doesn't meet the criteria of being a Feature.

Now, that doesn't mean your work is wasted.  It doesn't mean that,
assuming you get the missing packages into Fedora in time, LXDE won't
be installable.  It _will_ be.  All you are missing is the publicity
aspect of a Feature at that point.

Is that disappointing?  Yeah, perhaps.  But if you care enough (and
you seem to), then self-promoting LXDE is always a valid option.

josh



From jwboyer at gmail.com  Wed Oct  8 21:15:25 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 8 Oct 2008 17:15:25 -0400
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <20081008204502.GB3770@amd.home.annexia.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007190654.GE11246@amd.home.annexia.org>
	<48ED0E36.9030701@gmail.com>
	<20081008201328.GA3770@amd.home.annexia.org>
	<48ED1674.6090201@gmail.com>
	<20081008204502.GB3770@amd.home.annexia.org>
Message-ID: <20081008211525.GD10613@yoda.jdub.homelinux.org>

On Wed, Oct 08, 2008 at 09:45:02PM +0100, Richard W.M. Jones wrote:
>On Wed, Oct 08, 2008 at 01:22:12PM -0700, Toshio Kuratomi wrote:
>> Looking at things the other way, a lot of the things that you claim are
>> specific for MinGW whereas FESCo is designing something that applies to
>> cross-compilation in general.
>
>This just backs up what I said.
>
>If you'd spent time porting a package to MinGW you'd see that
>cross-compilation is a minor and rather insignificant part of the
>whole process.  You just do './configure --host=i686-pc-mingw32' and
>that does the whole cross-compilation thing.  The complicated stuff is
>when you get 20 pages of compiler errors because the program assumes
>it can make POSIX calls on a system which only has a Win32 API (no
>libc for you).
>
>So this whole business of MinGW being "applicable to cross-compilation
>in general" seems (from my point of view) to be detached from reality.

That is your point of view.  And frankly, as one of the FESCo members
that has repeatedly complimented and stood up for MinGW, your point of
view is starting to piss me off.

FESCo sees value in MinGW.  It also sees it as a natural starting
point for a mechanism to promote other cross compilers and library
sets.  The fact that you disagree because that doesn't immediately
help MinGW is a pretty myopic point of view. 

>If you want to do a package or two and then come back from a position
>of knowledge on this subject, I'd appreciate it, because FESCo and the
>other committees _ought_ to be approaching these decisions from a
>position of technical excellence.

If you want to be on FESCo for a term or two and come back from a
position of knowledge on _that_ subject, I'd appreciate it.  Because
honestly, your "what about me" attitude on the subject is just
petty and arrogant.

josh



From a.badger at gmail.com  Wed Oct  8 21:21:21 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 14:21:21 -0700
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <20081008204502.GB3770@amd.home.annexia.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>	<20081007190654.GE11246@amd.home.annexia.org>	<48ED0E36.9030701@gmail.com>	<20081008201328.GA3770@amd.home.annexia.org>	<48ED1674.6090201@gmail.com>
	<20081008204502.GB3770@amd.home.annexia.org>
Message-ID: <48ED2451.2050004@gmail.com>

Richard W.M. Jones wrote:
> On Wed, Oct 08, 2008 at 01:22:12PM -0700, Toshio Kuratomi wrote:
>> Looking at things the other way, a lot of the things that you claim are
>> specific for MinGW whereas FESCo is designing something that applies to
>> cross-compilation in general.
> 
> This just backs up what I said.
> 
> If you'd spent time porting a package to MinGW you'd see that
> cross-compilation is a minor and rather insignificant part of the
> whole process.  You just do './configure --host=i686-pc-mingw32' and
> that does the whole cross-compilation thing.  The complicated stuff is
> when you get 20 pages of compiler errors because the program assumes
> it can make POSIX calls on a system which only has a Win32 API (no
> libc for you).
> 
> So this whole business of MinGW being "applicable to cross-compilation
> in general" seems (from my point of view) to be detached from reality.
> 
> If you want to do a package or two and then come back from a position
> of knowledge on this subject, I'd appreciate it, because FESCo and the
> other committees _ought_ to be approaching these decisions from a
> position of technical excellence.
> 
*sigh*

Does the download repository separation make a difference to built
packages or building packages?

Can we build the noarch packages proposed for the separate repository in
Fedora without a cross compiler?

The committee to deal with your concerns about the building process is
the Fedora Packaging Committee.  The FPC has already passed the
Guidelines that you proposed.  Note that we did so without much prior
knowledge of MingW... but we did so by asking questions and listening to
your domain specific knowledge of *building packages* with MinGW.

FESCo is looking into *distributing* the packages that you've built
using those Guidelines along with the rest of Fedora.  This is an
entirely different piece of the puzzle than building packages.  Please
criticise FESCo more when you have experience distributing a release or
two of a Linux distribution to thousands of machines through a network
of mirrors with updates that surpass the size of the original release.
Until then, FESCo's decision to ask for domain specific knowledge of how
this should be done from rel-eng and infrastructure seems entirely
appropriate.  If rel-eng and infrastructure tell FESCo that distributing
this via a separate repo is too much work then FESCo, rel-eng, and
infrastructure will have to hash out a different plan for putting
cross-compiled libraries in the distro.

-Toshio

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

From christoph.wickert at googlemail.com  Wed Oct  8 21:33:43 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 08 Oct 2008 23:33:43 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <20081008132436.74d0a075@ohm.scrye.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008132436.74d0a075@ohm.scrye.com>
Message-ID: <1223501623.23034.79.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 13:24 -0600 schrieb Kevin Fenzi:
> On Wed, 08 Oct 2008 20:09:12 +0200
> christoph.wickert at googlemail.com (Christoph Wickert) wrote:
> 
> > Am Mittwoch, den 08.10.2008, 12:38 -0400 schrieb Bill Nottingham:
> > > Kevin Kofler (kevin.kofler at chello.at) said: 
> > > > Bill Nottingham <notting <at> redhat.com> writes:
> > > > > There are descriptions which are translated as well....
> > > > 
> > > > Well, leave it blank, leave it in English (untranslated), put
> > > > just a URL for the upstream web page as the description
> > > 
> > > ... or, actually follow the string freeze, and the string freeze
> > > break policy.
> > 
> > The first constructive statement I hear from a FeSCo member. In fact
> > you are the _only_ FeSCo member who responded to my mail at all.
> 
> Sorry, I can't speak for the rest of the FESCo members, but I have been
> really busy with my regular job and also I have been mostly in
> agreement with the posts by Bill. To expect everyone to respond to a
> post on a busy list in under 24 hours can be a bit much.

Sorry for waiting only 23:28 hours before I expected a response ;) I
have seen these people (at least some of them) posting mails on this
list in the last 24 hours, so I assume they have read my mail too.

> > >   * Package Reviews  (were not fully done)
> > 
> > But that's not my fault I guess.
> 
> No it's not. I feel partially to blame, as I looked at those reviews
> and they looked to be in progress, but it looks like no one is formally
> reviewing them after all. ;( 

This is Patrice's way of reviewing packages. He only assings the bug to
himself when he really starts the formal review. Otherwise he leaves the
package unassigned to not prevent somebody else from reviewing it.

> > >   * Comps: new group with id "lxde-desktop", name "LXDE"...
> > > 	o mandatory: lxde-common, lxpanel, openbox, pcmanfm
> > > 	o default: gpicview, leafpad, lxappearance, lxtask,
> > > lxterminal, obconf, xarchiver ... (wasn't done)
> > 
> > Wasn't done because
> >       * of the missing reviews
> >       * I expected someone from FeSCo to give me a go.
> 
> A go for what? Adding the comps group? 

Yes, as I wrote in reply to Toshios mail: We had endless discussions
about new groups in comps here, and IMO these were right. If every
maintainer would add new groups without permission of FeSCo and without
knowing the consequences (string freeze in my case), comps will be hosed
pretty soon.

> ...snipp...
> 
> > Obviously the only one who was at least a little informed is nirik,
> > he's also the only one who apologized for "the lack of communication"
> > in a conversation we had yesterday. 
> 
> Yes, and I am sad there was a lack of communication, and I hope things
> can be done better next time around. 

Just to clarify: I don't want to blame a single person and even if I
wanted to: You are the last one to blame, because you cared about the
feature most. Most likely because you were using LXDE on your mobile ;)

> > But nirik is wrong too: Those LXDE
> > packages that are already in Fedora are not there because they have
> > been forever but because they were part of my feature (lxtask,
> > lxterminal, lxlauncher, ...).
> 
> I'm not sure I understand this sentence... ? 
> Yes, there are other lxde packages that have passed review and are
> in, I understand that. 

In the meeting you said that "some [packages] are, but thats because
they were already in... like openbox is the windowmanager." This is not
correct. Of course openbox was already in Fedora, but lxterminal,
lxappearance, lxterminal and lxtask were not. They have entered Fedora
as part of my feature.

> > So the decision was made under the assumption that _none_ of the LXDE
> > packages has ever passed a review. How can somebody who has read the
> > feature page claim that? Why did nobody answer him back?
> 
> No, I never claimed that. I claimed that because 2 of them are missing
> then the feature must wait. Is that incorrect? 

No, that's correct, but from what wwoods and you said it _sounded_ like
none of the lx*-packages made it in. And I'm afraid that some FeSCo
members who did not read the feature page carefully enough believed that
too.
> 
> > Summing it all up: My outrage is because
> >       * nobody contacted my to ask me for status or to tell me the
> >         feature was dropped. Nobody contacted me at all.
> 
> I am very sorry for that. ;( 
> 
> >       * the wiki says [1]: "The feature owner is responsible for
> >         watching any owned pages for state changes, using the wiki
> > watch feature." That's what I did, nevertheless I did not get
> >         notified.
> 
> That needs to be changed/fixed. The wiki page watch is not sufficent
> here I don't think. 

If it's working reliably IMO it should be sufficient. This is something
we should take care of, but it's more problem for infrastructure then
for fedora-devel-lst I think.

> >       * the decision was made by people who obviously did not read the
> >         feature page and have no interest in the feature. If somebody
> >         has not read the page he should not speak up on that topic or
> >         decide about it, and if he has further question he should ask.
> 
> I don't understand this. I like the feature, I was using it on my phone
> for a while. it's a nice DE. I would love to see it in Fedora. 
> 
> It was not testable by Beta, so it shouldn't be advertised as a feature
> this time. I'm sorry that that is due to communication problems. ;( 
> I find it very unfortunate.  
> 
> It's after string freeze, but you can get an exception for that: 
> https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
> 
> So, you can get things in place, and we can advertise this as a Feature
> for F11. 
> 
> >       * no FeSCo member except from Bill reacted to my previous mails.
> 
> Sorry. 

Kevin, no need for further excuses, it's ok, although I'd really like to
hear some more statements from people involved in that decision.

Nevertheless we should now focus on getting the packages into the repos
ASAP.

Regards,
Christoph



From nicolas.mailhot at laposte.net  Wed Oct  8 21:47:51 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 08 Oct 2008 23:47:51 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223498986.23034.41.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<48ED07FE.4080604@gmail.com>
	<1223498986.23034.41.camel@wicktop.localdomain>
Message-ID: <1223502471.4621.3.camel@arekh.okg>

Le mercredi 08 octobre 2008 ? 22:49 +0200, Christoph Wickert a ?crit :

> Wait: I'm expected to introduce a new group in comps without previous
> discussion and without explicit permission from FeSCo? 

Comps is both central and under-regulated. You'll have a hard time
finding who is supposed to approve comps policy, and the files
themselves are wide open.

However out of respect both for the people working on comps
translatations, and for the people working of comps consummers, I
personnaly wouldn't make any deep restructuring such as new group
creation after test1 (to give people time to react)

-- 
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/20081008/81580347/attachment.sig>

From christoph.wickert at googlemail.com  Wed Oct  8 21:47:10 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 08 Oct 2008 23:47:10 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <20081008210834.GC10613@yoda.jdub.homelinux.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<20081008210834.GC10613@yoda.jdub.homelinux.org>
Message-ID: <1223502430.23034.90.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 17:08 -0400 schrieb Josh Boyer:
> On Wed, Oct 08, 2008 at 10:56:12PM +0200, Christoph Wickert wrote:
> >Am Mittwoch, den 08.10.2008, 16:47 -0400 schrieb Josh Boyer:
> >> The decision was made under the _fact_ that the Feature lacked packages
> >> that had not passed review.  If they aren't all there, it can't be tested
> >> by Beta.  It's really that simple.
> >
> >As I wrote in a previous mail: I don't challenge that, but for me it not
> >"really that simple" but "really that disappointing". I've put a lot of
> >work into the feature and when I see that people hardly seem to read the
> >feature page or don't care about informing the feature owner is just
> >disappointing.
> 
> I'm in FESCo.  I read the Feature page.  

Just curious: Why didn't you speak up then when somebody made an false
assumption?

> It was/is quite detailed.  It
> still, unfortunately, doesn't meet the criteria of being a Feature.

You mean in general or for Fedora 10?

> Now, that doesn't mean your work is wasted.  It doesn't mean that,
> assuming you get the missing packages into Fedora in time, LXDE won't
> be installable.  It _will_ be.  All you are missing is the publicity
> aspect of a Feature at that point.

I don't care about publicity, I don't want people to pat me on my back
or to hug me. I want these packages in Fedora, because I want to satisfy
the LXDE users. That's all.
> 
> Is that disappointing?  Yeah, perhaps.  But if you care enough (and
> you seem to), then self-promoting LXDE is always a valid option.

OK then, let's focus our efforts on the packages then (and forget about
my first question, although I'd really like to know from somebody who
attended the meeting)
> 
> josh

Regards,
Christoph



From bkoz at redhat.com  Wed Oct  8 22:08:45 2008
From: bkoz at redhat.com (Benjamin Kosnik)
Date: Wed, 8 Oct 2008 15:08:45 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <48ECFB21.7060301@gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48ECFB21.7060301@gmail.com>
Message-ID: <20081008150845.433de475@balbo.artheist.org>


FWIW, gcc-4.4.x will use libtool 2.2.6. It would be nice to have Fedora
bump a bit before.

-benjamin



From jwboyer at gmail.com  Wed Oct  8 22:12:05 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 8 Oct 2008 18:12:05 -0400
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223502430.23034.90.camel@wicktop.localdomain>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<20081008210834.GC10613@yoda.jdub.homelinux.org>
	<1223502430.23034.90.camel@wicktop.localdomain>
Message-ID: <20081008221205.GA3288@vader.jdub.homelinux.org>

On Wed, Oct 08, 2008 at 11:47:10PM +0200, Christoph Wickert wrote:
>Am Mittwoch, den 08.10.2008, 17:08 -0400 schrieb Josh Boyer:
>> On Wed, Oct 08, 2008 at 10:56:12PM +0200, Christoph Wickert wrote:
>> >Am Mittwoch, den 08.10.2008, 16:47 -0400 schrieb Josh Boyer:
>> >> The decision was made under the _fact_ that the Feature lacked packages
>> >> that had not passed review.  If they aren't all there, it can't be tested
>> >> by Beta.  It's really that simple.
>> >
>> >As I wrote in a previous mail: I don't challenge that, but for me it not
>> >"really that simple" but "really that disappointing". I've put a lot of
>> >work into the feature and when I see that people hardly seem to read the
>> >feature page or don't care about informing the feature owner is just
>> >disappointing.
>> 
>> I'm in FESCo.  I read the Feature page.  
>
>Just curious: Why didn't you speak up then when somebody made an false
>assumption?

Because nobody in FESCo made that statement.  Kevin had already
said "for lxde, sadly 2 packages are still in review...".  The
rest of the discussion was pretty moot after that.

>
>> It was/is quite detailed.  It
>> still, unfortunately, doesn't meet the criteria of being a Feature.
>
>You mean in general or for Fedora 10?

Oh, just for F10.

>> Now, that doesn't mean your work is wasted.  It doesn't mean that,
>> assuming you get the missing packages into Fedora in time, LXDE won't
>> be installable.  It _will_ be.  All you are missing is the publicity
>> aspect of a Feature at that point.
>
>I don't care about publicity, I don't want people to pat me on my back
>or to hug me. I want these packages in Fedora, because I want to satisfy
>the LXDE users. That's all.

Cool.  Go forth and conquer!

josh



From mcepl at redhat.com  Wed Oct  8 22:26:25 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 09 Oct 2008 00:26:25 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info> <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
Message-ID: <hlovr5xhlg.ln2@ppp1053.in.ipex.cz>

On 2008-10-08, 19:31 GMT, Kevin Fenzi wrote:
> Did this email come from the past? Do we really want to talk 
> about upstart again?

Did you read my message? That was just another example of 
decision making which was kind of weird, IMHO.

> I'm sorry you're offended. We can't please everyone all the 
> time with every decision. If you don't like the decisions, feel 
> free to run for FESCo and/or vote/not vote for people who you 
> disagree with.

Actually, I really cannot care less about whether sysvinit is 
better than Upstart (or other way around) -- I am a desktop guy 
and whatever gets me to gdm is good enough for me.

I am interested only in the procedure -- after what seemed like 
a rare example of flamewar which led to some conclusion, FESCO 
seemed to decide just opposite.

Whatever, back to deduplicating ATI crashes ;-).

Mat?j



From kevin.kofler at chello.at  Wed Oct  8 22:31:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 8 Oct 2008 22:31:46 +0000 (UTC)
Subject: tab completion less useful now, due to sbin in path
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
Message-ID: <loom.20081008T222346-18@post.gmane.org>

Matthew Miller <mattdm <at> mattdm.org> writes:
> Tell the user "sudo ifconfig". It's better than having them "su -" and *does
> the right thing the right way*. (Although arguably ifconfig is one of the
> commands that could be moved to /bin -- it's one of the few tricky cases so
> it's a bad example.)

The problem is that sudo doesn't work out of the box, it needs manual 
configuration.

If someone taught sudo to prompt for the root password if the user is not in 
sudoers, maybe even using consolehelper, so the password gets cached, your 
suggestion would become a serious one. But in the current state, it's just a 
PITA to teach a newbie (and the fact that there is a warning at the top 
of /etc/sudoers not to edit it with anything other than visudo and vi being a 
major usability disaster doesn't help - of course you can override EDITOR for 
visudo or even ignore the huge warning and just use kwrite as root to edit it, 
but the mere existence of that warning, with no instructions on how to use an 
editor other than vi, is still very newbie-unfriendly), so newbie-friendly 
instructions use su instead. Using sudo also reduces security (as only the user 
password is needed to get root access, not the root password).

The problem is that sudo tries to be a helpful tool, but fails horribly at it.

        Kevin Kofler



From Matt_Domsch at Dell.com  Wed Oct  8 22:34:40 2008
From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com)
Date: Wed, 8 Oct 2008 17:34:40 -0500
Subject: libcurl + (NSS or openssl)
Message-ID: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>

I understand the push behind getting as many packages to build against
nss as possible.  However, nss is not on feature parity with openssl at
this time.

I've run into two problems where this has bitten me.

First, libcurl being built against nss.  Nss does not provide some
functions which are necessary for NTLM authentication to succeed.  This
has defeatured the 'curl' application, rendering it useless in
environments where users are behind an NTLM-authenticating proxy.  This
bites me personally every day.  Yes, NTLM is based on MD4 which is
insecure. Nevertheless, choice of corporate proxy servers is often
beyond the reach of even the most senior Linux developers (aside from
changing jobs...)

Second, libcurl being built against nss.  OpenWSMAN has an eventing
capability, but this uses libcurl, which in turn would use a feature of
openssl. But as libcurl is not built against openssl, the eventing
capability at this point must be disabled in OpenWSMAN.  This capability
will be important to the sblim-* systems management software stack which
implements DMTF open standards.  I need to investigate further what the
source of the problem here is.

Arguably, one should discover the missing functionalty from nss, and
re-implement it so as to enable these functions.  However, as these
functions do work if linked against openssl, I would prefer to see the
expedient approach of linking libcurl against openssl again, and only
release with it linked against nss once it is at feature parity for the
functions used by software within Fedora.

Can I ask that libcurl be rebuilt against openssl instead of nss for the
time being?

Thanks,
Matt

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




From bpepple at fedoraproject.org  Wed Oct  8 22:41:18 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 08 Oct 2008 18:41:18 -0400
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223498986.23034.41.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<48ED07FE.4080604@gmail.com>
	<1223498986.23034.41.camel@wicktop.localdomain>
Message-ID: <1223505678.15503.2.camel@kennedy>

On Wed, 2008-10-08 at 22:49 +0200, Christoph Wickert wrote:
> 
> Agreed, but my point is: They don't need to know all details, but they
> need to read the feature page. And if the page says that 9 out of 11
> packages are done I expect FeSCo members to know that, not more, not
> less, but I expect somebody to not incorrectly state that none of the
> packages is available.

Umm, no FESCo member did state that.  A member of the QA did, and a
FESCo member (nirik) corrected him.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/28157bf8/attachment.sig>

From jkeating at redhat.com  Wed Oct  8 22:41:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 08 Oct 2008 15:41:41 -0700
Subject: Taking fedora-devel into consideration [Was: Re: tab
 completion less useful now, due to sbin in path]
In-Reply-To: <hlovr5xhlg.ln2@ppp1053.in.ipex.cz>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info> <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
	<hlovr5xhlg.ln2@ppp1053.in.ipex.cz>
Message-ID: <1223505701.4410.89.camel@luminos.localdomain>

On Thu, 2008-10-09 at 00:26 +0200, Matej Cepl wrote:
> 
> I am interested only in the procedure -- after what seemed like 
> a rare example of flamewar which led to some conclusion, FESCO 
> seemed to decide just opposite.

Conclusions are rarely reached on mailing list arguments.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/4684d060/attachment.sig>

From loupgaroublond at gmail.com  Wed Oct  8 22:43:57 2008
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Wed, 8 Oct 2008 18:43:57 -0400
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <20081007190654.GE11246@amd.home.annexia.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007190654.GE11246@amd.home.annexia.org>
Message-ID: <7f692fec0810081543u25d14790se9ed661653f32e6c@mail.gmail.com>

2008/10/7 Richard W.M. Jones <rjones at redhat.com>:
> The Haskell feature was dropped at the same meeting just because the
> guy maintaining it wasn't there.  Probably he didn't know the meeting
> was happening because he didn't read some announcement in one of the
> multitude of mailing lists that we need to keep up with.  Or being in
> Europe, he might have been busy at 7/8pm in the evening.

Actually, i'm in the US now.  I was in class at the time.

To be fair though, i'm not sure Haskell was ready either.  We don't
have many packages out of the review queue yet, and while this is
partially my fault, having something a little more worthy of Feature
Complete for Fedora 11 seems like a better idea.

Still... notification about a meeting would have been nice, if only so
I could have made this evaluation before the meeting occured, and it
could have been discussed better informed.

-Yaakov



From a.badger at gmail.com  Wed Oct  8 22:54:46 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 15:54:46 -0700
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
In-Reply-To: <hlovr5xhlg.ln2@ppp1053.in.ipex.cz>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>	<48EB03C6.9080300@leemhuis.info>
	<mpfur5xrg8.ln2@ppp1053.in.ipex.cz>	<20081008133115.0c164ef8@ohm.scrye.com>
	<hlovr5xhlg.ln2@ppp1053.in.ipex.cz>
Message-ID: <48ED3A36.2060605@gmail.com>

Matej Cepl wrote:

> Actually, I really cannot care less about whether sysvinit is 
> better than Upstart (or other way around) -- I am a desktop guy 
> and whatever gets me to gdm is good enough for me.
> 
I remember there was a flamewar but I don't remember all that was said
or where it concluded.  I do recall that Casey Dahlin decided we needed
to write our own init replacement somewhere near the end of it.  Then we
had a FUDCon and Casey pitched a session on defining the feature set we
wanted in a rewritten init.  At that session, people decided that
upstart either had all the features that had been mentioned or was
actively working on adding them.  After that, it was a matter of the
people who cared about a new init system were doing the work to get
upstart merged so FESCo approved that work as a feature.

-Toshio

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

From poelstra at redhat.com  Wed Oct  8 23:14:20 2008
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 08 Oct 2008 16:14:20 -0700
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <7f692fec0810081543u25d14790se9ed661653f32e6c@mail.gmail.com>
References: <1223404671.24360.51.camel@wicktop.localdomain>	<20081007190654.GE11246@amd.home.annexia.org>
	<7f692fec0810081543u25d14790se9ed661653f32e6c@mail.gmail.com>
Message-ID: <48ED3ECC.2030204@redhat.com>

Yaakov Nemoy said the following on 10/08/2008 03:43 PM Pacific Time:
> 2008/10/7 Richard W.M. Jones <rjones at redhat.com>:
>> The Haskell feature was dropped at the same meeting just because the
>> guy maintaining it wasn't there.  Probably he didn't know the meeting

@richard: not true
https://fedoraproject.org/wiki/Features/Policy/Dropping


> Actually, i'm in the US now.  I was in class at the time.
> 
> To be fair though, i'm not sure Haskell was ready either.  We don't
> have many packages out of the review queue yet, and while this is
> partially my fault, having something a little more worthy of Feature
> Complete for Fedora 11 seems like a better idea.
> 
> Still... notification about a meeting would have been nice, if only so
> I could have made this evaluation before the meeting occured, and it
> could have been discussed better informed.

https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01471.html
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02077.html




From ascii79 at gmail.com  Wed Oct  8 23:13:38 2008
From: ascii79 at gmail.com (Sachin)
Date: Wed, 8 Oct 2008 18:13:38 -0500
Subject: https://bugzilla.redhat.com/show_bug.cgi?id=465588
Message-ID: <a3c040240810081613q2b129f1iea388733e6173a49@mail.gmail.com>

Hi

Can some one please take look on this bug
https://bugzilla.redhat.com/show_bug.cgi?id=465588

Regards,
Sachin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/2a9baa9f/attachment.htm>

From selinux at gmail.com  Wed Oct  8 23:26:06 2008
From: selinux at gmail.com (Tom London)
Date: Wed, 8 Oct 2008 16:26:06 -0700
Subject: https://bugzilla.redhat.com/show_bug.cgi?id=465588
In-Reply-To: <a3c040240810081613q2b129f1iea388733e6173a49@mail.gmail.com>
References: <a3c040240810081613q2b129f1iea388733e6173a49@mail.gmail.com>
Message-ID: <4c4ba1530810081626ve6361e1s9a4e420d05ac14bc@mail.gmail.com>

2008/10/8 Sachin <ascii79 at gmail.com>:
> Hi
>
> Can some one please take look on this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=465588
>
> Regards,
> Sachin.
>
Same issue BZ'ed here: https://bugzilla.redhat.com/show_bug.cgi?id=465336  ????

-- 
Tom London



From ascii79 at gmail.com  Wed Oct  8 23:36:04 2008
From: ascii79 at gmail.com (Sachin)
Date: Wed, 8 Oct 2008 18:36:04 -0500
Subject: https://bugzilla.redhat.com/show_bug.cgi?id=465588
In-Reply-To: <4c4ba1530810081626ve6361e1s9a4e420d05ac14bc@mail.gmail.com>
References: <a3c040240810081613q2b129f1iea388733e6173a49@mail.gmail.com>
	<4c4ba1530810081626ve6361e1s9a4e420d05ac14bc@mail.gmail.com>
Message-ID: <a3c040240810081636p11b4a27bi6d96ee321789fcca@mail.gmail.com>

This is fixed in  https://bugs.freedesktop.org/show_bug.cgi?id=17233


On Wed, Oct 8, 2008 at 6:26 PM, Tom London <selinux at gmail.com> wrote:

> 2008/10/8 Sachin <ascii79 at gmail.com>:
> > Hi
> >
> > Can some one please take look on this bug
> > https://bugzilla.redhat.com/show_bug.cgi?id=465588
> >
> > Regards,
> > Sachin.
> >
> Same issue BZ'ed here: https://bugzilla.redhat.com/show_bug.cgi?id=465336 ????
>
> --
> Tom London
>
> --
> 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/20081008/1fd6aac5/attachment.htm>

From bpepple at fedoraproject.org  Wed Oct  8 23:45:56 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 08 Oct 2008 19:45:56 -0400
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223404671.24360.51.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
Message-ID: <1223509556.19113.6.camel@kennedy>

On Tue, 2008-10-07 at 20:37 +0200, Christoph Wickert wrote:
> But this won't
> help because no announcement has been made on the list and the latest
> meeting minutes were published on September 10th. (BTW: Meeting minutes
> seem to be published only sporadic recently.)

Wrong.  Only 1 weeks summary was missing (and that was because I was
without power for a week, and haven't had time to go back and write that
one up).

https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00281.html
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01684.html
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02258.html
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00062.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/c4c5d955/attachment.sig>

From airlied at redhat.com  Wed Oct  8 23:55:40 2008
From: airlied at redhat.com (Dave Airlie)
Date: Thu, 09 Oct 2008 09:55:40 +1000
Subject: https://bugzilla.redhat.com/show_bug.cgi?id=465588
In-Reply-To: <a3c040240810081613q2b129f1iea388733e6173a49@mail.gmail.com>
References: <a3c040240810081613q2b129f1iea388733e6173a49@mail.gmail.com>
Message-ID: <1223510140.3341.9.camel@clockmaker.usersys.redhat.com>

On Wed, 2008-10-08 at 18:13 -0500, Sachin wrote:
> Hi
> 
> Can some one please take look on this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=465588
> 

Why is posting here going to help?

If you feel a bug is more urgent please ping on the bug itself.

If everyone starts posting bugs here the list will be become even more useless.

This bug will be fixed by the next mesa upstream import, when we do that isn't going
to be decided by mailing this list.

Dave.




From a.badger at gmail.com  Wed Oct  8 23:58:25 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 08 Oct 2008 16:58:25 -0700
Subject: [Correction] Summary of the 2008-09-23 Packaging Committee Meeting
Message-ID: <48ED4921.9070600@gmail.com>

> The Packaging Committee board approved the following drafts :
[...]
> * Package guideline for Javascript
> https://fedoraproject.org/wiki/PackagingDrafts/JavaScript


This was actually discussed and we came up with a few changes to make.
So this policy isn't in effect yet.

-Toshio

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

From mattdm at mattdm.org  Thu Oct  9 00:04:10 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 8 Oct 2008 20:04:10 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <loom.20081008T222346-18@post.gmane.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<loom.20081008T222346-18@post.gmane.org>
Message-ID: <20081009000410.GA25476@jadzia.bu.edu>

On Wed, Oct 08, 2008 at 10:31:46PM +0000, Kevin Kofler wrote:
> The problem is that sudo doesn't work out of the box, it needs manual 
> configuration.


And fixing that is in progress too.


I'm okay with the current solution as a temporary patch if it makes people
feel better for now. It's annoying but I can live with it as a compromise --
but not as an excuse to avoid solving the problem.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From bnocera at redhat.com  Thu Oct  9 00:37:21 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 09 Oct 2008 01:37:21 +0100
Subject: Dead or alive package [Fwd: [Bug 465111] New: FTBFS
	bluez-utils-3.36-2.fc10]
Message-ID: <1223512641.24710.17.camel@cookie.hadess.net>

This package is marked as dead.package in CVS. Did I miss something, or
where shall I file the bug?
-------------- next part --------------
An embedded message was scrubbed...
From: bugzilla at redhat.com
Subject: [Bug 465111] New: FTBFS bluez-utils-3.36-2.fc10
Date: Wed, 1 Oct 2008 12:43:43 -0400
Size: 5052
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/92b1a052/attachment.eml>

From jkeating at redhat.com  Thu Oct  9 00:41:02 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 08 Oct 2008 17:41:02 -0700
Subject: Dead or alive package [Fwd: [Bug 465111] New: FTBFS
 bluez-utils-3.36-2.fc10]
In-Reply-To: <1223512641.24710.17.camel@cookie.hadess.net>
References: <1223512641.24710.17.camel@cookie.hadess.net>
Message-ID: <1223512862.4410.94.camel@luminos.localdomain>

On Thu, 2008-10-09 at 01:37 +0100, Bastien Nocera wrote:
> This package is marked as dead.package in CVS. Did I miss something, or
> where shall I file the bug?

It didn't get blocked until Oct 1st, which was after the rebuild attempt
happened.  Just close the FTBFS bug as WONTFIX with the explanation that
it has been retired.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081008/fd8a73c3/attachment.sig>

From jarod at redhat.com  Thu Oct  9 00:47:34 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Wed, 8 Oct 2008 20:47:34 -0400
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223501623.23034.79.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081008132436.74d0a075@ohm.scrye.com>
	<1223501623.23034.79.camel@wicktop.localdomain>
Message-ID: <200810082047.34646.jarod@redhat.com>

On Wednesday 08 October 2008 17:33:43 Christoph Wickert wrote:
> > > ? ? ? * no FeSCo member except from Bill reacted to my previous mails.
> >
> > Sorry.
>
> Kevin, no need for further excuses, it's ok, although I'd really like to
> hear some more statements from people involved in that decision.

As Josh already said, its as simple as the Feature not being testable at 
freeze time, due to packages required by the Feature not yet being approved. 
In my mind, nothing more, nothing less.

Communication could certainly stand to be improved, which was one of the focal 
topics of today's FESCo meeting, but the schedule and feature process pages 
have been out there in the wiki for some time, and clearly state that if a 
Feature isn't testable at freeze time, it will be dropped. However, its only 
"dropped" in that its not a Feature touted for the impending release, no 
reason it can't still progress forward and be touted in the next release 
(and/or made available in the -updates repo for the release it missed, in the 
case of new packages like this).

> Nevertheless we should now focus on getting the packages into the repos
> ASAP.

Agreed. You've got a healthy head start on an F11 Feature here. :)

(Which I'll gladly try out on my netbook, though I'm actually pretty happy 
with the tweaked gnome setup I have on it now...)

-- 
Jarod Wilson
jarod at redhat.com




From jarod at redhat.com  Thu Oct  9 00:51:50 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Wed, 8 Oct 2008 20:51:50 -0400
Subject: Dead or alive package [Fwd: [Bug 465111] New: FTBFS
	bluez-utils-3.36-2.fc10]
In-Reply-To: <1223512862.4410.94.camel@luminos.localdomain>
References: <1223512641.24710.17.camel@cookie.hadess.net>
	<1223512862.4410.94.camel@luminos.localdomain>
Message-ID: <200810082051.51087.jarod@redhat.com>

On Wednesday 08 October 2008 20:41:02 Jesse Keating wrote:
> On Thu, 2008-10-09 at 01:37 +0100, Bastien Nocera wrote:
> > This package is marked as dead.package in CVS. Did I miss something, or
> > where shall I file the bug?
>
> It didn't get blocked until Oct 1st, which was after the rebuild attempt
> happened.  Just close the FTBFS bug as WONTFIX with the explanation that
> it has been retired.

I thought it was marked dead.package, because bluez-utils was obsoleted by 
bluez or something like that, not because of the FTBFS bug.

-- 
Jarod Wilson
jarod at redhat.com



From wtogami at redhat.com  Thu Oct  9 02:10:43 2008
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 08 Oct 2008 22:10:43 -0400
Subject: Possible to default to KDE?
Message-ID: <48ED6823.5000901@redhat.com>

In Fedora 9 due to (some problems) it wasn't possible to set the system 
default desktop to KDE if you still had GNOME installed.

Yes, I know you could do it at the per-user level with ~/.dmrc, but that 
requires it to already be set once for a new-user.

Yes, I know you can easily do this if you switch away from gdm to kdm.

Does Fedora 10 have a way to default the entire system to any other 
desktop (including new users) without uninstalling GNOME and without 
switching away from gdm?

Warren Togami
wtogami at redhat.com



From bruno at wolff.to  Thu Oct  9 02:20:03 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 8 Oct 2008 21:20:03 -0500
Subject: Today's rawhide gcc appears to have problems
Message-ID: <20081009022003.GA25810@wolff.to>

I am seeing some internal compiler errors when building svn versions of
Wesnoth this evening using gcc-4.3.2-5.i386. I wasn't seeing that last
night.
I have added the output recommended by gcc to bug 466198.
I don't know how fast new compiler versions start getting used to build
other stuff, but it case its right away I wanted to put out a heads up.



From rc040203 at freenet.de  Thu Oct  9 02:54:12 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 09 Oct 2008 04:54:12 +0200
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <1223499686.26341.35.camel@localhost.localdomain>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<1223499686.26341.35.camel@localhost.localdomain>
Message-ID: <1223520853.3564.1147.camel@beck.corsepiu.local>

On Wed, 2008-10-08 at 16:01 -0500, Callum Lerwick wrote:
> On Tue, 2008-10-07 at 08:33 -0400, Matthew Miller wrote:
> > On Tue, Oct 07, 2008 at 01:25:26AM -0400, Jon Stanley wrote:
> > > The proper time to voice objections to this would have been there, 6
> > > weeks ago now.
> > 
> > Well, as I thought the discussion had been left before that meeting, fixing
> > the general problem of user-level commands in the wrong places was the
> > feature and it was going to be solved properly. The feature is called "sbin
> > sanity", and I'm 100% in support of that. The "ah, hell, just put everything
> > in the path and call that sane" change came as a surprise to me.
> 
> https://fedoraproject.org/wiki/Features/SbinSanity
> 
> And under Scope it says: "Change the default PATH to
> include /usr/local/sbin:/usr/sbin:/sbin for all users. Note that it must
> come at the end of the path for normal users, or consolehelper will
> break." According to the history, it's been there since at least May 24
> 2008, when it was imported from MoinMoin. A period of ~5 months.
> 
> If you're surprised by this, you simply aren't paying attention to the
> feature process. I've seen many emails go out on fedora-announce about
> the status of features, in which checking up on features you are
> interested in is a single click away.
> 
> Also notable, in the discussion section of the May 24 revision, since
> moved to the Talk page:
> 
> "Alternate approach: couldn't we just symlink commonly-used binaries
> into /bin or /usr/bin?
> 
> Yes, but this requires editing and rebuilding dozens of RPMs and
> constant argument about which binaries deserve special treatment. Lots
> more work for very little actual improvement."
> 
> No one in this thread is making any point that hasn't already been
> considered.
Correct, because none of these "alternatives" is discussworthy. Both are
equally broken.

Ralf






From kevin.kofler at chello.at  Thu Oct  9 03:06:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 9 Oct 2008 03:06:10 +0000 (UTC)
Subject: Possible to default to KDE?
References: <48ED6823.5000901@redhat.com>
Message-ID: <loom.20081009T030517-697@post.gmane.org>

Warren Togami <wtogami <at> redhat.com> writes:
> Does Fedora 10 have a way to default the entire system to any other 
> desktop (including new users) without uninstalling GNOME and without 
> switching away from gdm?

Uh, doesn't setting DESKTOP="KDE" in /etc/sysconfig/desktop work? If that 
indeed doesn't work with the current GDM, then IMHO that's a pretty serious bug 
in GDM.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct  9 03:12:20 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 9 Oct 2008 03:12:20 +0000 (UTC)
Subject: tab completion less useful now, due to sbin in path
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<loom.20081008T222346-18@post.gmane.org>
	<20081009000410.GA25476@jadzia.bu.edu>
Message-ID: <loom.20081009T030905-695@post.gmane.org>

Matthew Miller <mattdm <at> mattdm.org> writes:
>
> On Wed, Oct 08, 2008 at 10:31:46PM +0000, Kevin Kofler wrote:
> > The problem is that sudo doesn't work out of the box, it needs manual 
> > configuration.
> 
> And fixing that is in progress too.

By putting the first user into /etc/sudoers? That's completely and utterly 
broken. Just because Ubuntu does something doesn't mean it makes sense. ;-) 
sudo either needs to be fixed to prompt for the root password instead of 
denying access altogether if the user is not in sudoers or replaced by 
something which does (and can still be invoked with "sudo" because that's the 
command people know).

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct  9 03:17:32 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 9 Oct 2008 03:17:32 +0000 (UTC)
Subject: Dead or alive package [Fwd: [Bug 465111] New:
	FTBFS	bluez-utils-3.36-2.fc10]
References: <1223512641.24710.17.camel@cookie.hadess.net>
	<1223512862.4410.94.camel@luminos.localdomain>
	<200810082051.51087.jarod@redhat.com>
Message-ID: <loom.20081009T031655-787@post.gmane.org>

Jarod Wilson <jarod <at> redhat.com> writes:
> I thought it was marked dead.package, because bluez-utils was obsoleted by 
> bluez or something like that, not because of the FTBFS bug.

Sure, but it's kinda pointless to fix bugs in an obsolete package. ;-)

        Kevin Kofler



From pemboa at gmail.com  Thu Oct  9 03:30:59 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 8 Oct 2008 22:30:59 -0500
Subject: Possible to default to KDE?
In-Reply-To: <loom.20081009T030517-697@post.gmane.org>
References: <48ED6823.5000901@redhat.com>
	<loom.20081009T030517-697@post.gmane.org>
Message-ID: <16de708d0810082030y5b500e74xf03d5badba483ed0@mail.gmail.com>

On Wed, Oct 8, 2008 at 10:06 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Warren Togami <wtogami <at> redhat.com> writes:
>> Does Fedora 10 have a way to default the entire system to any other
>> desktop (including new users) without uninstalling GNOME and without
>> switching away from gdm?
>
> Uh, doesn't setting DESKTOP="KDE" in /etc/sysconfig/desktop work? If that
> indeed doesn't work with the current GDM, then IMHO that's a pretty serious bug
> in GDM.
>
>        Kevin Kofler
>

Switchdesk is supposed to do that. And switchdesk did  not work for me.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jonstanley at gmail.com  Thu Oct  9 03:40:24 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 8 Oct 2008 23:40:24 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <loom.20081009T030905-695@post.gmane.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<loom.20081008T222346-18@post.gmane.org>
	<20081009000410.GA25476@jadzia.bu.edu>
	<loom.20081009T030905-695@post.gmane.org>
Message-ID: <da159fda0810082040q7c639ab8oe502e4938568014d@mail.gmail.com>

On Wed, Oct 8, 2008 at 11:12 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:

> sudo either needs to be fixed to prompt for the root password instead of
> denying access altogether if the user is not in sudoers or replaced by

I've not tested this on Fedora quite yet, but I think in openSUSE they
have this by default:

Defaults: targetpw
ALL = ALL (ALL) ALL

This will cause sudo to prompt for the password of root if sudo is not
configured.  And there's a very clear comment that you shouldn't take
out the first line without also taking out the second :).   IMHO,
that's a fairly sane solution to the problem.



From kevin.kofler at chello.at  Thu Oct  9 03:42:15 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 9 Oct 2008 03:42:15 +0000 (UTC)
Subject: Possible to default to KDE?
References: <48ED6823.5000901@redhat.com>
	<loom.20081009T030517-697@post.gmane.org>
	<16de708d0810082030y5b500e74xf03d5badba483ed0@mail.gmail.com>
Message-ID: <loom.20081009T034109-769@post.gmane.org>

Arthur Pemberton <pemboa <at> gmail.com> writes:
> Switchdesk is supposed to do that. And switchdesk did  not work for me.

Switchdesk uses some per-user config file, not the 
system-wide /etc/sysconfig/desktop. Still, I'd also argue it's a bug somewhere 
(GDM?) that switchdesk no longer works.

        Kevin Kofler



From orcanbahri at yahoo.com  Thu Oct  9 03:52:22 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Wed, 8 Oct 2008 20:52:22 -0700 (PDT)
Subject: Possible to default to KDE?
In-Reply-To: <16de708d0810082030y5b500e74xf03d5badba483ed0@mail.gmail.com>
Message-ID: <696636.29027.qm@web32805.mail.mud.yahoo.com>


> 
> Switchdesk is supposed to do that. And switchdesk did  not
> work for me.
> 
> -- 


Did you use switchdesk as root? Then you probably have switched the desktop for root only, not for everyone.

-oget


      



From pemboa at gmail.com  Thu Oct  9 04:16:59 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 8 Oct 2008 23:16:59 -0500
Subject: Possible to default to KDE?
In-Reply-To: <696636.29027.qm@web32805.mail.mud.yahoo.com>
References: <16de708d0810082030y5b500e74xf03d5badba483ed0@mail.gmail.com>
	<696636.29027.qm@web32805.mail.mud.yahoo.com>
Message-ID: <16de708d0810082116u640a2b66k89f6826524258373@mail.gmail.com>

On Wed, Oct 8, 2008 at 10:52 PM, Orcan Ogetbil <orcanbahri at yahoo.com> wrote:
>
>>
>> Switchdesk is supposed to do that. And switchdesk did  not
>> work for me.
>>
>> --
>
>
> Did you use switchdesk as root? Then you probably have switched the desktop for root only, not for everyone.
>
> -oget

I used switchdesk as myself (I've used switchdesk before). Also,
another dude in #fedora had a similar problem

PS: Is there a search able log of #fedora?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From airlied at redhat.com  Thu Oct  9 04:51:57 2008
From: airlied at redhat.com (Dave Airlie)
Date: Thu, 09 Oct 2008 14:51:57 +1000
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <1223527917.3341.22.camel@clockmaker.usersys.redhat.com>

On Wed, 2008-10-01 at 18:52 +0200, Jakub Jelinek wrote:
> Hi!
> 

> MAKEDEV sources almost 500KB of config files on every invocation, and the
> inner loop is terribly inefficient.  The second patch allows it to shrink
> the files to 55KB while expressing the same info and makes the inner loop
> more efficient.  Depending on how many modprobe and MAKEDEV invocations
> are done on your box during bootup, this can or might not make meassurable
> difference.
> 

I've just pushed MAKEDEV 3.23-7 into koji should be in rawhide soon.

MAKEDEV is now hosted on git.fedorahosted.org for anyone who cares.

Thanks Jakub.

Dave.



From sundaram at fedoraproject.org  Thu Oct  9 04:58:02 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 09 Oct 2008 10:28:02 +0530
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
Message-ID: <48ED8F5A.3030403@fedoraproject.org>

Dave Airlie wrote:
> On Wed, 2008-10-01 at 18:52 +0200, Jakub Jelinek wrote:
>> Hi!
>>
> 
>> MAKEDEV sources almost 500KB of config files on every invocation, and the
>> inner loop is terribly inefficient.  The second patch allows it to shrink
>> the files to 55KB while expressing the same info and makes the inner loop
>> more efficient.  Depending on how many modprobe and MAKEDEV invocations
>> are done on your box during bootup, this can or might not make meassurable
>> difference.
>>
> 
> I've just pushed MAKEDEV 3.23-7 into koji should be in rawhide soon.
> 
> MAKEDEV is now hosted on git.fedorahosted.org for anyone who cares.
> 
> Thanks Jakub.

It is time for us to drop the exception in

http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream

Insist that we use fedorahosted.org or other project hosting websites 
whenever we are upstream for a project? It certainly makes it easier for 
others to consume our bits when they don't have to crawl through source 
rpm packages. SRPM dumps are a horrible way to manage upstream source 
code anyway.

Rahul



From peter.hutterer at who-t.net  Thu Oct  9 06:31:17 2008
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Thu, 9 Oct 2008 17:01:17 +1030
Subject: Upgrading to F10 was a bad experience
In-Reply-To: <loom.20081008T165049-236@post.gmane.org>
References: <3da3b5b40810071144m2692afd3x6d53a7b2eaadb342@mail.gmail.com>
	<200810072007.52451.jamatos@fc.up.pt>
	<loom.20081008T165049-236@post.gmane.org>
Message-ID: <20081009063117.GA5589@who-t.net>

On Wed, Oct 08, 2008 at 04:52:39PM +0000, Kevin Kofler wrote:
> Actually, don't disable layouts altogether, set model to "Evdev-managed 
> keyboard" instead. The latest kde-settings sets that up as the default, but if 
> you previously changed the model to something else, you'll have to change it by 
> hand.
> 
> If a better solution can't be found (some patch just went into 
> xorg-x11-drv-evdev which might help there)

xkeyboard-config 1.4 provides an evdev ruleset that is enforced by the driver.
The evdev model thus isn't a requirement anymore, at least not unless
something changes the rules back to "base". And that's a no-no anyway.

xorg-x11-drv-evdev-2.0.6-2 should work fine now.

Cheers,
  Peter



From Juha.Tuomala at iki.fi  Thu Oct  9 07:01:44 2008
From: Juha.Tuomala at iki.fi (Juha Tuomala)
Date: Thu, 9 Oct 2008 10:01:44 +0300
Subject: Possible to default to KDE?
In-Reply-To: <48ED6823.5000901@redhat.com>
References: <48ED6823.5000901@redhat.com>
Message-ID: <200810091001.45152.Juha.Tuomala@iki.fi>



On Thursday 09 October 2008 05:10:43 Warren Togami wrote:
> Yes, I know you can easily do this if you switch away from gdm to kdm.
> 
> Does Fedora 10 have a way to default the entire system to any other 
> desktop (including new users) without uninstalling GNOME and without 
> switching away from gdm?


How about if selecting KDE and deselecting GNOME during the 
installation and getting kdm as default window manager?

That doesn't happen and it's not what people expect.


Tuju

-- 
Varo hattup?isi? autoilijoita.



From jakub at redhat.com  Thu Oct  9 07:54:05 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Thu, 9 Oct 2008 09:54:05 +0200
Subject: Today's rawhide gcc appears to have problems
In-Reply-To: <20081009022003.GA25810@wolff.to>
References: <20081009022003.GA25810@wolff.to>
Message-ID: <20081009075405.GB13196@tyan-ft48-01.lab.bos.redhat.com>

On Wed, Oct 08, 2008 at 09:20:03PM -0500, Bruno Wolff III wrote:
> I am seeing some internal compiler errors when building svn versions of
> Wesnoth this evening using gcc-4.3.2-5.i386. I wasn't seeing that last
> night.
> I have added the output recommended by gcc to bug 466198.
> I don't know how fast new compiler versions start getting used to build
> other stuff, but it case its right away I wanted to put out a heads up.

I guess dup of #466169, which I have already a fix for from last night, will
just work on a a few minor details in the patch and build a new gcc soon.

	Jakub



From dwmw2 at infradead.org  Thu Oct  9 08:03:49 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 Oct 2008 09:03:49 +0100
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223499372.23034.47.camel@wicktop.localdomain>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
Message-ID: <1223539429.3145.365.camel@macbook.infradead.org>

On Wed, 2008-10-08 at 22:56 +0200, Christoph Wickert wrote:
> Am Mittwoch, den 08.10.2008, 16:47 -0400 schrieb Josh Boyer:
> > On Wed, Oct 08, 2008 at 08:09:12PM +0200, Christoph Wickert wrote:
> >
> > >So the decision was made under the assumption that _none_ of the LXDE
> > >packages has ever passed a review. How can somebody who has read the
> > >feature page claim that? Why did nobody answer him back?
> > 
> > The decision was made under the _fact_ that the Feature lacked packages
> > that had not passed review.  If they aren't all there, it can't be tested
> > by Beta.  It's really that simple.
> 
> As I wrote in a previous mail: I don't challenge that, but for me it not
> "really that simple" but "really that disappointing". I've put a lot of
> work into the feature and when I see that people hardly seem to read the
> feature page or don't care about informing the feature owner is just
> disappointing

It is unfortunate that you didn't get informed properly. We'll make an
effort to ensure that kind of thing doesn't happen again. I apologise
for that, and I suspect I speak for the rest of FESCo when I do so.

One thing we can do in future to make that situation better is Cc the
feature owners when the meeting agenda is sent to fedora-devel-list. I
hope we can manage that.

The other thing we should do, of course, is work out _why_ you didn't
get the notification. Do you get _any_ notifications? Was it just this
one which was missing? Is there someone from the infrastructure team who
can look into that? ISTR you said that you were the last person to edit
the page before the missing notification -- so it wasn't _expected_ that
you didn't get notified?


We appreciate the work you've put into packaging LXDE. We certainly
don't mean to suggest otherwise, and we are pleased to see the packages
in Fedora 10. (Well, I {do,don't,am}, and again I'm being presumptuous).

Let's get the final two packages reviewed -- and that's another area
where we could do with some improvement, because failing to approve
packages really _is_ verging on the 'deletionism' you spoke of. But
that's a separate discussion.

And then if everything's working and the only thing that's missing is an
entry in comps which lets you choose it in the installer, I think
there's a fairly strong case for having an exception to the string
freeze -- especially since the translation of 'LXDE' is going to be
'LDXE' in most cases ;)  We'll see...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pertusus at free.fr  Thu Oct  9 09:30:14 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 9 Oct 2008 11:30:14 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <48ED8F5A.3030403@fedoraproject.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
Message-ID: <20081009093014.GA2708@free.fr>

On Thu, Oct 09, 2008 at 10:28:02AM +0530, Rahul Sundaram wrote:
> Dave Airlie wrote:
>> On Wed, 2008-10-01 at 18:52 +0200, Jakub Jelinek wrote:
>>> Hi!
>>>
>>
>>> MAKEDEV sources almost 500KB of config files on every invocation, and the
>>> inner loop is terribly inefficient.  The second patch allows it to shrink
>>> the files to 55KB while expressing the same info and makes the inner loop
>>> more efficient.  Depending on how many modprobe and MAKEDEV invocations
>>> are done on your box during bootup, this can or might not make meassurable
>>> difference.
>>>
>>
>> I've just pushed MAKEDEV 3.23-7 into koji should be in rawhide soon.
>>
>> MAKEDEV is now hosted on git.fedorahosted.org for anyone who cares.
>>
>> Thanks Jakub.
>
> It is time for us to drop the exception in
>
> http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream
>
> Insist that we use fedorahosted.org or other project hosting websites  
> whenever we are upstream for a project? It certainly makes it easier for  
> others to consume our bits when they don't have to crawl through source  
> rpm packages. SRPM dumps are a horrible way to manage upstream source  
> code anyway.

I remember an old thread where it was agreed by all participants in
general that using any kind of hosting beside srpm was a must in fedora
(be it in fedorahosted.org, a simple html page with downloads, a project 
in savannah or wherever).

--
Pat



From rc040203 at freenet.de  Thu Oct  9 11:40:58 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 09 Oct 2008 13:40:58 +0200
Subject: rpms/perl-qooxdoo-compat/devel import.log, NONE, 1.1
	perl-qooxdoo-compat-0.7.3-strict.patch, NONE,
	1.1 perl-qooxdoo-compat.spec, 
	NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
In-Reply-To: <20081007180233.8CFEF700DE@cvs1.fedora.phx.redhat.com>
References: <20081007180233.8CFEF700DE@cvs1.fedora.phx.redhat.com>
Message-ID: <1223552458.3564.1185.camel@beck.corsepiu.local>

On Tue, 2008-10-07 at 18:02 +0000, Terje R?sten wrote:
> Author: terjeros
> 
> Update of /cvs/extras/rpms/perl-qooxdoo-compat/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv7049/devel
> 
> Modified Files:
> 	.cvsignore sources 
> Added Files:
> 	import.log perl-qooxdoo-compat-0.7.3-strict.patch 
> 	perl-qooxdoo-compat.spec 
> Log Message:
> Importing perl-qooxdoo-compat
> 
> 
> 
> 
> --- NEW FILE import.log ---
> perl-qooxdoo-compat-0_7_3-2_fc9:HEAD:perl-qooxdoo-compat-0.7.3-2.fc9.src.rpm:1223402492
> 
> perl-qooxdoo-compat-0.7.3-strict.patch:
> 
> --- NEW FILE perl-qooxdoo-compat-0.7.3-strict.patch ---
> --- qooxdoo-0.7.3-backend/backend/perl/Qooxdoo/JSONRPC.pm~	2008-01-14 15:24:16.000000000 +0100
> +++ qooxdoo-0.7.3-backend/backend/perl/Qooxdoo/JSONRPC.pm	2008-10-05 22:44:25.000000000 +0200
> @@ -18,7 +18,7 @@
>  # The JSON-RPC implementation.
>  # Use perldoc on this file to view documentation
>  
> -use strict;
> +#use strict;
>  

Why do you comment out strict?

Is this package's quality of such a kind, it doesn't work with strict?


Ralf





From buc at odusz.so-cdu.ru  Thu Oct  9 11:45:16 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 09 Oct 2008 15:45:16 +0400
Subject: libcurl + (NSS or openssl)
In-Reply-To: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
References: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
Message-ID: <48EDEECC.3040703@odu.neva.ru>

Matt_Domsch at Dell.com wrote:
> First, libcurl being built against nss.  Nss does not provide some
> functions which are necessary for NTLM authentication to succeed.  This
> has defeatured the 'curl' application, rendering it useless in
> environments where users are behind an NTLM-authenticating proxy.  This
> bites me personally every day.  Yes, NTLM is based on MD4 which is
> insecure. Nevertheless, choice of corporate proxy servers is often
> beyond the reach of even the most senior Linux developers (aside from
> changing jobs...)
>
> Second, libcurl being built against nss.  OpenWSMAN has an eventing
> capability, but this uses libcurl, which in turn would use a feature of
> openssl. But as libcurl is not built against openssl, the eventing
> capability at this point must be disabled in OpenWSMAN.  This capability
> will be important to the sblim-* systems management software stack which
> implements DMTF open standards.  I need to investigate further what the
> source of the problem here is.
>
> Arguably, one should discover the missing functionalty from nss, and
> re-implement it so as to enable these functions.  However, as these
> functions do work if linked against openssl, I would prefer to see the
> expedient approach of linking libcurl against openssl again, and only
> release with it linked against nss once it is at feature parity for the
> functions used by software within Fedora.
>
> Can I ask that libcurl be rebuilt against openssl instead of nss for the
> time being?
>   

You can, but it is obvious that a backward switch is very unlikely.

Addon of some extra functionality to NSS seems questionable as well. 
Perhaps, in far future only. Unlike the OpenSSL and Gnutls, NSS seems 
more stable, more tested, more certificated -- ie. more conservative. 
Hence the support of some "corner" cases is not a primary goal.

BTW, in some areas OpenSLL looks more perspective. For example, Russia 
have chosen other way for crypto in the state life -- so called GOST 
instead of RSA. OpenSSL will start to support it since 0.9.9, plans of 
NSS is unknown... As a result, the compulsion for NSS in Fedora can make 
its usage impossible in the state organisations of some countries.

Another issue is license compatibility. Whilst OpenSSL is "widely used", 
it can be considered as a "basic system application", hence programs may 
link with it anyway (due to some exception in GPL etc...). After the 
most of things will be switched to NSS, the OpenSSl itself will become 
"an optional" instead of "system basic". The correspond exception in GPL 
will not affect anymore, and the rest of GPL applications who still will 
use OpenSSL will become illegal.


Just my thoughts...

~buc



From mattdm at mattdm.org  Thu Oct  9 11:50:25 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 9 Oct 2008 07:50:25 -0400
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <loom.20081009T030905-695@post.gmane.org>
References: <200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<loom.20081008T222346-18@post.gmane.org>
	<20081009000410.GA25476@jadzia.bu.edu>
	<loom.20081009T030905-695@post.gmane.org>
Message-ID: <20081009115025.GA27302@jadzia.bu.edu>

On Thu, Oct 09, 2008 at 03:12:20AM +0000, Kevin Kofler wrote:
> By putting the first user into /etc/sudoers? That's completely and utterly 

No.

> broken. Just because Ubuntu does something doesn't mean it makes sense. ;-) 
> sudo either needs to be fixed to prompt for the root password instead of 
> denying access altogether if the user is not in sudoers or replaced by 
> something which does (and can still be invoked with "sudo" because that's the 
> command people know).

That's doable as a config option, and a good suggestion.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From rmeggins at redhat.com  Thu Oct  9 12:19:11 2008
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 09 Oct 2008 06:19:11 -0600
Subject: libcurl + (NSS or openssl)
In-Reply-To: <48EDEECC.3040703@odu.neva.ru>
References: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
	<48EDEECC.3040703@odu.neva.ru>
Message-ID: <48EDF6BF.2070909@redhat.com>

Dmitry Butskoy wrote:
> Matt_Domsch at Dell.com wrote:
>> First, libcurl being built against nss.  Nss does not provide some
>> functions which are necessary for NTLM authentication to succeed.  This
>> has defeatured the 'curl' application, rendering it useless in
>> environments where users are behind an NTLM-authenticating proxy.  This
>> bites me personally every day.  Yes, NTLM is based on MD4 which is
>> insecure. Nevertheless, choice of corporate proxy servers is often
>> beyond the reach of even the most senior Linux developers (aside from
>> changing jobs...)
>>
>> Second, libcurl being built against nss.  OpenWSMAN has an eventing
>> capability, but this uses libcurl, which in turn would use a feature of
>> openssl. But as libcurl is not built against openssl, the eventing
>> capability at this point must be disabled in OpenWSMAN.  This capability
>> will be important to the sblim-* systems management software stack which
>> implements DMTF open standards.  I need to investigate further what the
>> source of the problem here is.
>>
>> Arguably, one should discover the missing functionalty from nss, and
>> re-implement it so as to enable these functions.  However, as these
>> functions do work if linked against openssl, I would prefer to see the
>> expedient approach of linking libcurl against openssl again, and only
>> release with it linked against nss once it is at feature parity for the
>> functions used by software within Fedora.
>>
>> Can I ask that libcurl be rebuilt against openssl instead of nss for the
>> time being?
>>   
>
> You can, but it is obvious that a backward switch is very unlikely.
>
> Addon of some extra functionality to NSS seems questionable as well. 
> Perhaps, in far future only. Unlike the OpenSSL and Gnutls, NSS seems 
> more stable, more tested, more certificated -- ie. more conservative. 
> Hence the support of some "corner" cases is not a primary goal.
Not in NSS itself, but there is this project as well - 
http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ - 
to assist in porting applications that use OpenSSL to use NSS.  There 
are plans to provide support for MD4 as well.  I don't think MD4 will be 
added to NSS, but perhaps to the ossl wrapper layer or to some other 
add-on layer.
>
> BTW, in some areas OpenSLL looks more perspective. For example, Russia 
> have chosen other way for crypto in the state life -- so called GOST 
> instead of RSA. OpenSSL will start to support it since 0.9.9, plans of 
> NSS is unknown... As a result, the compulsion for NSS in Fedora can 
> make its usage impossible in the state organisations of some countries.
Now that NSS has been adopted by the LSB - 
http://ldn.linuxfoundation.org/article/lsb-40-the-cryptography-strategy 
- there will likely be a lot more impetus to support other crypto.  I 
think other countries have different crypto requirements outside of the 
usual SSLv3/TLSv1 algorithms and cipher suites, and I expect these will 
be supported by the NSS framework, if not directly supported by NSS.
>
> Another issue is license compatibility. Whilst OpenSSL is "widely 
> used", it can be considered as a "basic system application", hence 
> programs may link with it anyway (due to some exception in GPL 
> etc...). After the most of things will be switched to NSS, the OpenSSl 
> itself will become "an optional" instead of "system basic". The 
> correspond exception in GPL will not affect anymore, and the rest of 
> GPL applications who still will use OpenSSL will become illegal.
>
>
> Just my thoughts...
>
> ~buc
>

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

From ssorce at redhat.com  Thu Oct  9 12:38:31 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 09 Oct 2008 08:38:31 -0400
Subject: libcurl + (NSS or openssl)
In-Reply-To: <48EDEECC.3040703@odu.neva.ru>
References: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
	<48EDEECC.3040703@odu.neva.ru>
Message-ID: <1223555911.27822.16.camel@hopeson>

On Thu, 2008-10-09 at 15:45 +0400, Dmitry Butskoy wrote:

> Addon of some extra functionality to NSS seems questionable as well. 
> Perhaps, in far future only. Unlike the OpenSSL and Gnutls, NSS seems 
> more stable, more tested, more certificated -- ie. more conservative. 
> Hence the support of some "corner" cases is not a primary goal.

Usually these "corner cases" are just bad security practice, it is
better if NSS keep you straight and does not let you mess with security
related stuff.

> BTW, in some areas OpenSLL looks more perspective. For example, Russia 
> have chosen other way for crypto in the state life -- so called GOST 
> instead of RSA. OpenSSL will start to support it since 0.9.9, plans of 
> NSS is unknown... As a result, the compulsion for NSS in Fedora can make 
> its usage impossible in the state organisations of some countries.

Send inquiries to the NSS team about support of GOST in NSS then.

> Another issue is license compatibility. Whilst OpenSSL is "widely used", 
> it can be considered as a "basic system application", hence programs may 
> link with it anyway (due to some exception in GPL etc...). After the 
> most of things will be switched to NSS, the OpenSSl itself will become 
> "an optional" instead of "system basic". The correspond exception in GPL 
> will not affect anymore, and the rest of GPL applications who still will 
> use OpenSSL will become illegal.

Sorry but this is just legal mumbo-jumbo ...

Simo.




From fedora at leemhuis.info  Thu Oct  9 12:50:00 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 09 Oct 2008 14:50:00 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
In-Reply-To: <20081008133115.0c164ef8@ohm.scrye.com>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>	<48EB03C6.9080300@leemhuis.info>	<mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
Message-ID: <48EDFDF8.4080406@leemhuis.info>

On 08.10.2008 21:31, Kevin Fenzi wrote:
> On Wed, 08 Oct 2008 12:48:54 +0200
> mcepl at redhat.com (Matej Cepl) wrote:
>> On 2008-10-07, 06:37 GMT, Thorsten Leemhuis wrote:
> [...]
> I don't speak for FESCo, but I do care what gets discussed here. 
> I however don't think it should just be a majority rule or 'he who
> shouts loudest' or even 'who we think "won" the discussion. 

Agreed, but nevertheless the process for getting things/features 
discussed/approved by FESCo partly tends to follow the 'follow the one 
who shouts loudest' mechanism(?), because a whole lot of faith and trust 
is put into the one that drives the feature forward -- e.g. he's the one 
who shouts loudest in this case. But he's not doing it on purpose -- it 
just happens.


A totally made up example might help to express better what I'd like to say:

Say someone suggests to switch back to XFree86 for some reason (that's a 
bit to crazy for this example, but my mind didn't came up with something 
better). He writes a feature page and posts a proposal to fedora-devel 
(not all feature owners do that, which IMHO is wrong; posting the 
proposals to the list directly before they are being discussed would 
help a lot IMHO); some people will be in favor of the proposal (some 
people will be in favor even if things are crazy), but a lot of people 
will disagree (which definitely would be the right thing to do in the 
XFree86 example ;-) ). The discussion sooner or later will slow down; 
most subscribers will remember the debate as "most people disagree with 
it so this is not going to get realized in Fedora".

But now let's imagine that the one that want to do that change doesn't 
realize that it's wrong to do what he wants. He improves and modifies 
his proposal and one or two months later presents it to FESCo with the 
words "this was discussed on fedora-devel a few weeks ago; some people 
did not like it, hence I modified the proposal after I got all that 
feedback. Here is the improved version; please discuss and approve".

Most people (including FESCo members) after those one or two months will 
have forgotten most (if not all) of the arguments from the mailing list 
discussion; and only some people/FESCo members will look at the old 
discussion closer again (we are all busy and time is very rare); so it's 
easy to at least partly tend to trust the proposal (and its writer) that 
is up for FESCo discussion -- it's the classical "nuclear reactor" part 
in the bicycle shed example ( 
http://en.wikipedia.org/wiki/Color_of_the_bikeshed ).


The only way to prevent this problem: if you dislike something you need 
to watch "something" constantly and work against it as long as there is 
someone else that drives "something" forward. That's a whole lot of work 
  :-/

 > [...]

CU
knurd

(?) note that his was quite similar in the old days when I was in 
FESCo/FESCO chair, so don't read this mail as a "knurd is complaining 
about FESCo again" mail ;-)



From lesmikesell at gmail.com  Thu Oct  9 12:50:11 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 09 Oct 2008 07:50:11 -0500
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <1223520853.3564.1147.camel@beck.corsepiu.local>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>	<20081007123307.GA19618@jadzia.bu.edu>	<1223499686.26341.35.camel@localhost.localdomain>
	<1223520853.3564.1147.camel@beck.corsepiu.local>
Message-ID: <48EDFE03.8020209@gmail.com>

Ralf Corsepius wrote:
> On Wed, 2008-10-08 at 16:01 -0500, Callum Lerwick wrote:
>> On Tue, 2008-10-07 at 08:33 -0400, Matthew Miller wrote:
>>> On Tue, Oct 07, 2008 at 01:25:26AM -0400, Jon Stanley wrote:
>>>> The proper time to voice objections to this would have been there, 6
>>>> weeks ago now.
>>> Well, as I thought the discussion had been left before that meeting, fixing
>>> the general problem of user-level commands in the wrong places was the
>>> feature and it was going to be solved properly. The feature is called "sbin
>>> sanity", and I'm 100% in support of that. The "ah, hell, just put everything
>>> in the path and call that sane" change came as a surprise to me.
>> https://fedoraproject.org/wiki/Features/SbinSanity
>>
>> And under Scope it says: "Change the default PATH to
>> include /usr/local/sbin:/usr/sbin:/sbin for all users. Note that it must
>> come at the end of the path for normal users, or consolehelper will
>> break." According to the history, it's been there since at least May 24
>> 2008, when it was imported from MoinMoin. A period of ~5 months.
>>
>> If you're surprised by this, you simply aren't paying attention to the
>> feature process. I've seen many emails go out on fedora-announce about
>> the status of features, in which checking up on features you are
>> interested in is a single click away.
>>
>> Also notable, in the discussion section of the May 24 revision, since
>> moved to the Talk page:
>>
>> "Alternate approach: couldn't we just symlink commonly-used binaries
>> into /bin or /usr/bin?
>>
>> Yes, but this requires editing and rebuilding dozens of RPMs and
>> constant argument about which binaries deserve special treatment. Lots
>> more work for very little actual improvement."
>>
>> No one in this thread is making any point that hasn't already been
>> considered.
> Correct, because none of these "alternatives" is discussworthy. Both are
> equally broken.

What's broken about putting symlinks to the dozen or so programs that 
have common non-root usage into /usr/bin?  The symlinks could even be a 
separate package that people who didn't like the idea could remove. 
They don't even need to depend on the target package - if the target 
executable doesn't exist you aren't any worse off with the symlink than 
without.  Nothing would have to be rebuilt.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From sandeen at redhat.com  Thu Oct  9 13:04:46 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 09 Oct 2008 08:04:46 -0500
Subject: Heads up on ext4 changes
Message-ID: <48EE016E.8050407@redhat.com>

The ext4 patchset for 2.6.28 contains several fixes as well as,
ultimately, a change in the name of the filesystem from "ext4dev" to
"ext4." (*) - I've pulled this in for F10.

This will also require an updated e2fsprogs, because there was a bug in
blkid which failed to recognize older "ext4dev" filesystems (those with
the test_fs flag set) as ext4, as it should have.  This caused them to
not mount automatically.

So long story short, you'll need to update kernel & e2fsprogs together,
if you have ext4(dev) filesystems and you need them to mount seamlessly.
 It's recoverable (just a mounting  failure) but I don't want anyone to
be too surprised.

There are anaconda changes as well, so until anaconda gets in sync,
installs on ext4 may not work (that renaming patch has been sent, too).

Thanks,
-Eric

(*)Yes, this does indicate that the ext4 developers feel it's time to
move on past the "dev" stage; as the patch says "The ext4 filesystem is
getting stable enough that it's time to drop the "dev" prefix." - as
with any filesystem, though, I still encourage you to back up important
data :)



From lokthare at gmail.com  Thu Oct  9 13:16:40 2008
From: lokthare at gmail.com (=?ISO-8859-1?Q?Jean-Fran=E7ois?= Martin)
Date: Thu, 09 Oct 2008 15:16:40 +0200
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <1223161806.9727.8.camel@abel>
References: <1223161806.9727.8.camel@abel>
Message-ID: <1223558200.11538.18.camel@abel>

Le dimanche 05 octobre 2008 ? 01:10 +0200, Jean-Fran?ois Martin a
?crit :
> Hi,
> 
> I m looking for a reviewer for trash-cli
> (https://bugzilla.redhat.com/show_bug.cgi?id=448122).
> 
> Patrice Dumas had already done a partial review but don't want to accept
> the package because he think that executables are too generic (trash,
> empty-trash, list-trash, restore-trash).
> 
> Does any reviewer would accept this package with this scripts or should
> i try persuade upstream to change them?

I haven't find a reviewer so i have send a mail to convince the author
to change the command name.

If he don't accept, i will change the name of the command. Should i send
a mail to distributions at lists.freedesktop.org as Rahul Sundaram advises
me?
-- 
Jean-Fran?ois Martin
https://fedoraproject.org/wiki/User:Lokthare
https://lokthare.wordpress.com/
GPG: 3876DB6B



From valent.turkovic at gmail.com  Thu Oct  9 13:38:38 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 15:38:38 +0200
Subject: Fedora 10 Live CD services (all necessary?)
Message-ID: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>

Hi,
I checked which services are running by default after installing
Fedora 10 beta and here they are:

# chkconfig --list|grep 5:on
NetworkManager 	0:off	1:off	2:on	3:on	4:on	5:on	6:off
anacron        	0:off	1:off	2:on	3:on	4:on	5:on	6:off
atd            	0:off	1:off	2:off	3:on	4:on	5:on	6:off
auditd         	0:off	1:off	2:on	3:on	4:on	5:on	6:off
avahi-daemon   	0:off	1:off	2:off	3:on	4:on	5:on	6:off
bluetooth      	0:off	1:off	2:off	3:on	4:on	5:on	6:off
cpuspeed       	0:off	1:on	2:on	3:on	4:on	5:on	6:off
crond          	0:off	1:off	2:on	3:on	4:on	5:on	6:off
cups           	0:off	1:off	2:on	3:on	4:on	5:on	6:off
fedora-late-live	0:off	1:off	2:off	3:on	4:on	5:on	6:off
fedora-live    	0:off	1:off	2:off	3:on	4:on	5:on	6:off
gpm            	0:off	1:off	2:on	3:on	4:on	5:on	6:off
haldaemon      	0:off	1:off	2:off	3:on	4:on	5:on	6:off
ip6tables      	0:off	1:off	2:on	3:on	4:on	5:on	6:off
iptables       	0:off	1:off	2:on	3:on	4:on	5:on	6:off
irqbalance     	0:off	1:off	2:off	3:on	4:on	5:on	6:off
kerneloops     	0:off	1:off	2:off	3:on	4:on	5:on	6:off
mdmonitor      	0:off	1:off	2:on	3:on	4:on	5:on	6:off
messagebus     	0:off	1:off	2:on	3:on	4:on	5:on	6:off
microcode_ctl  	0:off	1:off	2:on	3:on	4:on	5:on	6:off
netfs          	0:off	1:off	2:off	3:on	4:on	5:on	6:off
nfslock        	0:off	1:off	2:off	3:on	4:on	5:on	6:off
ntpd           	0:off	1:off	2:on	3:on	4:on	5:on	6:off
portreserve    	0:off	1:off	2:on	3:on	4:on	5:on	6:off
rpcbind        	0:off	1:off	2:on	3:on	4:on	5:on	6:off
rpcgssd        	0:off	1:off	2:off	3:on	4:on	5:on	6:off
rpcidmapd      	0:off	1:off	2:off	3:on	4:on	5:on	6:off
rsyslog        	0:off	1:off	2:on	3:on	4:on	5:on	6:off
sendmail       	0:off	1:off	2:on	3:on	4:on	5:on	6:off
setroubleshoot 	0:off	1:off	2:off	3:on	4:on	5:on	6:off
udev-post      	0:off	1:on	2:on	3:on	4:on	5:on	6:off

Are these services all really necessary?

I bet that some of these could be disabled by default because some of
them are not needed for target audience - desktop users.

Any opinions?

Cheers,
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 naheemzaffar at gmail.com  Thu Oct  9 14:16:29 2008
From: naheemzaffar at gmail.com (Naheem Zaffar)
Date: Thu, 9 Oct 2008 15:16:29 +0100
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
Message-ID: <3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>

Which ones?

Just asking someone else to both investigate the situation and then do
the work is easy. Atleast the basic investigation step does not need a
coder/developer. Find what you believe is extra and then ask why that
is on, and if it can be turned off.

Pretty off topic, but I notice that NetworkManager, bluetooth and CUPS
are all on and I suspect that they will be useful to most people.

Would it be possible to turn these off and have HAL (or some sort of
hardware service manager) start them up if the relevant hardware is
detected? (yes, I am also asking - call me hypocritical :P)



From sgrubb at redhat.com  Thu Oct  9 14:24:20 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 9 Oct 2008 10:24:20 -0400
Subject: libcurl + (NSS or openssl)
In-Reply-To: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
References: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
Message-ID: <200810091024.20373.sgrubb@redhat.com>

On Wednesday 08 October 2008 18:34:40 Matt_Domsch at dell.com wrote:
> First, libcurl being built against nss.  Nss does not provide some
> functions which are necessary for NTLM authentication to succeed.  
> has defeatured the 'curl' application, rendering it useless in
> environments where users are behind an NTLM-authenticating proxy.  This
> bites me personally every day.  Yes, NTLM is based on MD4 which is
> insecure. Nevertheless, choice of corporate proxy servers is often
> beyond the reach of even the most senior Linux developers (aside from
> changing jobs...)

This appears to be bug:
https://bugzilla.redhat.com/show_bug.cgi?id=258481
or
https://bugzilla.redhat.com/show_bug.cgi?id=263241

I think that more effort needs to be put on these.


> Second, libcurl being built against nss.  OpenWSMAN has an eventing
> capability, but this uses libcurl, which in turn would use a feature of
> openssl. 

Which feature?

> But as libcurl is not built against openssl, the eventing capability at this
> point must be disabled in OpenWSMAN.  This capability will be important to
> the sblim-* systems management software stack which implements DMTF open
> standards.  I need to investigate further what the source of the problem
> here is. 

Yes, and please file a bug.


> Arguably, one should discover the missing functionalty from nss, and
> re-implement it so as to enable these functions.  However, as these
> functions do work if linked against openssl, I would prefer to see the
> expedient approach of linking libcurl against openssl again, and only
> release with it linked against nss once it is at feature parity for the
> functions used by software within Fedora.

If we didn't do this, you wouldn't have reported a problem and we wouldn't 
know something needs fixing. NSS has been accepted by LSB, so we need to 
press forward and make fixes. One could also say that openssl is not on 
feature parity with NSS, too.


> Can I ask that libcurl be rebuilt against openssl instead of nss for the
> time being?

I think we should identify what's broken and try to fix it.

Thanks,
-Steve



From paul at city-fan.org  Thu Oct  9 14:41:56 2008
From: paul at city-fan.org (Paul Howarth)
Date: Thu, 09 Oct 2008 15:41:56 +0100
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
Message-ID: <48EE1834.4020405@city-fan.org>

Naheem Zaffar wrote:
> Which ones?
> 
> Just asking someone else to both investigate the situation and then do
> the work is easy. Atleast the basic investigation step does not need a
> coder/developer. Find what you believe is extra and then ask why that
> is on, and if it can be turned off.
> 
> Pretty off topic, but I notice that NetworkManager, bluetooth and CUPS
> are all on and I suspect that they will be useful to most people.
> 
> Would it be possible to turn these off and have HAL (or some sort of
> hardware service manager) start them up if the relevant hardware is
> detected? (yes, I am also asking - call me hypocritical :P)

CUPS can autodetect network printers, which desktop users would no doubt 
find useful, even though there may be no local printing hardware.

Paul.



From dwmw2 at infradead.org  Thu Oct  9 14:44:10 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 Oct 2008 15:44:10 +0100
Subject: libcurl + (NSS or openssl)
In-Reply-To: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
References: <E9909A75A543064DB66E55B8E3BE41ECA227C9@ausx3mps307.aus.amer.dell.com>
Message-ID: <1223563450.28324.58.camel@macbook.infradead.org>

On Wed, 2008-10-08 at 17:34 -0500, Matt_Domsch at Dell.com wrote:
> I understand the push behind getting as many packages to build against
> nss as possible.  However, nss is not on feature parity with openssl
> at this time.

Using SSL certificates from a TPM is fairly trivial in OpenSSL too. Just
install the openssl-tpm-engine package and it's a few lines of code to
initialise that engine in your application (and curl has callbacks which
let you do it at the appropriate time).

For NSS, there's theoretically a PKCS#12 plugin which can use the TPM,
but it relies on a whole stack of other weird stuff we don't ship,
including more system d?mons, and which I haven't been able to get
working.

Then there's the DTLS protocol, which neither NSS or GNUTLS support at
all...

I actually ditched libcurl and wrote my own http code, cursing all the
time as I did it, because of the switch to NSS.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From mcepl at redhat.com  Thu Oct  9 15:13:54 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 09 Oct 2008 17:13:54 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info> <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
	<hlovr5xhlg.ln2@ppp1053.in.ipex.cz>
	<1223505701.4410.89.camel@luminos.localdomain>
Message-ID: <imj1s5xbkj.ln2@ppp1053.in.ipex.cz>

On 2008-10-08, 22:41 GMT, Jesse Keating wrote:
> Conclusions are rarely reached on mailing list arguments.

Which is the reason, why I remember this one exception. :)

Mat?j



From mcepl at redhat.com  Thu Oct  9 15:20:25 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 09 Oct 2008 17:20:25 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info> <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
	<48EDFDF8.4080406@leemhuis.info>
Message-ID: <p2k1s5x8qj.ln2@ppp1053.in.ipex.cz>

On 2008-10-09, 12:50 GMT, Thorsten Leemhuis wrote:
> Most people (including FESCo members) after those one or two 
> months will have forgotten most (if not all) of the arguments 
> from the mailing list discussion; and only some people/FESCo 
> members will look at the old discussion closer again (we are 
> all busy and time is very rare);

I thought that I will gladly let this thread die, but this 
paragraph hit me -- if this the description of reality in FESCo 
than I know how to vote in the upcoming elections. If you really 
don't prepare for the decision on the meeting agenda in advance 
(which would apparently include here checking the thread from the 
archives of fedora-devel), then you are not doing your job well.  

And I really don't care much how busy you are. If the quality of 
decision-making process is so bad, than you have probably put too 
much on your plate, and you should reconsider your involvment in 
Fedora and possibly scale down somewhere.

I hope that you were making up this scenario just to cheaply 
destroy my argument, because I would hate if this is the true 
description of the FESCo decision making process.

Best,

Mat?j



From mcepl at redhat.com  Thu Oct  9 15:27:04 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 09 Oct 2008 17:27:04 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info> <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
	<hlovr5xhlg.ln2@ppp1053.in.ipex.cz> <48ED3A36.2060605@gmail.com>
Message-ID: <8fk1s5x8qj.ln2@ppp1053.in.ipex.cz>

On 2008-10-08, 22:54 GMT, Toshio Kuratomi wrote:
> I remember there was a flamewar but I don't remember all that 
> was said or where it concluded.  I do recall that Casey Dahlin 
> decided we needed to write our own init replacement somewhere 
> near the end of it.  Then we had a FUDCon and Casey pitched 
> a session on defining the feature set we wanted in a rewritten 
> init.  At that session, people decided that upstart either had 
> all the features that had been mentioned or was actively 
> working on adding them.  After that, it was a matter of the 
> people who cared about a new init system were doing the work to 
> get upstart merged so FESCo approved that work as a feature.

OK, this is much better explanation that what I was afraid 
happened.

Thanks a lot for giving me peace in this situation.

Mat?j



From konrad at tylerc.org  Thu Oct  9 15:40:26 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 9 Oct 2008 08:40:26 -0700
Subject: trash-cli : Looking for a reviewer
In-Reply-To: <1223558200.11538.18.camel@abel>
References: <1223161806.9727.8.camel@abel> <1223558200.11538.18.camel@abel>
Message-ID: <200810090840.26149.konrad@tylerc.org>

On Thursday 09 October 2008 06:16:40 am Jean-Fran?ois Martin wrote:
> Le dimanche 05 octobre 2008 ? 01:10 +0200, Jean-Fran?ois Martin a
>
> ?crit :
> > Hi,
> >
> > I m looking for a reviewer for trash-cli
> > (https://bugzilla.redhat.com/show_bug.cgi?id=448122).
> >
> > Patrice Dumas had already done a partial review but don't want to accept
> > the package because he think that executables are too generic (trash,
> > empty-trash, list-trash, restore-trash).
> >
> > Does any reviewer would accept this package with this scripts or should
> > i try persuade upstream to change them?
>
> I haven't find a reviewer so i have send a mail to convince the author
> to change the command name.
>
> If he don't accept, i will change the name of the command. Should i send
> a mail to distributions at lists.freedesktop.org as Rahul Sundaram advises
> me?

Following Rahul's advise would be a good idea.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>





From mike at miketc.net  Thu Oct  9 15:59:29 2008
From: mike at miketc.net (Mike Chambers)
Date: Thu, 09 Oct 2008 10:59:29 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <48EE016E.8050407@redhat.com>
References: <48EE016E.8050407@redhat.com>
Message-ID: <1223567969.2870.2.camel@scrappy.miketc.net>

On Thu, 2008-10-09 at 08:04 -0500, Eric Sandeen wrote:

> (*)Yes, this does indicate that the ext4 developers feel it's time to
> move on past the "dev" stage; as the patch says "The ext4 filesystem is
> getting stable enough that it's time to drop the "dev" prefix." - as
> with any filesystem, though, I still encourage you to back up important
> data :)

Does this mean ext4 will be available as generic during
installs/upgrades, same as ext3?  Or does it have to be given as an
option during install to get it to show up?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From jwboyer at gmail.com  Thu Oct  9 16:03:30 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 9 Oct 2008 12:03:30 -0400
Subject: Taking fedora-devel into consideration [Was: Re: tab
	completion less useful now, due to sbin in path]
In-Reply-To: <p2k1s5x8qj.ln2@ppp1053.in.ipex.cz>
References: <1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info>
	<mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
	<48EDFDF8.4080406@leemhuis.info>
	<p2k1s5x8qj.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081009160330.GA24582@yoda.jdub.homelinux.org>

On Thu, Oct 09, 2008 at 05:20:25PM +0200, Matej Cepl wrote:
>On 2008-10-09, 12:50 GMT, Thorsten Leemhuis wrote:
>> Most people (including FESCo members) after those one or two 
>> months will have forgotten most (if not all) of the arguments 
>> from the mailing list discussion; and only some people/FESCo 
>> members will look at the old discussion closer again (we are 
>> all busy and time is very rare);
>
>I thought that I will gladly let this thread die, but this 
>paragraph hit me -- if this the description of reality in FESCo 
>than I know how to vote in the upcoming elections. If you really 
>don't prepare for the decision on the meeting agenda in advance 
>(which would apparently include here checking the thread from the 
>archives of fedora-devel), then you are not doing your job well.  
>
>And I really don't care much how busy you are. If the quality of 
>decision-making process is so bad, than you have probably put too 
>much on your plate, and you should reconsider your involvment in 
>Fedora and possibly scale down somewhere.
>
>I hope that you were making up this scenario just to cheaply 
>destroy my argument, because I would hate if this is the true 
>description of the FESCo decision making process.

I don't think it's really accurate of FESCo today.  I will
concede that during turnover, some of the history is lost in
FESCo in general.  That is only natural as new people come in,
and it's also why we changed the elections to only have 1/2 the
seats up for election at once.

josh



From sandeen at redhat.com  Thu Oct  9 16:05:39 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 09 Oct 2008 11:05:39 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <1223567969.2870.2.camel@scrappy.miketc.net>
References: <48EE016E.8050407@redhat.com>
	<1223567969.2870.2.camel@scrappy.miketc.net>
Message-ID: <48EE2BD3.2040106@redhat.com>

Mike Chambers wrote:
> On Thu, 2008-10-09 at 08:04 -0500, Eric Sandeen wrote:
> 
>> (*)Yes, this does indicate that the ext4 developers feel it's time to
>> move on past the "dev" stage; as the patch says "The ext4 filesystem is
>> getting stable enough that it's time to drop the "dev" prefix." - as
>> with any filesystem, though, I still encourage you to back up important
>> data :)
> 
> Does this mean ext4 will be available as generic during
> installs/upgrades, same as ext3?  Or does it have to be given as an
> option during install to get it to show up?

it still takes the ext4 option on boot.

-Eric



From valent.turkovic at gmail.com  Thu Oct  9 16:05:59 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 18:05:59 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
Message-ID: <64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>

On Thu, Oct 9, 2008 at 4:16 PM, Naheem Zaffar <naheemzaffar at gmail.com> wrote:
> Which ones?

I asked because I hoped that people here have more knowledge and
experience than I do regarding services... I can speak for myself as
an "more than average desktop user" who uses Fedora as his PRIMARY
desktop at home and also at work.

source for information about Fedora services:
http://delicious.com/valentt/services
btw is there Fedora Wiki page explaining services?

I would like to see the following services should be disabled by default:

anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off

I don't need schedulers, it some critical part of Fedora doesn't need
I don't see the need for it on a desktop system. Others that need it
also know where to find it and enable it.


avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off

I don't need it.


bluetooth       0:off   1:off   2:off   3:on    4:on    5:on    6:off

Depending on the laptop - it it has no bluetooth it should be
disabled, right? Ok, that will come in Fedora 11 as I have read with
upstart not running in compatible mode.


crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off

I don't need it.


fedora-late-live        0:off   1:off   2:off   3:on    4:on    5:on    6:off
fedora-live     0:off   1:off   2:off   3:on    4:on    5:on    6:off

Why are these service active on an installed system? This is not a
Live-CD anymore... is this a bug or some feature?


ip6tables       0:off   1:off   2:on    3:on    4:on    5:on    6:off

Don't use ipv6...


irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off

I don't need this because I have a single core laptop.


kerneloops      0:off   1:off   2:off   3:on    4:on    5:on    6:off

advanced users could opt-in and turn on thi service if then need it, I
don't need it.


mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off

On my laptop I'm not using lvm or raid, so i don't need this neither.



netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
nfslock         0:off   1:off   2:off   3:on    4:on    5:on    6:off

I'm not using NFS, if I did I would enable this, but I would like for
these services to be off by default.


ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

Don't need it.


portreserve     0:off   1:off   2:on    3:on    4:on    5:on    6:off



rpcbind         0:off   1:off   2:on    3:on    4:on    5:on    6:off
rpcgssd         0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcidmapd       0:off   1:off   2:off   3:on    4:on    5:on    6:off

I don't use and don't need NFS or related services.


sendmail        0:off   1:off   2:on    3:on    4:on    5:on    6:off

sendmail for a desktop system? I don't need it.


-- 
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 opensource at till.name  Thu Oct  9 16:09:01 2008
From: opensource at till.name (Till Maas)
Date: Thu, 09 Oct 2008 18:09:01 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <48ED8F5A.3030403@fedoraproject.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
Message-ID: <200810091809.07653.opensource@till.name>

On Thu October 9 2008, Rahul Sundaram wrote:

> It is time for us to drop the exception in
>
> http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream
>
> Insist that we use fedorahosted.org or other project hosting websites
> whenever we are upstream for a project? It certainly makes it easier for
> others to consume our bits when they don't have to crawl through source
> rpm packages. SRPM dumps are a horrible way to manage upstream source
> code anyway.

I agree. I find it also useful as a potential patch provider to have a clear 
upstream location where development can be watched and patches can be 
tracked.

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/20081009/468c91e4/attachment.sig>

From jkeating at redhat.com  Thu Oct  9 16:09:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 09 Oct 2008 09:09:44 -0700
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <48ED8F5A.3030403@fedoraproject.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
Message-ID: <1223568584.4410.101.camel@luminos.localdomain>

On Thu, 2008-10-09 at 10:28 +0530, Rahul Sundaram wrote:
> Insist that we use fedorahosted.org or other project hosting websites 
> whenever we are upstream for a project? It certainly makes it easier for 
> others to consume our bits when they don't have to crawl through source 
> rpm packages. SRPM dumps are a horrible way to manage upstream source 
> code anyway.

Only if we allow source repo tags to be a suitable source distribution
method.  Since fedorahosted still doesn't have an easy to use way of
distributing tarballs, and getting the code via a scm checkout is quite
easy, it should suffice.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/a873095b/attachment.sig>

From opensource at till.name  Thu Oct  9 16:16:30 2008
From: opensource at till.name (Till Maas)
Date: Thu, 09 Oct 2008 18:16:30 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223568584.4410.101.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
Message-ID: <200810091816.31361.opensource@till.name>

On Thu October 9 2008, Jesse Keating wrote:

> Only if we allow source repo tags to be a suitable source distribution
> method.  Since fedorahosted still doesn't have an easy to use way of
> distributing tarballs, and getting the code via a scm checkout is quite
> easy, it should suffice.

If this is the only obstacle to get this done, I will write a patch for 
Makefile.common that displays the URL for every file in sources to fetch it 
from the lookaside cache. Then this URL can be provided as source tarball on 
a fedorahosted wiki page.

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/20081009/3aed87da/attachment.sig>

From fedora at leemhuis.info  Thu Oct  9 16:18:22 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 09 Oct 2008 18:18:22 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
In-Reply-To: <p2k1s5x8qj.ln2@ppp1053.in.ipex.cz>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>	<48EB03C6.9080300@leemhuis.info>
	<mpfur5xrg8.ln2@ppp1053.in.ipex.cz>	<20081008133115.0c164ef8@ohm.scrye.com>	<48EDFDF8.4080406@leemhuis.info>
	<p2k1s5x8qj.ln2@ppp1053.in.ipex.cz>
Message-ID: <48EE2ECE.20006@leemhuis.info>

On 09.10.2008 17:20, Matej Cepl wrote:
> On 2008-10-09, 12:50 GMT, Thorsten Leemhuis wrote:
>> Most people (including FESCo members) after those one or two 
>> months will have forgotten most (if not all) of the arguments 
>> from the mailing list discussion; and only some people/FESCo 
>> members will look at the old discussion closer again (we are 
>> all busy and time is very rare);
> I thought that I will gladly let this thread die, but this 
> paragraph hit me -- if this the description of reality in FESCo 
> than I know how to vote in the upcoming elections. 

Just a reminder: I'm not in FESCo anymore.

> If you really 
> don't prepare for the decision on the meeting agenda in advance 
> (which would apparently include here checking the thread from the 
> archives of fedora-devel), then you are not doing your job well.  

I can't not speak for the current FESCo at all, as I haven't tried to 
get any proposals through FESCo in the past few months.

But during my FESCo time and the time after it (in which I tried to be a 
good Fedora contributor and tried to do things without being in FESCo, 
which was so hard and frustrating that I stopped trying (?)) I more then 
occasional noticed that at least some of the members had not really 
looked properly at proposals and their history; often they had trust in 
the one that handed in the proposal or just followed completely or 
partly the decision from another FESCO member they trusted to know that 
he's familiar with the topic.

Sure, that's not ideal, but I don't really blame us/them for it 
(especially as I suppose I worked similar now and then as well). We are 
all humans and time is limited -- thus we all the time in different 
aspects and areas of our life can't look at each and every detail, as 
there often simply is not enough time to do so; instead we look at the 
basics and put trust and faith in other people we know and just follow 
completely or partly their decision if the basics look good.

 > [...]

CU
knurd

(?) part of that story is relevant for the current as well: I for 
example once had a proposal that I posted to fedora-devel for public and 
FESCo review and discussion; in the end that proposal was posted to 
fedora-devel again and again (five times in the end), as in each new 
meeting a different FESCo member suddenly had a new comment about it and 
wanted something changed; I once or twice  asked why that comment or 
problem hadn't been raised in those earlier decisions on the list. I got 
the answer "sorry, I had no time to follow it closely".

But whatever. That is history now and not that much relevant anymore. It 
just shows how humans sometimes are; that is not specific to FESCo.



From jkeating at redhat.com  Thu Oct  9 16:22:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 09 Oct 2008 09:22:13 -0700
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <200810091816.31361.opensource@till.name>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
	<200810091816.31361.opensource@till.name>
Message-ID: <1223569333.4410.104.camel@luminos.localdomain>

On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> On Thu October 9 2008, Jesse Keating wrote:
> 
> > Only if we allow source repo tags to be a suitable source distribution
> > method.  Since fedorahosted still doesn't have an easy to use way of
> > distributing tarballs, and getting the code via a scm checkout is quite
> > easy, it should suffice.
> 
> If this is the only obstacle to get this done, I will write a patch for 
> Makefile.common that displays the URL for every file in sources to fetch it 
> from the lookaside cache. Then this URL can be provided as source tarball on 
> a fedorahosted wiki page.

Why must we insist on tarballs?  Unless the tarball includes scm
metadata in it, it's practically useless for upstream patch development.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/7a999914/attachment.sig>

From katzj at redhat.com  Thu Oct  9 16:24:43 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 09 Oct 2008 12:24:43 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223569333.4410.104.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
Message-ID: <1223569483.19673.167.camel@aglarond.local>

On Thu, 2008-10-09 at 09:22 -0700, Jesse Keating wrote:
> On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > On Thu October 9 2008, Jesse Keating wrote:
> > > Only if we allow source repo tags to be a suitable source distribution
> > > method.  Since fedorahosted still doesn't have an easy to use way of
> > > distributing tarballs, and getting the code via a scm checkout is quite
> > > easy, it should suffice.
> > 
> > If this is the only obstacle to get this done, I will write a patch for 
> > Makefile.common that displays the URL for every file in sources to fetch it 
> > from the lookaside cache. Then this URL can be provided as source tarball on 
> > a fedorahosted wiki page.
> 
> Why must we insist on tarballs?  Unless the tarball includes scm
> metadata in it, it's practically useless for upstream patch development.

I've been contributing to various upstreams based on patches to tarballs
for a long time.  It's hardly "practically useless".  Sure, working with
an SCM is better (and working with one of the newer ones is even more
so), but tarballs + patches are still quite doable

Jeremy



From jkeating at redhat.com  Thu Oct  9 16:29:42 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 09 Oct 2008 09:29:42 -0700
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223569483.19673.167.camel@aglarond.local>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
	<1223569483.19673.167.camel@aglarond.local>
Message-ID: <1223569782.4410.106.camel@luminos.localdomain>

On Thu, 2008-10-09 at 12:24 -0400, Jeremy Katz wrote:
> 
> I've been contributing to various upstreams based on patches to tarballs
> for a long time.  It's hardly "practically useless".  Sure, working with
> an SCM is better (and working with one of the newer ones is even more
> so), but tarballs + patches are still quite doable

Useful enough for anaconda to start uploading a tarball somewhere each
time you guys do a release?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/7cabb9dd/attachment.sig>

From sundaram at fedoraproject.org  Thu Oct  9 16:31:03 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 09 Oct 2008 22:01:03 +0530
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
Message-ID: <48EE31C7.6090602@fedoraproject.org>

Valent Turkovic wrote:

> I would like to see the following services should be disabled by default:
> 
> anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
> atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> I don't need schedulers, it some critical part of Fedora doesn't need
> I don't see the need for it on a desktop system. Others that need it
> also know where to find it and enable it.

You keep repeating "I don't need it" but the Live CD isn't designed 
exclusively for any single person. It is a general purpose system and 
defaults needs to meet the requirements of typical desktop user. So the 
real questions are "Why is this service enabled by default? What typical 
desktop use cases that does it solve?"

Rahul



From a.badger at gmail.com  Thu Oct  9 16:45:51 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 09 Oct 2008 09:45:51 -0700
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223568584.4410.101.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
Message-ID: <48EE353F.6080106@gmail.com>

Jesse Keating wrote:
> On Thu, 2008-10-09 at 10:28 +0530, Rahul Sundaram wrote:
>> Insist that we use fedorahosted.org or other project hosting websites 
>> whenever we are upstream for a project? It certainly makes it easier for 
>> others to consume our bits when they don't have to crawl through source 
>> rpm packages. SRPM dumps are a horrible way to manage upstream source 
>> code anyway.
> 
> Only if we allow source repo tags to be a suitable source distribution
> method.  Since fedorahosted still doesn't have an easy to use way of
> distributing tarballs, and getting the code via a scm checkout is quite
> easy, it should suffice.
> 
fedorahosted does have an easy to use way of distributing tarballs.
(Compare it to sourceforge's tarball mechanism if you doubt the easiness :-)

https://fedorahosted.org/releases/p/y/python-fedora/
https://fedorahosted.org/web/faq

Note: for people who have administrative access to fedorahosted.org, the
place to scp is slightly different.  For instance, to upload to
python-fedora I have to do:
  scp TARBALL fedorahosted.org:/srv/web/releases/p/y/python-fedora/

-Toshio

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

From myfedora at richip.dhs.org  Thu Oct  9 16:52:22 2008
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 09 Oct 2008 10:52:22 -0600
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <48EE31C7.6090602@fedoraproject.org>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
Message-ID: <48EE36C6.4060400@richip.dhs.org>

Rahul Sundaram wrote:
> Valent Turkovic wrote:
>
>> I would like to see the following services should be disabled by 
>> default:
>>
>> anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
>> atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
>>
>> I don't need schedulers, it some critical part of Fedora doesn't need
>> I don't see the need for it on a desktop system. Others that need it
>> also know where to find it and enable it.
>
> You keep repeating "I don't need it" but the Live CD isn't designed 
> exclusively for any single person. It is a general purpose system and 
> defaults needs to meet the requirements of typical desktop user. So 
> the real questions are "Why is this service enabled by default? What 
> typical desktop use cases that does it solve?"

It might even help to break it down further: 1) During and till the end 
of boot-up and before user interaction, does anything use any of these 
services? 2) In the course of system usage, what activities or apps 
would require that these services be running? 3) In case needed, is 
there a way to autostart them? (That last question reminds me of the 
time the issue came up where other services' premature startup's 
correctness was questioned, including PulseAudio.)

Unfortunately, for every argument that states that LiveCD's use is 
temporal, others would claim to leaving it on for several days, possible 
requiring log rotation and updating of the mlocate db ... unless the 
definition of LiveCD target audience is already pinned down.
--

Richi Plana



From valent.turkovic at gmail.com  Thu Oct  9 16:55:52 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 18:55:52 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <48EE31C7.6090602@fedoraproject.org>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
Message-ID: <64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>

On Thu, Oct 9, 2008 at 6:31 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Valent Turkovic wrote:
>
>> I would like to see the following services should be disabled by default:
>>
>> anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
>> atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
>>
>> I don't need schedulers, it some critical part of Fedora doesn't need
>> I don't see the need for it on a desktop system. Others that need it
>> also know where to find it and enable it.
>
> You keep repeating "I don't need it" but the Live CD isn't designed
> exclusively for any single person. It is a general purpose system and
> defaults needs to meet the requirements of typical desktop user. So the real
> questions are "Why is this service enabled by default? What typical desktop
> use cases that does it solve?"
>
> Rahul

I wrote "I don't need it" repeatedly on purpose because Naheem said
that I need to do investigate which services need to be turned on.
Well I don't have extensive knowledge about other user and their
habbits, and about some particular cases in which some service would
be needed, but I have general knowledge, my own needs of services as
an desktop user and did research regarding which services are used for
what.

I also said that I'm a "above average desktop user" so you could also
replace "I don't need" with "average desktop used doesn't need".

I believe that services should be regarded with the same attitude as
open ports on a firewall. Some long time ago all ports were open and
only "bad ones" were open, now all are closed and only explicitly ones
are opened. Also all security and administration Rad Hat guides say
that all unnecessary services should be turned off, and only turned on
if explicitly needed.

That is why I believe that ALL services should be disabled, and then
for each one there should be some kind of explanation why this service
absolutely needs to be enabled. All the rest services should be left
disabled by default.

Cheers,
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 notting at redhat.com  Thu Oct  9 16:56:34 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 9 Oct 2008 12:56:34 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223568584.4410.101.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
Message-ID: <20081009165634.GA24208@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> Only if we allow source repo tags to be a suitable source distribution
> method.  Since fedorahosted still doesn't have an easy to use way of
> distributing tarballs, and getting the code via a scm checkout is quite
> easy, it should suffice.

Actually, my concern would be whether the admin side of fedorahosted wants
to sign up for increased load, storage, etc.. But then again, I'm not 100%
certain how many packages this would affect.

Bill



From bruno at wolff.to  Thu Oct  9 16:03:37 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 9 Oct 2008 11:03:37 -0500
Subject: Today's rawhide gcc appears to have problems
In-Reply-To: <20081009075405.GB13196@tyan-ft48-01.lab.bos.redhat.com>
References: <20081009022003.GA25810@wolff.to>
	<20081009075405.GB13196@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20081009160337.GA32360@wolff.to>

On Thu, Oct 09, 2008 at 09:54:05 +0200,
  Jakub Jelinek <jakub at redhat.com> wrote:
> On Wed, Oct 08, 2008 at 09:20:03PM -0500, Bruno Wolff III wrote:
> > I am seeing some internal compiler errors when building svn versions of
> > Wesnoth this evening using gcc-4.3.2-5.i386. I wasn't seeing that last
> > night.
> > I have added the output recommended by gcc to bug 466198.
> > I don't know how fast new compiler versions start getting used to build
> > other stuff, but it case its right away I wanted to put out a heads up.
> 
> I guess dup of #466169, which I have already a fix for from last night, will
> just work on a a few minor details in the patch and build a new gcc soon.

Thanks. I won't get a chance to retest it until late tonight. But I'll
update the ticket with how things go either way.



From cra at WPI.EDU  Thu Oct  9 17:04:18 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 9 Oct 2008 13:04:18 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
Message-ID: <20081009170418.GY3000@angus.ind.WPI.EDU>

On Thu, Oct 09, 2008 at 06:55:52PM +0200, Valent Turkovic wrote:
> I also said that I'm a "above average desktop user" so you could also
> replace "I don't need" with "average desktop used doesn't need".
> 
> I believe that services should be regarded with the same attitude as
> open ports on a firewall. Some long time ago all ports were open and
> only "bad ones" were open, now all are closed and only explicitly ones
> are opened. Also all security and administration Rad Hat guides say
> that all unnecessary services should be turned off, and only turned on
> if explicitly needed.

Funny of you to bring this up and then suggest that the IPv6 firewall 
should be *disabled* by default.  Whether you know it or not, your 
system is running IPv6.  It is accessible via link-local at the very 
least, and if you happen to roam to a network that provides IPv6, you 
will get global connectivity.  Eventually I hope to have Fedora on par 
with other operating systems, and provide Teredo functionality [1] by 
default, which means automatic tunneled IPv6 global connectivity by 
default, even behind NATs.  ip6tables is important to have on by 
default now, and will only become more so important over time.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=437626



From valent.turkovic at gmail.com  Thu Oct  9 17:08:29 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 19:08:29 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <20081009170418.GY3000@angus.ind.WPI.EDU>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<20081009170418.GY3000@angus.ind.WPI.EDU>
Message-ID: <64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>

On Thu, Oct 9, 2008 at 7:04 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On Thu, Oct 09, 2008 at 06:55:52PM +0200, Valent Turkovic wrote:
>> I also said that I'm a "above average desktop user" so you could also
>> replace "I don't need" with "average desktop used doesn't need".
>>
>> I believe that services should be regarded with the same attitude as
>> open ports on a firewall. Some long time ago all ports were open and
>> only "bad ones" were open, now all are closed and only explicitly ones
>> are opened. Also all security and administration Rad Hat guides say
>> that all unnecessary services should be turned off, and only turned on
>> if explicitly needed.
>
> Funny of you to bring this up and then suggest that the IPv6 firewall
> should be *disabled* by default.  Whether you know it or not, your
> system is running IPv6.  It is accessible via link-local at the very
> least, and if you happen to roam to a network that provides IPv6, you
> will get global connectivity.  Eventually I hope to have Fedora on par
> with other operating systems, and provide Teredo functionality [1] by
> default, which means automatic tunneled IPv6 global connectivity by
> default, even behind NATs.  ip6tables is important to have on by
> default now, and will only become more so important over time.

I know that no network I access has IPv6. No ADSL carrier in Croatia
uses IPv6, my company doesn't use IPv6, and I in my home network I
don't use IPv6.

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  Thu Oct  9 17:15:27 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 19:15:27 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<20081009170418.GY3000@angus.ind.WPI.EDU>
	<64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
Message-ID: <64b14b300810091015r154bfee5k462322b5a643d0ab@mail.gmail.com>

On Thu, Oct 9, 2008 at 7:08 PM, Valent Turkovic
<valent.turkovic at gmail.com> wrote:
> On Thu, Oct 9, 2008 at 7:04 PM, Chuck Anderson <cra at wpi.edu> wrote:
>> On Thu, Oct 09, 2008 at 06:55:52PM +0200, Valent Turkovic wrote:
>>> I also said that I'm a "above average desktop user" so you could also
>>> replace "I don't need" with "average desktop used doesn't need".
>>>
>>> I believe that services should be regarded with the same attitude as
>>> open ports on a firewall. Some long time ago all ports were open and
>>> only "bad ones" were open, now all are closed and only explicitly ones
>>> are opened. Also all security and administration Rad Hat guides say
>>> that all unnecessary services should be turned off, and only turned on
>>> if explicitly needed.
>>
>> Funny of you to bring this up and then suggest that the IPv6 firewall
>> should be *disabled* by default.  Whether you know it or not, your
>> system is running IPv6.  It is accessible via link-local at the very
>> least, and if you happen to roam to a network that provides IPv6, you
>> will get global connectivity.  Eventually I hope to have Fedora on par
>> with other operating systems, and provide Teredo functionality [1] by
>> default, which means automatic tunneled IPv6 global connectivity by
>> default, even behind NATs.  ip6tables is important to have on by
>> default now, and will only become more so important over time.
>
> I know that no network I access has IPv6. No ADSL carrier in Croatia
> uses IPv6, my company doesn't use IPv6, and I in my home network I
> don't use IPv6.

ps. I also wrote:

"That is why I believe that ALL services should be disabled, and then
for each one there should be some kind of explanation why this service
absolutely needs to be enabled. All the rest services should be left
disabled by default."

Fedora 9 had an option during install where you choose to use or not
to use IPv6, I don't see that option in Fedora 10, why? If there is an
option I would like to disabel IPv6, and also IPv6 iptables. If there
is no option to disable IPv6 then as I wrote already "there should be
some kind of explanation why this service absolutely needs to be
enabled."

In a care that IPv6 can't be disabled in Fedora 10, as as previously
possible in Feodra 9, then IPv6 should be turned on by default.

Why do you only commend the "low hanging fruits" :) ie. services, what
are your comments regarding other services on the list?

Cheers,
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  Thu Oct  9 17:18:52 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 9 Oct 2008 13:18:52 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<20081009170418.GY3000@angus.ind.WPI.EDU>
	<64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
Message-ID: <20081009171852.GZ3000@angus.ind.WPI.EDU>

On Thu, Oct 09, 2008 at 07:08:29PM +0200, Valent Turkovic wrote:
> I know that no network I access has IPv6. No ADSL carrier in Croatia
> uses IPv6, my company doesn't use IPv6, and I in my home network I
> don't use IPv6.

That will not remain true for much longer.

Surprise.  Any network you access doesn't need to support IPv6 for 
link-local to work and expose your system to everyone else on the same 
link (subnet).  Any network you access won't need to support IPv6 for 
Teredo to work and expose your system to the entire internet at large, 
in spite of most NAT or network edge firewalls that are in place.

Besides, this isn't Valent Linux.  The defaults should be what is 
appropriate for the majority of Fedora users.  On by default firewalls 
that block all inbound network services are appropriate, as you 
suggested earlier.  That must include IPv6.



From seg at haxxed.com  Thu Oct  9 17:25:11 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 09 Oct 2008 12:25:11 -0500
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <48EDFE03.8020209@gmail.com>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<1223499686.26341.35.camel@localhost.localdomain>
	<1223520853.3564.1147.camel@beck.corsepiu.local>
	<48EDFE03.8020209@gmail.com>
Message-ID: <1223573111.26341.48.camel@localhost.localdomain>

On Thu, 2008-10-09 at 07:50 -0500, Les Mikesell wrote:
> The symlinks could even be a 
> separate package that people who didn't like the idea could remove. 
> They don't even need to depend on the target package - if the target 
> executable doesn't exist you aren't any worse off with the symlink than 
> without.  Nothing would have to be rebuilt.

Wouldn't work. You'd either have one package with a mess of dangling
symlinks, or you'd need a symlink package per main package which would
be as much or more work than just putting it in the main package to
begin with.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/ac474cc8/attachment.sig>

From sundaram at fedoraproject.org  Thu Oct  9 17:36:13 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 09 Oct 2008 23:06:13 +0530
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
Message-ID: <48EE410D.5040502@fedoraproject.org>

Valent Turkovic wrote:
> I also said that I'm a "above average desktop user" so you could also
> replace "I don't need" with "average desktop used doesn't need".

If you believe that any particular service is generally not useful for 
desktop users, then be specific about it. Avahi for example was in your 
list but is a very useful service for desktop users generally. There was 
a long discussion very recently on default services including sendmail 
as well. You might want to refer to that. No point in repeating it all 
over again.

> I believe that services should be regarded with the same attitude as
> open ports on a firewall. Some long time ago all ports were open and
> only "bad ones" were open, now all are closed and only explicitly ones
> are opened. Also all security and administration Rad Hat guides say
> that all unnecessary services should be turned off, and only turned on
> if explicitly needed.

You got to differentiate between services that listen to network 
connections like ssh from services like HAL which are local.

> That is why I believe that ALL services should be disabled, and then
> for each one there should be some kind of explanation why this service
> absolutely needs to be enabled. All the rest services should be left
> disabled by default.

This is pretty much what is followed already. If a service is enabled by 
default, it is usually there for a good reason.

Rahul



From jwboyer at gmail.com  Thu Oct  9 17:20:02 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 9 Oct 2008 13:20:02 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223569333.4410.104.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
Message-ID: <20081009172002.GB24582@yoda.jdub.homelinux.org>

On Thu, Oct 09, 2008 at 09:22:13AM -0700, Jesse Keating wrote:
>On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
>> On Thu October 9 2008, Jesse Keating wrote:
>> 
>> > Only if we allow source repo tags to be a suitable source distribution
>> > method.  Since fedorahosted still doesn't have an easy to use way of
>> > distributing tarballs, and getting the code via a scm checkout is quite
>> > easy, it should suffice.
>> 
>> If this is the only obstacle to get this done, I will write a patch for 
>> Makefile.common that displays the URL for every file in sources to fetch it 
>> from the lookaside cache. Then this URL can be provided as source tarball on 
>> a fedorahosted wiki page.
>
>Why must we insist on tarballs?  Unless the tarball includes scm
>metadata in it, it's practically useless for upstream patch development.

And why is upstream development being done from a Fedora SCM checkout?

josh



From valent.turkovic at gmail.com  Thu Oct  9 17:38:52 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 19:38:52 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <20081009171852.GZ3000@angus.ind.WPI.EDU>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<20081009170418.GY3000@angus.ind.WPI.EDU>
	<64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
	<20081009171852.GZ3000@angus.ind.WPI.EDU>
Message-ID: <64b14b300810091038p5d845e9t3e417e34b717feb4@mail.gmail.com>

On Thu, Oct 9, 2008 at 7:18 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On Thu, Oct 09, 2008 at 07:08:29PM +0200, Valent Turkovic wrote:
>> I know that no network I access has IPv6. No ADSL carrier in Croatia
>> uses IPv6, my company doesn't use IPv6, and I in my home network I
>> don't use IPv6.
>
> That will not remain true for much longer.
>
> Surprise.  Any network you access doesn't need to support IPv6 for
> link-local to work and expose your system to everyone else on the same
> link (subnet).  Any network you access won't need to support IPv6 for
> Teredo to work and expose your system to the entire internet at large,
> in spite of most NAT or network edge firewalls that are in place.
>
> Besides, this isn't Valent Linux.  The defaults should be what is
> appropriate for the majority of Fedora users.  On by default firewalls
> that block all inbound network services are appropriate, as you
> suggested earlier.  That must include IPv6.

Ok, I you proved your point and I acknowledged it already. I don't
know enough about ip6tables that is why I asked in the first place
that MORE experienced people say which of these services need to be
enabled and which not... so this service obviouls needs to be enabled
by default, what about other services?

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 notting at redhat.com  Thu Oct  9 18:03:19 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 9 Oct 2008 14:03:19 -0400
Subject: Arabic and Hebrew on the console
Message-ID: <20081009180319.GA25325@nostromo.devel.redhat.com>

We currently display Arabic and Hebrew translations on the virtual
console in LTR mode using the glyphs in latarcyrheb-sun16. Obviously,
that's not the preferred way.

Should we leave it this way, or do the same substitution to en_US that
we do for CJK locales?

Bill



From davej at redhat.com  Thu Oct  9 18:06:05 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 9 Oct 2008 14:06:05 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
Message-ID: <20081009180605.GB25049@redhat.com>

On Thu, Oct 09, 2008 at 06:05:59PM +0200, Valent Turkovic wrote:

 > kerneloops      0:off   1:off   2:off   3:on    4:on    5:on    6:off
 > 
 > advanced users could opt-in and turn on thi service if then need it, I
 > don't need it.

It's actually the non-advanced users that this is aimed at.
Having this enabled-by-default has caught a huge number of problems.
We see more Fedora kernel oopses reported at kerneloops.org than we
do in Fedora bugzilla.

	Dave

-- 
http://www.codemonkey.org.uk



From stlwrt at gmail.com  Thu Oct  9 18:07:52 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Thu, 9 Oct 2008 21:07:52 +0300
Subject: Possible to default to KDE?
In-Reply-To: <48ED6823.5000901@redhat.com>
References: <48ED6823.5000901@redhat.com>
Message-ID: <d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>

Put:

DISPLAYMANAGER=KDE

in  /etc/sysconfig/desktop, then select KDE session. KDM will remember
your choice when you log in next time
On Thu, Oct 9, 2008 at 5:10 AM, Warren Togami <wtogami at redhat.com> wrote:
> In Fedora 9 due to (some problems) it wasn't possible to set the system
> default desktop to KDE if you still had GNOME installed.
>
> Yes, I know you could do it at the per-user level with ~/.dmrc, but that
> requires it to already be set once for a new-user.
>
> Yes, I know you can easily do this if you switch away from gdm to kdm.
>
> Does Fedora 10 have a way to default the entire system to any other desktop
> (including new users) without uninstalling GNOME and without switching away
> from gdm?
>
> 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
>



-- 
http://scwlab.com



From valent.turkovic at gmail.com  Thu Oct  9 18:14:37 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 20:14:37 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <48EE410D.5040502@fedoraproject.org>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
Message-ID: <64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>

> This is pretty much what is followed already. If a service is enabled by
> default, it is usually there for a good reason.
>
> Rahul

I'm posting a revised list of services which maybe could be disabled
by default on Fedora Desktop Live CD, please correct me if I'm wrong.

anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off

Are schedulers needed for a Desktop system? When?

avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off

Needed only for print discovery? Ok this could maybe useful for some
people. I searched the places where avahi is discussed any only time
avahi is mentioned it is for network printer discovery. I haven't got
a clue how to use avahi and I manually configure all network printers
I use, but that is me :) So this service is could be useful in desktop
usage, so it should stay enabled.



fedora-late-live        0:off   1:off   2:off   3:on    4:on    5:on    6:off
fedora-live     0:off   1:off   2:off   3:on    4:on    5:on    6:off

I believe that these services could be disabled after Live CD is
installed, are there benefits for enabling these services?




irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off

This service should be disabled if system uses single core CPU,
otherwise it should be enabled.



kerneloops      0:off   1:off   2:off   3:on    4:on    5:on    6:off

Not sure why is this service needed :) So until somebody tells me what
is this benefit of this service to Desktop users it stays on the list
:) I didn't find almost no mention of this service on fedora-devel
list... strange...


mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off

If system isn't using lvm or raid this service should be disabled.



netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
nfslock         0:off   1:off   2:off   3:on    4:on    5:on    6:off

These service should be disabled, I don't see that Desktop users need NFS...


ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

Disabled by default, and if somebody needs it and know that it is used
for he can enable it.


portreserve     0:off   1:off   2:on    3:on    4:on    5:on    6:off
"The portreserve program aims to help services with well-known ports
that lie in the bindresvport() range (currently 600-1023). It prevents
programs requesting a port to the libc from occupying a real service's
port by occupying it itself, until the real service tells it to
release the port (generally in its init script)."

Not sure if this is needed for Desktop users...


rpcbind         0:off   1:off   2:on    3:on    4:on    5:on    6:off
rpcgssd         0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcidmapd       0:off   1:off   2:off   3:on    4:on    5:on    6:off

NFS is not used on Desktop, maybe on the servers, so what do you think
- could these services be disabled by default for Desktop systems?


sendmail        0:off   1:off   2:on    3:on    4:on    5:on    6:off

ok, this is useful if somebody is more advances user and looks for
logs and emails on his local system. I saw in earlier discussion that
somebody said that sendmail isn't installed anymore on Live CD - well
on Fedora 10 beta it is...
There was also a loooot of talk using/not using and about replacing
send mail with other (ssmtp) program. So I left it here but please
ignore it and don't comment it because in other discussions it was
said enough about sendmail :)


Cheers,
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  Thu Oct  9 18:16:40 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 9 Oct 2008 20:16:40 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <20081009180605.GB25049@redhat.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<20081009180605.GB25049@redhat.com>
Message-ID: <64b14b300810091116s69f08991r5c0ab34e41bd49ec@mail.gmail.com>

On Thu, Oct 9, 2008 at 8:06 PM, Dave Jones <davej at redhat.com> wrote:
> On Thu, Oct 09, 2008 at 06:05:59PM +0200, Valent Turkovic wrote:
>
>  > kerneloops      0:off   1:off   2:off   3:on    4:on    5:on    6:off
>  >
>  > advanced users could opt-in and turn on thi service if then need it, I
>  > don't need it.
>
> It's actually the non-advanced users that this is aimed at.
> Having this enabled-by-default has caught a huge number of problems.
> We see more Fedora kernel oopses reported at kerneloops.org than we
> do in Fedora bugzilla.
>
>        Dave

Ok, then scratch that one of the list.

What about other services? I posted an updated list, can you please
comment on it. 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 pemboa at gmail.com  Thu Oct  9 18:23:58 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 9 Oct 2008 13:23:58 -0500
Subject: Possible to default to KDE?
In-Reply-To: <d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>
References: <48ED6823.5000901@redhat.com>
	<d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>
Message-ID: <16de708d0810091123s44dbb79es96002d2be3e955f@mail.gmail.com>

On Thu, Oct 9, 2008 at 1:07 PM, Pavel Shevchuk <stlwrt at gmail.com> wrote:
> Put:
>
> DISPLAYMANAGER=KDE
>
> in  /etc/sysconfig/desktop, then select KDE session. KDM will remember
> your choice when you log in next time


Is editing  text file really the method we want to publicize as the
idea for switching (gui) desktop environment?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From michael at laptop.org  Thu Oct  9 17:11:44 2008
From: michael at laptop.org (Michael Stone)
Date: Thu, 9 Oct 2008 13:11:44 -0400
Subject: Tangent: recording upstream scm locations and contact info
In-Reply-To: <1223568584.4410.101.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
	<48ED8F5A.3030403@fedoraproject.org>
	<1223568584.4410.101.camel@luminos.localdomain>
Message-ID: <20081009171143.GB18785@didacte.laptop.org>

On Thu, Oct 09, 2008 at 09:09:44AM -0700, Jesse Keating wrote:
>On Thu, 2008-10-09 at 10:28 +0530, Rahul Sundaram wrote:
>> Insist that we use fedorahosted.org or other project hosting websites 
>> whenever we are upstream for a project? It certainly makes it easier for 
>> others to consume our bits when they don't have to crawl through source 
>> rpm packages. SRPM dumps are a horrible way to manage upstream source 
>> code anyway.
>
>Only if we allow source repo tags to be a suitable source distribution
>method.  Since fedorahosted still doesn't have an easy to use way of
>distributing tarballs, and getting the code via a scm checkout is quite
>easy, it should suffice.

On a tangential note, I'd _love_ it if specfiles started growing
metadata pointing back to upstream scm repos and development fora. This
is important to me because I have set myself a personal goal to make it
as easy as I can to go from OLPC's builds to patches delivered to
upstream developers; hence anything I can do which removes steps like
'find the upstream SCM' or 'find the upstream mailing list' from that
workflow is a Good Thing in my book.

Michael

P.S. - I'd definitely appreciate it if folks who are more knowledgable
about Fedora and RPM could suggest ways that I might pursue this goal
within the larger Fedora/RPM community.



From cmadams at hiwaay.net  Thu Oct  9 18:29:19 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 9 Oct 2008 13:29:19 -0500
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
Message-ID: <20081009182919.GC1302598@hiwaay.net>

Once upon a time, Valent Turkovic <valent.turkovic at gmail.com> said:
> anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
> atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> Are schedulers needed for a Desktop system? When?

Log rotation, /tmp cleanup, prelink, makewhatis, etc. all use cron (and
anacron picks up after people turn the system off when jobs were
supposed to run).  Also, just because it isn't a desktop doesn't mean
people don't want it to do things at certain times.

> irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> This service should be disabled if system uses single core CPU,
> otherwise it should be enabled.

It only runs when there is more than one CPU (core, HT, etc.).

> mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
> 
> If system isn't using lvm or raid this service should be disabled.

mdmonitor is for Linux software RAID only, not LVM, and it only runs
when software RAID is configured.

> netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
> nfslock         0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> These service should be disabled, I don't see that Desktop users need NFS...

Highly dependent on your environment (some places make great use of NFS
on the desktop).  This is the NFS client piece, not the server.  Some
home network storage appliances can be an NFS server to your desktops.

> ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
> 
> Disabled by default, and if somebody needs it and know that it is used
> for he can enable it.

It is configured in firstboot if you choose NTP.

> rpcbind         0:off   1:off   2:on    3:on    4:on    5:on    6:off
> rpcgssd         0:off   1:off   2:off   3:on    4:on    5:on    6:off
> rpcidmapd       0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> NFS is not used on Desktop, maybe on the servers, so what do you think
> - could these services be disabled by default for Desktop systems?

See above about NFS.

-- 
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 cra at WPI.EDU  Thu Oct  9 17:29:33 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 9 Oct 2008 13:29:33 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810091015r154bfee5k462322b5a643d0ab@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<20081009170418.GY3000@angus.ind.WPI.EDU>
	<64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
	<64b14b300810091015r154bfee5k462322b5a643d0ab@mail.gmail.com>
Message-ID: <20081009172933.GA3000@angus.ind.WPI.EDU>

On Thu, Oct 09, 2008 at 07:15:27PM +0200, Valent Turkovic wrote:
> "That is why I believe that ALL services should be disabled, and then
> for each one there should be some kind of explanation why this service
> absolutely needs to be enabled. All the rest services should be left
> disabled by default."

Ok, so that is why I'm pointing out the importance of ip6tables 
service.  The name "service" is really a misnomer, because all the 
"service" does is load a configuration file into the kernel.  Nothing 
remains running or listening to network sockets after ip6tables is 
done loading the firewall rules.

> Fedora 9 had an option during install where you choose to use or not
> to use IPv6, I don't see that option in Fedora 10, why? If there is an
> option I would like to disabel IPv6, and also IPv6 iptables. If there
> is no option to disable IPv6 then as I wrote already "there should be
> some kind of explanation why this service absolutely needs to be
> enabled."

Even if you disable IPv6 during the install of Fedora, it does NOT 
prevent the IPv6 network stack from loading into the kernel.  
Link-local will still work.  Stateless IPv6 Auto-Configuration for 
local and global connectivity will still work.  The only thing it does 
is prevent manual static addressing or DHCPv6 from being configured.

> In a care that IPv6 can't be disabled in Fedora 10, as as previously
> possible in Feodra 9, then IPv6 should be turned on by default.

Why don't we provide an option to disable IPv4 by default?  (Hint: 
that was a rhetorical question).  In any case, given the miniscule 
costs associated with keeping ip6tables enabled by default, I believe 
the benefits to protect against accidental exposure to other IPv6 
hosts is worth it, especially given how easy it is to unknowingly get 
IPv6 connectivity.

> Why do you only commend the "low hanging fruits" :) ie. services, what
> are your comments regarding other services on the list?

It is my self-appointed job to be vigilent about IPv6 :-)  I do care 
about the others on your list, but I'm sure others care enough about 
them to comment as well.



From notting at redhat.com  Thu Oct  9 18:34:14 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 9 Oct 2008 14:34:14 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <20081009182919.GC1302598@hiwaay.net>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
	<20081009182919.GC1302598@hiwaay.net>
Message-ID: <20081009183414.GA25698@nostromo.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> > mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
> > 
> > If system isn't using lvm or raid this service should be disabled.
> 
> mdmonitor is for Linux software RAID only, not LVM, and it only runs
> when software RAID is configured.

Right, but that's the sort of thing that could be disabled on the Live
image, and re-enabled once it's installed somewhere.

> > These service should be disabled, I don't see that Desktop users need NFS...
> 
> Highly dependent on your environment (some places make great use of NFS
> on the desktop).  This is the NFS client piece, not the server.  Some
> home network storage appliances can be an NFS server to your desktops.

This should really be started some other way. Not doable for F10, though.

Bill



From katzj at redhat.com  Thu Oct  9 18:59:00 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 09 Oct 2008 14:59:00 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <20081009183414.GA25698@nostromo.devel.redhat.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
	<20081009182919.GC1302598@hiwaay.net>
	<20081009183414.GA25698@nostromo.devel.redhat.com>
Message-ID: <1223578740.19673.172.camel@aglarond.local>

On Thu, 2008-10-09 at 14:34 -0400, Bill Nottingham wrote:
> Chris Adams (cmadams at hiwaay.net) said: 
> > > mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
> > > 
> > > If system isn't using lvm or raid this service should be disabled.
> > 
> > mdmonitor is for Linux software RAID only, not LVM, and it only runs
> > when software RAID is configured.
> 
> Right, but that's the sort of thing that could be disabled on the Live
> image, and re-enabled once it's installed somewhere.

It's easy enough to add to the list of things we temporarily turn off.
In fact, done as soon as I run git push.  Longer term, it'd be nice if
this were just done automatically based on the presence of RAID devs,
probably from udev

> > > These service should be disabled, I don't see that Desktop users need NFS...
> > 
> > Highly dependent on your environment (some places make great use of NFS
> > on the desktop).  This is the NFS client piece, not the server.  Some
> > home network storage appliances can be an NFS server to your desktops.
> 
> This should really be started some other way. Not doable for F10, though.

Indeed.  It'd be really nice if they would start on demand, but that's a
little tricky from what I discussed with steved a year or so ago

Jeremy



From cmadams at hiwaay.net  Thu Oct  9 19:01:42 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 9 Oct 2008 14:01:42 -0500
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <20081009183414.GA25698@nostromo.devel.redhat.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
	<20081009182919.GC1302598@hiwaay.net>
	<20081009183414.GA25698@nostromo.devel.redhat.com>
Message-ID: <20081009190142.GD1302598@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> Chris Adams (cmadams at hiwaay.net) said: 
> > > mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
> > > 
> > > If system isn't using lvm or raid this service should be disabled.
> > 
> > mdmonitor is for Linux software RAID only, not LVM, and it only runs
> > when software RAID is configured.
> 
> Right, but that's the sort of thing that could be disabled on the Live
> image, and re-enabled once it's installed somewhere.

How is that kind of thing (differences between LiveCD and
LiveCD-transferred-to-disk) handled?

> > > These service should be disabled, I don't see that Desktop users need NFS...
> > 
> > Highly dependent on your environment (some places make great use of NFS
> > on the desktop).  This is the NFS client piece, not the server.  Some
> > home network storage appliances can be an NFS server to your desktops.
> 
> This should really be started some other way. Not doable for F10, though.

It'd be good if mount could request NFS client services on demand.
Could that be pushed into mount.nfs?  I guess there'd have to be some
IPC for locking, since mount can try multiple NFS mounts in parallel,
and you don't want multiple attempts to start the services in parallel.
-- 
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 katzj at redhat.com  Thu Oct  9 19:01:51 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 09 Oct 2008 15:01:51 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <20081009190142.GD1302598@hiwaay.net>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
	<20081009182919.GC1302598@hiwaay.net>
	<20081009183414.GA25698@nostromo.devel.redhat.com>
	<20081009190142.GD1302598@hiwaay.net>
Message-ID: <1223578911.19673.173.camel@aglarond.local>

On Thu, 2008-10-09 at 14:01 -0500, Chris Adams wrote:
> Once upon a time, Bill Nottingham <notting at redhat.com> said:
> > Chris Adams (cmadams at hiwaay.net) said: 
> > > > mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
> > > > 
> > > > If system isn't using lvm or raid this service should be disabled.
> > > 
> > > mdmonitor is for Linux software RAID only, not LVM, and it only runs
> > > when software RAID is configured.
> > 
> > Right, but that's the sort of thing that could be disabled on the Live
> > image, and re-enabled once it's installed somewhere.
> 
> How is that kind of thing (differences between LiveCD and
> LiveCD-transferred-to-disk) handled?

The live initscript runs chkconfig for a few things (and runs very
early).  It's not reflected post-install as we copy over the pristine,
minimal ext3fs instead of the filesystem with changes

Jeremy



From cmadams at hiwaay.net  Thu Oct  9 19:06:25 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 9 Oct 2008 14:06:25 -0500
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <1223578740.19673.172.camel@aglarond.local>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
	<20081009182919.GC1302598@hiwaay.net>
	<20081009183414.GA25698@nostromo.devel.redhat.com>
	<1223578740.19673.172.camel@aglarond.local>
Message-ID: <20081009190625.GE1302598@hiwaay.net>

Once upon a time, Jeremy Katz <katzj at redhat.com> said:
> It's easy enough to add to the list of things we temporarily turn off.
> In fact, done as soon as I run git push.  Longer term, it'd be nice if
> this were just done automatically based on the presence of RAID devs,
> probably from udev

Like I said, mdmonitor only actually starts something if mdadm.conf
exists and has configuration in it.  All you save by disabling it (when
RAID isn't configured) is a shell script and "[ -f /etc/mdadm.conf ]";
that shouldn't take any significant amount of time, even on a CD (since
by then /bin/sh, /etc/rc.d/init.d/functions, and /etc should all be in
the kernel cache).

There used to be a bunch of things that started unconditionally, but
much of that has changed to only actually start a service when there was
something to be done.
-- 
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 cmadams at hiwaay.net  Thu Oct  9 19:09:06 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 9 Oct 2008 14:09:06 -0500
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <1223578911.19673.173.camel@aglarond.local>
References: <3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
	<20081009182919.GC1302598@hiwaay.net>
	<20081009183414.GA25698@nostromo.devel.redhat.com>
	<20081009190142.GD1302598@hiwaay.net>
	<1223578911.19673.173.camel@aglarond.local>
Message-ID: <20081009190906.GF1302598@hiwaay.net>

Once upon a time, Jeremy Katz <katzj at redhat.com> said:
> The live initscript runs chkconfig for a few things (and runs very
> early).  It's not reflected post-install as we copy over the pristine,
> minimal ext3fs instead of the filesystem with changes

Ah, that's why I didn't see it; the raw image on the CD has things
enabled like they'd be if you do a disk install.  Thanks.

-- 
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 rdieter at math.unl.edu  Thu Oct  9 18:54:08 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 09 Oct 2008 13:54:08 -0500
Subject: Possible to default to KDE?
References: <48ED6823.5000901@redhat.com>
	<d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>
	<16de708d0810091123s44dbb79es96002d2be3e955f@mail.gmail.com>
Message-ID: <gclk0g$5bm$1@ger.gmane.org>

Arthur Pemberton wrote:

> On Thu, Oct 9, 2008 at 1:07 PM, Pavel Shevchuk <stlwrt at gmail.com> wrote:
>> Put:
>>
>> DISPLAYMANAGER=KDE
>>
>> in  /etc/sysconfig/desktop, then select KDE session. KDM will remember
>> your choice when you log in next time
> 
> 
> Is editing  text file really the method we want to publicize as the
> idea for switching (gui) desktop environment?

This is about setting a default DE.

For F10, as I understand it, comps changes were made so that if only KDE is
selected to be installed, it should end up as the default using kdm (gdm
won't get installed).  This should give most people what they expect.

-- Rex




From cra at WPI.EDU  Thu Oct  9 18:57:00 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 9 Oct 2008 14:57:00 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
Message-ID: <20081009185700.GD3000@angus.ind.WPI.EDU>

On Thu, Oct 09, 2008 at 08:14:37PM +0200, Valent Turkovic wrote:
> > This is pretty much what is followed already. If a service is enabled by
> > default, it is usually there for a good reason.
> >
> > Rahul
> 
> I'm posting a revised list of services which maybe could be disabled
> by default on Fedora Desktop Live CD, please correct me if I'm wrong.
> 
> anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
> atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> Are schedulers needed for a Desktop system? When?

If you don't have cron/anacron, things like log files and other 
temporary files will overflow and fill up the disk since they won't be 
cleaned up/rotated automatically anymore.  Smolt won't send client 
checkins to the server anymore.  The manual page index won't be 
updated.  The updatedb database won't be updated, so "locate foo" 
won't work.  Binaries won't get prelinked, removing a security feature 
and potentially exposing systems to vulnerabilities.  

Other software that drops files in /etc/cron.*/ expecting it to get 
executed at regular intervals won't work anymore without manual 
intervention.

> avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> Needed only for print discovery? Ok this could maybe useful for some
> people. I searched the places where avahi is discussed any only time
> avahi is mentioned it is for network printer discovery. I haven't got
> a clue how to use avahi and I manually configure all network printers
> I use, but that is me :) So this service is could be useful in desktop
> usage, so it should stay enabled.

Actually, avahi is for all sorts of automatic discovery of services 
available on the local network.  Printing is just the one most often 
used I would guess.  Its great when I visit friends and their printer 
just shows up automatically on my Fedora laptop... I think iTunes 
shares also use this mechanism show they show up automatically in e.g. 
rhythmbox.

> irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> This service should be disabled if system uses single core CPU,
> otherwise it should be enabled.

I would argue that its getting harder to find single-core systems 
these days, and again a cost/benefit anaylsis would show that it isn't 
worth the cost to figure out automatically whether to enable or 
disable this based on the CPU the system is currently booted on, 
because by the time you figure it out, you've wasted more time than it 
would take to just start it always.

> mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
> 
> If system isn't using lvm or raid this service should be disabled.

Perhaps.

> netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
> nfslock         0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> These service should be disabled, I don't see that Desktop users need NFS...

Perhaps.  NFS is a dinosaur anyway.  I avoid it even for servers, 
preferring to use CIFS instead.

> ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
> 
> Disabled by default, and if somebody needs it and know that it is used
> for he can enable it.

Time synchronization is important.  It should just work out of the box 
without requiring a user to know about it and enable it.  I vote to 
keep ntpd on by default.

> portreserve     0:off   1:off   2:on    3:on    4:on    5:on    6:off
> "The portreserve program aims to help services with well-known ports
> that lie in the bindresvport() range (currently 600-1023). It prevents
> programs requesting a port to the libc from occupying a real service's
> port by occupying it itself, until the real service tells it to
> release the port (generally in its init script)."
> 
> Not sure if this is needed for Desktop users...
> 
> 
> rpcbind         0:off   1:off   2:on    3:on    4:on    5:on    6:off
> rpcgssd         0:off   1:off   2:off   3:on    4:on    5:on    6:off
> rpcidmapd       0:off   1:off   2:off   3:on    4:on    5:on    6:off
> 
> NFS is not used on Desktop, maybe on the servers, so what do you think
> - could these services be disabled by default for Desktop systems?

I agree that rpcbind, rpcgssd, rpcidmapd etc. should be disabled by 
default for Desktop users.  I think the only thing that Desktop users 
might need rpcbind for is if they authenticate to a NIS/yp directory, 
in which case they might need it and ypbind.

Lots of your suggestions require logic--a decision to be made at 
install or firstboot time on which services should be enabled/disabled 
by default based on other information.  Perhaps a firstboot module 
could be developed to implement this.



From opensource at till.name  Thu Oct  9 20:03:34 2008
From: opensource at till.name (Till Maas)
Date: Thu, 09 Oct 2008 22:03:34 +0200
Subject: Tangent: recording upstream scm locations and contact info
In-Reply-To: <20081009171143.GB18785@didacte.laptop.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223568584.4410.101.camel@luminos.localdomain>
	<20081009171143.GB18785@didacte.laptop.org>
Message-ID: <200810092203.39432.opensource@till.name>

On Thu October 9 2008, Michael Stone wrote:

> On a tangential note, I'd _love_ it if specfiles started growing
> metadata pointing back to upstream scm repos and development fora. This

> P.S. - I'd definitely appreciate it if folks who are more knowledgable
> about Fedora and RPM could suggest ways that I might pursue this goal
> within the larger Fedora/RPM community.

Why do you want it in the specfile? Imho it would fit better within the 
packagedb. There it should be also easier to add it, given that packagedb 
upstream accepts patches for this.

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/20081009/65bce4d6/attachment.sig>

From tcallawa at redhat.com  Thu Oct  9 20:08:37 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 09 Oct 2008 16:08:37 -0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <20081009180319.GA25325@nostromo.devel.redhat.com>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
Message-ID: <1223582917.20118.11.camel@localhost.localdomain>

On Thu, 2008-10-09 at 14:03 -0400, Bill Nottingham wrote:
> We currently display Arabic and Hebrew translations on the virtual
> console in LTR mode using the glyphs in latarcyrheb-sun16. Obviously,
> that's not the preferred way.
> 
> Should we leave it this way, or do the same substitution to en_US that
> we do for CJK locales?

Not being a Arabic or Hebrew reader, what are the tradeoffs between the
two approaches?

~spot



From alsadi at gmail.com  Thu Oct  9 20:16:10 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 9 Oct 2008 23:16:10 +0300
Subject: Arabic and Hebrew on the console
In-Reply-To: <1223582917.20118.11.camel@localhost.localdomain>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<1223582917.20118.11.camel@localhost.localdomain>
Message-ID: <385866f0810091316j7a6f715vef760293a6715d02@mail.gmail.com>

As a native Arabic speaker I'll tell you
if you keep it the way it's now an Arabic user will see translated
messages from initscripts mirrored to left (imagine your self reading
"Hello, World!" spelled backword)

if you move it to use LANG=en_US.UTF-8 when on vt this will disable
Arabic translated messages and that's very reasonable

I suggested to add rm po/ar.po to %prep of initscripts
but notting's solution is much smarter and it's better

(till some mature functional bidirectional support is introduced to the vt)



From opensource at till.name  Thu Oct  9 20:17:46 2008
From: opensource at till.name (Till Maas)
Date: Thu, 09 Oct 2008 22:17:46 +0200
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <48EE1834.4020405@city-fan.org>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<48EE1834.4020405@city-fan.org>
Message-ID: <200810092218.02425.opensource@till.name>

On Thu October 9 2008, Paul Howarth wrote:

> CUPS can autodetect network printers, which desktop users would no doubt
> find useful, even though there may be no local printing hardware.

Cups printer autodetection seems to work fast enough, that it could be enabled 
on demand, e.g. when kprinter is opened. I have cups always deactivated and 
when I need to print something, I start it and the kprinter instance I start 
directly after this, shows the network printers, that are found via cups 
browsing. But I guess there is no infrastructure there yet, to get cups 
started on demand.

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/20081009/60ffe7e3/attachment.sig>

From jeff at ocjtech.us  Thu Oct  9 20:21:13 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Thu, 9 Oct 2008 15:21:13 -0500
Subject: Tangent: recording upstream scm locations and contact info
In-Reply-To: <200810092203.39432.opensource@till.name>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223568584.4410.101.camel@luminos.localdomain>
	<20081009171143.GB18785@didacte.laptop.org>
	<200810092203.39432.opensource@till.name>
Message-ID: <935ead450810091321y40241be1o918802e91fed6e6e@mail.gmail.com>

2008/10/9 Till Maas <opensource at till.name>:
> On Thu October 9 2008, Michael Stone wrote:
>
>> On a tangential note, I'd _love_ it if specfiles started growing
>> metadata pointing back to upstream scm repos and development fora. This
>
>> P.S. - I'd definitely appreciate it if folks who are more knowledgable
>> about Fedora and RPM could suggest ways that I might pursue this goal
>> within the larger Fedora/RPM community.
>
> Why do you want it in the specfile? Imho it would fit better within the
> packagedb. There it should be also easier to add it, given that packagedb
> upstream accepts patches for this.

Actually, it'd be even better if this was in the RPM headers and would
show up in a "rpm -qi".

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From katzj at redhat.com  Thu Oct  9 20:21:22 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 09 Oct 2008 16:21:22 -0400
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <200810092218.02425.opensource@till.name>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<48EE1834.4020405@city-fan.org>
	<200810092218.02425.opensource@till.name>
Message-ID: <1223583682.19673.174.camel@aglarond.local>

On Thu, 2008-10-09 at 22:17 +0200, Till Maas wrote:
> On Thu October 9 2008, Paul Howarth wrote:
> > CUPS can autodetect network printers, which desktop users would no doubt
> > find useful, even though there may be no local printing hardware.
> 
> Cups printer autodetection seems to work fast enough, that it could be enabled 
> on demand, e.g. when kprinter is opened. I have cups always deactivated and 
> when I need to print something, I start it and the kprinter instance I start 
> directly after this, shows the network printers, that are found via cups 
> browsing. But I guess there is no infrastructure there yet, to get cups 
> started on demand.

There's some support in cups for it, but it's all tied to launchd for
OS/X.  It would definitely be nice to have someone work on making this
work for other environments

Jeremy



From opensource at till.name  Thu Oct  9 20:26:48 2008
From: opensource at till.name (Till Maas)
Date: Thu, 09 Oct 2008 22:26:48 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223569333.4410.104.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
Message-ID: <200810092226.50011.opensource@till.name>

On Thu October 9 2008, Jesse Keating wrote:
> On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > On Thu October 9 2008, Jesse Keating wrote:
> > > Only if we allow source repo tags to be a suitable source distribution
> > > method.  Since fedorahosted still doesn't have an easy to use way of
> > > distributing tarballs, and getting the code via a scm checkout is quite
> > > easy, it should suffice.
> >
> > If this is the only obstacle to get this done, I will write a patch for
> > Makefile.common that displays the URL for every file in sources to fetch
> > it from the lookaside cache. Then this URL can be provided as source
> > tarball on a fedorahosted wiki page.
>
> Why must we insist on tarballs?  Unless the tarball includes scm
> metadata in it, it's practically useless for upstream patch development.

Tarballs allow to easily build the desired software via rpm and test it. With 
make patch and make rediff and make prep from Makefile.common it is also 
pretty easy to create and update patches. I have sucessfully created patches 
for upstream using this. Using directly an upstream scm, it is always a PITA 
to make the spec build from there, because the spec needs to be heavily 
modificated or I have to remember to recreate the tarball everytime. It would 
like it very much, if this would be a lot easier, e.g. some intelligent 
macros in spec files that allow to use a scm instead of a tarball to be used 
as Source0 and some magic that allows to define what from the scm should be 
used, e.g. should uncommited changes be used?

Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore 
it is not much work to link to them. Therefore I do not really see what needs 
to be discussed 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/20081009/af9e5ab7/attachment.sig>

From tcallawa at redhat.com  Thu Oct  9 20:29:34 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 09 Oct 2008 16:29:34 -0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <385866f0810091316j7a6f715vef760293a6715d02@mail.gmail.com>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<1223582917.20118.11.camel@localhost.localdomain>
	<385866f0810091316j7a6f715vef760293a6715d02@mail.gmail.com>
Message-ID: <1223584175.20118.22.camel@localhost.localdomain>

On Thu, 2008-10-09 at 23:16 +0300, Muayyad AlSadi wrote:
> As a native Arabic speaker I'll tell you
> if you keep it the way it's now an Arabic user will see translated
> messages from initscripts mirrored to left (imagine your self reading
> "Hello, World!" spelled backword)
> 
> if you move it to use LANG=en_US.UTF-8 when on vt this will disable
> Arabic translated messages and that's very reasonable
> 
> I suggested to add rm po/ar.po to %prep of initscripts
> but notting's solution is much smarter and it's better

Alright, so, I'd defer to what you think is best, as you will be
affected by it, and I will not. :)

~spot



From jkeating at redhat.com  Thu Oct  9 20:37:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 09 Oct 2008 13:37:14 -0700
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <200810092226.50011.opensource@till.name>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
	<200810092226.50011.opensource@till.name>
Message-ID: <1223584634.4410.130.camel@luminos.localdomain>

On Thu, 2008-10-09 at 22:26 +0200, Till Maas wrote:
> On Thu October 9 2008, Jesse Keating wrote:
> > On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > > On Thu October 9 2008, Jesse Keating wrote:
> > > > Only if we allow source repo tags to be a suitable source distribution
> > > > method.  Since fedorahosted still doesn't have an easy to use way of
> > > > distributing tarballs, and getting the code via a scm checkout is quite
> > > > easy, it should suffice.
> > >
> > > If this is the only obstacle to get this done, I will write a patch for
> > > Makefile.common that displays the URL for every file in sources to fetch
> > > it from the lookaside cache. Then this URL can be provided as source
> > > tarball on a fedorahosted wiki page.
> >
> > Why must we insist on tarballs?  Unless the tarball includes scm
> > metadata in it, it's practically useless for upstream patch development.
> 
> Tarballs allow to easily build the desired software via rpm and test it. With 
> make patch and make rediff and make prep from Makefile.common it is also 
> pretty easy to create and update patches. I have sucessfully created patches 
> for upstream using this. Using directly an upstream scm, it is always a PITA 
> to make the spec build from there, because the spec needs to be heavily 
> modificated or I have to remember to recreate the tarball everytime. It would 
> like it very much, if this would be a lot easier, e.g. some intelligent 
> macros in spec files that allow to use a scm instead of a tarball to be used 
> as Source0 and some magic that allows to define what from the scm should be 
> used, e.g. should uncommited changes be used?
> 
> Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore 
> it is not much work to link to them. Therefore I do not really see what needs 
> to be discussed here. ;-)

I'm trying to see things from somebody else's point of view.  Recently,
on this list, somebody else was arguing that we in Fedora land should be
doing away with tarball distribution, and srpm distribution, and instead
direct everything back to SCM, and to work on RPM so that it just
understood SCM and left tarballs in the past.  Thank you for providing
some argument against that (:

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/675d0865/attachment.sig>

From alsadi at gmail.com  Thu Oct  9 20:37:40 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 9 Oct 2008 23:37:40 +0300
Subject: Arabic and Hebrew on the console
In-Reply-To: <1223584175.20118.22.camel@localhost.localdomain>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<1223582917.20118.11.camel@localhost.localdomain>
	<385866f0810091316j7a6f715vef760293a6715d02@mail.gmail.com>
	<1223584175.20118.22.camel@localhost.localdomain>
Message-ID: <385866f0810091337y54d062b2vae06471a294c1e18@mail.gmail.com>

I would love to test it,
would you send me the patch, or should I made one and send it to you
(I know it's too trivial, but just asking to have a unified one)



From walters at verbum.org  Thu Oct  9 20:45:43 2008
From: walters at verbum.org (Colin Walters)
Date: Thu, 9 Oct 2008 16:45:43 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223584634.4410.130.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
	<200810092226.50011.opensource@till.name>
	<1223584634.4410.130.camel@luminos.localdomain>
Message-ID: <faa16b610810091345m7983a6eqd09a6327fbeb0381@mail.gmail.com>

2008/10/9 Jesse Keating <jkeating at redhat.com>:
>
> I'm trying to see things from somebody else's point of view.  Recently,
> on this list, somebody else was arguing that we in Fedora land should be
> doing away with tarball distribution, and srpm distribution, and instead
> direct everything back to SCM, and to work on RPM so that it just
> understood SCM and left tarballs in the past.  Thank you for providing
> some argument against that (:

I don't think it was an argument against it - just that we need to
figure out what the patch workflow is.  The fundamental question there
is - do we expose the upstream version control system, or do we say
map everything into git?  Personally I lean towards the latter.

To those who think "wow, running a git mirror of everything would be
expensive", the current lookaside system ends up being the world's
worst revision control system in the long term.  Putting one copy of
OpenOffice.tar.gz in the lookaside is certainly cheaper than mirroring
OpenOffice CVS into git for a few tarballs, git is going to be far
cheaper once you have N new releases of openoffice tarballs in the
lookaside.  I don't know what N is for OpenOffice, but I bet it's less
than 20-30.



From wtogami at redhat.com  Thu Oct  9 20:46:19 2008
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 09 Oct 2008 16:46:19 -0400
Subject: Possible to default to KDE?
In-Reply-To: <gclk0g$5bm$1@ger.gmane.org>
References: <48ED6823.5000901@redhat.com>	<d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>	<16de708d0810091123s44dbb79es96002d2be3e955f@mail.gmail.com>
	<gclk0g$5bm$1@ger.gmane.org>
Message-ID: <48EE6D9B.90305@redhat.com>

Rex Dieter wrote:
> 
> This is about setting a default DE.
> 
> For F10, as I understand it, comps changes were made so that if only KDE is
> selected to be installed, it should end up as the default using kdm (gdm
> won't get installed).  This should give most people what they expect.
> 

This isn't the point I was trying to make.  I was only suggesting that 
if you want to stick to gdm, it is impossible to make any other desktop 
default on the system if you keep GNOME installed.  I was only hoping 
this would be fixed for Fedora 10 so people do not need to rip out gdm.

Warren Togami
wtogami at redhat.com



From notting at redhat.com  Thu Oct  9 20:56:49 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 9 Oct 2008 16:56:49 -0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <bf9c195a0810091349u78ca260cx5ce79b86d18e069e@mail.gmail.com>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<bf9c195a0810091349u78ca260cx5ce79b86d18e069e@mail.gmail.com>
Message-ID: <20081009205649.GA27421@nostromo.devel.redhat.com>

Milo? Komar?evi? (kmilos at gmail.com) said: 
> On Thu, Oct 9, 2008 at 7:03 PM, Bill Nottingham <notting at redhat.com> wrote:
> > We currently display Arabic and Hebrew translations on the virtual
> > console in LTR mode using the glyphs in latarcyrheb-sun16. Obviously,
> > that's not the preferred way.
> >
> > Should we leave it this way, or do the same substitution to en_US that
> > we do for CJK locales?
> 
> I have noticed some problems with Cyrillic (Serbian) as well (and same
> with non-ASCII characters in Serbian Latin) - this is still LTR, but
> comes out garbled.
> 
> Same issue, or a separate one I need to report in BZ?

No, that would be a separate issue. Although it's probably related to
bug 458362.

Bill



From berrange at redhat.com  Thu Oct  9 20:57:24 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 9 Oct 2008 21:57:24 +0100
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223584634.4410.130.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
	<200810092226.50011.opensource@till.name>
	<1223584634.4410.130.camel@luminos.localdomain>
Message-ID: <20081009205724.GP2941@redhat.com>

On Thu, Oct 09, 2008 at 01:37:14PM -0700, Jesse Keating wrote:
> On Thu, 2008-10-09 at 22:26 +0200, Till Maas wrote:
> > On Thu October 9 2008, Jesse Keating wrote:
> > > On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > > > On Thu October 9 2008, Jesse Keating wrote:
> > > > > Only if we allow source repo tags to be a suitable source distribution
> > > > > method.  Since fedorahosted still doesn't have an easy to use way of
> > > > > distributing tarballs, and getting the code via a scm checkout is quite
> > > > > easy, it should suffice.
> > > >
> > > > If this is the only obstacle to get this done, I will write a patch for
> > > > Makefile.common that displays the URL for every file in sources to fetch
> > > > it from the lookaside cache. Then this URL can be provided as source
> > > > tarball on a fedorahosted wiki page.
> > >
> > > Why must we insist on tarballs?  Unless the tarball includes scm
> > > metadata in it, it's practically useless for upstream patch development.
> > 
> > Tarballs allow to easily build the desired software via rpm and test it. With 
> > make patch and make rediff and make prep from Makefile.common it is also 
> > pretty easy to create and update patches. I have sucessfully created patches 
> > for upstream using this. Using directly an upstream scm, it is always a PITA 
> > to make the spec build from there, because the spec needs to be heavily 
> > modificated or I have to remember to recreate the tarball everytime. It would 
> > like it very much, if this would be a lot easier, e.g. some intelligent 
> > macros in spec files that allow to use a scm instead of a tarball to be used 
> > as Source0 and some magic that allows to define what from the scm should be 
> > used, e.g. should uncommited changes be used?
> > 
> > Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore 
> > it is not much work to link to them. Therefore I do not really see what needs 
> > to be discussed here. ;-)
> 
> I'm trying to see things from somebody else's point of view.  Recently,
> on this list, somebody else was arguing that we in Fedora land should be
> doing away with tarball distribution, and srpm distribution, and instead
> direct everything back to SCM, and to work on RPM so that it just
> understood SCM and left tarballs in the past.  Thank you for providing
> some argument against that (:

I like the tar.gz from a release tracking point of view - with pretty
much every distro, whether Linux, or BSD or Windows using pristine
tar.gz + patches, you can write some interesting tools to correlate
packages & patches across distros. I'm working on a toy/tool which 
would record the md5sum of every source & patch file from every 
released RPM in  Fedora, RHEL, Ubuntu, Debian, etc. It will also 
import checksums of official releases from major hosting sites like 
CPAN, gnome.org,  sourceforge etc. You can then correlate all the 
md5sums to track the relations between packages in different distros
vs upstream, even if the package naming is completely different. This
lets you answer questions like

 - What distros have at least version x.y.z 
 - When did version x.y.z appear in a distro
 - What packages are in distro A but not B
 - Is distro X out of date compared to latest upstream release
 - As a maintainer in distro A, what patches are other distros
   carrying against my packages
 - As an upstream maintainer, what patches are distros applying
   to my code.
 - As an app developer, if I have a choice between libraries A & B, 
   which is the most widely available in distros.
 - What source files claim to be version x.y.z, but don't match
   the x.y.z published by upstream (there's a number of surprises
   in this area, but in Fedora & CPAN itself :-)

There's probably more you can do, but those were the questions that 
motivated me to try and hack some cross-distro data corrrelation tool
together. Even if it doesn't turn into anything serious, its nice that
you can experiment with these kind of things. I fear it'd be harder to
do this kind of thing if everyone just bundled SCM repos in their distros
as source, as you'd need to actually get the source - currnetly I can 
just get the checksums from the 'sources' file in CVS without downloading
everything from the lookaside cache, likewise many hosting sites publish
the md5 sums separately from the sources. Then again maybe having the
full SCM repos would let you do some even more interesting correlation.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From alsadi at gmail.com  Thu Oct  9 20:33:12 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 9 Oct 2008 23:33:12 +0300
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <1223583682.19673.174.camel@aglarond.local>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<48EE1834.4020405@city-fan.org>
	<200810092218.02425.opensource@till.name>
	<1223583682.19673.174.camel@aglarond.local>
Message-ID: <385866f0810091333q495dba7dy773c511abd43f26e@mail.gmail.com>

regarding *cron* and alike scheduled tasks

they are useless on the CD and they are offensive for a USB or SD-memory

and I think they are disabled in the .ks of fedora unity



From opensource at till.name  Thu Oct  9 21:05:48 2008
From: opensource at till.name (Till Maas)
Date: Thu, 09 Oct 2008 23:05:48 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223584634.4410.130.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<200810092226.50011.opensource@till.name>
	<1223584634.4410.130.camel@luminos.localdomain>
Message-ID: <200810092306.03036.opensource@till.name>

On Thu October 9 2008, Jesse Keating wrote:

> I'm trying to see things from somebody else's point of view.  Recently,
> on this list, somebody else was arguing that we in Fedora land should be
> doing away with tarball distribution, and srpm distribution, and instead
> direct everything back to SCM, and to work on RPM so that it just
> understood SCM and left tarballs in the past.  Thank you for providing
> some argument against that (:

I do not see how I argued against this, because I also wrote that it would be 
helpful if one could rpm in combination SCMs efficently.

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/20081009/17052f51/attachment.sig>

From opensource at till.name  Thu Oct  9 21:12:08 2008
From: opensource at till.name (Till Maas)
Date: Thu, 09 Oct 2008 23:12:08 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081009205724.GP2941@redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223584634.4410.130.camel@luminos.localdomain>
	<20081009205724.GP2941@redhat.com>
Message-ID: <200810092312.10054.opensource@till.name>

On Thu October 9 2008, Daniel P. Berrange wrote:

> packages & patches across distros. I'm working on a toy/tool which
> would record the md5sum of every source & patch file from every
> released RPM in  Fedora, RHEL, Ubuntu, Debian, etc. It will also
> import checksums of official releases from major hosting sites like
> CPAN, gnome.org,  sourceforge etc. You can then correlate all the
> md5sums to track the relations between packages in different distros
> vs upstream, even if the package naming is completely different. This
> lets you answer questions like

This is great, I always planned to write a similiar application, but my desire 
was not big enough, that I found the time. But I also wanted to track the 
contents of the packages to make it easier to spot files on a system, that 
are not well known, e.g. malware. But I guess once your application is in a 
usable state, it can be easily added. :-)

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/20081009/e015bb1a/attachment.sig>

From dbn.lists at gmail.com  Thu Oct  9 21:55:25 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 9 Oct 2008 14:55:25 -0700
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <1223583682.19673.174.camel@aglarond.local>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<48EE1834.4020405@city-fan.org>
	<200810092218.02425.opensource@till.name>
	<1223583682.19673.174.camel@aglarond.local>
Message-ID: <91705d080810091455h371e066ew7e7b6b2ffd6be2f9@mail.gmail.com>

On Thu, Oct 9, 2008 at 1:21 PM, Jeremy Katz <katzj at redhat.com> wrote:
> On Thu, 2008-10-09 at 22:17 +0200, Till Maas wrote:
>> On Thu October 9 2008, Paul Howarth wrote:
>> > CUPS can autodetect network printers, which desktop users would no doubt
>> > find useful, even though there may be no local printing hardware.
>>
>> Cups printer autodetection seems to work fast enough, that it could be enabled
>> on demand, e.g. when kprinter is opened. I have cups always deactivated and
>> when I need to print something, I start it and the kprinter instance I start
>> directly after this, shows the network printers, that are found via cups
>> browsing. But I guess there is no infrastructure there yet, to get cups
>> started on demand.
>
> There's some support in cups for it, but it's all tied to launchd for
> OS/X.  It would definitely be nice to have someone work on making this
> work for other environments

Since cups already has a dbus interface, wouldn't it work to do this:

cat > /usr/share/dbus-1/system-services/com.redhat.PrinterSpooler.service
<< "EOF"
Name=com.redhat.PrinterSpooler
Exec=/usr/sbin/cupsd
User=root
EOF

I haven't tested that, but I think it should work for dbus using cups clients.

--
Dan



From mcepl at redhat.com  Thu Oct  9 21:54:55 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 09 Oct 2008 23:54:55 +0200
Subject: Fedora 10 Live CD services (all necessary?)
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<48EE410D.5040502@fedoraproject.org>
	<64b14b300810091114ta821ca1h8cb7fe2354c414ba@mail.gmail.com>
Message-ID: <f6b2s5x1go.ln2@ppp1053.in.ipex.cz>

On 2008-10-09, 18:14 GMT, Valent Turkovic wrote:
> I'm posting a revised list of services which maybe could be 
> disabled
> by default on Fedora Desktop Live CD, please correct me if I'm wrong.
>
> anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
> atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
>
> Are schedulers needed for a Desktop system? When?

ls /etc/cron.*

would tell you.

Mat?j



From mcepl at redhat.com  Thu Oct  9 22:06:09 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 10 Oct 2008 00:06:09 +0200
Subject: Taking fedora-devel into consideration [Was: Re: tab completion
 less useful now, due to sbin in path]
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<48EB03C6.9080300@leemhuis.info> <mpfur5xrg8.ln2@ppp1053.in.ipex.cz>
	<20081008133115.0c164ef8@ohm.scrye.com>
	<48EDFDF8.4080406@leemhuis.info>
	<p2k1s5x8qj.ln2@ppp1053.in.ipex.cz> <48EE2ECE.20006@leemhuis.info>
Message-ID: <hrb2s5x1go.ln2@ppp1053.in.ipex.cz>

On 2008-10-09, 16:18 GMT, Thorsten Leemhuis wrote:
> But whatever. That is history now and not that much relevant 
> anymore. It just shows how humans sometimes are; that is not 
> specific to FESCo.

Yeah, this could lead into the endless totally fruitless 
flamewar, so I would rather stop here.

Thanks for explanation,

Mat?j



From seg at haxxed.com  Thu Oct  9 22:18:01 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 09 Oct 2008 17:18:01 -0500
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <1223583682.19673.174.camel@aglarond.local>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<48EE1834.4020405@city-fan.org>
	<200810092218.02425.opensource@till.name>
	<1223583682.19673.174.camel@aglarond.local>
Message-ID: <1223590681.26341.58.camel@localhost.localdomain>

On Thu, 2008-10-09 at 16:21 -0400, Jeremy Katz wrote:
> On Thu, 2008-10-09 at 22:17 +0200, Till Maas wrote:
> > Cups printer autodetection seems to work fast enough, that it could be enabled 
> > on demand, e.g. when kprinter is opened. I have cups always deactivated and 
> > when I need to print something, I start it and the kprinter instance I start 
> > directly after this, shows the network printers, that are found via cups 
> > browsing. But I guess there is no infrastructure there yet, to get cups 
> > started on demand.
> 
> There's some support in cups for it, but it's all tied to launchd for
> OS/X.  It would definitely be nice to have someone work on making this
> work for other environments

Will it auto-terminate too? It annoys me greatly that, even though I
only very rarely print to a LaserJet with a JetDirect card, I have to
have a demon running all the time. I don't need to share the printer, it
does that just fine by itself.

It's also obnoxious and redundant that every machine on my LAN seems to
insist on offering the *same* printer to every other machine no matter
how much I try and tell it not to...

(Is it possible to get a JetDirect card to do the CUPS browsing thing?
Its one of the newer ones that do IPP natively, but as of the last time
I flash upgraded it, it showed no sign of support for browsing...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/ce0a5021/attachment.sig>

From behdad at behdad.org  Thu Oct  9 22:22:51 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 09 Oct 2008 18:22:51 -0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <20081009180319.GA25325@nostromo.devel.redhat.com>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
Message-ID: <48EE843B.20009@behdad.org>

Bill Nottingham wrote:
> We currently display Arabic and Hebrew translations on the virtual
> console in LTR mode using the glyphs in latarcyrheb-sun16. Obviously,
> that's not the preferred way.

Yeah, it's pretty unusable.  For ebrew it's just mirrored.  For Arabic it also
lacks shaping.  I have solutions for them if we really want to fix them, but
the solution needs:

  1) Switch to a new font for Arabic as a full Arabic font needs over a
hundred glyphs.  I have a good font for it, in the BiCon package mentioned below,

  2) Needs to run a filter on top of the console.  That can easily be done in
rc.  The code for it is mostly available already, in a package called BiCon.
Search for "BiCon Arabeyes".  Though I need to rewrite some parts of it to use
the new features in fribidi2.  In the end, it's fribidi (already in fedora)
plus a small 500-line script-like utility to pass everything through.

If there is enough interest, I can look into this.

> Should we leave it this way, or do the same substitution to en_US that
> we do for CJK locales?

In the short term (F10...), this makes perfect sense.

behdad

> Bill
> 



From rdieter at math.unl.edu  Thu Oct  9 22:27:12 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 09 Oct 2008 17:27:12 -0500
Subject: Possible to default to KDE?
References: <48ED6823.5000901@redhat.com>
	<d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>
	<16de708d0810091123s44dbb79es96002d2be3e955f@mail.gmail.com>
	<gclk0g$5bm$1@ger.gmane.org> <48EE6D9B.90305@redhat.com>
Message-ID: <gcm0fg$onr$1@ger.gmane.org>

Warren Togami wrote:

> I was only suggesting that
> if you want to stick to gdm, it is impossible to make any other desktop
> default on the system if you keep GNOME installed.  I was only hoping
> this would be fixed for Fedora 10 so people do not need to rip out gdm.

Ah, I'll have to double-check that case, but afaik, setting/modifying /etc/sysconfig/desktop (still) works for both kdm and gdm.

-- Rex



From paul at all-the-johnsons.co.uk  Thu Oct  9 22:48:45 2008
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 09 Oct 2008 23:48:45 +0100
Subject: WIX under Mono
Message-ID: <1223592525.15158.92.camel@PB3.Linux>

Hi,

I've been looking at porting WIX to run cleanly under Mono as it would
be both a useful package for cygwin as well as our friends over at
Novell (allows them to get the open source goodness of Mono onto Win32).

First the bad news - and it's quite a fair few prongs on it!

1. It is reliant on the HTML help 1.4 SDK. I'm not sure if this is a
binary only app available from MS or not.
2. It is reliant on the MSI SDK. Again, not sure if this a binary only
from MS or not
3. There are a lot of references to VS and VS paths in the NAnt files
4. Using NAnt - it's going to take ages to port.

The good news.

1. It should be easy enough to build the source with hand crafted make
files (such as how Debian do it with mysql-connector-net). I can't see
anything in the source which isn't implemented under Mono 2.0. The build
would need to be a two stage build (one for WIX, the other for the
native WIX files)

Now, the only thing I've not factored in is the time to do it...

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/28a6e5f6/attachment.sig>

From seg at haxxed.com  Thu Oct  9 22:50:00 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 09 Oct 2008 17:50:00 -0500
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>
	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>
	<64b14b300810090905g333fa51fp7a763955b4d4369b@mail.gmail.com>
	<48EE31C7.6090602@fedoraproject.org>
	<64b14b300810090955x76e40725l741696a6362159b1@mail.gmail.com>
	<20081009170418.GY3000@angus.ind.WPI.EDU>
	<64b14b300810091008r4d764594saf8bf6558d8c0515@mail.gmail.com>
Message-ID: <1223592600.26341.71.camel@localhost.localdomain>

On Thu, 2008-10-09 at 19:08 +0200, Valent Turkovic wrote:
> I know that no network I access has IPv6. No ADSL carrier in Croatia
> uses IPv6, my company doesn't use IPv6, and I in my home network I
> don't use IPv6.

6to4 does not require ISP support, and Microsoft requires it to be
supported for Vista certification of residential routers:

http://www.google.com/search?q=Network+Infrastructure+Device
+Implementer?s+Guide

(First hit, I link to google because it's a damn MS Word document...)

No idea how many manufacturers bother to get the Microsoft stamp of
approval, but it's out there. If you plug in to one of these, the router
handles 6to4, and provides native IPv6 to the LAN, which your Fedora box
(and any Vista machines...) will automatically use, all without needing
any support from the ISP or any configuration by you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/cc5990cb/attachment.sig>

From alsadi at gmail.com  Thu Oct  9 23:00:19 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 10 Oct 2008 02:00:19 +0300
Subject: Arabic and Hebrew on the console
In-Reply-To: <48EE843B.20009@behdad.org>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<48EE843B.20009@behdad.org>
Message-ID: <385866f0810091600w44a6ff6cuc8e539efe353c126@mail.gmail.com>

Behdad I looked for you in the IRC

when can we see BiCon rpm on fedora ?
and how to make the initscript translated messages be processed by bicon
(as bicon only process its child process)
have you managed to make it a daemon or something like that
because we don't want to put the boot process at risk by having a new
still beta application like bicon

and I'll be pleased to test BiCon rpms



From behdad at behdad.org  Thu Oct  9 23:07:21 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 09 Oct 2008 19:07:21 -0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <385866f0810091600w44a6ff6cuc8e539efe353c126@mail.gmail.com>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>	<48EE843B.20009@behdad.org>
	<385866f0810091600w44a6ff6cuc8e539efe353c126@mail.gmail.com>
Message-ID: <48EE8EA9.7060909@behdad.org>

Muayyad AlSadi wrote:
> Behdad I looked for you in the IRC
> 
> when can we see BiCon rpm on fedora ?

Whenever there's a need.

> and how to make the initscript translated messages be processed by bicon
> (as bicon only process its child process)

It can be handled by /etc/init.d/functions rather easily.

> have you managed to make it a daemon or something like that
> because we don't want to put the boot process at risk by having a new
> still beta application like bicon

What is "beta" anyway?  The code will be as good as the effort put in it.  And
I have no idea how making it a daemon (what does that mean for a converter
btw?) make it any better.

behdad

> and I'll be pleased to test BiCon rpms
> 



From mw_triad at users.sourceforge.net  Thu Oct  9 23:18:20 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 09 Oct 2008 18:18:20 -0500
Subject: Fedora 10 Live CD services (all necessary?)
In-Reply-To: <385866f0810091333q495dba7dy773c511abd43f26e@mail.gmail.com>
References: <64b14b300810090638u501701c6m3b249386329cf5a6@mail.gmail.com>	<3adc77210810090716i6422b0fey1bd31413494ea717@mail.gmail.com>	<48EE1834.4020405@city-fan.org>	<200810092218.02425.opensource@till.name>	<1223583682.19673.174.camel@aglarond.local>
	<385866f0810091333q495dba7dy773c511abd43f26e@mail.gmail.com>
Message-ID: <gcm3fs$2sq$2@ger.gmane.org>

Muayyad AlSadi wrote:
> regarding *cron* and alike scheduled tasks
> 
> they are useless on the CD and they are offensive for a USB or SD-memory

USB doesn't have /var/log/messages?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
When in doubt, duct tape!



From hbasava at yahoo.com  Thu Oct  9 23:06:44 2008
From: hbasava at yahoo.com (Basavaraj Hiremath)
Date: Thu, 9 Oct 2008 16:06:44 -0700 (PDT)
Subject: touchscreen
Message-ID: <242151.89206.qm@web36103.mail.mud.yahoo.com>

MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi =0AI am integrating touch screen to OMAP2430 device. We are not using om=
ap touch screen hardware.=0AWe are using separate touch controller connecte=
d to OMAP2430 through UART (/dev/ttyS0)=0AOMAP gets x, y and touch values t=
hrough /dev/ttyS0=E2=80=A6=0AHow to send these values to X-server, so that,=
 it can understand coordinates and touch, and handle transparently all the =
application open and close? =0AIs there any API=E2=80=99s to send it?=0AI h=
ave seen the existing touch screen in omap, it uses input_report_abs() API =
to send it across.=0ABut as I don=E2=80=99t have =E2=80=98dev=E2=80=99 defi=
ned on my omap, I cannot use this.=0A=0A=0AIf you have any other ideas, wel=
come!. It should fit in my architecture as mentioned above.=0A=0A=0AThanks =
& regards,=0ARaj=0A=0A=0A=0A      



From alsadi at gmail.com  Thu Oct  9 23:24:22 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 10 Oct 2008 02:24:22 +0300
Subject: Arabic and Hebrew on the console
In-Reply-To: <48EE8EA9.7060909@behdad.org>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<48EE843B.20009@behdad.org>
	<385866f0810091600w44a6ff6cuc8e539efe353c126@mail.gmail.com>
	<48EE8EA9.7060909@behdad.org>
Message-ID: <385866f0810091624m79e67e7do821c10e24ffbd013@mail.gmail.com>

> Whenever there's a need.
when ? my answer is yesterday :-)
for example if I want to use vim to edit my some Arabic text files
(it's an example you gave me in gnome's bugzilla)

>> have you managed to make it a daemon or something like that
>> because we don't want to put the boot process at risk by having a new
>> still beta application like bicon
>
> What is "beta" anyway?  The code will be as good as the effort put in it.  And
> I have no idea how making it a daemon (what does that mean for a converter
> btw?) make it any better.
>
yes, it will be, I hope that and I'm ready to help you with whatever I can
like testing and maybe some coding [although I'm not an expert of
console behind scenes]

I meant by daemon, to have bicond or something doing the the bidi on
all VTs in the background.
maybe this is not the right place for this talk.
maybe I should start a new thread about that topic



From sundaram at fedoraproject.org  Thu Oct  9 23:30:43 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 10 Oct 2008 05:00:43 +0530
Subject: Possible to default to KDE?
In-Reply-To: <16de708d0810091123s44dbb79es96002d2be3e955f@mail.gmail.com>
References: <48ED6823.5000901@redhat.com>	<d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>
	<16de708d0810091123s44dbb79es96002d2be3e955f@mail.gmail.com>
Message-ID: <48EE9423.4000203@fedoraproject.org>

Arthur Pemberton wrote:
> On Thu, Oct 9, 2008 at 1:07 PM, Pavel Shevchuk <stlwrt at gmail.com> wrote:
>> Put:
>>
>> DISPLAYMANAGER=KDE
>>
>> in  /etc/sysconfig/desktop, then select KDE session. KDM will remember
>> your choice when you log in next time
> 
> 
> Is editing  text file really the method we want to publicize as the
> idea for switching (gui) desktop environment?

If you want to automate more of the system administration tasks, you can 
do this or use switchdesk. If you are looking for a graphical utility, 
system-switch-displaymanager has been made available recently.

http://koji.fedoraproject.org/koji/buildinfo?buildID=64966

Rahul



From a.badger at gmail.com  Thu Oct  9 23:26:19 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 09 Oct 2008 16:26:19 -0700
Subject: Uberpackager replaces packager
Message-ID: <48EE931B.1030302@gmail.com>

The transition from a single packager group to an entry level packager
group that can only commit to packages that the person owns and a
separate uberpackager group that can commit to everything has been made.
   At this point in time, people who are only in the packager group
should be able to commit only to packages for which they explicitly have
commit acls (owner or commit in Approved state in the packagedb).

People in uberpackager should be able to commit to any package which is
open to the uberpackager group.  As part of the update, all packages
which were previously opened to packager/cvsextras are now opened to
uberpackager.

This concludes all the steps needed for:
http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment

The next step in the plan is written up here:
http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening

I'll let Casey Dahlin fill in a time frame for that and details on how
to opt-out of the acl opening.

-Toshio


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081009/956e9bc1/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 christoph.wickert at googlemail.com  Thu Oct  9 23:41:32 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 10 Oct 2008 01:41:32 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223539429.3145.365.camel@macbook.infradead.org>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
Message-ID: <1223595692.14070.16.camel@wicktop.localdomain>

Am Donnerstag, den 09.10.2008, 09:03 +0100 schrieb David Woodhouse:
> On Wed, 2008-10-08 at 22:56 +0200, Christoph Wickert wrote:
> > Am Mittwoch, den 08.10.2008, 16:47 -0400 schrieb Josh Boyer:
> > > On Wed, Oct 08, 2008 at 08:09:12PM +0200, Christoph Wickert wrote:
> > >
> > > >So the decision was made under the assumption that _none_ of the LXDE
> > > >packages has ever passed a review. How can somebody who has read the
> > > >feature page claim that? Why did nobody answer him back?
> > > 
> > > The decision was made under the _fact_ that the Feature lacked packages
> > > that had not passed review.  If they aren't all there, it can't be tested
> > > by Beta.  It's really that simple.
> > 
> > As I wrote in a previous mail: I don't challenge that, but for me it not
> > "really that simple" but "really that disappointing". I've put a lot of
> > work into the feature and when I see that people hardly seem to read the
> > feature page or don't care about informing the feature owner is just
> > disappointing
> 
> It is unfortunate that you didn't get informed properly. We'll make an
> effort to ensure that kind of thing doesn't happen again. I apologise
> for that, and I suspect I speak for the rest of FESCo when I do so.
> 
> One thing we can do in future to make that situation better is Cc the
> feature owners when the meeting agenda is sent to fedora-devel-list. I
> hope we can manage that.

Should not be that hard, there are not so many features/feature
owners. ;)

> The other thing we should do, of course, is work out _why_ you didn't
> get the notification. Do you get _any_ notifications? Was it just this
> one which was missing? Is there someone from the infrastructure team who
> can look into that? ISTR you said that you were the last person to edit
> the page before the missing notification -- so it wasn't _expected_ that
> you didn't get notified?

Nope. You get a notification for the first change, and John was the
first to edit the page after me. So I should have gotten a notice as I
got before on the other changes.
I'm using Gmail now and it's nearly impossible to delete a mail there
(it's even nearly impossible to delete it on purpose), because every
mail is also stored in the "All Messages"-folder. I have searched my
whole mailbox and I did not find anything.

> 
> We appreciate the work you've put into packaging LXDE. We certainly
> don't mean to suggest otherwise, and we are pleased to see the packages
> in Fedora 10. (Well, I {do,don't,am}, and again I'm being presumptuous).
> 
> Let's get the final two packages reviewed -- and that's another area
> where we could do with some improvement, because failing to approve
> packages really _is_ verging on the 'deletionism' you spoke of. But
> that's a separate discussion.

Agreed, we can discuss this later. BTW: The word "deletionsm" did not
come from me, it was Josh who said that, but of course I agree with him.
> 
> And then if everything's working and the only thing that's missing is an
> entry in comps which lets you choose it in the installer, I think
> there's a fairly strong case for having an exception to the string
> freeze -- especially since the translation of 'LXDE' is going to be
> 'LDXE' in most cases ;)  We'll see...

Ok, since there is good progress in the reviews now I'm going to ask the
localization team for a string freeze break.

Thanks for your support David, and of course everybody else, who
supports me the LXDE feature.

Regards,
Christoph



From christoph.wickert at googlemail.com  Thu Oct  9 23:44:18 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 10 Oct 2008 01:44:18 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223505678.15503.2.camel@kennedy>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<20081007184626.GB4377@nostromo.devel.redhat.com>
	<loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<48ED07FE.4080604@gmail.com>
	<1223498986.23034.41.camel@wicktop.localdomain>
	<1223505678.15503.2.camel@kennedy>
Message-ID: <1223595858.14070.18.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 18:41 -0400 schrieb Brian Pepple:
> On Wed, 2008-10-08 at 22:49 +0200, Christoph Wickert wrote:
> > 
> > Agreed, but my point is: They don't need to know all details, but they
> > need to read the feature page. And if the page says that 9 out of 11
> > packages are done I expect FeSCo members to know that, not more, not
> > less, but I expect somebody to not incorrectly state that none of the
> > packages is available.
> 
> Umm, no FESCo member did state that.  A member of the QA did, and a
> FESCo member (nirik) corrected him.

But niriks statement was incorrect too, as I already pointed out.
Anyway, I'm tired of this discussion now.

Regards,
Christoph



From christoph.wickert at googlemail.com  Thu Oct  9 23:52:38 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 10 Oct 2008 01:52:38 +0200
Subject: Disappointed: My feature was removed without noticing me
In-Reply-To: <1223509556.19113.6.camel@kennedy>
References: <1223404671.24360.51.camel@wicktop.localdomain>
	<1223509556.19113.6.camel@kennedy>
Message-ID: <1223596358.14070.22.camel@wicktop.localdomain>

Am Mittwoch, den 08.10.2008, 19:45 -0400 schrieb Brian Pepple:
> On Tue, 2008-10-07 at 20:37 +0200, Christoph Wickert wrote:
> > But this won't
> > help because no announcement has been made on the list and the latest
> > meeting minutes were published on September 10th. (BTW: Meeting minutes
> > seem to be published only sporadic recently.)
> 
> Wrong.  Only 1 weeks summary was missing (and that was because I was
> without power for a week, and haven't had time to go back and write that
> one up).

You are right, I had already corrected my previuos statement yesterday a
few hours before you wrote this mail, see
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00423.html

Sorry for blaming you unjustified.

Regards,
Christoph



From michael at laptop.org  Thu Oct  9 23:55:34 2008
From: michael at laptop.org (Michael Stone)
Date: Thu, 9 Oct 2008 19:55:34 -0400
Subject: Tangent: recording upstream scm locations and contact info
In-Reply-To: <200810092203.39432.opensource@till.name>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223568584.4410.101.camel@luminos.localdomain>
	<20081009171143.GB18785@didacte.laptop.org>
	<200810092203.39432.opensource@till.name>
Message-ID: <20081009235533.GI18785@didacte.laptop.org>

On Thu, Oct 09, 2008 at 10:03:34PM +0200, Till Maas wrote:
>On Thu October 9 2008, Michael Stone wrote:
>
>> On a tangential note, I'd _love_ it if specfiles started growing
>> metadata pointing back to upstream scm repos and development fora. This
>
>> P.S. - I'd definitely appreciate it if folks who are more knowledgable
>> about Fedora and RPM could suggest ways that I might pursue this goal
>> within the larger Fedora/RPM community.
>
>Why do you want it in the specfile? Imho it would fit better within the 
>packagedb. There it should be also easier to add it, given that packagedb 
>upstream accepts patches for this.

I suggested spec-files because I'm somewhat familiar with them, because
they don't have downtime, because they're included in SRPMs which I have
to preserve no matter what, and because I have to deal with a small
number of packages which are not yet available in Fedora (or which are
forked).

Does storing the information in packagedb have some compelling benefit
that compensates for dealing with these hassles by other means?

Thanks,

Michael



From jwboyer at gmail.com  Fri Oct 10 00:01:40 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 9 Oct 2008 20:01:40 -0400
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <1223595692.14070.16.camel@wicktop.localdomain>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
Message-ID: <20081010000140.GA31156@yoda.jdub.homelinux.org>

On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
>> Let's get the final two packages reviewed -- and that's another area
>> where we could do with some improvement, because failing to approve
>> packages really _is_ verging on the 'deletionism' you spoke of. But
>> that's a separate discussion.
>
>Agreed, we can discuss this later. BTW: The word "deletionsm" did not
>come from me, it was Josh who said that, but of course I agree with him.

I didn't say that.  Though I agree we need to be getting more packages
approved.

josh



From christoph.wickert at googlemail.com  Fri Oct 10 00:12:52 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 10 Oct 2008 02:12:52 +0200
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <20081010000140.GA31156@yoda.jdub.homelinux.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
Message-ID: <1223597573.14070.25.camel@wicktop.localdomain>

Am Donnerstag, den 09.10.2008, 20:01 -0400 schrieb Josh Boyer:
> On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
> >> Let's get the final two packages reviewed -- and that's another area
> >> where we could do with some improvement, because failing to approve
> >> packages really _is_ verging on the 'deletionism' you spoke of. But
> >> that's a separate discussion.
> >
> >Agreed, we can discuss this later. BTW: The word "deletionsm" did not
> >come from me, it was Josh who said that, but of course I agree with him.
> 
> I didn't say that.  Though I agree we need to be getting more packages
> approved.

I think this is something we all agree on. ;)

> josh
> 

Regards,
Christoph



From notting at redhat.com  Fri Oct 10 00:15:41 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 9 Oct 2008 20:15:41 -0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <200810092316.24993.oron@actcom.co.il>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<200810092316.24993.oron@actcom.co.il>
Message-ID: <20081010001541.GA29371@nostromo.devel.redhat.com>

Oron Peled (oron at actcom.co.il) said: 
> > Should we leave it this way, or do the same substitution to en_US that
> > we do for CJK locales?
> 
> What are you doing for CJK locales?

If you're on the console and LANG is set to zh_CN/ja_JP/etc, it
gets reset to en_US. See /etc/profile.d/lang.{csh,sh}

>  * Also, many times someone is running the program remotely from
>    a terminal emulator that has Unicode-Bidi implementation
>    (e.g: mlterm) and in this case they'll see the text fine.
>    How do you recognize that this is a virtual console and not
>    another text-mode terminal emulator?

This wouldn't be affected, as that is a pty (i.e., /dev/pts/X);
this only affects it if you're on /dev/tty[1-6].

Bill



From rawhide at fedoraproject.org  Fri Oct 10 01:44:26 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 10 Oct 2008 01:44:26 +0000 (UTC)
Subject: rawhide report: 20081009 changes
Message-ID: <20081010014426.476551B8001@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct  9 20:53:09 UTC 2008

New package chktex
        LaTex semantic checker
New package kde-plasma-quickaccess
        Plasma applet for quick access to the most used folders
New package perl-Module-Inspector
        Integrated API for inspecting Perl distributions
New package perl-ORLite
        Extremely light weight SQLite-specific ORM
New package rubygem-gettext
        RubyGem of Localization Library and Tools for Ruby
New package screenruler
        GNOME screen ruler
Removed package gruler
Removed package ruby-gettext-package
Updated Packages:

MAKEDEV-3.23-7
--------------
* Thu Oct  9 18:00:00 2008 Dave Airlie <airlied at redhat.com> 3.23-7
- Add bootup speed up patch from Jakub


PackageKit-0.3.6-3.fc10
-----------------------
* Thu Oct  9 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.6-3
- Add a patch from upstream to fix rh#466290


PyAmanith-0.3.35-4.fc10
-----------------------
* Thu Oct  9 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.3.35-4
- rebuild to prove it builds


anaconda-11.4.1.45-1
--------------------
* Thu Oct  9 18:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.45-1
- Fix sorting of repos so we always return an integer value (#466174).
  (clumens)
- Change the upgrade progress bar to pulse (#466053). (clumens)
- Mark iscsi disks not used for / as autostart (rh461840) (hans)
- Always display the wait window when fetching repo information. (clumens)
- Lazily unmount everything before killing NetworkManager (#463959).
  (clumens)
- lang-names really does need to depend on subdirs (katzj)
- Reset targetLang on language change (#465981) (katzj)
- Honor static net parameters with NM (#465270) (dcantrell)


bsd-games-2.17-24.fc10
----------------------
* Wed Oct  8 18:00:00 2008 Wart <wart at kobold.org> 2.17-24
- Temporarily set patch fuzz factor until patches can be rebased.


cairo-dock-1.6.3-0.1.svn1342_trunk.fc10
---------------------------------------
* Thu Oct  9 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1342


cheese-2.24.0-2.fc10
--------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 2.24.0-2
- Save space


cluster-2.99.10-6.fc10
----------------------
* Wed Oct  8 18:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 2.99.10-6
- cman init: add fix from upstream for cman_tool wrong path.


condor-7.0.5-1.fc10
-------------------
* Wed Oct  8 18:00:00 2008 <matt at redhat> - 7.0.5-1
- Rebased on 7.0.5, security update


control-center-2.24.0.1-5.fc10
------------------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0.1-5
- Change the default key combination to change keyboard layouts
  to shift-capslock, since alt-alt doesn't work (#465403)


coreutils-6.12-13.fc10
----------------------
* Wed Oct  8 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 6.12-13
- remove unimplemented (never accepted by upstream) option
  for chcon changes only. Removed from help and man.
- remove ugly lzma hack as lzma is now supported by setup
  macro


cpuspeed-1.5-1.fc10
-------------------
* Wed Oct  8 18:00:00 2008 Jarod Wilson <jarod at redhat.com> 1.5-1
- Update to v1.5 release


createrepo-0.9.5-5.fc10
-----------------------
* Thu Oct  9 18:00:00 2008 James Antill <james at fedoraproject.org> - 0.9.5-5
- Do atomic updates to the cachedir, for parallel runs
- Fix the patch


dasher-4.9.0-2.fc10
-------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 4.9.0-2
- Save some space


desktop-backgrounds-9.0.0-2
---------------------------
* Wed Oct  8 18:00:00 2008 Than Ngo <than at redhat.com> 9.0.0-2
- own /usr/share/wallpapers


drupal-6.5-1.fc10
-----------------
* Thu Oct  9 18:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 6.5-1
- Upgrade to 6.5, SA-2008-060.
- Added notes to README and drupal.conf re CVE-2008-3661.


e2fsprogs-1.41.2-2.fc10
-----------------------

ekiga-3.0.0-4.fc10
------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 3.0.0-4
- Save some space


enblend-3.2-2.fc10
------------------
* Wed Oct  8 18:00:00 2008 Bruno Postle <bruno at postle.net> - 3.2-2
- don't package /usr/share/info/dir

* Tue Sep 23 18:00:00 2008 Bruno Postle <bruno at postle.net> - 3.2-1
- upstream release


eog-2.24.0-2.fc10
-----------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Save some space


epiphany-2.24.0.1-4.fc10
------------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0.1-4
- Save some more space


evolution-2.24.0-3.fc10
-----------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-3
- Save space in the -help package by not shipping multiple copies
  of each screenshot


fedora-ds-base-1.1.3-5.fc10
---------------------------
* Thu Oct  9 18:00:00 2008 Rich Megginson <rmeggins at redhat.com> - 1.1.3-5
- updated update to patch bug463991-bdb47.patch

* Thu Oct  9 18:00:00 2008 Rich Megginson <rmeggins at redhat.com> - 1.1.3-4
- updated patch bug463991-bdb47.patch


fotoxx-5.4-1.fc10
-----------------
* Thu Oct  9 18:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 5.4-1
- Rebuild for 5.4


gcc-4.3.2-6
-----------
* Thu Oct  9 18:00:00 2008 Jakub Jelinek <jakub at redhat.com> 4.3.2-6
- fix fallouts from the -g -O0 debugging patch (#466169, #466198)

* Wed Oct  8 18:00:00 2008 Jakub Jelinek <jakub at redhat.com> 4.3.2-5
- update from gcc-4_3-branch
  - PRs c++/37555, c/35712, c/37645, fortran/35770, fortran/35945,
	fortran/36374, fortran/36454, fortran/36700, fortran/37274,
	fortran/37504, fortran/37580, fortran/37583, fortran/37626,
	fortran/37706, middle-end/36575, middle-end/37236, middle-end/37731,
	rtl-optimization/37544, target/35620, target/35713, target/37603,
	tree-opt/35737, tree-optimization/36343, tree-optimization/37539
- ensure one can put breakpoints on break, continue and goto statements
  with -g -O0 (#465824, PRs debug/29609, debug/36690, debug/37616)
- emit one DW_TAG_common_block for each common block in each scope, not
  one for each common block in one CU (#465974, PR debug/37738)
- Intel -maes and -mpclmul support


ghdl-0.27-0.110svn.1.fc10
-------------------------
* Thu Oct  9 18:00:00 2008 Thomas Sailer <t.sailer at alumni.ethz.ch> - 0.27-0.110svn.1
- rebuild


gimp-2.6.0-3.fc10
-----------------
* Wed Oct  8 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.0-3
- split off help browser plugin
- let gimp and gimp-help-browser obsolete older gimp versions to allow seamless
  upgrades


gnash-0.8.3-6.fc10
------------------
* Sat Oct  4 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.8.3-6
- use the KDE 3 executable with the KDE 4 KPart for now (making this conditional
  so it can easily be disabled or removed once the KDE 4 executable is fixed)

* Sat Oct  4 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.8.3-5
- register KComponentData properly in KDE 4 KPart

* Fri Oct  3 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.8.3-4
- KDE 4 port of klash by Benjamin Wolsey and Bernhard Rosenkr??nzer

* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 0.8.3-3
- include %_libdir/gnash directory


gnome-applet-netspeed-0.15-3.fc10
---------------------------------
* Tue Sep 30 18:00:00 2008 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.15-3
- Added patch fixing off-by-one error from SVN trunk (fixes gnome bug #554339)


gnome-packagekit-0.3.6-3.fc10
-----------------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 0.3.6-3
- Another space-saving hack


gnome-panel-2.24.0-6.fc10
-------------------------
* Thu Oct  9 18:00:00 2008 Ray Strode  <rstrode at redhat.com> - 2.24.0-6
- Hide shutdown item if unavailable

* Thu Oct  9 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-5
- Don't show menuitems which fail the tryexec test


gnome-power-manager-2.24.0-6.fc10
---------------------------------
* Thu Oct  9 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-6
- Enable policy kit support

* Wed Oct  8 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-5
- Save some more space


gnome-python2-extras-2.19.1-20.fc10
-----------------------------------
* Thu Oct  9 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-20
- Remove gtkspell-static patch.  Appears to not be needed anymore.

* Wed Oct  8 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-19
- Add build requirements to get this building again.

* Fri Oct  3 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-18
- Add Requires: gnome-python2-gnome.

* Fri Oct  3 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-17
* Rebuild against gecko-devel-unstable-1.9.0.2.


gnome-session-2.24.0-7.fc10
---------------------------
* Thu Oct  9 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-7
- Add new api for panel to figure out whether or not to show
  Shutdown menu item.


gnome-system-monitor-2.24.0-3.fc10
----------------------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-3
- Add a TryExec line to about-this-computer.desktop

* Wed Oct  8 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Save some space


gtk-vnc-0.3.7-3.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Daniel P. Berrange <berrange at redhat.com> - 0.3.7-3.fc10
- Avoid bogus framebuffer updates for psuedo-encodings
- Fix scancode translation for evdev


gtk2-2.14.3-6.fc10
------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.3-6
- Fix a problem with file chooser buttons


gucharmap-2.24.0-2.fc10
-----------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Save some space


hal-0.5.12-2.20081001git.fc10
-----------------------------
* Wed Oct  8 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-2.20081001git
- Add a patch from the mailing list to fix rh#466150


hercules-3.05-7.20081009cvs.fc10
--------------------------------
* Thu Oct  9 18:00:00 2008 Dan Horak <dan[at]danny.cz> 3.05-7.20081009cvs
- update to CVS snapshot 20081009 (#461044)
- install utils only as docs
- little cleanup

* Thu Apr 10 18:00:00 2008 Jarod Wilson <jwilson at redhat.com> 3.05-5
- Point to new project URL
- Add a template generic.prm matching provided hercules.cnf


hugin-0.7.0-1.fc10
------------------
* Tue Oct  7 18:00:00 2008 Bruno Postle <bruno at postle.net> 0.7.0-1
- 0.7.0 release


ibus-m17n-0.1.1.20081009-1.fc10
-------------------------------
* Thu Oct  9 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081009-1
- Update to 0.1.1.20081009.


icu4j-3.8.1-4.fc10
------------------
* Wed Oct  8 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0:3.8.1-4
- Disable debuginfo package when built with Eclipse support, change to
  noarch when built without it (#464017).


ipod-sharp-0.8.1-1.fc10
-----------------------
* Fri Sep 12 18:00:00 2008 David Nielsen <gnomeuser at gmail.com> - 0.8.1-1
- bump to 0.8.1


jabberd-2.2.4-1.fc10
--------------------
* Tue Oct  7 18:00:00 2008 Adrian Reber <adrian at lisas.de> - 2.2.4-1
- updated to 2.2.4
  (this version and pidgin 2.5.1 finally work together)


jd-2.0.3-0.1.svn2382_trunk.fc10
-------------------------------
* Thu Oct  9 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2382


kde-filesystem-4-20.fc10
------------------------
* Wed Oct  8 18:00:00 2008 Than Ngo <than at redhat.com> 4-20
- /usr/share/wallpapers owned by desktop-backgrounds-basic


kdebase-workspace-4.1.2-3.fc10
------------------------------
* Wed Oct  8 18:00:00 2008 Luk???? Tinkl <ltinkl at redhat.com> 4.1.2-3
- fix crash when invoking a klipper command for a second time


kdelibs-4.1.2-3.fc10
--------------------
* Wed Oct  8 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-3
- backport fix for google maps


kernel-2.6.27-0.408.rc9.git1.fc10
---------------------------------
* Wed Oct  8 18:00:00 2008 Eric Sandeen <sandeen at redhat.com>
- Add in latest ext4 patch queue - rename to ext4 as well.

* Wed Oct  8 18:00:00 2008 Dave Jones <davej at redhat.com>
- Work around VMWares busted mptfusion emulation again. (#466071)

* Wed Oct  8 18:00:00 2008 Dave Jones <davej at redhat.com>
- Reenable a bunch of PPC config options that broke earlier.

* Wed Oct  8 18:00:00 2008 Dave Jones <davej at redhat.com>
- Fix DEBUG_SHIRQ problem in tulip driver.  (#454575)

* Wed Oct  8 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- radeon - hopefully fix suspend/resume - reenable HW migration

* Tue Oct  7 18:00:00 2008 Roland McGrath <roland at redhat.com>
- Fix build ID fiddling magic. (#465873)

* Tue Oct  7 18:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.27-rc9-git1


kita-0.177.5-2.fc10
-------------------
* Thu Oct  9 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.177.5-2
- Fix sparc64 build


krazy2-2.6-6.20081008svn869261.fc10
-----------------------------------
* Wed Oct  8 18:00:00 2008 Ben Boeckel <MathStuf at gmail.com> 2.6-6.20081008svn869261
- Updated SVN
- Patch applied upstream


libXNVCtrl-169.12-2.fc10
------------------------
* Wed Oct  8 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> 169.12-2
- make sure libdir is set right on sparc64


libchewing-0.3.1-0.fc10
-----------------------
* Wed Oct  8 18:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 0.3.1-0
- Upstream update.


libopensync-plugin-gnokii-0.36-2.fc10
-------------------------------------
* Wed Oct  8 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.36-2
- rebuild for new gnokii


libxslt-1.1.24-2.fc10
---------------------
* Wed Oct  8 18:00:00 2008 Daniel Veillard <veillard at redhat.com> 1.1.24-2.fc10
- CVE-2008-2935 fix


mapnik-0.5.2-0.7.svn738.fc10
----------------------------
* Thu Oct  9 18:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 0.5.2-0.7.svn738
- require desktop-utils in koji

* Wed Oct  8 18:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 0.5.2-0.6.svn738
- fix self dependency build for viewer

* Wed Oct  8 18:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 0.5.2-0.5.svn738
- enable viewer application for mapnik's xml templates
- exclude viewer from demo than


mesa-7.2-0.7.fc10
-----------------
* Thu Oct  9 18:00:00 2008 Kristian H??gsberg <krh at redhat.com> - 7.2-0.7
- Actually add patch.

* Thu Oct  9 18:00:00 2008 Kristian H??gsberg <krh at redhat.com> - 7.2-0.6
- Fix black shadows in compiz (fix from Eric Anholt, bugs.fd.o #17233)


mkinitrd-6.0.66-1.fc10
----------------------
* Thu Oct  9 18:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.66-1
- Fix incorrect size allocation when probing weird scsi devices (#440661)


mousetweaks-2.24.0-2.fc10
-------------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Save some space


nethogs-0.7-4.20080627cvs.fc10
------------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.7-4.20080627cvs
- Fix Patch0:/%patch mismatch.


nsd-3.1.1-1.fc10
----------------
* Thu Oct  9 18:00:00 2008 Paul Wouters <paul at xelerance.com> - 3.1.1-1
- updated to 3.1.1


ntp-4.2.4p5-2.fc10
------------------
* Wed Oct  8 18:00:00 2008 Miroslav Lichvar <mlichvar at redhat.com> 4.2.4p5-2
- retry failed name resolution few times before giving up (#460561)
- don't write drift file upon exit
- run ntpq with full path in ntp-wait script


numpy-1.2.0-1.fc10
------------------
* Tue Oct  7 18:00:00 2008 Jon Ciesla <limb at jcomserv.net> 1.2.0-1
- New upstream release, added python-nose BR. BZ 465999.
- Using atlas blas, not blas-devel. BZ 461472.


openvrml-0.17.9-1.0.fc10
------------------------
* Thu Oct  9 18:00:00 2008 Braden McDaniel  <braden at endoframe.com> - 0.17.9-1.0
- Updated to 0.17.9.
- Removed patch to remove GTK_DISABLE_DEPRECATED.

* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org>
- Include two directories in -player pkg.


pam_mount-0.49-1.fc10
---------------------
* Wed Oct  8 18:00:00 2008 Till Maas <opensource at till.name> - 0.49-1
- Update to new release


paprefs-0.9.7-3.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 0.9.7-3
- Handle locales properly


pavucontrol-0.9.7-3.fc10
------------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 0.9.7-3
- Handle locales properly


perl-Panotools-Script-0.19-1.fc10
---------------------------------
* Fri Sep 19 18:00:00 2008 Bruno Postle <bruno at postle.net> 0.19-1
- New upstream version

* Thu Sep 11 18:00:00 2008 Bruno Postle <bruno at postle.net> 0.17-1
- New upstream version

* Tue Sep  2 18:00:00 2008 Bruno Postle <bruno at postle.net> 0.16-1
- New upstream version

* Sun Jul  6 18:00:00 2008 Bruno Postle <bruno at postle.net> 0.15-1
- New upstream version


php-pear-PHPUnit-3.3.1-1.fc10
-----------------------------
* Thu Oct  9 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 3.3.1-1
- Upstream sync

* Thu Oct  9 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 3.2.21-1
- Upstream sync
- Add php-xml to Requires (bz #464758)


php-pear-Validate-Finance-CreditCard-0.5.3-1.fc10
-------------------------------------------------
* Fri Sep 12 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 0.5.3-1
- Upstream sync


php-pear-XML-Beautifier-1.2.0-1.fc10
------------------------------------
* Thu Oct  9 18:00:00 2008 Christohper Stone <chris.stone at gmail.com> 1.2.0-1
- Upstream sync
- Update license to BSD


php-pear-XML-Util-1.2.0-1.fc10
------------------------------
* Thu Oct  9 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.2.0-1
- Upstream sync
- Update License
- Add new testdir to %files


php-pecl-xdebug-2.0.3-4.fc10
----------------------------
* Thu Oct  9 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 2.0.3-4
- Add code coverage patch (bz #460348)
- http://bugs.xdebug.org/bug_view_page.php?bug_id=0000344

* Thu Oct  9 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 2.0.3-3
- Revert last change

* Thu Oct  9 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 2.0.3-2
- Add php-xml to Requires (bz #464758)


plymouth-0.6.0-0.2008.10.08.1.fc10
----------------------------------
* Wed Oct  8 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.10.08.1
- Rework how "console=" args done again, to hopefully fix
  bug 460565


poker-network-1.6.0-2.fc10
--------------------------
* Thu Oct  9 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.6.0-2
- Update bot patch (bz #464986)


pulseaudio-0.9.13-2.fc10
------------------------
* Thu Oct  9 18:00:00 2008 Matthhias Clasen <mclasen at redhat.com> 0.9.13-2
- Handle locales properly


pungi-2.0.6-1.fc10
------------------
* Thu Oct  9 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 2.0.6-1
- Handle %packages --default to pick up the default groups.
- Set iso name to be the same as --name
- Make sure we don't include the 'sha1:' in the iso SHA1SUM file.
- Fix .treeinfo to have proper case in file names


pyclutter-0.8.0-0.1.20081008r3353.fc10
--------------------------------------
* Wed Oct  8 18:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.8.0-0.1.20081008r3353
- Update to SVN snapshot of pyclutter 0.8 until official release comes out.
- Fixes broken deps.

* Thu Sep 11 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 0.6.2-4
- Rebuild for new clutter

* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.6.2-3
- Fix unowned directory


pymetar-0.14-1.fc10
-------------------
* Wed Oct  8 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.14-1
- Update to 0.14.
- Include patch to remove no longer existing files from trying to be installed.


python-bugzilla-0.4-0.rc3.fc10
------------------------------
* Wed Oct  8 18:00:00 2008 Will Woods <wwoods at redhat.com> 0.4.0.rc3
- Add updateperms() - patch courtesy of Jon Stanley
- Fix attachfile() for RHBugzilla3
- Actually install man page. Whoops.


python-genshi-0.5.1-2.fc10
--------------------------
* Thu Oct  9 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.5.1-2
- Add patch from upstream that fixes problems when using Genshi in
- conjuction with Babel.


qt3-3.3.8b-17.fc10
------------------
* Wed Oct  8 18:00:00 2008 Than Ngo <than at redhat.com> 3.3.8b-17
- update qt-x11-immodule-unified-qt3 patch

* Tue Sep 30 18:00:00 2008 Than Ngo <than at redhat.com> 3.3.8b-16
- mv translations in main package (bz#448761)


rdma-1.0-3.fc10
---------------
* Thu Oct  9 18:00:00 2008 Doug Ledford <dledford at redhat.com> - 1.0-3
- Add the ifup-ib script so we support connected mode on ib interfaces


rhythmbox-0.11.6-13.5966.fc10
-----------------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 0.11.6-13.r5966
- Save some space


roundcubemail-0.2-3.beta.fc10
-----------------------------
* Thu Oct  9 18:00:00 2008 Jon Ciesla <limb at jcomserv.net> = 0.2-3.beta
- New upstream.


ruby-1.8.6.287-2.fc10
---------------------
* Wed Oct  8 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 1.8.6.287-2
- CVE-2008-3790: DoS vulnerability in the REXML module.


ruby-aws-0.4.4-1.fc10
---------------------
* Wed Oct  8 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.4-1
- 0.4.4


ruby-mechanize-0.8.4-1.fc10
---------------------------
* Wed Oct  8 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.8.4-1
- 0.8.4


seahorse-2.24.0-3.fc10
----------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.24.0-3
- Save some space


seahorse-plugins-2.24.0-4.fc10
------------------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.24.0-4
- Save some space


seamonkey-1.1.12-1.fc10
-----------------------

sectool-0.9.0-1.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Peter Vrabec <pvrabec at redhat.com> - 0.9.0-1
- upgrade, see changelog for changes


sim-0.9.5-0.13.20080923svn2261rev.fc10
--------------------------------------
* Thu Oct  9 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.13.20080923svn2261rev
- %bcond_with kde replaced to %bcond_without for default build kde support (Patrice Dumas)

* Tue Oct  7 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.12.20080923svn2261rev
- Remove $RPM_BUILD_ROOT/%{_datadir}/mimelnk/application/x-icq.desktop in %install section for Fedora 8


squid-3.0.STABLE7-4.fc10
------------------------
* Thu Oct  9 18:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> - 7:3.0.STABLE7-4
- change logrotate to move instead of copytruncate

* Wed Oct  8 18:00:00 2008 Jiri Skala <jskala at redhat.com> - 7:3.0.STABLE7-3
- fix #465052 -  FTBFS squid-3.0.STABLE7-1.fc10

* Thu Aug 14 18:00:00 2008 Jiri Skala <jskala at redhat.com> - 7:3.0.STABLE7-2
- used ncsa_auth.8 from man-pages. there will be this file removed due to conflict
- fix #458593 noisy initscript
- fix #463129 init script tests wrong conf file
- fix #450352 - build.patch patches only generated files


swfdec-gnome-2.24.0-2.fc10
--------------------------
* Wed Oct  8 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-2
- Do the intltool dance

* Wed Oct  8 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.0-1
- Update to 2.24.0


system-config-language-1.3.2-2.fc10
-----------------------------------
* Wed Oct  8 18:00:00 2008 Pravin Satpute <psatpute at redhat.com>- 1.3.2-2
- fix bug 462914


tclparser-1.4-5.20061030cvs.fc10
--------------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.4-5.20061030cvs
- Fix Patch0:/%patch mismatch.


tcltls-1.6-1.fc10
-----------------
* Thu Oct  9 18:00:00 2008 Sander Hoentjen <sander at hoentjen.eu> - 1.6-1
- Update to latest release


tomboy-0.12.0-2.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.12.0-2
- Save some space


totem-2.24.2-2.fc10
-------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2-2
- Save some space


vinagre-2.24.0-2.fc10
---------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Save some space


xorg-x11-drv-ati-6.9.0-22.fc10
------------------------------
* Wed Oct  8 18:00:00 2008 Adam Jackson <ajax at redhat.com> 6.9.0-22
- radeon-6.9.0-lvds-mapping.patch: Fix connector mapping on LVDS.


yaboot-1.3.14-5.fc10
--------------------
* Mon Aug 11 18:00:00 2008 Roman Rakus <rrakus at redhat.com> - 1.3.14-5
- Clearing in specfile
- Fixed patches for --fuzz=0

* Wed May 28 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.3.14-4
- fix license tag


zenity-2.24.0-2.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Save some space


Summary:
Added Packages: 6
Removed Packages: 2
Modified Packages: 105
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From rc040203 at freenet.de  Fri Oct 10 02:53:42 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 10 Oct 2008 04:53:42 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223584634.4410.130.camel@luminos.localdomain>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<200810091816.31361.opensource@till.name>
	<1223569333.4410.104.camel@luminos.localdomain>
	<200810092226.50011.opensource@till.name>
	<1223584634.4410.130.camel@luminos.localdomain>
Message-ID: <1223607222.3564.1212.camel@beck.corsepiu.local>

On Thu, 2008-10-09 at 13:37 -0700, Jesse Keating wrote:
> On Thu, 2008-10-09 at 22:26 +0200, Till Maas wrote:
> > On Thu October 9 2008, Jesse Keating wrote:
> > > On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > > > On Thu October 9 2008, Jesse Keating wrote:
> > > > > Only if we allow source repo tags to be a suitable source distribution
> > > > > method.  Since fedorahosted still doesn't have an easy to use way of
> > > > > distributing tarballs, and getting the code via a scm checkout is quite
> > > > > easy, it should suffice.
> > > >
> > > > If this is the only obstacle to get this done, I will write a patch for
> > > > Makefile.common that displays the URL for every file in sources to fetch
> > > > it from the lookaside cache. Then this URL can be provided as source
> > > > tarball on a fedorahosted wiki page.
> > >
> > > Why must we insist on tarballs?  Unless the tarball includes scm
> > > metadata in it, it's practically useless for upstream patch development.
> > 
> > Tarballs allow to easily build the desired software via rpm and test it. With 
> > make patch and make rediff and make prep from Makefile.common it is also 
> > pretty easy to create and update patches. I have sucessfully created patches 
> > for upstream using this. Using directly an upstream scm, it is always a PITA 
> > to make the spec build from there, because the spec needs to be heavily 
> > modificated or I have to remember to recreate the tarball everytime. It would 
> > like it very much, if this would be a lot easier, e.g. some intelligent 
> > macros in spec files that allow to use a scm instead of a tarball to be used 
> > as Source0 and some magic that allows to define what from the scm should be 
> > used, e.g. should uncommited changes be used?
> > 
> > Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore 
> > it is not much work to link to them. Therefore I do not really see what needs 
> > to be discussed here. ;-)
> 
> I'm trying to see things from somebody else's point of view.  Recently,
> on this list, somebody else was arguing that we in Fedora land should be
> doing away with tarball distribution, and srpm distribution, and instead
> direct everything back to SCM, and to work on RPM so that it just
> understood SCM and left tarballs in the past.  Thank you for providing
> some argument against that (:
There are many more arguments against directly working from an SCM:
+ tarballs are easy to verify, long-term stable and easy to copy.
+ tarballs don't need a server infrastructure.
+ tarballs need a minimal client infrastructure.
+ tarballs decouple "rpms" from "upstreams".

That said, I find letting rpm directly work from SCMs to be
- unstable/unreliable
- unsafe/a security risk
- resource demanding
- adding too many project dependencies.

=> I actually hardly find an argument speaking for letting rpm work
directly from an SCM.

Ralf





From shambo.linux at gmail.com  Fri Oct 10 05:12:18 2008
From: shambo.linux at gmail.com (Shambo Bose)
Date: Fri, 10 Oct 2008 10:42:18 +0530
Subject: Regarding install options
Message-ID: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>

Hi,

I think if possible the fedora installer can be modified to present two
install option to the user :

1. Desktop Install.

2. Server Install.

Thanks.


regards,

Shambo Bose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/480d1eb1/attachment.htm>

From konrad at tylerc.org  Fri Oct 10 05:28:57 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 9 Oct 2008 22:28:57 -0700
Subject: Regarding install options
In-Reply-To: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
Message-ID: <200810092228.57923.konrad@tylerc.org>

On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
> Hi,
>
> I think if possible the fedora installer can be modified to present two
> install option to the user :
>
> 1. Desktop Install.
>
> 2. Server Install.
>
> Thanks.
>
>
> regards,
>
> Shambo Bose

Any user who actually wants a 'Server Install' knows enough to uncheck GNOME, 
X, etc if they don't want them.

-- 
Conrad Meyer <konrad at tylerc.org>




From cdahlin at redhat.com  Fri Oct 10 05:52:02 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 10 Oct 2008 01:52:02 -0400
Subject: Regarding install options
In-Reply-To: <200810092228.57923.konrad@tylerc.org>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<200810092228.57923.konrad@tylerc.org>
Message-ID: <48EEED82.7030508@redhat.com>

Conrad Meyer wrote:
> On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
>   
>> Hi,
>>
>> I think if possible the fedora installer can be modified to present two
>> install option to the user :
>>
>> 1. Desktop Install.
>>
>> 2. Server Install.
>>
>> Thanks.
>>
>>
>> regards,
>>
>> Shambo Bose
>>     
>
> Any user who actually wants a 'Server Install' knows enough to uncheck GNOME, 
> X, etc if they don't want them.
>
>   
Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to 
install Fedora without having GNOME pulled in as a dependency before.

--CJD



From cdahlin at redhat.com  Fri Oct 10 05:55:48 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 10 Oct 2008 01:55:48 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
Message-ID: <48EEEE64.30506@redhat.com>

Dave Airlie wrote:
> On Wed, 2008-10-01 at 18:52 +0200, Jakub Jelinek wrote:
>   
>> Hi!
>>
>>     
>
>   
>> MAKEDEV sources almost 500KB of config files on every invocation, and the
>> inner loop is terribly inefficient.  The second patch allows it to shrink
>> the files to 55KB while expressing the same info and makes the inner loop
>> more efficient.  Depending on how many modprobe and MAKEDEV invocations
>> are done on your box during bootup, this can or might not make meassurable
>> difference.
>>
>>     
>
> I've just pushed MAKEDEV 3.23-7 into koji should be in rawhide soon.
>
> MAKEDEV is now hosted on git.fedorahosted.org for anyone who cares.
>
> Thanks Jakub.
>
> Dave.
>
>   
Has anyone made any bootcharts? Is there any word on how much this gains 
us at boot time?

--CJD



From konrad at tylerc.org  Fri Oct 10 05:59:28 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 9 Oct 2008 22:59:28 -0700
Subject: Regarding install options
In-Reply-To: <48EEED82.7030508@redhat.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<200810092228.57923.konrad@tylerc.org>
	<48EEED82.7030508@redhat.com>
Message-ID: <200810092259.28480.konrad@tylerc.org>

On Thursday 09 October 2008 10:52:02 pm Casey Dahlin wrote:
> Conrad Meyer wrote:
> > On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
> >> Hi,
> >>
> >> I think if possible the fedora installer can be modified to present two
> >> install option to the user :
> >>
> >> 1. Desktop Install.
> >>
> >> 2. Server Install.
> >>
> >> Thanks.
> >>
> >>
> >> regards,
> >>
> >> Shambo Bose
> >
> > Any user who actually wants a 'Server Install' knows enough to uncheck
> > GNOME, X, etc if they don't want them.
>
> Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to
> install Fedora without having GNOME pulled in as a dependency before.
>
> --CJD

You can always remove it later. It's not a huge deal either way.

-- 
Conrad Meyer <konrad at tylerc.org>




From rc040203 at freenet.de  Fri Oct 10 06:19:52 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 10 Oct 2008 08:19:52 +0200
Subject: Regarding install options
In-Reply-To: <200810092259.28480.konrad@tylerc.org>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<200810092228.57923.konrad@tylerc.org> <48EEED82.7030508@redhat.com>
	<200810092259.28480.konrad@tylerc.org>
Message-ID: <1223619593.3564.1233.camel@beck.corsepiu.local>

On Thu, 2008-10-09 at 22:59 -0700, Conrad Meyer wrote:
> On Thursday 09 October 2008 10:52:02 pm Casey Dahlin wrote:
> > Conrad Meyer wrote:
> > > On Thursday 09 October 2008 10:12:18 pm Shambo Bose wrote:
> > >> Hi,
> > >>
> > >> I think if possible the fedora installer can be modified to present two
> > >> install option to the user :
> > >>
> > >> 1. Desktop Install.
> > >>
> > >> 2. Server Install.
> > >>
> > >> Thanks.
> > >>
> > >>
> > >> regards,
> > >>
> > >> Shambo Bose
> > >
> > > Any user who actually wants a 'Server Install' knows enough to uncheck
> > > GNOME, X, etc if they don't want them.
> >
> > Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to
> > install Fedora without having GNOME pulled in as a dependency before.
> >
> > --CJD
> 
> You can always remove it later. It's not a huge deal either way.

Well, yes, convenience, usability and flexibility aren't necessarily a
strength of Fedora - I regret, but to me, Fedora has developed into a
single user, single seat OS.

Ralf





From kevin.kofler at chello.at  Fri Oct 10 06:36:05 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 10 Oct 2008 06:36:05 +0000 (UTC)
Subject: WIX under Mono
References: <1223592525.15158.92.camel@PB3.Linux>
Message-ID: <loom.20081010T062629-455@post.gmane.org>

Paul <paul <at> all-the-johnsons.co.uk> writes:
> I've been looking at porting WIX to run cleanly under Mono as it would
> be both a useful package for cygwin as well as our friends over at
> Novell (allows them to get the open source goodness of Mono onto Win32).

As you have noticed, this is one of those M$ "Open Source projects" which, 
while technically Free Software themselves, are intentionally designed to be 
both completely useless on anything other than Window$ and dependent on other 
proprietary M$ tools.

> 1. It is reliant on the HTML help 1.4 SDK. I'm not sure if this is a
> binary only app available from MS or not.

It's binary only and Window$ only. It doesn't even work in WINE (or didn't last 
I checked).

> 2. It is reliant on the MSI SDK. Again, not sure if this a binary only
> from MS or not

This is also binary only, and almost certainly Window$ only too (and it may or 
may not work in WINE). And WIX is completely useless without that SDK.

Just so you don't waste your time in the future: If you see an "Open Source 
project" from M$, you can be almost certain it's just an addon for some 
proprietary toolchain, usually M$VC or something related and that it's 
intentionally Window$-only and unfit for cross compilation.

For an actually Free Software generator for Window$ installer which does run on 
Fedora (the generator, not the generated installers - though those do run in 
WINE), look at NSIS. Richard Jones from the MinGW SIG is currently working on 
packaging NSIS.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 10 08:34:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 10 Oct 2008 08:34:59 +0000 (UTC)
Subject: tab completion less useful now, due to sbin in path
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<1223499686.26341.35.camel@localhost.localdomain>
	<1223520853.3564.1147.camel@beck.corsepiu.local>
	<48EDFE03.8020209@gmail.com>
	<1223573111.26341.48.camel@localhost.localdomain>
Message-ID: <loom.20081010T083001-855@post.gmane.org>

Callum Lerwick <seg <at> haxxed.com> writes:
> Wouldn't work. You'd either have one package with a mess of dangling
> symlinks, or you'd need a symlink package per main package which would
> be as much or more work than just putting it in the main package to
> begin with.

That's why Les said "if the target executable doesn't exist you aren't any 
worse off with the symlink than without". Now that's a statement one can agree 
or disagree with. I for one think having stuff in /usr/bin which points nowhere 
is broken and it could actually make tab completion even less useful than the 
status quo (depending on how smart the tab completion is with respect to broken 
symlinks). So I think that, while this wasn't necessarily a bad idea in 
principle, in practice (as you say) it won't work.

        Kevin Kofler



From ivazqueznet at gmail.com  Fri Oct 10 08:46:49 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 10 Oct 2008 04:46:49 -0400
Subject: Tangent: recording upstream scm locations and contact info
In-Reply-To: <20081009235533.GI18785@didacte.laptop.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223568584.4410.101.camel@luminos.localdomain>
	<20081009171143.GB18785@didacte.laptop.org>
	<200810092203.39432.opensource@till.name>
	<20081009235533.GI18785@didacte.laptop.org>
Message-ID: <1223628409.10562.41.camel@ignacio.lan>

On Thu, 2008-10-09 at 19:55 -0400, Michael Stone wrote:
> Does storing the information in packagedb have some compelling benefit
> that compensates for dealing with these hassles by other means?

It means that you don't have to muck through rpm's code in order to add
a tag that will cause older/other versions of rpm to puke.

-- 
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/20081010/db11bf60/attachment.sig>

From ivazqueznet at gmail.com  Fri Oct 10 09:02:49 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 10 Oct 2008 05:02:49 -0400
Subject: Regarding install options
In-Reply-To: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
Message-ID: <1223629369.10562.43.camel@ignacio.lan>

On Fri, 2008-10-10 at 10:42 +0530, Shambo Bose wrote:
> I think if possible the fedora installer can be modified to present
> two install option to the user :
> 
> 1. Desktop Install.
> 
> 2. Server Install.

Sounds like a good candidate for an install spin.

-- 
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/20081010/f2ac6764/attachment.sig>

From paul+fedora at saturnine.org.uk  Fri Oct 10 10:20:25 2008
From: paul+fedora at saturnine.org.uk (Paul Black)
Date: Fri, 10 Oct 2008 11:20:25 +0100
Subject: Regarding install options
In-Reply-To: <200810092259.28480.konrad@tylerc.org>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<200810092228.57923.konrad@tylerc.org> <48EEED82.7030508@redhat.com>
	<200810092259.28480.konrad@tylerc.org>
Message-ID: <a9274eb10810100320q14f8a419yf19795ce56e35543@mail.gmail.com>

2008/10/10 Conrad Meyer <konrad at tylerc.org>

> > Doesn't mean its not a pain in the ass. Hell, its taken me 3 tries to
> > install Fedora without having GNOME pulled in as a dependency before.
> >
> > --CJD
>
> You can always remove it later. It's not a huge deal either way.


Not an ideal scenario for a network install.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/62aae8e1/attachment.htm>

From rawhide at fedoraproject.org  Fri Oct 10 10:35:56 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 10 Oct 2008 10:35:56 +0000 (UTC)
Subject: rawhide report: 20081010 changes
Message-ID: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct 10 06:01:09 UTC 2008

Updated Packages:

anaconda-11.4.1.47-1
--------------------

exaile-0.2.14-1.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 0.2.14-1
- Update to 0.2.14

* Fri Jul 11 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.2.13-3
- fix license tag


gnome-session-2.24.0-8.fc10
---------------------------

jd-2.0.3-0.1.svn2386_trunk.fc10
-------------------------------
* Fri Oct 10 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2386


kdebase-workspace-4.1.2-4.fc10
------------------------------
* Thu Oct  9 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-4
- backport panel autohide from 4.2 / plasma-4.1-openSUSE


kernel-2.6.27-1.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Peter Jones <pjones at redhat.com>
- Fix the return code CD accesses when the CDROM drive door is closed
  but the drive isn't yet ready.

* Thu Oct  9 18:00:00 2008 Eric Sandeen <sandeen at redhat.com>
- Fix for xfs wrongly disabling barriers while running.

* Thu Oct  9 18:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.27-rc9-git2

* Thu Oct  9 18:00:00 2008 Dave Jones <davej at redhat.com>
- 2.6.27

* Thu Oct  9 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
- x86: switch to UP mode when only one CPU is present at boot time


monotorrent-0.50-1.fc10
-----------------------
* Fri Oct 10 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.50-1
- bump to the latest and greatest
- upstream version number fix


nagios-plugins-1.4.13-8.fc10
----------------------------
* Thu Oct  9 18:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.4.13-8
- Rebuilt with a proper patch

* Wed Oct  8 18:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.4.13-7
- Added changed recent permission changes to allow nagios group to execute

* Wed Oct  8 18:00:00 2008 Mike McGrath <mmcgrath at redhat.com> 1.4.13-6
- Fixed up some permission issues


nspr-4.7.1-5.fc10
-----------------
* Thu Oct  9 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 4.7.1-5
- forgot to cvs add patch... whoops. :/

* Thu Oct  9 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 4.7.1-4
- properly handle sparc64 in nspr code


perl-File-Copy-Recursive-0.37-1.fc10
------------------------------------
* Fri Oct 10 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.37-1
- Upstream update.


scim-1.4.7-34.fc10
------------------
* Fri Oct 10 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 1.4.7-34
- require im-chooser (#466252)
- add scim-thai to the Thai meta package


system-config-lvm-1.1.4-3.0.fc10
--------------------------------
* Fri Oct 10 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 1.1.4-3.0
- Fix up BuildRequires

* Thu Oct  9 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 1.1.4-2.0
- Properly install the desktop file (#442910)


thunderbird-2.0.0.17-1.fc10
---------------------------
* Thu Oct  9 18:00:00 2008 Christopher Aillon <caillon at redhat.com> 2.0.0.17-1
- Update to 2.0.0.17


uim-1.5.3-1.fc10
----------------
* Fri Oct 10 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 1.5.3-1
- New upstream release.
- Add im-chooser to Requires again.

* Fri Aug 29 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.5.2-2
- Include directories /usr/share/uim/pixmaps and /usr/share/uim/lib


xl2tpd-1.2.0-1.fc10
-------------------
* Thu Oct  9 18:00:00 2008 Paul Wouters <paul at xelerance.com> - 1.2.0-1
- Updated to new upstream release


xorg-x11-drv-ati-6.9.0-25.fc10
------------------------------
* Fri Oct 10 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-25
- fix rotation
- make output names compatible with non-kms

* Fri Oct 10 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-24
- radeon-modeset.patch - fix silly debugging fallback.

* Fri Oct 10 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-23
- rebase to upstream master
- radeon-6.9.0-lvds-mapping.patch - merged upstream
- copy-fb-contents.patch merged into modesetting tree.


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 16
Broken deps for i386
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.i386 requires libbluetooth.so.2
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.x86_64 requires libbluetooth.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc requires libbluetooth.so.2
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	asterisk-mobile-1.6.0-0.21.beta9.fc10.ppc64 requires libbluetooth.so.2()(64bit)
	livecd-tools-018-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From rjones at redhat.com  Fri Oct 10 10:48:24 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 10 Oct 2008 11:48:24 +0100
Subject: WIX under Mono
In-Reply-To: <1223592525.15158.92.camel@PB3.Linux>
References: <1223592525.15158.92.camel@PB3.Linux>
Message-ID: <20081010104824.GA20271@amd.home.annexia.org>

As Kevin said, I am indeed working on NSIS and a wrapper to make it a
bit easier to use.

Coincidentally I just blogged about this:

http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html

(The NSIS / nsiswrapper stuff is down at the bottom).

As usual you can download all the source from here:

http://hg.et.redhat.com/misc/fedora-mingw--devel/

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From lesmikesell at gmail.com  Fri Oct 10 11:41:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 10 Oct 2008 06:41:54 -0500
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <1223573111.26341.48.camel@localhost.localdomain>
References: <20081001022458.GA14186@jadzia.bu.edu>	<200810052154.15443.ville.skytta@iki.fi>	<1223310667.9987.30.camel@luminos.localdomain>	<200810062051.09666.ville.skytta@iki.fi>	<1223346128.3889.17.camel@code.and.org>	<20081007033633.GA5776@jadzia.bu.edu>	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>	<20081007123307.GA19618@jadzia.bu.edu>	<1223499686.26341.35.camel@localhost.localdomain>	<1223520853.3564.1147.camel@beck.corsepiu.local>	<48EDFE03.8020209@gmail.com>
	<1223573111.26341.48.camel@localhost.localdomain>
Message-ID: <48EF3F82.2000301@gmail.com>

Callum Lerwick wrote:
> On Thu, 2008-10-09 at 07:50 -0500, Les Mikesell wrote:
>> The symlinks could even be a 
>> separate package that people who didn't like the idea could remove. 
>> They don't even need to depend on the target package - if the target 
>> executable doesn't exist you aren't any worse off with the symlink than 
>> without.  Nothing would have to be rebuilt.
> 
> Wouldn't work. You'd either have one package with a mess of dangling
> symlinks, or you'd need a symlink package per main package which would
> be as much or more work than just putting it in the main package to
> begin with.

Yes, putting it in the main package is the correct approach but that 
hasn't been done and doesn't seem that likely.  One package with 
symlinks that might be dangling solves the real problem at the expense 
of possibly annoying a few people who would have the simple option of 
removing the package if they imagine that dangling symlinks are a 
problem.  Are there really installations that don't include ifconfig 
anyway?  How many others are there with common non-root usage?

-- 
    Les Mikesell
     lesmikesell at gmail.com



From dwmw2 at infradead.org  Fri Oct 10 12:28:35 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 10 Oct 2008 13:28:35 +0100
Subject: Disappointed: My feature was removed without notifying me
In-Reply-To: <20081010000140.GA31156@yoda.jdub.homelinux.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
Message-ID: <1223641715.6770.8.camel@macbook.infradead.org>

On Thu, 2008-10-09 at 20:01 -0400, Josh Boyer wrote:
> On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
> >> Let's get the final two packages reviewed -- and that's another area
> >> where we could do with some improvement, because failing to approve
> >> packages really _is_ verging on the 'deletionism' you spoke of. But
> >> that's a separate discussion.
> >
> >Agreed, we can discuss this later. BTW: The word "deletionsm" did not
> >come from me, it was Josh who said that, but of course I agree with him.
> 
> I didn't say that.  Though I agree we need to be getting more packages
> approved.

T'was Richard?. Sorry for the incorrect attribution.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

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




From itamar at ispbrasil.com.br  Fri Oct 10 12:53:40 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Fri, 10 Oct 2008 09:53:40 -0300
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
Message-ID: <48EF5054.3040106@ispbrasil.com.br>

forwarding message from Rodrigo Padula

any chance to increase the life of fedora releases ?

or fedora will be only blending edge ?

In my opinion fedora is losing space from centos and ubuntu


-------- Original Message --------
Subject: 	Wikipidia - Goodbye Red Hat and Fedora
Date: 	Fri, 10 Oct 2008 09:42:55 -0300
From: 	Rodrigo Padula de Oliveira <rodrigopadula at projetofedora.org>
Reply-To: 	For discussions about marketing and expanding the Fedora user 
base <fedora-marketing-list at redhat.com>
To: 	For discussions about marketing and expanding the Fedora user base 
<fedora-marketing-list at redhat.com>



Hello Guys!

Read this bad news:

http://www.linuxworld.com.au/index.php/id;1474805050;fp;16;fpid;1

This is happening frequently. I think we will have to revise some things
within the project, particularly the creation of a Legacy project or a
Fedora LTS.

The brazilian government, one of the biggest Fedora Case of the world is
changing from Fedora/ Red Hat to Ubuntu/Debian.

We need to think and create a solution to give support by a long time or
the fedora user will decrease!

My 0,02

-- 

Rodrigo Padula de Oliveira
M.Sc. Student - COPPE/UFRJ
Fedora Community Manager - Latin America
http://www.proyectofedora.org



-- 
Fedora-marketing-list mailing list
Fedora-marketing-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list






From opensource at till.name  Fri Oct 10 12:28:14 2008
From: opensource at till.name (Till Maas)
Date: Fri, 10 Oct 2008 14:28:14 +0200
Subject: Regarding install options
In-Reply-To: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
Message-ID: <200810101428.15696.opensource@till.name>

On Fri October 10 2008, Shambo Bose wrote:

> I think if possible the fedora installer can be modified to present two
> install option to the user :
>
> 1. Desktop Install.
>
> 2. Server Install.

and

3. Minimal Install

Iirc this can be done somehow with comps, at least I now remeber a discussion 
about providing a "minimal install" options and iirc it was said that this 
could probably be done with comps. But I do not excactly know how.

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/20081010/96d90a08/attachment.sig>

From dwmw2 at infradead.org  Fri Oct 10 13:14:08 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 10 Oct 2008 14:14:08 +0100
Subject: Package review backlog.
In-Reply-To: <1223597573.14070.25.camel@wicktop.localdomain>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
Message-ID: <1223644448.6770.18.camel@macbook.infradead.org>

On Fri, 2008-10-10 at 02:12 +0200, Christoph Wickert wrote:
> Am Donnerstag, den 09.10.2008, 20:01 -0400 schrieb Josh Boyer:
> > On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
> > >> Let's get the final two packages reviewed -- and that's another area
> > >> where we could do with some improvement, because failing to approve
> > >> packages really _is_ verging on the 'deletionism' you spoke of. But
> > >> that's a separate discussion.
> > >
> > >Agreed, we can discuss this later. BTW: The word "deletionsm" did not
> > >come from me, it was Josh who said that, but of course I agree with him.
> > 
> > I didn't say that.  Though I agree we need to be getting more packages
> > approved.
> 
> I think this is something we all agree on. ;)

I propose that each FESCo member should try to work on at least one
package review per week. Each week at the FESCo meeting, we'll ask
members which reviews they've worked on in the past week.

It won't be _mandatory_ -- we're not going to send the boys round to
visit a FESCo member who doesn't do it. But FESCo should be setting a
good example.

And anyone else who considers themselves an active member of the Fedora
development community should also try to do the same. If one a week
isn't realistic due to other commitments, set yourself a more relaxed
target -- like one a fortnight, or one a month, and try to stick to
that.

Too many people (myself included) are just leaving the reviews unloved.

When new contributors submit packages and can't get through the
bureaucracy of getting them reviewed and approved, we are turning away
the very people we should be embracing.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From mark.bidewell at alumni.clemson.edu  Fri Oct 10 13:13:44 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Fri, 10 Oct 2008 09:13:44 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF5054.3040106@ispbrasil.com.br>
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>

I would have to reply that rapid development is one of the reasons I love
Fedora.  Fedora fill a specific niche that fall between a Gentoo/LFS
mentality (although in the past I have seen Fedora RPMs more up to date than
Gentoo Ebuilds) and the superstable world of Debian and RHEL/CentOS.
Ubuntu releases, also fit into this category although they do not move as
rapidly as Fedora.  I would submit that CentOS/RHEL IS the equivalent of
Fedora LTS.  Also, personally I have found Fedora to be more stable than
Ubuntu.  IMOFedora needs to stay true to its purpose, and let the users
choose if that is appropriate for them.

Mark Bidewell

On Fri, Oct 10, 2008 at 8:53 AM, Itamar - IspBrasil <itamar at ispbrasil.com.br
> wrote:

> forwarding message from Rodrigo Padula
>
> any chance to increase the life of fedora releases ?
>
> or fedora will be only blending edge ?
>
> In my opinion fedora is losing space from centos and ubuntu
>
>
> -------- Original Message --------
> Subject:        Wikipidia - Goodbye Red Hat and Fedora
> Date:   Fri, 10 Oct 2008 09:42:55 -0300
> From:   Rodrigo Padula de Oliveira <rodrigopadula at projetofedora.org>
> Reply-To:       For discussions about marketing and expanding the Fedora
> user base <fedora-marketing-list at redhat.com>
> To:     For discussions about marketing and expanding the Fedora user base
> <fedora-marketing-list at redhat.com>
>
>
>
> Hello Guys!
>
> Read this bad news:
>
> http://www.linuxworld.com.au/index.php/id;1474805050;fp;16;fpid;1
>
> This is happening frequently. I think we will have to revise some things
> within the project, particularly the creation of a Legacy project or a
> Fedora LTS.
>
> The brazilian government, one of the biggest Fedora Case of the world is
> changing from Fedora/ Red Hat to Ubuntu/Debian.
>
> We need to think and create a solution to give support by a long time or
> the fedora user will decrease!
>
> My 0,02
>
> --
>
> Rodrigo Padula de Oliveira
> M.Sc. Student - COPPE/UFRJ
> Fedora Community Manager - Latin America
> http://www.proyectofedora.org
>
>
>
> --
> Fedora-marketing-list mailing list
> Fedora-marketing-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-marketing-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/20081010/1e80b831/attachment.htm>

From jwboyer at gmail.com  Fri Oct 10 13:13:51 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 10 Oct 2008 09:13:51 -0400
Subject: rawhide report: 20081010 changes
In-Reply-To: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>
References: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>
Message-ID: <20081010131351.GA12035@yoda.jdub.homelinux.org>

On Fri, Oct 10, 2008 at 10:35:56AM +0000, Rawhide Report wrote:
>Compose started at Fri Oct 10 06:01:09 UTC 2008
>kernel-2.6.27-1.fc10
>--------------------
>* Thu Oct  9 18:00:00 2008 Peter Jones <pjones at redhat.com>
>- Fix the return code CD accesses when the CDROM drive door is closed
>  but the drive isn't yet ready.
>
>* Thu Oct  9 18:00:00 2008 Eric Sandeen <sandeen at redhat.com>
>- Fix for xfs wrongly disabling barriers while running.
>
>* Thu Oct  9 18:00:00 2008 Dave Jones <davej at redhat.com>
>- 2.6.27-rc9-git2
>
>* Thu Oct  9 18:00:00 2008 Dave Jones <davej at redhat.com>
>- 2.6.27
>
>* Thu Oct  9 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com>
>- x86: switch to UP mode when only one CPU is present at boot time

SHENANIGANS!

I think whatever script is creating this is screwing up the
ordering and timestamps of the changelogs.  Every timestamp for
every package is 18:00:00, which cannot possibly be true.

josh



From limb at jcomserv.net  Fri Oct 10 13:19:27 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 10 Oct 2008 08:19:27 -0500 (CDT)
Subject: Package review backlog.
In-Reply-To: <1223644448.6770.18.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
Message-ID: <31489.198.175.55.5.1223644767.squirrel@mail.jcomserv.net>


> On Fri, 2008-10-10 at 02:12 +0200, Christoph Wickert wrote:
>> Am Donnerstag, den 09.10.2008, 20:01 -0400 schrieb Josh Boyer:
>> > On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
>> > >> Let's get the final two packages reviewed -- and that's another
>> area
>> > >> where we could do with some improvement, because failing to approve
>> > >> packages really _is_ verging on the 'deletionism' you spoke of. But
>> > >> that's a separate discussion.
>> > >
>> > >Agreed, we can discuss this later. BTW: The word "deletionsm" did not
>> > >come from me, it was Josh who said that, but of course I agree with
>> him.
>> >
>> > I didn't say that.  Though I agree we need to be getting more packages
>> > approved.
>>
>> I think this is something we all agree on. ;)
>
> I propose that each FESCo member should try to work on at least one
> package review per week. Each week at the FESCo meeting, we'll ask
> members which reviews they've worked on in the past week.
>
> It won't be _mandatory_ -- we're not going to send the boys round to
> visit a FESCo member who doesn't do it. But FESCo should be setting a
> good example.
>
> And anyone else who considers themselves an active member of the Fedora
> development community should also try to do the same. If one a week
> isn't realistic due to other commitments, set yourself a more relaxed
> target -- like one a fortnight, or one a month, and try to stick to
> that.
>
> Too many people (myself included) are just leaving the reviews unloved.
>
> When new contributors submit packages and can't get through the
> bureaucracy of getting them reviewed and approved, we are turning away
> the very people we should be embracing.

+A lot.

> --
> David Woodhouse                            Open Source Technology Centre
> David.Woodhouse at intel.com                              Intel Corporation
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From casimiro.barreto at gmail.com  Fri Oct 10 13:32:46 2008
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 10 Oct 2008 10:32:46 -0300
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF5054.3040106@ispbrasil.com.br>
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <48EF597E.9050805@gmail.com>

Itamar - IspBrasil escreveu:
> forwarding message from Rodrigo Padula
>
> any chance to increase the life of fedora releases ?
>
> or fedora will be only blending edge ?
>
> In my opinion fedora is losing space from centos and ubuntu
>
>
> -------- Original Message --------
But that's not all. Besides increasing life of releases it is important
to keep things working between updates (currently that's not the case)
and taking care of reported bugs before introducing new features and/or
advancing versions. Few examples:

    * GDM: the "bleeding edge" version was adopted in Rel 9. But there
      is no documentation on how to properly configure it. So, it you
      want to allow remote  applications to open windows in your desktop
      you have to migrate to KDM (no way to get rid of the -nolisten in
      GDM).
    * RHGB  that is scheduled to disappear stop working after I updated
      system 1 1/2 month ago.
    * pam_mount stop working properly about 2 months ago.
    * ...

Obviously this kind of situation prevents the use of Fedora in critical
mission environments and makes the distribution more attractive to geeks
that can expend unpayed hours bringing back to life things that were
already working.

CdAB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/6fd74120/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/6fd74120/attachment.sig>

From christoph.wickert at googlemail.com  Fri Oct 10 13:33:33 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 10 Oct 2008 15:33:33 +0200
Subject: Package review backlog.
In-Reply-To: <1223644448.6770.18.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
Message-ID: <1223645613.3514.12.camel@wicktop.localdomain>

Am Freitag, den 10.10.2008, 14:14 +0100 schrieb David Woodhouse:

> I propose that each FESCo member should try to work on at least one
> package review per week. Each week at the FESCo meeting, we'll ask
> members which reviews they've worked on in the past week.
>
> It won't be _mandatory_ -- 
[snipped] 

As a rule of thumb it's ok, but it should not be mandatory. I think the
FESCo members are already having a lot of work to do and I'm not sure if
everybody has enough spare time for reviews.

But perhaps we should think about making your proposal mandatory for
sponsors and - more important - for people who want to become a sponsor.

Christoph



From buc at odusz.so-cdu.ru  Fri Oct 10 13:33:47 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Fri, 10 Oct 2008 17:33:47 +0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF5054.3040106@ispbrasil.com.br>
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <48EF59BB.7000205@odu.neva.ru>

Itamar - IspBrasil wrote:
>
> any chance to increase the life of fedora releases ?
>
> or fedora will be only blending edge ?
>
> In my opinion fedora is losing space from centos and ubuntu

...

> The brazilian government, one of the biggest Fedora Case of the world is
> changing from Fedora/ Red Hat to Ubuntu/Debian.

The problem was at an initial point, when Fedora was considered "for 
enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just 
switch to CentOS (and similar RHEL-based systems), no more using Fedora, 
because "it is marked as a non-for-production system even by its creators".

As a result, the amount of Fedora-testers in real production 
environments significantly decreases. Fedora development seems to be 
focused on Desktop and some conseptual things now, rather than a real 
"production" life. Perhaps some marketing people assume that 
"production" implies the purchase of RHEL and commercial support, rather 
than trying to use some free-of-charge system, because such a system 
should be unstable for production environment. But people do not want to 
pay and they use CentOS instead...

This situation seems to be reflected in the Fedora project itself. 
Guess, how many Fedora infrastructure servers are run under the latest 
"stable" Fedora release? Maybe some previois release? How many key 
people work under Fedora Desktop "all the time"? (Maybe RedHat employees 
of them are compelled to use RHEL Desktop in basic working hours?)

And finally, when you will discover the actual situation, ask yourself 
-- why Brasilian should use Fedora (and Fedora-based RHEL), when even 
Fedora's fathers do not use it for anything real?


Sorry for a little bit sarcasm though...

~buc



From denis at poolshark.org  Fri Oct 10 13:44:07 2008
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 10 Oct 2008 15:44:07 +0200
Subject: rawhide report: 20081010 changes
In-Reply-To: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>
References: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>
Message-ID: <48EF5C27.9000004@poolshark.org>

Rawhide Report wrote:
> gnome-session-2.24.0-8.fc10
> ---------------------------

and that empty changelog should read:

"Fix assertion failure in last patch"

which caused desktop crash when clicking the start button 
(https://bugzilla.redhat.com/show_bug.cgi?id=466444).



From katzj at redhat.com  Fri Oct 10 13:46:46 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 10 Oct 2008 09:46:46 -0400
Subject: Tangent: recording upstream scm locations and contact info
In-Reply-To: <1223628409.10562.41.camel@ignacio.lan>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223568584.4410.101.camel@luminos.localdomain>
	<20081009171143.GB18785@didacte.laptop.org>
	<200810092203.39432.opensource@till.name>
	<20081009235533.GI18785@didacte.laptop.org>
	<1223628409.10562.41.camel@ignacio.lan>
Message-ID: <1223646406.19673.178.camel@aglarond.local>

On Fri, 2008-10-10 at 04:46 -0400, Ignacio Vazquez-Abrams wrote:
> On Thu, 2008-10-09 at 19:55 -0400, Michael Stone wrote:
> > Does storing the information in packagedb have some compelling benefit
> > that compensates for dealing with these hassles by other means?
> 
> It means that you don't have to muck through rpm's code in order to add
> a tag that will cause older/other versions of rpm to puke.

Adding tags actually doesn't make older versions of rpm puke, it just
ignores them

Jeremy



From jarod at redhat.com  Fri Oct 10 13:58:35 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Fri, 10 Oct 2008 09:58:35 -0400
Subject: Dead or alive package [Fwd: [Bug 465111] New: 
 FTBFS	bluez-utils-3.36-2.fc10]
In-Reply-To: <loom.20081009T031655-787@post.gmane.org>
References: <1223512641.24710.17.camel@cookie.hadess.net>
	<200810082051.51087.jarod@redhat.com>
	<loom.20081009T031655-787@post.gmane.org>
Message-ID: <200810100958.35836.jarod@redhat.com>

On Wednesday 08 October 2008 23:17:32 Kevin Kofler wrote:
> Jarod Wilson <jarod <at> redhat.com> writes:
> > I thought it was marked dead.package, because bluez-utils was obsoleted
> > by bluez or something like that, not because of the FTBFS bug.
>
> Sure, but it's kinda pointless to fix bugs in an obsolete package. ;-)

I had the impression Bastien was asking if the package had been marked dead 
because of the FTBFS bug. I probably mis-parsed something though.

-- 
Jarod Wilson
jarod at redhat.com



From rms at 1407.org  Fri Oct 10 13:58:41 2008
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Fri, 10 Oct 2008 14:58:41 +0100
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF597E.9050805@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF597E.9050805@gmail.com>
Message-ID: <20081010135841.GS16039@roque.1407.org>

>     * GDM: the "bleeding edge" version was adopted in Rel 9. But there
>       is no documentation on how to properly configure it. So, it you
>       want to allow remote  applications to open windows in your desktop
>       you have to migrate to KDM (no way to get rid of the -nolisten in
>       GDM).

Using "-nolisten tcp" by default Is Good.

Yes you can get it back if you have a strong reason (like you seem to
have) for it :)

If you have a strong reason for it, then you're in a very small minority
of more advanced users :)

Rui

-- 
Fnord.
Today is Pungenday, the 64th day of Bureaucracy in the YOLD 3174
+ 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 buc at odusz.so-cdu.ru  Fri Oct 10 14:03:30 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Fri, 10 Oct 2008 18:03:30 +0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <20081009180319.GA25325@nostromo.devel.redhat.com>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
Message-ID: <48EF60B2.4040708@odu.neva.ru>

Bill Nottingham wrote:
> We currently display Arabic and Hebrew translations on the virtual
> console in LTR mode using the glyphs in latarcyrheb-sun16. Obviously,
> that's not the preferred way.
>   

I would like to describe some related issue here.

Since RedHat Linux 8, "latarcyrherb-sun16"  is the default console font. 
It seems that it was chosen in assumption that 
ascii+latin+cyrillic+hebrew+arabic in one a font should satisfy all the 
needs of console users.

But "latarcyrheb-sun16" is so-called 512-glyphs font. Unfortunately, 
there is a restriction in hardware, which decreases the amount of 
available console colors if console font has more than 256 glyphs.

As a result, people who (for some reasons) use TUI on console have no 
yellow and bolding anymore.

The solution looks simple -- just change the default "latarcyrheb-sun16" 
to some old good 256-gliph font. It is an obvious thing, especially in 
fact that actually the "latin+cyrillic+hebrew+arabic" combination seems 
never used in a real life of console. What seems to be used is just 
"ascii + local native language" (ie. ascii+latin1, ascii+cyrillic etc.), 
and such combinations do not exceed 256-glyph limit.

But the switch to some of old 256-glyph fonts leads to lack of some  
glyphs (fe. euro sign) which became needed now. Hence it would be fine 
to split latarcyrheb-sun16 to several 256-glyphs fonts and use such 
fonts by default on console.


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From pertusus at free.fr  Fri Oct 10 14:06:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 10 Oct 2008 16:06:36 +0200
Subject: Package review backlog.
In-Reply-To: <1223645613.3514.12.camel@wicktop.localdomain>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
Message-ID: <20081010140636.GA3236@free.fr>

On Fri, Oct 10, 2008 at 03:33:33PM +0200, Christoph Wickert wrote:
> Am Freitag, den 10.10.2008, 14:14 +0100 schrieb David Woodhouse:
> 
> > I propose that each FESCo member should try to work on at least one
> > package review per week. Each week at the FESCo meeting, we'll ask
> > members which reviews they've worked on in the past week.
> >
> > It won't be _mandatory_ -- 
> [snipped] 
> 
> But perhaps we should think about making your proposal mandatory for
> sponsors and - more important - for people who want to become a sponsor.

This is taken into account in (secret) discussions about sponsors. Maybe
not enough, but as far as I can tell most sponsors have a good record of
reviews. There are certainly exception, but considering that the 3 who
do many reviews are sponsors, the balance for sponsors is very
positive... But it has to be that way, because it is easier to submit
packages than to do review (in my opinion) so experienced people should 
have a positive balance if things are to work smoothly.

--
Pat



From jeff at ocjtech.us  Fri Oct 10 14:08:55 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Fri, 10 Oct 2008 09:08:55 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF59BB.7000205@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
Message-ID: <935ead450810100708j6935696erd242e9d9250d0376@mail.gmail.com>

On Fri, Oct 10, 2008 at 8:33 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
>
> This situation seems to be reflected in the Fedora project itself. Guess,
> how many Fedora infrastructure servers are run under the latest "stable"
> Fedora release?

Almost none.  The reason is simple - the Fedora project does not have
infinite resources, the most important of which is time.  As can be
seen from the recent intrusion, completely rebuilding the
infrastructure takes a lot of time and causes a lot of pain.  It's a
better use of human resources to use RHEL in the Fedora Infrastructure
so we don't have to be continually rebuilding systems and we can focus
our time on other things.

> And finally, when you will discover the actual situation, ask yourself --
> why Brasilian should use Fedora (and Fedora-based RHEL),
> when even Fedora's fathers do not use it for anything real?

What do you mean by "real" - I sit in front of Fedora systems almost
all day long.  Why doesn't that count as "real"?

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From jonstanley at gmail.com  Fri Oct 10 14:13:57 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 10 Oct 2008 10:13:57 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF59BB.7000205@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
Message-ID: <da159fda0810100713x2d9c2e8ch339124e2510a930d@mail.gmail.com>

On Fri, Oct 10, 2008 at 9:33 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:

> The problem was at an initial point, when Fedora was considered "for
> enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just switch
> to CentOS (and similar RHEL-based systems), no more using Fedora, because
> "it is marked as a non-for-production system even by its creators".

Well, in all fairness, Fedora's stated goal is to advance the state of
free software. You get that by being bleeding-edge. Unfortunately,
being bleeding edge also means not being suitable for production
environments - these are two fundamentally incompatible goals. This is
why Red Hat Linux split into two - Fedora and RHEL. RHEL is a
derivative distribution of Fedora.

> As a result, the amount of Fedora-testers in real production environments
> significantly decreases. Fedora development seems to be focused on Desktop
> and some conseptual things now, rather than a real "production" life.

There's plenty of stuff going into Fedora aimed at production systems.
Take for example FreeIPA for one. It started life in Fedora quite a
while back, and is now Red Hat Enterprise IPA. That's just one
example. Others are:

SELinux
LVM2
Xen
Tickless kernel (I'd bet good money we'll be seeing it in RHEL6)

We're also working on getting Spacewalk into Fedora, which is neither
aimed at desktop users nor a "conceptual" thing. Fedora exists to
foster innovation, with this mission sometimes comes breakage. We
simply want to prepare folks for that.;

> Perhaps some marketing people assume that "production" implies the purchase
> of RHEL and commercial support, rather than trying to use some
> free-of-charge system, because such a system should be unstable for
> production environment. But people do not want to pay and they use CentOS
> instead..

That's fine.  The problem is not "marketing" that Fedora is viewed as
unstable for production use (and let me clarify the word production
here - something that you need up 24/7/365), it's technical. As I
stated before, the stated goals of Fedora are incompatible with
production use as I have defined it.
.
> This situation seems to be reflected in the Fedora project itself. Guess,
> how many Fedora infrastructure servers are run under the latest "stable"
> Fedora release? Maybe some previois release? How many key people work under

Not many, they are mostly RHEL (actually none that I personally know
of, but I think that the systems that create livecd's have to be if
I'm not mistaken), for exactly the reasons stated before.

> Fedora Desktop "all the time"? (Maybe RedHat employees of them are compelled
> to use RHEL Desktop in basic working hours?)

I'm not a Red Hat employee, but I'm pretty sure that they aren't
"compelled" to do anything. And lots of developers that I know run
rawhide all the time. A quick rundown of my machines at home:

Main desktop: Fedora 8

Main laptop: Fedora 9

Testing laptop: rawhide du jour

VM server: RHEL5.2 (may change this to F9 and kvm in the near future),
experiencing some weird Xen issues relating to Fedora testing.

DNS/DHCP: CentOS 4.6

VM's - depends on what they do :)

> And finally, when you will discover the actual situation, ask yourself --
> why Brasilian should use Fedora (and Fedora-based RHEL), when even Fedora's
> fathers do not use it for anything real?

Define "anything real". Of course it's used for real stuff. I'm
writing this on my F9 laptop right now.



From mcepl at redhat.com  Fri Oct 10 14:11:12 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 10 Oct 2008 16:11:12 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <0d44s5x8co.ln2@ppp1053.in.ipex.cz>

On 2008-10-10, 12:53 GMT, Itamar - IspBrasil wrote:
> In my opinion fedora is losing space from centos and ubuntu

a) If we are loosing to CentOS (which is a derivative of RHEL) 
   then there is no loss to our community.
b) If anybody is running production servers on Fedora, then worse 
   for him -- Fedora is a developers' distro and that's the 
   reason why it has limited support. If you think you want to 
   revive Fedora Legacy project (which died for disinterest of 
   its users), then I would suggest that you join CentOS -- I am 
   quite certain they can use as many people helping as possible.
c) Concerning Ubuntu. I am a Red Hat employee so I shouldn't talk 
   lightly about our competition, so let me add only this 
   thought.  If you compare current Ubuntu with current Fedora 
   (or maybe previous version of Fedora, because we tend to be 
   slightly ahead -- which is both good and bad) then difference 
   is only minimal.  What I would be much more interested is 
   difference between support for six years old distro (RHEL 
   2.1AS was released on 2002-03-26) on RHEL and Ubuntu. Yes, 
   I know, there is no six-years old Ubuntu, and there never will 
   be (LTS support is only five years on servers).
       However, still I would be interested in the level of 
   support for Dapper Drake (6.06) now comparing with the level 
   of support we provide for RHEL5 (that's roughly the same age, 
   right?). How many patches in the last six months went to 
   Dapper? I see on packages.ubuntu.com/firefox they still have 
   firefox 1.5 (we have 3.* even for RHEL3). Supporting old 
   distro is a huge undertaking (what about fixing bugs in kernel 
   2.4.9? That's is what we have in RHEL 2.1 -- and yes I see in
   our internal systems build from the last month, so it is still
   maintained) and jury is still out, whether Canonical will be 
   able to do it.

Best,

Matej



From rjones at redhat.com  Fri Oct 10 14:22:34 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 10 Oct 2008 15:22:34 +0100
Subject: Package review backlog.
In-Reply-To: <1223644448.6770.18.camel@macbook.infradead.org>
References: <loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
Message-ID: <20081010142234.GA21510@amd.home.annexia.org>

On Fri, Oct 10, 2008 at 02:14:08PM +0100, David Woodhouse wrote:
> I propose that each FESCo member should try to work on at least one
> package review per week. Each week at the FESCo meeting, we'll ask
> members which reviews they've worked on in the past week.
[...]
> And anyone else who considers themselves an active member of the Fedora
> development community should also try to do the same. If one a week
> isn't realistic due to other commitments, set yourself a more relaxed
> target -- like one a fortnight, or one a month, and try to stick to
> that.

I think this is an excellent idea.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From hughsient at gmail.com  Fri Oct 10 14:18:56 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 10 Oct 2008 15:18:56 +0100
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF59BB.7000205@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
Message-ID: <1223648336.3379.39.camel@hughsie-laptop>

On Fri, 2008-10-10 at 17:33 +0400, Dmitry Butskoy wrote:
> Maybe RedHat employees of them are compelled to use RHEL Desktop in
> basic working hours?

No. I spend 99% of my time in F9 or rawhide.

Richard.




From buc at odusz.so-cdu.ru  Fri Oct 10 14:23:22 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Fri, 10 Oct 2008 18:23:22 +0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <935ead450810100708j6935696erd242e9d9250d0376@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<935ead450810100708j6935696erd242e9d9250d0376@mail.gmail.com>
Message-ID: <48EF655A.3040504@odu.neva.ru>

Jeffrey Ollie wrote:
> On Fri, Oct 10, 2008 at 8:33 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
>   
>> This situation seems to be reflected in the Fedora project itself. Guess,
>> how many Fedora infrastructure servers are run under the latest "stable"
>> Fedora release?
>>     
>
> Almost none.  The reason is simple - the Fedora project does not have
> infinite resources, the most important of which is time.  As can be
> seen from the recent intrusion, completely rebuilding the
> infrastructure takes a lot of time and causes a lot of pain.  It's a
> better use of human resources to use RHEL in the Fedora Infrastructure
> so we don't have to be continually rebuilding systems 

I would prefer that Fedora would be stable enough, thus does not require 
"continually rebuilding systems" ;)

When the infrastructure of some distribution use this distribution 
immediately, the quality of the distribution is compelled to be much 
higher. In other words, when you create a bug, it is much better when 
this bug strikes your head at the same time, rather than someone will 
report it in bugzilla, where it will be delayed for a long time...


~buc



From pemboa at gmail.com  Fri Oct 10 14:27:01 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 09:27:01 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF5054.3040106@ispbrasil.com.br>
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <16de708d0810100727s1d5bac1du97d8ab01183d9d7b@mail.gmail.com>

On Fri, Oct 10, 2008 at 7:53 AM, Itamar - IspBrasil
<itamar at ispbrasil.com.br> wrote:
> forwarding message from Rodrigo Padula
>
> any chance to increase the life of fedora releases ?
>
> or fedora will be only blending edge ?
>
> In my opinion fedora is losing space from centos and ubuntu
>


Markets like that should be using Centos. I have no opinion on Ubuntu,
except that I don't personally feel they contribute enough to the
community.

According to the article, these people were using Fedora and Redhat 9.
Based on that they probably have been using some EOLed Fedora for
years now. In which switching to an updated Ubuntu is much better.
Ideally, they should have switched to Centos however.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pemboa at gmail.com  Fri Oct 10 14:30:21 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 09:30:21 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF5054.3040106@ispbrasil.com.br>
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <16de708d0810100730m27a99778xb6bde3f30e3c2e5f@mail.gmail.com>

On Fri, Oct 10, 2008 at 7:53 AM, Itamar - IspBrasil
<itamar at ispbrasil.com.br> wrote:
> forwarding message from Rodrigo Padula
>
> any chance to increase the life of fedora releases ?
>
> or fedora will be only blending edge ?
>
> In my opinion fedora is losing space from centos and ubuntu


Reading the article again, no mention was made of Centos. Only Fedora
and RedHat were considered. They didn't want to pay, but didn't
consider Centos. That leads me to believe that whoever was making the
decision before knew that they wanted Ubuntu and just  gave a
justification after the fact -- which is really their right, but
misleading of them.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pertusus at free.fr  Fri Oct 10 14:31:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 10 Oct 2008 16:31:37 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>
Message-ID: <20081010143137.GB3236@free.fr>

On Fri, Oct 10, 2008 at 09:13:44AM -0400, Mark Bidewell wrote:
> I would have to reply that rapid development is one of the reasons I love
> Fedora.  Fedora fill a specific niche that fall between a Gentoo/LFS
> mentality (although in the past I have seen Fedora RPMs more up to date than
> Gentoo Ebuilds) and the superstable world of Debian and RHEL/CentOS.
> Ubuntu releases, also fit into this category although they do not move as
> rapidly as Fedora.  I would submit that CentOS/RHEL IS the equivalent of
> Fedora LTS.  Also, personally I have found Fedora to be more stable than
> Ubuntu.  IMOFedora needs to stay true to its purpose, and let the users
> choose if that is appropriate for them.

I mostly agree, however it seems to me that a true Fedora LTS is
missing, that would allow those who want things that are new, including 
for testing but cannot afford changing everything each year (servers for 
example or user desktops). It seems to me that fedora ends up being used
almost exclusively as single user desktop, so that testing of other
functionalities is likely to be less widespread. Fortunately, those
functionnalities certainly need less integration and so less testing in
fedora before they go to RHEL/CENTOS + EPEL, but still it would
certainly have some relevance, in my opinion.

--
Pat



From hughsient at gmail.com  Fri Oct 10 14:18:56 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 10 Oct 2008 15:18:56 +0100
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF59BB.7000205@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
Message-ID: <1223648336.3379.39.camel@hughsie-laptop>

On Fri, 2008-10-10 at 17:33 +0400, Dmitry Butskoy wrote:
> Maybe RedHat employees of them are compelled to use RHEL Desktop in
> basic working hours?

No. I spend 99% of my time in F9 or rawhide.

Richard.




From buc at odusz.so-cdu.ru  Fri Oct 10 14:36:43 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Fri, 10 Oct 2008 18:36:43 +0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <0d44s5x8co.ln2@ppp1053.in.ipex.cz>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
Message-ID: <48EF687B.9090407@odu.neva.ru>

Matej Cepl wrote:
> b) If anybody is running production servers on Fedora, then worse 
>    for him 

Well, how about enthusiasm here?

What should do some previously RedHat-oriented enthusiast, when all the 
area for application of his enthusiasm is some "production environment"? 
Use RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS 
is far from the "bleeding edge", hence his enthusiasm just disappear...


~buc



From pemboa at gmail.com  Fri Oct 10 14:39:17 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 09:39:17 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF687B.9090407@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
Message-ID: <16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>

On Fri, Oct 10, 2008 at 9:36 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> Matej Cepl wrote:
>>
>> b) If anybody is running production servers on Fedora, then worse   for
>> him
>
> Well, how about enthusiasm here?
>
> What should do some previously RedHat-oriented enthusiast, when all the area
> for application of his enthusiasm is some "production environment"? Use
> RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS is far
> from the "bleeding edge", hence his enthusiasm just disappear...



I don't understand what you're saying. Why do you need to be
bleeding-edge in your stable environments?



-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From casimiro.barreto at gmail.com  Fri Oct 10 14:44:03 2008
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 10 Oct 2008 11:44:03 -0300
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010135841.GS16039@roque.1407.org>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF597E.9050805@gmail.com>
	<20081010135841.GS16039@roque.1407.org>
Message-ID: <48EF6A33.2040509@gmail.com>

Rui Miguel Silva Seabra escreveu:
> Using "-nolisten tcp" by default Is Good.
> Yes you can get it back if you have a strong reason (like you seem to
> have) for it :)
>
> If you have a strong reason for it, then you're in a very small minority
> of more advanced users :)
>
> Rui
>
>   
I agree about the security issue. That's not the point. The point is
that something documented was changed by something undocumented that
just doesn't work like the previous version.

Besides, I think that the discussion about "real environments" and
"development environments" is merely academic. I think that for unstable
and undocumented features the right place is the rawhide repository.
When something migrates from rawhide to the mainstream release/update
repositories then it should provide a nice migration.

I agree that Fedora is aimed to development. But not everybody is
developing everything and having to stop what you're doing (especially
if you have only a limited amount of time available) to
reconfigure/retrofit something that was previously working is annoying
and counterproductive.

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

From pertusus at free.fr  Fri Oct 10 14:44:26 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 10 Oct 2008 16:44:26 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <0d44s5x8co.ln2@ppp1053.in.ipex.cz>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081010144426.GC3236@free.fr>

On Fri, Oct 10, 2008 at 04:11:12PM +0200, Matej Cepl wrote:
> On 2008-10-10, 12:53 GMT, Itamar - IspBrasil wrote:
> > In my opinion fedora is losing space from centos and ubuntu
> 
> b) If anybody is running production servers on Fedora, then worse 
>    for him -- Fedora is a developers' distro and that's the 
>    reason why it has limited support. If you think you want to 
>    revive Fedora Legacy project (which died for disinterest of 
>    its users), then I would suggest that you join CentOS -- I am 
>    quite certain they can use as many people helping as possible.

Fedora legacy (or fedora lts) would not be the same than centos. Maybe a
Centos + repository with more recent stuff would be, but currently I
think that there is something in the middle between fedora and centos
that is missing. Now it may very well be possible that there is not
enough interested users to make that distro, but there is also a lack of
support from the boards. Some months ago I proposed something for a
fedora lts that was brought down, maybe for good reasons, but the tone
of the discussions really showed very few support, and I'd even say some
antagonism.

--
Pat



From buc at odusz.so-cdu.ru  Fri Oct 10 14:52:11 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Fri, 10 Oct 2008 18:52:11 +0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>
	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
Message-ID: <48EF6C1B.4060400@odu.neva.ru>

Arthur Pemberton wrote:
> On Fri, Oct 10, 2008 at 9:36 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
>   
>> Matej Cepl wrote:
>>     
>>> b) If anybody is running production servers on Fedora, then worse   for
>>> him
>>>       
>> Well, how about enthusiasm here?
>>
>> What should do some previously RedHat-oriented enthusiast, when all the area
>> for application of his enthusiasm is some "production environment"? Use
>> RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS is far
>> from the "bleeding edge", hence his enthusiasm just disappear...
>>     
>
>
>
> I don't understand what you're saying. Why do you need to be
> bleeding-edge in your stable environments?
>   

Well, not the "bleeding-edge" literally.

An environment, which is considered stable, can be "untypical". Ie. 
"untypical production stable environment".

All the years RHL/Fedora is used at my work, we was compelled (from time 
to time) to even port some future versions/features of N+1 distro to the 
current N distro. Because the features required for our "untypical" 
environment have appeared somewhere closer to the bleeding-edge...


~buc



From alsadi at gmail.com  Fri Oct 10 15:05:25 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 10 Oct 2008 18:05:25 +0300
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <48EEEE64.30506@redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223527917.3341.22.camel@clockmaker.usersys.redhat.com>
	<48EEEE64.30506@redhat.com>
Message-ID: <385866f0810100805y1b6923c6h256c8944ed5ac801@mail.gmail.com>

I have tested both on the virtual machine,
I built an rpm
www.ojuba.org/testing/module-init-tools-3.4.1-2.oj1.i386.rpm

and it was really fast

but the MAKEDEV gives errors/warnings like this
don't know how to make device "tty2"

here is a screenshot
http://www.linuxac.org/forum/attachment.php?attachmentid=4658&stc=1&d=1223650907



From dwmw2 at infradead.org  Fri Oct 10 14:30:07 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 10 Oct 2008 15:30:07 +0100
Subject: Package review backlog.
In-Reply-To: <1223645613.3514.12.camel@wicktop.localdomain>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
Message-ID: <1223649007.6770.25.camel@macbook.infradead.org>

On Fri, 2008-10-10 at 15:33 +0200, Christoph Wickert wrote:
> Am Freitag, den 10.10.2008, 14:14 +0100 schrieb David Woodhouse:
> 
> > I propose that each FESCo member should try to work on at least one
> > package review per week. Each week at the FESCo meeting, we'll ask
> > members which reviews they've worked on in the past week.
> >
> > It won't be _mandatory_ -- 
> [snipped] 
> 
> As a rule of thumb it's ok, but it should not be mandatory. I think the
> FESCo members are already having a lot of work to do and I'm not sure if
> everybody has enough spare time for reviews.

Absolutely. Besides, if you do call it 'mandatory' you have to start
defining what would happen if people don't comply, and the whole thing
just gets silly.

I'm talking about a 'recommended practice', and just asking people each
week which packages they've looked at. Nothing more.

And even though people are busy, it shouldn't actually take _that_ long
to make progress on reviewing a single package, each week.

> But perhaps we should think about making your proposal mandatory for
> sponsors and - more important - for people who want to become a sponsor.

I'm not sure I'd even go that far. Let's try just raising the profile of
package review first, and see where we get with it.

Might also be useful to send a list to fedora-devel-list periodically
(daily/weekly), listing the packages which are awaiting review.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From mcepl at redhat.com  Fri Oct 10 14:24:45 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 10 Oct 2008 16:24:45 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>
Message-ID: <d654s5x9eo.ln2@ppp1053.in.ipex.cz>

On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
> I would submit that CentOS/RHEL IS the equivalent of
> Fedora LTS.

I would venture even to say that CentOS *is* Fedora LTS, and (I 
am not sure whether they would agree, having apparently some bad 
experience with PNALD) that they are part of the "Fedora family 
of distributions" as its long-term-supported member.

Matej



From pemboa at gmail.com  Fri Oct 10 15:13:14 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 10:13:14 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF6C1B.4060400@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
	<48EF6C1B.4060400@odu.neva.ru>
Message-ID: <16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>

On Fri, Oct 10, 2008 at 9:52 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> Arthur Pemberton wrote:
>>
>> On Fri, Oct 10, 2008 at 9:36 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru>
>> wrote:
>>
>>>
>>> Matej Cepl wrote:
>>>
>>>>
>>>> b) If anybody is running production servers on Fedora, then worse   for
>>>> him
>>>>
>>>
>>> Well, how about enthusiasm here?
>>>
>>> What should do some previously RedHat-oriented enthusiast, when all the
>>> area
>>> for application of his enthusiasm is some "production environment"? Use
>>> RHEL/CentOS anywhere and Fedora on his laptop only? But RHEL/CentOS is
>>> far
>>> from the "bleeding edge", hence his enthusiasm just disappear...
>>>
>>
>>
>>
>> I don't understand what you're saying. Why do you need to be
>> bleeding-edge in your stable environments?
>>
>
> Well, not the "bleeding-edge" literally.
>
> An environment, which is considered stable, can be "untypical". Ie.
> "untypical production stable environment".
>
> All the years RHL/Fedora is used at my work, we was compelled (from time to
> time) to even port some future versions/features of N+1 distro to the
> current N distro. Because the features required for our "untypical"
> environment have appeared somewhere closer to the bleeding-edge...


Sounds like you want Centos + Extras then. Or maybe Extras isn't up to
date enough, and some people may need to create a new 'Current' repo
for Centos.

The closest I've come to wanting something "new" in Centos was wanting
a 2.4.3 (or so) Python instead of the 2.4.2 (or so) that comes with
RHEL/Centos. And that was easily avoided.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mcepl at redhat.com  Fri Oct 10 15:10:29 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 10 Oct 2008 17:10:29 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
Message-ID: <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>

On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
> What should do some previously RedHat-oriented enthusiast, when 
> all the area for application of his enthusiasm is some 
> "production environment"?  Use RHEL/CentOS anywhere and Fedora 
> on his laptop only? But RHEL/CentOS is far from the "bleeding 
> edge", hence his enthusiasm just disappear...

Think about that and repeat until you get it -- "distro is either 
bleeding-edge or stable; tercium non datur".

Matej



From pertusus at free.fr  Fri Oct 10 15:17:57 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 10 Oct 2008 17:17:57 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
	<48EF6C1B.4060400@odu.neva.ru>
	<16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
Message-ID: <20081010151757.GD3236@free.fr>

On Fri, Oct 10, 2008 at 10:13:14AM -0500, Arthur Pemberton wrote:
> 
> Sounds like you want Centos + Extras then. Or maybe Extras isn't up to
> date enough, and some people may need to create a new 'Current' repo
> for Centos.

If you are referring to EPEL with Extras, EPEL should not move faster
than RHEL, and, as far as I can tell, a 'Current' repo for Centos
doesn't exist.

--
Pat



From buc at odusz.so-cdu.ru  Fri Oct 10 15:22:07 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Fri, 10 Oct 2008 19:22:07 +0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru> <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
Message-ID: <48EF731F.40209@odu.neva.ru>

Matej Cepl wrote:
> On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
>   
>> What should do some previously RedHat-oriented enthusiast, when 
>> all the area for application of his enthusiasm is some 
>> "production environment"?  Use RHEL/CentOS anywhere and Fedora 
>> on his laptop only? But RHEL/CentOS is far from the "bleeding 
>> edge", hence his enthusiasm just disappear...
>>     
>
> Think about that and repeat until you get it -- "distro is either 
> bleeding-edge or stable; tercium non datur".
>   

Kinda black-white mentality?  ;)


~buc



From alsadi at gmail.com  Fri Oct 10 15:23:33 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 10 Oct 2008 18:23:33 +0300
Subject: Arabic and Hebrew on the console
In-Reply-To: <48EF60B2.4040708@odu.neva.ru>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<48EF60B2.4040708@odu.neva.ru>
Message-ID: <385866f0810100823r2cfe66eah705224170120e128@mail.gmail.com>

> What are you doing for CJK locales?

type less /etc/profile.d/lang.sh and you will know

> The solution looks simple -- just change the default "latarcyrheb-sun16" to some old good 256-gliph font.

the problem is RTL languages is the lake of BiDi support not the lake
of glyphs or fonts

I'll do the patch and do some testing, then I'll send it



From buc at odusz.so-cdu.ru  Fri Oct 10 15:25:31 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Fri, 10 Oct 2008 19:25:31 +0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>	<48EF6C1B.4060400@odu.neva.ru>
	<16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
Message-ID: <48EF73EB.9020108@odu.neva.ru>

Arthur Pemberton wrote:
> On Fri, Oct 10, 2008 at 9:52 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
>>
>>
>> An environment, which is considered stable, can be "untypical". Ie.
>> "untypical production stable environment".
>>
>> All the years RHL/Fedora is used at my work, we was compelled (from time to
>> time) to even port some future versions/features of N+1 distro to the
>> current N distro. Because the features required for our "untypical"
>> environment have appeared somewhere closer to the bleeding-edge...
>>     
>
>
> Sounds like you want Centos + Extras then.

No.

EPEL (Extras) is not bleeding-edge (AFAIK its policy).  And often enough 
we need a new version of some non-Extras package (ie. samba, openldap etc.)


~buc



From ville.skytta at iki.fi  Fri Oct 10 15:26:57 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Fri, 10 Oct 2008 18:26:57 +0300
Subject: Tangent: recording upstream scm locations and contact info
In-Reply-To: <1223646406.19673.178.camel@aglarond.local>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<1223628409.10562.41.camel@ignacio.lan>
	<1223646406.19673.178.camel@aglarond.local>
Message-ID: <200810101826.57850.ville.skytta@iki.fi>

On Friday 10 October 2008, Jeremy Katz wrote:
> On Fri, 2008-10-10 at 04:46 -0400, Ignacio Vazquez-Abrams wrote:
> > On Thu, 2008-10-09 at 19:55 -0400, Michael Stone wrote:
> > > Does storing the information in packagedb have some compelling benefit
> > > that compensates for dealing with these hassles by other means?
> >
> > It means that you don't have to muck through rpm's code in order to add
> > a tag that will cause older/other versions of rpm to puke.
>
> Adding tags actually doesn't make older versions of rpm puke, it just
> ignores them

rpmbuild on the other hand is pickier than that.

$ echo "Foo: bar" > foo.spec
$ rpmbuild -bb foo.spec
error: line 1: Unknown tag: Foo: bar



From cmadams at hiwaay.net  Fri Oct 10 15:29:43 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 10 Oct 2008 10:29:43 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF655A.3040504@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<935ead450810100708j6935696erd242e9d9250d0376@mail.gmail.com>
	<48EF655A.3040504@odu.neva.ru>
Message-ID: <20081010152942.GA1486104@hiwaay.net>

Once upon a time, Dmitry Butskoy <buc at odusz.so-cdu.ru> said:
> I would prefer that Fedora would be stable enough, thus does not require 
> "continually rebuilding systems" ;)

It isn't just an issue of stability; it is an issue of long-term
support.  Fedora does not have the manpower and/or interest to support
releases for a long time (as seen by the failure of the Fedora Legacy
project).  The goal of Fedora is to get new features and technology in
the hands of developers as fast as practical, so there are two releases
a year.  There are people interested in long-term support, but not
enough to make it happen.

If Fedora tried to support a release for even 3 years, that would be 6
different releases to support, which would require a large investment in
time, additional infrastructure (to handle up to 3 times as many active
packages), etc.  Would it be nice if that happened?  Sure, but the
demand does not magically produce the manpower to make it so.

That's part of why people pay Red Hat for RHEL: Red Hat does support a
release for years (7 or 8 IIRC now).  Basically, Red Hat takes a
snapshot of Fedora, reduces it to a core set of packages they think they
can support (both now and long-term), runs it through some additional
QA, and produces a RHEL release.  CentOS then takes the source to that
RHEL release and rebuilds it to produce a compatible free release.  Red
Hat does much of the "heavy lifting" involved in supporting a release
for a long time and CentOS has their own infrastructure to support it
for free uses.

Since Fedora releases are only supported for about 1 year, servers on
the Internet running Fedora need to upgraded at least that often.  There
are a lot of servers supporting the Fedora infrastructure, and it would
be a significant amount of work to upgrade them all every year.  So it
makes sense to use RHEL and/or CentOS (which are after all derived from
Fedora) on the infrastructure servers, so the limited support manpower
can spend time doing more productive things than just upgrading servers.

-- 
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 jkeating at redhat.com  Fri Oct 10 15:30:26 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 08:30:26 -0700
Subject: rawhide report: 20081010 changes
In-Reply-To: <20081010131351.GA12035@yoda.jdub.homelinux.org>
References: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>
	<20081010131351.GA12035@yoda.jdub.homelinux.org>
Message-ID: <1223652626.4410.148.camel@luminos.localdomain>

On Fri, 2008-10-10 at 09:13 -0400, Josh Boyer wrote:
> I think whatever script is creating this is screwing up the
> ordering and timestamps of the changelogs.  Every timestamp for
> every package is 18:00:00, which cannot possibly be true.


The spec itself doesn't have a timestamp, so you get interesting results
when you query the db for changlog entries.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/ff628b4b/attachment.sig>

From jarod at redhat.com  Fri Oct 10 15:31:18 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Fri, 10 Oct 2008 11:31:18 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <da159fda0810100713x2d9c2e8ch339124e2510a930d@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<da159fda0810100713x2d9c2e8ch339124e2510a930d@mail.gmail.com>
Message-ID: <200810101131.18903.jarod@redhat.com>

On Friday 10 October 2008 10:13:57 Jon Stanley wrote:
> On Fri, Oct 10, 2008 at 9:33 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
[...]
> > Fedora Desktop "all the time"? (Maybe RedHat employees of them are
> > compelled to use RHEL Desktop in basic working hours?)
>
> I'm not a Red Hat employee, but I'm pretty sure that they aren't
> "compelled" to do anything.

That would be correct.

> And lots of developers that I know run
> rawhide all the time.

Yep. My IBM ThinkPad T61 laptop, which I use for 99% of my $dayjob desktop use 
(docked on a ThinkPad Advanced Dock) is running rawhide. I've got several 
development boxes here in the office that are a mix of the latest RHEL and 
latest rawhide, as I have both package and kernel work to do on both. Some of 
'em have both rawhide and RHEL installs too.

On the home front, my personal web and mail server is still lagging behind on 
Fedora 9, but will get upgraded soon (yes, I consider running Fedora 9 to be 
lagging behind ;). My mythtv boxes, my tinkering desktop system at home, my 
Acer Aspire One netbook and my AppleTV, all running rawhide as well.

Also, taking off my Red Hat hat and speaking purely from a personal point of 
view, I'd echo the sentiment that CentOS pretty much *is* Fedora LTS for those 
that want such a thing.

-- 
Jarod Wilson
jarod at redhat.com



From pertusus at free.fr  Fri Oct 10 15:35:04 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 10 Oct 2008 17:35:04 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
Message-ID: <20081010153504.GE3236@free.fr>

On Fri, Oct 10, 2008 at 05:10:29PM +0200, Matej Cepl wrote:
> On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
> > What should do some previously RedHat-oriented enthusiast, when 
> > all the area for application of his enthusiasm is some 
> > "production environment"?  Use RHEL/CentOS anywhere and Fedora 
> > on his laptop only? But RHEL/CentOS is far from the "bleeding 
> > edge", hence his enthusiasm just disappear...
> 
> Think about that and repeat until you get it -- "distro is either 
> bleeding-edge or stable; tercium non datur".

It is a bit more complicated. A distro may begin its life bleeding edge
and become stable as time goes by, if it is still maintained. And a
stable distro may have parts that are bleeding-edge. This is not
necessarily easy to implement, but these scenarios certainly have
merits.

--
Pat



From lesmikesell at gmail.com  Fri Oct 10 15:49:56 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 10 Oct 2008 10:49:56 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010153504.GE3236@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr>
Message-ID: <48EF79A4.2030103@gmail.com>

Patrice Dumas wrote:
> On Fri, Oct 10, 2008 at 05:10:29PM +0200, Matej Cepl wrote:
>> On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
>>> What should do some previously RedHat-oriented enthusiast, when 
>>> all the area for application of his enthusiasm is some 
>>> "production environment"?  Use RHEL/CentOS anywhere and Fedora 
>>> on his laptop only? But RHEL/CentOS is far from the "bleeding 
>>> edge", hence his enthusiasm just disappear...
>> Think about that and repeat until you get it -- "distro is either 
>> bleeding-edge or stable; tercium non datur".
> 
> It is a bit more complicated. A distro may begin its life bleeding edge
> and become stable as time goes by, if it is still maintained. And a
> stable distro may have parts that are bleeding-edge. This is not
> necessarily easy to implement, but these scenarios certainly have
> merits.

That was the way things worked when redhat developed its popularity.  An 
  X.0 release was approximately as unstable as a fedora, but as it 
updated to X.2 or X.3 it would have become very stable and people who 
started a development cycle with the early versions could keep the same 
OS in production as it matured.  What we need for the same effect now is 
for the versions of fedora that provide the initial RHEL cuts to offer a 
seamless update to the subsequent matching CentOS, repointing to its 
update repositories for continued support.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From jwboyer at gmail.com  Fri Oct 10 15:49:43 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 10 Oct 2008 11:49:43 -0400
Subject: rawhide report: 20081010 changes
In-Reply-To: <1223652626.4410.148.camel@luminos.localdomain>
References: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>
	<20081010131351.GA12035@yoda.jdub.homelinux.org>
	<1223652626.4410.148.camel@luminos.localdomain>
Message-ID: <20081010154943.GA13966@yoda.jdub.homelinux.org>

On Fri, Oct 10, 2008 at 08:30:26AM -0700, Jesse Keating wrote:
>On Fri, 2008-10-10 at 09:13 -0400, Josh Boyer wrote:
>> I think whatever script is creating this is screwing up the
>> ordering and timestamps of the changelogs.  Every timestamp for
>> every package is 18:00:00, which cannot possibly be true.
>
>
>The spec itself doesn't have a timestamp, so you get interesting results
>when you query the db for changlog entries.

And the ordering?  I highly doubt davej put 2.6.27 in, and then applied
-rc9-git2 on top of that.

josh



From jkeating at redhat.com  Fri Oct 10 16:07:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 09:07:12 -0700
Subject: rawhide report: 20081010 changes
In-Reply-To: <20081010154943.GA13966@yoda.jdub.homelinux.org>
References: <20081010103556.31A411B8001@releng2.fedora.phx.redhat.com>
	<20081010131351.GA12035@yoda.jdub.homelinux.org>
	<1223652626.4410.148.camel@luminos.localdomain>
	<20081010154943.GA13966@yoda.jdub.homelinux.org>
Message-ID: <1223654832.4410.149.camel@luminos.localdomain>

On Fri, 2008-10-10 at 11:49 -0400, Josh Boyer wrote:
> 
> And the ordering?  I highly doubt davej put 2.6.27 in, and then applied
> -rc9-git2 on top of that.

If I understand it correctly, since there is no time stamp, the ordering
is not, well, ordered.  It doesn't appear in the DB exactly the same way
it appears in the spec file, or something like that.  Somebody with more
knowledge of rpm internals needs to help me out here.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/ab446eae/attachment.sig>

From kevin.kofler at chello.at  Fri Oct 10 16:08:24 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 10 Oct 2008 16:08:24 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
Message-ID: <loom.20081010T160239-992@post.gmane.org>

Les Mikesell <lesmikesell <at> gmail.com> writes:
> What we need for the same effect now is for the versions of fedora that
> provide the initial RHEL cuts to offer a seamless update to the subsequent
> matching CentOS, repointing to its update repositories for continued support.

I'm afraid that's not possible, because Fedora (even the previous version of 
it!) keeps getting version updates after RHEL gets branched and RHEL doesn't 
get most of them, so even the upgrade path from Fedora n-1 to a RHEL based on 
Fedora n can't be guaranteed, not even at the very moment RHEL gets released, 
and thus not at any point in time.

The development branch for RHEL would have to be opened up (and EPEL maintained 
against it, too) for a proposal like yours to work, and I don't think Red Hat 
is prepared to do that; additionally, you'd also have to hop off Fedora to 
there exactly at the right point in time, because Fedora would continue getting 
updates, not all of which will end up in RHEL.

        Kevin Kofler



From emmanuel.seyman at club-internet.fr  Fri Oct 10 16:09:23 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 10 Oct 2008 18:09:23 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010144426.GC3236@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
Message-ID: <20081010160923.GA5293@orient.maison.lan>

* Patrice Dumas [10/10/2008 17:39] :
>
>                  Now it may very well be possible that there is not
> enough interested users to make that distro, but there is also a lack of
> support from the boards.

You don't actually need support from the boards to do something.

If you believe something is worth doing, start it outside the Fedora
project and see if it catches on. If it does, you can consider making
a pitch to the board to bring it under the Fedora umbrella.

ISn't this how the KDE SIG got started ?

Emmanuel



From jkeating at j2solutions.net  Fri Oct 10 16:09:14 2008
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 10 Oct 2008 09:09:14 -0700
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081010143137.GB3236@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>
	<20081010143137.GB3236@free.fr>
Message-ID: <1223654954.4410.151.camel@luminos.localdomain>

On Fri, 2008-10-10 at 16:31 +0200, Patrice Dumas wrote:
> I mostly agree, however it seems to me that a true Fedora LTS is
> missing, that would allow those who want things that are new, including 
> for testing but cannot afford changing everything each year (servers for 
> example or user desktops). It seems to me that fedora ends up being used
> almost exclusively as single user desktop, so that testing of other
> functionalities is likely to be less widespread. Fortunately, those
> functionnalities certainly need less integration and so less testing in
> fedora before they go to RHEL/CENTOS + EPEL, but still it would
> certainly have some relevance, in my opinion.

Given the amount of churn we allow maintainers to introduce into our
"stable" releases, I highly doubt Fedora would be suitable for any
situation where a "LTS" was desired.  There is just too much major
version upgrading, behavioral changes, massive amounts of updates,
rapidly invalid documentation, and high chance of regression in the
"stable" updates.  We should address *that* problem before ever thinking
about extending the life.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/a06a2aa3/attachment.sig>

From pemboa at gmail.com  Fri Oct 10 16:16:29 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 11:16:29 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081010151757.GD3236@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
	<48EF6C1B.4060400@odu.neva.ru>
	<16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
	<20081010151757.GD3236@free.fr>
Message-ID: <16de708d0810100916s430a598at67ab1a1945760aed@mail.gmail.com>

On Fri, Oct 10, 2008 at 10:17 AM, Patrice Dumas <pertusus at free.fr> wrote:
> On Fri, Oct 10, 2008 at 10:13:14AM -0500, Arthur Pemberton wrote:
>>
>> Sounds like you want Centos + Extras then. Or maybe Extras isn't up to
>> date enough, and some people may need to create a new 'Current' repo
>> for Centos.
>
> If you are referring to EPEL with Extras, EPEL should not move faster
> than RHEL, and, as far as I can tell, a 'Current' repo for Centos
> doesn't exist.


Well I suspected from my usage that EPEL with Extras does not move
faster. Hence why I suggested that those interested may want to create
a 'Current' repo. To pull in newer packages that they feel are stable.
I am aware that such doesn't exist, and 'Current' is just a
placeholder for the idea. I myself see little value in it, but some
seem to.

Are there any distros which are very current, stable _and_ source of a
lot of development in the Linux/FOSS community? Seems to me, that once
can any given distro can only have two out of three of those
properties.

IMHO: If dropping any idea of stability meant a 50% (just an arbitrary
positive number) increase in dev productivity, I'm all for it.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From jkeating at redhat.com  Fri Oct 10 16:18:52 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 09:18:52 -0700
Subject: Regarding install options
In-Reply-To: <a9274eb10810100320q14f8a419yf19795ce56e35543@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<200810092228.57923.konrad@tylerc.org> <48EEED82.7030508@redhat.com>
	<200810092259.28480.konrad@tylerc.org>
	<a9274eb10810100320q14f8a419yf19795ce56e35543@mail.gmail.com>
Message-ID: <1223655532.4410.152.camel@luminos.localdomain>

On Fri, 2008-10-10 at 11:20 +0100, Paul Black wrote:
> 2008/10/10 Conrad Meyer <konrad at tylerc.org>
>         > Doesn't mean its not a pain in the ass. Hell, its taken me 3
>         tries to
>         > install Fedora without having GNOME pulled in as a
>         dependency before.
>         >
>         > --CJD
>         
>         
>         You can always remove it later. It's not a huge deal either
>         way.
> 
> Not an ideal scenario for a network install.
> 

There you would be using kickstart, and defining what you want at a very
granular level...

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/3ff603bf/attachment.sig>

From jkeating at redhat.com  Fri Oct 10 16:20:04 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 09:20:04 -0700
Subject: Regarding install options
In-Reply-To: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
Message-ID: <1223655604.4410.153.camel@luminos.localdomain>

On Fri, 2008-10-10 at 10:42 +0530, Shambo Bose wrote:
> 1. Desktop Install.
> 
> 2. Server Install.

Tell you what.  Try to get the majority of fedora-devel contributors to
agree on what should be in each of those installs.  Don't forget the
international community, who often need X in order to display the
language they speak.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/0b4beeed/attachment.sig>

From jkeating at redhat.com  Fri Oct 10 16:21:42 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 09:21:42 -0700
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810100916s430a598at67ab1a1945760aed@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
	<48EF6C1B.4060400@odu.neva.ru>
	<16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
	<20081010151757.GD3236@free.fr>
	<16de708d0810100916s430a598at67ab1a1945760aed@mail.gmail.com>
Message-ID: <1223655702.4410.154.camel@luminos.localdomain>

On Fri, 2008-10-10 at 11:16 -0500, Arthur Pemberton wrote:
> Are there any distros which are very current, stable _and_ source of a
> lot of development in the Linux/FOSS community? Seems to me, that once
> can any given distro can only have two out of three of those
> properties.

It's like the old good, fast, cheap adage.  Pick two of those because
that's all you'll ever get.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/505d9e6d/attachment.sig>

From lesmikesell at gmail.com  Fri Oct 10 16:23:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 10 Oct 2008 11:23:55 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <loom.20081010T160239-992@post.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>	<48EF687B.9090407@odu.neva.ru>	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>	<20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com>
	<loom.20081010T160239-992@post.gmane.org>
Message-ID: <48EF819B.8010607@gmail.com>

Kevin Kofler wrote:
> Les Mikesell <lesmikesell <at> gmail.com> writes:
>> What we need for the same effect now is for the versions of fedora that
>> provide the initial RHEL cuts to offer a seamless update to the subsequent
>> matching CentOS, repointing to its update repositories for continued support.
> 
> I'm afraid that's not possible, because Fedora (even the previous version of 
> it!) keeps getting version updates after RHEL gets branched and RHEL doesn't 
> get most of them, so even the upgrade path from Fedora n-1 to a RHEL based on 
> Fedora n can't be guaranteed, not even at the very moment RHEL gets released, 
> and thus not at any point in time.
> 
> The development branch for RHEL would have to be opened up (and EPEL maintained 
> against it, too) for a proposal like yours to work, and I don't think Red Hat 
> is prepared to do that; additionally, you'd also have to hop off Fedora to 
> there exactly at the right point in time, because Fedora would continue getting 
> updates, not all of which will end up in RHEL.

I know it doesn't work that way now - hence the complaints.

Fedora could make it's next release somewhere around the point where the 
paths start to diverge so people who wanted the fast-track unstable 
flavor could re-install as they apparently love to do, and the rest of 
us could just drift into stability.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Fri Oct 10 16:29:11 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 10 Oct 2008 11:29:11 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810100916s430a598at67ab1a1945760aed@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>	<48EF6C1B.4060400@odu.neva.ru>	<16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>	<20081010151757.GD3236@free.fr>
	<16de708d0810100916s430a598at67ab1a1945760aed@mail.gmail.com>
Message-ID: <48EF82D7.1050400@gmail.com>

Arthur Pemberton wrote:

> 
> Well I suspected from my usage that EPEL with Extras does not move
> faster. Hence why I suggested that those interested may want to create
> a 'Current' repo. To pull in newer packages that they feel are stable.
> I am aware that such doesn't exist, and 'Current' is just a
> placeholder for the idea. I myself see little value in it, but some
> seem to.

Now that RHEL apparently realizes that they don't have to stick to a 
years-behind firefox and openoffice, there's a little less value in 3rd 
party maintainers for those updates...

-- 
   Les Mikesell
     lesmikesell at gmail.com



From pertusus at free.fr  Fri Oct 10 16:28:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 10 Oct 2008 18:28:36 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010160923.GA5293@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<20081010160923.GA5293@orient.maison.lan>
Message-ID: <20081010162836.GF3236@free.fr>

On Fri, Oct 10, 2008 at 06:09:23PM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [10/10/2008 17:39] :
> >
> >                  Now it may very well be possible that there is not
> > enough interested users to make that distro, but there is also a lack of
> > support from the boards.
> 
> You don't actually need support from the boards to do something.

When it requires cooperation with the infrastructure, it does. It is
also possible to start something external like rpmfusion, but the amount
of work is very big. My proposal only made sense if the economies of
scale realized by working inside the fedora project were realized.

Still, if somebody provides the infrastructure, sure I'll try to help
with a project similar than the one I proposed, but I cannot myself do
anything for the infrastructure part.

--
Pat



From smooge at gmail.com  Fri Oct 10 16:43:04 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Fri, 10 Oct 2008 10:43:04 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081010153504.GE3236@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <20081010153504.GE3236@free.fr>
Message-ID: <80d7e4090810100943w7e275919qd0a6c24235fb0fd7@mail.gmail.com>

On Fri, Oct 10, 2008 at 9:35 AM, Patrice Dumas <pertusus at free.fr> wrote:
> On Fri, Oct 10, 2008 at 05:10:29PM +0200, Matej Cepl wrote:
>> On 2008-10-10, 14:36 GMT, Dmitry Butskoy wrote:
>> > What should do some previously RedHat-oriented enthusiast, when
>> > all the area for application of his enthusiasm is some
>> > "production environment"?  Use RHEL/CentOS anywhere and Fedora
>> > on his laptop only? But RHEL/CentOS is far from the "bleeding
>> > edge", hence his enthusiasm just disappear...
>>
>> Think about that and repeat until you get it -- "distro is either
>> bleeding-edge or stable; tercium non datur".
>
> It is a bit more complicated. A distro may begin its life bleeding edge
> and become stable as time goes by, if it is still maintained. And a
> stable distro may have parts that are bleeding-edge. This is not
> necessarily easy to implement, but these scenarios certainly have
> merits.
>

It can only become stable if you have people focus on things and not
look at new stuff. And usually it requires resources that are
expensive.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From tibbs at math.uh.edu  Fri Oct 10 16:50:08 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 10 Oct 2008 11:50:08 -0500
Subject: Package review backlog.
In-Reply-To: <1223644448.6770.18.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
Message-ID: <ufaabdce6nz.fsf@epithumia.math.uh.edu>

>>>>> "DW" == David Woodhouse <dwmw2 at infradead.org> writes:

DW> When new contributors submit packages and can't get through the
DW> bureaucracy of getting them reviewed and approved, we are turning
DW> away the very people we should be embracing.

Please keep in mind that new contributors have an additional
bureaucratic overhead, the sponsor procedure, which complicates
matters well beyond the issue of the review backlog.  I have simply
given up sponsoring anyone until the maintainer containment stuff is
in place because its simply more expedient for me to spend my
unfortunately limited time on non-needsponsor reviews.

 - J<



From tibbs at math.uh.edu  Fri Oct 10 16:59:00 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 10 Oct 2008 11:59:00 -0500
Subject: Package review backlog.
In-Reply-To: <ufaabdce6nz.fsf@epithumia.math.uh.edu>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<ufaabdce6nz.fsf@epithumia.math.uh.edu>
Message-ID: <ufa63o0e697.fsf@epithumia.math.uh.edu>

And of course I manage to miss Toshio's announcement that the
maintainer containment stuff is turned on now.  So that's one barrier
down.  Sponsors, now you don't need to worry about the people you
sponsor instantly getting access to everything.  Hooray!

 - J<



From dwmw2 at infradead.org  Fri Oct 10 17:06:27 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 10 Oct 2008 18:06:27 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <48ECEFB9.1080600@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
Message-ID: <1223658387.6770.53.camel@macbook.infradead.org>

On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
> prepare a Wiki page with details about that.

Isn't the whole point of libtool that it should make things _easier_,
not break huge swathes of packages whenever we change it?

How about we fix those 300 packages by making them _not_ use libtool,
rather than making them use the latest version?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pbrobinson at gmail.com  Fri Oct 10 17:13:09 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 10 Oct 2008 18:13:09 +0100
Subject: Package review backlog.
In-Reply-To: <1223644448.6770.18.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
Message-ID: <5256d0b0810101013s12e87a94ye0cbf498d2017d75@mail.gmail.com>

>> > On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
>> > >> Let's get the final two packages reviewed -- and that's another area
>> > >> where we could do with some improvement, because failing to approve
>> > >> packages really _is_ verging on the 'deletionism' you spoke of. But
>> > >> that's a separate discussion.
>> > >
>> > >Agreed, we can discuss this later. BTW: The word "deletionsm" did not
>> > >come from me, it was Josh who said that, but of course I agree with him.
>> >
>> > I didn't say that.  Though I agree we need to be getting more packages
>> > approved.
>>
>> I think this is something we all agree on. ;)
>
> I propose that each FESCo member should try to work on at least one
> package review per week. Each week at the FESCo meeting, we'll ask
> members which reviews they've worked on in the past week.
>
> It won't be _mandatory_ -- we're not going to send the boys round to
> visit a FESCo member who doesn't do it. But FESCo should be setting a
> good example.
>
> And anyone else who considers themselves an active member of the Fedora
> development community should also try to do the same. If one a week
> isn't realistic due to other commitments, set yourself a more relaxed
> target -- like one a fortnight, or one a month, and try to stick to
> that.

While of the topic of package review ticket backlog what is the rule
of thumb for people closing of tickets for package reviews that have
been long in Fedora (I know of one that is still open but the package
review done and its been in there since F-7). Do we just close them
off if the people in question haven't done so? Oh and I did make a
note on the ticket asking about it.

Peter



From tibbs at math.uh.edu  Fri Oct 10 17:19:34 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 10 Oct 2008 12:19:34 -0500
Subject: Package review backlog.
In-Reply-To: <5256d0b0810101013s12e87a94ye0cbf498d2017d75@mail.gmail.com>
References: <loom.20081008T092258-152@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<5256d0b0810101013s12e87a94ye0cbf498d2017d75@mail.gmail.com>
Message-ID: <ufa1vyoe5ax.fsf@epithumia.math.uh.edu>

>>>>> "PR" == Peter Robinson <pbrobinson at gmail.com> writes:

PR> While of the topic of package review ticket backlog what is the
PR> rule of thumb for people closing of tickets for package reviews
PR> that have been long in Fedora

Well, https://fedoraproject.org/wiki/Package_Review_Process says when
the ticket should be closed; if that's not done then I can't imagine a
reason why anyone would complain about someone doing cleanup.  The
ticket could always be reopened if it's being held open for some
particular reason.

 - J<



From shambo.linux at gmail.com  Fri Oct 10 17:47:11 2008
From: shambo.linux at gmail.com (Shambo Bose)
Date: Fri, 10 Oct 2008 23:17:11 +0530
Subject: Regarding install options
In-Reply-To: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
Message-ID: <b53a79450810101047s7d59fb8fu49e9ff5f292cb951@mail.gmail.com>

Everything can be done after installation of Fedora, but time is precious .
Installation of  fedora first then again install packages needed by a server
or a desktop is time consuming. I think we should keep in  mind that
kickstart files can be a solution for a advanced linux users not for new
linux users.

Why are we making fedora a OS for advanced linux users ? I think the new
layout will help new fedora users a lot . Personally I think we should
concentrate on "ease of use" concept. I am currently working on the options
layout, and what packages can be provided under each option.


Yours sincerely ,

Shambo Bose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/1ea28bbd/attachment.htm>

From emmanuel.seyman at club-internet.fr  Fri Oct 10 17:54:27 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 10 Oct 2008 19:54:27 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF79A4.2030103@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
Message-ID: <20081010175427.GA7389@orient.maison.lan>

* Les Mikesell [10/10/2008 19:45] :
>
>                                  What we need for the same effect now is  
> for the versions of fedora that provide the initial RHEL cuts to offer a  
> seamless update to the subsequent matching CentOS, repointing to its  
> update repositories for continued support.

I'ld expect migration guides and packages from Fedora to $DISTRIBUTION
to be written by the $DISTRIBUTION community, not Fedora's.

Emmanuel



From kevin.kofler at chello.at  Fri Oct 10 17:56:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 10 Oct 2008 17:56:59 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<20081010160923.GA5293@orient.maison.lan>
	<20081010162836.GF3236@free.fr>
Message-ID: <loom.20081010T175602-582@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:
> Still, if somebody provides the infrastructure, sure I'll try to help
> with a project similar than the one I proposed, but I cannot myself do
> anything for the infrastructure part.

All those "we want KDE 3" whiners should be providing the infrastructure for 
prolungating Fedora 8 support, they could make it happen. But something tells 
me they won't...

        Kevin Kofler



From sandeen at redhat.com  Fri Oct 10 18:27:13 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 10 Oct 2008 13:27:13 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <48EE016E.8050407@redhat.com>
References: <48EE016E.8050407@redhat.com>
Message-ID: <48EF9E81.4020403@redhat.com>

Eric Sandeen wrote:
> The ext4 patchset for 2.6.28 contains several fixes as well as,
> ultimately, a change in the name of the filesystem from "ext4dev" to
> "ext4." (*) - I've pulled this in for F10.
> 
> This will also require an updated e2fsprogs, because there was a bug in
> blkid which failed to recognize older "ext4dev" filesystems (those with
> the test_fs flag set) as ext4, as it should have.  This caused them to
> not mount automatically.
> 
> So long story short, you'll need to update kernel & e2fsprogs together,
> if you have ext4(dev) filesystems and you need them to mount seamlessly.
>  It's recoverable (just a mounting  failure) but I don't want anyone to
> be too surprised.

aaaand that turns out to be insufficient.

Changing /etc/fstab to list "ext4" for the root fs may be enough, do it
before you install the new kernel.

notting suggested a module alias to ext4dev in the ext4.ko module
itself, that sounds like a good plan and as long as it gets upstream
I'll commit it to Fedora shortly, and I think that should make it all
seamless.

Thanks,
-Eric



From a.badger at gmail.com  Fri Oct 10 18:31:43 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 10 Oct 2008 11:31:43 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223658387.6770.53.camel@macbook.infradead.org>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
Message-ID: <48EF9F8F.3010603@gmail.com>

David Woodhouse wrote:
> On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
>> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
>> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
>> prepare a Wiki page with details about that.
> 
> Isn't the whole point of libtool that it should make things _easier_,
> not break huge swathes of packages whenever we change it?
> 
> How about we fix those 300 packages by making them _not_ use libtool,
> rather than making them use the latest version?
> 
Hand coding Makefiles to compile shared libraries on all platforms is .
 Before libtools many upstreams simply wouldn't package shared libraries
because of all the problems with getting it right for SunOS, Solaris,
OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc, acc,
etc.  If the state of the art has advanced and there's a tool that can
replace libtool so a developer can say "I want a shared library" and the
tool builds it on all platforms then we could look into getting
upstreams to switch but simply getting rid of libtool in favour of
handcoding Makefiles to build shared libraries is a step in the wrong
direction.

-Toshio

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

From mw_triad at users.sourceforge.net  Fri Oct 10 18:41:46 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 10 Oct 2008 13:41:46 -0500
Subject: Arabic and Hebrew on the console
In-Reply-To: <48EF60B2.4040708@odu.neva.ru>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<48EF60B2.4040708@odu.neva.ru>
Message-ID: <gco7lb$2pr$1@ger.gmane.org>

Dmitry Butskoy wrote:
> Since RedHat Linux 8, "latarcyrherb-sun16"  is the default console font. 
> It seems that it was chosen in assumption that 
> ascii+latin+cyrillic+hebrew+arabic in one a font should satisfy all the 
> needs of console users.
> 
> But "latarcyrheb-sun16" is so-called 512-glyphs font. Unfortunately, 
> there is a restriction in hardware, which decreases the amount of 
> available console colors if console font has more than 256 glyphs.

Isn't Kernel Mode Setting supposed to fix this? (...because we won't be 
using hardware text mode and so will be able to use our own kernel glyph 
rendering code that won't have this restriction, and incidentally would 
allow things like very-high-resolution and 24-bit color on VT's?)

> As a result, people who (for some reasons) use TUI on console have no 
> yellow and bolding anymore.
> 
> The solution looks simple -- just change the default "latarcyrheb-sun16" 
> to some old good 256-gliph font. It is an obvious thing, especially in 
> fact that actually the "latin+cyrillic+hebrew+arabic" combination seems 
> never used in a real life of console. What seems to be used is just 
> "ascii + local native language" (ie. ascii+latin1, ascii+cyrillic etc.), 
> and such combinations do not exceed 256-glyph limit.

Yup. Granted, I don't use the VT's *all* that much (though I do, on 
occasion), but one of the first changes I make to a system is usually to 
set the font back to lat0-*. (I'd use lat0-10 or lat0-8 except switching 
to/from X tends to not restore the hardware font correctly; in fact I'm 
probably getting the BIOS font at that point.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
C++ is for people who want to be able to not just shoot themselves in 
the foot, but do it with a rocket launcher. -- Igor Peshansky



From notting at redhat.com  Fri Oct 10 18:45:42 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 10 Oct 2008 14:45:42 -0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <48EF60B2.4040708@odu.neva.ru>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<48EF60B2.4040708@odu.neva.ru>
Message-ID: <20081010184542.GA29560@nostromo.devel.redhat.com>

Dmitry Butskoy (buc at odusz.so-cdu.ru) said: 
> The solution looks simple -- just change the default "latarcyrheb-sun16"  
> to some old good 256-gliph font. It is an obvious thing, especially in  
> fact that actually the "latin+cyrillic+hebrew+arabic" combination seems  
> never used in a real life of console. What seems to be used is just  
> "ascii + local native language" (ie. ascii+latin1, ascii+cyrillic etc.),  
> and such combinations do not exceed 256-glyph limit.

This implies you'll never want to/need to see characters outside of
your local language. I'm not sure that's a valid assumption.

Bill



From ajax at redhat.com  Fri Oct 10 18:51:17 2008
From: ajax at redhat.com (Adam Jackson)
Date: Fri, 10 Oct 2008 14:51:17 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <48EF9F8F.3010603@gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
Message-ID: <1223664677.27225.12.camel@atropine.boston.devel.redhat.com>

On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
> David Woodhouse wrote:
> > On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
> >> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
> >> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
> >> prepare a Wiki page with details about that.
> > 
> > Isn't the whole point of libtool that it should make things _easier_,
> > not break huge swathes of packages whenever we change it?
> > 
> > How about we fix those 300 packages by making them _not_ use libtool,
> > rather than making them use the latest version?
> > 
> Hand coding Makefiles to compile shared libraries on all platforms is .
>  Before libtools many upstreams simply wouldn't package shared libraries
> because of all the problems with getting it right for SunOS, Solaris,
> OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc, acc,
> etc.  If the state of the art has advanced and there's a tool that can
> replace libtool so a developer can say "I want a shared library" and the
> tool builds it on all platforms then we could look into getting
> upstreams to switch but simply getting rid of libtool in favour of
> handcoding Makefiles to build shared libraries is a step in the wrong
> direction.

The state of the art is "gcc -shared".

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/0d421691/attachment.sig>

From a.badger at gmail.com  Fri Oct 10 19:07:24 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 10 Oct 2008 12:07:24 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>	<1223658387.6770.53.camel@macbook.infradead.org>	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
Message-ID: <48EFA7EC.6000607@gmail.com>

Adam Jackson wrote:
> On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
>> Hand coding Makefiles to compile shared libraries on all platforms is .
>>  Before libtools many upstreams simply wouldn't package shared libraries
>> because of all the problems with getting it right for SunOS, Solaris,
>> OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc, acc,
>> etc.  If the state of the art has advanced and there's a tool that can
>> replace libtool so a developer can say "I want a shared library" and the
>> tool builds it on all platforms then we could look into getting
>> upstreams to switch but simply getting rid of libtool in favour of
>> handcoding Makefiles to build shared libraries is a step in the wrong
>> direction.
> 
> The state of the art is "gcc -shared".
> 
So gcc is the compiler everywhere these days?  Note this is a genuine
question -- I haven't used anything besides Linux in so long I don't
know whether Sun or anyone else is shipping their own C compiler anymore.

-Toshio

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

From sandeen at redhat.com  Fri Oct 10 19:10:07 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 10 Oct 2008 14:10:07 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <48EF9E81.4020403@redhat.com>
References: <48EE016E.8050407@redhat.com> <48EF9E81.4020403@redhat.com>
Message-ID: <48EFA88F.7000105@redhat.com>

Eric Sandeen wrote:

> Changing /etc/fstab to list "ext4" for the root fs may be enough, do it
> before you install the new kernel.

On further reflection, you will probably just have to do this.

-Eric

> notting suggested a module alias to ext4dev in the ext4.ko module
> itself, that sounds like a good plan and as long as it gets upstream
> I'll commit it to Fedora shortly, and I think that should make it all
> seamless.




From berrange at redhat.com  Fri Oct 10 19:17:41 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 10 Oct 2008 20:17:41 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081010191741.GB5378@redhat.com>

On Fri, Oct 10, 2008 at 02:51:17PM -0400, Adam Jackson wrote:
> On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
> > David Woodhouse wrote:
> > > On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
> > >> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
> > >> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
> > >> prepare a Wiki page with details about that.
> > > 
> > > Isn't the whole point of libtool that it should make things _easier_,
> > > not break huge swathes of packages whenever we change it?
> > > 
> > > How about we fix those 300 packages by making them _not_ use libtool,
> > > rather than making them use the latest version?
> > > 
> > Hand coding Makefiles to compile shared libraries on all platforms is .
> >  Before libtools many upstreams simply wouldn't package shared libraries
> > because of all the problems with getting it right for SunOS, Solaris,
> > OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc, acc,
> > etc.  If the state of the art has advanced and there's a tool that can
> > replace libtool so a developer can say "I want a shared library" and the
> > tool builds it on all platforms then we could look into getting
> > upstreams to switch but simply getting rid of libtool in favour of
> > handcoding Makefiles to build shared libraries is a step in the wrong
> > direction.
> 
> The state of the art is "gcc -shared".

Not so much if you're trying to build for windows. The mingw32 work
has only been made viable because libtool has basically taken care 
of the horrible shared library build process required by Windows.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From ajax at redhat.com  Fri Oct 10 19:24:26 2008
From: ajax at redhat.com (Adam Jackson)
Date: Fri, 10 Oct 2008 15:24:26 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <48EFA7EC.6000607@gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<48EFA7EC.6000607@gmail.com>
Message-ID: <1223666666.7707.13.camel@atropine.boston.devel.redhat.com>

On Fri, 2008-10-10 at 12:07 -0700, Toshio Kuratomi wrote:
> Adam Jackson wrote:
> > On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
> >> Hand coding Makefiles to compile shared libraries on all platforms is .
> >>  Before libtools many upstreams simply wouldn't package shared libraries
> >> because of all the problems with getting it right for SunOS, Solaris,
> >> OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc, acc,
> >> etc.  If the state of the art has advanced and there's a tool that can
> >> replace libtool so a developer can say "I want a shared library" and the
> >> tool builds it on all platforms then we could look into getting
> >> upstreams to switch but simply getting rid of libtool in favour of
> >> handcoding Makefiles to build shared libraries is a step in the wrong
> >> direction.
> > 
> > The state of the art is "gcc -shared".
> > 
> So gcc is the compiler everywhere these days?  Note this is a genuine
> question -- I haven't used anything besides Linux in so long I don't
> know whether Sun or anyone else is shipping their own C compiler anymore.

Sun cc is pretty similar, but solaris has gcc installed well over half
the time anyway.  *BSD and OSX are all gcc, Windows is effectively gcc
for open source projects, and there are no other operating systems.

Most of the complexity in libtool (and autotools in general) is to
support systems that simply are not worth supporting and that
practically speaking don't exist anymore.  I'm being slightly flip in
saying 'gcc -shared' but really not by much.  Honestly for any fringe
platform the correct thing to do is port gcc/binutils/gmake first.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/6ad33710/attachment.sig>

From mattdm at mattdm.org  Fri Oct 10 19:33:16 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 10 Oct 2008 15:33:16 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223655702.4410.154.camel@luminos.localdomain>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
	<48EF6C1B.4060400@odu.neva.ru>
	<16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
	<20081010151757.GD3236@free.fr>
	<16de708d0810100916s430a598at67ab1a1945760aed@mail.gmail.com>
	<1223655702.4410.154.camel@luminos.localdomain>
Message-ID: <20081010193316.GA22524@jadzia.bu.edu>

On Fri, Oct 10, 2008 at 09:21:42AM -0700, Jesse Keating wrote:
> It's like the old good, fast, cheap adage.  Pick two of those because
> that's all you'll ever get.

And in this case "good + fast" is so non-cheap that no one in the world does
it. (Given the proper long-term-support context for "good" -- I certainly
don't mean that Fedora isn't good.)

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From jkeating at redhat.com  Fri Oct 10 19:37:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 12:37:20 -0700
Subject: Regarding install options
In-Reply-To: <b53a79450810101047s7d59fb8fu49e9ff5f292cb951@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<b53a79450810101047s7d59fb8fu49e9ff5f292cb951@mail.gmail.com>
Message-ID: <1223667440.4410.177.camel@luminos.localdomain>

On Fri, 2008-10-10 at 23:17 +0530, Shambo Bose wrote:
> I am currently working on the options
> layout, and what packages can be provided under each option.

Please note, that Red Hat Linux used to offer these options, and
eventually they were so blurred as to not really make any sense.  I
suspect history would repeat itself.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/5bc120df/attachment.sig>

From seg at haxxed.com  Fri Oct 10 19:38:45 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 10 Oct 2008 14:38:45 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <48EF9F8F.3010603@gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
Message-ID: <1223667525.26341.73.camel@localhost.localdomain>

On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
> If the state of the art has advanced and there's a tool that can
> replace libtool so a developer can say "I want a shared library" and the
> tool builds it on all platforms then we could look into getting
> upstreams to switch but simply getting rid of libtool in favour of
> handcoding Makefiles to build shared libraries is a step in the wrong
> direction.

CMake! Catch the wave!

http://www.cmake.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/d678723a/attachment.sig>

From a.badger at gmail.com  Fri Oct 10 19:38:34 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 10 Oct 2008 12:38:34 -0700
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF59BB.7000205@odu.neva.ru>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
Message-ID: <48EFAF3A.9080709@gmail.com>

Dmitry Butskoy wrote:
> Itamar - IspBrasil wrote:
>>
>> any chance to increase the life of fedora releases ?
>>
>> or fedora will be only blending edge ?
>>
>> In my opinion fedora is losing space from centos and ubuntu
> 
> ...
> 
>> The brazilian government, one of the biggest Fedora Case of the world is
>> changing from Fedora/ Red Hat to Ubuntu/Debian.
> 
> The problem was at an initial point, when Fedora was considered "for
> enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
> because "it is marked as a non-for-production system even by its creators".
> 
The fact that they switched to CentOS is *good* for Fedora.  CentOS's
goals are better oriented to the needs of someone that wants to deploy a
system and run it for years.  Fedora is good for people who want to get
the latest technologies from upstream as soon as they're stable enough
to integrate into a running system.  At the same time, CentOS is a
derivative distro of Fedora.  That means that the things you learn in
CentOS will have some bearing on Fedora; the things you learn in Fedora
will have some bearing on CentOS; and if you want to affect the packages
and decisions that go into the next version of CentOS, you can have a
great deal of impact by working on those changes within Fedora.

> 
> This situation seems to be reflected in the Fedora project itself.
> Guess, how many Fedora infrastructure servers are run under the latest
> "stable" Fedora release?

As few as possible.  The reason is not about stability.  It is about
updates.  Once Fedora stops getting updates we'd have to upgrade to the
next Fedora release with all of the churn that causes for vastly
unrelated pieces of the OS.  We'd much rather spend our time developing
new features of the infrastructure and fixing bugs in our software and
deployments than updating the OS every six months and figuring out what
caused our current services to break when we do.

> Maybe some previois release? How many key
> people work under Fedora Desktop "all the time"?

I'll also add my voice here as someone who runs Fedora on all his
machines.  But I have a question of my own: is this a question intended
to inform you of the true facts of what percent of key contributors run
Fedora?  Or leading question intended to make people think that Red Hat
employees do not run Fedora without any prior research into the matter?

> (Maybe RedHat employees
> of them are compelled to use RHEL Desktop in basic working hours?)
> 
Untrue.

> And finally, when you will discover the actual situation, ask yourself
> -- why Brasilian should use Fedora (and Fedora-based RHEL), when even
> Fedora's fathers do not use it for anything real?
> 

So on the one hand, since your base assumptions about usage of Fedora by
key people is not based in fact, I probably shouldn't answer this.  On the
other, I'd like to say that there are different distributions for
different purposes.  CentOS and RHEL fill one important niche that
Fedora is unsuited for due to its fast pace.  Fedora, in turn, is going
to be the place where people who want to get their hands on new
technology sooner are going to want to be.

As for your particular use-case, mentioned in another message, it sounds
like you want to be using CentOS/RHEL and backporting the services you
need (as you say you do now).  A distribution is going to be hard
pressed to do what you want in all cases because they have to keep
sanity for all their different customers.  If you need a new version of
libxml2 to get a hot new feature, will that cause problems for other
customers?  If they need a new version of apache because the modules
they're developing requires it will that cause problems for you?

-Toshio

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

From ajax at redhat.com  Fri Oct 10 19:40:49 2008
From: ajax at redhat.com (Adam Jackson)
Date: Fri, 10 Oct 2008 15:40:49 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081010191741.GB5378@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<20081010191741.GB5378@redhat.com>
Message-ID: <1223667649.7707.18.camel@atropine.boston.devel.redhat.com>

On Fri, 2008-10-10 at 20:17 +0100, Daniel P. Berrange wrote:
> On Fri, Oct 10, 2008 at 02:51:17PM -0400, Adam Jackson wrote:
> > The state of the art is "gcc -shared".
> 
> Not so much if you're trying to build for windows. The mingw32 work
> has only been made viable because libtool has basically taken care 
> of the horrible shared library build process required by Windows.

Really?  News to me.  If you've got a link to anything documenting the
issues there I'd be interested, I've got a vested interest in keeping
the windows ports of X working but man do I hate libtool.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/cb3f1a85/attachment.sig>

From katzj at redhat.com  Fri Oct 10 19:41:37 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 10 Oct 2008 15:41:37 -0400
Subject: Regarding install options
In-Reply-To: <1223667440.4410.177.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<b53a79450810101047s7d59fb8fu49e9ff5f292cb951@mail.gmail.com>
	<1223667440.4410.177.camel@luminos.localdomain>
Message-ID: <1223667697.12340.6.camel@aglarond.local>

On Fri, 2008-10-10 at 12:37 -0700, Jesse Keating wrote:
> On Fri, 2008-10-10 at 23:17 +0530, Shambo Bose wrote:
> > I am currently working on the options
> > layout, and what packages can be provided under each option.
> 
> Please note, that Red Hat Linux used to offer these options, and
> eventually they were so blurred as to not really make any sense.  I
> suspect history would repeat itself.

To be more explicit -- between user testing, bug reports, mailing lists,
forums, etc we realized that just about everyone picked "Custom" because
they figured they had something that made them different or special.

Realistically, we actually still have install options like this -- it's
just now more about picking a live image to start from rather than
selecting something within the installer.  And if you're doing the
install from DVD or from the network, chances are that you're exactly
the sort of person that would be picking custom :-)  "Desktop-y" users
should be going more for the live images and the download page is trying
to push them in that direction[1]

Jeremy

[1] And for Fedora 10, that will be even more the case from the mockups
thus far



From seg at haxxed.com  Fri Oct 10 19:47:38 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 10 Oct 2008 14:47:38 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF5054.3040106@ispbrasil.com.br>
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <1223668058.26341.78.camel@localhost.localdomain>

On Fri, 2008-10-10 at 09:53 -0300, Itamar - IspBrasil wrote:
> forwarding message from Rodrigo Padula
> 
> any chance to increase the life of fedora releases ?
> 
> or fedora will be only blending edge ?
> 
> In my opinion fedora is losing space from centos and ubuntu

We're nearing a release so I guess it's time for dead threads to rise
again:

http://fedoraproject.org/wiki/FWN/Issue117#Long-term_Support_Release

...but I seem to be too late to nip this thread in the bud.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/64660313/attachment.sig>

From braden at endoframe.com  Fri Oct 10 19:56:24 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 10 Oct 2008 15:56:24 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223667525.26341.73.camel@localhost.localdomain>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
Message-ID: <D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>


On Oct 10, 2008, at 3:38 PM, Callum Lerwick wrote:

> On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
>> If the state of the art has advanced and there's a tool that can
>> replace libtool so a developer can say "I want a shared library"  
>> and the
>> tool builds it on all platforms then we could look into getting
>> upstreams to switch but simply getting rid of libtool in favour of
>> handcoding Makefiles to build shared libraries is a step in the wrong
>> direction.
>
> CMake! Catch the wave!
>
> http://www.cmake.org/

Um, no. That's not what he asked for.

If you want upstream to stop using libtool altogether, find a suitable  
replacement and convince the Automake developers to use it instead.

This thread is getting less constructive by the posting.  We still  
don't know the nature of the failures.

Braden



From pemboa at gmail.com  Fri Oct 10 20:05:38 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 15:05:38 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EFAF3A.9080709@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
Message-ID: <16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>

2008/10/10 Toshio Kuratomi <a.badger at gmail.com>:
> Dmitry Butskoy wrote:
>> Itamar - IspBrasil wrote:
>>>
>>> any chance to increase the life of fedora releases ?
>>>
>>> or fedora will be only blending edge ?
>>>
>>> In my opinion fedora is losing space from centos and ubuntu
>>
>> ...
>>
>>> The brazilian government, one of the biggest Fedora Case of the world is
>>> changing from Fedora/ Red Hat to Ubuntu/Debian.
>>
>> The problem was at an initial point, when Fedora was considered "for
>> enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
>> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
>> because "it is marked as a non-for-production system even by its creators".
>>
> The fact that they switched to CentOS is *good* for Fedora.  CentOS's
> goals are better oriented to the needs of someone that wants to deploy a
> system and run it for years.


They switched to Debian and Ubuntu. There is no evidence that they
considered Centos.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mmcgrath at redhat.com  Fri Oct 10 20:11:14 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 10 Oct 2008 15:11:14 -0500 (CDT)
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.0810101510580.28154@laptop.mmcgrath.net>

On Fri, 10 Oct 2008, Arthur Pemberton wrote:

> 2008/10/10 Toshio Kuratomi <a.badger at gmail.com>:
> > Dmitry Butskoy wrote:
> >> Itamar - IspBrasil wrote:
> >>>
> >>> any chance to increase the life of fedora releases ?
> >>>
> >>> or fedora will be only blending edge ?
> >>>
> >>> In my opinion fedora is losing space from centos and ubuntu
> >>
> >> ...
> >>
> >>> The brazilian government, one of the biggest Fedora Case of the world is
> >>> changing from Fedora/ Red Hat to Ubuntu/Debian.
> >>
> >> The problem was at an initial point, when Fedora was considered "for
> >> enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
> >> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
> >> because "it is marked as a non-for-production system even by its creators".
> >>
> > The fact that they switched to CentOS is *good* for Fedora.  CentOS's
> > goals are better oriented to the needs of someone that wants to deploy a
> > system and run it for years.
>
>
> They switched to Debian and Ubuntu. There is no evidence that they
> considered Centos.
>
>

According to the CentOS guys, they used CentOS at some point in time.

	-Mike



From berrange at redhat.com  Fri Oct 10 20:11:52 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 10 Oct 2008 21:11:52 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223667649.7707.18.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<20081010191741.GB5378@redhat.com>
	<1223667649.7707.18.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081010201152.GC5378@redhat.com>

On Fri, Oct 10, 2008 at 03:40:49PM -0400, Adam Jackson wrote:
> On Fri, 2008-10-10 at 20:17 +0100, Daniel P. Berrange wrote:
> > On Fri, Oct 10, 2008 at 02:51:17PM -0400, Adam Jackson wrote:
> > > The state of the art is "gcc -shared".
> > 
> > Not so much if you're trying to build for windows. The mingw32 work
> > has only been made viable because libtool has basically taken care 
> > of the horrible shared library build process required by Windows.
> 
> Really?  News to me.  If you've got a link to anything documenting the
> issues there I'd be interested, I've got a vested interest in keeping
> the windows ports of X working but man do I hate libtool.

Traditionally the problem has been that you actually need to generate two
different bits of the DLL. A runtime part and linktime part. I thought it
was still the case that you needed to generate these separately, but it 
seems the libtool docs I was reading are outdated, because the build logs
I'm looking at show it does in fact appear to do everything in one go with
-shared.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From seg at haxxed.com  Fri Oct 10 20:13:54 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 10 Oct 2008 15:13:54 -0500
Subject: tab completion less useful now, due to sbin in path
In-Reply-To: <loom.20081010T083001-855@post.gmane.org>
References: <20081001022458.GA14186@jadzia.bu.edu>
	<200810052154.15443.ville.skytta@iki.fi>
	<1223310667.9987.30.camel@luminos.localdomain>
	<200810062051.09666.ville.skytta@iki.fi>
	<1223346128.3889.17.camel@code.and.org>
	<20081007033633.GA5776@jadzia.bu.edu>
	<da159fda0810062225v7c068c6er706e3b039a0bc14e@mail.gmail.com>
	<20081007123307.GA19618@jadzia.bu.edu>
	<1223499686.26341.35.camel@localhost.localdomain>
	<1223520853.3564.1147.camel@beck.corsepiu.local>
	<48EDFE03.8020209@gmail.com>
	<1223573111.26341.48.camel@localhost.localdomain>
	<loom.20081010T083001-855@post.gmane.org>
Message-ID: <1223669634.26341.85.camel@localhost.localdomain>

On Fri, 2008-10-10 at 08:34 +0000, Kevin Kofler wrote:
> Callum Lerwick <seg <at> haxxed.com> writes:
> > Wouldn't work. You'd either have one package with a mess of dangling
> > symlinks, or you'd need a symlink package per main package which would
> > be as much or more work than just putting it in the main package to
> > begin with.
> 
> That's why Les said "if the target executable doesn't exist you aren't any 
> worse off with the symlink than without". Now that's a statement one can agree 
> or disagree with. I for one think having stuff in /usr/bin which points nowhere 
> is broken and it could actually make tab completion even less useful than the 
> status quo (depending on how smart the tab completion is with respect to broken 
> symlinks). So I think that, while this wasn't necessarily a bad idea in 
> principle, in practice (as you say) it won't work.

Well I was thinking more in terms of violating packaging guidelines.
rpmlint complains loudly about dangling symlinks. It could very well
*technically* work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/a319d914/attachment.sig>

From snecklifter at gmail.com  Fri Oct 10 20:14:10 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Fri, 10 Oct 2008 21:14:10 +0100
Subject: Heads up on ext4 changes
In-Reply-To: <48EE2BD3.2040106@redhat.com>
References: <48EE016E.8050407@redhat.com>
	<1223567969.2870.2.camel@scrappy.miketc.net>
	<48EE2BD3.2040106@redhat.com>
Message-ID: <364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>

2008/10/9 Eric Sandeen <sandeen at redhat.com>:
> Mike Chambers wrote:
>> On Thu, 2008-10-09 at 08:04 -0500, Eric Sandeen wrote:
>>
>>> (*)Yes, this does indicate that the ext4 developers feel it's time to
>>> move on past the "dev" stage; as the patch says "The ext4 filesystem is
>>> getting stable enough that it's time to drop the "dev" prefix." - as
>>> with any filesystem, though, I still encourage you to back up important
>>> data :)
>>
>> Does this mean ext4 will be available as generic during
>> installs/upgrades, same as ext3?  Or does it have to be given as an
>> option during install to get it to show up?
>
> it still takes the ext4 option on boot.

Oh come on - that makes it barely differential between
iamanext4developer. Put your nuts on the line and offer it up as an
additional option on install - I dare you. I thought Fedora was
bleeding edge! I miss that heart-racing feeling when I _just dont
know_ if my data is coming back up on reboot... :)


-- 
Christopher Brown

http://www.chruz.com



From braden at endoframe.com  Fri Oct 10 19:11:57 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 10 Oct 2008 15:11:57 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <48EF9F8F.3010603@gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
Message-ID: <3E591139-DF7D-4210-AEFF-3C5DB634329D@endoframe.com>


On Oct 10, 2008, at 2:31 PM, Toshio Kuratomi wrote:

> David Woodhouse wrote:
>> On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
>>> Getting libtool-2.2 into F-11 is my plan, but I most likely need  
>>> to get that through
>>> FESCo as it breaks up to 300 packages according to my mass  
>>> rebuilds. I'm going to
>>> prepare a Wiki page with details about that.
>>
>> Isn't the whole point of libtool that it should make things _easier_,
>> not break huge swathes of packages whenever we change it?
>>
>> How about we fix those 300 packages by making them _not_ use libtool,
>> rather than making them use the latest version?
>>
> Hand coding Makefiles to compile shared libraries on all platforms  
> is .
> Before libtools many upstreams simply wouldn't package shared  
> libraries
> because of all the problems with getting it right for SunOS, Solaris,
> OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc,  
> acc,
> etc.  If the state of the art has advanced and there's a tool that can
> replace libtool so a developer can say "I want a shared library" and  
> the
> tool builds it on all platforms then we could look into getting
> upstreams to switch but simply getting rid of libtool in favour of
> handcoding Makefiles to build shared libraries is a step in the wrong
> direction.

Spec files that are breaking because they're running libtoolize/ 
auto[re]conf should be fixed, obviously. Wholesale replacement of  
packages' build systems is intractable and a silly suggestion.

This conversation really can't proceed productively without some  
concrete information about the nature of the failures.

Braden



From snecklifter at gmail.com  Fri Oct 10 20:15:00 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Fri, 10 Oct 2008 21:15:00 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223668058.26341.78.camel@localhost.localdomain>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223668058.26341.78.camel@localhost.localdomain>
Message-ID: <364d303b0810101315n5ec5dc39n5452db112b134ea8@mail.gmail.com>

2008/10/10 Callum Lerwick <seg at haxxed.com>:
> On Fri, 2008-10-10 at 09:53 -0300, Itamar - IspBrasil wrote:
>> forwarding message from Rodrigo Padula
>>
>> any chance to increase the life of fedora releases ?
>>
>> or fedora will be only blending edge ?
>>
>> In my opinion fedora is losing space from centos and ubuntu
>
> We're nearing a release so I guess it's time for dead threads to rise
> again:
>
> http://fedoraproject.org/wiki/FWN/Issue117#Long-term_Support_Release

No I think this horse is still twitching a litttle...

-- 
Christopher Brown

http://www.chruz.com



From mw_triad at users.sourceforge.net  Fri Oct 10 20:15:01 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 10 Oct 2008 15:15:01 -0500
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223666666.7707.13.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>	<1223658387.6770.53.camel@macbook.infradead.org>	<48EF9F8F.3010603@gmail.com>	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>	<48EFA7EC.6000607@gmail.com>
	<1223666666.7707.13.camel@atropine.boston.devel.redhat.com>
Message-ID: <gcod45$l62$1@ger.gmane.org>

Adam Jackson wrote:
> Sun cc is pretty similar, but solaris has gcc installed well over half
> the time anyway.  *BSD and OSX are all gcc, Windows is effectively gcc
> for open source projects, and there are no other operating systems.

Huh? There's OSF, HP-UX, and AIX, all of which I still deal with.

> Most of the complexity in libtool (and autotools in general) is to
> support systems that simply are not worth supporting and that
> practically speaking don't exist anymore.  I'm being slightly flip in
> saying 'gcc -shared' but really not by much.  Honestly for any fringe
> platform the correct thing to do is port gcc/binutils/gmake first.

Porting gmake is easy, porting binutils/gcc is hard and not likely to 
work with the system libraries. And people sometimes use other compilers 
(e.g. icc) even when gcc is available.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
C++ is for people who want to be able to not just shoot themselves in 
the foot, but do it with a rocket launcher. -- Igor Peshansky



From a.badger at gmail.com  Fri Oct 10 20:13:51 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 10 Oct 2008 13:13:51 -0700
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>
	<16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>
Message-ID: <48EFB77F.2040807@gmail.com>

Arthur Pemberton wrote:
> 2008/10/10 Toshio Kuratomi <a.badger at gmail.com>:
>> Dmitry Butskoy wrote:
>>>
>>>> The brazilian government, one of the biggest Fedora Case of the world is
>>>> changing from Fedora/ Red Hat to Ubuntu/Debian.
>>> The problem was at an initial point, when Fedora was considered "for
>>> enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
>>> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
>>> because "it is marked as a non-for-production system even by its creators".
>>>
>> The fact that they switched to CentOS is *good* for Fedora.  CentOS's
>> goals are better oriented to the needs of someone that wants to deploy a
>> system and run it for years.
> 
> 
> They switched to Debian and Ubuntu. There is no evidence that they
> considered Centos.
> 
Clarification: Wikipedia switched to Debian/Ubuntu.  Dmitry is talking
about the amorphous mass of "RedHat Linux enthusiasts" during the early
Fedora days.

-Toshio

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

From sandeen at redhat.com  Fri Oct 10 20:15:45 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 10 Oct 2008 15:15:45 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>	<1223567969.2870.2.camel@scrappy.miketc.net>	<48EE2BD3.2040106@redhat.com>
	<364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>
Message-ID: <48EFB7F1.9090102@redhat.com>

Christopher Brown wrote:
> 2008/10/9 Eric Sandeen <sandeen at redhat.com>:
>> Mike Chambers wrote:
>>> On Thu, 2008-10-09 at 08:04 -0500, Eric Sandeen wrote:
>>>
>>>> (*)Yes, this does indicate that the ext4 developers feel it's time to
>>>> move on past the "dev" stage; as the patch says "The ext4 filesystem is
>>>> getting stable enough that it's time to drop the "dev" prefix." - as
>>>> with any filesystem, though, I still encourage you to back up important
>>>> data :)
>>> Does this mean ext4 will be available as generic during
>>> installs/upgrades, same as ext3?  Or does it have to be given as an
>>> option during install to get it to show up?
>> it still takes the ext4 option on boot.
> 
> Oh come on - that makes it barely differential between
> iamanext4developer. Put your nuts on the line and offer it up as an
> additional option on install - I dare you. I thought Fedora was
> bleeding edge! I miss that heart-racing feeling when I _just dont
> know_ if my data is coming back up on reboot... :)

too late for the fedora feature process, otherwise I'd be tempted....

-Eric



From snecklifter at gmail.com  Fri Oct 10 20:18:01 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Fri, 10 Oct 2008 21:18:01 +0100
Subject: Heads up on ext4 changes
In-Reply-To: <48EFB7F1.9090102@redhat.com>
References: <48EE016E.8050407@redhat.com>
	<1223567969.2870.2.camel@scrappy.miketc.net>
	<48EE2BD3.2040106@redhat.com>
	<364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>
	<48EFB7F1.9090102@redhat.com>
Message-ID: <364d303b0810101318u553cc159q4ad1170ad7c9b5ca@mail.gmail.com>

2008/10/10 Eric Sandeen <sandeen at redhat.com>:
> Christopher Brown wrote:
>> 2008/10/9 Eric Sandeen <sandeen at redhat.com>:
>>> Mike Chambers wrote:
>>>> On Thu, 2008-10-09 at 08:04 -0500, Eric Sandeen wrote:
>>>>
>>>>> (*)Yes, this does indicate that the ext4 developers feel it's time to
>>>>> move on past the "dev" stage; as the patch says "The ext4 filesystem is
>>>>> getting stable enough that it's time to drop the "dev" prefix." - as
>>>>> with any filesystem, though, I still encourage you to back up important
>>>>> data :)
>>>> Does this mean ext4 will be available as generic during
>>>> installs/upgrades, same as ext3?  Or does it have to be given as an
>>>> option during install to get it to show up?
>>> it still takes the ext4 option on boot.
>>
>> Oh come on - that makes it barely differential between
>> iamanext4developer. Put your nuts on the line and offer it up as an
>> additional option on install - I dare you. I thought Fedora was
>> bleeding edge! I miss that heart-racing feeling when I _just dont
>> know_ if my data is coming back up on reboot... :)
>
> too late for the fedora feature process, otherwise I'd be tempted....

Fair enough. I'll settle for default on F11 then.


-- 
Christopher Brown

http://www.chruz.com



From skvidal at fedoraproject.org  Fri Oct 10 20:11:55 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 10 Oct 2008 16:11:55 -0400
Subject: Outage Notification - 2008-10-11 03:00 UTC
Message-ID: <1223669515.27425.10.camel@rosebud>

Outage Notification - 2008-10-11 03:00 UTC

There will be an outage starting at 2008-10-11 03:00 UTC, which will last
approximately 2 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-10-11 03:00 UTC'

Affected Services:
Fedora People

Unaffected Services:
Buildsystem
CVS / Source Control
Database
DNS
Fedora Hosted
Fedora Talk
Mail
Mirror System
Torrent
Translation Services
Websites


Reason for Outage: Migrating fedorapeople.org from Duke University hosting to 
Boston University hosting.

Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to track
the status of this outage.


_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From pbrobinson at gmail.com  Fri Oct 10 20:36:17 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Fri, 10 Oct 2008 21:36:17 +0100
Subject: Heads up on ext4 changes
In-Reply-To: <364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>
	<1223567969.2870.2.camel@scrappy.miketc.net>
	<48EE2BD3.2040106@redhat.com>
	<364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>
Message-ID: <5256d0b0810101336g539f5b78m4f0713ed04c44666@mail.gmail.com>

>>>> (*)Yes, this does indicate that the ext4 developers feel it's time to
>>>> move on past the "dev" stage; as the patch says "The ext4 filesystem is
>>>> getting stable enough that it's time to drop the "dev" prefix." - as
>>>> with any filesystem, though, I still encourage you to back up important
>>>> data :)
>>>
>>> Does this mean ext4 will be available as generic during
>>> installs/upgrades, same as ext3?  Or does it have to be given as an
>>> option during install to get it to show up?
>>
>> it still takes the ext4 option on boot.
>
> Oh come on - that makes it barely differential between
> iamanext4developer. Put your nuts on the line and offer it up as an
> additional option on install - I dare you. I thought Fedora was
> bleeding edge! I miss that heart-racing feeling when I _just dont
> know_ if my data is coming back up on reboot... :)

Are you going to put your nuts on the line and provide the support to
the end users when they don't get their data back on reboot?

Peter



From seg at haxxed.com  Fri Oct 10 20:56:06 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 10 Oct 2008 15:56:06 -0500
Subject: CMake!
In-Reply-To: <D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
Message-ID: <1223672167.26341.100.camel@localhost.localdomain>

On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote:
> On Oct 10, 2008, at 3:38 PM, Callum Lerwick wrote:
> 
> > On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
> >> If the state of the art has advanced and there's a tool that can
> >> replace libtool so a developer can say "I want a shared library"  
> >> and the
> >> tool builds it on all platforms then we could look into getting
> >> upstreams to switch but simply getting rid of libtool in favour of
> >> handcoding Makefiles to build shared libraries is a step in the wrong
> >> direction.
> >
> > CMake! Catch the wave!
> >
> > http://www.cmake.org/
> 
> Um, no. That's not what he asked for.
> 
> If you want upstream to stop using libtool altogether, find a suitable  
> replacement and convince the Automake developers to use it instead.

Why the h8? He was speaking in the context of "the state of the art" and
in my oh-so-humble opinion CMake is it. The whole of the Autotools stack
is very much... not. Last I checked I was just some random guy on the
internet who has sadly not been granted the power to force anyone to do
anything.

> This thread is getting less constructive by the posting.  We still  
> don't know the nature of the failures.

There, does changing the subject make you happier?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/55eb63d3/attachment.sig>

From mcepl at redhat.com  Fri Oct 10 20:53:59 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 10 Oct 2008 22:53:59 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com>
Message-ID: <70s4s5x57i.ln2@ppp1053.in.ipex.cz>

On 2008-10-10, 15:49 GMT, Les Mikesell wrote:
> What we need for the same effect now is for the versions of 
> fedora that provide the initial RHEL cuts to offer a seamless 
> update to the subsequent matching CentOS, repointing to its 
> update repositories for continued support.

How is it different from just using CentOS?

Mat?j



From dbn.lists at gmail.com  Fri Oct 10 21:02:42 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 10 Oct 2008 14:02:42 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223658387.6770.53.camel@macbook.infradead.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
Message-ID: <91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>

On Fri, Oct 10, 2008 at 10:06 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
>> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
>> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
>> prepare a Wiki page with details about that.
>
> Isn't the whole point of libtool that it should make things _easier_,
> not break huge swathes of packages whenever we change it?

The amount of breakage is usually very minor. The big thing that
caused breakage is that libtool-1.5 used to automatically haul in
configuration for C, C++ and fortran. Certainly you've seen this in a
configure run where it's checking for gcc, then g++, then g77. With
libtool-2.2, you have to specify if you need more than C. See here:

http://www.gnu.org/software/libtool/manual/libtool.html#index-LT_005fLANG-89

And an example patch where the package was broken using libtool-2.2:

http://lists.freedesktop.org/archives/hal/2008-May/011730.html

Pretty basic. I'm guessing someone could plow through and fix all
these issues pretty quickly. Gentoo has already been doing this for
months, so it would be straightforward to find any necessary patches.

--
Dan



From mcepl at redhat.com  Fri Oct 10 20:56:15 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 10 Oct 2008 22:56:15 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <48EF731F.40209@odu.neva.ru>
Message-ID: <f4s4s5x57i.ln2@ppp1053.in.ipex.cz>

On 2008-10-10, 15:22 GMT, Dmitry Butskoy wrote:
> Kinda black-white mentality?  ;)

I have spent a lot of time with RH Linux, 
Debian/{stable,testing,unstable} and now two years with Fedora -- 
I think I have some idea what I am talking about.

And you know, I know it is not fashionable, it is worthy to 
remember that sometimes there is black and white, and not 
everything is grey (thanks God!).

Mat?j



From alsadi at gmail.com  Fri Oct 10 21:08:39 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sat, 11 Oct 2008 00:08:39 +0300
Subject: Arabic and Hebrew on the console
In-Reply-To: <48EE843B.20009@behdad.org>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>
	<48EE843B.20009@behdad.org>
Message-ID: <385866f0810101408k57c4e65wc339a4ffff9cae69@mail.gmail.com>

>
>> Should we leave it this way, or do the same substitution to en_US that
>> we do for CJK locales?
>
> In the short term (F10...), this makes perfect sense.
>
> behdad
>
the patch is attached

please also consider this one too
https://bugzilla.redhat.com/show_bug.cgi?id=454105
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Disable-Arabic-and-RTL-Languages-in-VT.patch
Type: application/octet-stream
Size: 1827 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/38366f84/attachment.obj>

From sundaram at fedoraproject.org  Fri Oct 10 21:14:17 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 11 Oct 2008 02:44:17 +0530
Subject: Heads up on ext4 changes
In-Reply-To: <364d303b0810101318u553cc159q4ad1170ad7c9b5ca@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>	<1223567969.2870.2.camel@scrappy.miketc.net>	<48EE2BD3.2040106@redhat.com>	<364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>	<48EFB7F1.9090102@redhat.com>
	<364d303b0810101318u553cc159q4ad1170ad7c9b5ca@mail.gmail.com>
Message-ID: <48EFC5A9.9020506@fedoraproject.org>

Christopher Brown wrote:
> 
> Fair enough. I'll settle for default on F11 then.

Considering the btrfs roadmap, It might very well be the default. Eric 
Sandeen seems to have missed his only opportunity ;-)

Rahul




From braden at endoframe.com  Fri Oct 10 21:20:30 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 10 Oct 2008 17:20:30 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
Message-ID: <48EFC71E.5060607@endoframe.com>

Dan Nicholson wrote:
> On Fri, Oct 10, 2008 at 10:06 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> On Wed, 2008-10-08 at 19:36 +0200, Karsten Hopp wrote:
>>> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get that through
>>> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm going to
>>> prepare a Wiki page with details about that.
>> Isn't the whole point of libtool that it should make things _easier_,
>> not break huge swathes of packages whenever we change it?
> 
> The amount of breakage is usually very minor. The big thing that
> caused breakage is that libtool-1.5 used to automatically haul in
> configuration for C, C++ and fortran. Certainly you've seen this in a
> configure run where it's checking for gcc, then g++, then g77. With
> libtool-2.2, you have to specify if you need more than C. See here:
> 
> http://www.gnu.org/software/libtool/manual/libtool.html#index-LT_005fLANG-89
> 
> And an example patch where the package was broken using libtool-2.2:
> 
> http://lists.freedesktop.org/archives/hal/2008-May/011730.html
> 
> Pretty basic. I'm guessing someone could plow through and fix all
> these issues pretty quickly. Gentoo has already been doing this for
> months, so it would be straightforward to find any necessary patches.

A copy of the libtool script is typically included in a package. 
Breakage such as that patch fixes would only be incurred if 
libtoolize/autoreconf were run as part of the build process--something 
that simply shouldn't be happening in general for RPM builds.

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From rc040203 at freenet.de  Fri Oct 10 21:27:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 10 Oct 2008 23:27:09 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <935ead450810100708j6935696erd242e9d9250d0376@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<935ead450810100708j6935696erd242e9d9250d0376@mail.gmail.com>
Message-ID: <1223674029.3564.1252.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 09:08 -0500, Jeffrey Ollie wrote:
> On Fri, Oct 10, 2008 at 8:33 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> >
> > This situation seems to be reflected in the Fedora project itself. Guess,
> > how many Fedora infrastructure servers are run under the latest "stable"
> > Fedora release?
> 
> Almost none.  The reason is simple - the Fedora project does not have
> infinite resources, the most important of which is time.

Yes, the reasons are simple, but I see different reasons than you:
* Fedora has focused too much on Desktops.
* The Fedora project works inefficiently (too much bureaucracy, too many
"closed circles", too little cooperation, too much egoism ...)

=> Result: Lack of people.

Ralf







From mcepl at redhat.com  Fri Oct 10 21:01:07 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 10 Oct 2008 23:01:07 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<16de708d0810100739h7803e40ds538b9680e555555f@mail.gmail.com>
	<48EF6C1B.4060400@odu.neva.ru>
	<16de708d0810100813u19c4c1bcm758e079cc7e04b86@mail.gmail.com>
	<20081010151757.GD3236@free.fr>
	<16de708d0810100916s430a598at67ab1a1945760aed@mail.gmail.com>
Message-ID: <jds4s5x57i.ln2@ppp1053.in.ipex.cz>

On 2008-10-10, 16:16 GMT, Arthur Pemberton wrote:
> Are there any distros which are very current, stable _and_ 
> source of a lot of development in the Linux/FOSS community?  
> Seems to me, that once can any given distro can only have two 
> out of three of those properties.

Two? Which one is "very current and stable"?

Mat?j



From braden at endoframe.com  Fri Oct 10 21:31:35 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 10 Oct 2008 17:31:35 -0400
Subject: CMake!
In-Reply-To: <1223672167.26341.100.camel@localhost.localdomain>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>	<1223658387.6770.53.camel@macbook.infradead.org>	<48EF9F8F.3010603@gmail.com>	<1223667525.26341.73.camel@localhost.localdomain>	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
Message-ID: <48EFC9B7.50307@endoframe.com>

Callum Lerwick wrote:
> On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote:
>> On Oct 10, 2008, at 3:38 PM, Callum Lerwick wrote:
>>
>>> On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
>>>> If the state of the art has advanced and there's a tool that can
>>>> replace libtool so a developer can say "I want a shared library"  
>>>> and the
>>>> tool builds it on all platforms then we could look into getting
>>>> upstreams to switch but simply getting rid of libtool in favour of
>>>> handcoding Makefiles to build shared libraries is a step in the wrong
>>>> direction.
>>> CMake! Catch the wave!
>>>
>>> http://www.cmake.org/
>> Um, no. That's not what he asked for.
>>
>> If you want upstream to stop using libtool altogether, find a suitable  
>> replacement and convince the Automake developers to use it instead.
> 
> Why the h8? He was speaking in the context of "the state of the art" and
> in my oh-so-humble opinion CMake is it.

No, he was speaking in terms of something that could replace libtool 
upstream in (presumably some relatively high percentage of) 300 
packages. And CMake is so, *so* not it. I don't know if anything is 
"it". But the notion that Fedora is going to get ~300 upstream projects 
to make wholesale changes to their build systems is profoundly detached 
from reality.

> The whole of the Autotools stack
> is very much... not.

Maybe. But a tool that is less extensible than them is likely to be 
perceived as a step in the wrong direction by a fair number of build 
system maintainers.

> Last I checked I was just some random guy on the
> internet who has sadly not been granted the power to force anyone to do
> anything.

You have the power to affect the signal-to-noise ratio. Please use it 
wisely.

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From forum at ru.bir.ru  Fri Oct 10 21:32:44 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sat, 11 Oct 2008 01:32:44 +0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <d654s5x9eo.ln2@ppp1053.in.ipex.cz>
References: <48EF5054.3040106@ispbrasil.com.br>	<bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>
	<d654s5x9eo.ln2@ppp1053.in.ipex.cz>
Message-ID: <gcohlt$3k0$1@ger.gmane.org>

Matej Cepl ?????:
> On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
>> I would submit that CentOS/RHEL IS the equivalent of
>> Fedora LTS.
> 
> I would venture even to say that CentOS *is* Fedora LTS
I agree what CentOS is more stable and has more time support, but it is 
totally not equivalent of Fedora. Just see CVS branches of programs for 
Fedora and RHEL. So, many (notably new and not highly famous) programs 
is not present in RHEL and CentOS.



From rc040203 at freenet.de  Fri Oct 10 21:35:36 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 10 Oct 2008 23:35:36 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EFAF3A.9080709@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>  <48EFAF3A.9080709@gmail.com>
Message-ID: <1223674536.3564.1262.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> Dmitry Butskoy wrote:
> > Itamar - IspBrasil wrote:
> >>
> >> any chance to increase the life of fedora releases ?
> >>
> >> or fedora will be only blending edge ?
> >>
> >> In my opinion fedora is losing space from centos and ubuntu
> > 
> > ...
> > 
> >> The brazilian government, one of the biggest Fedora Case of the world is
> >> changing from Fedora/ Red Hat to Ubuntu/Debian.
> > 
> > The problem was at an initial point, when Fedora was considered "for
> > enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
> > switch to CentOS (and similar RHEL-based systems), no more using Fedora,
> > because "it is marked as a non-for-production system even by its creators".
> > 
> The fact that they switched to CentOS is *good* for Fedora. 
I can not disagree more - To me, it's yet another evidence of Fedora
being on the loose.

>  CentOS's
> goals are better oriented to the needs of someone that wants to deploy a
> system and run it for years.  Fedora is good for people who want to get
> the latest technologies from upstream as soon as they're stable enough
> to integrate into a running system.
Right. But why can't Fedora do better? I feel Fedora could do better.

> > This situation seems to be reflected in the Fedora project itself.
> > Guess, how many Fedora infrastructure servers are run under the latest
> > "stable" Fedora release?
> 
> As few as possible.
IMO, a fundamental management/infrastructure mistake - If these people
were using Fedora, they would be facing the issues Fedora users are
facing everyday and likely would being to understand why people complain
about Fedora.

>   The reason is not about stability.  It is about
> updates.  Once Fedora stops getting updates we'd have to upgrade to the
> next Fedora release with all of the churn that causes for vastly
> unrelated pieces of the OS. 
Gotcha! If not even the Fedora project can handle the issues, why do you
expect users to be able to solve them? I think technically the issues
can be overcome. It's a matter of will.

Ralf




From sundaram at fedoraproject.org  Fri Oct 10 21:35:10 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 11 Oct 2008 03:05:10 +0530
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gcohlt$3k0$1@ger.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>	<d654s5x9eo.ln2@ppp1053.in.ipex.cz>
	<gcohlt$3k0$1@ger.gmane.org>
Message-ID: <48EFCA8E.5050805@fedoraproject.org>

Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> Matej Cepl ?????:
>> On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
>>> I would submit that CentOS/RHEL IS the equivalent of
>>> Fedora LTS.
>>
>> I would venture even to say that CentOS *is* Fedora LTS
> I agree what CentOS is more stable and has more time support, but it is 
> totally not equivalent of Fedora. Just see CVS branches of programs for 
> Fedora and RHEL. So, many (notably new and not highly famous) programs 
> is not present in RHEL and CentOS.

About 2000 more in EPEL. http://fedoraproject.org/wiki/EPEL. 
Participate, if you would like to see your (missing) favourites as well.

Rahul



From dbn.lists at gmail.com  Fri Oct 10 21:36:33 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 10 Oct 2008 14:36:33 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223666666.7707.13.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<48EFA7EC.6000607@gmail.com>
	<1223666666.7707.13.camel@atropine.boston.devel.redhat.com>
Message-ID: <91705d080810101436p77f6f5cbhec618f201cc4b5fe@mail.gmail.com>

2008/10/10 Adam Jackson <ajax at redhat.com>:
>
> Most of the complexity in libtool (and autotools in general) is to
> support systems that simply are not worth supporting and that
> practically speaking don't exist anymore.  I'm being slightly flip in
> saying 'gcc -shared' but really not by much.  Honestly for any fringe
> platform the correct thing to do is port gcc/binutils/gmake first.

That's noble and all, but in the meantime I tend to like relying on
the years of experiences built into libtool. Taken a look at mesa's
bin/mklib lately? Tell me if you ever want to work on something like
that. You may have noticed how dolt doesn't touch the linking part of
libtool at all.

Something that people seem to forget about when bashing libtool is all
the flexibility it offers. Like convenience libraries? Like easily
deciding if you want static or shared libraries? Like having your
programs work while their in the source tree? Like having your so
version and symlinks handled automatically?

--
Dan



From kevin.kofler at chello.at  Fri Oct 10 21:38:22 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 10 Oct 2008 21:38:22 +0000 (UTC)
Subject: Status of libtool 2.2.X?
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<20081010191741.GB5378@redhat.com>
	<1223667649.7707.18.camel@atropine.boston.devel.redhat.com>
	<20081010201152.GC5378@redhat.com>
Message-ID: <loom.20081010T212845-842@post.gmane.org>

Daniel P. Berrange <berrange <at> redhat.com> writes:
> Traditionally the problem has been that you actually need to generate two
> different bits of the DLL. A runtime part and linktime part.

MinGW can actually link a DLL directly these days. However, that feature is 
rarely used in practice for a few reasons:
* Linking a DLL directly means you need to have it - this eliminates the native 
Window$ DLLs for cross-compiling, so I expect w32api to keep coming with import 
libraries for the foreseeable future.
* M$VC doesn't support it, so projects wanting to also support M$VC also have 
to support import libraries anyway (even if there's the added complexity that 
an import library for one compiler doesn't work with the other, one has to 
generate them both from the .def file, or use some convoluted process to 
convert one to the other (basically, reverse-engineering a .def first and then 
building the other import library from that) - that's why you see libraries 
coming with both a .lib and a .a import library: .lib is for M$VC, .a for 
MinGW).
* The usual layout for Free Software libraries on Window$ (at least all the 
major ones I've seen: GNUWIN32 packages, GTK+ packages, KDE 4 packages) has the 
DLLs in bin so they're found by the executables also in bin without search path 
tweaking, but the linker won't look in bin for libraries (unless you use a -L 
switch, and libraries are not set up to do that with a bin directory), so 
having the import library in lib is helpful.

        Kevin Kofler



From emmanuel.seyman at club-internet.fr  Fri Oct 10 21:44:38 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 10 Oct 2008 23:44:38 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010162836.GF3236@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<20081010160923.GA5293@orient.maison.lan>
	<20081010162836.GF3236@free.fr>
Message-ID: <20081010214438.GB7389@orient.maison.lan>

* Patrice Dumas [10/10/2008 19:45] :
>
> When it requires cooperation with the infrastructure, it does.

How so ?

Reading through the archives, your project was to extend support
for Fedora releases past EOL on a volunteer basis. That doesn't
require cooperation from the Fedora Powers That Be, nor does it
require the Fedora infrastructure.

Emmanuel



From rc040203 at freenet.de  Fri Oct 10 21:45:14 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 10 Oct 2008 23:45:14 +0200
Subject: Package review backlog.
In-Reply-To: <1223644448.6770.18.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
Message-ID: <1223675114.3564.1266.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 14:14 +0100, David Woodhouse wrote:
> On Fri, 2008-10-10 at 02:12 +0200, Christoph Wickert wrote:
> > Am Donnerstag, den 09.10.2008, 20:01 -0400 schrieb Josh Boyer:
> > > On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
> > > >> Let's get the final two packages reviewed -- and that's another area
> > > >> where we could do with some improvement, because failing to approve
> > > >> packages really _is_ verging on the 'deletionism' you spoke of. But
> > > >> that's a separate discussion.
> > > >
> > > >Agreed, we can discuss this later. BTW: The word "deletionsm" did not
> > > >come from me, it was Josh who said that, but of course I agree with him.
> > > 
> > > I didn't say that.  Though I agree we need to be getting more packages
> > > approved.
> > 
> > I think this is something we all agree on. ;)
> 
> I propose that each FESCo member should try to work on at least one
> package review per week.
+1. Such a step is way over due.

Ralf




From sandeen at redhat.com  Fri Oct 10 21:47:34 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 10 Oct 2008 16:47:34 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <48EFC5A9.9020506@fedoraproject.org>
References: <48EE016E.8050407@redhat.com>	<1223567969.2870.2.camel@scrappy.miketc.net>	<48EE2BD3.2040106@redhat.com>	<364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>	<48EFB7F1.9090102@redhat.com>	<364d303b0810101318u553cc159q4ad1170ad7c9b5ca@mail.gmail.com>
	<48EFC5A9.9020506@fedoraproject.org>
Message-ID: <48EFCD76.4030904@redhat.com>

Rahul Sundaram wrote:
> Christopher Brown wrote:
>> Fair enough. I'll settle for default on F11 then.
> 
> Considering the btrfs roadmap, It might very well be the default. Eric 
> Sandeen seems to have missed his only opportunity ;-)

btrfs is making great progress, Rahul, but I'd be willing to place a
small wager on it *not* being the default for F11 :)

-Eric



From rc040203 at freenet.de  Fri Oct 10 21:49:08 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 10 Oct 2008 23:49:08 +0200
Subject: Regarding install options
In-Reply-To: <1223655604.4410.153.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
Message-ID: <1223675348.3564.1271.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 09:20 -0700, Jesse Keating wrote:
> On Fri, 2008-10-10 at 10:42 +0530, Shambo Bose wrote:
> > 1. Desktop Install.
> > 
> > 2. Server Install.
> 
> Tell you what.  Try to get the majority of fedora-devel contributors to
> agree on what should be in each of those installs.
Provide a "minimal install" as install option, such that sysadmins can
add what they want, instead of forcing them to "manually minimize the
distro", as you are doing it now.






From jkeating at redhat.com  Fri Oct 10 21:52:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 14:52:13 -0700
Subject: Regarding install options
In-Reply-To: <1223675348.3564.1271.camel@beck.corsepiu.local>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
Message-ID: <1223675533.4410.183.camel@luminos.localdomain>

On Fri, 2008-10-10 at 23:49 +0200, Ralf Corsepius wrote:
> Provide a "minimal install" as install option, such that sysadmins can
> add what they want, instead of forcing them to "manually minimize the
> distro", as you are doing it now.

Great, now get consensus on what 'minimal' should be.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/f9bf6d6e/attachment.sig>

From pemboa at gmail.com  Fri Oct 10 21:53:20 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 16:53:20 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223674536.3564.1262.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
Message-ID: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>

On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>> Dmitry Butskoy wrote:
>> > Itamar - IspBrasil wrote:
[snip]
>> The fact that they switched to CentOS is *good* for Fedora.
> I can not disagree more - To me, it's yet another evidence of Fedora
> being on the loose.

You're going to have to expound on that. I do not see Centos in any
way as in competition with Fedora. Centos is something everyone should
be proud of.


>>  CentOS's
>> goals are better oriented to the needs of someone that wants to deploy a
>> system and run it for years.  Fedora is good for people who want to get
>> the latest technologies from upstream as soon as they're stable enough
>> to integrate into a running system.
> Right. But why can't Fedora do better? I feel Fedora could do better.

Sure. With more devs, servers, time, etc. But baring a sudden increase
in those, I would much prefer to see Fedora focus on dev and testing,
let other distros pretty things up.


>> > This situation seems to be reflected in the Fedora project itself.
>> > Guess, how many Fedora infrastructure servers are run under the latest
>> > "stable" Fedora release?
>>
>> As few as possible.
> IMO, a fundamental management/infrastructure mistake - If these people
> were using Fedora, they would be facing the issues Fedora users are
> facing everyday and likely would being to understand why people complain
> about Fedora.

Why would they, after often suggesting that Fedora _not_ be used on
production servers, use Fedora on their production servers?


>>   The reason is not about stability.  It is about
>> updates.  Once Fedora stops getting updates we'd have to upgrade to the
>> next Fedora release with all of the churn that causes for vastly
>> unrelated pieces of the OS.
> Gotcha! If not even the Fedora project can handle the issues, why do you
> expect users to be able to solve them? I think technically the issues
> can be overcome. It's a matter of will.

Well, it's not really an issue. It's only an issue if you run Fedora
on your production servers. Which, again is up to you, not
recommended, and as such no one expects users to "solve" this problem
either.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From behdad at behdad.org  Fri Oct 10 21:56:29 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Fri, 10 Oct 2008 17:56:29 -0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EF5054.3040106@ispbrasil.com.br>
References: <48EF5054.3040106@ispbrasil.com.br>
Message-ID: <48EFCF8D.1050904@behdad.org>

Itamar - IspBrasil wrote:
> forwarding message from Rodrigo Padula
> 
> any chance to increase the life of fedora releases ?
> 
> or fedora will be only blending edge ?
> 
> In my opinion fedora is losing space from centos and ubuntu

I agree with the rest of the threda that CentOS *is* Fedora LTS!
The major problem Wikipedia faced seems to me more being that
Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
upgrades quite nicely.  *That* seems to be a major weakness of us.

My 0.02CAD
behdad

> 
> -------- Original Message --------
> Subject:     Wikipidia - Goodbye Red Hat and Fedora
> Date:     Fri, 10 Oct 2008 09:42:55 -0300
> From:     Rodrigo Padula de Oliveira <rodrigopadula at projetofedora.org>
> Reply-To:     For discussions about marketing and expanding the Fedora
> user base <fedora-marketing-list at redhat.com>
> To:     For discussions about marketing and expanding the Fedora user
> base <fedora-marketing-list at redhat.com>
> 
> 
> 
> Hello Guys!
> 
> Read this bad news:
> 
> http://www.linuxworld.com.au/index.php/id;1474805050;fp;16;fpid;1
> 
> This is happening frequently. I think we will have to revise some things
> within the project, particularly the creation of a Legacy project or a
> Fedora LTS.
> 
> The brazilian government, one of the biggest Fedora Case of the world is
> changing from Fedora/ Red Hat to Ubuntu/Debian.
> 
> We need to think and create a solution to give support by a long time or
> the fedora user will decrease!
> 
> My 0,02
> 



From pemboa at gmail.com  Fri Oct 10 22:03:22 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 10 Oct 2008 17:03:22 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EFCF8D.1050904@behdad.org>
References: <48EF5054.3040106@ispbrasil.com.br> <48EFCF8D.1050904@behdad.org>
Message-ID: <16de708d0810101503q63dca4acq206f5d4d6581e62e@mail.gmail.com>

On Fri, Oct 10, 2008 at 4:56 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
> Itamar - IspBrasil wrote:
>> forwarding message from Rodrigo Padula
>>
>> any chance to increase the life of fedora releases ?
>>
>> or fedora will be only blending edge ?
>>
>> In my opinion fedora is losing space from centos and ubuntu
>
> I agree with the rest of the threda that CentOS *is* Fedora LTS!
> The major problem Wikipedia faced seems to me more being that
> Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
> upgrades quite nicely.  *That* seems to be a major weakness of us.


I saw no mention of Centos, though someone in the thread mentioned
that it had been attempted. Your point about upgrade makes sense,
though I find it pretty weak. Is doing an inplace upgrade on a
production server common? I don't think so, but I am quite possibly
wrong.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pertusus at free.fr  Fri Oct 10 22:03:51 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 11 Oct 2008 00:03:51 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010214438.GB7389@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<20081010160923.GA5293@orient.maison.lan>
	<20081010162836.GF3236@free.fr>
	<20081010214438.GB7389@orient.maison.lan>
Message-ID: <20081010220351.GB3381@free.fr>

On Fri, Oct 10, 2008 at 11:44:38PM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [10/10/2008 19:45] :
> >
> > When it requires cooperation with the infrastructure, it does.
> 
> How so ?
> 
> Reading through the archives, your project was to extend support
> for Fedora releases past EOL on a volunteer basis. That doesn't

But within the fedora infrastructure, and with the fedora rules (unlike 
fedora legacy that had different infrastructure and rules).

If I had my own infrastructure, I would still be maintaining some
packages for oldest releases.

As a side note, I think that in the end my project would certainly have
failed because I don't think that somebody would have stepped up to take
the big ones, like glibc, kernel, gcc but this would have been an
interesting test.

--
Pat



From pertusus at free.fr  Fri Oct 10 22:08:25 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 11 Oct 2008 00:08:25 +0200
Subject: Regarding install options
In-Reply-To: <1223675533.4410.183.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
Message-ID: <20081010220825.GC3381@free.fr>

On Fri, Oct 10, 2008 at 02:52:13PM -0700, Jesse Keating wrote:
> On Fri, 2008-10-10 at 23:49 +0200, Ralf Corsepius wrote:
> > Provide a "minimal install" as install option, such that sysadmins can
> > add what they want, instead of forcing them to "manually minimize the
> > distro", as you are doing it now.
> 
> Great, now get consensus on what 'minimal' should be.

No need for a consensus, pick a set of comps groups with your best
judgement. It would be better than nothing. Then people can argue. If
you want the arguing before, post it there, and wait for feedback.

--
Pat



From mrsam at courier-mta.com  Fri Oct 10 22:10:49 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Fri, 10 Oct 2008 18:10:49 -0400
Subject: Status of libtool 2.2.X?
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<48EFA7EC.6000607@gmail.com>
	<1223666666.7707.13.camel@atropine.boston.devel.redhat.com>
Message-ID: <cone.1223676649.887802.24845.500@commodore.email-scan.com>

Adam Jackson writes:

> Most of the complexity in libtool (and autotools in general) is to
> support systems that simply are not worth supporting and that
> practically speaking don't exist anymore.  I'm being slightly flip in
> saying 'gcc -shared' but really not by much.  Honestly for any fringe
> platform the correct thing to do is port gcc/binutils/gmake first.

There's much more to libtool then just building shared libraries. If you 
remove everything from libtool that supports ancient platforms, you'll still 
have quite a bit left.

For example, libtool builds both shared and static libraries in parallel. 
That, alone, saves you from dealing with a massive hairball in your 
makefiles. Ask anyone who works on a large, complicated app, that links with 
its own shared libraries. The option to easily build a statically-linked 
version is quite invaluable, for debugging purposes.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/768806b6/attachment.sig>

From jkeating at j2solutions.net  Fri Oct 10 22:14:18 2008
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 10 Oct 2008 15:14:18 -0700
Subject: Regarding install options
In-Reply-To: <20081010220825.GC3381@free.fr>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<20081010220825.GC3381@free.fr>
Message-ID: <1223676858.4410.184.camel@luminos.localdomain>

On Sat, 2008-10-11 at 00:08 +0200, Patrice Dumas wrote:
> 
> No need for a consensus, pick a set of comps groups with your best
> judgement. It would be better than nothing. Then people can argue. If
> you want the arguing before, post it there, and wait for feedback.

@core with optional @base.  What more/less do you want?

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/08cd7b00/attachment.sig>

From sundaram at fedoraproject.org  Fri Oct 10 22:16:08 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 11 Oct 2008 03:46:08 +0530
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810101503q63dca4acq206f5d4d6581e62e@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EFCF8D.1050904@behdad.org>
	<16de708d0810101503q63dca4acq206f5d4d6581e62e@mail.gmail.com>
Message-ID: <48EFD428.8030308@fedoraproject.org>

Arthur Pemberton wrote:
> 
> I saw no mention of Centos, though someone in the thread mentioned
> that it had been attempted. Your point about upgrade makes sense,
> though I find it pretty weak. Is doing an inplace upgrade on a
> production server common? I don't think so, but I am quite possibly
> wrong.

In my previous organization working as a administrator, I was asked by a 
server owner to live upgrade his Red Hat Linux 9 system to Fedora Core 2 
even though there was several hundreds of active domains in it. They had 
backups but time was absolutely of essence that he was willing to risk 
it. The upgrade via yum turned out to be fine in the end. I suspect 
situations like these are not very uncommon and more people will be able 
to use it, if we spend some resources tackling the problem. Thankfully, 
it is happening already.

Now that PackageKit has support for distro upgrades (ie) desktop 
notification for new releases, the situation is much better for many 
users. Preupgrade which PackageKit will be using to do the job, is also 
enhanced by making use of the blacklist and whiteout yum plugins that 
have been split up from Anaconda.

Rahul



From pertusus at free.fr  Fri Oct 10 22:23:22 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 11 Oct 2008 00:23:22 +0200
Subject: Regarding install options
In-Reply-To: <1223676858.4410.184.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<20081010220825.GC3381@free.fr>
	<1223676858.4410.184.camel@luminos.localdomain>
Message-ID: <20081010222322.GE3381@free.fr>

On Fri, Oct 10, 2008 at 03:14:18PM -0700, Jesse Keating wrote:
> On Sat, 2008-10-11 at 00:08 +0200, Patrice Dumas wrote:
> > 
> > No need for a consensus, pick a set of comps groups with your best
> > judgement. It would be better than nothing. Then people can argue. If
> > you want the arguing before, post it there, and wait for feedback.
> 
> @core with optional @base.  What more/less do you want?

Looks good to me.

--
Pat



From rc040203 at freenet.de  Fri Oct 10 22:23:48 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 11 Oct 2008 00:23:48 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
Message-ID: <1223677428.3564.1292.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> >> Dmitry Butskoy wrote:
> >> > Itamar - IspBrasil wrote:
> [snip]
> >> The fact that they switched to CentOS is *good* for Fedora.
> > I can not disagree more - To me, it's yet another evidence of Fedora
> > being on the loose.
> 
> You're going to have to expound on that. I do not see Centos in any
> way as in competition with Fedora.
EPEL drains away resources from Fedora.

If people were investing the time they (as I feel waste) on supporting
EPEL into Fedora, Fedora would be better.

>  Centos is something everyone should
> be proud of.
Well, to me CentOS is as important as any other arbitrary Linux distro.
I am glad they are around, but not more and not less.

> >>  CentOS's
> >> goals are better oriented to the needs of someone that wants to deploy a
> >> system and run it for years.  Fedora is good for people who want to get
> >> the latest technologies from upstream as soon as they're stable enough
> >> to integrate into a running system.
> > Right. But why can't Fedora do better? I feel Fedora could do better.
> 
> Sure. With more devs, servers, time, etc.
... less bureaucracy, less committees/less chiefs/more Indians,
different people, different strategies.

>  But baring a sudden increase
> in those, I would much prefer to see Fedora focus on dev and testing,
> let other distros pretty things up.
ACK. Unfortunately, Fedora is drifting away from this group towards
single-user desktops (e.g. OLPC).

> >> > This situation seems to be reflected in the Fedora project itself.
> >> > Guess, how many Fedora infrastructure servers are run under the latest
> >> > "stable" Fedora release?
> >>
> >> As few as possible.
> > IMO, a fundamental management/infrastructure mistake - If these people
> > were using Fedora, they would be facing the issues Fedora users are
> > facing everyday and likely would being to understand why people complain
> > about Fedora.
> 
> Why would they, after often suggesting that Fedora _not_ be used on
> production servers, use Fedora on their production servers?
Depends on how they mean it:
- if they are referring to "long term maintained/everlasting support"
servers, they are right.
- if they mean it as "Fedora is technically too unstable", then this
people should start working on improving the situation or (better) quit
Fedora.

> >>   The reason is not about stability.  It is about
> >> updates.  Once Fedora stops getting updates we'd have to upgrade to the
> >> next Fedora release with all of the churn that causes for vastly
> >> unrelated pieces of the OS.
> > Gotcha! If not even the Fedora project can handle the issues, why do you
> > expect users to be able to solve them? I think technically the issues
> > can be overcome. It's a matter of will.
> 
> Well, it's not really an issue. It's only an issue if you run Fedora
> on your production servers.
They would be less issues, if Fedora was using Fedora for its servers.

More bluntly: The fact Fedora is not using Fedora for its servers is a
shame for Fedora.

Ralf






From rc040203 at freenet.de  Fri Oct 10 22:25:08 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 11 Oct 2008 00:25:08 +0200
Subject: Regarding install options
In-Reply-To: <1223675533.4410.183.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
Message-ID: <1223677508.3564.1295.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 14:52 -0700, Jesse Keating wrote:
> On Fri, 2008-10-10 at 23:49 +0200, Ralf Corsepius wrote:
> > Provide a "minimal install" as install option, such that sysadmins can
> > add what they want, instead of forcing them to "manually minimize the
> > distro", as you are doing it now.
> 
> Great, now get consensus on what 'minimal' should be.
shell + networking.

Approximately the set of packages required for a networked install.

Ralf






From pertusus at free.fr  Fri Oct 10 22:30:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 11 Oct 2008 00:30:37 +0200
Subject: Regarding install options
In-Reply-To: <1223676858.4410.184.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<20081010220825.GC3381@free.fr>
	<1223676858.4410.184.camel@luminos.localdomain>
Message-ID: <20081010223037.GG3381@free.fr>

On Fri, Oct 10, 2008 at 03:14:18PM -0700, Jesse Keating wrote:
> On Sat, 2008-10-11 at 00:08 +0200, Patrice Dumas wrote:
> > 
> > No need for a consensus, pick a set of comps groups with your best
> > judgement. It would be better than nothing. Then people can argue. If
> > you want the arguing before, post it there, and wait for feedback.
> 
> @core with optional @base.  What more/less do you want?

Also system-tools as an optional group since there are some networking 
apps that could be of use there. But it is not that important.

--
Pat



From jkeating at redhat.com  Fri Oct 10 22:31:10 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 15:31:10 -0700
Subject: Regarding install options
In-Reply-To: <1223677508.3564.1295.camel@beck.corsepiu.local>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
Message-ID: <1223677870.4410.185.camel@luminos.localdomain>

On Sat, 2008-10-11 at 00:25 +0200, Ralf Corsepius wrote:
> > Great, now get consensus on what 'minimal' should be.
> shell + networking.
> 
> Approximately the set of packages required for a networked install.

And does that include the ability to add more later?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/a7b9aded/attachment.sig>

From kevin.kofler at chello.at  Fri Oct 10 22:39:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 10 Oct 2008 22:39:37 +0000 (UTC)
Subject: CMake!
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
Message-ID: <loom.20081010T213933-101@post.gmane.org>

Callum Lerwick <seg <at> haxxed.com> writes:
>
> On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote:
> > 
> > If you want upstream to stop using libtool altogether, find a suitable  
> > replacement and convince the Automake developers to use it instead.
> 
> Why the h8? He was speaking in the context of "the state of the art" and
> in my oh-so-humble opinion CMake is it. The whole of the Autotools stack
> is very much... not.

+1

The suggestion to convince the automake developers to use something other than 
libtool is pointless, because automake should also go away, it's at least as 
obsolete, buggy, unable to maintain backwards compatibility, annoying, a 
massive time waster at build time and a major PITA for developers to code with 
as libtool is. The whole autotools stack sucks. It always did, we just didn't 
have anything better. We now do, so why are people still using autotools?

Some of the major design failures of the autotools:
* They work by copying the same sets of files into lots of programs and 
encourage distributing generated files (and break compatibility so often that 
that recommendation is almost always followed), so we end up with dozens of 
programs all having their own copy of the check for some library - if it's 
broken, all those programs need patching (and aclocal is a bad solution to that 
because it involves more pregenerating and copying). A modern build system like 
CMake centralizes the checks so there's just one copy to fix (just like shared 
libraries) and keeps compatibility so programs can rely on a compatible version 
of the build tool to just be there and not ship pregenerated files.
* They're supposed to make programs more portable, but use *nix-only shell 
scripts. (And horribly ugly shell scripts working around bugs in dozens of 
subtly incompatible shells (all claiming to be Bourne-compatible and/or 
POSIX-compliant) at that.)
* Libtool generates .la files even on platforms which don't need them. It's 
ridiculous that we still have to delete unwanted files in almost all packages, 
and even more so that they have a comment on the top saying "DON'T DELETE THIS 
FILE!".
(That said, CMake has a similar dependency tracking feature which, when 
enabled, is similarly broken by default. A package has to either not use 
dependency tracking at all (which may cause problems on some 
platforms/configurations, e.g. static libraries) or use an extra command to do 
the right thing (only linking in indirect deps explicitly if the platform 
requires it). But at least it's possible, unlike libtool where you have to 
manually delete a file which screams not to be deleted.)
* Autoconf defaults (and it's extremely hard to disable that, IIRC you can't 
use some convenient macros almost all programs use and have to use low-level 
stuff) to doing all sorts of useless checks as part of the checks that the 
build environment is "sane", such as:
- checking that ISO C90 (ANSI C89) headers exist (hello??? It's 2008! That 
standard is 18-19 years old now! What totally obsolete systems _still_ not 
supporting them do we want to support?), the results of which are generally 
thrown away (because the program just assumes the ISO C headers exist, and 
rightfully so, and thus doesn't do anything with the HAVE_FOO variables from 
those tests), or
- checking that the Fortran and Java-to-native-code compilers exist (even in an 
all-C/C++ project).
All those totally useless tests waste a lot of time for every single build, 
even of trivial projects.
* Automake has 2 modes, a GNU mode which enforces GNU guidelines and 
a "foreign" mode which doesn't, but for some insane reason, it defaults to the 
GNU mode. This is broken for many reasons:
- A tool should not error when some coding style guideline is broken, at most 
it should warn.
- Most projects using automake these days are NOT GNU projects, it's silly to 
try to enforce GNU's guidelines on those.
- The most annoying thing the "GNU" mode enforces is the presence of some files 
like COPYING (OK, this one makes sense, though IMHO License.txt is a better 
name, we're no longer in the 1980s), INSTALL (which is often a verbatim copy of 
the default GNU INSTALL document added just to make automake happy and thus 
completely and utterly useless), NEWS and AUTHORS (both often completely empty, 
added just to make automake happy) and with these obsolete (the days of systems 
allowing only 7 characters in a file name are long gone!), non-portable names 
(Window$ users expect .txt extensions, and even on GNU/Linux, these days, the 
extensionless names aren't always properly detected as text files).
* Libtool thinks /usr/lib64 needs an RPATH, unless you use a Fedora-patched 
version, in which case it'll think /usr/lib needs an RPATH on x86_64 even on a 
Debian system. So, unless you're about to hack the generated/copied libtool 
scripts manually, there's no way (using libtool) to make a package which will 
generate no bogus RPATHs on x86_64 on at least one distro.

Needless to say, CMake doesn't have the above shortcomings (except for 
dependency tracking, and even that can be made to do the right thing by the 
library project if they know what they're doing; and if they don't know what 
they're doing, they'll probably not bother generating a dependency file at 
all ;-) - CMake doesn't do that by default).

CMake also has cool features like reporting the progress percentage of builds 
during make. And it's way faster too.

        Kevin Kofler



From smooge at gmail.com  Fri Oct 10 23:08:53 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Fri, 10 Oct 2008 17:08:53 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223677428.3564.1292.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
Message-ID: <80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>

On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>> >> Dmitry Butskoy wrote:
>> >> > Itamar - IspBrasil wrote:
>> [snip]
>> >> The fact that they switched to CentOS is *good* for Fedora.
>> > I can not disagree more - To me, it's yet another evidence of Fedora
>> > being on the loose.
>>
>> You're going to have to expound on that. I do not see Centos in any
>> way as in competition with Fedora.
> EPEL drains away resources from Fedora.
>
> If people were investing the time they (as I feel waste) on supporting
> EPEL into Fedora, Fedora would be better.
>

Ok. Ralf.. if you hate Fedora and all its projects so much, why do you
fricking stay around. Every fricking thread its "Fedora has too much
bueracracy. Fedora has a broken build system. EPEL steals resources..
" What are you doing?



>> Sure. With more devs, servers, time, etc.
> ... less bureaucracy, less committees/less chiefs/more Indians,
> different people, different strategies.
>

Then DO SOMETHING. Get your indians together and make your camp
somewhere and show us chiefs how it is supposed to be done.




-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From kevin.kofler at chello.at  Fri Oct 10 23:10:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 10 Oct 2008 23:10:10 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br> <48EFCF8D.1050904@behdad.org>
Message-ID: <loom.20081010T230545-621@post.gmane.org>

Behdad Esfahbod <behdad <at> behdad.org> writes:
> The major problem Wikipedia faced seems to me more being that
> Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
> upgrades quite nicely.  *That* seems to be a major weakness of us.

The same "apt-get dist-upgrade" which works on Debian/Ubuntu just works here 
too (with apt-rpm - I've done several upgrades to the next Fedora release that 
way), as does yum (which is better supported and nowadays also more reliable). 
And don't forget that Anaconda also supports upgrades (for RHEL, "upgrade" 
or "upgradeany" is your friend; you can even switch from RHEL/CentOS to Fedora 
with upgradeany (the opposite will only work properly if your Fedora is 
completely outdated though)).

         Kevin Kofler



From dbn.lists at gmail.com  Fri Oct 10 23:16:10 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 10 Oct 2008 16:16:10 -0700
Subject: CMake!
In-Reply-To: <loom.20081010T213933-101@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
Message-ID: <91705d080810101616w2b33508du3482e77261a70f11@mail.gmail.com>

On Fri, Oct 10, 2008 at 3:39 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>
> * Libtool generates .la files even on platforms which don't need them. It's
> ridiculous that we still have to delete unwanted files in almost all packages,
> and even more so that they have a comment on the top saying "DON'T DELETE THIS
> FILE!".
> (That said, CMake has a similar dependency tracking feature which, when
> enabled, is similarly broken by default. A package has to either not use
> dependency tracking at all (which may cause problems on some
> platforms/configurations, e.g. static libraries) or use an extra command to do
> the right thing (only linking in indirect deps explicitly if the platform
> requires it). But at least it's possible, unlike libtool where you have to
> manually delete a file which screams not to be deleted.)

The reason why the .la file is forced to be installed is because it's
needed to support `make uninstall'. Last I saw, the libtool developers
were considering allowing you to opt out of that situation. It's
certainly come up before, and there should be a way to avoid this.

> - checking that the Fortran and Java-to-native-code compilers exist (even in an
> all-C/C++ project).

libtool-2.2 doesn't do that anymore.

> * Libtool thinks /usr/lib64 needs an RPATH, unless you use a Fedora-patched
> version, in which case it'll think /usr/lib needs an RPATH on x86_64 even on a
> Debian system. So, unless you're about to hack the generated/copied libtool
> scripts manually, there's no way (using libtool) to make a package which will
> generate no bogus RPATHs on x86_64 on at least one distro.

Are you sure about that? Last time I looked (and I did look, because I
was trying to emulate libtool's rpath functionality for mesa), libtool
asks gcc for the system library directories by looking at `gcc
-print-search-dirs'. In libtool-2.2, it also takes into consideration
`gcc -print-multi-os-directory'.

--
Dan



From mzerqung at 0pointer.de  Fri Oct 10 23:20:42 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sat, 11 Oct 2008 01:20:42 +0200
Subject: CMake!
In-Reply-To: <loom.20081010T213933-101@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
Message-ID: <20081010232042.GA32721@tango.0pointer.de>

On Fri, 10.10.08 22:39, Kevin Kofler (kevin.kofler at chello.at) wrote:

> > > If you want upstream to stop using libtool altogether, find a
> > > suitable replacement and convince the Automake developers to use
> > > it instead.
> > 
> > Why the h8? He was speaking in the context of "the state of the
> > art" and in my oh-so-humble opinion CMake is it. The whole of the
> > Autotools stack is very much... not.
> 
> +1
> 
> The suggestion to convince the automake developers to use something
> other than libtool is pointless, because automake should also go
> away, it's at least as obsolete, buggy, unable to maintain backwards
> compatibility, annoying, a massive time waster at build time and a
> major PITA for developers to code with as libtool is. The whole
> autotools stack sucks. It always did, we just didn't have anything
> better. We now do, so why are people still using autotools?

I actually like autotools.

Oh, and I think that cmake is a big trainwreck.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From braden at endoframe.com  Fri Oct 10 22:54:43 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 10 Oct 2008 18:54:43 -0400
Subject: CMake!
In-Reply-To: <loom.20081010T213933-101@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>	<1223658387.6770.53.camel@macbook.infradead.org>	<48EF9F8F.3010603@gmail.com>	<1223667525.26341.73.camel@localhost.localdomain>	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
Message-ID: <48EFDD33.8050809@endoframe.com>

Kevin Kofler wrote:
> Callum Lerwick <seg <at> haxxed.com> writes:
>> On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote:
>>> If you want upstream to stop using libtool altogether, find a suitable  
>>> replacement and convince the Automake developers to use it instead.
>> Why the h8? He was speaking in the context of "the state of the art" and
>> in my oh-so-humble opinion CMake is it. The whole of the Autotools stack
>> is very much... not.
> 
> +1
> 
> The suggestion to convince the automake developers to use something other than 
> libtool is pointless, because automake should also go away, it's at least as 
> obsolete, buggy, unable to maintain backwards compatibility, annoying, a 
> massive time waster at build time and a major PITA for developers to code with 
> as libtool is. The whole autotools stack sucks. It always did, we just didn't 
> have anything better. We now do, so why are people still using autotools?
> 
> Some of the major design failures of the autotools:

[snip]

And we're done.  This thread has become a place for build system zealots 
rant without any regard to finding a pragmatic solution to the problem 
at hand and without consideration for those who might wish to do so.  Enjoy.

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From behdad at behdad.org  Fri Oct 10 23:27:39 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Fri, 10 Oct 2008 19:27:39 -0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <loom.20081010T230545-621@post.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br> <48EFCF8D.1050904@behdad.org>
	<loom.20081010T230545-621@post.gmane.org>
Message-ID: <48EFE4EB.70900@behdad.org>

Kevin Kofler wrote:
> Behdad Esfahbod <behdad <at> behdad.org> writes:
>> The major problem Wikipedia faced seems to me more being that
>> Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
>> upgrades quite nicely.  *That* seems to be a major weakness of us.
> 
> The same "apt-get dist-upgrade" which works on Debian/Ubuntu just works here 
> too (with apt-rpm - I've done several upgrades to the next Fedora release that 
> way), as does yum (which is better supported and nowadays also more reliable). 
> And don't forget that Anaconda also supports upgrades (for RHEL, "upgrade" 
> or "upgradeany" is your friend; you can even switch from RHEL/CentOS to Fedora 
> with upgradeany (the opposite will only work properly if your Fedora is 
> completely outdated though)).

You certainly "can", but does it "work"?

behdad

>          Kevin Kofler
> 



From emmanuel.seyman at club-internet.fr  Fri Oct 10 23:38:42 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sat, 11 Oct 2008 01:38:42 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010220351.GB3381@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<20081010160923.GA5293@orient.maison.lan>
	<20081010162836.GF3236@free.fr>
	<20081010214438.GB7389@orient.maison.lan>
	<20081010220351.GB3381@free.fr>
Message-ID: <20081010233842.GA13881@orient.maison.lan>

* Patrice Dumas [11/10/2008 00:59] :
>
> But within the fedora infrastructure, and with the fedora rules (unlike 
> fedora legacy that had different infrastructure and rules).

What's so important about the fedora infrastructure that it is required
to release updates past EOL ? The rules I can understand (even if I don't
agree) but those can be replicated elsewhere.

> As a side note, I think that in the end my project would certainly have
> failed because I don't think that somebody would have stepped up to take
> the big ones, like glibc, kernel, gcc but this would have been an
> interesting test.

But why didn't you try ?
Your proposal sounded like a good idea (although I think you're right
that not enough people are interested in it for it to be viable) and
I think it's a shame that you didn't go ahead and implement it.

Emmanuel



From jkeating at redhat.com  Fri Oct 10 23:46:39 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 16:46:39 -0700
Subject: Fedora 10 Snapshot 1 Released
Message-ID: <1223682399.3327.5.camel@luminos.localdomain>

As part of our development schedule, we are releasing a snapshot of
Rawhide in Live form.  We are releasing these via bittorrent
only as it is a much lighter weight method to get bits out the door than
to go through our mirroring system.  If you cannot use bittorrent we
apologize for the inconvenience.

http://torrent.fedoraproject.org/ has a section marked
F10-Snap1 with Live torrents.  There are no install images at this time
due to ongoing bugs with the installer.

Please us bugzilla to report any problems you find (after making sure
that somebody else hasn't already reported the issues).  The Beta
release notes
( http://fedoraproject.org/wiki/Releases/10/Beta/ReleaseNotes ) still
mostly apply.

Thanks for all the testing!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/42518a11/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 skvidal at fedoraproject.org  Fri Oct 10 23:47:26 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 10 Oct 2008 19:47:26 -0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48EFE4EB.70900@behdad.org>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EFCF8D.1050904@behdad.org> <loom.20081010T230545-621@post.gmane.org>
	<48EFE4EB.70900@behdad.org>
Message-ID: <1223682446.27425.19.camel@rosebud>

On Fri, 2008-10-10 at 19:27 -0400, Behdad Esfahbod wrote:
> Kevin Kofler wrote:
> > Behdad Esfahbod <behdad <at> behdad.org> writes:
> >> The major problem Wikipedia faced seems to me more being that
> >> Fedora/RHEL/CentOS is not really upgradeable, whereas Debian/Ubuntu handled
> >> upgrades quite nicely.  *That* seems to be a major weakness of us.
> > 
> > The same "apt-get dist-upgrade" which works on Debian/Ubuntu just works here 
> > too (with apt-rpm - I've done several upgrades to the next Fedora release that 
> > way), as does yum (which is better supported and nowadays also more reliable). 
> > And don't forget that Anaconda also supports upgrades (for RHEL, "upgrade" 
> > or "upgradeany" is your friend; you can even switch from RHEL/CentOS to Fedora 
> > with upgradeany (the opposite will only work properly if your Fedora is 
> > completely outdated though)).
> 
> You certainly "can", but does it "work"?
> 

It really depends on the package set you've got.


If you're talking about a server w/o an infinite set of pkgs installed,
sure, it's doable.

If you're talking about an ornate and baroque pkg selection on a server
which does a bazillion things, no, it won't be a clean process. notably,
it won't be clean on ANY distro.

-sv



From pertusus at free.fr  Fri Oct 10 23:55:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 11 Oct 2008 01:55:30 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010233842.GA13881@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<20081010160923.GA5293@orient.maison.lan>
	<20081010162836.GF3236@free.fr>
	<20081010214438.GB7389@orient.maison.lan>
	<20081010220351.GB3381@free.fr>
	<20081010233842.GA13881@orient.maison.lan>
Message-ID: <20081010235530.GH3381@free.fr>

On Sat, Oct 11, 2008 at 01:38:42AM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [11/10/2008 00:59] :
> >
> > But within the fedora infrastructure, and with the fedora rules (unlike 
> > fedora legacy that had different infrastructure and rules).
> 
> What's so important about the fedora infrastructure that it is required
> to release updates past EOL ? The rules I can understand (even if I don't
> agree) but those can be replicated elsewhere.
> 
> But why didn't you try ?

It requires hardware and some admins to have a build system. I don't
have the time, nor the computers.

> Your proposal sounded like a good idea (although I think you're right
> that not enough people are interested in it for it to be viable) and
> I think it's a shame that you didn't go ahead and implement it.

I cannot do that on my own. I am a packager and I know next to nothing
about how to set up a buildsystem. It took quite a long time for
rpmfusion to do that I don't have that time (nor the hardware).

--
Pat



From denis at poolshark.org  Sat Oct 11 00:01:33 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 11 Oct 2008 02:01:33 +0200
Subject: CMake!
In-Reply-To: <48EFDD33.8050809@endoframe.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>	<1223658387.6770.53.camel@macbook.infradead.org>	<48EF9F8F.3010603@gmail.com>	<1223667525.26341.73.camel@localhost.localdomain>	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>	<1223672167.26341.100.camel@localhost.localdomain>	<loom.20081010T213933-101@post.gmane.org>
	<48EFDD33.8050809@endoframe.com>
Message-ID: <48EFECDD.5000806@poolshark.org>

Braden McDaniel wrote:
> Kevin Kofler wrote:
>> Callum Lerwick <seg <at> haxxed.com> writes:
>>> On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote:
>>>> If you want upstream to stop using libtool altogether, find a 
>>>> suitable  replacement and convince the Automake developers to use it 
>>>> instead.
>>> Why the h8? He was speaking in the context of "the state of the art" and
>>> in my oh-so-humble opinion CMake is it. The whole of the Autotools stack
>>> is very much... not.
>>
>> +1
>>
>> The suggestion to convince the automake developers to use something 
>> other than libtool is pointless, because automake should also go away, 
>> it's at least as obsolete, buggy, unable to maintain backwards 
>> compatibility, annoying, a massive time waster at build time and a 
>> major PITA for developers to code with as libtool is. The whole 
>> autotools stack sucks. It always did, we just didn't have anything 
>> better. We now do, so why are people still using autotools?
>>
>> Some of the major design failures of the autotools:
> 
> [snip]
> 
> And we're done.  This thread has become a place for build system zealots 
> rant without any regard to finding a pragmatic solution to the problem 
> at hand and without consideration for those who might wish to do so.  
> Enjoy.

That's it, I'm hereby invoking Wayne Lord of the Malted Beverages to 
have y'all banned to heck :-)





From otto_rey at yahoo.com.ar  Sat Oct 11 00:24:12 2008
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Fri, 10 Oct 2008 17:24:12 -0700 (PDT)
Subject: Fedora 10 Snapshot 1 Released
Message-ID: <830731.95555.qm@web52405.mail.re2.yahoo.com>

Broken links in http://torrent.fedoraproject.org/ 

Instead of 
http://torrent.fedoraproject.org/torrents/F10-Snap1-x86_64-Live.torrent 
it says
http://torrent.fedoraproject.org/torrents//Fedora-10-Snap1-x86_64-Live.torrent



----- Mensaje original ----
De: Jesse Keating <jkeating at redhat.com>
Para: fedora-announce-list at redhat.com; fedora-devel-announce at redhat.com
Enviado: viernes 10 de octubre de 2008, 21:46:39
Asunto: Fedora 10 Snapshot 1 Released

As part of our development schedule, we are releasing a snapshot of
Rawhide in Live form.  We are releasing these via bittorrent
only as it is a much lighter weight method to get bits out the door than
to go through our mirroring system.  If you cannot use bittorrent we
apologize for the inconvenience.

http://torrent.fedoraproject.org/ has a section marked
F10-Snap1 with Live torrents.  There are no install images at this time
due to ongoing bugs with the installer.

Please us bugzilla to report any problems you find (after making sure
that somebody else hasn't already reported the issues).  The Beta
release notes
( http://fedoraproject.org/wiki/Releases/10/Beta/ReleaseNotes ) still
mostly apply.

Thanks for all the testing!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating



      Yahoo! Cocina
Recetas pr?cticas y comida saludable
http://ar.mujer.yahoo.com/cocina/



From kevin.kofler at chello.at  Sat Oct 11 00:44:59 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 00:44:59 +0000 (UTC)
Subject: CMake!
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>	<1223658387.6770.53.camel@macbook.infradead.org>	<48EF9F8F.3010603@gmail.com>	<1223667525.26341.73.camel@localhost.localdomain>	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<48EFDD33.8050809@endoframe.com>
Message-ID: <loom.20081011T003849-270@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> And we're done.  This thread has become a place for build system zealots 
> rant without any regard to finding a pragmatic solution to the problem 
> at hand and without consideration for those who might wish to do so.  Enjoy.

Sorry for having performed long-term thinking and foresight. I am aware of how 
horrible a crime that is and how we should never plan for any longer than the 
next 30 minutes. So let us spend hours debating on how to perform the various 
one-line changes needed to support the newest version of libtool, because 
that's oh so hard, and let us forget the fact that other build systems even 
exist: who would commit such a heresy as to use them?

Disclaimer: The above paragraph MAY contain sarcasm. (In the same sense that a 
bag of peanuts MAY contain peanuts.)

        Kevin Kofler



From kevin.kofler at chello.at  Sat Oct 11 00:53:05 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 00:53:05 +0000 (UTC)
Subject: libtool annoyances (was: Re: CMake!)
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<91705d080810101616w2b33508du3482e77261a70f11@mail.gmail.com>
Message-ID: <loom.20081011T004708-886@post.gmane.org>

Dan Nicholson <dbn.lists <at> gmail.com> writes:
> The reason why the .la file is forced to be installed is because it's
> needed to support `make uninstall'. Last I saw, the libtool developers
> were considering allowing you to opt out of that situation. It's
> certainly come up before, and there should be a way to avoid this.

Indeed, I'm glad you folks are aware there's a problem and trying to fix it.

> > - checking that the Fortran and Java-to-native-code compilers exist (even
> > in an all-C/C++ project).
> 
> libtool-2.2 doesn't do that anymore.

And that's good news, one less annoyance, thanks for that!

> > * Libtool thinks /usr/lib64 needs an RPATH, unless you use a Fedora-patched
> > version, in which case it'll think /usr/lib needs an RPATH on x86_64 even 
> > on a Debian system. So, unless you're about to hack the generated/copied 
> > libtool scripts manually, there's no way (using libtool) to make a package 
> > which will generate no bogus RPATHs on x86_64 on at least one distro.
> 
> Are you sure about that? Last time I looked (and I did look, because I
> was trying to emulate libtool's rpath functionality for mesa), libtool
> asks gcc for the system library directories by looking at `gcc
> -print-search-dirs'. In libtool-2.2, it also takes into consideration
> `gcc -print-multi-os-directory'.

It may have been a bug, but what I described is exactly what Romain Li?vin and 
I experienced with the tilibs (the libti* stuff at http://svn.tilp.info/ ): if 
Romain autotooled the project on Debian, I ended up with rpaths on Fedora 
x86_64, if I autotooled it on Fedora, he ended up with rpaths on Debian x86_64.

If libtool 2.2 does the right thing there, that's indeed good news.

        Kevin Kofler



From poelstra at redhat.com  Sat Oct 11 03:22:07 2008
From: poelstra at redhat.com (John Poelstra)
Date: Fri, 10 Oct 2008 20:22:07 -0700
Subject: Package review backlog.
In-Reply-To: <1223649007.6770.25.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
Message-ID: <48F01BDF.1000109@redhat.com>

David Woodhouse said the following on 10/10/2008 07:30 AM Pacific Time:
> On Fri, 2008-10-10 at 15:33 +0200, Christoph Wickert wrote:
>> Am Freitag, den 10.10.2008, 14:14 +0100 schrieb David Woodhouse:
>>
>>> I propose that each FESCo member should try to work on at least one
>>> package review per week. Each week at the FESCo meeting, we'll ask
>>> members which reviews they've worked on in the past week.
>>>
>>> It won't be _mandatory_ -- 
>> [snipped] 
>>
>> As a rule of thumb it's ok, but it should not be mandatory. I think the
>> FESCo members are already having a lot of work to do and I'm not sure if
>> everybody has enough spare time for reviews.
> 
> Absolutely. Besides, if you do call it 'mandatory' you have to start
> defining what would happen if people don't comply, and the whole thing
> just gets silly.
> 
> I'm talking about a 'recommended practice', and just asking people each
> week which packages they've looked at. Nothing more.
> 
> And even though people are busy, it shouldn't actually take _that_ long
> to make progress on reviewing a single package, each week.
> 

http://tinyurl.com/4kt682
1,212 open Package Review bugs

I think Jason Tibbitts put up a wiki page with some ideas for getting 
help from the bug triage team triaging the Package Review bugs... with 
1,212 open there have to be some dead ones there.  Right now the bug 
triage team ignores all bugs with component "Package Review".

This is definitely doable and would be even better if we could form some 
type of reciprocal arrangement with maintainers or package reviewers to 
triage regular bugs.

John



From jkeating at redhat.com  Sat Oct 11 04:04:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Oct 2008 21:04:07 -0700
Subject: Fedora 10 Snapshot 1 Released
In-Reply-To: <830731.95555.qm@web52405.mail.re2.yahoo.com>
References: <830731.95555.qm@web52405.mail.re2.yahoo.com>
Message-ID: <1223697847.3327.9.camel@luminos.localdomain>

On Fri, 2008-10-10 at 17:24 -0700, Otto Rey wrote:
> 
> Broken links in http://torrent.fedoraproject.org/ 
> 
> Instead of 
> http://torrent.fedoraproject.org/torrents/F10-Snap1-x86_64-Live.torrent 
> it says
> http://torrent.fedoraproject.org/torrents//Fedora-10-Snap1-x86_64-Live.torrent

This was fixed shortly after the announcement.  Doing things late on a
Friday for the win!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081010/813bb1a9/attachment.sig>

From braden at endoframe.com  Sat Oct 11 04:20:02 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 00:20:02 -0400
Subject: CMake!
In-Reply-To: <loom.20081011T003849-270@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<48EFDD33.8050809@endoframe.com>
	<loom.20081011T003849-270@post.gmane.org>
Message-ID: <1223698802.13589.284.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 00:44 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > And we're done.  This thread has become a place for build system zealots 
> > rant without any regard to finding a pragmatic solution to the problem 
> > at hand and without consideration for those who might wish to do so.  Enjoy.
> 
> Sorry for having performed long-term thinking and foresight. I am aware of how 
> horrible a crime that is and how we should never plan for any longer than the 
> next 30 minutes. So let us spend hours debating on how to perform the various 
> one-line changes needed to support the newest version of libtool, because 
> that's oh so hard, and let us forget the fact that other build systems even 
> exist: who would commit such a heresy as to use them?
> 
> Disclaimer: The above paragraph MAY contain sarcasm. (In the same sense that a 
> bag of peanuts MAY contain peanuts.)

And once again you miss the point: changing packages' build systems
wholesale is *never* going to be the right thing for Fedora to do.
Promoting a particular build system for participation in such a task is
not "long term planning", it's noise.

If you really care about getting projects to switch to CMake, swim
upstream.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From debarshi.ray at gmail.com  Sat Oct 11 04:21:59 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sat, 11 Oct 2008 09:51:59 +0530
Subject: CMake!
In-Reply-To: <loom.20081010T213933-101@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
Message-ID: <3170f42f0810102121r10db36ebh1fe3fa18f812f4f9@mail.gmail.com>

> * Automake has 2 modes, a GNU mode which enforces GNU guidelines and
> a "foreign" mode which doesn't, but for some insane reason, it defaults to the
> GNU mode. This is broken for many reasons:
> - A tool should not error when some coding style guideline is broken, at most
> it should warn.
> - Most projects using automake these days are NOT GNU projects, it's silly to
> try to enforce GNU's guidelines on those.
> - The most annoying thing the "GNU" mode

Now how much does it take to use the "foreign" mode? Not much. Just
the 7 letters: "f-o-r-e-i-g-n". That is not much of a pain, isn't it?
:-)

Cheers,
Debarshi



From a.badger at gmail.com  Sat Oct 11 05:22:28 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 10 Oct 2008 22:22:28 -0700
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <1223674536.3564.1262.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
Message-ID: <48F03814.5020508@gmail.com>

Ralf Corsepius wrote:
> On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:

>>   The reason is not about stability.  It is about
>> updates.  Once Fedora stops getting updates we'd have to upgrade to the
>> next Fedora release with all of the churn that causes for vastly
>> unrelated pieces of the OS. 
> Gotcha! If not even the Fedora project can handle the issues, why do you
> expect users to be able to solve them? I think technically the issues
> can be overcome. It's a matter of will.
> 
No gotcha here.  I don't expect users to handle the issues.  Either the
users in question want the opportunity to run the latest software in an
integrated distro and so choose to run Fedora or they want to have a
stable platform on which to deploy their own work and therefore they use
CentOS/RHEL/Debian Stable.

There's a right tool for any job and a wrong tool.  Using your crescent
wrench to hammer nails is possible but not very satisfying.

-Toshio

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

From rc040203 at freenet.de  Sat Oct 11 05:53:18 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 11 Oct 2008 07:53:18 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
Message-ID: <1223704398.3564.1316.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:
> On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> >> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> >> >> Dmitry Butskoy wrote:
> >> >> > Itamar - IspBrasil wrote:
> >> [snip]
> >> >> The fact that they switched to CentOS is *good* for Fedora.
> >> > I can not disagree more - To me, it's yet another evidence of Fedora
> >> > being on the loose.
> >>
> >> You're going to have to expound on that. I do not see Centos in any
> >> way as in competition with Fedora.
> > EPEL drains away resources from Fedora.
> >
> > If people were investing the time they (as I feel waste) on supporting
> > EPEL into Fedora, Fedora would be better.
> >
> 
> Ok. Ralf.. if you hate Fedora 
Absolutely not.

> and all its projects so much, why do you
> fricking stay around. Every fricking thread its "Fedora has too much
> bueracracy. Fedora has a broken build system. EPEL steals resources..
> " What are you doing?
I am complaining about a _few_ people having run down a once fascinating
project, with the very same people closing their eyes in front this, of
what I consider to be an inconvenient truth.

Wrt. EPEL, I have always had the same opinion on it, since the very
beginning.

> >> Sure. With more devs, servers, time, etc.
> > ... less bureaucracy, less committees/less chiefs/more Indians,
> > different people, different strategies.

> Then DO SOMETHING.
Sigh, I repeatedly have been trying to do something, but always the same
"Fedora chiefs" had machine-gunned almost each and every proposal.

You know, you have been one of these - Do I really have to be more
direct?

Ralf




From lesmikesell at gmail.com  Sat Oct 11 06:46:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 11 Oct 2008 01:46:51 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F03814.5020508@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<48F03814.5020508@gmail.com>
Message-ID: <48F04BDB.8090602@gmail.com>

Toshio Kuratomi wrote:
> 
> No gotcha here.  I don't expect users to handle the issues.  Either the
> users in question want the opportunity to run the latest software in an
> integrated distro and so choose to run Fedora or they want to have a
> stable platform on which to deploy their own work and therefore they use
> CentOS/RHEL/Debian Stable.

No, it's not an either/or scenario. Users may way to develop something 
new and be willing to put up with unstable fedora to get current tools 
for that, but there is no clear transition plan to put what they have 
built into production.  In the old RH X.0 -> X.1 -> X.2 days the 
transition from a new release to a stable OS usable in production 
happened through updates - now it doesn't happen at all.  Support is 
simply dropped for the platform you started on and there is no reason to 
expect anywhere near the same library versions and environment as you 
migrate to a stable platform.

> There's a right tool for any job and a wrong tool.  Using your crescent
> wrench to hammer nails is possible but not very satisfying.

What's the 'right' tool to develop for the next version of Centos?

-- 
    Les Mikesell
      lesmikesell at gmail.com



From shambo.linux at gmail.com  Sat Oct 11 07:26:49 2008
From: shambo.linux at gmail.com (Shambo Bose)
Date: Sat, 11 Oct 2008 12:56:49 +0530
Subject: Regarding install options
Message-ID: <b53a79450810110026p1bac331do34e26253f8d4248e@mail.gmail.com>

Hi,

I think we can have 4 install options :

1. Desktop
2. Server
3. Minimal
4. Custom ( For advanced users )

Some details about each options :

1. Desktop : Optimized for desktop performance with fully installed office
suite, desktop themes(compiz fusion), games,internet softwares ( mozilla
firefox , evolution, Pigdin etc),sound and video packages, graphics
maniplation packages ,Programming tools, Basic system administration tools
and networking tools.

2. Server : Optimized for server performance with different server
administration tools. High profile graphics and desktop effects should be
avoided . A basic GNOME environment with internet softwares ( mozilla
firefox , evolution) and important server and network administration tools
and packages should be the main features.

3. Minimal : A base system install with networking ideal for creating spins.

4. Custom ( For advanced users ) : Provide option to a user to select
individual packages. Ideal for users who want both desktop and server
features on a single system. It is basically a minimal install but
will provide option to a user to select individual packages.

I have just tried to desgn a outline , nothing more than that as I dont have
enough knowledge about fedora and linux packages.

Thank You.

yours sincerely,

Shambo Bose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/842f991c/attachment.htm>

From a.badger at gmail.com  Sat Oct 11 08:09:20 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 11 Oct 2008 01:09:20 -0700
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F04BDB.8090602@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<48F03814.5020508@gmail.com>
	<48F04BDB.8090602@gmail.com>
Message-ID: <48F05F30.6040601@gmail.com>

Les Mikesell wrote:
> Toshio Kuratomi wrote:
>>
>> No gotcha here.  I don't expect users to handle the issues.  Either the
>> users in question want the opportunity to run the latest software in an
>> integrated distro and so choose to run Fedora or they want to have a
>> stable platform on which to deploy their own work and therefore they use
>> CentOS/RHEL/Debian Stable.
> 
> No, it's not an either/or scenario. 

You're confusing what you want with what is.  What is *is* an either/or
scenario as there is no definite path from starting with Fedora to
getting to a long term OS.  What could be is a long term release for
certain releases if you and other like minded people do the work to
offer security updates and major bugfixes beyond the current EOL.

> Users may way to develop something
> new and be willing to put up with unstable fedora to get current tools
> for that, but there is no clear transition plan to put what they have
> built into production.  In the old RH X.0 -> X.1 -> X.2 days the
> transition from a new release to a stable OS usable in production
> happened through updates - now it doesn't happen at all.  Support is
> simply dropped for the platform you started on and there is no reason to
> expect anywhere near the same library versions and environment as you
> migrate to a stable platform.
> 
>> There's a right tool for any job and a wrong tool.  Using your crescent
>> wrench to hammer nails is possible but not very satisfying.
> 
> What's the 'right' tool to develop for the next version of Centos?
> 
Why, the initial release of the Fedora version that the next version of
CentOS is going to be based on, of course! :-)

And if you want to ask which version of Fedora that is, I'd like to ask
you how you knew there was going to be a RHL 6.2 but not a RHL 6.3; a
RHL 7.3, but not a RHL 8.1....

-Toshio

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

From lesmikesell at gmail.com  Sat Oct 11 08:41:38 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 11 Oct 2008 03:41:38 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F05F30.6040601@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<48F03814.5020508@gmail.com>	<48F04BDB.8090602@gmail.com>
	<48F05F30.6040601@gmail.com>
Message-ID: <48F066C2.6030100@gmail.com>

Toshio Kuratomi wrote:
> 
>>> No gotcha here.  I don't expect users to handle the issues.  Either the
>>> users in question want the opportunity to run the latest software in an
>>> integrated distro and so choose to run Fedora or they want to have a
>>> stable platform on which to deploy their own work and therefore they use
>>> CentOS/RHEL/Debian Stable.
>> No, it's not an either/or scenario. 
> 
> You're confusing what you want with what is.

No, I was responding to your misconception of what users want as stated 
above.  What you said is not what I want.

> What is *is* an either/or
> scenario as there is no definite path from starting with Fedora to
> getting to a long term OS.

Agreed, hence this thread of complaints.

>  What could be is a long term release for
> certain releases if you and other like minded people do the work to
> offer security updates and major bugfixes beyond the current EOL.

That doesn't make a lot of sense.  Why would you want to commit to long 
term support of some otherwise orphaned variant when all that is needed 
is a smooth, planned transition to a version designed for stability with 
existing long term support?

>>> There's a right tool for any job and a wrong tool.  Using your crescent
>>> wrench to hammer nails is possible but not very satisfying.
>> What's the 'right' tool to develop for the next version of Centos?
>>
> Why, the initial release of the Fedora version that the next version of
> CentOS is going to be based on, of course! :-)

Maybe - if the users that reported the bugs that permitted the 
improvements in stability through the fedora cycles weren't abandoned 
and left on their own to figure out the departure point and what the 
differences will be.

> And if you want to ask which version of Fedora that is, I'd like to ask
> you how you knew there was going to be a RHL 6.2 but not a RHL 6.3; a
> RHL 7.3, but not a RHL 8.1....

The version numbers aren't particularly relevant there (and by 8.x the 
process was so badly broken that no one would have wanted an 8.1).  The 
point is that from the early versions through 7.3 a user could start 
from the original release, report bugs while doing his own local 
development and testing, and end up with both the system and local work 
stabilizing and being usable in production together.  With fedora you 
get the bugs and can report them, but you never end up with a usable 
platform in the end.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Oct 11 08:55:56 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 11 Oct 2008 03:55:56 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
Message-ID: <48F06A1C.9040506@gmail.com>

Arthur Pemberton wrote:
>
>> Right. But why can't Fedora do better? I feel Fedora could do better.
> 
> Sure. With more devs, servers, time, etc. But baring a sudden increase
> in those, I would much prefer to see Fedora focus on dev and testing,
> let other distros pretty things up.

The way to get more devs is to make developing on Fedora useful. 
Currently it's a dead end and not a path towards something running in 
production.

>> IMO, a fundamental management/infrastructure mistake - If these people
>> were using Fedora, they would be facing the issues Fedora users are
>> facing everyday and likely would being to understand why people complain
>> about Fedora.
> 
> Why would they, after often suggesting that Fedora _not_ be used on
> production servers, use Fedora on their production servers?

Likewise, why develop for/on it?  Just so you can hope that a 
similar-enough-to-maybe-work enterprise platform will eventually appear?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From benny+usenet at amorsen.dk  Sat Oct 11 09:01:50 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sat, 11 Oct 2008 11:01:50 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> (Matej Cepl's message of
	"Fri\, 10 Oct 2008 16\:11\:12 +0200")
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
Message-ID: <m34p3jzerl.fsf@ursa.amorsen.dk>

Matej Cepl <mcepl at redhat.com> writes:

> b) If anybody is running production servers on Fedora, then worse 
>    for him -- Fedora is a developers' distro and that's the 
>    reason why it has limited support.

If your set up is such that you can survive an upgrade every 9 months,
Fedora is fine for servers.

With Fedora, you get benefits of the bleeding edge. Linux software in
general, even server software, is improving rapidly, and having your
software stack 12 months (or more) ahead of the competition is
valuable.

For servers, you can often do a full Fedora upgrade with yum and not
even have to reboot at the same time. That's officially unsupported,
but you can't get a support contract from Fedora anyway.


/Benny



From lesmikesell at gmail.com  Sat Oct 11 09:06:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 11 Oct 2008 04:06:36 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <70s4s5x57i.ln2@ppp1053.in.ipex.cz>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr>	<48EF79A4.2030103@gmail.com>
	<70s4s5x57i.ln2@ppp1053.in.ipex.cz>
Message-ID: <48F06C9C.2030503@gmail.com>

Matej Cepl wrote:
> On 2008-10-10, 15:49 GMT, Les Mikesell wrote:
>> What we need for the same effect now is for the versions of 
>> fedora that provide the initial RHEL cuts to offer a seamless 
>> update to the subsequent matching CentOS, repointing to its 
>> update repositories for continued support.
> 
> How is it different from just using CentOS?

There's no lead time for your own local development and testing.  You 
would never expect one of the old RH X.0 releases to be production-ready 
but the new releases would have new kernels, libraries, and utilities so 
you could incorporate their features in your own work, which was likely 
to proceed at approximately the same rate as the distro evolved toward 
stability.  With Centos you don't get anything to work with and test 
ahead of time, and if you'd tested on an earlier Fedora there may or may 
not be any relationship.  A side effect was that the community of RH 
users that reported/fixed bugs in the X.0 got something for their effort 
in being able to continue using the updated release instead of being 
abandoned as a wildly new X.0 came out.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From snecklifter at gmail.com  Sat Oct 11 09:28:40 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Sat, 11 Oct 2008 10:28:40 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223704398.3564.1316.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<1223704398.3564.1316.camel@beck.corsepiu.local>
Message-ID: <364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>

2008/10/11 Ralf Corsepius <rc040203 at freenet.de>:
> On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:
>> On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
>> >> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> >> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
>> >> >> Dmitry Butskoy wrote:
>> >> >> > Itamar - IspBrasil wrote:
>> >> [snip]
>> >> >> The fact that they switched to CentOS is *good* for Fedora.
>> >> > I can not disagree more - To me, it's yet another evidence of Fedora
>> >> > being on the loose.
>> >>
>> >> You're going to have to expound on that. I do not see Centos in any
>> >> way as in competition with Fedora.
>> > EPEL drains away resources from Fedora.
>> >
>> > If people were investing the time they (as I feel waste) on supporting
>> > EPEL into Fedora, Fedora would be better.
>> >
>>
>> Ok. Ralf.. if you hate Fedora
> Absolutely not.
>
>> and all its projects so much, why do you
>> fricking stay around. Every fricking thread its "Fedora has too much
>> bueracracy. Fedora has a broken build system. EPEL steals resources..
>> " What are you doing?
> I am complaining about a _few_ people having run down a once fascinating
> project, with the very same people closing their eyes in front this, of
> what I consider to be an inconvenient truth.
>
> Wrt. EPEL, I have always had the same opinion on it, since the very
> beginning.
>
>> >> Sure. With more devs, servers, time, etc.
>> > ... less bureaucracy, less committees/less chiefs/more Indians,
>> > different people, different strategies.
>
>> Then DO SOMETHING.
> Sigh, I repeatedly have been trying to do something, but always the same
> "Fedora chiefs" had machine-gunned almost each and every proposal.
>
> You know, you have been one of these - Do I really have to be more
> direct?

No, you just have to be less of an ass. As a casual observer, all you
seem to do is throw rocks. Your only sanctuary lies in the totally
open nature of the project and that it's pretty much impossible to
boot you off it. In fact, your occasional tantrums bears all the
hallmarks of ESR before he happily departed these shores - any chance
you'll be doing the same soon and leave people to get on with the task
in hand?

If not then please remember that good manners cost nothing.

Regards

-- 
Christopher Brown

http://www.chruz.com



From snecklifter at gmail.com  Sat Oct 11 09:34:55 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Sat, 11 Oct 2008 10:34:55 +0100
Subject: Heads up on ext4 changes
In-Reply-To: <5256d0b0810101336g539f5b78m4f0713ed04c44666@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>
	<1223567969.2870.2.camel@scrappy.miketc.net>
	<48EE2BD3.2040106@redhat.com>
	<364d303b0810101314n7a7864d0yd2cce90c62bb5075@mail.gmail.com>
	<5256d0b0810101336g539f5b78m4f0713ed04c44666@mail.gmail.com>
Message-ID: <364d303b0810110234x4b3ffae6t53706d0522878bcd@mail.gmail.com>

2008/10/10 Peter Robinson <pbrobinson at gmail.com>:
>>>>> (*)Yes, this does indicate that the ext4 developers feel it's time to
>>>>> move on past the "dev" stage; as the patch says "The ext4 filesystem is
>>>>> getting stable enough that it's time to drop the "dev" prefix." - as
>>>>> with any filesystem, though, I still encourage you to back up important
>>>>> data :)
>>>>
>>>> Does this mean ext4 will be available as generic during
>>>> installs/upgrades, same as ext3?  Or does it have to be given as an
>>>> option during install to get it to show up?
>>>
>>> it still takes the ext4 option on boot.
>>
>> Oh come on - that makes it barely differential between
>> iamanext4developer. Put your nuts on the line and offer it up as an
>> additional option on install - I dare you. I thought Fedora was
>> bleeding edge! I miss that heart-racing feeling when I _just dont
>> know_ if my data is coming back up on reboot... :)
>
> Are you going to put your nuts on the line and provide the support to
> the end users when they don't get their data back on reboot?

Sure, its called #fedora-ext4 with a bot spitting out the word
'backup' on every /join :D

-- 
Christopher Brown

http://www.chruz.com



From j.w.r.degoede at hhs.nl  Sat Oct 11 09:47:01 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 11 Oct 2008 11:47:01 +0200
Subject: Package review backlog.
In-Reply-To: <48F01BDF.1000109@redhat.com>
References: <loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<1223645613.3514.12.camel@wicktop.localdomain>	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com>
Message-ID: <48F07615.7060306@hhs.nl>

John Poelstra wrote:
> David Woodhouse said the following on 10/10/2008 07:30 AM Pacific Time:
>> On Fri, 2008-10-10 at 15:33 +0200, Christoph Wickert wrote:
>>> Am Freitag, den 10.10.2008, 14:14 +0100 schrieb David Woodhouse:
>>>
>>>> I propose that each FESCo member should try to work on at least one
>>>> package review per week. Each week at the FESCo meeting, we'll ask
>>>> members which reviews they've worked on in the past week.
>>>>
>>>> It won't be _mandatory_ -- 
>>> [snipped]
>>> As a rule of thumb it's ok, but it should not be mandatory. I think the
>>> FESCo members are already having a lot of work to do and I'm not sure if
>>> everybody has enough spare time for reviews.
>>
>> Absolutely. Besides, if you do call it 'mandatory' you have to start
>> defining what would happen if people don't comply, and the whole thing
>> just gets silly.
>>
>> I'm talking about a 'recommended practice', and just asking people each
>> week which packages they've looked at. Nothing more.
>>
>> And even though people are busy, it shouldn't actually take _that_ long
>> to make progress on reviewing a single package, each week.
>>
> 
> http://tinyurl.com/4kt682
> 1,212 open Package Review bugs

Woa,

Thats an amanzing number, I'll put in, or rather repeat, my 2 cents here. 
Fedora, like any opensource community, is all about give and take, about tit 
for tat.

I've submitted many, many new packages (100+ I guess) and I've *never* had any 
problems in getting them reviewed.

Of those 1200 pachages awaiting review, 100 block FE_NEEDSPONSOR, so 1100 are 
normal reviews submitted by people which are already contributers! Lets say 
every contributer has on average 2 packages waiting for review, then 2 have 550 
contributers for whom the review queue is a problem, if all of those 550 
submitters would review only 2 packages, then the entire normal review queue is 
gone!

What I always do, and what we should be promoting much more is exchange 
reviews. Just post a mail to fedora-devel-list, saying I've got these and these 
packages which need review, and I'll gladly review any other package in return.

Then people who are willing to do reviews themselves day sure, and my and their 
package is reviewed in a matter of days. For those who are not willing to do 
reviews in return for their own package being reviewed I've got little sympathy!

So the real problem to this solution is not mandating anyone to do reviews, but 
to seriously promote swapping reviews.

Regards,

Hans






From rjones at redhat.com  Sat Oct 11 09:57:40 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 11 Oct 2008 10:57:40 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081011095740.GA29105@amd.home.annexia.org>

On Fri, Oct 10, 2008 at 02:51:17PM -0400, Adam Jackson wrote:
> The state of the art is "gcc -shared".

That doesn't work on MinGW though.

I don't really like libtool (who does?) but it does solve a certain
problem properly.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From rjones at redhat.com  Sat Oct 11 09:59:53 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 11 Oct 2008 10:59:53 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223667649.7707.18.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<20081010191741.GB5378@redhat.com>
	<1223667649.7707.18.camel@atropine.boston.devel.redhat.com>
Message-ID: <20081011095953.GB29105@amd.home.annexia.org>

On Fri, Oct 10, 2008 at 03:40:49PM -0400, Adam Jackson wrote:
> Really?  News to me.  If you've got a link to anything documenting the
> issues there I'd be interested, I've got a vested interest in keeping
> the windows ports of X working but man do I hate libtool.

Probably best to start here:

http://fedoraproject.org/wiki/SIGs/MinGW

and also take a look at the libraries section in our packaging
guidelines:

http://fedoraproject.org/wiki/PackagingDrafts/MinGW#Libraries_.28DLLs.29

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From rjones at redhat.com  Sat Oct 11 10:02:02 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 11 Oct 2008 11:02:02 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <loom.20081010T212845-842@post.gmane.org>
References: <20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<20081010191741.GB5378@redhat.com>
	<1223667649.7707.18.camel@atropine.boston.devel.redhat.com>
	<20081010201152.GC5378@redhat.com>
	<loom.20081010T212845-842@post.gmane.org>
Message-ID: <20081011100202.GC29105@amd.home.annexia.org>

On Fri, Oct 10, 2008 at 09:38:22PM +0000, Kevin Kofler wrote:
> MinGW can actually link a DLL directly these days. However, that feature is 
> rarely used in practice for a few reasons:
[extremely insightful stuff]

Kevin, we'd really like you as part of the MinGW project ...

I'll take a look at the updated NSIS package you sent on Monday.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From rjones at redhat.com  Sat Oct 11 10:06:08 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 11 Oct 2008 11:06:08 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <48EFA7EC.6000607@gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<48EFA7EC.6000607@gmail.com>
Message-ID: <20081011100608.GD29105@amd.home.annexia.org>

On Fri, Oct 10, 2008 at 12:07:24PM -0700, Toshio Kuratomi wrote:
> So gcc is the compiler everywhere these days?  Note this is a genuine
> question -- I haven't used anything besides Linux in so long I don't
> know whether Sun or anyone else is shipping their own C compiler anymore.

The *BSDs have recently been talking about dropping GCC and adopting a
major rewrite of the original PCC.  The Portable C Compiler was the
basis of things like Sun cc.  Ironically it was liberated by
SCO^WCaldera.

Some more interesting stuff about this here:

  http://lwn.net/Articles/255558/

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From fedora at leemhuis.info  Sat Oct 11 10:13:48 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 11 Oct 2008 12:13:48 +0200
Subject: Package review backlog.
In-Reply-To: <1223644448.6770.18.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
Message-ID: <48F07C5C.8000403@leemhuis.info>

On 10.10.2008 15:14, David Woodhouse wrote:
> On Fri, 2008-10-10 at 02:12 +0200, Christoph Wickert wrote:
>> Am Donnerstag, den 09.10.2008, 20:01 -0400 schrieb Josh Boyer:
>>> On Fri, Oct 10, 2008 at 01:41:32AM +0200, Christoph Wickert wrote:
>>>>> Let's get the final two packages reviewed -- and that's another area
>>>>> where we could do with some improvement, because failing to approve
>>>>> packages really _is_ verging on the 'deletionism' you spoke of. But
>>>>> that's a separate discussion.
>>>> Agreed, we can discuss this later. BTW: The word "deletionsm" did not
>>>> come from me, it was Josh who said that, but of course I agree with him.
>>> I didn't say that.  Though I agree we need to be getting more packages
>>> approved.
>> I think this is something we all agree on. ;)
> I propose that each FESCo member should try to work on at least one
> package review per week. Each week at the FESCo meeting, we'll ask
> members which reviews they've worked on in the past week.

I blogged about this already(?), but a few hours later I think I should 
write a alternate proposal to prevent the problems I tried to outline in
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00560.html

So here we go:

---

I propose that each week at the FESCo meeting all FESCo members should 
be asked what they did (as FESCo member) over the past week to improve 
Fedora. They further should be asked what they (as FESCo member) plan 
for the coming week to improve Fedora.

---

Do I mean that serious? If the proposal from dwmw2 is considered to be 
accepted, then yes, definitely. In fact it might be wise to combine 
those two to something like that below *if* FESCo really wants to go 
down that route (which I still think is totally wrong to do, but that is 
a different topic; I'm just trying to make something that IMHO is worse 
a bit bitter):

---

I propose that each FESCo member should try to work on at least one 
package review per week. Each week at the FESCo meeting all FESCo 
members should be asked what they did (as FESCo member) over the past 
week to improve Fedora; they further should be asked what they (as FESCo 
member) plan for the coming week to improve Fedora. That includes, but 
is not limited to reviews.

---

That way I as ordinary contributor know way better how the FESCo member 
users his time. I then are able to say "okay, he did not do any review 
over the past month week, but I can see that he spend his time for 
things that were more important and overall improve Fedora; that is way 
better than one or two finished reviews". I can use that information in 
the next election.

CU
knurd

(?) see
http://thorstenl.blogspot.com/2008/10/popular-things-are-often-not-right.html
or just read on:

Popular things are often not the right thing to do

No, this has nothing to do with the presidential elections in the US; 
but yes, it's about politics. To quote from <a 
href="https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00673.html">a 
mail send by dwmw2 to fedora-devel</a>:

> I propose that each FESCo member should try to work on at least one
> package review per week. Each week at the FESCo meeting, we'll ask
> members which reviews they've worked on in the past week.

Nice idea, but for me that sounds like a pre-election promise to lower 
taxes or like big and rich politicians handling out food in a soup 
kitchen or a: It will help a few people and gives good press because 
it's popular, but it doesn't solve the underlying problem at all. In 
fact it's even worse, because time gets wasted instead of solving the 
underlying or other problems (that might be bigger or smaller).

Verbose:

Sure, putting pressure on FESCo members to do reviews will force them to 
face some of the problems in the review process. That might result in 
some small improvements to the review process that might make things 
easier in the long term (but for that to really become true we also 
would need to have the same "should try [...] at least one package 
review per week" suggestion for members of the Fedora Packaging 
Committee as well); and of course the review queue gets a tiny fraction 
shorter due to the reviews that get done. But the time imho would be 
*way* better spend if some FESCo members would directly work on 
improving the review process with people that are doing lots of reviews 
(hello tibbs), because only that will improve the situation in the end 
(if done properly) and solve the problem (as far as it's possible to solve).

Ideas for making things easier and better are there; they are afaics 
well known among contributors and the different committees that are 
responsible. Just nobody is working on them:

  * improve rpmlint and other tools to automate more of the checks to 
less the burden on the reviewer

  * make review exchanges easier; maybe even force/guide/direct people a 
little bit to do exchange reviews (e.g. a little bit like, but not as 
strict as "if you want to get your packages reviewed you have to review 
a package from somebody else first")

  * look more actively for new sponsors and be less strict when choosing 
them (like it has been in the past); we all make errors -- it's the 
ability to learn from them and to fix the errors once they got made

  * be less strict with sponsoring people like it was in the early 
Fedora Extras days in 2005. We can do that now that new packagers don't 
get access each and every package in CVS

  * add one more level between new packagers and sponsors; soon-to be 
sponsors there could work together with new packagers and keep an closer 
eye on them; by that they could get work of the real sponsor and show 
their ability to become a real sponsor sooner or later

  * let FESCo and the Fedora Packaging Committee work together to make 
review and packaging guidelines easier to understand. We have done that 
two times in the past iirc (once in the fedora.us days and the last time 
it iirc mainly was spot's work with some help from mschwendt, scop and 
some others in the early FESCo days before the FPC existed). I tend to 
say it's overdue to do it again. Guidelines for corner cases in that 
process should get moved to special add-on documents or sections that 
are hidden by default. That will make the main things easier to 
understand and remember. Otherwise we soon have guidelines that will 
look like a code of law/statute book that nobody really understands as 
knows, as they are long and quite hard to read. Maybe splitting the 
guidelines might make sense as well: a "this is how it works in general" 
  could be the quick ans easy start; a "here is how it works in detail" 
could serve as reference doc wher you have to look for the details and 
special treatments when it comes to perl/python/mono/java/...

  * there are likely more ideas floating around...

And note, package reviews are just a fraction of the the area that FESCo 
is responsible for. So in the end instead of wasting time in each FESCo 
meeting with questions like "which reviews did you work on over the past 
week" it would imho be way better to ask "what did you do over the past 
week to make Fedora (the distribution and the project) a better place 
for contributors and users". That would also help to answer the "whom to 
vote for in the next election" question a lot.



From rjones at redhat.com  Sat Oct 11 10:21:29 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 11 Oct 2008 11:21:29 +0100
Subject: Status of libtool 2.2.X?
In-Reply-To: <48EFC71E.5060607@endoframe.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
Message-ID: <20081011102129.GE29105@amd.home.annexia.org>

On Fri, Oct 10, 2008 at 05:20:30PM -0400, Braden McDaniel wrote:
> A copy of the libtool script is typically included in a package.  
> Breakage such as that patch fixes would only be incurred if  
> libtoolize/autoreconf were run as part of the build process--something  
> that simply shouldn't be happening in general for RPM builds.

If I parse that correctly, are you saying that autoreconf *shouldn't*
be run as part of an RPM build?

I have found that it sometimes needs autoreconf if I patch the
configure.ac script -- something which happens rather more frequently
when porting to MinGW.  (After these patches go upstream then it won't
be a problem of course).

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From pertusus at free.fr  Sat Oct 11 10:21:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 11 Oct 2008 12:21:20 +0200
Subject: Package review backlog.
In-Reply-To: <48F07615.7060306@hhs.nl>
References: <1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com> <48F07615.7060306@hhs.nl>
Message-ID: <20081011102120.GA2788@free.fr>

On Sat, Oct 11, 2008 at 11:47:01AM +0200, Hans de Goede wrote:
> John Poelstra wrote:
>>
>> http://tinyurl.com/4kt682
>> 1,212 open Package Review bugs
>
> Of those 1200 pachages awaiting review, 100 block FE_NEEDSPONSOR, so 1100 
> are normal reviews submitted by people which are already contributers! 

These numbers are partly misleading. Indeed many are merge reviews that
are... special, at least should not, in my opinion be counted like
other reviews since they are already in. And among the other many are in
progress and blocked by a change required somewhere, upstream, or in
other package or there is something not obvious in the package that
needs some work, it is not necessarily a lack of reviewers. In some way
having many active review bugs may be good if it is because the review
is serious and allow to have quality packages in only. So, in my opinion
the raw numbers don't mean a lot, what would be meaningful, would be, in
my opinion, the ratio of review requests that nobody had a look at over
the number of fedora contributors.

--
Pat



From jonrob at fedoraproject.org  Sat Oct 11 11:02:38 2008
From: jonrob at fedoraproject.org (Jonathan Roberts)
Date: Sat, 11 Oct 2008 12:02:38 +0100
Subject: Clutter 0.6 in F8?
Message-ID: <507738ef0810110402l3e7c4d3an866697e1bc85f3c0@mail.gmail.com>

I'm having trouble with my package ume-launcher and getting it to build in F8.

Mock fails saying that there's no package 'clutter >= 0.6' available,
but I've checked in Koji and there's a build for F8 completed.

Is there something I'm obviously missing here?

Kindly,

Jon



From rawhide at fedoraproject.org  Sat Oct 11 11:11:53 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 11 Oct 2008 11:11:53 +0000 (UTC)
Subject: rawhide report: 20081011 changes
Message-ID: <20081011111154.123791B8001@releng2.fedora.phx.redhat.com>

Compose started at Sat Oct 11 06:01:15 UTC 2008

New package dahdi-tools
        Userspace tools to configure the DAHDI kernel modules
New package hunspell-ber
        Amazigh hunspell dictionaries
New package hunspell-tk
        Turkmen hunspell dictionaries
New package lxde-common
        Default configuration files for LXDE
New package lxsession-lite
        Lightweight X11 session manager
Updated Packages:

anaconda-11.4.1.48-1
--------------------
* Fri Oct 10 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.48-1
- Remove unnecessary STEP_IP code. (dcantrell)
- Fix how configureTCPIP() returns. (dcantrell)
- Write new sysconfig data to a tmpdir first, then move in place. (dcantrell)
- Write NM_CONTROLLED=yes rather than NM_CONTROLLED= (dcantrell)
- Get rid of some iface flags that were not doing anything anymore.
  (dcantrell)
- Generate new config files in /.tmp in writeEnabledNetInfo() (dcantrell)
- Remove unused variables from configureTCPIP() (dcantrell)
- Do not call get_connection() twice for DHCP. (dcantrell)
- Ask for language and keyboard in rescue mode (#466525). (clumens)
- Fix bringing up the network in rescue mode (#466523). (clumens)
- If we don't have a translation for a lang name, just use the English
  (#466515) (katzj)
- Disable some more IPv6 checks. (clumens)
- Fix a typo (second part of #466374) (katzj)


asterisk-1.6.0.1-1.fc10
-----------------------
* Fri Oct 10 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.0-1
- Update to final release.

* Thu Sep 11 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.6.0-0.22.beta9
- Rebuild


autofs-5.0.3-26
---------------
* Fri Oct 10 18:00:00 2008 Ian Kent <ikent at redhat.com> - 5.0.3-26
- add map-type-in-map-name fix patch to sync with upstream and RHEL.
- don't readmap on HUP for new mount.
- add NIS_PARTIAL to map entry not found check and fix use after free bug.


beldi-0.9.22-1.fc10
-------------------
* Sat Oct 11 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.9.22-1
- Upgrade to 0.9.22
- Add locales and BR gettext

* Thu Oct  2 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.9.21-1
- Upgrade to 0.9.21
- Add new manpage


bluez-4.13-1.fc10
-----------------
* Fri Oct 10 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.13-1
- Update to 4.13


bluez-gnome-1.8-2.fc10
----------------------
* Fri Oct 10 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-2
- Add patch to make the PS3 BD remote work


chktex-1.6.4-3.fc10
-------------------
* Fri Oct 10 18:00:00 2008 Patrice Dumas <pertusus at free.fr>  1.6.4-3
- ship readme and pdf doc
- add ncurses-devel for termcap


cobbler-1.2.6-1.fc10
--------------------
* Tue Oct  7 18:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.2.6-1
- Upstream changes (see CHANGELOG)


control-center-2.24.0.1-7.fc10
------------------------------
* Fri Oct 10 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.0.1-7
- Remove OSS from the possible options (#466342)

* Fri Oct 10 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.0.1-6
- When a sound is selected with the file chooser in g-s-p, make
  sure to default to /usr/share/sounds if that dir exists
  (#456919)


cups-1.3.9-1.fc10
-----------------
* Fri Oct 10 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.3.9-1
- 1.3.9, including fixes for CVE-2008-3639 (STR #2918, bug #464710),
  CVE-2008-3640 (STR #2919, bug #464713) and CVE-2008-3641 (STR #2911,
  bug #464716).
- No longer need str2892 or res_init patches.


ekiga-3.0.0-5.fc10
------------------

gimp-2.6.1-1.fc10
-----------------
* Fri Oct 10 18:00:00 2008 Nils Philippsen <nils at redhat.com> - 2:2.6.1-1
- version 2.6.1

  Overview of Changes from GIMP 2.6.0 to GIMP 2.6.1
  =================================================

  * Bugs fixed:

   555587 ??? PSD file crashes PSD plug-in
   555222 ??? PSD Load Plugin: unsupported compression mode
   555362 ??? gimp-remote is not working properly
   555280 ??? some gif files will not be open
   554890 ??? JPEG Save Options Dialog does not remember
   554966 ??? Gimp crashes creating a new image using a template
   554785 ??? Compile failure on uri-backend-libcurl
   554646 ??? Opening Help crashes GIMP with lqr-plugin installed
   553534 ??? centering issues after image scaling and setting zoom
   554898 ??? Compile failure on uri-backend-wget.c

  * Updated translations:

   Belarusian (be)
   Catalan (ca)
   Finnish (fi)
   French (fr)
   Japanese (ja)
   Macedonian (mk)
   Punjab (pa)
   Brazilian Portuguese (pt_BR)
   Romanian (ro)
   Slovenian (sl)
   Swedish (sv)


gimp-help-2.4.2-1.fc10
----------------------
* Fri Oct 10 18:00:00 2008 Nils Philippsen <nphilipp at redhat.com> - 2.4.2-1
- version 2.4.2


glibc-2.8.90-13
---------------
* Fri Oct 10 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> 2.8.90-13
- apply sparcv9v memset patch from jakub and davem


gnome-applets-2.24.0.1-4.fc10
-----------------------------
* Fri Oct 10 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.0.1-4
- Save space


gnome-backgrounds-2.24.0-2.fc10
-------------------------------
* Fri Oct 10 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Don't ship unneeded translations


gnome-desktop-2.24.0-4.fc10
---------------------------
* Fri Oct 10 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-4
- Try to address bug 465699 by throttling animation frames
  to X server.  May revert if it ends up making animation
  choppy for a lot of people.


gnome-packagekit-0.3.6-5.fc10
-----------------------------
* Fri Oct 10 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.6-5
- Bump

* Fri Oct 10 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.6-4
- Add a bugfix from upstream so we don't try to check for updates
  when we've set to never. Fixes RH#461825.


gnome-screensaver-2.24.0-2.fc10
-------------------------------
* Fri Oct 10 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-2
- Don't leak background pixmaps (gnome bug 555701)


gnome-session-2.24.0-10.fc10
----------------------------
* Fri Oct 10 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-9
- Bring shutdown menu item back.  More fallout from my buggy
  patch introduced in -7

* Fri Oct 10 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-10
- Rewrite patch another time leverage better api and be more
  terse


gnome-settings-daemon-2.24.0-5.fc10
-----------------------------------
* Fri Oct 10 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-5
- Fix the picking up of the gdm keyboard layout even more


gnome-utils-2.24.0-3.fc10
-------------------------
* Fri Oct 10 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.0-3
- Save space


gstreamermm-0.9.7-1.fc10
------------------------
* Fri Oct 10 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 0.9.7-1
- Update to upstream 0.9.7


jd-2.0.3-0.1.svn2387_trunk.fc10
-------------------------------
* Sat Oct 11 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2387


kdebase-workspace-4.1.2-5.fc10
------------------------------
* Fri Oct 10 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-5
- disable panel-autohide-fix-flicker patch for now, eats CPU


kernel-2.6.27-3.fc10
--------------------
* Fri Oct 10 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- rebase drm patches onto drm-next.patch which is going upstream
- intel modesetting make not work properly due to rebase


koan-1.2.6-1.fc10
-----------------
* Thu Oct  2 18:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.2.6-1
- Upstream changes (see CHANGELOG)


libcanberra-0.10-2.fc10
-----------------------
* Fri Oct 10 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.10.2
- Drop libcanberra-gtk-module.sh since the gconf stuff is supported just fine in current gnome-session already.


lirc-0.8.4-0.5.pre2.fc10
------------------------
* Fri Oct 10 18:00:00 2008 - Jarod Wilson <jarod at redhat.com> - 0.8.4-0.5.pre2
- Re-enable portaudio driver by default, require v19 or later


livecd-tools-019-1.fc10
-----------------------
* Fri Oct 10 18:00:00 2008 Jeremy Katz <katzj at redhat.com> - 019-1
- livecd-iso-to-disk: Various other XO fixes
- Cleanup rpmdb locks after package installation
- Fix traceback due to lazy rhpl.keyboard import
- Fix using groups with options (jkeating)
- Support persistent /home on XO's internal flash
- Fix ramdisk load addr in boot/olpc.fth for XO
- Fix up boot from SD
- Fix extracting boot parameters for pxe (apevec)
- Make rpm macro information persist into the image (bkearney)
- Support %packages --instLangs (bkearney)


mgetty-1.1.36-2.fc10
--------------------
* Fri Oct 10 18:00:00 2008 Jiri Skala <jskala at redhat.com> - 1.1.36-1
- fix #464983 - FTBFS mgetty-1.1.36-1.fc10 - regenerated patches


mod_mono-2.0-5.fc10
-------------------
* Fri Oct 10 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-5
- fix URLs


nntpgrab-0.3.93-1.fc10
----------------------
* Fri Oct 10 18:00:00 2008 Erik van Pienbroek <info at nntpgrab.nl> - 0.3.93-1
- Update to 0.3.93


perl-Locale-Maketext-Lexicon-0.71-1.fc10
----------------------------------------
* Fri Oct 10 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.71-1
- Upstream update.
- Spec cleanup.
- Add spec hacks to work around rpm bugs.


plymouth-0.6.0-0.2008.10.08.2.fc10
----------------------------------
* Fri Oct 10 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.10.08.2
- Add Requires(post): nash (bug 466500)


python-netaddr-0.5.2-1.fc10
---------------------------
* Fri Oct 10 18:00:00 2008 John Eckersberg <jeckersb at redhat.com> - 0.5.2-1
- New upstream version, bug fixes for 0.5.1


python-sphinx-0.4.3-1.fc10
--------------------------
* Fri Oct 10 18:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.4.3-1
- Update to 0.4.3

* Wed Aug 27 18:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 0.4.2-1.1
- Fix for EL-5 build.


rubygem-cobbler-0.1.1-1.fc10
----------------------------
* Fri Oct 10 18:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 0.1.1-1
- Added support for image-based systems.


setup-2.7.4-1.fc10
------------------
* Thu Oct  9 18:00:00 2008 Phil Knirsch <pknirsch at redhat.com> 2.7.4-1
- Include new serviceslint for speedup (#465642)
- Cleaned up services due to newly discovered bugs in it with new serviceslint


slim-1.3.1-1.fc10
-----------------
* Thu Oct  9 18:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com>  1.3.1-1
- Update to 1.3.1


tar-1.20-3.fc10
---------------
* Fri Oct 10 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 2:1.20-3
- Fixed wrong documentation for xattrs options (#466517)
- fixed bug with null file terminator and change dirs
  (upstream)


xorg-x11-server-1.5.2-2.fc10
----------------------------
* Fri Oct 10 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.5.2-2
- xserver-1.5.1-global-backtrace.patch: Make backtraces possible from
  outside the xfree86 DDX.
- xserver-1.5.2-mieq-backtrace.patch: bt when we fill the input queue.

* Fri Oct 10 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.5.2-1
- xserver 1.5.2
- xserver-1.5.0-comment-out-glxdri2.c: Drop, no longer relevant.
- xserver-1.5.0-xkb-core-kbd-map-fix.patch: Drop, merged.
- xserver-1.5.1-int10-leaks.patch: Drop, merged.

* Fri Oct 10 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.5.1-11
- xserver-1.3.0-no-prerelease-warning.patch: Drop.


xpad-3.0-1.fc10
---------------
* Fri Oct 10 18:00:00 2008 Stefan Posdzich <cheekyboinc at foresightlinux.org> - 3.0-1
- Update to new upstream version 3.0
- Upstream: Doesn't wake up every 20 milliseconds
- Upstream: Added some command line options (--hide, --show)
- Upstream: Update icon a bit
- Change license to GPLv3+


Summary:
Added Packages: 5
Removed Packages: 0
Modified Packages: 43
Broken deps for i386
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From rjones at redhat.com  Sat Oct 11 11:27:42 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 11 Oct 2008 12:27:42 +0100
Subject: Python 2.6?
Message-ID: <20081011112639.GA29421@amd.home.annexia.org>


Is Python 2.6 planned for Fedora 10?

(Not asking for it, just wondering because it affects what the MinGW
SIG do).

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From pbrobinson at gmail.com  Sat Oct 11 11:38:34 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 11 Oct 2008 12:38:34 +0100
Subject: Clutter 0.6 in F8?
In-Reply-To: <507738ef0810110402l3e7c4d3an866697e1bc85f3c0@mail.gmail.com>
References: <507738ef0810110402l3e7c4d3an866697e1bc85f3c0@mail.gmail.com>
Message-ID: <5256d0b0810110438u2fa3dfe9w95cfcbd145972d4@mail.gmail.com>

> I'm having trouble with my package ume-launcher and getting it to build in F8.
>
> Mock fails saying that there's no package 'clutter >= 0.6' available,
> but I've checked in Koji and there's a build for F8 completed.
>
> Is there something I'm obviously missing here?

Has it just been built for F-8 or has it actually been pushed out to
updates? It will need to be in updates I think to be able to pull it
in otherwise you could push an update without the proper dependencies
being available. With F-8 going EOL shortly I have typically not been
pushing new packages out to F-8 and just doing F-9.

Peter



From pbrobinson at gmail.com  Sat Oct 11 11:41:18 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 11 Oct 2008 12:41:18 +0100
Subject: Python 2.6?
In-Reply-To: <20081011112639.GA29421@amd.home.annexia.org>
References: <20081011112639.GA29421@amd.home.annexia.org>
Message-ID: <5256d0b0810110441l18684870v10f9dbf037bab272@mail.gmail.com>

> Is Python 2.6 planned for Fedora 10?

I think its a bit late for new stuff especially something as large as
python, my guess is that it would hit rawhide shortly after the branch
for F-10.

Peter



From kevin.kofler at chello.at  Sat Oct 11 13:08:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 13:08:46 +0000 (UTC)
Subject: How to package code compiled with 'gcc -m32'?
References: <20081007133518.GA10140@amd.home.annexia.org>
	<1223392329.754.16.camel@aglarond.local>
	<20081007165609.GA10665@amd.home.annexia.org>
	<loom.20081007T173256-441@post.gmane.org>
	<20081007185127.GB11246@amd.home.annexia.org>
	<loom.20081008T092911-618@post.gmane.org>
	<20081008133754.GA14995@amd.home.annexia.org>
Message-ID: <loom.20081011T130330-357@post.gmane.org>

Richard W.M. Jones <rjones <at> redhat.com> writes:
> That patch builds a 64 bit makensis, which is definitely an
> improvement.  However something still wants to link with the 32 bit
> wxGTK-devel.i386 library and include <gnu/stubs-32.h>.

I fixed that, and I also disabled the wxGTK menu app because it doesn't appear 
to work on non-Window$. Disabling the menu also avoids having to drag in wxGTK 
into something which is otherwise a plain command-line tool.

I sent you updated SRPMs in private mail, can you please merge my changes? (In 
addition to the fixes, I'd also really like the Obsoletes/Provides for nsis and 
nsis-data to go in.)

        Kevin Kofler



From Matt_Domsch at dell.com  Sat Oct 11 13:17:59 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sat, 11 Oct 2008 08:17:59 -0500
Subject: Python 2.6?
In-Reply-To: <5256d0b0810110441l18684870v10f9dbf037bab272@mail.gmail.com>
References: <20081011112639.GA29421@amd.home.annexia.org>
	<5256d0b0810110441l18684870v10f9dbf037bab272@mail.gmail.com>
Message-ID: <20081011131759.GA2709@auslistsprd01.us.dell.com>


> > Is Python 2.6 planned for Fedora 10?
> 
> I think its a bit late for new stuff especially something as large as
> python, my guess is that it would hit rawhide shortly after the branch
> for F-10.

This is my understanding too.  Post-beta, no major changes should be
introduced, especially one as wide-ranging as upgrading python, upon
which hundreds of packages rely, and may have hard-coded '2.5's
scattered...

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



From christoph.wickert at googlemail.com  Sat Oct 11 13:25:15 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 11 Oct 2008 15:25:15 +0200
Subject: Package review backlog.
In-Reply-To: <48F01BDF.1000109@redhat.com>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com>
Message-ID: <1223731515.3923.23.camel@wicktop.localdomain>

Am Freitag, den 10.10.2008, 20:22 -0700 schrieb John Poelstra:
> David Woodhouse said the following on 10/10/2008 07:30 AM Pacific Time:
> > On Fri, 2008-10-10 at 15:33 +0200, Christoph Wickert wrote:
> >> Am Freitag, den 10.10.2008, 14:14 +0100 schrieb David Woodhouse:
> >>
> >>> I propose that each FESCo member should try to work on at least one
> >>> package review per week. Each week at the FESCo meeting, we'll ask
> >>> members which reviews they've worked on in the past week.
> >>>
> >>> It won't be _mandatory_ -- 
> >> [snipped] 
> >>
> >> As a rule of thumb it's ok, but it should not be mandatory. I think the
> >> FESCo members are already having a lot of work to do and I'm not sure if
> >> everybody has enough spare time for reviews.
> > 
> > Absolutely. Besides, if you do call it 'mandatory' you have to start
> > defining what would happen if people don't comply, and the whole thing
> > just gets silly.
> > 
> > I'm talking about a 'recommended practice', and just asking people each
> > week which packages they've looked at. Nothing more.
> > 
> > And even though people are busy, it shouldn't actually take _that_ long
> > to make progress on reviewing a single package, each week.
> > 
> 
> http://tinyurl.com/4kt682
> 1,212 open Package Review bugs

Thanks for putting up this link, but I think the number is misleading,
because it includes a high number of reviews that are already assigned
and/or have the flag set to "fedora?review?" A lot of them are waiting
for response from the review requester. AFAICS you searched for all
reviews that are not yet closed, right?

But this reminds me of another problem, which is IMO more important:

I have to admit that I'm one of those who have a negative balance, I own
more packages than I did reviews. But this is mostly due to the number
of xfce4-panel plugins I own and they are very trivial to review.

Back to my problem: 
I would have love to do more reviews, but I'm having a hard time trying
to find suitable reviews. Back in those days, when we had the tracker
bugs it was easy: I bookmarked the tracker bug in dependance view, so I
could see all info I need at a glance. Now that we have the reviews with
flags I don't even know how to search bugzilla, because I want to search
only for reviews that don't have a flag set. How to achieve that? When I
search for all review requests with

      * status=new
      * flag is not equal to fedora-review?
      * and
      * flag is not equal to fedora-review+

Bugzilla returns "This list is too long for Red Hat Bugzilla's little
mind..." What I'm I doing wrong?

Christoph



From kevin.kofler at chello.at  Sat Oct 11 13:59:11 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 13:59:11 +0000 (UTC)
Subject: Clutter 0.6 in F8?
References: <507738ef0810110402l3e7c4d3an866697e1bc85f3c0@mail.gmail.com>
	<5256d0b0810110438u2fa3dfe9w95cfcbd145972d4@mail.gmail.com>
Message-ID: <loom.20081011T135436-924@post.gmane.org>

Peter Robinson <pbrobinson <at> gmail.com> writes:
> Has it just been built for F-8 or has it actually been pushed out to
> updates? It will need to be in updates I think to be able to pull it
> in otherwise you could push an update without the proper dependencies
> being available.

You can get a candidate update into the buildroot faster if you ask rel-eng for 
the appropriate override tag (dist-f8-override or dist-f9-override, with 
dist-f10-override soon to come (but not existing or necessary yet, it will be 
used and needed only after the final development freeze, i.e. once builds start 
going into dist-f10-updates-candidate rather than dist-f10)):
https://fedorahosted.org/rel-eng/newticket

In some cases, like soname bumps, this is even _required_ or you'll break 
dependencies. (You have to push out dependent packages at the same time as the 
soname-bumped library, no earlier, no later, so you can't push the library to 
stable just to build the other stuff against it. Instead, you have to request 
an override tag for the library, rebuild the dependent stuff and then push a 
grouped update with everything.)

        Kevin Kofler



From james at fedoraproject.org  Sat Oct 11 14:12:09 2008
From: james at fedoraproject.org (James Antill)
Date: Sat, 11 Oct 2008 10:12:09 -0400
Subject: Python 2.6?
In-Reply-To: <20081011112639.GA29421@amd.home.annexia.org>
References: <20081011112639.GA29421@amd.home.annexia.org>
Message-ID: <1223734329.15256.2.camel@code.and.org>

On Sat, 2008-10-11 at 12:27 +0100, Richard W.M. Jones wrote:
> Is Python 2.6 planned for Fedora 10?
> 
> (Not asking for it, just wondering because it affects what the MinGW
> SIG do).

 python was branched for Fedora 10 early, so that when someone has time
they can put Python-2.6 in for Fedora 11 (if anyone wants to help out,
feel free to volunteer :).

-- 
James Antill <james at fedoraproject.org>
Fedora



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Oct 11 14:18:44 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sat, 11 Oct 2008 23:18:44 +0900
Subject: Package review backlog.
In-Reply-To: <1223731515.3923.23.camel@wicktop.localdomain>
References: <loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<1223645613.3514.12.camel@wicktop.localdomain>	<1223649007.6770.25.camel@macbook.infradead.org>	<48F01BDF.1000109@redhat.com>
	<1223731515.3923.23.camel@wicktop.localdomain>
Message-ID: <48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>

Christoph Wickert wrote, at 10/11/2008 10:25 PM +9:00:
> Am Freitag, den 10.10.2008, 20:22 -0700 schrieb John Poelstra:

>> http://tinyurl.com/4kt682
>> 1,212 open Package Review bugs
> 
> Thanks for putting up this link, but I think the number is misleading,
> because it includes a high number of reviews that are already assigned
> and/or have the flag set to "fedora?review?" A lot of them are waiting
> for response from the review requester. AFAICS you searched for all
> reviews that are not yet closed, right?
> 
> But this reminds me of another problem, which is IMO more important:
> 
> Back to my problem: 
> I would have love to do more reviews, but I'm having a hard time trying
> to find suitable reviews. Now that we have the reviews with
> flags I don't even know how to search bugzilla, because I want to search
> only for reviews that don't have a flag set. How to achieve that? When I
> search for all review requests with
> 
>       * status=new
>       * flag is not equal to fedora-review?
>       * and
>       * flag is not equal to fedora-review+
> 
> Bugzilla returns "This list is too long for Red Hat Bugzilla's little
> mind..." What I'm I doing wrong?
> 
> Christoph

http://fedoraproject.org/PackageReviewStatus/NEW.html
is perhaps the easiest.

Regards,
Mamoru



From pbrobinson at gmail.com  Sat Oct 11 14:55:49 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 11 Oct 2008 15:55:49 +0100
Subject: Package review backlog.
In-Reply-To: <48F07615.7060306@hhs.nl>
References: <loom.20081008T092258-152@post.gmane.org>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com> <48F07615.7060306@hhs.nl>
Message-ID: <5256d0b0810110755q4a7d93dayf677b9b490a4be06@mail.gmail.com>

>>>>> I propose that each FESCo member should try to work on at least one
>>>>> package review per week. Each week at the FESCo meeting, we'll ask
>>>>> members which reviews they've worked on in the past week.
>>>>>
>>>>> It won't be _mandatory_ --
>>>>
>>>> [snipped]
>>>> As a rule of thumb it's ok, but it should not be mandatory. I think the
>>>> FESCo members are already having a lot of work to do and I'm not sure if
>>>> everybody has enough spare time for reviews.
>>>
>>> Absolutely. Besides, if you do call it 'mandatory' you have to start
>>> defining what would happen if people don't comply, and the whole thing
>>> just gets silly.
>>>
>>> I'm talking about a 'recommended practice', and just asking people each
>>> week which packages they've looked at. Nothing more.
>>>
>>> And even though people are busy, it shouldn't actually take _that_ long
>>> to make progress on reviewing a single package, each week.
>>>
>>
>> http://tinyurl.com/4kt682
>> 1,212 open Package Review bugs
>
> Woa,
>
> Thats an amanzing number, I'll put in, or rather repeat, my 2 cents here.
> Fedora, like any opensource community, is all about give and take, about tit
> for tat.
>
> I've submitted many, many new packages (100+ I guess) and I've *never* had
> any problems in getting them reviewed.
>
> Of those 1200 pachages awaiting review, 100 block FE_NEEDSPONSOR, so 1100
> are normal reviews submitted by people which are already contributers! Lets
> say every contributer has on average 2 packages waiting for review, then 2
> have 550 contributers for whom the review queue is a problem, if all of
> those 550 submitters would review only 2 packages, then the entire normal
> review queue is gone!

There's also 100 odd packages with a fedora-cvs flag of some sort set
so should either be done and the bug needs closing or nearly done.

Peter



From opensource at till.name  Sat Oct 11 14:58:43 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 16:58:43 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010144426.GC3236@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
Message-ID: <200810111658.49564.opensource@till.name>

On Fri October 10 2008, Patrice Dumas wrote:

> support from the boards. Some months ago I proposed something for a
> fedora lts that was brought down, maybe for good reasons, but the tone
> of the discussions really showed very few support, and I'd even say some
> antagonism.

Iirc you would get support in terms of infrastructure in case you have a clear 
proposal and enough people doing the work. Also they should show, that they 
are really interested in doing this for long enough, that it does not look 
like a failed project. E.g. starting now a Fedora LTS project and ending it 
next year, because there are not enough maintainers/people interested in 
doing the work, does not look good for Fedora.

If you think you have enough people, then maybe create a list of them and show 
how they will maintain the packages for the LTS. E.g. they could be already 
(co)maintainers of the current Fedora packages and do work within Fedora 
Infrastructure, Security Response Team and Release Engineering, Translations 
and all the other teams that are needed to compose a distribution. But you 
cannot expect much support from people who do not have a big enough interest 
in this project and spend time on it, that they could spend on improving the 
parts of Fedora, they are interested in.

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/20081011/2291e0f3/attachment.sig>

From christoph.wickert at googlemail.com  Sat Oct 11 15:06:27 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sat, 11 Oct 2008 17:06:27 +0200
Subject: Package review backlog.
In-Reply-To: <48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com>
	<1223731515.3923.23.camel@wicktop.localdomain>
	<48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>
Message-ID: <1223737587.3923.29.camel@wicktop.localdomain>

Am Samstag, den 11.10.2008, 23:18 +0900 schrieb Mamoru Tasaka:
> Christoph Wickert wrote, at 10/11/2008 10:25 PM +9:00:
> > I would have love to do more reviews, but I'm having a hard time trying
> > to find suitable reviews. Now that we have the reviews with
> > flags I don't even know how to search bugzilla, because I want to search
> > only for reviews that don't have a flag set. How to achieve that? When I
> > search for all review requests with
> > 
> >       * status=new
> >       * flag is not equal to fedora-review?
> >       * and
> >       * flag is not equal to fedora-review+
> > 
> > Bugzilla returns "This list is too long for Red Hat Bugzilla's little
> > mind..." What I'm I doing wrong?
> > 
> > Christoph
> 
> http://fedoraproject.org/PackageReviewStatus/NEW.html
> is perhaps the easiest.

I know this one, but this page also returns reviews that are already
assigned. And if somebody assigns a review to himself I assume that he's
doing it.

> Regards,
> Mamoru

Regards,
Christoph



From dwmw2 at infradead.org  Sat Oct 11 15:07:35 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 11 Oct 2008 16:07:35 +0100
Subject: Package review backlog.
In-Reply-To: <48F07C5C.8000403@leemhuis.info>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<48F07C5C.8000403@leemhuis.info>
Message-ID: <1223737655.6770.251.camel@macbook.infradead.org>

On Sat, 2008-10-11 at 12:13 +0200, Thorsten Leemhuis wrote:
> Nice idea, but for me that sounds like a pre-election promise to lower
> taxes or like big and rich politicians handling out food in a soup 
> kitchen or a: It will help a few people and gives good press because 
> it's popular, but it doesn't solve the underlying problem at all. In 
> fact it's even worse, because time gets wasted instead of solving the 
> underlying or other problems (that might be bigger or smaller).

I don't think I'm up for election this time round, and I hope it didn't
come across that way. I'm always prepared to be held accountable for my
views and actions; I'm not really known for playing politics :)

As for asking about it in meetings -- I just meant that as a means of
encouraging/reminding people to actually _do_ it, because an empty
statement that we _intend_ to do such reviews is fairly pointless if we
then just forget about it. I certainly didn't mean it as some kind of
measure by which FESCo members' performance would be measured. You're
right; there are much better things for people to be looking at when
election time comes round.

I do think that my proposal would help to improve the underlying
problem, although of course I'm prepared to be persuaded otherwise --
and it was, after all, just a suggestion.

By getting FESCo members more involved in reviews, we should help to
raise the profile of package review and set a good example; hopefully
others will also follow suit. And it should mean that some of the
existing proposals for making reviews run smoother would get a little
bit more attention too, and thus get pushed through to reality. As well
as directly making a small dent in the backlog, of course -- but that
'direct' effect is minimal, and not really the point.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From jreiser at BitWagon.com  Sat Oct 11 15:10:06 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Sat, 11 Oct 2008 08:10:06 -0700
Subject: young Fedora torrents spread data too slowly
Message-ID: <48F0C1CE.30104@BitWagon.com>

Young torrents on http://torrent.fedoraproject.org/ spread data too slowly.
At 0500 UTC on Sat.Oct.11, there was 1 seed and 14 leeches, all at 13% done.
At 1300 UTC on Sat.Oct.11, there was 1 seed and 31 leeches, all at 55% done.
This is for F10-Snap1-x86_64-Live.
I turned my machine off for the night (US PDT), powered on in the morning,
and within half an hour had caught up to all leeches at 57% done.
I use tranmsissionbt, and I saw that the seed was sending pieces of 256 KiB
to me at 2.5 KiB/s, taking almost two minutes per piece (and then "pausing.")

It seems to me that torrent.fedoraproject.org is overloaded, and that a change
in policy would give sooner completion to everybody, even without more resources.
Namely, give priority service to young torrents (less than 1 day old), and
while there are less than 2 other seeds then give even higher priority service
to the fastest sqrt(N) leeches.  The current policy of serving each client alike
results in everybody waiting for the one overloaded seed.  Increasing the size
of the swarm does not decrease anybody's completion time.
Instead, the sooner that there are >=2 other seeds, then the sooner that
*all* leeches complete, even though the fastest may complete much sooner
than others, and even though some greedy new seeds may quit the swarm
soon after reaching 100%.

Implementing such policies may require using a seeder/tracker that serves
more than one torrent at a time, but this feature is available
in a number of trackers, including Transmission.

-- 



From dbn.lists at gmail.com  Sat Oct 11 15:17:40 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Sat, 11 Oct 2008 08:17:40 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081011102129.GE29105@amd.home.annexia.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
Message-ID: <91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>

On Sat, Oct 11, 2008 at 3:21 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Fri, Oct 10, 2008 at 05:20:30PM -0400, Braden McDaniel wrote:
>> A copy of the libtool script is typically included in a package.
>> Breakage such as that patch fixes would only be incurred if
>> libtoolize/autoreconf were run as part of the build process--something
>> that simply shouldn't be happening in general for RPM builds.
>
> If I parse that correctly, are you saying that autoreconf *shouldn't*
> be run as part of an RPM build?

That's what he's saying. The main goal of the autotools is that the
package comes to you ready to build with just basic unix tools: shell,
make, compiler/linker. So, you tend to not want to try to regenerate
the build files on your own. Especially since the procedure some
projects use can be fragile at best. autoreconf usually does the right
thing, though.

> I have found that it sometimes needs autoreconf if I patch the
> configure.ac script -- something which happens rather more frequently
> when porting to MinGW.  (After these patches go upstream then it won't
> be a problem of course).

You always need to run autoconf again if you've patched the
configure.ac file, or nothing happens. You can run autoreconf locally
and add the regenerated configure/aclocal.m4 to your patch, but it
will be severely bloated.

I tend to think it's not bad to regenerate the autotools. It's usually
cleaner and more robust to just fix the files at the source (like
you're doing) than to try to hack around it.

--
Dan



From cra at WPI.EDU  Sat Oct 11 15:32:33 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 11:32:33 -0400
Subject: Package review backlog.
In-Reply-To: <1223737587.3923.29.camel@wicktop.localdomain>
References: <1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com>
	<1223731515.3923.23.camel@wicktop.localdomain>
	<48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>
	<1223737587.3923.29.camel@wicktop.localdomain>
Message-ID: <20081011153233.GD10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 05:06:27PM +0200, Christoph Wickert wrote:
> > http://fedoraproject.org/PackageReviewStatus/NEW.html
> > is perhaps the easiest.
> 
> I know this one, but this page also returns reviews that are already
> assigned. And if somebody assigns a review to himself I assume that he's
> doing it.

I would like to help with reviews.  I'm not sponsored yet, but have 
several of my own review requests that have NEEDSPONSOR [1] [2] [3].  
Is it useful for me to review other packages in the queue?  What about 
Merge Reviews?  Given that I'm not sponsored, should I take ownership 
of the package review requests, or just do initial reviews without 
taking ownership?  Obviously, I don't think I can set the 
fedora-review flag yet.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=ocp
[2] https://bugzilla.redhat.com/show_bug.cgi?id=Judy
[3] https://bugzilla.redhat.com/show_bug.cgi?id=miredo



From cra at WPI.EDU  Sat Oct 11 15:36:21 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 11:36:21 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F0C1CE.30104@BitWagon.com>
References: <48F0C1CE.30104@BitWagon.com>
Message-ID: <20081011153621.GE10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 08:10:06AM -0700, John Reiser wrote:
> Young torrents on http://torrent.fedoraproject.org/ spread data too slowly.
> At 0500 UTC on Sat.Oct.11, there was 1 seed and 14 leeches, all at 13% done.
> At 1300 UTC on Sat.Oct.11, there was 1 seed and 31 leeches, all at 55% done.
> This is for F10-Snap1-x86_64-Live.
> I turned my machine off for the night (US PDT), powered on in the morning,
> and within half an hour had caught up to all leeches at 57% done.
> I use tranmsissionbt, and I saw that the seed was sending pieces of 256 KiB
> to me at 2.5 KiB/s, taking almost two minutes per piece (and then "pausing.")

To be honest, I'm less interested in downloading a snapshot that 
doesn't have an installer that works.  The whole point of using a 
snapshot rather than say, a daily rawhide, is to test the installer on 
media rather than a network install.  Perhaps others feel the same way 
which is why there isn't much contribution to this torrent.



From kevin.kofler at chello.at  Sat Oct 11 15:52:30 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 15:52:30 +0000 (UTC)
Subject: Poppler 0.10.0
Message-ID: <loom.20081011T155143-317@post.gmane.org>

Hi,

any chance we can get Poppler 0.10.0 into F10?
http://tsdgeos.blogspot.com/2008/10/poppler-0100-release.html

        Kevin Kofler



From jkeating at redhat.com  Sat Oct 11 16:07:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 11 Oct 2008 09:07:35 -0700
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <20081011153621.GE10204@angus.ind.WPI.EDU>
References: <48F0C1CE.30104@BitWagon.com>
	<20081011153621.GE10204@angus.ind.WPI.EDU>
Message-ID: <1223741255.3327.10.camel@luminos.localdomain>

On Sat, 2008-10-11 at 11:36 -0400, Chuck Anderson wrote:
> To be honest, I'm less interested in downloading a snapshot that 
> doesn't have an installer that works.  The whole point of using a 
> snapshot rather than say, a daily rawhide, is to test the installer on 
> media rather than a network install.  Perhaps others feel the same way 
> which is why there isn't much contribution to this torrent.

However testing a live image, which isn't created nightly with rawhide,
does have a lot of value.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/0a91acc8/attachment.sig>

From cra at WPI.EDU  Sat Oct 11 16:20:49 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 12:20:49 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <1223741255.3327.10.camel@luminos.localdomain>
References: <48F0C1CE.30104@BitWagon.com>
	<20081011153621.GE10204@angus.ind.WPI.EDU>
	<1223741255.3327.10.camel@luminos.localdomain>
Message-ID: <20081011162049.GF10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 09:07:35AM -0700, Jesse Keating wrote:
> However testing a live image, which isn't created nightly with rawhide,
> does have a lot of value.

Good point.  I'm torrenting now :-)



From kevin.kofler at chello.at  Sat Oct 11 16:34:42 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 16:34:42 +0000 (UTC)
Subject: Status of libtool 2.2.X?
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
	<91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>
Message-ID: <loom.20081011T161204-624@post.gmane.org>

Dan Nicholson <dbn.lists <at> gmail.com> writes:
> The main goal of the autotools is that the package comes to you ready to
> build with just basic unix tools: shell, make, compiler/linker. So, you tend
> to not want to try to regenerate the build files on your own.

And that's one of the main design flaws:
* Bugs at one place get copied into hundreds of packages.
* It wastes space for autogenerated files in tarballs (and those configure 
scripts can often be HUGE, e.g. anything including the KDE 3 acinclude.m4 ends 
up with a huge (over a MB) configure script).
* It makes you reliant on the shell, which may be not available (Window$ - 
sure, there is MSYS, but having to install MSYS is no better than having to 
install e.g. CMake) or very buggy (some proprietary Unix systems, workarounds 
for which are littered all throughout the autotools).
* It is unnecessary: Why is it OK to have to install make and not e.g. CMake?
* It leads to non-reproducibility, i.e. programs which only build with 
generated files which are very hard to regenerate properly ("fragile" as you 
call it), which makes it harder to modify the programs (I've had my fair share 
of problems already with programs which were hard to modify because they 
depended on some ancient autotools version which was no longer available in 
current distributions - the lack of backwards compatibility is a real problem, 
using pregenerated files solves this problem only for users, not for 
developers), going against the spirit of Free Software, maybe even against the 
letter of the GPL.

(CMake is only an example in the above - you could fill in any central build 
tool there, like SCons, qmake etc.)

Unfortunately, I don't think all the problems caused by this design flaw can be 
fixed within the autotools. What I would suggest to you and other autotools 
developers (and that's a serious suggestion!) is:
* improve backwards compatibility: Don't depend on pregenerated files for 
backwards compatibility, instead make sure there's a way to use older .ac 
and .am files with newer autotools. Keying compatibility features off macros 
like AC_PREREQ might work, or maybe something like Java's --source 1.5 (or 1.4 
or ...) switch.
* start discouraging shipping pregenerated files, instead make sure that 
autoreconf actually works (which mainly amounts to the above point about 
backwards compatibility).
But unfortunately, this won't solve the problem of the reliance on the shell, 
and as configure.ac scripts can contain arbitrary shell snippets, this can't 
really be fixed without a major redesign, the result of which would effectively 
no longer be autotools.

        Kevin Kofler



From jkeating at redhat.com  Sat Oct 11 16:55:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 11 Oct 2008 09:55:33 -0700
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F06C9C.2030503@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com> <70s4s5x57i.ln2@ppp1053.in.ipex.cz>
	<48F06C9C.2030503@gmail.com>
Message-ID: <1223744133.3327.11.camel@luminos.localdomain>

On Sat, 2008-10-11 at 04:06 -0500, Les Mikesell wrote:
> 
> There's no lead time for your own local development and testing.  You 
> would never expect one of the old RH X.0 releases to be production-ready 
> but the new releases would have new kernels, libraries, and utilities so 
> you could incorporate their features in your own work, which was likely 
> to proceed at approximately the same rate as the distro evolved toward 
> stability.  With Centos you don't get anything to work with and test 
> ahead of time, and if you'd tested on an earlier Fedora there may or may 
> not be any relationship.  A side effect was that the community of RH 
> users that reported/fixed bugs in the X.0 got something for their effort 
> in being able to continue using the updated release instead of being 
> abandoned as a wildly new X.0 came out.

CentOS should be putting out betas that match the RHEL betas so that you
can get access to it before the release.  Use Fedora as the technology
driver, use Betas as the bugfix cleanup for platform issues, and
eventually you get the "Enterprise" release.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/94af4e8b/attachment.sig>

From braden at endoframe.com  Sat Oct 11 17:08:59 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 13:08:59 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <20081011102129.GE29105@amd.home.annexia.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
Message-ID: <1223744939.13589.285.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 11:21 +0100, Richard W.M. Jones wrote:
> On Fri, Oct 10, 2008 at 05:20:30PM -0400, Braden McDaniel wrote:
> > A copy of the libtool script is typically included in a package.  
> > Breakage such as that patch fixes would only be incurred if  
> > libtoolize/autoreconf were run as part of the build process--something  
> > that simply shouldn't be happening in general for RPM builds.
> 
> If I parse that correctly, are you saying that autoreconf *shouldn't*
> be run as part of an RPM build?

Yes.

> I have found that it sometimes needs autoreconf if I patch the
> configure.ac script -- something which happens rather more frequently
> when porting to MinGW.  (After these patches go upstream then it won't
> be a problem of course).

You should be patching configure, not configure.ac.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From braden at endoframe.com  Sat Oct 11 17:26:39 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 13:26:39 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
	<91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>
Message-ID: <1223745999.13589.297.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 08:17 -0700, Dan Nicholson wrote:
> On Sat, Oct 11, 2008 at 3:21 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> > On Fri, Oct 10, 2008 at 05:20:30PM -0400, Braden McDaniel wrote:
> >> A copy of the libtool script is typically included in a package.
> >> Breakage such as that patch fixes would only be incurred if
> >> libtoolize/autoreconf were run as part of the build process--something
> >> that simply shouldn't be happening in general for RPM builds.
> >
> > If I parse that correctly, are you saying that autoreconf *shouldn't*
> > be run as part of an RPM build?
> 
> That's what he's saying. The main goal of the autotools is that the
> package comes to you ready to build with just basic unix tools: shell,
> make, compiler/linker. So, you tend to not want to try to regenerate
> the build files on your own. Especially since the procedure some
> projects use can be fragile at best. autoreconf usually does the right
> thing, though.
> 
> > I have found that it sometimes needs autoreconf if I patch the
> > configure.ac script -- something which happens rather more frequently
> > when porting to MinGW.  (After these patches go upstream then it won't
> > be a problem of course).
> 
> You always need to run autoconf again if you've patched the
> configure.ac file, or nothing happens. You can run autoreconf locally
> and add the regenerated configure/aclocal.m4 to your patch, but it
> will be severely bloated.

There's no reason to patch aclocal.m4 or configure.ac at all.  You only
need to patch configure.  While that patch is likely to be bigger than a
patch to configure.ac, calling it "bloated" is a gross exaggeration.

> I tend to think it's not bad to regenerate the autotools. It's usually
> cleaner and more robust to just fix the files at the source (like
> you're doing) than to try to hack around it.

I'm not sure how modifying files unnecessarily, pulling in additional
dependencies, and making builds take longer is "cleaner", but that's
subjective.  It is certainly *not* "more robust".  By rebuilding
configure with potentially different autotools than the upstream
developer used, you expose the package build to potential
incompatibilities and breakage.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From cra at WPI.EDU  Sat Oct 11 17:37:51 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 13:37:51 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <20081011162049.GF10204@angus.ind.WPI.EDU>
References: <48F0C1CE.30104@BitWagon.com>
	<20081011153621.GE10204@angus.ind.WPI.EDU>
	<1223741255.3327.10.camel@luminos.localdomain>
	<20081011162049.GF10204@angus.ind.WPI.EDU>
Message-ID: <20081011173751.GG10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 12:20:49PM -0400, Chuck Anderson wrote:
> On Sat, Oct 11, 2008 at 09:07:35AM -0700, Jesse Keating wrote:
> > However testing a live image, which isn't created nightly with rawhide,
> > does have a lot of value.
> 
> Good point.  I'm torrenting now :-)

If only 45 people are interested in downloading the torrent, why have 
a torrent at all?  This is much slower than a FTP or HTTP download 
would be.  For snapshots whose useful lifespan is maybe only a week 
and whose demand may be rather low, it might make more sense to 
provide un-mirrored direct HTTP downloads.  Or distribute the .iso's 
to a few willing mirrors who the seed the content via bittorrent.  I'm 
volunteering to do this.  I'll certainly leave my client seeding once 
it gets the whole file, but by then the weekend may be over and I 
won't have time for testing anymore :-(

file:     F10-Snap1-i686-Live
seeds:    1 seen now, plus 0 distributed copies(1:60.1%, 2:60.1%, 3:60.1%)
peers:    45 seen now

file:     F10-Snap1-x86_64-Live
seeds:    1 seen now, plus 0 distributed copies(1:76.1%, 2:75.9%, 3:75.9%)
peers:    43 seen now



From dbn.lists at gmail.com  Sat Oct 11 17:44:42 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Sat, 11 Oct 2008 10:44:42 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223745999.13589.297.camel@hinge.endoframe.net>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
	<91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>
	<1223745999.13589.297.camel@hinge.endoframe.net>
Message-ID: <91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>

On Sat, Oct 11, 2008 at 10:26 AM, Braden McDaniel <braden at endoframe.com> wrote:
> On Sat, 2008-10-11 at 08:17 -0700, Dan Nicholson wrote:
>>
>> You always need to run autoconf again if you've patched the
>> configure.ac file, or nothing happens. You can run autoreconf locally
>> and add the regenerated configure/aclocal.m4 to your patch, but it
>> will be severely bloated.
>
> There's no reason to patch aclocal.m4 or configure.ac at all.  You only
> need to patch configure.  While that patch is likely to be bigger than a
> patch to configure.ac, calling it "bloated" is a gross exaggeration.

You would need to patch aclocal.m4 if you need to pull in another
external macro.

I said that you should patch configure.ac so that you can actually
send a patch upstream, like a good consumer would do. Patching a
generated file is just a local fix. Would you patch a file generated
by bison or would you patch the .y file? One of those is "the right
way" and one is not.

--
Dan



From opensource at till.name  Sat Oct 11 17:50:25 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 19:50:25 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<1223745999.13589.297.camel@hinge.endoframe.net>
	<91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>
Message-ID: <200810111950.36248.opensource@till.name>

On Sat October 11 2008, Dan Nicholson wrote:

> I said that you should patch configure.ac so that you can actually
> send a patch upstream, like a good consumer would do. Patching a

Afaik, it is best practices to create a patch for upstream agains 
configure.ac, then run autoreconf etc. locally and then create a diff between 
the upstream tarball and the new contents and use this in the spec file, 
which would be a patch agains configure. Then you do not need to run 
autoreconf in rpmbuild.

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/20081011/f0170eac/attachment.sig>

From braden at endoframe.com  Sat Oct 11 18:07:59 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 14:07:59 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
Message-ID: <1223748479.13589.313.camel@hinge.endoframe.net>

When the estimate of "300 broken packages" was tossed out in the libtool
2.2.x thread, I figured there was no way *that* many packages could be
running autoreconf or libtoolize.  But I have been surprised to find no
advice against this practice in Fedora's packaging guidelines; and in
light of that, the number is not quite so incredible.

While forbidding the use of autoreconf (or similar: autoconf, automake,
libtoolize, etc.) in specfiles is probably too extreme, I do think it's
appropriate for the packaging guidelines to point out the pitfalls of
this practice and advise packagers to avoid it where possible.

So what are those pitfalls? By running autoreconf, the RPM build becomes
exposed to different versions of autoconf, automake, and libtool than
were used by the upstream developer to create the upstream source
package.  Newer versions of these tools have the potential to introduce
incompatibilities, breaking the RPM build.  Rather than patching
configure.[ac,in] and Makefile.am, a more resilient approach is to patch
the configure script and Makefile.in files.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From kevin.kofler at chello.at  Sat Oct 11 18:26:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 18:26:10 +0000 (UTC)
Subject: Status of libtool 2.2.X?
References: <48ECE6CC.6030001@cora.nwra.com>
	<1223745999.13589.297.camel@hinge.endoframe.net>
	<91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>
	<200810111950.36248.opensource@till.name>
Message-ID: <loom.20081011T182215-735@post.gmane.org>

Till Maas <opensource <at> till.name> writes:
> Afaik, it is best practices to create a patch for upstream agains 
> configure.ac, then run autoreconf etc. locally and then create a diff between 
> the upstream tarball and the new contents and use this in the spec file, 
> which would be a patch agains configure. Then you do not need to run 
> autoreconf in rpmbuild.

But unless you manage to find the exact same versions of the autotools upstream 
used (which are in general not packaged for Fedora at all), the patch will be 
huge and contain lots of bogus changes due to the autotools version change. For 
example, autoconf often adds support for some exotic target or a workaround for 
some obscure shell's bug from one minor version to the next and that support 
code or workaround gets copied up to dozens of times into the generated 
configure script. Also things like copyright dates and revision numbers appear 
at many places. So a diff for the generated files can be huge even with _no_ 
change to the sources, and the actual change will be hidden in the mess. 
Patches of that kind also have to be regenerated at every single new upstream 
version.

In most cases, patching generated files is a bad idea.

        Kevin Kofler



From braden at endoframe.com  Sat Oct 11 18:14:39 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 14:14:39 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
	<91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>
	<1223745999.13589.297.camel@hinge.endoframe.net>
	<91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>
Message-ID: <1223748879.13589.319.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 10:44 -0700, Dan Nicholson wrote:
> On Sat, Oct 11, 2008 at 10:26 AM, Braden McDaniel <braden at endoframe.com> wrote:
> > On Sat, 2008-10-11 at 08:17 -0700, Dan Nicholson wrote:
> >>
> >> You always need to run autoconf again if you've patched the
> >> configure.ac file, or nothing happens. You can run autoreconf locally
> >> and add the regenerated configure/aclocal.m4 to your patch, but it
> >> will be severely bloated.
> >
> > There's no reason to patch aclocal.m4 or configure.ac at all.  You only
> > need to patch configure.  While that patch is likely to be bigger than a
> > patch to configure.ac, calling it "bloated" is a gross exaggeration.
> 
> You would need to patch aclocal.m4 if you need to pull in another
> external macro.

No, you don't.  You only need to regenerate configure and generate a
patch for *it*.  The normal process of building a package (i.e.,
"configure; make") doesn't use aclocal.m4.  It's only used to regenerate
configure.

> I said that you should patch configure.ac so that you can actually
> send a patch upstream, like a good consumer would do. Patching a
> generated file is just a local fix. Would you patch a file generated
> by bison or would you patch the .y file? One of those is "the right
> way" and one is not.

Yes, but the kind of patches that should be sent upstream are not the
ones resulting in 300 busted packages from a libtool upgrade.  We're
talking about patches applied by a specfile build.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From opensource at till.name  Sat Oct 11 18:31:36 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 20:31:36 +0200
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223748479.13589.313.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
Message-ID: <200810112031.47265.opensource@till.name>

On Sat October 11 2008, Braden McDaniel wrote:
> When the estimate of "300 broken packages" was tossed out in the libtool
> 2.2.x thread, I figured there was no way *that* many packages could be
> running autoreconf or libtoolize.  But I have been surprised to find no
> advice against this practice in Fedora's packaging guidelines; and in
> light of that, the number is not quite so incredible.

There is a draft about this at:
https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

> While forbidding the use of autoreconf (or similar: autoconf, automake,
> libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> appropriate for the packaging guidelines to point out the pitfalls of
> this practice and advise packagers to avoid it where possible.

I have read either in the wiki or on this mailing list, that one should run 
autoreconf locally and create a patch from this, that is then used within the 
spec.

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/20081011/535112f6/attachment.sig>

From kevin.kofler at chello.at  Sat Oct 11 18:32:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 18:32:47 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
Message-ID: <loom.20081011T182618-279@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> Rather than patching configure.[ac,in] and Makefile.am, a more resilient
> approach is to patch the configure script and Makefile.in files.

Patching only the generated files is a hack which cannot be submitted upstream, 
so usually you end up with a patch which touches both source files and 
generated files, and that's a very fragile approach as:
* often you have to run "touch" on generated files which are not affected by 
the source change at all, because otherwise the autotools will try to be 
smarter than you and regenerate everything because not all generated files are 
up to date, and fail if the required autotools for regenerating everything are 
not there, and
* such patches generally have to be copied from the sources to the generated 
files by hand, because (as I explained in the other thread) regenerating them 
generally results in huge patches due to subtle autotools version differences, 
which then fail to apply to new upstream versions.

(This is exactly why generated files in source tarballs are a major PITA and 
the autotools are broken by design.)

        Kevin Kofler



From jonrob at fedoraproject.org  Sat Oct 11 18:42:24 2008
From: jonrob at fedoraproject.org (Jonathan Roberts)
Date: Sat, 11 Oct 2008 19:42:24 +0100
Subject: Clutter 0.6 in F8?
In-Reply-To: <5256d0b0810110438u2fa3dfe9w95cfcbd145972d4@mail.gmail.com>
References: <507738ef0810110402l3e7c4d3an866697e1bc85f3c0@mail.gmail.com>
	<5256d0b0810110438u2fa3dfe9w95cfcbd145972d4@mail.gmail.com>
Message-ID: <507738ef0810111142n1e06d635h8cd3e1f8f9d72d49@mail.gmail.com>

> Has it just been built for F-8 or has it actually been pushed out to
> updates? It will need to be in updates I think to be able to pull it
> in otherwise you could push an update without the proper dependencies
> being available. With F-8 going EOL shortly I have typicalily not been
> pushing new packages out to F-8 and just doing F-9.

It was built for F8 a few months ago...

I'll take your advise though and leave it out for F8.

Cheers,

Jon



From mmcgrath at redhat.com  Sat Oct 11 18:49:57 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 13:49:57 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F0C1CE.30104@BitWagon.com>
References: <48F0C1CE.30104@BitWagon.com>
Message-ID: <alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, John Reiser wrote:

> Young torrents on http://torrent.fedoraproject.org/ spread data too slowly.
> At 0500 UTC on Sat.Oct.11, there was 1 seed and 14 leeches, all at 13% done.
> At 1300 UTC on Sat.Oct.11, there was 1 seed and 31 leeches, all at 55% done.
> This is for F10-Snap1-x86_64-Live.
> I turned my machine off for the night (US PDT), powered on in the morning,
> and within half an hour had caught up to all leeches at 57% done.
> I use tranmsissionbt, and I saw that the seed was sending pieces of 256 KiB
> to me at 2.5 KiB/s, taking almost two minutes per piece (and then "pausing.")
>
> It seems to me that torrent.fedoraproject.org is overloaded, and that a change
> in policy would give sooner completion to everybody, even without more
> resources.

I wouldn't say overloaded.  Throttled is the right word, and we do have it
throttled.  Although even throttled on one machine I was able to download
the latest live beta in roughly 10 minutes on my slicehost.com host, and
closer to 9 hours on my workstation at home.  Its always difficult to tell
where the slowness happens but I suspect in my slow case it was because my
ISP was limiting my traffic and slicehost.com was not.

	-Mike



From alsadi at gmail.com  Sat Oct 11 19:17:04 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sat, 11 Oct 2008 22:17:04 +0300
Subject: default XFCE layout
Message-ID: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>

after some talk with nirik ( who maintain many xfce4 but not like
xfce-panel which is responsible on the layout) he suggested
nirik: I would say post to the dev list and suggest your layout and
ask if there has been thought to the default layout for 4.6 and see if
they have further ideas?

my suggestion is to take in consideration that xfce users usually have
less ram, less resolution because XFCE is light yet feature full

I suggest having only one panel
which have
menu
some launchers
separator
window list (taskbar)
workspace switcher in two rows to save space
systray
clock
volume mixer

here is a screen shot
http://img353.imageshack.us/my.php?image=xfce4layoutck3.png



From braden at endoframe.com  Sat Oct 11 19:18:33 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 15:18:33 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <200810112031.47265.opensource@till.name>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
Message-ID: <1223752713.13589.330.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 20:31 +0200, Till Maas wrote:
> On Sat October 11 2008, Braden McDaniel wrote:
> > When the estimate of "300 broken packages" was tossed out in the libtool
> > 2.2.x thread, I figured there was no way *that* many packages could be
> > running autoreconf or libtoolize.  But I have been surprised to find no
> > advice against this practice in Fedora's packaging guidelines; and in
> > light of that, the number is not quite so incredible.
> 
> There is a draft about this at:
> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

Thanks. I've edited this a bit to include references to libtoolize. I'd
be happy to help move this forward. What's required?

> > While forbidding the use of autoreconf (or similar: autoconf, automake,
> > libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> > appropriate for the packaging guidelines to point out the pitfalls of
> > this practice and advise packagers to avoid it where possible.
> 
> I have read either in the wiki or on this mailing list, that one should run 
> autoreconf locally and create a patch from this, that is then used within the 
> spec.

That is, generally, the right idea.  However, autoreconf is a bit of a
sledgehammer and can result in a patch that is larger than necessary.
The only files that should need patching are configure and Makefile.in.
autoconf will produce the former, and automake the latter.  It is more
unusual, but possible, that ltmain.sh might need patching.  libtoolize
can be used to generate a patch in that case.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From selinux at gmail.com  Sat Oct 11 19:19:17 2008
From: selinux at gmail.com (Tom London)
Date: Sat, 11 Oct 2008 12:19:17 -0700
Subject: Heads up on ext4 changes
In-Reply-To: <48EFA88F.7000105@redhat.com>
References: <48EE016E.8050407@redhat.com> <48EF9E81.4020403@redhat.com>
	<48EFA88F.7000105@redhat.com>
Message-ID: <4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>

On Fri, Oct 10, 2008 at 12:10 PM, Eric Sandeen <sandeen at redhat.com> wrote:
> Eric Sandeen wrote:
>
>> Changing /etc/fstab to list "ext4" for the root fs may be enough, do it
>> before you install the new kernel.
>
> On further reflection, you will probably just have to do this.
>
> -Eric
>
>> notting suggested a module alias to ext4dev in the ext4.ko module
>> itself, that sounds like a good plan and as long as it gets upstream
>> I'll commit it to Fedora shortly, and I think that should make it all
>> seamless.
>
>
I have an 'ext4' FS on a USB hard drive.  When I plug this in, I get a
"Cannot mount volume" popup:

The volume 'Backup1' uses the ext4dev file system which is not
supported by your system, followed by a dbus-type failure error
message about a minute later.

This just me, or what additional changes are needed?

tom
-- 
Tom London



From cra at WPI.EDU  Sat Oct 11 19:19:41 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 15:19:41 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
Message-ID: <20081011191941.GJ10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 01:49:57PM -0500, Mike McGrath wrote:
> On Sat, 11 Oct 2008, John Reiser wrote:
> 
> > Young torrents on http://torrent.fedoraproject.org/ spread data too slowly.
> > At 0500 UTC on Sat.Oct.11, there was 1 seed and 14 leeches, all at 13% done.
> > At 1300 UTC on Sat.Oct.11, there was 1 seed and 31 leeches, all at 55% done.
> > This is for F10-Snap1-x86_64-Live.
> > I turned my machine off for the night (US PDT), powered on in the morning,
> > and within half an hour had caught up to all leeches at 57% done.
> > I use tranmsissionbt, and I saw that the seed was sending pieces of 256 KiB
> > to me at 2.5 KiB/s, taking almost two minutes per piece (and then "pausing.")
> >
> > It seems to me that torrent.fedoraproject.org is overloaded, and that a change
> > in policy would give sooner completion to everybody, even without more
> > resources.
> 
> I wouldn't say overloaded.  Throttled is the right word, and we do have it
> throttled.  Although even throttled on one machine I was able to download
> the latest live beta in roughly 10 minutes on my slicehost.com host, and
> closer to 9 hours on my workstation at home.  Its always difficult to tell
> where the slowness happens but I suspect in my slow case it was because my
> ISP was limiting my traffic and slicehost.com was not.

I'm on multiple gig links, unrestricted, and it is taking an eternity 
to download the Snap1 images.



From opensource at till.name  Sat Oct 11 19:25:11 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 21:25:11 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <loom.20081011T182215-735@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<200810111950.36248.opensource@till.name>
	<loom.20081011T182215-735@post.gmane.org>
Message-ID: <200810112125.17757.opensource@till.name>

On Sat October 11 2008, Kevin Kofler wrote:
> Till Maas <opensource <at> till.name> writes:
> > Afaik, it is best practices to create a patch for upstream agains
> > configure.ac, then run autoreconf etc. locally and then create a diff
> > between the upstream tarball and the new contents and use this in the
> > spec file, which would be a patch agains configure. Then you do not need
> > to run autoreconf in rpmbuild.
>
> But unless you manage to find the exact same versions of the autotools
> upstream used (which are in general not packaged for Fedora at all), the
> patch will be huge and contain lots of bogus changes due to the autotools
> version change. For example, autoconf often adds support for some exotic
> target or a workaround for some obscure shell's bug from one minor version
> to the next and that support code or workaround gets copied up to dozens of
> times into the generated configure script. Also things like copyright dates
> and revision numbers appear at many places. So a diff for the generated
> files can be huge even with _no_ change to the sources, and the actual
> change will be hidden in the mess. Patches of that kind also have to be
> regenerated at every single new upstream version.
>
> In most cases, patching generated files is a bad idea.

I do not understand, why the huge changes are a big problem. The massive 
amount of changes is how autotools work. The "hidden change" can imho be 
better seen in the patch to the autotools input files, which still exists. 
Also in case upstream is not dead and is still providing new versions, the 
upstreamed patch should be in the next released version, so you do not have 
to regenerate the patch.

In case there is a demand to recreate the patch often, we could add a helper 
target (prepare-patch) to Makefile.common that does:

find -type f \! -regex ".*\\.configure.in$" -exec bash -c 'test -f 
{}.configure.in || cp -a {} {}.configure.in' \;

For the case the patch is called foo-1.2.3-configure.in.patch
Then you can run

make prep prepare-patch SUFFIX=configure.in
cd foo-1.2.3 && autoreconf
make patch SUFFIX=configure.in

To update the patch. To get rid of the bogus diff lines from the patch, you 
can add another
make prep patch SUFFIX=configure.in
after this.

If you want to keep some head in the patch, you can also use rediff instead of 
patch btw.

To make it even more easier, we could add a target, that does all the above 
and asumes that there is a script in the branch dir, that is called 
autogen.sh and does all the stuff that is used to run autoreconf and the 
patch should use the suffix autogen-patch, so you only need to run

make autogen-patch or all is done automagically.

Thinking of it, I will add the prepare-patch at least to my .cvspksrc, because 
it makes running make patch a lot simplier.

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/20081011/0938997f/attachment.sig>

From opensource at till.name  Sat Oct 11 19:35:16 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 21:35:16 +0200
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223752713.13589.330.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
Message-ID: <200810112135.17556.opensource@till.name>

On Sat October 11 2008, Braden McDaniel wrote:
> On Sat, 2008-10-11 at 20:31 +0200, Till Maas wrote:
> > On Sat October 11 2008, Braden McDaniel wrote:
> > > When the estimate of "300 broken packages" was tossed out in the
> > > libtool 2.2.x thread, I figured there was no way *that* many packages
> > > could be running autoreconf or libtoolize.  But I have been surprised
> > > to find no advice against this practice in Fedora's packaging
> > > guidelines; and in light of that, the number is not quite so
> > > incredible.
> >
> > There is a draft about this at:
> > https://fedoraproject.org/wiki/PackagingDrafts/AutoConf
>
> Thanks. I've edited this a bit to include references to libtoolize. I'd
> be happy to help move this forward. What's required?

You have to write an e-mail to the fedora packaging commitee and discuss it 
with them:
https://www.redhat.com/mailman/listinfo/fedora-packaging

> > > While forbidding the use of autoreconf (or similar: autoconf, automake,
> > > libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> > > appropriate for the packaging guidelines to point out the pitfalls of
> > > this practice and advise packagers to avoid it where possible.
> >
> > I have read either in the wiki or on this mailing list, that one should
> > run autoreconf locally and create a patch from this, that is then used
> > within the spec.
>
> That is, generally, the right idea.  However, autoreconf is a bit of a
> sledgehammer and can result in a patch that is larger than necessary.
> The only files that should need patching are configure and Makefile.in.
> autoconf will produce the former, and automake the latter.  It is more
> unusual, but possible, that ltmain.sh might need patching.  libtoolize
> can be used to generate a patch in that case.

So the one would run autoreconf, but only create a patch for configure, 
Makefile.in and ltmain.sh? Or should only automake and autoconf be run in the 
normal case and then the diff is the patch?
Maybe you can add whatever should be done to the AutoConf wiki page.

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/20081011/8e189b34/attachment.sig>

From sgrubb at redhat.com  Sat Oct 11 19:43:20 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 11 Oct 2008 15:43:20 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223752713.13589.330.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
Message-ID: <200810111543.21186.sgrubb@redhat.com>

On Saturday 11 October 2008 15:18:33 Braden McDaniel wrote:
> That is, generally, the right idea. ?However, autoreconf is a bit of a
> sledgehammer and can result in a patch that is larger than necessary.
> The only files that should need patching are configure and Makefile.in.
> autoconf will produce the former, and automake the latter.

There's been a number of occasions where I patch Makefile.am because its a 1 
liner and patching Makefile.in makes a very ugly patch that becomes harder to 
read. Examples of this is adding files to be compiled in, removing files to 
be compiled in, or making something optional for a configure flag. So, if you 
know what you are doing, its fine to patch configure.ac or Makefile.am.

On the otherhand...there are also a number of projects that use libmissing. We 
do not carry that in Fedora. That means that any project using libmissing, 
you always have to patch Makefile.in and not Makefile.am since autoreconf 
won't be able to find the m4 macros for gnulib. We should probably carry 
gnulib sooner or later.

-Steve



From smooge at gmail.com  Sat Oct 11 19:49:20 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sat, 11 Oct 2008 13:49:20 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223744133.3327.11.camel@luminos.localdomain>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com> <70s4s5x57i.ln2@ppp1053.in.ipex.cz>
	<48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
Message-ID: <80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>

2008/10/11 Jesse Keating <jkeating at redhat.com>:
> On Sat, 2008-10-11 at 04:06 -0500, Les Mikesell wrote:
>>
>> There's no lead time for your own local development and testing.  You
>> would never expect one of the old RH X.0 releases to be production-ready
>> but the new releases would have new kernels, libraries, and utilities so
>> you could incorporate their features in your own work, which was likely
>> to proceed at approximately the same rate as the distro evolved toward
>> stability.  With Centos you don't get anything to work with and test
>> ahead of time, and if you'd tested on an earlier Fedora there may or may
>> not be any relationship.  A side effect was that the community of RH
>> users that reported/fixed bugs in the X.0 got something for their effort
>> in being able to continue using the updated release instead of being
>> abandoned as a wildly new X.0 came out.
>
> CentOS should be putting out betas that match the RHEL betas so that you
> can get access to it before the release.  Use Fedora as the technology
> driver, use Betas as the bugfix cleanup for platform issues, and
> eventually you get the "Enterprise" release.
>

I think the major problem with CentOS putting out beta's in a timely
basis is that a large amount of time is getting the build resources
together AND then deciphering various build variables that RHEL uses
so that the CentOS binaries 'match' close enough to be bug for bug
compatible. The time to do that basically had a CentOS-5beta out at
the time that RHEL-5 is finalized.





-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From selinux at gmail.com  Sat Oct 11 19:50:06 2008
From: selinux at gmail.com (Tom London)
Date: Sat, 11 Oct 2008 12:50:06 -0700
Subject: Heads up on ext4 changes
In-Reply-To: <4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>
References: <48EE016E.8050407@redhat.com> <48EF9E81.4020403@redhat.com>
	<48EFA88F.7000105@redhat.com>
	<4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>
Message-ID: <4c4ba1530810111250g3cce50car72d251623c8e4b16@mail.gmail.com>

On Sat, Oct 11, 2008 at 12:19 PM, Tom London <selinux at gmail.com> wrote:
> On Fri, Oct 10, 2008 at 12:10 PM, Eric Sandeen <sandeen at redhat.com> wrote:
>> Eric Sandeen wrote:
>>
>>> Changing /etc/fstab to list "ext4" for the root fs may be enough, do it
>>> before you install the new kernel.
>>
>> On further reflection, you will probably just have to do this.
>>
>> -Eric
>>
>>> notting suggested a module alias to ext4dev in the ext4.ko module
>>> itself, that sounds like a good plan and as long as it gets upstream
>>> I'll commit it to Fedora shortly, and I think that should make it all
>>> seamless.
>>
>>
> I have an 'ext4' FS on a USB hard drive.  When I plug this in, I get a
> "Cannot mount volume" popup:
>
> The volume 'Backup1' uses the ext4dev file system which is not
> supported by your system, followed by a dbus-type failure error
> message about a minute later.
>
> This just me, or what additional changes are needed?
>
> tom
> --
Well, the "--fstype" option to gnome-mount works for manual command:
    "gnome-mount -d /dev/sdb1 --fstype ext4"

So I'm not road blocked.  The "plug and play" auto mounting doesn't work though.

tom
-- 
Tom London



From luya_tfz at thefinalzone.com  Sat Oct 11 20:04:01 2008
From: luya_tfz at thefinalzone.com (Luya Tshimbalanga)
Date: Sat, 11 Oct 2008 16:04:01 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<70s4s5x57i.ln2@ppp1053.in.ipex.cz> <48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
	<80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
Message-ID: <1223755441.48f106b15e44e@ssl.mecca.ca>

Comment,
Wikipedia - Goodbye Red Hat and Fedora -> At least it is not a farewell

Moving to Ubuntu LTS  might not be helpful at long term. The big issue is Ubuntu
LTS was created by Canonical for making money as aiming by Mark Shuttleworth
himself. Canonical as company is not profitable yet since its inception. It
appears more a publicity stunt rather than technical issue because CentOS fill
the gap between Red Hat and Fedora. My main corner is how much Canonical is
giving back to the community, most of time, they try to credit themselves on
something they improve from others.

This is only my opinion which does not necessarily represents the whole
community view.

-- 
Luya Tshimbalanga
Fedora Project contributor
http://www.fedoraproject.org/wiki/LuyaTshimbalanga



From opensource at till.name  Sat Oct 11 20:03:31 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 22:03:31 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
Message-ID: <200810112203.45142.opensource@till.name>

On Sat October 11 2008, Mike McGrath wrote:

> I wouldn't say overloaded.  Throttled is the right word, and we do have it
> throttled.  Although even throttled on one machine I was able to download
> the latest live beta in roughly 10 minutes on my slicehost.com host, and
> closer to 9 hours on my workstation at home.  Its always difficult to tell
> where the slowness happens but I suspect in my slow case it was because my
> ISP was limiting my traffic and slicehost.com was not.

For me surely torrent1.fedoraproject.org is the bottleneck, because it only 
seeds at around 0.2 KB/s and is the only seed at all. Something is strange, 
because given the time the torrent is already online, there should be several 
other seeds, but nearly all peers have the same percentage of the files, so 
they redistribute whatever they got, but nobody gets the missing chunks 
reasonable fast to redistribute them.

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/20081011/6f53dad5/attachment.sig>

From kevin.kofler at chello.at  Sat Oct 11 20:09:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 11 Oct 2008 20:09:04 +0000 (UTC)
Subject: Status of libtool 2.2.X?
References: <48ECE6CC.6030001@cora.nwra.com>
	<200810111950.36248.opensource@till.name>
	<loom.20081011T182215-735@post.gmane.org>
	<200810112125.17757.opensource@till.name>
Message-ID: <loom.20081011T195752-54@post.gmane.org>

Till Maas <opensource <at> till.name> writes:
> I do not understand, why the huge changes are a big problem. The massive 
> amount of changes is how autotools work. The "hidden change" can imho be 
> better seen in the patch to the autotools input files, which still exists. 
> Also in case upstream is not dead and is still providing new versions, the 
> upstreamed patch should be in the next released version, so you do not have 
> to regenerate the patch.

Maybe in an ideal world, but here in the real world, not all patches get 
upstreamed immediately in the next release, and unless this is a large 
organized project like GCC which enforces very precise autotools versions, the 
next release will often have used different autotools versions (either because 
a different developer (often using a different distribution) generated the 
autotools files or because the maintainer upgraded his autotools, which happens 
often if they're using e.g. Debian unstable (also if they use Fedora, but in 
that case, you have at least some hope of hitting the same autotools versions 
they used)) and so a patch containing lots of bogus changes (i.e. differences 
completely unrelated to your actual modifications) will almost certainly fail 
to apply.
 
> In case there is a demand to recreate the patch often, we could add a helper 
> target (prepare-patch) to Makefile.common that does: [...]

And this is a really complex solution with lots of manual work for the 
maintainer to do at each upstream release (your proposed Makefile.common 
snippets only automate small parts of it, which are just basic diff and patch 
invocations anyway), you didn't even list all of them (for example, the source 
tarball has to be extracted to rediff a patch).

So I don't get at all how you can think that this compares in simplicitly with:
BuildRequires: autoconf automake libtool
[and in the %prep section]
autoreconf

        Kevin Kofler



From smooge at gmail.com  Sat Oct 11 20:13:25 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sat, 11 Oct 2008 14:13:25 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223704398.3564.1316.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<1223704398.3564.1316.camel@beck.corsepiu.local>
Message-ID: <80d7e4090810111313t3f09d38avff8b11bc743f1a08@mail.gmail.com>

On Fri, Oct 10, 2008 at 11:53 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:

> Sigh, I repeatedly have been trying to do something, but always the same
> "Fedora chiefs" had machine-gunned almost each and every proposal.
>

If I am somehow a chief.. no-one has ever told me. On the other hand,
I do have a lack of patience and a lack of trying to see if there is a
way to work towards Win/Win.

> You know, you have been one of these - Do I really have to be more
> direct?
>

Actually I think you are too direct. You seem to have been
disappointed with how Fedora's leadership has gone, and never seem to
avoid a situation to remind people that. You complain about too much
bueracracy and lack of democracy, but your alternatives seem to be
communicated always as "do as a I say"  without compromise.

I know there is a void between us because English and email is not the
easiest language to communicate ideas with. How can we bridge it?

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From cra at WPI.EDU  Sat Oct 11 20:19:31 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 16:19:31 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <200810112203.45142.opensource@till.name>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
Message-ID: <20081011201931.GK10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 10:03:31PM +0200, Till Maas wrote:
> On Sat October 11 2008, Mike McGrath wrote:
> 
> > I wouldn't say overloaded.  Throttled is the right word, and we do have it
> > throttled.  Although even throttled on one machine I was able to download
> > the latest live beta in roughly 10 minutes on my slicehost.com host, and
> > closer to 9 hours on my workstation at home.  Its always difficult to tell
> > where the slowness happens but I suspect in my slow case it was because my
> > ISP was limiting my traffic and slicehost.com was not.
> 
> For me surely torrent1.fedoraproject.org is the bottleneck, because it only 
> seeds at around 0.2 KB/s and is the only seed at all. Something is strange, 
> because given the time the torrent is already online, there should be several 
> other seeds, but nearly all peers have the same percentage of the files, so 
> they redistribute whatever they got, but nobody gets the missing chunks 
> reasonable fast to redistribute them.

Yes, it seems like the seeder isn't handing out "random enough" chunks 
of the file to various clients--like all the clients have to go back 
to the single seeder for the missing chunks instead of getting them 
from other clients.  I would think there should be at least one 
distributed copy by now, but my client says there are 0 (not even 
fractional distributed copies...).

I'm using "bittorrent-curses".  I increased my max_upload_rate to 600 
KB/sec (is that bits or bytes by the way?) and enabled UDP 6881-6889 
through the host's firewall (in addition to TCP 6881-6889) since I 
hadn't realized that UDP is used now.



From mmcgrath at redhat.com  Sat Oct 11 20:22:01 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 15:22:01 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <20081011191941.GJ10204@angus.ind.WPI.EDU>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<20081011191941.GJ10204@angus.ind.WPI.EDU>
Message-ID: <alpine.LFD.1.10.0810111521090.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Chuck Anderson wrote:

> On Sat, Oct 11, 2008 at 01:49:57PM -0500, Mike McGrath wrote:
> > On Sat, 11 Oct 2008, John Reiser wrote:
> >
> > > Young torrents on http://torrent.fedoraproject.org/ spread data too slowly.
> > > At 0500 UTC on Sat.Oct.11, there was 1 seed and 14 leeches, all at 13% done.
> > > At 1300 UTC on Sat.Oct.11, there was 1 seed and 31 leeches, all at 55% done.
> > > This is for F10-Snap1-x86_64-Live.
> > > I turned my machine off for the night (US PDT), powered on in the morning,
> > > and within half an hour had caught up to all leeches at 57% done.
> > > I use tranmsissionbt, and I saw that the seed was sending pieces of 256 KiB
> > > to me at 2.5 KiB/s, taking almost two minutes per piece (and then "pausing.")
> > >
> > > It seems to me that torrent.fedoraproject.org is overloaded, and that a change
> > > in policy would give sooner completion to everybody, even without more
> > > resources.
> >
> > I wouldn't say overloaded.  Throttled is the right word, and we do have it
> > throttled.  Although even throttled on one machine I was able to download
> > the latest live beta in roughly 10 minutes on my slicehost.com host, and
> > closer to 9 hours on my workstation at home.  Its always difficult to tell
> > where the slowness happens but I suspect in my slow case it was because my
> > ISP was limiting my traffic and slicehost.com was not.
>
> I'm on multiple gig links, unrestricted, and it is taking an eternity
> to download the Snap1 images.
>

Seriously, this is a devel list, not an end-user list.  Quantitative
values will get taken seriously, "eternity" won't unless you're actually
telling me they're failing to download.

	-Mike



From ralph+fedora at strg-alt-entf.org  Sat Oct 11 20:21:47 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Sat, 11 Oct 2008 22:21:47 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<70s4s5x57i.ln2@ppp1053.in.ipex.cz> <48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
	<80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
Message-ID: <20081011202146.GG2305@br-online.de>

Stephen John Smoogen wrote:
> 2008/10/11 Jesse Keating <jkeating at redhat.com>:
>> CentOS should be putting out betas that match the RHEL betas so that you
>> can get access to it before the release.  Use Fedora as the technology
>> driver, use Betas as the bugfix cleanup for platform issues, and
>> eventually you get the "Enterprise" release.
> 
> I think the major problem with CentOS putting out beta's in a timely
> basis is that a large amount of time is getting the build resources
> together AND then deciphering various build variables that RHEL uses
> so that the CentOS binaries 'match' close enough to be bug for bug
> compatible. The time to do that basically had a CentOS-5beta out at
> the time that RHEL-5 is finalized.

Not having publicly available SRPMs for the beta versions (meaning 
available via public ftp) might be another reason. 

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/1717f9fc/attachment.sig>

From denis at poolshark.org  Sat Oct 11 20:14:13 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 11 Oct 2008 22:14:13 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <200810112203.45142.opensource@till.name>
References: <48F0C1CE.30104@BitWagon.com>	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
Message-ID: <48F10915.4060704@poolshark.org>

Till Maas wrote:
> For me surely torrent1.fedoraproject.org is the bottleneck, because it only 
> seeds at around 0.2 KB/s and is the only seed at all. Something is strange, 
> because given the time the torrent is already online, there should be several 
> other seeds, but nearly all peers have the same percentage of the files, so 
> they redistribute whatever they got, but nobody gets the missing chunks 
> reasonable fast to redistribute them.

Exactly the same thing here. Somebody kicks that bitorrent server...



From mmcgrath at redhat.com  Sat Oct 11 20:31:19 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 15:31:19 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <200810112203.45142.opensource@till.name>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
Message-ID: <alpine.LFD.1.10.0810111523330.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Till Maas wrote:

> On Sat October 11 2008, Mike McGrath wrote:
>
> > I wouldn't say overloaded.  Throttled is the right word, and we do have it
> > throttled.  Although even throttled on one machine I was able to download
> > the latest live beta in roughly 10 minutes on my slicehost.com host, and
> > closer to 9 hours on my workstation at home.  Its always difficult to tell
> > where the slowness happens but I suspect in my slow case it was because my
> > ISP was limiting my traffic and slicehost.com was not.
>
> For me surely torrent1.fedoraproject.org is the bottleneck, because it only
> seeds at around 0.2 KB/s and is the only seed at all. Something is strange,
> because given the time the torrent is already online, there should be several
> other seeds, but nearly all peers have the same percentage of the files, so
> they redistribute whatever they got, but nobody gets the missing chunks
> reasonable fast to redistribute them.
>

Thus the theory of torrent.  Things that are popular will download
quickly, things that aren't won't.  Seems to match well with community if
you ask me.

I just downloaded:

http://torrent.fedoraproject.org/torrents//F10-Snap1-x86_64-Live.torrent

It took just over 6 minutes and my top speed was 2037.3 KB/s  I might
suggest that different places have different rules wrt torrent and qos,
firewalls and other setups can affect torrent preformance.

	-Mike



From mmcgrath at redhat.com  Sat Oct 11 20:32:26 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 15:32:26 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F10915.4060704@poolshark.org>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
	<48F10915.4060704@poolshark.org>
Message-ID: <alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Denis Leroy wrote:

> Till Maas wrote:
> > For me surely torrent1.fedoraproject.org is the bottleneck, because it only
> > seeds at around 0.2 KB/s and is the only seed at all. Something is strange,
> > because given the time the torrent is already online, there should be
> > several other seeds, but nearly all peers have the same percentage of the
> > files, so they redistribute whatever they got, but nobody gets the missing
> > chunks reasonable fast to redistribute them.
>
> Exactly the same thing here. Somebody kicks that bitorrent server...
>

What speeds do you get from other bittorrent servers?

	-Mike



From opensource at till.name  Sat Oct 11 20:30:35 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 22:30:35 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111521090.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>
	<20081011191941.GJ10204@angus.ind.WPI.EDU>
	<alpine.LFD.1.10.0810111521090.25949@laptop.mmcgrath.net>
Message-ID: <200810112230.45782.opensource@till.name>

On Sat October 11 2008, Mike McGrath wrote:

> Seriously, this is a devel list, not an end-user list.  Quantitative
> values will get taken seriously, "eternity" won't unless you're actually
> telling me they're failing to download.

Eternity is quite right, because here rtorrent osscilates between downloading 
a little at with little speed and not getting any new chunks at all. Then it 
also does not display any estimated time to complete it.

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/20081011/5c2a9783/attachment.sig>

From mmcgrath at redhat.com  Sat Oct 11 20:36:37 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 15:36:37 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <200810112230.45782.opensource@till.name>
References: <48F0C1CE.30104@BitWagon.com>
	<20081011191941.GJ10204@angus.ind.WPI.EDU>
	<alpine.LFD.1.10.0810111521090.25949@laptop.mmcgrath.net>
	<200810112230.45782.opensource@till.name>
Message-ID: <alpine.LFD.1.10.0810111536000.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Till Maas wrote:

> On Sat October 11 2008, Mike McGrath wrote:
>
> > Seriously, this is a devel list, not an end-user list.  Quantitative
> > values will get taken seriously, "eternity" won't unless you're actually
> > telling me they're failing to download.
>
> Eternity is quite right, because here rtorrent osscilates between downloading
> a little at with little speed and not getting any new chunks at all. Then it
> also does not display any estimated time to complete it.
>

rtorrent is what I used, and it took about 6 minutes.  What speeds do you
get with other torrent servers?

	-Mike



From cra at WPI.EDU  Sat Oct 11 20:38:56 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 16:38:56 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111521090.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<20081011191941.GJ10204@angus.ind.WPI.EDU>
	<alpine.LFD.1.10.0810111521090.25949@laptop.mmcgrath.net>
Message-ID: <20081011203856.GL10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 03:22:01PM -0500, Mike McGrath wrote:
> > I'm on multiple gig links, unrestricted, and it is taking an eternity
> > to download the Snap1 images.
> 
> Seriously, this is a devel list, not an end-user list.  Quantitative
> values will get taken seriously, "eternity" won't unless you're actually
> telling me they're failing to download.

I've already posted rates, but here is an updated list.  While the 
ETAs below indicate 5-6 hours, in reality the ETAs aren't very 
accurate.  In many cases the ETAs are going up.

File				Size	  Download  Upload
--------------------------	-------- --------- ---------
F10-Snap1-i686-Live		686.3MiB  5.8KiB/s  1.7KiB/s
(70.5%) ETA in 6:14:50 - 23 peers 1 seeds 0 dist copies - 4.0MiB dn 5.7MiB up 

F10-Snap1-x86_64-Live		692.2MiB  6.3KiB/s  8.8KiB/s 
(86.8%) ETA in 5:39:08 - 36 peers 1 seeds 0 dist copies - 1.9MiB dn 32.6MiB up

F10-Snap1-i686-Live-KDE		694.5MiB  9.4KiB/s 27.7KiB/s
(71.2%) ETA in 5:47:44 - 11 peers 1 seeds 0 dist copies - 4.0MiB dn 8.1MiB up 

F10-Snap1-x86_64-Live-KDE	700.7MiB  5.1KiB/s 79.8KiB/s
(87.9%) ETA in 2:18:06 - 12 peers 0 seeds 0 dist copies - 4.5MiB dn 10.1MiB up 

It is interesting that the last one now has 0 seeds.  Did the seeder 
crash?



From denis at poolshark.org  Sat Oct 11 20:39:23 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 11 Oct 2008 22:39:23 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>	<200810112203.45142.opensource@till.name>	<48F10915.4060704@poolshark.org>
	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>
Message-ID: <48F10EFB.2020000@poolshark.org>

Mike McGrath wrote:
> On Sat, 11 Oct 2008, Denis Leroy wrote:
> 
>> Till Maas wrote:
>>> For me surely torrent1.fedoraproject.org is the bottleneck, because it only
>>> seeds at around 0.2 KB/s and is the only seed at all. Something is strange,
>>> because given the time the torrent is already online, there should be
>>> several other seeds, but nearly all peers have the same percentage of the
>>> files, so they redistribute whatever they got, but nobody gets the missing
>>> chunks reasonable fast to redistribute them.
>> Exactly the same thing here. Somebody kicks that bitorrent server...
>>
> 
> What speeds do you get from other bittorrent servers?

No something's wrong, I'm downloading from between 0 and 2 peers, out of 
40. This is not how bittorrent normally works. I'm getting 1 or 2 kb/s 
per second.



From smooge at gmail.com  Sat Oct 11 20:40:01 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sat, 11 Oct 2008 14:40:01 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081011202146.GG2305@br-online.de>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com> <70s4s5x57i.ln2@ppp1053.in.ipex.cz>
	<48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
	<80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
	<20081011202146.GG2305@br-online.de>
Message-ID: <80d7e4090810111340u2b2a2dd9j470e50c75d73ea0b@mail.gmail.com>

2008/10/11 Ralph Angenendt <ralph+fedora at strg-alt-entf.org>:
> Stephen John Smoogen wrote:
>> 2008/10/11 Jesse Keating <jkeating at redhat.com>:
>>> CentOS should be putting out betas that match the RHEL betas so that you
>>> can get access to it before the release.  Use Fedora as the technology
>>> driver, use Betas as the bugfix cleanup for platform issues, and
>>> eventually you get the "Enterprise" release.
>>
>> I think the major problem with CentOS putting out beta's in a timely
>> basis is that a large amount of time is getting the build resources
>> together AND then deciphering various build variables that RHEL uses
>> so that the CentOS binaries 'match' close enough to be bug for bug
>> compatible. The time to do that basically had a CentOS-5beta out at
>> the time that RHEL-5 is finalized.
>
> Not having publicly available SRPMs for the beta versions (meaning
> available via public ftp) might be another reason.

I thought the SRPMS were available, as Scientific Linux uses the
public ones to build their Betas.

I thought it was more a level of priority. CentOS is a volunteer
project with a lot of costs shouldered by the developers. There is
usually a shortage of diskspace, slow net links to various build
machines spread around the world, the fact that various devs have full
time jobs (there is no full-time build manager like Fedora and SciLin
have), and various other items. Any of which puts making betas a lower
priority than dealing with current issues.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From mmcgrath at redhat.com  Sat Oct 11 20:44:29 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 15:44:29 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F10EFB.2020000@poolshark.org>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
	<48F10915.4060704@poolshark.org>
	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>
	<48F10EFB.2020000@poolshark.org>
Message-ID: <alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Denis Leroy wrote:

> Mike McGrath wrote:
> > On Sat, 11 Oct 2008, Denis Leroy wrote:
> >
> > > Till Maas wrote:
> > > > For me surely torrent1.fedoraproject.org is the bottleneck, because it
> > > > only
> > > > seeds at around 0.2 KB/s and is the only seed at all. Something is
> > > > strange,
> > > > because given the time the torrent is already online, there should be
> > > > several other seeds, but nearly all peers have the same percentage of
> > > > the
> > > > files, so they redistribute whatever they got, but nobody gets the
> > > > missing
> > > > chunks reasonable fast to redistribute them.
> > > Exactly the same thing here. Somebody kicks that bitorrent server...
> > >
> >
> > What speeds do you get from other bittorrent servers?
>
> No something's wrong, I'm downloading from between 0 and 2 peers, out of 40.
> This is not how bittorrent normally works. I'm getting 1 or 2 kb/s per second.
>

I'm not saying something isn't wrong.  I'm saying I'm not seeing it and if
I can't see it I don't know how I'm going to fix it.  Can anyone give me
speeds for any other torrent besides ours?

	-Mike



From denis at poolshark.org  Sat Oct 11 20:50:12 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 11 Oct 2008 22:50:12 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>	<200810112203.45142.opensource@till.name>	<48F10915.4060704@poolshark.org>	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>	<48F10EFB.2020000@poolshark.org>
	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>
Message-ID: <48F11184.6070004@poolshark.org>

Mike McGrath wrote:
> I'm not saying something isn't wrong.  I'm saying I'm not seeing it and if
> I can't see it I don't know how I'm going to fix it.  Can anyone give me
> speeds for any other torrent besides ours?

Well I just added the Fedora 9 i686 live CD for comparison, I'm getting 
1.0 MBytes per second.



From pemboa at gmail.com  Sat Oct 11 20:51:42 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sat, 11 Oct 2008 15:51:42 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810111340u2b2a2dd9j470e50c75d73ea0b@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com> <70s4s5x57i.ln2@ppp1053.in.ipex.cz>
	<48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
	<80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
	<20081011202146.GG2305@br-online.de>
	<80d7e4090810111340u2b2a2dd9j470e50c75d73ea0b@mail.gmail.com>
Message-ID: <16de708d0810111351w6715b3b5ub020c5c0e7e2e917@mail.gmail.com>

On Sat, Oct 11, 2008 at 3:40 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
> 2008/10/11 Ralph Angenendt <ralph+fedora at strg-alt-entf.org>:
>> Stephen John Smoogen wrote:
>>> 2008/10/11 Jesse Keating <jkeating at redhat.com>:
>>>> CentOS should be putting out betas that match the RHEL betas so that you
>>>> can get access to it before the release.  Use Fedora as the technology
>>>> driver, use Betas as the bugfix cleanup for platform issues, and
>>>> eventually you get the "Enterprise" release.
>>>
>>> I think the major problem with CentOS putting out beta's in a timely
>>> basis is that a large amount of time is getting the build resources
>>> together AND then deciphering various build variables that RHEL uses
>>> so that the CentOS binaries 'match' close enough to be bug for bug
>>> compatible. The time to do that basically had a CentOS-5beta out at
>>> the time that RHEL-5 is finalized.
>>
>> Not having publicly available SRPMs for the beta versions (meaning
>> available via public ftp) might be another reason.
>
> I thought the SRPMS were available, as Scientific Linux uses the
> public ones to build their Betas.
>
> I thought it was more a level of priority. CentOS is a volunteer
> project with a lot of costs shouldered by the developers. There is
> usually a shortage of diskspace, slow net links to various build
> machines spread around the world, the fact that various devs have full
> time jobs (there is no full-time build manager like Fedora and SciLin
> have), and various other items. Any of which puts making betas a lower
> priority than dealing with current issues.


For those who can and may have not noticed the link before:
http://www.centos.org/modules/tinycontent/index.php?id=23


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From mmcgrath at redhat.com  Sat Oct 11 20:53:02 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 15:53:02 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F11184.6070004@poolshark.org>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
	<48F10915.4060704@poolshark.org>
	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>
	<48F10EFB.2020000@poolshark.org>
	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>
	<48F11184.6070004@poolshark.org>
Message-ID: <alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Denis Leroy wrote:

> Mike McGrath wrote:
> > I'm not saying something isn't wrong.  I'm saying I'm not seeing it and if
> > I can't see it I don't know how I'm going to fix it.  Can anyone give me
> > speeds for any other torrent besides ours?
>
> Well I just added the Fedora 9 i686 live CD for comparison, I'm getting 1.0
> MBytes per second.
>

So, on a new, less popular torrent like the Snap1 you see slow speeds.  On
an older, more popular torrent you see faster speeds.  How is the torrent
not behaving as it should again?

	-Mike



From ralph+fedora at strg-alt-entf.org  Sat Oct 11 20:55:06 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Sat, 11 Oct 2008 22:55:06 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111523330.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
	<alpine.LFD.1.10.0810111523330.25949@laptop.mmcgrath.net>
Message-ID: <20081011205506.GI2305@br-online.de>

Mike McGrath wrote:
> I just downloaded:
> 
> http://torrent.fedoraproject.org/torrents//F10-Snap1-x86_64-Live.torrent
> 
> It took just over 6 minutes and my top speed was 2037.3 KB/s  I might
> suggest that different places have different rules wrt torrent and qos,
> firewalls and other setups can affect torrent preformance.

I wonder how you did that, as I see exactly 1 peer which has 100% (the 
rest is at around 88%), and that is torrent1.fedoraproject.org. This doesn't
seem to be a performance issue >:)

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/1aef16ef/attachment.sig>

From ralph+fedora at strg-alt-entf.org  Sat Oct 11 20:57:06 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Sat, 11 Oct 2008 22:57:06 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810111340u2b2a2dd9j470e50c75d73ea0b@mail.gmail.com>
References: <48EF687B.9090407@odu.neva.ru> <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<70s4s5x57i.ln2@ppp1053.in.ipex.cz> <48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
	<80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
	<20081011202146.GG2305@br-online.de>
	<80d7e4090810111340u2b2a2dd9j470e50c75d73ea0b@mail.gmail.com>
Message-ID: <20081011205706.GJ2305@br-online.de>

Stephen John Smoogen wrote:
> 2008/10/11 Ralph Angenendt <ralph+fedora at strg-alt-entf.org>:
> > Not having publicly available SRPMs for the beta versions (meaning
> > available via public ftp) might be another reason.
> 
> I thought the SRPMS were available, as Scientific Linux uses the
> public ones to build their Betas.

Scientific builds Betas from the *released* version, not from the RHEL beta
versions. So maybe we should come to terms with "what does Beta mean" ...

> I thought it was more a level of priority. CentOS is a volunteer
> project with a lot of costs shouldered by the developers. There is
> usually a shortage of diskspace, slow net links to various build
> machines spread around the world, the fact that various devs have full
> time jobs (there is no full-time build manager like Fedora and SciLin
> have), and various other items. Any of which puts making betas a lower
> priority than dealing with current issues.

Sure, that also comes into play.

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/34957854/attachment.sig>

From denis at poolshark.org  Sat Oct 11 20:59:25 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 11 Oct 2008 22:59:25 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>	<200810112203.45142.opensource@till.name>	<48F10915.4060704@poolshark.org>	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>	<48F10EFB.2020000@poolshark.org>	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>	<48F11184.6070004@poolshark.org>
	<alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>
Message-ID: <48F113AD.4030707@poolshark.org>

Mike McGrath wrote:
> On Sat, 11 Oct 2008, Denis Leroy wrote:
> 
>> Mike McGrath wrote:
>>> I'm not saying something isn't wrong.  I'm saying I'm not seeing it and if
>>> I can't see it I don't know how I'm going to fix it.  Can anyone give me
>>> speeds for any other torrent besides ours?
>> Well I just added the Fedora 9 i686 live CD for comparison, I'm getting 1.0
>> MBytes per second.
>>
> 
> So, on a new, less popular torrent like the Snap1 you see slow speeds.  On
> an older, more popular torrent you see faster speeds.  How is the torrent
> not behaving as it should again?

As someone else mentioned, the distribution of the chunks pushed to the 
clients is supposed to be randomized. Apparently it isn't, we're all 
sitting here with the same completion percentage and the exact same 
chunks, all trying to download from the same one seed.

I'm not sure whether it's the client that picks the random chunk to 
download, or the server that imposes it though. Maybe we're all using 
the same buggy client :-) (I'm using transmission).

Can you add an extra seed using a different client ? (you can use 
transmissioncli for example).



From mmcgrath at redhat.com  Sat Oct 11 21:00:15 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 16:00:15 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <20081011205506.GI2305@br-online.de>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
	<alpine.LFD.1.10.0810111523330.25949@laptop.mmcgrath.net>
	<20081011205506.GI2305@br-online.de>
Message-ID: <alpine.LFD.1.10.0810111558450.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Ralph Angenendt wrote:

> Mike McGrath wrote:
> > I just downloaded:
> >
> > http://torrent.fedoraproject.org/torrents//F10-Snap1-x86_64-Live.torrent
> >
> > It took just over 6 minutes and my top speed was 2037.3 KB/s  I might
> > suggest that different places have different rules wrt torrent and qos,
> > firewalls and other setups can affect torrent preformance.
>
> I wonder how you did that, as I see exactly 1 peer which has 100% (the
> rest is at around 88%), and that is torrent1.fedoraproject.org. This doesn't
> seem to be a performance issue >:)
>

I'm testing from another host in the EU right now and I'm getting
somewhere around 3090.3 KB/s.  I'm all for quicker torrent downloads so if
y'all want to stop by #fedora-admin and chat it up perhaps we can come up
with a fix or better guidelines on how to use torrent or something.

	-Mike



From mmcgrath at redhat.com  Sat Oct 11 21:04:11 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 16:04:11 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F113AD.4030707@poolshark.org>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>
	<48F10915.4060704@poolshark.org>
	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>
	<48F10EFB.2020000@poolshark.org>
	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>
	<48F11184.6070004@poolshark.org>
	<alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>
	<48F113AD.4030707@poolshark.org>
Message-ID: <alpine.LFD.1.10.0810111602240.25949@laptop.mmcgrath.net>

On Sat, 11 Oct 2008, Denis Leroy wrote:

> Mike McGrath wrote:
> > On Sat, 11 Oct 2008, Denis Leroy wrote:
> >
> > > Mike McGrath wrote:
> > > > I'm not saying something isn't wrong.  I'm saying I'm not seeing it and
> > > > if
> > > > I can't see it I don't know how I'm going to fix it.  Can anyone give me
> > > > speeds for any other torrent besides ours?
> > > Well I just added the Fedora 9 i686 live CD for comparison, I'm getting
> > > 1.0
> > > MBytes per second.
> > >
> >
> > So, on a new, less popular torrent like the Snap1 you see slow speeds.  On
> > an older, more popular torrent you see faster speeds.  How is the torrent
> > not behaving as it should again?
>
> As someone else mentioned, the distribution of the chunks pushed to the
> clients is supposed to be randomized. Apparently it isn't, we're all sitting
> here with the same completion percentage and the exact same chunks, all trying
> to download from the same one seed.
>

Explain the timeline on how that happens to everyone, at the same time,
all of us getting every other chunk except this one, and none of us has
completed it (except me and my two machines)?

	-Mike



From braden at endoframe.com  Sat Oct 11 21:08:57 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 17:08:57 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081011T182618-279@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<loom.20081011T182618-279@post.gmane.org>
Message-ID: <1223759337.13589.344.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 18:32 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > Rather than patching configure.[ac,in] and Makefile.am, a more resilient
> > approach is to patch the configure script and Makefile.in files.
> 
> Patching only the generated files is a hack which cannot be submitted upstream, 
> so usually you end up with a patch which touches both source files and 
> generated files, and that's a very fragile approach as:

The premise that the patch you apply as part of the specfile build is
the same one you should be submitting upstream is faulty.

> * often you have to run "touch" on generated files which are not affected by 
> the source change at all, because otherwise the autotools will try to be 
> smarter than you and regenerate everything because not all generated files are 
> up to date, and fail if the required autotools for regenerating everything are 
> not there, and

Won't happen if you're only patching configure and Makefile.in, as you
should.

> * such patches generally have to be copied from the sources to the generated 
> files by hand, because (as I explained in the other thread) regenerating them 
> generally results in huge patches due to subtle autotools version differences, 
> which then fail to apply to new upstream versions.

There are only two possible reasons for such a failure:

     1. Upstream has deliberately changed the same portion(s) of the
        file(s) your patch touches.  In this case, your patch is going
        to break no matter what.
     2. Upstream has built its package with a different version of the
        autotools than were used in the previous release.  In all but
        exceptional cases, "different" means "newer".  Yea, they care!
        Now why didn't they include the patch you sent them?

There can be all sorts of reasons for that.  But packagers faced with an
uncooperative upstream need to learn to live with the reality that their
package will be harder to maintain.  It should not be considered
acceptable behavior for packagers to punt and create work for the poor
guy who drew the short straw for the libtool (or whatever, as the case
may be) upgrade.

> (This is exactly why generated files in source tarballs are a major PITA and 
> the autotools are broken by design.)

Yes, this sort of whining is *really* productive.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From rnicholsNOSPAM at comcast.net  Sat Oct 11 21:11:36 2008
From: rnicholsNOSPAM at comcast.net (Robert Nichols)
Date: Sat, 11 Oct 2008 16:11:36 -0500
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>	<200810112203.45142.opensource@till.name>	<48F10915.4060704@poolshark.org>	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>	<48F10EFB.2020000@poolshark.org>	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>	<48F11184.6070004@poolshark.org>
	<alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>
Message-ID: <gcr4q9$j9a$1@ger.gmane.org>

Mike McGrath wrote:
> On Sat, 11 Oct 2008, Denis Leroy wrote:
> 
>> Mike McGrath wrote:
>>> I'm not saying something isn't wrong.  I'm saying I'm not seeing it and if
>>> I can't see it I don't know how I'm going to fix it.  Can anyone give me
>>> speeds for any other torrent besides ours?
>> Well I just added the Fedora 9 i686 live CD for comparison, I'm getting 1.0
>> MBytes per second.
>>
> 
> So, on a new, less popular torrent like the Snap1 you see slow speeds.  On
> an older, more popular torrent you see faster speeds.  How is the torrent
> not behaving as it should again?

My download roared along at 700 to 800 KB/s until I had the same ~71% that
everyone else had, then my download speed dropped to 1 to 8 KB/s.  The
leechers are happily sharing everything they've got, but everyone has the
same chunks.  The one seed is passing out "virgin" chunks at about 5 KB/s.
At that rate, it'll take another 24 hours before anyone has the whole
thing, at which point _everyone_ will have it.

When I look at the peer list, the only people getting more than 8 KB/s
are those with less than 71% completion.  They can receive chunks from
many sources.  Everyone else has to wait for the one seed to send out
something new.

I'm running bittorrent-4.4.0.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.



From opensource at till.name  Sat Oct 11 21:11:17 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 23:11:17 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <loom.20081011T195752-54@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<200810112125.17757.opensource@till.name>
	<loom.20081011T195752-54@post.gmane.org>
Message-ID: <200810112311.26664.opensource@till.name>

On Sat October 11 2008, Kevin Kofler wrote:

> And this is a really complex solution with lots of manual work for the
> maintainer to do at each upstream release (your proposed Makefile.common
> snippets only automate small parts of it, which are just basic diff and
> patch invocations anyway), you didn't even list all of them (for example,
> the source tarball has to be extracted to rediff a patch).

I guess you do not know the make targets I posted, because "make prep" already 
extracts the source tarball, applies the patches and if you use "-b .foo" in 
the %patch, even a bar.foo backup file for bar is generated, so you can 
easily use gendiff. I do not see which commands were missing, except a cvs 
commit, which has to be done anyways.

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/20081011/0124a707/attachment.sig>

From rnicholsNOSPAM at comcast.net  Sat Oct 11 21:23:49 2008
From: rnicholsNOSPAM at comcast.net (Robert Nichols)
Date: Sat, 11 Oct 2008 16:23:49 -0500
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111602240.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>	<200810112203.45142.opensource@till.name>	<48F10915.4060704@poolshark.org>	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>	<48F10EFB.2020000@poolshark.org>	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>	<48F11184.6070004@poolshark.org>	<alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>	<48F113AD.4030707@poolshark.org>
	<alpine.LFD.1.10.0810111602240.25949@laptop.mmcgrath.net>
Message-ID: <gcr5h6$l3p$1@ger.gmane.org>

Mike McGrath wrote:
> On Sat, 11 Oct 2008, Denis Leroy wrote:
> 
>> Mike McGrath wrote:
>>> On Sat, 11 Oct 2008, Denis Leroy wrote:
>>>
>>>> Mike McGrath wrote:
>>>>> I'm not saying something isn't wrong.  I'm saying I'm not seeing it and
>>>>> if
>>>>> I can't see it I don't know how I'm going to fix it.  Can anyone give me
>>>>> speeds for any other torrent besides ours?
>>>> Well I just added the Fedora 9 i686 live CD for comparison, I'm getting
>>>> 1.0
>>>> MBytes per second.
>>>>
>>> So, on a new, less popular torrent like the Snap1 you see slow speeds.  On
>>> an older, more popular torrent you see faster speeds.  How is the torrent
>>> not behaving as it should again?
>> As someone else mentioned, the distribution of the chunks pushed to the
>> clients is supposed to be randomized. Apparently it isn't, we're all sitting
>> here with the same completion percentage and the exact same chunks, all trying
>> to download from the same one seed.
>>
> 
> Explain the timeline on how that happens to everyone, at the same time,
> all of us getting every other chunk except this one, and none of us has
> completed it (except me and my two machines)?

Here's my theory:

At the border of someone's network there is a gateway that has been set
up to restrict the bandwidth of torrent packets severely.  There is a
community of users that can access the seed without going through that
gateway.  They can access the seed and share chunks at high speed.  The
rest of the world, however, can only see the dribble of data that is
allowed through that gateway.

The only solution is to use another protocol to load a site on the
other side of that (unknown) gateway with a full seed.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.



From kevin at scrye.com  Sat Oct 11 21:26:20 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 11 Oct 2008 15:26:20 -0600
Subject: default XFCE layout
In-Reply-To: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
Message-ID: <20081011152620.5c57cb26@ohm.scrye.com>

On Sat, 11 Oct 2008 22:17:04 +0300
alsadi at gmail.com ("Muayyad AlSadi") wrote:

> after some talk with nirik ( who maintain many xfce4 but not like
> xfce-panel which is responsible on the layout) he suggested
> nirik: I would say post to the dev list and suggest your layout and
> ask if there has been thought to the default layout for 4.6 and see if
> they have further ideas?

Sorry, I meant the Xfce dev list there. 
http://foo-projects.org/mailman/listinfo/xfce4-dev/

> my suggestion is to take in consideration that xfce users usually have
> less ram, less resolution because XFCE is light yet feature full
> 
> I suggest having only one panel
> which have
> menu
> some launchers
> separator
> window list (taskbar)
> workspace switcher in two rows to save space
> systray
> clock
> volume mixer
> 
> here is a screen shot
> http://img353.imageshack.us/my.php?image=xfce4layoutck3.png

My thoughts (as I said on IRC): 

- We should talk with upstream. If you have a great idea for a layout
that works better as a default, why not get it in for all Xfce users?

- Such default layouts are very much a matter of taste. I am not a
Human Interface Design person or a Usability tester. You might have
more luck finding such a person upstream. Ie, its very hard to quantify
what is "better" about your suggested default. 

Thanks for providing the input!

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/530bfc25/attachment.sig>

From pertusus at free.fr  Sat Oct 11 21:33:41 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 11 Oct 2008 23:33:41 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <200810111658.49564.opensource@till.name>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
Message-ID: <20081011213341.GA8235@free.fr>

On Sat, Oct 11, 2008 at 04:58:43PM +0200, Till Maas wrote:
> On Fri October 10 2008, Patrice Dumas wrote:
> 
> > support from the boards. Some months ago I proposed something for a
> > fedora lts that was brought down, maybe for good reasons, but the tone
> > of the discussions really showed very few support, and I'd even say some
> > antagonism.
> 
> Iirc you would get support in terms of infrastructure in case you have a clear 
> proposal and enough people doing the work. Also they should show, that they 
> are really interested in doing this for long enough, that it does not look 
> like a failed project. E.g. starting now a Fedora LTS project and ending it 
> next year, because there are not enough maintainers/people interested in 
> doing the work, does not look good for Fedora.

My proposal was clear: start the project when somebody has volunteered
for each of the packages that are in @code and @base (and maybe other
comps groups, I don't remember exactly). And keep a page with the
packages maintained such as not to give wrong expectations.

--
Pat



From opensource at till.name  Sat Oct 11 21:34:52 2008
From: opensource at till.name (Till Maas)
Date: Sat, 11 Oct 2008 23:34:52 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com> <48F10EFB.2020000@poolshark.org>
	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>
Message-ID: <200810112334.59819.opensource@till.name>

On Sat October 11 2008, Mike McGrath wrote:

> I'm not saying something isn't wrong.  I'm saying I'm not seeing it and if
> I can't see it I don't know how I'm going to fix it.  Can anyone give me
> speeds for any other torrent besides ours?

You can fix it by adding a seed to the group of peers that do not get chunks 
fast from any other seed.

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/20081011/c1ca808d/attachment.sig>

From sandeen at redhat.com  Sat Oct 11 21:45:57 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 11 Oct 2008 16:45:57 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>
	<48EF9E81.4020403@redhat.com>	<48EFA88F.7000105@redhat.com>
	<4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>
Message-ID: <48F11E95.8040401@redhat.com>

Tom London wrote:
> On Fri, Oct 10, 2008 at 12:10 PM, Eric Sandeen <sandeen at redhat.com> wrote:
>> Eric Sandeen wrote:
>>
>>> Changing /etc/fstab to list "ext4" for the root fs may be enough, do it
>>> before you install the new kernel.
>> On further reflection, you will probably just have to do this.
>>
>> -Eric
>>
>>> notting suggested a module alias to ext4dev in the ext4.ko module
>>> itself, that sounds like a good plan and as long as it gets upstream
>>> I'll commit it to Fedora shortly, and I think that should make it all
>>> seamless.
>>
> I have an 'ext4' FS on a USB hard drive.  When I plug this in, I get a
> "Cannot mount volume" popup:
> 
> The volume 'Backup1' uses the ext4dev file system which is not
> supported by your system, followed by a dbus-type failure error
> message about a minute later.
> 
> This just me, or what additional changes are needed?

Do you have the most recent e2fsprogs?  And/or what does blkid
/dev/whatever say... if it says ext4dev, try newer e2fsprogs - blkid had
a bug that caused it to say "ext4dev" when "ext4" is what we wanted.

Going forward I think we'll register both ext4 & ext4dev from the ext4
kernel module, at least for a while, so that "mount -t ext4dev" will
work still work in the transition period.

Sorry for all the hassle :)

-Eric



From henriquecsj at gmail.com  Sat Oct 11 21:55:01 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Sat, 11 Oct 2008 18:55:01 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081011213341.GA8235@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
Message-ID: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>

Hello, everyone,
I would like to share with you an situation related to Fedora's time
of life that comes to me in recent days.
I was recently promoted to Software Manager in the governmental
partition where I work. Next year we've plans to migrate 500 Linux
desktop stations and, in the last month, finished the migration of all
servers to CentOS.
The question that worries me is that, despite the willingness to use
Fedora, dealing with an "end of life" of 13 months can make Fedora
impractical in these 500 desktops. I'll be pressed to use Ubuntu and
even got to think about maintain by myself an repository for
maintaining, maybe, the most important RPMs always updated even if the
Fedora come to the inevitable 13 months of use.
Perhaps it is time to seek volunteers to bring back the Fedora Legacy
and see if more people are interested this time.

Regards from Brazil


2008/10/11 Patrice Dumas <pertusus at free.fr>:
> On Sat, Oct 11, 2008 at 04:58:43PM +0200, Till Maas wrote:
>> On Fri October 10 2008, Patrice Dumas wrote:
>>
>> > support from the boards. Some months ago I proposed something for a
>> > fedora lts that was brought down, maybe for good reasons, but the tone
>> > of the discussions really showed very few support, and I'd even say some
>> > antagonism.
>>
>> Iirc you would get support in terms of infrastructure in case you have a clear
>> proposal and enough people doing the work. Also they should show, that they
>> are really interested in doing this for long enough, that it does not look
>> like a failed project. E.g. starting now a Fedora LTS project and ending it
>> next year, because there are not enough maintainers/people interested in
>> doing the work, does not look good for Fedora.
>
> My proposal was clear: start the project when somebody has volunteered
> for each of the packages that are in @code and @base (and maybe other
> comps groups, I don't remember exactly). And keep a page with the
> packages maintained such as not to give wrong expectations.
>
> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"



From pemboa at gmail.com  Sat Oct 11 22:00:32 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sat, 11 Oct 2008 17:00:32 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
Message-ID: <16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>

On Sat, Oct 11, 2008 at 4:55 PM, Henrique Junior <henriquecsj at gmail.com> wrote:
> Hello, everyone,
> I would like to share with you an situation related to Fedora's time
> of life that comes to me in recent days.
> I was recently promoted to Software Manager in the governmental
> partition where I work. Next year we've plans to migrate 500 Linux
> desktop stations and, in the last month, finished the migration of all
> servers to CentOS.
> The question that worries me is that, despite the willingness to use
> Fedora, dealing with an "end of life" of 13 months can make Fedora
> impractical in these 500 desktops. I'll be pressed to use Ubuntu and
> even got to think about maintain by myself an repository for
> maintaining, maybe, the most important RPMs always updated even if the
> Fedora come to the inevitable 13 months of use.
> Perhaps it is time to seek volunteers to bring back the Fedora Legacy
> and see if more people are interested this time.
>
> Regards from Brazil


A few points/questions:
* Does CentOS not meet your desktop needs?
* You should have a local repo for 500 machines anyways. You don't
want untested updates going to your 500 machines
* I don't think you're going to label running your desktops on a
Ubuntu LTS release as a "bad thing"
* As I understand it, Fedora Legacy died out of lack of interest, not
due to some intentional action


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From ralph+fedora at strg-alt-entf.org  Sat Oct 11 22:01:35 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Sun, 12 Oct 2008 00:01:35 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
Message-ID: <20081011220135.GK2305@br-online.de>

Henrique Junior wrote:
> Perhaps it is time to seek volunteers to bring back the Fedora Legacy
> and see if more people are interested this time.

It didn't work with the limited number of packages in 1, 2 and 3 - why (or
how) should it work now with the much larger number of packages available
for F9/10/11? The workload for maintaining legacy systems has increased 
manyfold. Sure, the number of people involved also has increased, but ...

Cheers,

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/48f2e95a/attachment.sig>

From selinux at gmail.com  Sat Oct 11 22:15:46 2008
From: selinux at gmail.com (Tom London)
Date: Sat, 11 Oct 2008 15:15:46 -0700
Subject: Heads up on ext4 changes
In-Reply-To: <48F11E95.8040401@redhat.com>
References: <48EE016E.8050407@redhat.com> <48EF9E81.4020403@redhat.com>
	<48EFA88F.7000105@redhat.com>
	<4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>
	<48F11E95.8040401@redhat.com>
Message-ID: <4c4ba1530810111515h5b7693b2n37cc55b57236bf97@mail.gmail.com>

On Sat, Oct 11, 2008 at 2:45 PM, Eric Sandeen <sandeen at redhat.com> wrote:
> Tom London wrote:
>> On Fri, Oct 10, 2008 at 12:10 PM, Eric Sandeen <sandeen at redhat.com> wrote:
>>> Eric Sandeen wrote:
>>>
>>>> Changing /etc/fstab to list "ext4" for the root fs may be enough, do it
>>>> before you install the new kernel.
>>> On further reflection, you will probably just have to do this.
>>>
>>> -Eric
>>>
>>>> notting suggested a module alias to ext4dev in the ext4.ko module
>>>> itself, that sounds like a good plan and as long as it gets upstream
>>>> I'll commit it to Fedora shortly, and I think that should make it all
>>>> seamless.
>>>
>> I have an 'ext4' FS on a USB hard drive.  When I plug this in, I get a
>> "Cannot mount volume" popup:
>>
>> The volume 'Backup1' uses the ext4dev file system which is not
>> supported by your system, followed by a dbus-type failure error
>> message about a minute later.
>>
>> This just me, or what additional changes are needed?
>
> Do you have the most recent e2fsprogs?  And/or what does blkid
> /dev/whatever say... if it says ext4dev, try newer e2fsprogs - blkid had
> a bug that caused it to say "ext4dev" when "ext4" is what we wanted.
>
> Going forward I think we'll register both ext4 & ext4dev from the ext4
> kernel module, at least for a while, so that "mount -t ext4dev" will
> work still work in the transition period.
>
> Sorry for all the hassle :)
>
> -Eric
>
No hassle, this is fun! ;)

Anyway:

[root at tlondon ~]# rpm -q e2fsprogs
e2fsprogs-1.41.2-2.fc10.i386
[root at tlondon ~]# blkid /dev/sdb1
/dev/sdb1: LABEL="Backup1" UUID="7066e635-fe1f-4cf8-94a6-1a3e9229a44c"
TYPE="ext4"
[root at tlondon ~]#

Guessing that something is compiled with 'ext4dev' (not 'ext4'), I did
'strings | grep ext4' in the usual places (/bin, /sbin, /usr/bin,
/usr/sbin/, /usr/libexec, /usr/lib).  Here is what I got (omitting
those that appeared to have both 'ext4' and ext4dev'):

/sbin/quotacheck
ext4dev
/sbin/quotaoff
ext4dev
/sbin/quotaon
ext4dev
/usr/bin/quota
ext4dev
/usr/sbin/convertquota
ext4dev
/usr/sbin/edquota
ext4dev
/usr/sbin/repquota
ext4dev
/usr/sbin/rpc.rquotad
ext4dev
/usr/sbin/setquota
ext4dev
/usr/sbin/warnquota
ext4dev

So I'm guessing those (all quota related) need updating.  Don't think
this has anything to do with my 'issue', however.

Anyway, I can mount manually for now. Sorry I couldn't quickly figure
out what was doing this.....

tom
-- 
Tom London



From pertusus at free.fr  Sat Oct 11 22:17:05 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 00:17:05 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081011220135.GK2305@br-online.de>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
Message-ID: <20081011221705.GC8235@free.fr>

On Sun, Oct 12, 2008 at 12:01:35AM +0200, Ralph Angenendt wrote:
> 
> It didn't work with the limited number of packages in 1, 2 and 3 - why (or
> how) should it work now with the much larger number of packages available
> for F9/10/11? The workload for maintaining legacy systems has increased 
> manyfold. Sure, the number of people involved also has increased, but ...

There are many other differences. We can use the rules of fedora (and
could use the infrastructure). And after the merging there are more
involvment of the community in maintaining packages. I was interested in
legacy at some point, but everything was so different than in fedora
extras that it deterred me.

--
Pat



From henriquecsj at gmail.com  Sat Oct 11 22:21:41 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Sat, 11 Oct 2008 19:21:41 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>
Message-ID: <4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>

Hi,
As a desktop, Fedora is the best solution. Should I use the best 2nd
solution? (Ubuntu).
Maybe if we take *some* releases to LLT, lets say, Fedora N, Fedora
N+4. The intermediary releases will be "non LLT".... Well, I know that
Fedora have to worry about all releases, but if we have few people to
work it should be one point.
Maybe it looks crazy.

P.S.: I'm sorry for my poor english.


2008/10/11 Arthur Pemberton <pemboa at gmail.com>:
> On Sat, Oct 11, 2008 at 4:55 PM, Henrique Junior <henriquecsj at gmail.com> wrote:
>> Hello, everyone,
>> I would like to share with you an situation related to Fedora's time
>> of life that comes to me in recent days.
>> I was recently promoted to Software Manager in the governmental
>> partition where I work. Next year we've plans to migrate 500 Linux
>> desktop stations and, in the last month, finished the migration of all
>> servers to CentOS.
>> The question that worries me is that, despite the willingness to use
>> Fedora, dealing with an "end of life" of 13 months can make Fedora
>> impractical in these 500 desktops. I'll be pressed to use Ubuntu and
>> even got to think about maintain by myself an repository for
>> maintaining, maybe, the most important RPMs always updated even if the
>> Fedora come to the inevitable 13 months of use.
>> Perhaps it is time to seek volunteers to bring back the Fedora Legacy
>> and see if more people are interested this time.
>>
>> Regards from Brazil
>
>
> A few points/questions:
> * Does CentOS not meet your desktop needs?
> * You should have a local repo for 500 machines anyways. You don't
> want untested updates going to your 500 machines
> * I don't think you're going to label running your desktops on a
> Ubuntu LTS release as a "bad thing"
> * As I understand it, Fedora Legacy died out of lack of interest, not
> due to some intentional action
>
>
> --
> Fedora 9 : sulphur is good for the skin
> ( www.pembo13.com )
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"



From bruno at wolff.to  Sat Oct 11 22:08:12 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 11 Oct 2008 17:08:12 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<1223704398.3564.1316.camel@beck.corsepiu.local>
	<364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>
Message-ID: <20081011220812.GA892@wolff.to>

On Sat, Oct 11, 2008 at 10:28:40 +0100,
  Christopher Brown <snecklifter at gmail.com> wrote:
> 
> No, you just have to be less of an ass. As a casual observer, all you
> seem to do is throw rocks. Your only sanctuary lies in the totally
> open nature of the project and that it's pretty much impossible to
> boot you off it. In fact, your occasional tantrums bears all the
> hallmarks of ESR before he happily departed these shores - any chance
> you'll be doing the same soon and leave people to get on with the task
> in hand?
> 
> If not then please remember that good manners cost nothing.

In that vein there was no reason to gratuitously dis ESR. He had a legitmate
difference of opinion and for a while tried to convince people that Fedora
should go in a different direction. He still contributes indirectly to
Fedora through the Wesnoth project.



From cra at WPI.EDU  Sat Oct 11 22:28:50 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 18:28:50 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081011221705.GC8235@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
Message-ID: <20081011222850.GM10204@angus.ind.WPI.EDU>

On Sun, Oct 12, 2008 at 12:17:05AM +0200, Patrice Dumas wrote:
> On Sun, Oct 12, 2008 at 12:01:35AM +0200, Ralph Angenendt wrote:
> > 
> > It didn't work with the limited number of packages in 1, 2 and 3 - why (or
> > how) should it work now with the much larger number of packages available
> > for F9/10/11? The workload for maintaining legacy systems has increased 
> > manyfold. Sure, the number of people involved also has increased, but ...
> 
> There are many other differences. We can use the rules of fedora (and
> could use the infrastructure). And after the merging there are more
> involvment of the community in maintaining packages. I was interested in
> legacy at some point, but everything was so different than in fedora
> extras that it deterred me.

There also doesn't need to be a requirement that every single package 
in the Everything repo be maintained for a longer time.  We could 
start with some of the spins, like Fedora spin, which contains most of 
the "core" packages.  Interested contributors would need to commit to 
support either their own packages for a longer term, or other packages 
where the current Fedora maintainer doesn't want to do long term 
maintenance.  This would be simlar to how EPEL works, but for Fedora 
releases.



From sundaram at fedoraproject.org  Sat Oct 11 22:33:11 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 12 Oct 2008 04:03:11 +0530
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081011220812.GA892@wolff.to>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<1223704398.3564.1316.camel@beck.corsepiu.local>	<364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>
	<20081011220812.GA892@wolff.to>
Message-ID: <48F129A7.6070706@fedoraproject.org>

Bruno Wolff III wrote:
> In that vein there was no reason to gratuitously dis ESR. He had a legitmate
> difference of opinion and for a while tried to convince people that Fedora
> should go in a different direction

Does legitimate difference of opinion involve making false claims about 
the impact of patents and trolling?

http://lwn.net/Articles/257586/

Are you actually defending this kind of behaviour?

Rahul



From opensource at till.name  Sat Oct 11 22:42:39 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 00:42:39 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081011213341.GA8235@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
Message-ID: <200810120042.45039.opensource@till.name>

On Sat October 11 2008, Patrice Dumas wrote:

> My proposal was clear: start the project when somebody has volunteered
> for each of the packages that are in @code and @base (and maybe other
> comps groups, I don't remember exactly). And keep a page with the
> packages maintained such as not to give wrong expectations.

So why don't you start to find the maintainers you need? If you got them 
together, it will be a lot easier to get this done.

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/20081012/9d33892b/attachment.sig>

From bruno at wolff.to  Sat Oct 11 22:52:15 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 11 Oct 2008 17:52:15 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F129A7.6070706@fedoraproject.org>
References: <48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<1223704398.3564.1316.camel@beck.corsepiu.local>
	<364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>
	<20081011220812.GA892@wolff.to>
	<48F129A7.6070706@fedoraproject.org>
Message-ID: <20081011225215.GA15341@wolff.to>

On Sun, Oct 12, 2008 at 04:03:11 +0530,
  Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Bruno Wolff III wrote:
>> In that vein there was no reason to gratuitously dis ESR. He had a legitmate
>> difference of opinion and for a while tried to convince people that Fedora
>> should go in a different direction
>
> Does legitimate difference of opinion involve making false claims about  
> the impact of patents and trolling?

They are independent.

>
> http://lwn.net/Articles/257586/
>
> Are you actually defending this kind of behaviour?

In my opinion ESR's comment there was in poor taste.



From alsadi at gmail.com  Sat Oct 11 22:59:21 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Sun, 12 Oct 2008 01:59:21 +0300
Subject: default XFCE layout
In-Reply-To: <20081011152620.5c57cb26@ohm.scrye.com>
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
	<20081011152620.5c57cb26@ohm.scrye.com>
Message-ID: <385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>

Hi, sorry I though you meant devel-list as a way to get it into F10
and upstream them later

> If you have a **great idea** for a layout
It's just a desktop layout it's not big deal nor rocket science
I don't think we should upstream our fedora backgrounds to xfce!

>
> kevin
>

do you have two fedora accounts
.fasinso nirik
.fasinfo kaven

Fedora people should stop using two names :-)



From sundaram at fedoraproject.org  Sat Oct 11 22:59:00 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 12 Oct 2008 04:29:00 +0530
Subject: Difference of opinions
In-Reply-To: <20081011225215.GA15341@wolff.to>
References: <48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<1223704398.3564.1316.camel@beck.corsepiu.local>
	<364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>
	<20081011220812.GA892@wolff.to>
	<48F129A7.6070706@fedoraproject.org>
	<20081011225215.GA15341@wolff.to>
Message-ID: <48F12FB4.1060802@fedoraproject.org>

Bruno Wolff III wrote:
> On Sun, Oct 12, 2008 at 04:03:11 +0530,
>   Rahul Sundaram wrote:
>> Bruno Wolff III wrote:
>>> In that vein there was no reason to gratuitously dis ESR. He had a legitmate
>>> difference of opinion and for a while tried to convince people that Fedora
>>> should go in a different direction
>> Does legitimate difference of opinion involve making false claims about  
>> the impact of patents and trolling?
> 
> They are independent.

How are they independent? If you want to express a difference of 
opinion, there are much better ways to do it than the approach he 
choose. Besides, if you start out with false assumptions or claims, how 
are your arguments going to be taken seriously?

>> http://lwn.net/Articles/257586/
>>
>> Are you actually defending this kind of behaviour?
> 
> In my opinion ESR's comment there was in poor taste.

Poor taste is very much a understatement. The reaction is not surprising 
at all.

Rahul



From pertusus at free.fr  Sat Oct 11 23:24:49 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 01:24:49 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <200810120042.45039.opensource@till.name>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<200810120042.45039.opensource@till.name>
Message-ID: <20081011232449.GD8235@free.fr>

On Sun, Oct 12, 2008 at 12:42:39AM +0200, Till Maas wrote:
> On Sat October 11 2008, Patrice Dumas wrote:
> 
> > My proposal was clear: start the project when somebody has volunteered
> > for each of the packages that are in @code and @base (and maybe other
> > comps groups, I don't remember exactly). And keep a page with the
> > packages maintained such as not to give wrong expectations.
> 
> So why don't you start to find the maintainers you need? If you got them 
> together, it will be a lot easier to get this done.

There is also the need for some infrastructure. (My proposal here was 
just to let the old branches live. At that time there was no packagedb,
now with packagedb it would even be simpler.) Without infrastructure, it
is not really worth gathering maintainers.

--
Pat



From opensource at till.name  Sat Oct 11 23:43:19 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 01:43:19 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810111558450.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com> <20081011205506.GI2305@br-online.de>
	<alpine.LFD.1.10.0810111558450.25949@laptop.mmcgrath.net>
Message-ID: <200810120143.24733.opensource@till.name>

On Sat October 11 2008, Mike McGrath wrote:

> I'm testing from another host in the EU right now and I'm getting
> somewhere around 3090.3 KB/s.  I'm all for quicker torrent downloads so if
> y'all want to stop by #fedora-admin and chat it up perhaps we can come up
> with a fix or better guidelines on how to use torrent or something.

We need more seeds at the beginning and more people with access to the isos. 
Dennis Gilmore finally managed to acquire the isos somehow and seeded them 
and this made it possible for everybody else to download them, too. 

I guess you did not finish a download of the Snap1 isos, because the tracker 
did not show while, but they were shown for Dennis and everyone else who 
finished then. Therefore the testing procedure for the torrents also needs to 
be improved. You can give the files to some people who are willing to seed 
them some hours before they are published and see, whether they can really 
get them and whether the tracker also counts the downloads. Then you also 
have more initial seeders.

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/20081012/a194d920/attachment.sig>

From smooge at gmail.com  Sun Oct 12 00:17:43 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sat, 11 Oct 2008 18:17:43 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081011205706.GJ2305@br-online.de>
References: <48EF687B.9090407@odu.neva.ru> <20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com> <70s4s5x57i.ln2@ppp1053.in.ipex.cz>
	<48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
	<80d7e4090810111249n4c62a8c8h73693fdaf6c5eb36@mail.gmail.com>
	<20081011202146.GG2305@br-online.de>
	<80d7e4090810111340u2b2a2dd9j470e50c75d73ea0b@mail.gmail.com>
	<20081011205706.GJ2305@br-online.de>
Message-ID: <80d7e4090810111717k4d79ccb4l13849a099ea5240e@mail.gmail.com>

2008/10/11 Ralph Angenendt <ralph+fedora at strg-alt-entf.org>:
> Stephen John Smoogen wrote:
>> 2008/10/11 Ralph Angenendt <ralph+fedora at strg-alt-entf.org>:
>> > Not having publicly available SRPMs for the beta versions (meaning
>> > available via public ftp) might be another reason.
>>
>> I thought the SRPMS were available, as Scientific Linux uses the
>> public ones to build their Betas.
>
> Scientific builds Betas from the *released* version, not from the RHEL beta
> versions. So maybe we should come to terms with "what does Beta mean" ...
>

My mistake.. reading through some of the alpha release notes from
SciLin4 that I was looking at indicated it was compiled from the beta.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From braden at endoframe.com  Sun Oct 12 00:40:14 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 20:40:14 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <200810111543.21186.sgrubb@redhat.com>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
Message-ID: <1223772015.13589.354.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 15:43 -0400, Steve Grubb wrote:
> On Saturday 11 October 2008 15:18:33 Braden McDaniel wrote:
> > That is, generally, the right idea.  However, autoreconf is a bit of a
> > sledgehammer and can result in a patch that is larger than necessary.
> > The only files that should need patching are configure and Makefile.in.
> > autoconf will produce the former, and automake the latter.
> 
> There's been a number of occasions where I patch Makefile.am because its a 1 
> liner and patching Makefile.in makes a very ugly patch that becomes harder to 
> read.

Many one-liner Makefile.am patches are also one-liner Makefile.in
patches when Makefile.in is modified manually.  There's no reason to be
shy about doing that.

Note also that, for better or for worse, Fedora includes several older
versions of autoconf and automake.  This is one time it's for the
better.  You can use a version of autoconf or automake that is
reasonably close to (but not older than) the one the upstream developer
used when regenerating the files, thus minimizing noise in the patch.

>  Examples of this is adding files to be compiled in, removing files to 
> be compiled in, or making something optional for a configure flag. So, if you 
> know what you are doing, its fine to patch configure.ac or Makefile.am.

It's really not.  Because even if you're perfectly capable using the
autotools, you're still exposing the package to potential breakage when
it gets rebuilt with a newer version of the tools.

> On the otherhand...there are also a number of projects that use libmissing. We 
> do not carry that in Fedora. That means that any project using libmissing, 
> you always have to patch Makefile.in and not Makefile.am since autoreconf 
> won't be able to find the m4 macros for gnulib. We should probably carry 
> gnulib sooner or later.

I was thinking that Fedora should package gnulib just the other night.
But not so that spec files could use gnulib-tool (or similar).  That's
just as broken as using autoreconf--and for exactly the same reasons.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From sandeen at redhat.com  Sun Oct 12 00:57:33 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 11 Oct 2008 19:57:33 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <4c4ba1530810111515h5b7693b2n37cc55b57236bf97@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>
	<48EF9E81.4020403@redhat.com>	<48EFA88F.7000105@redhat.com>	<4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>	<48F11E95.8040401@redhat.com>
	<4c4ba1530810111515h5b7693b2n37cc55b57236bf97@mail.gmail.com>
Message-ID: <48F14B7D.7000604@redhat.com>

Tom London wrote:
> On Sat, Oct 11, 2008 at 2:45 PM, Eric Sandeen <sandeen at redhat.com> wrote:
>> Tom London wrote:
>>> On Fri, Oct 10, 2008 at 12:10 PM, Eric Sandeen <sandeen at redhat.com> wrote:
>>>> Eric Sandeen wrote:
>>>>
>>>>> Changing /etc/fstab to list "ext4" for the root fs may be enough, do it
>>>>> before you install the new kernel.
>>>> On further reflection, you will probably just have to do this.
>>>>
>>>> -Eric
>>>>
>>>>> notting suggested a module alias to ext4dev in the ext4.ko module
>>>>> itself, that sounds like a good plan and as long as it gets upstream
>>>>> I'll commit it to Fedora shortly, and I think that should make it all
>>>>> seamless.
>>> I have an 'ext4' FS on a USB hard drive.  When I plug this in, I get a
>>> "Cannot mount volume" popup:
>>>
>>> The volume 'Backup1' uses the ext4dev file system which is not
>>> supported by your system, followed by a dbus-type failure error
>>> message about a minute later.
>>>
>>> This just me, or what additional changes are needed?
>> Do you have the most recent e2fsprogs?  And/or what does blkid
>> /dev/whatever say... if it says ext4dev, try newer e2fsprogs - blkid had
>> a bug that caused it to say "ext4dev" when "ext4" is what we wanted.
>>
>> Going forward I think we'll register both ext4 & ext4dev from the ext4
>> kernel module, at least for a while, so that "mount -t ext4dev" will
>> work still work in the transition period.
>>
>> Sorry for all the hassle :)
>>
>> -Eric
>>
> No hassle, this is fun! ;)
> 
> Anyway:
> 
> [root at tlondon ~]# rpm -q e2fsprogs
> e2fsprogs-1.41.2-2.fc10.i386
> [root at tlondon ~]# blkid /dev/sdb1
> /dev/sdb1: LABEL="Backup1" UUID="7066e635-fe1f-4cf8-94a6-1a3e9229a44c"
> TYPE="ext4"
> [root at tlondon ~]#
> 
> Guessing that something is compiled with 'ext4dev' (not 'ext4'), I did
> 'strings | grep ext4' in the usual places (/bin, /sbin, /usr/bin,
> /usr/sbin/, /usr/libexec, /usr/lib).  Here is what I got (omitting
> those that appeared to have both 'ext4' and ext4dev'):
> 
> /sbin/quotacheck
> ext4dev

crud, you're right:

#define MNTTYPE_EXT4            "ext4dev"       /* ext4 filesystem */

we'll need to update that.

Thanks,
-Eric



From sandeen at redhat.com  Sun Oct 12 01:04:30 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 11 Oct 2008 20:04:30 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <4c4ba1530810111515h5b7693b2n37cc55b57236bf97@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>
	<48EF9E81.4020403@redhat.com>	<48EFA88F.7000105@redhat.com>	<4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>	<48F11E95.8040401@redhat.com>
	<4c4ba1530810111515h5b7693b2n37cc55b57236bf97@mail.gmail.com>
Message-ID: <48F14D1E.6000805@redhat.com>

Tom London wrote:
>

> Anyway, I can mount manually for now. Sorry I couldn't quickly figure
> out what was doing this.....
> 
> tom

Actually, I wasn't thinking; hal uses udev not blkid; udev will also
need updates.  Registering both fs types will help, I'll get that done soon.

/me wishes the ext4dev thing had never come into existence right about now.

But we'll get it fixed up.

Thanks,
-Eric



From jreiser at BitWagon.com  Sun Oct 12 01:16:27 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Sat, 11 Oct 2008 18:16:27 -0700
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F0C1CE.30104@BitWagon.com>
References: <48F0C1CE.30104@BitWagon.com>
Message-ID: <48F14FEB.20406@BitWagon.com>

John Reiser wrote:
> Young torrents on http://torrent.fedoraproject.org/ spread data too slowly.
> At 0500 UTC on Sat.Oct.11, there was 1 seed and 14 leeches, all at 13% 
> done.
> At 1300 UTC on Sat.Oct.11, there was 1 seed and 31 leeches, all at 55% 
> done.
> This is for F10-Snap1-x86_64-Live.
> I turned my machine off for the night (US PDT), powered on in the morning,
> and within half an hour had caught up to all leeches at 57% done.
> I use tranmsissionbt, and I saw that the seed was sending pieces of 256 KiB
> to me at 2.5 KiB/s, taking almost two minutes per piece (and then 
> "pausing.")

About 2230 UTC on Sat.Oct.11, the 67 leeches finished within a few minutes
of each other.  The torrents started about 0000 UTC.  So it took more than 22 hours
to distribute the 67 copies of 726MB of data.  That is approx. 10KB/s for each,
on average, which is very slow.  The expected speed is at least 10 times as fast.

One theory is deliberate throttling/choking somewhere.
Here's a [current] traceroute for two of my machines that were in the swarm
during those 22 hours [first few hops omitted due to paranoia]:
-----
traceroute to torrent.fedoraproject.org (152.46.7.220), 30 hops max, 38 byte packets
    [server in internet hotel]
  3  ge-6-0-0.edge-rtr02.ptldor02.iinet.com (198.145.40.99)  0.427 ms  0.424 ms  0.394 ms
  4  fe-6-0-0-20.acs-rtr04.ptldor02.iinet.com (198.145.240.165)  0.855 ms  0.652 ms  0.521 ms
  5  66-193-100-89.static.twtelecom.net (66.193.100.89)  1.711 ms  2.106 ms  1.613 ms
  6  peer-01-so-0-0-0-0.snjs.twtelecom.net (64.129.248.17)  16.834 ms  49.743 ms  17.190 ms
  7  te3-2.mpd01.sjc01.atlas.cogentco.com (154.54.6.81)  223.951 ms te8-2.mpd01.sjc01.atlas.cogentco.com (154.54.6.237)  74.034 ms te8-2.ccr02.sjc01.atlas.cogentco.com (154.54.6.233)  17.179 ms
  8  te8-4.mpd01.lax01.atlas.cogentco.com (154.54.2.129)  63.993 ms te8-4.ccr02.lax01.atlas.cogentco.com (154.54.2.149)  38.244 ms  35.766 ms
  9  te2-8.mpd01.iah01.atlas.cogentco.com (154.54.5.101)  75.458 ms te9-8.mpd01.iah01.atlas.cogentco.com (154.54.0.230)  264.798 ms te9-8.ccr02.iah01.atlas.cogentco.com (154.54.3.185)  63.395 ms
10  te4-2.ccr01.atl01.atlas.cogentco.com (154.54.7.237)  77.549 ms te9-2.ccr01.atl01.atlas.cogentco.com (154.54.24.1)  106.957 ms  78.105 ms
11  te8-2.mpd01.atl04.atlas.cogentco.com (154.54.3.174)  89.485 ms te7-1.mpd01.atl04.atlas.cogentco.com (154.54.6.114)  77.320 ms te7-3.mpd01.atl04.atlas.cogentco.com (154.54.6.122)  92.799 ms
12  MCNC.demarc.cogentco.com (38.99.223.154)  86.542 ms  86.692 ms  86.470 ms
13  torrent1.fedoraproject.org (152.46.7.220)  86.432 ms !<10>  119.191 ms !<10>  86.265 ms !<10>
-----
traceroute to torrent.fedoraproject.org (152.46.7.220), 30 hops max, 60 byte packets
    [home ADSL]
  4  fa0-13.na02.b006468-1.pdx01.atlas.cogentco.com (38.103.165.25)  49.514 ms  51.751 ms  51.966 ms
  5  gi4-1.3506.core01.pdx01.atlas.cogentco.com (38.20.33.201)  53.016 ms  53.243 ms  53.924 ms
  6  po10-0.core01.sfo01.atlas.cogentco.com (154.54.3.133)  68.408 ms  58.018 ms  58.898 ms
  7  te3-1.mpd01.sfo01.atlas.cogentco.com (154.54.3.102)  61.053 ms  57.317 ms  57.872 ms
  8  te7-4.mpd01.sjc01.atlas.cogentco.com (154.54.6.134)  60.721 ms  60.586 ms  58.419 ms
  9  te8-4.mpd01.lax01.atlas.cogentco.com (154.54.2.129)  70.422 ms  69.758 ms  70.212 ms
10  te2-8.mpd01.iah01.atlas.cogentco.com (154.54.5.101)  106.394 ms te3-8.mpd01.iah01.atlas.cogentco.com (154.54.2.197)  105.619 ms  104.902 ms
11  te9-2.ccr01.atl01.atlas.cogentco.com (154.54.24.1)  118.926 ms  117.071 ms  118.478 ms
12  te7-1.mpd01.atl04.atlas.cogentco.com (154.54.6.114)  117.427 ms te7-3.mpd01.atl04.atlas.cogentco.com (154.54.6.122)  118.588 ms te8-4.mpd01.atl04.atlas.cogentco.com (154.54.3.170)  119.276 ms
13  MCNC.demarc.cogentco.com (38.99.223.154)  130.398 ms  126.942 ms  127.524 ms
14  torrent1.fedoraproject.org (152.46.7.220)  128.325 ms !X  128.997 ms !X  129.545 ms !X
-----

-- 



From braden at endoframe.com  Sun Oct 12 01:18:13 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 21:18:13 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <200810112135.17556.opensource@till.name>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810112135.17556.opensource@till.name>
Message-ID: <1223774293.13589.381.camel@hinge.endoframe.net>

On Sat, 2008-10-11 at 21:35 +0200, Till Maas wrote:
> On Sat October 11 2008, Braden McDaniel wrote:
> > On Sat, 2008-10-11 at 20:31 +0200, Till Maas wrote:
> > > On Sat October 11 2008, Braden McDaniel wrote:
> > > > When the estimate of "300 broken packages" was tossed out in the
> > > > libtool 2.2.x thread, I figured there was no way *that* many packages
> > > > could be running autoreconf or libtoolize.  But I have been surprised
> > > > to find no advice against this practice in Fedora's packaging
> > > > guidelines; and in light of that, the number is not quite so
> > > > incredible.
> > >
> > > There is a draft about this at:
> > > https://fedoraproject.org/wiki/PackagingDrafts/AutoConf
> >
> > Thanks. I've edited this a bit to include references to libtoolize. I'd
> > be happy to help move this forward. What's required?
> 
> You have to write an e-mail to the fedora packaging commitee and discuss it 
> with them:
> https://www.redhat.com/mailman/listinfo/fedora-packaging

Okay.

> > > > While forbidding the use of autoreconf (or similar: autoconf, automake,
> > > > libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> > > > appropriate for the packaging guidelines to point out the pitfalls of
> > > > this practice and advise packagers to avoid it where possible.
> > >
> > > I have read either in the wiki or on this mailing list, that one should
> > > run autoreconf locally and create a patch from this, that is then used
> > > within the spec.
> >
> > That is, generally, the right idea.  However, autoreconf is a bit of a
> > sledgehammer and can result in a patch that is larger than necessary.
> > The only files that should need patching are configure and Makefile.in.
> > autoconf will produce the former, and automake the latter.  It is more
> > unusual, but possible, that ltmain.sh might need patching.  libtoolize
> > can be used to generate a patch in that case.
> 
> So the one would run autoreconf, but only create a patch for configure, 
> Makefile.in and ltmain.sh? Or should only automake and autoconf be run in the 
> normal case and then the diff is the patch?

I'm not sure what's considered the "normal case" here.

      * If you've only modified Makefile.am, you can just run automake
        to regenerate Makefile.in.
      * If you've modified configure.[ac|in], but you didn't add any new
        macro invocations, you can just run autoconf.
      * If you've added macro invocations to configure.[ac|in], you need
        to run aclocal before running autoconf.

In any of these cases, there's no reason for your patch to include
modifications to files other than configure and Makefile.in.

autoreconf is the shotgun approach.  It exists as a convenience to
developers, when running the individual tools in the right order can be
tedious.  Patches should be surgical.  So for the purpose of generating
diff input, I'd suggest running the tools individually.

Needing to modify ltmain.sh is *really* unusual.  If you're trying to
surgically correct some behavior of the version of libtool used to build
the upstream source package, it's exactly the right thing to do.  If you
*really* need to use a different version of libtool than upstream used,
we're in choppier waters.  I think there's a case to be made for just
invoking libtoolize in the spec file for this purpose--but you should
proceed fully aware that your package will get whatever Fedora's
"latest" libtool happens to be and there is a very real possibility
(probability) that things will break.  Using a patch will be more
future-proof; but that patch is going to be big and unwieldy.

Really, the best thing you can do in such a scenario is reexamine the
choices that brought you to that place and realize, "What was I
thinking?!"

> Maybe you can add whatever should be done to the AutoConf wiki page.

I'll do that.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From kevin.kofler at chello.at  Sun Oct 12 01:19:20 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 01:19:20 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
Message-ID: <loom.20081012T011207-253@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> Many one-liner Makefile.am patches are also one-liner Makefile.in
> patches when Makefile.in is modified manually.  There's no reason to be
> shy about doing that.

He explicitly explained that in his case the Makefile.in change was NOT a 
one-liner. And I've seen that many times: Just add an additional source file (a 
one-line Makefile.am change) and watch how much Makefile.in changes.

> Because even if you're perfectly capable using the
> autotools, you're still exposing the package to potential breakage when
> it gets rebuilt with a newer version of the tools.

Newsflash: We're "exposing" all packages "to potential breakage" all the time 
when they "get rebuilt with a newer version of the" GCC and Binutils "tools". 
So what are you going to suggest next: packaging upstream's binaries? :-/

So how are the autotools different from GCC and Binutils?

I wonder if we shouldn't even start treating generated autotools files the same 
way as binary JARs (for which the packaging guidelines mandate that they have 
to be removed and rebuilt from source). They're all generated files.

        Kevin Kofler



From smooge at gmail.com  Sun Oct 12 01:23:59 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sat, 11 Oct 2008 19:23:59 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223744133.3327.11.camel@luminos.localdomain>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz> <20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com> <70s4s5x57i.ln2@ppp1053.in.ipex.cz>
	<48F06C9C.2030503@gmail.com>
	<1223744133.3327.11.camel@luminos.localdomain>
Message-ID: <80d7e4090810111823q5921ae38jd5bb531f7cfb2b@mail.gmail.com>

2008/10/11 Jesse Keating <jkeating at redhat.com>:
> On Sat, 2008-10-11 at 04:06 -0500, Les Mikesell wrote:
>>
>> There's no lead time for your own local development and testing.  You
>> would never expect one of the old RH X.0 releases to be production-ready
>> but the new releases would have new kernels, libraries, and utilities so
>> you could incorporate their features in your own work, which was likely
>> to proceed at approximately the same rate as the distro evolved toward
>> stability.  With Centos you don't get anything to work with and test
>> ahead of time, and if you'd tested on an earlier Fedora there may or may
>> not be any relationship.  A side effect was that the community of RH
>> users that reported/fixed bugs in the X.0 got something for their effort
>> in being able to continue using the updated release instead of being
>> abandoned as a wildly new X.0 came out.
>
> CentOS should be putting out betas that match the RHEL betas so that you
> can get access to it before the release.  Use Fedora as the technology
> driver, use Betas as the bugfix cleanup for platform issues, and
> eventually you get the "Enterprise" release.
>

I was wrong about why CentOS has not done Beta's in the past. So what
can be done about getting the src.rpms for the next set of beta's
(4.8/5.3) on the ftp servers when they are ready to be previewed?



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From cra at WPI.EDU  Sun Oct 12 01:24:28 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 11 Oct 2008 21:24:28 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F14FEB.20406@BitWagon.com>
References: <48F0C1CE.30104@BitWagon.com> <48F14FEB.20406@BitWagon.com>
Message-ID: <20081012012428.GN10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 06:16:27PM -0700, John Reiser wrote:
> About 2230 UTC on Sat.Oct.11, the 67 leeches finished within a few minutes
> of each other.  The torrents started about 0000 UTC.  So it took more than 22 hours
> to distribute the 67 copies of 726MB of data.  That is approx. 10KB/s for each,
> on average, which is very slow.  The expected speed is at least 10 times as fast.
>
> One theory is deliberate throttling/choking somewhere.
> Here's a [current] traceroute for two of my machines that were in the swarm
> during those 22 hours [first few hops omitted due to paranoia]:

I'm pretty sure this was throttling done by torrent1.fedoraproject.org 
itself.  I was coming in via Internet2, and I assume the reverse route 
was also via Internet2 (which might be a bad assumption).

 4  WORCESTER-BOSTON.GODDARD.GIGAPOP.NET (130.215.6.2)  1.947 ms  2.015 ms  2.041 ms
 5  nox1sumgw1-Vl-591-NoX-WPI.nox.org (192.5.89.41)  2.111 ms  2.092 ms  2.470 ms
 6  nox300gw1-Vl-803-NoX.nox.org (192.5.89.238)  2.991 ms  2.642 ms  2.679 ms
 7  nox300gw1-PEER-NoX-INTERNET2-192-5-89-222.nox.org (192.5.89.222)  7.883 ms  7.856 ms  7.712 ms
 8  ge-2-3-1.0.rtr.atla.net.internet2.edu (64.57.28.19)  12.137 ms  11.702 ms  11.662 ms
 9  so-0-0-0.0.rtr.atla.net.internet2.edu (64.57.28.6)  25.262 ms  25.396 ms  25.401 ms
10  dep7600-gw2-internet2.ncren.net (198.86.17.65)  33.395 ms  33.404 ms  33.439 ms
11  rtp7600-gw-to-dep7600-gw2.ncren.net (128.109.70.137)  35.270 ms  35.507 ms  36.060 ms
12  rtp11-gw-to-rtp7600-gw-sec.ncren.net (128.109.70.121)  36.187 ms  36.056 ms  36.068 ms
13  ibiblio-gw-to-rtp11-gw.ncren.net (128.109.70.114)  36.363 ms  36.371 ms  36.509 ms
14  torrent1.fedoraproject.org (152.46.7.220)  35.207 ms !X  35.207 ms !X  35.268 ms !X



From kevin.kofler at chello.at  Sun Oct 12 01:27:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 01:27:47 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<loom.20081011T182618-279@post.gmane.org>
	<1223759337.13589.344.camel@hinge.endoframe.net>
Message-ID: <loom.20081012T011928-869@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> The premise that the patch you apply as part of the specfile build is
> the same one you should be submitting upstream is faulty.
[snip]
> Won't happen if you're only patching configure and Makefile.in, as you
> should.

If your original change was on configure.ac and Makefile.am and you're only 
shipping the patch for the generated configure and Makefile.in, you're 
violating the GPL.

> There can be all sorts of reasons for that.  But packagers faced with an
> uncooperative upstream need to learn to live with the reality that their
> package will be harder to maintain.  It should not be considered
> acceptable behavior for packagers to punt and create work for the poor
> guy who drew the short straw for the libtool (or whatever, as the case
> may be) upgrade.

I don't see why this should be handled any differently from a new GCC version, 
where the GCC maintainer will help with actual GCC bugs and in with diagnosing 
some non-obvious problems, and also do a mass rebuild and report the results, 
but ultimately it's the maintainer of the affected package who is responsible 
for getting it to build with the latest GCC.

Still, it should be up to the maintainer to decide on the tradeoff (i.e. on 
what's more work: forward-porting the patch for the generated files or getting 
the package to build with newer libtool/auto*/... versions), and the autotools 
maintainers should expect their new versions to break things and so handle them 
like new GCC versions.

> > (This is exactly why generated files in source tarballs are a major PITA
> > and the autotools are broken by design.)
> 
> Yes, this sort of whining is *really* productive.

It's not whining, it's a statement of fact.

        Kevin Kofler



From braden at endoframe.com  Sun Oct 12 01:35:10 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 11 Oct 2008 21:35:10 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081012T011207-253@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
Message-ID: <1223775310.13589.392.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 01:19 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > Many one-liner Makefile.am patches are also one-liner Makefile.in
> > patches when Makefile.in is modified manually.  There's no reason to be
> > shy about doing that.
> 
> He explicitly explained that in his case the Makefile.in change was NOT a 
> one-liner. And I've seen that many times: Just add an additional source file (a 
> one-line Makefile.am change) and watch how much Makefile.in changes.

I wasn't contesting the reality of that scenario. I was merely pointing
out that Makefile.am changes aren't always so explosive; and how where
they aren't, noise generated from generating Makefile.in with a
different version of automake than upstream used can be avoided.

But in any case, who really cares if the patch is big as long as the
changes are necessary and appropriate?

> > Because even if you're perfectly capable using the
> > autotools, you're still exposing the package to potential breakage when
> > it gets rebuilt with a newer version of the tools.
> 
> Newsflash: We're "exposing" all packages "to potential breakage" all the time 
> when they "get rebuilt with a newer version of the" GCC and Binutils "tools". 
> So what are you going to suggest next: packaging upstream's binaries? :-/

We can do without the strawman.

> So how are the autotools different from GCC and Binutils?

Source packages produced by an autotools build are designed to be
buildable in the absence of the autotools themselves.  They are not
designed to be buildable without a compiler and POSIX environment.

Did that really have to be said?

> I wonder if we shouldn't even start treating generated autotools files the same 
> way as binary JARs (for which the packaging guidelines mandate that they have 
> to be removed and rebuilt from source). They're all generated files.

Probably the reason there is no guideline treating all generated files
the same way is that doing so is a really dumb idea.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From selinux at gmail.com  Sun Oct 12 01:38:28 2008
From: selinux at gmail.com (Tom London)
Date: Sat, 11 Oct 2008 18:38:28 -0700
Subject: Heads up on ext4 changes
In-Reply-To: <48F14D1E.6000805@redhat.com>
References: <48EE016E.8050407@redhat.com> <48EF9E81.4020403@redhat.com>
	<48EFA88F.7000105@redhat.com>
	<4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>
	<48F11E95.8040401@redhat.com>
	<4c4ba1530810111515h5b7693b2n37cc55b57236bf97@mail.gmail.com>
	<48F14D1E.6000805@redhat.com>
Message-ID: <4c4ba1530810111838oacacd80o74bca0f26de41810@mail.gmail.com>

On Sat, Oct 11, 2008 at 6:04 PM, Eric Sandeen <sandeen at redhat.com> wrote:
> Tom London wrote:
>>
>
>> Anyway, I can mount manually for now. Sorry I couldn't quickly figure
>> out what was doing this.....
>>
>> tom
>
> Actually, I wasn't thinking; hal uses udev not blkid; udev will also
> need updates.  Registering both fs types will help, I'll get that done soon.
>
> /me wishes the ext4dev thing had never come into existence right about now.
>
> But we'll get it fixed up.
>
> Thanks,
> -Eric
>
OK, this is getting spooky....

After "forcing" gnome-mount (via "gnome-mount -d /dev/sdb1 --fstype
ext4"), and unmounting (via gnome-mount -u), I rebooted and forgot to
power off/unplug the USB drive.

After gdm login, the system had no problem mounting the ext4
filesystem (/media/Backup1 was "just there").

Now, each time I "plug in" the USB drive, it just automagically mounts
the ext4 FS without any complaints or problems.

I can only guess that something was "caching" the filesystem type
(udev?) somewhere....

On the up side, this is now "just working" for me.  On the down side,
not sure I can help debug this any longer....

Make sense to you?

tom
-- 
Tom London



From sandeen at redhat.com  Sun Oct 12 01:44:14 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 11 Oct 2008 20:44:14 -0500
Subject: Heads up on ext4 changes
In-Reply-To: <4c4ba1530810111838oacacd80o74bca0f26de41810@mail.gmail.com>
References: <48EE016E.8050407@redhat.com>
	<48EF9E81.4020403@redhat.com>	<48EFA88F.7000105@redhat.com>	<4c4ba1530810111219m6045bd76ue7888f6e28060511@mail.gmail.com>	<48F11E95.8040401@redhat.com>	<4c4ba1530810111515h5b7693b2n37cc55b57236bf97@mail.gmail.com>	<48F14D1E.6000805@redhat.com>
	<4c4ba1530810111838oacacd80o74bca0f26de41810@mail.gmail.com>
Message-ID: <48F1566E.7000909@redhat.com>

Tom London wrote:

> OK, this is getting spooky....
> 
> After "forcing" gnome-mount (via "gnome-mount -d /dev/sdb1 --fstype
> ext4"), and unmounting (via gnome-mount -u), I rebooted and forgot to
> power off/unplug the USB drive.
> 
> After gdm login, the system had no problem mounting the ext4
> filesystem (/media/Backup1 was "just there").
> 
> Now, each time I "plug in" the USB drive, it just automagically mounts
> the ext4 FS without any complaints or problems.
> 
> I can only guess that something was "caching" the filesystem type
> (udev?) somewhere....
> 
> On the up side, this is now "just working" for me.  On the down side,
> not sure I can help debug this any longer....
> 
> Make sense to you?
> 
> tom

I'm honestly not as up to speed on udev as I probably should be, but
I've seen Ted make references before to needing reboots before new
filesystems can be recognized via udev... perhaps it's the same thing.

-Eric



From kevin.kofler at chello.at  Sun Oct 12 02:25:42 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 02:25:42 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
Message-ID: <loom.20081012T021105-415@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> But in any case, who really cares if the patch is big as long as the
> changes are necessary and appropriate?

A big patch is a patch which touches many locations and that is a patch which 
easily breaks when upstream makes any changes to their source code.

> We can do without the strawman.

I don't see how comparing the situation to GCC and Binutils is a strawman, 
they're all translators which take a source file as input and generate an 
output file.

> > So how are the autotools different from GCC and Binutils?
> 
> Source packages produced by an autotools build are designed to be
> buildable in the absence of the autotools themselves.  They are not
> designed to be buildable without a compiler and POSIX environment.

That distinction is artificial, you're defining "building" to include the 
compilation step for the code, but not the one for the build system. The only 
difference I can see between the autotools and a compiler is that the 
compiler's output is platform-specific (meaning you have to build from source 
for portability), but take Java/OpenJDK/IcedTea as the example and that 
distinction vanishes. Java binaries are "designed" to not need rebuilding at 
all, so should we just ship them from binaries?

No matter how you spin the definitions, generated files are _not_ source code.

> Probably the reason there is no guideline treating all generated files
> the same way is that doing so is a really dumb idea.

And why?

Now, banning all generated files is probably unnecessarily radical (there may 
be some valid reasons for them, even if I disagree about there being such valid 
reasons in the case of the autotools, as most of the alternatives do fine 
without shipped generated files), but that still doesn't mean you should blame 
maintainers for doing their modifications on the actual source code (which is, 
after all, the "preferred form for modification" under the GPL's definition) 
rather than some autogenerated file. Generated files are not meant to be 
edited.

        Kevin Kofler



From Matt_Domsch at dell.com  Sun Oct 12 02:54:17 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sat, 11 Oct 2008 21:54:17 -0500
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <20081012012428.GN10204@angus.ind.WPI.EDU>
References: <48F0C1CE.30104@BitWagon.com> <48F14FEB.20406@BitWagon.com>
	<20081012012428.GN10204@angus.ind.WPI.EDU>
Message-ID: <20081012025417.GA22225@auslistsprd01.us.dell.com>

On Sat, Oct 11, 2008 at 09:24:28PM -0400, Chuck Anderson wrote:
> On Sat, Oct 11, 2008 at 06:16:27PM -0700, John Reiser wrote:
> > About 2230 UTC on Sat.Oct.11, the 67 leeches finished within a few minutes
> > of each other.  The torrents started about 0000 UTC.  So it took more than 22 hours
> > to distribute the 67 copies of 726MB of data.  That is approx. 10KB/s for each,
> > on average, which is very slow.  The expected speed is at least 10 times as fast.
> >
> > One theory is deliberate throttling/choking somewhere.
> > Here's a [current] traceroute for two of my machines that were in the swarm
> > during those 22 hours [first few hops omitted due to paranoia]:
> 
> I'm pretty sure this was throttling done by torrent1.fedoraproject.org 
> itself.  I was coming in via Internet2, and I assume the reverse route 
> was also via Internet2 (which might be a bad assumption).

Looks symmetrical to me.

traceroute to 130.215.6.2 (130.215.6.2), 30 hops max, 40 byte packets
 1  152.46.7.254 (152.46.7.254)  0.915 ms  1.139 ms  1.359 ms
 2  rtp11-gw-to-ibiblio-gw.ncren.net (128.109.70.113)  0.248 ms  0.238 ms  0.215 ms
 3  rtp7600-gw-to-rtp11-gw-sec.ncren.net (128.109.70.122)  0.364 ms  0.382 ms  0.427 ms
 4  dep7600-gw2-to-rtp7600-gw.ncren.net (128.109.70.138)  3.401 ms  3.452 ms  3.534 ms
 5  internet2-to-dep7600-gw2.ncren.net (198.86.17.66)  19.154 ms  19.150 ms  19.195 ms
 6  ge-0-1-0.10.nycmng.abilene.ucaid.edu (64.57.28.7)  23.927 ms  23.909 ms  23.908 ms
 7  ge-1-3-0.666.rtr.atla.net.internet2.edu (64.57.28.18)  28.981 ms  28.940 ms  29.070 ms
 8  nox300gw1-Vl-110-NoX-INTERNET2.nox.org (192.5.89.221)  33.709 ms  42.725 ms  48.957 ms
 9  nox1sumgw1-Vl-803-NoX.nox.org (192.5.89.237)  33.796 ms  33.829 ms  33.856 ms
10  nox1sumgw1-PEER-NoX-WPI-192-5-89-42.nox.org (192.5.89.42)  33.988 ms !X  34.042 ms !X  34.080 ms !X


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



From lists at ralii.com  Sun Oct 12 03:12:38 2008
From: lists at ralii.com (Robert Locke)
Date: Sat, 11 Oct 2008 23:12:38 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>
	<4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>
Message-ID: <1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>


On Sat, 2008-10-11 at 19:21 -0300, Henrique Junior wrote:
> Hi,
> As a desktop, Fedora is the best solution. Should I use the best 2nd
> solution? (Ubuntu).
> Maybe if we take *some* releases to LLT, lets say, Fedora N, Fedora
> N+4. The intermediary releases will be "non LLT".... Well, I know that
> Fedora have to worry about all releases, but if we have few people to
> work it should be one point.
> Maybe it looks crazy.
> 
> P.S.: I'm sorry for my poor english.

But, isn't that exactly what RHEL/CentOS are?  RHEL/CentOS 3 were based
on Red Hat Linux 9, RHEL/CentOS 4 were based on Fedora Core 3,
RHEL/CentOS 5 were based on Fedora Core 6.  I presume that RHEL/CentOS 6
will be based around Fedora 10 or 11....  So, RHEL/CentOS are the Long
Term solution for Fedora.

What I think is lacking (but seem to be being worked on), is a
convenient "upgrade" process within the "family".  So that if I use
Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
comes out.

Historically, using RHEL/CentOS for desktop has been problematic for
some given their "stability" and "lack of movement".  But it does appear
that this is changing.  Looking at RHEL/CentOS 5.2 compared to 5.0,
there are some actual version upgrades to some of the packages, so
perhaps it becomes more feasible for more people as a desktop.

--Rob




From mmcgrath at redhat.com  Sun Oct 12 03:49:33 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Sat, 11 Oct 2008 22:49:33 -0500 (CDT)
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <200810120143.24733.opensource@till.name>
References: <48F0C1CE.30104@BitWagon.com> <20081011205506.GI2305@br-online.de>
	<alpine.LFD.1.10.0810111558450.25949@laptop.mmcgrath.net>
	<200810120143.24733.opensource@till.name>
Message-ID: <alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>

On Sun, 12 Oct 2008, Till Maas wrote:

> On Sat October 11 2008, Mike McGrath wrote:
>
> > I'm testing from another host in the EU right now and I'm getting
> > somewhere around 3090.3 KB/s.  I'm all for quicker torrent downloads so if
> > y'all want to stop by #fedora-admin and chat it up perhaps we can come up
> > with a fix or better guidelines on how to use torrent or something.
>
> We need more seeds at the beginning and more people with access to the isos.
> Dennis Gilmore finally managed to acquire the isos somehow and seeded them
> and this made it possible for everybody else to download them, too.
>

I'll have a talk with Jesse.  For the normal releases we typically have
multiple seeders from the start.  For these sorts of snapshots I suspect
some steps can be taken to ensure better usability here.  I talked with
Seth a bit about this too (he's our current torrent wrangler) and we
generally think this was just an issue with two many chunks and not enough
people for chunks from the beginning.  Which is self correcting but A)
is annoying and B) is preventable in the future.  We just have to figure
out the procedure on it.

Feel free to stop by #fedora-admin with ideas.  It might just be something
as simple as providing the iso somewhere for a specified time then
removing, allowing people to seed properly.  I like this because it keeps
with the community model, allows people to get involved for these sorts of
releases, and fixes the "slow to start" problem.

	-Mike



From braden at endoframe.com  Sun Oct 12 04:04:13 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 12 Oct 2008 00:04:13 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081012T011928-869@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<loom.20081011T182618-279@post.gmane.org>
	<1223759337.13589.344.camel@hinge.endoframe.net>
	<loom.20081012T011928-869@post.gmane.org>
Message-ID: <1223784253.13589.413.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 01:27 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > The premise that the patch you apply as part of the specfile build is
> > the same one you should be submitting upstream is faulty.
> [snip]
> > Won't happen if you're only patching configure and Makefile.in, as you
> > should.
> 
> If your original change was on configure.ac and Makefile.am and you're only 
> shipping the patch for the generated configure and Makefile.in, you're 
> violating the GPL.

Please actually read the licenses for the tools before making such
inflammatory accusations.  You're completely wrong.

Neither autoconf nor automake place restrictions on the use of their
output.  While a project could conceivably apply the GPL to its
configure and Makefile.in(s), I've never seen a project do that.  It
would be, to say the least, unusual.

> > There can be all sorts of reasons for that.  But packagers faced with an
> > uncooperative upstream need to learn to live with the reality that their
> > package will be harder to maintain.  It should not be considered
> > acceptable behavior for packagers to punt and create work for the poor
> > guy who drew the short straw for the libtool (or whatever, as the case
> > may be) upgrade.
> 
> I don't see why this should be handled any differently from a new GCC version, 
> where the GCC maintainer will help with actual GCC bugs and in with diagnosing 
> some non-obvious problems, and also do a mass rebuild and report the results, 
> but ultimately it's the maintainer of the affected package who is responsible 
> for getting it to build with the latest GCC.

It's different because such a situation is rather easy to avoid.

> Still, it should be up to the maintainer to decide on the tradeoff (i.e. on 
> what's more work: forward-porting the patch for the generated files or getting 
> the package to build with newer libtool/auto*/... versions), and the autotools 
> maintainers should expect their new versions to break things and so handle them 
> like new GCC versions.

There's no reason for the autotools maintainers to expect their releases
to break clients of autotools source packages because those packages are
designed to be usable without the autotools themselves.  Clients who opt
to ignore or subvert this functionality do so at their own risk.  It
becomes a problem for everyone else--and thus justifies a
guideline--when the risk incurred poses an impediment to the progress of
Fedora in general (in this particular case, upgrading libtool).

> > > (This is exactly why generated files in source tarballs are a major PITA
> > > and the autotools are broken by design.)
> > 
> > Yes, this sort of whining is *really* productive.
> 
> It's not whining, it's a statement of fact.

Asserting that the autotools are "broken by design" because their use
results in the distribution of generated files is simply your opinion.
The notion that source distributions should not include generated files
is certainly not something that is generally accepted as fact.  In fact,
the number of packages that do include generated files suggests that
your viewpoint is unorthodox.  The inability to differentiate dogmatic
opinion from objective fact is a characteristic of zealotry.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From braden at endoframe.com  Sun Oct 12 04:34:06 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 12 Oct 2008 00:34:06 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081012T021105-415@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
Message-ID: <1223786046.13589.436.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 02:25 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > But in any case, who really cares if the patch is big as long as the
> > changes are necessary and appropriate?
> 
> A big patch is a patch which touches many locations and that is a patch which 
> easily breaks when upstream makes any changes to their source code.

Sure, but we're talking about a patch that was generated from generated
code. It's easy enough to generate again.  Any changes to the source
files are no harder to integrate than they would be otherwise.

> > We can do without the strawman.
> 
> I don't see how comparing the situation to GCC and Binutils is a strawman, 
> they're all translators which take a source file as input and generate an 
> output file.

Well, I'm reasonably sure most persons reading this who are familiar
with the issues do see it.

> > > So how are the autotools different from GCC and Binutils?
> > 
> > Source packages produced by an autotools build are designed to be
> > buildable in the absence of the autotools themselves.  They are not
> > designed to be buildable without a compiler and POSIX environment.
> 
> That distinction is artificial, you're defining "building" to include the 
> compilation step for the code, but not the one for the build system.

I'm defining "building" to include whatever steps are *necessary* to
generate an RPM.  Rebuilding the build system scripts is not necessary
and can, in general, be avoided.  Avoiding this step is desirable
because undertaking it causes well-documented problems.

>  The only 
> difference I can see between the autotools and a compiler is that the 
> compiler's output is platform-specific (meaning you have to build from source 
> for portability), but take Java/OpenJDK/IcedTea as the example and that 
> distinction vanishes. Java binaries are "designed" to not need rebuilding at 
> all, so should we just ship them from binaries?

We seem to have drifted off into bizarro world.  Fedora's choice of how
to package Java impacts the issues here precisely nil.

You seem to have some notions of ideological purity about what packages
should contain and you're going to great argumentative lengths to ram
those notions down fedora-devel's collective throat.  What's missing
from your arguments is any characterization of a problem that gets
solved when we do it Your Way.

The guideline I've suggested (and apparently I'm not the first) is a
response to a real problem: stuff is broken and it wouldn't be broken if
the guideline had been followed.  You have not proposed an alternative
solution to the problem.  Rather, your position seems to be that the
breakage is simply acceptable.  Obviously, I disagree.  I think that
because it can be avoided, it should be.

> No matter how you spin the definitions, generated files are _not_ source code.
> 
> > Probably the reason there is no guideline treating all generated files
> > the same way is that doing so is a really dumb idea.
> 
> And why?

Indulging this question is beyond the scope of this thread.  The
guideline I'm proposing operates within the current ideological
framework, where patching files that happen to have been generated is
perfectly socially acceptable.  If you would like to propose a guideline
that changes that, feel free to do so; but please do have the courtesy
to pursue it in a new thread.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From skvidal at fedoraproject.org  Sun Oct 12 04:36:50 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sun, 12 Oct 2008 00:36:50 -0400
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com> <20081011205506.GI2305@br-online.de>
	<alpine.LFD.1.10.0810111558450.25949@laptop.mmcgrath.net>
	<200810120143.24733.opensource@till.name>
	<alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>
Message-ID: <1223786210.27425.31.camel@rosebud>

On Sat, 2008-10-11 at 22:49 -0500, Mike McGrath wrote:
> On Sun, 12 Oct 2008, Till Maas wrote:
> 
> > On Sat October 11 2008, Mike McGrath wrote:
> >
> > > I'm testing from another host in the EU right now and I'm getting
> > > somewhere around 3090.3 KB/s.  I'm all for quicker torrent downloads so if
> > > y'all want to stop by #fedora-admin and chat it up perhaps we can come up
> > > with a fix or better guidelines on how to use torrent or something.
> >
> > We need more seeds at the beginning and more people with access to the isos.
> > Dennis Gilmore finally managed to acquire the isos somehow and seeded them
> > and this made it possible for everybody else to download them, too.
> >
> 
> I'll have a talk with Jesse.  For the normal releases we typically have
> multiple seeders from the start.  For these sorts of snapshots I suspect
> some steps can be taken to ensure better usability here.  I talked with
> Seth a bit about this too (he's our current torrent wrangler) and we
> generally think this was just an issue with two many chunks and not enough
> people for chunks from the beginning.  Which is self correcting but A)
> is annoying and B) is preventable in the future.  We just have to figure
> out the procedure on it.
> 

If we have a spare site with lots of bandwidth to spare and works with
torrents we can set it up to be a second seed for whatever. 

automating it will be an ugh but not undoable.

-sv




From ravenoak at virtualxistenz.com  Sun Oct 12 05:28:20 2008
From: ravenoak at virtualxistenz.com (Caitlyn O'Hanna)
Date: Sat, 11 Oct 2008 22:28:20 -0700
Subject: Bodhi error while doing a 'make update', and now I can't make an
	update for that tag
Message-ID: <1223789300.9768.12.camel@himiko.beav.virtualxistenz.com>

I attempted to push my update via the command line, and encountered an
error from Bodhi while doing a 'make update'.  Now, I can't push the
update via the web interface as it says the update exists, but it isn't
listed with my other updates.  If I click on the link the error
provides, it says that there isn't an update.  The tag for my update is
pysvn-1_6_1-2_fc9.

Looking at the bug reports for Bodhi, it looks like I should have put
just 'B' in the type field and not 'bugfix' as the template lead me to
believe.

Is there anything I can do to unclog this?  Thanks for any help.


--Caitlyn



From wtogami at redhat.com  Sun Oct 12 05:39:31 2008
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 12 Oct 2008 01:39:31 -0400
Subject: Possible to default to KDE?
In-Reply-To: <48EE9423.4000203@fedoraproject.org>
References: <48ED6823.5000901@redhat.com>	<d25f375f0810091107m317280cse6da396a3008b663@mail.gmail.com>	<16de708d0810091123s44dbb79es96002d2be3e955f@mail.gmail.com>
	<48EE9423.4000203@fedoraproject.org>
Message-ID: <48F18D93.1020305@redhat.com>

Rahul Sundaram wrote:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=64966
> 
> Rahul
> 

What config files does system-switch-displaymanager change?  Only 
/etc/sysconfig/desktop?

Warren



From rc040203 at freenet.de  Sun Oct 12 06:09:46 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 12 Oct 2008 08:09:46 +0200
Subject: Regarding install options
In-Reply-To: <1223677870.4410.185.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
Message-ID: <1223791786.3564.1322.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 15:31 -0700, Jesse Keating wrote:
> On Sat, 2008-10-11 at 00:25 +0200, Ralf Corsepius wrote:
> > > Great, now get consensus on what 'minimal' should be.
> > shell + networking.
> > 
> > Approximately the set of packages required for a networked install.
> 
> And does that include the ability to add more later?
Sure, yum + rpm are a requirement.

Ralf
 



From rc040203 at freenet.de  Sun Oct 12 06:17:13 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 12 Oct 2008 08:17:13 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223666666.7707.13.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223664677.27225.12.camel@atropine.boston.devel.redhat.com>
	<48EFA7EC.6000607@gmail.com>
	<1223666666.7707.13.camel@atropine.boston.devel.redhat.com>
Message-ID: <1223792233.3564.1328.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 15:24 -0400, Adam Jackson wrote:
> On Fri, 2008-10-10 at 12:07 -0700, Toshio Kuratomi wrote:
> > Adam Jackson wrote:
> > > On Fri, 2008-10-10 at 11:31 -0700, Toshio Kuratomi wrote:
> > >> Hand coding Makefiles to compile shared libraries on all platforms is .
> > >>  Before libtools many upstreams simply wouldn't package shared libraries
> > >> because of all the problems with getting it right for SunOS, Solaris,
> > >> OpenBSD, NetBSD, i386BSD, FreeBSD, AIX, Linux-aout, Linux-elf, gcc, acc,
> > >> etc.  If the state of the art has advanced and there's a tool that can
> > >> replace libtool so a developer can say "I want a shared library" and the
> > >> tool builds it on all platforms then we could look into getting
> > >> upstreams to switch but simply getting rid of libtool in favour of
> > >> handcoding Makefiles to build shared libraries is a step in the wrong
> > >> direction.
> > > 
> > > The state of the art is "gcc -shared".
> > > 
> > So gcc is the compiler everywhere these days?  Note this is a genuine
> > question -- I haven't used anything besides Linux in so long I don't
> > know whether Sun or anyone else is shipping their own C compiler anymore.
> 
> Sun cc is pretty similar, but solaris has gcc installed well over half
> the time anyway.  *BSD and OSX are all gcc,
Though these beasts are GCC variants, they actually are quite different
from Linux-vendor's GCCs or FSF GCC.

>  Windows is effectively gcc
> for open source projects, and there are no other operating systems.
> 
> Most of the complexity in libtool (and autotools in general) is to
> support systems that simply are not worth supporting and that
> practically speaking don't exist anymore.
Ouch! Supporting different compilers is very small detail in libtool
(and the autotools in general). They do a lot more.

Ralf




From rc040203 at freenet.de  Sun Oct 12 06:22:51 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 12 Oct 2008 08:22:51 +0200
Subject: CMake!
In-Reply-To: <loom.20081010T213933-101@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
Message-ID: <1223792571.3564.1335.camel@beck.corsepiu.local>

On Fri, 2008-10-10 at 22:39 +0000, Kevin Kofler wrote:
> Callum Lerwick <seg <at> haxxed.com> writes:
> >
> > On Fri, 2008-10-10 at 15:56 -0400, Braden McDaniel wrote:
> > > 
> > > If you want upstream to stop using libtool altogether, find a suitable  
> > > replacement and convince the Automake developers to use it instead.
> > 
> > Why the h8? He was speaking in the context of "the state of the art" and
> > in my oh-so-humble opinion CMake is it. The whole of the Autotools stack
> > is very much... not.
> 
> +1
> 
> The suggestion to convince the automake developers to use something other than 
> libtool is pointless, because automake should also go away, it's at least as 
> obsolete, buggy, unable to maintain backwards compatibility, annoying, a 
> massive time waster at build time and a major PITA for developers to code with 
> as libtool is. The whole autotools stack sucks. It always did, we just didn't 
> have anything better. We now do, so why are people still using autotools?
Because there are no better alternatives.

Ralf




From rc040203 at freenet.de  Sun Oct 12 06:25:34 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 12 Oct 2008 08:25:34 +0200
Subject: CMake!
In-Reply-To: <20081010232042.GA32721@tango.0pointer.de>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
Message-ID: <1223792734.3564.1340.camel@beck.corsepiu.local>

On Sat, 2008-10-11 at 01:20 +0200, Lennart Poettering wrote:
> On Fri, 10.10.08 22:39, Kevin Kofler (kevin.kofler at chello.at) wrote:
> 
> > > > If you want upstream to stop using libtool altogether, find a
> > > > suitable replacement and convince the Automake developers to use
> > > > it instead.
> > > 
> > > Why the h8? He was speaking in the context of "the state of the
> > > art" and in my oh-so-humble opinion CMake is it. The whole of the
> > > Autotools stack is very much... not.
> > 
> > +1
> > 
> > The suggestion to convince the automake developers to use something
> > other than libtool is pointless, because automake should also go
> > away, it's at least as obsolete, buggy, unable to maintain backwards
> > compatibility, annoying, a massive time waster at build time and a
> > major PITA for developers to code with as libtool is. The whole
> > autotools stack sucks. It always did, we just didn't have anything
> > better. We now do, so why are people still using autotools?
> 
> I actually like autotools.
+1

> Oh, and I think that cmake is a big trainwreck.
I share this view. Cmake is imake in new clothes and suffers from the
same design flaws as imake did. It's only the limited set of
requirements being used by the limited set of use cases it's proponents
apply which lets them think "cmake is better".

Ralf




From fedora at leemhuis.info  Sun Oct 12 07:55:26 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 12 Oct 2008 09:55:26 +0200
Subject: Package review backlog.
In-Reply-To: <1223737655.6770.251.camel@macbook.infradead.org>
References: <loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<48F07C5C.8000403@leemhuis.info>
	<1223737655.6770.251.camel@macbook.infradead.org>
Message-ID: <48F1AD6E.9000602@leemhuis.info>

On 11.10.2008 17:07, David Woodhouse wrote:
> On Sat, 2008-10-11 at 12:13 +0200, Thorsten Leemhuis wrote:
>> Nice idea, but for me that sounds like a pre-election promise to lower
>> taxes or like big and rich politicians handling out food in a soup 
>> kitchen or a: It will help a few people and gives good press because 
>> it's popular, but it doesn't solve the underlying problem at all. In 
>> fact it's even worse, because time gets wasted instead of solving the 
>> underlying or other problems (that might be bigger or smaller).
> I don't think I'm up for election this time round, and I hope it didn't
> come across that way.

Nope, it did not.

And just to make things clear: I didn't do much reviews(?) when I was in 
FESCo (and it was round about the same before and after being in FESCo) 
-- I think I invested my time in different areas and it was IMHO 
definitely the right thing to do.

(?) In fact, by todays standard I wouldn't even considered to become a 
sponsor

> [...] I certainly didn't mean it as some kind of
> measure by which FESCo members' performance would be measured.

But I suppose some people will sooner or later just use those statements 
in the meetings to do that.

> [...]
> By getting FESCo members more involved in reviews, we should help to
> raise the profile of package review and set a good example;

Sure, that is something good. But packaging is just one aspect of the 
whole game and thus I think the rule you proposed distract some of the 
people from other important issues. Especially when people start to look 
at the "# of reviews during the last FESCo term" when the FESCo members 
runs for re-election.

> [...] And it should mean that some of the
> existing proposals for making reviews run smoother would get a little
> bit more attention too, and thus get pushed through to reality.

Maybe. But I tend to think you get to a better results quicker if a few 
people (that don't have to be in FESCo; it just makes things easier if 
at least two people from FESCo are part of the effort) that are familiar 
with reviewing and the guidelines work out improvements for the review 
process.


Cu
knurd



From nicolas.mailhot at laposte.net  Sun Oct 12 08:09:57 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 12 Oct 2008 10:09:57 +0200
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223775310.13589.392.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
Message-ID: <1223798997.9402.5.camel@arekh.okg>

Le samedi 11 octobre 2008 ? 21:35 -0400, Braden McDaniel a ?crit :
> On Sun, 2008-10-12 at 01:19 +0000, Kevin Kofler wrote:

> > I wonder if we shouldn't even start treating generated autotools files the same 
> > way as binary JARs (for which the packaging guidelines mandate that they have 
> > to be removed and rebuilt from source). They're all generated files.
> 
> Probably the reason there is no guideline treating all generated files
> the same way is that doing so is a really dumb idea.

Probably the reason there is no guideline treating all generated files
the same way is some groups of packagers are lazier than others.

See, I can make inflamatory comments too.

IMHO there is no reason to allow any pre-generated file except when the
generating chain is not packaged in Fedora. As Kevin wrote refusing to
re-generate files because of peotential breakage is only papering over
tool bugs. Also it's legaly borderline for everything which is (L)GPL.

-- 
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/20081012/4a3548ab/attachment.sig>

From tibbs at math.uh.edu  Sun Oct 12 08:30:32 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 12 Oct 2008 03:30:32 -0500
Subject: Package review backlog.
In-Reply-To: <1223737587.3923.29.camel@wicktop.localdomain>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com>
	<1223731515.3923.23.camel@wicktop.localdomain>
	<48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>
	<1223737587.3923.29.camel@wicktop.localdomain>
Message-ID: <ufaprm6cj13.fsf@epithumia.math.uh.edu>

>>>>> "CW" == Christoph Wickert <christoph.wickert at googlemail.com> writes:

CW> I know this one, but this page also returns reviews that are
CW> already assigned.

Only a very small number; trivial to ignore them if that's what you
want.

CW> And if somebody assigns a review to himself I assume that he's
CW> doing it.

Well, they should set the flag in that case.  (Yes, there are too many
things to set.  But often I'll go and set the flag.)

Honestly I can't imagine that the report becomes measurably less
useful because a small handful of the tickets have something other
than "(Nobody)" in the "Assignee" column.

 - J<



From nicolas.mailhot at laposte.net  Sun Oct 12 08:30:36 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 12 Oct 2008 10:30:36 +0200
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223786046.13589.436.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
Message-ID: <1223800236.9402.13.camel@arekh.okg>

Le dimanche 12 octobre 2008 ? 00:34 -0400, Braden McDaniel a ?crit :
> On Sun, 2008-10-12 at 02:25 +0000, Kevin Kofler wrote:

> > > > So how are the autotools different from GCC and Binutils?
> > > 
> > > Source packages produced by an autotools build are designed to be
> > > buildable in the absence of the autotools themselves.  They are not
> > > designed to be buildable without a compiler and POSIX environment.
> > 
> > That distinction is artificial, you're defining "building" to include the 
> > compilation step for the code, but not the one for the build system.
> 
> I'm defining "building" to include whatever steps are *necessary* to
> generate an RPM.  Rebuilding the build system scripts is not necessary
> and can, in general, be avoided.  Avoiding this step is desirable
> because undertaking it causes well-documented problems.

So if Oracle was freely redistributable tomorrow an rpm that just put
the pre-generated Oracle files in the right place would be ok with you?

Fedora is about free software and that means the ability to rebuild
everything from the ground up even when upstream disagrees or when it's
inconvenient to do so. When all is said you can never be 100% sure this
ability is retained unless you perform the full rebuild steps in the
spec file yourself.

-- 
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/20081012/8b6874b3/attachment.sig>

From sundaram at fedoraproject.org  Sun Oct 12 08:57:06 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 12 Oct 2008 14:27:06 +0530
Subject: Package warning - Rawhide
Message-ID: <48F1BBE2.5050406@fedoraproject.org>

Hi,

The PackageKit warning for every single unsigned package - which happens 
to be everything in rawhide is just plain annoying. Can't we do 
something nice about that?

Rahul



From rc040203 at freenet.de  Sun Oct 12 09:14:53 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 12 Oct 2008 11:14:53 +0200
Subject: Package warning - Rawhide
In-Reply-To: <48F1BBE2.5050406@fedoraproject.org>
References: <48F1BBE2.5050406@fedoraproject.org>
Message-ID: <1223802893.3564.1345.camel@beck.corsepiu.local>

On Sun, 2008-10-12 at 14:27 +0530, Rahul Sundaram wrote:
> Hi,
> 
> The PackageKit warning for every single unsigned package - which happens 
> to be everything in rawhide is just plain annoying. Can't we do 
> something nice about that?
The rationale for exposing users to the risks of using unsigned packages
has always escaped me, even less in the light of "The incident".

I.e. IMO, the "only correct  approach" would be to only have signed
packages in rawhide.

Ralf





From braden at endoframe.com  Sun Oct 12 09:19:27 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 12 Oct 2008 05:19:27 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223800236.9402.13.camel@arekh.okg>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<1223800236.9402.13.camel@arekh.okg>
Message-ID: <1223803167.13589.457.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 10:30 +0200, Nicolas Mailhot wrote:
> Le dimanche 12 octobre 2008 ? 00:34 -0400, Braden McDaniel a ?crit :
> > On Sun, 2008-10-12 at 02:25 +0000, Kevin Kofler wrote:
> 
> > > > > So how are the autotools different from GCC and Binutils?
> > > > 
> > > > Source packages produced by an autotools build are designed to be
> > > > buildable in the absence of the autotools themselves.  They are not
> > > > designed to be buildable without a compiler and POSIX environment.
> > > 
> > > That distinction is artificial, you're defining "building" to include the 
> > > compilation step for the code, but not the one for the build system.
> > 
> > I'm defining "building" to include whatever steps are *necessary* to
> > generate an RPM.  Rebuilding the build system scripts is not necessary
> > and can, in general, be avoided.  Avoiding this step is desirable
> > because undertaking it causes well-documented problems.
> 
> So if Oracle was freely redistributable tomorrow an rpm that just put
> the pre-generated Oracle files in the right place would be ok with you?

Getting to this question from what I said requires so many logical leaps
that it's not worth entertaining.

> Fedora is about free software and that means the ability to rebuild
> everything from the ground up even when upstream disagrees or when it's
> inconvenient to do so. When all is said you can never be 100% sure this
> ability is retained unless you perform the full rebuild steps in the
> spec file yourself.

Are you claiming that by creating tarballs that are designed to be used
without having the autotools installed, the GNU build system is
impairing free software?

"Ground" level is the upstream source provided by the developer.
Applying necessary patches to the build scripts in order to build
binaries does not make anything less free.

If a packager wants to include changes to the build script sources in
the source RPM, I have absolutely no objection to that.  But applying
those changes as part of the build wins nothing and invites breakage.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From opensource at till.name  Sun Oct 12 09:25:11 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 11:25:11 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081011232449.GD8235@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
Message-ID: <200810121125.17381.opensource@till.name>

On Sun October 12 2008, Patrice Dumas wrote:

> There is also the need for some infrastructure. (My proposal here was
> just to let the old branches live. At that time there was no packagedb,
> now with packagedb it would even be simpler.) Without infrastructure, it
> is not really worth gathering maintainers.

If you gather maintainers, you will probably also get people who can spare a 
machine to build up some infrastructure. Also you will easier get access to 
Fedora infrastructure. Or say to change your sentence:

Without interested people, it is not really worth preparing infrastructure.

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/20081012/6ba293da/attachment.sig>

From denis at poolshark.org  Sun Oct 12 09:26:40 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sun, 12 Oct 2008 11:26:40 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>
	<20081011205506.GI2305@br-online.de>	<alpine.LFD.1.10.0810111558450.25949@laptop.mmcgrath.net>	<200810120143.24733.opensource@till.name>
	<alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>
Message-ID: <48F1C2D0.2050403@poolshark.org>

Mike McGrath wrote:
> I'll have a talk with Jesse.  For the normal releases we typically have
> multiple seeders from the start.  For these sorts of snapshots I suspect
> some steps can be taken to ensure better usability here.  I talked with
> Seth a bit about this too (he's our current torrent wrangler) and we
> generally think this was just an issue with two many chunks and not enough
> people for chunks from the beginning.  Which is self correcting but A)
> is annoying and B) is preventable in the future.  We just have to figure
> out the procedure on it.

I'm not convinced by this explanation. If you know a little bit about 
the bittorrent protocol, the scenario of a fast uploader and about 40 
downloaders is literally a textbook example where bitorrent behaves at 
its best. Yet the algorithm broke down fairly quickly, as though the 
server pushed the chunks in linear order. That or something on the 
network got in the way.

As a precaution, could you try seeding using a different torrent client 
next time ? Transmission has a daemon mode that is quite nice 
(transmission-daemon and transmission-remote) for example.



From sundaram at fedoraproject.org  Sun Oct 12 09:27:30 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 12 Oct 2008 14:57:30 +0530
Subject: Package warning - Rawhide
In-Reply-To: <1223802893.3564.1345.camel@beck.corsepiu.local>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223802893.3564.1345.camel@beck.corsepiu.local>
Message-ID: <48F1C302.6000507@fedoraproject.org>

Ralf Corsepius wrote:
> On Sun, 2008-10-12 at 14:27 +0530, Rahul Sundaram wrote:
>> Hi,
>>
>> The PackageKit warning for every single unsigned package - which happens 
>> to be everything in rawhide is just plain annoying. Can't we do 
>> something nice about that?
> The rationale for exposing users to the risks of using unsigned packages
> has always escaped me, even less in the light of "The incident".
> 
> I.e. IMO, the "only correct  approach" would be to only have signed
> packages in rawhide.

I rarely find common ground with you but in this instance, I completely 
agree. Is time delay the reason behind not signing packages? There is a 
pretty big difference between unstable or development software packages 
and potentially trojaned ones. This is not just for rawhide. Many of us 
including me run rawhide for a large time of the Fedora development 
cycle, a security exploit in one of our machines via a bad rawhide 
mirror can result in malicious packages being pushed to stable 
repositories or other even worse issues. We should take this attack 
vector seriously.

Rahul



From rc040203 at freenet.de  Sun Oct 12 09:35:48 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 12 Oct 2008 11:35:48 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081011222850.GM10204@angus.ind.WPI.EDU>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
Message-ID: <1223804148.3564.1355.camel@beck.corsepiu.local>

On Sat, 2008-10-11 at 18:28 -0400, Chuck Anderson wrote:
> On Sun, Oct 12, 2008 at 12:17:05AM +0200, Patrice Dumas wrote:
> > On Sun, Oct 12, 2008 at 12:01:35AM +0200, Ralph Angenendt wrote:
> > > 
> > > It didn't work with the limited number of packages in 1, 2 and 3 - why (or
> > > how) should it work now with the much larger number of packages available
> > > for F9/10/11? The workload for maintaining legacy systems has increased 
> > > manyfold. Sure, the number of people involved also has increased, but ...
> > 
> > There are many other differences. We can use the rules of fedora (and
> > could use the infrastructure). And after the merging there are more
> > involvment of the community in maintaining packages. I was interested in
> > legacy at some point, but everything was so different than in fedora
> > extras that it deterred me.
> 
> There also doesn't need to be a requirement that every single package 
> in the Everything repo be maintained for a longer time.  We could 
> start with some of the spins, like Fedora spin, which contains most of 
> the "core" packages.  Interested contributors would need to commit to 
> support either their own packages for a longer term, or other packages 
> where the current Fedora maintainer doesn't want to do long term 
> maintenance.  This would be simlar to how EPEL works, but for Fedora 
> releases.

Similar proposals have come up several times before (I once proposed
something like this), but so far, they all had been shoot down so far.

Openly said, my impression that certain parties in Fedora fear a Fedora
LTS rsp. life-time-extended Fedora to compete with RH products.

Ralf
 



From pertusus at free.fr  Sun Oct 12 09:39:51 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 11:39:51 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <200810121125.17381.opensource@till.name>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
Message-ID: <20081012093951.GA3936@free.fr>

On Sun, Oct 12, 2008 at 11:25:11AM +0200, Till Maas wrote:
> On Sun October 12 2008, Patrice Dumas wrote:
> 
> > There is also the need for some infrastructure. (My proposal here was
> > just to let the old branches live. At that time there was no packagedb,
> > now with packagedb it would even be simpler.) Without infrastructure, it
> > is not really worth gathering maintainers.
> 
> If you gather maintainers, you will probably also get people who can spare a 
> machine to build up some infrastructure. Also you will easier get access to 
> Fedora infrastructure. Or say to change your sentence:
> 
> Without interested people, it is not really worth preparing infrastructure.

Look, saying 'yes, if you gather maintainers according to your plan,
we'll let you use the fedora infras, if you find someone willing to sign
your packages' doesn't cost any time. Gathering maintainers, just to
find that there is no infra in the end is very costly.

No infrastructure needs to be prepared. The existing one needs to be
kept (if it is done in the fedora scope). That's one very important
point of my plan, the no-cost infrastructure and no new community
organization.

--
Pat



From opensource at till.name  Sun Oct 12 09:40:33 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 11:40:33 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>
References: <48F0C1CE.30104@BitWagon.com>
	<200810120143.24733.opensource@till.name>
	<alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>
Message-ID: <200810121140.38773.opensource@till.name>

On Sun October 12 2008, Mike McGrath wrote:

> Seth a bit about this too (he's our current torrent wrangler) and we
> generally think this was just an issue with two many chunks and not enough
> people for chunks from the beginning.  Which is self correcting but A)
> is annoying and B) is preventable in the future.  We just have to figure
> out the procedure on it.

The question that still needs to be answered is, why torrent1 performed so 
badly. The second seed from Dennis Gilmore only provided 400 KB/s combined 
for every torrent. Then it took around 20 minutes for the majority of peers 
to complete the torrents. So the new seed made it a lot faster than only 
twice as fast. Also it was always visible that the peers exchanged every new 
chunk between them. I do not know which algorithm torrent1 uses to determine 
who it sends some chunks, but it somehow failed. I also noticed that the 
bittorrent protocol in general seems to fail to find the best distribution of 
chunks, because it seems that machines with a high upstream capacity do not 
get faster access to rare chunks or machines with low downstream capacity do 
not connect preferred to machines with low upstream capacity.

It would have been nice to have some details about to how many peers at which 
speeds torrent1 seeded his chunks, because even when it did not choke my 
client, it seeded only with 2 KB/s.
It took around 22 hours for the fastest torrents to distribute around 650 MB 
only from torrent one, which would be a total seeding speed of 8 KB/s.

> Feel free to stop by #fedora-admin with ideas.  It might just be something
> as simple as providing the iso somewhere for a specified time then
> removing, allowing people to seed properly.  I like this because it keeps
> with the community model, allows people to get involved for these sorts of
> releases, and fixes the "slow to start" problem.

There are three issues that should be solved imho:
1) The intial planned seeding should be fast enough
2) It should be easy to workaround any problems regarding 1)
3) Make debugging easier

For 1) I suggest to collect some interested people that are willing to seed 
the Snap1 and to debug the issues with torrent1.

For 2) maybe the isos could be copied were a large number of people around the 
world has access too, e.g. copy it on fedorapeople and give only sponsors 
read access to it.

To improve debugging, there should be statistics on how fast torrent1 seeds 
the new torrents, i.e. how fast to how many peers. This would also allow to 
easily notice if it disbehaves, which seems to have failed yesterday.

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/20081012/a9bd882f/attachment.sig>

From sundaram at fedoraproject.org  Sun Oct 12 09:49:51 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 12 Oct 2008 15:19:51 +0530
Subject: reviving Fedora Legacy
In-Reply-To: <1223804148.3564.1355.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<20081010144426.GC3236@free.fr>	<200810111658.49564.opensource@till.name>	<20081011213341.GA8235@free.fr>	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
Message-ID: <48F1C83F.5040200@fedoraproject.org>

Ralf Corsepius wrote:
> 
> Similar proposals have come up several times before (I once proposed
> something like this), but so far, they all had been shoot down so far.

It seems that there isn't enough people interested in doing the work. If 
there are, it is easy enough to form a SIG, demonstrate the interest and 
get others to endorse that effort.

> Openly said, my impression that certain parties in Fedora fear a Fedora
> LTS rsp. life-time-extended Fedora to compete with RH products.

That makes no sense. Red Hat's business is providing services on top of 
open source software. Fedora LTS wouldn't compete any better than one of 
binary compatible RHEL rebuilds. Vague accusations such as these are 
distinctly unhelpful. If you are going to make a claim, name the 
specific "certain parties in Fedora".

Rahul




From pertusus at free.fr  Sun Oct 12 10:02:48 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 12:02:48 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F1C83F.5040200@fedoraproject.org>
References: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
Message-ID: <20081012100248.GB3936@free.fr>

On Sun, Oct 12, 2008 at 03:19:51PM +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
>>
>> Similar proposals have come up several times before (I once proposed
>> something like this), but so far, they all had been shoot down so far.
>
> It seems that there isn't enough people interested in doing the work. If  
> there are, it is easy enough to form a SIG, demonstrate the interest and  
> get others to endorse that effort.

The interest will be very different depending whether we are allowed to
use the fedora infra at no cost or if we have to set up a whole new
infra. Saying 'use the infra if you find somebody to sign your package'
is much less costly than gathering packagers.

Doing a SIG although fedora infra won't be used is just pointless. And
yes, the right to use the fedora space was turned down.

--
Pat



From braden at endoframe.com  Sun Oct 12 10:05:59 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 12 Oct 2008 06:05:59 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223798997.9402.5.camel@arekh.okg>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<1223798997.9402.5.camel@arekh.okg>
Message-ID: <1223805959.13589.479.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 10:09 +0200, Nicolas Mailhot wrote:
> Le samedi 11 octobre 2008 ? 21:35 -0400, Braden McDaniel a ?crit :
> > On Sun, 2008-10-12 at 01:19 +0000, Kevin Kofler wrote:
> 
> > > I wonder if we shouldn't even start treating generated autotools files the same 
> > > way as binary JARs (for which the packaging guidelines mandate that they have 
> > > to be removed and rebuilt from source). They're all generated files.
> > 
> > Probably the reason there is no guideline treating all generated files
> > the same way is that doing so is a really dumb idea.
> 
> Probably the reason there is no guideline treating all generated files
> the same way is some groups of packagers are lazier than others.
> 
> See, I can make inflamatory comments too.

Our conclusions aren't mutually exclusive.  Quite the contrary, if we
suppose your analysis is spot-on, mine's true in spades.

> IMHO there is no reason to allow any pre-generated file except when the
> generating chain is not packaged in Fedora.

And as I pointed out to Kevin, you're free to pursue incorporation of
such a guiding principle into the packaging guidelines.  It's not there
now.  And furthermore, this mode of thinking is not reflected in a huge
number of packages.

>  As Kevin wrote refusing to
> re-generate files because of peotential breakage is only papering over
> tool bugs.

Whether you consider the use of obsolete constructs (or the obsolescence
itself) "bugs" is subjective.  But avoiding the unnecessary regeneration
of files is about avoiding problems rather than papering over them.  And
those problems are at least as likely to be in the package being built
as they are in the build tool.

>  Also it's legaly borderline for everything which is (L)GPL.

If there's any uncertainty about this, it's easily resolved by
distributing patches to the build script sources in the source RPM.  But
distributing them doesn't mean they have to be applied as part of the
build.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From rawhide at fedoraproject.org  Sun Oct 12 10:14:05 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 12 Oct 2008 10:14:05 +0000 (UTC)
Subject: rawhide report: 20081012 changes
Message-ID: <20081012101405.C9AC01F81DF@releng2.fedora.phx.redhat.com>

Compose started at Sun Oct 12 06:01:13 UTC 2008

New package notify-sharp
        A C# implementation for Desktop Notifications
New package sugar-browse
        Browse activity for Sugar
Updated Packages:

cairo-dock-1.6.3-0.1.svn1346_trunk.fc10
---------------------------------------
* Sun Oct 12 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1346


filezilla-3.1.4-0.1.rc1.fc10
----------------------------
* Sat Oct 11 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.4-0.1.rc1
- Update to 3.1.4-rc1


gcstar-1.4.3-1.fc10
-------------------
* Sat Oct 11 18:00:00 2008 Tian <tian at c-sait.net> - 1.4.3-1
-  Bug 466364
  - New upstream version http://svn.gna.org/viewcvs/*checkout*/gcstar/tags/GCstar_1_4_3/CHANGELOG


gnome-applet-netspeed-0.15.2-1.fc10
-----------------------------------
* Sat Oct 11 18:00:00 2008 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.15.2-1
- Updated to 0.15.2
- Dropped upstreamed patch


gnome-media-2.24.0.1-2.fc10
---------------------------
* Fri Oct 10 18:00:00 2008 Matthias Clasen <mclasen at redhat.com>  2.24.0.1-2
- Save some space


libpst-0.6.20-1.fc10
--------------------
* Thu Oct  9 18:00:00 2008 Carl Byington <carl at five-ten-sg.com> - 0.6.20-1
- add configure option --enable-dii=no to remove dependency on libgd.
- many fixes in pst2ldif by Robert Harris.
- add -D option to include deleted items, from Justin Greer
- fix from Justin Greer to add missing email headers
- fix from Justin Greer for my_stristr()
- fix for orphan children when building descriptor tree
- avoid writing uninitialized data to debug log file
- remove unreachable code
- create dummy top-of-folder descriptor if needed for corrupt pst files


mod_mono-2.0-6.fc10
-------------------
* Sat Oct 11 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-6
- use var run instead of tmp
- added additional Requires


ocsinventory-1.02-0.8.rc3.fc10
------------------------------
* Sat Oct 11 18:00:00 2008 Remi Collet <Fedora at famillecollet.com> 1.02-0.8.rc3
- last minute patch

* Sat Oct 11 18:00:00 2008 Remi Collet <Fedora at famillecollet.com> 1.02-0.7.rc3
- update to RC3


openoffice.org-3.0.0-9.3.fc10
-----------------------------
* Fri Oct 10 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.3
- Resolves: rhbz#465664 need lucene for runtime help search


planet-2.0-6.fc10
-----------------
* Sat Oct 11 18:00:00 2008 Richard Dawe <rich at phekda.gotadsl.co.uk> - 2.0-6
- Regenerate shebang patch to apply without fuzz.


prelude-lml-0.9.13-2.fc10
-------------------------
* Sat Oct 11 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 0.9.13-2
- improved mod_security rules


pysvn-1.6.1-2.fc10
------------------
* Sat Oct 11 18:00:00 2008 Caitlyn O'Hanna <ravenoak at virtualxistenz.com> - 1.6.1-2
- Fixed lingering module versioning in __init__


python-html2text-2.34-1.1
-------------------------
* Thu Oct  9 18:00:00 2008 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 2.34-1
- update to 2.34


python-peak-rules-0.5a1.dev-0.1.2581.fc10
-----------------------------------------
* Sat Oct 11 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5a1.dev-0.1.2581
- Update to the latest 0.5a1 development snapshot
- Fix the description


schedtool-1.3.0-1.fc10
----------------------
* Sat Oct 11 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 1.3.0-1
- Update to 1.3.0


xapian-bindings-1.0.8-1.fc10
----------------------------
* Sat Oct 11 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 1.0.8-1
- Update to 1.0.8


xapian-core-1.0.8-1.fc10
------------------------
* Sat Oct 11 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 1.0.8-1
- Update to 1.0.8


xdvik-22.84.14-3.fc10
---------------------
* Sun Oct 12 18:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 22.84.14-3
- Fix package build breakage

* Sun Oct 12 18:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 22.84.14-2
- Fix previous spec file changelog entry
- Fix Japanese font handling (BZ 465391) by reworking pxdvi patch


Summary:
Added Packages: 2
Removed Packages: 0
Modified Packages: 18
Broken deps for i386
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From opensource at till.name  Sun Oct 12 10:25:39 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 12:25:39 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012093951.GA3936@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
Message-ID: <200810121225.53879.opensource@till.name>

On Sun October 12 2008, Patrice Dumas wrote:

> Look, saying 'yes, if you gather maintainers according to your plan,
> we'll let you use the fedora infras, if you find someone willing to sign
> your packages' doesn't cost any time. Gathering maintainers, just to
> find that there is no infra in the end is very costly.

I do not see why creating a wiki page with a table that contains the minimum 
package set you want to support and people who would maintain it is very 
costly. If you find the 50 or whatever amount of people it at least needs to 
do this project, you will have good chances to be able to use the Fedora 
infrastructure. If you want to do this with only 5 people, you do not even 
much of an infrastructure.

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/20081012/19987be6/attachment.sig>

From rjones at redhat.com  Sun Oct 12 10:50:34 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 12 Oct 2008 11:50:34 +0100
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223748479.13589.313.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
Message-ID: <20081012105034.GA22414@amd.home.annexia.org>

On Sat, Oct 11, 2008 at 02:07:59PM -0400, Braden McDaniel wrote:
> So what are those pitfalls? By running autoreconf, the RPM build becomes
> exposed to different versions of autoconf, automake, and libtool than
> were used by the upstream developer to create the upstream source
> package.  Newer versions of these tools have the potential to introduce
> incompatibilities, breaking the RPM build.

This all seems very theoretical to me.  Just because it has happened
this once is unfortunate, but you have to weigh that against the
convenience of running auto{conf,reconf} after a patch to configure.ac
which is about to go upstream anyway.

I don't mind such a guideline, but don't make it mandatory, and
emphasize that patches to configure.ac/Makefile.am should go upstream
a bit more urgently than normal.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From emmanuel.seyman at club-internet.fr  Sun Oct 12 10:58:04 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sun, 12 Oct 2008 12:58:04 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223804148.3564.1355.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
Message-ID: <20081012105804.GA6353@orient.maison.lan>

* Ralf Corsepius [12/10/2008 11:45] :
>
> Similar proposals have come up several times before (I once proposed
> something like this), but so far, they all had been shoot down so far.

Actually, nothing has ever been proposed.

Occasionnally, someone suggests that updates be released post-EOL and
we then get submerged in proposals that all vary on the set of packages
to be supported, the ABI/API compatibility that should be given, who
will actually maintain what, ...

All of the people willing to work on this project start arguing amongst
themselves as to what is the right thing to do and nothing ever gets
proposed so there's never been anything to refuse.

We then get a whole host of excuses (the most popular of which is that
this is something that can only be done with the Fedora infrastructure),
all of which get replaced with other excuses every time one is shot
down.

Emmanuel



From emmanuel.seyman at club-internet.fr  Sun Oct 12 11:03:13 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sun, 12 Oct 2008 13:03:13 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012093951.GA3936@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
Message-ID: <20081012110313.GB6353@orient.maison.lan>

* Patrice Dumas [12/10/2008 11:45] :
>
>                                           That's one very important
> point of my plan, the no-cost infrastructure and no new community
> organization.

The cost of setting up infrastructure is trivial compared to
encouraging people to release updates past EOL. If you can't do
the former, how are you supposed to do the latter ?

Emmanuel



From opensource at till.name  Sun Oct 12 11:31:43 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 13:31:43 +0200
Subject: Package warning - Rawhide
In-Reply-To: <48F1C302.6000507@fedoraproject.org>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223802893.3564.1345.camel@beck.corsepiu.local>
	<48F1C302.6000507@fedoraproject.org>
Message-ID: <200810121331.55851.opensource@till.name>

On Sun October 12 2008, Rahul Sundaram wrote:

> I rarely find common ground with you but in this instance, I completely
> agree. Is time delay the reason behind not signing packages? There is a

This needs to be implemented / more developers:
https://fedorahosted.org/sigul

It is a signing server that stores the signing keys within smartcards or 
somethin similiar. Afaik Jesse Keating is working at this.

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/20081012/cadf76ae/attachment.sig>

From fedora at shmuelhome.mine.nu  Sun Oct 12 11:34:15 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Sun, 12 Oct 2008 13:34:15 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081012105804.GA6353@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<20081010144426.GC3236@free.fr>	<200810111658.49564.opensource@till.name>	<20081011213341.GA8235@free.fr>	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<20081011220135.GK2305@br-online.de>	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
Message-ID: <48F1E0B7.4000004@shmuelhome.mine.nu>

Emmanuel Seyman wrote:
> * Ralf Corsepius [12/10/2008 11:45] :
>   
>> Similar proposals have come up several times before (I once proposed
>> something like this), but so far, they all had been shoot down so far.
>>     
>
> Actually, nothing has ever been proposed.
>
> Occasionnally, someone suggests that updates be released post-EOL and
> we then get submerged in proposals that all vary on the set of packages
> to be supported, the ABI/API compatibility that should be given, who
> will actually maintain what, ...
>
> All of the people willing to work on this project start arguing amongst
> themselves as to what is the right thing to do and nothing ever gets
> proposed so there's never been anything to refuse.
>
> We then get a whole host of excuses (the most popular of which is that
> this is something that can only be done with the Fedora infrastructure),
> all of which get replaced with other excuses every time one is shot
> down.
>
> Emmanuel
>
>   
Seems to me that you have the beginning of a plan. There needs to be an 
individual with the responsibility to create a full-blown proposal. He 
must identify the scope of the task and the resources that would be 
required to fulfill the requirements. He must also be willing and able 
to incorporate the various suggestions and objections into the overall 
plan. Judging by the comments on this thread he would also need to 
identify an infrastructure sponsor who would commit to giving the 
project a home. As long as this remains a group of individuals with a 
vague feeling that a legacy project would be a good thing to have, 
nothing will happen.
And no, I am not that individual.



From jan.kratochvil at redhat.com  Sun Oct 12 11:44:36 2008
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Sun, 12 Oct 2008 13:44:36 +0200
Subject: gcc-4.3.2 related buiid issue
In-Reply-To: <48ECFC76.7080706@herr-schmitt.de>
References: <48ECFC76.7080706@herr-schmitt.de>
Message-ID: <20081012114436.GA7051@host0.dyn.jankratochvil.net>

On Wed, 08 Oct 2008 20:31:18 +0200, Jochen Schmitt wrote:
> I have try to build the most recent release of highlight-2.6.13 on koji.
> 
> Unfortunately, I have got the following error messages:
> 
> main.o: In function `HighlightApp::printDebugInfo(highlight::LanguageDefinition const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
> /builddir/build/BUILD/highlight-2.6.13/src/main.cpp:107: undefined reference to `Pattern::getPattern() const'
...
> collect2: ld returned 1 exit status
> make[1]: *** [compile] Error 1
...
> http://koji.fedoraproject.org/koji/getfile?taskID=868972&name=build.log

Upstream makefile is racy which fails on `make -j' due to (correct) .spec:
make %{?_smp_mflags} [...]


Regards,
Jan
-------------- next part --------------
--- highlight-2.6.13/src/makefile-orig	2008-09-30 03:09:52.000000000 +0200
+++ highlight-2.6.13/src/makefile	2008-10-12 13:28:20.000000000 +0200
@@ -69,7 +69,7 @@ endif
 compile: ${OBJECTFILES} libhighlight.a
 	${BUILD_CMD}
 
-libhighlight.a:
+libhighlight.a: ${CORE_OBJECTS}
 	echo "compile lib...."
 	${AR} ${ARFLAGS} libhighlight.a ${CORE_OBJECTS}
 

From khc at pm.waw.pl  Sun Oct 12 12:02:25 2008
From: khc at pm.waw.pl (Krzysztof Halasa)
Date: Sun, 12 Oct 2008 14:02:25 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <20081012012428.GN10204@angus.ind.WPI.EDU> (Chuck Anderson's
	message of "Sat\, 11 Oct 2008 21\:24\:28 -0400")
References: <48F0C1CE.30104@BitWagon.com> <48F14FEB.20406@BitWagon.com>
	<20081012012428.GN10204@angus.ind.WPI.EDU>
Message-ID: <m3skr2m372.fsf@maximus.localdomain>

Chuck Anderson <cra at WPI.EDU> writes:

> On Sat, Oct 11, 2008 at 06:16:27PM -0700, John Reiser wrote:
>> About 2230 UTC on Sat.Oct.11, the 67 leeches finished within a few minutes
>> of each other.  The torrents started about 0000 UTC.  So it took more than 22 hours
>> to distribute the 67 copies of 726MB of data.  That is approx. 10KB/s for each,
>> on average, which is very slow.  The expected speed is at least 10 times as fast.

> I'm pretty sure this was throttling done by torrent1.fedoraproject.org 
> itself.  I was coming in via Internet2, and I assume the reverse route 
> was also via Internet2 (which might be a bad assumption).

That would only make sense if the overall torrent1 limit is set to
10 KB/s (or maybe 20 KB/s). Is it? If it's much higher (as I suspect),
there is a problem with torrent protocol (the implementation i guess).
-- 
Krzysztof Halasa



From jwboyer at gmail.com  Sun Oct 12 12:10:15 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 12 Oct 2008 08:10:15 -0400
Subject: Package warning - Rawhide
In-Reply-To: <48F1C302.6000507@fedoraproject.org>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223802893.3564.1345.camel@beck.corsepiu.local>
	<48F1C302.6000507@fedoraproject.org>
Message-ID: <20081012121015.GA27208@yoda.jdub.homelinux.org>

On Sun, Oct 12, 2008 at 02:57:30PM +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
>> On Sun, 2008-10-12 at 14:27 +0530, Rahul Sundaram wrote:
>>> Hi,
>>>
>>> The PackageKit warning for every single unsigned package - which 
>>> happens to be everything in rawhide is just plain annoying. Can't we 
>>> do something nice about that?
>> The rationale for exposing users to the risks of using unsigned packages
>> has always escaped me, even less in the light of "The incident".
>>
>> I.e. IMO, the "only correct  approach" would be to only have signed
>> packages in rawhide.
>
> I rarely find common ground with you but in this instance, I completely  
> agree. Is time delay the reason behind not signing packages? There is a  

It's time delay, and the fact that we have a very limited number of
people that know the signing key.  As someone already pointed out,
we need the signing server for this to be a valid option.

josh



From pertusus at free.fr  Sun Oct 12 12:27:23 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 14:27:23 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012110313.GB6353@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
Message-ID: <20081012122723.GC3936@free.fr>

On Sun, Oct 12, 2008 at 01:03:13PM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [12/10/2008 11:45] :
> >
> >                                           That's one very important
> > point of my plan, the no-cost infrastructure and no new community
> > organization.
> 
> The cost of setting up infrastructure is trivial compared to
> encouraging people to release updates past EOL. If you can't do
> the former, how are you supposed to do the latter ?

I really can't see how you can say that. Look at the setup of rpmfusion, 
for example, it is clearly not something I can undertake myself.

--
Pat



From pertusus at free.fr  Sun Oct 12 12:33:41 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 14:33:41 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F1E0B7.4000004@shmuelhome.mine.nu>
References: <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
Message-ID: <20081012123341.GD3936@free.fr>

On Sun, Oct 12, 2008 at 01:34:15PM +0200, shmuel siegel wrote:
>>
>>   
> Seems to me that you have the beginning of a plan. There needs to be an  
> individual with the responsibility to create a full-blown proposal. He  

https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00598.html

At some point there was a page in the wiki, I can't find it anymore.

--
Pat



From rdieter at math.unl.edu  Sun Oct 12 12:51:09 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 12 Oct 2008 07:51:09 -0500
Subject: reviving Fedora Legacy
References: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr>
Message-ID: <gcsrr8$9mn$1@ger.gmane.org>

Patrice Dumas wrote:

> Doing a SIG although fedora infra won't be used is just pointless. And
> yes, the right to use the fedora space was turned down.

Really?  By whom?  References?

-- Rex




From pertusus at free.fr  Sun Oct 12 13:18:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 15:18:11 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <gcsrr8$9mn$1@ger.gmane.org>
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
Message-ID: <20081012131811.GA2700@free.fr>

On Sun, Oct 12, 2008 at 07:51:09AM -0500, Rex Dieter wrote:
> Patrice Dumas wrote:
> 
> > Doing a SIG although fedora infra won't be used is just pointless. And
> > yes, the right to use the fedora space was turned down.
> 
> Really?  By whom?  References?

It begins here:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00598.html

--
Pat



From opensource at till.name  Sun Oct 12 13:24:21 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 15:24:21 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012122723.GC3936@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
Message-ID: <200810121524.33949.opensource@till.name>

On Sun October 12 2008, Patrice Dumas wrote:
> On Sun, Oct 12, 2008 at 01:03:13PM +0200, Emmanuel Seyman wrote:
> > * Patrice Dumas [12/10/2008 11:45] :
> > >                                           That's one very important
> > > point of my plan, the no-cost infrastructure and no new community
> > > organization.
> >
> > The cost of setting up infrastructure is trivial compared to
> > encouraging people to release updates past EOL. If you can't do
> > the former, how are you supposed to do the latter ?
>
> I really can't see how you can say that. Look at the setup of rpmfusion,
> for example, it is clearly not something I can undertake myself.

Why do you have to do it by yourself? You can recruit interested people to do 
so. And in case you are by yourself, you do not need such a complex setup. 
You only need a script to run mock, rpm --addsign, rsync and createrepo.

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/20081012/e7d51544/attachment.sig>

From pertusus at free.fr  Sun Oct 12 13:31:22 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 15:31:22 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <200810121524.33949.opensource@till.name>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<200810121524.33949.opensource@till.name>
Message-ID: <20081012133122.GB2700@free.fr>

On Sun, Oct 12, 2008 at 03:24:21PM +0200, Till Maas wrote:
> 
> Why do you have to do it by yourself? You can recruit interested people to do 
> so. And in case you are by yourself, you do not need such a complex setup. 
> You only need a script to run mock, rpm --addsign, rsync and createrepo.

What you describe doesn't looks like a fedora LTS buildsystem. You are
describing how I maintain my personal repo (though no mock, rpmbuild is 
enough) but this is rather different from having a real infrastructure.
And I am not interested in maintaining all the packages in @core and
@base, so definitly need more people. Not to mention that I don't have
anything else than an i386.

--
Pat



From sgrubb at redhat.com  Sun Oct 12 13:32:31 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Sun, 12 Oct 2008 09:32:31 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223772015.13589.354.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
Message-ID: <200810120932.31949.sgrubb@redhat.com>

On Saturday 11 October 2008 20:40:14 Braden McDaniel wrote:
> > There's been a number of occasions where I patch Makefile.am because its
> > a 1 liner and patching Makefile.in makes a very ugly patch that becomes
> > harder to read.
>
> Many one-liner Makefile.am patches are also one-liner Makefile.in
> patches when Makefile.in is modified manually. ?There's no reason to be
> shy about doing that.

What if you are cherry picking a patch in upstream cvs/svn to fix a bug that 
upstream won't be releasing for a while? They are usually patches against 
Makefile.am if they touch that file at all.


> Note also that, for better or for worse, Fedora includes several older
> versions of autoconf and automake. 

I think that is for worse. I have tried many times in the past to get rid of 
old autotools so that people move to the new ones. Just having old autotools 
in the distro encourages clinging to the past. We need to purge the old ones 
and move on. Let's stop maintaining 6 copies of automake and 3 copies of 
autoconf.

I've also seen times when you had to regen the auto files because the 
config.guess file was too old.


> > ?Examples of this is adding files to be compiled in, removing files to
> > be compiled in, or making something optional for a configure flag. So, if
> > you know what you are doing, its fine to patch configure.ac or
> > Makefile.am.
>
> It's really not. ?Because even if you're perfectly capable using the
> autotools, you're still exposing the package to potential breakage when
> it gets rebuilt with a newer version of the tools.

That's where a developer's duties begin. You have to look at the output and 
decide if it were safe. In some cases you have to forward port the 
Makefile.am and configure.ac files. I usually send those upstream so that 
they can stop requiring the use of old tools. Since Fedora is cutting edge, I 
think we should be actively helping the old files move forward.

I don't mind seeing guidelines published for people that find autotools a 
mystery. But I don't think we should be making any policy about what a 
developer does to maintain his packages. If something blows up we shold just 
file a normal bug against it.

-Steve



From opensource at till.name  Sun Oct 12 13:38:12 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 15:38:12 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012133122.GB2700@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810121524.33949.opensource@till.name>
	<20081012133122.GB2700@free.fr>
Message-ID: <200810121538.19019.opensource@till.name>

On Sun October 12 2008, Patrice Dumas wrote:
> On Sun, Oct 12, 2008 at 03:24:21PM +0200, Till Maas wrote:
> > Why do you have to do it by yourself? You can recruit interested people
> > to do so. And in case you are by yourself, you do not need such a complex
> > setup. You only need a script to run mock, rpm --addsign, rsync and
> > createrepo.
>
> What you describe doesn't looks like a fedora LTS buildsystem. You are
> describing how I maintain my personal repo (though no mock, rpmbuild is
> enough) but this is rather different from having a real infrastructure.
> And I am not interested in maintaining all the packages in @core and
> @base, so definitly need more people. Not to mention that I don't have
> anything else than an i386.

Your only argument against setting up your own infrastructure is, that you 
cannot do it on your own. You agree that you need additional people, so this 
argument does not count.

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/20081012/22f9cb24/attachment.sig>

From pertusus at free.fr  Sun Oct 12 13:40:01 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 15:40:01 +0200
Subject: automatically grant watchbugzilla and watchcommits?
Message-ID: <20081012134001.GC2700@free.fr>

Hello,

After some thinking, I really can't see why a packager wouldn't approve
somebody asking for watchbugzilla or watchcommits. On the contrary,
packagers should never be able to turn down people wanting to watch what
is happening for a package. Everything is public in any case, it is just
a convenience.

What is your opinion?

I will fill a bug if accepted.

--
Pat



From pertusus at free.fr  Sun Oct 12 13:43:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 15:43:43 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <200810121538.19019.opensource@till.name>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810121524.33949.opensource@till.name>
	<20081012133122.GB2700@free.fr>
	<200810121538.19019.opensource@till.name>
Message-ID: <20081012134343.GD2700@free.fr>

On Sun, Oct 12, 2008 at 03:38:12PM +0200, Till Maas wrote:
> 
> Your only argument against setting up your own infrastructure is, that you 
> cannot do it on your own. You agree that you need additional people, so this 
> argument does not count.

My argument is that it is a lot of work to set up an infrastructure. I
wouldn't want to contribute a LTS project where the infrastructure is to
be done, while I would happily maintain packages and even drive the
project if an existing infrastructure is used. Now if there are people
who have the infrastructure, and it is similar with the fedora
infrastructure, and want packagers I'll join.

--
Pat



From nicolas.mailhot at laposte.net  Sun Oct 12 14:04:05 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 12 Oct 2008 16:04:05 +0200
Subject: Fontconfig rules installation guidelines change proposal
Message-ID: <1223820245.9402.18.camel@arekh.okg>

Hi all,

I've queued the following small guideline change proposal for FPC
consideration:

http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction_(fontconfig)

Please add comments, reactions and corrections in the wiki.

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/20081012/b56f2995/attachment.sig>

From emmanuel.seyman at club-internet.fr  Sun Oct 12 14:21:55 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sun, 12 Oct 2008 16:21:55 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012122723.GC3936@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
Message-ID: <20081012142155.GA13881@orient.maison.lan>

* Patrice Dumas [12/10/2008 14:43] :
>
> I really can't see how you can say that. Look at the setup of rpmfusion, 

Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
mailman, the works). This is much more difficult and goes above and beyond
the requirements for a third party repo to get started.

> for example, it is clearly not something I can undertake myself.

Once again, if you do not have the manpower to setup an infrastructure,
you do not have the manpower to support @code + @base . This is why
you need to start by building a community.

Emmanuel



From pertusus at free.fr  Sun Oct 12 14:25:12 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 16:25:12 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012142155.GA13881@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
Message-ID: <20081012142512.GE2700@free.fr>

On Sun, Oct 12, 2008 at 04:21:55PM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [12/10/2008 14:43] :
> >
> Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
> mailman, the works). This is much more difficult and goes above and beyond
> the requirements for a third party repo to get started.

It doesn't go beyond the requirements for a fedora LTS. If fedora LTS
isn't on par with fedora from the infrastrructure point of view, it is
not worth pursuing.

> Once again, if you do not have the manpower to setup an infrastructure,
> you do not have the manpower to support @code + @base . This is why
> you need to start by building a community.

A community of packagers. Not a community for infrastructure. This is
very different.

--
Pat



From cra at WPI.EDU  Sun Oct 12 14:43:21 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 12 Oct 2008 10:43:21 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>
	<4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>
	<1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>
Message-ID: <20081012144321.GO10204@angus.ind.WPI.EDU>

On Sat, Oct 11, 2008 at 11:12:38PM -0400, Robert Locke wrote:
> What I think is lacking (but seem to be being worked on), is a
> convenient "upgrade" process within the "family".  So that if I use
> Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
> comes out.

You could always pass "upgradeany" to Anaconda to upgrade other 
distros, but this isn't officially supported.



From emmanuel.seyman at club-internet.fr  Sun Oct 12 14:43:38 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sun, 12 Oct 2008 16:43:38 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012142512.GE2700@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<20081012142512.GE2700@free.fr>
Message-ID: <20081012144338.GA16066@orient.maison.lan>

* Patrice Dumas [12/10/2008 16:29] :
>
> It doesn't go beyond the requirements for a fedora LTS. If fedora LTS
> isn't on par with fedora from the infrastrructure point of view, it is
> not worth pursuing.

At which point we're back to making excuses for not actually doing
anything and demanding that people who aren't interested in Fedora LTS
do the needed work.

This is insane and if everybody had that atitude, half the Fedora SIGs
would never have seen the light of day.

Emmanuel



From pertusus at free.fr  Sun Oct 12 14:50:40 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 16:50:40 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012144338.GA16066@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<20081012142512.GE2700@free.fr>
	<20081012144338.GA16066@orient.maison.lan>
Message-ID: <20081012145040.GF2700@free.fr>

On Sun, Oct 12, 2008 at 04:43:38PM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [12/10/2008 16:29] :
> >
> > It doesn't go beyond the requirements for a fedora LTS. If fedora LTS
> > isn't on par with fedora from the infrastrructure point of view, it is
> > not worth pursuing.
> 
> At which point we're back to making excuses for not actually doing
> anything and demanding that people who aren't interested in Fedora LTS
> do the needed work.

Which work? Not shutting down builders and other infras for the EOL 
branches? In my proposal I propose to find somebody to do the signing,
which is the only part that requires work -- unless I am missing
something.

I am not competent in infrastructure building nor have I the time to 
lead a project which includes building an infrastructure. But I can lead
a project targeted at packaging the core of fedora for LTS -- but only
the packaging part.

> This is insane and if everybody had that atitude, half the Fedora SIGs
> would never have seen the light of day.

Most of the SIGs don't need specific infrastructure. The analogy is
EPEL, but EPEL got support.

--
Pat



From rdieter at math.unl.edu  Sun Oct 12 14:57:47 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 12 Oct 2008 09:57:47 -0500
Subject: reviving Fedora Legacy
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr>
Message-ID: <gct38m$scd$1@ger.gmane.org>

Patrice Dumas wrote:

> On Sun, Oct 12, 2008 at 07:51:09AM -0500, Rex Dieter wrote:
>> Patrice Dumas wrote:
>> 
>> > Doing a SIG although fedora infra won't be used is just pointless. And
>> > yes, the right to use the fedora space was turned down.
>> 
>> Really?  By whom?  References?
> 
> It begins here:
...

I perused the thread, but failed to find any reference to any authoritative statement that fedora infrastructure could not be used for such an effort.  Am I missing something?

-- Rex



From lesmikesell at gmail.com  Sun Oct 12 15:21:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 10:21:59 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012142155.GA13881@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>	<200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
Message-ID: <48F21617.7000707@gmail.com>

Emmanuel Seyman wrote:
> * Patrice Dumas [12/10/2008 14:43] :
>> I really can't see how you can say that. Look at the setup of rpmfusion, 
> 
> Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
> mailman, the works). This is much more difficult and goes above and beyond
> the requirements for a third party repo to get started.
> 
>> for example, it is clearly not something I can undertake myself.
> 
> Once again, if you do not have the manpower to setup an infrastructure,
> you do not have the manpower to support @code + @base . This is why
> you need to start by building a community.

But the first question should be why a separate community is necessary. 
  Why is it not possible for one of fedora's goals to be to provide a 
clean transition to RHEL or Centos at the end of certain development 
cycles, at which point EPEL/Rpmfusion, etc. would be unnecessary as 
separate entities since that fedora cycle's repository would be directly 
usable as-is and would simply need to be maintained instead of the 
various 3rd party versions that have been necessary to fill this void?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From emmanuel.seyman at club-internet.fr  Sun Oct 12 15:28:31 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sun, 12 Oct 2008 17:28:31 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012145040.GF2700@free.fr>
References: <200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<20081012142512.GE2700@free.fr>
	<20081012144338.GA16066@orient.maison.lan>
	<20081012145040.GF2700@free.fr>
Message-ID: <20081012152831.GA17239@orient.maison.lan>

* Patrice Dumas [12/10/2008 16:51] :
>
> Which work? Not shutting down builders and other infras for the EOL 
> branches?

Not just not shutting them down but actively maintaining them, which
would require more work than maintaining the non-EOL branches.

I'm sorry but, until there's a community committed to actually doing
the work, asking that infrastructure be created/adapted/maintained is an
unreasonable request, IMHO.

Emmanuel



From ralph+fedora at strg-alt-entf.org  Sun Oct 12 15:29:38 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Sun, 12 Oct 2008 17:29:38 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F21617.7000707@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
Message-ID: <20081012152937.GA428@br-online.de>

Les Mikesell wrote:
> But the first question should be why a separate community is necessary.  
> Why is it not possible for one of fedora's goals to be to provide a  
> clean transition to RHEL or Centos at the end of certain development  
> cycles, 

That point would have been FC6 alpha (or something like that) for RHEL 5. 
So you would have an alpha release from which you could do the transition. 

Everything (or mostly everything) else in FC6 after that point is newer than
the stuff you'd find in RHEL. How do you want to switch from there to RHEL? 

> at which point EPEL/Rpmfusion, etc. would be unnecessary as  
> separate entities since that fedora cycle's repository would be directly  
> usable as-is and would simply need to be maintained instead of the  
> various 3rd party versions that have been necessary to fill this void?

No, it wouldn't as stuff probably would require newer versions of base 
packages than are available in RHEL. 

I do not think that what you suggest is even remotely possible given the
development cycles of Fedora and the ones of Red Hat Enterprise.

And I don't think it is necessary.

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/b56567e9/attachment.sig>

From smooge at gmail.com  Sun Oct 12 15:30:59 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sun, 12 Oct 2008 09:30:59 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F21617.7000707@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
Message-ID: <80d7e4090810120830qbdc951dp3bf1ccdddc190ff9@mail.gmail.com>

On Sun, Oct 12, 2008 at 9:21 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Emmanuel Seyman wrote:
>>
>> * Patrice Dumas [12/10/2008 14:43] :
>>>
>>> I really can't see how you can say that. Look at the setup of rpmfusion,
>>
>> Rpmfusion chose to duplicate the Fedora infrastructure (bugzilla, CVS+FAS,
>> mailman, the works). This is much more difficult and goes above and beyond
>> the requirements for a third party repo to get started.
>>
>>> for example, it is clearly not something I can undertake myself.
>>
>> Once again, if you do not have the manpower to setup an infrastructure,
>> you do not have the manpower to support @code + @base . This is why
>> you need to start by building a community.
>
> But the first question should be why a separate community is necessary.  Why
> is it not possible for one of fedora's goals to be to provide a clean
> transition to RHEL or Centos at the end of certain development cycles, at
> which point EPEL/Rpmfusion, etc. would be unnecessary as separate entities
> since that fedora cycle's repository would be directly usable as-is and
> would simply need to be maintained instead of the various 3rd party versions
> that have been necessary to fill this void?

It would take a change in the branching of EL from Fedora. In the
past, EL's product cycle has required that it be branched on its
timeline NOT fedora's. So if Fedora is late, then the branch is taken
anyway and people start working on that to meet the EL roadmap. Thus
EL-3 is branched not from RH-9 but RH-9 beta. EL-4 is branched from
FC-3 beta ad EL-5 FC-6 beta.

Because packages are pushed into a release that hae major changes
(FC-6 final and RHEL-5 are very different in various packages so you
have to be careful getting some stuff moved over.) For the branching
to work it would need to be done at the END of a cycle. So instead of
RHEL-6 being based off of Fedora-11 it would need to be based off of
Fedora-8 when mainline does not make changes to it anymore.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From mailings at x-tnd.be  Sun Oct 12 15:45:55 2008
From: mailings at x-tnd.be (Johan Cwiklinski)
Date: Sun, 12 Oct 2008 17:45:55 +0200
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <20081012134001.GC2700@free.fr>
References: <20081012134001.GC2700@free.fr>
Message-ID: <48F21BB3.9060509@x-tnd.be>

Patrice Dumas a ?crit :
> Hello,
>
> After some thinking, I really can't see why a packager wouldn't approve
> somebody asking for watchbugzilla or watchcommits. On the contrary,
> packagers should never be able to turn down people wanting to watch what
> is happening for a package. Everything is public in any case, it is just
> a convenience.
>
> What is your opinion?
>
> I will fill a bug if accepted.
>
> --
> Pat
>
>   
Hello,

I completely agree with Patrice :-)

Regards,
Johan



From cra at WPI.EDU  Sun Oct 12 15:47:55 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 12 Oct 2008 11:47:55 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081012123341.GD3936@free.fr>
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
Message-ID: <20081012154755.GP10204@angus.ind.WPI.EDU>

On Sun, Oct 12, 2008 at 02:33:41PM +0200, Patrice Dumas wrote:
> On Sun, Oct 12, 2008 at 01:34:15PM +0200, shmuel siegel wrote:
> > Seems to me that you have the beginning of a plan. There needs to be an  
> > individual with the responsibility to create a full-blown proposal. He  
> 
> https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00598.html
> 
> At some point there was a page in the wiki, I can't find it anymore.

I just re-read the entire thread (its not that huge):

http://fedoraproject.org/wiki/DraftPageUAEL
http://fedoraproject.org/wiki/DraftUAEL

It sees that the main objections were/are:

1. Without some sort of statement on lifetime, users would be left 
high and dry at any instant in time that the branch could be declared 
"dead" after 7 days without a maintainer for one of the @core @base 
packages.

It was proposed to have a client-side UI to inform users of the 
viability/end-of-life/status of a branch.  I believe PackageKit could 
be used to do this now.  It has been discussed for regular Fedora EOL 
that a notification be sent via package metadata, possibly offering 
the user an upgrade path.  This upgrade path could be to the next 
Fedora via Pre-Upgrade, or to UAEL via changing the yum repo 
locations.  Likewise, at the end of UAEL life, similar warnings could 
be put out in advance of the EOL.

Also the bit about "if one of these packages isn't maintained anymore, 
the whole branch is retired after 1 week." won't really work with the 
above.  At the very least, give 3-4 weeks for a new maintainer to be 
found, on par with the existing Fedora policies.

My personal opinion is to start with a very limited extension of 
lifespan.  E.g. when F-8 goes EOL one month after F-10, UAEL would 
extend F-8 to one month after F-11 is released, giving an additional 
6-7 months of lifespan to F-8.  This would limit the amount of UAEL 
work to one distro release at a time and would solve one set of 
user/sysadmin problems, which is that by the time F-N stabalizes and 
slows down enough to upgrade to it (in my experience that is around 
the time F-N+1 comes out), there is only 6-7 months left before it 
goes EOL.  This proposal would extend that remainder to 12-13 months.  
At least then they could follow an annual upgrade cycle.  If they need 
more than a year, perhaps RHEL/CentOS is the right choice for them.

I think it is important that no matter what timeframe is decided, UAEL 
maintainers as a group must agree to stick to it, just like Fedora 
maintainers now are expected to stick to supporting their packages for 
the lifespan of F-N and F-N-1.

2. Jeff Spaleta wanted metrics and verification to be sure the UAEL 
maintainers were actually doing their job and maintaining the packages 
they said they would, and metrics to be sure no one maintainer took on 
too large of a load to prevent from getting burned out.

I think it is unrealistic to require more oversight for UAEL than 
there is for regular Fedora maintainers.  Trust that they will do the 
work.  If they don't, follow the same policies and procedures we have 
to deal with that in Fedora today.  

3. On the matter of infrastructure.  The UAEL proposal suggested that 
we reuse the existing Fedora infrastructure and just let the F-N 
branches live on, or create new branches in CVS for UAEL-N so as to 
allow UAEL contributors to concentrate on packaging, rather than 
setting up new infrastructure.

How would this affect the existing Fedora Infrastructure maintainers?  
Would this require much more committment and work from them?  Or is 
this just limited to finding someone to sign packages?  Are they okay 
with that?  By limiting the lifespan to 7 months or so, this also 
limits the expectations we have from Fedora Infrastructure.

4.  On ABI/API stability.  Fedora has no guarantee for ABI/API 
stability.  Neither would UAEL.  Maintainers could choose to upgrade, 
backport, or "steal" from newer Fedora/RHEL/CentOS as they see fit, to 
the same extent that Fedora package maintainers can and do today.  I 
don't see UAEL having any more guarantees than Fedora does in this 
regard.  Again, if you want more than this, then perhaps RHEL/CentOS 
is the right choice for you.

5. On security.  How does the Fedora Security Team work now?  It seems 
to be a pretty opaque group, i.e. not transparent to the rest of the 
community.  Without knowing how this part of Fedora works, it is hard 
to formulate a plan for UAEL.  At worst, UAEL could be reactive to 
other security announcements and update releases, like how Fedora 
Legacy used to work.  At best, there would be some cooperation between 
the Fedora Security Team and UAEL.



From hughsient at gmail.com  Sun Oct 12 15:52:01 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 12 Oct 2008 16:52:01 +0100
Subject: Package warning - Rawhide
In-Reply-To: <48F1BBE2.5050406@fedoraproject.org>
References: <48F1BBE2.5050406@fedoraproject.org>
Message-ID: <1223826721.3487.3.camel@hughsie-laptop>

On Sun, 2008-10-12 at 14:27 +0530, Rahul Sundaram wrote:
> The PackageKit warning for every single unsigned package - which
> happens to be everything in rawhide is just plain annoying. Can't we
> do something nice about that?

Being honest, PackageKit should really just abort the transaction in the
unsigned case, as if the mirror has been compromised then we should fail
to upgrade an unsigned package. At the moment rawhide is wide open.

If prevented unsigned packages, nobody would be able to use rawhide at
all.

Maybe a setting in PackageKit.conf might be the best plan:

UnsignedPackages=abort|warn|allow

What do you guys think. Upstream we set this to abort, and patch the
package in rawhide to "allow" -- having F10 set to warn or abort.

Comments?

Richard.




From emmanuel.seyman at club-internet.fr  Sun Oct 12 16:03:03 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sun, 12 Oct 2008 18:03:03 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F21617.7000707@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
Message-ID: <20081012160303.GA17461@orient.maison.lan>

* Les Mikesell [12/10/2008 17:28] :
>
> Why is it not possible for one of fedora's goals to be to provide a  
> clean transition to RHEL or Centos at the end of certain development  
> cycles,

-1.

Fedora already has a mission, one that I agree 100%. Anything that
distracts us from that mission is a negative.

Get the RHEL people to cover migrations from other distributions to RHEL
and the CentOS prople to cover migrations to CentOS. The Fedora people
should only be concerned with migrations to Fedora, not from it.

Emmanuel



From denis at poolshark.org  Sun Oct 12 16:04:37 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sun, 12 Oct 2008 18:04:37 +0200
Subject: Package warning - Rawhide
In-Reply-To: <1223826721.3487.3.camel@hughsie-laptop>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop>
Message-ID: <48F22015.40704@poolshark.org>

Richard Hughes wrote:
> On Sun, 2008-10-12 at 14:27 +0530, Rahul Sundaram wrote:
>> The PackageKit warning for every single unsigned package - which
>> happens to be everything in rawhide is just plain annoying. Can't we
>> do something nice about that?
> 
> Being honest, PackageKit should really just abort the transaction in the
> unsigned case, as if the mirror has been compromised then we should fail
> to upgrade an unsigned package. At the moment rawhide is wide open.
> 
> If prevented unsigned packages, nobody would be able to use rawhide at
> all.
> 
> Maybe a setting in PackageKit.conf might be the best plan:
> 
> UnsignedPackages=abort|warn|allow

This is a property of the repository, not of the package manager. If the 
rawhide repo is fundamentally unsigned, this should be a property in the 
.repo file itself, not a global property.



From opensource at till.name  Sun Oct 12 16:13:25 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 18:13:25 +0200
Subject: Fedora 8 and 9 updates re-enabled
In-Reply-To: <1221028475.3388.132.camel@luminos.localdomain>
References: <1221028475.3388.132.camel@luminos.localdomain>
Message-ID: <200810121813.36870.opensource@till.name>

On Wed September 10 2008, Jesse Keating wrote:

> There will be further milestones in the future that involve redirection
> of release package repos to match that of updates, and removing of old
> gpg key from rpm trust.

Is there a schedule when the Everything repo will be resigned with the new 
key, so that the old gpg key can be purged? 

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/20081012/b0d1fb4f/attachment.sig>

From cra at WPI.EDU  Sun Oct 12 16:23:28 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 12 Oct 2008 12:23:28 -0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012160303.GA17461@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
Message-ID: <20081012162328.GQ10204@angus.ind.WPI.EDU>

On Sun, Oct 12, 2008 at 06:03:03PM +0200, Emmanuel Seyman wrote:
> * Les Mikesell [12/10/2008 17:28] :
> >
> > Why is it not possible for one of fedora's goals to be to provide a  
> > clean transition to RHEL or Centos at the end of certain development  
> > cycles,
> 
> -1.
> 
> Fedora already has a mission, one that I agree 100%. Anything that
> distracts us from that mission is a negative.
> 
> Get the RHEL people to cover migrations from other distributions to RHEL
> and the CentOS prople to cover migrations to CentOS. The Fedora people
> should only be concerned with migrations to Fedora, not from it.

So we should make sure Fedora can upgrade old RHEL installations?  And 
how about cross-grading Ubuntu to Fedora?  Now that would be a hoot 
:-)



From opensource at till.name  Sun Oct 12 16:38:07 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 18:38:07 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F21617.7000707@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081012142155.GA13881@orient.maison.lan> <48F21617.7000707@gmail.com>
Message-ID: <200810121838.14362.opensource@till.name>

On Sun October 12 2008, Les Mikesell wrote:

> But the first question should be why a separate community is necessary.
>   Why is it not possible for one of fedora's goals to be to provide a
> clean transition to RHEL or Centos at the end of certain development
> cycles, at which point EPEL/Rpmfusion, etc. would be unnecessary as
> separate entities since that fedora cycle's repository would be directly
> usable as-is and would simply need to be maintained instead of the
> various 3rd party versions that have been necessary to fill this void?

You only need people to test this and document what needs to be done, like the 
yum upgrade SIG do. They document what is needed to run an upgrade without 
using anaconda from one Fedora release to another.

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/20081012/f183d647/attachment.sig>

From hughsient at gmail.com  Sun Oct 12 16:49:40 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 12 Oct 2008 17:49:40 +0100
Subject: Package warning - Rawhide
In-Reply-To: <48F22015.40704@poolshark.org>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop> <48F22015.40704@poolshark.org>
Message-ID: <1223830180.3487.8.camel@hughsie-laptop>

On Sun, 2008-10-12 at 18:04 +0200, Denis Leroy wrote:
> This is a property of the repository, not of the package manager. If
> the rawhide repo is fundamentally unsigned, this should be a property
> in the .repo file itself, not a global property.

Sure, this policy is only used if the repo is set to unsigned.

Richard.




From a.badger at gmail.com  Sun Oct 12 17:00:25 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 12 Oct 2008 10:00:25 -0700
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F21BB3.9060509@x-tnd.be>
References: <20081012134001.GC2700@free.fr> <48F21BB3.9060509@x-tnd.be>
Message-ID: <48F22D29.90109@gmail.com>

Johan Cwiklinski wrote:
> Patrice Dumas a ?crit :
>> Hello,
>>
>> After some thinking, I really can't see why a packager wouldn't approve
>> somebody asking for watchbugzilla or watchcommits. On the contrary,
>> packagers should never be able to turn down people wanting to watch what
>> is happening for a package. Everything is public in any case, it is just
>> a convenience.
>>
>> What is your opinion?
>>
>> I will fill a bug if accepted.
>>
>> --
>> Pat
>>
>>   
> Hello,
> 
> I completely agree with Patrice :-)
> 
When I brought this up, Bastien Nocera brought up security bugs and not
wanting random people to be CC'd before a security bug is resolved.  How
should we deal with this?

-Toshio

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

From a.badger at gmail.com  Sun Oct 12 17:29:48 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 12 Oct 2008 10:29:48 -0700
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223784253.13589.413.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>	<loom.20081011T182618-279@post.gmane.org>	<1223759337.13589.344.camel@hinge.endoframe.net>	<loom.20081012T011928-869@post.gmane.org>
	<1223784253.13589.413.camel@hinge.endoframe.net>
Message-ID: <48F2340C.7040904@gmail.com>

Rather than reply in depth to any of the posts which are in this thread,
I think I'll just say that both patching and regenerating autotools have
flaws.  I would vote against specifying that patches are better than
running autoconf commands or vice versa in Fedora packages.  I would
support a page written that outlined:

1) The minimal steps that a package maintainer needs to do when a change
to configure.ac/Makefile.am is necessary.
  A) Fix Makefile.am and configure.ac
  B) Generate patch
  C) Submit patch upstream
  D) Regenerate as necessary until patch is integrated upstream
2) How to create and continuously update patches to the generated files
and the gotchas involved with doing things this way and what the
maintainer should do to mitigate them.
3) Gotchas involved with rerunning autotools and what the maintainer
should do to mitigate them.

Neither of the two alternatives 2 or 3 is without major flaws so
advising maintainers that one or the other is the correct way is not
something I'll vote for.

-Toshio

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

From kevin.kofler at chello.at  Sun Oct 12 17:33:21 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 17:33:21 +0000 (UTC)
Subject: Package warning - Rawhide
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop>
Message-ID: <loom.20081012T172500-521@post.gmane.org>

Richard Hughes <hughsient <at> gmail.com> writes:
> UnsignedPackages=abort|warn|allow
> 
> What do you guys think. Upstream we set this to abort, and patch the
> package in rawhide to "allow" -- having F10 set to warn or abort.

"UnsignedPackages=abort" is insane, unless you intend to abort only for 
packages in a repository configured for signature checking. We need to be able 
to install unsigned packages which are not from some repository, like stuff 
directly from Koji, stuff we just built (OK, I could sign that with the 
repo.calcforge.org key, but not everyone has such a key already and 
self-signing packages just to make PackageKit accept them adds no security 
whatsoever), packages from some third-party non-repository download site (which 
are definitely a security risk, but which won't go away no matter how much 
you'd like them to: proprietary software is often distributed that way, and 
unfortunately (it should get into the repos instead!) some specialty Free 
Software too (I've seen the occasional RPM offered as a SourceForge download); 
those sites almost never bother signing their packages, and even if they did, 
the key would not be available to import from within PackageKit because there's 
no repository configuration file, not to mention that adding some random site's 
key as trusted might be counterproductive).

        Kevin Kofler



From hughsient at gmail.com  Sun Oct 12 17:30:47 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 12 Oct 2008 18:30:47 +0100
Subject: Package warning - Rawhide
In-Reply-To: <1223826721.3487.3.camel@hughsie-laptop>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop>
Message-ID: <1223832647.3487.14.camel@hughsie-laptop>

On Sun, 2008-10-12 at 16:52 +0100, Richard Hughes wrote:
> Maybe a setting in PackageKit.conf might be the best plan:
> 
> UnsignedPackages=abort|warn|allow
> 
> What do you guys think. Upstream we set this to abort, and patch the
> package in rawhide to "allow" -- having F10 set to warn or abort.

What about something like the attached? I can put a patch in the rawhide
spec file to change this to "allow" to avoid the warnings, and then when
F10 branches, remove the patch.

This covers my backside a little, in my opinion. Comments?

Richard.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pk-yum-allow-unsigned-unsigned.patch
Type: text/x-patch
Size: 6728 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/3ae1b67d/attachment.bin>

From hughsient at gmail.com  Sun Oct 12 17:37:50 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 12 Oct 2008 18:37:50 +0100
Subject: Package warning - Rawhide
In-Reply-To: <loom.20081012T172500-521@post.gmane.org>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop>
	<loom.20081012T172500-521@post.gmane.org>
Message-ID: <1223833070.3487.21.camel@hughsie-laptop>

On Sun, 2008-10-12 at 17:33 +0000, Kevin Kofler wrote:
> 
> "UnsignedPackages=abort" is insane, unless you intend to abort only for 
> packages in a repository configured for signature checking.

It always aborts if a package isn't signed in a signed repo.

> ...packages from some third-party non-repository download site (which 
> are definitely a security risk, but which won't go away no matter how much 
> you'd like them to

Sure, but at that point I absolve all guilt of any security breach.
Having packages automatically downloaded and installed can be both a
blessing and a curse. Perhaps making it harder for people to provide
unsigned repos might be a good idea long term.

Controversial I know. Of course, this is with my PackageKit maintainer
hat on, not my fedora or red hat on.

Richard.




From vonbrand at inf.utfsm.cl  Sun Oct 12 17:43:16 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 14:43:16 -0300
Subject: rawhide report: 20081011 changes
In-Reply-To: <20081011111154.123791B8001@releng2.fedora.phx.redhat.com>
References: <20081011111154.123791B8001@releng2.fedora.phx.redhat.com>
Message-ID: <200810121743.m9CHhGnd004172@laptop14.inf.utfsm.cl>

After this round, my Spanish keyboard is misdetected as English.
-- 
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 2340000       Fax:  +56 32 2797513



From kevin.kofler at chello.at  Sun Oct 12 17:44:41 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 17:44:41 +0000 (UTC)
Subject: CMake!
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
Message-ID: <loom.20081012T173610-940@post.gmane.org>

Ralf Corsepius <rc040203 <at> freenet.de> writes:
> On Sat, 2008-10-11 at 01:20 +0200, Lennart Poettering wrote:
> > Oh, and I think that cmake is a big trainwreck.
> I share this view. Cmake is imake in new clothes and suffers from the
> same design flaws as imake did.

Like for example?

The complaints I've read about imake is that it has tables for what systems 
have what properties and that you had to maintain those. Assuming that's true 
(I haven't actually used imake), that's very different from how CMake works. 
CMake can do configure checks just like autoconf, the difference is that it 
won't waste time on tests you didn't ask for (and thus won't use the results of 
anyway), like the existence of ubiquitous ISO C90 headers like <string.h> or 
ubiquitous ISO C90 functions like memcpy and memset.

> It's only the limited set of requirements being used by the limited set of
> use cases it's proponents apply which lets them think "cmake is better".

CMake is used by all of KDE 4, and several other projects have switched to 
CMake following that example (or in some cases, because the KDE Window$ porters 
did the port for them), and I'm not aware of anyone having switched back.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 12 17:49:03 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 17:49:03 +0000 (UTC)
Subject: Package warning - Rawhide
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop>
	<loom.20081012T172500-521@post.gmane.org>
	<1223833070.3487.21.camel@hughsie-laptop>
Message-ID: <loom.20081012T174743-738@post.gmane.org>

Richard Hughes <hughsient <at> gmail.com> writes:
> Sure, but at that point I absolve all guilt of any security breach.
> Having packages automatically downloaded and installed can be both a
> blessing and a curse. Perhaps making it harder for people to provide
> unsigned repos might be a good idea long term.

The problem is not unsigned repos, it's unsigned isolated packages one wants to 
run pk-install on.

        Kevin Kofler



From mailings at x-tnd.be  Sun Oct 12 17:50:07 2008
From: mailings at x-tnd.be (Johan Cwiklinski)
Date: Sun, 12 Oct 2008 19:50:07 +0200
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F22D29.90109@gmail.com>
References: <20081012134001.GC2700@free.fr> <48F21BB3.9060509@x-tnd.be>
	<48F22D29.90109@gmail.com>
Message-ID: <48F238CF.1060005@x-tnd.be>

Toshio Kuratomi a ?crit :
> Johan Cwiklinski wrote:
>   
>> Patrice Dumas a ?crit :
>>     
>>> Hello,
>>>
>>> After some thinking, I really can't see why a packager wouldn't approve
>>> somebody asking for watchbugzilla or watchcommits. On the contrary,
>>> packagers should never be able to turn down people wanting to watch what
>>> is happening for a package. Everything is public in any case, it is just
>>> a convenience.
>>>
>>> What is your opinion?
>>>
>>> I will fill a bug if accepted.
>>>
>>> --
>>> Pat
>>>
>>>   
>>>       
>> Hello,
>>
>> I completely agree with Patrice :-)
>>
>>     
> When I brought this up, Bastien Nocera brought up security bugs and not
> wanting random people to be CC'd before a security bug is resolved.  How
> should we deal with this?
>
> -Toshio
>
>   
Hi,

Isn't it the work of bugzilla to send security issues mails to only a
restricted group ?
As we cannot see these bugs in the bugzilla, I think it should not send
us mail also... But I do not know if bugzilla permit this or not.

For the commits, I really do not know, but once commited, any packager
can get the sources, that would be a "minor" issue, the security whole
would be resolved at this time, and should come into the repositories
quickly.

Another possibility would be to not allow automatic approval for such
packages, maybe with an option  in the interface, and let the maintainer
choose if he wants to allow that for his package  or not ?

Regards,
Johan



From hughsient at gmail.com  Sun Oct 12 17:48:42 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 12 Oct 2008 18:48:42 +0100
Subject: Package warning - Rawhide
In-Reply-To: <loom.20081012T174743-738@post.gmane.org>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop>
	<loom.20081012T172500-521@post.gmane.org>
	<1223833070.3487.21.camel@hughsie-laptop>
	<loom.20081012T174743-738@post.gmane.org>
Message-ID: <1223833722.3487.30.camel@hughsie-laptop>

On Sun, 2008-10-12 at 17:49 +0000, Kevin Kofler wrote:
> > Sure, but at that point I absolve all guilt of any security breach.
> > Having packages automatically downloaded and installed can be both a
> > blessing and a curse. Perhaps making it harder for people to provide
> > unsigned repos might be a good idea long term.
> 
> The problem is not unsigned repos, it's unsigned isolated packages one
> wants to run pk-install on.

Nahh, we'll allow this to proceed even with "abort" as InstallFile is a
different method, and doesn't operate on a repo. Different problem.

Richard.




From a.badger at gmail.com  Sun Oct 12 17:51:41 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 12 Oct 2008 10:51:41 -0700
Subject: Package review backlog.
In-Reply-To: <20081011153233.GD10204@angus.ind.WPI.EDU>
References: <1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<1223645613.3514.12.camel@wicktop.localdomain>	<1223649007.6770.25.camel@macbook.infradead.org>	<48F01BDF.1000109@redhat.com>	<1223731515.3923.23.camel@wicktop.localdomain>	<48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>	<1223737587.3923.29.camel@wicktop.localdomain>
	<20081011153233.GD10204@angus.ind.WPI.EDU>
Message-ID: <48F2392D.1090902@gmail.com>

Chuck Anderson wrote:
> On Sat, Oct 11, 2008 at 05:06:27PM +0200, Christoph Wickert wrote:
>>> http://fedoraproject.org/PackageReviewStatus/NEW.html
>>> is perhaps the easiest.
>> I know this one, but this page also returns reviews that are already
>> assigned. And if somebody assigns a review to himself I assume that he's
>> doing it.
> 
> I would like to help with reviews.  I'm not sponsored yet, but have 
> several of my own review requests that have NEEDSPONSOR [1] [2] [3].  
> Is it useful for me to review other packages in the queue?

Yes.  It will help get you sponsored faster as it will show that you
understand the packaging guidelines and any bugs that you find and the
packager addresses will help whoever approves the package in the end (it
might even be you when you get sponsored).

>  What about Merge Reviews?

Theoretically yes.  The problem I have seen with merge reviews, though
is that the packager has no reason to respond to the reviewer.  So
sometimes the merge reviews progress like any other review and things
are great.  Other times, the package owner is unresponsive and you are
left wondering why you've gotten no response.

This is something we may have to address with ideas specifically
targeted at them.  Doing important merge reviews first, then blocking
the rest of the unreviewed packages until they've finished review.
Creating a list of merge reviews at the start of a Fedora release cycle
that are going to be release blockers and alerting the package
maitnainers that the merge review for that package has to be resolved as
a high priority.  I'm sure there's other, better, ideas out there as
well :-)

>  Given that I'm not sponsored, should I take ownership 
> of the package review requests, or just do initial reviews without 
> taking ownership?  Obviously, I don't think I can set the 
> fedora-review flag yet.
> 
You probably should not take ownership.  However, I know that some
sponsors will review the review work you've done, sponsor you, and have
you finish up the review of the packages yourself.

-Toshio

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

From kevin.kofler at chello.at  Sun Oct 12 17:59:31 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 17:59:31 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
Message-ID: <loom.20081012T175241-931@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> I'm defining "building" to include whatever steps are *necessary* to
> generate an RPM.  Rebuilding the build system scripts is not necessary
> and can, in general, be avoided.  Avoiding this step is desirable
> because undertaking it causes well-documented problems.

That definition is already NOT current Fedora policy, see the policy on binary 
JARs (which I completely agree with, for that matter).

> We seem to have drifted off into bizarro world.  Fedora's choice of how
> to package Java impacts the issues here precisely nil.

Then how is this case different from that one? You still haven't answered that 
question, instead claiming it is "obvious".

> You seem to have some notions of ideological purity about what packages
> should contain and you're going to great argumentative lengths to ram
> those notions down fedora-devel's collective throat.  What's missing
> from your arguments is any characterization of a problem that gets
> solved when we do it Your Way.

Nicolas Mailhot answered that one pretty well.

> The guideline I've suggested (and apparently I'm not the first) is a
> response to a real problem: stuff is broken and it wouldn't be broken if
> the guideline had been followed.  You have not proposed an alternative
> solution to the problem.  Rather, your position seems to be that the
> breakage is simply acceptable.  Obviously, I disagree.  I think that
> because it can be avoided, it should be.

Then let's also avoid the breakage due to new GCC versions and just ship 
upstream binaries? (No, I'm not seriously suggesting that!)

> Indulging this question is beyond the scope of this thread.

It's not, the answer to that question is the premise for even considering your 
suggested guideline.

> The guideline I'm proposing operates within the current ideological
> framework, where patching files that happen to have been generated is
> perfectly socially acceptable.  If you would like to propose a guideline
> that changes that, feel free to do so; but please do have the courtesy
> to pursue it in a new thread.

What you're missing is that Fedora _already_ has guidelines requiring to build 
everything from source (which are enforced for Java and Mono stuff, for 
example), it's just that the autotools files are still considered "source", 
which they really aren't.

        Kevin Kofler



From smooge at gmail.com  Sun Oct 12 18:05:36 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sun, 12 Oct 2008 12:05:36 -0600
Subject: CMake!
In-Reply-To: <loom.20081012T173610-940@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
Message-ID: <80d7e4090810121105p75f6f6f5u346f615deab84367@mail.gmail.com>

On Sun, Oct 12, 2008 at 11:44 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Ralf Corsepius <rc040203 <at> freenet.de> writes:
>> On Sat, 2008-10-11 at 01:20 +0200, Lennart Poettering wrote:

> CMake is used by all of KDE 4, and several other projects have switched to
> CMake following that example (or in some cases, because the KDE Window$ porters
> did the port for them), and I'm not aware of anyone having switched back.
>

Ok the problem is that build tools are one of the things developers
build strong relationships with (System administrators build it with
their mail handler tools). You point out the deficiencies in someones
choices of tools and the brain begins attack/flight/protect hormone
chains. The same emotional centers in the brain as if you had picked
up an axe and pointed it at someones family. The hormones get
triggered and all logic circuits are cut off until the testosterone
and serotonin get back down to lower levels. [I think its serotonin..
it may be one of the other brain chemicals that get fired off in big
numbers when this occurs.]

The best part of this is that your logical parts of your brain are
'tricked' into saying "This is the most logical thing to do" although
3 or 4 days later you might regret it (though reading past emails will
probably trigger the same chemical reactiosn and you wont disagree but
even send one or two more emails to prove your point.)

So basically this conversation is a 'dead' conversation. People have
their hairs on their necks up, testosterone pumping to put 3 or 4
beards in a day, and are to the flinging poo part. At this point,
there is no way either side is going to say that Cmake is better at
this, or Autotools is better than that..

Wait a week, and see if one can bridge the gap with some diplomatic
discourse. Yes diplomatic discourse uses a lot of soft words and will
spend a week talking around the point before bringing it up.. but
thats because its meant to get around the human brains stupidity.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From lesmikesell at gmail.com  Sun Oct 12 18:07:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 13:07:27 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012160303.GA17461@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>	<200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
Message-ID: <48F23CDF.1090304@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [12/10/2008 17:28] :
>> Why is it not possible for one of fedora's goals to be to provide a  
>> clean transition to RHEL or Centos at the end of certain development  
>> cycles,
> 
> -1.
> 
> Fedora already has a mission, one that I agree 100%. Anything that
> distracts us from that mission is a negative.

Yes but what is the point of developing for it?  That is, why design 
anything or build support infrastructure for a planned dead-end? In 
particular, why should anyone even try building/running server software 
on fedora when it is clearly not a suitable environment.

> Get the RHEL people to cover migrations from other distributions to RHEL
> and the CentOS prople to cover migrations to CentOS. The Fedora people
> should only be concerned with migrations to Fedora, not from it.

First you have to give someone a reason to want to migrate to Fedora. 
With a planned progression to an enterprise version, that would not 
really be a migration away from fedora but the expected end point where 
you are permitted to continue using anything you've contributed or 
developed for your own use, staying in the same community instead of 
having all previous work dumped out the window at the end of a cycle. 
I'll point out again that this is the way Red Hat developed its 
popularity, although it was probably a mistake to have tried to support 
every release forever.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Sun Oct 12 18:08:04 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 18:08:04 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<1223800236.9402.13.camel@arekh.okg>
	<1223803167.13589.457.camel@hinge.endoframe.net>
Message-ID: <loom.20081012T175955-65@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
>
> On Sun, 2008-10-12 at 10:30 +0200, Nicolas Mailhot wrote:
> > So if Oracle was freely redistributable tomorrow an rpm that just put
> > the pre-generated Oracle files in the right place would be ok with you?
> 
> Getting to this question from what I said requires so many logical leaps
> that it's not worth entertaining.

For you, all the questions you cannot answer are "not worth entertaining". :-/

> Are you claiming that by creating tarballs that are designed to be used
> without having the autotools installed, the GNU build system is
> impairing free software?

I'll let Nicolas answer that (as he's the one you asked), but generated files 
definitely make it harder to exert your freedom to modify the software 
(especially if you need the exact same versions of the autotools or you run 
into trouble, which is what spawned your guideline and thus this discussion in 
the first place) and I don't see what advantages they bring.

> "Ground" level is the upstream source provided by the developer.

But here what upstream includes is _not_ source, it's a generated file!

If you define everything in the upstream tarball as "source", then Oracle's 
binaries are "source" too, which is absurd.

> Applying necessary patches to the build scripts in order to build
> binaries does not make anything less free.

Sure, but forbidding us to patch the actual source code on the ground that 
it "invites breakage" does.

> If a packager wants to include changes to the build script sources in
> the source RPM, I have absolutely no objection to that.  But applying
> those changes as part of the build wins nothing and invites breakage.

Why should we jump through hoops to patch generated files and regularly update 
the patches because they'll invariably break if we can just run autoreconf? It 
is our (the individual package maintainers') problem to fix things if an 
autotools update breaks them anyway!

        Kevin Kofler



From a.badger at gmail.com  Sun Oct 12 18:22:42 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 12 Oct 2008 11:22:42 -0700
Subject: Package review backlog.
In-Reply-To: <48F07C5C.8000403@leemhuis.info>
References: <loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>
	<48F07C5C.8000403@leemhuis.info>
Message-ID: <48F24072.2010308@gmail.com>

Thank you Thorsten!  This list is really really great!

Thorsten Leemhuis wrote:
> Ideas for making things easier and better are there; they are afaics
> well known among contributors and the different committees that are
> responsible. Just nobody is working on them:
> 
>  * improve rpmlint and other tools to automate more of the checks to
> less the burden on the reviewer
> 
We also need to note which Guildelines rpmlint completely checks for,
partially checks for, and does not check for.

Licensing, for instance is a a case where rpmlint helps by verifying
that the license tag matches the abbreviations we specify but does not
verify that the source code only contains the listed license(s).

>  * make review exchanges easier; maybe even force/guide/direct people a
> little bit to do exchange reviews (e.g. a little bit like, but not as
> strict as "if you want to get your packages reviewed you have to review
> a package from somebody else first")
> 
I agree with this although I think "a little bit like, but not as strict
as" is the crux of the issue.  We want people to realize that there's a
bottleneck in the review process so they have a duty to try and help fix
the situation.  How much we lean on them is the big question :-)

>  * look more actively for new sponsors and be less strict when choosing
> them (like it has been in the past); we all make errors -- it's the
> ability to learn from them and to fix the errors once they got made
> 
I'm not sure this is the bottleneck.  Or at least, once we fully
integrate the next point:

>  * be less strict with sponsoring people like it was in the early Fedora
> Extras days in 2005. We can do that now that new packagers don't get
> access each and every package in CVS
> 
The technical work has been done for this.  It would be nice to see some
written guidance on sponsorship now.  ie: the old mindset is that
sponsorship is bestowed when people have shown that they are reasonably
competent with the packaging Guidelines and are responsive when someone
points out an error in their packaging.

With the tightening of what an initially sponsored person can do, how
should this change?  How can we promulgate the changed expectations when
we determine them?

>  * add one more level between new packagers and sponsors; soon-to be
> sponsors there could work together with new packagers and keep an closer
> eye on them; by that they could get work of the real sponsor and show
> their ability to become a real sponsor sooner or later
> 
This makes some sense.  I don't know how formal the additional level
needs to be.  It seems that it's more or less just for tracking purposes.

>  * let FESCo and the Fedora Packaging Committee work together to make
> review and packaging guidelines easier to understand. We have done that
> two times in the past iirc (once in the fedora.us days and the last time
> it iirc mainly was spot's work with some help from mschwendt, scop and
> some others in the early FESCo days before the FPC existed). I tend to
> say it's overdue to do it again. Guidelines for corner cases in that
> process should get moved to special add-on documents or sections that
> are hidden by default. That will make the main things easier to
> understand and remember. Otherwise we soon have guidelines that will
> look like a code of law/statute book that nobody really understands as
> knows, as they are long and quite hard to read. Maybe splitting the
> guidelines might make sense as well: a "this is how it works in general"
>  could be the quick ans easy start; a "here is how it works in detail"
> could serve as reference doc wher you have to look for the details and
> special treatments when it comes to perl/python/mono/java/...
> 
+1

I've been trying to get some momentum up with the Docmentation Project
to reorganize the Packaging Guidelines.  I think one of their major
wishes to help with that is getting a CMS.  That in turn depends on
finding something that works and also doesn't make people cry when
security considerations are presented (if someone knows of a CMS with a
good security record, please step up!  If it's written in python so we
can easily make it better, that's a bonus but not 100% necessary.)

>  * there are likely more ideas floating around...
> 

So one thing we need to do is figure out how to get this into the wiki/
Project consciousness/ worked on by someone.  The last one on the list
is something that is progressing slowly with Docs and FPC.  I'll make
sure I keep talking with docs about doing that.

Some could be good small programming projects (or GSoC if we get a
definition of what we want by next summer [I'm thinking rpmlint/package
review tool here])

A few of the items should be discussed and then taken to FESCo.  For
instance, when to sponsor someone into packager, uberpackager, and sponsor.

-Toshio

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

From a.badger at gmail.com  Sun Oct 12 18:28:12 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 12 Oct 2008 11:28:12 -0700
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F238CF.1060005@x-tnd.be>
References: <20081012134001.GC2700@free.fr>
	<48F21BB3.9060509@x-tnd.be>	<48F22D29.90109@gmail.com>
	<48F238CF.1060005@x-tnd.be>
Message-ID: <48F241BC.7040506@gmail.com>

Johan Cwiklinski wrote:
> Toshio Kuratomi a ?crit :
>> When I brought this up, Bastien Nocera brought up security bugs and not
>> wanting random people to be CC'd before a security bug is resolved.  How
>> should we deal with this?
>>
>> -Toshio
>>
>>   
> Hi,
> 
> Isn't it the work of bugzilla to send security issues mails to only a
> restricted group ?
> As we cannot see these bugs in the bugzilla, I think it should not send
> us mail also... But I do not know if bugzilla permit this or not.
> 
AFAIK, bugzilla will send the security mail/allow people to see the
security bug if they are explicitly CC'd on the bug.

You are explicitly CC'd on the bug if you are given the watchbugzilla
acl in pkgdb.

> For the commits, I really do not know, but once commited, any packager
> can get the sources, that would be a "minor" issue, the security whole
> would be resolved at this time, and should come into the repositories
> quickly.
> 
<nod>  I'd like this to be consistent with the watchbugzilla acls if
possible but perhaps having watchcommits be autoapprove but not
watchbugzilla is the way to go.

> Another possibility would be to not allow automatic approval for such
> packages, maybe with an option  in the interface, and let the maintainer
> choose if he wants to allow that for his package  or not ?

It's a possibility but I don't think it's a good one.  Are we trying to
address a maintainer's concerns with such an option or are we trying to
keep security bugs private until the fix can be released?  If the latter
is the goal, making this settable per package is the wrong thing to do.

-Toshio

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

From lesmikesell at gmail.com  Sun Oct 12 18:35:53 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 13:35:53 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810120830qbdc951dp3bf1ccdddc190ff9@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>
	<80d7e4090810120830qbdc951dp3bf1ccdddc190ff9@mail.gmail.com>
Message-ID: <48F24389.1030906@gmail.com>

Stephen John Smoogen wrote:
> 
>> But the first question should be why a separate community is necessary.  Why
>> is it not possible for one of fedora's goals to be to provide a clean
>> transition to RHEL or Centos at the end of certain development cycles, at
>> which point EPEL/Rpmfusion, etc. would be unnecessary as separate entities
>> since that fedora cycle's repository would be directly usable as-is and
>> would simply need to be maintained instead of the various 3rd party versions
>> that have been necessary to fill this void?
> 
> It would take a change in the branching of EL from Fedora. In the
> past, EL's product cycle has required that it be branched on its
> timeline NOT fedora's.

And now?   I don't think fedora is a suitable starting point for a 
server OS so perhaps things will change for other reasons.  From a 
user's perspective the approach was always wrong anyway.  It would be 
good for both RHEL and fedora if they didn't really branch within a 
version - that is, at some point the RH betas take over the 
corresponding fedora release and fedora takes its wild and crazy changes 
to a new release.

> So if Fedora is late, then the branch is taken
> anyway and people start working on that to meet the EL roadmap. Thus
> EL-3 is branched not from RH-9 but RH-9 beta. EL-4 is branched from
> FC-3 beta ad EL-5 FC-6 beta.

Even so, some people claim to have done successful upgrades from fedora 
to the corresponding EL/Centos with just a few quirks that probably 
could have been avoided with a little central planning.  That is, even 
if it is impossible to coordinate the changes that lead to RHEL/Centos, 
there should be a way to have the final fedora update do a clean 
conversion - or at least better than most users could do on their own.

> Because packages are pushed into a release that hae major changes
> (FC-6 final and RHEL-5 are very different in various packages so you
> have to be careful getting some stuff moved over.) For the branching
> to work it would need to be done at the END of a cycle. So instead of
> RHEL-6 being based off of Fedora-11 it would need to be based off of
> Fedora-8 when mainline does not make changes to it anymore.

The question isn't so much whether it is easy or not, it is whether 
thousands of people should have to figure out on their own how to make 
this transition when fedora abandons their support or whether it should 
be planned and automatic.  The harder it is, the more critical it is to 
have it planned once and designed to be repeatable.  Personally I don't 
think 'long term fedora support' makes a bit of sense in terms of 
maintaining an update repository for years that is incompatible with, 
but only slightly different from RHEL or Centos, but neither does 
abandoning the community of users that developed around a fedora release 
and now needs a way to put their work into production.  It also doesn't 
make much sense for EPEL to be something different than the final 
version of the fedora release that becomes the enterprise version plus 
ongoing updates.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sun Oct 12 18:39:13 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 13:39:13 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <200810121838.14362.opensource@till.name>
References: <48EF5054.3040106@ispbrasil.com.br>	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<200810121838.14362.opensource@till.name>
Message-ID: <48F24451.2060704@gmail.com>

Till Maas wrote:
> On Sun October 12 2008, Les Mikesell wrote:
> 
>> But the first question should be why a separate community is necessary.
>>   Why is it not possible for one of fedora's goals to be to provide a
>> clean transition to RHEL or Centos at the end of certain development
>> cycles, at which point EPEL/Rpmfusion, etc. would be unnecessary as
>> separate entities since that fedora cycle's repository would be directly
>> usable as-is and would simply need to be maintained instead of the
>> various 3rd party versions that have been necessary to fill this void?
> 
> You only need people to test this and document what needs to be done, like the 
> yum upgrade SIG do. They document what is needed to run an upgrade without 
> using anaconda from one Fedora release to another.

Change 'document' to 'script' and I might agree with you.  No one really 
wants to know what one-off oddball quirks need to be handled between 
distros/versions, they just want it to be done correctly.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From opensource at till.name  Sun Oct 12 18:41:34 2008
From: opensource at till.name (Till Maas)
Date: Sun, 12 Oct 2008 20:41:34 +0200
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F22D29.90109@gmail.com>
References: <20081012134001.GC2700@free.fr> <48F21BB3.9060509@x-tnd.be>
	<48F22D29.90109@gmail.com>
Message-ID: <200810122041.40836.opensource@till.name>

On Sun October 12 2008, Toshio Kuratomi wrote:

> When I brought this up, Bastien Nocera brought up security bugs and not
> wanting random people to be CC'd before a security bug is resolved.  How
> should we deal with this?

So there are some packages that nobody can get watchbugzilla access in case 
that someone reports a security issue via Bugzilla?

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/20081012/96e8fedb/attachment.sig>

From lesmikesell at gmail.com  Sun Oct 12 18:49:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 13:49:14 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012152937.GA428@br-online.de>
References: <48EF5054.3040106@ispbrasil.com.br>	<200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>
	<20081012152937.GA428@br-online.de>
Message-ID: <48F246AA.8050408@gmail.com>

Ralph Angenendt wrote:
> 
>> But the first question should be why a separate community is necessary.  
>> Why is it not possible for one of fedora's goals to be to provide a  
>> clean transition to RHEL or Centos at the end of certain development  
>> cycles, 
> 
> That point would have been FC6 alpha (or something like that) for RHEL 5. 
> So you would have an alpha release from which you could do the transition. 
> 
> Everything (or mostly everything) else in FC6 after that point is newer than
> the stuff you'd find in RHEL. How do you want to switch from there to RHEL? 

"How" is the part that should be planned from the start instead of 
leaving all of your users in this position.

>> at which point EPEL/Rpmfusion, etc. would be unnecessary as  
>> separate entities since that fedora cycle's repository would be directly  
>> usable as-is and would simply need to be maintained instead of the  
>> various 3rd party versions that have been necessary to fill this void?
> 
> No, it wouldn't as stuff probably would require newer versions of base 
> packages than are available in RHEL. 

Again, that seems like bad planning.  Wasn't that predictable?  But, 
there are people who claim to have don't successful upgrades from FC6 to 
RHEL/Centos.

> I do not think that what you suggest is even remotely possible given the
> development cycles of Fedora and the ones of Red Hat Enterprise.
> 
> And I don't think it is necessary.

Perhaps having a user base isn't necessary. I doubt if RH would have 
ever attracted one in the beginning if they had not planned to support 
their users from development through production.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From seg at haxxed.com  Sun Oct 12 19:09:38 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 12 Oct 2008 14:09:38 -0500
Subject: CMake!
In-Reply-To: <80d7e4090810121105p75f6f6f5u346f615deab84367@mail.gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
	<80d7e4090810121105p75f6f6f5u346f615deab84367@mail.gmail.com>
Message-ID: <1223838578.26341.112.camel@localhost.localdomain>

On Sun, 2008-10-12 at 12:05 -0600, Stephen John Smoogen wrote:
> Ok the problem is that build tools are one of the things developers
> build strong relationships with (System administrators build it with
> their mail handler tools). You point out the deficiencies in someones
> choices of tools and the brain begins attack/flight/protect hormone
> chains. The same emotional centers in the brain as if you had picked
> up an axe and pointed it at someones family. The hormones get
> triggered and all logic circuits are cut off until the testosterone
> and serotonin get back down to lower levels. [I think its serotonin..
> it may be one of the other brain chemicals that get fired off in big
> numbers when this occurs.]

That assumes they're *happy* with their existing build system. If you're
happy with your build system, then fine, stay with it. All I'm saying
is, if you're not, consider CMake. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/f1304368/attachment.sig>

From smooge at gmail.com  Sun Oct 12 19:40:44 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sun, 12 Oct 2008 13:40:44 -0600
Subject: CMake!
In-Reply-To: <1223838578.26341.112.camel@localhost.localdomain>
References: <48ECE6CC.6030001@cora.nwra.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
	<80d7e4090810121105p75f6f6f5u346f615deab84367@mail.gmail.com>
	<1223838578.26341.112.camel@localhost.localdomain>
Message-ID: <80d7e4090810121240wa646230we429cf999ae309f3@mail.gmail.com>

2008/10/12 Callum Lerwick <seg at haxxed.com>:
> On Sun, 2008-10-12 at 12:05 -0600, Stephen John Smoogen wrote:
>> Ok the problem is that build tools are one of the things developers
>> build strong relationships with (System administrators build it with
>> their mail handler tools). You point out the deficiencies in someones
>> choices of tools and the brain begins attack/flight/protect hormone
>> chains. The same emotional centers in the brain as if you had picked
>> up an axe and pointed it at someones family. The hormones get
>> triggered and all logic circuits are cut off until the testosterone
>> and serotonin get back down to lower levels. [I think its serotonin..
>> it may be one of the other brain chemicals that get fired off in big
>> numbers when this occurs.]
>
> That assumes they're *happy* with their existing build system. If you're
> happy with your build system, then fine, stay with it. All I'm saying
> is, if you're not, consider CMake. :)
>

No it actually doesn't assume that sadly. The psychology has mostly
been studied in cars, but shows up in other choices also. A person may
hate every Ford part/car they have gotten for the last 4 years and say
it day in and day out, but ask them to switch to a Chevy/Toyota/etc
and the same reaction can occur.. In fact for some people the reaction
will be more active during such conversations because their brain has
mapped extra loyalty to the tool to deal with the fact the tool has
been failing or not doing what they want.

There are differences in software but the general human brain is the
same. It is built for survival against things that aren't as a big of
concern for most people and uses those circuits to deal with things
that on the evolutionary scale are small.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From vonbrand at inf.utfsm.cl  Sun Oct 12 19:48:21 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 16:48:21 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223677428.3564.1292.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
Message-ID: <200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> > >> Dmitry Butskoy wrote:
> > >> > Itamar - IspBrasil wrote:
> > [snip]
> > >> The fact that they switched to CentOS is *good* for Fedora.
> > > I can not disagree more - To me, it's yet another evidence of Fedora
> > > being on the loose.
> > 
> > You're going to have to expound on that. I do not see Centos in any
> > way as in competition with Fedora.

> EPEL drains away resources from Fedora.

Proof?

[People working on EPEL do so because they are interested in EPEL, which
 clearly isn't the same as being interested in Fedora... if EPEL went away,
 probably most of them would leave too.]

> If people were investing the time they (as I feel waste) on supporting
> EPEL into Fedora, Fedora would be better.

How true. But see above...

> >  Centos is something everyone should
> > be proud of.

> Well, to me CentOS is as important as any other arbitrary Linux distro.
> I am glad they are around, but not more and not less.

It is around becase RHEL is popular, and open source. A clone is
wellcome. And RHEL is popular in part because it works together with
Fedora.

> > >>  CentOS's
> > >> goals are better oriented to the needs of someone that wants to deploy a
> > >> system and run it for years.  Fedora is good for people who want to get
> > >> the latest technologies from upstream as soon as they're stable enough
> > >> to integrate into a running system.

> > > Right. But why can't Fedora do better? I feel Fedora could do better.

> > Sure. With more devs, servers, time, etc.

> ... less bureaucracy, less committees/less chiefs/more Indians,
> different people, different strategies.

Show how! Telling everybody here how awful things are going isn't helping
an iota. Everything has its limits, and for every desirable quality (newest
shiny toys, support for the newest fad in hardware in software) there is a
cost (can't be supported in the long range, fast turnaround, set procedures
to handle a huge stream of new stuff)

> >  But baring a sudden increase
> > in those, I would much prefer to see Fedora focus on dev and testing,
> > let other distros pretty things up.

> ACK. Unfortunately, Fedora is drifting away from this group towards
> single-user desktops (e.g. OLPC).

Then work towards drifting the opposite direction...

Fedora (or any other large group of people) will move where the majority
wants to go... 

> > >> > This situation seems to be reflected in the Fedora project itself.
> > >> > Guess, how many Fedora infrastructure servers are run under the latest
> > >> > "stable" Fedora release?

> > >> As few as possible.

> > > IMO, a fundamental management/infrastructure mistake - If these people
> > > were using Fedora, they would be facing the issues Fedora users are
> > > facing everyday and likely would being to understand why people complain
> > > about Fedora.

> > Why would they, after often suggesting that Fedora _not_ be used on
> > production servers, use Fedora on their production servers?

> Depends on how they mean it:
> - if they are referring to "long term maintained/everlasting support"
> servers, they are right.

"Servers" are "long-time maintained" by definition...

> - if they mean it as "Fedora is technically too unstable",

Because there is no "long term maintenance"...

>                                                            then this
> people should start working on improving the situation

Which one? Fedora is about /not/ "long term" but "bleeding edge"...

>                                                        or (better) quit
> Fedora.

Do so, then.
-- 
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 2340000       Fax:  +56 32 2797513



From christoph.wickert at googlemail.com  Sun Oct 12 19:28:08 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sun, 12 Oct 2008 21:28:08 +0200
Subject: Package review backlog.
In-Reply-To: <ufaprm6cj13.fsf@epithumia.math.uh.edu>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com>
	<1223731515.3923.23.camel@wicktop.localdomain>
	<48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>
	<1223737587.3923.29.camel@wicktop.localdomain>
	<ufaprm6cj13.fsf@epithumia.math.uh.edu>
Message-ID: <1223839688.18044.6.camel@wicktop.localdomain>

Am Sonntag, den 12.10.2008, 03:30 -0500 schrieb Jason L Tibbitts III:
> >>>>> "CW" == Christoph Wickert <christoph.wickert at com> writes:
> 
> CW> I know this one, but this page also returns reviews that are
> CW> already assigned.
> 
> Only a very small number; trivial to ignore them if that's what you
> want.

~390 out of ~1190. I would not call one third a very small number ;)

Regards,
Christoph



From lmacken at redhat.com  Sun Oct 12 19:59:31 2008
From: lmacken at redhat.com (Luke Macken)
Date: Sun, 12 Oct 2008 15:59:31 -0400
Subject: Bodhi error while doing a 'make update', and now I can't make
	an update for that tag
In-Reply-To: <1223789300.9768.12.camel@himiko.beav.virtualxistenz.com>
References: <1223789300.9768.12.camel@himiko.beav.virtualxistenz.com>
Message-ID: <20081012195931.GE3221@x300>

On Sat, Oct 11, 2008 at 10:28:20PM -0700, Caitlyn O'Hanna wrote:
> I attempted to push my update via the command line, and encountered an
> error from Bodhi while doing a 'make update'.  Now, I can't push the
> update via the web interface as it says the update exists, but it isn't
> listed with my other updates.  If I click on the link the error
> provides, it says that there isn't an update.  The tag for my update is
> pysvn-1_6_1-2_fc9.
> 
> Looking at the bug reports for Bodhi, it looks like I should have put
> just 'B' in the type field and not 'bugfix' as the template lead me to
> believe.

Nope, the template is correct.  The old style single-letter update types
are obsolete.

> Is there anything I can do to unclog this?  Thanks for any help.

It looks like due to a previous tag mismatch, koji threw a TagError when
bodhi attempted to obsolete and untag the previous pysvn update.

I cleaned up the stray build in bodhi, fixed the issue in git, rolled a
new release, and deployed it to our app servers.

Please give it another shot.

luke



From pertusus at free.fr  Sun Oct 12 20:02:38 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 22:02:38 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <gct38m$scd$1@ger.gmane.org>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr> <gct38m$scd$1@ger.gmane.org>
Message-ID: <20081012200238.GA2688@free.fr>

On Sun, Oct 12, 2008 at 09:57:47AM -0500, Rex Dieter wrote:
> 
> I perused the thread, but failed to find any reference to any authoritative statement that fedora infrastructure could not be used for such an effort.  Am I missing something?

There was no support, and hostility toward the project, for example,
but it is not the only one:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00802.html

In my response to that mail, failing to have a metric I retired my
proposal, and nobody supported my views (and overall nobody supported my
views).

I found the page, with a summary of why this was abandonned:
http://fedoraproject.org/wiki/DraftUAEL

I guess that Jef speaks for himself, but he also is on the board 
and he seemed authoritative enough to me.

--
Pat



From pertusus at free.fr  Sun Oct 12 20:11:02 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 22:11:02 +0200
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F22D29.90109@gmail.com>
References: <20081012134001.GC2700@free.fr> <48F21BB3.9060509@x-tnd.be>
	<48F22D29.90109@gmail.com>
Message-ID: <20081012201102.GB2688@free.fr>

On Sun, Oct 12, 2008 at 10:00:25AM -0700, Toshio Kuratomi wrote:
> > 
> When I brought this up, Bastien Nocera brought up security bugs and not
> wanting random people to be CC'd before a security bug is resolved.  How
> should we deal with this?

That's a valid issue. I didn't knew this happened in fedora. At least
the watchcommit should be automatic, since it is public anyway.

--
Pat



From otto_rey at yahoo.com.ar  Sun Oct 12 20:26:38 2008
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Sun, 12 Oct 2008 13:26:38 -0700 (PDT)
Subject: Fedora 9 + rawhide kernel/plymouth vs Fedora 10 rawhide - Plymouth
	or not plymouth... :D
Message-ID: <829216.87837.qm@web52402.mail.re2.yahoo.com>

Hardware: Notebook Toshiba Satelite, Athlon 64 X2, Radeon video chipset

Scenario 1 - Fedora 9 + updates (12-oct-2008) + rawhide kernel update (plymouth and others by dependecies), (12-oct-2008)

Plymouth showme a really nice fedora logo animation at startup. Everything works fine, no lficker screen, everything works really well except compiz (white screen)

Ok. I think that installing Rawhide, compiz will start working fine.


Scenario 2 - Fedora 10 Snapshot 1 + updates (12-oct-2008)  - Rawhide :)

Plymouth showme a sadly "text" progress bar at the button of screen. After login, screen flyck a little but compiz works fine.

I use plymouth-set-default-plugin solar (link in /usr/lib64/plymouth correctly changes) but no nice animation at startup, only ugly text progress bar.

I check rhgb boot parameter (this comes as default) and everything look correct, but no nice animation.

My question: how can i re-enable nice animation at startup? Should i file a bug?

Thanks



      Yahoo! Cocina
Recetas pr?cticas y comida saludable
http://ar.mujer.yahoo.com/cocina/



From dominik at greysector.net  Sun Oct 12 20:10:00 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sun, 12 Oct 2008 22:10:00 +0200
Subject: Package review backlog.
In-Reply-To: <48F24072.2010308@gmail.com>
References: <1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<48F07C5C.8000403@leemhuis.info> <48F24072.2010308@gmail.com>
Message-ID: <20081012200959.GC6604@mokona.greysector.net>

On Sunday, 12 October 2008 at 20:22, Toshio Kuratomi wrote:
> Thank you Thorsten!  This list is really really great!
> 
> Thorsten Leemhuis wrote:
> > Ideas for making things easier and better are there; they are afaics
> > well known among contributors and the different committees that are
> > responsible. Just nobody is working on them:
> > 
> >  * improve rpmlint and other tools to automate more of the checks to
> > less the burden on the reviewer
> > 
> We also need to note which Guildelines rpmlint completely checks for,
> partially checks for, and does not check for.
> 
> Licensing, for instance is a a case where rpmlint helps by verifying
> that the license tag matches the abbreviations we specify but does not
> verify that the source code only contains the listed license(s).

licensecheck.pl script from Debian's devscripts could help here. I've filed
an RFE for rpmdevtools: https://bugzilla.redhat.com/show_bug.cgi?id=466353

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From pertusus at free.fr  Sun Oct 12 20:42:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 22:42:43 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <gct38m$scd$1@ger.gmane.org>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr> <gct38m$scd$1@ger.gmane.org>
Message-ID: <20081012204243.GC2688@free.fr>

On Sun, Oct 12, 2008 at 09:57:47AM -0500, Rex Dieter wrote:
> 
> I perused the thread, but failed to find any reference to any authoritative statement that fedora infrastructure could not be used for such an effort.  Am I missing something?

In fact you are missing the previous thread, which is much longer, 
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02191.html

with, for example:
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02213.html
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02562.html

It ends with Jef Spaleta telling that it is sad that I voice my concerns
without taking the lead:
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02640.html

I ended up doing it by proposing UAEL, but without much more success
even if I took the lead I was shot down by the same Jef, on the metric
about packager investment in UAEL... I must say that, personnally for me
this was a bit bitter to see that unrealistic things are asked for to
shoot down an idea and that involvment is not necessarily enough to get
things done when some people oppose. 

--
Pat



From kevin.kofler at chello.at  Sun Oct 12 21:12:05 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 21:12:05 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr> <gct38m$scd$1@ger.gmane.org>
	<20081012200238.GA2688@free.fr>
Message-ID: <loom.20081012T205859-315@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:
> In my response to that mail, failing to have a metric I retired my
> proposal, and nobody supported my views (and overall nobody supported my
> views).

In terms of those metrics, I'm still in favor of a mostly anarchical approach:
* Don't promise *anything* yet - tell users that they may or may not get 
updates. Promises can come if the project turns out working.
* Lift *all* ACLs for the EOL branches (yes, even for the kernel).
* Security fixes can be committed and built by *anyone* without asking for 
anyone's approval.
* Likewise for bug fixes which went into the lowest maintained Fedora release 
(but they can be pushed to testing resp. stable no earlier than to testing 
resp. stable for that release).
* Anything else is strongly discouraged and needs approval from both the 
maintainer and some committee (which should be granted only in reasonable 
cases, such as new hardware support). (That's where the anarchy ends, otherwise 
we can end up in all sorts of absurd situations.) If necessary, offenders could 
be banned from committing to EOL branches.
* Just push out the results to the official Fedora repositories.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 12 21:19:57 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 21:19:57 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr> <gct38m$scd$1@ger.gmane.org>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
Message-ID: <loom.20081012T211319-320@post.gmane.org>

I wrote:
> In terms of those metrics, I'm still in favor of a mostly anarchical
> approach:
[snip]

Oh, and I forgot:
* *No* QA of the type the original Fedora Legacy had, where all updates had to 
reviewed before even pushing them to testing and tested before pushing them to 
stable. I believe it was this excessive QA which killed Fedora Legacy. Instead, 
it should be up to whoever submits the updates to decide whether to go through 
testing and when to push to stable, and no QA whatsoever should be required to 
push an update to testing, just as things work in all of Fedora. If the 
security team insists on it, the security team approval system for security 
updates could be applied (though I consider that completely unnecessary 
bureaucracy, but that's a separate rant), if they don't want to be approving 
security updates for EOL releases, then they should just go straight to stable.

        Kevin Kofler



From pertusus at free.fr  Sun Oct 12 21:21:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 12 Oct 2008 23:21:20 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081012T205859-315@post.gmane.org>
References: <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr> <gct38m$scd$1@ger.gmane.org>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
Message-ID: <20081012212120.GD2688@free.fr>

On Sun, Oct 12, 2008 at 09:12:05PM +0000, Kevin Kofler wrote:
> Patrice Dumas <pertusus <at> free.fr> writes:
> > In my response to that mail, failing to have a metric I retired my
> > proposal, and nobody supported my views (and overall nobody supported my
> > views).
> 
> In terms of those metrics, I'm still in favor of a mostly anarchical approach:

I completly agree. This is simple and leave everything to the packagers
initiative, I think that it is also what Ralf had in mind. But some people 
insisted on communicating to the public what was maintained, hence my 
proposal. But what you propose is better.

--
Pat



From hugh at mimosa.com  Sun Oct 12 21:33:13 2008
From: hugh at mimosa.com (D. Hugh Redelmeier)
Date: Sun, 12 Oct 2008 17:33:13 -0400 (EDT)
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F21617.7000707@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan> <48F21617.7000707@gmail.com>
Message-ID: <alpine.LRH.2.00.0810121651510.6827@redclaw.mimosa.com>

| From: Les Mikesell <lesmikesell at gmail.com>

| But the first question should be why a separate community is necessary.  Why
| is it not possible for one of fedora's goals to be to provide a clean
| transition to RHEL or Centos at the end of certain development cycles

I think that this idea has some merit.  I'm taking this out of context
to use as a jump-off point.

[I'm a long-term Red Hat and Fedora user.  I also use Ubuntu
sometimes.]

Ubuntu 8.04 LTS has seduced me with its simultaneous promises of being
maintained and having a current code base.

RHEL/CentOS feels too old.  Concrete issues:

- support for video cards

- PostgreSQL 8.3 vs 8.1

Ubuntu 8.04 will be quite stale before the next LTS comes out.
Probably more stale that RHEL/CentOS.  It is all a matter of where
each stream is in the cycle.  Right now, Ubuntu LTS is ahead of
RHEL/CentOS.

Ubuntu LTS is in the same series as regular Ubuntu.  RHEL/CentOS are
not the same as Fedora.  One could predict that the transition costs
between Ubuntus are lower that the transition costs from RHEL/CentOS
to or from Fedora.  This is a disadvantage.

I find the various Fedora-targeted 3rd party repositories confusing
and even conflicting.  This isn't healthy.  I've not had this problem
with Ubuntu but I'm not sure why.


I like that fedora is willing to take radical steps.  This is the only
way to do some important experiments.


Some changes make me (a conservative at heart) uncomfortable:

- the idea that network connectivity is part of a session just seems
  bizarre to me.  Network Manager may be useful but I think that this
  aspect does not fit in with my UNIX world-view.

- the idea that non-X consoles will go bothers me.  Just a few minutes
  ago, I used a non-X console to whack on an X problem.  I hit a lot
  of X problems due to the way hardware gets introduced more quickly
  than X versions are released (and debugged).  I may stop using
  Fedora when this change comes to pass.

- Documentation that I expect is not provided.

- the anatomy of the system changes more quickly than my
  understanding.  HAL/d-bus/etc. all seem like magic to me.



Why should a (source) package release be tied to a distro release?
For a lot of packages, the actual minimum requirements on the
environment are satisfied by earlier distro releases.

The strongest argument against is to do with testing: real
dependencies might diverge from declared dependencies and only testing
can show this.  This adds a lot of testing burden to the package
maintainer.

Some packages really are not independent modules.  Updating such a
package may require updating a lot of others.  At least sometimes
these binary packages are all created from a single source package.


I wonder if smooth evolution (frequent uncoordinated package updates),
as opposed to punctuated equilibrium (updates tied to distro releases)
would work.



From kevin.kofler at chello.at  Sun Oct 12 21:38:45 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 21:38:45 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>	<200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>
	<20081012152937.GA428@br-online.de> <48F246AA.8050408@gmail.com>
Message-ID: <loom.20081012T213250-651@post.gmane.org>

Les Mikesell <lesmikesell <at> gmail.com> writes:
> Again, that seems like bad planning.  Wasn't that predictable?

It was predictable, but not avoidable.

> But, there are people who claim to have don't successful upgrades from FC6 to 
> RHEL/Centos.
(I assume you mean "have done", not "have don't" which makes no sense.)

There are people who *claim* many things, I doubt their claims make sense, 
because really the first (and likely the last) RHEL which FC6 will have even 
the slightest chance of safely upgrading to will be RHEL 6. And that will be an 
upgrade skipping many Fedora releases and thus really bumpy. And at that point 
you'll have had a support hole of somewhere around 2 years!

Going from FC6 to RHEL 5 is essentially a downgrade, especially so if you got 
the numerous upgrades which went out after the FC6 release (if you never 
updated anything, not even security stuff, then you might have more success, 
but Fedora security upgrades are often new versions, RHEL security upgrades are 
usually backports) and the infrastructure doesn't support downgrades at all, 
neither Anaconda nor YUM support them.

        Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 12 21:55:16 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 21:55:16 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>	<200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>
	<80d7e4090810120830qbdc951dp3bf1ccdddc190ff9@mail.gmail.com>
	<48F24389.1030906@gmail.com>
Message-ID: <loom.20081012T213906-921@post.gmane.org>

Les Mikesell <lesmikesell <at> gmail.com> writes:
> user's perspective the approach was always wrong anyway.  It would be 
> good for both RHEL and fedora if they didn't really branch within a 
> version - that is, at some point the RH betas take over the 
> corresponding fedora release and fedora takes its wild and crazy changes 
> to a new release.

Look, what you're asking for is really impossible:

1. There is no way RHEL will branch from a near-EOL or EOL Fedora release just 
so you can safely upgrade from that version to RHEL. It would mean throwing out 
at least a year of development and going back to old stuff, and RHEL would ship 
with very outdated software (there are *already* complaints about its software 
being outdated, but that's unavoidable due to stabilization/QA and 
certification, but users would not tolerate even older software, they'd use a 
competitor with newer software). It would also not help those who already 
upgraded to a newer Fedora release.

2. There is also no way Fedora will stop pushing version upgrades to the 
releases RHEL gets branched from, that's not how Fedora works. Fedora is about 
bringing current software to our users and version upgrades are part of that. 
There are also several cases where backporting security fixes is much harder 
than just upgrading to a new version. It would also affect not just the version 
RHEL gets branched from, but the previous version (or even 2 versions below if 
it's the first month after a release) too, for obvious upgrade path reasons. 
And many Fedora users would see a move like that as RH perverting Fedora for 
their own purposes.

So Fedora will always have at least some packages which are newer than the RHEL 
versions at any point in time, and thus it is impossible to guarantee an 
upgrade path in that direction.

> Even so, some people claim to have done successful upgrades from fedora 
> to the corresponding EL/Centos with just a few quirks that probably 
> could have been avoided with a little central planning.

No amount of planning is going to avoid the fundamental impossibility outlined 
above. The upgrades you mention were either from long-EOL Fedora releases (that 
can work out, but it means months or even years without security updates!) or 
involved downgrading several packages (e.g. the kernel).

> That is, even if it is impossible to coordinate the changes that lead to
> RHEL/Centos, there should be a way to have the final fedora update do a clean 
> conversion - or at least better than most users could do on their own.

Even if you think there should be a way, the fact is that there is none.

         Kevin Kofler



From kevin.kofler at chello.at  Sun Oct 12 22:00:58 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 22:00:58 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<20081012162328.GQ10204@angus.ind.WPI.EDU>
Message-ID: <loom.20081012T220028-495@post.gmane.org>

Chuck Anderson <cra <at> WPI.EDU> writes:
> So we should make sure Fedora can upgrade old RHEL installations?

That actually mostly works. "upgradeany" is your friend.

        Kevin Kofler



From fedora at shmuelhome.mine.nu  Sun Oct 12 22:01:53 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Mon, 13 Oct 2008 00:01:53 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081012212120.GD2688@free.fr>
References: <20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<48F1C83F.5040200@fedoraproject.org>	<20081012100248.GB3936@free.fr>
	<gcsrr8$9mn$1@ger.gmane.org>	<20081012131811.GA2700@free.fr>
	<gct38m$scd$1@ger.gmane.org>	<20081012200238.GA2688@free.fr>	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
Message-ID: <48F273D1.6070604@shmuelhome.mine.nu>

Patrice Dumas wrote:
> On Sun, Oct 12, 2008 at 09:12:05PM +0000, Kevin Kofler wrote:
>   
>> Patrice Dumas <pertusus <at> free.fr> writes:
>>     
>>> In my response to that mail, failing to have a metric I retired my
>>> proposal, and nobody supported my views (and overall nobody supported my
>>> views).
>>>       
>> In terms of those metrics, I'm still in favor of a mostly anarchical approach:
>>     
>
> I completly agree. This is simple and leave everything to the packagers
> initiative, I think that it is also what Ralf had in mind. But some people 
> insisted on communicating to the public what was maintained, hence my 
> proposal. But what you propose is better.
>
> --
> Pat
>
>   
Up to here you definitely had my sympathy. But this anarchical approach 
makes me wonder who your target audience is. I would think that the 
majority of people who wouldn't want to upgrade to an official Fedora 
release would be people who need stability. Fedora itself  is probably a 
little bit too unstable for them. These people would probably want more 
than the average level of QA. To borrow a phrasing from Jef, legacy 
updates should be edible by babies.



From kevin.kofler at chello.at  Sun Oct 12 22:00:12 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 22:00:12 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>	<200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<48F23CDF.1090304@gmail.com>
Message-ID: <loom.20081012T215602-696@post.gmane.org>

Les Mikesell <lesmikesell <at> gmail.com> writes:
> With a planned progression to an enterprise version, that would not 
> really be a migration away from fedora but the expected end point where 
> you are permitted to continue using anything you've contributed or 
> developed for your own use, staying in the same community instead of 
> having all previous work dumped out the window at the end of a cycle. 

You don't have to throw away the development you've done, you just have to keep 
it updated with progress in technology. Or find somebody else who will, e.g. by 
getting your work integrated into some upstream project or by starting a Free 
Software project on your own. Fedora is not and will never be about "fire and 
forget" type of development.

        Kevin Kofler



From pertusus at free.fr  Sun Oct 12 22:26:13 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 00:26:13 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F273D1.6070604@shmuelhome.mine.nu>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr> <gct38m$scd$1@ger.gmane.org>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
Message-ID: <20081012222613.GF2688@free.fr>

On Mon, Oct 13, 2008 at 12:01:53AM +0200, shmuel siegel wrote:
>>   
> Up to here you definitely had my sympathy. But this anarchical approach  
> makes me wonder who your target audience is. I would think that the  
> majority of people who wouldn't want to upgrade to an official Fedora  
> release would be people who need stability. Fedora itself  is probably a  
> little bit too unstable for them. These people would probably want more  
> than the average level of QA. To borrow a phrasing from Jef, legacy  
> updates should be edible by babies.

More QA in EOL than in release doesn't make sense. This 'anarchical'
approach is not very anarchical given what kind of changes are allowed.

--
Pat



From emmanuel.seyman at club-internet.fr  Sun Oct 12 22:37:36 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 00:37:36 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F23CDF.1090304@gmail.com>
References: <200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<48F23CDF.1090304@gmail.com>
Message-ID: <20081012223736.GA19798@orient.maison.lan>

* Les Mikesell [12/10/2008 22:14] :
>
> Yes but what is the point of developing for it?

There's a notion called freedom that you may have heard of.

> With a planned progression to an enterprise version, that would not  
> really be a migration away from fedora but the expected end point where  

Again, this supposes that one of Fedora's end goals is to easily
permit its users to migrate to other distributions. This isn't the
case.

> you are permitted to continue using anything you've contributed or  
> developed for your own use, staying in the same community instead of  
> having all previous work dumped out the window at the end of a cycle.  

When a Fedora version release reaches EOL, users have the possibility
of upgrading to the next release. These days, they even have the option
of upgrading to the release following that one if they wait long enough.
I have no idea where you get the notion that we're guiding users to a
"planned dead-end" or that, once a Fedora release is EOL-ed, they have
to dump out their work out the window.

If your goal is to use an distribution that promises ABI/API
compatibility, long term support and other "enterprise" features, there
are a whole host of distributions for which these are goals.
Why not use them ?
 
Emmanuel



From vonbrand at inf.utfsm.cl  Sun Oct 12 22:37:50 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 19:37:50 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF79A4.2030103@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
Message-ID: <200810122237.m9CMboFx007148@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Patrice Dumas wrote:

[...]

> > It is a bit more complicated. A distro may begin its life bleeding
> > edge and become stable as time goes by, if it is still maintained. And
> > a stable distro may have parts that are bleeding-edge. This is not
> > necessarily easy to implement, but these scenarios certainly have
> > merits.

I don't see any... Sure, it might be nice for the (tiny minority) who wants
e.g. bleeding edge compiler (because they are hacking on it?) with a very
stable everything else.

> That was the way things worked when redhat developed its popularity.


No...

> An X.0 release was approximately as unstable as a fedora,

Not really.

>                                                           but as it
> updated to X.2 or X.3 it would have become very stable and people who
> started a development cycle with the early versions could keep the
> same OS in production as it matured.

But there was no guarantee whatsoever of a .1, a .2 or even a .3 would ever
materialize.

>                                      What we need

Who is the "we" here?

>                                                   for the same effect
> now is for the versions of fedora that provide the initial RHEL cuts
> to offer a seamless update to the subsequent matching CentOS,
> repointing to its update repositories for continued support.

If a majority of Fedora folks wanted that, Fedora would move like
that. Fedora Legacy wouldn't have gone belly up for lack of hands. And Red
Hat would have gone on doing .0, .1 and so on forever.
-- 
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 2340000       Fax:  +56 32 2797513



From vonbrand at inf.utfsm.cl  Sun Oct 12 22:40:59 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 19:40:59 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EF819B.8010607@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<loom.20081010T160239-992@post.gmane.org>
	<48EF819B.8010607@gmail.com>
Message-ID: <200810122241.m9CMf0kC007164@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> Fedora could make it's next release somewhere around the point where
> the paths start to diverge so people who wanted the fast-track
> unstable flavor could re-install as they apparently love to do, and
> the rest of us could just drift into stability.

Why would any Fedoran want to "drift into stability"? That is a
contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
Legacy would be alive and well, don't you think?
-- 
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 2340000       Fax:  +56 32 2797513



From pertusus at free.fr  Sun Oct 12 22:44:24 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 00:44:24 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810122241.m9CMf0kC007164@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<loom.20081010T160239-992@post.gmane.org>
	<48EF819B.8010607@gmail.com>
	<200810122241.m9CMf0kC007164@laptop14.inf.utfsm.cl>
Message-ID: <20081012224424.GG2688@free.fr>

On Sun, Oct 12, 2008 at 07:40:59PM -0300, Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> [...]
> 
> > Fedora could make it's next release somewhere around the point where
> > the paths start to diverge so people who wanted the fast-track
> > unstable flavor could re-install as they apparently love to do, and
> > the rest of us could just drift into stability.
> 
> Why would any Fedoran want to "drift into stability"? That is a
> contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
> Legacy would be alive and well, don't you think?

Things have changed since Fedora Legacy. Core has opened and 
infrastructure has seen many improvements. What was not practical in the
old days is, in my opinion, possible now.

--
Pat



From dr.diesel at gmail.com  Sun Oct 12 22:45:39 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Sun, 12 Oct 2008 18:45:39 -0400
Subject: F10B2 Install Bug?
Message-ID: <2a28d2ab0810121545u460760e6v3e599f345445efe3@mail.gmail.com>

I've installed Fedora since FC1, this was a new one on me!

When choosing the disk layout the installed seemed to format the wrong disk!

Here is/was my setup:

Toshiba Laptop with 120G internal Hitachi HD (already loaded with F10B2),
internal DVD drive and an USB Seagate 80G drive that I was going to install
to.  When I got to the disk partitioning section I choose to Remove all
partitions from disk, unchecked the Hitachi "Use this disk for
installation", Seagate disk was already checked and changed the boot from
disk from the Hitachi to the Seagate disk.  I did not review the layout and
pressed next, clicked "write changes to disk" then it crashed.  Didn't think
much about it, only that somehow I confused it trying to install to the USB
disk until I went to reboot using the normal internal Hitachi drive.  While
booting grub came up with my normal kernel options, choose my latest kernel
and hit enter, from there booting crashed not being able to find the logical
volume!

Is there an installer bug that formatted the wrong disk, or was I having a
mild stroke when configuring the disk layout?

Andy

-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/813a3528/attachment.htm>

From ravenoak at virtualxistenz.com  Sun Oct 12 22:50:51 2008
From: ravenoak at virtualxistenz.com (Caitlyn O'Hanna)
Date: Sun, 12 Oct 2008 15:50:51 -0700
Subject: Bodhi error while doing a 'make update', and now I can't make
	an update for that tag
In-Reply-To: <20081012195931.GE3221@x300>
References: <1223789300.9768.12.camel@himiko.beav.virtualxistenz.com>
	<20081012195931.GE3221@x300>
Message-ID: <1223851851.20064.7.camel@himiko.beav.virtualxistenz.com>

On Sun, 2008-10-12 at 15:59 -0400, Luke Macken wrote:

> Nope, the template is correct.  The old style single-letter update types
> are obsolete.

OK, there are still some bug reports open that mention the
single-letter vs. word thing.  The traceback from bodhi looked like a
key error, IIRC (I don't have it any more), so that is why I thought
that it fit.

> It looks like due to a previous tag mismatch, koji threw a TagError when
> bodhi attempted to obsolete and untag the previous pysvn update.
> 
> I cleaned up the stray build in bodhi, fixed the issue in git, rolled a
> new release, and deployed it to our app servers.
> 
> Please give it another shot.

Thanks Luke!  It worked this time.


--Caitlyn



From fedora at shmuelhome.mine.nu  Sun Oct 12 22:58:02 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Mon, 13 Oct 2008 00:58:02 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081012222613.GF2688@free.fr>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<48F1C83F.5040200@fedoraproject.org>	<20081012100248.GB3936@free.fr>
	<gcsrr8$9mn$1@ger.gmane.org>	<20081012131811.GA2700@free.fr>
	<gct38m$scd$1@ger.gmane.org>	<20081012200238.GA2688@free.fr>	<loom.20081012T205859-315@post.gmane.org>	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
Message-ID: <48F280FA.8010507@shmuelhome.mine.nu>

Patrice Dumas wrote:
> On Mon, Oct 13, 2008 at 12:01:53AM +0200, shmuel siegel wrote:
>   
>>>   
>>>       
>> Up to here you definitely had my sympathy. But this anarchical approach  
>> makes me wonder who your target audience is. I would think that the  
>> majority of people who wouldn't want to upgrade to an official Fedora  
>> release would be people who need stability. Fedora itself  is probably a  
>> little bit too unstable for them. These people would probably want more  
>> than the average level of QA. To borrow a phrasing from Jef, legacy  
>> updates should be edible by babies.
>>     
>
> More QA in EOL than in release doesn't make sense. This 'anarchical'
> approach is not very anarchical given what kind of changes are allowed.
>
> --
> Pat
>
>   
 From a developer's point of view you are right. But I believe that the 
majority of risk takers would upgrade before the end of life simply 
because they want the newer stuff. Like I said, I am at a loss to 
understand who your target audience is. I identified my concept of a 
target audience, one that doesn't want the instability of an upgrade. 
Who is your target audience and how big do you expect this audience to 
be? Are there any statistics from Fedora legacy which would indicate the 
demand for the product? Any surveys indicating what people wanted from a 
Fedora legacy.
Don't get me wrong. I am not trying to discourage you. I am trying to 
help you build a better use case.



From kevin.kofler at chello.at  Sun Oct 12 23:08:47 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 12 Oct 2008 23:08:47 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<48F1C83F.5040200@fedoraproject.org>	<20081012100248.GB3936@free.fr>
	<gcsrr8$9mn$1@ger.gmane.org>	<20081012131811.GA2700@free.fr>
	<gct38m$scd$1@ger.gmane.org>	<20081012200238.GA2688@free.fr>	<loom.20081012T205859-315@post.gmane.org>	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
Message-ID: <loom.20081012T230422-741@post.gmane.org>

shmuel siegel <fedora <at> shmuelhome.mine.nu> writes:
>
> Patrice Dumas wrote:
> > More QA in EOL than in release doesn't make sense. This 'anarchical'
> > approach is not very anarchical given what kind of changes are allowed.
>
>  From a developer's point of view you are right. But I believe that the 
> majority of risk takers would upgrade before the end of life simply 
> because they want the newer stuff.

We're just being pragmatic. It doesn't make sense to demand more QA than we 
have the resources to provide, that is what ultimately made Fedora Legacy fail.

        Kevin Kofler



From fedora at shmuelhome.mine.nu  Sun Oct 12 23:30:43 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Mon, 13 Oct 2008 01:30:43 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081012T230422-741@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<48F1C83F.5040200@fedoraproject.org>	<20081012100248.GB3936@free.fr>	<gcsrr8$9mn$1@ger.gmane.org>	<20081012131811.GA2700@free.fr>	<gct38m$scd$1@ger.gmane.org>	<20081012200238.GA2688@free.fr>	<loom.20081012T205859-315@post.gmane.org>	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>	<20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
Message-ID: <48F288A3.8000601@shmuelhome.mine.nu>

Kevin Kofler wrote:
> shmuel siegel <fedora <at> shmuelhome.mine.nu> writes:
>   
>> Patrice Dumas wrote:
>>     
>>> More QA in EOL than in release doesn't make sense. This 'anarchical'
>>> approach is not very anarchical given what kind of changes are allowed.
>>>       
>>  From a developer's point of view you are right. But I believe that the 
>> majority of risk takers would upgrade before the end of life simply 
>> because they want the newer stuff.
>>     
>
> We're just being pragmatic. It doesn't make sense to demand more QA than we 
> have the resources to provide, that is what ultimately made Fedora Legacy fail.
>
>         Kevin Kofler
>
>   
I disagree. You are not being pragmatic. You are looking for 
infrastructure support from Fedora without indicating that there is a 
benefit to Fedora. Supply without demand is no more useful than demand 
without supply. Since Fedora views itself as "the cutting edge distro", 
you have an uphill PR fight. Give the Fedora project a reason to spend 
some of their limited resources on you. At least let them know your 
target audience and why they would be interested.



From jkeating at redhat.com  Sun Oct 12 23:55:55 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 12 Oct 2008 16:55:55 -0700
Subject: Regarding install options
In-Reply-To: <1223791786.3564.1322.camel@beck.corsepiu.local>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
Message-ID: <1223855755.3327.12.camel@luminos.localdomain>

On Sun, 2008-10-12 at 08:09 +0200, Ralf Corsepius wrote:
> Sure, yum + rpm are a requirement.

And now you're dragging in python, plus the rest of yum's deps, which
I've already been told by many other people (at FUDCons, IRC, mail,
etc..) is not a "minimal" install.  Congratulations you've just walked
into a decade + argument. 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/71bc29e6/attachment.sig>

From lesmikesell at gmail.com  Sun Oct 12 23:56:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 18:56:49 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810122241.m9CMf0kC007164@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<loom.20081010T160239-992@post.gmane.org>
	<48EF819B.8010607@gmail.com>
	<200810122241.m9CMf0kC007164@laptop14.inf.utfsm.cl>
Message-ID: <48F28EC1.107@gmail.com>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> [...]
> 
>> Fedora could make it's next release somewhere around the point where
>> the paths start to diverge so people who wanted the fast-track
>> unstable flavor could re-install as they apparently love to do, and
>> the rest of us could just drift into stability.
> 
> Why would any Fedoran want to "drift into stability"? That is a
> contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
> Legacy would be alive and well, don't you think?

No, Fedora, legacy or not, is not good at maintaining stability. I'm not 
surprised it didn't work and wouldn't expect it to work if revived. 
What people actually do is run RHEL or Centos for their actual work. 
Which leaves the question of how to get from one to the other as you 
develop something new, then want to run it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From vonbrand at inf.utfsm.cl  Sun Oct 12 23:58:10 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 20:58:10 -0300
Subject: CMake!
In-Reply-To: <loom.20081012T173610-940@post.gmane.org>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
Message-ID: <200810122358.m9CNwAQE010549@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> Ralf Corsepius <rc040203 <at> freenet.de> writes:
> > On Sat, 2008-10-11 at 01:20 +0200, Lennart Poettering wrote:
> > > Oh, and I think that cmake is a big trainwreck.
> > I share this view. Cmake is imake in new clothes and suffers from the
> > same design flaws as imake did.
> 
> Like for example?

> The complaints I've read about imake is that it has tables for what
> systems have what properties and that you had to maintain those. Assuming
> that's true (I haven't actually used imake), that's very different from
> how CMake works. CMake can do configure checks just like autoconf, the
> difference is that it won't waste time on tests you didn't ask for (and
> thus won't use the results of anyway), like the existence of ubiquitous
> ISO C90 headers like <string.h> or ubiquitous ISO C90 functions like
> memcpy and memset.

Sorry, but either you cater to all strange systems out there (autotools and
it's ilk) or target a narrow subset. The later is easier, the former
implies looking if some stuff that "normal" systems have (_of course_) are
present... can't have both.

> > It's only the limited set of requirements being used by the limited set
> > of use cases it's proponents apply which lets them think "cmake is
> > better".

Limiting yourself to the range of stuff really relevant is good advise...

> CMake is used by all of KDE 4, and several other projects have switched
> to CMake following that example (or in some cases, because the KDE
> Window$ porters did the port for them), and I'm not aware of anyone
> having switched back.

Yes. But what was proposed here is switching /all/ packages using those to
cmake (or some such). Won't happen. And doing it in Fedora only is madness.
-- 
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 2340000       Fax:  +56 32 2797513



From jkeating at redhat.com  Mon Oct 13 00:21:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 12 Oct 2008 17:21:06 -0700
Subject: Package warning - Rawhide
In-Reply-To: <1223830180.3487.8.camel@hughsie-laptop>
References: <48F1BBE2.5050406@fedoraproject.org>
	<1223826721.3487.3.camel@hughsie-laptop> <48F22015.40704@poolshark.org>
	<1223830180.3487.8.camel@hughsie-laptop>
Message-ID: <1223857266.3327.13.camel@luminos.localdomain>

On Sun, 2008-10-12 at 17:49 +0100, Richard Hughes wrote:
> On Sun, 2008-10-12 at 18:04 +0200, Denis Leroy wrote:
> > This is a property of the repository, not of the package manager. If
> > the rawhide repo is fundamentally unsigned, this should be a property
> > in the .repo file itself, not a global property.
> 
> Sure, this policy is only used if the repo is set to unsigned.
> 
> Richard.
> 
> 

Which the rawhide repos (as shipped) are set to unsigned, until we can
get an automated signing system in place.  I don't think I'll be signing
up to getting online at 2am every day to sign all the packages built for
the day just before the rawhide compose.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/513c0a45/attachment.sig>

From kevin.kofler at chello.at  Mon Oct 13 00:22:42 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 00:22:42 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<48F1C83F.5040200@fedoraproject.org>	<20081012100248.GB3936@free.fr>	<gcsrr8$9mn$1@ger.gmane.org>	<20081012131811.GA2700@free.fr>	<gct38m$scd$1@ger.gmane.org>	<20081012200238.GA2688@free.fr>	<loom.20081012T205859-315@post.gmane.org>	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>	<20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
Message-ID: <loom.20081013T001327-394@post.gmane.org>

shmuel siegel <fedora <at> shmuelhome.mine.nu> writes:
> I disagree. You are not being pragmatic. You are looking for 
> infrastructure support from Fedora without indicating that there is a 
> benefit to Fedora. Supply without demand is no more useful than demand 
> without supply. Since Fedora views itself as "the cutting edge distro", 
> you have an uphill PR fight. Give the Fedora project a reason to spend 
> some of their limited resources on you. At least let them know your 
> target audience and why they would be interested.

My point of view is: If there are people wanting to do the work, why not let 
them? It costs almost nothing to just let people commit and build what they 
want, the infrastructure is essentially already there. Right now, we're stuck 
in a chicken&egg situation, where the people controlling the infrastructure 
say "show us interested maintainers first" and potentially interested packagers 
say "show us the infrastructure first".

My interest in this project doesn't go much farther than that - well, I could 
build KDE security updates, which are few and far between, I might even help 
with xine-lib security updates (which are more of a PITA), but I have only 
limited interest in old stuff -, but I think there are people who would build 
the important updates, it was overreaching bureaucracy which killed Fedora 
Legacy (e.g. excessive QA requirements, paranoia such as not trusting 
Bugzilla's authentication mechanisms, instead requiring GPG signing of Bugzilla 
comments, which raised the barrier to entry), not lack of interested 
developers.

        Kevin Kofler



From braden at endoframe.com  Mon Oct 13 00:42:56 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 12 Oct 2008 20:42:56 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081012T175955-65@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<1223800236.9402.13.camel@arekh.okg>
	<1223803167.13589.457.camel@hinge.endoframe.net>
	<loom.20081012T175955-65@post.gmane.org>
Message-ID: <1223858576.8635.8.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 18:08 +0000, Kevin Kofler wrote: 
> Braden McDaniel <braden <at> endoframe.com> writes:
> >
> > On Sun, 2008-10-12 at 10:30 +0200, Nicolas Mailhot wrote:
> > > So if Oracle was freely redistributable tomorrow an rpm that just put
> > > the pre-generated Oracle files in the right place would be ok with you?
> > 
> > Getting to this question from what I said requires so many logical leaps
> > that it's not worth entertaining.
> 
> For you, all the questions you cannot answer are "not worth entertaining". :-/

That's a baseless assertion.  If you're really interested in my answer,
mail me off-list.  I'm not going to do it here because the question is
an obvious attempt at baiting with the goal of making this thread less
useful for coming to any sort of conclusion.

> > Are you claiming that by creating tarballs that are designed to be used
> > without having the autotools installed, the GNU build system is
> > impairing free software?
> 
> I'll let Nicolas answer that (as he's the one you asked), but generated files 
> definitely make it harder to exert your freedom to modify the software 
> (especially if you need the exact same versions of the autotools or you run 
> into trouble, which is what spawned your guideline and thus this discussion in 
> the first place) and I don't see what advantages they bring.
> 
> > "Ground" level is the upstream source provided by the developer.
> 
> But here what upstream includes is _not_ source, it's a generated file!

That distinction requires knowledge of the toolchain; it is deliberately
designed to be irrelevant to tarball users (of which rpmbuild is one).
And aside from exceptional situations, it is.

Guidelines aren't generally about exceptional situations.  They're about
articulating best practice for common situations.  Exceptional
situations frequently warrant... exceptions.

> If you define everything in the upstream tarball as "source", then Oracle's 
> binaries are "source" too, which is absurd.

What Oracle provides in their tarball is the source for an RPM generated
from that tarball.  That's a statement of fact, regardless of the form
the source takes or how it must (or must not) be transformed in the
process of creating the RPM.

You are welcome to find a more specific term for what you mean. "Source"
has a more general meaning than the one you're trying to apply.

> > Applying necessary patches to the build scripts in order to build
> > binaries does not make anything less free.
> 
> Sure, but forbidding us to patch the actual source code on the ground that 
> it "invites breakage" does.

Maybe you should reread the subject of this thread. I haven't advocated
"forbidding" anything.

> > If a packager wants to include changes to the build script sources in
> > the source RPM, I have absolutely no objection to that.  But applying
> > those changes as part of the build wins nothing and invites breakage.
> 
> Why should we jump through hoops to patch generated files and regularly update 
> the patches because they'll invariably break if we can just run autoreconf? It 
> is our (the individual package maintainers') problem to fix things if an 
> autotools update breaks them anyway!

Because it affects more than just you.  We won't have libtool2 in Fedora
10 because people do what you're advocating.  That means there are
upstream developers who will be waiting that much longer for it and not
taking care of problems upstream on their own.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From vonbrand at inf.utfsm.cl  Mon Oct 13 00:45:01 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 21:45:01 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
Message-ID: <200810130045.m9D0j1Gn014225@laptop14.inf.utfsm.cl>

Henrique Junior <henriquecsj at gmail.com> wrote:
> I would like to share with you an situation related to Fedora's time
> of life that comes to me in recent days.
> I was recently promoted to Software Manager in the governmental
> partition where I work. Next year we've plans to migrate 500 Linux
> desktop stations and, in the last month, finished the migration of all
> servers to CentOS.
> The question that worries me is that, despite the willingness to use
> Fedora, dealing with an "end of life" of 13 months can make Fedora
> impractical in these 500 desktops. I'll be pressed to use Ubuntu and
> even got to think about maintain by myself an repository for
> maintaining, maybe, the most important RPMs always updated even if the
> Fedora come to the inevitable 13 months of use.
> Perhaps it is time to seek volunteers to bring back the Fedora Legacy
> and see if more people are interested this time.

Isn't CentOS enough for your desktop use?

Futzing around with two philosphies of how to handle packages,
configuration, etc is very definitely not fun. We had such a setup for a
time (Solaris on SPARC servers and Red Hat on workstations (yes, it was
long ago)), and we moved the SPARCs to Red Hat as soon as practical.

Later we moved to Fedora everywhere (needed in lab workstations, where
users demand latest bling), but it was a pain on the server side, so we
settled on CentOS there.
-- 
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 2340000       Fax:  +56 32 2797513



From vonbrand at inf.utfsm.cl  Mon Oct 13 00:53:24 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 21:53:24 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>
	<4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>
	<1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>
Message-ID: <200810130053.m9D0rOcw014248@laptop14.inf.utfsm.cl>

Robert Locke <lists at ralii.com> wrote:

[...]

> What I think is lacking (but seem to be being worked on), is a
> convenient "upgrade" process within the "family".  So that if I use
> Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
> comes out.

By the time RHEL/CentOS comes out, the Fedora from which it branched has
long moved past it...
 
> Historically, using RHEL/CentOS for desktop has been problematic for
> some given their "stability" and "lack of movement".

For many desktop uses the latest bling is definitely not a requirement,
more the contrary.  Sure, on notebooks stuff like WiFi is required (and
needs a newer kernel, etc). Perhaps a line with the required packages
(paralell to EPEL) would be doable?

>                                                      But it does appear
> that this is changing.  Looking at RHEL/CentOS 5.2 compared to 5.0,
> there are some actual version upgrades to some of the packages, so
> perhaps it becomes more feasible for more people as a desktop.

It has always been that selected packages get version upgrades during
RHEL's life. I'd suspect that happens when the pain of backporting gets too
large and the visible differences are small enough to not make a
difference. I.e., it helps you not a bit to get an "up to date desktop".
-- 
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 2340000       Fax:  +56 32 2797513



From lesmikesell at gmail.com  Mon Oct 13 00:59:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 19:59:28 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081012223736.GA19798@orient.maison.lan>
References: <200810120042.45039.opensource@till.name>	<20081011232449.GD8235@free.fr>	<200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>	<20081012160303.GA17461@orient.maison.lan>	<48F23CDF.1090304@gmail.com>
	<20081012223736.GA19798@orient.maison.lan>
Message-ID: <48F29D70.4020808@gmail.com>

Emmanuel Seyman wrote:
>
>> Yes but what is the point of developing for it?
> 
> There's a notion called freedom that you may have heard of.

And how is that specific to Fedora?  I meant as opposed to a system 
where you can actually deploy something that needs stability.

>> With a planned progression to an enterprise version, that would not  
>> really be a migration away from fedora but the expected end point where  
> 
> Again, this supposes that one of Fedora's end goals is to easily
> permit its users to migrate to other distributions. This isn't the
> case.

Agreed, Fedora does not seem suitable as is.

>> you are permitted to continue using anything you've contributed or  
>> developed for your own use, staying in the same community instead of  
>> having all previous work dumped out the window at the end of a cycle.  
> 
> When a Fedora version release reaches EOL, users have the possibility
> of upgrading to the next release. These days, they even have the option
> of upgrading to the release following that one if they wait long enough.
> I have no idea where you get the notion that we're guiding users to a
> "planned dead-end" or that, once a Fedora release is EOL-ed, they have
> to dump out their work out the window.

I've used Fedora... Every version ends support quickly.  Frequently the 
next version has completely incompatible versions of libraries, 
programs, and API's.  It's not something you can run in production.

> If your goal is to use an distribution that promises ABI/API
> compatibility, long term support and other "enterprise" features, there
> are a whole host of distributions for which these are goals.
> Why not use them ?

Local development for things you want to put into production progresses 
at about the same rate as the system itself.  If you wait for an 
enterprise version's release before starting, you'll be about a year and 
a half behind.  If you develop on the previous enterprise version, there 
will be a huge version jump in libraries, database versions, jvms, etc. 
that will require changes and not take advantage of new capabilities. 
For all the same reasons that the Fedora components need to be developed 
together, so does local development for the things you want to run on it 
- but Fedora never turns into something you can use for a long term or 
where you need reliability.

-- 
    Les Mikesell
     lesmikesell at gmail.com




From jspaleta at gmail.com  Mon Oct 13 01:02:30 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 12 Oct 2008 17:02:30 -0800
Subject: reviving Fedora Legacy
In-Reply-To: <20081012154755.GP10204@angus.ind.WPI.EDU>
References: <200810111658.49564.opensource@till.name>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu> <20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
Message-ID: <604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>

On Sun, Oct 12, 2008 at 7:47 AM, Chuck Anderson <cra at wpi.edu> wrote:
> 2. Jeff Spaleta wanted metrics and verification to be sure the UAEL
> maintainers were actually doing their job and maintaining the packages
> they said they would, and metrics to be sure no one maintainer took on
> too large of a load to prevent from getting burned out.
>
> I think it is unrealistic to require more oversight for UAEL than
> there is for regular Fedora maintainers.  Trust that they will do the
> work.  If they don't, follow the same policies and procedures we have
> to deal with that in Fedora today.

I think its unrealistic to not require more oversight for something
that is essentially an open-ended commitment.  if you are going to
leave it as an open-ended commitment with no firm EOL on the branch
then yes... i want metrics to make sure we aren't leaving people stuck
in a weird state for critical but unmaintained items for what could be
years.  I also do not accept the idea that its okay to open up a
Fedora branded branch which gives users absolutely no guidance as to
how long the packages branch will be usable.  I think its a poor use
of the brand.

I'm not talking about QA.. I'm talking about verifying that the
volunteer maintainers are actually still in place a year+ later.  How
do make users aware that packages are unmaintained for 1+ years? Do
you plan to expire unmaintained packages so new users don't have
access to them?You have to have some process to verify that the
maintainers are there because you are explicitly stating that the life
of branch depends on an accurate count of the active maintainers. if
you don't build a process to try to verify maintainer involvement..the
branches could live forever because there is no pre-defined EOL.

If the UAEL draft is not updated to include some firm EOL
expectations, I will continue to push back concerning metrics as to
maintainer commitment because the plan relies on maintainer commitment
to set the EOL timeframe.  How to address that concern is completely
unexplored because up till this point the proponents haven't cared to
try to address it.

Honestly after several days of discussion this week are the proponents
any further along than what was proposed in the UAEL draft? I haven't
seen a single new idea.  Until someone new, who is committed to moving
an implementation forward steps forward, this discussion is moot.
Would WPI give you some infrastructure resources to burn on this to
supplement existing project infrastructure to demonstrate that it was
a sustainable effort?


-jef



From vonbrand at inf.utfsm.cl  Mon Oct 13 01:03:19 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 22:03:19 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <1223804148.3564.1355.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
Message-ID: <200810130103.m9D13JM6014291@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:

[...]

> Openly said, my impression that certain parties in Fedora fear a Fedora
> LTS rsp. life-time-extended Fedora to compete with RH products.

CentOS or other repackaged RHEL is a /much/ greater threat than any Fedora
LTS could ever be... and much easier to maintain to boot. And Red Hat is
going out of its way to make them possible (by segregating the Red Hat only
stuff in easily replaced packages, by not adding a Red Hat icon to
everything they ship (that would be rather easy), by keeping the
distribution as such under GPL, by making the SRPMs publicly available,
even if they aren't forced to do so (yes, there is lots of non-GPL stuff in
RHEL; and GPL doesn't say you have to give source out to everybody freely,
just to anybody who got the binaries and asks)).

This conspiracy theory makes little sense (does any?).
-- 
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 2340000       Fax:  +56 32 2797513



From jspaleta at gmail.com  Mon Oct 13 01:04:23 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 12 Oct 2008 17:04:23 -0800
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T001327-394@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
Message-ID: <604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>

On Sun, Oct 12, 2008 at 4:22 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> My point of view is: If there are people wanting to do the work, why not let
> them? It costs almost nothing to just let people commit and build what they
> want, the infrastructure is essentially already there. Right now, we're stuck
> in a chicken&egg situation, where the people controlling the infrastructure
> say "show us interested maintainers first" and potentially interested packagers
> say "show us the infrastructure first".


Okay...if you start with enough maintainers... how do you plan to
verify that you continue to have enough maintainers to hold a branch
open?  Without a firm timeline on when to close a branch.. will we
ever see a branch close?

-jef



From rda at rincon.com  Mon Oct 13 01:22:16 2008
From: rda at rincon.com (Bob Arendt)
Date: Sun, 12 Oct 2008 18:22:16 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
References: <200810111658.49564.opensource@till.name>	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<20081012105804.GA6353@orient.maison.lan>	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
Message-ID: <48F2A2C8.2020306@rincon.com>

Jeff Spaleta wrote:
> I'm not talking about QA.. I'm talking about verifying that the
> volunteer maintainers are actually still in place a year+ later.  How
> do make users aware that packages are unmaintained for 1+ years? Do
> you plan to expire unmaintained packages so new users don't have
> access to them?You have to have some process to verify that the
> maintainers are there because you are explicitly stating that the life
> of branch depends on an accurate count of the active maintainers. if
> you don't build a process to try to verify maintainer involvement..the
> branches could live forever because there is no pre-defined EOL.
>
>   
I really don't see how a Fedora Legacy can be maintained.  If the goal 
is increased
stability and security patches, you need to guarantee that you have 
folks supporting
backpatches to the kernel, glibc, firefox, evolution,  openoffice, and 
several other large
and complex packages.  Incorporating new security patches into old 
baselines is *hard*.
Plus Fedora would "fork" a new release every 6 months.  How many legacy
Fedora's would be retained?  At some point it seems the legacy volunteer 
force
would saturate and legacy Fedora's would have to start dropping off 
every 6 months.



From lesmikesell at gmail.com  Mon Oct 13 01:23:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 20:23:49 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081010175427.GA7389@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>	<20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
Message-ID: <48F2A325.3090704@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [10/10/2008 19:45] :
>>                                  What we need for the same effect now is  
>> for the versions of fedora that provide the initial RHEL cuts to offer a  
>> seamless update to the subsequent matching CentOS, repointing to its  
>> update repositories for continued support.
> 
> I'ld expect migration guides and packages from Fedora to $DISTRIBUTION
> to be written by the $DISTRIBUTION community, not Fedora's.

Why, when Fedora is the one stopping support for the users that adapted 
to a particular Fedora version?  I'm suggestion this migration as a 
substitute for the  ongoing support that is lacking.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From vonbrand at inf.utfsm.cl  Mon Oct 13 01:32:51 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 22:32:51 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081012152831.GA17239@orient.maison.lan>
References: <200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<20081012142512.GE2700@free.fr>
	<20081012144338.GA16066@orient.maison.lan>
	<20081012145040.GF2700@free.fr>
	<20081012152831.GA17239@orient.maison.lan>
Message-ID: <200810130132.m9D1WpGV014409@laptop14.inf.utfsm.cl>

Emmanuel Seyman <emmanuel.seyman at club-internet.fr> wrote:
> * Patrice Dumas [12/10/2008 16:51] :
> > Which work? Not shutting down builders and other infras for the EOL 
> > branches?

> Not just not shutting them down but actively maintaining them, which
> would require more work than maintaining the non-EOL branches.

I fail to see what the big job is here, but whatever.

> I'm sorry but, until there's a community committed to actually doing
> the work,

Backporting fixes, handling bug reports, ... Note that here you _can't_
rely on upstream, they generally aren't interested in ancient versions, so
this is /much/ more work than regular maintainership.

>           asking that infrastructure be created/adapted/maintained is an
> unreasonable request, IMHO.

Nodz.
-- 
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 2340000       Fax:  +56 32 2797513



From kevin.kofler at chello.at  Mon Oct 13 01:37:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 01:37:44 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<1223800236.9402.13.camel@arekh.okg>
	<1223803167.13589.457.camel@hinge.endoframe.net>
	<loom.20081012T175955-65@post.gmane.org>
	<1223858576.8635.8.camel@hinge.endoframe.net>
Message-ID: <loom.20081013T013446-292@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> You are welcome to find a more specific term for what you mean. "Source"
> has a more general meaning than the one you're trying to apply.

I'm using the definition in the GPL:
> The ?source code? for a work means the preferred form of the work for making
> modifications to it.

Obviously autogenerated files are not "source code" under that definition. You 
are the one using the wrong term.

        Kevin Kofler



From the.masch at gmail.com  Mon Oct 13 01:39:18 2008
From: the.masch at gmail.com (Mario Chacon)
Date: Sun, 12 Oct 2008 22:39:18 -0300
Subject: F10 - X Server GUI Critical Problem!
Message-ID: <93d66b780810121839tc564de7s58e37947b806ed84@mail.gmail.com>

HI!
I have nVidia Corporation G71 [GeForce 7950 GT] and random times i
lost X Server GUI, i have no Video and no keyword. All other program
running in the machine works great, http server, SSH server, etc.

Can i do something to fix it?... 4 or 5 days ago i did not have this problem.

Salu2...



From bos at serpentine.com  Mon Oct 13 01:41:59 2008
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sun, 12 Oct 2008 18:41:59 -0700
Subject: Splitting a package apart - normal package review needed?
Message-ID: <c290c4f20810121841w6875375bhde0a750800e0e7fc@mail.gmail.com>

We're pondering splitting the ghc (Glasgow Haskell Compiler) package
into two: bsae ghc (retaining the ghc name) and ghc-platform (standard
libraries). The need for this is driven by the fact that ghc and its
standard libraries are going to be developed separately, and released
on different cycles. (The "ghc-" prefix for the platform package
merely denotes that it's Haskell code built to work with GHC.)

Given this, is there any reason to put the new ghc-platform package
through the normal package review process, or would there be some way
to fast-track it?



From kevin.kofler at chello.at  Mon Oct 13 01:40:54 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 01:40:54 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
Message-ID: <loom.20081013T013947-433@post.gmane.org>

Jeff Spaleta <jspaleta <at> gmail.com> writes:
> Okay...if you start with enough maintainers... how do you plan to
> verify that you continue to have enough maintainers to hold a branch
> open?  Without a firm timeline on when to close a branch.. will we
> ever see a branch close?

Why would we want to? Just let things going as long as there is at least one 
maintainer committing something. Even if not all security issues get fixed, 
it's better than if none gets fixed.

       Kevin Kofler



From lists at ralii.com  Mon Oct 13 01:59:33 2008
From: lists at ralii.com (Robert Locke)
Date: Sun, 12 Oct 2008 21:59:33 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810130053.m9D0rOcw014248@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>
	<4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>
	<1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>
	<200810130053.m9D0rOcw014248@laptop14.inf.utfsm.cl>
Message-ID: <1223863173.4250.26.camel@rlt60f8.laptop.redhat.com>


On Sun, 2008-10-12 at 21:53 -0300, Horst H. von Brand wrote:
> Robert Locke <lists at ralii.com> wrote:
> 
> [...]
> 
> > What I think is lacking (but seem to be being worked on), is a
> > convenient "upgrade" process within the "family".  So that if I use
> > Fedora 9 or 10, that I could "in-place" upgrade to RHEL/CentOS 6 when it
> > comes out.
> 
> By the time RHEL/CentOS comes out, the Fedora from which it branched has
> long moved past it...

Really?  You saying that Fedora 7 came out before RHEL5?  Looking at the
calendar, it's a pretty simple Fedora Core 6, RHEL/CentOS 5, Fedora 7.
I don't see that "long moved past", unless you like to run Rawhide, at
which point, why are we talking about a stable LTS?

>  
> > Historically, using RHEL/CentOS for desktop has been problematic for
> > some given their "stability" and "lack of movement".
> 
> For many desktop uses the latest bling is definitely not a requirement,
> more the contrary.  Sure, on notebooks stuff like WiFi is required (and
> needs a newer kernel, etc). Perhaps a line with the required packages
> (paralell to EPEL) would be doable?

Pick a side please.  If the latest bling is not a requirement, then
explain why CentOS is insufficient in providing the "long term
solution"?

I'm still not seeing the "need" for an LTS Fedora....

--Rob




From cra at WPI.EDU  Mon Oct 13 02:10:46 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 12 Oct 2008 22:10:46 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
Message-ID: <20081013021046.GA29893@angus.ind.WPI.EDU>

On Sun, Oct 12, 2008 at 05:02:30PM -0800, Jeff Spaleta wrote:
> Honestly after several days of discussion this week are the proponents
> any further along than what was proposed in the UAEL draft? I haven't
> seen a single new idea.  

Like my ideas above about having a 6 month timeframe for UAEL?

> Until someone new, who is committed to moving an implementation 
> forward steps forward, this discussion is moot. Would WPI give you 
> some infrastructure resources to burn on this to supplement existing 
> project infrastructure to demonstrate that it was a sustainable 
> effort?

Sure, what is needed?  Nothing that isn't already provided by Fedora 
Infrastructure as far as I can see.



From a.badger at gmail.com  Mon Oct 13 02:10:49 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 12 Oct 2008 19:10:49 -0700
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223858576.8635.8.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>	<200810112031.47265.opensource@till.name>	<1223752713.13589.330.camel@hinge.endoframe.net>	<200810111543.21186.sgrubb@redhat.com>	<1223772015.13589.354.camel@hinge.endoframe.net>	<loom.20081012T011207-253@post.gmane.org>	<1223775310.13589.392.camel@hinge.endoframe.net>	<loom.20081012T021105-415@post.gmane.org>	<1223786046.13589.436.camel@hinge.endoframe.net>	<1223800236.9402.13.camel@arekh.okg>	<1223803167.13589.457.camel@hinge.endoframe.net>	<loom.20081012T175955-65@post.gmane.org>
	<1223858576.8635.8.camel@hinge.endoframe.net>
Message-ID: <48F2AE29.1070909@gmail.com>

Braden McDaniel wrote:
> On Sun, 2008-10-12 at 18:08 +0000, Kevin Kofler wrote: 

>>> If a packager wants to include changes to the build script sources in
>>> the source RPM, I have absolutely no objection to that.  But applying
>>> those changes as part of the build wins nothing and invites breakage.
>> Why should we jump through hoops to patch generated files and regularly update 
>> the patches because they'll invariably break if we can just run autoreconf? It 
>> is our (the individual package maintainers') problem to fix things if an 
>> autotools update breaks them anyway!
> 
> Because it affects more than just you.  We won't have libtool2 in Fedora
> 10 because people do what you're advocating.  That means there are
> upstream developers who will be waiting that much longer for it and not
> taking care of problems upstream on their own.
> 
Uhm... no.  We won't have libtool-2.2 in Fedora 10 because it's a big
change and it's past beta.

If Fedora is to be relevant to developers as well as users we need to be
conscious of the fact that even developer tools shouldn't change in a
major, backwards incompatible way at the end of a release.

-Toshio

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

From martin.langhoff at gmail.com  Mon Oct 13 02:12:44 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 13 Oct 2008 15:12:44 +1300
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T013947-433@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
Message-ID: <46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>

On Mon, Oct 13, 2008 at 2:40 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> open?  Without a firm timeline on when to close a branch.. will we
>> ever see a branch close?
>
> Why would we want to? Just let things going as long as there is at least one
> maintainer committing something. Even if not all security issues get fixed,
> it's better than if none gets fixed.

I don't think anyone would sign up as a user for such "support". LTS
is about a fairly specific promise that is very hard to commit to.

The work I am doing would definitely benefit from having some Fedora
releases turn into LTS, even if it's perhaps for clearly defined a
subset of packages. What Ubuntu does with it's LTS is hard for the
distro team but is excellent for "users" (re-spinners) like OLPC.

At the moment, it's not clear to me (perhaps because I haven't read
the appropriate doco...)

 - Which Fedora release becomes the base for the next RH/CentOS release.
 - How I transition my userbase from Fedora support to CentOS support at EOL

So I think it is a fair expectation to be able to "follow" a Fedora
release into its RH/CentOS stabilisation, knowing that the process
exists and that the stable branches are published. It definitely works
for other distros. Perhaps it's possible with Fedora -- hints and
pointers welcome.

But I would not sign up for the "whatever" support plan some people
are suggesting -- how the hell do I plan for it? Ah, some things might
get patched, some might not, and we won't know or tell in advance.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From pemboa at gmail.com  Mon Oct 13 02:12:44 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sun, 12 Oct 2008 21:12:44 -0500
Subject: F10 - X Server GUI Critical Problem!
In-Reply-To: <93d66b780810121839tc564de7s58e37947b806ed84@mail.gmail.com>
References: <93d66b780810121839tc564de7s58e37947b806ed84@mail.gmail.com>
Message-ID: <16de708d0810121912y69c2ce9cgb3c835b49da8a308@mail.gmail.com>

On Sun, Oct 12, 2008 at 8:39 PM, Mario Chacon <the.masch at gmail.com> wrote:
> HI!
> I have nVidia Corporation G71 [GeForce 7950 GT] and random times i
> lost X Server GUI, i have no Video and no keyword. All other program
> running in the machine works great, http server, SSH server, etc.
>
> Can i do something to fix it?... 4 or 5 days ago i did not have this problem.
>
> Salu2...


I think you want fedora-list at redhat.com


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From cra at WPI.EDU  Mon Oct 13 02:14:20 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sun, 12 Oct 2008 22:14:20 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <48F2A2C8.2020306@rincon.com>
References: <20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
Message-ID: <20081013021420.GB29893@angus.ind.WPI.EDU>

On Sun, Oct 12, 2008 at 06:22:16PM -0700, Bob Arendt wrote:
> I really don't see how a Fedora Legacy can be maintained.  If the 
> goal is increased stability and security patches, you need to 
> guarantee that you have folks supporting backpatches to the kernel, 
> glibc, firefox, evolution, openoffice, and several other large and 
> complex packages.  Incorporating new security patches into old 
> baselines is *hard*. Plus Fedora would "fork" a new release every 6 
> months.  How many legacy Fedora's would be retained?  At some point 
> it seems the legacy volunteer force would saturate and legacy 
> Fedora's would have to start dropping off every 6 months.

Why do we need to guarantee any more than active Fedora releases 
guarantee?  Forget backporting.  Just upgrade the package.  Take it 
from the current Fedora and rebuild it if necessary.

I've already said my piece on the timeline.  6-7 months to start out.  
If that works, we can talk about extending it.



From vonbrand at inf.utfsm.cl  Mon Oct 13 02:19:35 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 23:19:35 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F24389.1030906@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<80d7e4090810120830qbdc951dp3bf1ccdddc190ff9@mail.gmail.com>
	<48F24389.1030906@gmail.com>
Message-ID: <200810130219.m9D2JZgV014500@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> Even so, some people claim to have done successful upgrades from
> fedora to the corresponding EL/Centos with just a few quirks that
> probably could have been avoided with a little central planning.  That
> is, even if it is impossible to coordinate the changes that lead to
> RHEL/Centos, there should be a way to have the final fedora update do
> a clean conversion - or at least better than most users could do on
> their own.

Why on earth would anybody start out on Fedora, and then move over to
RHEL/CentOS when it nears EOL? Better start off on RHEL/CentOS...
-- 
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 2340000       Fax:  +56 32 2797513



From dcbw at redhat.com  Mon Oct 13 02:20:50 2008
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 12 Oct 2008 22:20:50 -0400
Subject: NetworkManager-pptp
In-Reply-To: <48BF01EC.5000107@hi.is>
References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com>
	<1220364295.3176.19.camel@borkbork.foobar.com>
	<9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com>
	<1220369215.8041.15.camel@borkbork.foobar.com>
	<9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com>
	<1220473096.28633.5.camel@borkbork.foobar.com> <48BF01EC.5000107@hi.is>
Message-ID: <1223864450.11068.18.camel@localhost.localdomain>

On Wed, 2008-09-03 at 21:30 +0000, "J?hann B. Gu?mundsson" wrote:
> I get authenticated and an IP address but no route/gateway seems to be set
> hence my connection breaks..

I think I see the problem.  Is 130.208.165.95 the external IP address of
your VPN server?

Dan




From vonbrand at inf.utfsm.cl  Mon Oct 13 02:25:11 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 12 Oct 2008 23:25:11 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F23CDF.1090304@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<48F23CDF.1090304@gmail.com>
Message-ID: <200810130225.m9D2PBvU014524@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> First you have to give someone a reason to want to migrate to
> Fedora. With a planned progression to an enterprise version, that
> would not really be a migration away from fedora but the expected end
> point where you are permitted to continue using anything you've
> contributed or developed for your own use, staying in the same
> community instead of having all previous work dumped out the window at
> the end of a cycle. I'll point out again that this is the way Red Hat
> developed its popularity, although it was probably a mistake to have
> tried to support every release forever.

Fedora is _not_ enterprise, it is _not_ in its goals, it is _not_ it's
target audience. Why would anybody start on Fedora planning to "graduate"
to EL?
-- 
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 2340000       Fax:  +56 32 2797513



From lesmikesell at gmail.com  Mon Oct 13 02:28:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 21:28:02 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810130219.m9D2JZgV014500@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<80d7e4090810120830qbdc951dp3bf1ccdddc190ff9@mail.gmail.com>
	<48F24389.1030906@gmail.com>
	<200810130219.m9D2JZgV014500@laptop14.inf.utfsm.cl>
Message-ID: <48F2B232.1050804@gmail.com>

Horst H. von Brand wrote:
> 
>> Even so, some people claim to have done successful upgrades from
>> fedora to the corresponding EL/Centos with just a few quirks that
>> probably could have been avoided with a little central planning.  That
>> is, even if it is impossible to coordinate the changes that lead to
>> RHEL/Centos, there should be a way to have the final fedora update do
>> a clean conversion - or at least better than most users could do on
>> their own.
> 
> Why on earth would anybody start out on Fedora, and then move over to
> RHEL/CentOS when it nears EOL? Better start off on RHEL/CentOS...

That puts you about a year and a half behind if you wait for the release 
before starting.  Or you are developing to wildly different libraries, 
database versions, etc., etc. if you develop on the current version for 
something you plan to run on the next one.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From lists at ralii.com  Mon Oct 13 02:36:30 2008
From: lists at ralii.com (Robert Locke)
Date: Sun, 12 Oct 2008 22:36:30 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081013021420.GB29893@angus.ind.WPI.EDU>
References: <20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu> <20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
Message-ID: <1223865390.4250.32.camel@rlt60f8.laptop.redhat.com>


On Sun, 2008-10-12 at 22:14 -0400, Chuck Anderson wrote:
> On Sun, Oct 12, 2008 at 06:22:16PM -0700, Bob Arendt wrote:
> > I really don't see how a Fedora Legacy can be maintained.  If the 
> > goal is increased stability and security patches, you need to 
> > guarantee that you have folks supporting backpatches to the kernel, 
> > glibc, firefox, evolution, openoffice, and several other large and 
> > complex packages.  Incorporating new security patches into old 
> > baselines is *hard*. Plus Fedora would "fork" a new release every 6 
> > months.  How many legacy Fedora's would be retained?  At some point 
> > it seems the legacy volunteer force would saturate and legacy 
> > Fedora's would have to start dropping off every 6 months.
> 
> Why do we need to guarantee any more than active Fedora releases 
> guarantee?  Forget backporting.  Just upgrade the package.  Take it 
> from the current Fedora and rebuild it if necessary.

And then have everyone complaining when the "upgrade" to the new version
introduced an incompatibility.  Take a look at the recent complaining as
KDE moved forward.  Why not just upgrade to the next Fedora release
then?  If you want security/stability, it requires backporting....

But, then, I let RHEL/CentOS take care of that for me.... :-)

--Rob



From lesmikesell at gmail.com  Mon Oct 13 02:41:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 21:41:51 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810130225.m9D2PBvU014524@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<48F23CDF.1090304@gmail.com>
	<200810130225.m9D2PBvU014524@laptop14.inf.utfsm.cl>
Message-ID: <48F2B56F.7000508@gmail.com>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
>> First you have to give someone a reason to want to migrate to
>> Fedora. With a planned progression to an enterprise version, that
>> would not really be a migration away from fedora but the expected end
>> point where you are permitted to continue using anything you've
>> contributed or developed for your own use, staying in the same
>> community instead of having all previous work dumped out the window at
>> the end of a cycle. I'll point out again that this is the way Red Hat
>> developed its popularity, although it was probably a mistake to have
>> tried to support every release forever.
> 
> Fedora is _not_ enterprise, it is _not_ in its goals, it is _not_ it's
> target audience. Why would anybody start on Fedora planning to "graduate"
> to EL?

For exactly the same reason that people used to use RH X.0 versions for 
development and testing, planning to  run their programs on X.2 as both 
their local development and the distribution mature.  That's what made 
RH popular.  And there is no equivalent now that Fedora never matures to 
a supported stable version.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From lists at ralii.com  Mon Oct 13 03:00:47 2008
From: lists at ralii.com (Robert Locke)
Date: Sun, 12 Oct 2008 23:00:47 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F2B56F.7000508@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan> <48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan> <48F23CDF.1090304@gmail.com>
	<200810130225.m9D2PBvU014524@laptop14.inf.utfsm.cl>
	<48F2B56F.7000508@gmail.com>
Message-ID: <1223866847.4250.42.camel@rlt60f8.laptop.redhat.com>


On Sun, 2008-10-12 at 21:41 -0500, Les Mikesell wrote:
> Horst H. von Brand wrote:
> > Les Mikesell <lesmikesell at gmail.com> wrote:
> > 
> >> First you have to give someone a reason to want to migrate to
> >> Fedora. With a planned progression to an enterprise version, that
> >> would not really be a migration away from fedora but the expected end
> >> point where you are permitted to continue using anything you've
> >> contributed or developed for your own use, staying in the same
> >> community instead of having all previous work dumped out the window at
> >> the end of a cycle. I'll point out again that this is the way Red Hat
> >> developed its popularity, although it was probably a mistake to have
> >> tried to support every release forever.
> > 
> > Fedora is _not_ enterprise, it is _not_ in its goals, it is _not_ it's
> > target audience. Why would anybody start on Fedora planning to "graduate"
> > to EL?
> 
> For exactly the same reason that people used to use RH X.0 versions for 
> development and testing, planning to  run their programs on X.2 as both 
> their local development and the distribution mature.  That's what made 
> RH popular.  And there is no equivalent now that Fedora never matures to 
> a supported stable version.
> 

So, we are talking about doing development on a platform that evolves
and represents the latest in open source technology?  And we are wanting
to deploy on a production ready/stable release?  Doesn't the current
Fedora for development, and CentOS/RHEL for production not satisfy your
need?

I think the only thing missing from your need is a smooth "in-place"
upgrade capability?

But how often is development done (for a year or so) that then becomes
the actual production system?  Would not the production system be
installed in parallel as you approached the timeframe for deployment?

--Rob




From braden at endoframe.com  Mon Oct 13 03:20:04 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 12 Oct 2008 23:20:04 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <48F2AE29.1070909@gmail.com>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<1223800236.9402.13.camel@arekh.okg>
	<1223803167.13589.457.camel@hinge.endoframe.net>
	<loom.20081012T175955-65@post.gmane.org>
	<1223858576.8635.8.camel@hinge.endoframe.net>
	<48F2AE29.1070909@gmail.com>
Message-ID: <1223868004.8635.17.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 19:10 -0700, Toshio Kuratomi wrote:
> Braden McDaniel wrote:
> > On Sun, 2008-10-12 at 18:08 +0000, Kevin Kofler wrote: 
> 
> >>> If a packager wants to include changes to the build script sources in
> >>> the source RPM, I have absolutely no objection to that.  But applying
> >>> those changes as part of the build wins nothing and invites breakage.
> >> Why should we jump through hoops to patch generated files and regularly update 
> >> the patches because they'll invariably break if we can just run autoreconf? It 
> >> is our (the individual package maintainers') problem to fix things if an 
> >> autotools update breaks them anyway!
> > 
> > Because it affects more than just you.  We won't have libtool2 in Fedora
> > 10 because people do what you're advocating.  That means there are
> > upstream developers who will be waiting that much longer for it and not
> > taking care of problems upstream on their own.
> > 
> Uhm... no.  We won't have libtool-2.2 in Fedora 10 because it's a big
> change and it's past beta.

Well, yeah, *now*.  libtool 2.2 is not particularly new.  This one's
been hanging out there for some time.

Had this been the low-collateral-damage sort of upgrade that it ought to
have been, it seems pretty likely that it would have gone in.  That, at
least, is what the comments in bug 435737 lead me to believe.

> If Fedora is to be relevant to developers as well as users we need to be
> conscious of the fact that even developer tools shouldn't change in a
> major, backwards incompatible way at the end of a release.

I'm not suggesting otherwise.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From vonbrand at inf.utfsm.cl  Mon Oct 13 03:27:32 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 13 Oct 2008 00:27:32 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F28EC1.107@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<loom.20081010T160239-992@post.gmane.org>
	<48EF819B.8010607@gmail.com>
	<200810122241.m9CMf0kC007164@laptop14.inf.utfsm.cl>
	<48F28EC1.107@gmail.com>
Message-ID: <200810130327.m9D3RWbP016074@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:
> Horst H. von Brand wrote:
> > Les Mikesell <lesmikesell at gmail.com> wrote:
> > [...]
> >
> >> Fedora could make it's next release somewhere around the point where
> >> the paths start to diverge so people who wanted the fast-track
> >> unstable flavor could re-install as they apparently love to do, and
> >> the rest of us could just drift into stability.
> > Why would any Fedoran want to "drift into stability"? That is a
> > contradiction in terms... If it was /so/ badly wanted as you claim, Fedora
> > Legacy would be alive and well, don't you think?

> No, Fedora, legacy or not, is not good at maintaining stability. I'm
> not surprised it didn't work and wouldn't expect it to work if
> revived.

My impression too, but experimental data trumps that.

>          What people actually do is run RHEL or Centos for their
> actual work.

Depends on what "actual work" means...

>              Which leaves the question of how to get from one to the
> other as you develop something new, then want to run it.

Move the SRPM over, rebuild on the target? Have done so several times, with
minimal fuss. Also moved SRPMs to Aurora (on SPARC64, Fedora-based), and
even ported SRPMs for stuff I couldn't find on Fedora from a variety of
other distributions. I also maintained locally old packages for stuff where
the newer one didn't work.

I'd expect anybody who used Red Hat/CentOS/Fedora for any length of time
have done so too...
-- 
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 2340000       Fax:  +56 32 2797513



From vonbrand at inf.utfsm.cl  Mon Oct 13 03:38:24 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 13 Oct 2008 00:38:24 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <20081013021420.GB29893@angus.ind.WPI.EDU>
References: <20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
Message-ID: <200810130338.m9D3cOcq016121@laptop14.inf.utfsm.cl>

Chuck Anderson <cra at WPI.EDU> wrote:

[...]

> Why do we need to guarantee any more than active Fedora releases 
> guarantee?  Forget backporting.  Just upgrade the package.  Take it 
> from the current Fedora and rebuild it if necessary.

What is the difference from regular Fedora then, if you propose just
dumping new packages into the "stable" release?

> I've already said my piece on the timeline.  6-7 months to start out.  
> If that works, we can talk about extending it.

Nope. If anything, pick a Fedora release and propose to extend its life for
a year (less makes very little sense). Then move to the one EOL at that
point, etc.
-- 
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 2340000       Fax:  +56 32 2797513



From lesmikesell at gmail.com  Mon Oct 13 03:57:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 12 Oct 2008 22:57:36 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810130327.m9D3RWbP016074@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>	<20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com>	<loom.20081010T160239-992@post.gmane.org>	<48EF819B.8010607@gmail.com>	<200810122241.m9CMf0kC007164@laptop14.inf.utfsm.cl>	<48F28EC1.107@gmail.com>
	<200810130327.m9D3RWbP016074@laptop14.inf.utfsm.cl>
Message-ID: <48F2C730.8070204@gmail.com>

Horst H. von Brand wrote:
>
>> No, Fedora, legacy or not, is not good at maintaining stability. I'm
>> not surprised it didn't work and wouldn't expect it to work if
>> revived.
> 
> My impression too, but experimental data trumps that.

Do you have numbers for the bugs shipped in Fedora?  Even the ones fixed 
in subsequent updates?  I've had too many update kernels that wouldn't 
boot on hardware where the previous one ran fine.

>>          What people actually do is run RHEL or Centos for their
>> actual work.
> 
> Depends on what "actual work" means...

My experience is with things like http://www.quote.com or 
http://www.futuresource.com and their backend systems handling financial 
data, but I mean anything that is expected to be up 24x7 for years.

>>              Which leaves the question of how to get from one to the
>> other as you develop something new, then want to run it.
> 
> Move the SRPM over, rebuild on the target? Have done so several times, with
> minimal fuss. Also moved SRPMs to Aurora (on SPARC64, Fedora-based), and
> even ported SRPMs for stuff I couldn't find on Fedora from a variety of
> other distributions. I also maintained locally old packages for stuff where
> the newer one didn't work.
> 
> I'd expect anybody who used Red Hat/CentOS/Fedora for any length of time
> have done so too...

Yes, that sometimes works, but if it is as easy as you say, why not just 
do that with _everything_ on Fedora as its last update when the 
corresponding enterprise version has been released?

-- 
   Les Mikesell
    lesmikesell at gmail.com






From luya_tfz at thefinalzone.com  Mon Oct 13 04:00:48 2008
From: luya_tfz at thefinalzone.com (Luya Tshimbalanga)
Date: Mon, 13 Oct 2008 00:00:48 -0400
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <alpine.LRH.2.00.0810121651510.6827@redclaw.mimosa.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<alpine.LRH.2.00.0810121651510.6827@redclaw.mimosa.com>
Message-ID: <1223870448.48f2c7f04bffe@ssl.mecca.ca>

Quoting "D. Hugh Redelmeier" <hugh at mimosa.com>:

> | From: Les Mikesell <lesmikesell at gmail.com>
>
> | But the first question should be why a separate community is necessary.
> Why
> | is it not possible for one of fedora's goals to be to provide a clean
> | transition to RHEL or Centos at the end of certain development cycles
>
> I think that this idea has some merit.  I'm taking this out of context
> to use as a jump-off point.
>
> [I'm a long-term Red Hat and Fedora user.  I also use Ubuntu
> sometimes.]
>
> Ubuntu 8.04 LTS has seduced me with its simultaneous promises of being
> maintained and having a current code base.
>
> RHEL/CentOS feels too old.  Concrete issues:
>
> - support for video cards
>
> - PostgreSQL 8.3 vs 8.1


Obvious reasons, RHEL/CentOS are enterprise distributions where support for old
applications and old hardware are important. Trying to install a brand new
system without testing stability, perfornamce before applying to enterprise
fields is plain silly. Wikipedia is a non-profit organization, not an
enterprise.

> Ubuntu 8.04 will be quite stale before the next LTS comes out.
> Probably more stale that RHEL/CentOS.  It is all a matter of where
> each stream is in the cycle.  Right now, Ubuntu LTS is ahead of
> RHEL/CentOS.
>
> Ubuntu LTS is in the same series as regular Ubuntu.  RHEL/CentOS are
> not the same as Fedora.  One could predict that the transition costs
> between Ubuntus are lower that the transition costs from RHEL/CentOS
> to or from Fedora.  This is a disadvantage.

 It is very easy to be attracted by low cost transition without considering for
a long term approach. Remember Oracle promised the same thing with their
Unbreakable distribition. In this case, it is about Canonical that are looking
to make money because they are not even profitable since their inception. Time
will tell how successful Canonical strategy will be.

> I find the various Fedora-targeted 3rd party repositories confusing
> and even conflicting.  This isn't healthy.  I've not had this problem
> with Ubuntu but I'm not sure why.

Blame the software patents system. Fedora being an USA distribution cannot
afford for being a big target for patent vultures and, because of this FOSS
philosophy, does not include any closed and patented applications (apart
Firmware which are separate problems). Ubuntu chose to made compromise being a
non-USA distribution but has to follow US Patent law. It will be foolish to not
consider those legal issues especially for company like Canonical and Red Hat.

>
> I like that fedora is willing to take radical steps.  This is the only
> way to do some important experiments.
>
>
> Some changes make me (a conservative at heart) uncomfortable:
>
> - the idea that network connectivity is part of a session just seems
>   bizarre to me.  Network Manager may be useful but I think that this
>   aspect does not fit in with my UNIX world-view.

That is the problem: your UNIX world-view.

> - the idea that non-X consoles will go bothers me.  Just a few minutes
>   ago, I used a non-X console to whack on an X problem.  I hit a lot
>   of X problems due to the way hardware gets introduced more quickly
>   than X versions are released (and debugged).  I may stop using
>   Fedora when this change comes to pass.

What about other methods that may replace the old one?


> - Documentation that I expect is not provided.

Which one?

> - the anatomy of the system changes more quickly than my
>   understanding.  HAL/d-bus/etc. all seem like magic to me.

Perhaps a difficulty to adapt.


-- 
Luya Tshimbalanga
Fedora Project contributor
http://www.fedoraproject.org/wiki/LuyaTshimbalanga



From braden at endoframe.com  Mon Oct 13 04:24:22 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Mon, 13 Oct 2008 00:24:22 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081013T013446-292@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<1223800236.9402.13.camel@arekh.okg>
	<1223803167.13589.457.camel@hinge.endoframe.net>
	<loom.20081012T175955-65@post.gmane.org>
	<1223858576.8635.8.camel@hinge.endoframe.net>
	<loom.20081013T013446-292@post.gmane.org>
Message-ID: <1223871862.8635.31.camel@hinge.endoframe.net>

On Mon, 2008-10-13 at 01:37 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > You are welcome to find a more specific term for what you mean. "Source"
> > has a more general meaning than the one you're trying to apply.
> 
> I'm using the definition in the GPL:
> > The ?source code? for a work means the preferred form of the work for making
> > modifications to it.
> 
> Obviously autogenerated files are not "source code" under that definition. You 
> are the one using the wrong term.

The term in question is "source", not "source code".  

(And furthermore, the GPL, as is common for a legal document, defines
several key terms that do not have a consistent, generally accepted
meaning.  The definitions have authority only within the scope of the
document.  Seeing such a definition is a pretty good indication that
either the term does not have a broadly accepted definition or the
document is relying some particular subtlety of that meaning.)

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From otto_rey at yahoo.com.ar  Mon Oct 13 04:39:44 2008
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Sun, 12 Oct 2008 21:39:44 -0700 (PDT)
Subject: Siempre lo mismo con ustedes...
Message-ID: <91914.61356.qm@web52408.mail.re2.yahoo.com>

Siempre lo mismo con ustedes viejo....

Le dicen a la gente que reporten bugs y pueden pasar meses sin que tengan movimiento hasta que son cerrados por obsoletos. Uno se mete a hacer aportes en la lista de desarrollo sobre la versi?n que est? por salir, en este caso Fedora 10, aportando comentarios y experiencias sobre rawhide y no le dan importancia para nada. Se enroscan en discuciones politicas, y cosas de "gente superada"

Son una manga de inutiles... por eso la gente prefiere Debian o Ubuntu.... ustedes son tan craneos que se olvidan SIEMPRE de la gente, de los usuarios, de los desarrolladores perifericos, de los aportes de la gente, etc, etc, etc.... Siempre ustedes, la politica, y sus discuciones de cerebritos

Yo convenc? a 15 personas que se pasen de Windows a Fedora.... de hecho les hice soporte sin hacer lucro de eso, porque conozco bien a fedora (lo vengo configurando, administrando y usando desde Fedora Core 3), las herramientas de administracion, los "trucos", configuraciones, etc, etc... Pero bueno, ahora estoy cambiando de opinion y me parece que voy a evaluar Debian o Ubuntu, que parece algo un poco m?s serio que esta mentira de Fedora... es m?s, a la gente que la llev? hacia Fedora la voy a llevar a Ubuntu.

Desde Fedora Core 3 que vengo usando y aportando en Fedora.... pero bueno, ahora estan en estrellas y parece que se olvidan de la gente que los banc? y defendi? siempre... que foment? Fedora en todos lados, trabajo, hogar, etc....

Gracias y si alguno le interesa, que le pida a la c0ncha de su hermana que les traduzca el email...



      Yahoo! Cocina
Recetas pr?cticas y comida saludable
http://ar.mujer.yahoo.com/cocina/



From braden at endoframe.com  Mon Oct 13 04:41:43 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Mon, 13 Oct 2008 00:41:43 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081012T175241-931@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<loom.20081012T175241-931@post.gmane.org>
Message-ID: <1223872903.8635.46.camel@hinge.endoframe.net>

On Sun, 2008-10-12 at 17:59 +0000, Kevin Kofler wrote:

[snip]

> What you're missing is that Fedora _already_ has guidelines requiring to build 
> everything from source (which are enforced for Java and Mono stuff, for 
> example),

What you mean is that there are guidelines applicable to Java and Mono,
right?  If you're really saying that there's a guideline that applies
more generally, link please.

>  it's just that the autotools files are still considered "source",

That's right.  They *are* considered that.  So, again, if you want to
change that, you should propose an appropriate guideline.
 
> which they really aren't.

Maybe.  But they aren't delivered with the binary RPM; so how this
matters (or is the least bit similar to the Java/Mono situation) is not
clear.

Do you also want to use doxygen to regenerate API documentation included
in a tarball, despite the fact that a different doxygen version's subtle
stylesheet and markup changes could totally mangle the docs? How are you
going to catch *that* breakage?

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From martin.langhoff at gmail.com  Mon Oct 13 05:09:46 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 13 Oct 2008 18:09:46 +1300
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <91914.61356.qm@web52408.mail.re2.yahoo.com>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
Message-ID: <46a038f90810122209v2346a8c1pf9f47f22980431bf@mail.gmail.com>

2008/10/13 Otto Rey <otto_rey at yahoo.com.ar>:
> Siempre lo mismo con ustedes viejo....

Un equipo enorme de gente de un calibre profesional altisimo trabaja
dias larguisimos para hacer Fedora. Y sin pedirte un centavo no atarte
con nada. Si preferis otra distro, con tranquilidad y respeto podes
cambiar de distro. Sos libre.

Pero vas a ver que Debian y Ubuntu tienen reglas similares sobre el
'freeze'.  Es parte de como operan las distros y tiene buenas razones
de ser asi.




martin
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From hugh at mimosa.com  Mon Oct 13 05:26:20 2008
From: hugh at mimosa.com (D. Hugh Redelmeier)
Date: Mon, 13 Oct 2008 01:26:20 -0400 (EDT)
Subject: Status of libtool 2.2.X?
In-Reply-To: <1223748879.13589.319.camel@hinge.endoframe.net>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
	<91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>
	<1223745999.13589.297.camel@hinge.endoframe.net>
	<91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>
	<1223748879.13589.319.camel@hinge.endoframe.net>
Message-ID: <alpine.LRH.2.00.0810130118511.6827@redclaw.mimosa.com>

| From: Braden McDaniel <braden at endoframe.com>

| Yes, but the kind of patches that should be sent upstream are not the
| ones resulting in 300 busted packages from a libtool upgrade.  We're
| talking about patches applied by a specfile build.

Could you characterize the problems that cause 300 busted packages?

Naive questions:

- Might a reasonable patch to libtool 2.2 fix a lot of these problems?
  (And no, I don't mean "patch it back to 2.1.")

- Would it make sense to allow multiple versions of libtools co-exist
  on a system and allow a .spec declaration of some kind specify which
  to use?



From rc040203 at freenet.de  Mon Oct 13 05:27:46 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 07:27:46 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
Message-ID: <1223875666.3564.1441.camel@beck.corsepiu.local>

On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> > > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> > > >> Dmitry Butskoy wrote:
> > > >> > Itamar - IspBrasil wrote:
> > > [snip]
> > > >> The fact that they switched to CentOS is *good* for Fedora.
> > > > I can not disagree more - To me, it's yet another evidence of Fedora
> > > > being on the loose.
> > > 
> > > You're going to have to expound on that. I do not see Centos in any
> > > way as in competition with Fedora.
> 
> > EPEL drains away resources from Fedora.
> 
> Proof?

Urgh, isn't that obvious?

E.g.:
- Build server resources, mirror resources.
- People are using/testing EPEL instead of Fedora.
- Fedora infrastructure, e.g. EPEL enlarges the packagedb by almost
factor 2.
- EPEL would force Fedora contributors to test on both RHEL and Fedora.

> > >  Centos is something everyone should
> > > be proud of.
> 
> > Well, to me CentOS is as important as any other arbitrary Linux distro.
> > I am glad they are around, but not more and not less.
> 
> It is around becase RHEL is popular, and open source.
And non-free - If it was free, the CentOS folks could start directly
contribute to Fedora or RHEL. Right now, it's them wasting time to
workaround on RHEL being non-free.

> > > >>  CentOS's
> > > >> goals are better oriented to the needs of someone that wants to deploy a
> > > >> system and run it for years.  Fedora is good for people who want to get
> > > >> the latest technologies from upstream as soon as they're stable enough
> > > >> to integrate into a running system.
> 
> > > > Right. But why can't Fedora do better? I feel Fedora could do better.
> 
> > > Sure. With more devs, servers, time, etc.
> 
> > ... less bureaucracy, less committees/less chiefs/more Indians,
> > different people, different strategies.
> 
> Show how!

Ease reviews, bodhi, packagedb, koji, bugzilla, track, re-consider FTBS,
work-flow, trademark policy. 

E.g. right now, the tools being in use are a heterogenious mixture of
separate tools, are often broken, are far from easy to use and aim at
implementing a highly bureaucratic process/work-flow.

>  Telling everybody here how awful things are going isn't helping
> an iota. Everything has its limits, and for every desirable quality (newest
> shiny toys, support for the newest fad in hardware in software) there is a
> cost (can't be supported in the long range, fast turnaround, set procedures
> to handle a huge stream of new stuff)
> 
> > >  But baring a sudden increase
> > > in those, I would much prefer to see Fedora focus on dev and testing,
> > > let other distros pretty things up.
> 
> > ACK. Unfortunately, Fedora is drifting away from this group towards
> > single-user desktops (e.g. OLPC).
> 
> Then work towards drifting the opposite direction...
One reason why I am agitating ...

> Fedora (or any other large group of people) will move where the majority
> wants to go... 
Well, deployment of an OS to servers, will always be a "minority use
case" and will always collide somewhere with mere desktop oriented
developments.

> > > >> > This situation seems to be reflected in the Fedora project itself.
> > > >> > Guess, how many Fedora infrastructure servers are run under the latest
> > > >> > "stable" Fedora release?
> 
> > > >> As few as possible.
> 
> > > > IMO, a fundamental management/infrastructure mistake - If these people
> > > > were using Fedora, they would be facing the issues Fedora users are
> > > > facing everyday and likely would being to understand why people complain
> > > > about Fedora.
> 
> > > Why would they, after often suggesting that Fedora _not_ be used on
> > > production servers, use Fedora on their production servers?
> 
> > Depends on how they mean it:
> > - if they are referring to "long term maintained/everlasting support"
> > servers, they are right.
> 
> "Servers" are "long-time maintained" by definition...
To me, "server" is a "use-case of an OS" and is not at all connected to
running the same OS for many years. 

Yes, no doubt, running the same OS on a larger number of machines for a
longer time helps maintenance, but I do not see how this is connected to
a particular machine serving as "clients" or "servers".

Yes, no doubt, there are use-cases where "long-term API" stability is
important, but this applies to client use-cases as well as to server
use-cases.

...

Finally, yes, no doubt, Fedora is not the "shoe that fits all sizes" nor
are CentOS or RHEL, but ... this doesn't mean that Fedora may not be
applicable to server scenarios.

> > - if they mean it as "Fedora is technically too unstable",
> 
> Because there is no "long term maintenance"...
Again, I don't see how "lack of stability" and "no long term
maintenance" are linked together at all, nor how server and client
use-cases matter.

What matters in use-cases of short lived-distros such as Fedora is:
Upgrades "must simply work" and (admin-) personnel must be able to
handle them in a particular scenario.

> >                                                            then this
> > people should start working on improving the situation
> 
> Which one?
Lack of stability, lack of usability, deficiencies of the
infrastructure, bureaucracy, short-livedness ... tools

The lack of people to me is not a cause, it's a consequence of mistakes
in Fedora's history.

>  Fedora is about /not/ "long term" but "bleeding edge"...
"Leading edge" doesn't necessarily have to be linked to "bleeding" nor
"unstable". It's sad, the latter is true wrt. Fedora.

> >                                                        or (better) quit
> > Fedora.
> 
> Do so, then.
I haven't given in, yet. 

The cause for my current dissatisfaction is Fedora's infrastructure and
Fedora's leadership. They have driven Fedora/have allowed Fedora to move
into what I consider to be an unhealthy direction.




From rodrigopadula at projetofedora.org  Mon Oct 13 05:53:09 2008
From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira)
Date: Mon, 13 Oct 2008 02:53:09 -0300
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <91914.61356.qm@web52408.mail.re2.yahoo.com>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
Message-ID: <48F2E245.7090504@projetofedora.org>

Otto Rey escreveu:
> Siempre lo mismo con ustedes viejo....
> 
> Le dicen a la gente que reporten bugs y pueden pasar meses sin que tengan movimiento hasta que son cerrados por obsoletos. Uno se mete a hacer aportes en la lista de desarrollo sobre la versi?n que est? por salir, en este caso Fedora 10, aportando comentarios y experiencias sobre rawhide y no le dan importancia para nada. Se enroscan en discuciones politicas, y cosas de "gente superada"
> 
> Son una manga de inutiles... por eso la gente prefiere Debian o Ubuntu.... ustedes son tan craneos que se olvidan SIEMPRE de la gente, de los usuarios, de los desarrolladores perifericos, de los aportes de la gente, etc, etc, etc.... Siempre ustedes, la politica, y sus discuciones de cerebritos
> 
> Yo convenc? a 15 personas que se pasen de Windows a Fedora.... de hecho les hice soporte sin hacer lucro de eso, porque conozco bien a fedora (lo vengo configurando, administrando y usando desde Fedora Core 3), las herramientas de administracion, los "trucos", configuraciones, etc, etc... Pero bueno, ahora estoy cambiando de opinion y me parece que voy a evaluar Debian o Ubuntu, que parece algo un poco m?s serio que esta mentira de Fedora... es m?s, a la gente que la llev? hacia Fedora la voy a llevar a Ubuntu.
> 
> Desde Fedora Core 3 que vengo usando y aportando en Fedora.... pero bueno, ahora estan en estrellas y parece que se olvidan de la gente que los banc? y defendi? siempre... que foment? Fedora en todos lados, trabajo, hogar, etc....
> 
> Gracias y si alguno le interesa, que le pida a la c0ncha de su hermana que les traduzca el email...
> 
> 
> 
>       Yahoo! Cocina
> Recetas pr?cticas y comida saludable
> http://ar.mujer.yahoo.com/cocina/
> 

Yo creo que usted deva escribir con un poquito m?s de educacion!

I think you need to Be a little more polite with your words!

-- 

Rodrigo Padula de Oliveira
M.Sc. Student - COPPE/UFRJ
Fedora Community Manager - Latin America
http://www.proyectofedora.org





From rc040203 at freenet.de  Mon Oct 13 05:57:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 07:57:09 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<1223704398.3564.1316.camel@beck.corsepiu.local>
	<364d303b0810110228v2a6361aat34e943db895b0cb5@mail.gmail.com>
Message-ID: <1223877429.3564.1458.camel@beck.corsepiu.local>

On Sat, 2008-10-11 at 10:28 +0100, Christopher Brown wrote:
> 2008/10/11 Ralf Corsepius <rc040203 at freenet.de>:
> > On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:
> >> On Fri, Oct 10, 2008 at 4:23 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >> > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> >> >> On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >> >> > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> >> >> >> Dmitry Butskoy wrote:
> >> >> >> > Itamar - IspBrasil wrote:
> >> >> [snip]
> >> >> >> The fact that they switched to CentOS is *good* for Fedora.
> >> >> > I can not disagree more - To me, it's yet another evidence of Fedora
> >> >> > being on the loose.
> >> >>
> >> >> You're going to have to expound on that. I do not see Centos in any
> >> >> way as in competition with Fedora.
> >> > EPEL drains away resources from Fedora.
> >> >
> >> > If people were investing the time they (as I feel waste) on supporting
> >> > EPEL into Fedora, Fedora would be better.
> >> >
> >>
> >> Ok. Ralf.. if you hate Fedora
> > Absolutely not.
> >
> >> and all its projects so much, why do you
> >> fricking stay around. Every fricking thread its "Fedora has too much
> >> bueracracy. Fedora has a broken build system. EPEL steals resources..
> >> " What are you doing?
> > I am complaining about a _few_ people having run down a once fascinating
> > project, with the very same people closing their eyes in front this, of
> > what I consider to be an inconvenient truth.
> >
> > Wrt. EPEL, I have always had the same opinion on it, since the very
> > beginning.
> >
> >> >> Sure. With more devs, servers, time, etc.
> >> > ... less bureaucracy, less committees/less chiefs/more Indians,
> >> > different people, different strategies.
> >
> >> Then DO SOMETHING.
> > Sigh, I repeatedly have been trying to do something, but always the same
> > "Fedora chiefs" had machine-gunned almost each and every proposal.
> >
> > You know, you have been one of these - Do I really have to be more
> > direct?
> 
> No, you just have to be less of an ass. As a casual observer, all you
> seem to do is throw rocks.
Thanks for throwing rocks at a Fedora contributor who is maintaining
many packages in Fedora, whos had performed and contributed to many
reviews, who is actively involved into the FPC and is contributing to
many upstream projects.







From rc040203 at freenet.de  Mon Oct 13 06:09:45 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 08:09:45 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810111313t3f09d38avff8b11bc743f1a08@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<1223704398.3564.1316.camel@beck.corsepiu.local>
	<80d7e4090810111313t3f09d38avff8b11bc743f1a08@mail.gmail.com>
Message-ID: <1223878185.3564.1472.camel@beck.corsepiu.local>

On Sat, 2008-10-11 at 14:13 -0600, Stephen John Smoogen wrote:
> On Fri, Oct 10, 2008 at 11:53 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Fri, 2008-10-10 at 17:08 -0600, Stephen John Smoogen wrote:

> > You know, you have been one of these - Do I really have to be more
> > direct?
> >
> 
> Actually I think you are too direct. You seem to have been
> disappointed with how Fedora's leadership has gone, and never seem to
> avoid a situation to remind people that. You complain about too much
> bueracracy and lack of democracy, but your alternatives seem to be
> communicated always as "do as a I say"  without compromise.
Absolutely not. 

Compromising would require general agreement on "presence of a problem"
and "willingness to develop solutions". Unfortunately, I don't see them
in Fedora. To the contrary, I observe Fedora people celebrating things I
consider to be regressions/problems as "great achievements and
progress".




From konrad at tylerc.org  Mon Oct 13 06:12:16 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sun, 12 Oct 2008 23:12:16 -0700
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <91914.61356.qm@web52408.mail.re2.yahoo.com>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
Message-ID: <200810122312.16875.konrad@tylerc.org>

On Sunday 12 October 2008 09:39:44 pm Otto Rey wrote:
> Siempre lo mismo con ustedes viejo....
>
> Le dicen a la gente que reporten bugs y pueden pasar meses sin que tengan
> movimiento hasta que son cerrados por obsoletos. Uno se mete a hacer
> aportes en la lista de desarrollo sobre la versi?n que est? por salir, en
> este caso Fedora 10, aportando comentarios y experiencias sobre rawhide y
> no le dan importancia para nada. Se enroscan en discuciones politicas, y
> cosas de "gente superada"
>
> Son una manga de inutiles... por eso la gente prefiere Debian o Ubuntu....
> ustedes son tan craneos que se olvidan SIEMPRE de la gente, de los
> usuarios, de los desarrolladores perifericos, de los aportes de la gente,
> etc, etc, etc.... Siempre ustedes, la politica, y sus discuciones de
> cerebritos
>
> Yo convenc? a 15 personas que se pasen de Windows a Fedora.... de hecho les
> hice soporte sin hacer lucro de eso, porque conozco bien a fedora (lo vengo
> configurando, administrando y usando desde Fedora Core 3), las herramientas
> de administracion, los "trucos", configuraciones, etc, etc... Pero bueno,
> ahora estoy cambiando de opinion y me parece que voy a evaluar Debian o
> Ubuntu, que parece algo un poco m?s serio que esta mentira de Fedora... es
> m?s, a la gente que la llev? hacia Fedora la voy a llevar a Ubuntu.
>
> Desde Fedora Core 3 que vengo usando y aportando en Fedora.... pero bueno,
> ahora estan en estrellas y parece que se olvidan de la gente que los banc?
> y defendi? siempre... que foment? Fedora en todos lados, trabajo, hogar,
> etc....
>
> Gracias y si alguno le interesa, que le pida a la c0ncha de su hermana que
> les traduzca el email...
>
>
>
>       Yahoo! Cocina
> Recetas pr?cticas y comida saludable
> http://ar.mujer.yahoo.com/cocina/

Can any strong speaker of Spanish translate (or just summarize) this mail? (My 
year of high school Spanish isn't helping here.)

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>





From rc040203 at freenet.de  Mon Oct 13 06:16:49 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 08:16:49 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F2A2C8.2020306@rincon.com>
References: <200810111658.49564.opensource@till.name>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu> <20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
Message-ID: <1223878609.3564.1480.camel@beck.corsepiu.local>

On Sun, 2008-10-12 at 18:22 -0700, Bob Arendt wrote:
> Jeff Spaleta wrote:
> > I'm not talking about QA.. I'm talking about verifying that the
> > volunteer maintainers are actually still in place a year+ later.  How
> > do make users aware that packages are unmaintained for 1+ years? Do
> > you plan to expire unmaintained packages so new users don't have
> > access to them?You have to have some process to verify that the
> > maintainers are there because you are explicitly stating that the life
> > of branch depends on an accurate count of the active maintainers. if
> > you don't build a process to try to verify maintainer involvement..the
> > branches could live forever because there is no pre-defined EOL.
> >
> >   
> I really don't see how a Fedora Legacy can be maintained.
Ask yourselves: How can EPEL be maintained?

>   If the goal is increased stability and security patches,
The goal would be "extended life-time" at "no guarantees/use at your own
risk".

>  you need to guarantee that you have 
> folks supporting
> backpatches to the kernel, glibc, firefox, evolution,  openoffice, and 
> several other large
> and complex packages.  Incorporating new security patches into old 
> baselines is *hard*.
Right, ... the consequence would be instability and security risks
gradually creeping in. 

This is bad, nevertheless it still would better than letting people stay
with totally discontinued/unmaintained Fedoras or with driving them away
from Fedora and redirecting them to CentOS or RHEL.

> Plus Fedora would "fork" a new release every 6 months.  How many legacy
> Fedora's would be retained?  At some point it seems the legacy volunteer 
> force
> would saturate and legacy Fedora's would have to start dropping off 
> every 6 months.

Right, ... nevertheless, such an extended life-time would provide people
more time to upgrade to a newer Fedora.

Ralf




From martin.langhoff at gmail.com  Mon Oct 13 06:23:31 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Mon, 13 Oct 2008 19:23:31 +1300
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <200810122312.16875.konrad@tylerc.org>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
	<200810122312.16875.konrad@tylerc.org>
Message-ID: <46a038f90810122323u772dea6fyf97ec7e15639e4c7@mail.gmail.com>

2008/10/13 Conrad Meyer <konrad at tylerc.org>:
> Can any strong speaker of Spanish translate (or just summarize) this mail? (My
> year of high school Spanish isn't helping here.)

not worth it. Just flammage over something he hints at having proposed
for F10 only to be told it's too late. Replied to him in private
(something I generally recommend :-) ) and he actually was quite nice
and even thankful.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From rc040203 at freenet.de  Mon Oct 13 06:24:29 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 08:24:29 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F273D1.6070604@shmuelhome.mine.nu>
References: <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>	<20081012100248.GB3936@free.fr>
	<gcsrr8$9mn$1@ger.gmane.org>	<20081012131811.GA2700@free.fr>
	<gct38m$scd$1@ger.gmane.org>	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
Message-ID: <1223879069.3564.1489.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 00:01 +0200, shmuel siegel wrote:
> Patrice Dumas wrote:
> > On Sun, Oct 12, 2008 at 09:12:05PM +0000, Kevin Kofler wrote:
> >   
> >> Patrice Dumas <pertusus <at> free.fr> writes:
> >>     
> >>> In my response to that mail, failing to have a metric I retired my
> >>> proposal, and nobody supported my views (and overall nobody supported my
> >>> views).
> >>>       
> >> In terms of those metrics, I'm still in favor of a mostly anarchical approach:
> >>     
> >
> > I completly agree. This is simple and leave everything to the packagers
> > initiative, I think that it is also what Ralf had in mind. But some people 
> > insisted on communicating to the public what was maintained, hence my 
> > proposal. But what you propose is better.
> >
> > --
> > Pat
> >
> >   
> Up to here you definitely had my sympathy. But this anarchical approach 
> makes me wonder who your target audience is.
All "users", esp. those who currently stay with discontinued and
unmaintained Fedoras, because
- they are not aware about these Fedora's being dead.
- they can't cope with the "frequent upgrades" or can't afford upgrading
at the point in time a Fedora release is going EOL. discontinued.
- they can't upgrade for technical reasons.

Another aspect would be "keep users with Fedora" and to not force them
to resort to other distros.

Ralf




From braden at endoframe.com  Mon Oct 13 06:48:14 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Mon, 13 Oct 2008 02:48:14 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <alpine.LRH.2.00.0810130118511.6827@redclaw.mimosa.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<91705d080810101402m1ecbfaaj5df4ffbbcc0bc1ac@mail.gmail.com>
	<48EFC71E.5060607@endoframe.com>
	<20081011102129.GE29105@amd.home.annexia.org>
	<91705d080810110817r3fbbbb3gb386c87a7b6ea1f1@mail.gmail.com>
	<1223745999.13589.297.camel@hinge.endoframe.net>
	<91705d080810111044y6f0a3579icccd256132847543@mail.gmail.com>
	<1223748879.13589.319.camel@hinge.endoframe.net>
	<alpine.LRH.2.00.0810130118511.6827@redclaw.mimosa.com>
Message-ID: <1223880494.8635.62.camel@hinge.endoframe.net>

On Mon, 2008-10-13 at 01:26 -0400, D. Hugh Redelmeier wrote:
> | From: Braden McDaniel <braden at endoframe.com>
> 
> | Yes, but the kind of patches that should be sent upstream are not the
> | ones resulting in 300 busted packages from a libtool upgrade.  We're
> | talking about patches applied by a specfile build.
> 
> Could you characterize the problems that cause 300 busted packages?

I couldn't.  I hope Karsten Hopp will (the "300" figure comes from him);
he's said he's preparing a wiki page with this information.  (See
earlier in this thread.)

> Naive questions:
> 
> - Might a reasonable patch to libtool 2.2 fix a lot of these problems?
>   (And no, I don't mean "patch it back to 2.1.")

I don't know.  (And FYI, Fedora never shipped 2.1; I think it wasn't
released.  I think the 2.2 series succeeds the 1.5 one.)

> - Would it make sense to allow multiple versions of libtools co-exist
>   on a system and allow a .spec declaration of some kind specify which
>   to use?

That possibility has been floated; and things might even be leaning that
way.  See bug 459387.

I don't have an objection to that approach as long as "libtoolize" (and
similar) refers to the latest version of the tool--just as "autoconf" or
"automake" refer to the latest versions of those tools.  And as long as
that's the case, specfiles for libtool2-incompatible packages that run
autoreconf or libtoolize will need to make at least minor changes to
request the old version.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From rc040203 at freenet.de  Mon Oct 13 07:12:36 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 09:12:36 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
Message-ID: <1223881956.3564.1502.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 15:12 +1300, Martin Langhoff wrote:
> On Mon, Oct 13, 2008 at 2:40 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> >> open?  Without a firm timeline on when to close a branch.. will we
> >> ever see a branch close?
> >
> > Why would we want to? Just let things going as long as there is at least one
> > maintainer committing something. Even if not all security issues get fixed,
> > it's better than if none gets fixed.
> 
> I don't think anyone would sign up as a user for such "support". LTS
> is about a fairly specific promise that is very hard to commit to.
How so? It would be a legacy effort, run by volunteers, no guarantees,
no commitments.

> The work I am doing would definitely benefit from having some Fedora
> releases turn into LTS, even if it's perhaps for clearly defined a
> subset of packages. What Ubuntu does with it's LTS is hard for the
> distro team but is excellent for "users" (re-spinners) like OLPC.
Yes, but their notion of "LTS" is different from that of the "Legacy
Fedora" we are discussing here.

> At the moment, it's not clear to me (perhaps because I haven't read
> the appropriate doco...)
> 
>  - Which Fedora release becomes the base for the next RH/CentOS release.
Pardon, to me that's a RH internal business, not of any importance to
Fedora.

>  - How I transition my userbase from Fedora support to CentOS support at EOL
This thought is exactly what I am aiming against. I want to people to
stay with Fedora, which would imply them  to upgrade to a newer Fedora,
instead of seeing them switching away from Fedora.

> So I think it is a fair expectation to be able to "follow" a Fedora
> release into its RH/CentOS stabilisation, knowing that the process
> exists and that the stable branches are published. It definitely works
> for other distros. Perhaps it's possible with Fedora -- hints and
> pointers welcome.
> 
> But I would not sign up for the "whatever" support plan some people
> are suggesting -- how the hell do I plan for it? Ah, some things might
> get patched, some might not, and we won't know or tell in advance.
Right, but if you are consequent, you could start with the latest
released CentOS/RHEL right from the beginning instead of Fedora.
Besides the fact that the Fedora->RHEL upgrade path is unsupported (and
will never be complete), you'd loose some "technology preview", however
you would avoid "the Fedora hassle" more or less entirely.

Ralf





From dodji at seketeli.org  Mon Oct 13 07:26:10 2008
From: dodji at seketeli.org (Dodji Seketeli)
Date: Mon, 13 Oct 2008 09:26:10 +0200
Subject: Package review backlog.
In-Reply-To: <48F07615.7060306@hhs.nl>
References: <loom.20081008T092258-152@post.gmane.org>	<loom.20081008T094231-77@post.gmane.org>	<20081008151204.GA5629@nostromo.devel.redhat.com>	<loom.20081008T153926-770@post.gmane.org>	<20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<1223645613.3514.12.camel@wicktop.localdomain>	<1223649007.6770.25.camel@macbook.infradead.org>	<48F01BDF.1000109@redhat.com>
	<48F07615.7060306@hhs.nl>
Message-ID: <48F2F812.50407@seketeli.org>

Hans de Goede a ?crit :

[...]

> I've submitted many, many new packages (100+ I guess) and I've *never* 
> had any problems in getting them reviewed.
> 
> Of those 1200 pachages awaiting review, 100 block FE_NEEDSPONSOR, so 
> 1100 are normal reviews submitted by people which are already 
> contributers!

[...]

> Lets say every contributer has on average 2 packages 
> waiting for review, then 2 have 550 contributers for whom the review 
> queue is a problem, if all of those 550 submitters would review only 2 
> packages, then the entire normal review queue is gone!

Yeah, but what about the 100 people who are not contributors yet, and 
who are willing to get in ? What can be done to speed up the reviews of 
their packages in practice ?



From rc040203 at freenet.de  Mon Oct 13 07:29:13 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 09:29:13 +0200
Subject: Regarding install options
In-Reply-To: <1223855755.3327.12.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
Message-ID: <1223882953.3564.1509.camel@beck.corsepiu.local>

On Sun, 2008-10-12 at 16:55 -0700, Jesse Keating wrote:
> On Sun, 2008-10-12 at 08:09 +0200, Ralf Corsepius wrote:
> > Sure, yum + rpm are a requirement.
> 
> And now you're dragging in python, plus the rest of yum's deps, which
> I've already been told by many other people (at FUDCons, IRC, mail,
> etc..) is not a "minimal" install.
You are nit-picking at words.

Though a Fedora installation with yum + rpm isn't "truely minimal", it's
the minimal install to keep an installation usable/maintainable.

And yes, the fact yum pulls in python is a real problem on small
systems. Even worse are the system-config-* tools, most of which pull in
many more packages and don't even work without X.

>   Congratulations you've just walked
> into a decade + argument.
I don't see this.

Ralf





From the.masch at gmail.com  Mon Oct 13 07:31:19 2008
From: the.masch at gmail.com (Mario Chacon)
Date: Mon, 13 Oct 2008 04:31:19 -0300
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <46a038f90810122323u772dea6fyf97ec7e15639e4c7@mail.gmail.com>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
	<200810122312.16875.konrad@tylerc.org>
	<46a038f90810122323u772dea6fyf97ec7e15639e4c7@mail.gmail.com>
Message-ID: <93d66b780810130031y2510890dr901fd508ceeb2276@mail.gmail.com>

Sorry guys, i'm a very very frustrated person, like it's Otto Rey
almost time when i report some bug or some idea i have no answers. I
know your very busy build in the gauge OS, but some times your forget
the users needed. In fact now i'm using latest F10 and i have some
critical errors and i have no answers, i'm add some ideas and have no
answers.

Anyway thanks for all your wonderful works!...but please do not forget
people who are Users, no only part of the development team....


Salu2....

On Mon, Oct 13, 2008 at 3:23 AM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> 2008/10/13 Conrad Meyer <konrad at tylerc.org>:
>> Can any strong speaker of Spanish translate (or just summarize) this mail? (My
>> year of high school Spanish isn't helping here.)
>
> not worth it. Just flammage over something he hints at having proposed
> for F10 only to be told it's too late. Replied to him in private
> (something I generally recommend :-) ) and he actually was quite nice
> and even thankful.
>
> cheers,
>
>
>
> m
> --
>  martin.langhoff at gmail.com
>  martin at laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From pertusus at free.fr  Mon Oct 13 07:37:47 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 09:37:47 +0200
Subject: Splitting a package apart - normal package review needed?
In-Reply-To: <c290c4f20810121841w6875375bhde0a750800e0e7fc@mail.gmail.com>
References: <c290c4f20810121841w6875375bhde0a750800e0e7fc@mail.gmail.com>
Message-ID: <20081013073747.GB2670@free.fr>

On Sun, Oct 12, 2008 at 06:41:59PM -0700, Bryan O'Sullivan wrote:
> We're pondering splitting the ghc (Glasgow Haskell Compiler) package
> into two: bsae ghc (retaining the ghc name) and ghc-platform (standard
> libraries). The need for this is driven by the fact that ghc and its
> standard libraries are going to be developed separately, and released
> on different cycles. (The "ghc-" prefix for the platform package
> merely denotes that it's Haskell code built to work with GHC.)
> 
> Given this, is there any reason to put the new ghc-platform package
> through the normal package review process, or would there be some way
> to fast-track it?

I think that a new review is required, but I would suggest that you put
in CC the person who approved the ghc package such that this goes fast.

--
Pat



From kevin.kofler at chello.at  Mon Oct 13 07:46:06 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 07:46:06 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>
	<4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>
	<1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>
	<200810130053.m9D0rOcw014248@laptop14.inf.utfsm.cl>
	<1223863173.4250.26.camel@rlt60f8.laptop.redhat.com>
Message-ID: <loom.20081013T074503-537@post.gmane.org>

Robert Locke <lists <at> ralii.com> writes:
> Really?  You saying that Fedora 7 came out before RHEL5?  Looking at the
> calendar, it's a pretty simple Fedora Core 6, RHEL/CentOS 5, Fedora 7.
> I don't see that "long moved past", unless you like to run Rawhide, at
> which point, why are we talking about a stable LTS?

One word: updates!
By the time RHEL 5 came out, even FC5 had a newer kernel (and several other 
packages).

        Kevin Kofler



From dchen at redhat.com  Mon Oct 13 07:53:57 2008
From: dchen at redhat.com (Ding Yi Chen)
Date: Mon, 13 Oct 2008 03:53:57 -0400 (EDT)
Subject: reviving Fedora Legacy
In-Reply-To: <174473882.118211223883915968.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>




----- Original Message -----
From: "Ralf Corsepius" <rc040203 at freenet.de>
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Sent: 2008?10?13? ??? ??04?16?49? GMT +10:00 Brisbane
Subject: Re: reviving Fedora Legacy

On Sun, 2008-10-12 at 18:22 -0700, Bob Arendt wrote:
> Jeff Spaleta wrote:
> > I'm not talking about QA.. I'm talking about verifying that the
> > volunteer maintainers are actually still in place a year+ later.  How
> > do make users aware that packages are unmaintained for 1+ years? Do
> > you plan to expire unmaintained packages so new users don't have
> > access to them?You have to have some process to verify that the
> > maintainers are there because you are explicitly stating that the life
> > of branch depends on an accurate count of the active maintainers. if
> > you don't build a process to try to verify maintainer involvement..the
> > branches could live forever because there is no pre-defined EOL.
> >
> >   
> > I really don't see how a Fedora Legacy can be maintained.
> Ask yourselves: How can EPEL be maintained?

I can answer this. :-)

I have Fedora 9 on my left hand and RHEL 5 on my right hand,literately, 
As a Red Hat employee, I urge myself to support both the latest
released versions on Fedora and RHEL.
I suspect there are many people have similar situation,
thus EPEL is required.

As for Fedora Legacy, just lack of critical mass.

Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.


-- 
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  Mon Oct 13 08:04:02 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 08:04:02 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
Message-ID: <loom.20081013T075922-165@post.gmane.org>

Martin Langhoff <martin.langhoff <at> gmail.com> writes:
> I don't think anyone would sign up as a user for such "support". LTS
> is about a fairly specific promise that is very hard to commit to.

The users I have in mind wouldn't actively "sign up" for it, they'd end up with 
it due to inaction, just as they currently end up with no updates at all.

See also Ralf Cors?pius's reply:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01110.html

> At the moment, it's not clear to me (perhaps because I haven't read
> the appropriate doco...)
> 
>  - Which Fedora release becomes the base for the next RH/CentOS release.

This is a decision made by Red Hat behind closed doors and only when it's time 
for it, not in advance. So we cannot know.

>  - How I transition my userbase from Fedora support to CentOS support at EOL

This is just not possible, as explained many times in this thread. See e.g.:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01047.html

> So I think it is a fair expectation to be able to "follow" a Fedora
> release into its RH/CentOS stabilisation, knowing that the process
> exists and that the stable branches are published. It definitely works
> for other distros. Perhaps it's possible with Fedora -- hints and
> pointers welcome.

It's neither a fair expectation nor possible.

        Kevin Kofler



From kevin.kofler at chello.at  Mon Oct 13 08:08:57 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 08:08:57 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
	<1223865390.4250.32.camel@rlt60f8.laptop.redhat.com>
Message-ID: <loom.20081013T080514-964@post.gmane.org>

Robert Locke <lists <at> ralii.com> writes:
> And then have everyone complaining when the "upgrade" to the new version
> introduced an incompatibility.  Take a look at the recent complaining as
> KDE moved forward.  Why not just upgrade to the next Fedora release
> then?  If you want security/stability, it requires backporting....

Obviously we wouldn't upgrade F8 to KDE 4!

If anything, we'd upgrade it to newer 3.5.x releases, but even that is not 
necessary because KDE is among the few upstream projects who publish backported 
security patches for older releases, so we do not have to backport anything on 
our own, just apply the security fixes from KDE. We could stay on 3.5.10 for 
years, and that also works for branches like 4.0, 4.1 or 4.2 which aren't as 
long-lived as 3.5.

         Kevin Kofler



From kevin.kofler at chello.at  Mon Oct 13 08:15:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 08:15:29 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<48F23CDF.1090304@gmail.com>
	<200810130225.m9D2PBvU014524@laptop14.inf.utfsm.cl>
	<48F2B56F.7000508@gmail.com>
	<1223866847.4250.42.camel@rlt60f8.laptop.redhat.com>
Message-ID: <loom.20081013T081413-814@post.gmane.org>

Robert Locke <lists <at> ralii.com> writes:
> But how often is development done (for a year or so) that then becomes
> the actual production system?  Would not the production system be
> installed in parallel as you approached the timeframe for deployment?

They probably use the infamous "developmestuction" methodology. :-/

http://thedailywtf.com/Articles/The_Developmestuction_Environment.aspx

        Kevin Kofler



From pertusus at free.fr  Mon Oct 13 08:20:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 10:20:06 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
References: <174473882.118211223883915968.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <20081013082006.GC2670@free.fr>

On Mon, Oct 13, 2008 at 03:53:57AM -0400, Ding Yi Chen wrote:
> 
> I can answer this. :-)
> 
> I have Fedora 9 on my left hand and RHEL 5 on my right hand,literately, 
> As a Red Hat employee, I urge myself to support both the latest
> released versions on Fedora and RHEL.

Please don't give arguments to Ralf about secret redhat agendas...

> As for Fedora Legacy, just lack of critical mass.

How can you say that? The project was refused from the beginning. Look
at my reply to Rex for an historical perspective.

--
Pat



From emmanuel.seyman at club-internet.fr  Mon Oct 13 08:24:02 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 10:24:02 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F2A325.3090704@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
Message-ID: <20081013082402.GA25102@orient.maison.lan>

* Les Mikesell [13/10/2008 09:57] :
>
> Why, when Fedora is the one stopping support for the users that adapted  
> to a particular Fedora version?  I'm suggestion this migration as a  
> substitute for the  ongoing support that is lacking.

We do not stop support.
At any one time, two versions of Fedora are maintained.

Emmanuel



From rjones at redhat.com  Mon Oct 13 08:25:38 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 13 Oct 2008 09:25:38 +0100
Subject: CMake!
In-Reply-To: <loom.20081012T173610-940@post.gmane.org>
References: <48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
Message-ID: <20081013082538.GA26640@amd.home.annexia.org>


One specific problem with cmake again emerges because of Windows /
"strange platform" portability.  Gnulib[1] offers a very important
option to us when porting software which makes lots of posix/libc
calls.  Unfortunately Gnulib doesn't currently work unless you're
using automake & autoconf, and I cannot see that changing any time
soon, since Gnulib is intimately tied to m4 macros.

Rich.

[1] http://www.gnu.org/software/gnulib/

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From emmanuel.seyman at club-internet.fr  Mon Oct 13 08:30:12 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 10:30:12 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T001327-394@post.gmane.org>
References: <gct38m$scd$1@ger.gmane.org> <20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
Message-ID: <20081013083012.GB25102@orient.maison.lan>

* Kevin Kofler [13/10/2008 09:57] :
>
> want, the infrastructure is essentially already there. Right now, we're stuck 
> in a chicken&egg situation, where the people controlling the infrastructure 
> say "show us interested maintainers first" and potentially interested packagers 
> say "show us the infrastructure first".

The difference between the two sides is that, while the packagers are a
necessity, the Fedora infrastructure isn't.

Emmanuel



From rc040203 at freenet.de  Mon Oct 13 08:30:55 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 10:30:55 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
References: <2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <1223886656.3564.1522.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 03:53 -0400, Ding Yi Chen wrote:
> 
> 
> ----- Original Message -----
> From: "Ralf Corsepius" <rc040203 at freenet.de>
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> Sent: 2008?10?13? ??? ??04?16?49? GMT +10:00 Brisbane
> Subject: Re: reviving Fedora Legacy
> 
> On Sun, 2008-10-12 at 18:22 -0700, Bob Arendt wrote:
> > Jeff Spaleta wrote:
> > > I'm not talking about QA.. I'm talking about verifying that the
> > > volunteer maintainers are actually still in place a year+ later.  How
> > > do make users aware that packages are unmaintained for 1+ years? Do
> > > you plan to expire unmaintained packages so new users don't have
> > > access to them?You have to have some process to verify that the
> > > maintainers are there because you are explicitly stating that the life
> > > of branch depends on an accurate count of the active maintainers. if
> > > you don't build a process to try to verify maintainer involvement..the
> > > branches could live forever because there is no pre-defined EOL.
> > >
> > >   
> > > I really don't see how a Fedora Legacy can be maintained.
> > Ask yourselves: How can EPEL be maintained?
> 
> I can answer this. :-)
> 
> I have Fedora 9 on my left hand and RHEL 5 on my right hand,literately, 
> As a Red Hat employee, 
That's the difference !!!!

You volunteered to support your packages in EPEL because RHEL is part of
your job. As a free and independent Fedora contributor, neither RHEL nor
EPEL are of any interest to me. 

However I've repeatedly found myself in situations of being stuck with
EOL'ed Fedora => I'd offer to continue "keepalive maintenance" of my
packages for discontinued Fedora, if the related efforts can be kept
minimal.

> As for Fedora Legacy, just lack of critical mass.
Well, it certainly makes a difference if an enterprise's employees work
on several distros in parallel because these are part of their job (rsp.
the basis of their job) or whether somebody contributes packages on a
volunteered basis :)


Ralf





From forum at ru.bir.ru  Mon Oct 13 08:36:27 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 13 Oct 2008 12:36:27 +0400
Subject: Regarding install options
In-Reply-To: <1223791786.3564.1322.camel@beck.corsepiu.local>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>	<1223655604.4410.153.camel@luminos.localdomain>	<1223675348.3564.1271.camel@beck.corsepiu.local>	<1223675533.4410.183.camel@luminos.localdomain>	<1223677508.3564.1295.camel@beck.corsepiu.local>	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
Message-ID: <gcv1ab$l5h$1@ger.gmane.org>

Ralf Corsepius ?????:
> On Fri, 2008-10-10 at 15:31 -0700, Jesse Keating wrote:
>> On Sat, 2008-10-11 at 00:25 +0200, Ralf Corsepius wrote:
>>>> Great, now get consensus on what 'minimal' should be.
>>> shell + networking.
>>>
>>> Approximately the set of packages required for a networked install.
>> And does that include the ability to add more later?
> Sure, yum + rpm are a requirement.
> 
> Ralf
>  
> 

No, only rpm is needed.
So, yum may be safely installed later by rpm.



From dchen at redhat.com  Mon Oct 13 08:40:48 2008
From: dchen at redhat.com (Ding Yi Chen)
Date: Mon, 13 Oct 2008 04:40:48 -0400 (EDT)
Subject: reviving Fedora Legacy
In-Reply-To: <20081013082006.GC2670@free.fr>
Message-ID: <551627204.122091223887248439.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>

----- Original Message -----
From: "Patrice Dumas" <pertusus at free.fr>
To: fedora-devel-list at redhat.com
Sent: 2008?10?13? ??? ??06?20?06? GMT +10:00 Brisbane
Subject: Re: reviving Fedora Legacy

> On Mon, Oct 13, 2008 at 03:53:57AM -0400, Ding Yi Chen wrote:
> > 
> > I can answer this. :-)
> > 
> > I have Fedora 9 on my left hand and RHEL 5 on my right hand,literately, 
> > As a Red Hat employee, I urge myself to support both the latest
> > released versions on Fedora and RHEL.

> Please don't give arguments to Ralf about secret redhat agendas...

Don't worry, I don't know any secret agendas. :-)

> As for Fedora Legacy, just lack of critical mass.

> How can you say that? The project was refused from the beginning. Look
at my reply to Rex for an historical perspective.

Take the UQM project for example. It revives the Star Control 2,
which has been release in 1992. The date of release is not so relevant,
whether somebodies are convinced to continuously support it, that is. 


==
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.


-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list



From forum at ru.bir.ru  Mon Oct 13 08:41:44 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 13 Oct 2008 12:41:44 +0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48EFCA8E.5050805@fedoraproject.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<bfdeacfa0810100613k4a5a90dbi2ec9ce779860cd0f@mail.gmail.com>	<d654s5x9eo.ln2@ppp1053.in.ipex.cz>	<gcohlt$3k0$1@ger.gmane.org>
	<48EFCA8E.5050805@fedoraproject.org>
Message-ID: <gcv1k8$nb1$1@ger.gmane.org>

Rahul Sundaram ?????:
> Pavel Alexeev (aka Pahan-Hubbitus) wrote:
>> Matej Cepl ?????:
>>> On 2008-10-10, 13:13 GMT, Mark Bidewell wrote:
>>>> I would submit that CentOS/RHEL IS the equivalent of
>>>> Fedora LTS.
>>>
>>> I would venture even to say that CentOS *is* Fedora LTS
>> I agree what CentOS is more stable and has more time support, but it 
>> is totally not equivalent of Fedora. Just see CVS branches of programs 
>> for Fedora and RHEL. So, many (notably new and not highly famous) 
>> programs is not present in RHEL and CentOS.
> 
> About 2000 more in EPEL. http://fedoraproject.org/wiki/EPEL. 
> Participate, if you would like to see your (missing) favourites as well.
> 
> Rahul
> 
Off course. This is not reproach. I'm only constant fact - CentOS is far 
  from "Fedora LTS" equivalent. So, I'm choose Fedora and participate in 
it. And, with think what Fedora no needed LTS, any similar it is highly 
needed for servers, I thought sometimes.



From emmanuel.seyman at club-internet.fr  Mon Oct 13 08:46:14 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 10:46:14 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T075922-165@post.gmane.org>
References: <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
Message-ID: <20081013084614.GA25491@orient.maison.lan>

* Kevin Kofler [13/10/2008 10:36] :
>
> The users I have in mind wouldn't actively "sign up" for it, they'd end up with 
> it due to inaction, just as they currently end up with no updates at all.

With not even an opt-in ?
This means that we'll be changing support conditions on a user's box
without even telling him we're doing so.

Emmanuel



From emmanuel.seyman at club-internet.fr  Mon Oct 13 08:48:39 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 10:48:39 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013082006.GC2670@free.fr>
References: <174473882.118211223883915968.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<20081013082006.GC2670@free.fr>
Message-ID: <20081013084839.GB25491@orient.maison.lan>

* Patrice Dumas [13/10/2008 10:36] :
>
> How can you say that? The project was refused from the beginning. Look
> at my reply to Rex for an historical perspective.

???
Fedora Legacy was created way ahead of the schedule that Red Hat had
planned for it, at the community's request.

Emmanuel



From forum at ru.bir.ru  Mon Oct 13 08:49:07 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 13 Oct 2008 12:49:07 +0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <da159fda0810100713x2d9c2e8ch339124e2510a930d@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<da159fda0810100713x2d9c2e8ch339124e2510a930d@mail.gmail.com>
Message-ID: <gcv223$nb1$2@ger.gmane.org>

Jon Stanley ?????:
  > Well, in all fairness, Fedora's stated goal is to advance the state of
> free software. You get that by being bleeding-edge. Unfortunately,
> being bleeding edge also means not being suitable for production
> environments - these are two fundamentally incompatible goals. This is
> why Red Hat Linux split into two - Fedora and RHEL. RHEL is a
> derivative distribution of Fedora.
All sounds good, by RHEL is not free. So, in this case many people 
pointed to CentOS, and I agree with it, but it is even not RedHat or 
Fedora initiative.



From forum at ru.bir.ru  Mon Oct 13 08:54:31 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 13 Oct 2008 12:54:31 +0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>
	<16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>
Message-ID: <gcv2c7$nb1$3@ger.gmane.org>

Arthur Pemberton ?????:
> 2008/10/10 Toshio Kuratomi <a.badger at gmail.com>:
>> Dmitry Butskoy wrote:
>>> Itamar - IspBrasil wrote:
>>>> any chance to increase the life of fedora releases ?
>>>>
>>>> or fedora will be only blending edge ?
>>>>
>>>> In my opinion fedora is losing space from centos and ubuntu
>>> ...
>>>
>>>> The brazilian government, one of the biggest Fedora Case of the world is
>>>> changing from Fedora/ Red Hat to Ubuntu/Debian.
>>> The problem was at an initial point, when Fedora was considered "for
>>> enthusiasts only". A lot of previous "RedHat Linux enthusiasts" just
>>> switch to CentOS (and similar RHEL-based systems), no more using Fedora,
>>> because "it is marked as a non-for-production system even by its creators".
>>>
>> The fact that they switched to CentOS is *good* for Fedora.  CentOS's
>> goals are better oriented to the needs of someone that wants to deploy a
>> system and run it for years.
> 
> 
> They switched to Debian and Ubuntu. There is no evidence that they
> considered Centos.
> 
Apropos, is it very interesting - why?? Why Wikipedia was not considered 
Centos to migrate?. I'm not found any thinks about it in article.



From a.j.delaney at brighton.ac.uk  Mon Oct 13 08:57:14 2008
From: a.j.delaney at brighton.ac.uk (Aidan Delaney)
Date: Mon, 13 Oct 2008 09:57:14 +0100
Subject: OpenOffice and go-oo
Message-ID: <1223888234.4182.9.camel@ScaryMonster>

Dear all,
	Has there been any discussion of why Fedora ships a relatively stock
(stock + 98 patches) OO.o rather than shipping go-oo?  I must quickly
state that I'm not interested in starting a flamewar.  I've seen the
extended feature set provided by go-oo such as the opengl slide
transitions and I wonder what the rationale for shipping  stock+patches
is over shipping go-oo.  Particularly when go-oo appears to contain a
superset of the Fedora OO.o patches.

--
Aidan Delaney



From pertusus at free.fr  Mon Oct 13 09:20:32 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 11:20:32 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013084614.GA25491@orient.maison.lan>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
Message-ID: <20081013092032.GD2670@free.fr>

On Mon, Oct 13, 2008 at 10:46:14AM +0200, Emmanuel Seyman wrote:
> * Kevin Kofler [13/10/2008 10:36] :
> >
> > The users I have in mind wouldn't actively "sign up" for it, they'd end up with 
> > it due to inaction, just as they currently end up with no updates at all.
> 
> With not even an opt-in ?
> This means that we'll be changing support conditions on a user's box
> without even telling him we're doing so.

We don't need to tell if it is on the right direction. And sure we'll
tell, but only if it is succesful in term of enough packagers doing so.

--
Pat



From pertusus at free.fr  Mon Oct 13 09:22:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 11:22:37 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013084839.GB25491@orient.maison.lan>
References: <174473882.118211223883915968.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<20081013082006.GC2670@free.fr>
	<20081013084839.GB25491@orient.maison.lan>
Message-ID: <20081013092237.GE2670@free.fr>

On Mon, Oct 13, 2008 at 10:48:39AM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [13/10/2008 10:36] :
> >
> > How can you say that? The project was refused from the beginning. Look
> > at my reply to Rex for an historical perspective.
> 
> ???
> Fedora Legacy was created way ahead of the schedule that Red Hat had
> planned for it, at the community's request.

I am not speaking about fedora legacy but simply about leaving the EOL
fedora branches on such that interested packagers can still maintain
packages.

--
Pat



From emmanuel.seyman at club-internet.fr  Mon Oct 13 09:28:34 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 11:28:34 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F29D70.4020808@gmail.com>
References: <200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<48F23CDF.1090304@gmail.com>
	<20081012223736.GA19798@orient.maison.lan>
	<48F29D70.4020808@gmail.com>
Message-ID: <20081013092834.GA26064@orient.maison.lan>

* Les Mikesell [13/10/2008 09:57] :
>
> Emmanuel Seyman wrote:
>
>> There's a notion called freedom that you may have heard of.
>
> And how is that specific to Fedora?  I meant as opposed to a system  
> where you can actually deploy something that needs stability.

There are few distributions that I consider as free as Fedora and
none that I would consider more free.

> Local development for things you want to put into production progresses  
> at about the same rate as the system itself.  If you wait for an  
> enterprise version's release before starting, you'll be about a year and  
> a half behind.  If you develop on the previous enterprise version, there  
> will be a huge version jump in libraries, database versions, jvms, etc.  
> that will require changes and not take advantage of new capabilities.  

This sounds like you have an issue with the entreprise distributions and
you're trying to shoehorn Fedora into being a stopgap solution for it.
Why don't you work with the entreprise distributions' communities to
find a better solution ?

Emmanuel



From kevin.kofler at chello.at  Mon Oct 13 09:35:37 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 09:35:37 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<loom.20081012T175241-931@post.gmane.org>
	<1223872903.8635.46.camel@hinge.endoframe.net>
Message-ID: <loom.20081013T093227-545@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> Do you also want to use doxygen to regenerate API documentation

Yes, definitely! In fact, the KDE packages already do this. And have to do it, 
because KDE does not include Doxygen output in their tarballs (and rightfully 
so).

> included in a tarball

You're incorrectly assuming it is shipped in the tarball in the first place.

> despite the fact that a different doxygen version's subtle
> stylesheet and markup changes could totally mangle the docs?

I've yet to see that happen. Maybe Doxygen simply cares more about backwards 
compatibility than the autotools.

        Kevin Kofler



From emmanuel.seyman at club-internet.fr  Mon Oct 13 09:41:55 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 11:41:55 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013092032.GD2670@free.fr>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
Message-ID: <20081013094155.GA26167@orient.maison.lan>

* Patrice Dumas [13/10/2008 11:28] :
>
> We don't need to tell if it is on the right direction.

I strongly disagree. This is no way to provide support.

>                                                        And sure we'll
> tell, but only if it is succesful in term of enough packagers doing so.

You mean that you want to change support conditions on somebody's box
and only tell them if the support is decent enough ?
If the "long term support" project isn't succesful, we're going to force
half baked updates on a box and not even warn him we're doing so??

Emmanuel



From caolanm at redhat.com  Mon Oct 13 09:55:07 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Mon, 13 Oct 2008 10:55:07 +0100
Subject: OpenOffice and go-oo
In-Reply-To: <1223888234.4182.9.camel@ScaryMonster>
References: <1223888234.4182.9.camel@ScaryMonster>
Message-ID: <1223891707.10624.95.camel@vain.rhgalway>

On Mon, 2008-10-13 at 09:57 +0100, Aidan Delaney wrote:
> Dear all,
> 	Has there been any discussion of why Fedora ships a relatively stock
> (stock + 98 patches) OO.o rather than shipping go-oo?  

I judge that this route provides the stablest and best supported product
for fedora users. We have a very reliable OOo in fedora. Well, we have
an OOo in fedora with a very low incidence of open reported bugs, which
isn't necessarily the same thing :-). My logic follows a route something
like keeping the product we have closest to the product that most
OOo-developers have, so that the full upstream qa and developer
resources are applicable to it. With a fairly aggressive push of any
fedora patches back upstream asap (where
http://qa.openoffice.org/issues/show_bug.cgi?id=90439 tracks the
additional patches we carry at any given time and their upstreamed
issues). Currently 47 patches for 3.0, against 98 for 2.4.1. Ideally it
would be 0.

> the opengl slide transitions

They're still in a bit of a confused state, but I hope to see these in
Fedora for F-11. I felt it was a bit much to take on for 3.0 with the
simultaneous complexity of a three-layer OOo and more reliance on OOo
extensions. 

> Particularly when go-oo appears to contain a superset of the Fedora
>  OO.o patches.

I've no beef with ooo-build at all, and its a fine resource, and we work
with them quite a bit. We carry their gstreamer stuff for example, and
they carried (before it was merged into vanilla) our fontconfig glyph
replacement stuff, etc. Its also possible to e.g. use ooo-build, create
a fedora section in it, and in that section just reference the specific
patches that would be applied in addition to vanilla. Various
distributions built out of the ooo-build tree generally pick what
patches in ooo-build to apply, so go-ooo.org variants can and generally
do vary from eachother as to what is in them. You could think of
ooo-build as a pool of available additional nifty patches and an
infrastructure of picking which ones to apply.

One practical day-to-day reason for not doing that for example is that
ooo-build is a set of patches, so for e.g. a security errata on OOo
using ooo-build is that you can end up with patches for patches for
patches, and then my brain fries and I get physically pained at the feel
of limited developer time draining away into packaging administrivia.

C.



From emmanuel.seyman at club-internet.fr  Mon Oct 13 09:55:48 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 11:55:48 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013092237.GE2670@free.fr>
References: <174473882.118211223883915968.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<20081013082006.GC2670@free.fr>
	<20081013084839.GB25491@orient.maison.lan>
	<20081013092237.GE2670@free.fr>
Message-ID: <20081013095548.GA26277@orient.maison.lan>

* Patrice Dumas [13/10/2008 11:28] :
>
> I am not speaking about fedora legacy but simply about leaving the EOL
> fedora branches on such that interested packagers can still maintain
> packages.

Ah, my apologies for the confusion.

Your proposal was never refused. You made it, a number of people asked
for clarifications or raised objections and you retired your proposal
rather than carry the project forward.

Emmanuel



From kevin.kofler at chello.at  Mon Oct 13 09:56:56 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 09:56:56 +0000 (UTC)
Subject: CMake!
References: <48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
	<20081013082538.GA26640@amd.home.annexia.org>
Message-ID: <loom.20081013T094032-667@post.gmane.org>

Richard W.M. Jones <rjones <at> redhat.com> writes:
> One specific problem with cmake again emerges because of Windows /
> "strange platform" portability.  Gnulib[1] offers a very important
> option to us when porting software which makes lots of posix/libc
> calls.  Unfortunately Gnulib doesn't currently work unless you're
> using automake & autoconf, and I cannot see that changing any time
> soon, since Gnulib is intimately tied to m4 macros.

Gnulib suffers from the exact same design failures as the autotools, 
a "library" which works by copying itself into the source code of the project 
is a horribly broken concept.

KDE has a library called kdewin32 which similarly adds missing functions for 
Window$, but does it as an actual library which can be used and linked 
normally. And it can be used almost transparently, it just needs a 
FindPackage(KDEWIN32 REQUIRED) (OK, you need to copy the FindKDEWIN32.cmake 
from kdelibs, it's not part of cmake, but that's a very small file) and it will 
automatically tweak the include search paths so the incomplete Window$ headers 
get overridden by ones containing the kdewin32 functions. And the 
libkdewin32.dll has no Qt/KDE dependencies. (The kdewin-installer won't 
currently allow you to install the kdewin32 package without Qt though because 
the package also contains a few executables which do use Qt. But you won't be 
using that installer anyway in a non-KDE app.)

I consider kdewin32 to be the clearly better solution. That said, 
unfortunately, I don't think they really support using it outside of KDE. They 
did make sure it doesn't have Qt/KDE dependencies, but they intentionally don't 
use it to port what they call the "win32libs" (Window$ ports of the common Free 
Software libraries KDE depends on).

        Kevin Kofler



From kevin.kofler at chello.at  Mon Oct 13 10:02:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 10:02:55 +0000 (UTC)
Subject: CMake!
References: <48ECEFB9.1080600@redhat.com>
	<1223658387.6770.53.camel@macbook.infradead.org>
	<48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
	<20081013082538.GA26640@amd.home.annexia.org>
	<loom.20081013T094032-667@post.gmane.org>
Message-ID: <loom.20081013T095833-430@post.gmane.org>

I have to correct myself slightly about kdewin32:

I wrote:
> it will automatically tweak the include search paths

Actually, it's not automatical, you do need to specify:
include_directories(${KDEWIN32_INCLUDES})
like for any other library. And also:
target_link_libraries(yourexecutable ${KDEWIN32_LIBRARIES})
(again, as for any other library).

        Kevin Kofler



From christof at damian.net  Mon Oct 13 10:21:00 2008
From: christof at damian.net (Christof Damian)
Date: Mon, 13 Oct 2008 12:21:00 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gcv2c7$nb1$3@ger.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<16de708d0810101305k588d3074i84b7bff82cd5cfde@mail.gmail.com>
	<gcv2c7$nb1$3@ger.gmane.org>
Message-ID: <f7c6719a0810130321w34037944rd01a4ca9b9f14146@mail.gmail.com>

2008/10/13 Pavel Alexeev (aka Pahan-Hubbitus) <forum at ru.bir.ru>:
> Arthur Pemberton ?????:
>> They switched to Debian and Ubuntu. There is no evidence that they
>> considered Centos.
>>
> Apropos, is it very interesting - why?? Why Wikipedia was not considered
> Centos to migrate?. I'm not found any thinks about it in article.

I think they just wanted to switch to Ubuntu, probably some personal
preference of some of the administrators. Maybe also some pushing from
the Ubuntu "sales" guys.

Using Fedora for web servers was in my opinion always a bad choice.
You just don't want to upgrade your servers that often.

And nowadays I wouldn't even use Fedora for a desktop which I
need/expect for work and expect working after every update. It just
happens too often that my mouse, keyboard, audio, wireless and now X
stopped working and I have to go browsing bugzilla and fedoraforum. By
now I changed my firewall and backup server to CentOS, because I
couldn't be bothered with keeping those updated with Fedora any more.
I used Fedora Legacy for a short while, but the community was just to
small to provide the updates in time. At work we just have RHEL &
CentOS.

I think the target audience for Fedora are Linux developers or fan
boys (that would be me) who want to be at the bleeding edge of
development and don't mind debugging and reporting bugs. Most of these
are probably even using rawhide instead of the release installs.

Maybe this should be made a bit clearer to users who install it, as I
expect it to get worse and not better.

None of this is meant negative by the way. I got exactly what I wanted
and don't want to change.

--
Christof Damian



From nicu_fedora at nicubunu.ro  Mon Oct 13 10:32:35 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 13 Oct 2008 13:32:35 +0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gcv223$nb1$2@ger.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<da159fda0810100713x2d9c2e8ch339124e2510a930d@mail.gmail.com>
	<gcv223$nb1$2@ger.gmane.org>
Message-ID: <48F323C3.6090806@nicubunu.ro>

Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> Jon Stanley ?????:
>  > Well, in all fairness, Fedora's stated goal is to advance the state of
>> free software. You get that by being bleeding-edge. Unfortunately,
>> being bleeding edge also means not being suitable for production
>> environments - these are two fundamentally incompatible goals. This is
>> why Red Hat Linux split into two - Fedora and RHEL. RHEL is a
>> derivative distribution of Fedora.
> All sounds good, by RHEL is not free. So, in this case many people 

It may not be free but id Free.

> pointed to CentOS, and I agree with it, but it is even not RedHat or 
> Fedora initiative.

Does it matter who's the initiative from? if the bits, the license and 
the price are right...

-- 
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 pertusus at free.fr  Mon Oct 13 10:35:31 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 12:35:31 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013094155.GA26167@orient.maison.lan>
References: <loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
Message-ID: <20081013103531.GA3087@free.fr>

On Mon, Oct 13, 2008 at 11:41:55AM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [13/10/2008 11:28] :
> >
> >                                                        And sure we'll
> > tell, but only if it is succesful in term of enough packagers doing so.
> 
> You mean that you want to change support conditions on somebody's box
> and only tell them if the support is decent enough ?
> If the "long term support" project isn't succesful, we're going to force
> half baked updates on a box and not even warn him we're doing so??

Why are you telling about half baked updates? Who will do that? Fedora
packagers?

--
Pat



From pertusus at free.fr  Mon Oct 13 10:40:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 12:40:36 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013095548.GA26277@orient.maison.lan>
References: <174473882.118211223883915968.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<20081013082006.GC2670@free.fr>
	<20081013084839.GB25491@orient.maison.lan>
	<20081013092237.GE2670@free.fr>
	<20081013095548.GA26277@orient.maison.lan>
Message-ID: <20081013104036.GB3087@free.fr>

On Mon, Oct 13, 2008 at 11:55:48AM +0200, Emmanuel Seyman wrote:
> 
> Your proposal was never refused. You made it, a number of people asked
> for clarifications or raised objections and you retired your proposal
> rather than carry the project forward.

It was refused, at least by Jef. Other people clearly showed antagonism
and nobody showed support, at least among boards. Ralf and now Kevin are
also supporters, but this is still not agreed by those leading fedora
currently.

Also look at my answer to Rex for the reference on antagonism toward
this kind of proposal.

I can still submit Kevin proposal to the next FESCo to have more
advices, maybe supportive people didn't talk yet.

--
Pat



From denis at poolshark.org  Mon Oct 13 10:51:36 2008
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 13 Oct 2008 12:51:36 +0200
Subject: F10 blocker bugs
Message-ID: <48F32838.8070508@poolshark.org>

Sorry to interrupt with a technical Fedora-related potentially 
constructive non-political post :-)

I submitted a bug that I think should be a F-10 release blocker 
(466207: evolution calendar crash) as it renders a major feature of a 
major application unusable.

I'm seeing a Fedora 10 blocker (440169), Fedora 10 Desktop blocker 
(457945) and Fedora 10 kernel blocker (466414). Should I just use my own 
judgement and add the blocker to my submitted bug ? or is that up to the 
bug *owner* ?

More generally, I'm surprised by how little technical discussion there 
is on this mailing list about bug fixing and bug blocker selections...

-denis



From rjones at redhat.com  Mon Oct 13 11:12:00 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 13 Oct 2008 12:12:00 +0100
Subject: CMake!
In-Reply-To: <loom.20081013T094032-667@post.gmane.org>
References: <48EF9F8F.3010603@gmail.com>
	<1223667525.26341.73.camel@localhost.localdomain>
	<D4FE026A-DBB5-4C93-A248-966E2B65D428@endoframe.com>
	<1223672167.26341.100.camel@localhost.localdomain>
	<loom.20081010T213933-101@post.gmane.org>
	<20081010232042.GA32721@tango.0pointer.de>
	<1223792734.3564.1340.camel@beck.corsepiu.local>
	<loom.20081012T173610-940@post.gmane.org>
	<20081013082538.GA26640@amd.home.annexia.org>
	<loom.20081013T094032-667@post.gmane.org>
Message-ID: <20081013111200.GA27227@amd.home.annexia.org>

On Mon, Oct 13, 2008 at 09:56:56AM +0000, Kevin Kofler wrote:
> Gnulib suffers from the exact same design failures as the autotools,
> a "library" which works by copying itself into the source code of
> the project is a horribly broken concept.

I didn't claim that I especially like autotools, just that I can get
along with them.  In this case Gnulib is a useful porting tool.  It
implements a few missing POSIX/libc functions on Windows, instead of
trying to do full-blown (slow) emulation like Cygwin.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From emmanuel.seyman at club-internet.fr  Mon Oct 13 11:23:26 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 13:23:26 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013104036.GB3087@free.fr>
References: <174473882.118211223883915968.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<2116264867.120121223884437581.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<20081013082006.GC2670@free.fr>
	<20081013084839.GB25491@orient.maison.lan>
	<20081013092237.GE2670@free.fr>
	<20081013095548.GA26277@orient.maison.lan>
	<20081013104036.GB3087@free.fr>
Message-ID: <20081013112326.GA27319@orient.maison.lan>

* Patrice Dumas [13/10/2008 13:01] :
>
> It was refused, at least by Jef. Other people clearly showed antagonism
> and nobody showed support, at least among boards. Ralf and now Kevin are
> also supporters, but this is still not agreed by those leading fedora
> currently.

Of course, nobody showed support.
Your proposal was poorly defined. It suggested forcing people to use
updates which would be maintained by an undefined community for an
undefined period of time with an undefined amount of QA.

Who in their right mind would support putting the Fedora brand on
a proposal of this kind ?

Emmanuel



From emmanuel.seyman at club-internet.fr  Mon Oct 13 11:30:21 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 13:30:21 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013103531.GA3087@free.fr>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
	<20081013103531.GA3087@free.fr>
Message-ID: <20081013113021.GA27573@orient.maison.lan>

* Patrice Dumas [13/10/2008 13:23] :
>
> Why are you telling about half baked updates? Who will do that? Fedora

They're half-baked in the sense that there's less commitement
post-EOL than pre-EOL.

Emmanuel



From pertusus at free.fr  Mon Oct 13 11:32:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 13:32:34 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013113021.GA27573@orient.maison.lan>
References: <loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
	<20081013103531.GA3087@free.fr>
	<20081013113021.GA27573@orient.maison.lan>
Message-ID: <20081013113234.GD3087@free.fr>

On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
> * Patrice Dumas [13/10/2008 13:23] :
> >
> > Why are you telling about half baked updates? Who will do that? Fedora
> 
> They're half-baked in the sense that there's less commitement
> post-EOL than pre-EOL.

But post-EOL there is currently no commitment and there won't be any
promise on it. Some is better than not at all.

--
Pat



From rawhide at fedoraproject.org  Mon Oct 13 11:38:18 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 13 Oct 2008 11:38:18 +0000 (UTC)
Subject: rawhide report: 20081013 changes
Message-ID: <20081013113818.7E5B81F8239@releng2.fedora.phx.redhat.com>

Compose started at Mon Oct 13 06:01:09 UTC 2008

New package chntpw
        Change passwords in Windows SAM files
New package gnomint
        Graphical x509 Certification Authority management tool
New package pdf-renderer
        A 100% Java PDF renderer and viewer
New package perl-MooseX-Types
        Organise your Moose types in libraries
New package scala
        A hybrid functional/object-oriented language for the JVM
New package spin-kickstarts
        Kickstart files and templates for creating your own Fedora Spins
New package trustedqsl
        TrustedQSL ham-radio applications
Updated Packages:

NetworkManager-0.7.0-0.11.svn4175.fc10
--------------------------------------
* Sat Oct 11 18:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.11.svn4175
- Fix conflicts for older PPTP VPN plugins

* Sat Oct 11 18:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.11.svn4174
- Ensure that mobile broadband cards are powered up before trying to use them
- Hostname changing support (rh #441453)
- Fix mobile broadband secret requests to happen less often
- Better handling of default devices and default routes
- Better information in tooltips and notifications
- Various UI cleanups; hide widgets that aren't used (rh #465397, rh #465395)
- Accept different separators for DNS servers and searches
- Make applet's icon accurately reflect signal strength of the current AP


NetworkManager-openvpn-0.7.0-16.svn4175.fc10
--------------------------------------------
* Sun Oct 12 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-16.svn4175
- Rebuild for updated NetworkManager
- Allow changing passwords from the connection editor
- Honor OpenVPN's 'route-vpn-gateway' option


NetworkManager-pptp-0.7.0-0.11.svn4178.fc10
-------------------------------------------
* Sun Oct 12 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-11.svn4178
- Rebuild for updated NetworkManager
- Allow changing passwords from the connection editor


NetworkManager-vpnc-0.7.0-0.10.svn4175.fc10
-------------------------------------------
* Sun Oct 12 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-10.svn4175
- Rebuild for updated NetworkManager
- Allow changing passwords from the connection editor


cjkunifonts-0.2.20080216.1-8.fc10
---------------------------------
* Mon Oct 13 18:00:00 2008 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-8.fc10
- Resolves: rhbz#466667 (Reverted to 0.2.20080216.1-4 without conf.avail.)


coreutils-6.12-14.fc10
----------------------
* Sun Oct 12 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 6.12-14
- cp -Z now correctly separated in man page (#466646)
- cp -Z works again (#466653)
- make preservation of SELinux CTX non-mandatory for
  preserve=all cp option


deluge-1.0.2-1.fc10
-------------------
* Sun Oct 12 18:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 1.0.2-1
- Update to new upstream release (1.0.2)
- Drop multithreaded boost compilation patch (fixed upstream, again).
  - mt-boost-fix.patch


gammu-1.21.0-1.fc10
-------------------
* Sat Oct 11 18:00:00 2008 Xavier Lamien <lxtnow[at]gmail.com> - 1.21.0-1
- Update release.


glibmm24-2.18.0-4.fc10
----------------------
* Sat Oct 11 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.18.0-4
- Split documentation in new doc sub-package
- Fixed some devhelp documentation links


gnome-desktop-2.24.0-5.fc10
---------------------------
* Sun Oct 12 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-5
- Don't crossfade between frames on a slideshow


gnome-panel-2.24.0-7.fc10
-------------------------
* Sun Oct 12 18:00:00 2008 Ray Strode  <rstrode at redhat.com> - 2.24.0-7
- Update smooth slide patch to be simpler based on feedback
  on gnome bug (554343)


gnome-settings-daemon-2.24.0-7.fc10
-----------------------------------
* Sun Oct 12 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-6
- Update fade patch to skip crossfade when changing frames in
  slideshow background.

* Sun Oct 12 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-7
- Try harder not to override peoples configured keyboard layouts


gtkmm24-2.14.1-1.fc10
---------------------
* Sat Oct 11 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.14.1-1
- Update to 2.14.1
- Fix documentation links


jokosher-1.0-0.2.20081012svn.fc10
---------------------------------
* Sun Oct 12 18:00:00 2008 Christopher Brown <snecklifter at gmail.com> - 1.0-0.2.20081012svn
- Update to latest svn


ldm-2.0.13-3.fc10
-----------------
* Sun Oct 12 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.13-3
- 2.0.13
- K12Linux theme by Maureen Duffy
- Rearrange LDM layout, thanks to Ryan Niebur of Debian
- Fix login box focus


lirc-0.8.4-0.5.fc10
-------------------
* Sun Oct 12 18:00:00 2008 - Jarod Wilson <jarod at redhat.com> - 0.8.4-1
- Update to 0.8.4 release


ltspfs-0.5.5-1.fc10
-------------------
* Sun Oct 12 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 0.5.5-1
- 0.5.5 fixes a cdpinger segfault


mcabber-0.9.9-1.fc10
--------------------
* Sun Oct 12 18:00:00 2008 Michael Fleming <mfleming+rpm at enlartenment.com> - 0.9.9-1
- Upgrade to 0.9.9
- Revert to using OpenSSL (#bz 389481)


openoffice.org-voikko-3.0-3.fc10
--------------------------------
* Mon Oct 13 18:00:00 2008 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 3.0-3
- Remove unneeded openoffice.org-core Requires, rpmbuild should detect that
  automatically. Keep libvoikko >= 2.0 Requires as instructed by upstream
  release notes, rpmbuild can't detected that automatically.


ovaldi-5.5.4-1.fc10
-------------------
* Sun Oct 12 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> 5.5.4-1
- New upstream build


pangomm-2.14.0-2.fc10
---------------------
* Sun Oct 12 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.14.0-2
- Added patch to fix devhelp main page


perl-5.10.0-48.fc10
-------------------
* Sun Oct 12 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 4:5.10.0-48
- Include fix for rt#52740 to fix a crash when using Devel::Symdump and
  Compress::Zlib together


perl-CGI-SpeedyCGI-2.22-3.fc10
------------------------------
* Sun Oct 12 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 2.22-3
- Work around C99 inline issues caused by C99 inline support in
  newer GCC versions (#464963, thanks to Andreas Thienemann)


perl-JSON-2.12-1.fc10
---------------------
* Sun Oct 12 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 2.12-1
- update to 2.12


quicksynergy-0.8.1-1.fc10
-------------------------
* Sun Oct 12 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.8.1-1
- Update to 0.8.1


redet-8.26-1.fc10
-----------------
* Sun Oct 12 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 8.26-1
- Version bump to 8.26. Closes Red Hat Bugzilla bug #464335.
- Dropped README-General because it is irrelevant for Fedora users.


sim-0.9.5-0.14.20080923svn2261rev.fc10
--------------------------------------
* Sun Oct 12 18:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.14.20080923svn2261rev
- Add (Patrice Dumas)
	Requires(postun): /sbin/ldconfig
	Requires(post): /sbin/ldconfig


xhtml2fo-style-xsl-20051222-2.fc10
----------------------------------
* Sun Oct 12 18:00:00 2008 Ismael Olea <ismael at olea.org> 20051222-2
- adding the .fc10 macro to the spec


Summary:
Added Packages: 7
Removed Packages: 0
Modified Packages: 28
Broken deps for i386
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From caolanm at redhat.com  Mon Oct 13 12:18:15 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Mon, 13 Oct 2008 13:18:15 +0100
Subject: cross-compilers...
Message-ID: <1223900295.10624.100.camel@vain.rhgalway>

I see that our binutils has a very convenient binutils_target ifdef in
it to make cross-binutils. Before I home-cook something to hack up some
local up-to-date cross compilers for myself for icecream/distcc, do we
have any semi-standard hackery for making arbitrary cross-gcc gcc/g++
rpms from our vanilla gcc one ?

C.



From dwmw2 at infradead.org  Mon Oct 13 12:18:01 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 13 Oct 2008 13:18:01 +0100
Subject: reviving Fedora Legacy
In-Reply-To: <1223804148.3564.1355.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
Message-ID: <1223900281.6770.573.camel@macbook.infradead.org>

On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
> Similar proposals have come up several times before (I once proposed
> something like this), but so far, they all had been shoot down so far.
> 
> Openly said, my impression that certain parties in Fedora fear a Fedora
> LTS rsp. life-time-extended Fedora to compete with RH products.

I understand that there is a market for a Fedora-based distribution
which doesn't receive megabytes of updates each week, and which is
supported for longer than a year.

Those are reasonable and understandable desires, although they aren't
something that I want personally.

What I _don't_ understand is why these requirements are not met by
CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
to serve?

Perhaps I've been inattentive; if so then I apologise. But could someone
please state for the record precisely what they want when they ask for
'Fedora LTS', that CentOS doesn't provide?

As I see it, there is a continuum of sorts -- from the daily churn of
rawhide, through the less anarchic but still considerable churn of the
latest Fedora release (currently F9), to the more conservative set of
updates for the previous release (F8), and then a bit of a jump to the
long-term stagnation? of RHEL/CentOS. You can pick whichever one you
like, according to your needs.

There is _perhaps_ some reason to desire some kind of middle ground
between CentOS and the outgoing Fedora release. But is there _such_ a
wide gap between the two that it's worth creating a completely new
distribution to fill it?

It seems like you're trying to make a completely new bikeshed, because
you think you want it a _slightly_ different hue to the existing one.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

? in this case, 'stagnation' is a feature rather than being derogatory.



From rc040203 at freenet.de  Mon Oct 13 12:22:26 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 14:22:26 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810130132.m9D1WpGV014409@laptop14.inf.utfsm.cl>
References: <200810120042.45039.opensource@till.name>
	<20081011232449.GD8235@free.fr>
	<200810121125.17381.opensource@till.name>
	<20081012093951.GA3936@free.fr>
	<20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<20081012142512.GE2700@free.fr>
	<20081012144338.GA16066@orient.maison.lan>
	<20081012145040.GF2700@free.fr>
	<20081012152831.GA17239@orient.maison.lan>
	<200810130132.m9D1WpGV014409@laptop14.inf.utfsm.cl>
Message-ID: <1223900547.3029.25.camel@beck.corsepiu.local>

On Sun, 2008-10-12 at 22:32 -0300, Horst H. von Brand wrote:
> Emmanuel Seyman <emmanuel.seyman at club-internet.fr> wrote:
> > * Patrice Dumas [12/10/2008 16:51] :
> > > Which work? Not shutting down builders and other infras for the EOL 
> > > branches?
> 
> > Not just not shutting them down but actively maintaining them, which
> > would require more work than maintaining the non-EOL branches.
> 
> I fail to see what the big job is here, but whatever.
Is Fedora's infrastructure working such kind of ineffective, "keeping
the build infrastructure alive" is such an overwhelming amount of
effort?

If so, I am very sure, EPEL4 will be discontinued, once RHEL6 will be
released, because of the additional effort, right?

Of cause this will not happen. More likely RH will assign people to
maintain it - See, no secret plans, just "hegemony of interests".




From buc at odusz.so-cdu.ru  Mon Oct 13 12:25:59 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 13 Oct 2008 16:25:59 +0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <gco7lb$2pr$1@ger.gmane.org>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>	<48EF60B2.4040708@odu.neva.ru>
	<gco7lb$2pr$1@ger.gmane.org>
Message-ID: <48F33E57.2060903@odu.neva.ru>

Matthew Woehlke wrote:
> Dmitry Butskoy wrote:
>> Since RedHat Linux 8, "latarcyrherb-sun16"  is the default console 
>> font. It seems that it was chosen in assumption that 
>> ascii+latin+cyrillic+hebrew+arabic in one a font should satisfy all 
>> the needs of console users.
>>
>> But "latarcyrheb-sun16" is so-called 512-glyphs font. Unfortunately, 
>> there is a restriction in hardware, which decreases the amount of 
>> available console colors if console font has more than 256 glyphs.
>
> Isn't Kernel Mode Setting supposed to fix this?

Perhaps yes. But it is still in progress, hence it could be done 
completely somewhere in the future, not for now.

Besides that, people can use some hardware which do not support KMS 
(either too old, or too specific); people can use too old systems, etc. 
Hence it is better to resolve this issue despite of the KMS feature.


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From dwmw2 at infradead.org  Mon Oct 13 12:26:50 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 13 Oct 2008 13:26:50 +0100
Subject: cross-compilers...
In-Reply-To: <1223900295.10624.100.camel@vain.rhgalway>
References: <1223900295.10624.100.camel@vain.rhgalway>
Message-ID: <1223900810.6770.580.camel@macbook.infradead.org>

On Mon, 2008-10-13 at 13:18 +0100, Caol?n McNamara wrote:
> I see that our binutils has a very convenient binutils_target ifdef in
> it to make cross-binutils. Before I home-cook something to hack up some
> local up-to-date cross compilers for myself for icecream/distcc, do we
> have any semi-standard hackery for making arbitrary cross-gcc gcc/g++
> rpms from our vanilla gcc one ?

No, not yet. We still haven't really worked out how to deal with the
incestuous dependencies between libgcc and glibc (mostly that
libgcc_shared.so needs to be linked against libc).

Options include 
 - requiring a pre-existing glibc for the target
 - shipping glibc sources as _part_ of the gcc package and doing it all
   together
 - building gcc with a dummy shared library for libgcc to link against,
   rather than the _actual_ glibc.so. It only needs to have entry points
   for a few functions; it doesn't have to have any actual _code_.
 - splitting the gcc package into two -- the first stage which can be
   built without shared libraries and then a second stage where
   libgcc.so and other stuff gets built (after glibc exists). As
   separate .src.rpm packages.

There are issues with each, and there are probably more options that
I've forgotten. I tend to favour the dummy library option, although I
never got as far as proving that it's actually viable.

If you want to look into it and come up with something we can actually
ship, that would be great.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From buc at odusz.so-cdu.ru  Mon Oct 13 12:30:30 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 13 Oct 2008 16:30:30 +0400
Subject: Arabic and Hebrew on the console
In-Reply-To: <20081010184542.GA29560@nostromo.devel.redhat.com>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>	<48EF60B2.4040708@odu.neva.ru>
	<20081010184542.GA29560@nostromo.devel.redhat.com>
Message-ID: <48F33F66.2080208@odu.neva.ru>

Bill Nottingham wrote:
> Dmitry Butskoy (buc at odusz.so-cdu.ru) said: 
>   
>> The solution looks simple -- just change the default "latarcyrheb-sun16"  
>> to some old good 256-gliph font. It is an obvious thing, especially in  
>> fact that actually the "latin+cyrillic+hebrew+arabic" combination seems  
>> never used in a real life of console. What seems to be used is just  
>> "ascii + local native language" (ie. ascii+latin1, ascii+cyrillic etc.),  
>> and such combinations do not exceed 256-glyph limit.
>>     
>
> This implies you'll never want to/need to see characters outside of
> your local language. I'm not sure that's a valid assumption.
>   

Certainly it is non-valid for any GUI. But for console TUI users it is 
valid.

Surely it could be fine if I can see both all the glyphs and all the 
colors. But because it is impossible, I chose to see colors, rather than 
all the glyphs. I need colors every day every hour, and I can ignore 
some boxes in some occasional pages I visited by lynx/elinks ...


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From pertusus at free.fr  Mon Oct 13 12:29:55 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 14:29:55 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223900281.6770.573.camel@macbook.infradead.org>
References: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
Message-ID: <20081013122955.GF3087@free.fr>

On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
> 
> I understand that there is a market for a Fedora-based distribution
> which doesn't receive megabytes of updates each week, and which is
> supported for longer than a year.

What have been proposed so far doesn't solve the 'which doesn't receive
megabytes of updates each week' part, only the 'supported for longer
than a year' part.

> What I _don't_ understand is why these requirements are not met by
> CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
> to serve?

Because it is not the same as you stress yourself. Centos is clearly not
the same than 'Fedora-based distribution which is supported for longer 
than a year'. It allows to use innovative technologies while not being
forced to update each year.

> As I see it, there is a continuum of sorts -- from the daily churn of
> rawhide, through the less anarchic but still considerable churn of the
> latest Fedora release (currently F9), to the more conservative set of
> updates for the previous release (F8), and then a bit of a jump to the
> long-term stagnation? of RHEL/CentOS. You can pick whichever one you
> like, according to your needs.

The last jump is not realistic in all cases. What should F6 user jump
to? Centos 5? Centos 6? And F8 users?

> There is _perhaps_ some reason to desire some kind of middle ground
> between CentOS and the outgoing Fedora release. But is there _such_ a
> wide gap between the two that it's worth creating a completely new
> distribution to fill it?

The proposal is not to create a new distribution, but simply haev EOLed
branches acl removed and leave th epossibility to build and push th
eresults, with a limitation of the changes to grave bug fixes and
security issues.

> It seems like you're trying to make a completely new bikeshed, because
> you think you want it a _slightly_ different hue to the existing one.

Who wants that?

(That being said, it is also possible that 'which doesn't receive 
megabytes of updates each week' issue may deserve to be looked at, but
it is a different issue).
--
Pat



From lesmikesell at gmail.com  Mon Oct 13 12:36:26 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 07:36:26 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081013092834.GA26064@orient.maison.lan>
References: <200810121125.17381.opensource@till.name>	<20081012093951.GA3936@free.fr>	<20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>	<20081012160303.GA17461@orient.maison.lan>	<48F23CDF.1090304@gmail.com>	<20081012223736.GA19798@orient.maison.lan>	<48F29D70.4020808@gmail.com>
	<20081013092834.GA26064@orient.maison.lan>
Message-ID: <48F340CA.8070304@gmail.com>

Emmanuel Seyman wrote:
> 
>>> There's a notion called freedom that you may have heard of.
>> And how is that specific to Fedora?  I meant as opposed to a system  
>> where you can actually deploy something that needs stability.
> 
> There are few distributions that I consider as free as Fedora and
> none that I would consider more free.

OK, but how much of that freedom originates in Fedora?  I don't see how 
omitting more things from a distribution helps anyone.  But that's a 
different issue.

>> Local development for things you want to put into production progresses  
>> at about the same rate as the system itself.  If you wait for an  
>> enterprise version's release before starting, you'll be about a year and  
>> a half behind.  If you develop on the previous enterprise version, there  
>> will be a huge version jump in libraries, database versions, jvms, etc.  
>> that will require changes and not take advantage of new capabilities.  
> 
> This sounds like you have an issue with the entreprise distributions and
> you're trying to shoehorn Fedora into being a stopgap solution for it.
> Why don't you work with the entreprise distributions' communities to
> find a better solution ?

The issue is that the enterprise distributions don't put their own brand 
name on the early development work and ship it so users have a smooth 
transition through development, testing and the final release.  But the 
reason that doesn't happen is that Fedora fills that role except for 
providing a smooth transition to something production-ready.  I don't 
think it is me 'shoehorning' Fedora into the role that RH X.0 releases 
used to fill.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From fedora at leemhuis.info  Mon Oct 13 12:56:59 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 13 Oct 2008 14:56:59 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223900281.6770.573.camel@macbook.infradead.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<20081010144426.GC3236@free.fr>	<200810111658.49564.opensource@till.name>	<20081011213341.GA8235@free.fr>	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
Message-ID: <48F3459B.8080704@leemhuis.info>

On 13.10.2008 14:18, David Woodhouse wrote:
> On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
> 
> Perhaps I've been inattentive; if so then I apologise. But could someone
> please state for the record precisely what they want when they ask for
> 'Fedora LTS', that CentOS doesn't provide?

Sounds stupid, but afaics it's just two:

(1) having Fedora in the name.

(2) having all the package available that are Fedora and Add-On repos ship


"1" sounds stupid, but afaics it's really a big problem for a lot of 
people. They simply view CentOS as something completely different, which 
  it IMHO not really is. Maybe Fedora and CentOS should merge? Or maybe 
RH should simply start to distribute the RHEL bits freely.

Problem "2" is slowly getting fixed; EPEL now ships lots of those Fedora 
packages that are missing in RHEL/CentOS. More are needed, but that will 
happen over time. RPM Fusion will soon support RHEL/CentOS + EPEL as 
well, so most things soon will just work similarly on Fedora and 
RHEL/CentOS.

CU
knurd



From alsadi at gmail.com  Mon Oct 13 13:01:45 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 13 Oct 2008 16:01:45 +0300
Subject: OpenOffice and go-oo
In-Reply-To: <1223891707.10624.95.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
Message-ID: <385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>

I have not tested OOo 3.0 yet

but from my previous experience I vote for go-oo

many major distros except us use go-oo (novell/suse-related,
debian/ubuntu-related, Gentoo and others)

according to wikipedia one can't say it's a fork

but it's OOo with less political decisions (like relying on java for
almost every thing)
and go-oo fits well with fedora as it (the things I care about)
rely on gst
have a native support for SVG
faster
one can drop java and ship openoffice on a livecd (like other distros)
(although I don't care about 3D transitions)

http://go-oo.org/discover/

please double consider go-oo



From emmanuel.seyman at club-internet.fr  Mon Oct 13 13:06:32 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 15:06:32 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F340CA.8070304@gmail.com>
References: <20081012110313.GB6353@orient.maison.lan>
	<20081012122723.GC3936@free.fr>
	<20081012142155.GA13881@orient.maison.lan>
	<48F21617.7000707@gmail.com>
	<20081012160303.GA17461@orient.maison.lan>
	<48F23CDF.1090304@gmail.com>
	<20081012223736.GA19798@orient.maison.lan>
	<48F29D70.4020808@gmail.com>
	<20081013092834.GA26064@orient.maison.lan>
	<48F340CA.8070304@gmail.com>
Message-ID: <20081013130632.GA28298@orient.maison.lan>

* Les Mikesell [13/10/2008 14:48] :
>
> The issue is that the enterprise distributions don't put their own brand  
> name on the early development work and ship it so users have a smooth  
> transition through development, testing and the final release.  But the  

Again, this sounds like a problem that the entreprise distributions are
responsible. Working with them to release betas seems like the best
solution to your problem, IMHO.

Emmanuel



From sundaram at fedoraproject.org  Mon Oct 13 13:07:48 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 13 Oct 2008 18:37:48 +0530
Subject: F10 blocker bugs
In-Reply-To: <48F32838.8070508@poolshark.org>
References: <48F32838.8070508@poolshark.org>
Message-ID: <48F34824.9020603@fedoraproject.org>

Denis Leroy wrote:
> Sorry to interrupt with a technical Fedora-related potentially 
> constructive non-political post :-)
> 
> I submitted a bug that I think should be a F-10 release blocker (466207: 
> evolution calendar crash) as it renders a major feature of a major 
> application unusable.
> 
> I'm seeing a Fedora 10 blocker (440169), Fedora 10 Desktop blocker 
> (457945) and Fedora 10 kernel blocker (466414). Should I just use my own 
> judgement and add the blocker to my submitted bug ? or is that up to the 
> bug *owner* ?

Usually you can propose it. Adding it, doesn't actually make it a 
permanent blocker however. The relevant team involved and release 
engineering will have to make the final decision.

Rahul



From rc040203 at freenet.de  Mon Oct 13 13:09:29 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 15:09:29 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F3459B.8080704@leemhuis.info>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
Message-ID: <1223903369.3029.58.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote:
> On 13.10.2008 14:18, David Woodhouse wrote:
> > On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
> > 
> > Perhaps I've been inattentive; if so then I apologise. But could someone
> > please state for the record precisely what they want when they ask for
> > 'Fedora LTS', that CentOS doesn't provide?
> 
> Sounds stupid, but afaics it's just two:
> 
> (1) having Fedora in the name.
* CentOS/RHEL often are outdated in details, even in comparison with older Fedoras.
* RHEL being non-free.

> (2) having all the package available that are Fedora and Add-On repos ship
* Right, there is a huge gap between the packages being shipped by RHEL
+EPEL and those of Fedora.

> "1" sounds stupid, but afaics it's really a big problem for a lot of 
> people. They simply view CentOS as something completely different, which 
>   it IMHO not really is.
I disagree, CentOS and Fedora are completely different, e.g. on the
"project control/management" side, target-audience wise and
feature-wise.

>  Maybe Fedora and CentOS should merge?
Yes, this would be an improvement.

>  Or maybe 
> RH should simply start to distribute the RHEL bits freely.
And this would be an even better alternative, but it's not that I would
expect this to ever happen.

Ralf




From jwboyer at gmail.com  Mon Oct 13 13:11:24 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 13 Oct 2008 09:11:24 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081013122955.GF3087@free.fr>
References: <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
Message-ID: <20081013131123.GA19171@yoda.jdub.homelinux.org>

On Mon, Oct 13, 2008 at 02:29:55PM +0200, Patrice Dumas wrote:
>On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
>> 
>> I understand that there is a market for a Fedora-based distribution
>> which doesn't receive megabytes of updates each week, and which is
>> supported for longer than a year.
>
>What have been proposed so far doesn't solve the 'which doesn't receive
>megabytes of updates each week' part, only the 'supported for longer
>than a year' part.
>
>> What I _don't_ understand is why these requirements are not met by
>> CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
>> to serve?
>
>Because it is not the same as you stress yourself. Centos is clearly not
>the same than 'Fedora-based distribution which is supported for longer 
>than a year'. It allows to use innovative technologies while not being
>forced to update each year.

That, to me, sounds like you want to update/backport $new_hotness of the
day to Fedora LTS.  And that, to me, sounds like pain.

As an example, CentoOS and RHEL5 don't support KVM.  Would you want the
ability to backport KVM (or features like it) to a Fedora LTS?  If so,
that way lies madness.

>The proposal is not to create a new distribution, but simply haev EOLed
>branches acl removed and leave th epossibility to build and push th
>eresults, with a limitation of the changes to grave bug fixes and
>security issues.

Except that conflicts with what you said above about "...use innovative
technologies while not being forced to update each year.".

josh



From lesmikesell at gmail.com  Mon Oct 13 13:13:11 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 08:13:11 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081013082402.GA25102@orient.maison.lan>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<48EF687B.9090407@odu.neva.ru>	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>	<20081010153504.GE3236@free.fr>
	<48EF79A4.2030103@gmail.com>	<20081010175427.GA7389@orient.maison.lan>	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
Message-ID: <48F34967.9090201@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [13/10/2008 09:57] :
>> Why, when Fedora is the one stopping support for the users that adapted  
>> to a particular Fedora version?  I'm suggestion this migration as a  
>> substitute for the  ongoing support that is lacking.
> 
> We do not stop support.
> At any one time, two versions of Fedora are maintained.

How does that amount to not stopping support for a particular version?

The supported versions may be wildly different at any time and the next 
version may not be suitable for what you want to keep running.  For a 
simple example, what would you have done if your production environment 
involved packages from the jpackage repository through the time that the 
changes in fedora made it incompatible?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From nicolas.mailhot at laposte.net  Mon Oct 13 13:16:18 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 13 Oct 2008 15:16:18 +0200 (CEST)
Subject: reviving Fedora Legacy
In-Reply-To: <1223903369.3029.58.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
Message-ID: <d8da759ad3ab72a362c9cd870832b966.squirrel@arekh.dyndns.org>



Le Lun 13 octobre 2008 15:09, Ralf Corsepius a ?crit :
>
> On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote:

>> (2) having all the package available that are Fedora and Add-On
>> repos ship
> * Right, there is a huge gap between the packages being shipped by
> RHEL
> +EPEL and those of Fedora.

And there has nothing to do with the project name. Re-christening EPEL
Fedora LTS won't magically increase contributors.

-- 
Nicolas Mailhot



From ajax at redhat.com  Mon Oct 13 13:16:43 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 13 Oct 2008 09:16:43 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223748479.13589.313.camel@hinge.endoframe.net>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
Message-ID: <1223903803.7707.25.camel@atropine.boston.devel.redhat.com>

On Sat, 2008-10-11 at 14:07 -0400, Braden McDaniel wrote:
> When the estimate of "300 broken packages" was tossed out in the libtool
> 2.2.x thread, I figured there was no way *that* many packages could be
> running autoreconf or libtoolize.  But I have been surprised to find no
> advice against this practice in Fedora's packaging guidelines; and in
> light of that, the number is not quite so incredible.
> 
> While forbidding the use of autoreconf (or similar: autoconf, automake,
> libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> appropriate for the packaging guidelines to point out the pitfalls of
> this practice and advise packagers to avoid it where possible.
> 
> So what are those pitfalls? By running autoreconf, the RPM build becomes
> exposed to different versions of autoconf, automake, and libtool than
> were used by the upstream developer to create the upstream source
> package.  Newer versions of these tools have the potential to introduce
> incompatibilities, breaking the RPM build.  Rather than patching
> configure.[ac,in] and Makefile.am, a more resilient approach is to patch
> the configure script and Makefile.in files.

No thanks.  Patching Makefile.am at least stands a chance of applying
correctly across multiple releases of the package.  Worse, patching the
generated files stands a good chance of missing an instance of whatever
you were patching for when the next release comes out.

Packages change version much more often than libtool changes version.
I'd rather go with the method that's resilient against the more common
change.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/62c98e70/attachment.sig>

From sundaram at fedoraproject.org  Mon Oct 13 13:16:03 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 13 Oct 2008 18:46:03 +0530
Subject: OpenOffice and go-oo
In-Reply-To: <385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
References: <1223888234.4182.9.camel@ScaryMonster>	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
Message-ID: <48F34A13.1030906@fedoraproject.org>

Muayyad AlSadi wrote:
> I have not tested OOo 3.0 yet
> 
> but from my previous experience I vote for go-oo

There is no opportunity for voting here. The current OpenOffice.org 
maintainer has explained his reasons for the path of his choice. If a 
alternative needs to be in Fedora, somebody must step up to maintain it.

http://fedoraproject.org/wiki/PackageMaintainers/Join

Rahul



From caolanm at redhat.com  Mon Oct 13 13:19:57 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Mon, 13 Oct 2008 14:19:57 +0100
Subject: OpenOffice and go-oo
In-Reply-To: <385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
Message-ID: <1223903997.10624.113.camel@vain.rhgalway>

On Mon, 2008-10-13 at 16:01 +0300, Muayyad AlSadi wrote:
> go-oo fits well with fedora as it (the things I care about)
> rely on gst

As I said, we apply the gstreamer set of patches. FWIW Fedora was the
distro that provided the additional patches (now in vanilla) to place
all the *other* legacy audio stuff in OOo up on top of the audio-visual
stack which sits on that Novell-provided gstreamer base.

> one can drop java and ship openoffice on a livecd (like other distros)
> (although I don't care about 3D transitions)

Both go-ooo.org and vanilla can be configured using --without-java and
both will then suffer from (in 3.0) missing help search capability, and
various other random bits of java-requiring functionality. i.e.
openoffice.org-base needs hsqldb to work for the local .odb format and
hsqldb needs java to work. The help search requires lucene, and the xslt
style-sheet filter stuff needs saxon. Its wrong to think that the
go-ooo.org OOo doesn't need java to be completely functional.

C.



From pertusus at free.fr  Mon Oct 13 13:17:53 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 15:17:53 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013131123.GA19171@yoda.jdub.homelinux.org>
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<20081013131123.GA19171@yoda.jdub.homelinux.org>
Message-ID: <20081013131753.GB3139@free.fr>

On Mon, Oct 13, 2008 at 09:11:24AM -0400, Josh Boyer wrote:
> 
> >The proposal is not to create a new distribution, but simply haev EOLed
> >branches acl removed and leave th epossibility to build and push th
> >eresults, with a limitation of the changes to grave bug fixes and
> >security issues.
> 
> Except that conflicts with what you said above about "...use innovative
> technologies while not being forced to update each year.".

I wasn't clear, I should have said 'use innovative technologies during
the time fedora is not eol', while not being forced to update each year
(that's for the 'LTS' part).

--
Pat 



From lesmikesell at gmail.com  Mon Oct 13 13:19:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 08:19:34 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T075922-165@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>	<20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>	<loom.20081012T230422-741@post.gmane.org>	<48F288A3.8000601@shmuelhome.mine.nu>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
Message-ID: <48F34AE6.6060400@gmail.com>

Kevin Kofler wrote:
>
>>  - Which Fedora release becomes the base for the next RH/CentOS release.
> 
> This is a decision made by Red Hat behind closed doors and only when it's time 
> for it, not in advance. So we cannot know.

Does that mean that they think their customers like surprises?

>>  - How I transition my userbase from Fedora support to CentOS support at EOL
> 
> This is just not possible, as explained many times in this thread. See e.g.:
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01047.html
> 
>> So I think it is a fair expectation to be able to "follow" a Fedora
>> release into its RH/CentOS stabilisation, knowing that the process
>> exists and that the stable branches are published. It definitely works
>> for other distros. Perhaps it's possible with Fedora -- hints and
>> pointers welcome.
> 
> It's neither a fair expectation nor possible.

Then no one should be surprised at the migration to Ubuntu and other 
distributions that have a more orderly transition from version to version.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Oct 13 13:22:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 08:22:51 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <loom.20081013T074503-537@post.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<20081010144426.GC3236@free.fr>	<200810111658.49564.opensource@till.name>	<20081011213341.GA8235@free.fr>	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<16de708d0810111500h43f9b6a7k4a60df6ff654ccc6@mail.gmail.com>	<4f629b520810111521x758dac6dw4f11fc9a0a7fc82a@mail.gmail.com>	<1223781158.4250.17.camel@rlt60f8.laptop.redhat.com>	<200810130053.m9D0rOcw014248@laptop14.inf.utfsm.cl>	<1223863173.4250.26.camel@rlt60f8.laptop.redhat.com>
	<loom.20081013T074503-537@post.gmane.org>
Message-ID: <48F34BAB.8040806@gmail.com>

Kevin Kofler wrote:
> Robert Locke <lists <at> ralii.com> writes:
>> Really?  You saying that Fedora 7 came out before RHEL5?  Looking at the
>> calendar, it's a pretty simple Fedora Core 6, RHEL/CentOS 5, Fedora 7.
>> I don't see that "long moved past", unless you like to run Rawhide, at
>> which point, why are we talking about a stable LTS?
> 
> One word: updates!
> By the time RHEL 5 came out, even FC5 had a newer kernel (and several other 
> packages).

Ummm, as I recall, there were some update kernels in FC5 and even FC6 
that wouldn't boot on various hardware.  Was it _really_ necessary to 
ship those after a reliable version was available?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From fedora at leemhuis.info  Mon Oct 13 13:24:49 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 13 Oct 2008 15:24:49 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223903369.3029.58.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>	<0d44s5x8co.ln2@ppp1053.in.ipex.cz>
	<20081010144426.GC3236@free.fr>	<200810111658.49564.opensource@till.name>	<20081011213341.GA8235@free.fr>	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<1223900281.6770.573.camel@macbook.infradead.org>	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
Message-ID: <48F34C21.3000404@leemhuis.info>

On 13.10.2008 15:09, Ralf Corsepius wrote:
> On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote:
>> On 13.10.2008 14:18, David Woodhouse wrote:
>>> On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
 > [...]
>> "1" sounds stupid, but afaics it's really a big problem for a lot of 
>> people. They simply view CentOS as something completely different, which 
>>   it IMHO not really is.
> I disagree, CentOS and Fedora are completely different, e.g. on the
> "project control/management" side, target-audience wise and
> feature-wise.

Of course they are quite different in those areas. But when RHEL5 came 
out it felt and looked a lot like a slightly modified and enhanced 
Fedora Core 5 or 6 (which it was)-- that is want I meant ;-)

> [...]
>>  Or maybe 
>> RH should simply start to distribute the RHEL bits freely.
> And this would be an even better alternative, but it's not that I would
> expect this to ever happen.

Well, if things continue like in the past two years then the younger 
generation will only learn the Debian and Ubuntu way; that will 
influence the decisions which Linux distribution to take when those 
people get older and become decisions makers (the Wikipedia change is a 
good example for it afaics). Hence Red Hat and Fedora afaics really need 
to change some things become a bit more popular again if Red Hat wants 
to continue making money in the long run ;-)

Cu
knurd



From jwboyer at gmail.com  Mon Oct 13 13:23:37 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 13 Oct 2008 09:23:37 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081013131753.GB3139@free.fr>
References: <20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<20081013131123.GA19171@yoda.jdub.homelinux.org>
	<20081013131753.GB3139@free.fr>
Message-ID: <20081013132336.GB19171@yoda.jdub.homelinux.org>

On Mon, Oct 13, 2008 at 03:17:53PM +0200, Patrice Dumas wrote:
>On Mon, Oct 13, 2008 at 09:11:24AM -0400, Josh Boyer wrote:
>> 
>> >The proposal is not to create a new distribution, but simply haev EOLed
>> >branches acl removed and leave th epossibility to build and push th
>> >eresults, with a limitation of the changes to grave bug fixes and
>> >security issues.
>> 
>> Except that conflicts with what you said above about "...use innovative
>> technologies while not being forced to update each year.".
>
>I wasn't clear, I should have said 'use innovative technologies during
>the time fedora is not eol', while not being forced to update each year
>(that's for the 'LTS' part).

Ah.  And how is that different from CentOS?  At the time CentOS 5 was
release, it also contained the latest "innovative" technologies.  So,
what would be different about a Fedora LTS?

josh



From jonathan at jonmasters.org  Mon Oct 13 13:33:22 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Mon, 13 Oct 2008 09:33:22 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <20081007223409.19bc8223@ludwig-alpha.unil.ch>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com> <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
	<1223400274.26341.15.camel@localhost.localdomain>
	<1223402107.4410.20.camel@luminos.localdomain>
	<20081007223409.19bc8223@ludwig-alpha.unil.ch>
Message-ID: <1223904802.4264.37.camel@perihelion.int.jonmasters.org>

On Tue, 2008-10-07 at 22:34 +0200, Christian Iseli wrote:
> On Tue, 07 Oct 2008 10:55:07 -0700, Jesse Keating wrote:
> > Somebody else jumped on the thread and steered the conversation
> > toward a virtualbox problem, which somewhat related to Jon's issue,
> > it's not the same issue.
> 
> Right, mea culpa and sorry about that.  I thought my problem had the
> same root as the OP's problem, but it now appears I was wrong...

:)

I occasionally bring up the SELinux issue because I'm trying to ask
"what would a regular computer user think?", not whether I can solve the
problem for myself with setting contexts or disabling the protection. 

And last night, I had a wonderful SELinux experience again, this time
using Samba shares. None of the guests running within KVM were able to
talk to Samba, so I wasted time pondering networking problems, etc.
before I realized I rebooted since I setup the Samba shares. In the end,
the usual process of mumbling sweet words about SELinux and turning it
off was the response...and I remain convinced therefore that it is
entirely appropriate to subject regular desktop users to SELinux.

Jon.




From dwmw2 at infradead.org  Mon Oct 13 13:33:51 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 13 Oct 2008 14:33:51 +0100
Subject: reviving Fedora Legacy
In-Reply-To: <20081013122955.GF3087@free.fr>
References: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
Message-ID: <1223904831.6770.597.camel@macbook.infradead.org>

On Mon, 2008-10-13 at 14:29 +0200, Patrice Dumas wrote:
> On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
> > 
> > I understand that there is a market for a Fedora-based distribution
> > which doesn't receive megabytes of updates each week, and which is
> > supported for longer than a year.
> 
> What have been proposed so far doesn't solve the 'which doesn't receive
> megabytes of updates each week' part, only the 'supported for longer
> than a year' part.
> 
> > What I _don't_ understand is why these requirements are not met by
> > CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
> > to serve?
> 
> Because it is not the same as you stress yourself. Centos is clearly not
> the same than 'Fedora-based distribution which is supported for longer 
> than a year'. It allows to use innovative technologies while not being
> forced to update each year.

This is the part I have difficulty understanding. You want to use new
and innovative technologies, but you don't want to update your nice
stable system?

Do you want a perpetual motion machine with that too?

You're right -- you are offered updates, or you are offered stability,
and there isn't much of a middle ground. But that's just reality.

> > As I see it, there is a continuum of sorts -- from the daily churn of
> > rawhide, through the less anarchic but still considerable churn of the
> > latest Fedora release (currently F9), to the more conservative set of
> > updates for the previous release (F8), and then a bit of a jump to the
> > long-term stagnation? of RHEL/CentOS. You can pick whichever one you
> > like, according to your needs.
> 
> The last jump is not realistic in all cases. What should F6 user jump
> to? Centos 5? Centos 6? And F8 users?

F6 is basically RHEL4/CentOS 4 for the most part, isn't it?
And F8 would probably be closest to RHEL5/CentOS 5.

> The proposal is not to create a new distribution, but simply have
> EOLed branches acl removed and leave the possibility to build and push
> the results, with a limitation of the changes to grave bug fixes and
> security issues.

So no new innovation then? And you'd want to do this for _every_
six-monthly release of Fedora? Surely that's a whole boatload of effort
you don't need? Why not just do it for every other release? Or, perhaps
more usefully, every third release -- a new one about every 18 months?

I see no fundamental reason why we should _forbid_ people from doing
security updates for packages in EOL distributions, although I'm very
wary of the expectations that it would create. If we ship
official-looking updates for _some_ security bugs, na?ve users will
quite reasonably expect that they'll be receiving updates for _all_
serious security bugs, and our "You are unsupported; you need to upgrade
before you get hacked" message will be compromised.

I also think that with a niche market that small, between Fedora and
CentOS, you are unlikely to get enough volunteers to keep it viable --
isn't that what happened with Fedora Legacy last time? 

> (That being said, it is also possible that 'which doesn't receive 
> megabytes of updates each week' issue may deserve to be looked at, but
> it is a different issue).

That and/or ensuring that the packages you miss in CentOS are actually
in EPEL.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From lesmikesell at gmail.com  Mon Oct 13 13:34:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 08:34:27 -0500
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081013130632.GA28298@orient.maison.lan>
References: <20081012110313.GB6353@orient.maison.lan>	<20081012122723.GC3936@free.fr>	<20081012142155.GA13881@orient.maison.lan>	<48F21617.7000707@gmail.com>	<20081012160303.GA17461@orient.maison.lan>	<48F23CDF.1090304@gmail.com>	<20081012223736.GA19798@orient.maison.lan>	<48F29D70.4020808@gmail.com>	<20081013092834.GA26064@orient.maison.lan>	<48F340CA.8070304@gmail.com>
	<20081013130632.GA28298@orient.maison.lan>
Message-ID: <48F34E63.9050101@gmail.com>

Emmanuel Seyman wrote:
> * Les Mikesell [13/10/2008 14:48] :
>> The issue is that the enterprise distributions don't put their own brand  
>> name on the early development work and ship it so users have a smooth  
>> transition through development, testing and the final release.  But the  
> 
> Again, this sounds like a problem that the entreprise distributions are
> responsible. 

Yes, of course.  The change happened when RH stopped shipping X.0 
versions that were subsequently updated to X.1, X.2, etc. as they did 
through up through the 7.3 version, keeping the same community of users 
through the process.

> Working with them to release betas seems like the best
> solution to your problem, IMHO.

But Fedora _is_ the beta now... Or at least it was before the direction 
turned away from something suitable for servers.  I'm not quite sure 
where things are going now.

-- 
   Les Mikesell
    lesmikesell#gmail.com



From alsadi at gmail.com  Mon Oct 13 13:37:12 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 13 Oct 2008 16:37:12 +0300
Subject: OpenOffice and go-oo
In-Reply-To: <1223903997.10624.113.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
Message-ID: <385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>

> There is no opportunity for voting here.
I did not meant it literary

> As I said, we apply the gstreamer set of patches.
I was talking about video functionality

> ...
> Both go-ooo.org and vanilla can be configured using --without-java

there is a difference between disabling java completely
(--without-java) in vanilla ooo
and not relying on it in ooo-core and moving it away to less
frequently needed parts

in the first case you will lost most of functionality and that
functionality can't be installed later
but in the second case (having java but no dependence on it for
ooo-core) and extra package can introduce that functionality late

for example most livecd does not need ooo-base which depends on java
if you don't ship ooo-base but one should be able to add ooo-base
later from the repos this is not possible if ooo is compiled with
--without-java, the vanila ooo (at least 2.x) is a java monster while
go-oo don't miss much functionality without java because many things
in it are native

see what I have done with the vanilah
https://bugzilla.redhat.com/show_bug.cgi?id=453439
(I did that before knowing that other distros uses different ooo)



From emmanuel.seyman at club-internet.fr  Mon Oct 13 13:38:03 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 15:38:03 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <48F34967.9090201@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
Message-ID: <20081013133803.GA28852@orient.maison.lan>

* Les Mikesell [13/10/2008 15:31] :
>
> The supported versions may be wildly different at any time and the next  
> version may not be suitable for what you want to keep running.

Sounds like you should be using a distribution that offers a longer
support time than the Fedora offers.

Emmanuel



From rc040203 at freenet.de  Mon Oct 13 13:38:56 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 15:38:56 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F34C21.3000404@leemhuis.info>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
Message-ID: <1223905136.3029.81.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 15:24 +0200, Thorsten Leemhuis wrote:
> On 13.10.2008 15:09, Ralf Corsepius wrote:
> > On Mon, 2008-10-13 at 14:56 +0200, Thorsten Leemhuis wrote:
> >> On 13.10.2008 14:18, David Woodhouse wrote:
> >>> On Sun, 2008-10-12 at 11:35 +0200, Ralf Corsepius wrote:
>  > [...]
> >> "1" sounds stupid, but afaics it's really a big problem for a lot of 
> >> people. They simply view CentOS as something completely different, which 
> >>   it IMHO not really is.
> > I disagree, CentOS and Fedora are completely different, e.g. on the
> > "project control/management" side, target-audience wise and
> > feature-wise.
> 
> Of course they are quite different in those areas. But when RHEL5 came 
> out it felt and looked a lot like a slightly modified and enhanced 
> Fedora Core 5 or 6 (which it was)-- that is want I meant ;-)
True, at the time RHEL5 was new, it had been more or less a rebuilt
FC5/6 and switching between them had not been a major problem.

Nowadays, it isn't anymore and even will be less when FC10 comes out.

I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
alternatives. They are kind of a flashback to yesterday's state-of-art.

> > [...]
> >>  Or maybe 
> >> RH should simply start to distribute the RHEL bits freely.
> > And this would be an even better alternative, but it's not that I would
> > expect this to ever happen.
> 
> Well, if things continue like in the past two years then the younger 
> generation will only learn the Debian and Ubuntu way; that will 
> influence the decisions which Linux distribution to take when those 
> people get older and become decisions makers (the Wikipedia change is a 
> good example for it afaics). Hence Red Hat and Fedora afaics really need 
> to change some things become a bit more popular again if Red Hat wants 
> to continue making money in the long run ;-)

Chapeau! I whole-heartily agree.

Ralf




From jdieter at gmail.com  Mon Oct 13 13:38:54 2008
From: jdieter at gmail.com (Jonathan Dieter)
Date: Mon, 13 Oct 2008 16:38:54 +0300
Subject: SELinux - copying ISO file content
In-Reply-To: <1223904802.4264.37.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>
	<48E61A7E.8010404@redhat.com>
	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>
	<48EA1B32.1010008@redhat.com> <48EA725E.2050908@shaw.ca>
	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>
	<1223400274.26341.15.camel@localhost.localdomain>
	<1223402107.4410.20.camel@luminos.localdomain>
	<20081007223409.19bc8223@ludwig-alpha.unil.ch>
	<1223904802.4264.37.camel@perihelion.int.jonmasters.org>
Message-ID: <1223905134.22720.41.camel@jdlaptop>

On Mon, 2008-10-13 at 09:33 -0400, Jon Masters wrote:
> I occasionally bring up the SELinux issue because I'm trying to ask
> "what would a regular computer user think?", not whether I can solve the
> problem for myself with setting contexts or disabling the protection. 
> 
> And last night, I had a wonderful SELinux experience again, this time
> using Samba shares. None of the guests running within KVM were able to
> talk to Samba, so I wasted time pondering networking problems, etc.
> before I realized I rebooted since I setup the Samba shares. In the end,
> the usual process of mumbling sweet words about SELinux and turning it
> off was the response...and I remain convinced therefore that it is
> entirely appropriate to subject regular desktop users to SELinux.

Sorry, should that be s/appropriate/inappropriate/?  Just trying to
understand what you're saying.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/23af2eec/attachment.sig>

From pertusus at free.fr  Mon Oct 13 13:41:49 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 15:41:49 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081013133803.GA28852@orient.maison.lan>
References: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
Message-ID: <20081013134149.GD3139@free.fr>

On Mon, Oct 13, 2008 at 03:38:03PM +0200, Emmanuel Seyman wrote:
> * Les Mikesell [13/10/2008 15:31] :
> >
> > The supported versions may be wildly different at any time and the next  
> > version may not be suitable for what you want to keep running.
> 
> Sounds like you should be using a distribution that offers a longer
> support time than the Fedora offers.

Sounds like you don't want fedora packagers to volunteer for a longer 
(support) time in fedora (not necessarily under the fedora name but in 
the fedora infrastructure).

--
Pat



From poelstra at redhat.com  Mon Oct 13 13:44:38 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 13 Oct 2008 06:44:38 -0700
Subject: F10 blocker bugs
In-Reply-To: <48F32838.8070508@poolshark.org>
References: <48F32838.8070508@poolshark.org>
Message-ID: <48F350C6.10900@redhat.com>

Denis Leroy said the following on 10/13/2008 03:51 AM Pacific Time:
> Sorry to interrupt with a technical Fedora-related potentially 
> constructive non-political post :-)
> 
> I submitted a bug that I think should be a F-10 release blocker (466207: 
> evolution calendar crash) as it renders a major feature of a major 
> application unusable.

According to our release criteria this wouldn't necessarily block the 
release: https://fedoraproject.org/wiki/QA/ReleaseCriteria

> I'm seeing a Fedora 10 blocker (440169), Fedora 10 Desktop blocker 
> (457945) and Fedora 10 kernel blocker (466414). Should I just use my own 
> judgement and add the blocker to my submitted bug ? or is that up to the 
> bug *owner* ?

Here is a complete list of trackers for Fedora 10:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers



From poelstra at redhat.com  Mon Oct 13 13:46:05 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 13 Oct 2008 06:46:05 -0700
Subject: F10 blocker bugs
In-Reply-To: <48F350C6.10900@redhat.com>
References: <48F32838.8070508@poolshark.org> <48F350C6.10900@redhat.com>
Message-ID: <48F3511D.4070604@redhat.com>

John Poelstra said the following on 10/13/2008 06:44 AM Pacific Time:
> Denis Leroy said the following on 10/13/2008 03:51 AM Pacific Time:
>> Sorry to interrupt with a technical Fedora-related potentially 
>> constructive non-political post :-)
>>
>> I submitted a bug that I think should be a F-10 release blocker 
>> (466207: evolution calendar crash) as it renders a major feature of a 
>> major application unusable.
> 
> According to our release criteria this wouldn't necessarily block the 
> release: https://fedoraproject.org/wiki/QA/ReleaseCriteria

I correct myself.  Since it appears in a menu it MUST start and would be 
a blocker.

John



From a.j.delaney at brighton.ac.uk  Mon Oct 13 13:46:54 2008
From: a.j.delaney at brighton.ac.uk (Aidan Delaney)
Date: Mon, 13 Oct 2008 14:46:54 +0100
Subject: cross-compilers...
In-Reply-To: <1223900810.6770.580.camel@macbook.infradead.org>
References: <1223900295.10624.100.camel@vain.rhgalway>
	<1223900810.6770.580.camel@macbook.infradead.org>
Message-ID: <1223905615.4182.27.camel@ScaryMonster>

On Mon, 2008-10-13 at 13:26 +0100, David Woodhouse wrote:
> No, not yet. We still haven't really worked out how to deal with the
> incestuous dependencies between libgcc and glibc (mostly that
> libgcc_shared.so needs to be linked against libc).
This is further complicated as some of us (I assist with spu
cross-complilers) use newlib rather than glibc.

For spu-gcc we've come up with a solution where we have
spu-gcc-bootstrap which is in the BuildRequires of spu-newlib.  Then
spu-gcc Conflicts with spu-gcc-bootstrap and Depends on spu-newlib.

spu-gcc and spu-newlib are still available for package review in
bugzilla should anyone so fancy to critique our approach?  (Have I
dropped enough hints? :)

--
Aidan



From a.j.delaney at brighton.ac.uk  Mon Oct 13 13:51:45 2008
From: a.j.delaney at brighton.ac.uk (Aidan Delaney)
Date: Mon, 13 Oct 2008 14:51:45 +0100
Subject: OpenOffice and go-oo
In-Reply-To: <1223891707.10624.95.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
Message-ID: <1223905905.4182.32.camel@ScaryMonster>

Caol?n,
On Mon, 2008-10-13 at 10:55 +0100, Caol?n McNamara wrote:
> I judge that this route provides the stablest and best supported product
> for fedora users.
Many thanks for this concise and well-considered answer.  I am now
convinced that though go-oo may look like it has one or two extra
features on paper, the reality is that (a) these features may not be as
stable as we would like and (b) these features would require too much
investment of maintainer time.  Where both reasons (a) and (b) should
not be read as any criticism of the excellent go-oo codebase but are
personal opinions.

--
Aidan Delaney




From jonathan at jonmasters.org  Mon Oct 13 13:52:17 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Mon, 13 Oct 2008 09:52:17 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081001172038.GG10632@phobos.i.cabal.ca>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
Message-ID: <1223905937.4264.46.camel@perihelion.int.jonmasters.org>

On Wed, 2008-10-01 at 13:20 -0400, Kyle McMartin wrote:
> On Wed, Oct 01, 2008 at 06:52:15PM +0200, Jakub Jelinek wrote:
> > Given the recent 5sec boot efforts http://lwn.net/Articles/299483/
> > and Mandriva follow-ups on that http://lwn.net/Articles/300873/,
> > I thought I'd share my modprobe and MAKEDEV speedup patches with
> > a wider community so folks can experiment with them, especially seeing
> > Mandriva folks playing with turning modprobe into a daemon because of its
> > slowness.

> Have you tested things on a big endian machine? In any case, this looks
> really good. Hopefully Jon will apply this upstream soon so we can get
> it in F10.

So I've added an alternative patch from Alan Jenkins to the current git
and in rawhide today, also using a binary index (there's no version info
embedded right now however that is about to be fixed in a later patch).
I think my plan right now is to profile this against Jakub's patch and
pick the winner. So there might be a few more changes this week :)

Jon.




From berrange at redhat.com  Mon Oct 13 13:54:03 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 13 Oct 2008 14:54:03 +0100
Subject: cross-compilers...
In-Reply-To: <1223905615.4182.27.camel@ScaryMonster>
References: <1223900295.10624.100.camel@vain.rhgalway>
	<1223900810.6770.580.camel@macbook.infradead.org>
	<1223905615.4182.27.camel@ScaryMonster>
Message-ID: <20081013135403.GD28075@redhat.com>

On Mon, Oct 13, 2008 at 02:46:54PM +0100, Aidan Delaney wrote:
> On Mon, 2008-10-13 at 13:26 +0100, David Woodhouse wrote:
> > No, not yet. We still haven't really worked out how to deal with the
> > incestuous dependencies between libgcc and glibc (mostly that
> > libgcc_shared.so needs to be linked against libc).
> This is further complicated as some of us (I assist with spu
> cross-complilers) use newlib rather than glibc.
> 
> For spu-gcc we've come up with a solution where we have
> spu-gcc-bootstrap which is in the BuildRequires of spu-newlib.  Then
> spu-gcc Conflicts with spu-gcc-bootstrap and Depends on spu-newlib.

Sounds similar to what we've done for mingw packages.

To bootstrap we have have two packages whose source is just the pre-built
mingw related APIs/runtime

  mingw32-runtime-bootstrap   (closet equiv to libc for mingw)
  mingw32-w32apis-bootstrap   (extra windows APIs)

Then we can build  mingw32-binutils & mingw32-gcc, and with those then
build the real mingw32-runtime and mingw32-w32apis RPMs, which obsolete
the 2  -bootstrap RPMs of same name. The two bootstrap RPMs only ever
need to be installed in the mock chroot once, for the initial build 
cycle & can then be disposed of.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From rc040203 at freenet.de  Mon Oct 13 13:54:04 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 15:54:04 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223904831.6770.597.camel@macbook.infradead.org>
References: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<1223904831.6770.597.camel@macbook.infradead.org>
Message-ID: <1223906044.3029.97.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 14:33 +0100, David Woodhouse wrote:
> On Mon, 2008-10-13 at 14:29 +0200, Patrice Dumas wrote:
> > On Mon, Oct 13, 2008 at 01:18:01PM +0100, David Woodhouse wrote:
> > > 
> > > I understand that there is a market for a Fedora-based distribution
> > > which doesn't receive megabytes of updates each week, and which is
> > > supported for longer than a year.
> > 
> > What have been proposed so far doesn't solve the 'which doesn't receive
> > megabytes of updates each week' part, only the 'supported for longer
> > than a year' part.
> > 
> > > What I _don't_ understand is why these requirements are not met by
> > > CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
> > > to serve?
> > 
> > Because it is not the same as you stress yourself. Centos is clearly not
> > the same than 'Fedora-based distribution which is supported for longer 
> > than a year'. It allows to use innovative technologies while not being
> > forced to update each year.
> 
> This is the part I have difficulty understanding. You want to use new
> and innovative technologies, but you don't want to update your nice
> stable system?
It's not necessarily a matter of will on the user's side.

It often is a matter of situations where you can't upgrade because your
personal restrictions aren't synch'ed with Fedora's schedule.

> > The proposal is not to create a new distribution, but simply have
> > EOLed branches acl removed and leave the possibility to build and push
> > the results, with a limitation of the changes to grave bug fixes and
> > security issues.
> 
> So no new innovation then? 
Yes, just bug fixes for those bugs contributors find time to look into.

If things blow up, they blow up, still better than users using an
entirely unmaintained distro.

> And you'd want to do this for _every_
> six-monthly release of Fedora? Surely that's a whole boatload of effort
> you don't need? Why not just do it for every other release? Or, perhaps
> more usefully, every third release -- a new one about every 18 months?
This would be an alternative. 

In this case, I'd use those Fedora releases RHEL releases are being
derived from, because this would allow to harvest RHEL packages.




From pertusus at free.fr  Mon Oct 13 13:55:33 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 15:55:33 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013132336.GB19171@yoda.jdub.homelinux.org>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<20081013131123.GA19171@yoda.jdub.homelinux.org>
	<20081013131753.GB3139@free.fr>
	<20081013132336.GB19171@yoda.jdub.homelinux.org>
Message-ID: <20081013135533.GE3139@free.fr>

On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
> 
> Ah.  And how is that different from CentOS?  At the time CentOS 5 was
> release, it also contained the latest "innovative" technologies.  So,
> what would be different about a Fedora LTS?

Because it is not possible to switch to centos from all fedora releases.
Right now you cannot switch from F8 to any centos, and even an updated F6
couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
Maybe not F9 if switching from an updated F9 to centos 6 is possible,
but will centos 6 be ready in 6 months?

--
Pat



From rc040203 at freenet.de  Mon Oct 13 13:56:22 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 15:56:22 +0200
Subject: cross-compilers...
In-Reply-To: <1223905615.4182.27.camel@ScaryMonster>
References: <1223900295.10624.100.camel@vain.rhgalway>
	<1223900810.6770.580.camel@macbook.infradead.org>
	<1223905615.4182.27.camel@ScaryMonster>
Message-ID: <1223906182.3029.101.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 14:46 +0100, Aidan Delaney wrote:
> On Mon, 2008-10-13 at 13:26 +0100, David Woodhouse wrote:
> > No, not yet. We still haven't really worked out how to deal with the
> > incestuous dependencies between libgcc and glibc (mostly that
> > libgcc_shared.so needs to be linked against libc).
> This is further complicated as some of us (I assist with spu
> cross-complilers) use newlib rather than glibc.
I guess you are aware that most of newlib/gcc can be built one-tree-style.

Ralf




From ralph+fedora at strg-alt-entf.org  Mon Oct 13 13:57:56 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Mon, 13 Oct 2008 15:57:56 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F34AE6.6060400@gmail.com>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<48F34AE6.6060400@gmail.com>
Message-ID: <20081013135756.GO13066@br-online.de>

Les Mikesell wrote:
> Then no one should be surprised at the migration to Ubuntu and other  
> distributions that have a more orderly transition from version to 
> version.

Which problem do you have with the transition from Fedora x to Fedora
x+1?

Ralph
-------------- 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/20081013/45d984bf/attachment.sig>

From a.j.delaney at brighton.ac.uk  Mon Oct 13 14:01:09 2008
From: a.j.delaney at brighton.ac.uk (Aidan Delaney)
Date: Mon, 13 Oct 2008 15:01:09 +0100
Subject: cross-compilers...
In-Reply-To: <1223906182.3029.101.camel@beck.corsepiu.local>
References: <1223900295.10624.100.camel@vain.rhgalway>
	<1223900810.6770.580.camel@macbook.infradead.org>
	<1223905615.4182.27.camel@ScaryMonster>
	<1223906182.3029.101.camel@beck.corsepiu.local>
Message-ID: <1223906469.4182.37.camel@ScaryMonster>

Ralf,
On Mon, 2008-10-13 at 15:56 +0200, Ralf Corsepius wrote:
> I guess you are aware that most of newlib/gcc can be built one-tree-style.
I'm aware of it, but have never managed to actually make it work.  The
process appears quite brittle to me.  I tried multiple versions of gcc
with multiple versions of newlib, no configuration built cleanly.
Therefore we went for the -bootstrap approach.  Though I don't profess
to be an expert on gcc.

--
Aidan Delaney



From jeff at ocjtech.us  Mon Oct 13 14:03:13 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 09:03:13 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <1223905136.3029.81.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
Message-ID: <935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>

On Mon, Oct 13, 2008 at 8:38 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>
> True, at the time RHEL5 was new, it had been more or less a rebuilt
> FC5/6 and switching between them had not been a major problem.
>
> Nowadays, it isn't anymore and even will be less when FC10 comes out.
>
> I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
> alternatives. They are kind of a flashback to yesterday's state-of-art.

Well, DUH!

Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
NEW FEATURES INTRODUCES NEW BUGS*
*YOU CAN'T HAVE YOUR CAKE AND EAT IT TOO*

Sorry for shouting, but all of these people demanding a "Fedora LTS"
don't seem to get this fundamental point.

I mean really, if RHEL5 switched from KDE3.5 to KDE4.0 I'd be
screaming bloody murder. Or even from BIND 9.3 to BIND 9.5.  Or
whatever.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From jeff at ocjtech.us  Mon Oct 13 14:06:58 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 09:06:58 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <20081013135533.GE3139@free.fr>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<20081013131123.GA19171@yoda.jdub.homelinux.org>
	<20081013131753.GB3139@free.fr>
	<20081013132336.GB19171@yoda.jdub.homelinux.org>
	<20081013135533.GE3139@free.fr>
Message-ID: <935ead450810130706w168d9071o30155af1676c1021@mail.gmail.com>

On Mon, Oct 13, 2008 at 8:55 AM, Patrice Dumas <pertusus at free.fr> wrote:
> On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
>>
>> Ah.  And how is that different from CentOS?  At the time CentOS 5 was
>> release, it also contained the latest "innovative" technologies.  So,
>> what would be different about a Fedora LTS?
>
> Because it is not possible to switch to centos from all fedora releases.
> Right now you cannot switch from F8 to any centos, and even an updated F6
> couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
> Maybe not F9 if switching from an updated F9 to centos 6 is possible,
> but will centos 6 be ready in 6 months?

If you have a system you are developing that needs to run on
RHEL/CentOS, you start development on RHEL/CentOS not on Fedora.  The
same goes for anything - if you were going to deploy on Ubuntu 8.04
(the most recent LTS version) you wouldn't start development on Ubuntu
8.10 would you?

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From braden at endoframe.com  Mon Oct 13 14:08:45 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Mon, 13 Oct 2008 10:08:45 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <loom.20081013T093227-545@post.gmane.org>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<200810112031.47265.opensource@till.name>
	<1223752713.13589.330.camel@hinge.endoframe.net>
	<200810111543.21186.sgrubb@redhat.com>
	<1223772015.13589.354.camel@hinge.endoframe.net>
	<loom.20081012T011207-253@post.gmane.org>
	<1223775310.13589.392.camel@hinge.endoframe.net>
	<loom.20081012T021105-415@post.gmane.org>
	<1223786046.13589.436.camel@hinge.endoframe.net>
	<loom.20081012T175241-931@post.gmane.org>
	<1223872903.8635.46.camel@hinge.endoframe.net>
	<loom.20081013T093227-545@post.gmane.org>
Message-ID: <1223906925.8635.65.camel@hinge.endoframe.net>

On Mon, 2008-10-13 at 09:35 +0000, Kevin Kofler wrote:
> Braden McDaniel <braden <at> endoframe.com> writes:
> > Do you also want to use doxygen to regenerate API documentation
> 
> Yes, definitely! In fact, the KDE packages already do this. And have to do it, 
> because KDE does not include Doxygen output in their tarballs (and rightfully 
> so).
> 
> > included in a tarball
> 
> You're incorrectly assuming it is shipped in the tarball in the first place.

No, I'm not.  I'm talking specifically about cases where it is.

> > despite the fact that a different doxygen version's subtle
> > stylesheet and markup changes could totally mangle the docs?
> 
> I've yet to see that happen. Maybe Doxygen simply cares more about backwards 
> compatibility than the autotools.

Then you haven't been looking very hard. Or you're just looking at
packages which use nearly all of the doxygen default settings.  Because
this sort of breakage happens quite frequently with doxygen.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From jakub at redhat.com  Mon Oct 13 14:10:01 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 13 Oct 2008 16:10:01 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223905937.4264.46.camel@perihelion.int.jonmasters.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
	<1223905937.4264.46.camel@perihelion.int.jonmasters.org>
Message-ID: <20081013141001.GE29476@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Oct 13, 2008 at 09:52:17AM -0400, Jon Masters wrote:
> On Wed, 2008-10-01 at 13:20 -0400, Kyle McMartin wrote:
> > On Wed, Oct 01, 2008 at 06:52:15PM +0200, Jakub Jelinek wrote:
> > > Given the recent 5sec boot efforts http://lwn.net/Articles/299483/
> > > and Mandriva follow-ups on that http://lwn.net/Articles/300873/,
> > > I thought I'd share my modprobe and MAKEDEV speedup patches with
> > > a wider community so folks can experiment with them, especially seeing
> > > Mandriva folks playing with turning modprobe into a daemon because of its
> > > slowness.
> 
> > Have you tested things on a big endian machine? In any case, this looks
> > really good. Hopefully Jon will apply this upstream soon so we can get
> > it in F10.
> 
> So I've added an alternative patch from Alan Jenkins to the current git
> and in rawhide today, also using a binary index (there's no version info
> embedded right now however that is about to be fixed in a later patch).
> I think my plan right now is to profile this against Jakub's patch and
> pick the winner. So there might be a few more changes this week :)

FYI, here is a tiny incremental fix for the patch I've posted earlier
- Mandriva folks reported that with my patch depmod was upset when run
on a tree with no modules at all.
--- module-init-tools-3.4.1/depmod.c	2008-10-01 17:32:14.000000000 +0200
+++ module-init-tools-3.4.1/depmod.c	2008-10-07 11:49:29.000000000 +0200
@@ -651,6 +651,8 @@
 			d = d->next;
 		}
 	}
+	if (strings->dir0.len == -1)
+		strings->dir0.len = 0;
 no_dir0:;
 	/* Assign the remaining up to 255 directory table
 	   entries, starting with most often used ones.  */


	Jakub



From rc040203 at freenet.de  Mon Oct 13 14:12:40 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 16:12:40 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
Message-ID: <1223907160.3029.109.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 09:03 -0500, Jeffrey Ollie wrote:
> On Mon, Oct 13, 2008 at 8:38 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >
> > True, at the time RHEL5 was new, it had been more or less a rebuilt
> > FC5/6 and switching between them had not been a major problem.
> >
> > Nowadays, it isn't anymore and even will be less when FC10 comes out.
> >
> > I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
> > alternatives. They are kind of a flashback to yesterday's state-of-art.
> 
> Well, DUH!
> 
> Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
> NEW FEATURES INTRODUCES NEW BUGS*
> *YOU CAN'T HAVE YOUR CAKE AND EAT IT TOO*
> 
> Sorry for shouting, but all of these people demanding a "Fedora LTS"
> don't seem to get this fundamental point.
WHAT? Guess why people are demanding for a *FEDORA LTS* and are not
demanding for RHEL5 or CENTOS.

Answer: RHEL5 is not a replacement for a lifetime extended current
Fedora.

Rationale, e.g. this:
> I mean really, if RHEL5 switched from KDE3.5 to KDE4.0 I'd be
> screaming bloody murder. Or even from BIND 9.3 to BIND 9.5.  Or
> whatever.

If Fedora and RHEL were synch'ed, things would be different.

Ralf




From jwboyer at gmail.com  Mon Oct 13 14:14:52 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 13 Oct 2008 10:14:52 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <1223907160.3029.109.camel@beck.corsepiu.local>
References: <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
Message-ID: <20081013141451.GB9793@yoda.jdub.homelinux.org>

On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
>Answer: RHEL5 is not a replacement for a lifetime extended current
>Fedora.

Extended for how long?  Fedora releases are supported for roughly
13 months (1 month after N+2 is released).  Actually longer if you
take into account the slips that inevitably hit during each release
cycle.

So, what _exactly_ are you asking for?

josh



From pertusus at free.fr  Mon Oct 13 14:16:23 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 16:16:23 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223904831.6770.597.camel@macbook.infradead.org>
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<1223904831.6770.597.camel@macbook.infradead.org>
Message-ID: <20081013141623.GF3139@free.fr>

On Mon, Oct 13, 2008 at 02:33:51PM +0100, David Woodhouse wrote:
> > 
> > Because it is not the same as you stress yourself. Centos is clearly not
> > the same than 'Fedora-based distribution which is supported for longer 
> > than a year'. It allows to use innovative technologies while not being
> > forced to update each year.
> 
> This is the part I have difficulty understanding. You want to use new
> and innovative technologies, but you don't want to update your nice
> stable system?
> 
> You're right -- you are offered updates, or you are offered stability,
> and there isn't much of a middle ground. But that's just reality.

There can be a change in time, 1 year of innovative technologies and 
then only critical updates, if fedora maintainers are volunteering to
keep on doing critical updates. And I even think that 6 months of
innovative technologies, 6 months with a slowdown in updates, only
important updates, on user demand and then only critical fixes as long
as a maintainer is doing them would even be better.

> > The last jump is not realistic in all cases. What should F6 user jump
> > to? Centos 5? Centos 6? And F8 users?
> 
> F6 is basically RHEL4/CentOS 4 for the most part, isn't it?

If I recall well, FC-5 could be upgraded to RHEL/EPEL, but not a fully
uptodate FC-6.

> And F8 would probably be closest to RHEL5/CentOS 5.

Not necessarily. F8 could already be way ahead from RHEL5/Centos5/EPEL5 
(although it is likely not to be the case in reality since EPEL, for 
instance is relatively new). The reverse is also possible, but if a
maintainer still pushed updates to F-8 until th eend, then F-8 should be
much newer than EL-5.

That being said I'd do what I can to help with having better update
paths, between fedora distros and between fedora and RHEL/Centos, but I
can't see what else I can do, at least for all the packages I 
(co-)maintain. But this doesn't remove the need for more than one year
support on a volunteer basis.

> So no new innovation then? And you'd want to do this for _every_
> six-monthly release of Fedora? Surely that's a whole boatload of effort
> you don't need? Why not just do it for every other release? Or, perhaps
> more usefully, every third release -- a new one about every 18 months?

That's up to the packagers. My hope is that if there is an argeement
than the above is possible, a SIG is constituted and people agree on
that. This may lead to different result depending on what packagers
wants to do.

> I see no fundamental reason why we should _forbid_ people from doing
> security updates for packages in EOL distributions, although I'm very
> wary of the expectations that it would create. If we ship
> official-looking updates for _some_ security bugs, na?ve users will
> quite reasonably expect that they'll be receiving updates for _all_
> serious security bugs, and our "You are unsupported; you need to upgrade
> before you get hacked" message will be compromised.

The updates may be pushed to another location than the usual updates
directory, such that it is not in the fedora name.

> I also think that with a niche market that small, between Fedora and
> CentOS, you are unlikely to get enough volunteers to keep it viable --
> isn't that what happened with Fedora Legacy last time? 

Repeating once again, this is quite different from legacy, because this
is the same set of rule, there is no heavy QA, only what is done
normally in fedora, so the entrance barrier is much lower. I personnally
considered helping legacy but is was so different from fedora and so
complicated that I gave up.

> That and/or ensuring that the packages you miss in CentOS are actually
> in EPEL.

I don't miss any package in EPEL, when I miss one I (co-)maintain it. 
Still I'd prefer to be able to suggest people asking me which distro to
choose to use fedora and not ubuntu (in case RHEL/Centos is not the right
distro for them), like I have to do today, because of the one year only
support.

--
Pat



From emmanuel.seyman at club-internet.fr  Mon Oct 13 14:18:10 2008
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Mon, 13 Oct 2008 16:18:10 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081013134149.GD3139@free.fr>
References: <48EF687B.9090407@odu.neva.ru> <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
Message-ID: <20081013141810.GA29152@orient.maison.lan>

* Patrice Dumas [13/10/2008 15:52] :
>
> Sounds like you don't want fedora packagers to volunteer for a longer 
> (support) time in fedora (not necessarily under the fedora name but in 
> the fedora infrastructure).

Oh, I don't mind that Fedora packagers start an LTS project.

I do get annoyed that they keep claiming that Fedora infrastructure is
necessary when, in fact, it isn't and I find it surprising that they
keep coming up with excuse after excuse for not actually doing anything
instead of just starting their project.

You're free to work on whatever project you want. If the board feels it
isn't appropriate for you to work under the Fedora brand, you can just
do it somewhere else. They, like I, lack the magic powers necessary to
stop you from doing whatever you feel like doing.

Emmanuel



From rc040203 at freenet.de  Mon Oct 13 14:19:22 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 16:19:22 +0200
Subject: cross-compilers...
In-Reply-To: <1223906469.4182.37.camel@ScaryMonster>
References: <1223900295.10624.100.camel@vain.rhgalway>
	<1223900810.6770.580.camel@macbook.infradead.org>
	<1223905615.4182.27.camel@ScaryMonster>
	<1223906182.3029.101.camel@beck.corsepiu.local>
	<1223906469.4182.37.camel@ScaryMonster>
Message-ID: <1223907562.3029.113.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 15:01 +0100, Aidan Delaney wrote:
> Ralf,
> On Mon, 2008-10-13 at 15:56 +0200, Ralf Corsepius wrote:
> > I guess you are aware that most of newlib/gcc can be built one-tree-style.
> I'm aware of it, but have never managed to actually make it work.  The
> process appears quite brittle to me.
I am doing so for many years for my RTEMS toolchains.

c.f. ftp.rtems.org://pub/rtems/linux/

Ralf





From pertusus at free.fr  Mon Oct 13 14:21:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 16:21:20 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013141451.GB9793@yoda.jdub.homelinux.org>
References: <20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
Message-ID: <20081013142120.GG3139@free.fr>

On Mon, Oct 13, 2008 at 10:14:52AM -0400, Josh Boyer wrote:
> On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
> >Answer: RHEL5 is not a replacement for a lifetime extended current
> >Fedora.
> 
> Extended for how long?  Fedora releases are supported for roughly
> 13 months (1 month after N+2 is released).  Actually longer if you
> take into account the slips that inevitably hit during each release
> cycle.
> 
> So, what _exactly_ are you asking for?

That infrastructure for EOLed Fedora is not shut down such that
maintainers can keep on maintaining packages, with an emphasis on
critical updates only, as long as they want. In my proposal I said no
more than 5 years (but could be 3 if you want I don't care), and as long
as it doesn't mean specific extra work for nonvolunteering people in the 
infrastructure team.

--
Pat



From rc040203 at freenet.de  Mon Oct 13 14:23:49 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 13 Oct 2008 16:23:49 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013141451.GB9793@yoda.jdub.homelinux.org>
References: <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
Message-ID: <1223907829.3029.118.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 10:14 -0400, Josh Boyer wrote:
> On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
> >Answer: RHEL5 is not a replacement for a lifetime extended current
> >Fedora.
> 
> Extended for how long?  Fedora releases are supported for roughly
> 13 months (1 month after N+2 is released).  Actually longer if you
> take into account the slips that inevitably hit during each release
> cycle.
> 
> So, what _exactly_ are you asking for?
Reread this thread, I am really getting tired of reiterating everything
over and over again.

In a nutshell:
* Lift acls from all discontinued Fedoras
* Keep the buildinfrastructure alive.
* Allow fedora maintainers to fix bugs in discontinued Fedoras.

Alternative: Officially extend Fedora life-times.

Alternative: Discontinue EPEL and replace it a full RHEL/CentOS
derivative as part of Fedora.

Ralf




From jonathan at jonmasters.org  Mon Oct 13 14:24:39 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Mon, 13 Oct 2008 10:24:39 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <20081013141001.GE29476@tyan-ft48-01.lab.bos.redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
	<1223905937.4264.46.camel@perihelion.int.jonmasters.org>
	<20081013141001.GE29476@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <1223907879.4264.51.camel@perihelion.int.jonmasters.org>

On Mon, 2008-10-13 at 16:10 +0200, Jakub Jelinek wrote:

> FYI, here is a tiny incremental fix for the patch I've posted earlier
> - Mandriva folks reported that with my patch depmod was upset when run
> on a tree with no modules at all.

:) Though if we ever manage to "demodularize for the win" to that point,
well, it'll be quite exciting!

I'm testing your 3.4.1 patch against today's 3.5 tree and will followup
with some results. Whichever performs best, I'll keep. Sorry I didn't
sort this out sooner, but it's time to move forward and get this sorted
out - and there are more trivial fixes I've got in mind. As of today's
rawhide there are also no longer any Fedora-specific patches left.

Jon.




From mike at miketc.net  Mon Oct 13 14:33:26 2008
From: mike at miketc.net (Mike Chambers)
Date: Mon, 13 Oct 2008 09:33:26 -0500
Subject: F10 blocker bugs
In-Reply-To: <48F32838.8070508@poolshark.org>
References: <48F32838.8070508@poolshark.org>
Message-ID: <1223908406.5778.9.camel@scrappy.miketc.net>

On Mon, 2008-10-13 at 12:51 +0200, Denis Leroy wrote:
> Sorry to interrupt with a technical Fedora-related potentially 
> constructive non-political post :-)
> 
> I submitted a bug that I think should be a F-10 release blocker 
> (466207: evolution calendar crash) as it renders a major feature of a 
> major application unusable.
> 
> I'm seeing a Fedora 10 blocker (440169), Fedora 10 Desktop blocker 
> (457945) and Fedora 10 kernel blocker (466414). Should I just use my own 
> judgement and add the blocker to my submitted bug ? or is that up to the 
> bug *owner* ?

Speaking on evolution and blocker, is anyone else experiencing evolution
and evolution-bogofilter not working together?  As in, getting checking
junk mail failed error messages?  If so, wouldn't that be a blocker as
well against evo?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From lesmikesell at gmail.com  Mon Oct 13 14:33:22 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 09:33:22 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130706w168d9071o30155af1676c1021@mail.gmail.com>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<1223900281.6770.573.camel@macbook.infradead.org>	<20081013122955.GF3087@free.fr>	<20081013131123.GA19171@yoda.jdub.homelinux.org>	<20081013131753.GB3139@free.fr>	<20081013132336.GB19171@yoda.jdub.homelinux.org>	<20081013135533.GE3139@free.fr>
	<935ead450810130706w168d9071o30155af1676c1021@mail.gmail.com>
Message-ID: <48F35C32.9050901@gmail.com>

Jeffrey Ollie wrote:
> On Mon, Oct 13, 2008 at 8:55 AM, Patrice Dumas <pertusus at free.fr> wrote:
>> On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
>>> Ah.  And how is that different from CentOS?  At the time CentOS 5 was
>>> release, it also contained the latest "innovative" technologies.  So,
>>> what would be different about a Fedora LTS?
>> Because it is not possible to switch to centos from all fedora releases.
>> Right now you cannot switch from F8 to any centos, and even an updated F6
>> couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
>> Maybe not F9 if switching from an updated F9 to centos 6 is possible,
>> but will centos 6 be ready in 6 months?
> 
> If you have a system you are developing that needs to run on
> RHEL/CentOS, you start development on RHEL/CentOS not on Fedora.

That doesn't make sense.  If you expect your system to run on RH6 that 
would mean you couldn't start development until after it is released.

> The
> same goes for anything - if you were going to deploy on Ubuntu 8.04
> (the most recent LTS version) you wouldn't start development on Ubuntu
> 8.10 would you?

You don't plan to release something new on the last version of a 
distribution, you plan for the next - so yes, Ubuntu 8.10 would be a 
suitable development platform and Ubuntu has so far had a reasonable 
update process to their next versions (but admittedly they haven't had a 
hard one like going from a 2.4 to a 2.6 kernel yet).

-- 
   Les Mikesell
     lesmikesell at gmail.com




From orion at cora.nwra.com  Mon Oct 13 14:35:41 2008
From: orion at cora.nwra.com (orion at cora.nwra.com)
Date: Mon, 13 Oct 2008 08:35:41 -0600 (MDT)
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T080514-964@post.gmane.org>
References: <20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu> <20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
	<1223865390.4250.32.camel@rlt60f8.laptop.redhat.com>
	<loom.20081013T080514-964@post.gmane.org>
Message-ID: <1576.71.208.51.222.1223908541.squirrel@www.cora.nwra.com>

> Obviously we wouldn't upgrade F8 to KDE 4!
>
> If anything, we'd upgrade it to newer 3.5.x releases, but even that is not
> necessary because KDE is among the few upstream projects who publish
> backported
> security patches for older releases, so we do not have to backport
> anything on
> our own, just apply the security fixes from KDE. We could stay on 3.5.10
> for
> years, and that also works for branches like 4.0, 4.1 or 4.2 which aren't
> as
> long-lived as 3.5.
>
>          Kevin Kofler

This is the issue I face at the moment.  I've felt that KDE4 is just not
ready for me to upgrade to at work, so I've stuck with F8.  This has
happened a couple time over Fedora history, although for different reason,
where I've had to skip a release or two (at least now skipping a release
is supported).  CentOS is really not an option (for laptops and desktop)
due to lack of support for very current hardware and I'm not aware of KDE
for CentOS.

But this is a specific issue with a specific set of releases.  I'm not
sure it warrants a general policy, with the possible exception of simply
(is this really simple?) keeping Fedora infrastructure open for updates
for F-8 past the scheduled EOL.

- Orion



From jwboyer at gmail.com  Mon Oct 13 14:35:18 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 13 Oct 2008 10:35:18 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <1223907829.3029.118.camel@beck.corsepiu.local>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
Message-ID: <20081013143518.GA28184@yoda.jdub.homelinux.org>

On Mon, Oct 13, 2008 at 04:23:49PM +0200, Ralf Corsepius wrote:
>On Mon, 2008-10-13 at 10:14 -0400, Josh Boyer wrote:
>> On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:
>> >Answer: RHEL5 is not a replacement for a lifetime extended current
>> >Fedora.
>> 
>> Extended for how long?  Fedora releases are supported for roughly
>> 13 months (1 month after N+2 is released).  Actually longer if you
>> take into account the slips that inevitably hit during each release
>> cycle.
>> 
>> So, what _exactly_ are you asking for?
>Reread this thread, I am really getting tired of reiterating everything
>over and over again.

I've read the thread.  Twice.

>In a nutshell:
>* Lift acls from all discontinued Fedoras
>* Keep the buildinfrastructure alive.
>* Allow fedora maintainers to fix bugs in discontinued Fedoras.

This has impacts on everyone though, not just the people that
want to keep an old branch active.  You have to worry about:

1) Upgrade paths
2) buildsystem inheritence
3) Storage (CVS, mirrors, koji, etc)
4) Bug reports (because they certainly will get reported to the
   overall package maintainers, not just the "LTS" maintainers)
5a) Depletion of test and development resources to current releases
 or
5b) Lack of participation

I'm not saying it's a bad idea, just needs a lot of thought.
There is a reason the Fedora Legacy project died.

>Alternative: Officially extend Fedora life-times.

This is not an alternative to the above.  This is where my
confusion comes in.  You say "extend Fedora life-times", but
you don't say to what.  Just keep this one out because it's
not really a viable solution.

>Alternative: Discontinue EPEL and replace it a full RHEL/CentOS
>derivative as part of Fedora.

I think if you remove the RHEL part of this, it makes some sense.
I doubt Red Hat is going to sign up for support of all the EPEL
packages, so they will never be part of RHEL proper.

josh



From jeff at ocjtech.us  Mon Oct 13 14:37:01 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 09:37:01 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <1223907160.3029.109.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
Message-ID: <935ead450810130737i4b88aea8t1da65b3110b1c3a@mail.gmail.com>

On Mon, Oct 13, 2008 at 9:12 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>
> WHAT? Guess why people are demanding for a *FEDORA LTS* and are not
> demanding for RHEL5 or CENTOS.
>
> Answer: RHEL5 is not a replacement for a lifetime extended current
> Fedora.

So basically you're peeved that Red Hat doesn't release a new RHEL
every six months?  I thought you said that you were worried about Red
Hat remaining profitable in the future?

Not even Canonical does that - they release a LTS version every two years.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From lesmikesell at gmail.com  Mon Oct 13 14:41:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 09:41:50 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<1223900281.6770.573.camel@macbook.infradead.org>	<48F3459B.8080704@leemhuis.info>	<1223903369.3029.58.camel@beck.corsepiu.local>	<48F34C21.3000404@leemhuis.info>	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
Message-ID: <48F35E2E.8010507@gmail.com>

Jeffrey Ollie wrote:
> On Mon, Oct 13, 2008 at 8:38 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> True, at the time RHEL5 was new, it had been more or less a rebuilt
>> FC5/6 and switching between them had not been a major problem.
>>
>> Nowadays, it isn't anymore and even will be less when FC10 comes out.
>>
>> I.e. to today's FC7 or FC8 users, RHEL5 or CentOS5 are not viable
>> alternatives. They are kind of a flashback to yesterday's state-of-art.
> 
> Well, DUH!
> 
> Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
> NEW FEATURES INTRODUCES NEW BUGS*

But that's generally an upstream issue. The bugs get fixed upstream but 
in general the new releases aren't included in RHEL/Centos updates even 
after the updated program becomes less buggy that the shipped version. 
(Firefox and OO being recent, rare exceptions).

> *YOU CAN'T HAVE YOUR CAKE AND EAT IT TOO*

And sometimes you don't get either.  Like a beta Dovecot shipped in RHEL 
  4 and not replaced by the stable upstream when the release version was 
available.

> Sorry for shouting, but all of these people demanding a "Fedora LTS"
> don't seem to get this fundamental point.

Your point applies only on a package-by-package basis, but RHEL applies 
it across the board (with the above-mentioned rare exceptions).

> I mean really, if RHEL5 switched from KDE3.5 to KDE4.0 I'd be
> screaming bloody murder.

Nobody ever claimed KDE 4.0 was stable, did they?

 > Or even from BIND 9.3 to BIND 9.5.  Or
> whatever.

Not sure about that, but if upstream says it is better, it probably is.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jeff at ocjtech.us  Mon Oct 13 14:45:28 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 09:45:28 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <48F35C32.9050901@gmail.com>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<20081013131123.GA19171@yoda.jdub.homelinux.org>
	<20081013131753.GB3139@free.fr>
	<20081013132336.GB19171@yoda.jdub.homelinux.org>
	<20081013135533.GE3139@free.fr>
	<935ead450810130706w168d9071o30155af1676c1021@mail.gmail.com>
	<48F35C32.9050901@gmail.com>
Message-ID: <935ead450810130745j1039ef9dt4ea38c6d2f3989f1@mail.gmail.com>

On Mon, Oct 13, 2008 at 9:33 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Jeffrey Ollie wrote:
>>
>> On Mon, Oct 13, 2008 at 8:55 AM, Patrice Dumas <pertusus at free.fr> wrote:
>>>
>>> On Mon, Oct 13, 2008 at 09:23:37AM -0400, Josh Boyer wrote:
>>>>
>>>> Ah.  And how is that different from CentOS?  At the time CentOS 5 was
>>>> release, it also contained the latest "innovative" technologies.  So,
>>>> what would be different about a Fedora LTS?
>>>
>>> Because it is not possible to switch to centos from all fedora releases.
>>> Right now you cannot switch from F8 to any centos, and even an updated F6
>>> couldn't switch to centos 5. So it would be interesting for F6, F7, F8.
>>> Maybe not F9 if switching from an updated F9 to centos 6 is possible,
>>> but will centos 6 be ready in 6 months?
>>
>> If you have a system you are developing that needs to run on
>> RHEL/CentOS, you start development on RHEL/CentOS not on Fedora.
>
> That doesn't make sense.  If you expect your system to run on RH6 that would
> mean you couldn't start development until after it is released.

Sure it makes sense.  With RHEL being supported for 7 years, I can
spend a year or so developing my service on RHEL X and have five or
six years before I have to upgrade to RHEL X+1 or X+2.

>> The
>> same goes for anything - if you were going to deploy on Ubuntu 8.04
>> (the most recent LTS version) you wouldn't start development on Ubuntu
>> 8.10 would you?
>
> You don't plan to release something new on the last version of a
> distribution, you plan for the next - so yes, Ubuntu 8.10 would be a
> suitable development platform and Ubuntu has so far had a reasonable update
> process to their next versions (but admittedly they haven't had a hard one
> like going from a 2.4 to a 2.6 kernel yet).

Well it really depends on what I was building.  If I was developing a
new desktop application what you say might make sense.  If I was
developing an e-commerce web site you'd be nuts to do that.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From caolanm at redhat.com  Mon Oct 13 14:52:36 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Mon, 13 Oct 2008 15:52:36 +0100
Subject: OpenOffice and go-oo
In-Reply-To: <385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
Message-ID: <1223909556.10624.131.camel@vain.rhgalway>

On Mon, 2008-10-13 at 16:37 +0300, Muayyad AlSadi wrote:
> > There is no opportunity for voting here.
> I did not meant it literary
> 
> > As I said, we apply the gstreamer set of patches.
> I was talking about video functionality

Yeah, me too. Insert->movie & sound should "just work" on Fedora,
F-9 as well as F-10, and all that goes through the gstreamer stuff.It
was just a mention that some extra sound stuff also goes through
gstreamer (play button in the file dialog when browsing sound files,
etc)

> > Both go-ooo.org and vanilla can be configured using --without-java
> 
> there is a difference between disabling java completely
>  (--without-java) in vanilla ooo and not relying on it in ooo-core and
>  moving it away to less frequently needed parts

That may be so, but its unrelated to a go-ooo vs vanilla comparison.

> in the first case you will lost most of functionality and that
> functionality can't be installed later
> but in the second case (having java but no dependence on it for
> ooo-core) and extra package can introduce that functionality late

But rpm doesn't have any "Suggested" sort of feature, and I don't think
it makes sense to just chop Requires: and leave functional menus
dangling for need of user-intervention to install something else.
Leaving help-search non-functional and certain menus useless unless the
user has extra knowledge to install the missing requires manually to
make them work is too hacky.

I've no problem with doing things the right way though. For example in
F-9 we required bsh because there is a beanshell scripting engine in OOo
(got only knows why, but...). Here for F-10 that I re-packaged it as a
standalone openoffice.org-beanshell extension, did the right work to
only see the macros->beanshell entries when beanshell is installed, etc.
all of which removed the bsh require in core. That sort of thing is
fine, so for e.g. the lucene if someone wants to do the work to rewrite
(like I did for the an older help system to move it from some java
solution to libxml/libxslt) it to use some functioning non-java solution
they that'd be fine. And for the saxon one, if someone tweaked things so
that the menus that refer to xslt features are only enabled/appear when
saxon is available then that'd be acceptable too, especially for a
fairly power-user feature like "write your own xslt transforms".

C.



From lesmikesell at gmail.com  Mon Oct 13 14:52:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 09:52:42 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <20081013135756.GO13066@br-online.de>
References: <20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>	<loom.20081012T230422-741@post.gmane.org>	<48F288A3.8000601@shmuelhome.mine.nu>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>	<loom.20081013T075922-165@post.gmane.org>	<48F34AE6.6060400@gmail.com>
	<20081013135756.GO13066@br-online.de>
Message-ID: <48F360BA.7080806@gmail.com>

Ralph Angenendt wrote:
> Les Mikesell wrote:
>> Then no one should be surprised at the migration to Ubuntu and other  
>> distributions that have a more orderly transition from version to 
>> version.
> 
> Which problem do you have with the transition from Fedora x to Fedora
> x+1?

Massive breakage...  Compatibility with the jpackage repo would be one 
example.  Keeping a mod_perl program working with apache/perl version 
changes would be another.  Database version changes.  Basically any API 
change anywhere is likely to break local programming as well as 3rd 
party repo usability, and Fedora changes wildly between versions.  But 
more to the point, no version of Fedora is  suitable for production use. 
  For example, long after a stable, reliable kernel was available in 
RHEL5 and Centos, FC6 shipped an update kernel that crashed on a variety 
of scsi controllers.  The nature of the project is just such that 
sufficient QA is never going to happen.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From tibbs at math.uh.edu  Mon Oct 13 14:53:34 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 13 Oct 2008 09:53:34 -0500
Subject: Package review backlog.
In-Reply-To: <1223839688.18044.6.camel@wicktop.localdomain>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com>
	<1223731515.3923.23.camel@wicktop.localdomain>
	<48F0B5C4.6020702@ioa.s.u-tokyo.ac.jp>
	<1223737587.3923.29.camel@wicktop.localdomain>
	<ufaprm6cj13.fsf@epithumia.math.uh.edu>
	<1223839688.18044.6.camel@wicktop.localdomain>
Message-ID: <ufa7i8cczrl.fsf@epithumia.math.uh.edu>

>>>>> "CW" == Christoph Wickert <christoph.wickert at googlemail.com> writes:

CW> ~390 out of ~1190. I would not call one third a very small number
CW> ;)

I count 13.

I think you confuse something.  It is not possible to set a bug back
to the NEW state, so any ticket which ever became ASSIGNED stays that
way, even if it is not assigned to anyone.  So any ticket in the
ASSIGNED state which is assigned to (Nobody) is up for review.

 - J<



From pertusus at free.fr  Mon Oct 13 14:54:29 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 16:54:29 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013143518.GA28184@yoda.jdub.homelinux.org>
References: <1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
Message-ID: <20081013145429.GJ3139@free.fr>

On Mon, Oct 13, 2008 at 10:35:18AM -0400, Josh Boyer wrote:
> 
> This has impacts on everyone though, not just the people that
> want to keep an old branch active.  You have to worry about:
> 
> 1) Upgrade paths

No more than in fedora releases.

> 2) buildsystem inheritence

That seems like an interesting issue...  Could you be a bit more 
specific?

> 3) Storage (CVS, mirrors, koji, etc)

CVS is not really an issue, we leave old branches already currently.
Others may be problematic. How many updates do we keep in the download
server? Is it only one version or more? If there is only one version,
then there is no problem, in my opinion. For koji, I know that some
builds are already deleted, maybe for LTS we could keep builds around
for some months and delete all except the last one?

> 4) Bug reports (because they certainly will get reported to the
>    overall package maintainers, not just the "LTS" maintainers)

I see 2 phases. In the first phase we consider that EOL product aren't
maintained anymore, that is we respond to those bug reports in the same
way than we respond to bug reports about EOL products today. If there is
enough interest in the project, then we mandate LTS maintainers to be in
watchbugzilla and we find a way to advertise which packages are still
maintained. The most simple would be mass orphaning packages such that a
maintainer has to put himself in the fedora db for a package for that
package to be considered to be still maintained.

> 5a) Depletion of test and development resources to current releases

I don't think we should mandate how fedora contributors allocate their
time.

>  or
> 5b) Lack of participation

Time will tell.

> I'm not saying it's a bad idea, just needs a lot of thought.
> There is a reason the Fedora Legacy project died.

Once again it is very different now. Legacy had different
infrastructure, different rules, and overall was more complicated. And
there has been improvements in the fedora infrastructure since then.

--
Pat



From tibbs at math.uh.edu  Mon Oct 13 14:55:11 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 13 Oct 2008 09:55:11 -0500
Subject: Package review backlog.
In-Reply-To: <48F2F812.50407@seketeli.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<loom.20081008T094231-77@post.gmane.org>
	<20081008151204.GA5629@nostromo.devel.redhat.com>
	<loom.20081008T153926-770@post.gmane.org>
	<20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com> <48F07615.7060306@hhs.nl>
	<48F2F812.50407@seketeli.org>
Message-ID: <ufa3aj0czow.fsf@epithumia.math.uh.edu>

>>>>> "DS" == Dodji Seketeli <dodji at seketeli.org> writes:

DS> Yeah, but what about the 100 people who are not contributors yet,
DS> and who are willing to get in ? What can be done to speed up the
DS> reviews of their packages in practice ?

Lowering the barriers to sponsorship by not giving new contributors
access to every package has now been done; sponsorship should become
at least a bit easier now.

 - J<



From kwizart at gmail.com  Mon Oct 13 14:28:24 2008
From: kwizart at gmail.com (Nicolas Chauvet (kwizart))
Date: Mon, 13 Oct 2008 16:28:24 +0200
Subject: yafray "renamed" to yafaray - pick it ?
Message-ID: <48F35B08.3040600@gmail.com>

Hi!

As announced at http://www.yafray.org, yafaray replaces YafRay 0.0.9.
Thus I'm thinking of submitting yafray as dead.package in Rawhide. (1)

On the other side, I'm not going to work on yafaray soon. So, if anyone
wants to start working on it, feel free.

Nicolas (kwizart)


(1), There is no reason why yafray should stop working with the current
blender releases. But there might be a problem when theses two are
installed together. (until now, blender either dlopen library or call
binary, from yafray).
This has to be discussed in the yafaray review. So, please cc'ed me on
the review, along with your favorite reviewer. (or ask me as a reviewer).




From pertusus at free.fr  Mon Oct 13 15:05:08 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 17:05:08 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013145429.GJ3139@free.fr>
References: <48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
	<20081013145429.GJ3139@free.fr>
Message-ID: <20081013150508.GK3139@free.fr>

On Mon, Oct 13, 2008 at 04:54:29PM +0200, Patrice Dumas wrote:
> 
> CVS is not really an issue, we leave old branches already currently.
> Others may be problematic. How many updates do we keep in the download
> server? Is it only one version or more? If there is only one version,
> then there is no problem, in my opinion.

Thinking about it a bit more, there can be a problem. Indeed, even
though update directories shouldn't grow much, each 'supported' LTS
release will take a big space on mirrors (6G or something like that?).
So I think that the maximal number of EOL braches that are kept open
should be constrained by the available place. For example, 3 more years
would roughly mean 3*2 more updates directories. It could be too much, 
or not, depending on what is acceptable on fedora download servers.

In that case skipping some of the fedora release, like doing the LTS
stuff only each year may help.

--
Pat



From jeff at ocjtech.us  Mon Oct 13 15:16:11 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 10:16:11 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <48F35E2E.8010507@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<48F35E2E.8010507@gmail.com>
Message-ID: <935ead450810130816q521271c9q49bfa9e83825ee61@mail.gmail.com>

On Mon, Oct 13, 2008 at 9:41 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Jeffrey Ollie wrote:
>>
>> Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
>> NEW FEATURES INTRODUCES NEW BUGS*
>
> But that's generally an upstream issue. The bugs get fixed upstream but in
> general the new releases aren't included in RHEL/Centos updates even after
> the updated program becomes less buggy that the shipped version. (Firefox
> and OO being recent, rare exceptions).

Unfortunately, upstream developers don't always release bugfix-only
releases.  Many times they introduce new features or change the
behavior of old features.  Introducing new features means that there
are probably new bugs which is bad for distributions like RHEL/CentOS.
 Changing the behavior of old features is just as bad for RHEL/CentOS
because people are building systems that expect the old behavior.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From nicolas.mailhot at laposte.net  Mon Oct 13 15:22:54 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 13 Oct 2008 17:22:54 +0200 (CEST)
Subject: reviving Fedora Legacy
In-Reply-To: <48F360BA.7080806@gmail.com>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org> <48F34AE6.6060400@gmail.com>
	<20081013135756.GO13066@br-online.de> <48F360BA.7080806@gmail.com>
Message-ID: <affaa1bfa86ed44a0a60a38e488537ea.squirrel@arekh.dyndns.org>



Le Lun 13 octobre 2008 16:52, Les Mikesell a ?crit :
>
> Ralph Angenendt wrote:
>> Les Mikesell wrote:
>>> Then no one should be surprised at the migration to Ubuntu and
>>> other
>>> distributions that have a more orderly transition from version to
>>> version.
>>
>> Which problem do you have with the transition from Fedora x to
>> Fedora
>> x+1?
>
> Massive breakage...  Compatibility with the jpackage repo would be one
> example.

This is not a Fedora LTS (or even jpackage) problem, it's an artifact
of the historical OS/java split produced by closed JVMs.

It will heal itself as the jvm is internalised and the jpp <-> fedora
flow gets more dynamic.

-- 
Nicolas Mailhot



From arjan at infradead.org  Mon Oct 13 15:26:22 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Mon, 13 Oct 2008 11:26:22 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081013150508.GK3139@free.fr>
References: <48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
	<20081013145429.GJ3139@free.fr> <20081013150508.GK3139@free.fr>
Message-ID: <20081013112622.77fbf8ea@infradead.org>

On Mon, 13 Oct 2008 17:05:08 +0200
Patrice Dumas <pertusus at free.fr> wrote:

> In that case skipping some of the fedora release, like doing the LTS
> stuff only each year may help.


before solving the "how many" problem...
lets be realistic

1) Making every release LTS is not feasible, there's just not going to
be enough manpower for that (history has shown that) for now at least.
2) I don't think users would even really demand such a beast
3) The volunteer base is a bit thin; current fedora volunteers tend to
work on the latest version (or maybe two). In fact, so do many users.

I would suggest focusing on first getting ONE such LTS release going.
Figure out a plan on how to get out of it first (communication wise
etc) in case interest isn't what you expect, and how to monitor the
health. With that I suspect the fedora leadership will be happy to
endorse it happily.

Do one. Get that working. Don't even think about multiple until you
have gotten one down. You'll learn so much that it's not worth planning
beyond that.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From jkeating at redhat.com  Mon Oct 13 15:29:11 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 08:29:11 -0700
Subject: Regarding install options
In-Reply-To: <1223882953.3564.1509.camel@beck.corsepiu.local>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
Message-ID: <1223911751.3327.15.camel@luminos.localdomain>

On Mon, 2008-10-13 at 09:29 +0200, Ralf Corsepius wrote:
> You are nit-picking at words.

As was everybody who ever complained about the "minimal" install option
we had.

> 
> Though a Fedora installation with yum + rpm isn't "truely minimal", it's
> the minimal install to keep an installation usable/maintainable.

Which is useful to some, too fat for others.

> And yes, the fact yum pulls in python is a real problem on small
> systems. Even worse are the system-config-* tools, most of which pull in
> many more packages and don't even work without X.
> 
> >   Congratulations you've just walked
> > into a decade + argument.
> I don't see this.

Probably because you haven't been on the front line, taking the bug
reports, talking to users at events, trying to tweak the targets to
match expectation and continually failing because there is no singular
expectation.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/98c91da6/attachment.sig>

From jcm at redhat.com  Mon Oct 13 15:31:22 2008
From: jcm at redhat.com (Jon Masters)
Date: Mon, 13 Oct 2008 11:31:22 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223907879.4264.51.camel@perihelion.int.jonmasters.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
	<1223905937.4264.46.camel@perihelion.int.jonmasters.org>
	<20081013141001.GE29476@tyan-ft48-01.lab.bos.redhat.com>
	<1223907879.4264.51.camel@perihelion.int.jonmasters.org>
Message-ID: <1223911882.4264.65.camel@perihelion.int.jonmasters.org>

On Mon, 2008-10-13 at 10:24 -0400, Jon Masters wrote:
> On Mon, 2008-10-13 at 16:10 +0200, Jakub Jelinek wrote:
> 
> > FYI, here is a tiny incremental fix for the patch I've posted earlier
> > - Mandriva folks reported that with my patch depmod was upset when run
> > on a tree with no modules at all.
> 
> :) Though if we ever manage to "demodularize for the win" to that point,
> well, it'll be quite exciting!
> 
> I'm testing your 3.4.1 patch against today's 3.5 tree and will followup
> with some results. Whichever performs best, I'll keep. Sorry I didn't
> sort this out sooner, but it's time to move forward and get this sorted
> out - and there are more trivial fixes I've got in mind. As of today's
> rawhide there are also no longer any Fedora-specific patches left.

In one test, I ran modprobe about 8000 times on a desktop.

older modprobe:       190.03user 25.19system 3:55.54elapsed 91%CPU
upstream modprobe:      8.65user 19.69system 0:31.08elapsed 91%CPU
Jakob's modprobe:       6.71user 18.05system 0:27.01elapsed 91%CPU

The latter two vie a little between each other, but basically are
comparable. So for now, I'll keep upstream as it is and do some more
testing/write some scripts. Then I'll do some migration to unlocked
non-threaded functions and pull in other parts of Jakob's patch. I'm
thinking there are actually other places to focus on now - more
profiling will be called for and I'll push some more updates.

Older modprobe is 3.4.1, upstream is 3.5 (radix trie implementation),
Jakob's patch uses a hashtable/bucket mechanism.

Jon.




From jkeating at redhat.com  Mon Oct 13 15:33:56 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 08:33:56 -0700
Subject: Fedora 8 and 9 updates re-enabled
In-Reply-To: <200810121813.36870.opensource@till.name>
References: <1221028475.3388.132.camel@luminos.localdomain>
	<200810121813.36870.opensource@till.name>
Message-ID: <1223912036.3327.16.camel@luminos.localdomain>

On Sun, 2008-10-12 at 18:13 +0200, Till Maas wrote:
> Is there a schedule when the Everything repo will be resigned with the new 
> key, so that the old gpg key can be purged? 

I've been working on this over the past week or two.  Hopefully within
the next week we'll have the new stuff staged.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/4d05bd1b/attachment.sig>

From lesmikesell at gmail.com  Mon Oct 13 15:46:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 10:46:34 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <affaa1bfa86ed44a0a60a38e488537ea.squirrel@arekh.dyndns.org>
References: <20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>	<loom.20081012T230422-741@post.gmane.org>	<48F288A3.8000601@shmuelhome.mine.nu>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>	<loom.20081013T075922-165@post.gmane.org>
	<48F34AE6.6060400@gmail.com>	<20081013135756.GO13066@br-online.de>
	<48F360BA.7080806@gmail.com>
	<affaa1bfa86ed44a0a60a38e488537ea.squirrel@arekh.dyndns.org>
Message-ID: <48F36D5A.404@gmail.com>

Nicolas Mailhot wrote:
> 
>>>> Then no one should be surprised at the migration to Ubuntu and
>>>> other
>>>> distributions that have a more orderly transition from version to
>>>> version.
>>> Which problem do you have with the transition from Fedora x to
>>> Fedora
>>> x+1?
>> Massive breakage...  Compatibility with the jpackage repo would be one
>> example.
> 
> This is not a Fedora LTS (or even jpackage) problem,

Changing APIs and thus becoming incompatible with everything that 
depended on them is very much a Fedora problem - or perhaps better 
stated as a Fedora user's problem.

> it's an artifact
> of the historical OS/java split produced by closed JVMs.

No, it is an artifact of wildly changing APIs.  That was just an obvious 
example.  The same applies to apache/perl/python and just about every 
other package versioning.

> It will heal itself as the jvm is internalised and the jpp <-> fedora
> flow gets more dynamic.

I'm nowhere near that optimistic.  I expect more of the usual fedora 
syndrome where everything must become part of the internal repository 
and carefully tweaked to match today's weirdness to be expected to work 
at all, instead of working to match and maintain standard APIs and 
compatibility with 3rd party work.   And then between fedora releases, 
the internal weirdness makes wild jumps so even your own development 
work that depended on earlier APIs has to start over.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From mw_triad at users.sourceforge.net  Mon Oct 13 15:47:55 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 13 Oct 2008 10:47:55 -0500
Subject: Arabic and Hebrew on the console
In-Reply-To: <48F33E57.2060903@odu.neva.ru>
References: <20081009180319.GA25325@nostromo.devel.redhat.com>	<48EF60B2.4040708@odu.neva.ru>	<gco7lb$2pr$1@ger.gmane.org>
	<48F33E57.2060903@odu.neva.ru>
Message-ID: <gcvqjc$f0b$1@ger.gmane.org>

Dmitry Butskoy wrote:
> Besides that, people can use some hardware which do not support KMS 
> (either too old, or too specific); people can use too old systems, etc. 
> Hence it is better to resolve this issue despite of the KMS feature.

Why not support VGA in KMS? That would cover nearly everything 
"reasonable" in terms of "old", and I wonder where you're getting 
hardware text mode if you don't have VGA (unless you're already using 
something like KMS, but in that case there is no problem?).

Devices without /video/ (e.g. embedded) are presumably using a serial 
console already, in which case it's simply a matter of plugging in a 
decent VT emulator, so we already don't have issues from hardware fonts.

In fact, that's a simple way to phrase it, as the question was about 
hardware fonts: what (besides CGA/EGA and even older) uses hardware 
fonts that does NOT support VGA? If the answer is "nothing", well, just 
support VGA in KMS and use the software text engine in 640x480 mode. 
That shouldn't be any different from using it in higher resolutions.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer



From lesmikesell at gmail.com  Mon Oct 13 15:55:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 10:55:05 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130816q521271c9q49bfa9e83825ee61@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<1223900281.6770.573.camel@macbook.infradead.org>	<48F3459B.8080704@leemhuis.info>	<1223903369.3029.58.camel@beck.corsepiu.local>	<48F34C21.3000404@leemhuis.info>	<1223905136.3029.81.camel@beck.corsepiu.local>	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>	<48F35E2E.8010507@gmail.com>
	<935ead450810130816q521271c9q49bfa9e83825ee61@mail.gmail.com>
Message-ID: <48F36F59.70600@gmail.com>

Jeffrey Ollie wrote:
> 
>>> Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
>>> NEW FEATURES INTRODUCES NEW BUGS*
>> But that's generally an upstream issue. The bugs get fixed upstream but in
>> general the new releases aren't included in RHEL/Centos updates even after
>> the updated program becomes less buggy that the shipped version. (Firefox
>> and OO being recent, rare exceptions).
> 
> Unfortunately, upstream developers don't always release bugfix-only
> releases.  Many times they introduce new features or change the
> behavior of old features.

Agreed - sometimes they do things as bizarre as dropping a feature, then 
putting it back with a different name, like "yum --download-only" vs. 
much later an optional module invoked as "yum --downloadonly".

> Introducing new features means that there
> are probably new bugs which is bad for distributions like RHEL/CentOS.

But again, that's a package by package issue as to whether upstream is 
improved or not.  And mostly RHEL/Centos treats the whole distro the same.

>  Changing the behavior of old features is just as bad for RHEL/CentOS
> because people are building systems that expect the old behavior.

Yes, ideally there would be an optional, alternate repo for 
behavior-changing updates.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From benny+usenet at amorsen.dk  Mon Oct 13 15:56:26 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Mon, 13 Oct 2008 17:56:26 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T013947-433@post.gmane.org> (Kevin Kofler's message
	of "Mon\, 13 Oct 2008 01\:40\:54 +0000 \(UTC\)")
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
Message-ID: <m3tzbglc9h.fsf@ursa.amorsen.dk>

Kevin Kofler <kevin.kofler at chello.at> writes:

> Why would we want to? Just let things going as long as there is at least one 
> maintainer committing something. Even if not all security issues get fixed, 
> it's better than if none gets fixed.

I'd love to see this. It could e.g. keep a service in the process of
being decommissioned alive a little longer without having to do the
usual upgrade.

It wouldn't be good for anything too serious, but if noone steps up
for a necessary security patch, I could do it myself and then get to
share the result with everyone else on that obsolete release. I would
have to test all updates locally, but for services on the way out that
is generally easier than testing the full upgrade.

If it breaks something for someone, well, they should be more careful
which updates they apply, especially once official support is gone. It
might even encourage an upgrade and perhaps keep one box from being
compromised.


/Benny



From lesmikesell at gmail.com  Mon Oct 13 16:00:09 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 11:00:09 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130745j1039ef9dt4ea38c6d2f3989f1@mail.gmail.com>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<1223900281.6770.573.camel@macbook.infradead.org>	<20081013122955.GF3087@free.fr>	<20081013131123.GA19171@yoda.jdub.homelinux.org>	<20081013131753.GB3139@free.fr>	<20081013132336.GB19171@yoda.jdub.homelinux.org>	<20081013135533.GE3139@free.fr>	<935ead450810130706w168d9071o30155af1676c1021@mail.gmail.com>	<48F35C32.9050901@gmail.com>
	<935ead450810130745j1039ef9dt4ea38c6d2f3989f1@mail.gmail.com>
Message-ID: <48F37089.5070001@gmail.com>

Jeffrey Ollie wrote:
> 
> Well it really depends on what I was building.  If I was developing a
> new desktop application what you say might make sense.  If I was
> developing an e-commerce web site you'd be nuts to do that.

But then you'd probably use java to isolate yourself as much as possible 
from silly API changes in OS and distributions...  And fedora hasn't 
been a great place to use java.

-- 
   Les Mikesell
     lesmikesell at gmail.com





From jeff at ocjtech.us  Mon Oct 13 16:06:48 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 11:06:48 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <48F37089.5070001@gmail.com>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081013122955.GF3087@free.fr>
	<20081013131123.GA19171@yoda.jdub.homelinux.org>
	<20081013131753.GB3139@free.fr>
	<20081013132336.GB19171@yoda.jdub.homelinux.org>
	<20081013135533.GE3139@free.fr>
	<935ead450810130706w168d9071o30155af1676c1021@mail.gmail.com>
	<48F35C32.9050901@gmail.com>
	<935ead450810130745j1039ef9dt4ea38c6d2f3989f1@mail.gmail.com>
	<48F37089.5070001@gmail.com>
Message-ID: <935ead450810130906ofd95ad4g3439df9ea99e690e@mail.gmail.com>

On Mon, Oct 13, 2008 at 11:00 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Jeffrey Ollie wrote:
>>
>> Well it really depends on what I was building.  If I was developing a
>> new desktop application what you say might make sense.  If I was
>> developing an e-commerce web site you'd be nuts to do that.
>
> But then you'd probably use java to isolate yourself as much as possible
> from silly API changes in OS and distributions...  And fedora hasn't been a
> great place to use java.

I'm not a Java developer (I've written a few "Hello World" type things
but nothing more complex than that) but from what I've seen from
deploying a few Java-based systems is that while the "core" Java API
may be stable, "real-world" Java systems have dependencies on things
like Tomcat/Apache or other similar systems and are highly dependent
on particular versions of those apps and associated libraries.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From pertusus at free.fr  Mon Oct 13 16:13:16 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 18:13:16 +0200
Subject: Regarding install options
In-Reply-To: <1223911751.3327.15.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
Message-ID: <20081013161316.GL3139@free.fr>

On Mon, Oct 13, 2008 at 08:29:11AM -0700, Jesse Keating wrote:
> 
> Probably because you haven't been on the front line, taking the bug
> reports, talking to users at events, trying to tweak the targets to
> match expectation and continually failing because there is no singular
> expectation.

Indeed, so just come with what you prefer. With otr without python 
it will be better than what is now.

--
Pat



From jkeating at redhat.com  Mon Oct 13 16:23:42 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 09:23:42 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <1223907829.3029.118.camel@beck.corsepiu.local>
References: <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
Message-ID: <1223915022.3327.24.camel@luminos.localdomain>

On Mon, 2008-10-13 at 16:23 +0200, Ralf Corsepius wrote:
> 
> In a nutshell:
> * Lift acls from all discontinued Fedoras
> * Keep the buildinfrastructure alive.
> * Allow fedora maintainers to fix bugs in discontinued Fedoras.

I think the only way I'd vote for this to happen is if it was setup in
thusly:

At the point of official EOL (IE the 13~ month mark) PackageKit is
notified in such a way so that in it's attempts to fetch new updates
from existing repos it warns users about the EOL and explains to them
the situation.  It can offer a few different options:

A) Upgrade (via pre-upgrade) to a newer version of Fedora.

B) Configure itself for a new set of repos that are the product of
post-eol updates by maintainers, giving clear information to the user
that there is no set lifespan, no set package list, no set expectation,
no nothing.

C) Do nothing.

Users of EOL releases would have to make a conscious choice to jump on
the post-eol update world, so that they are given a chance to understand
what it is they would be consuming.  I would not want people to wind up
there without any prior knowledge and properly set expectation of what
they are getting, and I would want them to be urged to upgrade if at all
possible.

Furthermore I would want to prevent maintainers who do not wish to
participate in the post-EOL update world from getting bugzilla reports
by people using their software in EOL releases.

Finally, I would prefer if we had our automated signing system in place
prior to this, but I'm not going to make this a blocker.

Maintainer teams of various systems such as Bodhi and pkgdb and koji and
mirrormanager et al would also need to give their explicit approval and
add any further adjustments to any such plan.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/99247691/attachment.sig>

From jspaleta at gmail.com  Mon Oct 13 16:25:38 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 13 Oct 2008 08:25:38 -0800
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T013947-433@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
Message-ID: <604aa7910810130925t649ebf01vff54dca734d748c4@mail.gmail.com>

On Sun, Oct 12, 2008 at 5:40 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Why would we want to? Just let things going as long as there is at least one
> maintainer committing something. Even if not all security issues get fixed,
> it's better than if none gets fixed.


Ha!  Keeping a branch open because one maintainer interested in
something.  That's not a distribution. That's a personal respository.

-jef



From jkeating at redhat.com  Mon Oct 13 16:25:42 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 09:25:42 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <20081013112622.77fbf8ea@infradead.org>
References: <48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
	<20081013145429.GJ3139@free.fr> <20081013150508.GK3139@free.fr>
	<20081013112622.77fbf8ea@infradead.org>
Message-ID: <1223915142.3327.25.camel@luminos.localdomain>

On Mon, 2008-10-13 at 11:26 -0400, Arjan van de Ven wrote:
> 1) Making every release LTS is not feasible, there's just not going to
> be enough manpower for that (history has shown that) for now at least.
> 2) I don't think users would even really demand such a beast

The problem you run into is that everybody wants a /different/ one to be
the LTS release, that is the one they're currently stuck on.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/c6cf94f2/attachment.sig>

From hughsient at gmail.com  Mon Oct 13 16:28:35 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 13 Oct 2008 17:28:35 +0100
Subject: transifex and PackageKit
Message-ID: <1223915316.3551.27.camel@hughsie-laptop>

Today I released 0.3.7 and pushed it to rawhide. In a couple of weeks
time they'll be a bugfix 0.3.8 release that we'll see in F10 and F9.

Before that time, I would like the translations for PackageKit to be
updated -- updated translations are very important for the F10 release
quality and also for the F9 backport.

You can see the current stats here:

http://translate.fedoraproject.org/module/packagekit#master

Thanks, and keep rocking,

Richard.




From jkeating at redhat.com  Mon Oct 13 16:40:09 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 09:40:09 -0700
Subject: Regarding install options
In-Reply-To: <20081013161316.GL3139@free.fr>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
Message-ID: <1223916009.3327.28.camel@luminos.localdomain>

On Mon, 2008-10-13 at 18:13 +0200, Patrice Dumas wrote:
> On Mon, Oct 13, 2008 at 08:29:11AM -0700, Jesse Keating wrote:
> > 
> > Probably because you haven't been on the front line, taking the bug
> > reports, talking to users at events, trying to tweak the targets to
> > match expectation and continually failing because there is no singular
> > expectation.
> 
> Indeed, so just come with what you prefer. With otr without python 
> it will be better than what is now.

Not sure what you mean by "otr".

When I raised a bit of objection over adding 'yum' to the @core list,
the responding argument was that if you're getting so specific in your
'minimal' install, you're either doing a chroot type install or can
modify a groupdata set to strip it out for your install, whereas for all
the other cases it's better to have it there.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/f32bd56c/attachment.sig>

From pertusus at free.fr  Mon Oct 13 16:40:16 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 18:40:16 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013112622.77fbf8ea@infradead.org>
References: <48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
	<20081013145429.GJ3139@free.fr> <20081013150508.GK3139@free.fr>
	<20081013112622.77fbf8ea@infradead.org>
Message-ID: <20081013164016.GM3139@free.fr>

On Mon, Oct 13, 2008 at 11:26:22AM -0400, Arjan van de Ven wrote:
> On Mon, 13 Oct 2008 17:05:08 +0200
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > In that case skipping some of the fedora release, like doing the LTS
> > stuff only each year may help.
> 
> 
> before solving the "how many" problem...
> lets be realistic

I agree, but the issue of space may be a show stopper for some, so
better think about it.

> 1) Making every release LTS is not feasible, there's just not going to
> be enough manpower for that (history has shown that) for now at least.

Agreed.

> 2) I don't think users would even really demand such a beast

I don't know in general, but I know that I stopped proposing people that
were not absolute power users to use fedora, even if they were fluent
enough because of this issue. So fedora lost at least 2 users. But they
were not users likely to contribute, so they don't weight that much.

> 3) The volunteer base is a bit thin; current fedora volunteers tend to
> work on the latest version (or maybe two). In fact, so do many users.

There are only 2 versions... But it is true I don't think there are that 
many packagers interested in LTS, for the user, I am not sure. But I
also think that the amount of work for the 2 first year is not high, no
updates, for most packages is right. There are indeed some big and
complex core packages that may be problematic, we'll see.

> I would suggest focusing on first getting ONE such LTS release going.
> Figure out a plan on how to get out of it first (communication wise
> etc) in case interest isn't what you expect, and how to monitor the
> health. With that I suspect the fedora leadership will be happy to
> endorse it happily.

My suggestion is first to communicate only to the packagers that they
can update the packages, look whether there are some that are updated,
especially those in @code and @base, and especially when there is a
knowledge that something is broken or a security issue, create a SIG if
it looks that there is support, discuss the details, see how many
participants, make the rules and only afterwards communicate something 
to the exterior.

> Do one. Get that working. Don't even think about multiple until you
> have gotten one down. You'll learn so much that it's not worth planning
> beyond that.

Indeed, maybe the best would be to start with F9 such that the
infrastructure doesn't have to be revived.

--
Pat



From jkeating at redhat.com  Mon Oct 13 16:41:09 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 09:41:09 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <48F36D5A.404@gmail.com>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org> <48F34AE6.6060400@gmail.com>
	<20081013135756.GO13066@br-online.de> <48F360BA.7080806@gmail.com>
	<affaa1bfa86ed44a0a60a38e488537ea.squirrel@arekh.dyndns.org>
	<48F36D5A.404@gmail.com>
Message-ID: <1223916069.3327.29.camel@luminos.localdomain>

On Mon, 2008-10-13 at 10:46 -0500, Les Mikesell wrote:
> 
> No, it is an artifact of wildly changing APIs.  That was just an obvious 
> example.  The same applies to apache/perl/python and just about every 
> other package versioning.

But upstream chanced those APIs, and isn't upstream always right?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/5b1d7037/attachment.sig>

From bob at fedoraunity.org  Sun Oct 12 12:50:30 2008
From: bob at fedoraunity.org (Robert 'Bob' Jensen)
Date: Sun, 12 Oct 2008 12:50:30 +0000 (UTC)
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130906ofd95ad4g3439df9ea99e690e@mail.gmail.com>
Message-ID: <5107448.3521223815830229.JavaMail.root@zimbra.cbccgroup.com>

Fedora Legacy is DEAD, maybe call it Fedora Zombie. Walking dead packages, Walking dead packagers from trying to keep up...

Robert 'Bob' Jensen



From wwoods at redhat.com  Mon Oct 13 16:44:58 2008
From: wwoods at redhat.com (Will Woods)
Date: Mon, 13 Oct 2008 12:44:58 -0400
Subject: F10 blocker bugs
In-Reply-To: <48F3511D.4070604@redhat.com>
References: <48F32838.8070508@poolshark.org> <48F350C6.10900@redhat.com>
	<48F3511D.4070604@redhat.com>
Message-ID: <1223916298.3082.6.camel@localhost.localdomain>

On Mon, 2008-10-13 at 06:46 -0700, John Poelstra wrote:
> John Poelstra said the following on 10/13/2008 06:44 AM Pacific Time:
> > Denis Leroy said the following on 10/13/2008 03:51 AM Pacific Time:
> >> Sorry to interrupt with a technical Fedora-related potentially 
> >> constructive non-political post :-)
> >>
> >> I submitted a bug that I think should be a F-10 release blocker 
> >> (466207: evolution calendar crash) as it renders a major feature of a 
> >> major application unusable.
> > 
> > According to our release criteria this wouldn't necessarily block the 
> > release: https://fedoraproject.org/wiki/QA/ReleaseCriteria
> 
> I correct myself.  Since it appears in a menu it MUST start and would be 
> a blocker.

Not quite. The bug doesn't say that Evolution *doesn't start under any
circumstances*,  just that it crashes if configured to use a Google
Calendar. Therefore this is *not* a release blocker. 

But I agree that it's important - this is a fairly common configuration
of one of our default apps. So I've added it to F10Target.

-w



From pertusus at free.fr  Mon Oct 13 16:47:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 18:47:15 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <604aa7910810130925t649ebf01vff54dca734d748c4@mail.gmail.com>
References: <20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<604aa7910810130925t649ebf01vff54dca734d748c4@mail.gmail.com>
Message-ID: <20081013164715.GO3139@free.fr>

On Mon, Oct 13, 2008 at 08:25:38AM -0800, Jeff Spaleta wrote:
> On Sun, Oct 12, 2008 at 5:40 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> > Why would we want to? Just let things going as long as there is at least one
> > maintainer committing something. Even if not all security issues get fixed,
> > it's better than if none gets fixed.
> 
> 
> Ha!  Keeping a branch open because one maintainer interested in
> something.  That's not a distribution. That's a personal respository.

If it turns out that no community agregates around that idea and it is
indeed a personnal repository it should be stopped, but you cannot know
if you don't try.

--
Pat



From pertusus at free.fr  Mon Oct 13 16:56:31 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 18:56:31 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223915022.3327.24.camel@luminos.localdomain>
References: <1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<1223915022.3327.24.camel@luminos.localdomain>
Message-ID: <20081013165631.GP3139@free.fr>

On Mon, Oct 13, 2008 at 09:23:42AM -0700, Jesse Keating wrote:
> On Mon, 2008-10-13 at 16:23 +0200, Ralf Corsepius wrote:
> > 
> > In a nutshell:
> > * Lift acls from all discontinued Fedoras
> > * Keep the buildinfrastructure alive.
> > * Allow fedora maintainers to fix bugs in discontinued Fedoras.
> 
> I think the only way I'd vote for this to happen is if it was setup in
> thusly:
> 
> At the point of official EOL (IE the 13~ month mark) PackageKit is
> notified in such a way so that in it's attempts to fetch new updates
> from existing repos it warns users about the EOL and explains to them
> the situation.  It can offer a few different options:
> 
> A) Upgrade (via pre-upgrade) to a newer version of Fedora.
> 
> B) Configure itself for a new set of repos that are the product of
> post-eol updates by maintainers, giving clear information to the user
> that there is no set lifespan, no set package list, no set expectation,
> no nothing.
> 
> C) Do nothing.
> 
> Users of EOL releases would have to make a conscious choice to jump on
> the post-eol update world, so that they are given a chance to understand
> what it is they would be consuming.  I would not want people to wind up
> there without any prior knowledge and properly set expectation of what
> they are getting, and I would want them to be urged to upgrade if at all
> possible.

Agreed. In fact I think that we could start something even without B)
available in packagekit, but only with a manual change in the yum config
files. But packagekit pointing to the post-eol repo would be even
better.

> Furthermore I would want to prevent maintainers who do not wish to
> participate in the post-EOL update world from getting bugzilla reports
> by people using their software in EOL releases.

My proposal is to do a mass orphaning of EOLed branches, such that a
maintainer has to actively step in. But I can't see a way to avoid bugs
labelled against a non EOLed branch to reach the current maintainer. If
a packager maintains a EOLed branch I also thing that it should be
mandatory (and also logical!) to be in watchbugzilla (if the maintainer 
agrees, of course) to do bug triaging, but for those that are orphaned
in the EOLed branch I can't see waht to do for wrongly labelled bugs.

> Finally, I would prefer if we had our automated signing system in place
> prior to this, but I'm not going to make this a blocker.
> 
> Maintainer teams of various systems such as Bodhi and pkgdb and koji and
> mirrormanager et al would also need to give their explicit approval and
> add any further adjustments to any such plan.

Of course. At least for me, I think that this idea is not worth pursuing
if the cost in term of infras manpower or even hardware and the like is
not almost nill (except for volunteers really interested in that).

--
Pat



From poelstra at redhat.com  Mon Oct 13 16:58:34 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 13 Oct 2008 09:58:34 -0700
Subject: Package review backlog.
In-Reply-To: <20081011102120.GA2788@free.fr>
References: <1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<1223645613.3514.12.camel@wicktop.localdomain>	<1223649007.6770.25.camel@macbook.infradead.org>	<48F01BDF.1000109@redhat.com>
	<48F07615.7060306@hhs.nl> <20081011102120.GA2788@free.fr>
Message-ID: <48F37E3A.5030603@redhat.com>

Patrice Dumas said the following on 10/11/2008 03:21 AM Pacific Time:
> On Sat, Oct 11, 2008 at 11:47:01AM +0200, Hans de Goede wrote:
>> John Poelstra wrote:
>>> http://tinyurl.com/4kt682
>>> 1,212 open Package Review bugs
>> Of those 1200 pachages awaiting review, 100 block FE_NEEDSPONSOR, so 1100 
>> are normal reviews submitted by people which are already contributers! 
> 
> These numbers are partly misleading. Indeed many are merge reviews that
> are... special, at least should not, in my opinion be counted like
> other reviews since they are already in. And among the other many are in
> progress and blocked by a change required somewhere, upstream, or in
> other package or there is something not obvious in the package that
> needs some work, it is not necessarily a lack of reviewers. In some way
> having many active review bugs may be good if it is because the review
> is serious and allow to have quality packages in only. So, in my opinion
> the raw numbers don't mean a lot, what would be meaningful, would be, in
> my opinion, the ratio of review requests that nobody had a look at over
> the number of fedora contributors.
> 

I queried all open bugs for the "Package Review" component.

They are also a large part of the total of NEW rawhide bugs here: 
http://tinyurl.com/4cavl2

John



From jkeating at redhat.com  Mon Oct 13 16:59:17 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 09:59:17 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <20081013165631.GP3139@free.fr>
References: <1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<1223915022.3327.24.camel@luminos.localdomain>
	<20081013165631.GP3139@free.fr>
Message-ID: <1223917157.3327.30.camel@luminos.localdomain>

On Mon, 2008-10-13 at 18:56 +0200, Patrice Dumas wrote:
> Agreed. In fact I think that we could start something even without B)
> available in packagekit, but only with a manual change in the yum config
> files. But packagekit pointing to the post-eol repo would be even
> better.

That's acceptable to me too.

> 
> > Furthermore I would want to prevent maintainers who do not wish to
> > participate in the post-EOL update world from getting bugzilla reports
> > by people using their software in EOL releases.
> 
> My proposal is to do a mass orphaning of EOLed branches, such that a
> maintainer has to actively step in. But I can't see a way to avoid bugs
> labelled against a non EOLed branch to reach the current maintainer. If
> a packager maintains a EOLed branch I also thing that it should be
> mandatory (and also logical!) to be in watchbugzilla (if the maintainer 
> agrees, of course) to do bug triaging, but for those that are orphaned
> in the EOLed branch I can't see waht to do for wrongly labelled bugs.

Right, it would be silly of me to expect you to somehow prevent people
from filing bugs to the wrong release.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/b4074359/attachment.sig>

From denis at poolshark.org  Mon Oct 13 17:22:21 2008
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 13 Oct 2008 19:22:21 +0200
Subject: F10 blocker bugs
In-Reply-To: <1223916298.3082.6.camel@localhost.localdomain>
References: <48F32838.8070508@poolshark.org>
	<48F350C6.10900@redhat.com>	<48F3511D.4070604@redhat.com>
	<1223916298.3082.6.camel@localhost.localdomain>
Message-ID: <48F383CD.9020502@poolshark.org>

Will Woods wrote:
> Not quite. The bug doesn't say that Evolution *doesn't start under any
> circumstances*,  just that it crashes if configured to use a Google
> Calendar. Therefore this is *not* a release blocker. 

Actually even after removing the Google calender link, it typically 
crashes simply by clicking on the Calendar button on the bottom-left 
corner...



From limb at jcomserv.net  Mon Oct 13 17:09:53 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 13 Oct 2008 12:09:53 -0500 (CDT)
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <48F35B08.3040600@gmail.com>
References: <48F35B08.3040600@gmail.com>
Message-ID: <62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>


> Hi!
>
> As announced at http://www.yafray.org, yafaray replaces YafRay 0.0.9.
> Thus I'm thinking of submitting yafray as dead.package in Rawhide. (1)
>
> On the other side, I'm not going to work on yafaray soon. So, if anyone
> wants to start working on it, feel free.
>
> Nicolas (kwizart)
>
>
> (1), There is no reason why yafray should stop working with the current
> blender releases. But there might be a problem when theses two are
> installed together. (until now, blender either dlopen library or call
> binary, from yafray).
> This has to be discussed in the yafaray review. So, please cc'ed me on
> the review, along with your favorite reviewer. (or ask me as a reviewer).

I may just do that.  One thing though, am I blind or is there nor yafaray
tarball, and I'll have to work from a svn checkout?  (bleah)

>
> --
> 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  Mon Oct 13 16:45:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 18:45:36 +0200
Subject: Regarding install options
In-Reply-To: <1223916009.3327.28.camel@luminos.localdomain>
References: <1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
Message-ID: <20081013164536.GN3139@free.fr>

On Mon, Oct 13, 2008 at 09:40:09AM -0700, Jesse Keating wrote:
> On Mon, 2008-10-13 at 18:13 +0200, Patrice Dumas wrote:
> > On Mon, Oct 13, 2008 at 08:29:11AM -0700, Jesse Keating wrote:
> > > 
> > > Probably because you haven't been on the front line, taking the bug
> > > reports, talking to users at events, trying to tweak the targets to
> > > match expectation and continually failing because there is no singular
> > > expectation.
> > 
> > Indeed, so just come with what you prefer. With otr without python 
> > it will be better than what is now.
> 
> Not sure what you mean by "otr".

'or'

> When I raised a bit of objection over adding 'yum' to the @core list,
> the responding argument was that if you're getting so specific in your
> 'minimal' install, you're either doing a chroot type install or can
> modify a groupdata set to strip it out for your install, whereas for all
> the other cases it's better to have it there.

I think that these are valid arguments, in my opinion you should just
decide (as the release manager in chief or something like that ;-) for 
others, as there will never be an agreement. I think that it would be
better to have yum, but understand perfectly that other are better with
rpm only.

--
Pat



From kevin.kofler at chello.at  Mon Oct 13 18:03:50 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 18:03:50 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
	<1223865390.4250.32.camel@rlt60f8.laptop.redhat.com>
	<loom.20081013T080514-964@post.gmane.org>
	<1576.71.208.51.222.1223908541.squirrel@www.cora.nwra.com>
Message-ID: <loom.20081013T175006-679@post.gmane.org>

 <orion <at> cora.nwra.com> writes:
> I'm not aware of KDE for CentOS.

RHEL/CentOS contains KDE, and there are also newer versions available from the 
kde-redhat project. (There's currently 3.5.9 in stable and 3.5.10 in testing 
for EL5. The stock EL5 KDE is 3.5.4.)

        Kevin Kofler



From jkeating at redhat.com  Mon Oct 13 18:08:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 11:08:00 -0700
Subject: Regarding install options
In-Reply-To: <20081013164536.GN3139@free.fr>
References: <1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
Message-ID: <1223921280.3327.34.camel@luminos.localdomain>

On Mon, 2008-10-13 at 18:45 +0200, Patrice Dumas wrote:
> I think that these are valid arguments, in my opinion you should just
> decide (as the release manager in chief or something like that ;-) for 
> others, as there will never be an agreement. I think that it would be
> better to have yum, but understand perfectly that other are better with
> rpm only.

The problem was the never ending bug parade and arguments on mailing
lists, trade shows, etc...

We decided the only way to win this game was to not play at all, and we
let people decide their own definition of 'minimal'.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/c18c9901/attachment.sig>

From kevin.kofler at chello.at  Mon Oct 13 18:15:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 18:15:55 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<1223904831.6770.597.camel@macbook.infradead.org>
	<20081013141623.GF3139@free.fr>
Message-ID: <loom.20081013T181242-308@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:
> If I recall well, FC-5 could be upgraded to RHEL/EPEL, but not a fully
> uptodate FC-6.

Even an updated FC5 doesn't upgrade safely to EL5. For example, the kernel and 
KDE are newer in FC5 updates than in EL5. I'm sure there are more such 
packages.

        Kevin Kofler



From sundaram at fedoraproject.org  Mon Oct 13 18:17:13 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 13 Oct 2008 23:47:13 +0530
Subject: reviving Fedora Legacy
In-Reply-To: <20081013165631.GP3139@free.fr>
References: <1223900281.6770.573.camel@macbook.infradead.org>	<48F3459B.8080704@leemhuis.info>	<1223903369.3029.58.camel@beck.corsepiu.local>	<48F34C21.3000404@leemhuis.info>	<1223905136.3029.81.camel@beck.corsepiu.local>	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>	<1223907160.3029.109.camel@beck.corsepiu.local>	<20081013141451.GB9793@yoda.jdub.homelinux.org>	<1223907829.3029.118.camel@beck.corsepiu.local>	<1223915022.3327.24.camel@luminos.localdomain>
	<20081013165631.GP3139@free.fr>
Message-ID: <48F390A9.1050901@fedoraproject.org>

Patrice Dumas wrote:

> Of course. At least for me, I think that this idea is not worth pursuing
> if the cost in term of infras manpower or even hardware and the like is
> not almost nill (except for volunteers really interested in that).

Patrice,

It appears that 2.6.27 will be maintained for a longer period of time. 
If this project gets started, you might want to keep track of this.

http://thread.gmane.org/gmane.linux.kernel/742570/focus=743377

Rahul



From jwboyer at gmail.com  Mon Oct 13 18:46:21 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 13 Oct 2008 14:46:21 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <48F390A9.1050901@fedoraproject.org>
References: <1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<1223915022.3327.24.camel@luminos.localdomain>
	<20081013165631.GP3139@free.fr>
	<48F390A9.1050901@fedoraproject.org>
Message-ID: <20081013184621.GA4826@yoda.jdub.homelinux.org>

On Mon, Oct 13, 2008 at 11:47:13PM +0530, Rahul Sundaram wrote:
> Patrice Dumas wrote:
>
>> Of course. At least for me, I think that this idea is not worth pursuing
>> if the cost in term of infras manpower or even hardware and the like is
>> not almost nill (except for volunteers really interested in that).
>
> Patrice,
>
> It appears that 2.6.27 will be maintained for a longer period of time.  
> If this project gets started, you might want to keep track of this.
>
> http://thread.gmane.org/gmane.linux.kernel/742570/focus=743377

Except that over the life of F10, it will likely migrate to 2.6.28 and
therefore if/when a Fedora LTS gets created at the point that F10 is EOL,
the fact that 2.6.27 will be long-term maintained will be sort of irrelevant.

josh



From dbn.lists at gmail.com  Mon Oct 13 18:53:42 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 13 Oct 2008 11:53:42 -0700
Subject: Package review backlog.
In-Reply-To: <48F2F812.50407@seketeli.org>
References: <loom.20081008T092258-152@post.gmane.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<1223645613.3514.12.camel@wicktop.localdomain>
	<1223649007.6770.25.camel@macbook.infradead.org>
	<48F01BDF.1000109@redhat.com> <48F07615.7060306@hhs.nl>
	<48F2F812.50407@seketeli.org>
Message-ID: <91705d080810131153s3e62ec92ob598d81a19ef785a@mail.gmail.com>

On Mon, Oct 13, 2008 at 12:26 AM, Dodji Seketeli <dodji at seketeli.org> wrote:
>
> Yeah, but what about the 100 people who are not contributors yet, and who
> are willing to get in ? What can be done to speed up the reviews of their
> packages in practice ?

Be a hero today! Review this RPM for a ridiculously simple perl module
that allows you to use SSL/TLS to your mail server with
git-send-email.

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

--
Dan



From sundaram at fedoraproject.org  Mon Oct 13 18:54:46 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 14 Oct 2008 00:24:46 +0530
Subject: reviving Fedora Legacy
In-Reply-To: <20081013184621.GA4826@yoda.jdub.homelinux.org>
References: <1223903369.3029.58.camel@beck.corsepiu.local>	<48F34C21.3000404@leemhuis.info>	<1223905136.3029.81.camel@beck.corsepiu.local>	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>	<1223907160.3029.109.camel@beck.corsepiu.local>	<20081013141451.GB9793@yoda.jdub.homelinux.org>	<1223907829.3029.118.camel@beck.corsepiu.local>	<1223915022.3327.24.camel@luminos.localdomain>	<20081013165631.GP3139@free.fr>	<48F390A9.1050901@fedoraproject.org>
	<20081013184621.GA4826@yoda.jdub.homelinux.org>
Message-ID: <48F39976.9000607@fedoraproject.org>

Josh Boyer wrote:
> On Mon, Oct 13, 2008 at 11:47:13PM +0530, Rahul Sundaram wrote:
>> Patrice Dumas wrote:
>>
>>> Of course. At least for me, I think that this idea is not worth pursuing
>>> if the cost in term of infras manpower or even hardware and the like is
>>> not almost nill (except for volunteers really interested in that).
>> Patrice,
>>
>> It appears that 2.6.27 will be maintained for a longer period of time.  
>> If this project gets started, you might want to keep track of this.
>>
>> http://thread.gmane.org/gmane.linux.kernel/742570/focus=743377
> 
> Except that over the life of F10, it will likely migrate to 2.6.28 and
> therefore if/when a Fedora LTS gets created at the point that F10 is EOL,
> the fact that 2.6.27 will be long-term maintained will be sort of irrelevant.

I can't predict the future. 2.6.27 hasn't been pushed to Fedora 9. Maybe 
Patrice wants to start off with Fedora 8 or Fedora 9 instead of Fedora 
10. Maybe 2.6.28 won't hit Fedora 10. It is a potentially useful data 
point to consider. That's all.

Rahul



From notting at redhat.com  Mon Oct 13 18:56:39 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 13 Oct 2008 14:56:39 -0400
Subject: Package review backlog.
In-Reply-To: <48F07C5C.8000403@leemhuis.info>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<48F07C5C.8000403@leemhuis.info>
Message-ID: <20081013185639.GA27065@nostromo.devel.redhat.com>

Thorsten Leemhuis (fedora at leemhuis.info) said: 
> I propose that each FESCo member should try to work on at least one  
> package review per week. Each week at the FESCo meeting all FESCo  
> members should be asked what they did (as FESCo member) over the past  
> week to improve Fedora; they further should be asked what they (as FESCo  
> member) plan for the coming week to improve Fedora. That includes, but  
> is not limited to reviews.

This seems rather silly - do other elected bodies make each member
justify their existence once per week? (It's not like we're normally
hurting for things to talk about during meetings.)

CVS logs are public records. Bugzilla is a more-or-less public record.
Meeting logs are a public record. The information is there if people
want to use it for voter education purposes.

Bill



From kevin.kofler at chello.at  Mon Oct 13 19:15:06 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 19:15:06 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
	<20081013145429.GJ3139@free.fr> <20081013150508.GK3139@free.fr>
	<20081013112622.77fbf8ea@infradead.org>
	<1223915142.3327.25.camel@luminos.localdomain>
Message-ID: <loom.20081013T191219-301@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> The problem you run into is that everybody wants a /different/ one to be
> the LTS release, that is the one they're currently stuck on.

I think at least this time the choice of F8 is obvious:
* It's the version to go EOL next.
* F9 is a version with huge changes:
  - KDE 4
  - X.Org X11R7.4 (server 1.5.0)
  - GCC 4.3
  etc.
  all of which contribute to people being stuck on F8.

Frankly, if even the manpower to maintain F8 now can't be found, then I doubt 
there will ever be enough manpower for an LTS release.

        Kevin Kofler



From kwizart at gmail.com  Mon Oct 13 17:48:54 2008
From: kwizart at gmail.com (KH KH)
Date: Mon, 13 Oct 2008 19:48:54 +0200
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
Message-ID: <e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>

2008/10/13 Jon Ciesla <limb at jcomserv.net>:
>
>> Hi!
>>
>> As announced at http://www.yafray.org, yafaray replaces YafRay 0.0.9.
>> Thus I'm thinking of submitting yafray as dead.package in Rawhide. (1)
>>
>> On the other side, I'm not going to work on yafaray soon. So, if anyone
>> wants to start working on it, feel free.
>>
>> Nicolas (kwizart)
>>
>>
>> (1), There is no reason why yafray should stop working with the current
>> blender releases. But there might be a problem when theses two are
>> installed together. (until now, blender either dlopen library or call
>> binary, from yafray).
>> This has to be discussed in the yafaray review. So, please cc'ed me on
>> the review, along with your favorite reviewer. (or ask me as a reviewer).
>
> I may just do that.  One thing though, am I blind or is there nor yafaray
> tarball, and I'll have to work from a svn checkout?  (bleah)
Yes, that's right.
I think it will be appropriate to use a script to create one source tarball.
Good luck !

Nicolas (kwizart)
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> --
> novus ordo absurdum
>
> --
> 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  Mon Oct 13 19:18:31 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 13 Oct 2008 19:18:31 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
	<20081013145429.GJ3139@free.fr> <20081013150508.GK3139@free.fr>
	<20081013112622.77fbf8ea@infradead.org>
	<20081013164016.GM3139@free.fr>
Message-ID: <loom.20081013T191553-681@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:
> Indeed, maybe the best would be to start with F9 such that the
> infrastructure doesn't have to be revived.

Why not F8? It's still supported now, so nothing to revive, and I think a lot 
more people will be interested in a longer-term support for F8 than F9. F9->F10 
has few major changes (I see only the new RPM as a potential trouble point), 
F8->F9 had a lot of them (GCC 4.3 can be a problem for developers, KDE 4 for 
users, the new X11 for users of proprietary graphics drivers etc.).

        Kevin Kofler



From notting at redhat.com  Mon Oct 13 19:21:04 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 13 Oct 2008 15:21:04 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T013947-433@post.gmane.org>
References: <loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
Message-ID: <20081013192104.GB27065@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> Why would we want to? Just let things going as long as there is at least one 
> maintainer committing something. Even if not all security issues get fixed, 
> it's better than if none gets fixed.

Hi! We've got this great new thing for you! 

Do you like your current Fedora release?

Do you not want to upgrade?

Well, then here we go - we'll support it for you! [*]

[*] Not guaranteed to prevent any or all security attacks [**]
[**] Not all packages to receive security fixes [***]
[***] Maintenance guaranteed for a completely indeterminate period of time [****]
[****] Maintenance can be taken away at any time

Tell me again... what sort of people are you trying to serve with this? In what
way does this serve them better than RHEL or CentOS?

Bill



From alsadi at gmail.com  Mon Oct 13 16:16:55 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 13 Oct 2008 19:16:55 +0300
Subject: OpenOffice and go-oo
In-Reply-To: <1223909556.10624.131.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
	<1223909556.10624.131.camel@vain.rhgalway>
Message-ID: <385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>

> But rpm doesn't have any "Suggested" sort of feature, and I don't think
we have comps.xml, and in comps we can put "default" packages which
can be dropped in the livecd, but if ooo-core depends on java you
can't drop it

<<EOF
fine, so for e.g. the lucene if someone wants to do the work to rewrite
(like I did for the an older help system to move it from some java
solution to libxml/libxslt) it to use some functioning non-java solution
they that'd be fine. And for the saxon one, if someone tweaked things so
that the menus that refer to xslt features are only enabled/appear when
saxon is available then that'd be acceptable too, especially for a
fairly power-user feature like "write your own xslt transforms
EOF

but in go-oo I'm told that they have replaced some java things with
native replacement like some graphic things for example in sun's ooo
you need java to handle SVG in go-oo you don't

so it's NOT about leaving some un-functional things



From pertusus at free.fr  Mon Oct 13 19:41:27 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 21:41:27 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T191553-681@post.gmane.org>
References: <935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
	<20081013145429.GJ3139@free.fr> <20081013150508.GK3139@free.fr>
	<20081013112622.77fbf8ea@infradead.org>
	<20081013164016.GM3139@free.fr>
	<loom.20081013T191553-681@post.gmane.org>
Message-ID: <20081013194127.GA2738@free.fr>

On Mon, Oct 13, 2008 at 07:18:31PM +0000, Kevin Kofler wrote:
> Patrice Dumas <pertusus <at> free.fr> writes:
> > Indeed, maybe the best would be to start with F9 such that the
> > infrastructure doesn't have to be revived.
> 
> Why not F8? It's still supported now, so nothing to revive, and I think a lot 
> more people will be interested in a longer-term support for F8 than F9. F9->F10 

Forgot that F8 was still maintained... F8 would be nice, yes. It doesn't
make that much time to organize, but still right.

--
Pat



From pertusus at free.fr  Mon Oct 13 19:48:00 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 21:48:00 +0200
Subject: Regarding install options
In-Reply-To: <1223921280.3327.34.camel@luminos.localdomain>
References: <1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
Message-ID: <20081013194800.GB2738@free.fr>

On Mon, Oct 13, 2008 at 11:08:00AM -0700, Jesse Keating wrote:
> On Mon, 2008-10-13 at 18:45 +0200, Patrice Dumas wrote:
> > I think that these are valid arguments, in my opinion you should just
> > decide (as the release manager in chief or something like that ;-) for 
> > others, as there will never be an agreement. I think that it would be
> > better to have yum, but understand perfectly that other are better with
> > rpm only.
> 
> The problem was the never ending bug parade and arguments on mailing
> lists, trade shows, etc...

Indeed that will happen. But does doing nothing really prevent it from
happening? 

> We decided the only way to win this game was to not play at all, and we
> let people decide their own definition of 'minimal'.

The final word is up to you (and people in the release team) to choose
between all theses possibilities (not very helpful, I know, but I think
that there is no clear technically superior solution so you have to make
your choice based on your 'expert' judgement).

--
Pat



From shambo.linux at gmail.com  Mon Oct 13 19:54:46 2008
From: shambo.linux at gmail.com (Shambo Bose)
Date: Tue, 14 Oct 2008 01:24:46 +0530
Subject: Regarding install options
Message-ID: <b53a79450810131254r6d4073cch35112443c90bbed6@mail.gmail.com>

   Hi,

> The problem was the never ending bug parade and arguments on mailing
> lists, trade shows, etc...
>
> We decided the only way to win this game was to not play at all, and we
> let people decide their own definition of 'minimal'.

 I think the decision was good but a advance fedora user can only define
his/ her minimal , according to me there lies the problem as new users don't
have that knowledge about each and every packages.

>
> --
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
>

thank you.


Shambo Bose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/255a53e2/attachment.htm>

From pertusus at free.fr  Mon Oct 13 19:55:07 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 21:55:07 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013192104.GB27065@nostromo.devel.redhat.com>
References: <20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
Message-ID: <20081013195507.GC2738@free.fr>

On Mon, Oct 13, 2008 at 03:21:04PM -0400, Bill Nottingham wrote:
> 
> [*] Not guaranteed to prevent any or all security attacks [**]
> [**] Not all packages to receive security fixes [***]
> [***] Maintenance guaranteed for a completely indeterminate period of time [****]
> [****] Maintenance can be taken away at any time

Can you guarantee that for any fedora release. No. There is the same
level of guarantee, at least at the package level since there are only
volunteers. Of course there is a community and an enterprise behind
fedora proper so there can be a good confidence that the most important
parts of the distro will be maintained, but there is nothing binding.

> Tell me again... what sort of people are you trying to serve with this? In what
> way does this serve them better than RHEL or CentOS?

This has been answered many times. It is not the same to have some more
time of fedora than to install directly a Centos/RHEL, and upgrading to
Centos/RHEL is not always possible.

--
Pat



From notting at redhat.com  Mon Oct 13 20:00:47 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 13 Oct 2008 16:00:47 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081013195507.GC2738@free.fr>
References: <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
Message-ID: <20081013200047.GC27065@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> > [*] Not guaranteed to prevent any or all security attacks [**]
> > [**] Not all packages to receive security fixes [***]
> > [***] Maintenance guaranteed for a completely indeterminate period of time [****]
> > [****] Maintenance can be taken away at any time
> 
> Can you guarantee that for any fedora release.


Yes. There's the defined release lifespan; anything of consequence
will be maintained for that period.

> > Tell me again... what sort of people are you trying to serve with this? In what
> > way does this serve them better than RHEL or CentOS?
> 
> This has been answered many times. It is not the same to have some more
> time of fedora than to install directly a Centos/RHEL, and upgrading to
> Centos/RHEL is not always possible.

Neither is upgrading from TurboGears to Ruby on Rails and having your app
work. If you started off by choosing the wrong tool, why would you expect
an upgrade to something different to work? 

Bill



From pertusus at free.fr  Mon Oct 13 20:04:14 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 22:04:14 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F39976.9000607@fedoraproject.org>
References: <1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<1223915022.3327.24.camel@luminos.localdomain>
	<20081013165631.GP3139@free.fr>
	<48F390A9.1050901@fedoraproject.org>
	<20081013184621.GA4826@yoda.jdub.homelinux.org>
	<48F39976.9000607@fedoraproject.org>
Message-ID: <20081013200414.GD2738@free.fr>

On Tue, Oct 14, 2008 at 12:24:46AM +0530, Rahul Sundaram wrote:
>
> I can't predict the future. 2.6.27 hasn't been pushed to Fedora 9. Maybe  
> Patrice wants to start off with Fedora 8 or Fedora 9 instead of Fedora  
> 10. Maybe 2.6.28 won't hit Fedora 10. It is a potentially useful data  
> point to consider. That's all.

As Kevin suggested F8 would be a good start. And if we don't have time
to set things up, F9 would be the second choice. So this info is
definitely usefull.

--
Pat



From nicolas.mailhot at laposte.net  Mon Oct 13 20:11:05 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 13 Oct 2008 22:11:05 +0200
Subject: Regarding install options
In-Reply-To: <20081013194800.GB2738@free.fr>
References: <1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
Message-ID: <1223928665.29527.2.camel@arekh.okg>

Le lundi 13 octobre 2008 ? 21:48 +0200, Patrice Dumas a ?crit :
> On Mon, Oct 13, 2008 at 11:08:00AM -0700, Jesse Keating wrote:

> > We decided the only way to win this game was to not play at all, and we
> > let people decide their own definition of 'minimal'.
> 
> The final word is up to you (and people in the release team) to choose
> between all theses possibilities (not very helpful, I know, but I think
> that there is no clear technically superior solution so you have to make
> your choice based on your 'expert' judgement).

The final word is for the people who care about this minimal thing to
organise themselves and propose comps modification that permit minimal
installs.

As has been stated recently comps is 100% open and there are zero
barriers for a group of auditors to improvr our package classification.

-- 
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/20081013/9dd3002d/attachment.sig>

From jkeating at redhat.com  Mon Oct 13 20:12:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 13:12:44 -0700
Subject: Regarding install options
In-Reply-To: <20081013194800.GB2738@free.fr>
References: <1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
Message-ID: <1223928764.3327.40.camel@luminos.localdomain>

On Mon, 2008-10-13 at 21:48 +0200, Patrice Dumas wrote:
> 
> Indeed that will happen. But does doing nothing really prevent it from
> happening? 

Yes, since removing the install classes, the bugs against these classes
being wrong in one way shape or form have all but disappeared.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/2fe51012/attachment.sig>

From pertusus at free.fr  Mon Oct 13 20:22:31 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 22:22:31 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013200047.GC27065@nostromo.devel.redhat.com>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
Message-ID: <20081013202231.GE2738@free.fr>

On Mon, Oct 13, 2008 at 04:00:47PM -0400, Bill Nottingham wrote:
> 
> Yes. There's the defined release lifespan; anything of consequence
> will be maintained for that period.

You can say that but cannot give any guarantee.

> Neither is upgrading from TurboGears to Ruby on Rails and having your app
> work. If you started off by choosing the wrong tool, why would you expect
> an upgrade to something different to work? 

I know about users for which Centos/RHEL is not right because it is too
old, fedora would suit them, if they had not to upgrade after one year.
Currently I have to propose them to install ubuntu, because there is
nothing in the fedora/RHEL market that suits them. Not enough power user
for fedora updates every year, need too recent stuff for RHEL. Another
category who be those who want to use a controlled set of next
technology preview in production environment and are willing to do some
testing and help with bugs, hence would have choosen fedora, but cannot
if they have to update each year.

--
Pat



From pertusus at free.fr  Mon Oct 13 20:26:49 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 22:26:49 +0200
Subject: Regarding install options
In-Reply-To: <1223928764.3327.40.camel@luminos.localdomain>
References: <1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928764.3327.40.camel@luminos.localdomain>
Message-ID: <20081013202649.GF2738@free.fr>

On Mon, Oct 13, 2008 at 01:12:44PM -0700, Jesse Keating wrote:
> On Mon, 2008-10-13 at 21:48 +0200, Patrice Dumas wrote:
> > 
> > Indeed that will happen. But does doing nothing really prevent it from
> > happening? 
> 
> Yes, since removing the install classes, the bugs against these classes
> being wrong in one way shape or form have all but disappeared.

A very strong argument, indeed. It seems unfortunate but not 
unwise not to have any minimal set, then. Sigh...

--
Pat



From pertusus at free.fr  Mon Oct 13 20:32:44 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 13 Oct 2008 22:32:44 +0200
Subject: Regarding install options
In-Reply-To: <1223928665.29527.2.camel@arekh.okg>
References: <1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>
Message-ID: <20081013203244.GG2738@free.fr>

On Mon, Oct 13, 2008 at 10:11:05PM +0200, Nicolas Mailhot wrote:
> 
> The final word is for the people who care about this minimal thing to
> organise themselves and propose comps modification that permit minimal
> installs.
> 
> As has been stated recently comps is 100% open and there are zero
> barriers for a group of auditors to improvr our package classification.

I had a look recently, and I think that comps are in a good shape for
minimal installs. (there is an issue with anaconda deps being draggued 
in but it is an orthogonal issue). However chosing @core or @core +
@base is an unsolved (and unsolvable, in my opinion) issue.

--
Pat



From vonbrand at inf.utfsm.cl  Mon Oct 13 20:42:57 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 13 Oct 2008 17:42:57 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223875666.3564.1441.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
Message-ID: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
> > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> > > > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> > > > >> Dmitry Butskoy wrote:
> > > > >> > Itamar - IspBrasil wrote:
> > > > [snip]
> > > > >> The fact that they switched to CentOS is *good* for Fedora.
> > > > > I can not disagree more - To me, it's yet another evidence of Fedora
> > > > > being on the loose.
> > > > 
> > > > You're going to have to expound on that. I do not see Centos in any
> > > > way as in competition with Fedora.
> > 
> > > EPEL drains away resources from Fedora.
> > 
> > Proof?

> Urgh, isn't that obvious?

No, it isn't.

Note: In my experience, getting hardware and such is cheap/easy, getting
people willing (and capable, and dependable) of doing the job is hard.

> E.g.:
> - Build server resources, mirror resources.

I don't see a great drain in build servers, and mirrors are voluntary.

> - People are using/testing EPEL instead of Fedora.

Either I run RHEL/CentOS + EPEL or Fedora. No loss at all, more of a win
(EPEL users /also/ test Fedora stuff).

> - Fedora infrastructure, e.g. EPEL enlarges the packagedb by almost
> factor 2.

Not that important, IMHO.

> - EPEL would force Fedora contributors to test on both RHEL and Fedora.

You sure? In any case, extra burden on contributors is a real drain... but
then again, EPEL and Fedora contributors aren't the same bunch, so...

> > > >  Centos is something everyone should be proud of.

> > > Well, to me CentOS is as important as any other arbitrary Linux distro.
> > > I am glad they are around, but not more and not less.

> > It is around becase RHEL is popular, and open source.

> And non-free

It /is/ free... you pay for support only.

>              - If it was free, the CentOS folks could start directly
> contribute to Fedora

No...

>                      or RHEL.

They do (funnelling bug reports and patches upstream to RH).

>                               Right now, it's them wasting time to
> workaround on RHEL being non-free.

As I told earlier, RH is going out of their way to make CentOS /easy/, not
hard. 

> > > > >> CentOS's goals are better oriented to the needs of someone 
> > > > >> that wants to deploy a system and run it for years. Fedora is
> > > > >> good for people who want to get the latest technologies from
> > > > >> upstream as soon as they're stable enough to integrate into a
> > > > >> running system.

> > > > > Right. But why can't Fedora do better?

Define "better"... "Good Fedora" is bleeding edge, not fully stabilized
software, experimental stuff that may pan out (or it might not, being
replaced by something else), changing APIs (literally and sysadmin-wise),
fast turnaround. "Good RHEL" is rock stable, unchanging (even in details)
for years. What is good for one is terrible for the other.

> > > > >                                        I feel Fedora could do better.

> > > > Sure. With more devs, servers, time, etc.

> > > ... less bureaucracy, less committees/less chiefs/more Indians,
> > > different people, different strategies.

> > Show how!

> Ease reviews, bodhi, packagedb, koji, bugzilla, track, re-consider FTBS,
> work-flow, trademark policy. 

Definite proposals that can be discussed?

What does "trademark policy" have to do with anything, BTW?

> E.g. right now, the tools being in use are a heterogenious mixture of
> separate tools,

Unix...

>                 are often broken,

Fixing hands are presumably wellcome...

>                                   are far from easy to use

Concrete proposals on what to change how?

>                                                            and aim at
> implementing a highly bureaucratic process/work-flow.

Again, proposals, please?

> >  Telling everybody here how awful things are going isn't helping
> > an iota. Everything has its limits, and for every desirable quality (newest
> > shiny toys, support for the newest fad in hardware in software) there is a
> > cost (can't be supported in the long range, fast turnaround, set procedures
> > to handle a huge stream of new stuff)
> > 
> > > >  But baring a sudden increase
> > > > in those, I would much prefer to see Fedora focus on dev and testing,
> > > > let other distros pretty things up.
> > 
> > > ACK. Unfortunately, Fedora is drifting away from this group towards
> > > single-user desktops (e.g. OLPC).
> > 
> > Then work towards drifting the opposite direction...

> One reason why I am agitating ...

"Agitating" doesn't help much.

> > Fedora (or any other large group of people) will move where the majority
> > wants to go... 

> Well, deployment of an OS to servers, will always be a "minority use
> case" and will always collide somewhere with mere desktop oriented
> developments.

So?

[...]

> > > > Why would they, after often suggesting that Fedora _not_ be used on
> > > > production servers, use Fedora on their production servers?

> > > Depends on how they mean it:
> > > - if they are referring to "long term maintained/everlasting support"
> > > servers, they are right.

> > "Servers" are "long-time maintained" by definition...

> To me, "server" is a "use-case of an OS" and is not at all connected to
> running the same OS for many years. 

That is "testing an OS with server workload", something different entirely.

> Yes, no doubt, running the same OS on a larger number of machines for a
> longer time helps maintenance, but I do not see how this is connected to
> a particular machine serving as "clients" or "servers".
> 
> Yes, no doubt, there are use-cases where "long-term API" stability is
> important, but this applies to client use-cases as well as to server
> use-cases.

Those /are/ the "server" use cases you want so badly! And that is at
fundamental odds with Fedora's goals, so it won't happen.

> ...

> Finally, yes, no doubt, Fedora is not the "shoe that fits all sizes" nor
> are CentOS or RHEL, but ... this doesn't mean that Fedora may not be
> applicable to server scenarios.
> 
> > > - if they mean it as "Fedora is technically too unstable",
> > 
> > Because there is no "long term maintenance"...

> Again, I don't see how "lack of stability" and "no long term
> maintenance" are linked together at all, nor how server and client
> use-cases matter.

Again: "stability" is /not/ "when run on 10 thousand machines only one
crashes a day", it is "runs for thousands of days before crashing", and
/that/ is as un-Fedora as it gets.

> What matters in use-cases of short lived-distros such as Fedora is:
> Upgrades "must simply work" and (admin-) personnel must be able to
> handle them in a particular scenario.

Sure. Test upgrading for a few months until everything is A-OK, and here
comes the next release, before we finished testing the last one. Nice idea.

> > >                                                            then this
> > > people should start working on improving the situation

> > Which one?

> Lack of stability,

Design objective.

>                    lack of usability,

Do the work of usability testing, feed it back. Many thanks will flow back.

>                                       deficiencies of the
> infrastructure,

Ditto.

>                 bureaucracy,

Ditto.

>                              short-livedness

Design objective, won't change.

>                                              ... tools

Huh?

> The lack of people to me is not a cause, it's a consequence of mistakes
> in Fedora's history.

Is there /really/ a lack of people? Are any statistics of contributors (and
contributions) at hand?

> >  Fedora is about /not/ "long term" but "bleeding edge"...

> "Leading edge" doesn't necessarily have to be linked to "bleeding" nor
> "unstable". It's sad, the latter is true wrt. Fedora.

It is true (sad or not) for /all/ "leading edge" endeavors, the more
"leading" the more "bleeding". Live with it, as you can't do without.

> > >                                                        or (better) quit
> > > Fedora.

> > Do so, then.

> I haven't given in, yet. 

Great!

> The cause for my current dissatisfaction is Fedora's infrastructure and
> Fedora's leadership. They have driven Fedora/have allowed Fedora to move
> into what I consider to be an unhealthy direction.

Just whining that everything is wrong and in bad shape doesn't help, does
it. Come back with concrete proposals of what to fix how, and volunteer
doing the work. Run for office in Fedora on your proposals.
-- 
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 2340000       Fax:  +56 32 2797513



From jkeating at redhat.com  Mon Oct 13 20:45:47 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 13:45:47 -0700
Subject: Regarding install options
In-Reply-To: <20081013203244.GG2738@free.fr>
References: <1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr> <1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
Message-ID: <1223930747.3327.41.camel@luminos.localdomain>

On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
> I had a look recently, and I think that comps are in a good shape for
> minimal installs. (there is an issue with anaconda deps being draggued 
> in but it is an orthogonal issue). However chosing @core or @core +
> @base is an unsolved (and unsolvable, in my opinion) issue.

How so?  You uncheck everything to get @core, you uncheck everything but
the Base group to get @core + @base

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/3d2e6139/attachment.sig>

From lesmikesell at gmail.com  Mon Oct 13 20:46:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 15:46:51 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <1223916069.3327.29.camel@luminos.localdomain>
References: <20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>	<loom.20081012T230422-741@post.gmane.org>	<48F288A3.8000601@shmuelhome.mine.nu>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>	<loom.20081013T075922-165@post.gmane.org>
	<48F34AE6.6060400@gmail.com>	<20081013135756.GO13066@br-online.de>
	<48F360BA.7080806@gmail.com>	<affaa1bfa86ed44a0a60a38e488537ea.squirrel@arekh.dyndns.org>	<48F36D5A.404@gmail.com>
	<1223916069.3327.29.camel@luminos.localdomain>
Message-ID: <48F3B3BB.6090602@gmail.com>

Jesse Keating wrote:
> On Mon, 2008-10-13 at 10:46 -0500, Les Mikesell wrote:
>> No, it is an artifact of wildly changing APIs.  That was just an obvious 
>> example.  The same applies to apache/perl/python and just about every 
>> other package versioning.
> 
> But upstream chanced those APIs, and isn't upstream always right?

Even if it is right in the long run, the point of a distribution is to 
to protect its users from mid-release breakage.  If I wanted the 
upstream version as-is every day, I'd download it directly myself.  I 
expect a distribution to not break compatibility with what it packaged 
and shipped yesterday.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From notting at redhat.com  Mon Oct 13 20:49:19 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 13 Oct 2008 16:49:19 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081013202231.GE2738@free.fr>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
Message-ID: <20081013204919.GA28298@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> > Yes. There's the defined release lifespan; anything of consequence
> > will be maintained for that period.
> 
> You can say that but cannot give any guarantee.

On the contrary. The Fedora project provides maintenance of the release
for the release period. You're guaranteeing ... nothing.

> > Neither is upgrading from TurboGears to Ruby on Rails and having your app
> > work. If you started off by choosing the wrong tool, why would you expect
> > an upgrade to something different to work? 
> 
> I know about users for which Centos/RHEL is not right because it is too
> old,

... but then later want a longer term of support, up to 3-5 years, during
which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
in fact.

> technology preview in production environment and are willing to do some
> testing and help with bugs, hence would have choosen fedora, but cannot
> if they have to update each year.

I'm beginning to wonder if this isn't a straw horse that's being beaten to
death.

Fedora 8's been out less a year. It has, in that timeframe, received *over
4600 updates*. Fedora 9 has received over 2600 in its current lifetime.

How is upgrading to the next release really that many orders of magnitude
more change than this?

After all, if you're on F9 you've already consumed a KDE-4.0 to KDE-4.1
update, for example. Or kernel updates from 2.6.25 through to 2.6.27.
Or NetworkManager updates to the current version. Or ... <insert
changes here>...

Bill



From vonbrand at inf.utfsm.cl  Mon Oct 13 20:50:32 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 13 Oct 2008 17:50:32 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <1223881956.3564.1502.camel@beck.corsepiu.local>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<1223881956.3564.1502.camel@beck.corsepiu.local>
Message-ID: <200810132050.m9DKoWNG012058@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Mon, 2008-10-13 at 15:12 +1300, Martin Langhoff wrote:

[...]

> > I don't think anyone would sign up as a user for such "support". LTS
> > is about a fairly specific promise that is very hard to commit to.

> How so? It would be a legacy effort, run by volunteers, no guarantees,
> no commitments.

So would that satisfy /you/ in very particular? You would come screaming
bloody murder when one fine summer day, out of the blue, the "LTS" you were
planning on using for a few months more until you are ready to migrate to
the Latest And Greatest announces it will stop out of boredom of its last
maintainers... or just /the/ package you depend on is left stranded for
lack of interest... or terrible security problems in some unmaintained
packages show up...
-- 
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 2340000       Fax:  +56 32 2797513



From lesmikesell at gmail.com  Mon Oct 13 20:52:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 13 Oct 2008 15:52:59 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130906ofd95ad4g3439df9ea99e690e@mail.gmail.com>
References: <4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>	<20081013122955.GF3087@free.fr>	<20081013131123.GA19171@yoda.jdub.homelinux.org>	<20081013131753.GB3139@free.fr>	<20081013132336.GB19171@yoda.jdub.homelinux.org>	<20081013135533.GE3139@free.fr>	<935ead450810130706w168d9071o30155af1676c1021@mail.gmail.com>	<48F35C32.9050901@gmail.com>	<935ead450810130745j1039ef9dt4ea38c6d2f3989f1@mail.gmail.com>	<48F37089.5070001@gmail.com>
	<935ead450810130906ofd95ad4g3439df9ea99e690e@mail.gmail.com>
Message-ID: <48F3B52B.9080506@gmail.com>

Jeffrey Ollie wrote:
> 
>>> Well it really depends on what I was building.  If I was developing a
>>> new desktop application what you say might make sense.  If I was
>>> developing an e-commerce web site you'd be nuts to do that.
>> But then you'd probably use java to isolate yourself as much as possible
>> from silly API changes in OS and distributions...  And fedora hasn't been a
>> great place to use java.
> 
> I'm not a Java developer (I've written a few "Hello World" type things
> but nothing more complex than that) but from what I've seen from
> deploying a few Java-based systems is that while the "core" Java API
> may be stable, "real-world" Java systems have dependencies on things
> like Tomcat/Apache or other similar systems and are highly dependent
> on particular versions of those apps and associated libraries.

Agreed, but I'm not sure where this point leads.  Fedora has been fairly 
horrible about consistency in those areas too.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Mon Oct 13 21:00:08 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 14:00:08 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <48F3B3BB.6090602@gmail.com>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org> <48F34AE6.6060400@gmail.com>
	<20081013135756.GO13066@br-online.de> <48F360BA.7080806@gmail.com>
	<affaa1bfa86ed44a0a60a38e488537ea.squirrel@arekh.dyndns.org>
	<48F36D5A.404@gmail.com> <1223916069.3327.29.camel@luminos.localdomain>
	<48F3B3BB.6090602@gmail.com>
Message-ID: <1223931608.3327.46.camel@luminos.localdomain>

On Mon, 2008-10-13 at 15:46 -0500, Les Mikesell wrote:
> 
> Even if it is right in the long run, the point of a distribution is to 
> to protect its users from mid-release breakage.  If I wanted the 
> upstream version as-is every day, I'd download it directly myself.  I 
> expect a distribution to not break compatibility with what it packaged 
> and shipped yesterday.

You certainly have a point if we're talking about in release updates,
but not if we're talking release to release upgrades (IE 9 to 10).  We
(the Fedora project) leave it up to maintainer discretion as to what
kind of updates to bring to in release updates.  I'm pretty certain that
if we tried to be more authoritative on this front you'd find lots of
your brethren quite upset at the 'bureaucracy' getting involved.

So if you have a issue with in-release updates, you need to look no
further than the other maintainers.  This is what happens when we let
maintainers make their own decisions, for better or worse.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/03908142/attachment.sig>

From stickster at gmail.com  Mon Oct 13 21:14:42 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 13 Oct 2008 21:14:42 +0000
Subject: reviving Fedora Legacy
In-Reply-To: <20081013204919.GA28298@nostromo.devel.redhat.com>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
Message-ID: <1223932482.8602.44.camel@localhost.localdomain>

On Mon, 2008-10-13 at 16:49 -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > > Yes. There's the defined release lifespan; anything of consequence
> > > will be maintained for that period.
> > 
> > You can say that but cannot give any guarantee.
> 
> On the contrary. The Fedora project provides maintenance of the release
> for the release period. You're guaranteeing ... nothing.
> 
> > > Neither is upgrading from TurboGears to Ruby on Rails and having your app
> > > work. If you started off by choosing the wrong tool, why would you expect
> > > an upgrade to something different to work? 
> > 
> > I know about users for which Centos/RHEL is not right because it is too
> > old,
> 
> ... but then later want a longer term of support, up to 3-5 years, during
> which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
> in fact.
> 
> > technology preview in production environment and are willing to do some
> > testing and help with bugs, hence would have choosen fedora, but cannot
> > if they have to update each year.
> 
> I'm beginning to wonder if this isn't a straw horse that's being beaten to
> death.
> 
> Fedora 8's been out less a year. It has, in that timeframe, received *over
> 4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
> 
> How is upgrading to the next release really that many orders of magnitude
> more change than this?
> 
> After all, if you're on F9 you've already consumed a KDE-4.0 to KDE-4.1
> update, for example. Or kernel updates from 2.6.25 through to 2.6.27.
> Or NetworkManager updates to the current version. Or ... <insert
> changes here>...

The expectations people will undoubtedly have from this sort of extended
release maintenance will be completely out of line with what's provided.
How can you provide security updates for some of a distribution and have
it be meaningful?  What does it matter if you patch a problem in a user
application and not those in the kernel?  And how do you reconcile that
disparity with the expectations of the user of this supposedly
maintained branch, who thinks that somehow they're doing better
security-wise than if they move to a platform actively maintained by a
community, be it a current Fedora, RHEL, or CentOS?

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   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/20081013/542535c2/attachment.sig>

From cweyl at alumni.drew.edu  Mon Oct 13 21:17:01 2008
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 13 Oct 2008 14:17:01 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <20081013202231.GE2738@free.fr>
References: <20081012222613.GF2688@free.fr>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
Message-ID: <7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>

On Mon, Oct 13, 2008 at 1:22 PM, Patrice Dumas <pertusus at free.fr> wrote:
>
> On Mon, Oct 13, 2008 at 04:00:47PM -0400, Bill Nottingham wrote:
>
> > Neither is upgrading from TurboGears to Ruby on Rails and having your app
> > work. If you started off by choosing the wrong tool, why would you expect
> > an upgrade to something different to work?
>
> I know about users for which Centos/RHEL is not right because it is too
> old, fedora would suit them, if they had not to upgrade after one year.
> Currently I have to propose them to install ubuntu, because there is
> nothing in the fedora/RHEL market that suits them. Not enough power user
> for fedora updates every year, need too recent stuff for RHEL. Another
> category who be those who want to use a controlled set of next
> technology preview in production environment and are willing to do some
> testing and help with bugs, hence would have choosen fedora, but cannot
> if they have to update each year.

On this point, I know I tend to be pretty liberal with my personal
machines (and tend to keep them at the latest !rawhide), but for my
work laptop, while I run Fedora for a variety of reasons, I tend to be
pretty conservative and upgrade to the latest only when forced to by
distro EOL or some other compelling reason.  A LTS plan would make
sense for reasonable situations like this.

                                                  -Chris
--
Chris Weyl
Ex astris, scientia



From mw_triad at users.sourceforge.net  Mon Oct 13 21:41:03 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 13 Oct 2008 16:41:03 -0500
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <200810122312.16875.konrad@tylerc.org>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
	<200810122312.16875.konrad@tylerc.org>
Message-ID: <gd0f9f$q9o$1@ger.gmane.org>

Conrad Meyer wrote:
> Can any strong speaker of Spanish translate (or just summarize) this mail? (My 
> year of high school Spanish isn't helping here.)

http://translate.google.com/?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer



From benny+usenet at amorsen.dk  Mon Oct 13 21:43:12 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Mon, 13 Oct 2008 23:43:12 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223900281.6770.573.camel@macbook.infradead.org> (David
	Woodhouse's message of "Mon\, 13 Oct 2008 13\:18\:01 +0100")
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de> <20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
Message-ID: <m3od1o9nnz.fsf@ursa.amorsen.dk>

David Woodhouse <dwmw2 at infradead.org> writes:

> What I _don't_ understand is why these requirements are not met by
> CentOS. Isn't that _precisely_ the 'market' that RHEL and CentOS exist
> to serve?

RHEL and CentOS are simply too slow for some things, unless you get
very lucky and they happen to have a release at the perfect time.

Imagine starting development on something to be deployed in half a
year or a year. RHEL right now is on kernel 2.6.18. If you e.g. need
some of the many new features of netfilter since 2.6.18, you're
"stuck" with Fedora. Not that I mind in the least being stuck with
Fedora, of course.

Also, let's take Asterisk, which is included in Fedora. You get to
have 1.4.x if you use Fedora 8, and 1.6.x with Fedora 9. With EPEL,
you currently get neither, but that is relatively easy to fix. What
isn't so easy to fix is that you get either 1.4.x or 1.6.x with EPEL,
and it's a long wait for the next release of RHEL just to get a new
Asterisk. You can solve that by adding updated packages yourself, of
course, but it can easily devolve into your very own distro where RHEL
updates don't apply safely.

So I want a RHEL with a new release every 6 months and 5 years of
stability. And a pony. If I can't have that, I'd like to have whatever
updates people can be bothered to make for old Fedoras. It's ok if
they break things, it's ok if they don't manage to cover all the
updates that RHEL would have done, it's ok if everyone gives up on it
after 3 months. I'll take what I can get.


/Benny



From caolanm at redhat.com  Mon Oct 13 21:50:02 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Mon, 13 Oct 2008 22:50:02 +0100
Subject: OpenOffice and go-oo
In-Reply-To: <385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
	<1223909556.10624.131.camel@vain.rhgalway>
	<385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>
Message-ID: <1223934602.10624.179.camel@vain.rhgalway>

On Mon, 2008-10-13 at 19:16 +0300, Muayyad AlSadi wrote:
> > But rpm doesn't have any "Suggested" sort of feature, and I don't
> think
> we have comps.xml, and in comps we can put "default" packages which
> can be dropped in the livecd, but if ooo-core depends on java you
> can't drop it

That doesn't really cut it IMO. yum install ounpenoffice.org-writer
should just give you an openoffice.org writer that "just works". I'd be
massively irritated if I was to install some other package and I had to
guess as to what else should be installed to afterwards make it work
correctly.

comps.xml is nifty for the initial recommended stuff that should be
installed, but not really something that should be relied upon as a
mechanism for specifying requirements for a package that are considered
undesirable under some other specific circumstances. "Just working" is
all that I imagine j-random-user cares about as the initial position.
They may very well care that too many dependencies have been pulled in,
but their base position is that everything at least works. Not working
would be infuriating.

Now; Your focus seems that the java dependencies massively bloat OOo
requirements, and some of that is addressed by e.g. the F-10
openoffice.org-bsh split which should avoid the wearisome "OOo requires
tomecat, what a stupid program" nonsense. Some other thoughts in this
area are the large gcj aot compiled .sos that come with pretty much all
our java packages, but which are only used when gij is the
java-of-choice and not when openjdk is the java-of-choice. I'd be
interested in a solution in *that* area. i.e. right now one can install
openjdk as the default java, and then install any random java package
from fedora but are then forced to take the space hit of bringing the
gij-specific aot .sos along with then, and also then pulling libgcj back
in as a dependency of those .sos.

I would like to see OOo on the LiveCD :-), but have never gotten around
to seeing what exact space is available and what sort of cunning I could
employ to pretend to be small enough to fit, though I do feel that a
universal LiveCD for all supported languages can only work if an awful
lot of languages would play nice and not have a lot of translations or
any help files :-) The last time I checked other distributions FWIW they
simply limited OOo translations on their LiveCDs to the major ones that
would fit. Generally < "the big 12".

> but in go-oo I'm told that they have replaced some java things with
> native replacement like some graphic things for example in sun's ooo
> you need java to handle SVG in go-oo you don't
> 
> so it's NOT about leaving some un-functional things

I'm not against dropping java requirements, but I don't want to push the
burden of caring about it down to the individual users. I'm totally in
favour of non-java solutions for main-line functionality in OOo. svg
import is sort of outside the two direct immediate usage routes that do
(today) require java. Searching help, and the xsltfilter stuff are both
directly available from the UI, and both need java at the moment to work
right, and I don't think the right approach is to drop the Requires: on
them to avoid their truly-there java dependency.

C.



From pertusus at free.fr  Mon Oct 13 22:04:20 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 00:04:20 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013204919.GA28298@nostromo.devel.redhat.com>
References: <loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
Message-ID: <20081013220420.GJ2738@free.fr>

On Mon, Oct 13, 2008 at 04:49:19PM -0400, Bill Nottingham wrote:
> 
> On the contrary. The Fedora project provides maintenance of the release
> for the release period. You're guaranteeing ... nothing.

It provides maintainance, but cannot guarantee anytihng. The idea is to 
provide maintainance for the packages people are interested in providing 
maintainance.

> ... but then later want a longer term of support, up to 3-5 years, during
> which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
> in fact.

Not at all. Centos starts already old, it is very different.

> I'm beginning to wonder if this isn't a straw horse that's being beaten to
> death.
> 
> Fedora 8's been out less a year. It has, in that timeframe, received *over
> 4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
> 
> How is upgrading to the next release really that many orders of magnitude
> more change than this?

It is very different because the updates are not fundamental changes,
like those that happens between releases. You know that, don't you,
those changes that goes through rawhide.

> After all, if you're on F9 you've already consumed a KDE-4.0 to KDE-4.1
> update, for example. Or kernel updates from 2.6.25 through to 2.6.27.
> Or NetworkManager updates to the current version. Or ... <insert
> changes here>...

Sure, but not the big changes that goes between version. I am sure you
know what I am speaking about.

--
Pat



From pertusus at free.fr  Mon Oct 13 22:06:31 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 00:06:31 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223932482.8602.44.camel@localhost.localdomain>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<1223932482.8602.44.camel@localhost.localdomain>
Message-ID: <20081013220631.GK2738@free.fr>

On Mon, Oct 13, 2008 at 09:14:42PM +0000, Paul W. Frields wrote:
> 
> The expectations people will undoubtedly have from this sort of extended
> release maintenance will be completely out of line with what's provided.
> How can you provide security updates for some of a distribution and have
> it be meaningful?  What does it matter if you patch a problem in a user
> application and not those in the kernel?  And how do you reconcile that
> disparity with the expectations of the user of this supposedly
> maintained branch, who thinks that somehow they're doing better
> security-wise than if they move to a platform actively maintained by a
> community, be it a current Fedora, RHEL, or CentOS?

I cannot do anything if people don't read the pages explaining what the
project offers. Did I said something about 'doing better
security-wise than if they move to a platform actively maintained by a
community, be it a current Fedora, RHEL, or CentOS'. No.

--
Pat



From pertusus at free.fr  Mon Oct 13 22:10:48 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 00:10:48 +0200
Subject: Regarding install options
In-Reply-To: <1223930747.3327.41.camel@luminos.localdomain>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
Message-ID: <20081013221048.GL2738@free.fr>

On Mon, Oct 13, 2008 at 01:45:47PM -0700, Jesse Keating wrote:
> On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
> > I had a look recently, and I think that comps are in a good shape for
> > minimal installs. (there is an issue with anaconda deps being draggued 
> > in but it is an orthogonal issue). However chosing @core or @core +
> > @base is an unsolved (and unsolvable, in my opinion) issue.
> 
> How so?  You uncheck everything to get @core, you uncheck everything but
> the Base group to get @core + @base

It isn't what I meant, I meant it is unsolvable to tell whether minimal
is @core or @code + @base.

--
Pat



From alsadi at gmail.com  Mon Oct 13 22:11:14 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 14 Oct 2008 01:11:14 +0300
Subject: OpenOffice and go-oo
In-Reply-To: <1223934602.10624.179.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
	<1223909556.10624.131.camel@vain.rhgalway>
	<385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>
	<1223934602.10624.179.camel@vain.rhgalway>
Message-ID: <385866f0810131511s5ebd6588peda46c7dfe98cc67@mail.gmail.com>

> "Just working" is all that I imagine j-random-user cares about as the initial position.
> They may very well care that too many dependencies have been pulled in,
> but their base position is that everything at least works. Not working
> would be infuriating.

 said to make all that stuff to be the default to it will just work
and in the same time, some one who makes the livecd could drop those
extra stuff this is the point

> and some of that is addressed by e.g. the F-10
>openoffice.org-bsh split which should avoid the wearisome "OOo requires
>tomecat, what a stupid program" nonsense.

can you please make that clear for me, can I have minimal Oo.o on a
fedora-based livecd without having java on it and without exceeding
700Mb limit



> I would like to see OOo on the LiveCD :-),

I did it, I made a fedora based livecd with
openoffice.org-{writer,impress,calc} on it
http://fedoraproject.org/wiki/DerivedDistributions/LiveCDs#Ojuba_Linux

I moved away some files from ooo-core to another package so that
writer,impress and calc works without java and thus can be put into a
livecd
and with this ojuba users can happily  open .doc .rtf .odt ..etc files

but because I that on vanilla ooo many functionality could be missing
because they are java-centric, while if I build it over the go-oo it
will be perfect, so in Ojuba 2 if ooo3 is still java-centric and
ooo-core depends on java I'll base it package on go-oo which does not

> universal LiveCD for all supported languages
Ojuba is not aimed to be international, it's aimed for Arabic speakers
and Fedora is aimed to be a core that is easy for people [like me] to spin it

building OOo was a nightmare, and without mock I would never be able to build it

>favour of non-java solutions for main-line functionality in OOo. svg
>import is sort of outside the two direct immediate usage routes that do
>(today) require java. Searching help, and the xsltfilter stuff are both
>directly available from the UI, and both need java at the moment to work
>right, and I don't think the right

they only need java in vanilla ooo not in go-oo and this is the point
behind asking you to base it on go-oo
because the minimal oo.o will have more functionality and better native speed

and BTW: *filters need not be installed in the livecd



From jkeating at redhat.com  Mon Oct 13 22:36:03 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 15:36:03 -0700
Subject: Regarding install options
In-Reply-To: <20081013221048.GL2738@free.fr>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr> <1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
Message-ID: <1223937363.3056.10.camel@luminos.localdomain>

On Tue, 2008-10-14 at 00:10 +0200, Patrice Dumas wrote:
> On Mon, Oct 13, 2008 at 01:45:47PM -0700, Jesse Keating wrote:
> > On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
> > > I had a look recently, and I think that comps are in a good shape for
> > > minimal installs. (there is an issue with anaconda deps being draggued 
> > > in but it is an orthogonal issue). However chosing @core or @core +
> > > @base is an unsolved (and unsolvable, in my opinion) issue.
> > 
> > How so?  You uncheck everything to get @core, you uncheck everything but
> > the Base group to get @core + @base
> 
> It isn't what I meant, I meant it is unsolvable to tell whether minimal
> is @core or @code + @base.

Right, because "minimal" is defined in the eye of the installer, IE the
person doing the installing.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/8f72fedf/attachment.sig>

From mark.bidewell at alumni.clemson.edu  Mon Oct 13 22:43:21 2008
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Mon, 13 Oct 2008 18:43:21 -0400
Subject: Running Fedora 10 Beta in KVM
Message-ID: <bfdeacfa0810131543s2bbd3de4rd0de07130d39b0eb@mail.gmail.com>

Is anyone running the Fedora 10 Beta in KVM?  I am using KVM-77 and Fedora
10 Install either loses Keyboard and/or mouse and will lock up part way
through the install. Text mode install cannot see the harddrive?  Has anyone
else seen this?

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/edc1e83b/attachment.htm>

From opensource at till.name  Mon Oct 13 22:45:03 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 00:45:03 +0200
Subject: Regarding install options
In-Reply-To: <1223911751.3327.15.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
Message-ID: <200810140045.20715.opensource@till.name>

On Mon October 13 2008, Jesse Keating wrote:
> On Mon, 2008-10-13 at 09:29 +0200, Ralf Corsepius wrote:
> > You are nit-picking at words.
>
> As was everybody who ever complained about the "minimal" install option
> we had.
>
> > Though a Fedora installation with yum + rpm isn't "truely minimal", it's
> > the minimal install to keep an installation usable/maintainable.
>
> Which is useful to some, too fat for others.

Can we make it possible to easily select the following four minimal sets? E.g. 
hide the first three a little and print a warning dialog when one selects 
them?

minimal-bootable: A Fedora systems that boots and allows to login via text or 
serial console and install software via rpm.

minimal-rpm: minimal-bootable + rpm

minimal-yum: A Fedora system that has also yum installed

It should be also easy to add support for ethernet network or have at least 
ethernet network support and make it easy to also select dial up and wireless 
support.

minimal-suggested: The current minimal possible set

Is it possible to design these sets for anaconda without recreating a boot 
image, but only e.g. pointing it to an external repo that only contains comps 
information?

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/20081014/4afa45c1/attachment.sig>

From jkeating at redhat.com  Mon Oct 13 22:50:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Oct 2008 15:50:54 -0700
Subject: Regarding install options
In-Reply-To: <200810140045.20715.opensource@till.name>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<200810140045.20715.opensource@till.name>
Message-ID: <1223938254.3056.12.camel@luminos.localdomain>

On Tue, 2008-10-14 at 00:45 +0200, Till Maas wrote:
> Is it possible to design these sets for anaconda without recreating a boot 
> image, but only e.g. pointing it to an external repo that only contains comps 
> information?

I think you'd have a lot of "fun" trying to get the UI right for your
suggestion, but as far as working with install sets vs install media,
you can boot install media with repo=<something> and it will look to
that repo for it's package information (including group information, and
what a "default" install is) rather than the media itself, or any
default repo path on the media.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/46fab549/attachment.sig>

From poelstra at redhat.com  Mon Oct 13 22:52:01 2008
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 13 Oct 2008 15:52:01 -0700
Subject: Fedora Release Engineering Meeting Recap 2008-10-13 
Message-ID: <48F3D111.105@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-oct-13

Please make corrections and clarifications to the wiki page.

== F10 Snapshot 1 ==
* regression in installer so no DVDs
** cd-rom media testing fix didn't make it and dhcp was broken again
* 500 tracked downloads of live images
* concerns about torrent performance
* DECISION: f13 will work with dgilmore and nirik to get additional 
seeders in place for the next snapshot release

== F10 Snapshot 2 ==
* Goes out end of this week
* ACTIONS:
*# create F10Snap2 tracker
*# migrage F10Snap1 issues to F10Snap2
*# produce full install tree and get pre-testing on it

== Package Signing ==
* rough sketch of signing appliance:
** Networkless appliance connected via serial/usb/whatever
** Send data to system, it returns signature for data from given key
** Use of multilevel pins, one for admin, one for use of keys
** Upload new firmware via usb/serial, not network.
** Interact with gnupg and one I'm still not quite sure about
** Sign binaries approved to use in automated ways with system for signing
** In essence we need a box that isn't connected to anything else but 
our signing host
* ACTIONS:
*# f13 to document current setup
*# sgrubb to coordinate resources to start scoping out
*# sgrubb to rediscuss at next meeting

== MinGW Repos ==
* reviewed the amount of work necessary to support MinGW built packages 
in their own repo and determine whether it's "worth" the work
* built packages are installable and usable under fedora (with wine, or 
if you're compiling something that BuildRequires them)
** example: 
http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html 

* CONCLUSION:
** A lot of work to get these packages in their own repo with little 
perceived benefit
** Report back to Fedora Board:
*#Release Engineering believes the return on investment for making a 
separate repo for MinGW built packages is too low and the amount of work 
too high at the present time.
*#Release Engineering believes this issue would be worth revisiting in 
the future if space becomes an issue in the future

== Open Discussion ==
* See IRC Transcript

== IRC Transcript ==




From konrad at tylerc.org  Mon Oct 13 23:36:58 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 13 Oct 2008 16:36:58 -0700
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <gd0f9f$q9o$1@ger.gmane.org>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
	<200810122312.16875.konrad@tylerc.org> <gd0f9f$q9o$1@ger.gmane.org>
Message-ID: <200810131636.58239.konrad@tylerc.org>

On Monday 13 October 2008 02:41:03 pm Matthew Woehlke 
<mw_triad at users.sourceforge.net> wrote:
> Conrad Meyer wrote:
> > Can any strong speaker of Spanish translate (or just summarize) this
> > mail? (My year of high school Spanish isn't helping here.)
>
> http://translate.google.com/?

I'm sorry, but Google translate isn't 'a strong speaker of Spanish'. I 
appreciate Martin Langhoff's concise summary.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From casimiro.barreto at gmail.com  Mon Oct 13 23:49:27 2008
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Mon, 13 Oct 2008 20:49:27 -0300
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <gd0f9f$q9o$1@ger.gmane.org>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>	<200810122312.16875.konrad@tylerc.org>
	<gd0f9f$q9o$1@ger.gmane.org>
Message-ID: <48F3DE87.6050905@gmail.com>

Matthew Woehlke escreveu:
> Conrad Meyer wrote:
>> Can any strong speaker of Spanish translate (or just summarize) this
>> mail? (My year of high school Spanish isn't helping here.)
>
> http://translate.google.com/?
>
That would be something like "allways the same stuff"
In Portuguese: "sempre a mesma coisa"

Gives the idea that conversation is going in circles. Something boring.


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

From mw_triad at users.sourceforge.net  Tue Oct 14 00:13:53 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 13 Oct 2008 19:13:53 -0500
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <200810131636.58239.konrad@tylerc.org>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>	<200810122312.16875.konrad@tylerc.org>
	<gd0f9f$q9o$1@ger.gmane.org> <200810131636.58239.konrad@tylerc.org>
Message-ID: <gd0o81$3ns$1@ger.gmane.org>

(Ahem. Please do not quote my e-mail address unobfuscated in message 
bodies. Thank you.)

Conrad Meyer wrote:
> On Monday 13 October 2008 02:41:03 pm Matthew Woehlke wrote:
>> Conrad Meyer wrote:
>>> Can any strong speaker of Spanish translate (or just summarize) this
>>> mail? (My year of high school Spanish isn't helping here.)
>> http://translate.google.com/?
> 
> I'm sorry, but Google translate isn't 'a strong speaker of Spanish'.

Maybe not "strong", but if it wasn't sufficient to get the gist, perhaps 
you should mention that in your request?

> I appreciate Martin Langhoff's concise summary.

Sure, and I have no complaints about it. I was merely pointing out a 
useful tool that you seemed to be unaware of; "for future reference" as 
it were.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer



From martin.langhoff at gmail.com  Tue Oct 14 00:21:27 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Tue, 14 Oct 2008 13:21:27 +1300
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <200810131636.58239.konrad@tylerc.org>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
	<200810122312.16875.konrad@tylerc.org> <gd0f9f$q9o$1@ger.gmane.org>
	<200810131636.58239.konrad@tylerc.org>
Message-ID: <46a038f90810131721o2747aaf9n8dd43d66d94bad14@mail.gmail.com>

On Tue, Oct 14, 2008 at 12:36 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> I'm sorry, but Google translate isn't 'a strong speaker of Spanish'. I
> appreciate Martin Langhoff's concise summary.

You're welcome :-) The problem is not that google is not a "strong
speaker of Spanish", but that it's not a speaker of strongly-worded
flaming Spanish.

The tone starts with the subject ("always the same with you guys!"),
it's written in rather colloquial Spanish from Buenos Aires (my
hometown) with some *very* rude bits. Why is he upset? Unclear. He
mentions filing a bug against F10 and then being told that it's too
late / won't make it to F10, and so he rails about devs arguing
technical stuff and politics instead of fixing bugs.

He doesn't tell us which bug -- that could make the msg more useful.

I hadn't read such colourful (rude!) colloquialisms for a while. Amusing.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From notting at redhat.com  Tue Oct 14 00:36:50 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 13 Oct 2008 20:36:50 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081013220420.GJ2738@free.fr>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
Message-ID: <20081014003650.GB30302@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> > On the contrary. The Fedora project provides maintenance of the release
> > for the release period. You're guaranteeing ... nothing.
> 
> It provides maintainance, but cannot guarantee anytihng.

Be realistic. If we didn't de-facto guarantee that we'd provide security
updates during the specified lifespan for all relevant packages, we woudn't
have a viable distribution.

> The idea is to 
> provide maintainance for the packages people are interested in providing 
> maintainance.

I know exactly what you're proposing, you don't need to restate it. I just
think it's a fundamentally bad idea that actively harms users by giving
them an open-ended rope to hang themselves with, which doesn't at all claim
to cover their entire system, as opposed to the clear support and
maintenance they have now.

To put it a different way - would you buy a car whose extended warranty
won't tell you what it covers, or for how long, and tells you it's subject
to change *AT ANY TIME*? If so, I think I've got some cars to sell you.

You want me to support your plan? Cover the entire distribution, for a
specified period of time. Simple, right?

> > ... but then later want a longer term of support, up to 3-5 years, during
> > which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
> > in fact.
> 
> Not at all. Centos starts already old, it is very different.

How so? When Centos 5/RHEL 5 is released, it's pretty much up to date, or
at least within 6 months. If you're looking for a 3-5 year lifespan (which
you said your goal is), that's nothing. And halfway or so through your
proposed arrangement, your release would be just as old and outdated
as an equivalent RHEL release of the same vintage.

> > How is upgrading to the next release really that many orders of magnitude
> > more change than this?
> 
> It is very different because the updates are not fundamental changes,
> like those that happens between releases. You know that, don't you,
> those changes that goes through rawhide.

... how so? There's a ton of changes between kernel-2.6.25 and kernel-2.6.27.
KDE-4.1 is a fairly big step from KDE-4.0. The entirety of system
network configuration support was added between F8 GA NetworkManager
and the F8 updates version.

Is it *all* of the large changes? No. But it's more than you'd think.
Moreover, exactly which of these big changes break people? Is
rhgb -> plymouth a big change? Sure. Does it actively break third-party
applications or development? No.

Honestly, I think a whole lot more of the work here is best done:
- promoting RHEL/CentOS as the alternative for users who need longer support
- making distribution upgrades seamless and easy

Bill



From mw_triad at users.sourceforge.net  Tue Oct 14 00:44:17 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 13 Oct 2008 19:44:17 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <20081014003650.GB30302@nostromo.devel.redhat.com>
References: <48F288A3.8000601@shmuelhome.mine.nu>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<20081013192104.GB27065@nostromo.devel.redhat.com>	<20081013195507.GC2738@free.fr>	<20081013200047.GC27065@nostromo.devel.redhat.com>	<20081013202231.GE2738@free.fr>	<20081013204919.GA28298@nostromo.devel.redhat.com>	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
Message-ID: <gd0q11$6ns$1@ger.gmane.org>

Bill Nottingham wrote:
> To put it a different way - would you buy a car whose extended warranty
> won't tell you what it covers, or for how long, and tells you it's subject
> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.

Have you ever bought a used car?

People drive cars not under warranty because they know that, if 
something goes wrong, they can either fix it themselves (for those who 
are hobby mechanics) or pay someone to fix it. The same goes for a 
distro; if you need an update and there is no support, you can always 
build it yourself or pay someone to build it for you (which is, after 
all, sort of the point of Free Software).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer



From jwboyer at gmail.com  Tue Oct 14 00:51:13 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 13 Oct 2008 20:51:13 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <gd0q11$6ns$1@ger.gmane.org>
References: <604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
	<gd0q11$6ns$1@ger.gmane.org>
Message-ID: <20081014005113.GB3258@vader.jdub.homelinux.org>

On Mon, Oct 13, 2008 at 07:44:17PM -0500, Matthew Woehlke wrote:
> Bill Nottingham wrote:
>> To put it a different way - would you buy a car whose extended warranty
>> won't tell you what it covers, or for how long, and tells you it's subject
>> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
>
> Have you ever bought a used car?
>
> People drive cars not under warranty because they know that, if  
> something goes wrong, they can either fix it themselves (for those who  
> are hobby mechanics) or pay someone to fix it. The same goes for a  
> distro; if you need an update and there is no support, you can always  
> build it yourself or pay someone to build it for you (which is, after  
> all, sort of the point of Free Software).

Thank you for providing the analogy that proves the Fedora project
(the car dealership here) does not need to provide an LTS because the
consumers (the Fedora users) can fix things themselves.

josh



From jwboyer at gmail.com  Tue Oct 14 00:47:54 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 13 Oct 2008 20:47:54 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
References: <loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
Message-ID: <20081014004747.GA3258@vader.jdub.homelinux.org>

On Mon, Oct 13, 2008 at 02:17:01PM -0700, Chris Weyl wrote:
>> I know about users for which Centos/RHEL is not right because it is too
>> old, fedora would suit them, if they had not to upgrade after one year.
>> Currently I have to propose them to install ubuntu, because there is
>> nothing in the fedora/RHEL market that suits them. Not enough power user
>> for fedora updates every year, need too recent stuff for RHEL. Another
>> category who be those who want to use a controlled set of next
>> technology preview in production environment and are willing to do some
>> testing and help with bugs, hence would have choosen fedora, but cannot
>> if they have to update each year.
>
>On this point, I know I tend to be pretty liberal with my personal
>machines (and tend to keep them at the latest !rawhide), but for my
>work laptop, while I run Fedora for a variety of reasons, I tend to be
>pretty conservative and upgrade to the latest only when forced to by
>distro EOL or some other compelling reason.  A LTS plan would make
>sense for reasonable situations like this.

No, it wouldn't.

(I know you know that I know what you know so you should know what
I know and I know there are other options and I know that you know
that.)

josh



From cra at WPI.EDU  Tue Oct 14 01:17:43 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 13 Oct 2008 21:17:43 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081014005113.GB3258@vader.jdub.homelinux.org>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
	<gd0q11$6ns$1@ger.gmane.org>
	<20081014005113.GB3258@vader.jdub.homelinux.org>
Message-ID: <20081014011743.GA27052@angus.ind.WPI.EDU>

On Mon, Oct 13, 2008 at 08:51:13PM -0400, Josh Boyer wrote:
> On Mon, Oct 13, 2008 at 07:44:17PM -0500, Matthew Woehlke wrote:
> > Bill Nottingham wrote:
> >> To put it a different way - would you buy a car whose extended warranty
> >> won't tell you what it covers, or for how long, and tells you it's subject
> >> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
> >
> > Have you ever bought a used car?
> >
> > People drive cars not under warranty because they know that, if  
> > something goes wrong, they can either fix it themselves (for those who  
> > are hobby mechanics) or pay someone to fix it. The same goes for a  
> > distro; if you need an update and there is no support, you can always  
> > build it yourself or pay someone to build it for you (which is, after  
> > all, sort of the point of Free Software).
> 
> Thank you for providing the analogy that proves the Fedora project
> (the car dealership here) does not need to provide an LTS because the
> consumers (the Fedora users) can fix things themselves.

And why shouldn't the Fedora project provide a place for the consumers 
who fixed things themselves to share with those who can't fix things?



From rc040203 at freenet.de  Tue Oct 14 01:33:30 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 03:33:30 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <604aa7910810130925t649ebf01vff54dca734d748c4@mail.gmail.com>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<604aa7910810130925t649ebf01vff54dca734d748c4@mail.gmail.com>
Message-ID: <1223948010.3029.136.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 08:25 -0800, Jeff Spaleta wrote:
> On Sun, Oct 12, 2008 at 5:40 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> > Why would we want to? Just let things going as long as there is at least one
> > maintainer committing something. Even if not all security issues get fixed,
> > it's better than if none gets fixed.
> 
> 
> Ha!  Keeping a branch open because one maintainer interested in
> something.  That's not a distribution. That's a personal respository.
Nonsense - Such a strategy would not be any different from how Fedora
works now.

Ralf





From notting at redhat.com  Tue Oct 14 01:41:07 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 13 Oct 2008 21:41:07 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <gd0q11$6ns$1@ger.gmane.org>
References: <604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
	<gd0q11$6ns$1@ger.gmane.org>
Message-ID: <20081014014106.GA1315@nostromo.devel.redhat.com>

Matthew Woehlke (mw_triad at users.sourceforge.net) said: 
> Bill Nottingham wrote:
>> To put it a different way - would you buy a car whose extended warranty
>> won't tell you what it covers, or for how long, and tells you it's subject
>> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
>
> Have you ever bought a used car?
>
> People drive cars not under warranty because they know that, if  
> something goes wrong, they can either fix it themselves (for those who  
> are hobby mechanics) or pay someone to fix it. The same goes for a  
> distro; if you need an update and there is no support, you can always  
> build it yourself or pay someone to build it for you (which is, after  
> all, sort of the point of Free Software).

Right, that's what we have now. What he's suggesting is some sort
of 'other' warranty that can expire at any time, and which packages/
parts of the car are covered can change at any time. I know of *no one*
who gets that sort of warranty.

Bill



From rc040203 at freenet.de  Tue Oct 14 01:59:48 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 03:59:48 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013143518.GA28184@yoda.jdub.homelinux.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<1223907160.3029.109.camel@beck.corsepiu.local>
	<20081013141451.GB9793@yoda.jdub.homelinux.org>
	<1223907829.3029.118.camel@beck.corsepiu.local>
	<20081013143518.GA28184@yoda.jdub.homelinux.org>
Message-ID: <1223949588.3029.148.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 10:35 -0400, Josh Boyer wrote:
> On Mon, Oct 13, 2008 at 04:23:49PM +0200, Ralf Corsepius wrote:
> >On Mon, 2008-10-13 at 10:14 -0400, Josh Boyer wrote:
> >> On Mon, Oct 13, 2008 at 04:12:40PM +0200, Ralf Corsepius wrote:

> >Alternative: Officially extend Fedora life-times.
> 
> This is not an alternative to the above. 
Why not?

Other distros apply much longer life-times.

openSUSE has 2 years:
http://lists.opensuse.org/opensuse-announce/2008-10/msg00000.html

> >Alternative: Discontinue EPEL and replace it a full RHEL/CentOS
> >derivative as part of Fedora.
> 
> I think if you remove the RHEL part of this, it makes some sense.
> I doubt Red Hat is going to sign up for support of all the EPEL
> packages, so they will never be part of RHEL proper.
Agreed.

Ralf





From cweyl at alumni.drew.edu  Tue Oct 14 02:39:23 2008
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 13 Oct 2008 19:39:23 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <20081014004747.GA3258@vader.jdub.homelinux.org>
References: <loom.20081012T230422-741@post.gmane.org>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
	<20081014004747.GA3258@vader.jdub.homelinux.org>
Message-ID: <7dd7ab490810131939u174eaa67l87a3071f96500a69@mail.gmail.com>

On Mon, Oct 13, 2008 at 5:47 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Mon, Oct 13, 2008 at 02:17:01PM -0700, Chris Weyl wrote:
>>> I know about users for which Centos/RHEL is not right because it is too
>>> old, fedora would suit them, if they had not to upgrade after one year.
>>> Currently I have to propose them to install ubuntu, because there is
>>> nothing in the fedora/RHEL market that suits them. Not enough power user
>>> for fedora updates every year, need too recent stuff for RHEL. Another
>>> category who be those who want to use a controlled set of next
>>> technology preview in production environment and are willing to do some
>>> testing and help with bugs, hence would have choosen fedora, but cannot
>>> if they have to update each year.
>>
>>On this point, I know I tend to be pretty liberal with my personal
>>machines (and tend to keep them at the latest !rawhide), but for my
>>work laptop, while I run Fedora for a variety of reasons, I tend to be
>>pretty conservative and upgrade to the latest only when forced to by
>>distro EOL or some other compelling reason.  A LTS plan would make
>>sense for reasonable situations like this.
>
> No, it wouldn't.
>
> (I know you know that I know what you know so you should know what
> I know and I know there are other options and I know that you know
> that.)

I know :)  But, along those lines you know it's not that clear cut... ya know?

But this isn't really about other options, whether they be centos/rhel
or ubuntu/debian or slackware or gentoo, this is about people who
choose to use Fedora.  What does it say about freedom, when we say
"Use Fedora and be free! ...except, you know, how you want to."  Why
are we spending so much time and effort saying no, instead of getting
out of the way of those who are interested in doing it and watching it
succeed or fail on its merits?

                                  -Chris
-- 
Chris Weyl
Ex astris, scientia



From rc040203 at freenet.de  Tue Oct 14 02:40:14 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 04:40:14 +0200
Subject: Regarding install options
In-Reply-To: <1223911751.3327.15.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
Message-ID: <1223952014.3029.166.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 08:29 -0700, Jesse Keating wrote:
> On Mon, 2008-10-13 at 09:29 +0200, Ralf Corsepius wrote:
> > You are nit-picking at words.
> 
> As was everybody who ever complained about the "minimal" install option
> we had.
> 
> > 
> > Though a Fedora installation with yum + rpm isn't "truely minimal", it's
> > the minimal install to keep an installation usable/maintainable.
> 
> Which is useful to some, too fat for others.
Well, to me a "no-yum" installation is an ignorable extremal singular
case.

> > And yes, the fact yum pulls in python is a real problem on small
> > systems. Even worse are the system-config-* tools, most of which pull in
> > many more packages and don't even work without X.
> > 
> > >   Congratulations you've just walked
> > > into a decade + argument.
> > I don't see this.
> 
> Probably because you haven't been on the front line, taking the bug
> reports, talking to users at events,
Right.

>  trying to tweak the targets to
> match expectation and continually failing because there is no singular
> expectation.
Right, there is no singular expectation. But what Fedora currently
offers is not even an approximation of a minimal install.

What I am looking for as "minimal install", is a default configuration,
which is just sufficient to boot up into a root shell and launch yum,
such one can start to taylor an install set to personal demands.

Ralf




From martin.langhoff at gmail.com  Tue Oct 14 03:31:20 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Tue, 14 Oct 2008 16:31:20 +1300
Subject: Regarding install options
In-Reply-To: <1223938254.3056.12.camel@luminos.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<200810140045.20715.opensource@till.name>
	<1223938254.3056.12.camel@luminos.localdomain>
Message-ID: <46a038f90810132031v19e2606cx123fa72dccbe7b10@mail.gmail.com>

2008/10/14 Jesse Keating <jkeating at redhat.com>:
> On Tue, 2008-10-14 at 00:45 +0200, Till Maas wrote:
>> Is it possible to design these sets for anaconda without recreating a boot
>> image, but only e.g. pointing it to an external repo that only contains comps
>> information?

Even working with anaconda and doing your own spins with revisor it's
not easy to get a slim F9 install. It's almost impossible to shed the
gtk/xorg toolchain because anaconda pulls it in.

> I think you'd have a lot of "fun" trying to get the UI right for your
> suggestion,

Other distros I use offer this ("desktop install", "server install"
radio buttons) instead of the current anaconda sets, and hide the
comps groups behind an 'advanced' option. The server install does
_not_ install X.

And on a different email, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> > Though a Fedora installation with yum + rpm isn't "truely minimal", it's
>> > the minimal install to keep an installation usable/maintainable.
>>
>> Which is useful to some, too fat for others.
>
> Well, to me a "no-yum" installation is an ignorable extremal singular
> case.

The embedded devices crowd uses this kind of install ("no yum, no rpm
even") quite a bit, and they have a lot of overlap with the "headless
server" crowd in interests. So if you don't ignore that requirement,
you get a larger community of users/developers with a significant
overlap with your interests :-)

Even if each group thinks that the other is crazy... the overlap is
significant, and both can feed off each other.

Note! I am not arguing that such "no yum" option needs to be available
from the GUI anaconda installer. That'd be pointless. I just say that
it should be possible and at least somewhat supported via anaconda in
combination with revisor or pungi.

Right now it does not seem to be.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From rc040203 at freenet.de  Tue Oct 14 03:39:11 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 05:39:11 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
Message-ID: <1223955551.3029.219.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
> > > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote:
> > > > > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > > > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote:
> > > > > >> Dmitry Butskoy wrote:
> > > > > >> > Itamar - IspBrasil wrote:
> > > > > [snip]
> > > > > >> The fact that they switched to CentOS is *good* for Fedora.
> > > > > > I can not disagree more - To me, it's yet another evidence of Fedora
> > > > > > being on the loose.
> > > > > 
> > > > > You're going to have to expound on that. I do not see Centos in any
> > > > > way as in competition with Fedora.
> > > 
> > > > EPEL drains away resources from Fedora.

> > > > >  Centos is something everyone should be proud of.
> 
> > > > Well, to me CentOS is as important as any other arbitrary Linux distro.
> > > > I am glad they are around, but not more and not less.
> 
> > > It is around becase RHEL is popular, and open source.
> 
> > And non-free
> 
> It /is/ free... you pay for support only.
Wrong. RHEL is opensource, but it is not free. You can't get RHEL
binaries anywhere.

> 
> >              - If it was free, the CentOS folks could start directly
> > contribute to Fedora
> 
> No...
Why not? CentOS would go out of business, because RH binaries could be
used instead => their resources would be freed.

> > > > > >> CentOS's goals are better oriented to the needs of someone 
> > > > > >> that wants to deploy a system and run it for years. Fedora is
> > > > > >> good for people who want to get the latest technologies from
> > > > > >> upstream as soon as they're stable enough to integrate into a
> > > > > >> running system.
> 
> > > > > > Right. But why can't Fedora do better?
> 
> Define "better"... "Good Fedora" is bleeding edge, not fully stabilized
> software, experimental stuff that may pan out (or it might not, being
> replaced by something else), changing APIs (literally and sysadmin-wise),
> fast turnaround.
Yes, this is what it is supposed to be. Unfortunately this doesn't
apply. 

Current Fedora isn't much more than a single-user desktop-focused RH
development/rawhide snapshot.

> > > > > >                                        I feel Fedora could do better.
> 
> > > > > Sure. With more devs, servers, time, etc.
> 
> > > > ... less bureaucracy, less committees/less chiefs/more Indians,
> > > > different people, different strategies.
> 
> > > Show how!
> 
> > Ease reviews, bodhi, packagedb, koji, bugzilla, track, re-consider FTBS,
> > work-flow, trademark policy. 
> 
> Definite proposals that can be discussed?
> 
> What does "trademark policy" have to do with anything, BTW?
A lot.

> > E.g. right now, the tools being in use are a heterogenious mixture of
> > separate tools,
> 
> Unix...
My point is: Lack of integration and them being over-loaded with
features.

> >                 are often broken,
> 
> Fixing hands are presumably wellcome...
Well, ...

> >                                   are far from easy to use
> 
> Concrete proposals on what to change how?
Many, many tiny details. In fact, there are tons of usability issues
with all of them.

One pretty obvious example: bugzilla. 
IMO, it has never been less usable than it is now. It isn't possible
anymore to reopen bugs, automatic CC:-adding when commenting to BZs,
many lists are hidden in dropdowns, tags have changes (assignee), FTBS
activities have rendered bugzilla "unsearchable", flagged review stuff,
etc.

> >                                                            and aim at
> > implementing a highly bureaucratic process/work-flow.
> 
> Again, proposals, please?
E.g.: Work-flow: branch fc11 early (discussed and shot down last week).

> > >  Telling everybody here how awful things are going isn't helping
> > > an iota. Everything has its limits, and for every desirable quality (newest
> > > shiny toys, support for the newest fad in hardware in software) there is a
> > > cost (can't be supported in the long range, fast turnaround, set procedures
> > > to handle a huge stream of new stuff)
> > > 
> > > > >  But baring a sudden increase
> > > > > in those, I would much prefer to see Fedora focus on dev and testing,
> > > > > let other distros pretty things up.
> > > 
> > > > ACK. Unfortunately, Fedora is drifting away from this group towards
> > > > single-user desktops (e.g. OLPC).
> > > 
> > > Then work towards drifting the opposite direction...
> 
> > One reason why I am agitating ...
> 
> "Agitating" doesn't help much.
Of cause it does. It help making people aware about problems.

> > > Fedora (or any other large group of people) will move where the majority
> > > wants to go... 
> 
> > Well, deployment of an OS to servers, will always be a "minority use
> > case" and will always collide somewhere with mere desktop oriented
> > developments.
> 
> So?
Examples: NetworkManager, PulseAudio, setroubleshoot, SELinux-policies,
PackageKit, defaults ...

> > > > > Why would they, after often suggesting that Fedora _not_ be used on
> > > > > production servers, use Fedora on their production servers?
> 
> > > > Depends on how they mean it:
> > > > - if they are referring to "long term maintained/everlasting support"
> > > > servers, they are right.
> 
> > > "Servers" are "long-time maintained" by definition...
> 
> > To me, "server" is a "use-case of an OS" and is not at all connected to
> > running the same OS for many years. 
> 
> That is "testing an OS with server workload", something different entirely.
Just because some piece of hardware is labeled "server" or caged into a
rack, doesn't make it a "server".

A server is a use-case of software, the hardware doesn't actually
matter.

> > Yes, no doubt, running the same OS on a larger number of machines for a
> > longer time helps maintenance, but I do not see how this is connected to
> > a particular machine serving as "clients" or "servers".
> > 
> > Yes, no doubt, there are use-cases where "long-term API" stability is
> > important, but this applies to client use-cases as well as to server
> > use-cases.
> 
> Those /are/ the "server" use cases you want so badly!
NO! I am talking about file-, yp/ldap-, nfs-, print-, streaming-, audio
(mpd etc.)-, video-, VCS (CVS, svn, git, etc.)-, http-, SQL (postgres,
mysql, etc.)- servers and similar.

> > Finally, yes, no doubt, Fedora is not the "shoe that fits all sizes" nor
> > are CentOS or RHEL, but ... this doesn't mean that Fedora may not be
> > applicable to server scenarios.
> > 
> > > > - if they mean it as "Fedora is technically too unstable",
> > > 
> > > Because there is no "long term maintenance"...
> 
> > Again, I don't see how "lack of stability" and "no long term
> > maintenance" are linked together at all, nor how server and client
> > use-cases matter.
> 
> Again: "stability" is /not/ "when run on 10 thousand machines only one
> crashes a day", it is "runs for thousands of days before crashing", and
> /that/ is as un-Fedora as it gets.
Again: server is a use-case of SW. Like on desktops, I can live with
rebooting once a week due to kernel updates and don't need 1000hrs of
uptimes nor do I have 1000s of users nor machines.


> > What matters in use-cases of short lived-distros such as Fedora is:
> > Upgrades "must simply work" and (admin-) personnel must be able to
> > handle them in a particular scenario.
> 
> Sure. Test upgrading for a few months until everything is A-OK,
No, rolling release, respun distros. 


> > Lack of stability,
> 
> Design objective.
No, mismanagement, lack of QA

> >                                              ... tools
> 
> Huh?
koji, bodhi, bugzilla, packagedb ...

One detail: The amount of administration emails I am receiving from
koji, bodhi, packagedb: Often, several 1000s per month.

> > The lack of people to me is not a cause, it's a consequence of mistakes
> > in Fedora's history.
> 
> Is there /really/ a lack of people?
Yes, all over the place.

Examples:
* reviews
* Fedora infrastructure "wining" on "lack of people"
* Fedora infrastructure "signing" issues.

>  Are any statistics of contributors (and
> contributions) at hand?
None that I am aware about. 

Ralf






From rc040203 at freenet.de  Tue Oct 14 03:43:05 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 05:43:05 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810130816q521271c9q49bfa9e83825ee61@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<48F35E2E.8010507@gmail.com>
	<935ead450810130816q521271c9q49bfa9e83825ee61@mail.gmail.com>
Message-ID: <1223955785.3029.224.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 10:16 -0500, Jeffrey Ollie wrote:
> On Mon, Oct 13, 2008 at 9:41 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> > Jeffrey Ollie wrote:
> >>
> >> Long term stability is achieved by *NOT ADDING NEW FEATURES*.  *ADDING
> >> NEW FEATURES INTRODUCES NEW BUGS*
> >
> > But that's generally an upstream issue. The bugs get fixed upstream but in
> > general the new releases aren't included in RHEL/Centos updates even after
> > the updated program becomes less buggy that the shipped version. (Firefox
> > and OO being recent, rare exceptions).
> 
> Unfortunately, upstream developers don't always release bugfix-only
> releases.  Many times they introduce new features or change the
> behavior of old features.
Right, and how do you expect EPEL to handle this issue?

I would expect EPEL to starve out contributors during RHEL's long time
time and those who will try to continue supporting it, will be facing
the problems you described.

May-be I missed it, but I would like to hear about EPEL's visions on
this matter.

Ralf






From rc040203 at freenet.de  Tue Oct 14 03:46:46 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 05:46:46 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081014011743.GA27052@angus.ind.WPI.EDU>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
	<gd0q11$6ns$1@ger.gmane.org>
	<20081014005113.GB3258@vader.jdub.homelinux.org>
	<20081014011743.GA27052@angus.ind.WPI.EDU>
Message-ID: <1223956006.3029.227.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 21:17 -0400, Chuck Anderson wrote:
> On Mon, Oct 13, 2008 at 08:51:13PM -0400, Josh Boyer wrote:
> > On Mon, Oct 13, 2008 at 07:44:17PM -0500, Matthew Woehlke wrote:
> > > Bill Nottingham wrote:
> > >> To put it a different way - would you buy a car whose extended warranty
> > >> won't tell you what it covers, or for how long, and tells you it's subject
> > >> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
> > >
> > > Have you ever bought a used car?
> > >
> > > People drive cars not under warranty because they know that, if  
> > > something goes wrong, they can either fix it themselves (for those who  
> > > are hobby mechanics) or pay someone to fix it. The same goes for a  
> > > distro; if you need an update and there is no support, you can always  
> > > build it yourself or pay someone to build it for you (which is, after  
> > > all, sort of the point of Free Software).
> > 
> > Thank you for providing the analogy that proves the Fedora project
> > (the car dealership here) does not need to provide an LTS because the
> > consumers (the Fedora users) can fix things themselves.
> 
> And why shouldn't the Fedora project provide a place for the consumers 
> who fixed things themselves to share with those who can't fix things?

Exactly! Wasn't this the original idea behind Fedora?

Ralf




From behdad at behdad.org  Tue Oct 14 03:51:05 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Mon, 13 Oct 2008 23:51:05 -0400
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <20081012201102.GB2688@free.fr>
References: <20081012134001.GC2700@free.fr>
	<48F21BB3.9060509@x-tnd.be>	<48F22D29.90109@gmail.com>
	<20081012201102.GB2688@free.fr>
Message-ID: <48F41729.30606@behdad.org>

> On Sun, Oct 12, 2008 at 10:00:25AM -0700, Toshio Kuratomi wrote:
>> When I brought this up, Bastien Nocera brought up security bugs and not
>> wanting random people to be CC'd before a security bug is resolved.  How
>> should we deal with this?


I think the correct way to deal with this is that watchbugzilla should not
automatically CC user to bugs for the component, but instead modify the user's
 bugzilla account to watch some special address like, eg for package pango,
pango-bugs at fedora.bugs.  And the product pango changed to have
pango-bugs at fedora.bugs as default assignee or Q/A contact.  This way we avoid
the security problem issue, as well as those inbox-filling mass changes to
remove people from CC lists or to change default assignee of the product.

My 0.02CAD,
behdad



From peter at thecodergeek.com  Tue Oct 14 04:02:06 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Mon, 13 Oct 2008 21:02:06 -0700
Subject: Siempre lo mismo con ustedes...
In-Reply-To: <46a038f90810131721o2747aaf9n8dd43d66d94bad14@mail.gmail.com>
References: <91914.61356.qm@web52408.mail.re2.yahoo.com>
	<200810122312.16875.konrad@tylerc.org> <gd0f9f$q9o$1@ger.gmane.org>
	<200810131636.58239.konrad@tylerc.org>
	<46a038f90810131721o2747aaf9n8dd43d66d94bad14@mail.gmail.com>
Message-ID: <1223956926.3262.22.camel@tuxhugs>

On Tue, 2008-10-14 at 13:21 +1300, Martin Langhoff wrote:
> I hadn't read such colourful (rude!) colloquialisms for a while. Amusing.

Heh. Even though I can communicate fluently in Spanish, my knowledge of
the language is almost entirely academic (learned through high school
and college courses) aside from the slight Peruvian dialectal bias from
my mother's side of the family. So it took me some Google-ing and
Wiktionary help to figure out what he was saying for the idioms and
other things of it. (For example, at first I thought the end of it said
to ask the seashell for the translation...and that just made me very
confused until Wiktionary gave me the appropriate colloquial
translation. XD)

As an aside, written Spanish is very much a diacritic-sensitive
language! Not seeing the acute accent on some of the words where there
should be (such as what should have been "pol?tica" and "discusi?n")
made my brain hurt a bit. :(

But I digress.
-- 
?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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/08a33cb2/attachment.sig>

From kevin.kofler at chello.at  Tue Oct 14 04:18:53 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 14 Oct 2008 04:18:53 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
Message-ID: <loom.20081014T041756-21@post.gmane.org>

Ralf Corsepius <rc040203 <at> freenet.de> writes:
> It isn't possible anymore to reopen bugs

It is. Just set the status dropdown from CLOSED back to ASSIGNED.

        Kevin Kofler



From jeff at ocjtech.us  Tue Oct 14 04:22:20 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 23:22:20 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <1223956006.3029.227.camel@beck.corsepiu.local>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
	<gd0q11$6ns$1@ger.gmane.org>
	<20081014005113.GB3258@vader.jdub.homelinux.org>
	<20081014011743.GA27052@angus.ind.WPI.EDU>
	<1223956006.3029.227.camel@beck.corsepiu.local>
Message-ID: <935ead450810132122x78f87f50x220e2affea03fc1c@mail.gmail.com>

On Mon, Oct 13, 2008 at 10:46 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>>
>> And why shouldn't the Fedora project provide a place for the consumers
>> who fixed things themselves to share with those who can't fix things?
>
> Exactly! Wasn't this the original idea behind Fedora?

While my memory isn't the best (and my google-fu fails me), I'm pretty
sure that Fedora was never meant to be a free-for-all.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From jeff at ocjtech.us  Tue Oct 14 04:37:03 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Mon, 13 Oct 2008 23:37:03 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <7dd7ab490810131939u174eaa67l87a3071f96500a69@mail.gmail.com>
References: <loom.20081012T230422-741@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
	<20081014004747.GA3258@vader.jdub.homelinux.org>
	<7dd7ab490810131939u174eaa67l87a3071f96500a69@mail.gmail.com>
Message-ID: <935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>

On Mon, Oct 13, 2008 at 9:39 PM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
>
> What does it say about freedom, when we say
> "Use Fedora and be free! ...except, you know, how you want to."  Why
> are we spending so much time and effort saying no, instead of getting
> out of the way of those who are interested in doing it and watching it
> succeed or fail on its merits?

"We" are saying no because "they" want "us" to do something, rather
than doing it themselves.  All of the software that goes into
producing Fedora is free (in both the Beer and Speech senses).  What
*isn't* free is the infrastructure that goes into producing Fedora
releases (the power/cooling/bandwidth/hardware as well as the time of
the various employees and volunteers).   *I* think that Red Hat has
been extremely generous in letting us use that infrastructure to build
a cool distribution like Fedora.

But why should Red Hat (and those of us that believe in the current
Fedora mission) let that infrastructure and perhaps more importantly
the Fedora brand get used for some "Fedora LTS" project?  Based upon
the failure of the Fedora Legacy project and the most recent
discussion there are only a few people interested in volunteering
their time to such a project.  And from what I've seen in this latest
discussion the LTS project goals are either ill-defined or
overambitious or both.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From rc040203 at freenet.de  Tue Oct 14 04:39:17 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 06:39:17 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810132122x78f87f50x220e2affea03fc1c@mail.gmail.com>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
	<gd0q11$6ns$1@ger.gmane.org>
	<20081014005113.GB3258@vader.jdub.homelinux.org>
	<20081014011743.GA27052@angus.ind.WPI.EDU>
	<1223956006.3029.227.camel@beck.corsepiu.local>
	<935ead450810132122x78f87f50x220e2affea03fc1c@mail.gmail.com>
Message-ID: <1223959157.3029.236.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 23:22 -0500, Jeffrey Ollie wrote:
> On Mon, Oct 13, 2008 at 10:46 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >>
> >> And why shouldn't the Fedora project provide a place for the consumers
> >> who fixed things themselves to share with those who can't fix things?
> >
> > Exactly! Wasn't this the original idea behind Fedora?
> 
> While my memory isn't the best (and my google-fu fails me), I'm pretty
> sure that Fedora was never meant to be a free-for-all.

FE was meant to be an "integration forum" to "bundle" various external
repos. This was never meant to be free-for-all.

Ralf






From rc040203 at freenet.de  Tue Oct 14 04:47:50 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 06:47:50 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>
References: <loom.20081012T230422-741@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
	<20081014004747.GA3258@vader.jdub.homelinux.org>
	<7dd7ab490810131939u174eaa67l87a3071f96500a69@mail.gmail.com>
	<935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>
Message-ID: <1223959670.3029.246.camel@beck.corsepiu.local>

On Mon, 2008-10-13 at 23:37 -0500, Jeffrey Ollie wrote:
> On Mon, Oct 13, 2008 at 9:39 PM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
> >
> > What does it say about freedom, when we say
> > "Use Fedora and be free! ...except, you know, how you want to."  Why
> > are we spending so much time and effort saying no, instead of getting
> > out of the way of those who are interested in doing it and watching it
> > succeed or fail on its merits?
> 
> "We" are saying no because "they" want "us" to do something, rather
> than doing it themselves.  All of the software that goes into
> producing Fedora is free (in both the Beer and Speech senses).  What
> *isn't* free is the infrastructure that goes into producing Fedora
> releases (the power/cooling/bandwidth/hardware as well as the time of
> the various employees and volunteers).   *I* think that Red Hat has
> been extremely generous in letting us use that infrastructure to build
> a cool distribution like Fedora.
Well, it had been RH's deliberate decision to do so.

/me thinks, they actually had no other choice at that time.

> But why should Red Hat (and those of us that believe in the current
> Fedora mission) let that infrastructure and perhaps more importantly
> the Fedora brand get used for some "Fedora LTS" project?
Marketing, customer bonding, ... ?

>   Based upon
> the failure of the Fedora Legacy project and the most recent
> discussion there are only a few people interested in volunteering
> their time to such a project.  And from what I've seen in this latest
> discussion the LTS project goals are either ill-defined or
> overambitious or both.
Your opinion.

Ralf




From fedora at leemhuis.info  Tue Oct 14 04:48:34 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 14 Oct 2008 06:48:34 +0200
Subject: Package review backlog.
In-Reply-To: <20081013185639.GA27065@nostromo.devel.redhat.com>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>	<1223489352.3434.94.camel@wicktop.localdomain>	<20081008204711.GA10613@yoda.jdub.homelinux.org>	<1223499372.23034.47.camel@wicktop.localdomain>	<1223539429.3145.365.camel@macbook.infradead.org>	<1223595692.14070.16.camel@wicktop.localdomain>	<20081010000140.GA31156@yoda.jdub.homelinux.org>	<1223597573.14070.25.camel@wicktop.localdomain>	<1223644448.6770.18.camel@macbook.infradead.org>	<48F07C5C.8000403@leemhuis.info>
	<20081013185639.GA27065@nostromo.devel.redhat.com>
Message-ID: <48F424A2.7090805@leemhuis.info>

On 13.10.2008 20:56, Bill Nottingham wrote:
> Thorsten Leemhuis (fedora at leemhuis.info) said: 
>> I propose that each FESCo member should try to work on at least one  
>> package review per week. Each week at the FESCo meeting all FESCo  
>> members should be asked what they did (as FESCo member) over the past  
>> week to improve Fedora; they further should be asked what they (as FESCo  
>> member) plan for the coming week to improve Fedora. That includes, but  
>> is not limited to reviews.
> This seems rather silly -

Of course it is -- just like the original proposal from dwmw2 imho, 
where FESCo members were just asked what reviews they did (and nothing 
else). But many people liked that "one review per week" proposal, hence 
I thought I better come up with something else that goes in the same 
direction, but at least is not that bad.

> [...]

CU
knurd



From sundaram at fedoraproject.org  Tue Oct 14 05:39:57 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 14 Oct 2008 11:09:57 +0530
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223955551.3029.219.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
Message-ID: <48F430AD.5050002@fedoraproject.org>

Ralf Corsepius wrote:
> On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
>> Ralf Corsepius <rc040203 at freenet.de> wrote:
>>> On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
>>>> Ralf Corsepius <rc040203 at freenet.de> wrote:
>>>>> I am glad they are around, but not more and not less.
>>>> It is around becase RHEL is popular, and open source.
>>> And non-free
>> It /is/ free... you pay for support only.
> Wrong. RHEL is opensource, but it is not free. You can't get RHEL
> binaries anywhere.

You are confusing non-free and commercial. They are not the same. 
Non-free is a well established term for proprietary software. FSF, 
Debian and even RPMFusion is using that term as such.

RHEL is commercial but not, non-free. The complete source in the form of 
SRPMs is available in the Red Hat public ftp server. The free 
availability of binaries is never a requirement for any of the free and 
open source licenses.

Rahul



From rc040203 at freenet.de  Tue Oct 14 06:09:15 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 08:09:15 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F430AD.5050002@fedoraproject.org>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
Message-ID: <1223964555.3029.273.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 11:09 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
> > On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
> >> Ralf Corsepius <rc040203 at freenet.de> wrote:
> >>> On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
> >>>> Ralf Corsepius <rc040203 at freenet.de> wrote:
> >>>>> I am glad they are around, but not more and not less.
> >>>> It is around becase RHEL is popular, and open source.
> >>> And non-free
> >> It /is/ free... you pay for support only.
> > Wrong. RHEL is opensource, but it is not free. You can't get RHEL
> > binaries anywhere.

>  The complete source in the form of 
> SRPMs is available in the Red Hat public ftp server. 
Did I say something else?

> The free 
> availability of binaries is never a requirement for any of the free and 
> open source licenses.
This is what RedHat propaganda is telling you.





From martin.langhoff at gmail.com  Tue Oct 14 06:43:26 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Tue, 14 Oct 2008 19:43:26 +1300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223964555.3029.273.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
Message-ID: <46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>

On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> The free
>> availability of binaries is never a requirement for any of the free and
>> open source licenses.
> This is what RedHat propaganda is telling you.

I've done several papers in Law School specifically on software
licensing and analysis of GPL and related licenses. Rahul's statement
is correct -- no licenses require availability of binaries.

Might be awkward or less than helpful, but it's comfortably within the
rules of the license.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From paul+fedora at saturnine.org.uk  Tue Oct 14 07:01:11 2008
From: paul+fedora at saturnine.org.uk (Paul Black)
Date: Tue, 14 Oct 2008 08:01:11 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223964555.3029.273.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
Message-ID: <a9274eb10810140001o3792ab45q274f405a69b1c65e@mail.gmail.com>

2008/10/14 Ralf Corsepius <rc040203 at freenet.de>

> > The free
> > availability of binaries is never a requirement for any of the free and
> > open source licenses.
> This is what RedHat propaganda is telling you.


Software isn't truly free until someone else builds it for you?

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

From rc040203 at freenet.de  Tue Oct 14 07:01:53 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 09:01:53 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
Message-ID: <1223967713.3029.282.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 19:43 +1300, Martin Langhoff wrote:
> On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >> The free
> >> availability of binaries is never a requirement for any of the free and
> >> open source licenses.
> > This is what RedHat propaganda is telling you.
> 
> I've done several papers in Law School specifically on software
> licensing and analysis of GPL and related licenses. Rahul's statement
> is correct -- no licenses require availability of binaries.
>
> Might be awkward or less than helpful, but it's comfortably within the
> rules of the license.
I am not doubting this: It's a different definition of free. It's one
case of the usual word-games with "freedom"-related words.

To me, a product you can not get without having to pay for, doesn't
qualify as free - It's may be free in the sense of "intellectual
property", but this doesn't make it free in the "common man's sense".

Ask your neighbor, if he would pay USD600 for a barrel of "free beer".

Ralf








From sundaram at fedoraproject.org  Tue Oct 14 07:46:12 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 14 Oct 2008 13:16:12 +0530
Subject: non-free software
In-Reply-To: <1223967713.3029.282.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
Message-ID: <48F44E44.7040705@fedoraproject.org>

Ralf Corsepius wrote:
> On Tue, 2008-10-14 at 19:43 +1300, Martin Langhoff wrote:
>> On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>>>> The free
>>>> availability of binaries is never a requirement for any of the free and
>>>> open source licenses.
>>> This is what RedHat propaganda is telling you.
>> I've done several papers in Law School specifically on software
>> licensing and analysis of GPL and related licenses. Rahul's statement
>> is correct -- no licenses require availability of binaries.
>>
>> Might be awkward or less than helpful, but it's comfortably within the
>> rules of the license.
> I am not doubting this: It's a different definition of free.

It is the most commonly accepted definition and well established within 
the free and open source software community. Free software and non-free 
software have a very specific meaning in this context. You are well 
aware of that. Using it in another way deliberately is just misleading. 
If you try to redefine it to mean commercial instead of proprietary, 
then, that would lead to the interpretation, that say Debian or 
RPMFusion non-free repository packages are only available for a fee 
which is clearly not true. Confusing betwen proprietary and commercial 
is a classic mistake we shouldn't be propagating.

Rahul



From pertusus at free.fr  Tue Oct 14 07:51:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 09:51:18 +0200
Subject: Regarding install options
In-Reply-To: <46a038f90810132031v19e2606cx123fa72dccbe7b10@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<200810140045.20715.opensource@till.name>
	<1223938254.3056.12.camel@luminos.localdomain>
	<46a038f90810132031v19e2606cx123fa72dccbe7b10@mail.gmail.com>
Message-ID: <20081014075118.GC2657@free.fr>

On Tue, Oct 14, 2008 at 04:31:20PM +1300, Martin Langhoff wrote:

> Note! I am not arguing that such "no yum" option needs to be available
> from the GUI anaconda installer. That'd be pointless. I just say that
> it should be possible and at least somewhat supported via anaconda in
> combination with revisor or pungi.
> 
> Right now it does not seem to be.

There is a bug in anaconda that forces all build time anaconda 
dependencies in, until this is fixed it is not possible to come with
something really small. Then we'll see once it is fixed.

--
Pat



From dwmw2 at infradead.org  Tue Oct 14 07:56:16 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 14 Oct 2008 08:56:16 +0100
Subject: reviving Fedora Legacy
In-Reply-To: <1223959670.3029.246.camel@beck.corsepiu.local>
References: <loom.20081012T230422-741@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
	<20081014004747.GA3258@vader.jdub.homelinux.org>
	<7dd7ab490810131939u174eaa67l87a3071f96500a69@mail.gmail.com>
	<935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>
	<1223959670.3029.246.camel@beck.corsepiu.local>
Message-ID: <1223970976.6770.703.camel@macbook.infradead.org>

On Tue, 2008-10-14 at 06:47 +0200, Ralf Corsepius wrote:
> On Mon, 2008-10-13 at 23:37 -0500, Jeffrey Ollie wrote:
> >   Based upon
> > the failure of the Fedora Legacy project and the most recent
> > discussion there are only a few people interested in volunteering
> > their time to such a project.  And from what I've seen in this latest
> > discussion the LTS project goals are either ill-defined or
> > overambitious or both.

> Your opinion.

Mine, too.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From dwmw2 at infradead.org  Tue Oct 14 07:59:52 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 14 Oct 2008 08:59:52 +0100
Subject: Package review backlog.
In-Reply-To: <48F424A2.7090805@leemhuis.info>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<1223489352.3434.94.camel@wicktop.localdomain>
	<20081008204711.GA10613@yoda.jdub.homelinux.org>
	<1223499372.23034.47.camel@wicktop.localdomain>
	<1223539429.3145.365.camel@macbook.infradead.org>
	<1223595692.14070.16.camel@wicktop.localdomain>
	<20081010000140.GA31156@yoda.jdub.homelinux.org>
	<1223597573.14070.25.camel@wicktop.localdomain>
	<1223644448.6770.18.camel@macbook.infradead.org>
	<48F07C5C.8000403@leemhuis.info>
	<20081013185639.GA27065@nostromo.devel.redhat.com>
	<48F424A2.7090805@leemhuis.info>
Message-ID: <1223971192.6770.707.camel@macbook.infradead.org>

On Tue, 2008-10-14 at 06:48 +0200, Thorsten Leemhuis wrote:
> On 13.10.2008 20:56, Bill Nottingham wrote:
> > Thorsten Leemhuis (fedora at leemhuis.info) said: 
> >> I propose that each FESCo member should try to work on at least one  
> >> package review per week. Each week at the FESCo meeting all FESCo  
> >> members should be asked what they did (as FESCo member) over the past  
> >> week to improve Fedora; they further should be asked what they (as FESCo  
> >> member) plan for the coming week to improve Fedora. That includes, but  
> >> is not limited to reviews.
> > This seems rather silly -
> 
> Of course it is -- just like the original proposal from dwmw2 imho, 
> where FESCo members were just asked what reviews they did (and nothing 
> else). But many people liked that "one review per week" proposal, hence 
> I thought I better come up with something else that goes in the same 
> direction, but at least is not that bad.

Yes. The 'justify your existence to the electorate' connotations really
weren't intended.

Maybe a one-line report to FESCo each week, stating the number of
reviews completed in the past week and the number still outstanding,
would be perfectly sufficient. It wasn't about _forcing_ people to
comply; it was just to keep it fresh in our minds, and make sure we
remember that we agreed to do it (if, indeed, we _do_ agree to do it. So
far it's just a suggestion).

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From nils at redhat.com  Tue Oct 14 08:06:29 2008
From: nils at redhat.com (Nils Philippsen)
Date: Tue, 14 Oct 2008 10:06:29 +0200
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F41729.30606@behdad.org>
References: <20081012134001.GC2700@free.fr> <48F21BB3.9060509@x-tnd.be>
	<48F22D29.90109@gmail.com> <20081012201102.GB2688@free.fr>
	<48F41729.30606@behdad.org>
Message-ID: <1223971589.1314.0.camel@wombat.tiptoe.de>

On Mon, 2008-10-13 at 23:51 -0400, Behdad Esfahbod wrote:
> > On Sun, Oct 12, 2008 at 10:00:25AM -0700, Toshio Kuratomi wrote:
> >> When I brought this up, Bastien Nocera brought up security bugs and not
> >> wanting random people to be CC'd before a security bug is resolved.  How
> >> should we deal with this?
> 
> 
> I think the correct way to deal with this is that watchbugzilla should not
> automatically CC user to bugs for the component, but instead modify the user's
>  bugzilla account to watch some special address like, eg for package pango,
> pango-bugs at fedora.bugs.  And the product pango changed to have
> pango-bugs at fedora.bugs as default assignee or Q/A contact.  This way we avoid
> the security problem issue, as well as those inbox-filling mass changes to
> remove people from CC lists or to change default assignee of the product.
> 
> My 0.02CAD,

I'll add my ?0.02, that proposal sounds well.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From martin.langhoff at gmail.com  Tue Oct 14 08:06:06 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Tue, 14 Oct 2008 21:06:06 +1300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223967713.3029.282.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
Message-ID: <46a038f90810140106p6f9b67e8w2e45937d45008c1c@mail.gmail.com>

On Tue, Oct 14, 2008 at 8:01 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> I am not doubting this: It's a different definition of free. It's one
> case of the usual word-games with "freedom"-related words.

Then you are equivocating around with the 2 meanings of free, which is
a royal waste of time.



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From pertusus at free.fr  Tue Oct 14 08:07:37 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 10:07:37 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081014003650.GB30302@nostromo.devel.redhat.com>
References: <loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<20081013220420.GJ2738@free.fr>
	<20081014003650.GB30302@nostromo.devel.redhat.com>
Message-ID: <20081014080737.GD2657@free.fr>

On Mon, Oct 13, 2008 at 08:36:50PM -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > > On the contrary. The Fedora project provides maintenance of the release
> > > for the release period. You're guaranteeing ... nothing.
> > 
> > It provides maintainance, but cannot guarantee anytihng.
> 
> Be realistic. If we didn't de-facto guarantee that we'd provide security
> updates during the specified lifespan for all relevant packages, we woudn't
> have a viable distribution.

Sure. I exactly the same in response to your first mail. There is a
de-facto guarantee, but nothing substantial to fedora. And specific
packages can go unmaintained, important bugs can be unfixed and so on...

> > The idea is to 
> > provide maintainance for the packages people are interested in providing 
> > maintainance.
> 
> I know exactly what you're proposing, you don't need to restate it. I just
> think it's a fundamentally bad idea that actively harms users by giving
> them an open-ended rope to hang themselves with, which doesn't at all claim
> to cover their entire system, as opposed to the clear support and
> maintenance they have now.

If it is clearly communicated, and requires manual steps to set up, with
a clear comunication (well as clear as possible) I can't see where is
the issue.

> To put it a different way - would you buy a car whose extended warranty
> won't tell you what it covers, or for how long, and tells you it's subject
> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.

Once again fedora cannot make that claim either.

> You want me to support your plan? Cover the entire distribution, for a
> specified period of time. Simple, right?

Unneeded and impossible (at least in the short term). First there is no
point in covering the parts that are not central to the distribution.
And then covering parts is much better than covering nothing. And I
recall you that the plan is to see how many people are interested before
doing anything publicly.

> > > ... but then later want a longer term of support, up to 3-5 years, during
> > > which... their OS will be old. Just as old as an equivalent RHEL/CentOS,
> > > in fact.
> > 
> > Not at all. Centos starts already old, it is very different.
> 
> How so? When Centos 5/RHEL 5 is released, it's pretty much up to date, or
> at least within 6 months. If you're looking for a 3-5 year lifespan (which
> you said your goal is), that's nothing. And halfway or so through your
> proposed arrangement, your release would be just as old and outdated
> as an equivalent RHEL release of the same vintage.

Of course, but it would have started from something recent. And if you
begin at any other time than time of a RHEL release which doesn't happen
very often, there is absolutely nothing for you.

> > It is very different because the updates are not fundamental changes,
> > like those that happens between releases. You know that, don't you,
> > those changes that goes through rawhide.
> 
> ... how so? There's a ton of changes between kernel-2.6.25 and kernel-2.6.27.
> KDE-4.1 is a fairly big step from KDE-4.0. The entirety of system
> network configuration support was added between F8 GA NetworkManager
> and the F8 updates version.
> 
> Is it *all* of the large changes? No. But it's more than you'd think.
> Moreover, exactly which of these big changes break people? Is
> rhgb -> plymouth a big change? Sure. Does it actively break third-party
> applications or development? No.

That's exactly the point. The changes in stable release break less than
between releases. I really can't see why you can't agree to that with
your level of knowledge of th edistro.

> Honestly, I think a whole lot more of the work here is best done:
> - promoting RHEL/CentOS as the alternative for users who need longer support
> - making distribution upgrades seamless and easy

It isn't exclusive. But it isn't the same and doesn't solve the same use
cases. I am already personally very involved in EPEL (all my packages
are in EPEL since long), and I can't see what I can do for distribution
upgrades to be seamless and easy, except for my own packages (and those
I co-maintain).

--
Pat



From alan at redhat.com  Tue Oct 14 08:18:15 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Oct 2008 04:18:15 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223955551.3029.219.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
Message-ID: <20081014081815.GA25871@shell.devel.redhat.com>

On Tue, Oct 14, 2008 at 05:39:11AM +0200, Ralf Corsepius wrote:
> > It /is/ free... you pay for support only.
> Wrong. RHEL is opensource, but it is not free. You can't get RHEL
> binaries anywhere.

I would suggest you re-read the FSF definition of free.



From alan at redhat.com  Tue Oct 14 08:21:38 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Oct 2008 04:21:38 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223964555.3029.273.camel@beck.corsepiu.local>
References: <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
Message-ID: <20081014082138.GC25871@shell.devel.redhat.com>

On Tue, Oct 14, 2008 at 08:09:15AM +0200, Ralf Corsepius wrote:
> > availability of binaries is never a requirement for any of the free and 
> > open source licenses.
> This is what RedHat propaganda is telling you.

Red Hat, two words please. If you are going to pointless and pedantic you
could at least get trademarks correct even if you can't get the FSF definition
of free software right

Alan



From pertusus at free.fr  Tue Oct 14 08:22:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 10:22:36 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>
References: <604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
	<20081014004747.GA3258@vader.jdub.homelinux.org>
	<7dd7ab490810131939u174eaa67l87a3071f96500a69@mail.gmail.com>
	<935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>
Message-ID: <20081014082236.GE2657@free.fr>

On Mon, Oct 13, 2008 at 11:37:03PM -0500, Jeffrey Ollie wrote:
> 
> "We" are saying no because "they" want "us" to do something, rather
> than doing it themselves.  All of the software that goes into
> producing Fedora is free (in both the Beer and Speech senses).  What
> *isn't* free is the infrastructure that goes into producing Fedora
> releases (the power/cooling/bandwidth/hardware as well as the time of
> the various employees and volunteers).   *I* think that Red Hat has
> been extremely generous in letting us use that infrastructure to build
> a cool distribution like Fedora.

If it turns out that this project requires too much resources, as I
repeadly said, no problem not to do it. But currently I don't think it
requires much resources (and I may be wrong), since it profits from
scale economies and the fact that there isn't a full use of the
resources most of the time (on the builders).

> But why should Red Hat (and those of us that believe in the current
> Fedora mission) let that infrastructure and perhaps more importantly
> the Fedora brand get used for some "Fedora LTS" project?  Based upon

The fedora brand wouldn't be involved, at least until the project has
proven to be succesful.

> the failure of the Fedora Legacy project and the most recent

It was under different conditions, but I'm becoming to be tired of
reexplaining that. I made that point in at least 2 mails if not 3...

> discussion there are only a few people interested in volunteering
> their time to such a project.  And from what I've seen in this latest

I'd say the rerverse. Very fine packagers like Kevin, Chris and Orion
seemed to be supportive (at least of the idea), and there were also
some users saying that they would love to see such a project happen. And
Jesse and Josh made very constructive comments. Sure there are also many
people that are against the idea, among those who count in fedora, but
it is definitly much better than the last attempt.

How many people started EPEL?

> discussion the LTS project goals are either ill-defined or
> overambitious or both.

Reread Kevin proposition and my answers to Josh. At least it is not ill
defined (and there is still the UEAL proposal that can be a commplement)
as for overambition I don't really see what you mean here.

--
Pat



From alan at redhat.com  Tue Oct 14 08:24:46 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Oct 2008 04:24:46 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223967713.3029.282.camel@beck.corsepiu.local>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
Message-ID: <20081014082446.GD25871@shell.devel.redhat.com>

On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
> Ask your neighbor, if he would pay USD600 for a barrel of "free beer".

I think you fundamentally miss the entire point of free software here.

Lots of people will pay for "free" beer in the sense that free means the
recipe is published and you could go make your own. They don't want to make
their own beer at the moment and they understand either intuitively or directly
the most basic concepts of economics like specialisation.

Alan



From opensource at till.name  Tue Oct 14 08:43:13 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 10:43:13 +0200
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F41729.30606@behdad.org>
References: <20081012134001.GC2700@free.fr> <20081012201102.GB2688@free.fr>
	<48F41729.30606@behdad.org>
Message-ID: <200810141043.20354.opensource@till.name>

On Tue October 14 2008, Behdad Esfahbod wrote:
> > On Sun, Oct 12, 2008 at 10:00:25AM -0700, Toshio Kuratomi wrote:
> >> When I brought this up, Bastien Nocera brought up security bugs and not
> >> wanting random people to be CC'd before a security bug is resolved.  How
> >> should we deal with this?
>
> I think the correct way to deal with this is that watchbugzilla should not
> automatically CC user to bugs for the component, but instead modify the
> user's bugzilla account to watch some special address like, eg for package
> pango, pango-bugs at fedora.bugs.  And the product pango changed to have
> pango-bugs at fedora.bugs as default assignee or Q/A contact.  This way we
> avoid the security problem issue, as well as those inbox-filling mass
> changes to remove people from CC lists or to change default assignee of the
> product.

I do still not understand what the issue is and how this would resolve it, 
e.g. if nobody who watches pango-bugs gets informed about security bugs, how 
will the maintainer of the package get informed?

Nevertheless your proposal would fix the other issues you described. I would 
only change to add pango-bugs to both the assignee and CC, to make sure 
everyone stays in the loop, once the package is assigned to some individual.

Oh, but there is also a problem about your proposal. Afaik in this case, the 
bugs do not appear on the Bugzilla Frontpage and/or the "My Bugs" search. Can 
it made sure, that they do?

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/20081014/62f1a928/attachment.sig>

From opensource at till.name  Tue Oct 14 08:48:20 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 10:48:20 +0200
Subject: Package review backlog.
In-Reply-To: <1223971192.6770.707.camel@macbook.infradead.org>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<48F424A2.7090805@leemhuis.info>
	<1223971192.6770.707.camel@macbook.infradead.org>
Message-ID: <200810141048.21131.opensource@till.name>

On Tue October 14 2008, David Woodhouse wrote:

> Maybe a one-line report to FESCo each week, stating the number of
> reviews completed in the past week and the number still outstanding,
> would be perfectly sufficient. It wasn't about _forcing_ people to

How about updating this weekly:
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus

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/20081014/8afb1ea0/attachment.sig>

From oliver at linux-kernel.at  Tue Oct 14 09:14:54 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 14 Oct 2008 11:14:54 +0200
Subject: compat-python, Zope...
Message-ID: <48F4630E.7030002@linux-kernel.at>

Hi!

Is there a reason, that there is no compat-python package available? I 
have seen a compat-python24 from livna, that works well. And I created 
(based on the livna spec) a compat-python23 package.

The main reason for me to spend time on this are our web developers who 
are Zope developers. Most projects run with Zope 2.10 and 2.11 and these 
Zope versions require Python 2.4.

There are really old projects using Zope 2.8 and this requires Python 2.3.

So. Are there reasons, why there are no older Python version available? 
If we would have it, we could also package Zope/Plone...

I'd volunteer to package Zope and it's deps, if there are no objections...

-of



From dominik at greysector.net  Tue Oct 14 09:32:41 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 14 Oct 2008 11:32:41 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223955551.3029.219.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
Message-ID: <20081014093239.GA27002@mokona.greysector.net>

On Tuesday, 14 October 2008 at 05:39, Ralf Corsepius wrote:
> On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote:
> > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote:
[...]
> > > > Fedora (or any other large group of people) will move where the majority
> > > > wants to go... 
> > 
> > > Well, deployment of an OS to servers, will always be a "minority use
> > > case" and will always collide somewhere with mere desktop oriented
> > > developments.
> > 
> > So?
> Examples: NetworkManager, PulseAudio, setroubleshoot, SELinux-policies,
> PackageKit, defaults ...

I have to agree here. NM maintainer keeps pushing it on people who don't
want it. There is a bug[1] filed, which was fixed and then reverted and now
yum update wants to install NM on my system again, which drags in other
packages which I don't want on my system either.
Another example of its brokenness is this: if you log out of the X session,
you lose your (wireless) network connection.

SELinux is another subject for a good rant. Example: I created /var/log/dovecot,
chowned it to dovecot user and configured it to put its logs there. Bang!
SELinux denial. There's no easy way to fix it permanently either and SELinux
tools documentation is akin to arcane knowledge. Unless you're familiar with
all the terminology, you won't understand it.

PulseAudio is another mess. Three Fedora releases down the road and it still
doesn't work right. It's another of the things I turn off and uninstall after
installing a new Fedora box.

I could go on, but that's enough for now.

[...]
> > >                                              ... tools
> > 
> > Huh?
> koji, bodhi, bugzilla, packagedb ...
> 
> One detail: The amount of administration emails I am receiving from
> koji, bodhi, packagedb: Often, several 1000s per month.

Yeah. Why would I want to receive notification that I requested an update
to be pushed to testing or stable? I already know that, I just did it!

Regards,
R.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=351101

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From opensource at till.name  Tue Oct 14 09:43:28 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 11:43:28 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F4630E.7030002@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at>
Message-ID: <200810141143.29185.opensource@till.name>

On Tue October 14 2008, Oliver Falk wrote:

> So. Are there reasons, why there are no older Python version available?
> If we would have it, we could also package Zope/Plone...

The two main reasons I remember are

1) The fear of bug reports because of users running the old python version for 
software that requires the new one

2) The old python versions do not get security updates

So all effort regarding this is best spent on porting Zope to newer python 
versions.

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/20081014/a87970ec/attachment.sig>

From fedora at leemhuis.info  Tue Oct 14 09:48:30 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 14 Oct 2008 11:48:30 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F4630E.7030002@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at>
Message-ID: <48F46AEE.6090005@leemhuis.info>

On 14.10.2008 11:14, Oliver Falk wrote:
> Is there a reason, that there is no compat-python package available?

The short version: The python maintainer didn't want to have one in 
Fedora and FESCo backed that decision. You will find a lot more about 
this topic in the archives of this list; for example in this discussion:
http://www.redhat.com/archives/fedora-devel-list/2007-May/msg00226.html

I doubt the situation changed in between, thus my suggestion would be to 
put your packages up for review in bugzilla.rpmfusion.org.

If I'm wrong and if the situation has changed then we should try to move 
the compat-python* packages from RPM Fusion to Fedora.

CU
knurd



From oliver at linux-kernel.at  Tue Oct 14 10:10:39 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 14 Oct 2008 12:10:39 +0200
Subject: compat-python, Zope...
In-Reply-To: <200810141143.29185.opensource@till.name>
References: <48F4630E.7030002@linux-kernel.at>
	<200810141143.29185.opensource@till.name>
Message-ID: <48F4701F.6030209@linux-kernel.at>

Hi Till!

Till Maas wrote:
> On Tue October 14 2008, Oliver Falk wrote:
> 
>> So. Are there reasons, why there are no older Python version available?
>> If we would have it, we could also package Zope/Plone...
> 
> The two main reasons I remember are
> 
> 1) The fear of bug reports because of users running the old python version for 
> software that requires the new one

Hm. This could only happen, if someone would use /usr/bin/python23 or 
/usr/bin/python2.4, instead of /usr/bin/python. It's very unlikely this 
happens by accident - I think... However. I do understand that fear a bit.

> 2) The old python versions do not get security updates

Python 2.3 latest update was on March 11, to version 2.3.7, so this 
seems to be still developed/supported.

Python 2.4 lastest update was also on March 11, to version 2.4.5, so 
this is also still developed/supported.

But of course, security flaws are likely first found in latest versions 
and it's unsure, if they do find their way into older releases....

> So all effort regarding this is best spent on porting Zope to newer python 
> versions.

I would say the same... BUT: I know the Zope developers are trying this 
since a long time already and haven't made much progress - it seems. I'm 
happy they do support Python 2.4 already with their latest Versions.
There's also the problem, that Python versions are a a moving target. 
Eg. October 1: Release of Python 2.6. What does that mean? Fedora 
Rawhide will soon include this - I guess. So as soon as you have ported 
Zope to support Python 2.5, you have 2.6 everywhere. And as soon as you 
have ported Zope to support Python 2.6, there's likely Python 3 :-)

Also, since I'm not an enthusiastic and smart Python developer, this 
sounds quite impossible for me to do...

The only thing I *want*, is to have Zope/Plone and it's deps in Fedora.

We have a lot of Debian servers here, because Zope/Plone works out of 
the box... You understand I want to get rid of these boxes :-)

-of



From than at redhat.com  Tue Oct 14 10:20:50 2008
From: than at redhat.com (Than Ngo)
Date: Tue, 14 Oct 2008 12:20:50 +0200
Subject: Possible to default to KDE?
In-Reply-To: <48F18D93.1020305@redhat.com>
References: <48ED6823.5000901@redhat.com> <48EE9423.4000203@fedoraproject.org>
	<48F18D93.1020305@redhat.com>
Message-ID: <200810141220.50383.than@redhat.com>

Am Sonntag 12 Oktober 2008 07:39:31 schrieb Warren Togami:
> Rahul Sundaram wrote:
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=64966
> >
> > Rahul
>
> What config files does system-switch-displaymanager change?  Only
> /etc/sysconfig/desktop?
>

yes, it changes the /etc/sysconfig/desktop.

Than



From rawhide at fedoraproject.org  Tue Oct 14 10:24:21 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 14 Oct 2008 10:24:21 +0000 (UTC)
Subject: rawhide report: 20081014 changes
Message-ID: <20081014102421.4C88B1B8001@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct 14 06:01:09 UTC 2008

New package itext
        A Free Java-PDF library
New package ocspd
        OpenCA OCSP Daemon
New package pam_kcoda
        A Pluggable Authentication Module for coda using krb5 authentication
New package python-cssutils
        CSS Cascading Style Sheets library for Python
New package python-webtest
        Helper to test WSGI applications
New package starlab
        A Software Environment for Collisional Stellar Dynamics
Updated Packages:

PackageKit-0.3.7-1.fc10
-----------------------
* Mon Oct 13 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.7-1
- New upstream version
- Add dynamic groups functionality to the API
- Many performance and other bugfixes


Pound-2.4.3-1.fc10
------------------
* Mon Oct 13 18:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.4.3-1
- Upstream released new version


audacious-1.5.1-4.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Ralf Ertzinger <ralf at skytale.net> 1.5.1-4
- Remove lingering references to libSAD from the installed
  headers


blobAndConquer-1.0-1.fc10
-------------------------
* Tue Sep 30 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 1.0-1
- New upstream release 1.0


bluez-4.13-2.fc10
-----------------
* Mon Oct 13 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.13-2
- Fix PS3 BD remote input event generation


cairo-dock-1.6.3-0.1.svn1351_trunk.fc10
---------------------------------------
* Tue Oct 14 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1351


coreutils-6.12-15.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 6.12-15
- fix several date issues(e.g. countable dayshifts, ignoring
  some cases of relative offset, locales conversions...)
- clarify ls exit statuses documentation (#446294)


e2fsprogs-1.41.3-1.fc10
-----------------------
* Fri Oct  3 18:00:00 2008 Eric Sandeen <sandeen at redhat.com> 1.41.3-2
- New upstream version (very minor fixes, ext4-related)


eclipse-subclipse-1.2.4-12.fc10
-------------------------------
* Mon Oct 13 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> - 1.2.4-12
- Bump revision.

* Mon Oct 13 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> - 1.2.4-11
- Fix build with eclipse 3.4.
- Rediff plugin-classpath.patch.

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.2.4-10
- Fix Patch0:/%patch mismatch.


fio-1.22-1.fc10
---------------
* Mon Oct 13 18:00:00 2008 Eric Sandeen <sandeen at redhat.com> 1.22-1
- New upstream version, several bugs fixed.


ghc-6.8.3-7.fc10
----------------
* Mon Oct 13 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 6.8.3-7.fc10
- add selinux file context for unconfined_execmem following darcs package


gnome-lirc-properties-0.2.8-6.fc10
----------------------------------
* Tue Oct 14 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.2.8-6
- Fix compilation

* Mon Oct 13 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.2.8-5
- Add PS3 remote controls support


gnome-packagekit-0.3.7-1.fc10
-----------------------------
* Mon Oct 13 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.7-1
- New upstream version
- Much better log viewer functionality
- New service pack creator tool


hal-0.5.12-3.20081013git.fc10
-----------------------------
* Mon Oct 13 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-3.20081013git
- Update to git snapshot 20081013git


hal-info-20081013-1.fc10
------------------------
* Mon Oct 13 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 20081013-1
- Update to latest upstream release


happy-1.17-3.fc10
-----------------
* Tue Oct 14 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 1.17-3
- add selinux unconfined_execmem_exec_t file context


hddtemp-0.3-0.16.beta15.fc9
---------------------------
* Wed Oct  1 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.3-0.16.beta15
- Sync with Debian's 0.3-beta15-45 for a fix for undesired spin-ups with
  most current drives (#464912).


ibus-m17n-0.1.1.20081013-1.fc10
-------------------------------
* Mon Oct 13 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081013-1
- Update to 0.1.1.20081013.


im-chooser-1.2.4-1.fc10
-----------------------
* Tue Oct 14 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 1.2.4-1
- New upstream release.


imsettings-0.105.0-1.fc10
-------------------------
* Tue Oct 14 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.105.0-1
- New upstream release.
  - Have a workaround for the race condition issue. (#452849)
  - Fix a freeze issue with ibus. (#465431)
  - Fix a freeze issue on Desktops not supporting XSETTINGS.


iscsi-initiator-utils-6.2.0.870-0.1.rc1.fc10
--------------------------------------------
* Tue Sep 30 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 6.2.0.870-0.1.rc1
- Rewrite SysV initscripts, fixes rh 441290, 246960, 282001, 436175, 430791
- Add patch to make iscsiadm complain and exit when run as user instead
  of hang spinning for the database lock
- Add patch to make iscsiadm start iscsid when needed (rh 436175 related)
- Don't start iscsi service when network not yet up (in case of using NM)
  add NM dispatcher script to start iscsi service once network is up


jd-2.0.3-0.1.svn2389_trunk.fc10
-------------------------------
* Tue Oct 14 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2389


joda-time-1.5.2-9.tzdata2008g.fc10
----------------------------------
* Mon Oct 13 18:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 1.5.2-7.tzdata2008g
- New tzdata (2008g).


jwhois-4.0-8.fc10
-----------------
* Mon Oct 13 18:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 4.0-8
- Update to latest upstream config
  Resolves: #463972


kdelibs-4.1.2-4.fc10
--------------------
* Mon Oct 13 18:00:00 2008 Than Ngo <than at redhat.com> 4.1.2-4
- backport patch to fix crash kded startup crash


latexmk-4.01-1.fc10
-------------------
* Mon Oct 13 18:00:00 2008 Jerry James <loganjerry at gmail.com> - 4.01-1
- New version 4.01.


libgxim-0.3.0-1.fc10
--------------------
* Tue Oct 14 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.3.0-1
- New upstream release.
  - Have a workaround to avoid the race condition issue. (#452849)
  - Fix a freeze issue with ibus. (#465431)


libprelude-0.9.21.2-1.fc10
--------------------------
* Mon Oct 13 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> - 0.9.21.2-1
- New upstream bugfix release


libv4l-0.5.1-1.fc10
-------------------
* Mon Oct 13 18:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.1-1
- New upstream release 0.5.1


libxcb-1.1.91-4.fc10
--------------------
* Mon Oct 13 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.1.91-4
- libxcb-1.1-abstract-socket.patch: Drop.
- libxcb-1.1.91-git.patch: Update to git master.

* Wed Sep 17 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.1.91-3
- libxcb-1.1-xreply-leak.patch: Plug a memory leak in _XReply when the
  caller has a non-fatal error handler. (mclasen, fdo #17616)


lighttpd-1.4.20-1.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.4.20-1
- Update to 1.4.20 final.


m2crypto-0.19.1-1
-----------------
* Mon Oct 13 18:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 0.19.1-1
- Update to m2crypto-0.19.1


merkaartor-0.12-1.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Sven Lankes <sven at lank.es> - 0.12-1
- new upstream release
- enable geotagging support (requires exiv2)
- remove -fixes patch


mesa-7.2-0.8.fc10
-----------------
* Mon Oct 13 18:00:00 2008 Dave Airlie <airlied at redhat.com> 7.2-0.8
- r300-bufmgr.patch - fix sw fallbacks + kernel texture error.


module-init-tools-3.5-3.fc10
----------------------------
* Mon Oct 13 18:00:00 2008 Jon Masters <jcm at redhat.com> - 3.5-3
- Remove silly noescape patch we've had forever.
- Nobody knows why any more.

* Mon Oct 13 18:00:00 2008 Jon Masters <jcm at redhat.com> - 3.5
- Rebase to latest upstream release.
- NOTE: This release adds binary module indexes.


nedit-5.5-20.fc10
-----------------
* Mon Oct 13 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 5.5-20
- BR: xorg-x11-fonts-ISO8859-1 to avoid incorrect font
  substitutions (#464945)


netatalk-2.0.3-21.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Jiri Skala <jskala at redhat.com> - 4:2.0.3-21
- fix #465050 - FTBFS netatalk-2.0.3-19 - regenerated patches

* Mon Aug 11 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 4:2.0.3-20
- fix license tag


netbeans-6.1-8.fc10
-------------------
* Thu Oct  9 18:00:00 2008 Victor G. Vasilyev <victor.vasilyev at sun.com> 6.1-8
- Update center - NetBeans is disabled, update center - NetBeans for Fedora is added (#466179)
- Some cosmetics


openais-0.91-2.fc10
-------------------
* Mon Oct 13 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> 0.91-2
- remove ExclusiveArch line


openldap-2.4.11-3.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Jan Safranek <jsafranek at redhat.com> 2.4.11-3
- add SLAPD_SHUTDOWN_TIMEOUT to /etc/sysconfig/ldap, allowing admins
  to set non-default slapd shutdown timeout
- add checkpoint to default slapd.conf file (#458679)


openswan-2.6.18-2.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Avesh Agarwal <avagarwa at redhat.com> - 2.6.18-2
- Addressed some issues related to buzilla 447419
- Added xmlto and bind-devel to BuildRequires 
- Removed the patch openswan-2.6-noxmlto.patch
- Removed the command "rm -rf programs/readwriteconf" from the spec file
  as readwriteconf is used with "make check" for debugging purposes.
- Removed USE_LWRES=false from the spec file as it has been 
  obsolete in upstream (using bind-devel instead)


perl-IO-Socket-SSL-1.17-1.fc10
------------------------------
* Mon Oct 13 18:00:00 2008 Paul Howarth <paul at city-fan.org> - 1.17-1
- Update to latest upstream version: 1.17


perl-QWizard-3.15-1.fc9
-----------------------
* Wed Sep 17 18:00:00 2008 Wes Hardaker <wjhns174 at hardakers.net> - 3.15-1
- Update to latest upstream bug fixes


perl-libwww-perl-5.817-1.fc10
-----------------------------
* Fri Oct 10 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 5.817-1
- update to 5.817


php-Smarty-2.6.20-1.fc10
------------------------
* Mon Oct 13 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 2.6.20-1
- Upstream sync


php-pear-Net-UserAgent-Detect-2.5.0-1.fc10
------------------------------------------
* Mon Oct 13 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 2.5.0-1
- Upstream sync


pitivi-0.11.1.4-1.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.1.4-1
- Update to 0.11.1.4


planner-0.14.3-5.fc10
---------------------
* Mon Oct 13 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 0.14.3-5
- Resolves: rhbz#466615 back-port html improvements


pm-utils-1.2.2.1-1.fc10
-----------------------
* Mon Oct 13 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 1.2.2.1-1
- Update to 1.2.2.1
- Supports automatically pulling quirks from HAL and has the ability to save
  the last working set of quirks to an .fdi file.


rawstudio-1.1.1-1.fc10
----------------------
* Mon Oct 13 18:00:00 2008 Gianluca Sforna <giallu gmail com> - 1.1.1-1
- new upstream release


rhpl-0.217-1
------------
* Mon Oct 13 18:00:00 2008 Chris Lumens <clumens at redhat.com> 0.217-1
- Don't set XKB model (ajax, #461832).
- Don't use the deprecated gtk.mainiteration function (#432115).
- Use $(MAKE), not make (#458455).
- Use the Save stock button instead of Open (#432345).


rubygem-hoe-1.8.0-1.fc10
------------------------
* Mon Oct 13 18:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 1.8.0-1
- Release 1.8.0 of the gem.


scribus-1.3.5-0.5.12516svn.fc10
-------------------------------
* Mon Oct 13 18:00:00 2008 Dan Hor??k <dan[AT]danny.cz> 1.3.5-0.5.12516svn
- install global desktop file instead of KDE-only one (#461124)
- little cleanup


solar-backgrounds-0.0.2-1.fc10
------------------------------
* Mon Oct 13 18:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.0.2-1
- New release, adds 5:4 wallpapers


subversion-1.5.3-3
------------------
* Mon Oct 13 18:00:00 2008 Joe Orton <jorton at redhat.com> 1.5.3-3
- fix build

* Mon Oct 13 18:00:00 2008 Joe Orton <jorton at redhat.com> 1.5.3-2
- update to 1.5.3 (#466674)
- update psvn.el to r33557


system-config-printer-1.0.8-3.fc10
----------------------------------
* Mon Oct 13 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.8-3
- Added patch for 1.0.x changes since 1.0.8:
  - Don't use a LinkButton for the 'Problems?' button (bug #465407).
  - Don't use a separator for the server settings dialog (bug
      - Don't set non-zero page size for SpinButtons.
  - Don't show an error dialog if an IPP operation's authentication
    dialog is cancelled by the user, but show an error dialog if the
    password was incorrect (bug #465407).
  - Set Server Settings... menu entry sensitive depending on whether
    we are connected to a server (Ubuntu #280736).
  - Lots of translations updated.


tomcat6-6.0.18-6.2.fc10
-----------------------
* Mon Oct 13 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-6.2
- use Fedora-specific changes to force java 1.6.0

* Tue Oct  7 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-6.1
- use lsb_release instead of lsb-release to get the distributor

* Tue Oct  7 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-5
- fix initscript messages on Mandriva Linux
- fix help message in initscript

* Wed Oct  1 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-4
- redefine %_initrddir for FHS-compliance
- make initscript LSB-complaint

* Fri Sep 26 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-3
- fix status in initscript

* Thu Sep 25 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:6.0.18-2
- remove initscripts and /sbin/service requirement
- call initscript directly without using /sbin/service
- require /sbin/chkconfig instead of chkconfig
- remove chkconfig requirement from packages that don't require it


tuxcmd-0.6.50-3.fc10
--------------------
* Mon Oct 13 18:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 0.6.50-3
- Connection Manager: Fix restoring last used item


tzdata-2008h-1.fc10
-------------------
* Mon Oct 13 18:00:00 2008 Petr Machata <pmachata at redhat.com> - 2008h-1
- Upstream 2008h
  - Fix exact DST transition hour for Mauritius
  - Syria will leave the period of DST on Nov 1
  - Fix coordinates of Pacific/Niue


ucview-0.22-1.fc10
------------------
* Mon Oct 13 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 0.22-1
- Upgrade to 0.22

* Sun Jul 27 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 0.21-1
- Upgrade to 0.21


unicap-0.9.3-1.fc10
-------------------
* Mon Oct 13 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 0.9.3-1
- Upgrade to 0.9.3 (#466825, thanks to Hans de Goede)
- Enabled libv4l support for the new gspca kernel driver


wklej-0.1.4-1.fc10
------------------
* Mon Oct 13 18:00:00 2008 Rafa?? Psota <rafalzaq at gmail.com> - 0.1.4-1
- update to 0.1.4


wpa_supplicant-0.6.4-2.fc10
---------------------------
* Wed Oct 15 18:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.6.4-2
- Handle encryption keys correctly when switching 802.11 modes (rh #459399)
- Better scanning behavior on resume from suspend/hibernate
- Better interaction with newer kernels and drivers


xorg-x11-drv-ati-6.9.0-26.fc10
------------------------------
* Mon Oct 13 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-26
- radeon-modeset.patch - fix nexuiz mode switch - remove unused reuse code


xorg-x11-drv-i810-2.4.2-10.fc10
-------------------------------
* Tue Oct 14 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.4.2-10
- rebase to latest upstream master


Summary:
Added Packages: 6
Removed Packages: 0
Modified Packages: 65
Broken deps for i386
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	python-prioritized-methods-0.2.1-1.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2562
	python-turbojson-1.2.1-2.fc10.noarch requires python-peak-rules >= 0:0.5a1.dev-0.2555
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From oliver at linux-kernel.at  Tue Oct 14 11:02:48 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 14 Oct 2008 13:02:48 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F46AEE.6090005@leemhuis.info>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
Message-ID: <48F47C58.9060702@linux-kernel.at>

Thorsten Leemhuis wrote:
> On 14.10.2008 11:14, Oliver Falk wrote:
>> Is there a reason, that there is no compat-python package available?
> 
> The short version: The python maintainer didn't want to have one in 
> Fedora and FESCo backed that decision. You will find a lot more about 
> this topic in the archives of this list; for example in this discussion:
> http://www.redhat.com/archives/fedora-devel-list/2007-May/msg00226.html
> 
> I doubt the situation changed in between, thus my suggestion would be to 
> put your packages up for review in bugzilla.rpmfusion.org.
> 
> If I'm wrong and if the situation has changed then we should try to move 
> the compat-python* packages from RPM Fusion to Fedora.

OK. I think I've read the whole old thread now :-)

First of all: I *will* package compat-python and Zope/Plone, because I 
need it at work. The only question is if Fedora/FESCo wants me to share 
my work with the Fedora community or not!

I can think of a Python 2.4 package that lives within the Zope tree to 
make it extra hard for others to use it by accident - but I don't think 
that this would be neat, seen from a FHS point of view.

I'm not a big fan of third party repositories. DOT. This would lead to 
an extra discussion...

a) I maintain Zope/Plone (+ deps, eg. compat-python) in Fedora
b) I maintain it on my *private* company repo
c) NOTE!: I guess this will lead to packages a la 
compat-python24-{elementtree,feedparser,imaging,lxml,setuptools,psycopg} 
and maybe a whole bunch of others...

So. FESCo? Do you want me to share my work with the community or not. DOT.

-of

PS: I'm thinking of rpmfusion, but then I would have to maintain 
packages in 3 places: company, fedora, rpmfusion... If I would maintain 
it only company internal, I would get bugreports only by our web 
developers - would reduce my work - not too bad, isn't it :-P



From nils at redhat.com  Tue Oct 14 11:18:29 2008
From: nils at redhat.com (Nils Philippsen)
Date: Tue, 14 Oct 2008 13:18:29 +0200
Subject: transifex and PackageKit
In-Reply-To: <1223915316.3551.27.camel@hughsie-laptop>
References: <1223915316.3551.27.camel@hughsie-laptop>
Message-ID: <1223983109.17970.40.camel@localhost.localdomain>

Hi Richard,

On Mon, 2008-10-13 at 17:28 +0100, Richard Hughes wrote: 
> Today I released 0.3.7 and pushed it to rawhide. In a couple of weeks
> time they'll be a bugfix 0.3.8 release that we'll see in F10 and F9.
> 
> Before that time, I would like the translations for PackageKit to be
> updated -- updated translations are very important for the F10 release
> quality and also for the F9 backport.
> 
> You can see the current stats here:
> 
> http://translate.fedoraproject.org/module/packagekit#master

I've taken a look at the German translation and found out that some
messages are really hard to translate, partly because there are no
comments about the context, partly because the messages are not complete
sentences and you didn't use placeholders in there.

For example, I guess the string "Could not find what packages require"
could mean "I can't find out what some packages require that are already
mentioned elsewhere" but it could also be "I can't find out which
packages require (something else not mentioned)". The former should
probably be phrased "Couldn't find what these packages require.", the
latter "Couldn't find which packages require %1$s.": Note the complete
sentences and the indexed placeholder in the second one which lets
translators move around these things if necessary. Add a comment like
"placeholder is a list of packages" to put icing on that ;-).

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From rc040203 at freenet.de  Tue Oct 14 11:34:35 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 13:34:35 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014082446.GD25871@shell.devel.redhat.com>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
Message-ID: <1223984075.3029.292.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
> On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
> > Ask your neighbor, if he would pay USD600 for a barrel of "free beer".
> 
> I think you fundamentally miss the entire point of free software here.
I don't think so. 

I simply decided not to contribute to software products, which are not
freely (cost-free) available nor cost-freely redistributable and to
brand them as "non-free".

Ralf





From rc040203 at freenet.de  Tue Oct 14 11:38:44 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 13:38:44 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014081815.GA25871@shell.devel.redhat.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014081815.GA25871@shell.devel.redhat.com>
Message-ID: <1223984324.3029.299.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 04:18 -0400, Alan Cox wrote:
> On Tue, Oct 14, 2008 at 05:39:11AM +0200, Ralf Corsepius wrote:
> > > It /is/ free... you pay for support only.
> > Wrong. RHEL is opensource, but it is not free. You can't get RHEL
> > binaries anywhere.
> 
> I would suggest you re-read the FSF definition of free.
> 
I know the FSF-definition very well. They are defining free in the sense
of "open source" - RHEL is opensource, nevertheless, there are no freely
available binaries.





From hughsient at gmail.com  Tue Oct 14 11:43:58 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 14 Oct 2008 12:43:58 +0100
Subject: transifex and PackageKit
In-Reply-To: <1223983109.17970.40.camel@localhost.localdomain>
References: <1223915316.3551.27.camel@hughsie-laptop>
	<1223983109.17970.40.camel@localhost.localdomain>
Message-ID: <1223984638.3487.15.camel@hughsie-laptop>

On Tue, 2008-10-14 at 13:18 +0200, Nils Philippsen wrote:
> Hi Richard,
> 
> On Mon, 2008-10-13 at 17:28 +0100, Richard Hughes wrote: 
> > Today I released 0.3.7 and pushed it to rawhide. In a couple of weeks
> > time they'll be a bugfix 0.3.8 release that we'll see in F10 and F9.
> > 
> > Before that time, I would like the translations for PackageKit to be
> > updated -- updated translations are very important for the F10 release
> > quality and also for the F9 backport.
> > 
> > You can see the current stats here:
> > 
> > http://translate.fedoraproject.org/module/packagekit#master
> 
> I've taken a look at the German translation and found out that some
> messages are really hard to translate, partly because there are no
> comments about the context, partly because the messages are not complete
> sentences and you didn't use placeholders in there.

Sure, I really apologise. I'm generally rubbish at this sort of thing,
so I appreciate any help.

> For example, I guess the string "Could not find what packages require"
> could mean "I can't find out what some packages require that are already
> mentioned elsewhere" but it could also be "I can't find out which
> packages require (something else not mentioned)". The former should
> probably be phrased "Couldn't find what these packages require.", the
> latter "Couldn't find which packages require %1$s.": Note the complete
> sentences and the indexed placeholder in the second one which lets
> translators move around these things if necessary. Add a comment like
> "placeholder is a list of packages" to put icing on that ;-).

Could you find any other dodgey strings and send a mail to the
packagekit mailing list please? We'll then go through any of the bad
ones, fixing them up and adding translator comments.

You don't need to subscribe if you don't want, I'll moderate you
through.

Thanks,

Richard.




From nicu_fedora at nicubunu.ro  Tue Oct 14 11:48:31 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Tue, 14 Oct 2008 14:48:31 +0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223984075.3029.292.camel@beck.corsepiu.local>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<1223967713.3029.282.camel@beck.corsepiu.local>	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
Message-ID: <48F4870F.4020207@nicubunu.ro>

Ralf Corsepius wrote:
> On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
>> On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
>>> Ask your neighbor, if he would pay USD600 for a barrel of "free beer".
>> I think you fundamentally miss the entire point of free software here.
> I don't think so. 
> 
> I simply decided not to contribute to software products, which are not
> freely (cost-free) available nor cost-freely redistributable and to
> brand them as "non-free".

I tried to stay away from this flame but... I also can decide to call 
"non-free" software that does not help me getting laid, how is that 
relevant?

-- 
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 jwboyer at gmail.com  Tue Oct 14 11:37:21 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 14 Oct 2008 07:37:21 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F47C58.9060702@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
Message-ID: <20081014113721.GA18347@yoda.jdub.homelinux.org>

On Tue, Oct 14, 2008 at 01:02:48PM +0200, Oliver Falk wrote:
> Thorsten Leemhuis wrote:
>> On 14.10.2008 11:14, Oliver Falk wrote:
>>> Is there a reason, that there is no compat-python package available?
>>
>> The short version: The python maintainer didn't want to have one in  
>> Fedora and FESCo backed that decision. You will find a lot more about  
>> this topic in the archives of this list; for example in this 
>> discussion:
>> http://www.redhat.com/archives/fedora-devel-list/2007-May/msg00226.html
>>
>> I doubt the situation changed in between, thus my suggestion would be 
>> to put your packages up for review in bugzilla.rpmfusion.org.
>>
>> If I'm wrong and if the situation has changed then we should try to 
>> move the compat-python* packages from RPM Fusion to Fedora.
>
> OK. I think I've read the whole old thread now :-)
>
> First of all: I *will* package compat-python and Zope/Plone, because I  
> need it at work. The only question is if Fedora/FESCo wants me to share  
> my work with the Fedora community or not!
>
> I can think of a Python 2.4 package that lives within the Zope tree to  
> make it extra hard for others to use it by accident - but I don't think  
> that this would be neat, seen from a FHS point of view.
>
> I'm not a big fan of third party repositories. DOT. This would lead to  
> an extra discussion...
>
> a) I maintain Zope/Plone (+ deps, eg. compat-python) in Fedora
> b) I maintain it on my *private* company repo
> c) NOTE!: I guess this will lead to packages a la  
> compat-python24-{elementtree,feedparser,imaging,lxml,setuptools,psycopg}  
> and maybe a whole bunch of others...
>
> So. FESCo? Do you want me to share my work with the community or not. DOT.

While we try very hard to follow all threads on the mailing list, if you
really want to ask FESCo a specific question please either open a Trac
ticket or email the FESCo members directly.

josh



From rc040203 at freenet.de  Tue Oct 14 12:04:43 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 14:04:43 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F4870F.4020207@nicubunu.ro>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
Message-ID: <1223985883.3029.306.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 14:48 +0300, Nicu Buculei wrote:
> Ralf Corsepius wrote:
> > On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
> >> On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
> >>> Ask your neighbor, if he would pay USD600 for a barrel of "free beer".
> >> I think you fundamentally miss the entire point of free software here.
> > I don't think so. 
> > 
> > I simply decided not to contribute to software products, which are not
> > freely (cost-free) available nor cost-freely redistributable and to
> > brand them as "non-free".
> 
> I tried to stay away from this flame but... I also can decide to call 
> "non-free" software that does not help me getting laid, how is that 
> relevant?
This rationale contributes to me not to consider RHEL and CentOS, which
is the rationale why I don't consider them to be replacements for a
"Fedora LTS".

Or differently: It doesn't matter what people sell as "free", it matters
what people accept as "free". 






From limb at jcomserv.net  Tue Oct 14 12:15:29 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 14 Oct 2008 07:15:29 -0500 (CDT)
Subject: Package review backlog.
In-Reply-To: <200810141048.21131.opensource@till.name>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<48F424A2.7090805@leemhuis.info>
	<1223971192.6770.707.camel@macbook.infradead.org>
	<200810141048.21131.opensource@till.name>
Message-ID: <21964.198.175.55.5.1223986529.squirrel@mail.jcomserv.net>


> On Tue October 14 2008, David Woodhouse wrote:
>
>> Maybe a one-line report to FESCo each week, stating the number of
>> reviews completed in the past week and the number still outstanding,
>> would be perfectly sufficient. It wasn't about _forcing_ people to
>
> How about updating this weekly:
> http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus

Even monthly, if it's a hassle, he said, not knowing how it was generated,
and then noticing that he was undercaffienated and self-narrating, fell
silent.

> Regards,
> Till
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From email.ahmedkamal at googlemail.com  Tue Oct 14 12:32:36 2008
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Tue, 14 Oct 2008 14:32:36 +0200
Subject: btrfs useability on rawhide
Message-ID: <3da3b5b40810140532o5860503ct78e024a60015859@mail.gmail.com>

Hi,
I see btrfs-progs on rawhide, can I find a btrfs enabled kernel on rawhide
too ? Is someone tracking btrfs and packaging for rawhide ? Also, any plans
for including btrfs (say as a tech Preview) in F11 ?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/04954122/attachment.htm>

From vonbrand at inf.utfsm.cl  Tue Oct 14 12:38:31 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 14 Oct 2008 09:38:31 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T075922-165@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
Message-ID: <200810141238.m9ECcVil009198@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> Martin Langhoff <martin.langhoff <at> gmail.com> writes:
> > I don't think anyone would sign up as a user for such "support". LTS
> > is about a fairly specific promise that is very hard to commit to.

> The users I have in mind wouldn't actively "sign up" for it, they'd end
> up with it due to inaction, just as they currently end up with no updates
> at all.

Catering to lazyness sounds misguided to me...
-- 
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 2340000       Fax:  +56 32 2797513



From james.antill at redhat.com  Tue Oct 14 12:40:09 2008
From: james.antill at redhat.com (James Antill)
Date: Tue, 14 Oct 2008 08:40:09 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F47C58.9060702@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>  <48F47C58.9060702@linux-kernel.at>
Message-ID: <1223988009.16958.51.camel@code.and.org>

On Tue, 2008-10-14 at 13:02 +0200, Oliver Falk wrote:

> First of all: I *will* package compat-python and Zope/Plone, because I 
> need it at work. The only question is if Fedora/FESCo wants me to share 
> my work with the Fedora community or not!

 From what I remember the previous person who wanted python in Fedora
was also willing to create/maintain a compat-python24 package. But
that's not the only problem.

> I can think of a Python 2.4 package that lives within the Zope tree to 
> make it extra hard for others to use it by accident - but I don't think 
> that this would be neat, seen from a FHS point of view.

 In some ways this might be doable, at least it has less pain points
than packaging it "properly".

> I'm not a big fan of third party repositories. DOT. This would lead to 
> an extra discussion...
> 
> a) I maintain Zope/Plone (+ deps, eg. compat-python) in Fedora
> b) I maintain it on my *private* company repo
> c) NOTE!: I guess this will lead to packages a la 
> compat-python24-{elementtree,feedparser,imaging,lxml,setuptools,psycopg} 
> and maybe a whole bunch of others...

 C is the biggest problem, in that "someone" has to dup all the modules
people need ... which also need to be kept in sync. ... and you need to
make sure that python-foo doesn't pull in compat-python24-bar (and vice
versa).

-- 
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/20081014/9722431b/attachment.sig>

From vonbrand at inf.utfsm.cl  Tue Oct 14 12:42:21 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 14 Oct 2008 09:42:21 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <20081013113234.GD3087@free.fr>
References: <loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
	<20081013103531.GA3087@free.fr>
	<20081013113021.GA27573@orient.maison.lan>
	<20081013113234.GD3087@free.fr>
Message-ID: <200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>

Patrice Dumas <pertusus at free.fr> wrote:
> On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
> > * Patrice Dumas [13/10/2008 13:23] :
> > >
> > > Why are you telling about half baked updates? Who will do that? Fedora
> > 
> > They're half-baked in the sense that there's less commitement
> > post-EOL than pre-EOL.

> But post-EOL there is currently no commitment and there won't be any
> promise on it. Some is better than not at all.

"Might someday get looked at and fixed, if somebody cares" is definitely
much worse than "No more fixes, do upgrade".

[Yes, the exact same reasoning behind rm(1)ed files are gone for good:
 Users moan the first few times they get burned, afterwards they learn and
 are careful.]
-- 
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 2340000       Fax:  +56 32 2797513



From jwboyer at gmail.com  Tue Oct 14 12:48:17 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 14 Oct 2008 08:48:17 -0400
Subject: btrfs useability on rawhide
In-Reply-To: <3da3b5b40810140532o5860503ct78e024a60015859@mail.gmail.com>
References: <3da3b5b40810140532o5860503ct78e024a60015859@mail.gmail.com>
Message-ID: <20081014124817.GB18347@yoda.jdub.homelinux.org>

On Tue, Oct 14, 2008 at 02:32:36PM +0200, Ahmed Kamal wrote:
>Hi,
>I see btrfs-progs on rawhide, can I find a btrfs enabled kernel on rawhide
>too ?

No.

>Is someone tracking btrfs and packaging for rawhide ?

Since we only have one kernel, no.

>Also, any plans for including btrfs (say as a tech Preview) in F11 ?

This might be possible.  It really depends on how quickly btrfs gets
put into mainline.  If it's there, it will probably be enabled as
a module at least.  I would doubt that anaconda would do an install
with btrfs as the root filesystem, but who knows.

josh



From caolanm at redhat.com  Tue Oct 14 12:55:57 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Tue, 14 Oct 2008 13:55:57 +0100
Subject: OpenOffice and go-oo
In-Reply-To: <385866f0810131511s5ebd6588peda46c7dfe98cc67@mail.gmail.com>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
	<1223909556.10624.131.camel@vain.rhgalway>
	<385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>
	<1223934602.10624.179.camel@vain.rhgalway>
	<385866f0810131511s5ebd6588peda46c7dfe98cc67@mail.gmail.com>
Message-ID: <1223988957.10624.205.camel@vain.rhgalway>

On Tue, 2008-10-14 at 01:11 +0300, Muayyad AlSadi wrote:
> can you please make that clear for me, can I have minimal Oo.o on a
> fedora-based livecd without having java on it and without exceeding
> 700Mb limit

There are two explicit java-requires in stock Fedora F-10 OOo "core"
rpms. One on saxon and one on lucene. So you can't put the OOo rpm on a
LiveCD and not get java pulled in there as well. But there is no longer
one for bsh in the "core" rpms, only on the beanshell one. Which reduces
the java-requires stack somewhat if just trying to put the major OOo
components on it.

> > I would like to see OOo on the LiveCD :-),
> 
> I did it, I made a fedora based livecd with

There's no great difficulty putting (a translation subset of) OOo on "a"
LiveCD. I was referring to "the" stock fedora LiveCD.

> but because I that on vanilla ooo many functionality could be missing
> because they are java-centric, while if I build it over the go-oo it
> will be perfect, 

> they only need java in vanilla ooo not in go-oo and this is the point
> behind asking you to base it on go-oo

go-ooo unfortunately is not a magic version of OOo, so it is just not
the case that it can fully work without java. On such a "java-less"
3.0.0 go-ooo, or even on your own LiveCD java-less OOo of probably
fedora-vanilla-based 2.4.0...

a) what happens when you run file->wizards->letter ?
b) what happens when you enter a search term in the online help (note
3.0.0, not 2.4.X) ?
c) what happens when you use tools->xml filter settings-> and add a new
xslt transform and use "test xslts"
d) and what happens when you run oobase and attempt to create a new
local database.

Those examples need java to work, whether go-ooo.org or vanilla.

C.



From lesmikesell at gmail.com  Tue Oct 14 12:54:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 07:54:14 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
Message-ID: <48F49676.7060008@gmail.com>

Martin Langhoff wrote:
> On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>>> The free
>>> availability of binaries is never a requirement for any of the free and
>>> open source licenses.
>> This is what RedHat propaganda is telling you.
> 
> I've done several papers in Law School specifically on software
> licensing and analysis of GPL and related licenses. Rahul's statement
> is correct -- no licenses require availability of binaries.
> 
> Might be awkward or less than helpful, but it's comfortably within the
> rules of the license.

How does that clause "You may not impose any further restrictions on the 
recipients' exercise of the rights granted herein." mesh with the 
further restrictions that Red Hat imposes?  The GPL does not distinguish 
between binaries and source in the required terms.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From tim.lauridsen at googlemail.com  Tue Oct 14 12:55:42 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Tue, 14 Oct 2008 14:55:42 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223985883.3029.306.camel@beck.corsepiu.local>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<1223967713.3029.282.camel@beck.corsepiu.local>	<20081014082446.GD25871@shell.devel.redhat.com>	<1223984075.3029.292.camel@beck.corsepiu.local>	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
Message-ID: <48F496CE.1040309@googlemail.com>

Ralf Corsepius wrote:
> On Tue, 2008-10-14 at 14:48 +0300, Nicu Buculei wrote:
>   
>> Ralf Corsepius wrote:
>>     
>>> On Tue, 2008-10-14 at 04:24 -0400, Alan Cox wrote:
>>>       
>>>> On Tue, Oct 14, 2008 at 09:01:53AM +0200, Ralf Corsepius wrote:
>>>>         
>>>>> Ask your neighbor, if he would pay USD600 for a barrel of "free beer".
>>>>>           
>>>> I think you fundamentally miss the entire point of free software here.
>>>>         
>>> I don't think so. 
>>>
>>> I simply decided not to contribute to software products, which are not
>>> freely (cost-free) available nor cost-freely redistributable and to
>>> brand them as "non-free".
>>>       
>> I tried to stay away from this flame but... I also can decide to call 
>> "non-free" software that does not help me getting laid, how is that 
>> relevant?
>>     
> This rationale contributes to me not to consider RHEL and CentOS, which
> is the rationale why I don't consider them to be replacements for a
> "Fedora LTS".
>
> Or differently: It doesn't matter what people sell as "free", it matters
> what people accept as "free". 
>
>   
I don't accept the earth is round, so it must be flat !

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

From rc040203 at freenet.de  Tue Oct 14 12:57:30 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 14:57:30 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>
References: <loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
	<20081013103531.GA3087@free.fr>
	<20081013113021.GA27573@orient.maison.lan>
	<20081013113234.GD3087@free.fr>
	<200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>
Message-ID: <1223989050.3029.321.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 09:42 -0300, Horst H. von Brand wrote:
> Patrice Dumas <pertusus at free.fr> wrote:
> > On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
> > > * Patrice Dumas [13/10/2008 13:23] :
> > > >
> > > > Why are you telling about half baked updates? Who will do that? Fedora
> > > 
> > > They're half-baked in the sense that there's less commitement
> > > post-EOL than pre-EOL.
> 
> > But post-EOL there is currently no commitment and there won't be any
> > promise on it. Some is better than not at all.
> 
> "Might someday get looked at and fixed, if somebody cares" is definitely
> much worse than "No more fixes, do upgrade".

Some users will do so, but others will react as Wikipedia did: Quit
using Fedora and switch to a different distro or OS.

Hell, folks, I have seen people switching to MinGW, because of this.
They told me, "MinGW" better suites their needs because it offers
support for "this weird GNU-stuff" on "the industry-standard OS".




From jeff at ocjtech.us  Tue Oct 14 12:58:56 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 14 Oct 2008 07:58:56 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F49676.7060008@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<48F49676.7060008@gmail.com>
Message-ID: <935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>

On Tue, Oct 14, 2008 at 7:54 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>
> How does that clause "You may not impose any further restrictions on the
> recipients' exercise of the rights granted herein." mesh with the further
> restrictions that Red Hat imposes?  The GPL does not distinguish between
> binaries and source in the required terms.

To which additional restrictions do you refer?

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From rc040203 at freenet.de  Tue Oct 14 12:58:54 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 14:58:54 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F496CE.1040309@googlemail.com>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
	<48F496CE.1040309@googlemail.com>
Message-ID: <1223989134.3029.323.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 14:55 +0200, Tim Lauridsen wrote:

> I don't accept the earth is round, so it must be flat !

The GDR was democratic, was it?




From lesmikesell at gmail.com  Tue Oct 14 13:00:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 08:00:06 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <200810141238.m9ECcVil009198@laptop14.inf.utfsm.cl>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>	<20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>	<loom.20081012T230422-741@post.gmane.org>	<48F288A3.8000601@shmuelhome.mine.nu>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>	<loom.20081013T075922-165@post.gmane.org>
	<200810141238.m9ECcVil009198@laptop14.inf.utfsm.cl>
Message-ID: <48F497D6.5080405@gmail.com>

Horst H. von Brand wrote:
> Kevin Kofler <kevin.kofler at chello.at> wrote:
>> Martin Langhoff <martin.langhoff <at> gmail.com> writes:
>>> I don't think anyone would sign up as a user for such "support". LTS
>>> is about a fairly specific promise that is very hard to commit to.
> 
>> The users I have in mind wouldn't actively "sign up" for it, they'd end
>> up with it due to inaction, just as they currently end up with no updates
>> at all.
> 
> Catering to lazyness sounds misguided to me...

While I don't have much faith in Fedora to provide long term or even 
short term stability, providing security fixes for bugs you shipped even 
beyond the expected support time frame sounds like a very responsible 
thing to do.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From clumens at redhat.com  Tue Oct 14 13:05:56 2008
From: clumens at redhat.com (Chris Lumens)
Date: Tue, 14 Oct 2008 09:05:56 -0400
Subject: Regarding install options
In-Reply-To: <20081014075118.GC2657@free.fr>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<200810140045.20715.opensource@till.name>
	<1223938254.3056.12.camel@luminos.localdomain>
	<46a038f90810132031v19e2606cx123fa72dccbe7b10@mail.gmail.com>
	<20081014075118.GC2657@free.fr>
Message-ID: <20081014130555.GC28638@localhost.localdomain>

> There is a bug in anaconda that forces all build time anaconda 
> dependencies in, until this is fixed it is not possible to come with
> something really small. Then we'll see once it is fixed.

And the bug number would be... ?  I'm not seeing this in the code at
all.  The only things anaconda pulls in that aren't explicitly given by
the user or the dependency of another package are:  filesystem
utilities, raid/iscsi/whatever if you install that, gcc if you install
kernel-devel, authconfig, chkconfig, mkinitrd, rhpl, and
system-config-firewall-tui.

The anaconda BuildReqs are rather extensive and includes tons of -devel
packages.  I don't see these getting installed in my testing.

- Chris



From pertusus at free.fr  Tue Oct 14 13:03:03 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 15:03:03 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>
References: <loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
	<20081013103531.GA3087@free.fr>
	<20081013113021.GA27573@orient.maison.lan>
	<20081013113234.GD3087@free.fr>
	<200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>
Message-ID: <20081014130303.GA3126@free.fr>

On Tue, Oct 14, 2008 at 09:42:21AM -0300, Horst H. von Brand wrote:
> Patrice Dumas <pertusus at free.fr> wrote:
> > On Mon, Oct 13, 2008 at 01:30:21PM +0200, Emmanuel Seyman wrote:
> > > * Patrice Dumas [13/10/2008 13:23] :
> > > >
> > > > Why are you telling about half baked updates? Who will do that? Fedora
> > > 
> > > They're half-baked in the sense that there's less commitement
> > > post-EOL than pre-EOL.
> 
> > But post-EOL there is currently no commitment and there won't be any
> > promise on it. Some is better than not at all.
> 
> "Might someday get looked at and fixed, if somebody cares" is definitely
> much worse than "No more fixes, do upgrade".

It will still be "No more fixes, do upgrade" that will be the main
message, but packagers could have the possibility to care. If there are
enough packagers, then we'll communicate on this but only if succesful.

--
Pat



From lesmikesell at gmail.com  Tue Oct 14 13:10:39 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 08:10:39 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <1223989050.3029.321.camel@beck.corsepiu.local>
References: <loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>	<loom.20081013T075922-165@post.gmane.org>	<20081013084614.GA25491@orient.maison.lan>	<20081013092032.GD2670@free.fr>	<20081013094155.GA26167@orient.maison.lan>	<20081013103531.GA3087@free.fr>	<20081013113021.GA27573@orient.maison.lan>	<20081013113234.GD3087@free.fr>	<200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>
	<1223989050.3029.321.camel@beck.corsepiu.local>
Message-ID: <48F49A4F.8010900@gmail.com>

Ralf Corsepius wrote:
> 
>>>>> Why are you telling about half baked updates? Who will do that? Fedora
>>>> They're half-baked in the sense that there's less commitement
>>>> post-EOL than pre-EOL.
>>> But post-EOL there is currently no commitment and there won't be any
>>> promise on it. Some is better than not at all.
>> "Might someday get looked at and fixed, if somebody cares" is definitely
>> much worse than "No more fixes, do upgrade".
> 
> Some users will do so, but others will react as Wikipedia did: Quit
> using Fedora and switch to a different distro or OS.
> 
> Hell, folks, I have seen people switching to MinGW, because of this.
> They told me, "MinGW" better suites their needs because it offers
> support for "this weird GNU-stuff" on "the industry-standard OS".

I don't think I'd use 'standard' to describe something unique and 
proprietary, but there is something to be said about an OS that runs for 
years without reinstalling and works with vendor provided drivers that 
also don't need to be reinstalled every few weeks.

-- 
    Les Mikesell
      lesmikesell at gmail.com




From lesmikesell at gmail.com  Tue Oct 14 13:17:58 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 08:17:58 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>
	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>
Message-ID: <48F49C06.5070405@gmail.com>

Jeffrey Ollie wrote:
> On Tue, Oct 14, 2008 at 7:54 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> How does that clause "You may not impose any further restrictions on the
>> recipients' exercise of the rights granted herein." mesh with the further
>> restrictions that Red Hat imposes?  The GPL does not distinguish between
>> binaries and source in the required terms.
> 
> To which additional restrictions do you refer?

Can I buy one copy of a Red Hat package and redistribute it as the GPL 
permits for any GPL covered portion?  Or install on as many machines as 
I want?  Does every part that has any GPL component permit 
redistribution of the work-as-a-whole?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From ralph+fedora at strg-alt-entf.org  Tue Oct 14 13:25:54 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Tue, 14 Oct 2008 15:25:54 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223985883.3029.306.camel@beck.corsepiu.local>
References: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
Message-ID: <20081014132554.GT13066@br-online.de>

Ralf Corsepius wrote:
> This rationale contributes to me not to consider RHEL and CentOS, which
> is the rationale why I don't consider them to be replacements for a
> "Fedora LTS".

So CentOS is non-free? 

Ralph
-------------- 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/20081014/4b2ff304/attachment.sig>

From jeff at ocjtech.us  Tue Oct 14 13:37:39 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 14 Oct 2008 08:37:39 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F49C06.5070405@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<48F49676.7060008@gmail.com>
	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>
	<48F49C06.5070405@gmail.com>
Message-ID: <935ead450810140637vac8b68x8b758fe01370d1a1@mail.gmail.com>

On Tue, Oct 14, 2008 at 8:17 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Jeffrey Ollie wrote:
>>
>> On Tue, Oct 14, 2008 at 7:54 AM, Les Mikesell <lesmikesell at gmail.com>
>> wrote:
>>>
>>> How does that clause "You may not impose any further restrictions on the
>>> recipients' exercise of the rights granted herein." mesh with the further
>>> restrictions that Red Hat imposes?  The GPL does not distinguish between
>>> binaries and source in the required terms.
>>
>> To which additional restrictions do you refer?

OK, so I'm not a lawyer, and I've never purchased a copy of RHEL, and
I don't work for Red Hat but:

> Can I buy one copy of a Red Hat package and redistribute it as the GPL
> permits for any GPL covered portion?

For certain you can redistribute the source for the GPL and other OSS
bits.  I'm less clear on whether the GPL allows you to redistribute
the binary code.  A quick re-reading of the GPLv2 left me confused as
to whether it was always talking about source code or it was talking
about source code + binaries.

> Or install on as many machines as I want?

I would say yes.  What you won't get is updates (at least not directly).

> Does every part that has any GPL component permit redistribution of
> the work-as-a-whole?

On that I have no idea.

Anyway, if all you want is RHEL without having to pay for support, why
not go for CentOS (or one of the other rebuilds)?

One thing to note is that Red Hat has some very F/OSS-savvy lawyers
around.  I would be very surprised to find out that Red Hat was
deliberately trying to "get around" the GPL.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From rc040203 at freenet.de  Tue Oct 14 13:42:16 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 15:42:16 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014132554.GT13066@br-online.de>
References: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
	<20081014132554.GT13066@br-online.de>
Message-ID: <1223991736.3029.347.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 15:25 +0200, Ralph Angenendt wrote:
> Ralf Corsepius wrote:
> > This rationale contributes to me not to consider RHEL and CentOS, which
> > is the rationale why I don't consider them to be replacements for a
> > "Fedora LTS".
> 
> So CentOS is non-free?
CentOS is free as "free-beer", but CentOS is not free to take decisions
on their own, because they depend on RHEL's sources.






From vonbrand at inf.utfsm.cl  Tue Oct 14 13:46:40 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 14 Oct 2008 10:46:40 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081013134149.GD3139@free.fr>
References: <0d44s5x8co.ln2@ppp1053.in.ipex.cz> <48EF687B.9090407@odu.neva.ru>
	<5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
Message-ID: <200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>

Patrice Dumas <pertusus at free.fr> wrote:
> On Mon, Oct 13, 2008 at 03:38:03PM +0200, Emmanuel Seyman wrote:
> > * Les Mikesell [13/10/2008 15:31] :
> > >
> > > The supported versions may be wildly different at any time and the next  
> > > version may not be suitable for what you want to keep running.
> > 
> > Sounds like you should be using a distribution that offers a longer
> > support time than the Fedora offers.

> Sounds like you don't want fedora packagers to volunteer for a longer 
> (support) time in fedora (not necessarily under the fedora name but in 
> the fedora infrastructure).

Show me the developers who are _commited_ on making it happen, then we can
talk. The infrastructure is in place.

Fedora Legacy foundered because everybody said they wanted it, almost
nobody was willing to do the (hard!) work, and in the end the "many users"
didn't materialize either.

[No, I'm not talking in any official Fedora position, but I think the above
 sort of sums it up.]
-- 
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 2340000       Fax:  +56 32 2797513



From paul+fedora at saturnine.org.uk  Tue Oct 14 13:57:56 2008
From: paul+fedora at saturnine.org.uk (Paul Black)
Date: Tue, 14 Oct 2008 14:57:56 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223991736.3029.347.camel@beck.corsepiu.local>
References: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
	<20081014132554.GT13066@br-online.de>
	<1223991736.3029.347.camel@beck.corsepiu.local>
Message-ID: <a9274eb10810140657l5733d370l7b2ddb329b8fe725@mail.gmail.com>

2008/10/14 Ralf Corsepius <rc040203 at freenet.de>
>
> CentOS is free as "free-beer", but CentOS is not free to take decisions
> on their own, because they depend on RHEL's sources.

Centos is free to do what they like. With that freedom, they've chosen
to try to be "100% binary compatible" with with RHEL:
http://www.centos.org/modules/tinycontent/index.php?id=3

--
Paul



From vonbrand at inf.utfsm.cl  Tue Oct 14 13:52:24 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 14 Oct 2008 10:52:24 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <20081013131753.GB3139@free.fr>
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<20081013131123.GA19171@yoda.jdub.homelinux.org>
	<20081013131753.GB3139@free.fr>
Message-ID: <200810141352.m9EDqOGA022546@laptop14.inf.utfsm.cl>

Patrice Dumas <pertusus at free.fr> wrote:

[...]

> I wasn't clear, I should have said 'use innovative technologies during
> the time fedora is not eol', while not being forced to update each year
> (that's for the 'LTS' part).

OK, so you want not to have to upgrade _and_ the latest technology...
-- 
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 2340000       Fax:  +56 32 2797513



From jeff at ocjtech.us  Tue Oct 14 13:58:45 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 14 Oct 2008 08:58:45 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223991736.3029.347.camel@beck.corsepiu.local>
References: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
	<20081014132554.GT13066@br-online.de>
	<1223991736.3029.347.camel@beck.corsepiu.local>
Message-ID: <935ead450810140658n20ba4775scd9b4ba9a8bc0c57@mail.gmail.com>

On Tue, Oct 14, 2008 at 8:42 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>
> CentOS is free as "free-beer", but CentOS is not free to take decisions
> on their own, because they depend on RHEL's sources.

Which is a choice CentOS has made deliberately.  Were CentOS to choose
differently CentOS would be much less valuable to me.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From a.badger at gmail.com  Tue Oct 14 13:49:14 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 14 Oct 2008 06:49:14 -0700
Subject: compat-python, Zope...
In-Reply-To: <1223988009.16958.51.camel@code.and.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<1223988009.16958.51.camel@code.and.org>
Message-ID: <48F4A35A.7060300@gmail.com>

James Antill wrote:
> On Tue, 2008-10-14 at 13:02 +0200, Oliver Falk wrote:
> 
>> First of all: I *will* package compat-python and Zope/Plone, because I 
>> need it at work. The only question is if Fedora/FESCo wants me to share 
>> my work with the Fedora community or not!
> 
>  From what I remember the previous person who wanted python in Fedora
> was also willing to create/maintain a compat-python24 package. But
> that's not the only problem.
> 
>> I can think of a Python 2.4 package that lives within the Zope tree to 
>> make it extra hard for others to use it by accident - but I don't think 
>> that this would be neat, seen from a FHS point of view.
> 
>  In some ways this might be doable, at least it has less pain points
> than packaging it "properly".
> 
>> I'm not a big fan of third party repositories. DOT. This would lead to 
>> an extra discussion...
>>
>> a) I maintain Zope/Plone (+ deps, eg. compat-python) in Fedora
>> b) I maintain it on my *private* company repo
>> c) NOTE!: I guess this will lead to packages a la 
>> compat-python24-{elementtree,feedparser,imaging,lxml,setuptools,psycopg} 
>> and maybe a whole bunch of others...
> 
>  C is the biggest problem, in that "someone" has to dup all the modules
> people need ... which also need to be kept in sync. ... and you need to
> make sure that python-foo doesn't pull in compat-python24-bar (and vice
> versa).
> 
> 
If C really is the biggest issue, we could look at what Debian is doing
in this area.  They have a package (I think it's called python-central
although that might be the old package and they have a newer one that
takes its place) which aids them in putting the python source modules in
a central store.  Then the modules are byte compiled for every python
that is installed on the system.  I'm not certain of how it works or
whether it is hacky in practice, just aware of its existence.

Is there anyone here with some Debian experience who can point us to a
better piece of information than what I just gave?


-Toshio

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

From jreiser at BitWagon.com  Tue Oct 14 14:06:35 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Tue, 14 Oct 2008 07:06:35 -0700
Subject: btrfs useability on rawhide
In-Reply-To: <20081014124817.GB18347@yoda.jdub.homelinux.org>
References: <3da3b5b40810140532o5860503ct78e024a60015859@mail.gmail.com>
	<20081014124817.GB18347@yoda.jdub.homelinux.org>
Message-ID: <48F4A76B.6070901@BitWagon.com>

> I would doubt that anaconda would do an install
> with btrfs as the root filesystem, but who knows.

Anaconda itself should not care, but the bootloader GRUB
must understand how to read /boot, and GRUB does not read btrfs.
If root is btrfs then /boot must be mounted on a filesystem
that GRUB understands; see /boot/grub/*_stage1_5 for the list.

-- 



From mastahnke at gmail.com  Tue Oct 14 14:14:40 2008
From: mastahnke at gmail.com (Michael Stahnke)
Date: Tue, 14 Oct 2008 09:14:40 -0500
Subject: Attn Ruby People: Package Review request
Message-ID: <7874d9dd0810140714s354245d6qb2690ab9410a2d8a@mail.gmail.com>

Two thing out here to the Ruby Community in Fedora:

1.  I have a package that has needed a review since May, I just
updated it. https://bugzilla.redhat.com/show_bug.cgi?id=452450  This
is RSPEC.

2.  ruby-rpm fails to build from source.
https://bugzilla.redhat.com/show_bug.cgi?id=465103  I don't have a
very good idea on what is needed to fix this. I am not the primary
maintainer, but I am always interested in more Ruby stuff in Fedora.
If anybody has time to fix this, it'd be great.




stahnma



From jwboyer at gmail.com  Tue Oct 14 14:27:20 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 14 Oct 2008 10:27:20 -0400
Subject: btrfs useability on rawhide
In-Reply-To: <48F4A76B.6070901@BitWagon.com>
References: <3da3b5b40810140532o5860503ct78e024a60015859@mail.gmail.com>
	<20081014124817.GB18347@yoda.jdub.homelinux.org>
	<48F4A76B.6070901@BitWagon.com>
Message-ID: <20081014142720.GA16227@yoda.jdub.homelinux.org>

On Tue, Oct 14, 2008 at 07:06:35AM -0700, John Reiser wrote:
>> I would doubt that anaconda would do an install
>> with btrfs as the root filesystem, but who knows.
>
> Anaconda itself should not care, but the bootloader GRUB

Except that Anaconda does care if it's formatting the filesystem.
It has to call the right tools to do the format.

The rest of what you said about Grub is certainly true as well
though.

josh



From sandeen at redhat.com  Tue Oct 14 14:33:02 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 14 Oct 2008 09:33:02 -0500
Subject: btrfs useability on rawhide
In-Reply-To: <20081014142720.GA16227@yoda.jdub.homelinux.org>
References: <3da3b5b40810140532o5860503ct78e024a60015859@mail.gmail.com>	<20081014124817.GB18347@yoda.jdub.homelinux.org>	<48F4A76B.6070901@BitWagon.com>
	<20081014142720.GA16227@yoda.jdub.homelinux.org>
Message-ID: <48F4AD9E.4070100@redhat.com>

Josh Boyer wrote:
> On Tue, Oct 14, 2008 at 07:06:35AM -0700, John Reiser wrote:
>>> I would doubt that anaconda would do an install
>>> with btrfs as the root filesystem, but who knows.
>> Anaconda itself should not care, but the bootloader GRUB
> 
> Except that Anaconda does care if it's formatting the filesystem.
> It has to call the right tools to do the format.
> 
> The rest of what you said about Grub is certainly true as well
> though.
> 
> josh
> 

well, /boot support is the least of the problems.  grub doesn't support
ext4 on /boot yet either, and grub does the wrong thing for xfs so
that's excluded too.  A separate /boot is pretty commonplace.

Aside from mkfs, Anaconda also needs to be able to detect fs types - it
uses blkid for that, but there is not yet a stable btrfs disk format for
blkid to recognize, so blkid can't get updated yet.

So it's all still a ways off.

But if you want to play w/ btrfs, you can almost certainly build the
kernel module against the kernel-devel package and have something usable.

(And since rawhide's btrfs-progs is already stale, I guess you can just
build that from source, too) :)

-Eric



From vonbrand at inf.utfsm.cl  Tue Oct 14 14:37:56 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 14 Oct 2008 11:37:56 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <20081013141623.GF3139@free.fr>
References: <200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<20081013122955.GF3087@free.fr>
	<1223904831.6770.597.camel@macbook.infradead.org>
	<20081013141623.GF3139@free.fr>
Message-ID: <200810141437.m9EEbufp022664@laptop14.inf.utfsm.cl>

Patrice Dumas <pertusus at free.fr> wrote:

[...]

> There can be a change in time, 1 year of innovative technologies

Fedora users are happy, you are grumbling that your "stable" setup
breaks each other day...

>                                                                  and 
> then only critical updates,

... and now you are happy, while Fedora users leave disappointed that there
is no new technology... and next cycle is a _huge_ jump, and your grumbling
can only get worse.

>                             if fedora maintainers are volunteering to
> keep on doing critical updates.

They aren't. It is enough of a chore to track upstream, to track upstream
_and_ backport fixes is too much to ask. And most fun comes to your average
geek from playing with the newest, shiniest toy around...

>                                 And I even think that 6 months of
> innovative technologies, 6 months with a slowdown in updates, only
> important updates, on user demand and then only critical fixes as long
> as a maintainer is doing them would even be better.

Tell you what, this is /exactly/ (well, almost) what you'd get following
CentOS or RHEL, only /without/ screwing up Fedora.
-- 
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 2340000       Fax:  +56 32 2797513



From alan at redhat.com  Tue Oct 14 14:50:55 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Oct 2008 10:50:55 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223984324.3029.299.camel@beck.corsepiu.local>
References: <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014081815.GA25871@shell.devel.redhat.com>
	<1223984324.3029.299.camel@beck.corsepiu.local>
Message-ID: <20081014145055.GA3068@shell.devel.redhat.com>

On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> I know the FSF-definition very well. They are defining free in the sense
> of "open source"

I don't think they agree with you there, in fact Richard would probably be most
upset at such a claim...

Alan
--
	"That was said by Eric Raymond who belongs to another movement" 
			- Richard Stallman



From pertusus at free.fr  Tue Oct 14 14:56:50 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 16:56:50 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
References: <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
	<200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
Message-ID: <20081014145650.GB3126@free.fr>

On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:
> 
> Show me the developers who are _commited_ on making it happen, then we can
> talk. The infrastructure is in place.

I am, and a few others. But the infrastructure is still not in place. I
mean it may be physically, but there hasn't been an agreement from
fedora leadership. But I'll propose something for th enext FESCo, we'll
see how it turns out.

> Fedora Legacy foundered because everybody said they wanted it, almost
> nobody was willing to do the (hard!) work, and in the end the "many users"
> didn't materialize either.

The work in the scope of this project will be less hard than what was
done in the scope of legacy, since there will be less QA, in fact the
same amount than in fedora.

I wanted to help fedora legacy, and I wasn't deterred by the packaging
work, but by the amount of QA compared with fedora extras, the processes
were much more complicated for me. I think that the quality was higher, 
too. I don't think that we need that quality right now. Legacy continued 
the Red Hat releases that were quite stable. Here the aim is to continue
fedora release that are very unstable. The aim is to try to be as stable
as possible, but with the same processes than in fedora.

--
Pat



From lesmikesell at gmail.com  Tue Oct 14 15:03:08 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 10:03:08 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014145055.GA3068@shell.devel.redhat.com>
References: <48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<20081014081815.GA25871@shell.devel.redhat.com>	<1223984324.3029.299.camel@beck.corsepiu.local>
	<20081014145055.GA3068@shell.devel.redhat.com>
Message-ID: <48F4B4AC.8010004@gmail.com>

Alan Cox wrote:
> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>> I know the FSF-definition very well. They are defining free in the sense
>> of "open source"
> 
> I don't think they agree with you there, in fact Richard would probably be most
> upset at such a claim...

Yes, the term "open source" came about to correct the FSF fanaticism and 
mean something useful...

-- 
   Les Mikesell
     lesmikesell at gmail.com



From jwboyer at gmail.com  Tue Oct 14 15:06:32 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 14 Oct 2008 11:06:32 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014145650.GB3126@free.fr>
References: <20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
	<200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
	<20081014145650.GB3126@free.fr>
Message-ID: <20081014150632.GB16227@yoda.jdub.homelinux.org>

On Tue, Oct 14, 2008 at 04:56:50PM +0200, Patrice Dumas wrote:
>On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:
>> 
>> Show me the developers who are _commited_ on making it happen, then we can
>> talk. The infrastructure is in place.
>
>I am, and a few others. But the infrastructure is still not in place. I
>mean it may be physically, but there hasn't been an agreement from
>fedora leadership. But I'll propose something for th enext FESCo, we'll
>see how it turns out.

As a suggestion, create your proposal focusing around opening the ACLs
on the older package branches, and keeping the build infrastructure in
place for them.  Don't mention "LTS" and take baby steps.

FESCo will likely ask for input from Infrastructure and Rel-Eng as well,
given that Rel-Eng would be required to push updates, and Infrastructure
will have to allocate storage for this.  Getting the conversation
started with those groups now would be advised.  Infrastructure has been
moving EOL releases to archives, so other changes would be needed to
point repos to the right locations would be needed also.

josh



From nils at redhat.com  Tue Oct 14 15:21:17 2008
From: nils at redhat.com (Nils Philippsen)
Date: Tue, 14 Oct 2008 17:21:17 +0200
Subject: transifex and PackageKit
In-Reply-To: <1223984638.3487.15.camel@hughsie-laptop>
References: <1223915316.3551.27.camel@hughsie-laptop>
	<1223983109.17970.40.camel@localhost.localdomain>
	<1223984638.3487.15.camel@hughsie-laptop>
Message-ID: <1223997677.24060.178.camel@localhost.localdomain>

On Tue, 2008-10-14 at 12:43 +0100, Richard Hughes wrote:
> On Tue, 2008-10-14 at 13:18 +0200, Nils Philippsen wrote:
> > Hi Richard,
> > 
> > On Mon, 2008-10-13 at 17:28 +0100, Richard Hughes wrote: 
> > > Today I released 0.3.7 and pushed it to rawhide. In a couple of weeks
> > > time they'll be a bugfix 0.3.8 release that we'll see in F10 and F9.
> > > 
> > > Before that time, I would like the translations for PackageKit to be
> > > updated -- updated translations are very important for the F10 release
> > > quality and also for the F9 backport.
> > > 
> > > You can see the current stats here:
> > > 
> > > http://translate.fedoraproject.org/module/packagekit#master
> > 
> > I've taken a look at the German translation and found out that some
> > messages are really hard to translate, partly because there are no
> > comments about the context, partly because the messages are not complete
> > sentences and you didn't use placeholders in there.
> 
> Sure, I really apologise. I'm generally rubbish at this sort of thing,
> so I appreciate any help.

No sweat, don't take it as criticism.

> > For example, I guess the string "Could not find what packages require"
> > could mean "I can't find out what some packages require that are already
> > mentioned elsewhere" but it could also be "I can't find out which
> > packages require (something else not mentioned)". The former should
> > probably be phrased "Couldn't find what these packages require.", the
> > latter "Couldn't find which packages require %1$s.": Note the complete
> > sentences and the indexed placeholder in the second one which lets
> > translators move around these things if necessary. Add a comment like
> > "placeholder is a list of packages" to put icing on that ;-).
> 
> Could you find any other dodgey strings and send a mail to the
> packagekit mailing list please? We'll then go through any of the bad
> ones, fixing them up and adding translator comments.
> 
> You don't need to subscribe if you don't want, I'll moderate you
> through.

I've just sent the mail, mind that I didn't flag all messages that have
a certain problem, just some as examples.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From kevin at scrye.com  Tue Oct 14 15:21:46 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Tue, 14 Oct 2008 09:21:46 -0600
Subject: compat-python, Zope...
In-Reply-To: <48F47C58.9060702@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
Message-ID: <20081014092146.1696d636@ohm.scrye.com>

On Tue, 14 Oct 2008 13:02:48 +0200
oliver at linux-kernel.at (Oliver Falk) wrote:

> OK. I think I've read the whole old thread now :-)
> 
> First of all: I *will* package compat-python and Zope/Plone, because
> I need it at work. The only question is if Fedora/FESCo wants me to
> share my work with the Fedora community or not!

FYI, note that compat-python24 and compat-zope are already in livna
(and I assume then also rpmfusion). 

Perhaps you could offer to help maintain those with their maintainer
there? Even less work, since they are already packaged/used. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/7213f688/attachment.sig>

From jkeating at redhat.com  Tue Oct 14 15:26:24 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 14 Oct 2008 08:26:24 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <48F497D6.5080405@gmail.com>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<200810141238.m9ECcVil009198@laptop14.inf.utfsm.cl>
	<48F497D6.5080405@gmail.com>
Message-ID: <1223997984.1710.1.camel@localhost.localdomain>

On Tue, 2008-10-14 at 08:00 -0500, Les Mikesell wrote:
> While I don't have much faith in Fedora to provide long term or even 
> short term stability, providing security fixes for bugs you shipped even 
> beyond the expected support time frame sounds like a very responsible 
> thing to do.

It would be, if all security updates were pushed, or at least all
critical updates.  However the current proposals are "whatever any
maintainer feels like" not even close to "all".  Leading people into
that realm via lazyness is in fact very irresponsible, and not something
Fedora would put it's name on.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/a0553a02/attachment.sig>

From nils at redhat.com  Tue Oct 14 15:29:27 2008
From: nils at redhat.com (Nils Philippsen)
Date: Tue, 14 Oct 2008 17:29:27 +0200
Subject: transifex and PackageKit
In-Reply-To: <1223997677.24060.178.camel@localhost.localdomain>
References: <1223915316.3551.27.camel@hughsie-laptop>
	<1223983109.17970.40.camel@localhost.localdomain>
	<1223984638.3487.15.camel@hughsie-laptop>
	<1223997677.24060.178.camel@localhost.localdomain>
Message-ID: <1223998167.24060.182.camel@localhost.localdomain>

On Tue, 2008-10-14 at 17:21 +0200, Nils Philippsen wrote:
> On Tue, 2008-10-14 at 12:43 +0100, Richard Hughes wrote:
> > On Tue, 2008-10-14 at 13:18 +0200, Nils Philippsen wrote:
> > > Hi Richard,
> > > 
> > > On Mon, 2008-10-13 at 17:28 +0100, Richard Hughes wrote: 
> > > > Today I released 0.3.7 and pushed it to rawhide. In a couple of weeks
> > > > time they'll be a bugfix 0.3.8 release that we'll see in F10 and F9.
> > > > 
> > > > Before that time, I would like the translations for PackageKit to be
> > > > updated -- updated translations are very important for the F10 release
> > > > quality and also for the F9 backport.
> > > > 
> > > > You can see the current stats here:
> > > > 
> > > > http://translate.fedoraproject.org/module/packagekit#master
> > > 
> > > I've taken a look at the German translation and found out that some
> > > messages are really hard to translate, partly because there are no
> > > comments about the context, partly because the messages are not complete
> > > sentences and you didn't use placeholders in there.
> > 
> > Sure, I really apologise. I'm generally rubbish at this sort of thing,
> > so I appreciate any help.
> 
> No sweat, don't take it as criticism.
> 
> > > For example, I guess the string "Could not find what packages require"
> > > could mean "I can't find out what some packages require that are already
> > > mentioned elsewhere" but it could also be "I can't find out which
> > > packages require (something else not mentioned)". The former should
> > > probably be phrased "Couldn't find what these packages require.", the
> > > latter "Couldn't find which packages require %1$s.": Note the complete
> > > sentences and the indexed placeholder in the second one which lets
> > > translators move around these things if necessary. Add a comment like
> > > "placeholder is a list of packages" to put icing on that ;-).
> > 
> > Could you find any other dodgey strings and send a mail to the
> > packagekit mailing list please? We'll then go through any of the bad
> > ones, fixing them up and adding translator comments.
> > 
> > You don't need to subscribe if you don't want, I'll moderate you
> > through.
> 
> I've just sent the mail, mind that I didn't flag all messages that have
> a certain problem, just some as examples.

Forgot one thing: Mind that you may want to talk to fedora-trans-list
before you dump boatloads of new messages into PK ;-).

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From opensource at till.name  Tue Oct 14 15:33:00 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 17:33:00 +0200
Subject: Fedora 8 and 9 updates re-enabled
In-Reply-To: <1223912036.3327.16.camel@luminos.localdomain>
References: <1221028475.3388.132.camel@luminos.localdomain>
	<200810121813.36870.opensource@till.name>
	<1223912036.3327.16.camel@luminos.localdomain>
Message-ID: <200810141733.12905.opensource@till.name>

On Mon October 13 2008, Jesse Keating wrote:
> On Sun, 2008-10-12 at 18:13 +0200, Till Maas wrote:
> > Is there a schedule when the Everything repo will be resigned with the
> > new key, so that the old gpg key can be purged?
>
> I've been working on this over the past week or two.  Hopefully within
> the next week we'll have the new stuff staged.

This is wonderful. In case I can help with something, please tell me.

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/20081014/55ef35a1/attachment.sig>

From fedora at leemhuis.info  Tue Oct 14 15:53:11 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 14 Oct 2008 17:53:11 +0200
Subject: First steps of the transition from Livna to RPM Fusion begins now
 for livna-devel users!
Message-ID: <48F4C067.90308@leemhuis.info>

Hi!

Find below a cut'n'pasted and slightly enhanced version of a post from 
my blog FYI:


As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ), 
the merger of Dribble, Freshrpms and Livna gets closer to its official 
release/start. Most of the packages from Livna have been imported and 
build for RPM Fusion already, hence we now begin to slowly move users 
from Livna over to RPM Fusion by activating the RPM Fusion free and 
nonfree rawhide repos for users of livna's devel branch *now*.

The transition works like this: I just added the rpmfusion-release 
packages for the RPM Fusion's free and nonfree rawhide repos to the 
livna-devel repo; in parallel I built a new livna-release package that 
tracks those two in with a hard dep. That way all users that installed 
livna properly (e.g. by installing the livna-release package) will get 
RPM Fusion repos enabled automatically with the next update. Yum/PK will 
hence with the overnext update will download a big bunch of updates, as 
all the packages were build anew for RPM Fusion; but rawhide users are 
likely used to big downloads, so this should hopefully not be a big 
problem ;-)

Note, nearly all of livna's packages have been imported and build for 
RPM Fusion, but a few are still missing. So you should leave livna-devel 
enabled for now if you want access to those. Once all the packages have 
a new home we'll let the rpmfusion-nonfree-release package obsolete 
livna-release.

But please note that all the packages that have been imported and build 
in RPM Fusion will *not* be updated anymore in livna-devel! Hence if you 
didn't install livna using the livna-release package then please enable 
RPM Fusion using the following command:

> rpm -ivh \
> http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm \
> http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm

That command from now on is the right one to use if you want RPM Fusion 
enabled on your fresh new Fedora Alpha/Beta/RC/Rawhide install.


FYI, the plan is to move livna users of F8 and F9 over to RPM Fusion 
with the same trick sooner or later. But some things in RPM Fusion need 
to get brought in shape before we start doing that. But if you want you 
can already help by using and testing RPM Fusion for F8 and F9 by 
running this command:

> rpm -ivh \
> http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
> http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

RPM Fusion's Bugtracker (please report all issues here and not on the 
mailing lists!):
http://bugzilla.rpmfusion.org/

Mailing lists for RPM Fusion users (includes users of the devel branch)
http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users

Mailing lists for RPM Fusion developers:
http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-developers


Please spread the news, to make sure all the docs in the internet get 
updated! tia!

CU
knurd

P.S.: BTW, some of you might have noticed already, the livna mailing 
lists (like freeworld{,-graphics}@livna.org) are dead since a few weeks; 
the hard disk in Anvil's mailman host died afaik (I don't know more 
details; sorry). But Livna will be superseded by RPM Fusion soon anyway, 
so simply use the those lists from rpmfusion from now on. They should 
serve well for the remaining time, as all the livna contributors should 
be subscribed there as well. Sorry for the trouble.

P.P.S.: Sorry for crossposting this to four lists, but it seemed wise 
for this announcement...



From jarod at redhat.com  Tue Oct 14 15:55:52 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Tue, 14 Oct 2008 11:55:52 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <m3od1o9nnz.fsf@ursa.amorsen.dk>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<m3od1o9nnz.fsf@ursa.amorsen.dk>
Message-ID: <200810141155.52793.jarod@redhat.com>

On Monday 13 October 2008 17:43:12 Benny Amorsen wrote:
> RHEL and CentOS are simply too slow for some things, unless you get
> very lucky and they happen to have a release at the perfect time.
>
> Imagine starting development on something to be deployed in half a
> year or a year. RHEL right now is on kernel 2.6.18. If you e.g. need
> some of the many new features of netfilter since 2.6.18, you're
> "stuck" with Fedora. Not that I mind in the least being stuck with
> Fedora, of course.

I don't mind being "stuck" with Fedora either, but I'd like to clarify 
something... If you need new features of netfilter (or other feature foo) 
since 2.6.18, its likely others do too, and its also likely that we've back-
ported said features to the RHEL5 kernel already (or intend to for the next 
release). Just because it says 2.6.18 doesn't mean its completely devoid of 
features that have gone upstream since then.

Certainly, there *are* cases where features can't/won't be back-ported to the 
RHEL kernel and a newer kernel is the only option, but beware of what you 
think the RHEL kernel can't do. ;)

-- 
Jarod Wilson
jarod at redhat.com



From jkeating at redhat.com  Tue Oct 14 15:56:27 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 14 Oct 2008 08:56:27 -0700
Subject: Regarding install options
In-Reply-To: <46a038f90810132031v19e2606cx123fa72dccbe7b10@mail.gmail.com>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<200810140045.20715.opensource@till.name>
	<1223938254.3056.12.camel@luminos.localdomain>
	<46a038f90810132031v19e2606cx123fa72dccbe7b10@mail.gmail.com>
Message-ID: <1223999787.1710.3.camel@luminos.localdomain>

On Tue, 2008-10-14 at 16:31 +1300, Martin Langhoff wrote:
> 
> Even working with anaconda and doing your own spins with revisor it's
> not easy to get a slim F9 install. It's almost impossible to shed the
> gtk/xorg toolchain because anaconda pulls it in.

I do believe that's just a compose tool problem, and one that I do
believe is fixed in rawhide.  You no longer need any of anaconda's deps
in your compose payload/manifest, as buildinstall will bring in what it
needs to create the graphical install images at compose time.  Your
images (stage2) will have the graphical stuff, but not your install
payload.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/ff66a97f/attachment.sig>

From jkeating at redhat.com  Tue Oct 14 15:57:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 14 Oct 2008 08:57:35 -0700
Subject: Regarding install options
In-Reply-To: <1223952014.3029.166.camel@beck.corsepiu.local>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<1223952014.3029.166.camel@beck.corsepiu.local>
Message-ID: <1223999856.1710.4.camel@luminos.localdomain>

On Tue, 2008-10-14 at 04:40 +0200, Ralf Corsepius wrote:
> Right, there is no singular expectation. But what Fedora currently
> offers is not even an approximation of a minimal install.

So lets see some comps patches for the @core group, because @core is
what you describe, and what you'd get if you unchecked all the boxes
during an interactive install, or just had %packages --nobase in
kickstart.  Please tell me how this doesn't meet your definition of
'minimal'.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/d3cf3eb7/attachment.sig>

From pertusus at free.fr  Tue Oct 14 15:27:00 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 17:27:00 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014150632.GB16227@yoda.jdub.homelinux.org>
References: <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
	<200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
	<20081014145650.GB3126@free.fr>
	<20081014150632.GB16227@yoda.jdub.homelinux.org>
Message-ID: <20081014152700.GD3126@free.fr>

On Tue, Oct 14, 2008 at 11:06:32AM -0400, Josh Boyer wrote:
> 
> As a suggestion, create your proposal focusing around opening the ACLs
> on the older package branches, and keeping the build infrastructure in
> place for them.  Don't mention "LTS" and take baby steps.

Agreed.

> FESCo will likely ask for input from Infrastructure and Rel-Eng as well,
> given that Rel-Eng would be required to push updates, and Infrastructure
> will have to allocate storage for this.  Getting the conversation
> started with those groups now would be advised.  Infrastructure has been
> moving EOL releases to archives, so other changes would be needed to
> point repos to the right locations would be needed also.

Yes. I have begun to read in the wiki how to contact infrastructure
people and things like that, I will certainly begin asking questions on
the relevant mailing lists soon.

--
Pat



From pertusus at free.fr  Tue Oct 14 16:00:44 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 18:00:44 +0200
Subject: Regarding install options
In-Reply-To: <20081014130555.GC28638@localhost.localdomain>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<200810140045.20715.opensource@till.name>
	<1223938254.3056.12.camel@luminos.localdomain>
	<46a038f90810132031v19e2606cx123fa72dccbe7b10@mail.gmail.com>
	<20081014075118.GC2657@free.fr>
	<20081014130555.GC28638@localhost.localdomain>
Message-ID: <20081014160044.GF3126@free.fr>

On Tue, Oct 14, 2008 at 09:05:56AM -0400, Chris Lumens wrote:
> > There is a bug in anaconda that forces all build time anaconda 
> > dependencies in, until this is fixed it is not possible to come with
> > something really small. Then we'll see once it is fixed.
> 
> And the bug number would be... ?  I'm not seeing this in the code at
> all.  The only things anaconda pulls in that aren't explicitly given by
> the user or the dependency of another package are:  filesystem
> utilities, raid/iscsi/whatever if you install that, gcc if you install
> kernel-devel, authconfig, chkconfig, mkinitrd, rhpl, and
> system-config-firewall-tui.

I couldn't find it, but Jesse responded in the same thread that the bug 
is closed now. And as Jesse said, it was an issue with composition
rather than with anaconda itself. 

--
Pat



From vonbrand at inf.utfsm.cl  Tue Oct 14 16:04:40 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 14 Oct 2008 13:04:40 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <m3tzbglc9h.fsf@ursa.amorsen.dk>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
Message-ID: <200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>

Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> Kevin Kofler <kevin.kofler at chello.at> writes:

> > Why would we want to? Just let things going as long as there is at
> > least one maintainer committing something. Even if not all security
> > issues get fixed, it's better than if none gets fixed.

> I'd love to see this. It could e.g. keep a service in the process of
> being decommissioned alive a little longer without having to do the
> usual upgrade.

Currently you have *6 months* to move over to the next Fedora...

> It wouldn't be good for anything too serious,

I.e., completely useless.

>                                               but if noone steps up
> for a necessary security patch, I could do it myself

Sorry, I very much doubt that.

>                                                      and then get to
> share the result with everyone else on that obsolete release. I would
> have to test all updates locally, but for services on the way out that
> is generally easier than testing the full upgrade.

It is even easier to migrate to CentOS and keep going with that one... the
difference is that the bumps in the road are much bigger, but you have a
couple of years to migrate your stuff.

> If it breaks something for someone, well, they should be more careful
> which updates they apply, especially once official support is gone. It
> might even encourage an upgrade and perhaps keep one box from being
> compromised.

How is that less work in the longer run than just keep upgrading or moving
to some LTS distribution?
-- 
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 2340000       Fax:  +56 32 2797513



From smooge at gmail.com  Tue Oct 14 16:19:09 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 10:19:09 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223991736.3029.347.camel@beck.corsepiu.local>
References: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
	<20081014132554.GT13066@br-online.de>
	<1223991736.3029.347.camel@beck.corsepiu.local>
Message-ID: <80d7e4090810140919p6cc26c33jd8e1cc152e7ceb4a@mail.gmail.com>

On Tue, Oct 14, 2008 at 7:42 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Tue, 2008-10-14 at 15:25 +0200, Ralph Angenendt wrote:
>> Ralf Corsepius wrote:
>> > This rationale contributes to me not to consider RHEL and CentOS, which
>> > is the rationale why I don't consider them to be replacements for a
>> > "Fedora LTS".
>>
>> So CentOS is non-free?
> CentOS is free as "free-beer", but CentOS is not free to take decisions
> on their own, because they depend on RHEL's sources.

Lets count how many angels dance on a pinhead...

Can I put any package into Fedora then? I mean if I wanted to put in a
package with EPOCH:MAXINT, provides: kernel, glibc, etc and just has a
%post rm -rf / I can add that into Fedora? Or would I be dependant on
Fedora packaging guidelines and packages?




-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From rc040203 at freenet.de  Tue Oct 14 16:20:03 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 18:20:03 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014145055.GA3068@shell.devel.redhat.com>
References: <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014081815.GA25871@shell.devel.redhat.com>
	<1223984324.3029.299.camel@beck.corsepiu.local>
	<20081014145055.GA3068@shell.devel.redhat.com>
Message-ID: <1224001203.3029.384.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> > I know the FSF-definition very well. They are defining free in the sense
> > of "open source"
> 
> I don't think they agree with you there, in fact Richard would probably be most
> upset at such a claim...
May-be, may-be not.

Fact is: The GPL's notion of freedom is essentially covering freedom on
"source code". It's "viral" nature has has some implications on binaries
("make source code available to customers"), but it nowhere states that
binaries having been built from GPL'ed sources must be "free-beer".

This notion actually is the door, which opens enterprises opportunities
to ship their binaries for money. Another door, enterprises use is
bundling trademarked packages next to GPL'ed packages or to claim
restrictive copyrights on the "collection" their product consists of.







From rc040203 at freenet.de  Tue Oct 14 16:22:39 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 18:22:39 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810140919p6cc26c33jd8e1cc152e7ceb4a@mail.gmail.com>
References: <200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
	<20081014082446.GD25871@shell.devel.redhat.com>
	<1223984075.3029.292.camel@beck.corsepiu.local>
	<48F4870F.4020207@nicubunu.ro>
	<1223985883.3029.306.camel@beck.corsepiu.local>
	<20081014132554.GT13066@br-online.de>
	<1223991736.3029.347.camel@beck.corsepiu.local>
	<80d7e4090810140919p6cc26c33jd8e1cc152e7ceb4a@mail.gmail.com>
Message-ID: <1224001359.3029.388.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 10:19 -0600, Stephen John Smoogen wrote:
> On Tue, Oct 14, 2008 at 7:42 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Tue, 2008-10-14 at 15:25 +0200, Ralph Angenendt wrote:
> >> Ralf Corsepius wrote:
> >> > This rationale contributes to me not to consider RHEL and CentOS, which
> >> > is the rationale why I don't consider them to be replacements for a
> >> > "Fedora LTS".
> >>
> >> So CentOS is non-free?
> > CentOS is free as "free-beer", but CentOS is not free to take decisions
> > on their own, because they depend on RHEL's sources.

> Can I put any package into Fedora then?
Yes, but you can't modify packages in CentOS, which would break
RHEL-compatibility, nor will you be able to add any package to EPEL, if
a release of CentOS doesn't meet this package's demands.





From jkeating at redhat.com  Tue Oct 14 16:03:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 14 Oct 2008 09:03:54 -0700
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F49C06.5070405@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<48F49676.7060008@gmail.com>
	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>
	<48F49C06.5070405@gmail.com>
Message-ID: <1224000234.1710.6.camel@localhost.localdomain>

On Tue, 2008-10-14 at 08:17 -0500, Les Mikesell wrote:
> 
> Can I buy one copy of a Red Hat package and redistribute it as the GPL 
> permits for any GPL covered portion?  Or install on as many machines as 
> I want?  Does every part that has any GPL component permit 
> redistribution of the work-as-a-whole?

You can, however you would be violating the terms of your Red Hat
Network service, and Red Hat would be in their rights to terminate your
service.

Common misconception.  You don't buy RHEL.  You buy a subscription to
the Red Hat Network service.  Via the RHN service you can obtain further
subscriptions to Red Hat Enterprise Linux, and note there is no version
there.  One RHEL entitlement would work for RHEL2.1 on up to RHEL5,
whichever one you choose.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/867a677e/attachment.sig>

From smooge at gmail.com  Tue Oct 14 16:28:32 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 10:28:32 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223967713.3029.282.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<1223967713.3029.282.camel@beck.corsepiu.local>
Message-ID: <80d7e4090810140928p6554d2efyd52ef74a9eccb88b@mail.gmail.com>

On Tue, Oct 14, 2008 at 1:01 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Tue, 2008-10-14 at 19:43 +1300, Martin Langhoff wrote:
>> On Tue, Oct 14, 2008 at 7:09 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> >> The free
>> >> availability of binaries is never a requirement for any of the free and
>> >> open source licenses.
>> > This is what RedHat propaganda is telling you.
>>
>> I've done several papers in Law School specifically on software
>> licensing and analysis of GPL and related licenses. Rahul's statement
>> is correct -- no licenses require availability of binaries.
>>
>> Might be awkward or less than helpful, but it's comfortably within the
>> rules of the license.
> I am not doubting this: It's a different definition of free. It's one
> case of the usual word-games with "freedom"-related words.
>
> To me, a product you can not get without having to pay for, doesn't
> qualify as free - It's may be free in the sense of "intellectual
> property", but this doesn't make it free in the "common man's sense".
>

I think common man's sense is not a logical item to deal with. The
common man does not speak English but most likely a SouthEast Asian
language, and they would probably use a word that means one of the 20
definitions of Free. The problem with the word Free as the was pointed
out since its inception and the FSF acknowledged after a while was
that it is an overloaded construct and has too many definitions. They
should have gone  with Libre or something as the French and other
languages have words that mean exactly what they were wanting.. but
English does not.

> Ask your neighbor, if he would pay USD600 for a barrel of "free beer".
>

Actually I know people who do. They spend over 600 for the ingredients
and brew their own in large vats.  But my neighbors would not fall
under the common man.

> Ralf
>
>
>
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From buc at odusz.so-cdu.ru  Tue Oct 14 16:49:11 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 14 Oct 2008 20:49:11 +0400
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <48F4C067.90308@leemhuis.info>
References: <48F4C067.90308@leemhuis.info>
Message-ID: <48F4CD87.6080402@odu.neva.ru>

Thorsten Leemhuis wrote:
> Note, nearly all of livna's packages have been imported and build for 
> RPM Fusion, but a few are still missing.

What about libdvdcss?

According to the bottom of the page at 
http://rpmfusion.org/SteeringCommittee, it was dropped.

Does it mean that for some packages (in general) users will still need 
Livna?


~buc



From fedora at leemhuis.info  Tue Oct 14 16:55:50 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 14 Oct 2008 18:55:50 +0200
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <48F4CD87.6080402@odu.neva.ru>
References: <48F4C067.90308@leemhuis.info> <48F4CD87.6080402@odu.neva.ru>
Message-ID: <48F4CF16.6020307@leemhuis.info>

On 14.10.2008 18:49, Dmitry Butskoy wrote:
> Thorsten Leemhuis wrote:
>> Note, nearly all of livna's packages have been imported and build for 
>> RPM Fusion, but a few are still missing.
> What about [...]

Note: We should not bring our friends at Red Hat into trouble, thus I 
will not answer this question here and instead will send the answer to 
the rpmfusion-developers lists (link to the list and its archives can be 
found in the first mail of this thread).

CU
knurd



From ivazqueznet at gmail.com  Tue Oct 14 16:20:57 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 14 Oct 2008 12:20:57 -0400
Subject: compat-python, Zope...
In-Reply-To: <20081014092146.1696d636@ohm.scrye.com>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info> <48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>
Message-ID: <1224001257.13861.56.camel@ignacio.lan>

On Tue, 2008-10-14 at 09:21 -0600, Kevin Fenzi wrote:
> FYI, note that compat-python24 and compat-zope are already in livna
> (and I assume then also rpmfusion). 
> 
> Perhaps you could offer to help maintain those with their maintainer
> there? Even less work, since they are already packaged/used. 

The maintainer, Jonathan Steffan (who is currently having email issues),
told me that he would appreciate having comaintainers. The livna
infrastructure doesn't support them, but the RPMFusion infrastructure
does.

-- 
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/20081014/bd08631c/attachment.sig>

From opensource at till.name  Tue Oct 14 17:00:02 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 19:00:02 +0200
Subject: Package review backlog.
In-Reply-To: <21964.198.175.55.5.1223986529.squirrel@mail.jcomserv.net>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<200810141048.21131.opensource@till.name>
	<21964.198.175.55.5.1223986529.squirrel@mail.jcomserv.net>
Message-ID: <200810141900.03678.opensource@till.name>

On Tue October 14 2008, Jon Ciesla wrote:
> > On Tue October 14 2008, David Woodhouse wrote:
> >> Maybe a one-line report to FESCo each week, stating the number of
> >> reviews completed in the past week and the number still outstanding,
> >> would be perfectly sufficient. It wasn't about _forcing_ people to
> >
> > How about updating this weekly:
> > http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus
>
> Even monthly, if it's a hassle, he said, not knowing how it was generated,
> and then noticing that he was undercaffienated and self-narrating, fell
> silent.

Yippie, I believe I finally understood what you were writing. ;-) Christian 
Iseli maintained and created it, I asked him via private mail for sources.

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/20081014/8c8cf41a/attachment.sig>

From fedora at leemhuis.info  Tue Oct 14 17:10:09 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 14 Oct 2008 19:10:09 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224001257.13861.56.camel@ignacio.lan>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>
	<1224001257.13861.56.camel@ignacio.lan>
Message-ID: <48F4D271.2080703@leemhuis.info>

On 14.10.2008 18:20, Ignacio Vazquez-Abrams wrote:
> On Tue, 2008-10-14 at 09:21 -0600, Kevin Fenzi wrote:
>> FYI, note that compat-python24 and compat-zope are already in livna
>> (and I assume then also rpmfusion). 
>>
>> Perhaps you could offer to help maintain those with their maintainer
>> there? Even less work, since they are already packaged/used. 
> The maintainer, Jonathan Steffan (who is currently having email issues),
> told me that he would appreciate having comaintainers. The livna
> infrastructure doesn't support them

Which is not true; the nvidia drivers for example are maintained by two 
different contributors together. I hope we for RPM Fusion can even find 
more maintainers for them, as there is afaics still room for lots of 
improvements and better testing when new drivers get released from upstream.

> but the RPMFusion infrastructure does.

Yep.

Cu
knurd



From rdieter at math.unl.edu  Tue Oct 14 17:13:46 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 14 Oct 2008 12:13:46 -0500
Subject: reviving Fedora Legacy
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>
Message-ID: <gd2k0a$cc0$1@ger.gmane.org>

Horst H. von Brand wrote:

> Benny Amorsen <benny+usenet at amorsen.dk> wrote:

>> I'd love to see this. It could e.g. keep a service in the process of
>> being decommissioned alive a little longer without having to do the
>> usual upgrade.
> 
> Currently you have *6 months* to move over to the next Fedora...

s/6/13/ ?

-- Rex



From lesmikesell at gmail.com  Tue Oct 14 17:23:29 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 12:23:29 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224001203.3029.384.camel@beck.corsepiu.local>
References: <48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<20081014081815.GA25871@shell.devel.redhat.com>	<1223984324.3029.299.camel@beck.corsepiu.local>	<20081014145055.GA3068@shell.devel.redhat.com>
	<1224001203.3029.384.camel@beck.corsepiu.local>
Message-ID: <48F4D591.3030909@gmail.com>

Ralf Corsepius wrote:
> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>>> I know the FSF-definition very well. They are defining free in the sense
>>> of "open source"
>> I don't think they agree with you there, in fact Richard would probably be most
>> upset at such a claim...
> May-be, may-be not.
> 
> Fact is: The GPL's notion of freedom is essentially covering freedom on
> "source code". It's "viral" nature has has some implications on binaries
> ("make source code available to customers"), but it nowhere states that
> binaries having been built from GPL'ed sources must be "free-beer".

There is no distinction between binaries and source in regard to the 
rights recipients have to redistribute them, except for the point that 
if you distribute binaries at all you must also make the corresponding 
source available to the recipeints.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From smooge at gmail.com  Tue Oct 14 17:25:05 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 11:25:05 -0600
Subject: reviving Fedora Legacy
In-Reply-To: <gd2k0a$cc0$1@ger.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>
	<gd2k0a$cc0$1@ger.gmane.org>
Message-ID: <80d7e4090810141025y7a8cdf2emd77f1ec6c89f1c9e@mail.gmail.com>

On Tue, Oct 14, 2008 at 11:13 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
> Horst H. von Brand wrote:
>
>> Benny Amorsen <benny+usenet at amorsen.dk> wrote:
>
>>> I'd love to see this. It could e.g. keep a service in the process of
>>> being decommissioned alive a little longer without having to do the
>>> usual upgrade.
>>
>> Currently you have *6 months* to move over to the next Fedora...
>
> s/6/13/ ?
>

I think the problem is that people have a hard time seeing what each
other is talking about. I think this is what the upgrade policy is.

           Release                 EOL
Fedora 8   2007-11-10      2008-12-25?
Fedora 9   2008-05-13      2008-05-XX
Fedora 10  2008-11-25?     2008-11-XX
Fedora 11  2008-05-XX      2009-05-XX

If Fedora were to make its schedules of 6 months.. and I am at Fedora
8, I have 7 months to move from Fedora 8 -> 9 since 8 isn't available
til 6 months out of my 13 month support. Now the lifetime of Fedora 8
would be 13 months.. but my window to upgrade before I lose security
is 7 months.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From smooge at gmail.com  Tue Oct 14 17:27:59 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 11:27:59 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F4D591.3030909@gmail.com>
References: <48EFAF3A.9080709@gmail.com>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014081815.GA25871@shell.devel.redhat.com>
	<1223984324.3029.299.camel@beck.corsepiu.local>
	<20081014145055.GA3068@shell.devel.redhat.com>
	<1224001203.3029.384.camel@beck.corsepiu.local>
	<48F4D591.3030909@gmail.com>
Message-ID: <80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>

On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Ralf Corsepius wrote:
>>
>> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
>>>
>>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>>>>
>>>> I know the FSF-definition very well. They are defining free in the sense
>>>> of "open source"
>>>
>>> I don't think they agree with you there, in fact Richard would probably
>>> be most
>>> upset at such a claim...
>>
>> May-be, may-be not.
>>
>> Fact is: The GPL's notion of freedom is essentially covering freedom on
>> "source code". It's "viral" nature has has some implications on binaries
>> ("make source code available to customers"), but it nowhere states that
>> binaries having been built from GPL'ed sources must be "free-beer".
>
> There is no distinction between binaries and source in regard to the rights
> recipients have to redistribute them, except for the point that if you
> distribute binaries at all you must also make the corresponding source
> available to the recipeints.
>

Do you have a lawyers advice on that? A courts decision on that? I ask
because I have yet to see legal advice that says that versus common
"well if I were the law, this is what I would interpret it to be."






-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From limb at jcomserv.net  Tue Oct 14 17:35:17 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 14 Oct 2008 12:35:17 -0500 (CDT)
Subject: Package review backlog.
In-Reply-To: <200810141900.03678.opensource@till.name>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<200810141048.21131.opensource@till.name>
	<21964.198.175.55.5.1223986529.squirrel@mail.jcomserv.net>
	<200810141900.03678.opensource@till.name>
Message-ID: <59619.198.175.55.5.1224005717.squirrel@mail.jcomserv.net>


> On Tue October 14 2008, Jon Ciesla wrote:
>> > On Tue October 14 2008, David Woodhouse wrote:
>> >> Maybe a one-line report to FESCo each week, stating the number of
>> >> reviews completed in the past week and the number still outstanding,
>> >> would be perfectly sufficient. It wasn't about _forcing_ people to
>> >
>> > How about updating this weekly:
>> > http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus
>>
>> Even monthly, if it's a hassle, he said, not knowing how it was
>> generated,
>> and then noticing that he was undercaffienated and self-narrating, fell
>> silent.
>
> Yippie, I believe I finally understood what you were writing. ;-)
> Christian
> Iseli maintained and created it, I asked him via private mail for sources.

Yeah, my English isn't always the best*.  Sorry about that. :)

> Regards,
> Till
>

*I am an American.

-- 
novus ordo absurdum



From rc040203 at freenet.de  Tue Oct 14 17:37:10 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Oct 2008 19:37:10 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>
References: <48EFAF3A.9080709@gmail.com>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014081815.GA25871@shell.devel.redhat.com>
	<1223984324.3029.299.camel@beck.corsepiu.local>
	<20081014145055.GA3068@shell.devel.redhat.com>
	<1224001203.3029.384.camel@beck.corsepiu.local>
	<48F4D591.3030909@gmail.com>
	<80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>
Message-ID: <1224005830.3029.396.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 11:27 -0600, Stephen John Smoogen wrote:
> On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> > Ralf Corsepius wrote:
> >>
> >> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
> >>>
> >>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
> >>>>
> >>>> I know the FSF-definition very well. They are defining free in the sense
> >>>> of "open source"
> >>>
> >>> I don't think they agree with you there, in fact Richard would probably
> >>> be most
> >>> upset at such a claim...
> >>
> >> May-be, may-be not.
> >>
> >> Fact is: The GPL's notion of freedom is essentially covering freedom on
> >> "source code". It's "viral" nature has has some implications on binaries
> >> ("make source code available to customers"), but it nowhere states that
> >> binaries having been built from GPL'ed sources must be "free-beer".
> >
> > There is no distinction between binaries and source in regard to the rights
> > recipients have to redistribute them, except for the point that if you
> > distribute binaries at all you must also make the corresponding source
> > available to the recipeints.
> >
> 
> Do you have a lawyers advice on that? A courts decision on that?
Yes, there have been cases in front of courts, where enterprises using
"binaries having been built from GPL'ed sources" without offering their
sources had been sued.

c.f. http://gpl-violations.org/

Check their "news".

Ralf




From lesmikesell at gmail.com  Tue Oct 14 17:39:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 12:39:59 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>
References: <48EFAF3A.9080709@gmail.com>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<20081014081815.GA25871@shell.devel.redhat.com>	<1223984324.3029.299.camel@beck.corsepiu.local>	<20081014145055.GA3068@shell.devel.redhat.com>	<1224001203.3029.384.camel@beck.corsepiu.local>	<48F4D591.3030909@gmail.com>
	<80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>
Message-ID: <48F4D96F.2060504@gmail.com>

Stephen John Smoogen wrote:
> On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> Ralf Corsepius wrote:
>>> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
>>>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>>>>> I know the FSF-definition very well. They are defining free in the sense
>>>>> of "open source"
>>>> I don't think they agree with you there, in fact Richard would probably
>>>> be most
>>>> upset at such a claim...
>>> May-be, may-be not.
>>>
>>> Fact is: The GPL's notion of freedom is essentially covering freedom on
>>> "source code". It's "viral" nature has has some implications on binaries
>>> ("make source code available to customers"), but it nowhere states that
>>> binaries having been built from GPL'ed sources must be "free-beer".
>> There is no distinction between binaries and source in regard to the rights
>> recipients have to redistribute them, except for the point that if you
>> distribute binaries at all you must also make the corresponding source
>> available to the recipeints.
>>
> 
> Do you have a lawyers advice on that? A courts decision on that? I ask
> because I have yet to see legal advice that says that versus common
> "well if I were the law, this is what I would interpret it to be."

I'm sure you could pay a lawyer to argue either side for you if you 
wanted, but I don't see any possible way to avoid the conclusion that a 
binary is a derivative of the original source and the license explicitly 
states that it applies to all derivative works.

-- 
    Les Mikesell
      lesmikesell at gmail.com



From behdad at behdad.org  Tue Oct 14 17:42:01 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 14 Oct 2008 13:42:01 -0400
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <200810141043.20354.opensource@till.name>
References: <20081012134001.GC2700@free.fr>
	<20081012201102.GB2688@free.fr>	<48F41729.30606@behdad.org>
	<200810141043.20354.opensource@till.name>
Message-ID: <48F4D9E9.70607@behdad.org>

Till Maas wrote:
> On Tue October 14 2008, Behdad Esfahbod wrote:
>>> On Sun, Oct 12, 2008 at 10:00:25AM -0700, Toshio Kuratomi wrote:
>>>> When I brought this up, Bastien Nocera brought up security bugs and not
>>>> wanting random people to be CC'd before a security bug is resolved.  How
>>>> should we deal with this?
>> I think the correct way to deal with this is that watchbugzilla should not
>> automatically CC user to bugs for the component, but instead modify the
>> user's bugzilla account to watch some special address like, eg for package
>> pango, pango-bugs at fedora.bugs.  And the product pango changed to have
>> pango-bugs at fedora.bugs as default assignee or Q/A contact.  This way we
>> avoid the security problem issue, as well as those inbox-filling mass
>> changes to remove people from CC lists or to change default assignee of the
>> product.
> 
> I do still not understand what the issue is and how this would resolve it, 
> e.g. if nobody who watches pango-bugs gets informed about security bugs, how 
> will the maintainer of the package get informed?

You're right.  So maybe only use the alias for Q/A and let the default
assignee be the maintainer(s).

> Nevertheless your proposal would fix the other issues you described. I would 
> only change to add pango-bugs to both the assignee and CC, to make sure 
> everyone stays in the loop, once the package is assigned to some individual.
> 
> Oh, but there is also a problem about your proposal. Afaik in this case, the 
> bugs do not appear on the Bugzilla Frontpage and/or the "My Bugs" search. Can 
> it made sure, that they do?

I thought "My Bugs" only shows bugs I opened or the ones assigned to me, not
all bugs I'm CC'ed on?


behdad

> Regards,
> Till
> 



From smooge at gmail.com  Tue Oct 14 17:44:56 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 11:44:56 -0600
Subject: reviving Fedora Legacy
In-Reply-To: <80d7e4090810141025y7a8cdf2emd77f1ec6c89f1c9e@mail.gmail.com>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>
	<gd2k0a$cc0$1@ger.gmane.org>
	<80d7e4090810141025y7a8cdf2emd77f1ec6c89f1c9e@mail.gmail.com>
Message-ID: <80d7e4090810141044l6d7f09a6sdf895bfc375afaa9@mail.gmail.com>

On Tue, Oct 14, 2008 at 11:25 AM, Stephen John Smoogen <smooge at gmail.com> wrote:
> On Tue, Oct 14, 2008 at 11:13 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
>> Horst H. von Brand wrote:
>>
>>> Benny Amorsen <benny+usenet at amorsen.dk> wrote:
>>
>>>> I'd love to see this. It could e.g. keep a service in the process of
>>>> being decommissioned alive a little longer without having to do the
>>>> usual upgrade.
>>>
>>> Currently you have *6 months* to move over to the next Fedora...
>>
>> s/6/13/ ?
>>
>
> I think the problem is that people have a hard time seeing what each
> other is talking about. I think this is what the upgrade policy is.
>
>           Release                 EOL
> Fedora 8   2007-11-10      2008-12-25?
> Fedora 9   2008-05-13      2008-05-XX
> Fedora 10  2008-11-25?     2008-11-XX
> Fedora 11  2008-05-XX      2009-05-XX
>

I don't know who the idiot who wrote this is... but boy he should be shot.

           Release                 EOL
Fedora  8  2007-11-10      2008-12-25?
Fedora  9  2008-05-13      2008-06-XX
Fedora 10  2008-11-25?     2009-12-XX
Fedora 11  2009-05-XX      2010-06-XX
Fedora 12  2009-11-XX      2010-12-XX
Fedora 13  2010-05-XX      2011-06-XX


> If Fedora were to make its schedules of 6 months.. and I am at Fedora
> 8, I have 7 months to move from Fedora 8 -> 9 since 8 isn't available
> til 6 months out of my 13 month support. Now the lifetime of Fedora 8
> would be 13 months.. but my window to upgrade before I lose security
> is 7 months.
>
> --
> Stephen J Smoogen. -- BSD/GNU/Linux
> How far that little candle throws his beams! So shines a good deed
> in a naughty world. = Shakespeare. "The Merchant of Venice"
>



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From bpepple at fedoraproject.org  Tue Oct 14 17:45:01 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 14 Oct 2008 13:45:01 -0400
Subject: Plan for tomorrows (20081014) FESCO meeting
Message-ID: <1224006301.23471.2.camel@truman>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Wednesday at 17:00
UTC in #fedora-meeting on irc.freenode.org:

/topic FESCo-Meeting -- MinGW - all

/topic FESCo meeting -- Free discussion around Fedora

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.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/3bcd6606/attachment.sig>

From skvidal at fedoraproject.org  Tue Oct 14 17:50:21 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 14 Oct 2008 13:50:21 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <80d7e4090810141044l6d7f09a6sdf895bfc375afaa9@mail.gmail.com>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>
	<gd2k0a$cc0$1@ger.gmane.org>
	<80d7e4090810141025y7a8cdf2emd77f1ec6c89f1c9e@mail.gmail.com>
	<80d7e4090810141044l6d7f09a6sdf895bfc375afaa9@mail.gmail.com>
Message-ID: <1224006621.16857.138.camel@rosebud>

On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
> I don't know who the idiot who wrote this is... but boy he should be shot.
> 
>            Release                 EOL
> Fedora  8  2007-11-10      2008-12-25?
> Fedora  9  2008-05-13      2008-06-XX

                             ^^^^ 2009-06-XX? I hope. :)


-sv




From lesmikesell at gmail.com  Tue Oct 14 17:50:44 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 12:50:44 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224005830.3029.396.camel@beck.corsepiu.local>
References: <48EFAF3A.9080709@gmail.com>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<20081014081815.GA25871@shell.devel.redhat.com>	<1223984324.3029.299.camel@beck.corsepiu.local>	<20081014145055.GA3068@shell.devel.redhat.com>	<1224001203.3029.384.camel@beck.corsepiu.local>	<48F4D591.3030909@gmail.com>	<80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>
	<1224005830.3029.396.camel@beck.corsepiu.local>
Message-ID: <48F4DBF4.3030900@gmail.com>

Ralf Corsepius wrote:
>
>>> There is no distinction between binaries and source in regard to the rights
>>> recipients have to redistribute them, except for the point that if you
>>> distribute binaries at all you must also make the corresponding source
>>> available to the recipeints.
>>>
>> Do you have a lawyers advice on that? A courts decision on that?
> Yes, there have been cases in front of courts, where enterprises using
> "binaries having been built from GPL'ed sources" without offering their
> sources had been sued.

I think the question was aimed at my implication that the redistribution 
  of GPL'd binaries could not have additional restrictions applied 
(beyond the GPL itself).  Have there been any actual cases where this 
requirement was challenged one way or another?  I think it is pretty 
clear from any reading of the license but most people focus on the source.

-- 
  Les Mikesell
    lesmikesell at gmail.com



From alsadi at gmail.com  Tue Oct 14 17:54:08 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 14 Oct 2008 20:54:08 +0300
Subject: OpenOffice and go-oo
In-Reply-To: <1223988957.10624.205.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
	<1223909556.10624.131.camel@vain.rhgalway>
	<385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>
	<1223934602.10624.179.camel@vain.rhgalway>
	<385866f0810131511s5ebd6588peda46c7dfe98cc67@mail.gmail.com>
	<1223988957.10624.205.camel@vain.rhgalway>
Message-ID: <385866f0810141054h54c7f049i7655a6e2d50bb5b2@mail.gmail.com>

> go-ooo unfortunately is not a magic version of OOo, so it is just not
> the case that it can fully work without java. On such a "java-less"
> 3.0.0 go-ooo, or even on your own LiveCD java-less OOo of probably
> fedora-vanilla-based 2.4.0...
>
> a) what happens when you run file->wizards->letter ?
> b) what happens when you enter a search term in the online help (note
> 3.0.0, not 2.4.X) ?
> c) what happens when you use tools->xml filter settings-> and add a new
> xslt transform and use "test xslts"
> d) and what happens when you run oobase and attempt to create a new
> local database.
>
> Those examples need java to work, whether go-ooo.org or vanilla.
>
regarding a, c in go-oo 2.4.x they just say "please install jre
package" see attachement

and b,d they are not included in the livecd they are in a separated
package, anyway who needs ooo-base in a livecd, fedora livecd don't
ship any replacement ooo-base

I'm not asking to make the striped openoffice the default, I'm asking
to make the default behaviour in comps to be full featured, but
packages dependency should allow removal of java for spinners like me,
ie. rpm -qpR openoffce.org-{core,writter,impress,calc} should not
mention any java dependency
-------------- next part --------------
A non-text attachment was scrubbed...
Name: go-oo.png
Type: image/png
Size: 9879 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/3103eb2e/attachment.png>

From smooge at gmail.com  Tue Oct 14 17:54:03 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 11:54:03 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224005830.3029.396.camel@beck.corsepiu.local>
References: <48EFAF3A.9080709@gmail.com>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014081815.GA25871@shell.devel.redhat.com>
	<1223984324.3029.299.camel@beck.corsepiu.local>
	<20081014145055.GA3068@shell.devel.redhat.com>
	<1224001203.3029.384.camel@beck.corsepiu.local>
	<48F4D591.3030909@gmail.com>
	<80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>
	<1224005830.3029.396.camel@beck.corsepiu.local>
Message-ID: <80d7e4090810141054u239e6875l853e3176f40fd23b@mail.gmail.com>

On Tue, Oct 14, 2008 at 11:37 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Tue, 2008-10-14 at 11:27 -0600, Stephen John Smoogen wrote:
>> On Tue, Oct 14, 2008 at 11:23 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> > Ralf Corsepius wrote:
>> >>
>> >> On Tue, 2008-10-14 at 10:50 -0400, Alan Cox wrote:
>> >>>
>> >>> On Tue, Oct 14, 2008 at 01:38:44PM +0200, Ralf Corsepius wrote:
>> >>>>
>> >>>> I know the FSF-definition very well. They are defining free in the sense
>> >>>> of "open source"
>> >>>
>> >>> I don't think they agree with you there, in fact Richard would probably
>> >>> be most
>> >>> upset at such a claim...
>> >>
>> >> May-be, may-be not.
>> >>
>> >> Fact is: The GPL's notion of freedom is essentially covering freedom on
>> >> "source code". It's "viral" nature has has some implications on binaries
>> >> ("make source code available to customers"), but it nowhere states that
>> >> binaries having been built from GPL'ed sources must be "free-beer".
>> >
>> > There is no distinction between binaries and source in regard to the rights
>> > recipients have to redistribute them, except for the point that if you
>> > distribute binaries at all you must also make the corresponding source
>> > available to the recipeints.
>> >
>>
>> Do you have a lawyers advice on that? A courts decision on that?
> Yes, there have been cases in front of courts, where enterprises using
> "binaries having been built from GPL'ed sources" without offering their
> sources had been sued.
>

That is a completely different problem space. We aren't even talking
apples and oranges but apples and orangutans.

Red Hat gives out the source to its customers.. which it is legally
obligated to. AND gives the source to us freeloaders, which it is not
legally obligated to.

Red Hat gives out its binaries to its customers but does not give it
out to us freeloaders which it is not legally obligated to.. any more
than you are legally obligated to give me a peanut and butter sandwich
that you just made if I came to your door.

Red Hat makes an agreement with you that you will get their compiled
binaries from them for X dollars and a stipulation that says "if you
share the binaries, we will not give you updates anymore." Companies
from the beginning of the GPL have done this and have been told by the
authors of the GPL that this was well within the intent of the license
as it does not restrict the usage of the source code in any way.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From smooge at gmail.com  Tue Oct 14 17:56:10 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 11:56:10 -0600
Subject: reviving Fedora Legacy
In-Reply-To: <1224006621.16857.138.camel@rosebud>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>
	<gd2k0a$cc0$1@ger.gmane.org>
	<80d7e4090810141025y7a8cdf2emd77f1ec6c89f1c9e@mail.gmail.com>
	<80d7e4090810141044l6d7f09a6sdf895bfc375afaa9@mail.gmail.com>
	<1224006621.16857.138.camel@rosebud>
Message-ID: <80d7e4090810141056j5868963bw3c7d471735117c00@mail.gmail.com>

On Tue, Oct 14, 2008 at 11:50 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
>> I don't know who the idiot who wrote this is... but boy he should be shot.
>>
>>            Release                 EOL
>> Fedora  8  2007-11-10      2008-12-25?
>> Fedora  9  2008-05-13      2008-06-XX
>
>                             ^^^^ 2009-06-XX? I hope. :)
>

Geez.. the guy who updated the original author really needs to be shot also.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From jameshubbard at gmail.com  Tue Oct 14 17:57:07 2008
From: jameshubbard at gmail.com (James Hubbard)
Date: Tue, 14 Oct 2008 13:57:07 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F4DBF4.3030900@gmail.com>
References: <48EFAF3A.9080709@gmail.com>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014081815.GA25871@shell.devel.redhat.com>
	<1223984324.3029.299.camel@beck.corsepiu.local>
	<20081014145055.GA3068@shell.devel.redhat.com>
	<1224001203.3029.384.camel@beck.corsepiu.local>
	<48F4D591.3030909@gmail.com>
	<80d7e4090810141027q43997d40n8120a71416770705@mail.gmail.com>
	<1224005830.3029.396.camel@beck.corsepiu.local>
	<48F4DBF4.3030900@gmail.com>
Message-ID: <f3ddc6d30810141057l5e64722r98d6142dfe0146cc@mail.gmail.com>

On Tue, Oct 14, 2008 at 1:50 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Ralf Corsepius wrote:
>>
>>>> There is no distinction between binaries and source in regard to the
>>>> rights
>>>> recipients have to redistribute them, except for the point that if you
>>>> distribute binaries at all you must also make the corresponding source
>>>> available to the recipeints.
>>>>
>>> Do you have a lawyers advice on that? A courts decision on that?
>>
>> Yes, there have been cases in front of courts, where enterprises using
>> "binaries having been built from GPL'ed sources" without offering their
>> sources had been sued.
>
> I think the question was aimed at my implication that the redistribution  of
> GPL'd binaries could not have additional restrictions applied (beyond the
> GPL itself).  Have there been any actual cases where this requirement was
> challenged one way or another?  I think it is pretty clear from any reading
> of the license but most people focus on the source.

Sveasoft required compliance with its policies if you wished to
continue to receive updates. The FSF looked into it.  See link and
quote below.

Sveasoft and the GPL: http://lwn.net/Articles/178550/
...
To some, it looks very much like Sveasoft is attempting to add
restrictions to the GPL-licensed software it uses for its products. It
is, in essence, imposing a penalty on anyone who redistributes its
products. In the end, however, challenges to this model have not
gotten far, and the Free Software Foundation has stated that Sveasoft
is in compliance with the GPL - at least, with regard to its support
agreements.
...



From lesmikesell at gmail.com  Tue Oct 14 17:31:29 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 12:31:29 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224000234.1710.6.camel@localhost.localdomain>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>
	<1224000234.1710.6.camel@localhost.localdomain>
Message-ID: <48F4D771.9080509@gmail.com>

Jesse Keating wrote:
> On Tue, 2008-10-14 at 08:17 -0500, Les Mikesell wrote:
>> Can I buy one copy of a Red Hat package and redistribute it as the GPL 
>> permits for any GPL covered portion?  Or install on as many machines as 
>> I want?  Does every part that has any GPL component permit 
>> redistribution of the work-as-a-whole?
> 
> You can, however you would be violating the terms of your Red Hat
> Network service, and Red Hat would be in their rights to terminate your
> service.

So there is a penalty for violating the restriction.  Can you still 
claim there is no restriction?

> Common misconception.  You don't buy RHEL.  You buy a subscription to
> the Red Hat Network service. 

The question wasn't about buying it.  It was about the redistribution 
restriction attached that the GPL does not permit.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From gmaxwell at gmail.com  Tue Oct 14 18:03:58 2008
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Tue, 14 Oct 2008 14:03:58 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48F4D771.9080509@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<48F49676.7060008@gmail.com>
	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>
	<48F49C06.5070405@gmail.com>
	<1224000234.1710.6.camel@localhost.localdomain>
	<48F4D771.9080509@gmail.com>
Message-ID: <e692861c0810141103l35cb9d84o3ac112400d991450@mail.gmail.com>

On Tue, Oct 14, 2008 at 1:31 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> So there is a penalty for violating the restriction.  Can you still claim
> there is no restriction?

I will no longer make you new copies of Linux CDs (or work on your bug
reports) if you allow your dog to dig up my tulip bed.

Have I placed a restriction on the free software that I've previously
given you?  Why would the situation change if I warned you about this
reality in advance?

On way of looking at free software licenses is:  Free software
licenses assure for the users of the software certain specific rights
with the FSF believes are both necessary and sufficient for software
to be considered free software.  Additional powers, like the ability
to get a software developer to listen to your bug reports, or a get
distributor to print more disks for you, are external to those rights.
These things are external to the license agreement, an necessarily so
since no one would accept a license which make them unbounded slaves
to all downstream recipients.


... such a stupid thread ...



From rmeggins at redhat.com  Tue Oct 14 18:05:23 2008
From: rmeggins at redhat.com (Rich Megginson)
Date: Tue, 14 Oct 2008 12:05:23 -0600
Subject: reviving Fedora Legacy
In-Reply-To: <80d7e4090810141056j5868963bw3c7d471735117c00@mail.gmail.com>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<m3tzbglc9h.fsf@ursa.amorsen.dk>	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>	<gd2k0a$cc0$1@ger.gmane.org>	<80d7e4090810141025y7a8cdf2emd77f1ec6c89f1c9e@mail.gmail.com>	<80d7e4090810141044l6d7f09a6sdf895bfc375afaa9@mail.gmail.com>	<1224006621.16857.138.camel@rosebud>
	<80d7e4090810141056j5868963bw3c7d471735117c00@mail.gmail.com>
Message-ID: <48F4DF63.3040709@redhat.com>

Stephen John Smoogen wrote:
> On Tue, Oct 14, 2008 at 11:50 AM, seth vidal <skvidal at fedoraproject.org> wrote:
>   
>> On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
>>     
>>> I don't know who the idiot who wrote this is... but boy he should be shot.
>>>
>>>            Release                 EOL
>>> Fedora  8  2007-11-10      2008-12-25?
>>> Fedora  9  2008-05-13      2008-06-XX
>>>       
>>                             ^^^^ 2009-06-XX? I hope. :)
>>
>>     
>
> Geez.. the guy who updated the original author really needs to be shot also.
>   

The directors of the project enlisted to     
correct the dates after the other   
people had been sacked, wish it to     
be known that they have just been      
sacked.                                

The release and EOL dates have been completed        
in an entirely different style at great
effort and at the last minute.

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

From ml at deadbabylon.de  Tue Oct 14 17:31:09 2008
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 14 Oct 2008 19:31:09 +0200
Subject: KDE-SIG weekly report (42/2008)
Message-ID: <200810141931.14664.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/2008

Time: 2008-10-14 16:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-14

Meeting log: https://fedoraproject.org/w/uploads/f/f9/KDE-SIG-2008-10-14.txt

----------------------------------------------------------------------------------

= Participants =

* JaroslavReznik 
* KevinKofler 
* KushalDas 
* LorenzoVillani 
* LukasTinkl 
* RexDieter 
* SebastianVahl 
* StevenParrish 
* ThanNgo

----------------------------------------------------------------------------------

= Agenda =

* Replacing gnome-packagekit with kpackagekit on KDE live images? 
* Release notes 
* artwork: kdm, ksplash, kwin background 
* kde-4.1.2 status, ready for (stable) updates soon? 
* kde-4.2.x cvs import status? 
* F10/rawhide testing

= Summary =

Replacing gnome-packagekit with kpackagekit on KDE live images? 
- - - - -
* kpackagekit will be proposed as default on Snapshot2. 
* If the testing doesn't go well this change will be reverted. 
* It wasn't decided during the meeting whether this only affects the live 
images or whether we also make the change in comps. 

Release notes:
- - - - -
* The Release Notes were updated to match the current KDE desktop and should 
be complete now. [1]
* Unfortunately the Desktop User Guide is still outdated. [2]
* We'll try chop this into smaller pieces to get this fixed soon (though any 
help here is appreciated). 
* JaroslavReznik will coordinate these efforts. 

artwork: kdm, ksplash, kwin background: 
- - - - -
* KSplash: only widescreen display support is missing. 
* KDM: work is still ongoing. 
* The backgrounds have to be packaged for KSplash and KDM. 

kde-4.1.2 status, ready for (stable) updates soon?:
- - - - -
* The issue with kioslaves not dying on exit was fixed today. 
* KDE 4.1.2 will be pushed to stable on Friday if no other blockers appear. 
* After that the autohide backport for plasma's panel will be pushed to 
testing. 

kde-4.2.x cvs import status: 
- - - - -
* According to LorenzoVillani, KDE 4.1.69 is building fine except kdebindings 
and kdebase. 
* The Fedora patches have to be re-checked if they all apply correctly. 
* Also the specfiles should be reviewed before actually getting imported into 
CVS. 

F10/rawhide testing: 
- - - - -
* (please see the log file for a list of short statements)

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-21

----------------------------------------------------------------------------------

= Links =

[1] https://fedoraproject.org/wiki/Docs/Beats#KDE
[2] https://fedoraproject.org/wiki/Docs/Drafts/DesktopUserGuide/KdeDesktop
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/31a7a1f3/attachment.sig>

From kevin.kofler at chello.at  Tue Oct 14 18:11:33 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 14 Oct 2008 18:11:33 +0000 (UTC)
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014093239.GA27002@mokona.greysector.net>
Message-ID: <loom.20081014T180137-585@post.gmane.org>

Dominik 'Rathann' Mierzejewski <dominik <at> greysector.net> writes:
> Another example of its brokenness is this: if you log out of the X session,
> you lose your (wireless) network connection.

Well, if you could help me fix the bugs in this patch:
http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00284.html
so it can get merged, that would solve this problem. :-)

> SELinux is another subject for a good rant. Example: I
> created /var/log/dovecot,
> chowned it to dovecot user and configured it to put its logs there. Bang!
> SELinux denial. There's no easy way to fix it permanently either and SELinux
> tools documentation is akin to arcane knowledge. Unless you're familiar with
> all the terminology, you won't understand it.

I also consider SELinux to be a useless PITA and I turn it off on all my 
machines (completely, not just permissive).

> PulseAudio is another mess. Three Fedora releases down the road and it still
> doesn't work right. It's another of the things I turn off and uninstall after
> installing a new Fedora box.

PulseAudio works for me.

        Kevin Kofler



From sundaram at fedoraproject.org  Tue Oct 14 18:15:37 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 14 Oct 2008 23:45:37 +0530
Subject: GPL Licensing
In-Reply-To: <48F4D771.9080509@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>	<1224000234.1710.6.camel@localhost.localdomain>
	<48F4D771.9080509@gmail.com>
Message-ID: <48F4E1C9.3060705@fedoraproject.org>

Les Mikesell wrote:

> The question wasn't about buying it.  It was about the redistribution 
> restriction attached that the GPL does not permit.

GPL requires that you will get the source if you get the binary but 
there is no requirement that forces anybody to give you the binaries in 
the first place including updates. So the subscriptions requirement are 
in compliance. Again, there is zero requirements in any free and open 
source license to give binaries for free to anybody because there is a 
limit to which copyright laws can extend itself.

You have to be pretty naive to think that Red Hat would build a business 
model without checking basic details like these. You might also want to 
note that Red Hat counsel involved is now a associate at the Software 
Freedom Law Center with Eben Moglen who wrote the license in the first 
place and Red Hat employs lawyers who participated in GPLv3 changes. If 
you actually believe that there is a license violation, feel free to 
convince any of the developers of GPL licensed code that Red Hat 
includes in RHEL or FSF itself. I am sure they would happy to tell you 
exactly why you are wrong in detail if necessary.

http://www.fsf.org/licensing/licenses/gpl-violation.html

Rahul



From kevin.kofler at chello.at  Tue Oct 14 18:22:56 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 14 Oct 2008 18:22:56 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<200810141238.m9ECcVil009198@laptop14.inf.utfsm.cl>
	<48F497D6.5080405@gmail.com>
	<1223997984.1710.1.camel@localhost.localdomain>
Message-ID: <loom.20081014T181932-105@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> It would be, if all security updates were pushed, or at least all
> critical updates.  However the current proposals are "whatever any
> maintainer feels like" not even close to "all".  Leading people into
> that realm via lazyness is in fact very irresponsible, and not something
> Fedora would put it's name on.

The assumption in the proposal is that if the update is really critical, 
somebody will care.

And those "lazy" people (in quotes because there are also other reasons than 
laziness) would otherwise end up with no updates at all, how is that better 
than at least providing _some_ security fixes, even if not all gets fixed?

        Kevin Kofler



From jkeating at redhat.com  Tue Oct 14 18:32:46 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 14 Oct 2008 11:32:46 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081014T181932-105@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012212120.GD2688@free.fr>	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<200810141238.m9ECcVil009198@laptop14.inf.utfsm.cl>
	<48F497D6.5080405@gmail.com>
	<1223997984.1710.1.camel@localhost.localdomain>
	<loom.20081014T181932-105@post.gmane.org>
Message-ID: <1224009166.4122.15.camel@luminos.localdomain>

On Tue, 2008-10-14 at 18:22 +0000, Kevin Kofler wrote:
> And those "lazy" people (in quotes because there are also other reasons than 
> laziness) would otherwise end up with no updates at all, how is that better 
> than at least providing _some_ security fixes, even if not all gets fixed?

No updates, as well as warnings from PackageKit et al that explains that
the release has gone end of life is a heck of a lot different from a
continued dribble of updates that /looks/ like the release is still in
good support.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/027db1f3/attachment.sig>

From mmcgrath at redhat.com  Tue Oct 14 18:59:32 2008
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 14 Oct 2008 13:59:32 -0500 (CDT)
Subject: Outage Notification - 2008-10-15 13:30 UTC
Message-ID: <alpine.LFD.1.10.0810141359130.19173@laptop.mmcgrath.net>

There will be an outage starting at 2008-10-15 13:30 UTC, which will last
approximately 1 hour.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2008-10-15 13:30 UTC'

Affected Services:

Buildsystem
Database
Fedora Hosted
Translation Services
Websites

Unaffected Services:

DNS
CVS / Source Control
Fedora People
Fedora Talk
Mail
Mirror System
Torrent


Ticket Link:

https://fedorahosted.org/fedora-infrastructure/ticket/911

Reason for Outage:

Migrating to postgres 8.3.  This should require minutes of outage time.
We're going to do a dump, delete, update, import.  Doing this one in the
morning because its short, so we can monitor it during the day instead of
have it fail at night, and so we don't interrupt any of the builds or
mashes that would happen in the evening.  Actual downtime should be about
5-10 minutes

Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From lesmikesell at gmail.com  Tue Oct 14 19:03:53 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 14:03:53 -0500
Subject: GPL Licensing
In-Reply-To: <48F4E1C9.3060705@fedoraproject.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>	<1224000234.1710.6.camel@localhost.localdomain>	<48F4D771.9080509@gmail.com>
	<48F4E1C9.3060705@fedoraproject.org>
Message-ID: <48F4ED19.5040203@gmail.com>

Rahul Sundaram wrote:
> Les Mikesell wrote:
> 
>> The question wasn't about buying it.  It was about the redistribution 
>> restriction attached that the GPL does not permit.
> 
> GPL requires that you will get the source if you get the binary but 
> there is no requirement that forces anybody to give you the binaries in 
> the first place including updates. So the subscriptions requirement are 
> in compliance. Again, there is zero requirements in any free and open 
> source license to give binaries for free to anybody because there is a 
> limit to which copyright laws can extend itself.

I didn't say anything about getting the first copy.  What I am saying is 
that the GPL forbids restrictions that could keep someone from 
redistributing their copy after they get it and there is no distinction 
in that regard whether the binary or source is involved.

> If 
> you actually believe that there is a license violation, feel free to 
> convince any of the developers of GPL licensed code that Red Hat 
> includes in RHEL or FSF itself. I am sure they would happy to tell you 
> exactly why you are wrong in detail if necessary.

I do think that if there is a penalty involved for redistributing copies 
of GPL'd code, binary or not, it conflicts with the 'no additional 
restrictions' clause of the GPL.  If they apply this restriction only to 
the non-GPL components, that would be different, but I don't know if 
that is the case.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From ralph+fedora at strg-alt-entf.org  Tue Oct 14 19:04:44 2008
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Tue, 14 Oct 2008 21:04:44 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1224006621.16857.138.camel@rosebud>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>
	<gd2k0a$cc0$1@ger.gmane.org>
	<80d7e4090810141025y7a8cdf2emd77f1ec6c89f1c9e@mail.gmail.com>
	<80d7e4090810141044l6d7f09a6sdf895bfc375afaa9@mail.gmail.com>
	<1224006621.16857.138.camel@rosebud>
Message-ID: <20081014190444.GD88732@br-online.de>

seth vidal wrote:
> On Tue, 2008-10-14 at 11:44 -0600, Stephen John Smoogen wrote:
> > I don't know who the idiot who wrote this is... but boy he should be shot.
> > 
> >            Release                 EOL
> > Fedora  8  2007-11-10      2008-12-25?
> > Fedora  9  2008-05-13      2008-06-XX
> 
>                              ^^^^ 2009-06-XX? I hope. :)

Just shoot that idiot again =:D

Ralph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/425f5b19/attachment.sig>

From sundaram at fedoraproject.org  Tue Oct 14 19:27:50 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 15 Oct 2008 00:57:50 +0530
Subject: GPL Licensing
In-Reply-To: <48F4ED19.5040203@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>	<1224000234.1710.6.camel@localhost.localdomain>	<48F4D771.9080509@gmail.com>	<48F4E1C9.3060705@fedoraproject.org>
	<48F4ED19.5040203@gmail.com>
Message-ID: <48F4F2B6.9080202@fedoraproject.org>

Les Mikesell wrote:

> I didn't say anything about getting the first copy.  What I am saying is 
> that the GPL forbids restrictions that could keep someone from 
> redistributing their copy after they get it and there is no distinction 
> in that regard whether the binary or source is involved.

Copy of the entire product is not bound by a single license. You are 
conflating two different things. Let's assume that what you claim is 
true. Even then, GPL is only a copyright license and applies only to 
selective components within the product. Red Hat still has its own 
trademarks on the product and Red Hat decides (within free use 
limitations) how that trademarks should be used. It is not free for all.

> I do think that if there is a penalty involved for redistributing copies 
> of GPL'd code, binary or not, it conflicts with the 'no additional 
> restrictions' clause of the GPL.  If they apply this restriction only to 
> the non-GPL components, that would be different, but I don't know if 
> that is the case.

The conflict in only in your mind. Without the subscription agreement, 
you don't get the initial binaries and you are only guaranteed ongoing 
updates from Red Hat if you agree to it. The requirements of GPL is 
orthogonal to this since this is a additional service as Gregory Maxwell 
has indicated to you as well with other examples. If you still have 
trouble understanding this, feel free to consult with FSF and ask them 
to explain it to you. It is a waste of time and off topic to continue 
discussing it here.

Rahul



From lesmikesell at gmail.com  Tue Oct 14 19:41:12 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 14:41:12 -0500
Subject: GPL Licensing
In-Reply-To: <48F4F2B6.9080202@fedoraproject.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>	<1224000234.1710.6.camel@localhost.localdomain>	<48F4D771.9080509@gmail.com>	<48F4E1C9.3060705@fedoraproject.org>	<48F4ED19.5040203@gmail.com>
	<48F4F2B6.9080202@fedoraproject.org>
Message-ID: <48F4F5D8.1080405@gmail.com>

Rahul Sundaram wrote:
> Les Mikesell wrote:
> 
>> I didn't say anything about getting the first copy.  What I am saying 
>> is that the GPL forbids restrictions that could keep someone from 
>> redistributing their copy after they get it and there is no 
>> distinction in that regard whether the binary or source is involved.
> 
> Copy of the entire product is not bound by a single license. You are 
> conflating two different things. Let's assume that what you claim is 
> true. Even then, GPL is only a copyright license and applies only to 
> selective components within the product. Red Hat still has its own 
> trademarks on the product and Red Hat decides (within free use 
> limitations) how that trademarks should be used. It is not free for all.

So if I'd like to circumvent GPL requirements, all I have to do is add a 
trademarked item to it?

>> I do think that if there is a penalty involved for redistributing 
>> copies of GPL'd code, binary or not, it conflicts with the 'no 
>> additional restrictions' clause of the GPL.  If they apply this 
>> restriction only to the non-GPL components, that would be different, 
>> but I don't know if that is the case.
> 
> The conflict in only in your mind. Without the subscription agreement, 
> you don't get the initial binaries and you are only guaranteed ongoing 
> updates from Red Hat if you agree to it. The requirements of GPL is 
> orthogonal to this since this is a additional service as Gregory Maxwell 
> has indicated to you as well with other examples.

The GPL says 'any further restrictions'.  It doesn't say some kinds of 
restrictions are OK and some not.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From opensource at till.name  Tue Oct 14 19:48:06 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 21:48:06 +0200
Subject: Package review backlog.
In-Reply-To: <59619.198.175.55.5.1224005717.squirrel@mail.jcomserv.net>
References: <20081008163852.GB5629@nostromo.devel.redhat.com>
	<200810141900.03678.opensource@till.name>
	<59619.198.175.55.5.1224005717.squirrel@mail.jcomserv.net>
Message-ID: <200810142148.22936.opensource@till.name>

On Tue October 14 2008, Jon Ciesla wrote:
> > On Tue October 14 2008, Jon Ciesla wrote:
> >> > On Tue October 14 2008, David Woodhouse wrote:
> >> >> Maybe a one-line report to FESCo each week, stating the number of
> >> >> reviews completed in the past week and the number still outstanding,
> >> >> would be perfectly sufficient. It wasn't about _forcing_ people to
> >> >
> >> > How about updating this weekly:
> >> > http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus
> >>
> >> Even monthly, if it's a hassle, he said, not knowing how it was
> >> generated,
> >> and then noticing that he was undercaffienated and self-narrating, fell
> >> silent.
> >
> > Yippie, I believe I finally understood what you were writing. ;-)
> > Christian
> > Iseli maintained and created it, I asked him via private mail for
> > sources.
>
> Yeah, my English isn't always the best*.  Sorry about that. :)

To me it looked like poetry ;-). Here are the sources for the reports btw:
http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora

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/20081014/d05440dd/attachment.sig>

From sundaram at fedoraproject.org  Tue Oct 14 19:54:33 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 15 Oct 2008 01:24:33 +0530
Subject: GPL Licensing
In-Reply-To: <48F4F5D8.1080405@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>	<1223875666.3564.1441.camel@beck.corsepiu.local>	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>	<1223955551.3029.219.camel@beck.corsepiu.local>	<48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>	<1224000234.1710.6.camel@localhost.localdomain>	<48F4D771.9080509@gmail.com>	<48F4E1C9.3060705@fedoraproject.org>	<48F4ED19.5040203@gmail.com>	<48F4F2B6.9080202@fedoraproject.org>
	<48F4F5D8.1080405@gmail.com>
Message-ID: <48F4F8F9.5030807@fedoraproject.org>

Les Mikesell wrote:

> So if I'd like to circumvent GPL requirements, all I have to do is add a 
> trademarked item to it?

Don't confuse trademark and copyright requirements. They are different.

> The GPL says 'any further restrictions'.  It doesn't say some kinds of 
> restrictions are OK and some not.

It is not so simple as you claim. Read carefully FSF's response on 
export requirements. Many such requirements are outside the purview of GPL.

http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF

"The GPL has no problem with you being picky about who you give the 
software to: if you want, you can decide that you'll only distribute to 
paying customers, or people with blue hair."

It appears you still have trouble understanding that GPL can only say no 
further restrictions on what it covers or you just don't want to 
understand. So go talk to someone who can explain it better if they can. 
Don't waste time on this off-topic conversation here. We are done with 
this.

Rahul



From atkac at redhat.com  Tue Oct 14 20:01:13 2008
From: atkac at redhat.com (Adam Tkac)
Date: Tue, 14 Oct 2008 22:01:13 +0200
Subject: Packaging guidelines update? - Naming snapshots
Message-ID: <20081014200113.GA31112@traged.atkac.englab.brq.redhat.com>

Hi all,

I'm trying pass tightvnc package through package review but I've been
informed that I don't meet package naming guidelines.

Source is pulled from upstream svn so I used this Revision tag and
.tar.bz2 name:

tightvnc-1.5.0-0.4.svn2975%{?dist}
tightvnc-1.5.0-svn2975.tar.bz2

Point where source was taken from upstream VCS is absolutely clear -
it was revision 2975 but packaging guidelines says that I have to use
date (something like 20081008svn or 20081008svn2975):

https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#SnapshotPackages

I think that guidelines should be updated and using of "revision" tag
should be allowed when upstream uses something like svn.

Do you have any comments?

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.



From opensource at till.name  Tue Oct 14 20:01:55 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 22:01:55 +0200
Subject: automatically grant watchbugzilla and watchcommits?
In-Reply-To: <48F4D9E9.70607@behdad.org>
References: <20081012134001.GC2700@free.fr>
	<200810141043.20354.opensource@till.name> <48F4D9E9.70607@behdad.org>
Message-ID: <200810142202.12326.opensource@till.name>

On Tue October 14 2008, Behdad Esfahbod wrote:
> Till Maas wrote:
> > On Tue October 14 2008, Behdad Esfahbod wrote:
> >>> On Sun, Oct 12, 2008 at 10:00:25AM -0700, Toshio Kuratomi wrote:
> >>>> When I brought this up, Bastien Nocera brought up security bugs and
> >>>> not wanting random people to be CC'd before a security bug is
> >>>> resolved.  How should we deal with this?
> >>
> >> I think the correct way to deal with this is that watchbugzilla should
> >> not automatically CC user to bugs for the component, but instead modify
> >> the user's bugzilla account to watch some special address like, eg for
> >> package pango, pango-bugs at fedora.bugs.  And the product pango changed to
> >> have pango-bugs at fedora.bugs as default assignee or Q/A contact.  This
> >> way we avoid the security problem issue, as well as those inbox-filling
> >> mass changes to remove people from CC lists or to change default
> >> assignee of the product.
> >
> > I do still not understand what the issue is and how this would resolve
> > it, e.g. if nobody who watches pango-bugs gets informed about security
> > bugs, how will the maintainer of the package get informed?
>
> You're right.  So maybe only use the alias for Q/A and let the default
> assignee be the maintainer(s).

I guess it cannot be really solved without someone providing the actual 
security concerns and scenarios where they apply.
The bug report about this does also not provide any information about this:
https://fedorahosted.org/packagedb/ticket/66


> > Nevertheless your proposal would fix the other issues you described. I
> > would only change to add pango-bugs to both the assignee and CC, to make
> > sure everyone stays in the loop, once the package is assigned to some
> > individual.
> >
> > Oh, but there is also a problem about your proposal. Afaik in this case,
> > the bugs do not appear on the Bugzilla Frontpage and/or the "My Bugs"
> > search. Can it made sure, that they do?
>
> I thought "My Bugs" only shows bugs I opened or the ones assigned to me,
> not all bugs I'm CC'ed on?

This is true for "My Frontpage", but the "My Bugs" query also shows every bug, 
where one is CC'ed.

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/20081014/f1fae606/attachment.sig>

From dan at danny.cz  Tue Oct 14 20:25:51 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 14 Oct 2008 22:25:51 +0200
Subject: Packaging guidelines update? - Naming snapshots
In-Reply-To: <20081014200113.GA31112@traged.atkac.englab.brq.redhat.com>
References: <20081014200113.GA31112@traged.atkac.englab.brq.redhat.com>
Message-ID: <1224015951.3593.71.camel@eagle.danny.cz>


Adam Tkac p??e v ?t 14. 10. 2008 v 22:01 +0200:
> Hi all,
> 
> I'm trying pass tightvnc package through package review but I've been
> informed that I don't meet package naming guidelines.
> 

I am doing the review, so I will try to explain.

> Source is pulled from upstream svn so I used this Revision tag and
> .tar.bz2 name:
> 
> tightvnc-1.5.0-0.4.svn2975%{?dist}
> tightvnc-1.5.0-svn2975.tar.bz2
> 
> Point where source was taken from upstream VCS is absolutely clear -
> it was revision 2975 but packaging guidelines says that I have to use
> date (something like 20081008svn or 20081008svn2975):

20081008svn2975 is preferred here

> 
> https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control
> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#SnapshotPackages
> 
> I think that guidelines should be updated and using of "revision" tag
> should be allowed when upstream uses something like svn.
> 

If I remember it correctly from the previous discussions on this theme,
then the main purpose of using date in the revision for svn, git, etc.
is that it is immediately clear how old is the snapshot. And this
information cannot be seen from the revision number or git hash without
asking the version control system first.


		Dan

-- 
Fedora and Red Hat package maintainer



From mastahnke at gmail.com  Tue Oct 14 20:25:48 2008
From: mastahnke at gmail.com (Michael Stahnke)
Date: Tue, 14 Oct 2008 15:25:48 -0500
Subject: Attn Ruby People: Package Review request
In-Reply-To: <7874d9dd0810140714s354245d6qb2690ab9410a2d8a@mail.gmail.com>
References: <7874d9dd0810140714s354245d6qb2690ab9410a2d8a@mail.gmail.com>
Message-ID: <7874d9dd0810141325q11f22e23idc196dc69b7b7cd3@mail.gmail.com>

On Tue, Oct 14, 2008 at 9:14 AM, Michael Stahnke <mastahnke at gmail.com> wrote:
> Two thing out here to the Ruby Community in Fedora:
>
> 1.  I have a package that has needed a review since May, I just
> updated it. https://bugzilla.redhat.com/show_bug.cgi?id=452450  This
> is RSPEC.
>
New updated and correct bug number:
https://bugzilla.redhat.com/show_bug.cgi?id=446563

(That's what I get for multi-tasking).






> 2.  ruby-rpm fails to build from source.
> https://bugzilla.redhat.com/show_bug.cgi?id=465103  I don't have a
> very good idea on what is needed to fix this. I am not the primary
> maintainer, but I am always interested in more Ruby stuff in Fedora.
> If anybody has time to fix this, it'd be great.
>
>
>
>
> stahnma
>



From pertusus at free.fr  Tue Oct 14 20:29:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 22:29:06 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <1224006301.23471.2.camel@truman>
References: <1224006301.23471.2.camel@truman>
Message-ID: <20081014202906.GB2688@free.fr>

On Tue, Oct 14, 2008 at 01:45:01PM -0400, Brian Pepple wrote:
> Hi,
> 
> 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.

I have drafted something for the possibility to keep infrastructure
runnin after EOL based on the discussions:

https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL

The discussion is still somehow on-going and there was no feedback on
this draft, but I think that there was already many things said in the
discussion and I hope to have faithfully transmitted the idea of the
people in favor of the proposal. I didn't put what people opposing to
the proposal object in the wiki, they can do it if they want to.

--
Pat



From kevin at scrye.com  Tue Oct 14 20:31:53 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Tue, 14 Oct 2008 14:31:53 -0600
Subject: reviving Fedora Legacy
In-Reply-To: <1223955785.3029.224.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<48F35E2E.8010507@gmail.com>
	<935ead450810130816q521271c9q49bfa9e83825ee61@mail.gmail.com>
	<1223955785.3029.224.camel@beck.corsepiu.local>
Message-ID: <20081014143153.29c0fb64@ohm.scrye.com>

On Tue, 14 Oct 2008 05:43:05 +0200
rc040203 at freenet.de (Ralf Corsepius) wrote:

> On Mon, 2008-10-13 at 10:16 -0500, Jeffrey Ollie wrote:
...snip...
> > 
> > Unfortunately, upstream developers don't always release bugfix-only
> > releases.  Many times they introduce new features or change the
> > behavior of old features.
> Right, and how do you expect EPEL to handle this issue?
> 
> I would expect EPEL to starve out contributors during RHEL's long time
> time and those who will try to continue supporting it, will be facing
> the problems you described.
> 
> May-be I missed it, but I would like to hear about EPEL's visions on
> this matter.

Sorry for the late reply. 

In many ways EPEL has it easy. Since they don't maintain the kernel,
glibc, and all the other packages that RHEL maintains. 

But you are right, for the packages they do maintain it will get harder
over time to backport security fixes or avoid updating versions.

I think the fact that EPEL doesn't have to handle those more
vulnerable core packages, and only has to worry about the leaf node
packages is one thing that makes it more viable. 

Also, note that since many of the packages in EPEL are leaf nodes /
add on packages they don't tend to have deep dependencies that more
central packages have. 
 
> Ralf

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/845ad5e1/attachment.sig>

From jlaska at redhat.com  Tue Oct 14 20:34:55 2008
From: jlaska at redhat.com (James Laska)
Date: Tue, 14 Oct 2008 16:34:55 -0400
Subject: 2008-10-16 - Fedora Test Day - Security Audit and Better LIRC
	Support
Message-ID: <1224016495.7420.56.camel@flatline>

Greetings folks,

I'd like to invite testers and users to join #fedora-qa this Thursday,
October 16, 2008.  Testing efforts will focus on:

      * Security Audit
      * Better LIRC Support
      * Fedora 10 Beta snapshot#1 

Come with questions, bug reports, and/or suggested test areas.

More details will be posted to
https://fedoraproject.org/wiki/QA/Test_Days/2008-10-16.

See you there,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081014/0187ad0b/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 alan at redhat.com  Tue Oct 14 20:49:43 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Oct 2008 16:49:43 -0400
Subject: GPL Licensing
In-Reply-To: <48F4ED19.5040203@gmail.com>
References: <48F430AD.5050002@fedoraproject.org>
	<1223964555.3029.273.camel@beck.corsepiu.local>
	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<48F49676.7060008@gmail.com>
	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>
	<48F49C06.5070405@gmail.com>
	<1224000234.1710.6.camel@localhost.localdomain>
	<48F4D771.9080509@gmail.com> <48F4E1C9.3060705@fedoraproject.org>
	<48F4ED19.5040203@gmail.com>
Message-ID: <20081014204943.GD10101@shell.devel.redhat.com>

On Tue, Oct 14, 2008 at 02:03:53PM -0500, Les Mikesell wrote:
> I do think that if there is a penalty involved for redistributing copies 
> of GPL'd code, binary or not, it conflicts with the 'no additional 
> restrictions' clause of the GPL.  If they apply this restriction only to 
> the non-GPL components, that would be different, but I don't know if 
> that is the case.

To start at the beginning of your confusion - it isn't a penalty. I'm entitled
not to distribute anything to you. I'm entitled to exclude aol.com from my
download site.

So its an additional service with conditions. That is quite different. Your
GPL rights are the same before or after.



From opensource at till.name  Tue Oct 14 20:53:24 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 22:53:24 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <20081014202906.GB2688@free.fr>
References: <1224006301.23471.2.camel@truman> <20081014202906.GB2688@free.fr>
Message-ID: <200810142253.43378.opensource@till.name>

On Tue October 14 2008, Patrice Dumas wrote:
> On Tue, Oct 14, 2008 at 01:45:01PM -0400, Brian Pepple wrote:
> > Hi,
> >
> > 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.
>
> I have drafted something for the possibility to keep infrastructure
> runnin after EOL based on the discussions:
>
> https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_E
>OL
>
> The discussion is still somehow on-going and there was no feedback on
> this draft, but I think that there was already many things said in the
> discussion and I hope to have faithfully transmitted the idea of the
> people in favor of the proposal. I didn't put what people opposing to
> the proposal object in the wiki, they can do it if they want to.

For how many Fedora Releases do you want to keep then infrastructure running 
after EOL? E.g. in bodhi the oldest supported release is at the top of the 
menu, having the releases there, that probably the majority of maintainers 
does not care about at the top is not so nice. Maybe the UI can be adapted to 
allow to specify which releases on is interested.

Will there be a script that orphans all packages of the EOL release for every 
non interested maintainer in packagedb, so that the interested maintainers 
can pick it up and the non interested maintainers do not get unecessary 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/20081014/249a8df2/attachment.sig>

From pertusus at free.fr  Tue Oct 14 21:05:56 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 23:05:56 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <200810142253.43378.opensource@till.name>
References: <1224006301.23471.2.camel@truman> <20081014202906.GB2688@free.fr>
	<200810142253.43378.opensource@till.name>
Message-ID: <20081014210556.GD2688@free.fr>

On Tue, Oct 14, 2008 at 10:53:24PM +0200, Till Maas wrote:
> 
> For how many Fedora Releases do you want to keep then infrastructure running 
> after EOL? E.g. in bodhi the oldest supported release is at the top of the 

I think it is a bit too soon to answer, but maybe something like 3 years
max, or 5 years max. And maybe try to be long enough such that it allows
to upgrade to the next RHEL+EPEL (that is all the evr in the RHEL/Centos
are higher than those at the time fedora was EOLed, and we hope or try
to have packagers not render this upgrade path impossible).

> menu, having the releases there, that probably the majority of maintainers 
> does not care about at the top is not so nice. Maybe the UI can be adapted to 
> allow to specify which releases on is interested.

Indeed, having 6 additional release will clutter bohdi a lot (whether
they are at the top or not, in fact...). This is not only an issue for
this proposal, but also for EPEL, for the day it switches to bodhi, 
and something that requires some thinking. The most simple would be to
use another bodhi instance, but I can only guess that bodhi requires
some work to be set up, which contradicts using few fedora resources.
I will ask on the infras list.

> Will there be a script that orphans all packages of the EOL release for every 
> non interested maintainer in packagedb, so that the interested maintainers 
> can pick it up and the non interested maintainers do not get unecessary mail?

This is in the 'Possible follow-up' section, but maybe this should be
done right from the start.

--
Pat



From opensource at till.name  Tue Oct 14 21:25:32 2008
From: opensource at till.name (Till Maas)
Date: Tue, 14 Oct 2008 23:25:32 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <20081014210556.GD2688@free.fr>
References: <1224006301.23471.2.camel@truman>
	<200810142253.43378.opensource@till.name>
	<20081014210556.GD2688@free.fr>
Message-ID: <200810142325.45200.opensource@till.name>

On Tue October 14 2008, Patrice Dumas wrote:
> On Tue, Oct 14, 2008 at 10:53:24PM +0200, Till Maas wrote:

> > Will there be a script that orphans all packages of the EOL release for
> > every non interested maintainer in packagedb, so that the interested
> > maintainers can pick it up and the non interested maintainers do not get
> > unecessary mail?
>
> This is in the 'Possible follow-up' section, but maybe this should be
> done right from the start.

Oh, I should not have skipped that section. This orphaning should be probably 
somehow enhanced, that also co-maintainers are removed, who are not 
interested. But it is hard to estimate how much this will be annoying, i.e. 
how many changes there will be for how many packages. But it will also allow 
to easier to track which packages are maintained in the EOL branch, which is 
also useful for people, who want to have a certain package maintained.

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/20081014/cc1d72b3/attachment.sig>

From lesmikesell at gmail.com  Tue Oct 14 21:14:24 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 16:14:24 -0500
Subject: GPL Licensing
In-Reply-To: <20081014204943.GD10101@shell.devel.redhat.com>
References: <48F430AD.5050002@fedoraproject.org>	<1223964555.3029.273.camel@beck.corsepiu.local>	<46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>	<1224000234.1710.6.camel@localhost.localdomain>	<48F4D771.9080509@gmail.com>
	<48F4E1C9.3060705@fedoraproject.org>	<48F4ED19.5040203@gmail.com>
	<20081014204943.GD10101@shell.devel.redhat.com>
Message-ID: <48F50BB0.5030806@gmail.com>

Alan Cox wrote:
> On Tue, Oct 14, 2008 at 02:03:53PM -0500, Les Mikesell wrote:
>> I do think that if there is a penalty involved for redistributing copies 
>> of GPL'd code, binary or not, it conflicts with the 'no additional 
>> restrictions' clause of the GPL.  If they apply this restriction only to 
>> the non-GPL components, that would be different, but I don't know if 
>> that is the case.
> 
> To start at the beginning of your confusion - it isn't a penalty. I'm entitled
> not to distribute anything to you. I'm entitled to exclude aol.com from my
> download site.
> 
> So its an additional service with conditions.

Yes, conditions that are an additional restriction of what I can do with 
a GPL-covered work.

> That is quite different. Your
> GPL rights are the same before or after.

No they aren't if I lose something I've paid for.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From pertusus at free.fr  Tue Oct 14 21:29:54 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 14 Oct 2008 23:29:54 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <200810142325.45200.opensource@till.name>
References: <1224006301.23471.2.camel@truman>
	<200810142253.43378.opensource@till.name>
	<20081014210556.GD2688@free.fr>
	<200810142325.45200.opensource@till.name>
Message-ID: <20081014212954.GB4141@free.fr>

On Tue, Oct 14, 2008 at 11:25:32PM +0200, Till Maas wrote:
> On Tue October 14 2008, Patrice Dumas wrote:
> > On Tue, Oct 14, 2008 at 10:53:24PM +0200, Till Maas wrote:
> 
> > > Will there be a script that orphans all packages of the EOL release for
> > > every non interested maintainer in packagedb, so that the interested
> > > maintainers can pick it up and the non interested maintainers do not get
> > > unecessary mail?
> >
> > This is in the 'Possible follow-up' section, but maybe this should be
> > done right from the start.
> 
> Oh, I should not have skipped that section. This orphaning should be probably 
> somehow enhanced, that also co-maintainers are removed, who are not 
> interested. But it is hard to estimate how much this will be annoying, i.e. 

Indeed. I will change the page, thanks.

> how many changes there will be for how many packages. But it will also allow 
> to easier to track which packages are maintained in the EOL branch, which is 
> also useful for people, who want to have a certain package maintained.

Indeed. I didn't want to put that in the initial proposal, to try to
minimize the changes as much as possible.

--
Pat



From denis at poolshark.org  Tue Oct 14 21:59:46 2008
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 14 Oct 2008 23:59:46 +0200
Subject: Packaging guidelines update? - Naming snapshots
In-Reply-To: <1224015951.3593.71.camel@eagle.danny.cz>
References: <20081014200113.GA31112@traged.atkac.englab.brq.redhat.com>
	<1224015951.3593.71.camel@eagle.danny.cz>
Message-ID: <48F51652.5020809@poolshark.org>

Dan Hor?k wrote:
> Adam Tkac p????e v ??t 14. 10. 2008 v 22:01 +0200:
>> Hi all,
>>
>> I'm trying pass tightvnc package through package review but I've been
>> informed that I don't meet package naming guidelines.
>>
> 
> I am doing the review, so I will try to explain.
> 
>> Source is pulled from upstream svn so I used this Revision tag and
>> .tar.bz2 name:
>>
>> tightvnc-1.5.0-0.4.svn2975%{?dist}
>> tightvnc-1.5.0-svn2975.tar.bz2
>>
>> Point where source was taken from upstream VCS is absolutely clear -
>> it was revision 2975 but packaging guidelines says that I have to use
>> date (something like 20081008svn or 20081008svn2975):
> 
> 20081008svn2975 is preferred here

It doesn't make much sense to put both date and svn revision into the 
tag. Use one or the other. For CVS, the date is the only option of 
course. Most of the svn snapshots packages we have right now only use 
the revision number, which in the case of svn is more accurate than the 
snapshot date.

Mabye the FPC can revisit this if the wiki page is confusing...

-denis



From cdahlin at redhat.com  Tue Oct 14 22:00:17 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 14 Oct 2008 18:00:17 -0400
Subject: Attn Ruby People: Package Review request
In-Reply-To: <7874d9dd0810141325q11f22e23idc196dc69b7b7cd3@mail.gmail.com>
References: <7874d9dd0810140714s354245d6qb2690ab9410a2d8a@mail.gmail.com>
	<7874d9dd0810141325q11f22e23idc196dc69b7b7cd3@mail.gmail.com>
Message-ID: <48F51671.7090908@redhat.com>

Michael Stahnke wrote:
> On Tue, Oct 14, 2008 at 9:14 AM, Michael Stahnke <mastahnke at gmail.com> wrote:
>   
>> Two thing out here to the Ruby Community in Fedora:
>>
>> 1.  I have a package that has needed a review since May, I just
>> updated it. https://bugzilla.redhat.com/show_bug.cgi?id=452450  This
>> is RSPEC.
>>
>>     
> New updated and correct bug number:
> https://bugzilla.redhat.com/show_bug.cgi?id=446563
>
> (That's what I get for multi-tasking).
>
>
>
>
>   

I'll swap you. Here's a review request for rcov:

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

--CJD

>
>   
>> 2.  ruby-rpm fails to build from source.
>> https://bugzilla.redhat.com/show_bug.cgi?id=465103  I don't have a
>> very good idea on what is needed to fix this. I am not the primary
>> maintainer, but I am always interested in more Ruby stuff in Fedora.
>> If anybody has time to fix this, it'd be great.
>>
>>
>>
>>
>> stahnma
>>
>>     
>
>   



From paul at city-fan.org  Tue Oct 14 22:28:45 2008
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 14 Oct 2008 23:28:45 +0100
Subject: Packaging guidelines update? - Naming snapshots
In-Reply-To: <48F51652.5020809@poolshark.org>
References: <20081014200113.GA31112@traged.atkac.englab.brq.redhat.com>
	<1224015951.3593.71.camel@eagle.danny.cz>
	<48F51652.5020809@poolshark.org>
Message-ID: <20081014232845.5645ccfe@metropolis.intra.city-fan.org>

On Tue, 14 Oct 2008 23:59:46 +0200
Denis Leroy <denis at poolshark.org> wrote:

> Dan Hor?k wrote:
> > Adam Tkac p????e v ??t 14. 10. 2008 v 22:01 +0200:
> >> Hi all,
> >>
> >> I'm trying pass tightvnc package through package review but I've
> >> been informed that I don't meet package naming guidelines.
> >>
> > 
> > I am doing the review, so I will try to explain.
> > 
> >> Source is pulled from upstream svn so I used this Revision tag and
> >> .tar.bz2 name:
> >>
> >> tightvnc-1.5.0-0.4.svn2975%{?dist}
> >> tightvnc-1.5.0-svn2975.tar.bz2
> >>
> >> Point where source was taken from upstream VCS is absolutely clear
> >> - it was revision 2975 but packaging guidelines says that I have
> >> to use date (something like 20081008svn or 20081008svn2975):
> > 
> > 20081008svn2975 is preferred here
> 
> It doesn't make much sense to put both date and svn revision into the 
> tag. Use one or the other. For CVS, the date is the only option of 
> course. Most of the svn snapshots packages we have right now only use 
> the revision number, which in the case of svn is more accurate than
> the snapshot date.
> 
> Mabye the FPC can revisit this if the wiki page is confusing...

The wiki page is IMO quite clear and requires the date. There are
examples on the page of svn checkouts that include the date.

The FPC are aware that a date can be inferred from an svn revision
number but felt that including the date was useful anyway, as a reading
of the discussion around the subject shows:

https://fedoraproject.org/wiki/Packaging/Minutes20070619
https://fedoraproject.org/wiki/Packaging/Minutes20070626

Paul.



From alan at redhat.com  Tue Oct 14 22:44:20 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Oct 2008 18:44:20 -0400
Subject: GPL Licensing
In-Reply-To: <48F50BB0.5030806@gmail.com>
References: <46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<48F49676.7060008@gmail.com>
	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>
	<48F49C06.5070405@gmail.com>
	<1224000234.1710.6.camel@localhost.localdomain>
	<48F4D771.9080509@gmail.com> <48F4E1C9.3060705@fedoraproject.org>
	<48F4ED19.5040203@gmail.com>
	<20081014204943.GD10101@shell.devel.redhat.com>
	<48F50BB0.5030806@gmail.com>
Message-ID: <20081014224420.GB22182@shell.devel.redhat.com>

On Tue, Oct 14, 2008 at 04:14:24PM -0500, Les Mikesell wrote:
> >not to distribute anything to you. I'm entitled to exclude aol.com from my
> >download site.
> >
> >So its an additional service with conditions.
> 
> Yes, conditions that are an additional restriction of what I can do with 
> a GPL-covered work.

Its an additional service. It doesn't change your GPL rights. If you can't grasp
that basic concept then I think you have a problem.




From caolanm at redhat.com  Tue Oct 14 22:51:21 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Tue, 14 Oct 2008 23:51:21 +0100
Subject: OpenOffice and go-oo
In-Reply-To: <385866f0810141054h54c7f049i7655a6e2d50bb5b2@mail.gmail.com>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
	<385866f0810130601i2ba0552avcfbd97145124fc96@mail.gmail.com>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
	<1223909556.10624.131.camel@vain.rhgalway>
	<385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>
	<1223934602.10624.179.camel@vain.rhgalway>
	<385866f0810131511s5ebd6588peda46c7dfe98cc67@mail.gmail.com>
	<1223988957.10624.205.camel@vain.rhgalway>
	<385866f0810141054h54c7f049i7655a6e2d50bb5b2@mail.gmail.com>
Message-ID: <1224024681.10624.250.camel@vain.rhgalway>

On Tue, 2008-10-14 at 20:54 +0300, Muayyad AlSadi wrote:
> > a) what happens when you run file->wizards->letter ?
...
> > c) what happens when you use tools->xml filter settings-> and add a new
> > xslt transform and use "test xslts"
...
> >
> > Those examples need java to work, whether go-ooo.org or vanilla.
> >
> regarding a, c in go-oo 2.4.x they just say "please install jre
> package" see attachement

There's no magic go-ooo pixie dust there, that's a vanilla dialog shown
when no jvm/java-infrastructure at all is found when trying to trigger
java-dependant functionality. The OOo of that screen-shot hasn't found a
jvm at all. If there *was* a jvm, the next stage would be to find out
that the next set of requirements is missing, at which point something
generally will fail silently. i.e. that dialog says "no java was found",
if there *was* a java but not e.g. lucene/saxon it will say nothing and
just not work. That's a miserable user experience, and people will in
their thousands get into that situation and not be able to get out it.

> and b,d they are not included in the livecd they are in a separated
> package, anyway who needs ooo-base in a livecd, fedora livecd don't
> ship any replacement ooo-base.

Sure, and dropping oobase from a LiveCD is reasonable, so the hsqldb
requires in F-10 is now just on oobase, rather than core. My point there
was that go.ooo is no different from vanilla in needing java to work
correctly, and moving to go.ooo gains you very little in terms of a
java-less OOo.

Not "Require:"ing the Java requirements for help and other always
presented dialogs and menus that are shown as available is to fudge the
reality that OOo truly does require those packages for Ooo to fulfil the
contract that the UI makes with the user. 

Taking "removing java from core dependencies" as the target, then the
right approach is the boring slow-fix stuff to e.g. rewrite the help
search to not require the java lucene stuff and to tweak the xsltfilter
stuff to be a standalone expert-style feature that only appears in the
menus when the xsltfilter package is installed and place the saxon
requires on that subpackage, and so on for other java functionality. 

Or not do any of that, and investigate further as to why exactly
removing or replacing java dependencies is the target, when I last
thought seriously about the area I felt the right thing to do was stop
swimming against the tide and boil out some concrete standalone feature
requires for gcj to be able to provide the functionality that was
missing at that stage to implement the java-needs of OOo, and our
fabulous java hackers simply implemented them. Your questions should be
what exactly are the size figures are for requiring the java
dependencies and where is that space getting used and why.

> I'm not asking to make the striped openoffice the default, I'm asking
> to make the default behaviour in comps to be full featured, but
> packages dependency should allow removal of java

I think this is the wrong approach. OOo will just end up getting
installed part-working an awful lot of the time and the OOo maintainer
of the day will have to deal with the resulting justified bile and
hatred.

I'm no lover of java, and I've previously expended effort of making OOo
buildable without java for platforms that don't have a working java and
on replacing java functionality with native code in some time critial
build-paths, so I'm all in favour of what you want to achieve, but I
don't want to compromise to make it happen.

C.




From dpquigl at tycho.nsa.gov  Tue Oct 14 22:36:11 2008
From: dpquigl at tycho.nsa.gov (David P. Quigley)
Date: Tue, 14 Oct 2008 18:36:11 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014093239.GA27002@mokona.greysector.net>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014093239.GA27002@mokona.greysector.net>
Message-ID: <1224023771.18940.15.camel@moss-terrapins.epoch.ncsc.mil>

On Tue, 2008-10-14 at 11:32 +0200, Dominik 'Rathann' Mierzejewski wrote:
> SELinux is another subject for a good rant. Example: I created /var/log/dovecot,
> chowned it to dovecot user and configured it to put its logs there. Bang!
> SELinux denial. There's no easy way to fix it permanently either and SELinux
> tools documentation is akin to arcane knowledge. Unless you're familiar with
> all the terminology, you won't understand it.
> 
[snip]

Permanent fix which survives relabels.

/usr/sbin/semanage fcontext -a -t dovecot_var_log_t /var/log/dovecot
/sbin/restorecon -v /var/log/dovecot

SELinux documentation has been lacking in the past but Red Hat has hired
someone to write proper documentation for SELinux and it is getting
better every day. In an article on LWN I answered this question[1]. In
addition to this someone also linked the page below which contains quite
a bit of information that this person gathered when learning about
SELinux[2]. If you are willing to take the time to go through some of
his stuff you will realize SELinux really isn't as difficult as people
make it out to be, it's just that its not what they are use to. You
already know to set one set of permissions on the file when you create
it you just have to realize there is a type that needs to be set as
well.

[1]http://lwn.net/Articles/290168/
[2]http://equivocation.org/selinux




From lesmikesell at gmail.com  Tue Oct 14 23:06:10 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 14 Oct 2008 18:06:10 -0500
Subject: GPL Licensing
In-Reply-To: <20081014224420.GB22182@shell.devel.redhat.com>
References: <46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>	<48F49676.7060008@gmail.com>	<935ead450810140558i430a6bfem152b6c91ef3ea45e@mail.gmail.com>	<48F49C06.5070405@gmail.com>	<1224000234.1710.6.camel@localhost.localdomain>	<48F4D771.9080509@gmail.com>
	<48F4E1C9.3060705@fedoraproject.org>	<48F4ED19.5040203@gmail.com>	<20081014204943.GD10101@shell.devel.redhat.com>	<48F50BB0.5030806@gmail.com>
	<20081014224420.GB22182@shell.devel.redhat.com>
Message-ID: <48F525E2.8020607@gmail.com>

Alan Cox wrote:
> On Tue, Oct 14, 2008 at 04:14:24PM -0500, Les Mikesell wrote:
>>> not to distribute anything to you. I'm entitled to exclude aol.com from my
>>> download site.
>>>
>>> So its an additional service with conditions.
>> Yes, conditions that are an additional restriction of what I can do with 
>> a GPL-covered work.
> 
> Its an additional service.

And taking it away or making it conditional based on giving up your GPL 
right is a restriction.

> It doesn't change your GPL rights. If you can't grasp
> that basic concept then I think you have a problem.

No, I can't grasp the concept that a restriction that involves a penalty 
is not a restriction.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From smooge at gmail.com  Tue Oct 14 23:15:34 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 14 Oct 2008 17:15:34 -0600
Subject: GPL Licensing
In-Reply-To: <48F525E2.8020607@gmail.com>
References: <46a038f90810132343q4da445dex79b80e9d37e2aa95@mail.gmail.com>
	<48F49C06.5070405@gmail.com>
	<1224000234.1710.6.camel@localhost.localdomain>
	<48F4D771.9080509@gmail.com> <48F4E1C9.3060705@fedoraproject.org>
	<48F4ED19.5040203@gmail.com>
	<20081014204943.GD10101@shell.devel.redhat.com>
	<48F50BB0.5030806@gmail.com>
	<20081014224420.GB22182@shell.devel.redhat.com>
	<48F525E2.8020607@gmail.com>
Message-ID: <80d7e4090810141615l575a0348q8715f95d9d986e5b@mail.gmail.com>

On Tue, Oct 14, 2008 at 5:06 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Alan Cox wrote:
>>
>> On Tue, Oct 14, 2008 at 04:14:24PM -0500, Les Mikesell wrote:
>>>>
>>>> not to distribute anything to you. I'm entitled to exclude aol.com from
>>>> my
>>>> download site.
>>>>
>>>> So its an additional service with conditions.
>>>
>>> Yes, conditions that are an additional restriction of what I can do with
>>> a GPL-covered work.
>>
>> Its an additional service.
>
> And taking it away or making it conditional based on giving up your GPL
> right is a restriction.
>
>> It doesn't change your GPL rights. If you can't grasp
>> that basic concept then I think you have a problem.
>
> No, I can't grasp the concept that a restriction that involves a penalty is
> not a restriction.
>

And as long you keep insisting that your definition of how the law is
versus how the legal system sees it.. I don't see this changing. You
might as well say the GPL isn't valid because it doesn't use ALL
CAPITAL LETTERS IN ALL PARTS or some other nutter idea.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From benny+usenet at amorsen.dk  Wed Oct 15 00:15:28 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 15 Oct 2008 02:15:28 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl> (Horst H. von
	Brand's message of "Tue\, 14 Oct 2008 13\:04\:40 -0300")
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<m3tzbglc9h.fsf@ursa.amorsen.dk>
	<200810141604.m9EG4eCd024339@laptop14.inf.utfsm.cl>
Message-ID: <m3d4i2r9wf.fsf@ursa.amorsen.dk>

"Horst H. von Brand" <vonbrand at inf.utfsm.cl> writes:

> Currently you have *6 months* to move over to the next Fedora...

Sure, and in the vast majority of cases I make it on time. It's just
for a few not so important services.

>> It wouldn't be good for anything too serious,

> I.e., completely useless.

Useless for you, not for me.

>>                                               but if noone steps up
>> for a necessary security patch, I could do it myself
>
> Sorry, I very much doubt that.

You doubt that I could? I'd generally just rebuild the SRPM from a
newer release or from CentOS. It's not particularly hard, even for me.

>> and then get to share the result with everyone else on that
>> obsolete release. I would have to test all updates locally, but for
>> services on the way out that is generally easier than testing the
>> full upgrade.

> It is even easier to migrate to CentOS and keep going with that one... the
> difference is that the bumps in the road are much bigger, but you have a
> couple of years to migrate your stuff.

It is in fact quite difficult to migrate to CentOS, unless your timing
is very lucky. CentOS and RHEL live in the past most of the time. If
you need a newer kernel feature, you end up running RHEL+custom
kernel, and even running your very own mini-distro is better than
that.

>> If it breaks something for someone, well, they should be more careful
>> which updates they apply, especially once official support is gone. It
>> might even encourage an upgrade and perhaps keep one box from being
>> compromised.
>
> How is that less work in the longer run than just keep upgrading or moving
> to some LTS distribution?

In the longer run the server gets shut down. If the service is to be
kept alive for more than perhaps a year, upgrading or moving to some
LTS distribution are indeed the only options.


/Benny



From benny+usenet at amorsen.dk  Wed Oct 15 00:25:55 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 15 Oct 2008 02:25:55 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081013204919.GA28298@nostromo.devel.redhat.com> (Bill
	Nottingham's message of "Mon\, 13 Oct 2008 16\:49\:19 -0400")
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
Message-ID: <m38wsqr9f0.fsf@ursa.amorsen.dk>

Bill Nottingham <notting at redhat.com> writes:

> Fedora 8's been out less a year. It has, in that timeframe, received *over
> 4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
>
> How is upgrading to the next release really that many orders of magnitude
> more change than this?

The largest difference is that upgrading to the next release is almost
an all-or-nothing thing. Incremental upgrades during the release
generally affect just one package at a time, so testing is relatively
easy. When you upgrade the whole distribution you change openssl
version, and that basically means upgrading everything that could in
any way cause trouble, all at once. It is far from impossible, I do it
all the time, but it does need a lot more care.

Once OpenSSL gets banished this pain will subside a bit, but it will
probably never go away. Back in the "good" old days it was libc
causing that problem, but the developers of glibc have done an
excellent job of keeping compatibility for many years now.


/Benny



From benny+usenet at amorsen.dk  Wed Oct 15 00:31:55 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 15 Oct 2008 02:31:55 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>
	(Jeffrey Ollie's message of "Mon\, 13 Oct 2008 23\:37\:03 -0500")
References: <loom.20081012T230422-741@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<7dd7ab490810131417o730656f0rfabd5a3854dec428@mail.gmail.com>
	<20081014004747.GA3258@vader.jdub.homelinux.org>
	<7dd7ab490810131939u174eaa67l87a3071f96500a69@mail.gmail.com>
	<935ead450810132137y659cf96dv4b99b8c3fcf22946@mail.gmail.com>
Message-ID: <m34p3er950.fsf@ursa.amorsen.dk>

"Jeffrey Ollie" <jeff at ocjtech.us> writes:

> And from what I've seen in this latest discussion the LTS project
> goals are either ill-defined or overambitious or both.

Most of the complaints have been about the goals being
underambitious. No ambition for a specific time frame, no ambition for
a specific package set, no ambition for a response guarantee for
security problems...


/Benny



From mw_triad at users.sourceforge.net  Wed Oct 15 00:32:13 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 14 Oct 2008 19:32:13 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <20081014014106.GA1315@nostromo.devel.redhat.com>
References: <604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<20081013192104.GB27065@nostromo.devel.redhat.com>	<20081013195507.GC2738@free.fr>	<20081013200047.GC27065@nostromo.devel.redhat.com>	<20081013202231.GE2738@free.fr>	<20081013204919.GA28298@nostromo.devel.redhat.com>	<20081013220420.GJ2738@free.fr>	<20081014003650.GB30302@nostromo.devel.redhat.com>	<gd0q11$6ns$1@ger.gmane.org>
	<20081014014106.GA1315@nostromo.devel.redhat.com>
Message-ID: <gd3dmd$t9f$1@ger.gmane.org>

Bill Nottingham wrote:
> Matthew Woehlke (mw_triad at users.sourceforge.net) said: 
>> Bill Nottingham wrote:
>>> To put it a different way - would you buy a car whose extended warranty
>>> won't tell you what it covers, or for how long, and tells you it's subject
>>> to change *AT ANY TIME*? If so, I think I've got some cars to sell you.
>> Have you ever bought a used car?
>>
>> People drive cars not under warranty because they know that, if  
>> something goes wrong, they can either fix it themselves (for those who  
>> are hobby mechanics) or pay someone to fix it. The same goes for a  
>> distro; if you need an update and there is no support, you can always  
>> build it yourself or pay someone to build it for you (which is, after  
>> all, sort of the point of Free Software).
> 
> Right, that's what we have now. What he's suggesting is some sort
> of 'other' warranty that can expire at any time, and which packages/
> parts of the car are covered can change at any time. I know of *no one*
> who gets that sort of warranty.

Well, if it were free, I might... well, I can't say I'd buy it, because 
I'm not buying anything :-). I'll let all y'all argue amongst yourselves 
if that's better or worse than nothing.

However... your original analogy didn't ask if I'd buy a /warranty/, it 
asked if I'd buy a /car/.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Oh, the double-entendre!



From a.badger at gmail.com  Wed Oct 15 01:16:53 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 14 Oct 2008 18:16:53 -0700
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <20081014202906.GB2688@free.fr>
References: <1224006301.23471.2.camel@truman> <20081014202906.GB2688@free.fr>
Message-ID: <48F54485.9090706@gmail.com>

Patrice Dumas wrote:
> On Tue, Oct 14, 2008 at 01:45:01PM -0400, Brian Pepple wrote:
>> Hi,
>>
>> 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.
> 
> I have drafted something for the possibility to keep infrastructure
> runnin after EOL based on the discussions:
> 
> https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL
> 
> The discussion is still somehow on-going and there was no feedback on
> this draft, but I think that there was already many things said in the
> discussion and I hope to have faithfully transmitted the idea of the
> people in favor of the proposal. I didn't put what people opposing to
> the proposal object in the wiki, they can do it if they want to.

I'm not on FESCo but I added some notes to the discussion page.  I tried
to steer clear of the portion of the decision that is up to FESCo and
stick with technical details.

-Toshio

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

From rc040203 at freenet.de  Wed Oct 15 02:09:31 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 15 Oct 2008 04:09:31 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081014143153.29c0fb64@ohm.scrye.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<1223900281.6770.573.camel@macbook.infradead.org>
	<48F3459B.8080704@leemhuis.info>
	<1223903369.3029.58.camel@beck.corsepiu.local>
	<48F34C21.3000404@leemhuis.info>
	<1223905136.3029.81.camel@beck.corsepiu.local>
	<935ead450810130703x26205940naa0f056e0ff4e4c5@mail.gmail.com>
	<48F35E2E.8010507@gmail.com>
	<935ead450810130816q521271c9q49bfa9e83825ee61@mail.gmail.com>
	<1223955785.3029.224.camel@beck.corsepiu.local>
	<20081014143153.29c0fb64@ohm.scrye.com>
Message-ID: <1224036571.3029.449.camel@beck.corsepiu.local>

On Tue, 2008-10-14 at 14:31 -0600, Kevin Fenzi wrote:
> On Tue, 14 Oct 2008 05:43:05 +0200
> rc040203 at freenet.de (Ralf Corsepius) wrote:
> 
> > On Mon, 2008-10-13 at 10:16 -0500, Jeffrey Ollie wrote:
> ...snip...
> > > 
> > > Unfortunately, upstream developers don't always release bugfix-only
> > > releases.  Many times they introduce new features or change the
> > > behavior of old features.
> > Right, and how do you expect EPEL to handle this issue?
> > 
> > I would expect EPEL to starve out contributors during RHEL's long time
> > time and those who will try to continue supporting it, will be facing
> > the problems you described.
> > 
> > May-be I missed it, but I would like to hear about EPEL's visions on
> > this matter.
> 
> Sorry for the late reply. 
> 
> In many ways EPEL has it easy. Since they don't maintain the kernel,
> glibc, and all the other packages that RHEL maintains. 
> 
> But you are right, for the packages they do maintain it will get harder
> over time to backport security fixes or avoid updating versions.
> 
> I think the fact that EPEL doesn't have to handle those more
> vulnerable core packages, and only has to worry about the leaf node
> packages is one thing that makes it more viable. 
OK.

> Also, note that since many of the packages in EPEL are leaf nodes /
> add on packages they don't tend to have deep dependencies that more
> central packages have.

OK, so you're basically ignoring this issue and hope for the best?

Certainly, the likelihood of such an incident to happen in "non-core
packages" is less than in "core packages" and the severity of such
incidents in "leaf-packages" is likely less than that in core packages,
nevertheless they are possible to happen over the long time span EPEL is
supposed to be around, nevertheless are non-core packages which can have
long and deep dependency chains.

I only need to have a look into the packages I maintain in fedora ;)

Ralf





From braden at endoframe.com  Wed Oct 15 05:05:26 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Wed, 15 Oct 2008 01:05:26 -0400
Subject: Suggested packaging guideline: avoid running autoreconf
In-Reply-To: <1223903803.7707.25.camel@atropine.boston.devel.redhat.com>
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<1223903803.7707.25.camel@atropine.boston.devel.redhat.com>
Message-ID: <1224047126.8635.115.camel@hinge.endoframe.net>

On Mon, 2008-10-13 at 09:16 -0400, Adam Jackson wrote:
> On Sat, 2008-10-11 at 14:07 -0400, Braden McDaniel wrote:
> > When the estimate of "300 broken packages" was tossed out in the libtool
> > 2.2.x thread, I figured there was no way *that* many packages could be
> > running autoreconf or libtoolize.  But I have been surprised to find no
> > advice against this practice in Fedora's packaging guidelines; and in
> > light of that, the number is not quite so incredible.
> > 
> > While forbidding the use of autoreconf (or similar: autoconf, automake,
> > libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> > appropriate for the packaging guidelines to point out the pitfalls of
> > this practice and advise packagers to avoid it where possible.
> > 
> > So what are those pitfalls? By running autoreconf, the RPM build becomes
> > exposed to different versions of autoconf, automake, and libtool than
> > were used by the upstream developer to create the upstream source
> > package.  Newer versions of these tools have the potential to introduce
> > incompatibilities, breaking the RPM build.  Rather than patching
> > configure.[ac,in] and Makefile.am, a more resilient approach is to patch
> > the configure script and Makefile.in files.
> 
> No thanks.  Patching Makefile.am at least stands a chance of applying
> correctly across multiple releases of the package.

Patching Makefile.in stands a reasonable chance of that, too.  Exactly
what the odds are depends greatly on the nature of the change; and it is
certainly the case that for a class of changes, the patch to Makefile.am
is more likely to apply cleanly.  Your implication that a patch to
Makefile.in stands no chance of applying cleanly to future releases is
simply hyperbole.

>   Worse, patching the
> generated files stands a good chance of missing an instance of whatever
> you were patching for when the next release comes out.

I think the claim of such a "good chance" is, once again, hyperbole.
Sure, there's *some* chance.  And there's *some* chance of that
regardless of what you file patch.  Again, just what sort of increase to
the likelihood of failure we're talking about depends greatly on the
nature of the change.

> Packages change version much more often than libtool changes version.
> I'd rather go with the method that's resilient against the more common
> change.

If you ran autoreconf, you also need to worry about upgrades to autoconf
and automake in addition to libtool.  Still, there are certainly
packages that have more frequent releases than all three of those put
together.  So from the point of view of an individual maintainer, I see
where you're coming from.  But I have a problem with the practice of
regenerating these files when the broad application of this practice
winds up presenting a serious impediment to upgrading one of these build
tools in Fedora.  That didn't have to happen.

But if all you did was run "automake", I'm pretty sure upgrading libtool
won't break your package.  In fact, I'm not even sure that running
"autoreconf" (without arguments) is sufficient to incur breakage.  What
is nearly guaranteed to cause breakage is running "autoreconf -f".  And
not only is it likely to cause breakage, it's going to be completely
unnecessary in all but *very* unusual cases.

I can accept that my objectives for resiliency may not be shared by all
packagers.  I think it's possible to craft a guideline that steers
packagers toward less deleterious invocations of the autotools (when
they feel the need to do so at all).  But before trying to make any
further progress on this, I want to have a look at the packages that a
libtool2 upgrade stands to break.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From oliver at linux-kernel.at  Wed Oct 15 07:03:07 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 09:03:07 +0200
Subject: compat-python, Zope...
In-Reply-To: <20081014113721.GA18347@yoda.jdub.homelinux.org>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>
	<20081014113721.GA18347@yoda.jdub.homelinux.org>
Message-ID: <48F595AB.6030903@linux-kernel.at>

Josh Boyer wrote:
> On Tue, Oct 14, 2008 at 01:02:48PM +0200, Oliver Falk wrote:
>> Thorsten Leemhuis wrote:
>>> On 14.10.2008 11:14, Oliver Falk wrote:
>>>> Is there a reason, that there is no compat-python package available?
>>> The short version: The python maintainer didn't want to have one in  
>>> Fedora and FESCo backed that decision. You will find a lot more about  
>>> this topic in the archives of this list; for example in this 
>>> discussion:
>>> http://www.redhat.com/archives/fedora-devel-list/2007-May/msg00226.html
>>>
>>> I doubt the situation changed in between, thus my suggestion would be 
>>> to put your packages up for review in bugzilla.rpmfusion.org.
>>>
>>> If I'm wrong and if the situation has changed then we should try to 
>>> move the compat-python* packages from RPM Fusion to Fedora.
>> OK. I think I've read the whole old thread now :-)
>>
>> First of all: I *will* package compat-python and Zope/Plone, because I  
>> need it at work. The only question is if Fedora/FESCo wants me to share  
>> my work with the Fedora community or not!
>>
>> I can think of a Python 2.4 package that lives within the Zope tree to  
>> make it extra hard for others to use it by accident - but I don't think  
>> that this would be neat, seen from a FHS point of view.
>>
>> I'm not a big fan of third party repositories. DOT. This would lead to  
>> an extra discussion...
>>
>> a) I maintain Zope/Plone (+ deps, eg. compat-python) in Fedora
>> b) I maintain it on my *private* company repo
>> c) NOTE!: I guess this will lead to packages a la  
>> compat-python24-{elementtree,feedparser,imaging,lxml,setuptools,psycopg}  
>> and maybe a whole bunch of others...
>>
>> So. FESCo? Do you want me to share my work with the community or not. DOT.
> 
> While we try very hard to follow all threads on the mailing list, if you
> really want to ask FESCo a specific question please either open a Trac
> ticket or email the FESCo members directly.

Noted. :-) Thx.

-of



From oliver at linux-kernel.at  Wed Oct 15 07:08:34 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 09:08:34 +0200
Subject: compat-python, Zope...
In-Reply-To: <1223988009.16958.51.camel@code.and.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<1223988009.16958.51.camel@code.and.org>
Message-ID: <48F596F2.6000902@linux-kernel.at>

James Antill wrote:
[ ... ]
>> I can think of a Python 2.4 package that lives within the Zope tree to 
>> make it extra hard for others to use it by accident - but I don't think 
>> that this would be neat, seen from a FHS point of view.
> 
>  In some ways this might be doable, at least it has less pain points
> than packaging it "properly".

I'm not sure what you mean here? Do you mean with properly an 
/usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to 
invite everybody to have a look at the livna packages. Those are fine 
and don't hurt the main python...

>> I'm not a big fan of third party repositories. DOT. This would lead to 
>> an extra discussion...
>>
>> a) I maintain Zope/Plone (+ deps, eg. compat-python) in Fedora
>> b) I maintain it on my *private* company repo
>> c) NOTE!: I guess this will lead to packages a la 
>> compat-python24-{elementtree,feedparser,imaging,lxml,setuptools,psycopg} 
>> and maybe a whole bunch of others...
> 
>  C is the biggest problem, in that "someone" has to dup all the modules
> people need ... which also need to be kept in sync. ...

Of course. I can think of providing the package people need - upon 
request. But of course other python module packagers are invited to join 
my effort :-)

 > and you need to
> make sure that python-foo doesn't pull in compat-python24-bar (and vice
> versa).

Hm. How should that happen? Especially with koji....

-of



From oliver at linux-kernel.at  Wed Oct 15 07:12:54 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 09:12:54 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F4A35A.7060300@gmail.com>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<1223988009.16958.51.camel@code.and.org>
	<48F4A35A.7060300@gmail.com>
Message-ID: <48F597F6.6030200@linux-kernel.at>

Toshio Kuratomi wrote:
> James Antill wrote:
>> On Tue, 2008-10-14 at 13:02 +0200, Oliver Falk wrote:
>>
>>> First of all: I *will* package compat-python and Zope/Plone, because I 
>>> need it at work. The only question is if Fedora/FESCo wants me to share 
>>> my work with the Fedora community or not!
>>  From what I remember the previous person who wanted python in Fedora
>> was also willing to create/maintain a compat-python24 package. But
>> that's not the only problem.
>>
>>> I can think of a Python 2.4 package that lives within the Zope tree to 
>>> make it extra hard for others to use it by accident - but I don't think 
>>> that this would be neat, seen from a FHS point of view.
>>  In some ways this might be doable, at least it has less pain points
>> than packaging it "properly".
>>
>>> I'm not a big fan of third party repositories. DOT. This would lead to 
>>> an extra discussion...
>>>
>>> a) I maintain Zope/Plone (+ deps, eg. compat-python) in Fedora
>>> b) I maintain it on my *private* company repo
>>> c) NOTE!: I guess this will lead to packages a la 
>>> compat-python24-{elementtree,feedparser,imaging,lxml,setuptools,psycopg} 
>>> and maybe a whole bunch of others...
>>  C is the biggest problem, in that "someone" has to dup all the modules
>> people need ... which also need to be kept in sync. ... and you need to
>> make sure that python-foo doesn't pull in compat-python24-bar (and vice
>> versa).
>>
>>
> If C really is the biggest issue, we could look at what Debian is doing
> in this area.  They have a package (I think it's called python-central
> although that might be the old package and they have a newer one that
> takes its place) which aids them in putting the python source modules in
> a central store.  Then the modules are byte compiled for every python
> that is installed on the system.  I'm not certain of how it works or
> whether it is hacky in practice, just aware of its existence.

You mean, if someone installs python-foo, it gets compiled for all 
compat-python?? and python installed on the system? I don't think this a 
very good idea (sounds like this 
kernel-module-automagic-rebuild-for-new-kernel-whatever-it-was-called 
stuff. dkms or such!?).

How can we make sure the module *really* compiles if not done inside of 
koji? And you put an extra effort on all python-foo packagers, as they 
might need to maintain patches for the old pythons...

> Is there anyone here with some Debian experience who can point us to a
> better piece of information than what I just gave?

I'm - of course - interested in this 'technology', but I don't think 
it's good for Fedora.

-of



From oliver at linux-kernel.at  Wed Oct 15 07:17:25 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 09:17:25 +0200
Subject: compat-python, Zope...
In-Reply-To: <20081014092146.1696d636@ohm.scrye.com>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>
Message-ID: <48F59905.50206@linux-kernel.at>

Kevin Fenzi wrote:
> On Tue, 14 Oct 2008 13:02:48 +0200
> oliver at linux-kernel.at (Oliver Falk) wrote:
> 
>> OK. I think I've read the whole old thread now :-)
>>
>> First of all: I *will* package compat-python and Zope/Plone, because
>> I need it at work. The only question is if Fedora/FESCo wants me to
>> share my work with the Fedora community or not!
> 
> FYI, note that compat-python24 and compat-zope are already in livna
> (and I assume then also rpmfusion). 
> 
> Perhaps you could offer to help maintain those with their maintainer
> there? Even less work, since they are already packaged/used. 

I've taken these packages as a starting point. I will need additional 
python modules and I do also need compat-python23 and why not take these 
packages into Fedora. Why is everyone wicked about maintaining packages 
in a third party repository? I know rpmfusion and most packages seem to 
be quite good. What's the reason for not taking them into Fedora - 
except those packages with non-floss licenses?

-of



From oliver at linux-kernel.at  Wed Oct 15 07:27:31 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 09:27:31 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224001257.13861.56.camel@ignacio.lan>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>
	<1224001257.13861.56.camel@ignacio.lan>
Message-ID: <48F59B63.3050402@linux-kernel.at>

Ignacio Vazquez-Abrams wrote:
> On Tue, 2008-10-14 at 09:21 -0600, Kevin Fenzi wrote:
>> FYI, note that compat-python24 and compat-zope are already in livna
>> (and I assume then also rpmfusion). 
>>
>> Perhaps you could offer to help maintain those with their maintainer
>> there? Even less work, since they are already packaged/used. 
> 
> The maintainer, Jonathan Steffan (who is currently having email issues),
> told me that he would appreciate having comaintainers. The livna
> infrastructure doesn't support them, but the RPMFusion infrastructure
> does.

Thx a lot for this information. But let us first try to bring this 
discussion to an end.

Still, the major questions: Do we really want:

a) Zope/Plone developers not to use Fedora? But instead choose eg. 
Debian, because apt-get install does the trick for them.

b) Admins who then have to maintain Zope/Plone in an production 
environment over its life cycle not choose Fedora? Because apt-get 
install on a Debian system does the trick for them.

c) Very experienced Admins *maybe* choose Fedora (because they *really* 
love it) and use livna/rpmfusion packages, but in the end have the 
problem about the lack of support and the lack of additional python 
modules for Zope/Plone.

d-z) A whole bunch of people who are pissed of, because of a lot of 
other reasons, that don't come to my mind immediately. But I'm quite 
sure there are more... :-)

-of



From dwmw2 at infradead.org  Wed Oct 15 07:31:12 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 15 Oct 2008 08:31:12 +0100
Subject: reviving Fedora Legacy
In-Reply-To: <20081013021420.GB29893@angus.ind.WPI.EDU>
References: <20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu> <20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
Message-ID: <1224055872.6770.950.camel@macbook.infradead.org>

On Sun, 2008-10-12 at 22:14 -0400, Chuck Anderson wrote:
> On Sun, Oct 12, 2008 at 06:22:16PM -0700, Bob Arendt wrote:
> > I really don't see how a Fedora Legacy can be maintained.  If the 
> > goal is increased stability and security patches, you need to 
> > guarantee that you have folks supporting backpatches to the kernel, 
> > glibc, firefox, evolution, openoffice, and several other large and 
> > complex packages.  Incorporating new security patches into old 
> > baselines is *hard*. Plus Fedora would "fork" a new release every 6 
> > months.  How many legacy Fedora's would be retained?  At some point 
> > it seems the legacy volunteer force would saturate and legacy 
> > Fedora's would have to start dropping off every 6 months.
> 
> Why do we need to guarantee any more than active Fedora releases 
> guarantee?  Forget backporting.  Just upgrade the package.  Take it 
> from the current Fedora and rebuild it if necessary.

Once you start upgrading packages all over the place to a much newer
version than was in the original release, you might as well just
upgrade.

Seriously, I don't know why people are so scared of just _upgrading_, if
new packages are acceptable.

I upgrade remote, headless machines with yum, and reboot them into the
new distribution. Quite frequently. And I laugh at the people who say it
doesn't work. It's a fairly fundamental part of my server management
technique -- yes, I run Fedora on my servers.

Perhaps a better approach to this whole thing would be to educate people
a little better that upgrades _do_ work, and they're generally fairly
seamless. And to fix the occasional cases where they're not.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From dwmw2 at infradead.org  Wed Oct 15 07:36:05 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 15 Oct 2008 08:36:05 +0100
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T013947-433@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr> <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
Message-ID: <1224056165.6770.955.camel@macbook.infradead.org>

On Mon, 2008-10-13 at 01:40 +0000, Kevin Kofler wrote:
> Why would we want to? Just let things going as long as there is at least one 
> maintainer committing something. Even if not all security issues get fixed, 
> it's better than if none gets fixed.

I disagree with that very strongly.

If we present the _appearance_ of a distro with security updates, while
in fact there are serious security issues being unfixed, then that is
_much_ worse than the current "That distro is EOL. Upgrade before you
get hacked" messaging.

For anything to have the Fedora name on it, it _must_ have guaranteed
security fixes for at least the highest priority issues.

(That's not a decree; I'm not in a position to make such. It's just
common sense.)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pertusus at free.fr  Wed Oct 15 07:36:09 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 09:36:09 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F59905.50206@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>
	<48F59905.50206@linux-kernel.at>
Message-ID: <20081015073609.GA2795@free.fr>

On Wed, Oct 15, 2008 at 09:17:25AM +0200, Oliver Falk wrote:
>
> I've taken these packages as a starting point. I will need additional  
> python modules and I do also need compat-python23 and why not take these  
> packages into Fedora. Why is everyone wicked about maintaining packages  
> in a third party repository? I know rpmfusion and most packages seem to  
> be quite good. What's the reason for not taking them into Fedora -  
> except those packages with non-floss licenses?

This should be the only reason. I think that preventing packagers to do
compat package is wrong. But in general FESCO give reason to the main
packager (and if I remembmer well it was also the case of a parallel 
installable newer version). 

In my opinion, instead, packagers should be co-maintaining the main
version when they do a compat package, and that's all.

--
Pat



From pertusus at free.fr  Wed Oct 15 07:42:28 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 09:42:28 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1224056165.6770.955.camel@macbook.infradead.org>
References: <20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
Message-ID: <20081015074228.GB2795@free.fr>

On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
> 
> If we present the _appearance_ of a distro with security updates, while
> in fact there are serious security issues being unfixed, then that is
> _much_ worse than the current "That distro is EOL. Upgrade before you
> get hacked" messaging.

The aim here is not to present the _appearance_ of a distro with
security updates but give the choice to the user either to upgrade or to
stick with a distro where some packages will not be maintained.
Something along "That distro is EOL. Upgrade before you get hacked.
Alternatively, and at your own risk, you can enable a repository where 
some packages are updated on a volunteer basis, but some packages aren't
maintained anymore."

With a page listing which packages are still supported.

--
Pat



From pertusus at free.fr  Wed Oct 15 07:52:02 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 09:52:02 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1224055872.6770.950.camel@macbook.infradead.org>
References: <20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
	<1224055872.6770.950.camel@macbook.infradead.org>
Message-ID: <20081015075202.GC2795@free.fr>

On Wed, Oct 15, 2008 at 08:31:12AM +0100, David Woodhouse wrote:
> 
> Once you start upgrading packages all over the place to a much newer
> version than was in the original release, you might as well just
> upgrade.
> 
> Seriously, I don't know why people are so scared of just _upgrading_, if
> new packages are acceptable.

One example in my mind is the change from pam_console to consolekit.
Sure this is an improvement. But xdm and wdm didn't worked after that.
This is typically a big change that happens between releases that a user
may want to avoid. The thing that don't work in later versions may even
get fixed over time. There are a lot of similar regressions between
fedora releases. Other examples are programs that worked with KDE 3 and
don't work with KDE 4.

> I upgrade remote, headless machines with yum, and reboot them into the
> new distribution. Quite frequently. And I laugh at the people who say it
> doesn't work. It's a fairly fundamental part of my server management
> technique -- yes, I run Fedora on my servers.
> 
> Perhaps a better approach to this whole thing would be to educate people
> a little better that upgrades _do_ work, and they're generally fairly
> seamless. And to fix the occasional cases where they're not.

Sometime it is easily fixable, sometime it is complicated, it depends a
lot whether upstream takes care about compatibility or not (as is the
case, for example in the dbus/hal/*Kit case). And in any case it takes 
some time. Also in general the maintainers in fedora are 
looking forward and don't care about breaking compatibility, and if they 
cared this would slow down innovation.

--
Pat



From fedora at leemhuis.info  Wed Oct 15 07:53:22 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 09:53:22 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F59905.50206@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>
	<48F59905.50206@linux-kernel.at>
Message-ID: <48F5A172.9000405@leemhuis.info>

On 15.10.2008 09:17, Oliver Falk wrote:
> Kevin Fenzi wrote:
>> On Tue, 14 Oct 2008 13:02:48 +0200
>> oliver at linux-kernel.at (Oliver Falk) wrote:
>>
>>> OK. I think I've read the whole old thread now :-)
>>> First of all: I *will* package compat-python and Zope/Plone, because
>>> I need it at work. The only question is if Fedora/FESCo wants me to
>>> share my work with the Fedora community or not!
>> FYI, note that compat-python24 and compat-zope are already in livna
>> (and I assume then also rpmfusion). 
>> Perhaps you could offer to help maintain those with their maintainer
>> there? Even less work, since they are already packaged/used. 
> I've taken these packages as a starting point. I will need additional 
> python modules and I do also need compat-python23 and why not take these 
> packages into Fedora. Why is everyone wicked about maintaining packages 
> in a third party repository? I know rpmfusion and most packages seem to 
> be quite good. What's the reason for not taking them into Fedora - 
> except those packages with non-floss licenses?

Just a note for those not familiar with the habits from Livna/RPM 
Fusion: Livna/RPM Fusion normally doesn't take any packages that are 
suitable for Fedora (?).

Back then we tried our best to get compat-python directly into Fedora, 
but those efforts failed. Hence Livna accepted compat-python (and hence 
it made its way to RPM Fusion). But I'm all for moving compat-python* to 
Fedora, so I really appreciate your efforts Oliver!

CU
knurd


(?) yes, now and then a package accidentally slipped through (or 
suddenly becomes suitable for Fedora); but all of them afaik have been 
moved to Fedora or are in the process of moving (the last one I know cam 
from Dribble as is under review for Fedora now)



From oliver at linux-kernel.at  Wed Oct 15 08:01:16 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 10:01:16 +0200
Subject: compat-python, Zope...
In-Reply-To: <20081015073609.GA2795@free.fr>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<20081015073609.GA2795@free.fr>
Message-ID: <48F5A34C.3090701@linux-kernel.at>

Patrice Dumas wrote:
> On Wed, Oct 15, 2008 at 09:17:25AM +0200, Oliver Falk wrote:
>> I've taken these packages as a starting point. I will need additional  
>> python modules and I do also need compat-python23 and why not take these  
>> packages into Fedora. Why is everyone wicked about maintaining packages  
>> in a third party repository? I know rpmfusion and most packages seem to  
>> be quite good. What's the reason for not taking them into Fedora -  
>> except those packages with non-floss licenses?
> 
> This should be the only reason. I think that preventing packagers to do
> compat package is wrong.

At least one person who's on my side :-)

 > But in general FESCO give reason to the main
> packager (and if I remembmer well it was also the case of a parallel 
> installable newer version). 
 >
> In my opinion, instead, packagers should be co-maintaining the main
> version when they do a compat package, and that's all.

It's python, it's the holy (Fedora/Red Hat) grail. I think only people 
on the Red Hat payroll are allowed to commit to python CVS, isn't it? 
:-P Sorry, no offense!

I think the main version packagers should allowed to have commit access 
to the compat packages instead. In case compat packager breaks main 
version, the main version packager can fix it...

-of



From denis at poolshark.org  Wed Oct 15 08:12:42 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 15 Oct 2008 10:12:42 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F5A172.9000405@leemhuis.info>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info>
Message-ID: <48F5A5FA.90604@poolshark.org>

Thorsten Leemhuis wrote:
> Just a note for those not familiar with the habits from Livna/RPM 
> Fusion: Livna/RPM Fusion normally doesn't take any packages that are 
> suitable for Fedora (??).

Can you define "suitable" :-) ? there are some packages that are 
suitable in theory, but won't get in without a fight through FeSCo.



From pertusus at free.fr  Wed Oct 15 08:16:39 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 10:16:39 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F5A5FA.90604@poolshark.org>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>
	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info> <48F5A5FA.90604@poolshark.org>
Message-ID: <20081015081639.GF2795@free.fr>

On Wed, Oct 15, 2008 at 10:12:42AM +0200, Denis Leroy wrote:
> Thorsten Leemhuis wrote:
>> Just a note for those not familiar with the habits from Livna/RPM  
>> Fusion: Livna/RPM Fusion normally doesn't take any packages that are  
>> suitable for Fedora (??).
>
> Can you define "suitable" :-) ? there are some packages that are  
> suitable in theory, but won't get in without a fight through FeSCo.

Which free software package without patent issue wouldn't be suitable?
Maybe an additional kernel (like the bsd kernel or the HURD, would be
nice, any taker?), but otherwise?

--
Pat 



From denis at poolshark.org  Wed Oct 15 08:21:47 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 15 Oct 2008 10:21:47 +0200
Subject: compat-python, Zope...
In-Reply-To: <20081015081639.GF2795@free.fr>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>	<48F5A172.9000405@leemhuis.info>
	<48F5A5FA.90604@poolshark.org> <20081015081639.GF2795@free.fr>
Message-ID: <48F5A81B.90505@poolshark.org>

Patrice Dumas wrote:
> On Wed, Oct 15, 2008 at 10:12:42AM +0200, Denis Leroy wrote:
>> Thorsten Leemhuis wrote:
>>> Just a note for those not familiar with the habits from Livna/RPM  
>>> Fusion: Livna/RPM Fusion normally doesn't take any packages that are  
>>> suitable for Fedora (??).
>> Can you define "suitable" :-) ? there are some packages that are  
>> suitable in theory, but won't get in without a fight through FeSCo.
> 
> Which free software package without patent issue wouldn't be suitable?
> Maybe an additional kernel (like the bsd kernel or the HURD, would be
> nice, any taker?), but otherwise?

- packages likely to be vetoed by a Red Hat employee (and therefore by 
FeSCo): compat-python, compat-gcc-32

- packages that include kernel modules, like open-vm-tools.



From oliver at linux-kernel.at  Wed Oct 15 08:28:27 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 10:28:27 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F5A172.9000405@leemhuis.info>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info>
Message-ID: <48F5A9AB.1030604@linux-kernel.at>

Thorsten Leemhuis wrote:
> On 15.10.2008 09:17, Oliver Falk wrote:
>> Kevin Fenzi wrote:
>>> On Tue, 14 Oct 2008 13:02:48 +0200
>>> oliver at linux-kernel.at (Oliver Falk) wrote:
>>>
>>>> OK. I think I've read the whole old thread now :-)
>>>> First of all: I *will* package compat-python and Zope/Plone, because
>>>> I need it at work. The only question is if Fedora/FESCo wants me to
>>>> share my work with the Fedora community or not!
>>> FYI, note that compat-python24 and compat-zope are already in livna
>>> (and I assume then also rpmfusion). Perhaps you could offer to help 
>>> maintain those with their maintainer
>>> there? Even less work, since they are already packaged/used. 
>> I've taken these packages as a starting point. I will need additional 
>> python modules and I do also need compat-python23 and why not take 
>> these packages into Fedora. Why is everyone wicked about maintaining 
>> packages in a third party repository? I know rpmfusion and most 
>> packages seem to be quite good. What's the reason for not taking them 
>> into Fedora - except those packages with non-floss licenses?
> 
> Just a note for those not familiar with the habits from Livna/RPM 
> Fusion: Livna/RPM Fusion normally doesn't take any packages that are 
> suitable for Fedora (?).

I do know and I know the footnote as well :-)

> Back then we tried our best to get compat-python directly into Fedora, 
> but those efforts failed. Hence Livna accepted compat-python (and hence 
> it made its way to RPM Fusion). But I'm all for moving compat-python* to 
> Fedora, so I really appreciate your efforts Oliver!

This is good news, that you want the same!
I really want to have them in the main repository and I'm willing to 
help to get them in and also help you to maintain them, if you like.

I've already raised a FESCo ticket, so they can discuss it in their next 
meeting.

[ ... ]

-of



From oliver at linux-kernel.at  Wed Oct 15 08:28:52 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Wed, 15 Oct 2008 10:28:52 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F5A5FA.90604@poolshark.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>	<48F5A172.9000405@leemhuis.info>
	<48F5A5FA.90604@poolshark.org>
Message-ID: <48F5A9C4.7030700@linux-kernel.at>

Denis Leroy wrote:
> Thorsten Leemhuis wrote:
>> Just a note for those not familiar with the habits from Livna/RPM 
>> Fusion: Livna/RPM Fusion normally doesn't take any packages that are 
>> suitable for Fedora (??).
> 
> Can you define "suitable" :-) ? there are some packages that are 
> suitable in theory, but won't get in without a fight through FeSCo.

What are the allowed weapons?

-of



From pertusus at free.fr  Wed Oct 15 08:35:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 10:35:11 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <48F54485.9090706@gmail.com>
References: <1224006301.23471.2.camel@truman> <20081014202906.GB2688@free.fr>
	<48F54485.9090706@gmail.com>
Message-ID: <20081015083511.GG2795@free.fr>

On Tue, Oct 14, 2008 at 06:16:53PM -0700, Toshio Kuratomi wrote:
> 
> I'm not on FESCo but I added some notes to the discussion page.  I tried
> to steer clear of the portion of the decision that is up to FESCo and
> stick with technical details.

Thanks for your comments. I incorporated 2 of them, but for the 'not
possible currently to report bug against these packages' in fact I want
to say that we do the same currently than when a release goes EOL. I
don't know exactly how to convey more clearly the idea, though.

--
Pat



From fedora at leemhuis.info  Wed Oct 15 09:05:44 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 11:05:44 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F5A5FA.90604@poolshark.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>	<48F5A172.9000405@leemhuis.info>
	<48F5A5FA.90604@poolshark.org>
Message-ID: <48F5B268.7070102@leemhuis.info>

On 15.10.2008 10:12, Denis Leroy wrote:
> Thorsten Leemhuis wrote:
>> Just a note for those not familiar with the habits from Livna/RPM 
>> Fusion: Livna/RPM Fusion normally doesn't take any packages that are 
>> suitable for Fedora (??).
> Can you define "suitable" :-) ?

Not exactly ;-)

> there are some packages that are 
> suitable in theory, but won't get in without a fight through FeSCo.

Then really try to fight. If you loose in the end then you can knock on 
RPM Fusion's door.

Cu
knurd



From fedora at leemhuis.info  Wed Oct 15 09:08:33 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 11:08:33 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F5A81B.90505@poolshark.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>	<48F5A172.9000405@leemhuis.info>	<48F5A5FA.90604@poolshark.org>
	<20081015081639.GF2795@free.fr> <48F5A81B.90505@poolshark.org>
Message-ID: <48F5B311.2040804@leemhuis.info>

On 15.10.2008 10:21, Denis Leroy wrote:

> - packages that include kernel modules, like open-vm-tools.

Which I'd really like to see in RPM Fusion soon. As you iirc known, 
there are packages floating around in some places that are based on 
older packages that were up for review in Livna. Someone should collect 
all of those packages, merge them and put the result up for review in 
RPM Fusion; if everything works fine we can have them available in RPM 
Fuson by weeks end (I'm willing to do the review is the packager 
actually tested that the packages work).

CU
knurd



From d.lesca at solinos.it  Wed Oct 15 09:13:22 2008
From: d.lesca at solinos.it (Dario Lesca)
Date: Wed, 15 Oct 2008 11:13:22 +0200
Subject: open-vm-tools for Fedora
Message-ID: <1224062002.4116.10.camel@lesca>

Why Fedora not have in our standard repo the open-vm-tools package?

http://open-vm-tools.sourceforge.net/

> linux-0chi:~ # rpm -qi open-vm-tools-2008.04.14-21.1
> Name        : open-vm-tools                Relocations: (not relocatable)
> Version     : 2008.04.14                        Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
> ....
> Group       : System/Emulators/PC           Source RPM: open-vm-tools-2008.04.14-21.1.src.rpm
> Size        : 1495998                          License: BSD 3-Clause; GPL v2 only; LGPL v2.1 only
> ....
> Summary     : Open Virtual Machine Tools
> Description :
> Open Virtual Machine Tools (open-vm-tools) are the open source
> implementation of VMware Tools.

It's a License Problem?
Or maintainer problem?

Many thanks
-- 
Dario Lesca <d.lesca at solinos.it>



From kevin.kofler at chello.at  Wed Oct 15 09:21:42 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 15 Oct 2008 09:21:42 +0000 (UTC)
Subject: Suggested packaging guideline: avoid running autoreconf
References: <1223748479.13589.313.camel@hinge.endoframe.net>
	<1223903803.7707.25.camel@atropine.boston.devel.redhat.com>
	<1224047126.8635.115.camel@hinge.endoframe.net>
Message-ID: <loom.20081015T091538-438@post.gmane.org>

Braden McDaniel <braden <at> endoframe.com> writes:
> 
> On Mon, 2008-10-13 at 09:16 -0400, Adam Jackson wrote:
> > No thanks.  Patching Makefile.am at least stands a chance of applying
> > correctly across multiple releases of the package.
> 
> Patching Makefile.in stands a reasonable chance of that, too.  Exactly

No it doesn't.

> what the odds are depends greatly on the nature of the change; and it is
> certainly the case that for a class of changes, the patch to Makefile.am
> is more likely to apply cleanly.  Your implication that a patch to
> Makefile.in stands no chance of applying cleanly to future releases is
> simply hyperbole.

No it isn't. Adam Jackson (ajax) is an experienced packager, he knows what he's 
talking about!

> >   Worse, patching the
> > generated files stands a good chance of missing an instance of whatever
> > you were patching for when the next release comes out.
> 
> I think the claim of such a "good chance" is, once again, hyperbole.
> Sure, there's *some* chance.  And there's *some* chance of that
> regardless of what you file patch.  Again, just what sort of increase to
> the likelihood of failure we're talking about depends greatly on the
> nature of the change.

Again, I'm sure Ajax is talking from experience there, not inventing things. 
How many packages have you maintained to come to your conclusion?

> where you're coming from.  But I have a problem with the practice of
> regenerating these files when the broad application of this practice
> winds up presenting a serious impediment to upgrading one of these build
> tools in Fedora.  That didn't have to happen.

The real problem is that libtool is breaking compatibility, not that packages 
are running libtool. We have exactly the same problems with e.g. GCC breaking 
source compatibility (and I also blame GCC for doing that).

        Kevin Kofler



From paul at city-fan.org  Wed Oct 15 09:24:13 2008
From: paul at city-fan.org (Paul Howarth)
Date: Wed, 15 Oct 2008 10:24:13 +0100
Subject: open-vm-tools for Fedora
In-Reply-To: <1224062002.4116.10.camel@lesca>
References: <1224062002.4116.10.camel@lesca>
Message-ID: <48F5B6BD.2020800@city-fan.org>

Dario Lesca wrote:
> Why Fedora not have in our standard repo the open-vm-tools package?
> 
> http://open-vm-tools.sourceforge.net/
> 
>> linux-0chi:~ # rpm -qi open-vm-tools-2008.04.14-21.1
>> Name        : open-vm-tools                Relocations: (not relocatable)
>> Version     : 2008.04.14                        Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
>> ....
>> Group       : System/Emulators/PC           Source RPM: open-vm-tools-2008.04.14-21.1.src.rpm
>> Size        : 1495998                          License: BSD 3-Clause; GPL v2 only; LGPL v2.1 only
>> ....
>> Summary     : Open Virtual Machine Tools
>> Description :
>> Open Virtual Machine Tools (open-vm-tools) are the open source
>> implementation of VMware Tools.
> 
> It's a License Problem?
> Or maintainer problem?

Neither, it's that out-of-tree kernel modules aren't allowed in Fedora.

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

Paul.



From berrange at redhat.com  Wed Oct 15 09:29:35 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 15 Oct 2008 10:29:35 +0100
Subject: open-vm-tools for Fedora
In-Reply-To: <1224062002.4116.10.camel@lesca>
References: <1224062002.4116.10.camel@lesca>
Message-ID: <20081015092935.GB25527@redhat.com>

On Wed, Oct 15, 2008 at 11:13:22AM +0200, Dario Lesca wrote:
> Why Fedora not have in our standard repo the open-vm-tools package?
> 
> http://open-vm-tools.sourceforge.net/
> 
> > linux-0chi:~ # rpm -qi open-vm-tools-2008.04.14-21.1
> > Name        : open-vm-tools                Relocations: (not relocatable)
> > Version     : 2008.04.14                        Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
> > ....
> > Group       : System/Emulators/PC           Source RPM: open-vm-tools-2008.04.14-21.1.src.rpm
> > Size        : 1495998                          License: BSD 3-Clause; GPL v2 only; LGPL v2.1 only
> > ....
> > Summary     : Open Virtual Machine Tools
> > Description :
> > Open Virtual Machine Tools (open-vm-tools) are the open source
> > implementation of VMware Tools.
> 
> It's a License Problem?

As you can see from text you quoted the License(s) are all open source
and allowed by Fedora. A quick look at the code and it seems these
license tags are accurate too.

The open-vm-tools contains a mixture of userspace libraries/agents, and
a bunch of kernel modules. The kernel modules will not be allowed in 
Fedora as per packaging standards. Anyone is free to package up the
userspace tools. 

Despite their generic sounding name they are really only useful for
VMWare because the host<->guest communication protocl is utter
crackrock, relying on poking a special (potentially unsafe) IO port,
and not portable to non-x86 architectures.

Furthermore 'vm tools' as a concept really shouldn't need to even exist.
Each bit of functionality should be integrated into the appropriate 
existing application or tool, so things 'just work' in a VM without 
needing install of special packages. eg mouse / video drivers are already
part of Xorg as standard. The hgfs mount helper program should just be 
part of util-lnux; monitoring extensions added to existing monitoring 
tools like collectd or nagios. Don't let that stop you packaging it up
if you want it in Fedora though.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From denis at poolshark.org  Wed Oct 15 09:35:34 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 15 Oct 2008 11:35:34 +0200
Subject: open-vm-tools for Fedora
In-Reply-To: <20081015092935.GB25527@redhat.com>
References: <1224062002.4116.10.camel@lesca>
	<20081015092935.GB25527@redhat.com>
Message-ID: <48F5B966.8080405@poolshark.org>

Daniel P. Berrange wrote:
> Furthermore 'vm tools' as a concept really shouldn't need to even exist.
> Each bit of functionality should be integrated into the appropriate 
> existing application or tool, so things 'just work' in a VM without 
> needing install of special packages.

Send patches.

> Don't let that stop you packaging it up
> if you want it in Fedora though.

http://www.poolshark.org/dkms-open-vm-tools/



From pbrobinson at gmail.com  Wed Oct 15 09:39:18 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 15 Oct 2008 10:39:18 +0100
Subject: open-vm-tools for Fedora
In-Reply-To: <48F5B6BD.2020800@city-fan.org>
References: <1224062002.4116.10.camel@lesca> <48F5B6BD.2020800@city-fan.org>
Message-ID: <5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>

On Wed, Oct 15, 2008 at 10:24 AM, Paul Howarth <paul at city-fan.org> wrote:
> Dario Lesca wrote:
>>
>> Why Fedora not have in our standard repo the open-vm-tools package?
>>
>> http://open-vm-tools.sourceforge.net/
>>
>>> linux-0chi:~ # rpm -qi open-vm-tools-2008.04.14-21.1
>>> Name        : open-vm-tools                Relocations: (not relocatable)
>>> Version     : 2008.04.14                        Vendor: SUSE LINUX
>>> Products GmbH, Nuernberg, Germany
>>> ....
>>> Group       : System/Emulators/PC           Source RPM:
>>> open-vm-tools-2008.04.14-21.1.src.rpm
>>> Size        : 1495998                          License: BSD 3-Clause; GPL
>>> v2 only; LGPL v2.1 only
>>> ....
>>> Summary     : Open Virtual Machine Tools
>>> Description :
>>> Open Virtual Machine Tools (open-vm-tools) are the open source
>>> implementation of VMware Tools.
>>
>> It's a License Problem?
>> Or maintainer problem?
>
> Neither, it's that out-of-tree kernel modules aren't allowed in Fedora.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=294341

Looks like a perfect candidate for rpmfusion.org

Peter



From berrange at redhat.com  Wed Oct 15 09:40:29 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 15 Oct 2008 10:40:29 +0100
Subject: open-vm-tools for Fedora
In-Reply-To: <48F5B966.8080405@poolshark.org>
References: <1224062002.4116.10.camel@lesca>
	<20081015092935.GB25527@redhat.com>
	<48F5B966.8080405@poolshark.org>
Message-ID: <20081015094029.GE25527@redhat.com>

On Wed, Oct 15, 2008 at 11:35:34AM +0200, Denis Leroy wrote:
> Daniel P. Berrange wrote:
> >Furthermore 'vm tools' as a concept really shouldn't need to even exist.
> >Each bit of functionality should be integrated into the appropriate 
> >existing application or tool, so things 'just work' in a VM without 
> >needing install of special packages.
> 
> Send patches.

I already send patches for virt support to relevant applications.

I've no interest in sending patches to open-vm-tools as a project
because VMware require that you sign a contributors agreement.
This gives VMWare joint copyright assignment allowing them to use
all contributed code in non-open source projects. No thanks.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From pbrobinson at gmail.com  Wed Oct 15 09:43:00 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 15 Oct 2008 10:43:00 +0100
Subject: First steps of the transition from Livna to RPM Fusion begins
	now for livna-devel users!
In-Reply-To: <48F4C067.90308@leemhuis.info>
References: <48F4C067.90308@leemhuis.info>
Message-ID: <5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>

> Find below a cut'n'pasted and slightly enhanced version of a post from my
> blog FYI:
>
>
> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ), the
> merger of Dribble, Freshrpms and Livna gets closer to its official
> release/start. Most of the packages from Livna have been imported and build
> for RPM Fusion already, hence we now begin to slowly move users from Livna
> over to RPM Fusion by activating the RPM Fusion free and nonfree rawhide
> repos for users of livna's devel branch *now*.
>
> The transition works like this: I just added the rpmfusion-release packages
> for the RPM Fusion's free and nonfree rawhide repos to the livna-devel repo;
> in parallel I built a new livna-release package that tracks those two in
> with a hard dep. That way all users that installed livna properly (e.g. by
> installing the livna-release package) will get RPM Fusion repos enabled
> automatically with the next update. Yum/PK will hence with the overnext
> update will download a big bunch of updates, as all the packages were build
> anew for RPM Fusion; but rawhide users are likely used to big downloads, so
> this should hopefully not be a big problem ;-)
>
> Note, nearly all of livna's packages have been imported and build for RPM
> Fusion, but a few are still missing. So you should leave livna-devel enabled
> for now if you want access to those. Once all the packages have a new home
> we'll let the rpmfusion-nonfree-release package obsolete livna-release.
>
> But please note that all the packages that have been imported and build in
> RPM Fusion will *not* be updated anymore in livna-devel! Hence if you didn't
> install livna using the livna-release package then please enable RPM Fusion
> using the following command:
>
>> rpm -ivh \
>>
>> http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm
>> \
>>
>> http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm
>
> That command from now on is the right one to use if you want RPM Fusion
> enabled on your fresh new Fedora Alpha/Beta/RC/Rawhide install.

Is there any chance of getting all the kmod packages rebuilt against
the the current 2.6.27-3 release? The rest of the packages I've tested
look great, its just some of the kmod ones I can't.

Peter



From denis at poolshark.org  Wed Oct 15 09:45:36 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 15 Oct 2008 11:45:36 +0200
Subject: open-vm-tools for Fedora
In-Reply-To: <20081015094029.GE25527@redhat.com>
References: <1224062002.4116.10.camel@lesca>	<20081015092935.GB25527@redhat.com>	<48F5B966.8080405@poolshark.org>
	<20081015094029.GE25527@redhat.com>
Message-ID: <48F5BBC0.5030204@poolshark.org>

Daniel P. Berrange wrote:
> I've no interest in sending patches to open-vm-tools as a project
> because VMware require that you sign a contributors agreement.
> This gives VMWare joint copyright assignment allowing them to use
> all contributed code in non-open source projects.

Didn't realize that. Yes, that's pretty awful.
-denis



From fedora at leemhuis.info  Wed Oct 15 09:50:53 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 11:50:53 +0200
Subject: open-vm-tools for Fedora
In-Reply-To: <5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>
References: <1224062002.4116.10.camel@lesca> <48F5B6BD.2020800@city-fan.org>
	<5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>
Message-ID: <48F5BCFD.4010006@leemhuis.info>

On 15.10.2008 11:39, Peter Robinson wrote:
> On Wed, Oct 15, 2008 at 10:24 AM, Paul Howarth <paul at city-fan.org> wrote:
>> Dario Lesca wrote:
>>> Why Fedora not have in our standard repo the open-vm-tools package?
>>>
>>> http://open-vm-tools.sourceforge.net/
>>>
>>>> linux-0chi:~ # rpm -qi open-vm-tools-2008.04.14-21.1
>>>> Name        : open-vm-tools                Relocations: (not relocatable)
>>>> Version     : 2008.04.14                        Vendor: SUSE LINUX
>>>> Products GmbH, Nuernberg, Germany
>>>> ....
>>>> Group       : System/Emulators/PC           Source RPM:
>>>> open-vm-tools-2008.04.14-21.1.src.rpm
>>>> Size        : 1495998                          License: BSD 3-Clause; GPL
>>>> v2 only; LGPL v2.1 only
>>>> ....
>>>> Summary     : Open Virtual Machine Tools
>>>> Description :
>>>> Open Virtual Machine Tools (open-vm-tools) are the open source
>>>> implementation of VMware Tools.
>>> It's a License Problem?
>>> Or maintainer problem?
>> Neither, it's that out-of-tree kernel modules aren't allowed in Fedora.
>> https://bugzilla.redhat.com/show_bug.cgi?id=294341
> Looks like a perfect candidate for rpmfusion.org

As mentioned earlier in this thread today:

Simply download those:

http://people.centos.org/hughesjr/open-vm-tools/5/SRPMS/open-vm-tools-0-0.20080620.el5.centos.src.rpm
http://install.dulug.duke.edu/pub/linux/add-on/distrib/centos-5/SRPMS/open-vm-tools-0-0.20080319.2.el5_2.src.rpm

http://people.centos.org/hughesjr/open-vm-tools/5/SRPMS/open-vm-tools-kmod-0-0.20080620.2.6.18_92.el5.src.rpm
http://install.dulug.duke.edu/pub/linux/add-on/distrib/centos-5/SRPMS/open-vm-tools-kmod-0-0.20080319.1.2.6.18_92.1.10.el5.src.rpm

merge each of the two and submit for review; if you need help then 
contact me in private (I'll help with the modifications for the kmod2 
stuff and I'll normally take care of rebuilding all the kmod for newly 
released Fedora update kernels).

CU
knurd

P.S.: The base for the packages above iirc comes from Livna; see
http://bugzilla.livna.org/show_bug.cgi?id=1664
http://bugzilla.livna.org/show_bug.cgi?id=1665
I still have those packages on my hard disk somewhere.



From denis at poolshark.org  Wed Oct 15 09:26:36 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 15 Oct 2008 11:26:36 +0200
Subject: open-vm-tools for Fedora
In-Reply-To: <1224062002.4116.10.camel@lesca>
References: <1224062002.4116.10.camel@lesca>
Message-ID: <48F5B74C.6040508@poolshark.org>

Dario Lesca wrote:
> Why Fedora not have in our standard repo the open-vm-tools package?
> 
> http://open-vm-tools.sourceforge.net/
> 
>> linux-0chi:~ # rpm -qi open-vm-tools-2008.04.14-21.1
>> Name        : open-vm-tools                Relocations: (not relocatable)
>> Version     : 2008.04.14                        Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
>> ....
>> Group       : System/Emulators/PC           Source RPM: open-vm-tools-2008.04.14-21.1.src.rpm
>> Size        : 1495998                          License: BSD 3-Clause; GPL v2 only; LGPL v2.1 only
>> ....
>> Summary     : Open Virtual Machine Tools
>> Description :
>> Open Virtual Machine Tools (open-vm-tools) are the open source
>> implementation of VMware Tools.
> 
> It's a License Problem?
> Or maintainer problem?

It's a Fedora Policy problem.

http://www.redhat.com/archives/fedora-devel-list/2007-September/msg01949.html



From fedora at leemhuis.info  Wed Oct 15 10:02:22 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 12:02:22 +0200
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>
References: <48F4C067.90308@leemhuis.info>
	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>
Message-ID: <48F5BFAE.3030406@leemhuis.info>

On 15.10.2008 11:43, Peter Robinson wrote:
>> Find below a cut'n'pasted and slightly enhanced version of a post from my
>> blog FYI:
>>
>> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ), the
>> merger of Dribble, Freshrpms and Livna gets closer to its official
>> release/start. Most of the packages from Livna have been imported and build
>> for RPM Fusion already, hence we now begin to slowly move users from Livna
>> over to RPM Fusion by activating the RPM Fusion free and nonfree rawhide
>> repos for users of livna's devel branch *now*.
>>[...]
> Is there any chance of getting all the kmod packages rebuilt against
> the the current 2.6.27-3 release? The rest of the packages I've tested
> look great, its just some of the kmod ones I can't.

I build the kmods for the kernel that were shipped with the beta. If you 
follow rawhide then you might want to install the akmod-packages (e.g. 
akmod-nvidia); then the akmods scripts will automatically build new kmod 
packages when you install a new kernel-install (or during boot); that's 
similar to how dkms does it.

The plan is to rebuild all kmods in RPM Fusion for the latest rawhide 
kernel automatically once a week (likely on each Sunday) to make sure 
they still compile (and for users with slow netbooks, where you don't 
want to compile modules); but I haven't got around to set that up yet, 
sorry.

CU
knurd



From pbrobinson at gmail.com  Wed Oct 15 10:13:58 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 15 Oct 2008 11:13:58 +0100
Subject: First steps of the transition from Livna to RPM Fusion begins
	now for livna-devel users!
In-Reply-To: <48F5BFAE.3030406@leemhuis.info>
References: <48F4C067.90308@leemhuis.info>
	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>
	<48F5BFAE.3030406@leemhuis.info>
Message-ID: <5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>

>>> Find below a cut'n'pasted and slightly enhanced version of a post from my
>>> blog FYI:
>>>
>>> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ),
>>> the
>>> merger of Dribble, Freshrpms and Livna gets closer to its official
>>> release/start. Most of the packages from Livna have been imported and
>>> build
>>> for RPM Fusion already, hence we now begin to slowly move users from
>>> Livna
>>> over to RPM Fusion by activating the RPM Fusion free and nonfree rawhide
>>> repos for users of livna's devel branch *now*.
>>> [...]
>>
>> Is there any chance of getting all the kmod packages rebuilt against
>> the the current 2.6.27-3 release? The rest of the packages I've tested
>> look great, its just some of the kmod ones I can't.
>
> I build the kmods for the kernel that were shipped with the beta. If you
> follow rawhide then you might want to install the akmod-packages (e.g.
> akmod-nvidia); then the akmods scripts will automatically build new kmod
> packages when you install a new kernel-install (or during boot); that's
> similar to how dkms does it.
>
> The plan is to rebuild all kmods in RPM Fusion for the latest rawhide kernel
> automatically once a week (likely on each Sunday) to make sure they still
> compile (and for users with slow netbooks, where you don't want to compile
> modules); but I haven't got around to set that up yet, sorry.

The netbook wifi drivers were what I was after as my netbook doesn't
have the space for compilers etc. and I don't have any other i386
boxes around to recompile and hadn't had time to try and work out how
to make mock build them. Weekly would be great.

Peter



From fedora at leemhuis.info  Wed Oct 15 10:30:27 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 12:30:27 +0200
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>
	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>
Message-ID: <48F5C643.1080709@leemhuis.info>

On 15.10.2008 12:13, Peter Robinson wrote:
>>>> Find below a cut'n'pasted and slightly enhanced version of a post from my
>>>> blog FYI:
>>>>
>>>> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ),
>>>> the
>>>> merger of Dribble, Freshrpms and Livna gets closer to its official
>>>> release/start. Most of the packages from Livna have been imported and
>>>> build
>>>> for RPM Fusion already, hence we now begin to slowly move users from
>>>> Livna
>>>> over to RPM Fusion by activating the RPM Fusion free and nonfree rawhide
>>>> repos for users of livna's devel branch *now*.
>>>> [...]
>>> Is there any chance of getting all the kmod packages rebuilt against
>>> the the current 2.6.27-3 release? The rest of the packages I've tested
>>> look great, its just some of the kmod ones I can't.
>> I build the kmods for the kernel that were shipped with the beta. If you
>> follow rawhide then you might want to install the akmod-packages (e.g.
>> akmod-nvidia); then the akmods scripts will automatically build new kmod
>> packages when you install a new kernel-install (or during boot); that's
>> similar to how dkms does it.
>>
>> The plan is to rebuild all kmods in RPM Fusion for the latest rawhide kernel
>> automatically once a week (likely on each Sunday) to make sure they still
>> compile (and for users with slow netbooks, where you don't want to compile
>> modules); but I haven't got around to set that up yet, sorry.
> 
> The netbook wifi drivers were what I was after as my netbook [...]

I suppose you own a 1st gen EeePC? If yes, then give the ath5k driver 
from 2.6.27 a try, as it should support the wireless chips in those Eee 
PCs afaik.

CU
knurd



From karsten at redhat.com  Wed Oct 15 10:35:06 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Wed, 15 Oct 2008 12:35:06 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <48ECEFB9.1080600@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>
Message-ID: <48F5C75A.9040603@redhat.com>

Karsten Hopp schrieb:
> Josh Boyer schrieb:
>> On Wed, Oct 08, 2008 at 01:14:28PM -0400, Bill Nottingham wrote:
>>> Orion Poplawski (orion at cora.nwra.com) said:
>>>> Should we get libtool 2.2.X into F-11 now?
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=435737
>>> After beta freeze seems like a bad time to add a package that's going
>>> to cause other things not to build. If it can be added as an additional
>>> package that won't get int the way of builds that aren't expecting it,
>>> it would be more palatable.
>>
>> He said F-11.  I would extrapolate that to mean "branch libtool
>> for F-10 now, and have devel be libtool 2.2.x."  That would have
>> no bearing on rawhide/F-10.
>>
>> josh
>>
> 
> Getting libtool-2.2 into F-11 is my plan, but I most likely need to get 
> that through
> FESCo as it breaks up to 300 packages according to my mass rebuilds. I'm 
> going to
> prepare a Wiki page with details about that.
> 
>     Karsten
> 

Braden reminded me to post an update on this ;-)

My last rebuild showed only ~100 failures, I'm not sure what I've done differently
this time. I suspect that the removal of libtool-ltdl and all related packages from
my full-install might have caused this and I'm in the process of rebuilding those with libtool-2.
I've uploaded the current logs to http://karsten.fedorapeople.org/
After a quick glance at them I think that there are quite a few easy fixes, but I still
have to find out what causes p.e. the cracklib failure.

    Karsten



From dominik at greysector.net  Wed Oct 15 10:45:14 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 15 Oct 2008 12:45:14 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224023771.18940.15.camel@moss-terrapins.epoch.ncsc.mil>
References: <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014093239.GA27002@mokona.greysector.net>
	<1224023771.18940.15.camel@moss-terrapins.epoch.ncsc.mil>
Message-ID: <20081015104513.GA5543@mokona.greysector.net>

On Wednesday, 15 October 2008 at 00:36, David P. Quigley wrote:
> On Tue, 2008-10-14 at 11:32 +0200, Dominik 'Rathann' Mierzejewski wrote:
> > SELinux is another subject for a good rant. Example: I created /var/log/dovecot,
> > chowned it to dovecot user and configured it to put its logs there. Bang!
> > SELinux denial. There's no easy way to fix it permanently either and SELinux
> > tools documentation is akin to arcane knowledge. Unless you're familiar with
> > all the terminology, you won't understand it.
> > 
> [snip]
> 
> Permanent fix which survives relabels.

And how do you know that? I can't find anything about it in man semanage.

> /usr/sbin/semanage fcontext -a -t dovecot_var_log_t /var/log/dovecot
> /sbin/restorecon -v /var/log/dovecot

You mean there's no generic "allow-owner-to-write-in-their-own-directory"
setting? That's just great. So how do I find out the magic incantation
for another application?

> SELinux documentation has been lacking in the past but Red Hat has hired
> someone to write proper documentation for SELinux and it is getting
> better every day. In an article on LWN I answered this question[1]. In
> addition to this someone also linked the page below which contains quite
> a bit of information that this person gathered when learning about
> SELinux[2]. If you are willing to take the time to go through some of
> his stuff you will realize SELinux really isn't as difficult as people
> make it out to be, it's just that its not what they are use to. You
> already know to set one set of permissions on the file when you create
> it you just have to realize there is a type that needs to be set as
> well.
> 
> [1]http://lwn.net/Articles/290168/
> [2]http://equivocation.org/selinux

Ah. Isn't that obvious? An LWN article and some random website as the canonical
source of SELinux documentation. Of course that's the first place anyone will
look.

At least put it in policycoreutils package docs. There's nothing apart from
manpages there and these are quite uninformative. Or put those articles (or
link to them) on Fedora wiki. Please.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From tmus at tmus.dk  Wed Oct 15 10:47:19 2008
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Wed, 15 Oct 2008 08:47:19 -0200
Subject: open-vm-tools for Fedora
In-Reply-To: <20081015094029.GE25527@redhat.com>
References: <1224062002.4116.10.camel@lesca>	<20081015092935.GB25527@redhat.com>	<48F5B966.8080405@poolshark.org>
	<20081015094029.GE25527@redhat.com>
Message-ID: <48F5CA37.1030501@tmus.dk>

Daniel P. Berrange wrote:
> 
> I've no interest in sending patches to open-vm-tools as a project
> because VMware require that you sign a contributors agreement.
> This gives VMWare joint copyright assignment allowing them to use
> all contributed code in non-open source projects. No thanks.
> 
IANAL, but can VMware even require that for GPL,LGPL licensed code?
I'd think not..?

/Thomas



From berrange at redhat.com  Wed Oct 15 10:55:05 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 15 Oct 2008 11:55:05 +0100
Subject: open-vm-tools for Fedora
In-Reply-To: <48F5CA37.1030501@tmus.dk>
References: <1224062002.4116.10.camel@lesca>
	<20081015092935.GB25527@redhat.com>
	<48F5B966.8080405@poolshark.org>
	<20081015094029.GE25527@redhat.com> <48F5CA37.1030501@tmus.dk>
Message-ID: <20081015105505.GH25527@redhat.com>

On Wed, Oct 15, 2008 at 08:47:19AM -0200, Thomas M Steenholdt wrote:
> Daniel P. Berrange wrote:
> >
> >I've no interest in sending patches to open-vm-tools as a project
> >because VMware require that you sign a contributors agreement.
> >This gives VMWare joint copyright assignment allowing them to use
> >all contributed code in non-open source projects. No thanks.
> >
> IANAL, but can VMware even require that for GPL,LGPL licensed code?
> I'd think not..?

That's the whole point of requiring contributors to give them copyright
over submissions. If you are copyright owner you can change license 
terms to whatever you like any time you like.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From rjones at redhat.com  Wed Oct 15 10:55:31 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 15 Oct 2008 11:55:31 +0100
Subject: open-vm-tools for Fedora
In-Reply-To: <48F5CA37.1030501@tmus.dk>
References: <1224062002.4116.10.camel@lesca>
	<20081015092935.GB25527@redhat.com>
	<48F5B966.8080405@poolshark.org>
	<20081015094029.GE25527@redhat.com> <48F5CA37.1030501@tmus.dk>
Message-ID: <20081015105531.GA17267@amd.home.annexia.org>

On Wed, Oct 15, 2008 at 08:47:19AM -0200, Thomas M Steenholdt wrote:
> Daniel P. Berrange wrote:
>>
>> I've no interest in sending patches to open-vm-tools as a project
>> because VMware require that you sign a contributors agreement.
>> This gives VMWare joint copyright assignment allowing them to use
>> all contributed code in non-open source projects. No thanks.
>>
> IANAL, but can VMware even require that for GPL,LGPL licensed code?
> I'd think not..?

You can require copyright assignments for any project (any project
protected by copyright at any rate).  The FSF, for example, routinely
asks for copyright assignments for all of their projects - it's just
that we trust the FSF a lot more than some random closed-source
company.

http://www.gnu.org/licenses/why-assign.html

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From pbrobinson at gmail.com  Wed Oct 15 11:09:43 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 15 Oct 2008 12:09:43 +0100
Subject: First steps of the transition from Livna to RPM Fusion begins
	now for livna-devel users!
In-Reply-To: <48F5C643.1080709@leemhuis.info>
References: <48F4C067.90308@leemhuis.info>
	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>
	<48F5BFAE.3030406@leemhuis.info>
	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>
	<48F5C643.1080709@leemhuis.info>
Message-ID: <5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>

>>>>> Find below a cut'n'pasted and slightly enhanced version of a post from
>>>>> my
>>>>> blog FYI:
>>>>>
>>>>> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org
>>>>> ),
>>>>> the
>>>>> merger of Dribble, Freshrpms and Livna gets closer to its official
>>>>> release/start. Most of the packages from Livna have been imported and
>>>>> build
>>>>> for RPM Fusion already, hence we now begin to slowly move users from
>>>>> Livna
>>>>> over to RPM Fusion by activating the RPM Fusion free and nonfree
>>>>> rawhide
>>>>> repos for users of livna's devel branch *now*.
>>>>> [...]
>>>>
>>>> Is there any chance of getting all the kmod packages rebuilt against
>>>> the the current 2.6.27-3 release? The rest of the packages I've tested
>>>> look great, its just some of the kmod ones I can't.
>>>
>>> I build the kmods for the kernel that were shipped with the beta. If you
>>> follow rawhide then you might want to install the akmod-packages (e.g.
>>> akmod-nvidia); then the akmods scripts will automatically build new kmod
>>> packages when you install a new kernel-install (or during boot); that's
>>> similar to how dkms does it.
>>>
>>> The plan is to rebuild all kmods in RPM Fusion for the latest rawhide
>>> kernel
>>> automatically once a week (likely on each Sunday) to make sure they still
>>> compile (and for users with slow netbooks, where you don't want to
>>> compile
>>> modules); but I haven't got around to set that up yet, sorry.
>>
>> The netbook wifi drivers were what I was after as my netbook [...]
>
> I suppose you own a 1st gen EeePC? If yes, then give the ath5k driver from
> 2.6.27 a try, as it should support the wireless chips in those Eee PCs
> afaik.

Nope, a eeePC 901 with the rt2680 card (I think its that one - some
realtek 11n card anyway).

Peter



From jwboyer at gmail.com  Wed Oct 15 11:33:17 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 15 Oct 2008 07:33:17 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081015074228.GB2795@free.fr>
References: <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
Message-ID: <20081015113317.GA26690@yoda.jdub.homelinux.org>

On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
>On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
>> 
>> If we present the _appearance_ of a distro with security updates, while
>> in fact there are serious security issues being unfixed, then that is
>> _much_ worse than the current "That distro is EOL. Upgrade before you
>> get hacked" messaging.
>
>The aim here is not to present the _appearance_ of a distro with
>security updates but give the choice to the user either to upgrade or to
>stick with a distro where some packages will not be maintained.
>Something along "That distro is EOL. Upgrade before you get hacked.
>Alternatively, and at your own risk, you can enable a repository where 
>some packages are updated on a volunteer basis, but some packages aren't
>maintained anymore."
>
>With a page listing which packages are still supported.

The issue you will have is that people will not be comfortable opening the
ACLs for things like the kernel or glibc or gcc.  And if those ACLs are still
closed and the maintainers have no interest in participating in this "life
after EOL" scheme, then it's very hard to have any appearance of security.

josh



From jwboyer at gmail.com  Wed Oct 15 11:46:59 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 15 Oct 2008 07:46:59 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F5A81B.90505@poolshark.org>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>
	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info> <48F5A5FA.90604@poolshark.org>
	<20081015081639.GF2795@free.fr> <48F5A81B.90505@poolshark.org>
Message-ID: <20081015114659.GB26690@yoda.jdub.homelinux.org>

On Wed, Oct 15, 2008 at 10:21:47AM +0200, Denis Leroy wrote:
> Patrice Dumas wrote:
>> On Wed, Oct 15, 2008 at 10:12:42AM +0200, Denis Leroy wrote:
>>> Thorsten Leemhuis wrote:
>>>> Just a note for those not familiar with the habits from Livna/RPM   
>>>> Fusion: Livna/RPM Fusion normally doesn't take any packages that 
>>>> are  suitable for Fedora (??).
>>> Can you define "suitable" :-) ? there are some packages that are   
>>> suitable in theory, but won't get in without a fight through FeSCo.
>>
>> Which free software package without patent issue wouldn't be suitable?
>> Maybe an additional kernel (like the bsd kernel or the HURD, would be
>> nice, any taker?), but otherwise?
>
> - packages likely to be vetoed by a Red Hat employee (and therefore by  
> FeSCo): compat-python, compat-gcc-32

Red Hat does not control FESCo.  There are Red Hat employees on FESCo,
but each one was elected by the community.

josh



From jwboyer at gmail.com  Wed Oct 15 11:50:53 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 15 Oct 2008 07:50:53 -0400
Subject: open-vm-tools for Fedora
In-Reply-To: <48F5B74C.6040508@poolshark.org>
References: <1224062002.4116.10.camel@lesca> <48F5B74C.6040508@poolshark.org>
Message-ID: <20081015115053.GC26690@yoda.jdub.homelinux.org>

On Wed, Oct 15, 2008 at 11:26:36AM +0200, Denis Leroy wrote:
> Dario Lesca wrote:
>> Why Fedora not have in our standard repo the open-vm-tools package?
>>
>> http://open-vm-tools.sourceforge.net/
>>
>>> linux-0chi:~ # rpm -qi open-vm-tools-2008.04.14-21.1
>>> Name        : open-vm-tools                Relocations: (not relocatable)
>>> Version     : 2008.04.14                        Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
>>> ....
>>> Group       : System/Emulators/PC           Source RPM: open-vm-tools-2008.04.14-21.1.src.rpm
>>> Size        : 1495998                          License: BSD 3-Clause; GPL v2 only; LGPL v2.1 only
>>> ....
>>> Summary     : Open Virtual Machine Tools
>>> Description :
>>> Open Virtual Machine Tools (open-vm-tools) are the open source
>>> implementation of VMware Tools.
>>
>> It's a License Problem?
>> Or maintainer problem?
>
> It's a Fedora Policy problem.

It's not a problem.  It's simply a Fedora Policy.

josh



From d.lesca at solinos.it  Wed Oct 15 11:58:40 2008
From: d.lesca at solinos.it (Dario Lesca)
Date: Wed, 15 Oct 2008 13:58:40 +0200
Subject: open-vm-tools for Fedora
In-Reply-To: <1224062002.4116.10.camel@lesca>
References: <1224062002.4116.10.camel@lesca>
Message-ID: <1224071920.4116.46.camel@lesca>

Il giorno mer, 15/10/2008 alle 11.13 +0200, Dario Lesca ha scritto:

> Many thanks
yes, many thanks to all

I am not a super expert on Linux and then I will not be able to generate
all the packages needed. 

So I continue to NOT use the vmtools: everything worked well without
them. 

Regards

-- 
Dario Lesca <d.lesca at solinos.it>



From pertusus at free.fr  Wed Oct 15 12:13:50 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 14:13:50 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081015113317.GA26690@yoda.jdub.homelinux.org>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
Message-ID: <20081015121350.GB3091@free.fr>

On Wed, Oct 15, 2008 at 07:33:17AM -0400, Josh Boyer wrote:
> >
> >The aim here is not to present the _appearance_ of a distro with
> >security updates but give the choice to the user either to upgrade or to
> >stick with a distro where some packages will not be maintained.
> >Something along "That distro is EOL. Upgrade before you get hacked.
> >Alternatively, and at your own risk, you can enable a repository where 
> >some packages are updated on a volunteer basis, but some packages aren't
> >maintained anymore."
> >
> >With a page listing which packages are still supported.
> 
> The issue you will have is that people will not be comfortable opening the
> ACLs for things like the kernel or glibc or gcc.  And if those ACLs are still
> closed and the maintainers have no interest in participating in this "life
> after EOL" scheme, then it's very hard to have any appearance of security.

You mean, even for branches they don't maintain anymore? That would be
strange.

--
Pat



From rc040203 at freenet.de  Wed Oct 15 12:19:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 15 Oct 2008 14:19:09 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081015113317.GA26690@yoda.jdub.homelinux.org>
References: <48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr> <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
Message-ID: <1224073149.3029.550.camel@beck.corsepiu.local>

On Wed, 2008-10-15 at 07:33 -0400, Josh Boyer wrote:
> On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
> >On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
> >> 
> >> If we present the _appearance_ of a distro with security updates, while
> >> in fact there are serious security issues being unfixed, then that is
> >> _much_ worse than the current "That distro is EOL. Upgrade before you
> >> get hacked" messaging.
> >
> >The aim here is not to present the _appearance_ of a distro with
> >security updates but give the choice to the user either to upgrade or to
> >stick with a distro where some packages will not be maintained.
> >Something along "That distro is EOL. Upgrade before you get hacked.
> >Alternatively, and at your own risk, you can enable a repository where 
> >some packages are updated on a volunteer basis, but some packages aren't
> >maintained anymore."
> >
> >With a page listing which packages are still supported.
> 
> The issue you will have is that people will not be comfortable opening the
> ACLs for things like the kernel or glibc or gcc.
And their rationale being what?

Them preferring leaving users exposed to vulnerabilities?

Or is their rationale of personal nature?




From dwalsh at redhat.com  Wed Oct 15 12:40:49 2008
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 15 Oct 2008 08:40:49 -0400
Subject: SELinux - copying ISO file content
In-Reply-To: <1223904802.4264.37.camel@perihelion.int.jonmasters.org>
References: <1223010224.28226.11.camel@perihelion.int.jonmasters.org>	<48E61A7E.8010404@redhat.com>	<1223108738.9328.40.camel@perihelion.int.jonmasters.org>	<48EA1B32.1010008@redhat.com>
	<48EA725E.2050908@shaw.ca>	<1223386945.10179.6.camel@londonpacket.bos.redhat.com>	<1223400274.26341.15.camel@localhost.localdomain>	<1223402107.4410.20.camel@luminos.localdomain>	<20081007223409.19bc8223@ludwig-alpha.unil.ch>
	<1223904802.4264.37.camel@perihelion.int.jonmasters.org>
Message-ID: <48F5E4D1.3090309@redhat.com>

Jon Masters wrote:
> On Tue, 2008-10-07 at 22:34 +0200, Christian Iseli wrote:
>> On Tue, 07 Oct 2008 10:55:07 -0700, Jesse Keating wrote:
>>> Somebody else jumped on the thread and steered the conversation
>>> toward a virtualbox problem, which somewhat related to Jon's issue,
>>> it's not the same issue.
>> Right, mea culpa and sorry about that.  I thought my problem had the
>> same root as the OP's problem, but it now appears I was wrong...
> 
> :)
> 
> I occasionally bring up the SELinux issue because I'm trying to ask
> "what would a regular computer user think?", not whether I can solve the
> problem for myself with setting contexts or disabling the protection. 
> 
> And last night, I had a wonderful SELinux experience again, this time
> using Samba shares. None of the guests running within KVM were able to
> talk to Samba, so I wasted time pondering networking problems, etc.
> before I realized I rebooted since I setup the Samba shares. In the end,
> the usual process of mumbling sweet words about SELinux and turning it
> off was the response...and I remain convinced therefore that it is
> entirely appropriate to subject regular desktop users to SELinux.
> 
> Jon.
> 
> 
Not wanting to get into a argument what was the problem you were seeing?
 Were your virtual machines on a samba share?  And libvirt not able to
start the image because qemu was not allowed to read samba shares?




From jwboyer at gmail.com  Wed Oct 15 12:43:48 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 15 Oct 2008 08:43:48 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081015121350.GB3091@free.fr>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
Message-ID: <20081015124348.GA27658@yoda.jdub.homelinux.org>

On Wed, Oct 15, 2008 at 02:13:50PM +0200, Patrice Dumas wrote:
>On Wed, Oct 15, 2008 at 07:33:17AM -0400, Josh Boyer wrote:
>> >
>> >The aim here is not to present the _appearance_ of a distro with
>> >security updates but give the choice to the user either to upgrade or to
>> >stick with a distro where some packages will not be maintained.
>> >Something along "That distro is EOL. Upgrade before you get hacked.
>> >Alternatively, and at your own risk, you can enable a repository where 
>> >some packages are updated on a volunteer basis, but some packages aren't
>> >maintained anymore."
>> >
>> >With a page listing which packages are still supported.
>> 
>> The issue you will have is that people will not be comfortable opening the
>> ACLs for things like the kernel or glibc or gcc.  And if those ACLs are still
>> closed and the maintainers have no interest in participating in this "life
>> after EOL" scheme, then it's very hard to have any appearance of security.
>
>You mean, even for branches they don't maintain anymore? That would be
>strange.

No, it really wouldn't.  If the ACLs are open for the kernel on an older branch
anyone with cvsextras (or whatever the FAS group is now called) can commit to it.
That means anyone can fsck up the kernel and break all of those users on this
EOLed release.

(And bug reports, blah blah blah.)

josh



From jwboyer at gmail.com  Wed Oct 15 12:45:49 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 15 Oct 2008 08:45:49 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <1224073149.3029.550.camel@beck.corsepiu.local>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<1224073149.3029.550.camel@beck.corsepiu.local>
Message-ID: <20081015124549.GB27658@yoda.jdub.homelinux.org>

On Wed, Oct 15, 2008 at 02:19:09PM +0200, Ralf Corsepius wrote:
>On Wed, 2008-10-15 at 07:33 -0400, Josh Boyer wrote:
>> On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
>> >On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
>> >> 
>> >> If we present the _appearance_ of a distro with security updates, while
>> >> in fact there are serious security issues being unfixed, then that is
>> >> _much_ worse than the current "That distro is EOL. Upgrade before you
>> >> get hacked" messaging.
>> >
>> >The aim here is not to present the _appearance_ of a distro with
>> >security updates but give the choice to the user either to upgrade or to
>> >stick with a distro where some packages will not be maintained.
>> >Something along "That distro is EOL. Upgrade before you get hacked.
>> >Alternatively, and at your own risk, you can enable a repository where 
>> >some packages are updated on a volunteer basis, but some packages aren't
>> >maintained anymore."
>> >
>> >With a page listing which packages are still supported.
>> 
>> The issue you will have is that people will not be comfortable opening the
>> ACLs for things like the kernel or glibc or gcc.
>And their rationale being what?

See my other reply.

>Them preferring leaving users exposed to vulnerabilities?

Obviously not, since the newer distros are maintained.

>Or is their rationale of personal nature?

Well, since we're all just talking theoreticals I don't see how anything
can be of a personal nature yet.

josh



From opensource at till.name  Wed Oct 15 12:50:13 2008
From: opensource at till.name (Till Maas)
Date: Wed, 15 Oct 2008 14:50:13 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081015124348.GA27658@yoda.jdub.homelinux.org>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
Message-ID: <200810151450.24406.opensource@till.name>

On Wed October 15 2008, Josh Boyer wrote:

> (And bug reports, blah blah blah.)

If the ACLs for the EOL releases are cleared, the maintainers of the supported 
packages will not get any bug reports (unless Bugzilla does not support this 
of course). Also the EOL-team can triage the bugs for the supported release 
to avoid bugging the maintainers.

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/20081015/00a1398e/attachment.sig>

From lesmikesell at gmail.com  Wed Oct 15 12:57:00 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 15 Oct 2008 07:57:00 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <20081015124549.GB27658@yoda.jdub.homelinux.org>
References: <48F280FA.8010507@shmuelhome.mine.nu>	<loom.20081012T230422-741@post.gmane.org>	<48F288A3.8000601@shmuelhome.mine.nu>	<loom.20081013T001327-394@post.gmane.org>	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>	<loom.20081013T013947-433@post.gmane.org>	<1224056165.6770.955.camel@macbook.infradead.org>	<20081015074228.GB2795@free.fr>	<20081015113317.GA26690@yoda.jdub.homelinux.org>	<1224073149.3029.550.camel@beck.corsepiu.local>
	<20081015124549.GB27658@yoda.jdub.homelinux.org>
Message-ID: <48F5E89C.4040005@gmail.com>

Josh Boyer wrote:
> On Wed, Oct 15, 2008 at 02:19:09PM +0200, Ralf Corsepius wrote:
>> On Wed, 2008-10-15 at 07:33 -0400, Josh Boyer wrote:
>>> On Wed, Oct 15, 2008 at 09:42:28AM +0200, Patrice Dumas wrote:
>>>> On Wed, Oct 15, 2008 at 08:36:05AM +0100, David Woodhouse wrote:
>>>>> If we present the _appearance_ of a distro with security updates, while
>>>>> in fact there are serious security issues being unfixed, then that is
>>>>> _much_ worse than the current "That distro is EOL. Upgrade before you
>>>>> get hacked" messaging.
>>>> The aim here is not to present the _appearance_ of a distro with
>>>> security updates but give the choice to the user either to upgrade or to
>>>> stick with a distro where some packages will not be maintained.
>>>> Something along "That distro is EOL. Upgrade before you get hacked.
>>>> Alternatively, and at your own risk, you can enable a repository where 
>>>> some packages are updated on a volunteer basis, but some packages aren't
>>>> maintained anymore."
>>>>
>>>> With a page listing which packages are still supported.
>>> The issue you will have is that people will not be comfortable opening the
>>> ACLs for things like the kernel or glibc or gcc.
>> And their rationale being what?
> 
> See my other reply.
> 
>> Them preferring leaving users exposed to vulnerabilities?
> 
> Obviously not, since the newer distros are maintained.

With disruptive changes that make it impossible to know if your hardware 
or applications will still work after an upgrade - and what is the 
alternative if they don't?

-- 
   Les Mikesell
    lesmikesell at gmail.com




From lesmikesell at gmail.com  Wed Oct 15 13:12:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 15 Oct 2008 08:12:04 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <1224055872.6770.950.camel@macbook.infradead.org>
References: <20081011220135.GK2305@br-online.de>	<20081011221705.GC8235@free.fr>	<20081011222850.GM10204@angus.ind.WPI.EDU>	<1223804148.3564.1355.camel@beck.corsepiu.local>	<20081012105804.GA6353@orient.maison.lan>	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>	<20081012154755.GP10204@angus.ind.WPI.EDU>	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>	<48F2A2C8.2020306@rincon.com>	<20081013021420.GB29893@angus.ind.WPI.EDU>
	<1224055872.6770.950.camel@macbook.infradead.org>
Message-ID: <48F5EC24.9020007@gmail.com>

David Woodhouse wrote:
> 
>>> I really don't see how a Fedora Legacy can be maintained.  If the 
>>> goal is increased stability and security patches, you need to 
>>> guarantee that you have folks supporting backpatches to the kernel, 
>>> glibc, firefox, evolution, openoffice, and several other large and 
>>> complex packages.  Incorporating new security patches into old 
>>> baselines is *hard*. Plus Fedora would "fork" a new release every 6 
>>> months.  How many legacy Fedora's would be retained?  At some point 
>>> it seems the legacy volunteer force would saturate and legacy 
>>> Fedora's would have to start dropping off every 6 months.
>> Why do we need to guarantee any more than active Fedora releases 
>> guarantee?  Forget backporting.  Just upgrade the package.  Take it 
>> from the current Fedora and rebuild it if necessary.
> 
> Once you start upgrading packages all over the place to a much newer
> version than was in the original release, you might as well just
> upgrade.
> 
> Seriously, I don't know why people are so scared of just _upgrading_, if
> new packages are acceptable.
> 
> I upgrade remote, headless machines with yum, and reboot them into the
> new distribution. Quite frequently. And I laugh at the people who say it
> doesn't work. It's a fairly fundamental part of my server management
> technique -- yes, I run Fedora on my servers.

What do you do when the upgrade kernel won't boot?   This sometimes 
happens even on updates within a version.

> Perhaps a better approach to this whole thing would be to educate people
> a little better that upgrades _do_ work, and they're generally fairly
> seamless. And to fix the occasional cases where they're not.

And supply them with spare test machines like you must use?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From alan at redhat.com  Wed Oct 15 13:14:46 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 15 Oct 2008 09:14:46 -0400
Subject: open-vm-tools for Fedora
In-Reply-To: <48F5CA37.1030501@tmus.dk>
References: <1224062002.4116.10.camel@lesca>
	<20081015092935.GB25527@redhat.com>
	<48F5B966.8080405@poolshark.org>
	<20081015094029.GE25527@redhat.com> <48F5CA37.1030501@tmus.dk>
Message-ID: <20081015131446.GA19296@shell.devel.redhat.com>

> IANAL, but can VMware even require that for GPL,LGPL licensed code?
> I'd think not..?

They can - its not an implicit right to have people take your patches so they
can refuse them all they like. What they can't stop you doing is simply forking
the project and creating a new version with their GPL code and your GPL code and
redistributing that.

Alan



From katzj at redhat.com  Wed Oct 15 12:57:36 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 15 Oct 2008 08:57:36 -0400
Subject: open-vm-tools for Fedora
In-Reply-To: <5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>
References: <1224062002.4116.10.camel@lesca> <48F5B6BD.2020800@city-fan.org>
	<5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>
Message-ID: <1224075456.12340.145.camel@aglarond.local>

On Wed, 2008-10-15 at 10:39 +0100, Peter Robinson wrote:
> On Wed, Oct 15, 2008 at 10:24 AM, Paul Howarth <paul at city-fan.org> wrote:
> > Neither, it's that out-of-tree kernel modules aren't allowed in Fedora.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=294341
> 
> Looks like a perfect candidate for rpmfusion.org

... and rather than helping to propagate the notion to vendors that out
of tree drivers are "okay", why not try to help work with the
maintainers to get the drivers upstream?  Maybe more effort, but in the
end it's far more rewarding as *all* Linux users who would care about
them benefit.

Jeremy



From katzj at redhat.com  Wed Oct 15 12:57:53 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 15 Oct 2008 08:57:53 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F5A172.9000405@leemhuis.info>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>
	<48F59905.50206@linux-kernel.at> <48F5A172.9000405@leemhuis.info>
Message-ID: <1224075473.12340.146.camel@aglarond.local>

On Wed, 2008-10-15 at 09:53 +0200, Thorsten Leemhuis wrote:
> On 15.10.2008 09:17, Oliver Falk wrote:
> Back then we tried our best to get compat-python directly into Fedora, 
> but those efforts failed. Hence Livna accepted compat-python (and hence 
> it made its way to RPM Fusion). But I'm all for moving compat-python* to 
> Fedora, so I really appreciate your efforts Oliver!

I am still very very much against the existence of a compat-python* in
Fedora.  I'll even go a step further and say that the existence of such
in rpmfusion/livna has actually hurt things rather than helped.  Since
rpmfusion/livna has carried this package, there has continued to be no
impetus on the Zope people to actually move forward to a modern version
of python.  We had this discussion *OVER* a year ago and at the time a
compat-python was "just going to be for a release".  Yet more than a
year later, the situation is exactly the same.  And actually, it's worse
now because people have realized that just base python isn't enough --
they need base python plus some set of modules that they care about.
And another group of people will need another set of packages for their
zope/plone deployment[1].  In three years, are we still going to need a
compat-python2.4 for zope/plone in 3 years because, as was mentioned,
we'll be going to python 2.6 in Fedora 11 and python 3 at an unspecified
point beyond that and if python 2.5 is this much trouble, 2.6 and 3 are
going to be far worse.

We don't ship multiple versions of Xorg because a new version of Xorg
breaks some driver, instead we fix drivers.  We don't ship multiple
versions of apache because apache2 broke some modules.  <insert
infinitely long list of other such things we don't support>.  Why should
python be *any* different for zope/plone?

Jeremy

[1] Want to have your zope and plone instances auth to FAS?  Guess you
need python-fedora now...  How about openid?  There's a different module
there.  Etc.



From jwboyer at gmail.com  Wed Oct 15 13:19:58 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 15 Oct 2008 09:19:58 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <48F5EC24.9020007@gmail.com>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<20081013021420.GB29893@angus.ind.WPI.EDU>
	<1224055872.6770.950.camel@macbook.infradead.org>
	<48F5EC24.9020007@gmail.com>
Message-ID: <20081015131958.GC27658@yoda.jdub.homelinux.org>

On Wed, Oct 15, 2008 at 08:12:04AM -0500, Les Mikesell wrote:
> David Woodhouse wrote:
>>
>>>> I really don't see how a Fedora Legacy can be maintained.  If the  
>>>> goal is increased stability and security patches, you need to  
>>>> guarantee that you have folks supporting backpatches to the kernel, 
>>>> glibc, firefox, evolution, openoffice, and several other large and  
>>>> complex packages.  Incorporating new security patches into old  
>>>> baselines is *hard*. Plus Fedora would "fork" a new release every 6 
>>>> months.  How many legacy Fedora's would be retained?  At some point 
>>>> it seems the legacy volunteer force would saturate and legacy  
>>>> Fedora's would have to start dropping off every 6 months.
>>> Why do we need to guarantee any more than active Fedora releases  
>>> guarantee?  Forget backporting.  Just upgrade the package.  Take it  
>>> from the current Fedora and rebuild it if necessary.
>>
>> Once you start upgrading packages all over the place to a much newer
>> version than was in the original release, you might as well just
>> upgrade.
>>
>> Seriously, I don't know why people are so scared of just _upgrading_, if
>> new packages are acceptable.
>>
>> I upgrade remote, headless machines with yum, and reboot them into the
>> new distribution. Quite frequently. And I laugh at the people who say it
>> doesn't work. It's a fairly fundamental part of my server management
>> technique -- yes, I run Fedora on my servers.
>
> What do you do when the upgrade kernel won't boot?   This sometimes  
> happens even on updates within a version.

Yum updates leave the kernel you are currently running on in-place.
Boot back to that one and file a bug.

josh



From arequipeno at gmail.com  Tue Oct 14 16:48:01 2008
From: arequipeno at gmail.com (Ian Pilcher)
Date: Tue, 14 Oct 2008 11:48:01 -0500
Subject: Running Fedora 10 Beta in KVM
In-Reply-To: <bfdeacfa0810131543s2bbd3de4rd0de07130d39b0eb@mail.gmail.com>
References: <bfdeacfa0810131543s2bbd3de4rd0de07130d39b0eb@mail.gmail.com>
Message-ID: <gd2ig2$7o6$1@ger.gmane.org>

Mark Bidewell wrote:
> Is anyone running the Fedora 10 Beta in KVM?  I am using KVM-77 and
> Fedora 10 Install either loses Keyboard and/or mouse and will lock up
> part way through the install. Text mode install cannot see the
> harddrive?  Has anyone else seen this?

I didn't have any real problem installing it on top of Fedora 8 (both
x86_64).  In fact, it works a heck of a lot better there than on any
real hardware that I've tried.

-- 
========================================================================
Ian Pilcher                                         arequipeno at gmail.com
========================================================================



From dbn.lists at gmail.com  Wed Oct 15 13:34:36 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Wed, 15 Oct 2008 06:34:36 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <48F5C75A.9040603@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48F5C75A.9040603@redhat.com>
Message-ID: <91705d080810150634g516508bby93f316288651b71@mail.gmail.com>

On Wed, Oct 15, 2008 at 3:35 AM, Karsten Hopp <karsten at redhat.com> wrote:
>
> My last rebuild showed only ~100 failures, I'm not sure what I've done
> differently
> this time. I suspect that the removal of libtool-ltdl and all related
> packages from
> my full-install might have caused this and I'm in the process of rebuilding
> those with libtool-2.
> I've uploaded the current logs to http://karsten.fedorapeople.org/
> After a quick glance at them I think that there are quite a few easy fixes,
> but I still
> have to find out what causes p.e. the cracklib failure.

Looking at the first few:

afflib: needs AC_PROG_CXX
amanda: aclocal not told where macros are, end up using old libtool m4 macros
aplus-fsf: needs AC_PROG_CXX
apr: script manually copying libtool files and getting it wrong (just
use autoreconf!)
avahi: needs AC_PROG_CXX
ax25-apps: looks like aclocal was run, but libtoolize wasn't, causing
mismatch between macros and ltmain.sh
bind: aclocal not told where macros are, end up using old libtool m4 macros
blackbox: needs AC_PROG_CXX
bmpx: needs AC_PROG_CXX
bzflag: needs AC_PROG_CXX
cairo-dock: needs AC_PROG_CXX
compat-db: libtool macros copied manually and getting it wrong
cracklib: yeah, failing on --tag=CC is very weird, especially when
configure.in seems completely reasonable

--
Dan



From pertusus at free.fr  Wed Oct 15 13:34:53 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 15:34:53 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081015124348.GA27658@yoda.jdub.homelinux.org>
References: <loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
Message-ID: <20081015133453.GC3091@free.fr>

On Wed, Oct 15, 2008 at 08:43:48AM -0400, Josh Boyer wrote:
> 
> No, it really wouldn't.  If the ACLs are open for the kernel on an older branch
> anyone with cvsextras (or whatever the FAS group is now called) can commit to it.
> That means anyone can fsck up the kernel and break all of those users on this
> EOLed release.

In the proposal the updated packages go to another repository, isn't
that enough? I honestly don't think that FESCo would endorse such an attitude.
Unless I am missing something, the closed ACL are only accepted for
security reasons, I don't think that a "don't touch my packages even
though I don't maintain them" attitude is something we want to have in
Fedora. My understanding of the current situation is even that Jesse 
(hoping I recall well) is pushing forward opening ACLs for former core 
packages except when there is a strong security concern, now that there 
are 2 groups, uberpackagers and packagers.

> (And bug reports, blah blah blah.)

Also removing the owners from the ACL (which is something that should be
done in the future, I think) will stop them from receiving bug reports
for the branch.

--
Pat



From denis at poolshark.org  Wed Oct 15 13:38:05 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 15 Oct 2008 15:38:05 +0200
Subject: open-vm-tools for Fedora
In-Reply-To: <1224075456.12340.145.camel@aglarond.local>
References: <1224062002.4116.10.camel@lesca>
	<48F5B6BD.2020800@city-fan.org>	<5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>
	<1224075456.12340.145.camel@aglarond.local>
Message-ID: <48F5F23D.3030603@poolshark.org>

Jeremy Katz wrote:
> ... and rather than helping to propagate the notion to vendors that out
> of tree drivers are "okay", why not try to help work with the
> maintainers to get the drivers upstream?

My understanding is that they are. One of problem with the "get the 
drivers upstream" concept is that it's a slow and difficult endeavour. 
There used to be some anti-VMWare resentment on LKML that wouldn't help 
either, but I don't know whether that's still true or not...

-denis




From james.antill at redhat.com  Wed Oct 15 13:45:05 2008
From: james.antill at redhat.com (James Antill)
Date: Wed, 15 Oct 2008 09:45:05 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F596F2.6000902@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info> <48F47C58.9060702@linux-kernel.at>
	<1223988009.16958.51.camel@code.and.org>
	<48F596F2.6000902@linux-kernel.at>
Message-ID: <1224078305.16958.82.camel@code.and.org>

On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
> James Antill wrote:
> [ ... ]
> >> I can think of a Python 2.4 package that lives within the Zope tree to 
> >> make it extra hard for others to use it by accident - but I don't think 
> >> that this would be neat, seen from a FHS point of view.
> > 
> >  In some ways this might be doable, at least it has less pain points
> > than packaging it "properly".
> 
> I'm not sure what you mean here? Do you mean with properly an 
> /usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to 
> invite everybody to have a look at the livna packages. Those are fine 
> and don't hurt the main python...

% repoquery --repoid=livna --provides compat-python24-imaging      
_imaging.so()(64bit)
_imagingft.so()(64bit)
_imagingmath.so()(64bit)
compat-python24-imaging = 1.1.6-1.lvn9
% repoquery --provides python-imaging               
_imaging.so()(64bit)
_imagingft.so()(64bit)
_imagingmath.so()(64bit)
python-imaging = 1.1.6-9.fc9
% repoquery --repoid=livna --provides compat-python24-lxml   
compat-python24-lxml = 2.0.5-1.lvn9
etree.so()(64bit)
objectify.so()(64bit)
pyclasslookup.so()(64bit)
% repoquery --provides python-lxml
etree.so()(64bit)
objectify.so()(64bit)
pyclasslookup.so()(64bit)
python-lxml = 2.0.8-1.fc9

...those are all "wrong", in that you can get cross python/python24
provides/requires.

>  > and you need to
> > make sure that python-foo doesn't pull in compat-python24-bar (and vice
> > versa).
> 
> Hm. How should that happen? Especially with koji....

 Well that's a big question, the simplest solution we've come up with is
"don't package python24" ... hence my text about that if everything was
kludged into Zope itself (and all the provides removed) it would be
better, in some ways.

-- 
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/20081015/e92fc26e/attachment.sig>

From james.antill at redhat.com  Wed Oct 15 13:51:35 2008
From: james.antill at redhat.com (James Antill)
Date: Wed, 15 Oct 2008 09:51:35 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F5A34C.3090701@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<20081015073609.GA2795@free.fr>  <48F5A34C.3090701@linux-kernel.at>
Message-ID: <1224078695.16958.89.camel@code.and.org>

On Wed, 2008-10-15 at 10:01 +0200, Oliver Falk wrote:

> > In my opinion, instead, packagers should be co-maintaining the main
> > version when they do a compat package, and that's all.
> 
> It's python, it's the holy (Fedora/Red Hat) grail. I think only people 
> on the Red Hat payroll are allowed to commit to python CVS, isn't it? 
> :-P Sorry, no offense!

 I've given python co-maintainer ship to the only non-RH person who has
asked for it. On the other hand, if you seemed sane and I gave it to
you ... and then you broke python so that Zope could work, I'm not
likely to be impressed :).

> I think the main version packagers should allowed to have commit access 
> to the compat packages instead. In case compat packager breaks main 
> version, the main version packager can fix it...

 That implies we don't mind it being broken for a while ... given how
important python is we _really_ don't like it breaking in a non-trivial
way (or eg. yum doesn't work, and you can't update out of your problem)

 Also that's not how the breaks happen, it's not like you get file
conflicts etc. ... you get multiple dep. providers and there's no way to
fix that by changing the main python package.

-- 
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/20081015/b2d64cbf/attachment.sig>

From berrange at redhat.com  Wed Oct 15 13:53:44 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 15 Oct 2008 14:53:44 +0100
Subject: open-vm-tools for Fedora
In-Reply-To: <48F5F23D.3030603@poolshark.org>
References: <1224062002.4116.10.camel@lesca> <48F5B6BD.2020800@city-fan.org>
	<5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>
	<1224075456.12340.145.camel@aglarond.local>
	<48F5F23D.3030603@poolshark.org>
Message-ID: <20081015135344.GN25527@redhat.com>

On Wed, Oct 15, 2008 at 03:38:05PM +0200, Denis Leroy wrote:
> Jeremy Katz wrote:
> >... and rather than helping to propagate the notion to vendors that out
> >of tree drivers are "okay", why not try to help work with the
> >maintainers to get the drivers upstream?
> 
> My understanding is that they are. One of problem with the "get the 
> drivers upstream" concept is that it's a slow and difficult endeavour. 
> There used to be some anti-VMWare resentment on LKML that wouldn't help 
> either, but I don't know whether that's still true or not...

Some of the it has been sent upstream and there were some issues
that needed more work - eg getting a reliable and safe way to
detect that it is running on vmware

[quote http://lkml.org/lkml/2008/9/8/130]
vmware could have used one of the following methods to communicate to 
the guest kernel:

 - a CPUID and an MSR range - like a good virtual CPU should. That way 
   even bootloaders could detect the presence of vmware.
 - or a PCI ID and a PCI driver like KVM does
 - or a system call hypercall gateway like Xen and KVM does
 - or it could even have used a DMI signature of some sort

but no, vmware had to use 30 year old unsafe ISA port magic...

To add insult to injury that port is named 'backdoor' - very smart and 
confidence raising naming. Plus it does not even use some well-known PC 
port that is harmless to read - it has to be from the middle of the 
generic IO port resource range where a real PCI card could sit: 0x5658.
[/quote]

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From limb at jcomserv.net  Wed Oct 15 13:55:56 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 15 Oct 2008 08:55:56 -0500 (CDT)
Subject: open-vm-tools for Fedora
In-Reply-To: <20081015135344.GN25527@redhat.com>
References: <1224062002.4116.10.camel@lesca> <48F5B6BD.2020800@city-fan.org>
	<5256d0b0810150239r33fec891kc31579273e9baf70@mail.gmail.com>
	<1224075456.12340.145.camel@aglarond.local>
	<48F5F23D.3030603@poolshark.org> <20081015135344.GN25527@redhat.com>
Message-ID: <33417.198.175.55.5.1224078956.squirrel@mail.jcomserv.net>


> On Wed, Oct 15, 2008 at 03:38:05PM +0200, Denis Leroy wrote:
>> Jeremy Katz wrote:
>> >... and rather than helping to propagate the notion to vendors that out
>> >of tree drivers are "okay", why not try to help work with the
>> >maintainers to get the drivers upstream?
>>
>> My understanding is that they are. One of problem with the "get the
>> drivers upstream" concept is that it's a slow and difficult endeavour.
>> There used to be some anti-VMWare resentment on LKML that wouldn't help
>> either, but I don't know whether that's still true or not...
>
> Some of the it has been sent upstream and there were some issues
> that needed more work - eg getting a reliable and safe way to
> detect that it is running on vmware
>
> [quote http://lkml.org/lkml/2008/9/8/130]
> vmware could have used one of the following methods to communicate to
> the guest kernel:
>
>  - a CPUID and an MSR range - like a good virtual CPU should. That way
>    even bootloaders could detect the presence of vmware.
>  - or a PCI ID and a PCI driver like KVM does
>  - or a system call hypercall gateway like Xen and KVM does
>  - or it could even have used a DMI signature of some sort
>
> but no, vmware had to use 30 year old unsafe ISA port magic...
>
> To add insult to injury that port is named 'backdoor' - very smart and
> confidence raising naming. Plus it does not even use some well-known PC
> port that is harmless to read - it has to be from the middle of the
> generic IO port resource range where a real PCI card could sit: 0x5658.
> [/quote]

Wow.  Certainly gives one pause.

> Daniel
> --
> |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/
> :|
> |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
> :|
>
> --
> 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  Wed Oct 15 13:56:17 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 15 Oct 2008 08:56:17 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <20081015131958.GC27658@yoda.jdub.homelinux.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>	<20081012105804.GA6353@orient.maison.lan>	<48F1E0B7.4000004@shmuelhome.mine.nu>	<20081012123341.GD3936@free.fr>	<20081012154755.GP10204@angus.ind.WPI.EDU>	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>	<48F2A2C8.2020306@rincon.com>	<20081013021420.GB29893@angus.ind.WPI.EDU>	<1224055872.6770.950.camel@macbook.infradead.org>	<48F5EC24.9020007@gmail.com>
	<20081015131958.GC27658@yoda.jdub.homelinux.org>
Message-ID: <48F5F681.7050404@gmail.com>

Josh Boyer wrote:
> On Wed, Oct 15, 2008 at 08:12:04AM -0500, Les Mikesell wrote:
>> David Woodhouse wrote:
>>>>> I really don't see how a Fedora Legacy can be maintained.  If the  
>>>>> goal is increased stability and security patches, you need to  
>>>>> guarantee that you have folks supporting backpatches to the kernel, 
>>>>> glibc, firefox, evolution, openoffice, and several other large and  
>>>>> complex packages.  Incorporating new security patches into old  
>>>>> baselines is *hard*. Plus Fedora would "fork" a new release every 6 
>>>>> months.  How many legacy Fedora's would be retained?  At some point 
>>>>> it seems the legacy volunteer force would saturate and legacy  
>>>>> Fedora's would have to start dropping off every 6 months.
>>>> Why do we need to guarantee any more than active Fedora releases  
>>>> guarantee?  Forget backporting.  Just upgrade the package.  Take it  
>>>> from the current Fedora and rebuild it if necessary.
>>> Once you start upgrading packages all over the place to a much newer
>>> version than was in the original release, you might as well just
>>> upgrade.
>>>
>>> Seriously, I don't know why people are so scared of just _upgrading_, if
>>> new packages are acceptable.
>>>
>>> I upgrade remote, headless machines with yum, and reboot them into the
>>> new distribution. Quite frequently. And I laugh at the people who say it
>>> doesn't work. It's a fairly fundamental part of my server management
>>> technique -- yes, I run Fedora on my servers.
>> What do you do when the upgrade kernel won't boot?   This sometimes  
>> happens even on updates within a version.
> 
> Yum updates leave the kernel you are currently running on in-place.
> Boot back to that one and file a bug.

And if the machine is remote and headless as above?  Or just generally 
inconvenient to access or have down while you figure out what broke?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pertusus at free.fr  Wed Oct 15 14:05:27 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 16:05:27 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224078305.16958.82.camel@code.and.org>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<1223988009.16958.51.camel@code.and.org>
	<48F596F2.6000902@linux-kernel.at>
	<1224078305.16958.82.camel@code.and.org>
Message-ID: <20081015140527.GD3091@free.fr>

On Wed, Oct 15, 2008 at 09:45:05AM -0400, James Antill wrote:
> 
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)

These kind of provides are simply wrong (in my opinion). rpm provides
script should only get the sonames automatically. Other people disagree
because it is what the elf linker does. See also:

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

--
Pat



From j.w.r.degoede at hhs.nl  Wed Oct 15 14:36:07 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 15 Oct 2008 16:36:07 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224078305.16958.82.camel@code.and.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>	<1223988009.16958.51.camel@code.and.org>	<48F596F2.6000902@linux-kernel.at>
	<1224078305.16958.82.camel@code.and.org>
Message-ID: <48F5FFD7.5050908@hhs.nl>

James Antill wrote:
> On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
>> James Antill wrote:
>> [ ... ]
>>>> I can think of a Python 2.4 package that lives within the Zope tree to 
>>>> make it extra hard for others to use it by accident - but I don't think 
>>>> that this would be neat, seen from a FHS point of view.
>>>  In some ways this might be doable, at least it has less pain points
>>> than packaging it "properly".
>> I'm not sure what you mean here? Do you mean with properly an 
>> /usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to 
>> invite everybody to have a look at the livna packages. Those are fine 
>> and don't hurt the main python...
> 
> % repoquery --repoid=livna --provides compat-python24-imaging      
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)
> compat-python24-imaging = 1.1.6-1.lvn9
> % repoquery --provides python-imaging               
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)

Yes rpmbuild is very broken in that it generates provides for .so files which 
are not under libdir, so plugins for applications / libs / languages can have 
conflicting Provides, luckily nothing should ever Require these plugins. Never 
the less this is an rpm big, which should get fixed for the reduce the repo 
metadata size reason alone, feel free to file a bug *against rpm* for this (or 
add comments to the existing one)

> python-imaging = 1.1.6-9.fc9

Notice how this one differs, and this is the only one which packages should 
ever require!

> % repoquery --repoid=livna --provides compat-python24-lxml   
> compat-python24-lxml = 2.0.5-1.lvn9
> etree.so()(64bit)
> objectify.so()(64bit)
> pyclasslookup.so()(64bit)
> % repoquery --provides python-lxml
> etree.so()(64bit)
> objectify.so()(64bit)
> pyclasslookup.so()(64bit)
> python-lxml = 2.0.8-1.fc9
> 

Same here.

> ...those are all "wrong", in that you can get cross python/python24
> provides/requires.

Yes just like any application which can use esd for sound, but does not has it 
hard compiled in and has a plugin called esd.so for that under %{_libdir}/%{name}

Will conflict with another application which has a plugin with the same name, 
under:
%{_libdir}/%{different-name}

This is an *rpm bug* and I'm sure we already have many many Provides 
"conflicts" becase of this, nothing to see here (except an *rpm bug*) move along.

Regards,

Hans



From sundaram at fedoraproject.org  Wed Oct 15 14:35:17 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 15 Oct 2008 20:05:17 +0530
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>	<48F5C643.1080709@leemhuis.info>
	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
Message-ID: <48F5FFA5.3050607@fedoraproject.org>

Peter Robinson wrote:

> 
> Nope, a eeePC 901 with the rt2680 card (I think its that one - some
> realtek 11n card anyway).

Follow

http://lkml.org/lkml/2008/8/5/519

Rahul



From notting at redhat.com  Wed Oct 15 14:51:09 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 15 Oct 2008 10:51:09 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <20081015133453.GC3091@free.fr>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
Message-ID: <20081015145109.GD1773@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> In the proposal the updated packages go to another repository, isn't
> that enough? I honestly don't think that FESCo would endorse such an attitude.

If it's going to another repository... why do you need the same CVS
history? (To play devil's advocate.)

Bill



From fedora at leemhuis.info  Wed Oct 15 14:55:22 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 16:55:22 +0200
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <48F5FFA5.3050607@fedoraproject.org>
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>	<48F5C643.1080709@leemhuis.info>	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
	<48F5FFA5.3050607@fedoraproject.org>
Message-ID: <48F6045A.5010609@leemhuis.info>

On 15.10.2008 16:35, Rahul Sundaram wrote:
> Peter Robinson wrote:
> 
>> Nope, a eeePC 901 with the rt2680 card (I think its that one - some
>> realtek 11n card anyway).
> 
> Follow
> http://lkml.org/lkml/2008/8/5/519

Heck, why? Those drivers that Linus refers to are the ones that are 
provided by RPM Fusion ;-) And the proper driver that hopefully gets 
merged into the kernel sooner or later is still far from ready afaics:

http://thread.gmane.org/gmane.linux.kernel.wireless.general/19813/focus=21177

Cu
knurd



From sundaram at fedoraproject.org  Wed Oct 15 15:03:47 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 15 Oct 2008 20:33:47 +0530
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <48F6045A.5010609@leemhuis.info>
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>	<48F5C643.1080709@leemhuis.info>	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>	<48F5FFA5.3050607@fedoraproject.org>
	<48F6045A.5010609@leemhuis.info>
Message-ID: <48F60653.9000502@fedoraproject.org>

Thorsten Leemhuis wrote:
> On 15.10.2008 16:35, Rahul Sundaram wrote:
>> Peter Robinson wrote:
>>
>>> Nope, a eeePC 901 with the rt2680 card (I think its that one - some
>>> realtek 11n card anyway).
>>
>> Follow
>> http://lkml.org/lkml/2008/8/5/519
> 
> Heck, why? Those drivers that Linus refers to are the ones that are 
> provided by RPM Fusion ;-) And the proper driver that hopefully gets 
> merged into the kernel sooner or later is still far from ready afaics:
> 
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/19813/focus=21177 

It is part of the same thread. My point was not for him to install third 
party drivers that way but to show current discussions upstream.

Rahul



From pbrobinson at gmail.com  Wed Oct 15 15:06:05 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 15 Oct 2008 16:06:05 +0100
Subject: First steps of the transition from Livna to RPM Fusion begins
	now for livna-devel users!
In-Reply-To: <48F6045A.5010609@leemhuis.info>
References: <48F4C067.90308@leemhuis.info>
	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>
	<48F5BFAE.3030406@leemhuis.info>
	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>
	<48F5C643.1080709@leemhuis.info>
	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
	<48F5FFA5.3050607@fedoraproject.org> <48F6045A.5010609@leemhuis.info>
Message-ID: <5256d0b0810150806y119ebeb5oc73d133f02d3c90d@mail.gmail.com>

>>> Nope, a eeePC 901 with the rt2680 card (I think its that one - some
>>> realtek 11n card anyway).
>>
>> Follow
>> http://lkml.org/lkml/2008/8/5/519
>
> Heck, why? Those drivers that Linus refers to are the ones that are provided
> by RPM Fusion ;-) And the proper driver that hopefully gets merged into the
> kernel sooner or later is still far from ready afaics:
>
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/19813/focus=21177

The problem is that I believe they are focusing primarily on the 2870
usb version first with plans for the PCI one later so to have a kmod
in rpmfusion in the mean time would be useful.

Peter



From pertusus at free.fr  Wed Oct 15 15:15:38 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 17:15:38 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081015145109.GD1773@nostromo.devel.redhat.com>
References: <loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
Message-ID: <20081015151506.GG3091@free.fr>

On Wed, Oct 15, 2008 at 10:51:09AM -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > In the proposal the updated packages go to another repository, isn't
> > that enough? I honestly don't think that FESCo would endorse such an attitude.
> 
> If it's going to another repository... why do you need the same CVS
> history? (To play devil's advocate.)

In the long term, if the project has gained trust and approval from
fedora and can be under the fedora umbrella it will be more simple. And
even before it will be more simple...

--
Pat



From fedora at leemhuis.info  Wed Oct 15 15:15:43 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 17:15:43 +0200
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <48F60653.9000502@fedoraproject.org>
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>	<48F5C643.1080709@leemhuis.info>	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>	<48F5FFA5.3050607@fedoraproject.org>	<48F6045A.5010609@leemhuis.info>
	<48F60653.9000502@fedoraproject.org>
Message-ID: <48F6091F.5070308@leemhuis.info>

On 15.10.2008 17:03, Rahul Sundaram wrote:
> Thorsten Leemhuis wrote:
>> On 15.10.2008 16:35, Rahul Sundaram wrote:
>>> Peter Robinson wrote:
>>>
>>>> Nope, a eeePC 901 with the rt2680 card (I think its that one - some
>>>> realtek 11n card anyway).
>>> Follow
>>> http://lkml.org/lkml/2008/8/5/519
>> Heck, why? Those drivers that Linus refers to are the ones that are 
>> provided by RPM Fusion ;-) And the proper driver that hopefully gets 
>> merged into the kernel sooner or later is still far from ready afaics:
>>
>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/19813/focus=21177 
> 
> It is part of the same thread.

Nope. It's not even the same mailing list ;-)

Cu
knurd



From rc040203 at freenet.de  Wed Oct 15 15:18:28 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 15 Oct 2008 17:18:28 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081015145109.GD1773@nostromo.devel.redhat.com>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
Message-ID: <1224083908.3029.560.camel@beck.corsepiu.local>

On Wed, 2008-10-15 at 10:51 -0400, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > In the proposal the updated packages go to another repository, isn't
> > that enough? I honestly don't think that FESCo would endorse such an attitude.
> 
> If it's going to another repository... why do you need the same CVS
> history? (To play devil's advocate.)
Right. 

If this all shall make sense and remain unbureaucratic and efficient,
there must not be any "other repo" nor "other VCS" nor distrust.

Seems to me as if some people around here are resistant to learning?





From fedora at leemhuis.info  Wed Oct 15 15:23:03 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 15 Oct 2008 17:23:03 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224075473.12340.146.camel@aglarond.local>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info>
	<1224075473.12340.146.camel@aglarond.local>
Message-ID: <48F60AD7.2020807@leemhuis.info>

On 15.10.2008 14:57, Jeremy Katz wrote:
 > [...]

You have lots of good arguments and I agree partly or completely with 
most of them. Nevertheless I think it is the right thing to ship 
compat-python* in RPM Fusion/Livna.

Why?

In short: Well, the world sometimes is not as good as we would like it 
to be; we can try our best to fix it, but the task is really really big; 
if you nevertheless try to do it you might forget the real goal you 
aimed for in the beginning -- if you are not careful you might get 
obsoleted and irrelevant on the way.


The longer variant: We can try our best to fix things and put pressure 
on other other people to fix their stuff -- the plone and zope 
developers in this case. But we can't force people to do what we want 
(which is a good thing in the end), as this whole game is about *free* 
software; thus the only way to definitely get what we want would be to 
do it ourselves.

That is a whole lot of work that afaics nobody from us is willing to do. 
Thus trying to increase the pressure by not shipping plone and zope at 
all seems like a good idea. But by doing that we bring ourselves 
(Fedora) in a worse situation. And free software/Linux is about choice 
-- if you don't get what you want from somebody (from Fedora) you can 
always (a) find somebody else that gives you want you want or (b) do it 
yourself.

The (a) case afaics is quite easy way for a lot of people and afaics one 
of the reasons why Ubuntu is so popular these days, because they just 
give people what they ask for (including proprietary drivers (which is 
bad, but that is another topic)). Hence if we in the plone/zope case and 
hundred similar cases do what is best, but not what users want, then 
Fedora and Red Hat in the end might lose completely. They might become a 
niche distribution that is only worth a short paragraph in "the history 
of Open-Source from 1983 -- 2083"; others will get all the glory.


Note note! With above I don't mean that we should throw away all or 
ideals and start including proprietary drivers in Linux. But we could 
work together with the other big distributors to increase the pressure 
on the plone and zope developers -- because if the main and popular ones 
together say "we'll drop python 2.4 on distributions released after 
20081231" then for sure something will happen.

And yes, sure, there is still the freedom and the possibility that 
another Ubuntu then arises from nowhere and just does things the users 
want even if those things are worse for the ecosystem; but that's not 
that easy to do.

Cu
knurd



From nicu_fedora at nicubunu.ro  Wed Oct 15 15:27:51 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Wed, 15 Oct 2008 18:27:51 +0300
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>	<48F5C643.1080709@leemhuis.info>
	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
Message-ID: <48F60BF7.1020504@nicubunu.ro>

Peter Robinson wrote:
>>> The netbook wifi drivers were what I was after as my netbook [...]
>> I suppose you own a 1st gen EeePC? If yes, then give the ath5k driver from
>> 2.6.27 a try, as it should support the wireless chips in those Eee PCs
>> afaik.
> 
> Nope, a eeePC 901 with the rt2680 card (I think its that one - some
> realtek 11n card anyway).

Well, I rebuilt the src.rpm from rpmfusion for the latest rawhide, it is 
able so see APs, can connect to the unencrypted ones but seems to fail 
for WPA-PSK.

-- 
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 sundaram at fedoraproject.org  Wed Oct 15 15:29:36 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 15 Oct 2008 20:59:36 +0530
Subject: First steps of the transition from Livna to RPM Fusion begins
 now for livna-devel users!
In-Reply-To: <48F6091F.5070308@leemhuis.info>
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>	<48F5C643.1080709@leemhuis.info>	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>	<48F5FFA5.3050607@fedoraproject.org>	<48F6045A.5010609@leemhuis.info>	<48F60653.9000502@fedoraproject.org>
	<48F6091F.5070308@leemhuis.info>
Message-ID: <48F60C60.6050401@fedoraproject.org>

Thorsten Leemhuis wrote:
> On 15.10.2008 17:03, Rahul Sundaram wrote:
>> Thorsten Leemhuis wrote:
>>> On 15.10.2008 16:35, Rahul Sundaram wrote:
>>>> Peter Robinson wrote:
>>>>
>>>>> Nope, a eeePC 901 with the rt2680 card (I think its that one - some
>>>>> realtek 11n card anyway).
>>>> Follow
>>>> http://lkml.org/lkml/2008/8/5/519
>>> Heck, why? Those drivers that Linus refers to are the ones that are 
>>> provided by RPM Fusion ;-) And the proper driver that hopefully gets 
>>> merged into the kernel sooner or later is still far from ready afaics:
>>>
>>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/19813/focus=21177 
>>
>>
>> It is part of the same thread.
> 
> Nope. It's not even the same mailing list ;-)

I meant, it is referred.

Rahul



From dpquigl at tycho.nsa.gov  Wed Oct 15 15:12:12 2008
From: dpquigl at tycho.nsa.gov (David P. Quigley)
Date: Wed, 15 Oct 2008 11:12:12 -0400
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081015104513.GA5543@mokona.greysector.net>
References: <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<200810121948.m9CJmL6j006990@laptop14.inf.utfsm.cl>
	<1223875666.3564.1441.camel@beck.corsepiu.local>
	<200810132042.m9DKgvDr012026@laptop14.inf.utfsm.cl>
	<1223955551.3029.219.camel@beck.corsepiu.local>
	<20081014093239.GA27002@mokona.greysector.net>
	<1224023771.18940.15.camel@moss-terrapins.epoch.ncsc.mil>
	<20081015104513.GA5543@mokona.greysector.net>
Message-ID: <1224083532.18940.39.camel@moss-terrapins.epoch.ncsc.mil>

On Wed, 2008-10-15 at 12:45 +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 15 October 2008 at 00:36, David P. Quigley wrote:
> > On Tue, 2008-10-14 at 11:32 +0200, Dominik 'Rathann' Mierzejewski wrote:
> > > SELinux is another subject for a good rant. Example: I created /var/log/dovecot,
> > > chowned it to dovecot user and configured it to put its logs there. Bang!
> > > SELinux denial. There's no easy way to fix it permanently either and SELinux
> > > tools documentation is akin to arcane knowledge. Unless you're familiar with
> > > all the terminology, you won't understand it.
> > > 
> > [snip]
> > 
> > Permanent fix which survives relabels.
> 
> And how do you know that? I can't find anything about it in man semanage.

The new documentation being written addresses this. Also I think Dan
rewrote the man pages recently so you will probably see changes to them
in the next version of Fedora.

> 
> > /usr/sbin/semanage fcontext -a -t dovecot_var_log_t /var/log/dovecot
> > /sbin/restorecon -v /var/log/dovecot
> 
> You mean there's no generic "allow-owner-to-write-in-their-own-directory"
> setting? That's just great. So how do I find out the magic incantation
> for another application?

There is no concept of "owner" in SELinux. The permission checks aren't
based on the identity of the user but rather the program that is being
executed. Trying to find out the correct type of a file is something
that is a little difficult at the moment. Once again this comes down to
documentation. It would be nice to have a list of each of the
applications covered by the policy, their types (listed by application)
and what their purposes is. If we had a document that said the targeted
policy covers dovecot and here are the types for it and their meaning it
would make life easier for people. This way you could have lookedup
dovecot and its logfile type and seen it was dovecot_var_log_t. I will
add this onto the list of things for the documentation writer to look
into but you are right as of the moment it is a little difficult to
figure it out.

However since that list doesn't currently exist (at least not that I
know of) the way I found the correct type for you was to load up the
loaded policy in apol and look for all the types that started with
dovecot. 

> 
> > SELinux documentation has been lacking in the past but Red Hat has hired
> > someone to write proper documentation for SELinux and it is getting
> > better every day. In an article on LWN I answered this question[1]. In
> > addition to this someone also linked the page below which contains quite
> > a bit of information that this person gathered when learning about
> > SELinux[2]. If you are willing to take the time to go through some of
> > his stuff you will realize SELinux really isn't as difficult as people
> > make it out to be, it's just that its not what they are use to. You
> > already know to set one set of permissions on the file when you create
> > it you just have to realize there is a type that needs to be set as
> > well.
> > 
> > [1]http://lwn.net/Articles/290168/
> > [2]http://equivocation.org/selinux
> 
> Ah. Isn't that obvious? An LWN article and some random website as the canonical
> source of SELinux documentation. Of course that's the first place anyone will
> look.
> 
> At least put it in policycoreutils package docs. There's nothing apart from
> manpages there and these are quite uninformative. Or put those articles (or
> link to them) on Fedora wiki. Please.

Well there is also SELinux by Example by the Tresys folks. That is
considered one of the canonical sources of information about SELinux.
Also there are the foundation papers on the NSA website you can read as
well. I may sound like a broken record with this but a lot of this stuff
will be addressed once the documentation writer releases the new
documentation.  The current state of documentation isn't really well
organized but its out there and hopefully once all the new docs are
released it will provide all the information people need in a
centralized place. If documentation is the main hurdle for people using
SELinux we hope that the new docs will make understanding SELinux easier
for all those who want to learn it. 

If there are any topics you would like to see in the documentation feel
free to send them to me and Ill add them onto the list for the
documentation writer. The current list can be seen at the URL below[1].
If you are interested in the current state of the documentation work you
can look at the SELinux mailing list archives for messages from Murray
McAllister[2]. He posted the initial drafts of the documentation and
there are numerous responses to his postings with addition information.
It's worth noting that these documents are still drafts so they might
not be 100% correct at the moment and will probably contain more
information in their finished form. 

Dave

[1]http://selinuxproject.org/page/Documentation_TODO
[2]http://marc.info/?l=selinux&w=2&r=1&s=McAllister&q=b



From a.badger at gmail.com  Wed Oct 15 15:33:56 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 15 Oct 2008 08:33:56 -0700
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <20081015083511.GG2795@free.fr>
References: <1224006301.23471.2.camel@truman>
	<20081014202906.GB2688@free.fr>	<48F54485.9090706@gmail.com>
	<20081015083511.GG2795@free.fr>
Message-ID: <48F60D64.1060400@gmail.com>

Patrice Dumas wrote:
> On Tue, Oct 14, 2008 at 06:16:53PM -0700, Toshio Kuratomi wrote:
>> I'm not on FESCo but I added some notes to the discussion page.  I tried
>> to steer clear of the portion of the decision that is up to FESCo and
>> stick with technical details.
> 
> Thanks for your comments. I incorporated 2 of them, but for the 'not
> possible currently to report bug against these packages' in fact I want
> to say that we do the same currently than when a release goes EOL. I
> don't know exactly how to convey more clearly the idea, though.
> 
I was able to open a bug against a package in  Fedora Core 2::
  https://bugzilla.redhat.com/show_bug.cgi?id=467067

So I guess I don't understand what this portion of the proposal means.

-Toshio

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

From tcallawa at redhat.com  Wed Oct 15 15:44:44 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 15 Oct 2008 11:44:44 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F60AD7.2020807@leemhuis.info>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info>
	<1224075473.12340.146.camel@aglarond.local>
	<48F60AD7.2020807@leemhuis.info>
Message-ID: <1224085484.3270.26.camel@localhost.localdomain>

On Wed, 2008-10-15 at 17:23 +0200, Thorsten Leemhuis wrote:
> Well, the world sometimes is not as good as we would like it 
> to be; we can try our best to fix it, but the task is really really
> big; 
> if you nevertheless try to do it you might forget the real goal you 
> aimed for in the beginning -- if you are not careful you might get 
> obsoleted and irrelevant on the way.

I wonder if a fraction of the effort put into building up a parallel
python branch was put into fixing Zope to work with modern python...
would we still be worried about compat-python?

There is a good chance that we'll be looking at Python 3 in a coming
Fedora release, so Zope will be two major python releases backwards, now
seems like a great time for interested parties to work towards getting
Zope working with Python 2.6 (at least).

~spot



From kevin.kofler at chello.at  Wed Oct 15 16:03:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 15 Oct 2008 16:03:55 +0000 (UTC)
Subject: First steps of the transition from Livna to RPM Fusion begins
	now for livna-devel users!
References: <48F4C067.90308@leemhuis.info>	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>	<48F5BFAE.3030406@leemhuis.info>	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>	<48F5C643.1080709@leemhuis.info>
	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
	<48F60BF7.1020504@nicubunu.ro>
Message-ID: <loom.20081015T160227-345@post.gmane.org>

Nicu Buculei <nicu_fedora <at> nicubunu.ro> writes:
> Well, I rebuilt the src.rpm from rpmfusion for the latest rawhide, it is 
> able so see APs, can connect to the unencrypted ones but seems to fail 
> for WPA-PSK.

If it's like the previous drivers released by Ralink (the old rt2400, rt2500 
and rt2570 legacy drivers), you have to use special iwpriv commands to use WPA, 
it doesn't support wpa_supplicant (and thus NetworkManager) for WPA.

        Kevin Kofler



From pbrobinson at gmail.com  Wed Oct 15 16:25:21 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 15 Oct 2008 17:25:21 +0100
Subject: First steps of the transition from Livna to RPM Fusion begins
	now for livna-devel users!
In-Reply-To: <loom.20081015T160227-345@post.gmane.org>
References: <48F4C067.90308@leemhuis.info>
	<5256d0b0810150243n524a1c22gb884a1224ac687d1@mail.gmail.com>
	<48F5BFAE.3030406@leemhuis.info>
	<5256d0b0810150313g3f4f16bek96650a8ddb159210@mail.gmail.com>
	<48F5C643.1080709@leemhuis.info>
	<5256d0b0810150409x653f0a12kcc2dc791cae27695@mail.gmail.com>
	<48F60BF7.1020504@nicubunu.ro>
	<loom.20081015T160227-345@post.gmane.org>
Message-ID: <5256d0b0810150925t40c84c81j40370b15b29d2d9d@mail.gmail.com>

On Wed, Oct 15, 2008 at 5:03 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Nicu Buculei <nicu_fedora <at> nicubunu.ro> writes:
>> Well, I rebuilt the src.rpm from rpmfusion for the latest rawhide, it is
>> able so see APs, can connect to the unencrypted ones but seems to fail
>> for WPA-PSK.
>
> If it's like the previous drivers released by Ralink (the old rt2400, rt2500
> and rt2570 legacy drivers), you have to use special iwpriv commands to use WPA,
> it doesn't support wpa_supplicant (and thus NetworkManager) for WPA.

I read some where this one has to be compiled with different options
depending on whether you want WEP or WPA (lovely!!) but then I've also
seen a 1.8.0 release which may well fix the issue with the WPA.
Release notes here mentioned here.

https://bugs.launchpad.net/linux/+bug/210725/comments/62

Peter



From a.badger at gmail.com  Wed Oct 15 16:37:57 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 15 Oct 2008 09:37:57 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <200810151450.24406.opensource@till.name>
References: <48F280FA.8010507@shmuelhome.mine.nu>	<20081015121350.GB3091@free.fr>	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<200810151450.24406.opensource@till.name>
Message-ID: <48F61C65.5090600@gmail.com>

Till Maas wrote:
> On Wed October 15 2008, Josh Boyer wrote:
> 
>> (And bug reports, blah blah blah.)
> 
> If the ACLs for the EOL releases are cleared, the maintainers of the supported 
> packages will not get any bug reports (unless Bugzilla does not support this 
> of course). Also the EOL-team can triage the bugs for the supported release 
> to avoid bugging the maintainers.
> 
I think we're stretching beyond bugzilla's capabilities but I'd be happy
to be proved wrong :-)

I don't think bugzilla has separation of Product-versions so there's no
way to assign different people to Fedora-10 and Fedora-7.

Like Fedora Legacy we could have a separate Fedora Legacy/LTS Product...
but then, how do we guide people to use that Product when their machine
suddenly transitions from Fedora-Current-Release to Fedora-Legacy-Release?

-Toshio

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

From jspaleta at gmail.com  Wed Oct 15 16:48:55 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 15 Oct 2008 08:48:55 -0800
Subject: reviving Fedora Legacy
In-Reply-To: <20081015074228.GB2795@free.fr>
References: <20081012212120.GD2688@free.fr> <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
Message-ID: <604aa7910810150948u64c866fax88e33f95d0012861@mail.gmail.com>

On Tue, Oct 14, 2008 at 11:42 PM, Patrice Dumas <pertusus at free.fr> wrote:
> The aim here is not to present the _appearance_ of a distro with
> security updates but give the choice to the user either to upgrade or to
> stick with a distro where some packages will not be maintained.
> Something along "That distro is EOL. Upgrade before you get hacked.
> Alternatively, and at your own risk, you can enable a repository where
> some packages are updated on a volunteer basis, but some packages aren't
> maintained anymore."
>
> With a page listing which packages are still supported.

I still want to see more affirmative scenarios on how old branches are
to be closed out..eventually.  If you can not decide and publish a
pre-determined EOL date, then you will have to measure something to
determine when to close out the branch. Branches must have an end
scenario.. we can not make an open ended resource commitment to each
and every Fedora release from now into the future.  What you are
setting up is a situation were all branches remain open forever on the
off-chance that someone might want to pick up and maintain a package
15 years from now. Not acceptable.  If these branches are going to
remain open based on interest..then we'll need to measure that
interest and set a bar to meet that makes sense as a determining point
to start shutting down the branch.

-jef



From opensource at till.name  Wed Oct 15 16:51:33 2008
From: opensource at till.name (Till Maas)
Date: Wed, 15 Oct 2008 18:51:33 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F61C65.5090600@gmail.com>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<200810151450.24406.opensource@till.name> <48F61C65.5090600@gmail.com>
Message-ID: <200810151851.48595.opensource@till.name>

On Wed October 15 2008, Toshio Kuratomi wrote:
> Till Maas wrote:
> > On Wed October 15 2008, Josh Boyer wrote:
> >> (And bug reports, blah blah blah.)
> >
> > If the ACLs for the EOL releases are cleared, the maintainers of the
> > supported packages will not get any bug reports (unless Bugzilla does not
> > support this of course). Also the EOL-team can triage the bugs for the
> > supported release to avoid bugging the maintainers.
>
> I think we're stretching beyond bugzilla's capabilities but I'd be happy
> to be proved wrong :-)
>
> I don't think bugzilla has separation of Product-versions so there's no
> way to assign different people to Fedora-10 and Fedora-7.

I always feared this. In case this is true and initialCC cannot be configured 
differently for different Fedora versions, too, (which I assume is 
unrealistic if bugzilla cannot distinguish versions for assignees) imho the 
packageDB UI should reflect this.

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/20081015/040d1b5c/attachment.sig>

From pertusus at free.fr  Wed Oct 15 17:00:04 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 19:00:04 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224085484.3270.26.camel@localhost.localdomain>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>
	<48F59905.50206@linux-kernel.at> <48F5A172.9000405@leemhuis.info>
	<1224075473.12340.146.camel@aglarond.local>
	<48F60AD7.2020807@leemhuis.info>
	<1224085484.3270.26.camel@localhost.localdomain>
Message-ID: <20081015170003.GA2679@free.fr>

On Wed, Oct 15, 2008 at 11:44:44AM -0400, Tom spot Callaway wrote:
> 
> I wonder if a fraction of the effort put into building up a parallel
> python branch was put into fixing Zope to work with modern python...
> would we still be worried about compat-python?

I don't know about the amount of work in both caes, but the type of 
work is very different and cannot necessarily be undertaken by the same
people.

--
Pat



From pekkas at netcore.fi  Wed Oct 15 17:00:47 2008
From: pekkas at netcore.fi (Pekka Savola)
Date: Wed, 15 Oct 2008 20:00:47 +0300 (EEST)
Subject: reviving Fedora Legacy
In-Reply-To: <1224083908.3029.560.camel@beck.corsepiu.local>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
Message-ID: <alpine.LRH.2.00.0810151952370.28934@netcore.fi>

On Wed, 15 Oct 2008, Ralf Corsepius wrote:
> If this all shall make sense and remain unbureaucratic and efficient,
> there must not be any "other repo" nor "other VCS" nor distrust.
>
> Seems to me as if some people around here are resistant to learning?

Learning what?

It seems folks proposing this madness failed to learn from how Fedora 
Legacy failed.

I was there.  During the last year or so (when the updates were still 
being cranked out regularly), there were about 2 or 3 folks who would 
review proposed updates or try to put any significant work in it.

Unless we get a list of 20 maintainer-capable people willing to spend 
time in doing security fixes (for _any_ package, not just their pet 
packages), we shouldn't even be wasting time discussing this.

Is there such a list?  If you wish to continue with this, I'd suggest 
you start collecting one at a wiki somewhere, where people could sign 
and tell the terms under which they would be interested in 
contributing.

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



From pertusus at free.fr  Wed Oct 15 17:08:41 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 19:08:41 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <alpine.LRH.2.00.0810151952370.28934@netcore.fi>
References: <loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
Message-ID: <20081015170841.GB2679@free.fr>

On Wed, Oct 15, 2008 at 08:00:47PM +0300, Pekka Savola wrote:
>
> I was there.  During the last year or so (when the updates were still  
> being cranked out regularly), there were about 2 or 3 folks who would  
> review proposed updates or try to put any significant work in it.

Now there won't be a strict need for reviewers. After some time in
bodhi things will get pushed, as it is the case in releases. Hopefully
people will review the updates. As I said repeatedly, we won't ask more
QA than what is in fedora release, and therefore not the amount that was
in legacy.

> Unless we get a list of 20 maintainer-capable people willing to spend  
> time in doing security fixes (for _any_ package, not just their pet  
> packages), we shouldn't even be wasting time discussing this.
>
> Is there such a list?  If you wish to continue with this, I'd suggest  
> you start collecting one at a wiki somewhere, where people could sign  
> and tell the terms under which they would be interested in contributing.

The conditions of such a project is what is discussed here. Having
fedora infrastructure and fedora rules used or not is, in my opinion the
most important item for potential contributors. I wanted to contribute
to legacy but was deterred by the fact that another infra with another
set of rules was used. And other people told the same.

--
Pat



From kevin.kofler at chello.at  Wed Oct 15 17:09:11 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 15 Oct 2008 17:09:11 +0000 (UTC)
Subject: reviving Fedora Legacy
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
Message-ID: <loom.20081015T170547-730@post.gmane.org>

Pekka Savola <pekkas <at> netcore.fi> writes:
> I was there.  During the last year or so (when the updates were still 
> being cranked out regularly), there were about 2 or 3 folks who would 
> review proposed updates or try to put any significant work in it.

With no QA to worry about, that might even be enough.

And less bureaucracy, no separate infrastructure to worry about and ability to 
reuse existing Fedora sponsorship instead of going through yet another 
community process might help attract more packagers. (I intentionally don't use 
the word "maintainers" here because I think more of a "bazaar" model where 
whoever feels able to fix a given security hole can do it, only membership in 
uberpackager (or maybe even only packager) required.)

        Kevin Kofler



From pertusus at free.fr  Wed Oct 15 17:12:50 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 19:12:50 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <604aa7910810150948u64c866fax88e33f95d0012861@mail.gmail.com>
References: <20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<604aa7910810150948u64c866fax88e33f95d0012861@mail.gmail.com>
Message-ID: <20081015171250.GC2679@free.fr>

On Wed, Oct 15, 2008 at 08:48:55AM -0800, Jeff Spaleta wrote:
> 
> I still want to see more affirmative scenarios on how old branches are
> to be closed out..eventually.  If you can not decide and publish a
> pre-determined EOL date, then you will have to measure something to
> determine when to close out the branch. Branches must have an end
> scenario.. we can not make an open ended resource commitment to each
> and every Fedora release from now into the future.  What you are
> setting up is a situation were all branches remain open forever on the
> off-chance that someone might want to pick up and maintain a package
> 15 years from now. Not acceptable.  If these branches are going to

No, I have proposed 3 or 5 years, and currently only F8, as an
experimental proof of concept and proof of interest. In the scope of
this we coould then set up rules for closing branches, try to see what
is th erates of updates, the coverage... but for now I just want to get
it started as an experimental F8 only project to see if there is
interest or not, set up a SIG and discuss the other points.

I wouldn't be bothered if FESCo said, you only have 18 months, as well.

--
Pat



From pertusus at free.fr  Wed Oct 15 17:18:41 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 19:18:41 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F61C65.5090600@gmail.com>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<200810151450.24406.opensource@till.name>
	<48F61C65.5090600@gmail.com>
Message-ID: <20081015171841.GD2679@free.fr>

On Wed, Oct 15, 2008 at 09:37:57AM -0700, Toshio Kuratomi wrote:
> > 
> I think we're stretching beyond bugzilla's capabilities but I'd be happy
> to be proved wrong :-)
> 
> I don't think bugzilla has separation of Product-versions so there's no
> way to assign different people to Fedora-10 and Fedora-7.

That's annoying. Is it something we have to worry about in Fedora and
EPEL proper, that is, would we like to be able to separate owners for
different releases, or is it something we need to worry about only if
infrastructure is kept open for old branches?

> Like Fedora Legacy we could have a separate Fedora Legacy/LTS Product...
> but then, how do we guide people to use that Product when their machine
> suddenly transitions from Fedora-Current-Release to Fedora-Legacy-Release?

I don't think there should ever be a sudden and unnoticed transition. I
like what Jesse proposed with PackageKit for the long term, and in the
short term people would have to manually install a yum config file
(maybe part of a rpm, but manually).

--
Pat



From pertusus at free.fr  Wed Oct 15 17:23:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 19:23:11 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <48F60D64.1060400@gmail.com>
References: <1224006301.23471.2.camel@truman> <20081014202906.GB2688@free.fr>
	<48F54485.9090706@gmail.com> <20081015083511.GG2795@free.fr>
	<48F60D64.1060400@gmail.com>
Message-ID: <20081015172310.GE2679@free.fr>

On Wed, Oct 15, 2008 at 08:33:56AM -0700, Toshio Kuratomi wrote:
> > 
> I was able to open a bug against a package in  Fedora Core 2::
>   https://bugzilla.redhat.com/show_bug.cgi?id=467067
> 
> So I guess I don't understand what this portion of the proposal means.

That's because I don't understand how a bugzilla owner is selected, and
what happens in old branches in the regular case. I am not sure that it
is the right place to discuss it, is there a documentation somewhere? If
not I will certainly ask on the infrastructure list.

--
Pat



From smooge at gmail.com  Wed Oct 15 17:25:18 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 15 Oct 2008 11:25:18 -0600
Subject: reviving Fedora Legacy
In-Reply-To: <20081015170841.GB2679@free.fr>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
Message-ID: <80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>

On Wed, Oct 15, 2008 at 11:08 AM, Patrice Dumas <pertusus at free.fr> wrote:
> On Wed, Oct 15, 2008 at 08:00:47PM +0300, Pekka Savola wrote:
>>
>> I was there.  During the last year or so (when the updates were still
>> being cranked out regularly), there were about 2 or 3 folks who would
>> review proposed updates or try to put any significant work in it.
>
> Now there won't be a strict need for reviewers. After some time in
> bodhi things will get pushed, as it is the case in releases. Hopefully
> people will review the updates. As I said repeatedly, we won't ask more
> QA than what is in fedora release, and therefore not the amount that was
> in legacy.
>

I think its this which is causing people to react in fear to the
proposal. The large amount of uncertainty ( how long, what to do with
bad vulnerabilities not getting fixed, no knowledge of the quality of
the package, etc) is causing doubt. And this is the sort of FUD that
comes about because something is too amorphous and isn't getting
fleshed out.

1) Dealing with the fear of hurting the Fedora brand. Come up with a
new brand for this: Long Term Blue Shoes (or something).
2) Dealing with the various uncertainties:
  A. Get a list of people dedicated to this
  B. Put out how long you are extending it:  1 extra year.
  C. How to vet package quality/deal with bad trees.
  D. What stuff is staying 'static/slow-moving' and what gets whatever
is in the latest Fedora?
3) Dealing with the Doubt.
  A. Get the SIG organized
  B. Build a test project of supporting Fedora 9 for 6 extra months.
        This allows you time to get procedures, infrastructure, and
whatever else needed.
  C. Follow your plans
  D. Report how it worked.
  E. Fix what didn't work and repeat.

If you can do that you will have a working project that will show that
LTS is possible and a viable proposition that some place like
Wikipedia or Brazil would trust their computers on.

[And yes, you are going to need to deal with infrastructure. Disk
space, cpu cycles, memory and power is not 'cheap' as much as people
think it is. Extra build boxes will be needed, extra disk space to
store stuff, and extra cpu cycles as Fedora's current infrastructure
is built on the assumption that it only needs to deal with X releases
for Y time. Adding to X and Y means more equipment needed. It will
also mean that someone's on the team are going ot have to focus on the
infrastructure problems as that addition also increases the number of
people needed to watch builds, etc.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From jkeating at redhat.com  Wed Oct 15 17:47:15 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 15 Oct 2008 10:47:15 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
Message-ID: <1224092835.4122.45.camel@luminos.localdomain>

On Wed, 2008-10-15 at 11:25 -0600, Stephen John Smoogen wrote:
> 
> [And yes, you are going to need to deal with infrastructure. Disk
> space, cpu cycles, memory and power is not 'cheap' as much as people
> think it is. Extra build boxes will be needed, extra disk space to
> store stuff, and extra cpu cycles as Fedora's current infrastructure
> is built on the assumption that it only needs to deal with X releases
> for Y time. Adding to X and Y means more equipment needed. It will
> also mean that someone's on the team are going ot have to focus on the
> infrastructure problems as that addition also increases the number of
> people needed to watch builds, etc.

along with infrastructure, you need a release engineer.  Somebody who's
going to babysit the collections, do buildroot overrides to build chains
of packages, do package signing, urge (a) bodhi into pushing the
updates, making sure they get rsynced properly, dealing with bug reports
about broken deps, so on and so forth.  I say this, because I'm not
about to volunteer to do that work for you.  I say this also, because
trying to bring somebody in to do these things on the "LTS" section, but
isolate that person from the normal section is going to be difficult, if
we have to go that route.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081015/3b0588da/attachment.sig>

From ivazqueznet at gmail.com  Wed Oct 15 18:08:12 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 15 Oct 2008 14:08:12 -0400
Subject: compat-python, Zope...
In-Reply-To: <1224085484.3270.26.camel@localhost.localdomain>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>
	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info>
	<1224075473.12340.146.camel@aglarond.local>
	<48F60AD7.2020807@leemhuis.info>
	<1224085484.3270.26.camel@localhost.localdomain>
Message-ID: <1224094092.13861.92.camel@ignacio.lan>

On Wed, 2008-10-15 at 11:44 -0400, Tom "spot" Callaway wrote:
> On Wed, 2008-10-15 at 17:23 +0200, Thorsten Leemhuis wrote:
> > Well, the world sometimes is not as good as we would like it 
> > to be; we can try our best to fix it, but the task is really really
> > big; 
> > if you nevertheless try to do it you might forget the real goal you 
> > aimed for in the beginning -- if you are not careful you might get 
> > obsoleted and irrelevant on the way.
> 
> I wonder if a fraction of the effort put into building up a parallel
> python branch was put into fixing Zope to work with modern python...
> would we still be worried about compat-python?

It's a lot easier to change "make install" in a spec file to "make
altinstall" than it is to rewrite a bytecode interpreter/analyzer. So
unless the fraction ends up being much, much greater than 1, yes.

Not that I'm saying it shouldn't be done of course; it's just far from
trivial.

-- 
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/20081015/fb2ba3f1/attachment.sig>

From a.badger at gmail.com  Wed Oct 15 18:23:44 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 15 Oct 2008 11:23:44 -0700
Subject: compat-python, Zope...
In-Reply-To: <1224085484.3270.26.camel@localhost.localdomain>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>	<48F5A172.9000405@leemhuis.info>	<1224075473.12340.146.camel@aglarond.local>	<48F60AD7.2020807@leemhuis.info>
	<1224085484.3270.26.camel@localhost.localdomain>
Message-ID: <48F63530.7010806@gmail.com>

Tom "spot" Callaway wrote:
> On Wed, 2008-10-15 at 17:23 +0200, Thorsten Leemhuis wrote:
>> Well, the world sometimes is not as good as we would like it 
>> to be; we can try our best to fix it, but the task is really really
>> big; 
>> if you nevertheless try to do it you might forget the real goal you 
>> aimed for in the beginning -- if you are not careful you might get 
>> obsoleted and irrelevant on the way.
> 
> I wonder if a fraction of the effort put into building up a parallel
> python branch was put into fixing Zope to work with modern python...
> would we still be worried about compat-python?
> 
As long as we're speculating without knowledge, I'd say that more effort
would have to be spent on porting Zope and gettign the patches
integrated upstream than packaging compat-python.

Maintaining is another story, though :-).  So, although I'm very glad
that rpmfusion has compat-python packages, I think it is reasonable to
decide not to have it in Fedora.

Note that Zope3 developers tell me that they're making Zope more modular
(on the order of 100+ packages) which means that getting started on
working on Zope3's code (and porting it to new python versions) will get
easier but packaging it will get harder.

> There is a good chance that we'll be looking at Python 3 in a coming
> Fedora release, so Zope will be two major python releases backwards, now
> seems like a great time for interested parties to work towards getting
> Zope working with Python 2.6 (at least).
> 
I've been looking more closely at Python 3 lately for unicode problems
we're going to trip over.  Python-3.0rc1, at least, would cause *huge*
problems in all sorts of random places within our codebase.  Hopefully
things will be better by python-3.1 but a lot of the issues need to be
pushed from other people with a Unix/Linux or distro-centric viewpoint.
 A few voices in the wilderness are not enough.  It would be great if we
had more upstream presence in all aspects of python.

Python-2.6, as a transition between 2.x and 3.x will be easier for us to
port to but that does mean that we'll have more porting work to do for
the python-3.x move.

-Toshio

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

From a.badger at gmail.com  Wed Oct 15 18:30:35 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 15 Oct 2008 11:30:35 -0700
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <20081015172310.GE2679@free.fr>
References: <1224006301.23471.2.camel@truman>
	<20081014202906.GB2688@free.fr>	<48F54485.9090706@gmail.com>
	<20081015083511.GG2795@free.fr>	<48F60D64.1060400@gmail.com>
	<20081015172310.GE2679@free.fr>
Message-ID: <48F636CB.2030203@gmail.com>

Patrice Dumas wrote:
> On Wed, Oct 15, 2008 at 08:33:56AM -0700, Toshio Kuratomi wrote:
>> I was able to open a bug against a package in  Fedora Core 2::
>>   https://bugzilla.redhat.com/show_bug.cgi?id=467067
>>
>> So I guess I don't understand what this portion of the proposal means.
> 
> That's because I don't understand how a bugzilla owner is selected, and
> what happens in old branches in the regular case. I am not sure that it
> is the right place to discuss it, is there a documentation somewhere? If
> not I will certainly ask on the infrastructure list.
> 
No documentation that I know of.  This might help, though:  In our
bugzilla instance, there's a 'Fedora' product and a 'Fedora EPEL'
product.  You can have separate owners, cclists, etc per product.  We
take the owner from the "Fedora-devel" branch in the pkgdb and "Fedora
EPEL-5" branch for each of those products.

Bugzilla also has versions for each product.  So Fedora currently has
versions 1, 2, 3, 4, 5, 6, 7, 8, 9, and devel.  Versions cannot have
separate owners, cclists, etc.  So if you open a bug against a package
(component in bugzilla) it will get the same owner whether it's against
Fedora-2 or Fedora-devel.  This is also why I don't think bugzilla has
the ability to close bugs for old releases of Fedora (although, I'm not
a bugzilla guru so it could be possible.)

-Toshio

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

From pertusus at free.fr  Wed Oct 15 18:57:58 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 20:57:58 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
References: <20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
Message-ID: <20081015185758.GG2679@free.fr>

On Wed, Oct 15, 2008 at 11:25:18AM -0600, Stephen John Smoogen wrote:
> On Wed, Oct 15, 2008 at 11:08 AM, Patrice Dumas <pertusus at free.fr> wrote:
> 
> I think its this which is causing people to react in fear to the
> proposal. The large amount of uncertainty ( how long, what to do with
> bad vulnerabilities not getting fixed, no knowledge of the quality of
> the package, etc) is causing doubt. And this is the sort of FUD that
> comes about because something is too amorphous and isn't getting
> fleshed out.

There are 2 reasons why I don't want to flesh it too much. One is
because I think it is an iterative process, we don't need much to start
and we'll see how it goes, and in the start it won't be public, only
something experimental. The other reason is that I see a lot of over
confidence in fedora releases although fedora cannot promise 
anything: some guarantes that Fedora releases cannot make are asked for
for that project, I really can't understand why.

> 1) Dealing with the fear of hurting the Fedora brand. Come up with a
> new brand for this: Long Term Blue Shoes (or something).

I proposed UAEL. Update After End of Life. But I don't care a bit about
the name, as long as there is one and that it is clear that it is not
under the fedora brand.

> 2) Dealing with the various uncertainties:
>   A. Get a list of people dedicated to this

I want to do this as soon as possible, but not before there is a formal
agreement that it will be possible to use fedora infrastructure and
rules, because it completly determines if people are interested. I won't
be, for example, if I have to set up a new infrastructure.

>   B. Put out how long you are extending it:  1 extra year.

In my opinion, in the first experimental phase this is not very
important. After some thinking I think that 3 years for selected
releases and no more than 1 year for others may be right, but I think
that this should better be determined by discussing within the SIG and
with FESCo for advice and guidance and with infras for the available 
resources.

>   C. How to vet package quality/deal with bad trees.

Package quality will be checked using the current fedora QA practices
(well the practices at the time a branch is EOLed).
What do you mean with 'bad tree'? A whole release? For a whole release,
I think that first it should be possible to see if there is somebody
interested in a given branch for a given package, and if there is a
package of @core or @base that is not maintained the branch should be
shut (that was basically the UAEL proposal).

>   D. What stuff is staying 'static/slow-moving' and what gets whatever
> is in the latest Fedora?

For this one my opinion is that the whole project should be on the side
of the stability. However if the packager thinks that there won't be
major disruptions by using what is in the oldest fedora, and it lowers
his workload he can do it. In fact I think that something that should be
discussed within the SIG is how hard we try to keep a possible upgrade
path toward the next RHEL/EPEL. If there is a majority to think that it
is important, I think that we should try (without impairing the project)
to do that. Also if it fixes grave bugs and back porting is no easy.

> 3) Dealing with the Doubt.
>   A. Get the SIG organized

That's th efirst thing to do if the basics are agreed.

>   B. Build a test project of supporting Fedora 9 for 6 extra months.
>         This allows you time to get procedures, infrastructure, and
> whatever else needed.

The current plan is more for F8. But indeed this is the plan, begin
first with one branch, see if it works both on the infrastructure and 
packaging side, and stop if not (maybe before 6 months...).

>   C. Follow your plans
>   D. Report how it worked.
>   E. Fix what didn't work and repeat.

That's the plan.

> [And yes, you are going to need to deal with infrastructure. Disk
> space, cpu cycles, memory and power is not 'cheap' as much as people
> think it is. Extra build boxes will be needed, extra disk space to

I am not sure that cpu cycles, memory and power will be very
problematic, since we really should be on the side of stability and, in
contrary to EPEL the pacakges are already built. Moreover this is a one
time cost. Bandwidth and disk cost is another story, especially since it
is replicated in mirrors.

> store stuff, and extra cpu cycles as Fedora's current infrastructure
> is built on the assumption that it only needs to deal with X releases
> for Y time. Adding to X and Y means more equipment needed. It will
> also mean that someone's on the team are going ot have to focus on the
> infrastructure problems as that addition also increases the number of
> people needed to watch builds, etc.

Indeed. I am ready to face that the project uses too much resources, but
without trying one cannot know.

--
Pat



From bruno at wolff.to  Wed Oct 15 19:08:55 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 15 Oct 2008 14:08:55 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <48F5E89C.4040005@gmail.com>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<1224073149.3029.550.camel@beck.corsepiu.local>
	<20081015124549.GB27658@yoda.jdub.homelinux.org>
	<48F5E89C.4040005@gmail.com>
Message-ID: <20081015190855.GA9388@wolff.to>

On Wed, Oct 15, 2008 at 07:57:00 -0500,
  Les Mikesell <lesmikesell at gmail.com> wrote:
>
> With disruptive changes that make it impossible to know if your hardware  
> or applications will still work after an upgrade - and what is the  
> alternative if they don't?

Don't upgrade and deal with security problems yourself. I ran Redhat 6.2 on
on a network connected system for several years after support ended. For
critical network facing services, I build them from up to date source.
Other stuff stayed the way it was. Later I was stuck at FC5 for a while
past EOL because of a kernel bug and kept an eye on security bug fixes to see
if I needed to update any packages to fix a problem that would apply to me.



From vonbrand at inf.utfsm.cl  Wed Oct 15 19:15:27 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 15 Oct 2008 16:15:27 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <48F49A4F.8010900@gmail.com>
References: <loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
	<20081013103531.GA3087@free.fr>
	<20081013113021.GA27573@orient.maison.lan>
	<20081013113234.GD3087@free.fr>
	<200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>
	<1223989050.3029.321.camel@beck.corsepiu.local>
	<48F49A4F.8010900@gmail.com>
Message-ID: <200810151915.m9FJFRiK011370@laptop14.inf.utfsm.cl>

Les Mikesell <lesmikesell at gmail.com> wrote:

[...]

> I don't think I'd use 'standard' to describe something unique and
> proprietary, but there is something to be said about an OS that runs
> for years without reinstalling and works with vendor provided drivers
> that also don't need to be reinstalled every few weeks.

You must have been using a different strand of that stuff than I got...
-- 
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 2340000       Fax:  +56 32 2797513



From behdad at behdad.org  Wed Oct 15 19:10:23 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 15 Oct 2008 15:10:23 -0400
Subject: Fontconfig rules installation guidelines change proposal
In-Reply-To: <1223820245.9402.18.camel@arekh.okg>
References: <1223820245.9402.18.camel@arekh.okg>
Message-ID: <48F6401F.3040301@behdad.org>

Nicolas Mailhot wrote:
> Hi all,
> 
> I've queued the following small guideline change proposal for FPC
> consideration:
> 
> http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction_(fontconfig)
> 
> Please add comments, reactions and corrections in the wiki.

Hi Nicolas,

I like the direction of it.

The idea of having separate conf.avail and conf.d is that sysadmins can
symlink/unlink entries into conf.d to enable/disable configuration for their
system.  This would only work if upgrading fontconfig/fonts rpms does not
reinstate the unlinked symlink.  However, last time I checked this was not
working correctly.  Can you check this first?

Thanks,

behdad

> Regards,



From pertusus at free.fr  Wed Oct 15 19:25:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 21:25:34 +0200
Subject: Plan for tomorrows (20081014) FESCO meeting
In-Reply-To: <48F636CB.2030203@gmail.com>
References: <1224006301.23471.2.camel@truman> <20081014202906.GB2688@free.fr>
	<48F54485.9090706@gmail.com> <20081015083511.GG2795@free.fr>
	<48F60D64.1060400@gmail.com> <20081015172310.GE2679@free.fr>
	<48F636CB.2030203@gmail.com>
Message-ID: <20081015192534.GH2679@free.fr>

On Wed, Oct 15, 2008 at 11:30:35AM -0700, Toshio Kuratomi wrote:
> > 
> No documentation that I know of.  This might help, though:  In our
> bugzilla instance, there's a 'Fedora' product and a 'Fedora EPEL'
> product.  You can have separate owners, cclists, etc per product.  We
> take the owner from the "Fedora-devel" branch in the pkgdb and "Fedora
> EPEL-5" branch for each of those products.

That's a bit odd that it doesn't match what is in packagedb. And this is
definitely a problem for the project of keeping infra open for old
branches.

> Bugzilla also has versions for each product.  So Fedora currently has
> versions 1, 2, 3, 4, 5, 6, 7, 8, 9, and devel.  Versions cannot have
> separate owners, cclists, etc.  So if you open a bug against a package
> (component in bugzilla) it will get the same owner whether it's against
> Fedora-2 or Fedora-devel.  This is also why I don't think bugzilla has
> the ability to close bugs for old releases of Fedora (although, I'm not
> a bugzilla guru so it could be possible.)

Has somebody ever noticed that it was that way, and is it considered to
be an issue in fedora or EPEL space? To me this is at least unfortunate,
since one cannot have a packager responsible for rawhide while another
is responsible for releases. It is not really problematic however since
all the co-maintainers should be aware of the bugs and watch others.

But it is definitively an issue for my proposal. In particular it means
that orphaning old releases won't cause bugs not to be directed toward a
maintainer (such that it is not that important in fact). In the long
term, and if fedora finds the project useful, I think that adding a new
component would be the right thing to do. For the very beginning and the
very experimental phase it is not an issue either, since there would be
no reason to report bugs. But for the period between those 2, this is
definitely problematic. Because we want to have an idea how bugs are
handled, and we don't want to bother regular release packagers.

--
Pat



From vonbrand at inf.utfsm.cl  Wed Oct 15 19:29:07 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 15 Oct 2008 16:29:07 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081014145650.GB3126@free.fr>
References: <5s74s5x9q4.ln2@ppp1053.in.ipex.cz>
	<20081010153504.GE3236@free.fr> <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
	<200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
	<20081014145650.GB3126@free.fr>
Message-ID: <200810151929.m9FJT7NH011508@laptop14.inf.utfsm.cl>

Patrice Dumas <pertusus at free.fr> wrote:
> On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:

[...]

> > Fedora Legacy foundered because everybody said they wanted it, almost
> > nobody was willing to do the (hard!) work, and in the end the "many users"
> > didn't materialize either.

> The work in the scope of this project will be less hard than what was
> done in the scope of legacy,

I just can't imagine why it would be less; if anything, much more (there
are more packages today, and the "basic stuff that must work" is getting
more and more).

>                              since there will be less QA, in fact the
> same amount than in fedora.

Right. And everybody complaints that Fedora isn't doing enough here, and
discussions on how to make it work better are common...
-- 
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 2340000       Fax:  +56 32 2797513



From pertusus at free.fr  Wed Oct 15 19:34:27 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 21:34:27 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810151929.m9FJT7NH011508@laptop14.inf.utfsm.cl>
References: <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
	<200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
	<20081014145650.GB3126@free.fr>
	<200810151929.m9FJT7NH011508@laptop14.inf.utfsm.cl>
Message-ID: <20081015193427.GI2679@free.fr>

On Wed, Oct 15, 2008 at 04:29:07PM -0300, Horst H. von Brand wrote:
> Patrice Dumas <pertusus at free.fr> wrote:
> > On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:
> 
> > The work in the scope of this project will be less hard than what was
> > done in the scope of legacy,
> 
> I just can't imagine why it would be less; if anything, much more (there
> are more packages today, and the "basic stuff that must work" is getting
> more and more).

Maybe on the packaging side, that is more packages to maintain (the
minimal target being @code + @base in my opinion, but this can be
discussed), but less on the QA and process side. Moreover now that core
is opened it means that contributors may be more involved in core
packages and may have done merge reviews (at least it is my case) 
while for legacy people started with packages they had no
reason to know.

> >                              since there will be less QA, in fact the
> > same amount than in fedora.
> 
> Right. And everybody complaints that Fedora isn't doing enough here, and
> discussions on how to make it work better are common...

We'll follow. But I don't think that fedora will ever get near what had
to be done in legacy.

--
Pat



From jspaleta at gmail.com  Wed Oct 15 19:48:18 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 15 Oct 2008 11:48:18 -0800
Subject: reviving Fedora Legacy
In-Reply-To: <20081015185758.GG2679@free.fr>
References: <20081015074228.GB2795@free.fr> <20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<20081015185758.GG2679@free.fr>
Message-ID: <604aa7910810151248w419ad975qea649cdb672a7da2@mail.gmail.com>

On Wed, Oct 15, 2008 at 10:57 AM, Patrice Dumas <pertusus at free.fr> wrote:
> There are 2 reasons why I don't want to flesh it too much. One is
> because I think it is an iterative process, we don't need much to start
> and we'll see how it goes, and in the start it won't be public, only
> something experimental.

I've no problem with interested people making an experimental stab at
this.  if the intent is to have FESCo revisit this in like a year or
something, try to setup the metrics or milestones now that will form
the basis of that future progress review.

I will say however, that if the initial mission and goals for a SIG
are too ill-defined you may have a problem harnessing manpower and
have everyone pulling the effort forward in a common direction.  Just
be wary of that.  As you move forward and create a SIG, I'm going to
need something concrete enough as a statement so when I'm talking to
people "outside" about their interests I know whether or not to point
them to this SIG as a place to dig in and help.  The last thing I want
to do is encourage people with dissimilar needs/interest to sit in a
room together and have them fight with each other.

> In fact I think that something that should be
> discussed within the SIG is how hard we try to keep a possible
> upgrade path toward the next RHEL/EPEL.

That statement right there, is probably simultaneously the hardest and
potentially rewarding objective that an extended update effort could
attempt to achieve.  And its a far different thing to state that as an
objective to work towards over just saying maintainers can do whatever
they want.  But to do it well, would probably require a consensual
understanding by Red Hat and the external community that such an
upgrade path was a valuable thing to work towards together.

-jef



From pertusus at free.fr  Wed Oct 15 20:13:51 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 15 Oct 2008 22:13:51 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <604aa7910810151248w419ad975qea649cdb672a7da2@mail.gmail.com>
References: <20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<20081015185758.GG2679@free.fr>
	<604aa7910810151248w419ad975qea649cdb672a7da2@mail.gmail.com>
Message-ID: <20081015201351.GJ2679@free.fr>

On Wed, Oct 15, 2008 at 11:48:18AM -0800, Jeff Spaleta wrote:
> On Wed, Oct 15, 2008 at 10:57 AM, Patrice Dumas <pertusus at free.fr> wrote:
> > There are 2 reasons why I don't want to flesh it too much. One is
> > because I think it is an iterative process, we don't need much to start
> > and we'll see how it goes, and in the start it won't be public, only
> > something experimental.
> 
> I've no problem with interested people making an experimental stab at
> this.  if the intent is to have FESCo revisit this in like a year or
> something, try to setup the metrics or milestones now that will form
> the basis of that future progress review.

I think that it is too soon to try to set metrics before it is clear if
people should mandatorily sign off as maintainers for older branches,
whether and when there will be bug reports (and how) and so on.

> I will say however, that if the initial mission and goals for a SIG
> are too ill-defined you may have a problem harnessing manpower and
> have everyone pulling the effort forward in a common direction.  Just
> be wary of that.  As you move forward and create a SIG, I'm going to
> need something concrete enough as a statement so when I'm talking to
> people "outside" about their interests I know whether or not to point
> them to this SIG as a place to dig in and help.  The last thing I want
> to do is encourage people with dissimilar needs/interest to sit in a
> room together and have them fight with each other.

Indeed, that's a real issue for this project, as there is no consensus
on what is a good LTS project. For some it is absolute stability, for
other it is innovative as in fedora release, for other it is to bridge
the gap between RHEL releases, and so on. In my opinion saying that it
is more on the stability side, but without the same constraints than in
EPEL is a good start.

> > In fact I think that something that should be
> > discussed within the SIG is how hard we try to keep a possible
> > upgrade path toward the next RHEL/EPEL.
> 
> That statement right there, is probably simultaneously the hardest and
> potentially rewarding objective that an extended update effort could
> attempt to achieve.  And its a far different thing to state that as an
> objective to work towards over just saying maintainers can do whatever
> they want.  But to do it well, would probably require a consensual
> understanding by Red Hat and the external community that such an
> upgrade path was a valuable thing to work towards together.

I think that this is far too soon to have such target. In the short 
term leaving maintainers to do whatever they want is in my opinion a 
better option to begin with. As soon as th eSIG is established there
could be a refinement of the rules, but before I think that letting
packagers do what they want is the simplest and most general target we
can have.

--
Pat



From vonbrand at inf.utfsm.cl  Wed Oct 15 20:27:05 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 15 Oct 2008 17:27:05 -0300
Subject: reviving Fedora Legacy
In-Reply-To: <m38wsqr9f0.fsf@ursa.amorsen.dk>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<m38wsqr9f0.fsf@ursa.amorsen.dk>
Message-ID: <200810152027.m9FKR5Ww012370@laptop14.inf.utfsm.cl>

Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> Bill Nottingham <notting at redhat.com> writes:
> > Fedora 8's been out less a year. It has, in that timeframe, received *over
> > 4600 updates*. Fedora 9 has received over 2600 in its current lifetime.
> >
> > How is upgrading to the next release really that many orders of magnitude
> > more change than this?

> The largest difference is that upgrading to the next release is almost
> an all-or-nothing thing. Incremental upgrades during the release
> generally
  ---------
      |
      +--- But by no means always...

>           affect just one package at a time, so testing is relatively
> easy. When you upgrade the whole distribution you change openssl
> version, and that basically means upgrading everything that could in
> any way cause trouble, all at once.

Exactly like when OpenSSL is upgraded mid-life of the distribution. And
"just rebuild the new stuff over the old distribution" will probably break
badly when this happens too.

>                                     It is far from impossible, I do it
> all the time, but it does need a lot more care.

Care that could better be spent on the /new/ release.

> Once OpenSSL gets banished this pain will subside a bit, but it will
> probably never go away.

/That/ pain might dissapear, others are sure around...

>                         Back in the "good" old days it was libc
> causing that problem, but the developers of glibc have done an
> excellent job of keeping compatibility for many years now.
-- 
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 2340000       Fax:  +56 32 2797513



From nicolas.mailhot at laposte.net  Wed Oct 15 20:34:16 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 15 Oct 2008 22:34:16 +0200
Subject: Fontconfig rules installation guidelines change proposal
In-Reply-To: <48F6401F.3040301@behdad.org>
References: <1223820245.9402.18.camel@arekh.okg> <48F6401F.3040301@behdad.org>
Message-ID: <1224102856.4844.12.camel@arekh.okg>

Le mercredi 15 octobre 2008 ? 15:10 -0400, Behdad Esfahbod a ?crit :

conf.avail and conf.dyyyyyyyyyyyyyyy

> Hi Nicolas,

Hi Behdad,

Thank you for reviewing it,

> I like the direction of it.
> 
> The idea of having separate conf.avail and conf.d is that sysadmins can
> symlink/unlink entries into conf.d to enable/disable configuration for their
> system.  This would only work if upgrading fontconfig/fonts rpms does not
> reinstate the unlinked symlink.  However, last time I checked this was not
> working correctly.  Can you check this first?

I didn't write it in the wiki, but as far as I understand rpm it is not
possible to tell it "if this file/symlink does not exist do not install
it". So this bit of conf.avail/conf.d design will never work on rpm
systems. And even if it worked, what you'd actually need would be "if
this file does not exist and was installed by a previous rpm" to handle
initial deployment. Which starts to be real hairy. (more generally
treating absence of an item as disabling this item is a broken computer
pattern IMHO.)

However (someone please check this) it's probably possible to disable an
entry permanently by creating a symlink with the same name pointing
somewhere else (how does fontconfig reacts to /dev/null symlinks or
symlinks pointing to empty files)? So having a repository of
pre-deployed config snippets is fine with me.

Also (and this bit is traced on the wiki) as I understand the
FHS /etc/.../conf.avail is a complete no-go and should be moved
to /usr/share/something if we want to be clean. And that
before /etc/.../conf.avail is duplicated in many packages.

-- 
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/20081015/83665827/attachment.sig>

From behdad at behdad.org  Wed Oct 15 20:39:11 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 15 Oct 2008 16:39:11 -0400
Subject: Fontconfig rules installation guidelines change proposal
In-Reply-To: <1224102856.4844.12.camel@arekh.okg>
References: <1223820245.9402.18.camel@arekh.okg> <48F6401F.3040301@behdad.org>
	<1224102856.4844.12.camel@arekh.okg>
Message-ID: <48F654EF.5000505@behdad.org>

Nicolas Mailhot wrote:
> Le mercredi 15 octobre 2008 ? 15:10 -0400, Behdad Esfahbod a ?crit :
> 
>> Hi Nicolas,
> 
> Hi Behdad,
> 
> Thank you for reviewing it,
> 
>> I like the direction of it.
>>
>> The idea of having separate conf.avail and conf.d is that sysadmins can
>> symlink/unlink entries into conf.d to enable/disable configuration for their
>> system.  This would only work if upgrading fontconfig/fonts rpms does not
>> reinstate the unlinked symlink.  However, last time I checked this was not
>> working correctly.  Can you check this first?
> 
> I didn't write it in the wiki, but as far as I understand rpm it is not
> possible to tell it "if this file/symlink does not exist do not install
> it". So this bit of conf.avail/conf.d design will never work on rpm
> systems. And even if it worked, what you'd actually need would be "if
> this file does not exist and was installed by a previous rpm" to handle
> initial deployment. Which starts to be real hairy.

Well, it is: don't include the symlink in the RPM but create it in %post, and
only if no previous versions of the package were installed ($1 = 0 IIRC).

> (more generally
> treating absence of an item as disabling this item is a broken computer
> pattern IMHO.)

The alternative would be people editing the files to disable them.  Not much
more package-manager friendly.

> However (someone please check this) it's probably possible to disable an
> entry permanently by creating a symlink with the same name pointing
> somewhere else

This can be ok.  If it works, we can document it.

> (how does fontconfig reacts to /dev/null symlinks or
> symlinks pointing to empty files)? 

Works fine.

> So having a repository of
> pre-deployed config snippets is fine with me.
> 
> Also (and this bit is traced on the wiki) as I understand the
> FHS /etc/.../conf.avail is a complete no-go and should be moved
> to /usr/share/something if we want to be clean. And that
> before /etc/.../conf.avail is duplicated in many packages.

Really?  Where does it talk about those kind of stuff?

behdad



From lesmikesell at gmail.com  Wed Oct 15 20:55:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 15 Oct 2008 15:55:54 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <200810151915.m9FJFRiK011370@laptop14.inf.utfsm.cl>
References: <loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<46a038f90810121912n6481dd66se53a497d9449c540@mail.gmail.com>
	<loom.20081013T075922-165@post.gmane.org>
	<20081013084614.GA25491@orient.maison.lan>
	<20081013092032.GD2670@free.fr>
	<20081013094155.GA26167@orient.maison.lan>
	<20081013103531.GA3087@free.fr>
	<20081013113021.GA27573@orient.maison.lan>
	<20081013113234.GD3087@free.fr>
	<200810141242.m9ECgLVs009225@laptop14.inf.utfsm.cl>
	<1223989050.3029.321.camel@beck.corsepiu.local>
	<48F49A4F.8010900@gmail.com>
	<200810151915.m9FJFRiK011370@laptop14.inf.utfsm.cl>
Message-ID: <48F658DA.3000805@gmail.com>

Horst H. von Brand wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> [...]
> 
>> I don't think I'd use 'standard' to describe something unique and
>> proprietary, but there is something to be said about an OS that runs
>> for years without reinstalling and works with vendor provided drivers
>> that also don't need to be reinstalled every few weeks.
> 
> You must have been using a different strand of that stuff than I got...

Or maybe you haven't kept up to date.  Win2k and XP with service pack 2 
and everything since are very reliable if kept updated and 
virus-protected.  Vista broke some interfaces and shows the problems you 
expect from that, though.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From benny+usenet at amorsen.dk  Wed Oct 15 20:56:35 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 15 Oct 2008 22:56:35 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <200810152027.m9FKR5Ww012370@laptop14.inf.utfsm.cl>
References: <48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<20081013192104.GB27065@nostromo.devel.redhat.com>
	<20081013195507.GC2738@free.fr>
	<20081013200047.GC27065@nostromo.devel.redhat.com>
	<20081013202231.GE2738@free.fr>
	<20081013204919.GA28298@nostromo.devel.redhat.com>
	<m38wsqr9f0.fsf@ursa.amorsen.dk>
	<200810152027.m9FKR5Ww012370@laptop14.inf.utfsm.cl>
Message-ID: <1224104196.26246.4.camel@ursa.amorsen.dk>

ons, 15 10 2008 kl. 17:27 -0300, skrev Horst H. von Brand:

> Exactly like when OpenSSL is upgraded mid-life of the distribution. And
> "just rebuild the new stuff over the old distribution" will probably break
> badly when this happens too.

I don't remember OpenSSL getting an incompatible upgrade during mid-life
Fedora. I'm fairly sure I would have noticed. Has it happened?


/Benny




From jeff at ocjtech.us  Wed Oct 15 21:12:52 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 15 Oct 2008 16:12:52 -0500
Subject: New PiTiVi Release!
Message-ID: <935ead450810151412s201a34eascb51e2ffecd9277f@mail.gmail.com>

Finally, there is a new PiTiVi release and I've built it for F-9 and
rawhide.  Please, take a moment to download it and give it a workout.
Please report bugs upstream (http://pitivi.org/wiki/Main_Page)
Hopefully, it will fix the following bugs:

452490 - GStreamer-CRITICAL **: gst_caps_get_structure: assertion
`GST_IS_CAPS (caps)' failed
450393 - pitivi shows "Internal data flow error." on launch
440488 - Program crash on start up... possible race condition.
462108 - Pitivi fails to start

>From the release announcement:

* Features of this release

 * New advanced timeline interface by Brandon Lewis (SoC)
 * Capture interface for webcams and network sources by Sarath Lakshman
(SoC).
 * Simple Timeline is gone.
 * Project save/load now activated by default
 * Cutting/Trimming/Removing features added to advanced timeline.
 * Misc fixes and improvements

* Bugs Fixed

 * 552777 : [ruler.py] BadAlloc error with big sources
 * 353870 : Save/Load project from/to file
 * 332473 : Capture from given gstreamer input source
 * 334631 : xvsink crash with python in pitivi
 * 339895 : [Advanced Timeline] Zooming in too much causes X error
 * 432678 : [discoverer] Files that report a duration of 0s is BUGGY !!!
 * 458944 : Cancelling while rendering does not work
 * 461738 : [Advanced Timeline] Scrollbar always comes back to beginning
 * 498071 : [Simple Timeline] Drag and Drop puts clips in the wrong slot
 * 498904 : incorrect indentation: some tabs are mixed with spaces in...
 * 501028 : Missing files from POTFILES.in
 * 501068 : Uses make instead of $(MAKE)
 * 518301 : Pitivi won't start under KDE: &quot; Icon 'misc' not pres...
 * 547095 : [Export Settings] Filter unusable muxers
 * 554544 : net_capture.glade not installed
 * 554602 : seeking is not working correctly ...

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From martin.langhoff at gmail.com  Wed Oct 15 21:47:55 2008
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Thu, 16 Oct 2008 10:47:55 +1300
Subject: Hardware test protocols for Fedora compat?
Message-ID: <46a038f90810151447p79671d78qd5351bc6ec6c825b@mail.gmail.com>

Are there any published testing protocols to test HW against
RHEL/Fedora? Even the protocol is very time-consuming or general /
indicative, it would be useful to us as a starting point.

My guess is that RH certification includes (perhaps amongst other
things) a test protocol -- but I am not sure it is public.

Looking around, I see some people offer commercial testing services...
http://www.linux-tested.com/lnx_hardware.html - they do offer "pre
test kits" that are perhaps a good starting point...

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From rawhide at fedoraproject.org  Wed Oct 15 22:59:16 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 15 Oct 2008 22:59:16 +0000 (UTC)
Subject: rawhide report: 20081015 changes
Message-ID: <20081015225916.567ED1B8001@releng2.fedora.phx.redhat.com>

Compose started at Wed Oct 15 17:10:58 UTC 2008

New package dnstracer
        Trace a DNS record to its start of authority
New package ebnetd
        EBNET protocol server
New package gromacs
        GROMACS binaries
New package httperf
        Tool for measuring web server performance
New package hunspell-br
        Breton hunspell dictionaries
New package hunspell-te
        Telugu hunspell dictionaries
New package insight
        Graphical debugger based on GDB
New package perl-Padre
        Perl Application Development and Refactoring Environment
New package python-pmw
        Python powerwidgets
Updated Packages:

NetworkManager-vpnc-0.7.0-0.11.svn4175.fc10
-------------------------------------------
* Tue Oct 14 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-11.svn4175
- Fix password issue with configurations that don't save the user password
	in the keyring (rh #466864)


amanda-2.5.2p1-13.fc10
----------------------
* Wed Oct 15 18:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 2.5.2.p1-13 
- --with-tcpportrange removed again (people getting AVC denies, #462681)


anaconda-11.4.1.49-1
--------------------
* Tue Oct 14 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.49-1
- Make kickstart installs work again (#374271, #392021, #448096, #466340,
  - Let users go Back when loading updates. (dcantrell)
- Write ifcfg files to /etc/sysconfig/network-scripts instead of /.tmp
  (dcantrell)
- Handle unknown hosts in getDefaultHostname (#466775) (dcantrell)
- Try to look up the hostname by the IP address NM reports (#466775)
  (dcantrell)
- NM no longer provides the hostname as a property (#466775). (clumens)
- ext4dev -> ext4 (esandeen). (clumens)
- Move persistent network udev rule to under /etc (#464844). (clumens)
- Update keymaps to include latest Romanian settings (#466117). (clumens)
- Take ip= parameter values by not resetting ipinfo_set. (dcantrell)


blender-2.48-1.fc10
-------------------
* Wed Oct 15 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 2.48-1
- New upstream release
- Build agains system glew library (#466755)


bluez-4.13-3.fc10
-----------------
* Tue Oct 14 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.13-3
- Update udev rules (#246840)


bluez-gnome-1.8-3.fc10
----------------------
* Tue Oct 14 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-3
- Add patches to clean up the button list (#465398)


bug-buddy-2.24.0-3.fc10
-----------------------
* Wed Oct 15 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.0-3
- Don't install unused files

- Don't install unused files

- Don't install unused files

- Don't install unused files


ca-certificates-2008-7
----------------------
* Tue Oct 14 18:00:00 2008 Joe Orton <jorton at redhat.com> 2008-7
- update to certdata.txt r1.49


cobbler-1.2.8-1.fc10
--------------------
* Wed Oct 15 18:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.2.8-1
- Upstream changes (see CHANGELOG)

* Tue Oct 14 18:00:00 2008 Michael DeHaan <mdehaan at redhat.com> - 1.2.7-1
- Upstream changes (see CHANGELOG)


eclipse-pydev-1.3.20-1.fc10
---------------------------
* Tue Oct 14 18:00:00 2008 Michal Nowak <mnowak at redhat.com> 1:1.3.20-1
- bump to 1.3.20
- created general versioning scheme for version tag & tarball URI)
- sed: /usr/local/bin/python -> /usr/bin/env python in Jython's cgi.py
- convert .py$ files from mode 0644 to mode 0755
- possibility to convert '\r\n' end-of-lines to *nix-like '\n'
  in all '.py$' files


eclipse-setools-3.3.2.4-3.fc10
------------------------------
* Tue Oct 14 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> - 3.3.2.4-3
- Rebuild to move in dropins.

* Thu Jul 31 18:00:00 2008 Dave Sugar <dsugar at tresys.com> - 3.3.2.4-2
- update for F10 layout changes for Eclipse 3.4


eclipse-slide-1.3.9-3.fc10
--------------------------
* Fri Aug  8 18:00:00 2008 Dave Sugar <dsugar at tresys.com> - 1.3.9-3
- change from libdir to datadir as base for install

* Thu Jul 31 18:00:00 2008 Dave Sugar <dsugar at tresys.com> - 1.3.9-2
- update for F10 layout changes for Eclipse 3.4


eel2-2.24.0-5.fc10
------------------
* Wed Oct 15 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-5
- Fix crossfade from login session now that g-s-d race
  is fixed.


Broken deps for i386
----------------------------------------------------------
	ibus-m17n-latin-0.1.1.20081013-2.fc10.i386 requires latin
	ibus-m17n-latin-0.1.1.20081013-2.fc10.i386 requires t-latn
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.i386 requires syriac
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.i386 requires t-syrc
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ibus-m17n-latin-0.1.1.20081013-2.fc10.x86_64 requires latin
	ibus-m17n-latin-0.1.1.20081013-2.fc10.x86_64 requires t-latn
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.x86_64 requires syriac
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.x86_64 requires t-syrc
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ibus-m17n-latin-0.1.1.20081013-2.fc10.ppc requires latin
	ibus-m17n-latin-0.1.1.20081013-2.fc10.ppc requires t-latn
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.ppc requires syriac
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.ppc requires t-syrc
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	ibus-m17n-latin-0.1.1.20081013-2.fc10.ppc64 requires latin
	ibus-m17n-latin-0.1.1.20081013-2.fc10.ppc64 requires t-latn
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.ppc64 requires syriac
	ibus-m17n-syriac-0.1.1.20081013-2.fc10.ppc64 requires t-syrc
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From bpepple at fedoraproject.org  Wed Oct 15 23:26:44 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 15 Oct 2008 19:26:44 -0400
Subject: FESCo Meeting Summary for 2008-10-08
Message-ID: <1224113204.8840.6.camel@kennedy>

=== Members Present ===
* Brian Pepple		(bpepple)
* Kevin Fenzi		(nirik)
* Jarod Wilson		(j-rod)
* Bill Nottingham       (notting)
* Jon Stanley		(jds2001)
* Dennis Gilmore        (dgilmore)
* Josh Boyer		(jwb)
* David Woodhouse       (dwmw2)
* Karsten Hopp		(kick_)

== Summary ==
=== Features ====
* Talked with the some members of the QA team on the progress of the QA
test days.
https://fedoraproject.org/wiki/QA/TestResults/Fedora10Features/Beta
* Discussed ways to better communicate decisions.  Will start cc'ing
feature owners on the meeting summaries when decisions are made on their
features.

=== MinGW ===
* Issue was forwarded to Rel-Eng to determine how much extra work was
needed to implement separate repo for cross-compiler environments.

=== Comp.xml ===
* j-rod and jds2001 are going to work on updating the CompsXml policy.
https://fedoraproject.org/wiki/PackageMaintainers/CompsXml

=== Package Reviews ===
* dwmw2 proposed that FESCo members tried to review a minimum of one
package a week.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-08.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081015/4c572173/attachment.sig>

From vonbrand at inf.utfsm.cl  Wed Oct 15 23:30:34 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 15 Oct 2008 20:30:34 -0300
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081015193427.GI2679@free.fr>
References: <48EF79A4.2030103@gmail.com>
	<20081010175427.GA7389@orient.maison.lan>
	<48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
	<200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
	<20081014145650.GB3126@free.fr>
	<200810151929.m9FJT7NH011508@laptop14.inf.utfsm.cl>
	<20081015193427.GI2679@free.fr>
Message-ID: <200810152330.m9FNUYHR004642@laptop14.inf.utfsm.cl>

Patrice Dumas <pertusus at free.fr> wrote:
> On Wed, Oct 15, 2008 at 04:29:07PM -0300, Horst H. von Brand wrote:
> > Patrice Dumas <pertusus at free.fr> wrote:
> > > On Tue, Oct 14, 2008 at 10:46:40AM -0300, Horst H. von Brand wrote:

> > > The work in the scope of this project will be less hard than what was
> > > done in the scope of legacy,

> > I just can't imagine why it would be less; if anything, much more (there
> > are more packages today, and the "basic stuff that must work" is getting
> > more and more).

> Maybe on the packaging side, that is more packages to maintain (the
> minimal target being @code + @base in my opinion, but this can be
> discussed), but less on the QA and process side. Moreover now that core
> is opened it means that contributors may be more involved in core
> packages and may have done merge reviews (at least it is my case) 
> while for legacy people started with packages they had no
> reason to know.

If all that is "maintained" is a skeleton system, that won't do much good
(how often was a /@core/ or /@base/ packages that can't be upgraded the
cause of not moving to the next Fedora?)
-- 
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 2340000       Fax:  +56 32 2797513



From bpepple at fedoraproject.org  Wed Oct 15 23:53:58 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 15 Oct 2008 19:53:58 -0400
Subject: FESCo Meeting Summary for 2008-10-01
Message-ID: <1224114838.8840.12.camel@kennedy>

=== Members Present ===
* Brian Pepple          (bpepple)
* Kevin Fenzi           (nirik)
* Jarod Wilson          (j-rod)
* Bill Nottingham       (notting)
* Jon Stanley           (jds2001)
* Dennis Gilmore        (dgilmore)
* Josh Boyer            (jwb)
* David Woodhouse       (dwmw2)
* Karsten Hopp          (kick_)

== Summary ==
=== MinGW ===
* FESCo dropped the requirement for a separate repo for MinGW, based on
recommendation from Rel-Eng.

=== Keeping Infrastructure Open for EOL Proposal ===
* FESCo felt that the Board need to be included in this decision, since
it deals with:
     1. Infrastructure
     2. Goals of the project
     3. Use of the 'Fedora' brand (including possibly the trademarks)
* FESCo members had other concerns also, that they were going to add to
the discussion page of the proposal.

=== Zope/Plone ===
* FESCo voted against a proposal to reverse it's previous decision (from
Dec. '06) regarding including a compat-python package in Fedora.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-15.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081015/acb79ecb/attachment.sig>

From jkeating at redhat.com  Thu Oct 16 01:15:18 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 15 Oct 2008 18:15:18 -0700
Subject: rawhide report: 20081015 changes
In-Reply-To: <20081015225916.567ED1B8001@releng2.fedora.phx.redhat.com>
References: <20081015225916.567ED1B8001@releng2.fedora.phx.redhat.com>
Message-ID: <1224119718.4122.63.camel@luminos.localdomain>

On Wed, 2008-10-15 at 22:59 +0000, Rawhide Report wrote:
> Updated Packages:

Couple things.

1) It looks like the diff got cut off somewhere, not sure what's up
there, will investigate tomorrow.

2) We're now using unique metadata names in the yum repodata.  This
should help proxies and such.  Please report any problems experienced
that could potentially have to do with this change.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081015/16086a90/attachment.sig>

From christoph.wickert at googlemail.com  Thu Oct 16 01:16:47 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 16 Oct 2008 03:16:47 +0200
Subject: default XFCE layout
In-Reply-To: <385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
	<20081011152620.5c57cb26@ohm.scrye.com>
	<385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>
Message-ID: <1224119807.13994.48.camel@wicktop.localdomain>

Am Sonntag, den 12.10.2008, 01:59 +0300 schrieb Muayyad AlSadi:
> Hi, sorry I though you meant devel-list as a way to get it into F10
> and upstream them later

We have several tweaks in the panel configuration (trash, mailwatch,
etc) but we [1] want the basic panel layout (top and bottom panel) to
follow upstream.

> > If you have a **great idea** for a layout
> It's just a desktop layout it's not big deal nor rocket science
> I don't think we should upstream our fedora backgrounds to xfce!

There are some things I don't like in you layout:
      * pager is to small, if it has two rows you it does not show
        application icons any longer
      * window list is to small, at least on your screenshot
      * it's nearly a 1:1 copy of the default Windoze taskbar. I'm
        pretty sure this is _not_ what upstream wants. ;)

Also keep in mind that two panels don't use significant more resources
than one panel, it's still a single process. The only resource that is
actually used is screen size.

> do you have two fedora accounts
> .fasinso nirik
> .fasinfo kaven
> 
> Fedora people should stop using two names :-)

Nirik has only one account. There is no kaven and kevin is Kevin Kofler.

Regards,
Christoph

[1] the Xfce SIG: nirik, mether and me



From christoph.wickert at googlemail.com  Thu Oct 16 01:19:19 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 16 Oct 2008 03:19:19 +0200
Subject: Help! XFCE event sounds in Rawhide -- make it stop!
In-Reply-To: <20080814024758.GA4153@jadzia.bu.edu>
References: <20080813025153.GA13866@jadzia.bu.edu>
	<1218618589.3415.5.camel@wicktop.localdomain>
	<20080813114142.GA25538@jadzia.bu.edu>
	<1218645283.6997.5.camel@localhost.localdomain>
	<20080813193221.GA7928@jadzia.bu.edu>
	<1218666208.5012.5.camel@wicktop.localdomain>
	<20080814024758.GA4153@jadzia.bu.edu>
Message-ID: <1224119959.13994.50.camel@wicktop.localdomain>

Am Mittwoch, den 13.08.2008, 22:47 -0400 schrieb Matthew Miller:
> On Thu, Aug 14, 2008 at 12:23:28AM +0200, Christoph Wickert wrote:
> > This is something that should be done upstream and since
> > xfce-mcs-manager is going to be replaced by xfconf in Xfce 4.6 it's not
> > very likely to happen.
> 
> So, will xfconf already support the needed sound prefs?

Update on this topic: Yes xfconf/Xfce 4.6 will have support for sound
themes, see http://blog.xfce.org/?p=405

Regards,
Christoph




From sundaram at fedoraproject.org  Thu Oct 16 01:27:12 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 16 Oct 2008 06:57:12 +0530
Subject: default XFCE layout
In-Reply-To: <1224119807.13994.48.camel@wicktop.localdomain>
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>	<20081011152620.5c57cb26@ohm.scrye.com>	<385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>
	<1224119807.13994.48.camel@wicktop.localdomain>
Message-ID: <48F69870.8070607@fedoraproject.org>

Christoph Wickert wrote:
> Am Sonntag, den 12.10.2008, 01:59 +0300 schrieb Muayyad AlSadi:
>> Hi, sorry I though you meant devel-list as a way to get it into F10
>> and upstream them later
> 
> We have several tweaks in the panel configuration (trash, mailwatch,
> etc) but we [1] want the basic panel layout (top and bottom panel) to
> follow upstream.

Well, since you included me in that conversation, I would like to note 
that the simple layout changes suggested here usually do not require 
invasive patches and can easily be maintained which is one of the usual 
pain points otherwise but I do not maintain any Xfce package and just 
the Xfce spin/live cd so this is upto others to decide.

Also I do personally prefer a double panel with the layout I have filed 
a RFE on, a while back, rather than a single one but if there is a more 
universal appeal in doing things otherwise, I can go with that choice. 
Notifying upstream is a good idea nevertheless. The current upstream 
default seems more reminiscent of their CDE look alike legacy rather 
than anything to do with usability.

Rahul



From jeff at ocjtech.us  Thu Oct 16 01:44:38 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 15 Oct 2008 20:44:38 -0500
Subject: New PiTiVi Release!
In-Reply-To: <935ead450810151412s201a34eascb51e2ffecd9277f@mail.gmail.com>
References: <935ead450810151412s201a34eascb51e2ffecd9277f@mail.gmail.com>
Message-ID: <935ead450810151844t74325336x6ec44d3d87c6123b@mail.gmail.com>

On Wed, Oct 15, 2008 at 4:12 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
> Finally, there is a new PiTiVi release and I've built it for F-9 and
> rawhide.  Please, take a moment to download it and give it a workout.
> Please report bugs upstream (http://pitivi.org/wiki/Main_Page)

Until the packages make their way to the mirrors, they can be downloaded here:

F-10: http://koji.fedoraproject.org/koji/buildinfo?buildID=66472
F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=66475

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From christoph.wickert at googlemail.com  Thu Oct 16 02:18:39 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 16 Oct 2008 04:18:39 +0200
Subject: default XFCE layout
In-Reply-To: <48F69870.8070607@fedoraproject.org>
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
	<20081011152620.5c57cb26@ohm.scrye.com>
	<385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>
	<1224119807.13994.48.camel@wicktop.localdomain>
	<48F69870.8070607@fedoraproject.org>
Message-ID: <1224123519.13994.90.camel@wicktop.localdomain>

Am Donnerstag, den 16.10.2008, 06:57 +0530 schrieb Rahul Sundaram:
> Christoph Wickert wrote:
> > Am Sonntag, den 12.10.2008, 01:59 +0300 schrieb Muayyad AlSadi:
> >> Hi, sorry I though you meant devel-list as a way to get it into F10
> >> and upstream them later
> > 
> > We have several tweaks in the panel configuration (trash, mailwatch,
> > etc) but we [1] want the basic panel layout (top and bottom panel) to
> > follow upstream.
> 
> Well, since you included me in that conversation, I would like to note 
> that the simple layout changes suggested here usually do not require 
> invasive patches and can easily be maintained which is one of the usual 
> pain points otherwise but I do not maintain any Xfce package and just 
> the Xfce spin/live cd so this is upto others to decide.

Sorry for mentioning you although you were not really involved in this
decision. Kevin and me talked about that during our latest Xfce SIG
meetings while you haven't been around. I know it's hard/impossible for
you to attend the meetings at the current time slot but we have offered
several alternatives and haven't heard anything back from you after my
last suggestion (which was UTC 18:00).

I did several mockus [1] but in the end Kevin and I agreed that we
should not follow the Xubuntu path and instead stick close to upstream.
If someone wants something different, he can easily change the panel
layout.

> Also I do personally prefer a double panel with the layout I have filed 
> a RFE on, a while back, rather than a single one but if there is a more 
> universal appeal in doing things otherwise, I can go with that choice. 

IIRC your RFE [2] was about icons for suspend, hibernate ans switch
users but not about the basic panel layout.

> Notifying upstream is a good idea nevertheless. The current upstream 
> default seems more reminiscent of their CDE look alike legacy rather 
> than anything to do with usability.

As current screenshots of Xfce 4.6 [3] basically still show the same
layout there seems to be agreement about this among the Xfce developers.
So if somebody thinks that the current layout has nothing to do with
usability IMO he really should push this discussion upstream.

> 
> Rahul

Regards,
Christoph

[1] e.g.
http://cwickert.fedorapeople.org/screenshots/xfce-gnome-like-panel.png
[2] https://bugzilla.redhat.com/show_bug.cgi?id=433150
[3] http://marktmisc.blogspot.com/2008/09/xfce-trunk.html





From mattdm at mattdm.org  Thu Oct 16 03:02:42 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 15 Oct 2008 23:02:42 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <1224092835.4122.45.camel@luminos.localdomain>
References: <20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
Message-ID: <20081016030242.GA20109@jadzia.bu.edu>

On Wed, Oct 15, 2008 at 10:47:15AM -0700, Jesse Keating wrote:
> along with infrastructure, you need a release engineer.  Somebody who's
> going to babysit the collections, do buildroot overrides to build chains
> of packages, do package signing, urge (a) bodhi into pushing the
> updates, making sure they get rsynced properly, dealing with bug reports
> about broken deps, so on and so forth.  I say this, because I'm not
> about to volunteer to do that work for you.  I say this also, because
> trying to bring somebody in to do these things on the "LTS" section, but
> isolate that person from the normal section is going to be difficult, if
> we have to go that route.

And let's be clear: this alone is a full-time job. Or job and a half.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From sundaram at fedoraproject.org  Thu Oct 16 03:34:00 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 16 Oct 2008 09:04:00 +0530
Subject: default XFCE layout
In-Reply-To: <1224123519.13994.90.camel@wicktop.localdomain>
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>	<20081011152620.5c57cb26@ohm.scrye.com>	<385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>	<1224119807.13994.48.camel@wicktop.localdomain>	<48F69870.8070607@fedoraproject.org>
	<1224123519.13994.90.camel@wicktop.localdomain>
Message-ID: <48F6B628.3010603@fedoraproject.org>

Christoph Wickert wrote:

I know it's hard/impossible for
> you to attend the meetings at the current time slot but we have offered
> several alternatives and haven't heard anything back from you after my
> last suggestion (which was UTC 18:00).

I think, I did reply but might have left you from the CC list 
accidentally. Anyway, let's get on with UTC 18.00 and see how well that 
works. I don't really have a very regular routine for work. The only 
thing I am involved with, is the live cd. The entire Xfce SIG should 
have commit access to the spin ks repo which allows you, kevin (and 
others) to implement changes as necessary. So, nothing should be 
blocking on me.
> 
> IIRC your RFE [2] was about icons for suspend, hibernate ans switch
> users but not about the basic panel layout.

I was more concerned about exposing functionality than the layout which 
people tend to customize anyway but I do recall suggesting ideas on one 
of the RFE's filed.

Rahul



From rc040203 at freenet.de  Thu Oct 16 04:32:25 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 16 Oct 2008 06:32:25 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <alpine.LRH.2.00.0810151952370.28934@netcore.fi>
References: <48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
	<604aa7910810121804g35b134cem892fb3410ed11a32@mail.gmail.com>
	<loom.20081013T013947-433@post.gmane.org>
	<1224056165.6770.955.camel@macbook.infradead.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
Message-ID: <1224131545.3029.625.camel@beck.corsepiu.local>

On Wed, 2008-10-15 at 20:00 +0300, Pekka Savola wrote:
> On Wed, 15 Oct 2008, Ralf Corsepius wrote:
> > If this all shall make sense and remain unbureaucratic and efficient,
> > there must not be any "other repo" nor "other VCS" nor distrust.
> >
> > Seems to me as if some people around here are resistant to learning?
> 
> Learning what?
Keeping things simple, avoiding bureaucracy, developing trust etc.

> It seems folks proposing this madness failed to learn from how Fedora 
> Legacy failed.
Legacy failed exactly for the reasons above: Separate VCS, separate
buildsystem, blownup bureaucracy, lack of collaboration, distrust.

Ralf







From rc040203 at freenet.de  Thu Oct 16 04:53:44 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 16 Oct 2008 06:53:44 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1224092835.4122.45.camel@luminos.localdomain>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
Message-ID: <1224132824.3029.628.camel@beck.corsepiu.local>

On Wed, 2008-10-15 at 10:47 -0700, Jesse Keating wrote:
> On Wed, 2008-10-15 at 11:25 -0600, Stephen John Smoogen wrote:
> > 
> > [And yes, you are going to need to deal with infrastructure. Disk
> > space, cpu cycles, memory and power is not 'cheap' as much as people
> > think it is. Extra build boxes will be needed, extra disk space to
> > store stuff, and extra cpu cycles as Fedora's current infrastructure
> > is built on the assumption that it only needs to deal with X releases
> > for Y time. Adding to X and Y means more equipment needed. It will
> > also mean that someone's on the team are going ot have to focus on the
> > infrastructure problems as that addition also increases the number of
> > people needed to watch builds, etc.
> 
> along with infrastructure, you need a release engineer.
I guess, you will apply the same rationale when EPEL6 comes out?

Ralf





From petersen at redhat.com  Thu Oct 16 04:59:19 2008
From: petersen at redhat.com (Jens Petersen)
Date: Thu, 16 Oct 2008 00:59:19 -0400 (EDT)
Subject: rawhide report: 20081015 changes
In-Reply-To: <661989927.1124051224133097928.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1127282423.1124121224133159152.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

> 	ibus-m17n-latin-0.1.1.20081013-2.fc10.i386 requires latin
> 	ibus-m17n-latin-0.1.1.20081013-2.fc10.i386 requires t-latn
> 	ibus-m17n-syriac-0.1.1.20081013-2.fc10.i386 requires syriac
> 	ibus-m17n-syriac-0.1.1.20081013-2.fc10.i386 requires t-syrc

should be fixed by ibus-m17n-0.1.1.20081013-3.fc10



From jkeating at redhat.com  Thu Oct 16 05:05:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 15 Oct 2008 22:05:20 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <1224132824.3029.628.camel@beck.corsepiu.local>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
	<1224132824.3029.628.camel@beck.corsepiu.local>
Message-ID: <1224133520.4122.64.camel@luminos.localdomain>

On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
> I guess, you will apply the same rationale when EPEL6 comes out?

EPEL currently has people filling this role.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081015/c9c6fcaf/attachment.sig>

From rc040203 at freenet.de  Thu Oct 16 05:23:47 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 16 Oct 2008 07:23:47 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1224133520.4122.64.camel@luminos.localdomain>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
	<1224132824.3029.628.camel@beck.corsepiu.local>
	<1224133520.4122.64.camel@luminos.localdomain>
Message-ID: <1224134627.3029.631.camel@beck.corsepiu.local>

On Wed, 2008-10-15 at 22:05 -0700, Jesse Keating wrote:
> On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
> > I guess, you will apply the same rationale when EPEL6 comes out?
> 
> EPEL currently has people filling this role.
You mean, RH's hegemony is taking care about it and has allocated
budgets.




From jkeating at redhat.com  Thu Oct 16 05:26:59 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 15 Oct 2008 22:26:59 -0700
Subject: reviving Fedora Legacy
In-Reply-To: <1224134627.3029.631.camel@beck.corsepiu.local>
References: <loom.20081013T013947-433@post.gmane.org>
	<20081015074228.GB2795@free.fr>
	<20081015113317.GA26690@yoda.jdub.homelinux.org>
	<20081015121350.GB3091@free.fr>
	<20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
	<1224132824.3029.628.camel@beck.corsepiu.local>
	<1224133520.4122.64.camel@luminos.localdomain>
	<1224134627.3029.631.camel@beck.corsepiu.local>
Message-ID: <1224134820.4122.66.camel@luminos.localdomain>

On Thu, 2008-10-16 at 07:23 +0200, Ralf Corsepius wrote:
> You mean, RH's hegemony is taking care about it and has allocated
> budgets.

Actually no, I don't believe any @redhat.com folks are filling the
releng tasks for EPEL, or if they are, they were doing it before being
hired at RH and it is not part of their job.

To the best of my knowledge, not a single person within Red Hat is paid
to work on EPEL.  Any @redhat.com participation is done in one's spare
time.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081015/b4177c9b/attachment.sig>

From jonathan at jonmasters.org  Thu Oct 16 06:13:47 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 02:13:47 -0400
Subject: minimum memory requirements
Message-ID: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>

Hi,

I've noticed that a fresh rawhide install is ooming unless I allocate
512MB to the guest machine that it is running within. Is this to be
expected? i.e. are we requiring 512MB now for a new install?

Not a loaded/baited question. I'd expect to install in 256MB.

Jon.




From pertusus at free.fr  Thu Oct 16 07:38:05 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 16 Oct 2008 09:38:05 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <200810152330.m9FNUYHR004642@laptop14.inf.utfsm.cl>
References: <48F2A325.3090704@gmail.com>
	<20081013082402.GA25102@orient.maison.lan>
	<48F34967.9090201@gmail.com>
	<20081013133803.GA28852@orient.maison.lan>
	<20081013134149.GD3139@free.fr>
	<200810141346.m9EDkeol022503@laptop14.inf.utfsm.cl>
	<20081014145650.GB3126@free.fr>
	<200810151929.m9FJT7NH011508@laptop14.inf.utfsm.cl>
	<20081015193427.GI2679@free.fr>
	<200810152330.m9FNUYHR004642@laptop14.inf.utfsm.cl>
Message-ID: <20081016073805.GA2645@free.fr>

On Wed, Oct 15, 2008 at 08:30:34PM -0300, Horst H. von Brand wrote:
> 
> If all that is "maintained" is a skeleton system, that won't do much good
> (how often was a /@core/ or /@base/ packages that can't be upgraded the
> cause of not moving to the next Fedora?)

This is not the goal. Hopefully there will be much more maintained
packages (and given that some people seem to be interested and they
maintain or co-maintain a large number of packages) but this is to
define a minimal set of packages that are mandatorily actively 
maintained.

--
Pat



From schaiba at gmail.com  Thu Oct 16 07:45:28 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Thu, 16 Oct 2008 10:45:28 +0300
Subject: minimum memory requirements
In-Reply-To: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
Message-ID: <778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>

On Thu, Oct 16, 2008 at 9:13 AM, Jon Masters <jonathan at jonmasters.org>wrote:

> Hi,
>
> I've noticed that a fresh rawhide install is ooming unless I allocate
> 512MB to the guest machine that it is running within. Is this to be
> expected? i.e. are we requiring 512MB now for a new install?
>
> Not a loaded/baited question. I'd expect to install in 256MB.
>
> Jon.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Could be beacause of the debuginfo present in rawhide but left out on
release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/07d688dd/attachment.htm>

From pmatilai at laiskiainen.org  Thu Oct 16 07:53:49 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 16 Oct 2008 10:53:49 +0300 (EEST)
Subject: compat-python, Zope...
In-Reply-To: <48F5FFD7.5050908@hhs.nl>
References: <48F4630E.7030002@linux-kernel.at> <48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>
	<1223988009.16958.51.camel@code.and.org>
	<48F596F2.6000902@linux-kernel.at>
	<1224078305.16958.82.camel@code.and.org> <48F5FFD7.5050908@hhs.nl>
Message-ID: <alpine.DEB.1.10.0810160839390.11642@gotcha.dreamhost.com>

On Wed, 15 Oct 2008, Hans de Goede wrote:

> James Antill wrote:
>> On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
>>> James Antill wrote:
>>> [ ... ]
>>>>> I can think of a Python 2.4 package that lives within the Zope tree to 
>>>>> make it extra hard for others to use it by accident - but I don't think 
>>>>> that this would be neat, seen from a FHS point of view.
>>>>  In some ways this might be doable, at least it has less pain points
>>>> than packaging it "properly".
>>> I'm not sure what you mean here? Do you mean with properly an 
>>> /usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to 
>>> invite everybody to have a look at the livna packages. Those are fine and 
>>> don't hurt the main python...
>> 
>> % repoquery --repoid=livna --provides compat-python24-imaging 
>> _imaging.so()(64bit)
>> _imagingft.so()(64bit)
>> _imagingmath.so()(64bit)
>> compat-python24-imaging = 1.1.6-1.lvn9
>> % repoquery --provides python-imaging               _imaging.so()(64bit)
>> _imagingft.so()(64bit)
>> _imagingmath.so()(64bit)
>
> Yes rpmbuild is very broken in that it generates provides for .so files which 
> are not under libdir, so plugins for applications / libs / languages can have 
> conflicting Provides, luckily nothing should ever Require these plugins.

If something requires / can require them, how can they be "wrong"?

Not that I disagree, the above are silly and completely useless for all I 
can tell. But how is rpmbuild going to know what's a real library 
and what's not? %{_libdir} vs outside it is not going to work as it'd 
cause perfectly legal uses of /etc/ld.so.conf.d and LD_LIBRARY_PATH 
(both of which are runtime, not buildtime configuration items) to 
break.

The question to me is: is there a way to *realiably* detect dlopen()'ed 
modules from real libraries? There are a number of possible hints that can 
be looked at, such as having DT_SONAME or not but AFAICT, it's all just 
guesswork. Since the elf linker doesn't require DT_SONAME for shared 
libraries, we'd break the dependency resolution of valid uses if we 
filtered those out from provides generation.

As there doesn't seem to be hard rules (feel free to prove me wrong) we 
can detect at build-time, then heuristics + manual overrides is the best 
we can get. One possibility is a build configuration flag that allows 
switching off generation of provides for DSO's without DT_SONAME, flip 
that on in redhat-rpm-config and rebuild what's necessary. That'd be 
essentially a one-liner patch to rpm.

Just to get an idea of what that would "gain": On my F9 + selected bits 
from rawhide system, the number of DSO's in /%{_lib}, %{_libdir} and their 
subdirectories is 3385. Roughly one third of them don't have DT_SONAME 
set. Looking at the remaining ~2000, there's a lot of "unnecessary" stuff 
left still.

But then, libtool seems to be putting soname into things built with 
-module which makes the DT_SONAME test kinda moot already.

 	- Panu -



From nicolas.mailhot at laposte.net  Thu Oct 16 07:39:56 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 16 Oct 2008 09:39:56 +0200 (CEST)
Subject: Fontconfig rules installation guidelines change proposal
In-Reply-To: <48F654EF.5000505@behdad.org>
References: <1223820245.9402.18.camel@arekh.okg>
	<48F6401F.3040301@behdad.org> <1224102856.4844.12.camel@arekh.okg>
	<48F654EF.5000505@behdad.org>
Message-ID: <4122c5e09deac33103f3079265aedf3a.squirrel@arekh.dyndns.org>



Le Mer 15 octobre 2008 22:39, Behdad Esfahbod a ?crit :
>
> Nicolas Mailhot wrote:
>> Le mercredi 15 octobre 2008 ? 15:10 -0400, Behdad Esfahbod a ?crit :

>>> The idea of having separate conf.avail and conf.d is that sysadmins
>>> can
>>> symlink/unlink entries into conf.d to enable/disable configuration
>>> for their
>>> system.  This would only work if upgrading fontconfig/fonts rpms
>>> does not
>>> reinstate the unlinked symlink.  However, last time I checked this
>>> was not
>>> working correctly.  Can you check this first?
>>
>> I didn't write it in the wiki, but as far as I understand rpm it is
>> not
>> possible to tell it "if this file/symlink does not exist do not
>> install
>> it". So this bit of conf.avail/conf.d design will never work on rpm
>> systems. And even if it worked, what you'd actually need would be
>> "if
>> this file does not exist and was installed by a previous rpm" to
>> handle
>> initial deployment. Which starts to be real hairy.
>
> Well, it is: don't include the symlink in the RPM but create it in
> %post, and
> only if no previous versions of the package were installed ($1 = 0
> IIRC).

Yurk. How safe is it WRT package renames? Because we've been renaming
font packages a lot in the past (and I plan another mass rename for
F11, hopefully the last one but I wouldn't bet anything I care about
on it).

Really this is being too clever for your own good IMHO.

>> However (someone please check this) it's probably possible to
>> disable an
>> entry permanently by creating a symlink with the same name pointing
>> somewhere else
>
> This can be ok.  If it works, we can document it.

>> Also (and this bit is traced on the wiki) as I understand the
>> FHS /etc/.../conf.avail is a complete no-go and should be moved
>> to /usr/share/something if we want to be clean. And that
>> before /etc/.../conf.avail is duplicated in many packages.
>
> Really?  Where does it talk about those kind of stuff?

In conf.avail files are not really user-editable config files (in fact
you don't use config(noreplace) so any package update will stomp on
user modifications). They're more static configuration blocks users
can not change but only activate/desactivate in conf.d via symlinks,
and as such they match the "read-only architecture independent data
files" definition of /usr/share.

That rpmlint complains of %config files without noreplace in /etc is a
pretty strong hint those files are misplaced. In fact one can wonder
what's good is there %config-ing them at all.

IIRC there was a pretty long thread on the subject in fedora-devel in
the last months, but I don't have the time to pull it from archives.

-- 
Nicolas Mailhot



From jonathan at jonmasters.org  Thu Oct 16 08:12:28 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 04:12:28 -0400
Subject: minimum memory requirements
In-Reply-To: <778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
Message-ID: <1224144749.11413.11.camel@perihelion.int.jonmasters.org>

On Thu, 2008-10-16 at 10:45 +0300, Aioanei Rares wrote:

> On Thu, Oct 16, 2008 at 9:13 AM, Jon Masters
> <jonathan at jonmasters.org> 

>         I've noticed that a fresh rawhide install is ooming unless I
>         allocate 512MB to the guest machine that it is running within.


> Could be beacause of the debuginfo present in rawhide but left out on
> release.

Nah. I don't see how that would account for such a difference. This is
crashing early in the install - prior to partitioning. I'm a bit behind
in Anaconda phraseology, but this is almost what used to be stage 1,
except we're running within a 100MB+ ramdisk image with a GUI now.

Something is using a lot of memory (anaconda) and causing the kernel
badness calculation to blame it for all the world's evils. I'd love to
know if others have seen this, especially in F-10 Beta.

Jon.




From oliver at linux-kernel.at  Thu Oct 16 08:29:08 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 16 Oct 2008 10:29:08 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224075473.12340.146.camel@aglarond.local>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info>
	<1224075473.12340.146.camel@aglarond.local>
Message-ID: <48F6FB54.1080909@linux-kernel.at>

Jeremy Katz wrote:
> On Wed, 2008-10-15 at 09:53 +0200, Thorsten Leemhuis wrote:
>> On 15.10.2008 09:17, Oliver Falk wrote:
>> Back then we tried our best to get compat-python directly into Fedora, 
>> but those efforts failed. Hence Livna accepted compat-python (and hence 
>> it made its way to RPM Fusion). But I'm all for moving compat-python* to 
>> Fedora, so I really appreciate your efforts Oliver!
[ ... ]
> We don't ship multiple versions of Xorg because a new version of Xorg
> breaks some driver, instead we fix drivers.

You cannot run multiple versions of Xorg....

 > We don't ship multiple
> versions of apache because apache2 broke some modules. 

Well. I had a lot of mod_perl 1.x apps and so had apache 1.3 running on 
Fedora for a long time. Until I finally fixed *my* apps to work with 
mod_perl 2.x. I know a few more people who (still) have the same problem 
and therefore a similar setup I had. So even for apache it would have 
made sense to provide compat packages. But it seems nobody worried about 
the Admins and the Developers...

I can remember similar problems with php 4 -> 5... I had a few cases 
where php 5 didn't work with some OSS, but these where fixed quite fast 
and I only had to wait for a short while (less than half a year) until I 
was able to upgrade to the next Fedora version.

It (Fedora) is sometimes only a just-get-the-latest-stuff into the 
latest-distribution. Which actually sometimes is nice, but sometimes 
break things horrible!

 > <insert
> infinitely long list of other such things we don't support>.  Why should
> python be *any* different for zope/plone?

Well. Why do we have tomcat 5.x and tomcat 6.x? :-P
Ah, because there might be some enterprise customers who actually have 
enterprise applications running with tomcat 5 and are not compatible 
with tomcat 6?

I *do* have experience with this as well. In my former company, we had 
tomcat 5 and had to put much effort in 'porting' our application to 
tomcat 6. I'm not sure if the application has been finally migrated or 
not... Maybe not and it still runs with Tomcat 5.
I do know some other Tomcat app, that didn't even work with Tomcat 4 and 
we had to package (on some RHEL system) tomcat 3.

Can you imagine the fun?

And back to Zope. I know of some really large enterprise company (known 
especially from selling books) - located in Germany - who actually use 
Zope for their intranet. I guess they are not going to update any time 
soon, but if they decide to upgrade their base OS, they have to install 
python + deps manually from tarball and since we have new DB4, that will 
not be easy. BUT *we* do already have the patches, so why don't we want 
our users (and RH customers) use packages, if the man power to provide 
the packages is within the community?
Actually I don't know if they are RH customers or Fedora users...

> [1] Want to have your zope and plone instances auth to FAS?  Guess you
> need python-fedora now...  How about openid?  There's a different module
> there.  Etc.

Yes. Of course we are going to have a long tail of extra packages for 
the compat packages...


Final statement:
If we believe that there are users and (especially!) customers out there 
who actually use old crap, we should provide them with the old crap 
instead of let them alone. Because else they are either never upgrading 
to a new distribution until they are forced by _whatever_ or change 
distribution.

OK. My thinking is more a RH thinking, than a Fedora thinking, because 
I'm actually afraid of loosing RH customers and not that much afraid of 
loosing Fedora userbase... Sorry.

-of



From oliver at linux-kernel.at  Thu Oct 16 08:02:44 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 16 Oct 2008 10:02:44 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224085484.3270.26.camel@localhost.localdomain>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>	<48F5A172.9000405@leemhuis.info>	<1224075473.12340.146.camel@aglarond.local>	<48F60AD7.2020807@leemhuis.info>
	<1224085484.3270.26.camel@localhost.localdomain>
Message-ID: <48F6F524.5060104@linux-kernel.at>

Tom "spot" Callaway wrote:
> On Wed, 2008-10-15 at 17:23 +0200, Thorsten Leemhuis wrote:
>> Well, the world sometimes is not as good as we would like it 
>> to be; we can try our best to fix it, but the task is really really
>> big; 
>> if you nevertheless try to do it you might forget the real goal you 
>> aimed for in the beginning -- if you are not careful you might get 
>> obsoleted and irrelevant on the way.
> 
> I wonder if a fraction of the effort put into building up a parallel
> python branch was put into fixing Zope to work with modern python...
> would we still be worried about compat-python?
> 
> There is a good chance that we'll be looking at Python 3 in a coming
> Fedora release, so Zope will be two major python releases backwards, now
> seems like a great time for interested parties to work towards getting
> Zope working with Python 2.6 (at least).

Spot. If it would be that easy, I would have done this already! Believe 
me. But
a) I'm not a python guru and so it's very hard for *me*
b) Even the Zope guys tried and haven't made much progress yet

See also http://wiki.zope.org/zope3/Zope3UsingPython25 and that's Zope 3.

Well, while it might not be a rocket science, it's for sure *much* more 
work than packaging compat-python + deps.

-of



From oliver at linux-kernel.at  Thu Oct 16 08:33:57 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 16 Oct 2008 10:33:57 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224078695.16958.89.camel@code.and.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>	<20081015073609.GA2795@free.fr>
	<48F5A34C.3090701@linux-kernel.at>
	<1224078695.16958.89.camel@code.and.org>
Message-ID: <48F6FC75.5000806@linux-kernel.at>

James Antill wrote:
> On Wed, 2008-10-15 at 10:01 +0200, Oliver Falk wrote:
> 
>>> In my opinion, instead, packagers should be co-maintaining the main
>>> version when they do a compat package, and that's all.
>> It's python, it's the holy (Fedora/Red Hat) grail. I think only people 
>> on the Red Hat payroll are allowed to commit to python CVS, isn't it? 
>> :-P Sorry, no offense!
> 
>  I've given python co-maintainer ship to the only non-RH person who has
> asked for it. On the other hand, if you seemed sane and I gave it to
> you ... and then you broke python so that Zope could work, I'm not
> likely to be impressed :).

All true. Again, that was no offence.

>> I think the main version packagers should allowed to have commit access 
>> to the compat packages instead. In case compat packager breaks main 
>> version, the main version packager can fix it...
> 
>  That implies we don't mind it being broken for a while ... given how
> important python is we _really_ don't like it breaking in a non-trivial
> way (or eg. yum doesn't work, and you can't update out of your problem)

Of course we don't want to break things. But that's what testing and 
rawhide is good for!

>  Also that's not how the breaks happen, it's not like you get file
> conflicts etc. ... you get multiple dep. providers and there's no way to
> fix that by changing the main python package.

I have not yet thought about the multi dep. providers. My fault. And as 
Hans already stated, it's an rpm fault, but we could work around it. We 
just need to discuss what is the best way to work around it and then 
*do* it. Instead of just saying that this is a problem.

-of



From jonathan at jonmasters.org  Thu Oct 16 08:37:41 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 04:37:41 -0400
Subject: minimum memory requirements
In-Reply-To: <1224144749.11413.11.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
Message-ID: <1224146261.11413.23.camel@perihelion.int.jonmasters.org>

On Thu, 2008-10-16 at 04:12 -0400, Jon Masters wrote:
> On Thu, 2008-10-16 at 10:45 +0300, Aioanei Rares wrote:
> 
> > On Thu, Oct 16, 2008 at 9:13 AM, Jon Masters
> > <jonathan at jonmasters.org> 
> 
> >         I've noticed that a fresh rawhide install is ooming unless I
> >         allocate 512MB to the guest machine that it is running within.
> 
> 
> > Could be beacause of the debuginfo present in rawhide but left out on
> > release.
> 
> Nah. I don't see how that would account for such a difference. This is
> crashing early in the install - prior to partitioning. I'm a bit behind
> in Anaconda phraseology, but this is almost what used to be stage 1,
> except we're running within a 100MB+ ramdisk image with a GUI now.
> 
> Something is using a lot of memory (anaconda) and causing the kernel
> badness calculation to blame it for all the world's evils. I'd love to
> know if others have seen this, especially in F-10 Beta.

FYI,
http://fedoraproject.org/wiki/Docs/Beats/ArchSpecific#Hardware_requirements_for_x86 states that the minimum requirements for x86 are:

* Recommended for text-mode: 200 MHz Pentium-class or better
* Recommended for graphical: 400 MHz Pentium II or better
* Minimum RAM for text-mode: 128MiB
* Minimum RAM for graphical: 192MiB
* Recommended RAM for graphical: 256MiB

I'd dispute the CPU requirements (but that's another subject anyway) but
I'm having to allocate at least 384MB of (virtual) RAM for the system to
not regularly OOM. That seems a little high, even for rawhide. Do the
minimum requirements need updating?

Jon.




From jonathan at jonmasters.org  Thu Oct 16 08:39:37 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 04:39:37 -0400
Subject: minimum memory requirements
In-Reply-To: <1224146261.11413.23.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
Message-ID: <1224146377.11413.26.camel@perihelion.int.jonmasters.org>

On Thu, 2008-10-16 at 04:38 -0400, Jon Masters wrote:

> I'd dispute the CPU requirements (but that's another subject anyway) but
> I'm having to allocate at least 384MB of (virtual) RAM for the system to
> not regularly OOM. That seems a little high, even for rawhide. Do the
> minimum requirements need updating?

Gah, ignore me. I meant to install i386 earlier but wound up installing
an x86_64 image which accounts for the difference. And the docs agree
fully with my subsequent experience :)

Jon.




From oliver at linux-kernel.at  Thu Oct 16 08:46:11 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 16 Oct 2008 10:46:11 +0200
Subject: compat-python, Zope...
In-Reply-To: <1224078305.16958.82.camel@code.and.org>
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>
	<48F47C58.9060702@linux-kernel.at>	<1223988009.16958.51.camel@code.and.org>	<48F596F2.6000902@linux-kernel.at>
	<1224078305.16958.82.camel@code.and.org>
Message-ID: <48F6FF53.8050509@linux-kernel.at>

James Antill wrote:
> On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
>> James Antill wrote:
>> [ ... ]
>>>> I can think of a Python 2.4 package that lives within the Zope tree to 
>>>> make it extra hard for others to use it by accident - but I don't think 
>>>> that this would be neat, seen from a FHS point of view.
>>>  In some ways this might be doable, at least it has less pain points
>>> than packaging it "properly".
>> I'm not sure what you mean here? Do you mean with properly an 
>> /usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to 
>> invite everybody to have a look at the livna packages. Those are fine 
>> and don't hurt the main python...
> 
> % repoquery --repoid=livna --provides compat-python24-imaging      
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)
> compat-python24-imaging = 1.1.6-1.lvn9
> % repoquery --provides python-imaging               
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)
> python-imaging = 1.1.6-9.fc9
> % repoquery --repoid=livna --provides compat-python24-lxml   
> compat-python24-lxml = 2.0.5-1.lvn9
> etree.so()(64bit)
> objectify.so()(64bit)
> pyclasslookup.so()(64bit)
> % repoquery --provides python-lxml
> etree.so()(64bit)
> objectify.so()(64bit)
> pyclasslookup.so()(64bit)
> python-lxml = 2.0.8-1.fc9
> 
> ...those are all "wrong", in that you can get cross python/python24
> provides/requires.

Oh yes. I've not yet thought about this problem and it's my fault. It's 
good this problem was brought up and now we can discuss about possible 
solutions.

>>  > and you need to
>>> make sure that python-foo doesn't pull in compat-python24-bar (and vice
>>> versa).
>> Hm. How should that happen? Especially with koji....
> 
>  Well that's a big question, the simplest solution we've come up with is
> "don't package python24" ... 

"Don't package it" is *not a solution*! It's about don't worrying about 
the problem and don't invest time on finding a solution!

 > hence my text about that if everything was
> kludged into Zope itself (and all the provides removed) it would be
> better, in some ways.

Well. What if some additional module, like pil, psycopg is needed? You 
want the Zope package maintainer to put it into the Zope package and 
release a new build?

Let me do some time travel:
#bash compat-zope/F-10] make upload FILES=python-psycopg*gz
#bash compat-zope/F-10] vi compat-zope.spec
#bash compat-zope/F-10] cvs commit -m"* Update psycopg"
#bash compat-zope/F-10] koji build
... wait ...
... wait ...
#bash root] yum --enablerepo=testing update compat-zope
...
Total download size: 24 MB
Is this ok [y/N]:

Duh? I don't to see this happen. :-)

We should better find a way to work around the dependency problematic. 
Eg. patching rpm (long term solution), packaging compat-python + modules 
without AutoProv or prefixing the automatically generated deps with 
_whatever_.

-of



From schaiba at gmail.com  Thu Oct 16 08:47:11 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Thu, 16 Oct 2008 11:47:11 +0300
Subject: minimum memory requirements
In-Reply-To: <1224146377.11413.26.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
Message-ID: <778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>

On Thu, Oct 16, 2008 at 11:39 AM, Jon Masters <jonathan at jonmasters.org>wrote:

> On Thu, 2008-10-16 at 04:38 -0400, Jon Masters wrote:
>
> > I'd dispute the CPU requirements (but that's another subject anyway) but
> > I'm having to allocate at least 384MB of (virtual) RAM for the system to
> > not regularly OOM. That seems a little high, even for rawhide. Do the
> > minimum requirements need updating?
>
> Gah, ignore me. I meant to install i386 earlier but wound up installing
> an x86_64 image which accounts for the difference. And the docs agree
> fully with my subsequent experience :)
>
> Jon.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Either way, I think you're right...the req's are kinda high...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/475ccd7d/attachment.htm>

From oliver at linux-kernel.at  Thu Oct 16 08:48:08 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 16 Oct 2008 10:48:08 +0200
Subject: compat-python, Zope...
In-Reply-To: <20081015140527.GD3091@free.fr>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<1223988009.16958.51.camel@code.and.org>	<48F596F2.6000902@linux-kernel.at>	<1224078305.16958.82.camel@code.and.org>
	<20081015140527.GD3091@free.fr>
Message-ID: <48F6FFC8.6030609@linux-kernel.at>

Patrice Dumas wrote:
> On Wed, Oct 15, 2008 at 09:45:05AM -0400, James Antill wrote:
>> _imaging.so()(64bit)
>> _imagingft.so()(64bit)
>> _imagingmath.so()(64bit)
> 
> These kind of provides are simply wrong (in my opinion). rpm provides
> script should only get the sonames automatically. Other people disagree
> because it is what the elf linker does. See also:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=224544

Wrong, well, not totally (yes, ld rules!), but in our case it's just a 
pain point, where we need to find a solution...

-of



From oliver at linux-kernel.at  Thu Oct 16 09:07:37 2008
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 16 Oct 2008 11:07:37 +0200
Subject: compat-python, Zope...
In-Reply-To: <48F4630E.7030002@linux-kernel.at>
References: <48F4630E.7030002@linux-kernel.at>
Message-ID: <48F70459.4060101@linux-kernel.at>

fyi. FESCo voted against compat-python:

 > We discussed this in today's FESCo meeting, and voted against your
 > proposal to include a compat-python24 in Fedora.  We felt that nothing
 > had changed since our original decision, and if anything the argument
 > was even stronger for it's exclusion since it's been more than a year
 > and a half and Zope/Plone is still dependent on python-2.4.
 >
 >  If you would like to review the full discussion we had on this, you
 > can find the irc log here:
 > http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-15.html

-of



From j.w.r.degoede at hhs.nl  Thu Oct 16 09:11:04 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 16 Oct 2008 11:11:04 +0200
Subject: compat-python, Zope...
In-Reply-To: <alpine.DEB.1.10.0810160839390.11642@gotcha.dreamhost.com>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<1223988009.16958.51.camel@code.and.org>	<48F596F2.6000902@linux-kernel.at>	<1224078305.16958.82.camel@code.and.org>
	<48F5FFD7.5050908@hhs.nl>
	<alpine.DEB.1.10.0810160839390.11642@gotcha.dreamhost.com>
Message-ID: <48F70528.1030802@hhs.nl>

Panu Matilainen wrote:
> On Wed, 15 Oct 2008, Hans de Goede wrote:
> 
>> James Antill wrote:
>>> On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
>>>> James Antill wrote:
>>>> [ ... ]
>>>>>> I can think of a Python 2.4 package that lives within the Zope 
>>>>>> tree to make it extra hard for others to use it by accident - but 
>>>>>> I don't think that this would be neat, seen from a FHS point of view.
>>>>>  In some ways this might be doable, at least it has less pain points
>>>>> than packaging it "properly".
>>>> I'm not sure what you mean here? Do you mean with properly an 
>>>> /usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to 
>>>> invite everybody to have a look at the livna packages. Those are 
>>>> fine and don't hurt the main python...
>>>
>>> % repoquery --repoid=livna --provides compat-python24-imaging 
>>> _imaging.so()(64bit)
>>> _imagingft.so()(64bit)
>>> _imagingmath.so()(64bit)
>>> compat-python24-imaging = 1.1.6-1.lvn9
>>> % repoquery --provides python-imaging               _imaging.so()(64bit)
>>> _imagingft.so()(64bit)
>>> _imagingmath.so()(64bit)
>>
>> Yes rpmbuild is very broken in that it generates provides for .so 
>> files which are not under libdir, so plugins for applications / libs / 
>> languages can have conflicting Provides, luckily nothing should ever 
>> Require these plugins.
> 
> If something requires / can require them, how can they be "wrong"?

Its all about namespaces, normal libraries all share a common namespace, so all 
sonames (or filenames when the lib lacks a soname) in the standard library 
path, or in additional library paths added through /etc/ld.so.conf.d must be 
unique as they share one namespace.

Plugins otoh which should be and usually are installed outside of the regular 
library path, do not have to have a unique soname (or filename) and often 
don't, basicly every applications which uses plugings has its own plugin 
namespace usually under %{_libdir}/%{name}. Having these plugins have provides 
like foo_plugin(soname) is fine having them provide just soname is wrong, as 
these provides provide stuff in a *completely different namespace*

> Not that I disagree

Glad you agree :) So if we agree that doing soname provides for things like 
plugins is wrong as it polutes the library provide namespace with non library 
provides. Lets start looking at a solution.

> The above are silly and completely useless for all 
> I can tell. But how is rpmbuild going to know what's a real library and 
> what's not? %{_libdir} vs outside it is not going to work

I disagree, as your numbers and explanation below shows using a having 
DT_SONAME or not check does not work. Only doing soname provides generation for 
so files under /%{_lib} and %{_libdir} clearly is the right thing to do. Sure 
some stuff will break, and I understand that you are afraid of that, but those 
things are exceptions, lets first get the generic case right, which clearly is 
to only do soname provides for files directly under /%{_lib} and %{_libdir} and 
then start worrying about exceptions.

 > as it'd cause
> perfectly legal uses of /etc/ld.so.conf.d

/etc/ld.so.conf.d is special and most uses of it can be handled automatically 
by rpmbuild. In most (all?) cases where /etc/ld.so.conf.d gets used the 
libraries installed in the path listed in /etc/ld.so.conf.d/foo, are part of 
the same (sub)package as /etc/ld.so.conf.d/foo, so we can patch (hack) the 
rpmbuild dependency generator(s both intern and extern) to see if there are 
files under /etc/ld.so.conf.d in the subpackage and if there are get the paths 
from them and add those to the path to search for soname provides.

Thinking about this more, there might be exceptions here, so we may not even 
want to do this hack, as we will need a mechanism for special cases anyway, so 
I would like to suggest to solve all special cases like /etc/ld.so.conf.d using 
the following:

1) Add a soname_provides_search_path %define, which defaults to:
    "/%{_lib}:%{libdir}"
2) Allow spec files to redefine this (to add additional paths to search) and
    make sure we use the specfile defined version if present when generating
    Provides

This mechanism can be used to handle any special cases no matter how exotic, 
while keeping rpmbuild all nice and clean.

We could the do a full install see what is under /etc/ld.so.conf.d and file 
bugs against all packages putting files there to warn them that they should 
start redefining soname_provides_search_path because rpmbuild will no longer 
search the entire world for soname provides.

 > and LD_LIBRARY_PATH (both of
> which are runtime, not buildtime configuration items) to break.

Using LD_LIBRARY_PATH in packages is usually evil, and where it isn't the 
user/developer apparently does not want the soname's in that dir to always be 
part of the global library namespace, in which case the sonames in that dir 
certainly do not belong in the global library Provides namespace.

Again this is al about namespaces (a concept which rpm Provides sorely lack, 
but thats a different discussion).

> The question to me is: is there a way to *realiably* detect dlopen()'ed 
> modules from real libraries? There are a number of possible hints that 
> can be looked at, such as having DT_SONAME or not but AFAICT, it's all 
> just guesswork. Since the elf linker doesn't require DT_SONAME for 
> shared libraries, we'd break the dependency resolution of valid uses if 
> we filtered those out from provides generation.
> 
> As there doesn't seem to be hard rules (feel free to prove me wrong)

There is one hard rule: libraries are to be installed in the default library 
path searched by /lib[64]/ld-linux.so.2

Everything which does not do that (like qt3) is an ugly hack (as qt4 has 
proven), an exception, and one should never optimize for the exceptions.

> we 
> can detect at build-time, then heuristics + manual overrides is the best 
> we can get.
 >
 > One possibility is a build configuration flag that allows
> switching off generation of provides for DSO's without DT_SONAME, flip 
> that on in redhat-rpm-config and rebuild what's necessary. That'd be 
> essentially a one-liner patch to rpm.
> 
> Just to get an idea of what that would "gain": On my F9 + selected bits 
> from rawhide system, the number of DSO's in /%{_lib}, %{_libdir} and 
> their subdirectories is 3385. Roughly one third of them don't have 
> DT_SONAME set. Looking at the remaining ~2000, there's a lot of 
> "unnecessary" stuff left still.
> But then, libtool seems to be putting soname into things built with 
> -module which makes the DT_SONAME test kinda moot already.
> 

The whole quote directly above indicates this is the wrong solution, as its a 
half baked solution at best.

The proper solution is really easy we need to only generate soname provides for 
files in the default library path, and add a mechanism (as proposed above) for 
corner cases to modify this behaviour from the specfile.

Let me repeat: I understand that you are afraid of breaking things, but I don't 
think it will be that bad. As always I'm willing to put my time where my mouth 
is, so if we do this for F11 (and pretty please do) I'm more then willing to 
help fixing up any fall out, hell you may asign any bugs you get filed about 
this change to me and I'll handle them (anything to get this mess fixed up once 
and for all).

Regards,

Hans



From giallu at gmail.com  Thu Oct 16 09:14:26 2008
From: giallu at gmail.com (Gianluca Sforna)
Date: Thu, 16 Oct 2008 11:14:26 +0200
Subject: minimum memory requirements
In-Reply-To: <1224144749.11413.11.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
Message-ID: <d5ad21470810160214q1a700189hd63e982752f53dc3@mail.gmail.com>

On Thu, Oct 16, 2008 at 10:12 AM, Jon Masters <jonathan at jonmasters.org> wrote:
> Something is using a lot of memory (anaconda)

I read NetworkManager is being integrated in anaconda. Maybe related?


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From kevin.kofler at chello.at  Thu Oct 16 09:59:33 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 16 Oct 2008 09:59:33 +0000 (UTC)
Subject: compat-python, Zope...
References: <48F4630E.7030002@linux-kernel.at>	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>	<20081014092146.1696d636@ohm.scrye.com>	<48F59905.50206@linux-kernel.at>
	<48F5A172.9000405@leemhuis.info>
	<1224075473.12340.146.camel@aglarond.local>
	<48F6FB54.1080909@linux-kernel.at>
Message-ID: <loom.20081016T095605-731@post.gmane.org>

Oliver Falk <oliver <at> linux-kernel.at> writes:
> but if they decide to upgrade their base OS, they have to install 
> python + deps manually from tarball

Why are you intentionally ignoring RPM Fusion as an option? RPM Fusion even has 
a section for RHEL, so it's quite likely that compat-zope for EL6 will also 
show up there if it's not included in EL6 (and if not, nothing prevents you 
from maintaining it there).

        Kevin Kofler



From rawhide at fedoraproject.org  Thu Oct 16 10:05:09 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 16 Oct 2008 10:05:09 +0000 (UTC)
Subject: rawhide report: 20081016 changes
Message-ID: <20081016100510.0E8411B8001@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct 16 06:01:17 UTC 2008

New package darkice
        Live audio streamer
New package drascula
        Drascula: The Vampire Strikes Back
New package perl-DBD-Multi
        DB Proxy with failover and load balancing
New package perl-Net-SMTP-SSL
        SSL support for Net::SMTP
New package un-extra-fonts
        Un Extra family of Korean TrueType fonts
Updated Packages:

alex-2.3-1.fc10
---------------
* Mon Oct 13 18:00:00 2008 Bryan O'Sullivan <bos at serpentine.com> - 2.3-1
- Update to 2.3

* Thu May 29 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.2-3
- fix license tag


amarok-1.92.2-1.fc10
--------------------
* Wed Oct 15 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.92.2-1
- 1.92.2


cairo-dock-1.6.3-0.1.svn1353_trunk.fc10
---------------------------------------
* Thu Oct 16 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1353


clustermon-0.15.0-6.fc10
------------------------
* Wed Oct 15 18:00:00 2008 Ryan McCabe <rmccabe at redhat.com> 0.15.0-6
- Don't make failing to update the cluster version a fatal error when trying to set a new configuration file.


clutter-gtk-0.8.2-1.fc10
------------------------
* Wed Oct 15 18:00:00 2008 Allisson Azevedo <allisson at gmail.com> 0.8.2-1
- Update to 0.8.2


eclipse-cdt-5.0.0-7.fc10
------------------------
* Wed Oct 15 18:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 5.0.0-7
- Change to use new linuxtools version of autotools-1.0.1.
- Add build of libhover plugins again from linuxtools.


gambit-c-4.2.9-1.fc10
---------------------
* Tue Oct 14 18:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 4.2.9-1
- Update to 4.2.9
- Disable Termite for now; still broken
- When built on EL-5, depend directly on emacs binary rather than emacs(bin)


gdm-2.24.0-10.fc10
------------------

gpodder-0.13.0-1.fc10
---------------------
* Thu Oct  9 18:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> 0.13.0-1
- 0.13 Series

* Sun Aug 10 18:00:00 2008 Jef Spaleta <jspaleta AT fedoraproject DOT org> 0.12.2-1
- Bugfix release of the 0.12.x series


hellanzb-0.13-6.fc10
--------------------
* Wed Oct 15 18:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 0.13-6
- Don't allow multiple groups as support for that is broken.


ibus-0.1.1.20081016-1.fc10
--------------------------
* Thu Oct 16 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081016-1
- Update to 0.1.1.20081016.


ibus-m17n-0.1.1.20081013-3.fc10
-------------------------------
* Thu Oct 16 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.1.1.20081013-3
- move the .engine files to m17n-db and m17n-contrib (#466410)


krusader-2.0.0-0.1.beta1.fc10
-----------------------------
* Thu Oct 16 18:00:00 2008 Marcin Garski <mgarski[AT]post.pl> 2.0.0-0.1.beta1
- Update to 2.0.0-beta1


liferea-1.4.20-2.fc10
---------------------
* Wed Oct 15 18:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 1.4.20-2
- Add missing patch file

* Wed Oct 15 18:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 1.4.20-1
- New upstream release and fix for #467083


m17n-contrib-1.1.7-4.fc10
-------------------------
* Wed Oct 15 18:00:00 2008 Parag Nemade <pnemade at redhat.com> - 1.5.2-4
- create .engine files for ibus-m17n with m17n-gen-ibus-engine (#466410)


m17n-db-1.5.2-3.fc10
--------------------
* Wed Oct 15 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 1.5.2-3
- create .engine files for ibus-m17n with m17n-gen-ibus-engine (#466410)


man-pages-ja-20081015-1.fc10
----------------------------
* Thu Oct 16 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 20081015-1
- updates to 20081015.


manedit-1.2.1-1.fc10
--------------------
* Thu Oct 16 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.2.1-1
- 1.2.1


merkaartor-0.12-2.fc10
----------------------
* Wed Oct 15 18:00:00 2008 Sven Lankes <sven at lank.es> - 0.12-2
- remove additional source merkaartor.xpm - now included
- minor update of .desktop-file


mkinitrd-6.0.67-1.fc10
----------------------
* Wed Oct 15 18:00:00 2008 Jeremy Katz <katzj at redhat.com> - 6.0.67-1
- Fix various live initrd + plymouth interactions
- Allow resetting the overlay at boot time for live initrd
- Don't make the eject failure with the live_ram case fatal (#466114)


mock-0.9.12-1.fc10
------------------
* Tue Oct 14 18:00:00 2008 Clark Williams <williams at redhat.com> - 0.9.12-1
- internal setarch support for s390/s390x (mikem)
- Refer to the .newkey location of current Fedora 8/9 updates. (jkeating)
- [bz458234] Picked up corrected patch (pmatilai)


nted-1.3.3-1.fc10
-----------------
* Wed Oct 15 18:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.3.3-1
- Update to upstream's 1.3.3 release.


ntfs-3g-1.5012-1.fc10
---------------------
* Wed Oct 15 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2:1.5012-1
- update to 1.5012 (same code as 1.2926-RC)


pitivi-0.11.2-1.fc10
--------------------
* Wed Oct 15 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.2-1
- Update to 0.11.2


plymouth-0.6.0-0.2008.10.15.1.fc10
----------------------------------
* Wed Oct 15 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.10.15.1
- Don't free windows on --hide-splash (fix from Jeremy)


publican-0.38-0.fc10
--------------------
* Thu Oct 16 18:00:00 2008 Jeff Fearn <jfearn at redhat.com> 0.38
- Fix inline tags removing following new line in verbatim tags. BZ #461369
- Fix Numeration settings for HTML ordered lists. BZ #462601
- Fix PDF Example background color. BZ #463127
- Fix list item spacing. BZ #462673
- Fix translation report error on 2 charater langs, CSS, and layout. BZ #465201
- Added error for tgroup.cols not matching entry count. BZ #462205
- Fix TOC padding for appendix and glossary. BZ #462991
- Made comments in highlighted code more prominent. BZ #462552
- Added citerefentry, refentrytitle, and manvolnum to list of QA'd tags. BZ #464038
- Fixed '1' in ulink with no text. BZ #465411
- Change env path to be more portable. Patch by Artem Zolochevskiy . BZ #466194
- Added package meta to XHTML to allow content to be tracked to an RPM.
- Added catch for missing title and productname.
- Changed Formal Para Title to follow parent indent. BZ #466309
- Fix xmlClean not handling entity names with underscores or numbers. BZ #466994
- Fix clean_ids removing comments. BZ #467145
- Fix missing revhistory giving useless error. BZ #467147
- Stopped proecssing xml files in extras directory.
- Added conditional tagging to user Guide. By Don Domingo.


python-prioritized-methods-0.2.1-2.fc10
---------------------------------------
* Wed Oct 15 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.2.1-2
- Fix our python-peak-rules dependency


ricci-0.15.0-6.fc10
-------------------
* Wed Oct 15 18:00:00 2008 Ryan McCabe <rmccabe at redhat.com> 0.15.0-6
- When setting a cluster.conf file with ccs_sync, only try to update the cman cluster version if the node is a member of a cluster.


scim-1.4.7-35.fc10
------------------
* Thu Oct 16 18:00:00 2008 Huang Peng <phuang at redhat.com> - 1.4.7-35
- Read data from WindowProperty properly (#466657) by Tagoh.


selinux-policy-3.5.12-2.fc10
----------------------------
* Wed Oct 15 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.12-2
- Fix labeling of libGL


setroubleshoot-2.0.12-1.fc10
----------------------------
* Wed Oct 15 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> - 2.0.12-1
- Update to upstream
  - 2008-10-06  Dan Walsh <dwalsh at redhat.com>
	- remove .png from desktop files


setroubleshoot-plugins-2.0.9-1.fc10
-----------------------------------
* Wed Oct 15 18:00:00 2008 <dwalsh at redhat.com> - 2.0.9-1
- Fix catchall_plugin


solar-backgrounds-0.90.0-1.fc10
-------------------------------
* Wed Oct 15 18:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.90.0-1
- New release, adds dual screen wallpapers


system-config-printer-1.0.8-5.fc10
----------------------------------

telepathy-gabble-0.7.10-1.fc10
------------------------------
* Wed Oct 15 18:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.10-1
- Update to 0.7.10.


tuxguitar-1.0-8.fc10
--------------------
* Wed Oct 15 18:00:00 2008 Orcan Ogetbil <orcanbahri[AT]yahoo[DOT]com> - 1.0-8
- Enabled the PDF plugin since all the dependencies are now provided in repos


Summary:
Added Packages: 5
Removed Packages: 0
Modified Packages: 36
Broken deps for i386
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From jonathan at jonmasters.org  Thu Oct 16 10:21:17 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 06:21:17 -0400
Subject: minimum memory requirements
In-Reply-To: <778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
Message-ID: <1224152477.6400.2.camel@londonpacket.bos.redhat.com>

On Thu, 2008-10-16 at 11:47 +0300, Aioanei Rares wrote:

>         
>         Gah, ignore me. I meant to install i386 earlier but wound up
>         installing
>         an x86_64 image which accounts for the difference. And the
>         docs agree
>         fully with my subsequent experience :)


> Either way, I think you're right...the req's are kinda high...

Well, yes. I will do an i386 install later and compare. I don't really
blame the *x86_64* figures for being so high, largely because any system
featuring an x86_64 probably never had less than 256MB RAM and 512MB
really isn't all that much to be expecting these days. It'd just be
nicer if we could install in a virtual machine with less allocated.

Jon.




From schaiba at gmail.com  Thu Oct 16 10:54:08 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Thu, 16 Oct 2008 13:54:08 +0300
Subject: minimum memory requirements
In-Reply-To: <1224152477.6400.2.camel@londonpacket.bos.redhat.com>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
Message-ID: <778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>

On Thu, Oct 16, 2008 at 1:21 PM, Jon Masters <jonathan at jonmasters.org>wrote:

> On Thu, 2008-10-16 at 11:47 +0300, Aioanei Rares wrote:
>
> >
> >         Gah, ignore me. I meant to install i386 earlier but wound up
> >         installing
> >         an x86_64 image which accounts for the difference. And the
> >         docs agree
> >         fully with my subsequent experience :)
>
>
> > Either way, I think you're right...the req's are kinda high...
>
> Well, yes. I will do an i386 install later and compare. I don't really
> blame the *x86_64* figures for being so high, largely because any system
> featuring an x86_64 probably never had less than 256MB RAM and 512MB
> really isn't all that much to be expecting these days. It'd just be
> nicer if we could install in a virtual machine with less allocated.
>
> Jon.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

x86_64 requires more disk space/RAM because of the libraries. But it still
would be nice if
we could come up with some idea to un-bloat various aspects in Fedora,
aspects which
attract a somehow negative image upon the distribution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/aa33ecd7/attachment.htm>

From alsadi at gmail.com  Thu Oct 16 12:04:25 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 16 Oct 2008 15:04:25 +0300
Subject: default XFCE layout
In-Reply-To: <48F6B628.3010603@fedoraproject.org>
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
	<20081011152620.5c57cb26@ohm.scrye.com>
	<385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>
	<1224119807.13994.48.camel@wicktop.localdomain>
	<48F69870.8070607@fedoraproject.org>
	<1224123519.13994.90.camel@wicktop.localdomain>
	<48F6B628.3010603@fedoraproject.org>
Message-ID: <385866f0810160504y53b89fe3s62dc5a024cfe5f86@mail.gmail.com>

> We have several tweaks in the panel configuration (trash, mailwatch,
> etc) but we [1] want the basic panel layout (top and bottom panel) to
> follow upstream.
the upstream was not happy by trying to move this discussion to their ML
they say that layout is a branding issue and me trying to upstream
that is like claiming to be "I'm always right"

> Upstreaming is for sending patches to upstream. You are talking about branding.

http://foo-projects.org/pipermail/xfce/2008-October/024007.html
http://foo-projects.org/pipermail/xfce/2008-October/024022.html
http://foo-projects.org/pipermail/xfce/2008-October/024027.html
http://foo-projects.org/pipermail/xfce/2008-October/024037.html

as a summary
many liked it
some says that ubuntu uses a gnome-like two panels
http://foo-projects.org/pipermail/xfce/2008-October/024002.html
http://foo-projects.org/pipermail/xfce/2008-October/024007.html
some say it can be easily changed by users so there is no point to change it
some suggest having a first-login layout chooser
and some say that Xfce default layout is not optimal but it's made so
to make gnome users unhappy and to make CDE geeks happy
http://foo-projects.org/pipermail/xfce/2008-October/023987.html
and some summaries it like this <<EOF
The advantages and disadvantages of setups as I know of now:

 = Two panels =
 + Makes optimal use of the screen corners.
 + Gives the task list enough space on resolutions that are not that wide.
 - Uses more vertical screen real estate.

 = One panel =
 + Saves screen real estate (given that the one panel is not that big like
it is with e.g. KDE) for resolutions that are not that high (which might
occur with the new netbooks which have enough horizontal space due to the
website problem I mentioned above, but are saving on vertical space).
 - Might cause clutter in the panels when too many items are added.

 = Vertical panel(s) =
 - Distorts websites
 - Makes the task list less easy to read
EOF
http://foo-projects.org/pipermail/xfce/2008-October/023974.html

> Nirik has only one account. There is no kaven and kevin is Kevin Kofler.
I was mislead by zodbot

alsadi: .whoowns xfce4-panel
zodbot: alsadi: kevin

http://www.xubuntu.org/files/thunar.png

> Well, since you included me in that conversation, I would like to note that the simple layout changes suggested here usually do not require invasive patches and can easily be maintained which is one of the usual pain points otherwise but I do not maintain any Xfce package and just the Xfce spin/live cd so this is upto others to decide.

yes it's very simple, It's just to copy the panels .rc files in the right folder
(make the session you love then copy ~/.config/xfce4/panel/ files to
/etc/xdg/xfce4/panel/)

the upstream says that their users are the tarball users who can
compile Xfce not Windows converts who are using Linux for desktop,
that's why they will continue with the CDE layout
but the question now, is Fedora intended for such people [ie. CDE geeks]

please if you decide to keep the upstream CDE styled layout, please
put the defaults in a subpackage so that spinners like me could
replace it
%files default
/etc/xdg/xfce4/panel/*.rc
/etc/xdg/xfce4/panel/*.xml



From kushaldas at gmail.com  Thu Oct 16 12:39:48 2008
From: kushaldas at gmail.com (Kushal Das)
Date: Thu, 16 Oct 2008 18:09:48 +0530
Subject: review-o-matic : Fedora package review helper
Message-ID: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>

Hi all,

I am starting a project called review-o-matic which will do reviews of
Fedora packages based on discussions at
https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html.
We know of having couple of scripts being used by different people to
do so, but this tool's target is to consolidate those efforts and add
a number of additional features as well. The basic idea is to remove
the grunt work from package reviews.

Wishlist:

Run rpmlint
Build the package in mock
verify the md5sum of upstream source matches what is in the srpm
<your ideas here>

Workflow:

The instance you submit a new review request, this tool will
automatically do the following:

* Download SRPM and SPEC as soon as new package review get submitted.
* Do a review , post it on bugzilla and also keep track to show on own
web front end
* People can upload their SRPS to the system to get a review done by the system.

Kushal
-- 
http://fedoraproject.org
http://kushaldas.in



From harald at redhat.com  Thu Oct 16 12:42:46 2008
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 16 Oct 2008 14:42:46 +0200
Subject: No more MAKEDEV?
In-Reply-To: <20080919172851.31cfd30a@infradead.org>
References: <20080919004112.GB8478@nostromo.devel.redhat.com>
	<20080919172851.31cfd30a@infradead.org>
Message-ID: <48F736C6.3030904@redhat.com>

Arjan van de Ven wrote:
> On Thu, 18 Sep 2008 17:41:12 -0700
> Bill Nottingham <notting at redhat.com> wrote:
> 
>> Looking at some of the inefficiencies in bootup (in regards to the 5
>> second Fedora boot), we came across MAKEDEV. To be short - it's a pig.
>>
>> The only user of it in Fedora is udev, which uses it for entries in
>> /etc/udev/makedev.d. However, there's an already-upstream solution
>> of putting device nodes in /lib/udev/devices. Why not just use this,
>> remove MAKEDEV, simplify start_udev, and boot faster?
> 
> this btw can be done in two steps; 
> Step 1) Put the standard static device nodes in /lib/udev/devices
> Step 2) Once MAKEDEV no longer is used as a result, obsolete it
> 
> Step 1) is obviously simple and can be done with no risk ... and will
> in practice make MAKEDEV unused and gives you the boottime gain


I switched from /lib/udev/devices to MAKEDEV!

Complaints have been filed in bugzilla, because /lib should not contain devices.
a
# grep -r foo /lib
could do harm!

selinux does not like devices in /lib also.



> 
> Step 2) can be done later... to make people who guard freezes less
> nervous
> 
> 



From cmadams at hiwaay.net  Thu Oct 16 12:48:35 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 16 Oct 2008 07:48:35 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <1224134627.3029.631.camel@beck.corsepiu.local>
References: <20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
	<1224132824.3029.628.camel@beck.corsepiu.local>
	<1224133520.4122.64.camel@luminos.localdomain>
	<1224134627.3029.631.camel@beck.corsepiu.local>
Message-ID: <20081016124835.GA1269041@hiwaay.net>

Once upon a time, Ralf Corsepius <rc040203 at freenet.de> said:
> On Wed, 2008-10-15 at 22:05 -0700, Jesse Keating wrote:
> > On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
> > > I guess, you will apply the same rationale when EPEL6 comes out?
> > 
> > EPEL currently has people filling this role.
> You mean, RH's hegemony is taking care about it and has allocated
> budgets.

Why are you here if you have so little faith in Red Hat and their
alleged ulterior motives?
-- 
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 harald at redhat.com  Thu Oct 16 12:49:18 2008
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 16 Oct 2008 14:49:18 +0200
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <1223911882.4264.65.camel@perihelion.int.jonmasters.org>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>	<20081001172038.GG10632@phobos.i.cabal.ca>	<1223905937.4264.46.camel@perihelion.int.jonmasters.org>	<20081013141001.GE29476@tyan-ft48-01.lab.bos.redhat.com>	<1223907879.4264.51.camel@perihelion.int.jonmasters.org>
	<1223911882.4264.65.camel@perihelion.int.jonmasters.org>
Message-ID: <48F7384E.4080605@redhat.com>

Jon Masters wrote:
> On Mon, 2008-10-13 at 10:24 -0400, Jon Masters wrote:
>> On Mon, 2008-10-13 at 16:10 +0200, Jakub Jelinek wrote:
>>
>>> FYI, here is a tiny incremental fix for the patch I've posted earlier
>>> - Mandriva folks reported that with my patch depmod was upset when run
>>> on a tree with no modules at all.
>> :) Though if we ever manage to "demodularize for the win" to that point,
>> well, it'll be quite exciting!
>>
>> I'm testing your 3.4.1 patch against today's 3.5 tree and will followup
>> with some results. Whichever performs best, I'll keep. Sorry I didn't
>> sort this out sooner, but it's time to move forward and get this sorted
>> out - and there are more trivial fixes I've got in mind. As of today's
>> rawhide there are also no longer any Fedora-specific patches left.
> 
> In one test, I ran modprobe about 8000 times on a desktop.
> 
> older modprobe:       190.03user 25.19system 3:55.54elapsed 91%CPU
> upstream modprobe:      8.65user 19.69system 0:31.08elapsed 91%CPU
> Jakob's modprobe:       6.71user 18.05system 0:27.01elapsed 91%CPU
> 
> The latter two vie a little between each other, but basically are
> comparable. So for now, I'll keep upstream as it is and do some more
> testing/write some scripts. Then I'll do some migration to unlocked
> non-threaded functions and pull in other parts of Jakob's patch. I'm
> thinking there are actually other places to focus on now - more
> profiling will be called for and I'll push some more updates.
> 
> Older modprobe is 3.4.1, upstream is 3.5 (radix trie implementation),
> Jakob's patch uses a hashtable/bucket mechanism.
> 
> Jon.
> 
> 

modprobe is mostly disk I/O bound, so for benchmarking the disk cache has to be 
cleared before every run



From ivazqueznet at gmail.com  Thu Oct 16 12:58:30 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 16 Oct 2008 08:58:30 -0400
Subject: compat-python, Zope...
In-Reply-To: <48F70528.1030802@hhs.nl>
References: <48F4630E.7030002@linux-kernel.at>
	<48F46AEE.6090005@leemhuis.info>	<48F47C58.9060702@linux-kernel.at>
	<1223988009.16958.51.camel@code.and.org>	<48F596F2.6000902@linux-kernel.at>
	<1224078305.16958.82.camel@code.and.org> <48F5FFD7.5050908@hhs.nl>
	<alpine.DEB.1.10.0810160839390.11642@gotcha.dreamhost.com>
	<48F70528.1030802@hhs.nl>
Message-ID: <1224161910.13861.125.camel@ignacio.lan>

On Thu, 2008-10-16 at 11:11 +0200, Hans de Goede wrote:
> Panu Matilainen wrote:
>  > as it'd cause
> > perfectly legal uses of /etc/ld.so.conf.d
> 
> /etc/ld.so.conf.d is special and most uses of it can be handled automatically 
> by rpmbuild. In most (all?) cases where /etc/ld.so.conf.d gets used the 
> libraries installed in the path listed in /etc/ld.so.conf.d/foo, are part of 
> the same (sub)package as /etc/ld.so.conf.d/foo, so we can patch (hack) the 
> rpmbuild dependency generator(s both intern and extern) to see if there are 
> files under /etc/ld.so.conf.d in the subpackage and if there are get the paths 
> from them and add those to the path to search for soname provides.

Or, you know, you *could* use this script I wrote years ago:

http://ivazquez.fedorapeople.org/files/parseldconfig

-- 
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/20081016/e0b6247e/attachment.sig>

From cra at WPI.EDU  Thu Oct 16 13:04:57 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 16 Oct 2008 09:04:57 -0400
Subject: No more MAKEDEV?
In-Reply-To: <48F736C6.3030904@redhat.com>
References: <20080919004112.GB8478@nostromo.devel.redhat.com>
	<20080919172851.31cfd30a@infradead.org>
	<48F736C6.3030904@redhat.com>
Message-ID: <20081016130457.GE27052@angus.ind.WPI.EDU>

On Thu, Oct 16, 2008 at 02:42:46PM +0200, Harald Hoyer wrote:
> Arjan van de Ven wrote:
> I switched from /lib/udev/devices to MAKEDEV!
>
> Complaints have been filed in bugzilla, because /lib should not contain devices.
> a
> # grep -r foo /lib
> could do harm!
>
> selinux does not like devices in /lib also.

Why can't we put devices in /dev?



From lesmikesell at gmail.com  Thu Oct 16 13:12:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 16 Oct 2008 08:12:14 -0500
Subject: reviving Fedora Legacy
In-Reply-To: <20081016030242.GA20109@jadzia.bu.edu>
References: <20081015113317.GA26690@yoda.jdub.homelinux.org>	<20081015121350.GB3091@free.fr>	<20081015124348.GA27658@yoda.jdub.homelinux.org>	<20081015133453.GC3091@free.fr>	<20081015145109.GD1773@nostromo.devel.redhat.com>	<1224083908.3029.560.camel@beck.corsepiu.local>	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>	<20081015170841.GB2679@free.fr>	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>	<1224092835.4122.45.camel@luminos.localdomain>
	<20081016030242.GA20109@jadzia.bu.edu>
Message-ID: <48F73DAE.4050800@gmail.com>

Matthew Miller wrote:
> On Wed, Oct 15, 2008 at 10:47:15AM -0700, Jesse Keating wrote:
>> along with infrastructure, you need a release engineer.  Somebody who's
>> going to babysit the collections, do buildroot overrides to build chains
>> of packages, do package signing, urge (a) bodhi into pushing the
>> updates, making sure they get rsynced properly, dealing with bug reports
>> about broken deps, so on and so forth.  I say this, because I'm not
>> about to volunteer to do that work for you.  I say this also, because
>> trying to bring somebody in to do these things on the "LTS" section, but
>> isolate that person from the normal section is going to be difficult, if
>> we have to go that route.
> 
> And let's be clear: this alone is a full-time job. Or job and a half.

Ahh, nostalgia for the old days when Freshrpms and a few others were 
one-man shows covering most of the early RH releases and some of the 
fedoras beyond their own supported life - and inventing the way to do 
it.   Maybe you could find a third party site to take over...

-- 
   Les Mikesell
     lesmikesell at gmail.com



From jonathan at jonmasters.org  Thu Oct 16 13:20:42 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 09:20:42 -0400
Subject: [PATCH] Speed up modprobe and MAKEDEV
In-Reply-To: <48F7384E.4080605@redhat.com>
References: <20081001165215.GA32682@tyan-ft48-01.lab.bos.redhat.com>
	<20081001172038.GG10632@phobos.i.cabal.ca>
	<1223905937.4264.46.camel@perihelion.int.jonmasters.org>
	<20081013141001.GE29476@tyan-ft48-01.lab.bos.redhat.com>
	<1223907879.4264.51.camel@perihelion.int.jonmasters.org>
	<1223911882.4264.65.camel@perihelion.int.jonmasters.org>
	<48F7384E.4080605@redhat.com>
Message-ID: <1224163242.6400.35.camel@londonpacket.bos.redhat.com>

On Thu, 2008-10-16 at 14:49 +0200, Harald Hoyer wrote:

> modprobe is mostly disk I/O bound, so for benchmarking the disk cache has to be 
> cleared before every run

Nah. We're not making any claims about magically being able to speed up
the reading/module init itself, only the parsing of the meta data. At
udev coldstart time, the (small) files are likely sitting in the page
cache already anyway. I'm not so worried about how long udev/modprobe
takes once you've booted and insert your $whatever_random_device.

Your point is noted, and I will investigate further, but I'm pretty
convinced that we've got a dramatic speedup here either way. I'll be
pushing a 3.6 release ensuring that the binary files have a version
attached so I can make changes to the format in the future and then
fallback to the text versions of those files automatically.

Cheers,

Jon.




From rc040203 at freenet.de  Thu Oct 16 13:34:59 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 16 Oct 2008 15:34:59 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <20081016124835.GA1269041@hiwaay.net>
References: <20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
	<1224132824.3029.628.camel@beck.corsepiu.local>
	<1224133520.4122.64.camel@luminos.localdomain>
	<1224134627.3029.631.camel@beck.corsepiu.local>
	<20081016124835.GA1269041@hiwaay.net>
Message-ID: <1224164099.3029.679.camel@beck.corsepiu.local>

On Thu, 2008-10-16 at 07:48 -0500, Chris Adams wrote:
> Once upon a time, Ralf Corsepius <rc040203 at freenet.de> said:
> > On Wed, 2008-10-15 at 22:05 -0700, Jesse Keating wrote:
> > > On Thu, 2008-10-16 at 06:53 +0200, Ralf Corsepius wrote:
> > > > I guess, you will apply the same rationale when EPEL6 comes out?
> > > 
> > > EPEL currently has people filling this role.
> > You mean, RH's hegemony is taking care about it and has allocated
> > budgets.
> 
> Why are you here if you have so little faith in Red Hat and their
> alleged ulterior motives?
Who said I don't have faith in RH and their motives?

They are a commercial enterprise and hardly wouldn't sponsor Fedora if
they would not want to profit from it and if they wouldn't want to
conduct it in directions they want it to head to?

Yes, I feel bitter and frustrated about how Fedora evolves, yes, I was
sarcastic, and yes, I am personally disappointed about Jesse Keating and
some other FPB and FESCO folks.






From pingou at pingoured.fr  Thu Oct 16 13:36:27 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 16 Oct 2008 15:36:27 +0200
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
Message-ID: <48F7435B.40203@pingoured.fr>

Kushal Das wrote:
> Hi all,
> 
> I am starting a project called review-o-matic which will do reviews of
> Fedora packages based on discussions at
> https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html.
> We know of having couple of scripts being used by different people to
> do so, but this tool's target is to consolidate those efforts and add
> a number of additional features as well. The basic idea is to remove
> the grunt work from package reviews.
> 
> Wishlist:
> 
> Run rpmlint
> Build the package in mock
> verify the md5sum of upstream source matches what is in the srpm
What about making directly the build on koji ?
It enables to test all version and all arch before the review.

I actually think that we should couple a bit more Koji and the BZ such as
- I submit a review
- I provide a build number from koji (me if I am approved or review-o-matic)
- Koji does not delete this build until the review is done
- When the package is approved (is so), koji remove the build.

Would that be an interesting feature ?

Best regards,

Pierre



From stickster at gmail.com  Thu Oct 16 13:39:47 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 16 Oct 2008 09:39:47 -0400
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <48F7435B.40203@pingoured.fr>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<48F7435B.40203@pingoured.fr>
Message-ID: <1224164388.19681.28.camel@victoria-eth>

On Thu, 2008-10-16 at 15:36 +0200, Pierre-Yves wrote:
> Kushal Das wrote:
> > Hi all,
> > 
> > I am starting a project called review-o-matic which will do reviews of
> > Fedora packages based on discussions at
> > https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html.
> > We know of having couple of scripts being used by different people to
> > do so, but this tool's target is to consolidate those efforts and add
> > a number of additional features as well. The basic idea is to remove
> > the grunt work from package reviews.
> > 
> > Wishlist:
> > 
> > Run rpmlint
> > Build the package in mock
> > verify the md5sum of upstream source matches what is in the srpm
> What about making directly the build on koji ?
> It enables to test all version and all arch before the review.
> 
> I actually think that we should couple a bit more Koji and the BZ such as
> - I submit a review
> - I provide a build number from koji (me if I am approved or review-o-matic)
> - Koji does not delete this build until the review is done
> - When the package is approved (is so), koji remove the build.
> 
> Would that be an interesting feature ?

Would a koji scratch-build work for this purpose?

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   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/20081016/692fcdfb/attachment.sig>

From jonathan at jonmasters.org  Thu Oct 16 13:39:07 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 09:39:07 -0400
Subject: No more MAKEDEV?
In-Reply-To: <48F736C6.3030904@redhat.com>
References: <20080919004112.GB8478@nostromo.devel.redhat.com>
	<20080919172851.31cfd30a@infradead.org> <48F736C6.3030904@redhat.com>
Message-ID: <1224164347.6400.52.camel@londonpacket.bos.redhat.com>

On Thu, 2008-10-16 at 14:42 +0200, Harald Hoyer wrote:
> Arjan van de Ven wrote:
> > On Thu, 18 Sep 2008 17:41:12 -0700
> > Bill Nottingham <notting at redhat.com> wrote:
> > 
> >> Looking at some of the inefficiencies in bootup (in regards to the 5
> >> second Fedora boot), we came across MAKEDEV. To be short - it's a pig.
> >>
> >> The only user of it in Fedora is udev, which uses it for entries in
> >> /etc/udev/makedev.d. However, there's an already-upstream solution
> >> of putting device nodes in /lib/udev/devices. Why not just use this,
> >> remove MAKEDEV, simplify start_udev, and boot faster?
> > 
> > this btw can be done in two steps; 
> > Step 1) Put the standard static device nodes in /lib/udev/devices
> > Step 2) Once MAKEDEV no longer is used as a result, obsolete it
> > 
> > Step 1) is obviously simple and can be done with no risk ... and will
> > in practice make MAKEDEV unused and gives you the boottime gain
> 
> 
> I switched from /lib/udev/devices to MAKEDEV!

Understood. And in answer to Chuck's followup, I think the concern is
that because /dev is going to be mounted over we'd rather store the
static entries someplace else physically outside that mountpoint.

> Complaints have been filed in bugzilla, because /lib should not contain devices.
> a
> # grep -r foo /lib
> could do harm!

That's a validish complaint actually. Maybe a /dev_static or something
is actually called for. Otherwise fun and games with bind mounts.

> selinux does not like devices in /lib also.

Personally, I don't care what the SELinux policy does or doesn't like -
it can and should be adapted to whatever is decided :)

Jon.




From notting at redhat.com  Thu Oct 16 13:45:20 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 16 Oct 2008 09:45:20 -0400
Subject: No more MAKEDEV?
In-Reply-To: <48F736C6.3030904@redhat.com>
References: <20080919004112.GB8478@nostromo.devel.redhat.com>
	<20080919172851.31cfd30a@infradead.org>
	<48F736C6.3030904@redhat.com>
Message-ID: <20081016134520.GE20184@nostromo.devel.redhat.com>

Harald Hoyer (harald at redhat.com) said: 
> I switched from /lib/udev/devices to MAKEDEV!
>
> Complaints have been filed in bugzilla, because /lib should not contain devices.
> a
> # grep -r foo /lib
> could do harm!

loopback can be fixed (they can be allocated on demand.) I'm not sure how
grep of /dev/lp0 can cause issues. 

> selinux does not like devices in /lib also.

Upstream udev supports /lib/udev/devices only, and seemed unwilling to change
from discussions with them.

Bill



From pingou at pingoured.fr  Thu Oct 16 13:46:58 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 16 Oct 2008 15:46:58 +0200
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <1224164388.19681.28.camel@victoria-eth>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>	<48F7435B.40203@pingoured.fr>
	<1224164388.19681.28.camel@victoria-eth>
Message-ID: <48F745D2.7070101@pingoured.fr>

Paul W. Frields wrote:
> On Thu, 2008-10-16 at 15:36 +0200, Pierre-Yves wrote:
>> What about making directly the build on koji ?
>> It enables to test all version and all arch before the review.
>>
>> I actually think that we should couple a bit more Koji and the BZ such as
>> - I submit a review
>> - I provide a build number from koji (me if I am approved or review-o-matic)
>> - Koji does not delete this build until the review is done
>> - When the package is approved (is so), koji remove the build.
>>
>> Would that be an interesting feature ?
> 
> Would a koji scratch-build work for this purpose?
That my though, the only constraints here is for new packager.
Correct me if I am wrong but I think only people from the packager group 
can do a scratch-build.

Best regards,

Pierre



From bkearney at redhat.com  Thu Oct 16 13:45:09 2008
From: bkearney at redhat.com (Bryan Kearney)
Date: Thu, 16 Oct 2008 09:45:09 -0400
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <48F745D2.7070101@pingoured.fr>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>	<48F7435B.40203@pingoured.fr>	<1224164388.19681.28.camel@victoria-eth>
	<48F745D2.7070101@pingoured.fr>
Message-ID: <48F74565.8030007@redhat.com>

Pierre-Yves wrote:
> Paul W. Frields wrote:
>> On Thu, 2008-10-16 at 15:36 +0200, Pierre-Yves wrote:
>>> What about making directly the build on koji ?
>>> It enables to test all version and all arch before the review.
>>>
>>> I actually think that we should couple a bit more Koji and the BZ 
>>> such as
>>> - I submit a review
>>> - I provide a build number from koji (me if I am approved or 
>>> review-o-matic)
>>> - Koji does not delete this build until the review is done
>>> - When the package is approved (is so), koji remove the build.
>>>
>>> Would that be an interesting feature ?
>>
>> Would a koji scratch-build work for this purpose?
> That my though, the only constraints here is for new packager.
> Correct me if I am wrong but I think only people from the packager group 
> can do a scratch-build.
No.. anyone with a FAS account can do a scratch build. I think it would 
be good to encourage scratch builds before reviews are done.

-- bk




From debarshi.ray at gmail.com  Thu Oct 16 13:49:43 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Thu, 16 Oct 2008 19:19:43 +0530
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <1224164388.19681.28.camel@victoria-eth>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<48F7435B.40203@pingoured.fr> <1224164388.19681.28.camel@victoria-eth>
Message-ID: <3170f42f0810160649q475e5285jea352f62333572cd@mail.gmail.com>

>> What about making directly the build on koji ?
>> It enables to test all version and all arch before the review.
>>
>> I actually think that we should couple a bit more Koji and the BZ such as

> Would a koji scratch-build work for this purpose?

Currently Koji's scratch builds get removed after a fixed period of
time. If we can somehow manage to keep the build till the review is
finished, it would be perfect.

Often during the course of a review, the submitter and reviewer work
on fixing some issues which might need fresh builds. To save Koji's
disk space we can override an older build with a newer one.

What do you think?

Cheers,
Debarshi



From pingou at pingoured.fr  Thu Oct 16 13:53:00 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 16 Oct 2008 15:53:00 +0200
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <3170f42f0810160649q475e5285jea352f62333572cd@mail.gmail.com>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>	<48F7435B.40203@pingoured.fr>
	<1224164388.19681.28.camel@victoria-eth>
	<3170f42f0810160649q475e5285jea352f62333572cd@mail.gmail.com>
Message-ID: <48F7473C.8040906@pingoured.fr>

Debarshi Ray wrote:
>>> What about making directly the build on koji ?
>>> It enables to test all version and all arch before the review.
>>>
>>> I actually think that we should couple a bit more Koji and the BZ such as
> 
>> Would a koji scratch-build work for this purpose?
> 
> Currently Koji's scratch builds get removed after a fixed period of
> time. If we can somehow manage to keep the build till the review is
> finished, it would be perfect.
> 
> Often during the course of a review, the submitter and reviewer work
> on fixing some issues which might need fresh builds. To save Koji's
> disk space we can override an older build with a newer one.
> 
> What do you think?

You perfectly got my point.

Should I make a Feature Request on the bugzilla ?

Best regards,

Pierre



From ivazqueznet at gmail.com  Thu Oct 16 13:54:38 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 16 Oct 2008 09:54:38 -0400
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <48F745D2.7070101@pingoured.fr>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<48F7435B.40203@pingoured.fr> <1224164388.19681.28.camel@victoria-eth>
	<48F745D2.7070101@pingoured.fr>
Message-ID: <1224165278.13861.130.camel@ignacio.lan>

On Thu, 2008-10-16 at 15:46 +0200, Pierre-Yves wrote:
> Paul W. Frields wrote:
> > On Thu, 2008-10-16 at 15:36 +0200, Pierre-Yves wrote:
> >> What about making directly the build on koji ?
> >> It enables to test all version and all arch before the review.
> >>
> >> I actually think that we should couple a bit more Koji and the BZ such as
> >> - I submit a review
> >> - I provide a build number from koji (me if I am approved or review-o-matic)
> >> - Koji does not delete this build until the review is done
> >> - When the package is approved (is so), koji remove the build.
> >>
> >> Would that be an interesting feature ?
> > 
> > Would a koji scratch-build work for this purpose?
> That my though, the only constraints here is for new packager.
> Correct me if I am wrong but I think only people from the packager group 
> can do a scratch-build.

Presumably if we automate this to the point where it uses a bot to
"pre-review" then we could just put the bot in the group.

-- 
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/20081016/0d11082f/attachment.sig>

From ivazqueznet at gmail.com  Thu Oct 16 13:57:02 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 16 Oct 2008 09:57:02 -0400
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <3170f42f0810160649q475e5285jea352f62333572cd@mail.gmail.com>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<48F7435B.40203@pingoured.fr> <1224164388.19681.28.camel@victoria-eth>
	<3170f42f0810160649q475e5285jea352f62333572cd@mail.gmail.com>
Message-ID: <1224165422.13861.134.camel@ignacio.lan>

On Thu, 2008-10-16 at 19:19 +0530, Debarshi Ray wrote:
> >> What about making directly the build on koji ?
> >> It enables to test all version and all arch before the review.
> >>
> >> I actually think that we should couple a bit more Koji and the BZ such as
> 
> > Would a koji scratch-build work for this purpose?
> 
> Currently Koji's scratch builds get removed after a fixed period of
> time. If we can somehow manage to keep the build till the review is
> finished, it would be perfect.

Presumably the scripts could check to see if the builds succeeded and
annotate the review appropriately.

-- 
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/20081016/b7c23ce6/attachment.sig>

From debarshi.ray at gmail.com  Thu Oct 16 14:01:00 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Thu, 16 Oct 2008 19:31:00 +0530
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <48F7473C.8040906@pingoured.fr>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<48F7435B.40203@pingoured.fr> <1224164388.19681.28.camel@victoria-eth>
	<3170f42f0810160649q475e5285jea352f62333572cd@mail.gmail.com>
	<48F7473C.8040906@pingoured.fr>
Message-ID: <3170f42f0810160701k5a95b758sad0fff4b4b607d8@mail.gmail.com>

Just for the record, Rakesh Pandit pointed us to this Python script on
the Fedora India mailing list:
http://gauret.free.fr/fichiers/rpms/fedora/fedora-qa

What we found was that rpmlint has incorporated some of the checks
implemented separately by the above script, and that it was generally
old and did not incorporate all the recent modifications made to our
guidelines.

If we can work on correcting these deficiencies, can it serve as the
backend of the "pre-review bot" or "review-o-matic" ?

Cheers,
Debarshi



From nicu_fedora at nicubunu.ro  Thu Oct 16 13:59:30 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 16 Oct 2008 16:59:30 +0300
Subject: New PiTiVi Release!
In-Reply-To: <935ead450810151844t74325336x6ec44d3d87c6123b@mail.gmail.com>
References: <935ead450810151412s201a34eascb51e2ffecd9277f@mail.gmail.com>
	<935ead450810151844t74325336x6ec44d3d87c6123b@mail.gmail.com>
Message-ID: <48F748C2.6060005@nicubunu.ro>

Jeffrey Ollie wrote:
> On Wed, Oct 15, 2008 at 4:12 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
>> Finally, there is a new PiTiVi release and I've built it for F-9 and
>> rawhide.  Please, take a moment to download it and give it a workout.
>> Please report bugs upstream (http://pitivi.org/wiki/Main_Page)
> 
> Until the packages make their way to the mirrors, they can be downloaded here:
> 
> F-10: http://koji.fedoraproject.org/koji/buildinfo?buildID=66472
> F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=66475

I think I am stupid or something, as I am unable to find a way to insert 
an Ogg Theora video and an Ogg Vorbis audio file and render them as one 
Ogg clip with both video and audio...

-- 
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 buc at odusz.so-cdu.ru  Thu Oct 16 14:15:58 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 16 Oct 2008 18:15:58 +0400
Subject: reviving Fedora Legacy
In-Reply-To: <1224164099.3029.679.camel@beck.corsepiu.local>
References: <20081015133453.GC3091@free.fr>	<20081015145109.GD1773@nostromo.devel.redhat.com>	<1224083908.3029.560.camel@beck.corsepiu.local>	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>	<20081015170841.GB2679@free.fr>	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>	<1224092835.4122.45.camel@luminos.localdomain>	<1224132824.3029.628.camel@beck.corsepiu.local>	<1224133520.4122.64.camel@luminos.localdomain>	<1224134627.3029.631.camel@beck.corsepiu.local>	<20081016124835.GA1269041@hiwaay.net>
	<1224164099.3029.679.camel@beck.corsepiu.local>
Message-ID: <48F74C9E.6010308@odu.neva.ru>

Ralf Corsepius wrote:
> On Thu, 2008-10-16 at 07:48 -0500, Chris Adams wrote:
>   
>> Why are you here if you have so little faith in Red Hat and their
>> alleged ulterior motives?
>>     
> Who said I don't have faith in RH and their motives?
>
> They are a commercial enterprise and hardly wouldn't sponsor Fedora if
> they would not want to profit from it and if they wouldn't want to
> conduct it in directions they want it to head to?
>
> Yes, I feel bitter and frustrated about how Fedora evolves, yes, I was
> sarcastic, and yes, I am personally disappointed about Jesse Keating and
> some other FPB and FESCO folks.
>
>
>   

...and it is completely normal and even useful situation. It is kinda 
opposition. A people system without any opposition is dictatorship.

Former "Red Hat Linux" was very popular, and had become a much more 
wider than just a RH project. There are people which use RH/Fedora 
themselves -- ie. not buying some support, and not planning to buy such 
a support at all. Some of those people are here.

The question is: Is it suitable to have a contributor in Fedora,  whose 
activity never will bring direct money for RH? Just patches, testing 
(including production environments) etc. only? What to do if he see that 
something goes wrong? Just answer him, that he should leave?


~buc



From jreiser at BitWagon.com  Thu Oct 16 14:29:50 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Thu, 16 Oct 2008 07:29:50 -0700
Subject: minimum memory requirements
In-Reply-To: <1224144749.11413.11.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
Message-ID: <48F74FDE.8000003@BitWagon.com>

Jon Masters wrote:
> Something is using a lot of memory (anaconda) ...

At which anaconda install dialog do you see the Out-Of-Memory crash?

The Debian Installer runs the disk partitioner as the very first task
(using character-cell graphics), in order to get swap [paging] space
so that tasks which come afterwards can use more virtual space.

-- 



From rjones at redhat.com  Thu Oct 16 14:35:39 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 16 Oct 2008 15:35:39 +0100
Subject: minimum memory requirements
In-Reply-To: <778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
Message-ID: <20081016143539.GA23830@amd.home.annexia.org>

On Thu, Oct 16, 2008 at 01:54:08PM +0300, Aioanei Rares wrote:
> x86_64 requires more disk space/RAM because of the libraries. But it
> still would be nice if we could come up with some idea to un-bloat
> various aspects in Fedora, aspects which attract a somehow negative
> image upon the distribution.

Indeed ... at my last job I routinely ran x86_64 Debian virtual
machines in 64 MB of RAM.

I'd bump them up to 128 MB or, on one occasion 256 MB of RAM, if they
were doing anything special, like running a medium-traffic webserver.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From rjones at redhat.com  Thu Oct 16 14:41:20 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 16 Oct 2008 15:41:20 +0100
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
Message-ID: <20081016144120.GB23830@amd.home.annexia.org>

On Thu, Oct 16, 2008 at 06:09:48PM +0530, Kushal Das wrote:
> Build the package in mock

Could it submit the package to Koji?  Always nice to know it builds on
ppc/ppc64.

> verify the md5sum of upstream source matches what is in the srpm
> <your ideas here>

Essentially every package guideline which (a) isn't already done by
rpmlint, and (b) can feasibly be checked automatically, should be
checked.

> Workflow:

I've long thought that rpmbuild should have an option to run test
tools on the generated packages.  Particularly rpmlint, but your
review tool is another candidate.

  rpmbuild --test=rpmlint -ba foo.spec

Maybe rpmbuild can actually do this with one of its myriad macros?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From jonathan at jonmasters.org  Thu Oct 16 14:44:00 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 10:44:00 -0400
Subject: minimum memory requirements
In-Reply-To: <20081016143539.GA23830@amd.home.annexia.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
	<20081016143539.GA23830@amd.home.annexia.org>
Message-ID: <1224168240.6400.60.camel@londonpacket.bos.redhat.com>

On Thu, 2008-10-16 at 15:35 +0100, Richard W.M. Jones wrote:
> On Thu, Oct 16, 2008 at 01:54:08PM +0300, Aioanei Rares wrote:
> > x86_64 requires more disk space/RAM because of the libraries. But it
> > still would be nice if we could come up with some idea to un-bloat
> > various aspects in Fedora, aspects which attract a somehow negative
> > image upon the distribution.
> 
> Indeed ... at my last job I routinely ran x86_64 Debian virtual
> machines in 64 MB of RAM.
> 
> I'd bump them up to 128 MB or, on one occasion 256 MB of RAM, if they
> were doing anything special, like running a medium-traffic webserver.

To be fair, they probably didn't have a desktop to carry along for the
ride. But then I guess I could counter that the problem here is I
couldn't even run the installer with less than 384MB RAM. I dropped it
down to 256MB after install but then had to bump it back up again - and
I expect the first time I run yum I'll want to put it back to 512MB.

I had been trying to reduce VM memory sizes to run more at once...

Jon.




From james.antill at redhat.com  Thu Oct 16 14:48:12 2008
From: james.antill at redhat.com (James Antill)
Date: Thu, 16 Oct 2008 10:48:12 -0400
Subject: minimum memory requirements
In-Reply-To: <1224152477.6400.2.camel@londonpacket.bos.redhat.com>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
Message-ID: <1224168492.16958.109.camel@code.and.org>

On Thu, 2008-10-16 at 06:21 -0400, Jon Masters wrote:
> On Thu, 2008-10-16 at 11:47 +0300, Aioanei Rares wrote:
> 
> >         
> >         Gah, ignore me. I meant to install i386 earlier but wound up
> >         installing
> >         an x86_64 image which accounts for the difference. And the
> >         docs agree
> >         fully with my subsequent experience :)
> 
> 
> > Either way, I think you're right...the req's are kinda high...
> 
> Well, yes. I will do an i386 install later and compare. I don't really
> blame the *x86_64* figures for being so high, largely because any system
> featuring an x86_64 probably never had less than 256MB RAM and 512MB
> really isn't all that much to be expecting these days. It'd just be
> nicer if we could install in a virtual machine with less allocated.

 I had a feature request open to have the x86_64 installer actually be
a .i386 python/yum/anaconda (anaconda does not currently need more than
4GB of virtual space :). Which would make the installer size
requirements for x86_64 be the same:

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

 Feel free to pile on the love to clumens :).

-- 
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/20081016/e4215b7f/attachment.sig>

From jonathan at jonmasters.org  Thu Oct 16 14:51:04 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 10:51:04 -0400
Subject: minimum memory requirements
In-Reply-To: <1224168492.16958.109.camel@code.and.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<1224168492.16958.109.camel@code.and.org>
Message-ID: <1224168664.6400.62.camel@londonpacket.bos.redhat.com>

On Thu, 2008-10-16 at 10:48 -0400, James Antill wrote:
> On Thu, 2008-10-16 at 06:21 -0400, Jon Masters wrote:
> > On Thu, 2008-10-16 at 11:47 +0300, Aioanei Rares wrote:
> > 
> > >         
> > >         Gah, ignore me. I meant to install i386 earlier but wound up
> > >         installing
> > >         an x86_64 image which accounts for the difference. And the
> > >         docs agree
> > >         fully with my subsequent experience :)
> > 
> > 
> > > Either way, I think you're right...the req's are kinda high...
> > 
> > Well, yes. I will do an i386 install later and compare. I don't really
> > blame the *x86_64* figures for being so high, largely because any system
> > featuring an x86_64 probably never had less than 256MB RAM and 512MB
> > really isn't all that much to be expecting these days. It'd just be
> > nicer if we could install in a virtual machine with less allocated.
> 
>  I had a feature request open to have the x86_64 installer actually be
> a .i386 python/yum/anaconda (anaconda does not currently need more than
> 4GB of virtual space :). Which would make the installer size
> requirements for x86_64 be the same:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=437914
> 
>  Feel free to pile on the love to clumens :).

I hate to say it, but that makes a lot of sense. A disturbing amount of
sense - glad it was already on the radar :)

Jon.




From nicu_fedora at nicubunu.ro  Thu Oct 16 15:08:19 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 16 Oct 2008 18:08:19 +0300
Subject: reviving Fedora Legacy
In-Reply-To: <48F74C9E.6010308@odu.neva.ru>
References: <20081015133453.GC3091@free.fr>	<20081015145109.GD1773@nostromo.devel.redhat.com>	<1224083908.3029.560.camel@beck.corsepiu.local>	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>	<20081015170841.GB2679@free.fr>	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>	<1224092835.4122.45.camel@luminos.localdomain>	<1224132824.3029.628.camel@beck.corsepiu.local>	<1224133520.4122.64.camel@luminos.localdomain>	<1224134627.3029.631.camel@beck.corsepiu.local>	<20081016124835.GA1269041@hiwaay.net>	<1224164099.3029.679.camel@beck.corsepiu.local>
	<48F74C9E.6010308@odu.neva.ru>
Message-ID: <48F758E3.1020109@nicubunu.ro>

Dmitry Butskoy wrote:
> 
> The question is: Is it suitable to have a contributor in Fedora,  whose 
> activity never will bring direct money for RH? Just patches, testing 
> (including production environments) etc. only? What to do if he see that 
> something goes wrong? Just answer him, that he should leave?

I believe that all the contributions regarding games (OpenArena and 
such) do not bring direct money for Red Hat and we have plenty of games.

-- 
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 jeff at ocjtech.us  Thu Oct 16 15:33:38 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Thu, 16 Oct 2008 10:33:38 -0500
Subject: New PiTiVi Release!
In-Reply-To: <48F748C2.6060005@nicubunu.ro>
References: <935ead450810151412s201a34eascb51e2ffecd9277f@mail.gmail.com>
	<935ead450810151844t74325336x6ec44d3d87c6123b@mail.gmail.com>
	<48F748C2.6060005@nicubunu.ro>
Message-ID: <935ead450810160833h25248195o3dc0a7909097fcc9@mail.gmail.com>

On Thu, Oct 16, 2008 at 8:59 AM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Jeffrey Ollie wrote:
>>
>> On Wed, Oct 15, 2008 at 4:12 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
>>>
>>> Finally, there is a new PiTiVi release and I've built it for F-9 and
>>> rawhide.  Please, take a moment to download it and give it a workout.
>>> Please report bugs upstream (http://pitivi.org/wiki/Main_Page)
>>
>> Until the packages make their way to the mirrors, they can be downloaded
>> here:
>>
>> F-10: http://koji.fedoraproject.org/koji/buildinfo?buildID=66472
>> F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=66475
>
> I think I am stupid or something, as I am unable to find a way to insert an
> Ogg Theora video and an Ogg Vorbis audio file and render them as one Ogg
> clip with both video and audio...

Hmm definitely would be a useful thing to do.  I don't have the time
ATM or I'd try it myself. I'd talk to the upstream devs about it...

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From jarod at redhat.com  Thu Oct 16 13:49:36 2008
From: jarod at redhat.com (Jarod Wilson)
Date: Thu, 16 Oct 2008 09:49:36 -0400
Subject: 2008-10-16 - Fedora Test Day - Security Audit and Better LIRC
	Support
In-Reply-To: <1224016495.7420.56.camel@flatline>
References: <1224016495.7420.56.camel@flatline>
Message-ID: <200810160949.36146.jarod@redhat.com>

On Tuesday 14 October 2008 16:34:55 James Laska wrote:
> Greetings folks,
>
> I'd like to invite testers and users to join #fedora-qa this Thursday,
> October 16, 2008.  Testing efforts will focus on:
>
>       * Security Audit
>       * Better LIRC Support
>       * Fedora 10 Beta snapshot#1
>
> Come with questions, bug reports, and/or suggested test areas.
>
> More details will be posted to
> https://fedoraproject.org/wiki/QA/Test_Days/2008-10-16.

If you've got a laptop with a built-in IrDA port, that might also work with 
LIRC via the lirc_sir module. If you've got an Intel Mac that shipped with an 
Apple remote, you've also got a system that'll talk to LIRC.

If you happen to be in Red Hat's Westford office and have an interest in 
beating on LIRC, but don't have a remote or a receiver, swing by my desk. I've 
got a number of receivers and remotes I can loan out.

-- 
Jarod Wilson
jarod at redhat.com

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From jkeating at redhat.com  Thu Oct 16 16:07:54 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 16 Oct 2008 09:07:54 -0700
Subject: minimum memory requirements
In-Reply-To: <1224168240.6400.60.camel@londonpacket.bos.redhat.com>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
	<20081016143539.GA23830@amd.home.annexia.org>
	<1224168240.6400.60.camel@londonpacket.bos.redhat.com>
Message-ID: <1224173274.4122.69.camel@luminos.localdomain>

On Thu, 2008-10-16 at 10:44 -0400, Jon Masters wrote:
> 
> To be fair, they probably didn't have a desktop to carry along for the
> ride. But then I guess I could counter that the problem here is I
> couldn't even run the installer with less than 384MB RAM. I dropped it
> down to 256MB after install but then had to bump it back up again - and
> I expect the first time I run yum I'll want to put it back to 512MB.
> 
> I had been trying to reduce VM memory sizes to run more at once...

You haven't yet stated your install type and method, which can make a
huge difference.

Graphical install type, booted from just vmlinuz and initrd.img and
subsequently downloading stage2 from the network is going to have
a /much/ higher memory footprint than if you were to boot from boot.iso
(which has stage2 on it), do a text mode install from whatever method.

You see, if you have to download stage2, you're downloading it to memory
based filesystem and losing that much memory just to the storage of the
file.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/c2caa483/attachment.sig>

From mzerqung at 0pointer.de  Thu Oct 16 17:14:51 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Thu, 16 Oct 2008 19:14:51 +0200
Subject: The Big ACL Opening
In-Reply-To: <48F64212.2010505@redhat.com>
References: <48F64212.2010505@redhat.com>
Message-ID: <20081016171451.GA7049@tango.0pointer.de>

On Wed, 15.10.08 15:18, Casey Dahlin (cdahlin at redhat.com) wrote:

> What will happen is all packages which are now set to be private,  
> accessible by their maintainers and a few specific individuals only,  
> will be opened up to all ?berpackager members. Members of ?berpackager  
> represent a filtered minority of CVS comitters, but membership is easy  
> to come by for anyone that asks.

Hmm, am I the only one who finds the choice of the term "?berpackager"
a bit questionnable?

I am assuming this refers to Nietzsche's "?bermensch" which to start
with is not a particular sympathetic idea to many. What I find
particularly problematic however is that at least in Germany this term
more often than not implies some kind of connection to, uhh, certain
dark times about 60 years ago.

Prefixing things with "?ber-" seems to be popular in the english
speaking world these days. In the German language it is however not
common to build new words with that prefix -- and the aforementioned
connotation plays a role in that.

I don't think using smelly worlds like that one and forgetting about their
history would be good for a formalized workflow like ours in
Fedora. I mean, we are supposed to be democratic with all our
board elections and stuff. But, uh, using Nazi terminology is not a
good way to promote that.

Or, if we have "?berpackagers", maybe it's time to rename normal
packagers to "Unterpackagers"? That would fit awfully well into our
pursuit for world domination, wouldn't it?

Lennart



From limb at jcomserv.net  Thu Oct 16 17:28:06 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 16 Oct 2008 12:28:06 -0500 (CDT)
Subject: The Big ACL Opening
In-Reply-To: <20081016171451.GA7049@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <22598.198.175.55.5.1224178086.squirrel@mail.jcomserv.net>


> On Wed, 15.10.08 15:18, Casey Dahlin (cdahlin at redhat.com) wrote:
>
>> What will happen is all packages which are now set to be private,
>> accessible by their maintainers and a few specific individuals only,
>> will be opened up to all ?berpackager members. Members of ?berpackager
>> represent a filtered minority of CVS comitters, but membership is easy
>> to come by for anyone that asks.
>
> Hmm, am I the only one who finds the choice of the term "?berpackager"
> a bit questionnable?
>
> I am assuming this refers to Nietzsche's "?bermensch" which to start
> with is not a particular sympathetic idea to many. What I find
> particularly problematic however is that at least in Germany this term
> more often than not implies some kind of connection to, uhh, certain
> dark times about 60 years ago.
>
> Prefixing things with "?ber-" seems to be popular in the english
> speaking world these days. In the German language it is however not
> common to build new words with that prefix -- and the aforementioned
> connotation plays a role in that.
>
> I don't think using smelly worlds like that one and forgetting about their
> history would be good for a formalized workflow like ours in
> Fedora. I mean, we are supposed to be democratic with all our
> board elections and stuff. But, uh, using Nazi terminology is not a
> good way to promote that.
>
> Or, if we have "?berpackagers", maybe it's time to rename normal
> packagers to "Unterpackagers"? That would fit awfully well into our
> pursuit for world domination, wouldn't it?

Point taken, but in all honesty, this has been being bandied about for
awhile.  Wouldn't have been more expedient to contribute to the naming
discussion before extensive infrastructure changes we made?

I mean, I agree with you to some extent, but the goat has already run off
with the burrito, so to speak.

> Lennart
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From stickster at gmail.com  Thu Oct 16 17:37:43 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 16 Oct 2008 13:37:43 -0400
Subject: The Big ACL Opening
In-Reply-To: <20081016171451.GA7049@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <1224178664.17377.23.camel@victoria-eth>

On Thu, 2008-10-16 at 19:14 +0200, Lennart Poettering wrote:
> On Wed, 15.10.08 15:18, Casey Dahlin (cdahlin at redhat.com) wrote:
> 
> > What will happen is all packages which are now set to be private,  
> > accessible by their maintainers and a few specific individuals only,  
> > will be opened up to all ?berpackager members. Members of ?berpackager  
> > represent a filtered minority of CVS comitters, but membership is easy  
> > to come by for anyone that asks.
> 
> Hmm, am I the only one who finds the choice of the term "?berpackager"
> a bit questionnable?
> 
> I am assuming this refers to Nietzsche's "?bermensch" which to start
> with is not a particular sympathetic idea to many. What I find
> particularly problematic however is that at least in Germany this term
> more often than not implies some kind of connection to, uhh, certain
> dark times about 60 years ago.
> 
> Prefixing things with "?ber-" seems to be popular in the english
> speaking world these days. In the German language it is however not
> common to build new words with that prefix -- and the aforementioned
> connotation plays a role in that.
> 
> I don't think using smelly worlds like that one and forgetting about their
> history would be good for a formalized workflow like ours in
> Fedora. I mean, we are supposed to be democratic with all our
> board elections and stuff. But, uh, using Nazi terminology is not a
> good way to promote that.
> 
> Or, if we have "?berpackagers", maybe it's time to rename normal
> packagers to "Unterpackagers"? That would fit awfully well into our
> pursuit for world domination, wouldn't it?

If we were to go with a dead language instead and say "ultrapackagers,"
would that be less likely to offend?  (Serious question, not being
snarky.)

Use of "?ber-" has indeed made the jump to slang English.  I think
there's an increasing tendency in new media communities to attempt to
subvert or undermine existing connotations of terms, for better or
worse.  In cases like this, I think we unconsciously or semi-consciously
think we're deflating any unpleasantness by using them casually.  I'm
certain no offense was intended, but your comment is worth serious
consideration.

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   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/20081016/0dc81360/attachment.sig>

From tibbs at math.uh.edu  Thu Oct 16 17:40:44 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 16 Oct 2008 12:40:44 -0500
Subject: The Big ACL Opening
In-Reply-To: <20081016171451.GA7049@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <ufa1vygwi8z.fsf@epithumia.math.uh.edu>

>>>>> "LP" == Lennart Poettering <mzerqung at 0pointer.de> writes:

LP> I am assuming this refers to Nietzsche's "?bermensch" which to
LP> start with is not a particular sympathetic idea to many. What I
LP> find particularly problematic however is that at least in Germany
LP> this term more often than not implies some kind of connection to,
LP> uhh, certain dark times about 60 years ago.

And here I was thinking it came from a poem written in 1841.  Or the
Dead Kennedys.  Oh, well.  Guess I'm not culturally enlightened.

 - J<



From mzerqung at 0pointer.de  Thu Oct 16 17:43:58 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Thu, 16 Oct 2008 19:43:58 +0200
Subject: The Big ACL Opening
In-Reply-To: <22598.198.175.55.5.1224178086.squirrel@mail.jcomserv.net>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<22598.198.175.55.5.1224178086.squirrel@mail.jcomserv.net>
Message-ID: <20081016174357.GA8706@tango.0pointer.de>

On Thu, 16.10.08 12:28, Jon Ciesla (limb at jcomserv.net) wrote:

> > I don't think using smelly worlds like that one and forgetting about their
> > history would be good for a formalized workflow like ours in
> > Fedora. I mean, we are supposed to be democratic with all our
> > board elections and stuff. But, uh, using Nazi terminology is not a
> > good way to promote that.
> >
> > Or, if we have "?berpackagers", maybe it's time to rename normal
> > packagers to "Unterpackagers"? That would fit awfully well into our
> > pursuit for world domination, wouldn't it?
> 
> Point taken, but in all honesty, this has been being bandied about for
> awhile.  Wouldn't have been more expedient to contribute to the naming
> discussion before extensive infrastructure changes we made?
> 
> I mean, I agree with you to some extent, but the goat has already run off
> with the burrito, so to speak.

Neither your hungry goat nor the fact that I don't follow all and very
single discussion on the fedora MLs changes that "?berpackager" is a
pretty bad choice of words. 

I noticed the adoption of this term for the first time a week or two
ago when I had to log into FAS and noticed I had become an
?berpackager. And, oh, god, with my blonde hair and blue eyes it felt
so deserved...

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From limb at jcomserv.net  Thu Oct 16 17:55:05 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 16 Oct 2008 12:55:05 -0500 (CDT)
Subject: The Big ACL Opening
In-Reply-To: <20081016174357.GA8706@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<22598.198.175.55.5.1224178086.squirrel@mail.jcomserv.net>
	<20081016174357.GA8706@tango.0pointer.de>
Message-ID: <41086.198.175.55.5.1224179705.squirrel@mail.jcomserv.net>


> On Thu, 16.10.08 12:28, Jon Ciesla (limb at jcomserv.net) wrote:
>
>> > I don't think using smelly worlds like that one and forgetting about
>> their
>> > history would be good for a formalized workflow like ours in
>> > Fedora. I mean, we are supposed to be democratic with all our
>> > board elections and stuff. But, uh, using Nazi terminology is not a
>> > good way to promote that.
>> >
>> > Or, if we have "?berpackagers", maybe it's time to rename normal
>> > packagers to "Unterpackagers"? That would fit awfully well into our
>> > pursuit for world domination, wouldn't it?
>>
>> Point taken, but in all honesty, this has been being bandied about for
>> awhile.  Wouldn't have been more expedient to contribute to the naming
>> discussion before extensive infrastructure changes we made?
>>
>> I mean, I agree with you to some extent, but the goat has already run
>> off
>> with the burrito, so to speak.
>
> Neither your hungry goat nor the fact that I don't follow all and very
> single discussion on the fedora MLs changes that "?berpackager" is a
> pretty bad choice of words.

Neither do I.  I though this had been on f-announce.  Immaterial. . .

> I noticed the adoption of this term for the first time a week or two
> ago when I had to log into FAS and noticed I had become an
> ?berpackager. And, oh, god, with my blonde hair and blue eyes it felt
> so deserved...

To fair, I'm descended from Polish Catholics, and I didn't even think
about it, and I've read quite a bit of Nietzsche.  I can certainly
understand why many would be sensitive to this, but I guess in my mind I
associate Nietzsche less with what a textbook of mine euphemistically
referred to as Problems in Western Civilization than I do with one
philosopher's rants on Why 4$$holes Get Ahead.  Not to dismiss your
concerns, I'm just trying to illustrate why someone in a different milieu
might have missed it.

Do you have an alternate suggestion?  Package-guru?  Spec-mentat?

> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
>
> --
> 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  Thu Oct 16 18:08:05 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Thu, 16 Oct 2008 20:08:05 +0200
Subject: The Big ACL Opening
In-Reply-To: <1224178664.17377.23.camel@victoria-eth>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<1224178664.17377.23.camel@victoria-eth>
Message-ID: <20081016180804.GB8706@tango.0pointer.de>

On Thu, 16.10.08 13:37, Paul W. Frields (stickster at gmail.com) wrote:

> > I don't think using smelly worlds like that one and forgetting about their
> > history would be good for a formalized workflow like ours in
> > Fedora. I mean, we are supposed to be democratic with all our
> > board elections and stuff. But, uh, using Nazi terminology is not a
> > good way to promote that.
> > 
> > Or, if we have "?berpackagers", maybe it's time to rename normal
> > packagers to "Unterpackagers"? That would fit awfully well into our
> > pursuit for world domination, wouldn't it?
> 
> If we were to go with a dead language instead and say "ultrapackagers,"
> would that be less likely to offend?  (Serious question, not being
> snarky.)

It has been a while since my last lessons in Latin.

But yes, it's just the german prefix "?ber-" used in this reference
that makes me feel uncomfortable. To my knowledge latin or greek
or.... english (woah!) translations of that word do not have any
similar connotation.

You never can be entirely safe, there are always words that in some
languages or to some people may be offending or have a questionnable
connotation. However, since Nazism is almost universally agreed to be
without comparison and practically a superlative of evil there are
more than enough reasons to stay away from terminology related to
Nazism.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From jonathan at jonmasters.org  Thu Oct 16 18:08:24 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 16 Oct 2008 14:08:24 -0400
Subject: minimum memory requirements
In-Reply-To: <1224173274.4122.69.camel@luminos.localdomain>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
	<20081016143539.GA23830@amd.home.annexia.org>
	<1224168240.6400.60.camel@londonpacket.bos.redhat.com>
	<1224173274.4122.69.camel@luminos.localdomain>
Message-ID: <1224180504.27747.4.camel@perihelion.int.jonmasters.org>

On Thu, 2008-10-16 at 09:07 -0700, Jesse Keating wrote:
> On Thu, 2008-10-16 at 10:44 -0400, Jon Masters wrote:
> > 
> > To be fair, they probably didn't have a desktop to carry along for the
> > ride. But then I guess I could counter that the problem here is I
> > couldn't even run the installer with less than 384MB RAM. I dropped it
> > down to 256MB after install but then had to bump it back up again - and
> > I expect the first time I run yum I'll want to put it back to 512MB.
> > 
> > I had been trying to reduce VM memory sizes to run more at once...
> 
> You haven't yet stated your install type and method, which can make a
> huge difference.

Ah, this was rawhide done from a boot.iso image.

> Graphical install type, booted from just vmlinuz and initrd.img and
> subsequently downloading stage2 from the network is going to have
> a /much/ higher memory footprint than if you were to boot from boot.iso
> (which has stage2 on it), do a text mode install from whatever method.

True, I know I could just do a text mode install.

> You see, if you have to download stage2, you're downloading it to memory
> based filesystem and losing that much memory just to the storage of the
> file.

I'm not sure that's the case any more though. There used to be a stage1
and a stage2 image for Anaconda, but now I think it's all a live image
within that 100+ MB boot.iso file, without a separate download stage2.
Perhaps I'll do another install later and switch to the console (it's
cool that there's a usable shell early on now too) to check tmpfs.

Jon.




From katzj at redhat.com  Thu Oct 16 18:13:30 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 16 Oct 2008 14:13:30 -0400
Subject: minimum memory requirements
In-Reply-To: <1224180504.27747.4.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
	<20081016143539.GA23830@amd.home.annexia.org>
	<1224168240.6400.60.camel@londonpacket.bos.redhat.com>
	<1224173274.4122.69.camel@luminos.localdomain>
	<1224180504.27747.4.camel@perihelion.int.jonmasters.org>
Message-ID: <1224180810.370.11.camel@aglarond.local>

On Thu, 2008-10-16 at 14:08 -0400, Jon Masters wrote:
> On Thu, 2008-10-16 at 09:07 -0700, Jesse Keating wrote:
> > On Thu, 2008-10-16 at 10:44 -0400, Jon Masters wrote:
> > > 
> > > To be fair, they probably didn't have a desktop to carry along for the
> > > ride. But then I guess I could counter that the problem here is I
> > > couldn't even run the installer with less than 384MB RAM. I dropped it
> > > down to 256MB after install but then had to bump it back up again - and
> > > I expect the first time I run yum I'll want to put it back to 512MB.
> > > 
> > > I had been trying to reduce VM memory sizes to run more at once...
> > 
> > You haven't yet stated your install type and method, which can make a
> > huge difference.
> 
> Ah, this was rawhide done from a boot.iso image.
> 
> > Graphical install type, booted from just vmlinuz and initrd.img and
> > subsequently downloading stage2 from the network is going to have
> > a /much/ higher memory footprint than if you were to boot from boot.iso
> > (which has stage2 on it), do a text mode install from whatever method.
> 
> True, I know I could just do a text mode install.
> 
> > You see, if you have to download stage2, you're downloading it to memory
> > based filesystem and losing that much memory just to the storage of the
> > file.
> 
> I'm not sure that's the case any more though. There used to be a stage1
> and a stage2 image for Anaconda, but now I think it's all a live image
> within that 100+ MB boot.iso file, without a separate download stage2.
> Perhaps I'll do another install later and switch to the console (it's
> cool that there's a usable shell early on now too) to check tmpfs.

No, there's still a separate first and second stage.  The first stage is
larger due to us using standard system functionality like NetworkManager
and there's no longer a (not-so-)minimal stage2 image as the size
difference was getting close to zero.

If you're booting from CD, the problem is that we have to copy the
stage2 off of the CD and into RAM so that you can later change CDs to
put in installation CDs.  There's unfortunately not much of a way around
it

Jeremy



From jkeating at redhat.com  Thu Oct 16 18:15:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 16 Oct 2008 11:15:32 -0700
Subject: minimum memory requirements
In-Reply-To: <1224180504.27747.4.camel@perihelion.int.jonmasters.org>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
	<20081016143539.GA23830@amd.home.annexia.org>
	<1224168240.6400.60.camel@londonpacket.bos.redhat.com>
	<1224173274.4122.69.camel@luminos.localdomain>
	<1224180504.27747.4.camel@perihelion.int.jonmasters.org>
Message-ID: <1224180932.4122.86.camel@luminos.localdomain>

On Thu, 2008-10-16 at 14:08 -0400, Jon Masters wrote:
> > You see, if you have to download stage2, you're downloading it to memory
> > based filesystem and losing that much memory just to the storage of the
> > file.
> 
> I'm not sure that's the case any more though. There used to be a stage1
> and a stage2 image for Anaconda, but now I think it's all a live image
> within that 100+ MB boot.iso file, without a separate download stage2.
> Perhaps I'll do another install later and switch to the console (it's
> cool that there's a usable shell early on now too) to check tmpfs.

Correction.  There used to be a boot.iso and a rescue.iso.  The boot.iso
of old only had stage 1 on it.  The rescue.iso had both stage1 and
stage2 (different files!).  We got rid of boot.iso, renamed rescue.iso
to boot.iso (as well as netinst.iso), and kept it the way it was, stage1
and stage2, different files.

In the exploded tree, stage1 and stage2 are different files.  In fact,
there are a few different variations of each depending on what you're
doing.  PXE booting doesn't like it very much if you try to shove the
100+meg file down it as a combined stage1/2, so we have a much smaller
stage1 which then gets stage2 via a more reliable method.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/4c0529a6/attachment.sig>

From jkeating at redhat.com  Thu Oct 16 18:22:51 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 16 Oct 2008 11:22:51 -0700
Subject: minimum memory requirements
In-Reply-To: <1224180810.370.11.camel@aglarond.local>
References: <1224137627.11413.2.camel@perihelion.int.jonmasters.org>
	<778179b00810160045p66b5148ek2abe82c6f827b508@mail.gmail.com>
	<1224144749.11413.11.camel@perihelion.int.jonmasters.org>
	<1224146261.11413.23.camel@perihelion.int.jonmasters.org>
	<1224146377.11413.26.camel@perihelion.int.jonmasters.org>
	<778179b00810160147t5be707bag88ef5c4952df125e@mail.gmail.com>
	<1224152477.6400.2.camel@londonpacket.bos.redhat.com>
	<778179b00810160354h491bdd9es1e0881a1e7561676@mail.gmail.com>
	<20081016143539.GA23830@amd.home.annexia.org>
	<1224168240.6400.60.camel@londonpacket.bos.redhat.com>
	<1224173274.4122.69.camel@luminos.localdomain>
	<1224180504.27747.4.camel@perihelion.int.jonmasters.org>
	<1224180810.370.11.camel@aglarond.local>
Message-ID: <1224181371.4122.87.camel@luminos.localdomain>

On Thu, 2008-10-16 at 14:13 -0400, Jeremy Katz wrote:
> If you're booting from CD, the problem is that we have to copy the
> stage2 off of the CD and into RAM so that you can later change CDs to
> put in installation CDs.  There's unfortunately not much of a way
> around
> it

Is that true when doing boot.iso install + network repo install method?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/61dbf3ad/attachment.sig>

From jspaleta at gmail.com  Thu Oct 16 18:49:13 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 16 Oct 2008 10:49:13 -0800
Subject: Python modules breaking python help() behaviour
Message-ID: <604aa7910810161149w17a6a87o7af158060b4884d9@mail.gmail.com>

As seen in association with numpy:
https://bugzilla.redhat.com/show_bug.cgi?id=467266

But poking at it a little bit, the module listing functionality seems
to be broken by other modules. At least pygtk2 and possibly
gnome-applets via different exceptions depending on situation from my
own personal testing.

I'll try to track down the ones I'm aware of and get bugs filed, but I
don't have any idea how many individual modules are a problem.  Nor do
I really know if this is a serious problem. How broken has this
functionality been over the bast 2 or 3 releases? No idea. The numpy
issue affects f8 and f9 and devel.

I'm not sure where this falls on the scale importance. But its not
limited to just numpy, and it does affect our default desktop spin, so
I'd thought I'd make everyone aware of it and let maintainers choose
to deal with this or not.  But it would be nice to get an idea of how
widespread the problem is.

I would humbly ask that other maintainers for other python packages
take a moment and do a test of their own package via mock in the
process outlined in comment 8 of that bug:
https://bugzilla.redhat.com/show_bug.cgi?id=467266#c8

1) set up the mock localbuild root
mock -r <whatever_release> init

2) chroot into the root of that mock environment

3) Run the python help module test, which should return clean
python
help()
modules
(Ctrl-D a few times to get back out of the python and chroot sessions)

4) install the module you think is a problem
mock -r <whatever_release> install <py_package>

5) Do step 2 and 3 again see if its a traceback and if there is something is
wonky with the python modules in the installed package or one of its
dependencies.

If someone wanted to script that test (Hey Matt! Hey Seth!) and run
over an entire rawhide tree..that'd be sort of nice.

Note however that this procedure will not catch all the ways exception
handling in modules breaks the python module listing
functionality...since the mock chroot environment make trigger
different exceptions than your running client system.  Isn't this fun?


-jef



From ggw at wolves.durham.nc.us  Thu Oct 16 18:54:45 2008
From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury)
Date: Thu, 16 Oct 2008 14:54:45 -0400
Subject: repodata and comps.xml filenames in hexadecimal?
Message-ID: <48F78DF5.8000308@wolves.durham.nc.us>

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

I know someone is working on a rewrite of some of the stuff dealing with
repodata and comps.xml.  I notice today that the names of the files in
repodata have the hexadecimal checksums prepended.   Is this the new
"standard" or is there a bug in the generation scripts?

- --
G.Wolfe Woodbury
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iJwEAQECAAYFAkj3jfQACgkQLX6Uvr8IXrexuQQAuWeLrozd3mK8AeZTKMs9hijg
sEaho4eNjNpGV1nX5HWEjFurCWI5LDNFdhqRHHW3CkJ75MHKrZ7lgc0R10KCCK6M
lvs1f0QO4Y0nb76KEUTdFMSeRG1cBDK3Nx1Uo/QAfAGg6pgCD97bj76fX3ddM1nf
jklVbAhTiuAXKCJbqWE=
=EODf
-----END PGP SIGNATURE-----



From mdehaan at redhat.com  Thu Oct 16 19:01:32 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Thu, 16 Oct 2008 15:01:32 -0400
Subject: (devel) a note about automated tests and how we're going to do them
 moving forward
Message-ID: <48F78F8C.5050903@redhat.com>

I've switching "make test" to call unit tests via nose, which produces 
some nicer output from the same test code.

To get nose, you'll need to:

    # yum install nose

Nose can also be called with coverage if you uncomment that part of the 
Makefile.

    # easy_install coverage

While currently a lot of tests exist in tests/test.py the intent is for 
new tests to live with the code, so that they have a greater hope of 
being maintained when folks add features (since they will obviously be 
in the same file).  

For instance, XMLRPC tests will live in remote.py.

Nose allows for tests to be named "test_something" and it will find 
functions of that form and see if any asserts in them fail.

For instance:

    assert x == 2, "verify that the return code is two"

Another nice feature of nose is that when running "make test" the output 
is a lot nicer, it will only show stdout/stderr for tests that actually 
fail, so there's a lot less noise to sift through.

--Michael



From berrange at redhat.com  Thu Oct 16 19:01:39 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 16 Oct 2008 20:01:39 +0100
Subject: Python modules breaking python help() behaviour
In-Reply-To: <604aa7910810161149w17a6a87o7af158060b4884d9@mail.gmail.com>
References: <604aa7910810161149w17a6a87o7af158060b4884d9@mail.gmail.com>
Message-ID: <20081016190139.GA6745@redhat.com>

On Thu, Oct 16, 2008 at 10:49:13AM -0800, Jeff Spaleta wrote:
> As seen in association with numpy:
> https://bugzilla.redhat.com/show_bug.cgi?id=467266
> 
> But poking at it a little bit, the module listing functionality seems
> to be broken by other modules. At least pygtk2 and possibly
> gnome-applets via different exceptions depending on situation from my
> own personal testing.

If it is so easy for lots of modules to break pydoc's help() function, 
then there also needs to be a bug filed against python itself to make
it robust against these problems.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From jkeating at redhat.com  Thu Oct 16 19:08:38 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 16 Oct 2008 12:08:38 -0700
Subject: repodata and comps.xml filenames in hexadecimal?
In-Reply-To: <48F78DF5.8000308@wolves.durham.nc.us>
References: <48F78DF5.8000308@wolves.durham.nc.us>
Message-ID: <1224184118.4122.92.camel@luminos.localdomain>

On Thu, 2008-10-16 at 14:54 -0400, G.Wolfe Woodbury wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I know someone is working on a rewrite of some of the stuff dealing with
> repodata and comps.xml.  I notice today that the names of the files in
> repodata have the hexadecimal checksums prepended.   Is this the new
> "standard" or is there a bug in the generation scripts?

It's a new standard.  The repodata files are uniquely named which helps
many things such as proxies.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/fafffe63/attachment.sig>

From jkeating at redhat.com  Thu Oct 16 19:09:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 16 Oct 2008 12:09:53 -0700
Subject: (devel) a note about automated tests and how we're going to do
 them moving forward
In-Reply-To: <48F78F8C.5050903@redhat.com>
References: <48F78F8C.5050903@redhat.com>
Message-ID: <1224184193.4122.93.camel@luminos.localdomain>

On Thu, 2008-10-16 at 15:01 -0400, Michael DeHaan wrote:
> 
> I've switching "make test" to call unit tests via nose, which
> produces 
> some nicer output from the same test code.

Did this go to the wrong list?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/c0ff26fe/attachment.sig>

From mdehaan at redhat.com  Thu Oct 16 19:57:54 2008
From: mdehaan at redhat.com (Michael DeHaan)
Date: Thu, 16 Oct 2008 15:57:54 -0400
Subject: (devel) a note about automated tests and how we're going to do
 them moving forward
In-Reply-To: <48F78F8C.5050903@redhat.com>
References: <48F78F8C.5050903@redhat.com>
Message-ID: <48F79CC2.5060400@redhat.com>

Michael DeHaan wrote:
> I've switching "make test" to call unit tests via nose, which produces 
> some nicer output from the same test code.
>
> To get nose, you'll need to:
>
>    # yum install nose
>
> Nose can also be called with coverage if you uncomment that part of 
> the Makefile.
>
>    # easy_install coverage
>
> While currently a lot of tests exist in tests/test.py the intent is 
> for new tests to live with the code, so that they have a greater hope 
> of being maintained when folks add features (since they will obviously 
> be in the same file). 
> For instance, XMLRPC tests will live in remote.py.
>
> Nose allows for tests to be named "test_something" and it will find 
> functions of that form and see if any asserts in them fail.
>
> For instance:
>
>    assert x == 2, "verify that the return code is two"
>
> Another nice feature of nose is that when running "make test" the 
> output is a lot nicer, it will only show stdout/stderr for tests that 
> actually fail, so there's a lot less noise to sift through.
>
> --Michael
>

Wrong list, grr




From a.badger at gmail.com  Thu Oct 16 19:59:23 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 16 Oct 2008 12:59:23 -0700
Subject: The Big ACL Opening
In-Reply-To: <1224178664.17377.23.camel@victoria-eth>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<1224178664.17377.23.camel@victoria-eth>
Message-ID: <48F79D1B.9080800@gmail.com>

Paul W. Frields wrote:

> If we were to go with a dead language instead and say "ultrapackagers,"
> would that be less likely to offend?  (Serious question, not being
> snarky.)
> 
I can change this without too much trouble (Just have to remember all
the places I just changed it :-).  I'll change to ultrapackagers in the
source tree on Monday (hopefully deploying the same day but you never
know) unless someone has a better suggestion.

-Toshio

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

From limb at jcomserv.net  Thu Oct 16 20:03:10 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 16 Oct 2008 15:03:10 -0500 (CDT)
Subject: The Big ACL Opening
In-Reply-To: <48F79D1B.9080800@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<1224178664.17377.23.camel@victoria-eth> <48F79D1B.9080800@gmail.com>
Message-ID: <4462.198.175.55.5.1224187390.squirrel@mail.jcomserv.net>


> Paul W. Frields wrote:
>
>> If we were to go with a dead language instead and say "ultrapackagers,"
>> would that be less likely to offend?  (Serious question, not being
>> snarky.)
>>
> I can change this without too much trouble (Just have to remember all
> the places I just changed it :-).  I'll change to ultrapackagers in the
> source tree on Monday (hopefully deploying the same day but you never
> know) unless someone has a better suggestion.

+1

> -Toshio
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From nicolas.mailhot at laposte.net  Thu Oct 16 20:05:46 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 16 Oct 2008 22:05:46 +0200
Subject: repodata and comps.xml filenames in hexadecimal?
In-Reply-To: <1224184118.4122.92.camel@luminos.localdomain>
References: <48F78DF5.8000308@wolves.durham.nc.us>
	<1224184118.4122.92.camel@luminos.localdomain>
Message-ID: <1224187546.19524.0.camel@arekh.okg>

Le jeudi 16 octobre 2008 ? 12:08 -0700, Jesse Keating a ?crit :
> On Thu, 2008-10-16 at 14:54 -0400, G.Wolfe Woodbury wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > I know someone is working on a rewrite of some of the stuff dealing with
> > repodata and comps.xml.  I notice today that the names of the files in
> > repodata have the hexadecimal checksums prepended.   Is this the new
> > "standard" or is there a bug in the generation scripts?
> 
> It's a new standard.  The repodata files are uniquely named which helps
> many things such as proxies.

And there was much rejoicing. Thanks to everyone involved!

-- 
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/20081016/07e8cdca/attachment.sig>

From mattdm at mattdm.org  Thu Oct 16 21:30:33 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 16 Oct 2008 17:30:33 -0400
Subject: reviving Fedora Legacy
In-Reply-To: <48F73DAE.4050800@gmail.com>
References: <20081015124348.GA27658@yoda.jdub.homelinux.org>
	<20081015133453.GC3091@free.fr>
	<20081015145109.GD1773@nostromo.devel.redhat.com>
	<1224083908.3029.560.camel@beck.corsepiu.local>
	<alpine.LRH.2.00.0810151952370.28934@netcore.fi>
	<20081015170841.GB2679@free.fr>
	<80d7e4090810151025w1b481a58j2aabb8395caf7bdf@mail.gmail.com>
	<1224092835.4122.45.camel@luminos.localdomain>
	<20081016030242.GA20109@jadzia.bu.edu> <48F73DAE.4050800@gmail.com>
Message-ID: <20081016213033.GA30097@jadzia.bu.edu>

On Thu, Oct 16, 2008 at 08:12:14AM -0500, Les Mikesell wrote:
> Ahh, nostalgia for the old days when Freshrpms and a few others were 
> one-man shows covering most of the early RH releases and some of the 
> fedoras beyond their own supported life - and inventing the way to do it.   
> Maybe you could find a third party site to take over...

Sure, those places supported (and still support) their own random collection
of packages for older releases. That's very different from what's needed
here.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From tmus at tmus.dk  Thu Oct 16 22:35:25 2008
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Thu, 16 Oct 2008 20:35:25 -0200
Subject: repodata and comps.xml filenames in hexadecimal?
In-Reply-To: <1224184118.4122.92.camel@luminos.localdomain>
References: <48F78DF5.8000308@wolves.durham.nc.us>
	<1224184118.4122.92.camel@luminos.localdomain>
Message-ID: <48F7C1AD.2050806@tmus.dk>

Jesse Keating wrote:
> On Thu, 2008-10-16 at 14:54 -0400, G.Wolfe Woodbury wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I know someone is working on a rewrite of some of the stuff dealing with
>> repodata and comps.xml.  I notice today that the names of the files in
>> repodata have the hexadecimal checksums prepended.   Is this the new
>> "standard" or is there a bug in the generation scripts?
> 
> It's a new standard.  The repodata files are uniquely named which helps
> many things such as proxies.
> 
> 

Is there a reason why the uniqueness part is prepended rather than 
appended? It's kinda hard to tell which file is which when browsing 
repositories.

http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/repodata/

I realize that you probably won't browse the repodata directory too 
often, but just in case it didn't make a difference, I thought it would 
be kinda nice to be able to tell one from the other, on the few 
occations where you actually might need to do so... :-)

/Thomas



From mike at flyn.org  Thu Oct 16 22:43:32 2008
From: mike at flyn.org (W. Michael Petullo)
Date: Thu, 16 Oct 2008 18:43:32 -0400
Subject: Problems with PowerPC iBook and X
Message-ID: <3C7112D9-D48F-4506-AE21-72B03048A9D8@flyn.org>

For quite some time during the ramp up to Fedora 10, X has not worked  
on my PowerPC iBook. I have submitted a bug report (Bugzilla #463118)  
and a few people have mentioned a similar problem. Is anyone out  
there using a PowerPC iBook / Radeon Mobility 9200 to test Rawhide?  
What is your experience?

Mike



From promac at gmail.com  Thu Oct 16 22:46:14 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Thu, 16 Oct 2008 19:46:14 -0300
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
Message-ID: <68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>

On Mon, Oct 13, 2008 at 2:48 PM, KH KH <kwizart at gmail.com> wrote:

> 2008/10/13 Jon Ciesla <limb at jcomserv.net>:
> >
> >> Hi!
> >>
> >> As announced at http://www.yafray.org, yafaray replaces YafRay 0.0.9.
> >> Thus I'm thinking of submitting yafray as dead.package in Rawhide. (1)
> >>
> >> On the other side, I'm not going to work on yafaray soon. So, if anyone
> >> wants to start working on it, feel free.
> >>
> >> Nicolas (kwizart)
> >>
> >>
> >> (1), There is no reason why yafray should stop working with the current
> >> blender releases. But there might be a problem when theses two are
> >> installed together. (until now, blender either dlopen library or call
> >> binary, from yafray).
> >> This has to be discussed in the yafaray review. So, please cc'ed me on
> >> the review, along with your favorite reviewer. (or ask me as a
> reviewer).
> >
> > I may just do that.  One thing though, am I blind or is there nor yafaray
> > tarball, and I'll have to work from a svn checkout?  (bleah)
> Yes, that's right.
> I think it will be appropriate to use a script to create one source
> tarball.
> Good luck !
>
>
I can give you an .src.rpm that builds fine for F8, including the QT
interface.

http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc8.src.rpm

If you are able to integrate yafaray with blender, let me know...

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/2d7f321e/attachment.htm>

From alsadi at gmail.com  Thu Oct 16 23:22:45 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 17 Oct 2008 02:22:45 +0300
Subject: OpenOffice and go-oo
In-Reply-To: <1224024681.10624.250.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223903997.10624.113.camel@vain.rhgalway>
	<385866f0810130637h39cecba3i11ef50af8d41bd58@mail.gmail.com>
	<1223909556.10624.131.camel@vain.rhgalway>
	<385866f0810130916l52aa2e99m85172ee79f3d285b@mail.gmail.com>
	<1223934602.10624.179.camel@vain.rhgalway>
	<385866f0810131511s5ebd6588peda46c7dfe98cc67@mail.gmail.com>
	<1223988957.10624.205.camel@vain.rhgalway>
	<385866f0810141054h54c7f049i7655a6e2d50bb5b2@mail.gmail.com>
	<1224024681.10624.250.camel@vain.rhgalway>
Message-ID: <385866f0810161622t1ea2372fuf355312f357cb3b7@mail.gmail.com>

go-oo.org provides a Yum repo and a release rpm
http://go-oo.mirrorbrain.org/stable/linux-i586/GoOo-release-0.0.3-0.noarch.rpm

could anyone do a review/comparison for us

because there were many enhancements in the upstream oo.o 3



From seg at haxxed.com  Fri Oct 17 00:13:00 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 16 Oct 2008 19:13:00 -0500
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F113AD.4030707@poolshark.org>
References: <48F0C1CE.30104@BitWagon.com>
	<alpine.LFD.1.10.0810111347100.25949@laptop.mmcgrath.net>
	<200810112203.45142.opensource@till.name>	<48F10915.4060704@poolshark.org>
	<alpine.LFD.1.10.0810111532150.25949@laptop.mmcgrath.net>
	<48F10EFB.2020000@poolshark.org>
	<alpine.LFD.1.10.0810111543490.25949@laptop.mmcgrath.net>
	<48F11184.6070004@poolshark.org>
	<alpine.LFD.1.10.0810111551590.25949@laptop.mmcgrath.net>
	<48F113AD.4030707@poolshark.org>
Message-ID: <1224202380.26341.161.camel@localhost.localdomain>

On Sat, 2008-10-11 at 22:59 +0200, Denis Leroy wrote:
> As someone else mentioned, the distribution of the chunks pushed to the 
> clients is supposed to be randomized. Apparently it isn't, we're all 
> sitting here with the same completion percentage and the exact same 
> chunks, all trying to download from the same one seed.

This has nothing to do with ordering and everything to do with
bandwidth. This situation looks to me like a textbook case of a
bottleneck or throttling between the seed and that entire group of
peers. Having the same set of blocks indicates that set of peers are
well connected to each other. Or at least, better connected to each
other than to the seed. :P

> I'm not sure whether it's the client that picks the random chunk to 
> download, or the server that imposes it though. Maybe we're all using 
> the same buggy client :-) (I'm using transmission).

Well, its a P2P app. There's no server or client. When peers connect,
each peer informs the other peer of what blocks it has. A peer then
requests a block from the list of what's available. The requesting peer
will generally favor the "rarest" block from it's point of view as its
primary criteria, falling back on random selection as a secondary
criteria. The sending peer will then send the block... at its
discretion. The sending peer is also trying to maximize block
distribution, it may queue the block in favor of other peers requesting
rarer blocks. Sending peers also usually favor sending blocks to peers
who are sending them the most blocks in return. This rewards uploading
and discourages leeching.

... So there's quite a bit of handshaking both ways. The requesting
("client") peer picks what block it wants, but the sender can refuse to
send it. A peer can also "lie" about what blocks it has, forcing other
peers to pick from a subset of blocks. See: Superseeding.

http://en.wikipedia.org/wiki/Super-seeding
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/2005d92f/attachment.sig>

From seg at haxxed.com  Fri Oct 17 00:27:20 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 16 Oct 2008 19:27:20 -0500
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <48F1C2D0.2050403@poolshark.org>
References: <48F0C1CE.30104@BitWagon.com> <20081011205506.GI2305@br-online.de>
	<alpine.LFD.1.10.0810111558450.25949@laptop.mmcgrath.net>
	<200810120143.24733.opensource@till.name>
	<alpine.LFD.1.10.0810112244000.25949@laptop.mmcgrath.net>
	<48F1C2D0.2050403@poolshark.org>
Message-ID: <1224203240.26341.175.camel@localhost.localdomain>

On Sun, 2008-10-12 at 11:26 +0200, Denis Leroy wrote:
> Mike McGrath wrote:
> > I'll have a talk with Jesse.  For the normal releases we typically have
> > multiple seeders from the start.  For these sorts of snapshots I suspect
> > some steps can be taken to ensure better usability here.  I talked with
> > Seth a bit about this too (he's our current torrent wrangler) and we
> > generally think this was just an issue with two many chunks and not enough
> > people for chunks from the beginning.  Which is self correcting but A)
> > is annoying and B) is preventable in the future.  We just have to figure
> > out the procedure on it.
> 
> I'm not convinced by this explanation. If you know a little bit about 
> the bittorrent protocol, the scenario of a fast uploader and about 40 
> downloaders is literally a textbook example where bitorrent behaves at 
> its best. Yet the algorithm broke down fairly quickly, as though the 
> server pushed the chunks in linear order. That or something on the 
> network got in the way.

Any followup on this? I doubt it's the protocol/algorithm. It doesn't
matter what order the seed "pushes" blocks, if a seed gives a block to
just one of a well connected set of "leeches", that block will quickly
spread to all the others, causing them to never request that block from
the seed. Bittorrent block transfers are initiated by request, not
"pushed" by the seed.

It's far more likely that the seed is throttled in some way, than if
every one of those downloading peers are not talking to each other...

I'd look for throttling somewhere near (or at) the seed. Some ISPs are
getting very aggressive about throttling P2P traffic. A major backbone
throttling bittorrent traffic is quite likely these days... :P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/b8d7437a/attachment.sig>

From dcantrell at redhat.com  Fri Oct 17 01:28:50 2008
From: dcantrell at redhat.com (David Cantrell)
Date: Thu, 16 Oct 2008 15:28:50 -1000
Subject: removal of libdhcp (and related libraries)
Message-ID: <20081017012849.GA2334@rabbet.honolulu.burdell.org>

It's time for libdhcp to be removed.  If you do not know what libdhcp is, read
on -or- ignore this email entirely.

HISTORY

libdhcp was originally supposed to be a replacement for libpump.  libpump was
the only thing still being built out of the pump package before libdhcp came
along.  libdhcp was to give us a library capable of DHCP and DHCPv6 as well as
manual interface configuration (which is what pump did).

What appeared instead was a library called libdhcp which called functions in
libdhcp4client (for DHCP) or libdhcp6client (for DHCPv6).  Code reuse is good,
but this combination was a bit of a hassle to deal with.

The only programs to ever use libdhcp were anaconda and nash (part of
mkinitrd).

...skip to now

anaconda is now using NetworkManager for its networking backend.  That leaves
nash as the only remaining user of libdhcp.

USERS OF LIBDHCP

I would like libdhcp to be removed as soon as possible from Fedora, which
means nash needs to use something else, perhaps this:

    http://dcantrel.fedorapeople.org/patches/mkinitrd/0001-Use-libnl-and-dhclient-in-nash-for-network-configura.patch

OBJECTIONS

If, for some bizarre reason, you are using libdhcp, libdhcp4client, or
libdhcp6client, please tell me.  For most users, I think an alternative can be
found.  For potential users where libdhcp has become absolutely mission
critical for their environment, you might be the lucky winner and be the new
libdhcp maintainer.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/9943bf4d/attachment.sig>

From katzj at redhat.com  Fri Oct 17 01:32:10 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 16 Oct 2008 21:32:10 -0400
Subject: removal of libdhcp (and related libraries)
In-Reply-To: <20081017012849.GA2334@rabbet.honolulu.burdell.org>
References: <20081017012849.GA2334@rabbet.honolulu.burdell.org>
Message-ID: <1224207130.370.57.camel@aglarond.local>

On Thu, 2008-10-16 at 15:28 -1000, David Cantrell wrote:
> It's time for libdhcp to be removed.  If you do not know what libdhcp is, read
> on -or- ignore this email entirely.

Given that we're past the beta and, consequently, past the feature
freeze, I think that this is the sort of change that needs to wait for
Fedora 11.  Especially given that if the libnl+dhclient changes to nash
break it means that people won't be able to boot their systems.

Jeremy



From dcantrell at redhat.com  Fri Oct 17 04:37:59 2008
From: dcantrell at redhat.com (David Cantrell)
Date: Thu, 16 Oct 2008 18:37:59 -1000
Subject: removal of libdhcp (and related libraries)
In-Reply-To: <1224207130.370.57.camel@aglarond.local>
References: <20081017012849.GA2334@rabbet.honolulu.burdell.org>
	<1224207130.370.57.camel@aglarond.local>
Message-ID: <20081017043758.GA2991@rabbet.honolulu.burdell.org>

On Thu, Oct 16, 2008 at 09:32:10PM -0400, Jeremy Katz wrote:
> On Thu, 2008-10-16 at 15:28 -1000, David Cantrell wrote:
> > It's time for libdhcp to be removed.  If you do not know what libdhcp is, read
> > on -or- ignore this email entirely.
> 
> Given that we're past the beta and, consequently, past the feature
> freeze, I think that this is the sort of change that needs to wait for
> Fedora 11.  Especially given that if the libnl+dhclient changes to nash
> break it means that people won't be able to boot their systems.

That's fine.  So long as removing libdhcp happens sooner rather than later.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081016/bb79a211/attachment.sig>

From nicu_fedora at nicubunu.ro  Fri Oct 17 06:25:00 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 17 Oct 2008 09:25:00 +0300
Subject: The Big ACL Opening
In-Reply-To: <20081016171451.GA7049@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <48F82FBC.5010003@nicubunu.ro>

Lennart Poettering wrote:
> 
> Hmm, am I the only one who finds the choice of the term "?berpackager"
> a bit questionnable?

Pretty much terms like "?bergeek" and "?berhacker" are part of the 
online culture:
http://uncyclopedia.org/wiki/Ubergeek
http://en.wikipedia.org/wiki/Uberhacker

-- 
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 braden at endoframe.com  Fri Oct 17 06:58:38 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 17 Oct 2008 02:58:38 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <91705d080810150634g516508bby93f316288651b71@mail.gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48F5C75A.9040603@redhat.com>
	<91705d080810150634g516508bby93f316288651b71@mail.gmail.com>
Message-ID: <1224226718.20619.42.camel@hinge.endoframe.net>

On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
> On Wed, Oct 15, 2008 at 3:35 AM, Karsten Hopp <karsten at redhat.com> wrote:
> >
> > My last rebuild showed only ~100 failures, I'm not sure what I've done
> > differently
> > this time. I suspect that the removal of libtool-ltdl and all related
> > packages from
> > my full-install might have caused this and I'm in the process of rebuilding
> > those with libtool-2.
> > I've uploaded the current logs to http://karsten.fedorapeople.org/
> > After a quick glance at them I think that there are quite a few easy fixes,
> > but I still
> > have to find out what causes p.e. the cracklib failure.
> 
> Looking at the first few:
> 
> afflib: needs AC_PROG_CXX

Or better, just call autoconf instead of autoreconf.  (Or do it right
and patch configure.)

> amanda: aclocal not told where macros are, end up using old libtool m4 macros

The problem is that libtoolize is getting run at all.

> aplus-fsf: needs AC_PROG_CXX

Wow... This one's a mess.  I don't think that's the problem.  In fact,
I'm not convinced the problem with this package has anything to do with
libtool2.  It's hard to see what's going on amid all the warnings about
this code that the compiler is spewing; but if you scroll down to the
bottom you'll see it's just missing something that goes after a -L flag;
presumably some variable isn't getting set for some reason.

> apr: script manually copying libtool files and getting it wrong (just
> use autoreconf!)

Or don't.  I don't see any reason to regenerate configure in this
package.  Only Makefile.in is getting patched.

> avahi: needs AC_PROG_CXX

Again, this looks like a case where autoreconf doesn't need to be run at
all.

> ax25-apps: looks like aclocal was run, but libtoolize wasn't, causing
> mismatch between macros and ltmain.sh

I see this patching a couple of Makefile.am's; running automake should
be sufficient.  Eliding the calls to aclocal and autoconf should avoid
the problem.

> bind: aclocal not told where macros are, end up using old libtool m4 macros

It's not clear to me why this spec file is running libtoolize and
aclocal at all.

> blackbox: needs AC_PROG_CXX

I see no reason at all for this to be running autoreconf. (A comment
claims it gets rid of an rpath; I'd be a little surprised if this were
still true.)

> bmpx: needs AC_PROG_CXX

Actually, the problem is that it patches both configure.ac and
configure.  Presumably the timestamps don't line up right as a result
and "make" triggers regenerating stuff.  Either the patch to
configure.ac should be culled or the timestamps need massaging.
(There's also a patch to soup.m4 that just looks goofy.)

> bzflag: needs AC_PROG_CXX

I see no reason to call autoreconf here.

> cairo-dock: needs AC_PROG_CXX

Yikes. There's a bunch of magic happening here (of dubious value IMO;
but clearly the maintainer doesn't share that view).  I'm really not
sure what to say here.

> compat-db: libtool macros copied manually and getting it wrong

Yeah, more unusual stuff that's just very breakage-prone.  Hard to say
if there's a better way without some deep knowledge of this package.

> cracklib: yeah, failing on --tag=CC is very weird, especially when
> configure.in seems completely reasonable

Pulling in new libtool here is really unnecessary.  The package could
simply run autoconf instead of autoreconf.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From opensource at till.name  Fri Oct 17 07:38:04 2008
From: opensource at till.name (Till Maas)
Date: Fri, 17 Oct 2008 09:38:04 +0200
Subject: young Fedora torrents spread data too slowly
In-Reply-To: <1224203240.26341.175.camel@localhost.localdomain>
References: <48F0C1CE.30104@BitWagon.com> <48F1C2D0.2050403@poolshark.org>
	<1224203240.26341.175.camel@localhost.localdomain>
Message-ID: <200810170938.10710.opensource@till.name>

On Fri October 17 2008, Callum Lerwick wrote:

> Any followup on this? I doubt it's the protocol/algorithm. It doesn't

> It's far more likely that the seed is throttled in some way, than if
> every one of those downloading peers are not talking to each other...

I was told that the throtteling is intended to save bandwidth. The currently 
used software does not allow more intelligent usage of bandwidth. To avoid 
the slow seeding of new SnapXs, there will be more initial seeders which have  
more bandwidth than torrent1 for fresh torrents.

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/20081017/eaca11d3/attachment.sig>

From rawhide at fedoraproject.org  Fri Oct 17 10:29:20 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 17 Oct 2008 10:29:20 +0000 (UTC)
Subject: rawhide report: 20081017 changes
Message-ID: <20081017102920.A94A11B8001@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct 17 06:01:16 UTC 2008

New package DivFix++
        A program to repair broken AVI file streams by rebuilding index part of file
New package apt-mirror
        APT sources mirroring tool
New package perl-Net-Daemon
        Perl extension for portable daemons
New package primer3
        PCR primer design tool
New package printoxx
        Print image files
New package pthsem
        The GNU Portable Threads library extended with semaphore support
New package publican-ovirt
        Common documentation files for oVirt
New package qpackagekit
        Qt interface for PackageKit
New package sugar-moon
        Moon phases activity for sugar
Updated Packages:

R-2.7.2-2.fc10
--------------
* Thu Oct 16 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 2.7.2-2
- fix sh compile (bz 464055)


amqp-1.0.705289-1.fc10
----------------------
* Thu Oct 16 18:00:00 2008 Nuno Santos <nsantos at redhat.com> - 0:1.0.705289-1
- Rebased to svn rev 705289


asterisk-1.6.0.1-2.fc10
-----------------------
* Thu Oct 16 18:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.0.1-2
- Explicitly require dahdi-tools-libs to see if we can get this to build.


audacious-plugin-fc-0.3-1
-------------------------
* Thu Oct 16 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 0.3-1
- Update to 0.3 for Audacious >= 1.4.0.


audit-1.7.7-2.fc10
------------------
* Thu Oct 16 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.7-2
- Remove selinux policy for zos-remote


ballz-1.0.1-1.fc10
------------------
* Wed Oct 15 18:00:00 2008 Sylvain Beucler <beuc at beuc.net> - 1.0.1-1
- New upstream release that includes all patches and simplifies packaging


bluez-4.14-1.fc10
-----------------
* Fri Oct 17 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.14-1
- Update to 4.14


cairo-dock-1.6.3-0.2.svn1353_trunk.fc10
---------------------------------------

eclipse-3.4.1-2.fc10
--------------------
* Thu Oct 16 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.4.1-2
- Fix quoting bug in pdebuild.sh.

* Thu Oct 16 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.4.1-1
- Move copy-platform instead of copying it.

* Wed Oct 15 18:00:00 2008 Andrew Overholt <overholt at redhat.com> 3.4.1-1
- Add conditionals around Equinox initialization to enable debugging.

* Mon Oct 13 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.4.1-1
- Symlink to ant-apache-bsf and ant-commons-net. 
- Update branding.
- Don't re-pack JARs (see fedora-devel-java-list discussion in September 2008).
- Update desktop-file-install usage and add --vendor=fedora. (Andrew Overholt)
- Resolves #466476. Fix pdebuild script. (Jeff Johnston)
- Remove dropins contents while running initializer. 
- Add patch for wrong javaHome on x86_64 in the native build.(Alexander Kurtakov)

* Fri Oct  3 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.4.1-0
- 3.4.1
- Update nojarsignatures patch.
- Added osgi-classpath.patch fixes broken bootclasspath (Sean Flanigan).
- Removed patches 33 and 34 - not needed anymore.


eclipse-cdt-5.0.0-10.fc10
-------------------------
* Thu Oct 16 18:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 5.0.0-9
- Fix org.eclipse.linuxtools.libhover.glibc plugin to add toc.xml to
  binary file list.

* Thu Oct 16 18:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 5.0.0-8
- Fix org.eclipse.linuxtools.libhover.feature to include
  org.eclipse.linuxtools.libhover.library_docs plugin.
- Add work-around patch for managed configurations dialog problem.

* Thu Oct 16 18:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 5.0.0-10
- Change runtests section to remove new libhover plugin rather than old
  com.redhat.* autotools plugin.


file-4.26-3.fc10
----------------
* Thu Oct 16 18:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 4.26-3
- fix #465994 file --mime-encoding seems broken


glib2-2.18.2-1.fc10
-------------------
* Thu Oct 16 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.18.2-1
- Update to 2.18.2


gnome-lirc-properties-0.2.8-11.fc10
-----------------------------------
* Fri Oct 17 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.2.8-11
- Fix the Logitech mini-receivers being tagged as remotes

* Thu Oct 16 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.2.8-9
- Add support for Mac Mini remotes (#467149)

* Thu Oct 16 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.2.8-8
- Fix glade warning on startup

* Thu Oct 16 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.2.8-7
- Remove "Update" button, and don't load Fluendo provided remote
  definitions, they're older than ours

* Thu Oct 16 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.2.8-10
- Add more receiver definitions


Broken deps for i386
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From mzerqung at 0pointer.de  Fri Oct 17 10:34:56 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Fri, 17 Oct 2008 12:34:56 +0200
Subject: The Big ACL Opening
In-Reply-To: <48F79D1B.9080800@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<1224178664.17377.23.camel@victoria-eth>
	<48F79D1B.9080800@gmail.com>
Message-ID: <20081017103456.GA22692@tango.0pointer.de>

On Thu, 16.10.08 12:59, Toshio Kuratomi (a.badger at gmail.com) wrote:

> Paul W. Frields wrote:
> 
> > If we were to go with a dead language instead and say "ultrapackagers,"
> > would that be less likely to offend?  (Serious question, not being
> > snarky.)
> > 
> I can change this without too much trouble (Just have to remember all
> the places I just changed it :-).  I'll change to ultrapackagers in the
> source tree on Monday (hopefully deploying the same day but you never
> know) unless someone has a better suggestion.

I'd vote for "Superpackager". You could read an ironic connection to
"Superman" from that term, which is certainly more fun than one to the
"?bermensch".

Also, "Ultra" means "beyond" while "Super" means "above", IIRC. Super
hence appears more appropriate to me here, and less extreme. But
that's just me.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From llange at redhat.com  Fri Oct 17 11:31:32 2008
From: llange at redhat.com (Lutz Lange)
Date: Fri, 17 Oct 2008 13:31:32 +0200
Subject: Sendmail still default?
Message-ID: <48F87794.3090108@redhat.com>

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

Hi,

i've just wondered why sendmail is still the default MTA in Fedora.
Please enlighten me?

cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFI+HeU15TuH1mPaRURAr5AAJwOv5KOoZFZXdsIHlEALIfyA586xACePrlg
MtRkQuvfYTiN35lUcQFSnsQ=
=qzu9
-----END PGP SIGNATURE-----



From pertusus at free.fr  Fri Oct 17 11:35:04 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 17 Oct 2008 13:35:04 +0200
Subject: Sendmail still default?
In-Reply-To: <48F87794.3090108@redhat.com>
References: <48F87794.3090108@redhat.com>
Message-ID: <20081017113504.GD2698@free.fr>

On Fri, Oct 17, 2008 at 01:31:32PM +0200, Lutz Lange wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?

This is a (very) controversial issue. If I recall well, it has been
decided not to change anything for F10, but there was an heated thread
some time ago, and maybe this could be discussed in the timeframe of 
F11. To sum up some people considered that local delivery was a must for
the default MTA, and that a send-only MTA wasn't good enough, eg, for
cronie. My personnal opinion is that there should not be any MTA in the
@base or @code group, and that a MTA should be chosed if it is pulled in
as a dependency, so it could be sendmail or anything else. Whether local
delivery is a must for cronie or other packages that today require
/usr/sbin/sendmail is another story that caould be discussed a bit more,
though in the end it seems to me that this should be up to the
maintainer.

But could you please elaborate a bit more on something like a proposal?

--
Pat



From llange at redhat.com  Fri Oct 17 12:00:41 2008
From: llange at redhat.com (Lutz Lange)
Date: Fri, 17 Oct 2008 14:00:41 +0200
Subject: private group administration
Message-ID: <48F87E69.7040409@redhat.com>

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

Hi all,

i was thinking about user creation and group administration. Every user
gets his own private group when he is created. And the motivation for
that is to avoid users sharing files with all other users to per default
right?

But what if the user wants to change his files with a specific user or
two? An easy though not well known way to do that would be to push these
users into the private group. For this to work the user has to be
Administrator of his private group.

( eg. i'm tux with group tux
  - root has to make me administrator of my private group :
  # gpasswd -A tux tux

  now i can get paul in to my private group
  tux at somewhere ~> gpasswd -a paul tux

  or i could set/change my group passwort
  tux at somewhere ~> gpasswd tux

  change rights on /home/tux
  tux at somewhere ~> chmod g+rx .

  don't forget to check all the other dirs and files for group access
  tux at somewhere ~> ls -la .

  you might want to remove group and other bits
  tux at somewhere ~> chmod g=,o= * .*

  explicitly open a project dir in /home/tux
  tux at somewhere ~> mkdir project
  tux at somewhere ~> chmod g+rwx project

Writing this i realize that this will only make sense if i use the right
umask. So lets set it to something more secure, since i might not want
to change all my files with paul.

  tux at somewhere ~> vi .bashrc
	umask 077

All right it might not be in my best interest to share something in my
home dir, or if i do i have to be very careful about the permissions
there...

But i still thinks a user should be in control of his private group.
)

But he is not. This has to be set explicitly by the entity that creates
the user. I wonder what the reasoning is/was behind that.

Why is a user not made administrator of his private group per default?

Cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFI+H5p15TuH1mPaRURAg4BAJ9DxUEPfVHWIgSI56gkgOZauXsAQwCgrMfW
KQTnbpQE1Dc+WUipzERTzk4=
=QW4T
-----END PGP SIGNATURE-----



From llange at redhat.com  Fri Oct 17 12:11:19 2008
From: llange at redhat.com (Lutz Lange)
Date: Fri, 17 Oct 2008 14:11:19 +0200
Subject: Sendmail still default?
In-Reply-To: <20081017113504.GD2698@free.fr>
References: <48F87794.3090108@redhat.com> <20081017113504.GD2698@free.fr>
Message-ID: <48F880E7.6010306@redhat.com>

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

Patrice Dumas schrieb:
> On Fri, Oct 17, 2008 at 01:31:32PM +0200, Lutz Lange wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> i've just wondered why sendmail is still the default MTA in Fedora.
>> Please enlighten me?
> 
> This is a (very) controversial issue. If I recall well, it has been
> decided not to change anything for F10, but there was an heated thread
> some time ago, and maybe this could be discussed in the timeframe of 
> F11. To sum up some people considered that local delivery was a must for
> the default MTA, and that a send-only MTA wasn't good enough, eg, for
> cronie. My personnal opinion is that there should not be any MTA in the
> @base or @code group, and that a MTA should be chosed if it is pulled in
> as a dependency, so it could be sendmail or anything else. Whether local
> delivery is a must for cronie or other packages that today require
> /usr/sbin/sendmail is another story that caould be discussed a bit more,
> though in the end it seems to me that this should be up to the
> maintainer.
> 
> But could you please elaborate a bit more on something like a proposal?
> 
> --
> Pat
> 

Hi Pat,

i'm an instructor an just had students wondering why we still ship
sendmail as default. All i was really looking for was a good
argumentation shows why we do it like that. I wanted to show that is was
a choice and that we do it for good reason.
  The for me obvious alternative is using postfix as default. This seams
more up to date, easier to configure, and it's not a big blob of binary
software as sendmail seams to be. For the stability argument, i've hear
that sendmail and postfix are quite comparable and have had about the
amount of bug both in severity and count over the last few years.
  But to be fair, i will confess, i'm not really that deep into Mail and
therefore the wrong person to judge from a professional perspective.
Though i think we should provide good reasons for the thinks we ship /
do. An just arguing we've done this for X years this way, doesn't seam
enough somehow.

Cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFI+IDn15TuH1mPaRURAg3OAKDUpQ5HPGoJLKmU1LUpVCpyveN90wCgh60X
/a7mg0DQDpzUFk7wGcvfrfo=
=RwNa
-----END PGP SIGNATURE-----



From lesmikesell at gmail.com  Fri Oct 17 12:39:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 17 Oct 2008 07:39:05 -0500
Subject: Sendmail still default?
In-Reply-To: <48F87794.3090108@redhat.com>
References: <48F87794.3090108@redhat.com>
Message-ID: <48F88769.2010308@gmail.com>

Lutz Lange wrote:
>
> 
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?

It works. It can be configured to do just about anything.  Everyone who 
has every worked with a unix-like system is used to it.  Every program 
written for unix-like systems is likely to expect it to be installed. 
Even though the original design and code weren't particularly secure, 
the current version is probably one of the most audited pieces of code 
and the milter capability lets you extend it with features that don't 
share the full permissions of the main process yet can interact in real 
time during delivery.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From nicolas.mailhot at laposte.net  Fri Oct 17 12:49:31 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 17 Oct 2008 14:49:31 +0200 (CEST)
Subject: Sendmail still default?
In-Reply-To: <48F88769.2010308@gmail.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
Message-ID: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>



Le Ven 17 octobre 2008 14:39, Les Mikesell a ?crit :
>
> Lutz Lange wrote:
>>
>>
>> i've just wondered why sendmail is still the default MTA in Fedora.
>> Please enlighten me?
>
> It works.

Sort of

> It can be configured to do just about anything.

Like others

> Everyone who
> has every worked with a unix-like system is used to it.

No

>  Every program
> written for unix-like systems is likely to expect it to be installed.

They only expect the sendmail interface alternatives are also providing

> Even though the original design and code weren't particularly secure,
> the current version is probably one of the most audited pieces of code
> and

And upstream has such a confidence in the result they're rewriting it
from scratch.

> the milter capability lets you extend it with features that don't
> share the full permissions of the main process yet can interact in
> real time during delivery.

Milter is supported by alternatives too

Not that I particularly want to shoot ambulances, but those are not
good arguments.

-- 
Nicolas Mailhot



From fedora at shmuelhome.mine.nu  Fri Oct 17 12:57:08 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Fri, 17 Oct 2008 14:57:08 +0200
Subject: Sendmail still default?
In-Reply-To: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
Message-ID: <48F88BA4.1050106@shmuelhome.mine.nu>

Nicolas Mailhot wrote:
> Not that I particularly want to shoot ambulances, but those are not
> good arguments.
>
>   
They would be lousy arguments for changing to sendmail but they are 
fairly good arguments for keeping it. One needs a fairly compelling 
reason to change something that is already there. The above arguments 
amount to "there is no compelling reason to change".



From llange at redhat.com  Fri Oct 17 13:13:38 2008
From: llange at redhat.com (Lutz Lange)
Date: Fri, 17 Oct 2008 15:13:38 +0200
Subject: Sendmail still default?
In-Reply-To: <48F88BA4.1050106@shmuelhome.mine.nu>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88BA4.1050106@shmuelhome.mine.nu>
Message-ID: <48F88F82.7090100@redhat.com>

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

shmuel siegel schrieb:
> Nicolas Mailhot wrote:
>> Not that I particularly want to shoot ambulances, but those are not
>> good arguments.
>>
>>   
> They would be lousy arguments for changing to sendmail but they are
> fairly good arguments for keeping it. One needs a fairly compelling
> reason to change something that is already there. The above arguments
> amount to "there is no compelling reason to change".
> 

What about : it's not easy to configure it right or to learn how to do
it. If you already know it, you might be fine. If not you might be in
trouble.
And: It's second choice for an MTA for most people i know.
I may know the wrong people but as an instructor i meet quite a lot of
them :)

Cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFI+I+C15TuH1mPaRURAlqYAJ4ydPwaXtQtdoyldHDMNqPcysFLjgCfXcmi
KB5FCFnHtjs83aALxzhunSU=
=xdnt
-----END PGP SIGNATURE-----



From lesmikesell at gmail.com  Fri Oct 17 13:13:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 17 Oct 2008 08:13:06 -0500
Subject: Sendmail still default?
In-Reply-To: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
Message-ID: <48F88F62.5080004@gmail.com>

Nicolas Mailhot wrote:
> 
>>> i've just wondered why sendmail is still the default MTA in Fedora.
>>> Please enlighten me?
>> It works.
> 
> Sort of

What does that mean?  It delivers most of the mail on the internet and 
always has.

>> Even though the original design and code weren't particularly secure,
>> the current version is probably one of the most audited pieces of code
>> and
> 
> And upstream has such a confidence in the result they're rewriting it
> from scratch.

And its not the first time.  All good programs are periodically 
rewritten and improved.

>> the milter capability lets you extend it with features that don't
>> share the full permissions of the main process yet can interact in
>> real time during delivery.
> 
> Milter is supported by alternatives too

They pretend to, but won't actually run complex milters like MimeDefang.

> Not that I particularly want to shoot ambulances, but those are not
> good arguments.

Sorry, but I don't see any counterargument here.  The alternatives are 
all worse.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From denis at poolshark.org  Fri Oct 17 13:18:52 2008
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 17 Oct 2008 15:18:52 +0200
Subject: Sendmail still default?
In-Reply-To: <48F88769.2010308@gmail.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
Message-ID: <48F890BC.3090302@poolshark.org>

Les Mikesell wrote:
> It can be configured to do just about anything.

The sendmail configuration file is arguably one of the most complex and 
obfuscated configuration format ever designed in the history of computer 
science. :-)

-denis



From karsten at redhat.com  Fri Oct 17 13:20:59 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Fri, 17 Oct 2008 15:20:59 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <1224226718.20619.42.camel@hinge.endoframe.net>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>
	<48F5C75A.9040603@redhat.com>	<91705d080810150634g516508bby93f316288651b71@mail.gmail.com>
	<1224226718.20619.42.camel@hinge.endoframe.net>
Message-ID: <48F8913B.9000705@redhat.com>

Braden McDaniel schrieb:
> On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
>> On Wed, Oct 15, 2008 at 3:35 AM, Karsten Hopp <karsten at redhat.com> wrote:
>>> My last rebuild showed only ~100 failures, I'm not sure what I've done
>>> differently
>>> this time. I suspect that the removal of libtool-ltdl and all related
>>> packages from
>>> my full-install might have caused this and I'm in the process of rebuilding
>>> those with libtool-2.
>>> I've uploaded the current logs to http://karsten.fedorapeople.org/
>>> After a quick glance at them I think that there are quite a few easy fixes,
>>> but I still
>>> have to find out what causes p.e. the cracklib failure.
>> Looking at the first few:
>>
>> afflib: needs AC_PROG_CXX
> 
> Or better, just call autoconf instead of autoreconf.  (Or do it right
> and patch configure.)
> 
>> amanda: aclocal not told where macros are, end up using old libtool m4 macros
> 
> The problem is that libtoolize is getting run at all.
> 
>> aplus-fsf: needs AC_PROG_CXX
> 
> Wow... This one's a mess.  I don't think that's the problem.  In fact,
> I'm not convinced the problem with this package has anything to do with
> libtool2.  It's hard to see what's going on amid all the warnings about
> this code that the compiler is spewing; but if you scroll down to the
> bottom you'll see it's just missing something that goes after a -L flag;
> presumably some variable isn't getting set for some reason.
>

Looking at old build logs this isn't something introduced by libtool-2,
http://kojipkgs.fedoraproject.org/packages/aplus-fsf/4.22.4/4.fc10/data/logs/x86_64/build.log
shows the same error. New in libtool-2 is that it doesn't silently ignore or misparse this anymore
and bails out with an error instead. This is a bug in aplus-fsf that needs to be fixed.


....

> 
>> cracklib: yeah, failing on --tag=CC is very weird, especially when
>> configure.in seems completely reasonable

It seems that an old ltmain.sh causes this.

    Karsten



From a.badger at gmail.com  Fri Oct 17 13:20:46 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 17 Oct 2008 06:20:46 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1224226718.20619.42.camel@hinge.endoframe.net>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>
	<48F5C75A.9040603@redhat.com>	<91705d080810150634g516508bby93f316288651b71@mail.gmail.com>
	<1224226718.20619.42.camel@hinge.endoframe.net>
Message-ID: <48F8912E.8000104@gmail.com>

Braden McDaniel wrote:
> On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
> 
>> blackbox: needs AC_PROG_CXX
> 
> I see no reason at all for this to be running autoreconf. (A comment
> claims it gets rid of an rpath; I'd be a little surprised if this were
> still true.)
> 
*scratches head* If this is using an old, unpatched version of libtool,
wouldn't it add the rpath until a new version of libtool is inserted
into the package?  So it will be true until upstream is updated to use a
new version of libtool?

>> bmpx: needs AC_PROG_CXX
> 
> Actually, the problem is that it patches both configure.ac and
> configure.  Presumably the timestamps don't line up right as a result
> and "make" triggers regenerating stuff.  Either the patch to
> configure.ac should be culled or the timestamps need massaging.
> (There's also a patch to soup.m4 that just looks goofy.)
> 
Please stop giving bad advice (I think you're doing it in the interests
of brevity but still.) Telling people to have two patches, one for
configure.ac and one for configure and making sure the configure.ac
patch is applied before the configure patch is good advice, continue
doing that!  But using phrases like "or do it right and patch configure"
and "the patch to configure.ac should be culled" is bad advice; it
leaves people who read this thread and do not understand autotools with
the idea that a patch to configure *alone* is the best way to make
changes.  This is not true as we still want to have something to send to
upstream and a patch to configure, Makefile.in, or any other generated
files is not what upstream wants to see.

That's why I think an informational page about autotools stuff is
desirable.  It can explain the primary importance of patching the source
files (configure.ac, Makefile.am) and sending those patches upstream.
Then it can talk about the pros and cons of both methods of dealing with
the generated files so maintainers can see what they're getting
themselves in for if they choose one route over the other.

-Toshio

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

From llange at redhat.com  Fri Oct 17 13:28:07 2008
From: llange at redhat.com (Lutz Lange)
Date: Fri, 17 Oct 2008 15:28:07 +0200
Subject: Sendmail still default?
In-Reply-To: <48F88F62.5080004@gmail.com>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
Message-ID: <48F892E7.9000701@redhat.com>

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

Les Mikesell schrieb:
> 
> What does that mean?  It delivers most of the mail on the internet and
> always has.
> 
...
>>
>> Milter is supported by alternatives too
> 
> They pretend to, but won't actually run complex milters like MimeDefang.
> 
>> Not that I particularly want to shoot ambulances, but those are not
>> good arguments.
> 
> Sorry, but I don't see any counterargument here.  The alternatives are
> all worse.
> 

The question remains, is it the best option for the most users? That's
what the default MTA should be right?

Cheers
Lutz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFI+JLn15TuH1mPaRURAtONAKDRIaEFTxkxn2GBw6wVjchAVIbdVwCfWR3/
xAlGEz7mHPMp6DJ6ZMEKygk=
=07ts
-----END PGP SIGNATURE-----



From schaiba at gmail.com  Fri Oct 17 13:28:42 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Fri, 17 Oct 2008 16:28:42 +0300
Subject: Sendmail still default?
In-Reply-To: <48F890BC.3090302@poolshark.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<48F890BC.3090302@poolshark.org>
Message-ID: <778179b00810170628lab0a700m41741f7defca768d@mail.gmail.com>

On Fri, Oct 17, 2008 at 4:18 PM, Denis Leroy <denis at poolshark.org> wrote:

> Les Mikesell wrote:
>
>> It can be configured to do just about anything.
>>
>
> The sendmail configuration file is arguably one of the most complex and
> obfuscated configuration format ever designed in the history of computer
> science. :-)
>
> -denis
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

....so why not try exim4 for a change?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/48d54e46/attachment.htm>

From alan at redhat.com  Fri Oct 17 13:31:10 2008
From: alan at redhat.com (Alan Cox)
Date: Fri, 17 Oct 2008 09:31:10 -0400
Subject: Sendmail still default?
In-Reply-To: <48F890BC.3090302@poolshark.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<48F890BC.3090302@poolshark.org>
Message-ID: <20081017133110.GA8761@shell.devel.redhat.com>

On Fri, Oct 17, 2008 at 03:18:52PM +0200, Denis Leroy wrote:
> The sendmail configuration file is arguably one of the most complex and 
> obfuscated configuration format ever designed in the history of computer 
> science. :-)

You've clearly never worked with either IBM JCL or TECO



From bkearney at redhat.com  Fri Oct 17 13:28:09 2008
From: bkearney at redhat.com (Bryan Kearney)
Date: Fri, 17 Oct 2008 09:28:09 -0400
Subject: Sendmail still default?
In-Reply-To: <20081017133110.GA8761@shell.devel.redhat.com>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<48F890BC.3090302@poolshark.org>
	<20081017133110.GA8761@shell.devel.redhat.com>
Message-ID: <48F892E9.9050209@redhat.com>

Alan Cox wrote:
> On Fri, Oct 17, 2008 at 03:18:52PM +0200, Denis Leroy wrote:
>> The sendmail configuration file is arguably one of the most complex and 
>> obfuscated configuration format ever designed in the history of computer 
>> science. :-)
> 
> You've clearly never worked with either IBM JCL or TECO
> 
=3.4.2;;;;;;;;;;;;;;;;;;;;;;


-- bk



From mhw at WittsEnd.com  Fri Oct 17 13:35:33 2008
From: mhw at WittsEnd.com (Michael H. Warfield)
Date: Fri, 17 Oct 2008 09:35:33 -0400
Subject: Sendmail still default?
In-Reply-To: <48F88F82.7090100@redhat.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88BA4.1050106@shmuelhome.mine.nu>  <48F88F82.7090100@redhat.com>
Message-ID: <1224250533.7899.211.camel@canyon.wittsend.com>

On Fri, 2008-10-17 at 15:13 +0200, Lutz Lange wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> shmuel siegel schrieb:
> > Nicolas Mailhot wrote:
> >> Not that I particularly want to shoot ambulances, but those are not
> >> good arguments.
> >>
> >>   
> > They would be lousy arguments for changing to sendmail but they are
> > fairly good arguments for keeping it. One needs a fairly compelling
> > reason to change something that is already there. The above arguments
> > amount to "there is no compelling reason to change".

> What about : it's not easy to configure it right or to learn how to do
> it. If you already know it, you might be fine. If not you might be in
> trouble.

	If you're old school and insist on editing the .cf I might agree with
you but that then contradicts your "If not" clause.  If you don't know
what you're doing you might be deceived by complainers into thinking
that's how it's configured and that's how you have to do it.  

	OTOH...  The .m4 configurations are not very complicated.  Very
straight forward to enabled and disable features and configure names and
tokens and files.  I don't find the m4 interface to be any more
complicated to configure than say smail or postfix and a hell of a lot
simpler than many other utilities.  I find sendmail far easier to
configure than, say, squid or other complex utilities requiring acls and
filters, which we largely take for granted.  I also find that sendmail
generally works just fine out of the box for simple systems.

> And: It's second choice for an MTA for most people i know.
> I may know the wrong people but as an instructor i meet quite a lot of
> them :)

	Not quite sure I know how to parse that last one.  Do you mean that
sendmail is a second choice?  Or what is a second choice?  I'm not sure
one what the "It" is that you are referring to or how you are arguing
there.

	You mean that people given a list would place sendmail second?  I know
a lot of people in the business and have known a lot of them down
through the last two decades.  I know people who are passionate about
QMail and I know Wietse and I happen to think Postfix is wonderful and
I've personally contributed to the Smail project many many years ago and
I've even worked with and ported and configured MMDF (anyone remember
MMDF, the default MTA on SCO Unix for many many years?).  I would not
make the statement that most would put Sendmail second.  I would not
make the statement that most would put Sendmail first.  I know that both
Postfix and Sendmail are very popular.  Sendmail is well established as
the default with a reasonably easy option to switch to Postfix, and I
see no compelling reason to switch.

> Cheers
> Lutz

	Regards,
	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/8da808fa/attachment.sig>

From lesmikesell at gmail.com  Fri Oct 17 13:56:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 17 Oct 2008 08:56:54 -0500
Subject: Sendmail still default?
In-Reply-To: <48F890BC.3090302@poolshark.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<48F890BC.3090302@poolshark.org>
Message-ID: <48F899A6.3030807@gmail.com>

Denis Leroy wrote:
> Les Mikesell wrote:
>> It can be configured to do just about anything.
> 
> The sendmail configuration file is arguably one of the most complex and 
> obfuscated configuration format ever designed in the history of computer 
> science. :-)

Yes, it was designed back in the days of wooden computers and iron 
programmers - with a prime concern being the runtime processing needed 
to interpret the configuration.  But these days all of the m4 templates 
anyone might ever need have already been written, so everyone just 
uncomments or tweaks a few lines in sendmail.mc for options and the 
default already does the right thing for most people.  Or, for complex 
scenarios you can drop in MimeDefang as a milter and do most of the 
control steps with perl snippets.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lists at ralii.com  Fri Oct 17 14:11:01 2008
From: lists at ralii.com (Robert Locke)
Date: Fri, 17 Oct 2008 10:11:01 -0400
Subject: private group administration
In-Reply-To: <48F87E69.7040409@redhat.com>
References: <48F87E69.7040409@redhat.com>
Message-ID: <1224252661.5273.9.camel@rlt60f8.laptop.redhat.com>


On Fri, 2008-10-17 at 14:00 +0200, Lutz Lange wrote:

> Hi all,
> 
> i was thinking about user creation and group administration. Every user
> gets his own private group when he is created. And the motivation for
> that is to avoid users sharing files with all other users to per default
> right?
> 
> But what if the user wants to change his files with a specific user or
> two? An easy though not well known way to do that would be to push these
> users into the private group. For this to work the user has to be
> Administrator of his private group.

No, you are mixing collaboration with equivalence.  Putting someone in
your private group is more like making them you (based on current
implementation).  "ALL" my files are rw- by my private group.

> 
> ( eg. i'm tux with group tux
>   - root has to make me administrator of my private group :
>   # gpasswd -A tux tux
> 
>   now i can get paul in to my private group
>   tux at somewhere ~> gpasswd -a paul tux
> 
>   or i could set/change my group passwort
>   tux at somewhere ~> gpasswd tux
> 
>   change rights on /home/tux
>   tux at somewhere ~> chmod g+rx .
> 
>   don't forget to check all the other dirs and files for group access
>   tux at somewhere ~> ls -la .
> 
>   you might want to remove group and other bits
>   tux at somewhere ~> chmod g=,o= * .*
> 
>   explicitly open a project dir in /home/tux
>   tux at somewhere ~> mkdir project
>   tux at somewhere ~> chmod g+rwx project
> 
> Writing this i realize that this will only make sense if i use the right
> umask. So lets set it to something more secure, since i might not want
> to change all my files with paul.
> 
>   tux at somewhere ~> vi .bashrc
> 	umask 077
> 
> All right it might not be in my best interest to share something in my
> home dir, or if i do i have to be very careful about the permissions
> there...

So now the private group is not private and is more of a collaborative
group which is no longer "just working" and requiring the user to make a
bunch of caveats....  Changing the umask now breaks the way we "teach"
to do collaboration which takes advantage of the umask 0002 and uses
SGID to cause the collaborative group to be inherited from the directory
rather than the "primary/private" group of the process.  A slippery
slope....

Just use ACLs.  They are turned on by default by anaconda on our ext3
filesystems now through the filesystem superblock.

> 
> But i still thinks a user should be in control of his private group.
> )

Well, I don't have a good argument as to why a user should not be able
to administer their own private group, but still believe your "case
study" is better served by ACLs....

> 
> But he is not. This has to be set explicitly by the entity that creates
> the user. I wonder what the reasoning is/was behind that.
> 
> Why is a user not made administrator of his private group per default?
> 
> Cheers
> Lutz

--Rob



From dbn.lists at gmail.com  Fri Oct 17 14:11:30 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 17 Oct 2008 07:11:30 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1224226718.20619.42.camel@hinge.endoframe.net>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48F5C75A.9040603@redhat.com>
	<91705d080810150634g516508bby93f316288651b71@mail.gmail.com>
	<1224226718.20619.42.camel@hinge.endoframe.net>
Message-ID: <91705d080810170711i22f57b1ek1a7253f978b2cd5f@mail.gmail.com>

On Thu, Oct 16, 2008 at 11:58 PM, Braden McDaniel <braden at endoframe.com> wrote:
> On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
>> On Wed, Oct 15, 2008 at 3:35 AM, Karsten Hopp <karsten at redhat.com> wrote:
>> >
>> > My last rebuild showed only ~100 failures, I'm not sure what I've done
>> > differently
>> > this time. I suspect that the removal of libtool-ltdl and all related
>> > packages from
>> > my full-install might have caused this and I'm in the process of rebuilding
>> > those with libtool-2.
>> > I've uploaded the current logs to http://karsten.fedorapeople.org/
>> > After a quick glance at them I think that there are quite a few easy fixes,
>> > but I still
>> > have to find out what causes p.e. the cracklib failure.
>>
>> Looking at the first few:
>>
>> afflib: needs AC_PROG_CXX
>
> Or better, just call autoconf instead of autoreconf.  (Or do it right
> and patch configure.)

Again, I'm talking about real fixes to send upstream. There is a very
simple, correct way to fix this. If the packager wants to work around
it in one way or another, that's an option, but I'm interested in
getting things fixed correctly so they stop being broken now and
later.

Clearly, we're looking at this from two totally different perspectives.

--
Dan



From ajax at redhat.com  Fri Oct 17 14:13:47 2008
From: ajax at redhat.com (Adam Jackson)
Date: Fri, 17 Oct 2008 10:13:47 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <48F5C75A.9040603@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com>  <48F5C75A.9040603@redhat.com>
Message-ID: <1224252827.11508.1.camel@atropine.boston.devel.redhat.com>

On Wed, 2008-10-15 at 12:35 +0200, Karsten Hopp wrote:

> My last rebuild showed only ~100 failures, I'm not sure what I've done differently
> this time. I suspect that the removal of libtool-ltdl and all related packages from
> my full-install might have caused this and I'm in the process of rebuilding those with libtool-2.
> I've uploaded the current logs to http://karsten.fedorapeople.org/
> After a quick glance at them I think that there are quite a few easy fixes, but I still
> have to find out what causes p.e. the cracklib failure.

I don't know what's going on with the libXp and xorg-x11-drv-* failures,
we're not doing anything tricky.  Someone have a clue?

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/3c5d0a81/attachment.sig>

From denis at poolshark.org  Fri Oct 17 14:16:03 2008
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 17 Oct 2008 16:16:03 +0200
Subject: Updating gtksourceview
Message-ID: <48F89E23.5000601@poolshark.org>

I just realized that F-10 is going to ship with a very old version of 
gtksourceview (18-month old 1.8.5, while latest is 2.4). Is there a 
specific reason for that ?

I would like to push updates for glom that require the 2.0 API. I see 
about 10 dependent packages for libgtksourceview-1.0.so.0, some of which 
already support the 2.0 API. We're left with the following packages with 
hard 1.0 API dependencies :

- ocaml-lablgtk
- gnome-python2-gtksourceview
- mathmap
- conglomerate
- libgnomedb
- scratchpad

So either we'll have to write patches, or create a 
compat-gtksourceview10 package. Does anyone know the work involved to 
port from the 1.0 to the 2.0 API ?

-denis



From mclasen at redhat.com  Fri Oct 17 14:39:13 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 17 Oct 2008 10:39:13 -0400
Subject: Updating gtksourceview
In-Reply-To: <48F89E23.5000601@poolshark.org>
References: <48F89E23.5000601@poolshark.org>
Message-ID: <1224254353.3642.1.camel@localhost.localdomain>

On Fri, 2008-10-17 at 16:16 +0200, Denis Leroy wrote:
> I just realized that F-10 is going to ship with a very old version of 
> gtksourceview (18-month old 1.8.5, while latest is 2.4). Is there a 
> specific reason for that ?
> 
> I would like to push updates for glom that require the 2.0 API. I see 
> about 10 dependent packages for libgtksourceview-1.0.so.0, some of which 
> already support the 2.0 API. We're left with the following packages with 
> hard 1.0 API dependencies :
> 
> - ocaml-lablgtk
> - gnome-python2-gtksourceview
> - mathmap
> - conglomerate
> - libgnomedb
> - scratchpad
> 
> So either we'll have to write patches, or create a 
> compat-gtksourceview10 package. Does anyone know the work involved to 
> port from the 1.0 to the 2.0 API ?
> 
> -denis

gtksourceview2



From denis at poolshark.org  Fri Oct 17 14:42:43 2008
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 17 Oct 2008 16:42:43 +0200
Subject: Updating gtksourceview
In-Reply-To: <1224254353.3642.1.camel@localhost.localdomain>
References: <48F89E23.5000601@poolshark.org>
	<1224254353.3642.1.camel@localhost.localdomain>
Message-ID: <48F8A463.4000701@poolshark.org>

Matthias Clasen wrote:
> On Fri, 2008-10-17 at 16:16 +0200, Denis Leroy wrote:
>> I just realized that F-10 is going to ship with a very old version of 
>> gtksourceview (18-month old 1.8.5, while latest is 2.4). Is there a 
>> specific reason for that ?
>>
>> I would like to push updates for glom that require the 2.0 API. I see 
>> about 10 dependent packages for libgtksourceview-1.0.so.0, some of which 
>> already support the 2.0 API. We're left with the following packages with 
>> hard 1.0 API dependencies :
>>
>> - ocaml-lablgtk
>> - gnome-python2-gtksourceview
>> - mathmap
>> - conglomerate
>> - libgnomedb
>> - scratchpad
>>
>> So either we'll have to write patches, or create a 
>> compat-gtksourceview10 package. Does anyone know the work involved to 
>> port from the 1.0 to the 2.0 API ?
>>
>> -denis
> 
> gtksourceview2

Don't know how I missed it. nothing to see here, carry along :-)




From limb at jcomserv.net  Fri Oct 17 15:01:34 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 17 Oct 2008 10:01:34 -0500 (CDT)
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
	<68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
Message-ID: <27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>


> On Mon, Oct 13, 2008 at 2:48 PM, KH KH <kwizart at gmail.com> wrote:
>
>> 2008/10/13 Jon Ciesla <limb at jcomserv.net>:
>> >
>> >> Hi!
>> >>
>> >> As announced at http://www.yafray.org, yafaray replaces YafRay 0.0.9.
>> >> Thus I'm thinking of submitting yafray as dead.package in Rawhide.
>> (1)
>> >>
>> >> On the other side, I'm not going to work on yafaray soon. So, if
>> anyone
>> >> wants to start working on it, feel free.
>> >>
>> >> Nicolas (kwizart)
>> >>
>> >>
>> >> (1), There is no reason why yafray should stop working with the
>> current
>> >> blender releases. But there might be a problem when theses two are
>> >> installed together. (until now, blender either dlopen library or call
>> >> binary, from yafray).
>> >> This has to be discussed in the yafaray review. So, please cc'ed me
>> on
>> >> the review, along with your favorite reviewer. (or ask me as a
>> reviewer).
>> >
>> > I may just do that.  One thing though, am I blind or is there nor
>> yafaray
>> > tarball, and I'll have to work from a svn checkout?  (bleah)
>> Yes, that's right.
>> I think it will be appropriate to use a script to create one source
>> tarball.
>> Good luck !
>>
>>
> I can give you an .src.rpm that builds fine for F8, including the QT
> interface.
>
> http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc8.src.rpm

Thanks, I'll have a look, and see if I can rip-of^H^H^H^H^H^Hborrow from
this to solve some of the issues I've run into so far.

> If you are able to integrate yafaray with blender, let me know...
>
> --
> Paulo Roma Cavalcanti
> LCG - UFRJ
>


-- 
novus ordo absurdum



From cweyl at alumni.drew.edu  Fri Oct 17 15:14:31 2008
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Fri, 17 Oct 2008 08:14:31 -0700
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
Message-ID: <7dd7ab490810170814j24e1dd51w2f24d6f87e05ccc6@mail.gmail.com>

On Thu, Oct 16, 2008 at 5:39 AM, Kushal Das <kushaldas at gmail.com> wrote:

> Hi all,
>
> I am starting a project called review-o-matic which will do reviews of
> Fedora packages based on discussions at
> https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html
> .
> We know of having couple of scripts being used by different people to
> do so, but this tool's target is to consolidate those efforts and add
> a number of additional features as well. The basic idea is to remove
> the grunt work from package reviews.
>

Cool. Apparently I didn't mention it there, but I've already started work on
a base implementation.  I'm curious how you're intending to do this --
perhaps there's room for collaboration?

                                         -Chris
-- 
Chris Weyl
Ex astris, scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/ba7bc554/attachment.htm>

From limb at jcomserv.net  Fri Oct 17 15:22:04 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 17 Oct 2008 10:22:04 -0500 (CDT)
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
	<68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
	<27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>
Message-ID: <26499.198.175.55.5.1224256924.squirrel@mail.jcomserv.net>


>
>> On Mon, Oct 13, 2008 at 2:48 PM, KH KH <kwizart at gmail.com> wrote:
>>
>>> 2008/10/13 Jon Ciesla <limb at jcomserv.net>:
>>> >
>>> >> Hi!
>>> >>
>>> >> As announced at http://www.yafray.org, yafaray replaces YafRay
>>> 0.0.9.
>>> >> Thus I'm thinking of submitting yafray as dead.package in Rawhide.
>>> (1)
>>> >>
>>> >> On the other side, I'm not going to work on yafaray soon. So, if
>>> anyone
>>> >> wants to start working on it, feel free.
>>> >>
>>> >> Nicolas (kwizart)
>>> >>
>>> >>
>>> >> (1), There is no reason why yafray should stop working with the
>>> current
>>> >> blender releases. But there might be a problem when theses two are
>>> >> installed together. (until now, blender either dlopen library or
>>> call
>>> >> binary, from yafray).
>>> >> This has to be discussed in the yafaray review. So, please cc'ed me
>>> on
>>> >> the review, along with your favorite reviewer. (or ask me as a
>>> reviewer).
>>> >
>>> > I may just do that.  One thing though, am I blind or is there nor
>>> yafaray
>>> > tarball, and I'll have to work from a svn checkout?  (bleah)
>>> Yes, that's right.
>>> I think it will be appropriate to use a script to create one source
>>> tarball.
>>> Good luck !
>>>
>>>
>> I can give you an .src.rpm that builds fine for F8, including the QT
>> interface.
>>
>> http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc8.src.rpm
>
> Thanks, I'll have a look, and see if I can rip-of^H^H^H^H^H^Hborrow from
> this to solve some of the issues I've run into so far.

Hmm, on F-9:

scons: done building targets.
+ sed -i -es,/var/tmp/yafaray-0.1.0-buildroot,,g
/var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafaraycore.so
+ /usr/lib/rpm/find-debuginfo.sh /home/limb/rpmbuild/BUILD/yafaray
extracting debug info from
/var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafarayqt.so
extracting debug info from
/var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafaraycore.so
Failed to write file: invalid section alignment
error: Bad exit status from /var/tmp/rpm-tmp.80705 (%install)


>> If you are able to integrate yafaray with blender, let me know...
>>
>> --
>> Paulo Roma Cavalcanti
>> LCG - UFRJ
>>
>
>
> --
> novus ordo absurdum
>


-- 
novus ordo absurdum



From johannbg at hi.is  Fri Oct 17 15:46:20 2008
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Fri, 17 Oct 2008 15:46:20 +0000
Subject: Status of libtool 2.2.X?
In-Reply-To: <1224252827.11508.1.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>
	<48F5C75A.9040603@redhat.com>
	<1224252827.11508.1.camel@atropine.boston.devel.redhat.com>
Message-ID: <48F8B34C.9010301@hi.is>

Adam Jackson wrote:
> On Wed, 2008-10-15 at 12:35 +0200, Karsten Hopp wrote:
>
>   
>> My last rebuild showed only ~100 failures, I'm not sure what I've done differently
>> this time. I suspect that the removal of libtool-ltdl and all related packages from
>> my full-install might have caused this and I'm in the process of rebuilding those with libtool-2.
>> I've uploaded the current logs to http://karsten.fedorapeople.org/
>> After a quick glance at them I think that there are quite a few easy fixes, but I still
>> have to find out what causes p.e. the cracklib failure.
>>     
>
> I don't know what's going on with the libXp and xorg-x11-drv-* failures,
> we're not doing anything tricky.  Someone have a clue?
>
> - ajax
>   
Since there seemed to be bunch of stuff failing with X--tag=CC: command 
not found
This might shed some light on that issue...
http://news.ycombinator.com/item?id=261104

Hope it helps..

JBG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/050b3c6c/attachment.vcf>

From cra at WPI.EDU  Fri Oct 17 15:27:35 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 17 Oct 2008 11:27:35 -0400
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <7dd7ab490810170814j24e1dd51w2f24d6f87e05ccc6@mail.gmail.com>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<7dd7ab490810170814j24e1dd51w2f24d6f87e05ccc6@mail.gmail.com>
Message-ID: <20081017152735.GB27444@angus.ind.WPI.EDU>

On Fri, Oct 17, 2008 at 08:14:31AM -0700, Chris Weyl wrote:
> On Thu, Oct 16, 2008 at 5:39 AM, Kushal Das <kushaldas at gmail.com> wrote:
> 
> > Hi all,
> >
> > I am starting a project called review-o-matic which will do reviews of
> > Fedora packages based on discussions at
> > https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html
> > .
> > We know of having couple of scripts being used by different people to
> > do so, but this tool's target is to consolidate those efforts and add
> > a number of additional features as well. The basic idea is to remove
> > the grunt work from package reviews.
> >
> 
> Cool. Apparently I didn't mention it there, but I've already started work on
> a base implementation.  I'm curious how you're intending to do this --
> perhaps there's room for collaboration?

It would be great if some effort could also be spent extending rpmlint 
itself to handle most of these things.  Why implement a new tool when 
we have one already?

Also, we need to document somewhere what review items are checked by 
rpmlint.  Last time I did a review, I tried to figure out which of the 
items on the Packging Guidelines were checked by rpmlint, even going 
as far to check the source code, but gave up in frustration.  It is 
redundant to give rpmlint output, and then still have to report on 
every review guideline--even ones that the lack of rpmlint output 
implies.

Furthermore, since the Packaging Guidelines can change, it would help 
if they were versioned in some way so that rpmlint could refer to 
which version of the guidelines it is following.



From cweyl at alumni.drew.edu  Fri Oct 17 16:10:22 2008
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Fri, 17 Oct 2008 09:10:22 -0700
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <20081017152735.GB27444@angus.ind.WPI.EDU>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<7dd7ab490810170814j24e1dd51w2f24d6f87e05ccc6@mail.gmail.com>
	<20081017152735.GB27444@angus.ind.WPI.EDU>
Message-ID: <7dd7ab490810170910m5e23018n12df2306de18f895@mail.gmail.com>

On Fri, Oct 17, 2008 at 8:27 AM, Chuck Anderson <cra at wpi.edu> wrote:

>
> It would be great if some effort could also be spent extending rpmlint
> itself to handle most of these things.  Why implement a new tool when
> we have one already?


rpmlint is quite the useful tool -- however, much as we wouldn't extend ls
to email a directory listing, submitting koji scratch builds and posting
results to bugzilla is probably a bit out of scope for it :-)

                                  -Chris
-- 
Chris Weyl
Ex astris, scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/74262973/attachment.htm>

From lesmikesell at gmail.com  Fri Oct 17 17:05:10 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 17 Oct 2008 12:05:10 -0500
Subject: private group administration
In-Reply-To: <48F87E69.7040409@redhat.com>
References: <48F87E69.7040409@redhat.com>
Message-ID: <48F8C5C6.3050004@gmail.com>

Lutz Lange wrote:
> 
> i was thinking about user creation and group administration. Every user
> gets his own private group when he is created. And the motivation for
> that is to avoid users sharing files with all other users to per default
> right?

Not exactly.  Having your own private group assigned from the start 
makes it possible to use a default umask that gives group access to your 
files without actually giving anyone else access yet.  That means 
when/if you do want to let someone else have access, you don't have to 
go back and change the permissions on all your existing files and 
directories.


>   tux at somewhere ~> vi .bashrc
> 	umask 077

Don't forget to compliment the bits.  The default umask 002 gives group rwx.

> All right it might not be in my best interest to share something in my
> home dir, or if i do i have to be very careful about the permissions
> there...

No, the point of the private group is to permit access to everything 
that is yours.  If you don't want that, make a new group with the 
appropriate set of users added and use that group ownership instead of 
your own.

> But i still thinks a user should be in control of his private group.
> )
> 
> But he is not. This has to be set explicitly by the entity that creates
> the user. I wonder what the reasoning is/was behind that.
> 
> Why is a user not made administrator of his private group per default?

Think of common multiuser scenarios - like an office or school. 
Individuals are typically not in charge of their collaborative groups - 
that will be assigned by someone else.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From pertusus at free.fr  Fri Oct 17 17:31:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 17 Oct 2008 19:31:18 +0200
Subject: old release bugs handling
Message-ID: <20081017173118.GB2681@free.fr>

Hello,

When looking at the infra after eol issue, Toshio made me aware that 
nothing special is done for bugzilla in eol branches. Maybe it would 
be nice to have bugs filled against old branches associated with 
another product, such that they are easier to triage, and owner 
doesn't get those bugs automatically? As a disclaimer I know nothing 
about both the technical issues and the organizational issues involved
by that proposal. The idea could be along (provided it is technically 
feasible):

* when a bug is filled against an old release in the current fedora 
  product, the product is automatically changed to 'fedora EOL' 
  (or 'fedora Legacy' if that product is to be reused), which means 
  that they don't necessarily go to the same mail adress than current
  releases. Also there is an automatic answer for those bugs, along:

'You are reporting a bug against an unsupported fedora release, you 
are urged to upgrade, and retry with the new release'.

* the owner of this product is the owner of one of the old releases,
  for example could be the owner of F7 currently. That way, if this 
  release is orphaned by the maintainer, he won't get bug reports 
  for the old branch anymore. I would even suggest mass orphaning such 
  that the default is that the maintainer doesn't get those bugs.


Then people interested in triaging bugs for old releases could be 
subscribed to the adress all the product bugs are forwarded to, 
such that they can triage the bugs.


Of course this would make more sense in case the infra was left 
open for old releases, as there would be people specifically interested 
in triaging those bugs and also interested in becoming maintainers 
of old branches, but even if the proposal to keep infra open for old
branches is rejected --- and I am almost sure that it will be 
rejected --- it could still be something relevant to do.

Thoughts?



PS: tell me if this is better to ask that kind of question on the infra
list.

--
Pat



From ville.skytta at iki.fi  Fri Oct 17 17:40:56 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Fri, 17 Oct 2008 20:40:56 +0300
Subject: The Big ACL Opening
In-Reply-To: <20081017103456.GA22692@tango.0pointer.de>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
Message-ID: <200810172040.57322.ville.skytta@iki.fi>

On Friday 17 October 2008, Lennart Poettering wrote:

> Also, "Ultra" means "beyond" while "Super" means "above", IIRC. Super
> hence appears more appropriate to me here, and less extreme. But
> that's just me.

Nope, me too.



From limb at jcomserv.net  Fri Oct 17 17:46:10 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 17 Oct 2008 12:46:10 -0500 (CDT)
Subject: The Big ACL Opening
In-Reply-To: <200810172040.57322.ville.skytta@iki.fi>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
Message-ID: <11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>


> On Friday 17 October 2008, Lennart Poettering wrote:
>
>> Also, "Ultra" means "beyond" while "Super" means "above", IIRC. Super
>> hence appears more appropriate to me here, and less extreme. But
>> that's just me.
>
> Nope, me too.

An interesting irony here is that while Nietzsche's Ubermensch is best
translated as Overman, for English, it's commonly mistranslated as
Superman, and so Superpackager "sounds" more like what Lennart was getting
at than does Uberpackager.  To me, anyway.

FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
and superpackager.

> --
> 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  Fri Oct 17 17:03:51 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 17 Oct 2008 19:03:51 +0200
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <20081017152735.GB27444@angus.ind.WPI.EDU>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<7dd7ab490810170814j24e1dd51w2f24d6f87e05ccc6@mail.gmail.com>
	<20081017152735.GB27444@angus.ind.WPI.EDU>
Message-ID: <20081017170351.GA2681@free.fr>

On Fri, Oct 17, 2008 at 11:27:35AM -0400, Chuck Anderson wrote:
> 
> It would be great if some effort could also be spent extending rpmlint 
> itself to handle most of these things.  Why implement a new tool when 
> we have one already?
> 
> Furthermore, since the Packaging Guidelines can change, it would help 
> if they were versioned in some way so that rpmlint could refer to 
> which version of the guidelines it is following.

Unless I am wrong, rpmlint is not a checked for fedora package
guidelines, it is distribution agnostic, simply a tool for checking
common errors in rpm packages.

--
Pat



From tibbs at math.uh.edu  Fri Oct 17 18:07:33 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 17 Oct 2008 13:07:33 -0500
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <20081017170351.GA2681@free.fr>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<7dd7ab490810170814j24e1dd51w2f24d6f87e05ccc6@mail.gmail.com>
	<20081017152735.GB27444@angus.ind.WPI.EDU>
	<20081017170351.GA2681@free.fr>
Message-ID: <ufay70nksd6.fsf@epithumia.math.uh.edu>

>>>>> "PD" == Patrice Dumas <pertusus at free.fr> writes:

PD> Unless I am wrong, rpmlint is not a checked for fedora package
PD> guidelines, it is distribution agnostic, simply a tool for
PD> checking common errors in rpm packages.

Well, Ville does update (or patch, I'm not sure) our rpmlint to
correspond to our guidelines.  For example, verification of the
License: tag matches exactly the licenses from
http://fedoraproject.org/wiki/Licensing and the syntax rules in
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines (module
any delay in getting updates to those pages propagated into the code).

 - J<



From valent.turkovic at gmail.com  Fri Oct 17 18:44:10 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 17 Oct 2008 20:44:10 +0200
Subject: nvidia strangeness
Message-ID: <64b14b300810171144n623e1904l11ceb048f1131f2e@mail.gmail.com>

After last update and reboot I got really disturbed video.

I have Nvidia 6100go on HP tx1000 laptop using opensource nv driver running
fedora 10 (rawhide)

I can't even look what I'm typing so sorry for the typos...

Look how my fedora desktop looks after last update:
http://www.uploadgeek.com/uploads456/0/DSC07584.JPG
http://www.uploadgeek.com/uploads456/0/DSC07583.JPG
http://www.uploadgeek.com/uploads456/0/DSC07582.JPG
http://www.uploadgeek.com/uploads456/0/DSC07581.JPG

...

Bad, bad, bad...


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/765c0e08/attachment.htm>

From dominik at greysector.net  Fri Oct 17 18:55:49 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 17 Oct 2008 20:55:49 +0200
Subject: Sendmail still default?
In-Reply-To: <48F88F62.5080004@gmail.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
Message-ID: <20081017185549.GA2433@mokona.greysector.net>

On Friday, 17 October 2008 at 15:13, Les Mikesell wrote:
> Nicolas Mailhot wrote:
> >>>i've just wondered why sendmail is still the default MTA in Fedora.
> >>>Please enlighten me?
[...]
> >>the milter capability lets you extend it with features that don't
> >>share the full permissions of the main process yet can interact in
> >>real time during delivery.
> >
> >Milter is supported by alternatives too
> 
> They pretend to, but won't actually run complex milters like MimeDefang.

Postfix will: http://www.mimedefang.org/kwiki/index.cgi?Milter
...
Milter and Postfix

The Postfix MTA implemented partial Milter support in version 2.3 and more
complete support in 2.4. See http://www.postfix.org/MILTER_README.html for
details. MIMEDefang 2.63 works with Postfix.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> >Not that I particularly want to shoot ambulances, but those are not
> >good arguments.
> 
> Sorry, but I don't see any counterargument here.  The alternatives are 
> all worse.

Postfix is not worse. I'd argue that's it's better in every respect,
but I guess you wouldn't listen anyway and I'm a bit short on time.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jkeating at redhat.com  Fri Oct 17 18:56:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 11:56:35 -0700
Subject: post-beta snapshots
Message-ID: <1224269795.4142.14.camel@luminos.localdomain>

In this release cycle, we actually have working split media installs,
and getting those staged, along with the DVD, for i386, x86_64, ppc, and
source is proving quite challenging, especially when trying to stage
Live images for Desktop, KDE, i686/x86_64 (and any "spins" I have other
time for).  I just don't think we can do a compose + sync to torrents
(and now we have to sync multiple torrent locations so that the trackers
don't suck) in one day.  Also, I don't think we've ever had a successful
snapshot the first day we tried it (Thursdays).

I'm thinking we need to adjust this slightly, attempt the snapshot on
Wed instead, fix anything we can leading to Thursday, spend Thursday
creating the content, Thursday night staging the content and releasing
it on Friday.  This puts the snapshot content a day older than rawhide,
but that should be fine.

Anybody think this is a bad idea?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/1d9883ea/attachment.sig>

From ville.skytta at iki.fi  Fri Oct 17 19:00:35 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Fri, 17 Oct 2008 22:00:35 +0300
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <ufay70nksd6.fsf@epithumia.math.uh.edu>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<20081017170351.GA2681@free.fr>
	<ufay70nksd6.fsf@epithumia.math.uh.edu>
Message-ID: <200810172200.35964.ville.skytta@iki.fi>

On Friday 17 October 2008, Jason L Tibbitts III wrote:
> >>>>> "PD" == Patrice Dumas <pertusus at free.fr> writes:
>
> PD> Unless I am wrong, rpmlint is not a checked for fedora package
> PD> guidelines, it is distribution agnostic, simply a tool for
> PD> checking common errors in rpm packages.
>
> Well, Ville does update (or patch, I'm not sure) our rpmlint to
> correspond to our guidelines.  For example, verification of the
> License: tag matches exactly the licenses from
> http://fedoraproject.org/wiki/Licensing and the syntax rules in
> http://fedoraproject.org/wiki/Packaging/LicensingGuidelines (module
> any delay in getting updates to those pages propagated into the code).

That's right.  If necessary, we'll patch rpmlint in Fedora for Fedora needs, 
but I'd much rather make changes upstream.

The good thing is that a lot of the changes we've historically made in Fedora 
rpmlint have been found desirable in rpmlint upstream as well - other distros 
have found them useful too.  Compared to vanilla upstream, we currently have 
only two patches (one of which could actually be applicable upstream) and our 
own config in the Fedora package.  The license checks are a good example of 
this (and to give credit where it's due, it was spot who implemented them) - 
the code to check stuff is upstream and we just maintain the list of 
Fedora-approved license identifiers in config files in the Fedora package.

I'm sure that there are a lot of things that are not at all Fedora specific 
that rpmlint doesn't currently check but very well could.  Please do send 
patches either to Bugzilla or upstream rpmlint Trac, or just file RFE's 
(these usually preferably in upstream Trac) in case you have good ideas but 
no code yet.

The two things I'd like people to keep in mind when submitting rpmlint RFE's 
are that 1) ideally checks should be made as generic as feasible so we can 
maintain them upstream (but that doesn't have to prevent submitting entirely 
Fedora specific ones in Bugzilla), and 2) apart from some very specific 
checks on installed packages, the unit of work for rpmlint is one package.  
I'm not aware of any plans to change that (nor do I really know if it'd be a 
good direction for rpmlint), so some RFE's/bug reports may be rejected if 
getting them done would require knowledge of other packages than the one 
currently being checked.  Good patches are of course one way to change 
that ;)



From jkeating at redhat.com  Fri Oct 17 19:33:12 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 12:33:12 -0700
Subject: Fedora 10 Final Freeze less than 2 weeks away
Message-ID: <1224271992.4142.19.camel@luminos.localdomain>

We're getting quite close to the final devel freeze for Fedora 10.  A
week and a couple days is all that is left in the "free build" time.
After that point, any changes will have to be explicitly approved as per
the Final Freeze policy[1].

Now would be a very very good time to check the Fedora 10 Blocker[2] and
Tracker[3] bugs for things that involve your packages.

There is only this week's and next week's snapshots, then the preview
release (which is just a snapshot with a different name) before our
final release.  Lets work hard and together to make Fedora 10 awesome!


[1]: https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy
[2]:
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Blocker&hide_resolved=1
[3]:
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Target&hide_resolved=1

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/0d166398/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 jkeating at redhat.com  Fri Oct 17 19:36:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 12:36:30 -0700
Subject: Fedora 10 Snapshot 2
Message-ID: <1224272190.4142.22.camel@luminos.localdomain>

This week brings us Fedora 10 Snapshot 2.  This time not only will we
have Live images, we'll also have DVD and split CD install images.  Due
to the amount of data to sync around, we're going to stagger the torrent
releases, making them available as they finish syncing to the torrent
server.  Please keep watching http://torrent.fedoraproject.org/ for new
torrents to start showing up in the next few hours.

Based on feedback from Snapshot 1 we're also adding a few more seeders
to help get the bits out.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/e4e2aa30/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 jkeating at redhat.com  Fri Oct 17 19:49:15 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 12:49:15 -0700
Subject: Collapsing DVD and CD torrents into one
Message-ID: <1224272955.4142.25.camel@luminos.localdomain>

Most torrent clients I've seen today allow you to pick and choose which
files you wish to download.  As such, does it make sense to collapse the
DVD and CD torrents into a single torrent and allow people to use the
client to pick which they want?  Are there pros/cons to this?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/cbb00edb/attachment.sig>

From limb at jcomserv.net  Fri Oct 17 19:51:08 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 17 Oct 2008 14:51:08 -0500 (CDT)
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>


> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?

Does it work it bittorrent-curses?

> --
> Jesse Keating
> Fedora -- Freedom?? is a feature!
> identi.ca: http://identi.ca/jkeating
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From notting at redhat.com  Fri Oct 17 19:52:30 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 17 Oct 2008 15:52:30 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <20081017195230.GA13662@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?

By 'most', do you know specifically which ones do not?

Bill



From konrad at tylerc.org  Fri Oct 17 19:51:16 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 17 Oct 2008 12:51:16 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <200810171251.16971.konrad@tylerc.org>

On Friday 17 October 2008 12:49:15 pm Jesse Keating wrote:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?

Something to keep in mind: Debian doesn't even put multiple CDs/DVDs from the 
same release into one torrent, instead having a separate torrent per ISO. I'm 
not entirely sure of their rationale for doing this, but maybe keep it in 
mind?

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From skvidal at fedoraproject.org  Fri Oct 17 19:57:22 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 17 Oct 2008 19:57:22 +0000
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <1224273442.21581.95.camel@rosebud>

On Fri, 2008-10-17 at 12:49 -0700, Jesse Keating wrote:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?

mindlessness for downloading, I guess.

limiting space consumed?


-sv




From kaie at kuix.de  Fri Oct 17 19:58:38 2008
From: kaie at kuix.de (Kai Engert)
Date: Fri, 17 Oct 2008 21:58:38 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <48F8EE6E.5060603@kuix.de>

Jesse Keating wrote:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?
>   

Those who don't know about this (or are too lazy to check) will download 
everything, causing extra traffic.

Kai

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

From konrad at tylerc.org  Fri Oct 17 19:52:41 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 17 Oct 2008 12:52:41 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
Message-ID: <200810171252.41862.konrad@tylerc.org>

On Friday 17 October 2008 12:51:08 pm Jon Ciesla wrote:
> > Most torrent clients I've seen today allow you to pick and choose which
> > files you wish to download.  As such, does it make sense to collapse the
> > DVD and CD torrents into a single torrent and allow people to use the
> > client to pick which they want?  Are there pros/cons to this?
>
> Does it work it bittorrent-curses?

I believe rtorrent can selectively enable or disable individual files in a 
torrent, and it has a curses interface.

-- 
Conrad Meyer <konrad at tylerc.org>




From jreiser at BitWagon.com  Fri Oct 17 19:59:05 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Fri, 17 Oct 2008 12:59:05 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <48F8EE89.1030907@BitWagon.com>

> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.

The original bittorrent client does *NOT* have this feature.

-- 



From jkeating at redhat.com  Fri Oct 17 20:04:30 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 13:04:30 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <20081017195230.GA13662@nostromo.devel.redhat.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<20081017195230.GA13662@nostromo.devel.redhat.com>
Message-ID: <1224273870.4142.27.camel@luminos.localdomain>

On Fri, 2008-10-17 at 15:52 -0400, Bill Nottingham wrote:
> By 'most', do you know specifically which ones do not?

Hrm, actually I don't.  The 'most' is anecdotal as well.  Every client
I've used supports it, however I wouldn't feel comfortable saying every
client supports it.

I've used transmission, Azureus, deluge, and a couple others I can't
remember any more.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/2407d535/attachment.sig>

From skvidal at fedoraproject.org  Fri Oct 17 20:06:26 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 17 Oct 2008 16:06:26 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224273870.4142.27.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<20081017195230.GA13662@nostromo.devel.redhat.com>
	<1224273870.4142.27.camel@luminos.localdomain>
Message-ID: <1224273986.21581.97.camel@rosebud>

On Fri, 2008-10-17 at 13:04 -0700, Jesse Keating wrote:
> On Fri, 2008-10-17 at 15:52 -0400, Bill Nottingham wrote:
> > By 'most', do you know specifically which ones do not?
> 
> Hrm, actually I don't.  The 'most' is anecdotal as well.  Every client
> I've used supports it, however I wouldn't feel comfortable saying every
> client supports it.
> 
> I've used transmission, Azureus, deluge, and a couple others I can't
> remember any more.
> 

how about the default bittorrent-curses client?

-sv




From jkeating at redhat.com  Fri Oct 17 20:08:35 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 13:08:35 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
Message-ID: <1224274115.4142.28.camel@luminos.localdomain>

On Fri, 2008-10-17 at 14:51 -0500, Jon Ciesla wrote:
> Does it work it bittorrent-curses?

I don't think so, but bittorrent-* from bittorrent.com is essentially
dead code to us, since they closed source any newer versions.  I don't
think we should consider it the 'least common denominator' anymore.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/e48ee70c/attachment.sig>

From jkeating at redhat.com  Fri Oct 17 20:09:43 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 13:09:43 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224273442.21581.95.camel@rosebud>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<1224273442.21581.95.camel@rosebud>
Message-ID: <1224274183.4142.29.camel@luminos.localdomain>

On Fri, 2008-10-17 at 19:57 +0000, seth vidal wrote:
> mindlessness for downloading, I guess.
> 
> limiting space consumed?

Huh?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/ba4c89e6/attachment.sig>

From jkeating at redhat.com  Fri Oct 17 20:10:14 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 13:10:14 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8EE6E.5060603@kuix.de>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE6E.5060603@kuix.de>
Message-ID: <1224274215.4142.30.camel@luminos.localdomain>

On Fri, 2008-10-17 at 21:58 +0200, Kai Engert wrote:
> Those who don't know about this (or are too lazy to check) will download 
> everything, causing extra traffic.

Which is just traffic between peers, which will actually help the peers
that do want the data.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/cc4bf6ea/attachment.sig>

From jkeating at redhat.com  Fri Oct 17 20:10:36 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 13:10:36 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8EE89.1030907@BitWagon.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>
Message-ID: <1224274237.4142.31.camel@luminos.localdomain>

On Fri, 2008-10-17 at 12:59 -0700, John Reiser wrote:
> > Most torrent clients I've seen today allow you to pick and choose which
> > files you wish to download.
> 
> The original bittorrent client does *NOT* have this feature.
> 
> -- 
> 

Which one, the dead opensource one, or the continued closed source one?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/e7f1786b/attachment.sig>

From jreiser at BitWagon.com  Fri Oct 17 20:28:52 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Fri, 17 Oct 2008 13:28:52 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224274237.4142.31.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>	<48F8EE89.1030907@BitWagon.com>
	<1224274237.4142.31.camel@luminos.localdomain>
Message-ID: <48F8F584.3090208@BitWagon.com>

>>> Most torrent clients I've seen today allow you to pick and choose which
>>> files you wish to download.

>> The original bittorrent client does *NOT* have this feature.

> Which one, the dead opensource one, or the continued closed source one?

bittorrent-4.4.0-7.fc9.noarch continues to work as originally intended:
all files in the torrent are downloaded.

-- 



From lesmikesell at gmail.com  Fri Oct 17 19:33:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 17 Oct 2008 14:33:34 -0500
Subject: Sendmail still default?
In-Reply-To: <20081017185549.GA2433@mokona.greysector.net>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>
	<20081017185549.GA2433@mokona.greysector.net>
Message-ID: <48F8E88E.5090700@gmail.com>

Dominik 'Rathann' Mierzejewski wrote:
>
> [...]
>>>> the milter capability lets you extend it with features that don't
>>>> share the full permissions of the main process yet can interact in
>>>> real time during delivery.
>>> Milter is supported by alternatives too
>> They pretend to, but won't actually run complex milters like MimeDefang.
> 
> Postfix will: http://www.mimedefang.org/kwiki/index.cgi?Milter
> ...
> Milter and Postfix
> 
> The Postfix MTA implemented partial Milter support in version 2.3 and more
> complete support in 2.4. See http://www.postfix.org/MILTER_README.html for
> details. MIMEDefang 2.63 works with Postfix.
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Interesting - that doesn't seem to be generally known.  I hadn't seen it 
mentioned on the MimeDefang list.  Maybe it is just because the 
distributions stable enough to be used as a mail server don't include 
2.4 yet.

>>> Not that I particularly want to shoot ambulances, but those are not
>>> good arguments.
>> Sorry, but I don't see any counterargument here.  The alternatives are 
>> all worse.
> 
> Postfix is not worse. I'd argue that's it's better in every respect,
> but I guess you wouldn't listen anyway and I'm a bit short on time.

It's worse at backwards compatibility.  Fedora seems to assume that 
their users don't already have something working, so maybe that's not a 
concern to anyone here.  If it shipped with a decked-out, well tested 
setup already integrated with MimeDefang/clamd/spamassassin it might be 
enough of an improvement to switch.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From myfedora at richip.dhs.org  Fri Oct 17 20:29:32 2008
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 17 Oct 2008 14:29:32 -0600
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <48F8F5AC.7050303@richip.dhs.org>

Jesse Keating wrote:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?
>   

 From an ease-of-use standpoint, I'd say now's not the time to collate 
the ISO's under one torrent. Most people really only download one ISO. 
Two if they're supporting multiple platforms (might be a good idea to go 
back to stats to see). Currently, I have my desktop set up such that 
when I click on a torrent file in my browser, it passes it off to 
Azureus which downloads it in the background. Two clicks (which could be 
made one if I told Firefox to "Always perform" the action).

The argument here is whether to "default to all and remove items" or to 
"select each item one-by-one and somehow add a select all".

It would be nice if the BT protocol could actually support including a 
subset of a torrent in the set for that standalone torrent, though (ie. 
if I had the DVD image in a torrent that's composed of more files than 
just that ISO image, it would still allow people who are just 
downloading the standalone ISO image torrent to use my share as a 
resource). That would make offering both options attractive.
--

Richi Plana



From jkeating at redhat.com  Fri Oct 17 20:29:51 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 13:29:51 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8F584.3090208@BitWagon.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>
	<1224274237.4142.31.camel@luminos.localdomain>
	<48F8F584.3090208@BitWagon.com>
Message-ID: <1224275391.4142.32.camel@luminos.localdomain>

On Fri, 2008-10-17 at 13:28 -0700, John Reiser wrote:
> bittorrent-4.4.0-7.fc9.noarch continues to work as originally
> intended:
> all files in the torrent are downloaded.

Right, that's the old dead one.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/84a52b31/attachment.sig>

From behdad at behdad.org  Fri Oct 17 20:42:19 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Fri, 17 Oct 2008 16:42:19 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224274115.4142.28.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
	<1224274115.4142.28.camel@luminos.localdomain>
Message-ID: <48F8F8AB.3070304@behdad.org>

Jesse Keating wrote:
> On Fri, 2008-10-17 at 14:51 -0500, Jon Ciesla wrote:
>> Does it work it bittorrent-curses?
> 
> I don't think so, but bittorrent-* from bittorrent.com is essentially
> dead code to us, since they closed source any newer versions.  I don't
> think we should consider it the 'least common denominator' anymore.

Then why don't you tell us what one can use from the cmdline as easily as
bittorrent-curses?

I agree with seth: mindlessness.  How am I going to explain to a friend of
mine who wants to download Fedora then?  "Take the torrent from the site, but
then only download the file with dvd in the name".

Why don't we also include nonfree codecs in the image and make some cash while
at it?

behdad



From sundaram at fedoraproject.org  Fri Oct 17 20:45:19 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 18 Oct 2008 02:15:19 +0530
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8F8AB.3070304@behdad.org>
References: <1224272955.4142.25.camel@luminos.localdomain>	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>	<1224274115.4142.28.camel@luminos.localdomain>
	<48F8F8AB.3070304@behdad.org>
Message-ID: <48F8F95F.3050904@fedoraproject.org>

Behdad Esfahbod wrote:
> Jesse Keating wrote:
>> On Fri, 2008-10-17 at 14:51 -0500, Jon Ciesla wrote:
>>> Does it work it bittorrent-curses?
>> I don't think so, but bittorrent-* from bittorrent.com is essentially
>> dead code to us, since they closed source any newer versions.  I don't
>> think we should consider it the 'least common denominator' anymore.
> 
> Then why don't you tell us what one can use from the cmdline as easily as
> bittorrent-curses?
> 
> I agree with seth: mindlessness.  How am I going to explain to a friend of
> mine who wants to download Fedora then?  "Take the torrent from the site, but
> then only download the file with dvd in the name".
> 
> Why don't we also include nonfree codecs in the image and make some cash while
> at it?

Stop being rude without any provocation at all. Jesse Keating *is* 
asking for feedback, so you can be courteous while disagreeing.

Rahul



From behdad at behdad.org  Fri Oct 17 20:49:32 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Fri, 17 Oct 2008 16:49:32 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8F95F.3050904@fedoraproject.org>
References: <1224272955.4142.25.camel@luminos.localdomain>	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>	<1224274115.4142.28.camel@luminos.localdomain>	<48F8F8AB.3070304@behdad.org>
	<48F8F95F.3050904@fedoraproject.org>
Message-ID: <48F8FA5C.9060303@behdad.org>

Rahul Sundaram wrote:
> Behdad Esfahbod wrote:
>> Jesse Keating wrote:
>>> On Fri, 2008-10-17 at 14:51 -0500, Jon Ciesla wrote:
>>>> Does it work it bittorrent-curses?
>>> I don't think so, but bittorrent-* from bittorrent.com is essentially
>>> dead code to us, since they closed source any newer versions.  I don't
>>> think we should consider it the 'least common denominator' anymore.
>>
>> Then why don't you tell us what one can use from the cmdline as easily as
>> bittorrent-curses?
>>
>> I agree with seth: mindlessness.  How am I going to explain to a
>> friend of
>> mine who wants to download Fedora then?  "Take the torrent from the
>> site, but
>> then only download the file with dvd in the name".
>>
>> Why don't we also include nonfree codecs in the image and make some
>> cash while
>> at it?
> 
> Stop being rude without any provocation at all. Jesse Keating *is*
> asking for feedback, so you can be courteous while disagreeing.

I didn't intend to be rude, sorry if it looked that way.  I was showing by
example that merging the CD and DVD images is making it hard for users to get
what they want without what they don't want.  I don't think the example was
too far.

behdad

> Rahul
> 



From walters at verbum.org  Fri Oct 17 20:58:18 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 17 Oct 2008 16:58:18 -0400
Subject: Sendmail still default?
In-Reply-To: <48F87794.3090108@redhat.com>
References: <48F87794.3090108@redhat.com>
Message-ID: <faa16b610810171358h5221993wcf05923c55d6163b@mail.gmail.com>

On Fri, Oct 17, 2008 at 7:31 AM, Lutz Lange <llange at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?

A note - the desktop spin would like to have no MTA by default for
F11.  We'll likely change the way cron is handled so that if you have
per-user cron jobs an MTA is installed.

What MTA the server images use is up to whoever owns server stuff  (I
like Postfix too personally).



From alan at redhat.com  Fri Oct 17 21:01:47 2008
From: alan at redhat.com (Alan Cox)
Date: Fri, 17 Oct 2008 17:01:47 -0400
Subject: The Big ACL Opening
In-Reply-To: <11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
Message-ID: <20081017210147.GA24430@shell.devel.redhat.com>

> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
> and superpackager.

Super is probably sane enough but English has a long and distinguished
history of stealing other peoples words and using them wrongly so uber- in
English [ab]use is not atypical ;)



From sundaram at fedoraproject.org  Fri Oct 17 21:01:28 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 18 Oct 2008 02:31:28 +0530
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8EE89.1030907@BitWagon.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>
Message-ID: <48F8FD28.5070805@fedoraproject.org>

John Reiser wrote:
>> Most torrent clients I've seen today allow you to pick and choose which
>> files you wish to download.
> 
> The original bittorrent client does *NOT* have this feature.

The "original" client went proprietary and is a dead end. Everybody 
should be using something more actively maintained.

Rahul



From skvidal at fedoraproject.org  Fri Oct 17 21:17:15 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 17 Oct 2008 21:17:15 +0000
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8FD28.5070805@fedoraproject.org>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>  <48F8FD28.5070805@fedoraproject.org>
Message-ID: <1224278235.21581.104.camel@rosebud>

On Sat, 2008-10-18 at 02:31 +0530, Rahul Sundaram wrote:
> John Reiser wrote:
> >> Most torrent clients I've seen today allow you to pick and choose which
> >> files you wish to download.
> > 
> > The original bittorrent client does *NOT* have this feature.
> 
> The "original" client went proprietary and is a dead end. Everybody 
> should be using something more actively maintained.
> 

in terms of clients - there are a lot of choices.
in terms of trackers and good server-like-seeders there are NOT a lot of
choices.

the original bittorrent client pre-proprietary is the best we have right
now.

-sv




From jkeating at redhat.com  Fri Oct 17 21:27:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 14:27:53 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8F8AB.3070304@behdad.org>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
	<1224274115.4142.28.camel@luminos.localdomain>
	<48F8F8AB.3070304@behdad.org>
Message-ID: <1224278873.4142.39.camel@luminos.localdomain>

On Fri, 2008-10-17 at 16:42 -0400, Behdad Esfahbod wrote:
> Then why don't you tell us what one can use from the cmdline as easily as
> bittorrent-curses?
> 
> I agree with seth: mindlessness.  How am I going to explain to a friend of
> mine who wants to download Fedora then?  "Take the torrent from the site, but
> then only download the file with dvd in the name".

Mindless and commandline don't often go hand in hand (:

The way it works for me is I click on a torrent file that's offered via
a webpage, like get.fedoraproject.org .  This opens up Transmission,
which shows me a window with all the files in the torrent, boxes
pre-checked by them.  I uncheck what I don't want to download and hit
"add".  Transmission starts downloading the content and life is good.

We can reduce the number of links offered to users on download pages,
simplify the instructions, and have a better end user experience.

I'd imagine other desktops have similar workflows when dealing with
torrent files, I'd think resorting to the command line to deal with them
would be a last resort for the people who need help getting Fedora
downloaded.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/66ab28b8/attachment.sig>

From jkeating at redhat.com  Fri Oct 17 21:30:03 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 14:30:03 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8F5AC.7050303@richip.dhs.org>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8F5AC.7050303@richip.dhs.org>
Message-ID: <1224279003.4142.41.camel@luminos.localdomain>

On Fri, 2008-10-17 at 14:29 -0600, Richi Plana wrote:
>  From an ease-of-use standpoint, I'd say now's not the time to collate 
> the ISO's under one torrent. Most people really only download one ISO. 
> Two if they're supporting multiple platforms (might be a good idea to go 
> back to stats to see).

Hrm, I meant collapsing them per arch, so you'd have one torrent file
for Fedora 10 x86_64, one for Fedora 10 i386, ppc, source etc..  and
probably different torrent files for the i686 Live and x86_64 Live
offerings.  I wouldn't imagine one giant torrent file that has every iso
of the release on it.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/0d1ec3ff/attachment.sig>

From skvidal at fedoraproject.org  Fri Oct 17 21:31:49 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 17 Oct 2008 17:31:49 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224278873.4142.39.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
	<1224274115.4142.28.camel@luminos.localdomain>
	<48F8F8AB.3070304@behdad.org>
	<1224278873.4142.39.camel@luminos.localdomain>
Message-ID: <1224279109.21581.106.camel@rosebud>

On Fri, 2008-10-17 at 14:27 -0700, Jesse Keating wrote:
> On Fri, 2008-10-17 at 16:42 -0400, Behdad Esfahbod wrote:
> > Then why don't you tell us what one can use from the cmdline as easily as
> > bittorrent-curses?
> > 
> > I agree with seth: mindlessness.  How am I going to explain to a friend of
> > mine who wants to download Fedora then?  "Take the torrent from the site, but
> > then only download the file with dvd in the name".
> 
> Mindless and commandline don't often go hand in hand (:
> 
> The way it works for me is I click on a torrent file that's offered via
> a webpage, like get.fedoraproject.org .  This opens up Transmission,
> which shows me a window with all the files in the torrent, boxes
> pre-checked by them.  I uncheck what I don't want to download and hit
> "add".  Transmission starts downloading the content and life is good.
> 
> We can reduce the number of links offered to users on download pages,
> simplify the instructions, and have a better end user experience.
> 
> I'd imagine other desktops have similar workflows when dealing with
> torrent files, I'd think resorting to the command line to deal with them
> would be a last resort for the people who need help getting Fedora
> downloaded.

someone asks me how to do it I can paste the command in that does the
whole thing.

-sv




From jreiser at BitWagon.com  Fri Oct 17 21:39:41 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Fri, 17 Oct 2008 14:39:41 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224278873.4142.39.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>	<1224274115.4142.28.camel@luminos.localdomain>	<48F8F8AB.3070304@behdad.org>
	<1224278873.4142.39.camel@luminos.localdomain>
Message-ID: <48F9061D.8080508@BitWagon.com>

> I'd think resorting to the command line to deal with them
> would be a last resort for the people who need help getting Fedora
> downloaded.

Many servers do not have X11 installed, yet have the connectivity
and bandwidth that torrents can use well.  transmission-daemon and
transmission-remote offer a reasonable command-line interface,
including control over subset downloads.

-- 



From csnook at redhat.com  Fri Oct 17 21:45:56 2008
From: csnook at redhat.com (Chris Snook)
Date: Fri, 17 Oct 2008 17:45:56 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <48F90794.6010806@redhat.com>

Jesse Keating wrote:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?

We should Do The Right Thing By Default.  Thus, there needs to be a standalone 
torrent that has just the DVD ISO (and maybe the netinst ISO) for all those 
newcomers who don't know any better, so we don't scare them off with a 9 GB torrent.

In theory, we could have a "menu" torrent to let you download the x86_64 DVD, 
the PPC CDs, and the i686 Live image all in the same place, but this would give 
us a sparse and somewhat disjoint set of peers in a torrent that's much smaller 
than the main single-purpose torrents, defeating the purpose of using bittorrent.

Another problem is prioritization.  Right now, if I'm downloading three DVD ISOs 
and two liveCD images (not entirely unlikely) I can tell my torrent client that 
I really want the i686 liveCD first, and I will get it inside the hour, and I 
can play around for a bit while I'm waiting for the rest to complete.  If 
they're all in a single torrent, I'm stuck sitting on my thumbs for a day while 
it randomly pulls chunks that are mostly from other ISOs.

Since bittorrent doesn't have a concept of dependencies (no "metatorrents") 
there's no benefit to having multiple files in a torrent unless all of them are 
useless without the others.

-- Chris



From dr.diesel at gmail.com  Fri Oct 17 21:49:48 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 17 Oct 2008 17:49:48 -0400
Subject: Presto Rawhide?
Message-ID: <2a28d2ab0810171449r240f1f8ao3930ca9a84918f28@mail.gmail.com>

Can't seem to find a link for Rawhide's presto information!  Any available info?

Thanks
Andy

-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org



From smooge at gmail.com  Fri Oct 17 21:54:25 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Fri, 17 Oct 2008 15:54:25 -0600
Subject: The Big ACL Opening
In-Reply-To: <20081017210147.GA24430@shell.devel.redhat.com>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
Message-ID: <80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>

On Fri, Oct 17, 2008 at 3:01 PM, Alan Cox <alan at redhat.com> wrote:
>> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
>> and superpackager.
>
> Super is probably sane enough but English has a long and distinguished
> history of stealing other peoples words and using them wrongly so uber- in
> English [ab]use is not atypical ;)
>

or adding them together... super-ultra-ginormous packager.

super was used a lot so it was no longer super. I think that is when
Ultra was the new super.. Uber was the 80's new Super since it 'should
have' umlauts like any 'proper' Germanic word. I mean how else can you
have a rock band name without umlauts.  I think gi-normous  is the
current generations super...


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From konrad at tylerc.org  Fri Oct 17 21:56:16 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 17 Oct 2008 14:56:16 -0700
Subject: Presto Rawhide?
In-Reply-To: <2a28d2ab0810171449r240f1f8ao3930ca9a84918f28@mail.gmail.com>
References: <2a28d2ab0810171449r240f1f8ao3930ca9a84918f28@mail.gmail.com>
Message-ID: <200810171456.16256.konrad@tylerc.org>

On Friday 17 October 2008 02:49:48 pm Dr. Diesel wrote:
> Can't seem to find a link for Rawhide's presto information!  Any available
> info?
>
> Thanks
> Andy

https://admin.fedoraproject.org/pkgdb/packages/name/presto#Fedoradevel

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From jkeating at redhat.com  Fri Oct 17 21:58:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 14:58:33 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F90794.6010806@redhat.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F90794.6010806@redhat.com>
Message-ID: <1224280713.4142.42.camel@luminos.localdomain>

On Fri, 2008-10-17 at 17:45 -0400, Chris Snook wrote:
> Since bittorrent doesn't have a concept of dependencies (no "metatorrents") 
> there's no benefit to having multiple files in a torrent unless all of them are 
> useless without the others.

Does that mean we should do one torrent per CD iso too?  'cause you can
do an install with just the first, you don't need the rest...

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/f6c3c6e3/attachment.sig>

From dr.diesel at gmail.com  Fri Oct 17 22:04:46 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 17 Oct 2008 18:04:46 -0400
Subject: Presto Rawhide?
In-Reply-To: <200810171456.16256.konrad@tylerc.org>
References: <2a28d2ab0810171449r240f1f8ao3930ca9a84918f28@mail.gmail.com>
	<200810171456.16256.konrad@tylerc.org>
Message-ID: <2a28d2ab0810171504t1945d2c9o124b0b04d864e857@mail.gmail.com>

On Fri, Oct 17, 2008 at 5:56 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> On Friday 17 October 2008 02:49:48 pm Dr. Diesel wrote:
>> Can't seem to find a link for Rawhide's presto information!  Any available
>> info?
>>
>> Thanks
>> Andy
>
> https://admin.fedoraproject.org/pkgdb/packages/name/presto#Fedoradevel
>
> Regards,
> --
> Conrad Meyer <konrad at tylerc.org>

Thanks, but I'm searching for the yum repo links, with the presto metadata.

Andy

-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org



From sundaram at fedoraproject.org  Fri Oct 17 22:06:50 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 18 Oct 2008 03:36:50 +0530
Subject: Presto Rawhide?
In-Reply-To: <2a28d2ab0810171449r240f1f8ao3930ca9a84918f28@mail.gmail.com>
References: <2a28d2ab0810171449r240f1f8ao3930ca9a84918f28@mail.gmail.com>
Message-ID: <48F90C7A.50901@fedoraproject.org>

Dr. Diesel wrote:
> Can't seem to find a link for Rawhide's presto information!  Any available info?
> 
> Thanks
> Andy
> 

https://fedorahosted.org/presto

Rahul



From kevin.kofler at chello.at  Fri Oct 17 22:22:25 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 17 Oct 2008 22:22:25 +0000 (UTC)
Subject: Presto Rawhide?
References: <2a28d2ab0810171449r240f1f8ao3930ca9a84918f28@mail.gmail.com>
	<200810171456.16256.konrad@tylerc.org>
Message-ID: <loom.20081017T222153-86@post.gmane.org>

Conrad Meyer <konrad <at> tylerc.org> writes:
> https://admin.fedoraproject.org/pkgdb/packages/name/presto#Fedoradevel

Wrong Presto... ;-)

        Kevin Kofler



From csnook at redhat.com  Fri Oct 17 22:25:13 2008
From: csnook at redhat.com (Chris Snook)
Date: Fri, 17 Oct 2008 18:25:13 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224280713.4142.42.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>	<48F90794.6010806@redhat.com>
	<1224280713.4142.42.camel@luminos.localdomain>
Message-ID: <48F910C9.8060302@redhat.com>

Jesse Keating wrote:
> On Fri, 2008-10-17 at 17:45 -0400, Chris Snook wrote:
>> Since bittorrent doesn't have a concept of dependencies (no "metatorrents") 
>> there's no benefit to having multiple files in a torrent unless all of them are 
>> useless without the others.
> 
> Does that mean we should do one torrent per CD iso too?  'cause you can
> do an install with just the first, you don't need the rest...

No.  That would not be Doing The Right Thing By Default.  CDs 2-N are not very 
useful without CD 1, so they really should all be in one torrent.  The power 
users who can get by with just CD 1 should be able to handle unchecking ISOs 2-N 
in their bittorrent client.  If we have a separate torrent for just CD 1, it'll 
be devoid of seeds, since the vast majority of people will use the torrent for 
the whole set, so there's not much point having a separate one for just CD 1 either.

-- Chris



From opensource at till.name  Fri Oct 17 22:26:39 2008
From: opensource at till.name (Till Maas)
Date: Sat, 18 Oct 2008 00:26:39 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224280713.4142.42.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F90794.6010806@redhat.com>
	<1224280713.4142.42.camel@luminos.localdomain>
Message-ID: <200810180026.46029.opensource@till.name>

On Fri October 17 2008, Jesse Keating wrote:
> On Fri, 2008-10-17 at 17:45 -0400, Chris Snook wrote:
> > Since bittorrent doesn't have a concept of dependencies (no
> > "metatorrents") there's no benefit to having multiple files in a torrent
> > unless all of them are useless without the others.
>
> Does that mean we should do one torrent per CD iso too?  'cause you can
> do an install with just the first, you don't need the rest...


I guess in this case, one would be better suited with a live 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/20081018/49a307e4/attachment.sig>

From jspaleta at gmail.com  Fri Oct 17 22:29:12 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Oct 2008 14:29:12 -0800
Subject: The Big ACL Opening
In-Reply-To: <80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
Message-ID: <604aa7910810171529g6cfcac4epc410140199822f21@mail.gmail.com>

On Fri, Oct 17, 2008 at 1:54 PM, Stephen John Smoogen
> or adding them together... super-ultra-ginormous packager.

supercalifragilisticexpialidocious-packager.

-jef"Um diddle diddle diddle um diddle ay"spaleta



From cra at WPI.EDU  Fri Oct 17 22:31:26 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 17 Oct 2008 18:31:26 -0400
Subject: The Big ACL Opening
In-Reply-To: <80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
Message-ID: <20081017223126.GH27444@angus.ind.WPI.EDU>

On Fri, Oct 17, 2008 at 03:54:25PM -0600, Stephen John Smoogen wrote:
> On Fri, Oct 17, 2008 at 3:01 PM, Alan Cox <alan at redhat.com> wrote:
> >> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
> >> and superpackager.
> >
> > Super is probably sane enough but English has a long and distinguished
> > history of stealing other peoples words and using them wrongly so uber- in
> > English [ab]use is not atypical ;)
> >
> 
> or adding them together... super-ultra-ginormous packager.
> 
> super was used a lot so it was no longer super. I think that is when
> Ultra was the new super.. Uber was the 80's new Super since it 'should
> have' umlauts like any 'proper' Germanic word. I mean how else can you
> have a rock band name without umlauts.  I think gi-normous  is the
> current generations super...

How about a more neutral term?

experiencedpackager
trustedpackager

Here's some that imply scope rather than "l33tness"? (no, lets not use 
l33tpackager as fun as it sounds).  Since those packagers can touch 
(almost) all packages how about:

globalpackager
universepackager
everypackager



From jkeating at redhat.com  Fri Oct 17 22:42:23 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 15:42:23 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <200810180026.46029.opensource@till.name>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F90794.6010806@redhat.com>
	<1224280713.4142.42.camel@luminos.localdomain>
	<200810180026.46029.opensource@till.name>
Message-ID: <1224283343.4142.44.camel@luminos.localdomain>

On Sat, 2008-10-18 at 00:26 +0200, Till Maas wrote:
> I guess in this case, one would be better suited with a live cd.

Actually, to install the same set of software that is on the LiveCD
using traditional CDs, you'd likely need the first 3.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/33bc38e1/attachment.sig>

From mzerqung at 0pointer.de  Fri Oct 17 22:53:59 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sat, 18 Oct 2008 00:53:59 +0200
Subject: The Big ACL Opening
In-Reply-To: <11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
Message-ID: <20081017225358.GA29935@tango.0pointer.de>

On Fri, 17.10.08 12:46, Jon Ciesla (limb at jcomserv.net) wrote:

> An interesting irony here is that while Nietzsche's Ubermensch is best
> translated as Overman, for English, it's commonly mistranslated as
> Superman, and so Superpackager "sounds" more like what Lennart was getting
> at than does Uberpackager.  To me, anyway.

Uh, no. The problem I see is specifically with the german language
prefix "?ber-" used (as prefix to a word of any other language) as
some kind of superlative when used in reference to Nietzsche's
"?bermensch" -- because that term at least Germany has been
appropriated by the Nazis.

I fully understand that not everyone is aware of this connection,
especially outside of Germany. But uh, in Germany it is very obvious.

Also note that the "?ber" in the first stanza of the "Deutschlandlied"
played a role in the decision to make only the third stanza the German
anthem. (i.e. "Deutschland, Deutschland, ?ber alles.")

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From opensource at till.name  Fri Oct 17 23:04:11 2008
From: opensource at till.name (Till Maas)
Date: Sat, 18 Oct 2008 01:04:11 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <200810180104.18321.opensource@till.name>

On Fri October 17 2008, Jesse Keating wrote:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?

I have a probably crazy idea: How about composing the DVD iso using a 
filesystem that contains the CD isos and a bootloader that can use the CD 
isos as installation source? Then a little bit of space of the DVD iso would 
be wasted and it would take a little more effort to burn only the CD isos, 
but then only one torrent would be needed and everyone can easily share 
bandwidth with everyone else.

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/20081018/d8f627e2/attachment.sig>

From kevin.kofler at chello.at  Fri Oct 17 23:22:11 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 17 Oct 2008 23:22:11 +0000 (UTC)
Subject: default XFCE layout
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
	<20081011152620.5c57cb26@ohm.scrye.com>
	<385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>
	<1224119807.13994.48.camel@wicktop.localdomain>
Message-ID: <loom.20081017T231909-171@post.gmane.org>

Christoph Wickert <christoph.wickert <at> googlemail.com> writes:
> Nirik has only one account. There is no kaven and kevin is Kevin Kofler.

No. My FAS username is kkofler. kevin is Kevin Fenzi's FAS username, his IRC 
nick is nirik. There's no FAS account named nirik.

https://admin.fedoraproject.org/accounts/user/view/kkofler
https://admin.fedoraproject.org/accounts/user/view/kevin

https://admin.fedoraproject.org/accounts/user/view/nirik
-> username: 'nirik' does not exist.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 17 23:28:39 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 17 Oct 2008 23:28:39 +0000 (UTC)
Subject: default XFCE layout
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
Message-ID: <loom.20081017T232811-43@post.gmane.org>

Muayyad AlSadi <alsadi <at> gmail.com> writes:
> http://img353.imageshack.us/my.php?image=xfce4layoutck3.png

That looks a lot like the KDE 3 default. :-)

        Kevin Kofler



From kevin.kofler at chello.at  Fri Oct 17 23:26:58 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 17 Oct 2008 23:26:58 +0000 (UTC)
Subject: default XFCE layout
References: <385866f0810111217i2b81bcfas45bdd2fcf5f4ff3e@mail.gmail.com>
	<20081011152620.5c57cb26@ohm.scrye.com>
	<385866f0810111559y2cb55432xec7884156ba9fef@mail.gmail.com>
	<1224119807.13994.48.camel@wicktop.localdomain>
	<48F69870.8070607@fedoraproject.org>
	<1224123519.13994.90.camel@wicktop.localdomain>
	<48F6B628.3010603@fedoraproject.org>
	<385866f0810160504y53b89fe3s62dc5a024cfe5f86@mail.gmail.com>
Message-ID: <loom.20081017T232431-952@post.gmane.org>

Muayyad AlSadi <alsadi <at> gmail.com> writes:
> > Nirik has only one account. There is no kaven and kevin is Kevin Kofler.
> I was mislead by zodbot
> 
> alsadi: .whoowns xfce4-panel
> zodbot: alsadi: kevin

No, you weren't. zodbot gave you the right answer, the kevin who maintains 
xfce4-panel is Kevin Fenzi, known as nirik on IRC, not me. What you missed is 
that he uses nirik on IRC and kevin in FAS.

I'm the KDE Kevin, not the XFCE Kevin. ;-)

        Kevin Kofler



From bnocera at redhat.com  Fri Oct 17 23:34:06 2008
From: bnocera at redhat.com (Bastien Nocera)
Date: Sat, 18 Oct 2008 00:34:06 +0100
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224273986.21581.97.camel@rosebud>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<20081017195230.GA13662@nostromo.devel.redhat.com>
	<1224273870.4142.27.camel@luminos.localdomain>
	<1224273986.21581.97.camel@rosebud>
Message-ID: <1224286446.5268.6696.camel@cookie.hadess.net>

On Fri, 2008-10-17 at 16:06 -0400, seth vidal wrote:
> On Fri, 2008-10-17 at 13:04 -0700, Jesse Keating wrote:
> > On Fri, 2008-10-17 at 15:52 -0400, Bill Nottingham wrote:
> > > By 'most', do you know specifically which ones do not?
> > 
> > Hrm, actually I don't.  The 'most' is anecdotal as well.  Every client
> > I've used supports it, however I wouldn't feel comfortable saying every
> > client supports it.
> > 
> > I've used transmission, Azureus, deluge, and a couple others I can't
> > remember any more.
> > 
> 
> how about the default bittorrent-curses client?

transmission has a daemon mode as well, on top of which you can run the
usual UI.



From jkeating at redhat.com  Fri Oct 17 23:39:20 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Oct 2008 16:39:20 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <200810180104.18321.opensource@till.name>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<200810180104.18321.opensource@till.name>
Message-ID: <1224286760.4142.46.camel@luminos.localdomain>

On Sat, 2008-10-18 at 01:04 +0200, Till Maas wrote:
> I have a probably crazy idea: How about composing the DVD iso using a 
> filesystem that contains the CD isos and a bootloader that can use the CD 
> isos as installation source? Then a little bit of space of the DVD iso would 
> be wasted and it would take a little more effort to burn only the CD isos, 
> but then only one torrent would be needed and everyone can easily share 
> bandwidth with everyone else.

Split media installs (which that would result in for even the DVD case)
has some interesting side-effects, that really hurt when trying to add
external repos (particularly of updates) at install time.  I wouldn't
want to force it upon everybody.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/3a00fbfb/attachment.sig>

From mw_triad at users.sourceforge.net  Sat Oct 18 00:06:49 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 17 Oct 2008 19:06:49 -0500
Subject: Sendmail still default?
In-Reply-To: <faa16b610810171358h5221993wcf05923c55d6163b@mail.gmail.com>
References: <48F87794.3090108@redhat.com>
	<faa16b610810171358h5221993wcf05923c55d6163b@mail.gmail.com>
Message-ID: <gdb9ap$jc9$1@ger.gmane.org>

Colin Walters wrote:
> A note - the desktop spin would like to have no MTA by default for
> F11.  We'll likely change the way cron is handled so that if you have
> per-user cron jobs an MTA is installed.

What happens to root's cron jobs (e.g. logwatch)? Do they just go to 
/dev/null, or do you have some cool new log monitor?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
When on POSIX, do as POSIX mandates.



From andrewparker at bigfoot.com  Sat Oct 18 00:09:42 2008
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Fri, 17 Oct 2008 20:09:42 -0400
Subject: The Big ACL Opening
In-Reply-To: <20081017225358.GA29935@tango.0pointer.de>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
Message-ID: <6c3f5e6c0810171709w5b9bfd5dhe64e87e9fbb21cf7@mail.gmail.com>

On Fri, Oct 17, 2008 at 6:53 PM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> On Fri, 17.10.08 12:46, Jon Ciesla (limb at jcomserv.net) wrote:
>
>> An interesting irony here is that while Nietzsche's Ubermensch is best
>> translated as Overman, for English, it's commonly mistranslated as
>> Superman, and so Superpackager "sounds" more like what Lennart was getting
>> at than does Uberpackager.  To me, anyway.
>
> Uh, no. The problem I see is specifically with the german language
> prefix "?ber-" used (as prefix to a word of any other language) as
> some kind of superlative when used in reference to Nietzsche's
> "?bermensch" -- because that term at least Germany has been
> appropriated by the Nazis.
>
> I fully understand that not everyone is aware of this connection,
> especially outside of Germany. But uh, in Germany it is very obvious.
>
> Also note that the "?ber" in the first stanza of the "Deutschlandlied"
> played a role in the decision to make only the third stanza the German
> anthem. (i.e. "Deutschland, Deutschland, ?ber alles.")
>

I don't understand why this is an issue.  Uber has no negative
connotations in English, does it? Do we have to have all our words
vetted against every language before we can use them?

Please refrain from using the word "cut" because it is Vietnamese for "shit".

As a Brit living in the USA, I don't try to stop Americans from using
the word "fanny" just because it is offensive to me, although I have
learnt not to ask for a rubber so that I can rub something out :)



From mw_triad at users.sourceforge.net  Sat Oct 18 00:07:15 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 17 Oct 2008 19:07:15 -0500
Subject: Sendmail still default?
In-Reply-To: <48F87794.3090108@redhat.com>
References: <48F87794.3090108@redhat.com>
Message-ID: <gdb9bj$jc9$2@ger.gmane.org>

Lutz Lange wrote:
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?

Some people (/me waves) were concerned about the element of surprise 
when someone configures a new system, throws some (user) cron jobs on 
it, and expects local mail delivery to Just Work.

I also suggested that setting up what happens to cron's mail in 
anaconda/firstboot would be an adequate solution. However it was too 
late to do this for F10.

What I'd be interested in for F11 is a screen during install that 
requires you to either provide a valid e-mail address recipient for 
root's mail and the default user's mail (with, I suppose, any other mail 
going to whatever is set up for root), or else explicitly requesting a 
local-mail capable MTA.

Um... which is actually another reason for local mail being default; in 
the event a user's mail recipient is not configured, it goes to a local 
spool only readable by root and that user. If Sue sets up a computer and 
adds an account for Bob, it's not really ideal if Bob's mail gets sent 
to sue at mydomain.com because Bob doesn't have a recipient specified. 
True, Sue probably has root access and could read Bob's mail if she 
wanted, but you've gone the extra step to tossing Bob's mail in Sue's 
inbox without warning.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
When on POSIX, do as POSIX mandates.



From walters at verbum.org  Sat Oct 18 00:12:20 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 17 Oct 2008 20:12:20 -0400
Subject: Sendmail still default?
In-Reply-To: <gdb9ap$jc9$1@ger.gmane.org>
References: <48F87794.3090108@redhat.com>
	<faa16b610810171358h5221993wcf05923c55d6163b@mail.gmail.com>
	<gdb9ap$jc9$1@ger.gmane.org>
Message-ID: <faa16b610810171712k96f1d9bqc77e230f0124bdf5@mail.gmail.com>

On Fri, Oct 17, 2008 at 8:06 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Colin Walters wrote:
>>
>> A note - the desktop spin would like to have no MTA by default for
>> F11.  We'll likely change the way cron is handled so that if you have
>> per-user cron jobs an MTA is installed.
>
> What happens to root's cron jobs (e.g. logwatch)? Do they just go to
> /dev/null, or do you have some cool new log monitor?

/dev/null by default.  In the longer term what I would like to see is
*some* of this kind of thing integrated with:
http://fedoraproject.org/wiki/Features/CrashHandling
But most logs from a desktop machine are just pure noise.



From mw_triad at users.sourceforge.net  Sat Oct 18 00:12:44 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 17 Oct 2008 19:12:44 -0500
Subject: private group administration
In-Reply-To: <48F8C5C6.3050004@gmail.com>
References: <48F87E69.7040409@redhat.com> <48F8C5C6.3050004@gmail.com>
Message-ID: <gdb9ls$kop$1@ger.gmane.org>

Les Mikesell wrote:
> Lutz Lange wrote:
>>
>> i was thinking about user creation and group administration. Every user
>> gets his own private group when he is created. And the motivation for
>> that is to avoid users sharing files with all other users to per default
>> right?
> 
> Not exactly.  Having your own private group assigned from the start 
> makes it possible to use a default umask that gives group access to your 
> files without actually giving anyone else access yet.  That means 
> when/if you do want to let someone else have access, you don't have to 
> go back and change the permissions on all your existing files and 
> directories.

...which means as soon as you save something to a setgid directory, you 
just gave the world (or at least, some larger group) write permission to 
your files. Personally I always considered umask 002 to be Evil. Better 
to make it hard to intentionally grant others write for your files than 
to make it easy to accidentally give write permission that you didn't 
want to give.

If 'chmod g+w file;chgrp foo file' is too much work then there should be 
a command that can do both.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
When on POSIX, do as POSIX mandates.



From mw_triad at users.sourceforge.net  Sat Oct 18 00:17:52 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 17 Oct 2008 19:17:52 -0500
Subject: Sendmail still default?
In-Reply-To: <faa16b610810171712k96f1d9bqc77e230f0124bdf5@mail.gmail.com>
References: <48F87794.3090108@redhat.com>	<faa16b610810171358h5221993wcf05923c55d6163b@mail.gmail.com>	<gdb9ap$jc9$1@ger.gmane.org>
	<faa16b610810171712k96f1d9bqc77e230f0124bdf5@mail.gmail.com>
Message-ID: <gdb9vg$kop$2@ger.gmane.org>

Colin Walters wrote:
> On Fri, Oct 17, 2008 at 8:06 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> Colin Walters wrote:
>>> A note - the desktop spin would like to have no MTA by default for
>>> F11.  We'll likely change the way cron is handled so that if you have
>>> per-user cron jobs an MTA is installed.
>> What happens to root's cron jobs (e.g. logwatch)? Do they just go to
>> /dev/null, or do you have some cool new log monitor?
> 
> /dev/null by default.  In the longer term what I would like to see is
> *some* of this kind of thing integrated with:
> http://fedoraproject.org/wiki/Features/CrashHandling
> But most logs from a desktop machine are just pure noise.

Yes and no. I'd prefer to see some sort of event viewer that would do 
logwatch, but with much more terse, consolidated output (and by default 
throw out all but the last N days' entries).

Even on desktops, I'd like to watch who's logging in, but it's such a 
pain to do right now...

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
When on POSIX, do as POSIX mandates.



From walters at verbum.org  Sat Oct 18 00:21:07 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 17 Oct 2008 20:21:07 -0400
Subject: private group administration
In-Reply-To: <gdb9ls$kop$1@ger.gmane.org>
References: <48F87E69.7040409@redhat.com> <48F8C5C6.3050004@gmail.com>
	<gdb9ls$kop$1@ger.gmane.org>
Message-ID: <faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>

On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
>
> If 'chmod g+w file;chgrp foo file' is too much work then there should be a
> command that can do both.

Groups are broken.  Use access control lists: "man setfacl"



From sundaram at fedoraproject.org  Sat Oct 18 00:26:02 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 18 Oct 2008 05:56:02 +0530
Subject: Sendmail still default?
In-Reply-To: <gdb9vg$kop$2@ger.gmane.org>
References: <48F87794.3090108@redhat.com>	<faa16b610810171358h5221993wcf05923c55d6163b@mail.gmail.com>	<gdb9ap$jc9$1@ger.gmane.org>	<faa16b610810171712k96f1d9bqc77e230f0124bdf5@mail.gmail.com>
	<gdb9vg$kop$2@ger.gmane.org>
Message-ID: <48F92D1A.7020909@fedoraproject.org>

Matthew Woehlke wrote:
> 
> Yes and no. I'd prefer to see some sort of event viewer that would do 
> logwatch, but with much more terse, consolidated output (and by default 
> throw out all but the last N days' entries).
> 
> Even on desktops, I'd like to watch who's logging in, but it's such a 
> pain to do right now...

gnome-system-log (gnome-utils) might help. KDE has a log viewer as well. 
Might consider working on it to do what you want it to do otherwise.

Rahul



From chrisw at redhat.com  Sat Oct 18 00:27:29 2008
From: chrisw at redhat.com (Chris Wright)
Date: Fri, 17 Oct 2008 17:27:29 -0700
Subject: Fedora 10 Snapshot 2
In-Reply-To: <1224272190.4142.22.camel@luminos.localdomain>
References: <1224272190.4142.22.camel@luminos.localdomain>
Message-ID: <20081018002729.GC3671@acer.localdomain>

* Jesse Keating (jkeating at redhat.com) wrote:
> Based on feedback from Snapshot 1 we're also adding a few more seeders
> to help get the bits out.

Thanks for that, BTW.  Grabbing Snap2 was much...err...snappier ;-)

thanks,
-chris



From kwhiskerz at gmail.com  Sat Oct 18 01:10:05 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Fri, 17 Oct 2008 19:10:05 -0600
Subject: text-to-speech doesn't work
Message-ID: <gdbd1f$r8e$1@ger.gmane.org>

I am using Fedora release 9.92 (Rawhide). For some time now, likely late in Fedora 8, or during Fedora 9, text-to-speech ceased to work. This applies to both festival and espeak.

festival --tts file.txt
espeak -f file.txt --punct=""

Neither gives any audible output. The programs just run indefinitely and nothing happens.



From sahartsu at xs4all.nl  Sat Oct 18 01:31:25 2008
From: sahartsu at xs4all.nl (Stefan Hartsuiker)
Date: Sat, 18 Oct 2008 03:31:25 +0200 (CEST)
Subject: Collapsing DVD and CD torrents into one
Message-ID: <7155.82.95.253.31.1224293485.squirrel@webmail.xs4all.nl>

Op Za, 18 oktober, 2008 01:39, schreef Jesse Keating:
> On Sat, 2008-10-18 at 01:04 +0200, Till Maas wrote:
>> I have a probably crazy idea: How about composing the DVD iso using a
>> filesystem that contains the CD isos and a bootloader that can use the CD
>> isos as installation source? Then a little bit of space of the DVD iso would
>> be wasted and it would take a little more effort to burn only the CD isos,
>> but then only one torrent would be needed and everyone can easily share
>> bandwidth with everyone else.
>
> Split media installs (which that would result in for even the DVD case)
> has some interesting side-effects, that really hurt when trying to add
> external repos (particularly of updates) at install time.  I wouldn't
> want to force it upon everybody.
>
Uhm, maybe it's me, but if the system can boot from the dvd, why do you want
to install from cd's?
As to making cd's available on the dvd, I see a use case there, but then
perhaps it might be wiser to use a jigdo file that uses the rpm's already on
the dvd.
It can then on-the-fly compose the cd iso that are wanted.

Regards,
Stefan Hartsuiker




From promac at gmail.com  Sat Oct 18 01:56:46 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Fri, 17 Oct 2008 22:56:46 -0300
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <26499.198.175.55.5.1224256924.squirrel@mail.jcomserv.net>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
	<68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
	<27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>
	<26499.198.175.55.5.1224256924.squirrel@mail.jcomserv.net>
Message-ID: <68720af30810171856ucad1d58ufc5ca16b28d81378@mail.gmail.com>

On Fri, Oct 17, 2008 at 12:22 PM, Jon Ciesla <limb at jcomserv.net> wrote:

>
> >
> >> On Mon, Oct 13, 2008 at 2:48 PM, KH KH <kwizart at gmail.com> wrote:
> >>
> >>> 2008/10/13 Jon Ciesla <limb at jcomserv.net>:
> >>> >
> >>> >> Hi!
> >>> >>
> >>> >> As announced at http://www.yafray.org, yafaray replaces YafRay
> >>> 0.0.9.
> >>> >> Thus I'm thinking of submitting yafray as dead.package in Rawhide.
> >>> (1)
> >>> >>
> >>> >> On the other side, I'm not going to work on yafaray soon. So, if
> >>> anyone
> >>> >> wants to start working on it, feel free.
> >>> >>
> >>> >> Nicolas (kwizart)
> >>> >>
> >>> >>
> >>> >> (1), There is no reason why yafray should stop working with the
> >>> current
> >>> >> blender releases. But there might be a problem when theses two are
> >>> >> installed together. (until now, blender either dlopen library or
> >>> call
> >>> >> binary, from yafray).
> >>> >> This has to be discussed in the yafaray review. So, please cc'ed me
> >>> on
> >>> >> the review, along with your favorite reviewer. (or ask me as a
> >>> reviewer).
> >>> >
> >>> > I may just do that.  One thing though, am I blind or is there nor
> >>> yafaray
> >>> > tarball, and I'll have to work from a svn checkout?  (bleah)
> >>> Yes, that's right.
> >>> I think it will be appropriate to use a script to create one source
> >>> tarball.
> >>> Good luck !
> >>>
> >>>
> >> I can give you an .src.rpm that builds fine for F8, including the QT
> >> interface.
> >>
> >> http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc8.src.rpm<http://people.atrpms.net/%7Epcavalcanti/srpms/yafaray-0.1.0-3.fc8.src.rpm>
> >
> > Thanks, I'll have a look, and see if I can rip-of^H^H^H^H^H^Hborrow from
> > this to solve some of the issues I've run into so far.
>
> Hmm, on F-9:
>
> scons: done building targets.
> + sed -i -es,/var/tmp/yafaray-0.1.0-buildroot,,g
> /var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafaraycore.so
> + /usr/lib/rpm/find-debuginfo.sh /home/limb/rpmbuild/BUILD/yafaray
> extracting debug info from
> /var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafarayqt.so
> extracting debug info from
> /var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafaraycore.so
> Failed to write file: invalid section alignment
> error: Bad exit status from /var/tmp/rpm-tmp.80705 (%install)
>
>
>
The problem is that  check-buildroot is
accusing  "%{buildroot}"  in libyafaraycore.so

I just erased the reference to %{buildroot} from the library to
be able to get an rpm. F9 seems to have a more strict check.

This was the only problem I got, and it needs a better solution.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081017/71a3636f/attachment.htm>

From lesmikesell at gmail.com  Sat Oct 18 02:17:35 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 17 Oct 2008 21:17:35 -0500
Subject: private group administration
In-Reply-To: <faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
References: <48F87E69.7040409@redhat.com>
	<48F8C5C6.3050004@gmail.com>	<gdb9ls$kop$1@ger.gmane.org>
	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
Message-ID: <48F9473F.9070205@gmail.com>

Colin Walters wrote:
> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> If 'chmod g+w file;chgrp foo file' is too much work then there should be a
>> command that can do both.
> 
> Groups are broken.  Use access control lists: "man setfacl"

Groups have never been broken.  Access control lists let you set up a 
mishmash of exceptions that nobody can understand or recreate and not 
all tools understand them when making copies or backups or working 
across different platforms.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From braden at endoframe.com  Sat Oct 18 04:16:02 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 18 Oct 2008 00:16:02 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <48F8912E.8000104@gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48F5C75A.9040603@redhat.com>
	<91705d080810150634g516508bby93f316288651b71@mail.gmail.com>
	<1224226718.20619.42.camel@hinge.endoframe.net>
	<48F8912E.8000104@gmail.com>
Message-ID: <1224303362.20619.49.camel@hinge.endoframe.net>

On Fri, 2008-10-17 at 06:20 -0700, Toshio Kuratomi wrote:
> Braden McDaniel wrote:
> > On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
> > 
> >> blackbox: needs AC_PROG_CXX
> > 
> > I see no reason at all for this to be running autoreconf. (A comment
> > claims it gets rid of an rpath; I'd be a little surprised if this were
> > still true.)
> > 
> *scratches head* If this is using an old, unpatched version of libtool,
> wouldn't it add the rpath until a new version of libtool is inserted
> into the package?  So it will be true until upstream is updated to use a
> new version of libtool?
> 
> >> bmpx: needs AC_PROG_CXX
> > 
> > Actually, the problem is that it patches both configure.ac and
> > configure.  Presumably the timestamps don't line up right as a result
> > and "make" triggers regenerating stuff.  Either the patch to
> > configure.ac should be culled or the timestamps need massaging.
> > (There's also a patch to soup.m4 that just looks goofy.)
> > 
> Please stop giving bad advice (I think you're doing it in the interests
> of brevity but still.) Telling people to have two patches, one for
> configure.ac and one for configure and making sure the configure.ac
> patch is applied before the configure patch is good advice, continue
> doing that!  But using phrases like "or do it right and patch configure"
> and "the patch to configure.ac should be culled" is bad advice; it
> leaves people who read this thread and do not understand autotools with
> the idea that a patch to configure *alone* is the best way to make
> changes.  This is not true as we still want to have something to send to
> upstream and a patch to configure, Makefile.in, or any other generated
> files is not what upstream wants to see.

"Only patch configure" is not bad advice.  *Including* a patch to
configure.ac--in the source RPM and/or in revision control--is
sufficient to satisfy any requirement for an upstream-worthy patch.
*Applying* a patch to configure.ac when you're also applying a patch to
configure can only do harm.  It defeats the purpose of patching
configure.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From braden at endoframe.com  Sat Oct 18 04:30:13 2008
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 18 Oct 2008 00:30:13 -0400
Subject: Status of libtool 2.2.X?
In-Reply-To: <1224226718.20619.42.camel@hinge.endoframe.net>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48F5C75A.9040603@redhat.com>
	<91705d080810150634g516508bby93f316288651b71@mail.gmail.com>
	<1224226718.20619.42.camel@hinge.endoframe.net>
Message-ID: <1224304213.20619.61.camel@hinge.endoframe.net>

On Fri, 2008-10-17 at 02:58 -0400, Braden McDaniel wrote:
> On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:

[snip]

> > blackbox: needs AC_PROG_CXX
> 
> I see no reason at all for this to be running autoreconf. (A comment
> claims it gets rid of an rpath; I'd be a little surprised if this were
> still true.)

Well, I'm surprised.  More than a little, even.

A look at Fedora's libtool package shows that a patch to address this
issue is still being applied.  Having heard of this issue for some time,
I'd assumed it had been addressed upstream by now. :-/

While one way to address this is to patch ltmain.sh (with one that looks
a whole lot like the aforementioned patch that is applied to libtool),
an easier and less invasive way to address this is to use the installed
libtool script:

        make LIBTOOL=/usr/bin/libtool

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From stickster at gmail.com  Sat Oct 18 04:51:16 2008
From: stickster at gmail.com (Paul W. Frields)
Date: Sat, 18 Oct 2008 00:51:16 -0400
Subject: The Big ACL Opening
In-Reply-To: <20081017223126.GH27444@angus.ind.WPI.EDU>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
	<20081017223126.GH27444@angus.ind.WPI.EDU>
Message-ID: <1224305476.28644.15.camel@victoria-eth.internal.frields.org>

On Fri, 2008-10-17 at 18:31 -0400, Chuck Anderson wrote:
> On Fri, Oct 17, 2008 at 03:54:25PM -0600, Stephen John Smoogen wrote:
> > On Fri, Oct 17, 2008 at 3:01 PM, Alan Cox <alan at redhat.com> wrote:
> > >> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
> > >> and superpackager.
> > >
> > > Super is probably sane enough but English has a long and distinguished
> > > history of stealing other peoples words and using them wrongly so uber- in
> > > English [ab]use is not atypical ;)
> > >
> > 
> > or adding them together... super-ultra-ginormous packager.
> > 
> > super was used a lot so it was no longer super. I think that is when
> > Ultra was the new super.. Uber was the 80's new Super since it 'should
> > have' umlauts like any 'proper' Germanic word. I mean how else can you
> > have a rock band name without umlauts.  I think gi-normous  is the
> > current generations super...
> 
> How about a more neutral term?
> 
> experiencedpackager
> trustedpackager
> 
> Here's some that imply scope rather than "l33tness"? (no, lets not use 
> l33tpackager as fun as it sounds).  Since those packagers can touch 
> (almost) all packages how about:
> 
> globalpackager
> universepackager
> everypackager

"Allpackager," kind of like "allspice."

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   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/20081018/f60491ac/attachment.sig>

From skvidal at fedoraproject.org  Sat Oct 18 05:07:08 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 18 Oct 2008 01:07:08 -0400
Subject: The Big ACL Opening
In-Reply-To: <1224305476.28644.15.camel@victoria-eth.internal.frields.org>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
	<20081017223126.GH27444@angus.ind.WPI.EDU>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
Message-ID: <1224306428.21581.108.camel@rosebud>

On Sat, 2008-10-18 at 00:51 -0400, Paul W. Frields wrote:
> On Fri, 2008-10-17 at 18:31 -0400, Chuck Anderson wrote:
> > On Fri, Oct 17, 2008 at 03:54:25PM -0600, Stephen John Smoogen wrote:
> > > On Fri, Oct 17, 2008 at 3:01 PM, Alan Cox <alan at redhat.com> wrote:
> > > >> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
> > > >> and superpackager.
> > > >
> > > > Super is probably sane enough but English has a long and distinguished
> > > > history of stealing other peoples words and using them wrongly so uber- in
> > > > English [ab]use is not atypical ;)
> > > >
> > > 
> > > or adding them together... super-ultra-ginormous packager.
> > > 
> > > super was used a lot so it was no longer super. I think that is when
> > > Ultra was the new super.. Uber was the 80's new Super since it 'should
> > > have' umlauts like any 'proper' Germanic word. I mean how else can you
> > > have a rock band name without umlauts.  I think gi-normous  is the
> > > current generations super...
> > 
> > How about a more neutral term?
> > 
> > experiencedpackager
> > trustedpackager
> > 
> > Here's some that imply scope rather than "l33tness"? (no, lets not use 
> > l33tpackager as fun as it sounds).  Since those packagers can touch 
> > (almost) all packages how about:
> > 
> > globalpackager
> > universepackager
> > everypackager
> 
> "Allpackager," kind of like "allspice."
> 

OdinPackager? 
WednesdayPackager?

-sv




From dev at nigelj.com  Sat Oct 18 05:47:07 2008
From: dev at nigelj.com (Nigel Jones)
Date: Sat, 18 Oct 2008 18:47:07 +1300
Subject: The Big ACL Opening
In-Reply-To: <1224305476.28644.15.camel@victoria-eth.internal.frields.org>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
	<20081017223126.GH27444@angus.ind.WPI.EDU>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
Message-ID: <1224308827.8880.21.camel@fantail.jnet.net.nz>

On Sat, 2008-10-18 at 00:51 -0400, Paul W. Frields wrote:
> On Fri, 2008-10-17 at 18:31 -0400, Chuck Anderson wrote:
> > On Fri, Oct 17, 2008 at 03:54:25PM -0600, Stephen John Smoogen wrote:
> > > On Fri, Oct 17, 2008 at 3:01 PM, Alan Cox <alan at redhat.com> wrote:
> > > >> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
> > > >> and superpackager.
> > > >
> > > > Super is probably sane enough but English has a long and distinguished
> > > > history of stealing other peoples words and using them wrongly so uber- in
> > > > English [ab]use is not atypical ;)
> > > >
> > > 
> > > or adding them together... super-ultra-ginormous packager.
> > > 
> > > super was used a lot so it was no longer super. I think that is when
> > > Ultra was the new super.. Uber was the 80's new Super since it 'should
> > > have' umlauts like any 'proper' Germanic word. I mean how else can you
> > > have a rock band name without umlauts.  I think gi-normous  is the
> > > current generations super...
> > 
> > How about a more neutral term?
> > 
> > experiencedpackager
> > trustedpackager
> > 
> > Here's some that imply scope rather than "l33tness"? (no, lets not use 
> > l33tpackager as fun as it sounds).  Since those packagers can touch 
> > (almost) all packages how about:
> > 
> > globalpackager
> > universepackager
> > everypackager
> 
> "Allpackager," kind of like "allspice."
masterpackager? (i.e. you've mastered packaging...)

- NJ
-- 
Nigel Jones <dev at nigelj.com>



From opensource at till.name  Sat Oct 18 06:45:07 2008
From: opensource at till.name (Till Maas)
Date: Sat, 18 Oct 2008 08:45:07 +0200
Subject: private group administration
In-Reply-To: <faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
References: <48F87E69.7040409@redhat.com> <gdb9ls$kop$1@ger.gmane.org>
	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
Message-ID: <200810180845.15175.opensource@till.name>

On Sat October 18 2008, Colin Walters wrote:
> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
>
> <mw_triad at users.sourceforge.net> wrote:
> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> > a command that can do both.
>
> Groups are broken.  Use access control lists: "man setfacl"

ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that 
everything within a certain directory is owned by everyone of a group, i.e. 
they all can do whatever they want with these files and directories without 
using sudo. The problem is, that the group permissions of a file constrain 
the permissions for all group acl permissions.

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/20081018/d0e5af8d/attachment.sig>

From opensource at till.name  Sat Oct 18 06:55:21 2008
From: opensource at till.name (Till Maas)
Date: Sat, 18 Oct 2008 08:55:21 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081017225358.GA29935@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
Message-ID: <200810180855.32076.opensource@till.name>

On Sat October 18 2008, Lennart Poettering wrote:

> I fully understand that not everyone is aware of this connection,
> especially outside of Germany. But uh, in Germany it is very obvious.

I live in Germany and am a native speaker, but for me this is not very 
obvious. I also doubt, that anyone I know would think about someone within 
Fedora beeing a nazi oder inhuman, because of the groupname uberpackager.

> Also note that the "?ber" in the first stanza of the "Deutschlandlied"
> played a role in the decision to make only the third stanza the German
> anthem. (i.e. "Deutschland, Deutschland, ?ber alles.")

Did it really? I would believe, that it is the meaning of this stanza that led 
to id not being the national anthem of Germany.

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/20081018/ca98739b/attachment.sig>

From opensource at till.name  Sat Oct 18 06:59:10 2008
From: opensource at till.name (Till Maas)
Date: Sat, 18 Oct 2008 08:59:10 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081017223126.GH27444@angus.ind.WPI.EDU>
References: <48F64212.2010505@redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
	<20081017223126.GH27444@angus.ind.WPI.EDU>
Message-ID: <200810180859.10969.opensource@till.name>

On Sat October 18 2008, Chuck Anderson wrote:

> Here's some that imply scope rather than "l33tness"? (no, lets not use

Here is one, that implies more 1337ness ;-):
packagepwner

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/20081018/d9458f2b/attachment.sig>

From opensource at till.name  Sat Oct 18 07:00:17 2008
From: opensource at till.name (Till Maas)
Date: Sat, 18 Oct 2008 09:00:17 +0200
Subject: The Big ACL Opening
In-Reply-To: <1224308827.8880.21.camel@fantail.jnet.net.nz>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
Message-ID: <200810180900.18085.opensource@till.name>

On Sat October 18 2008, Nigel Jones wrote:

> masterpackager? (i.e. you've mastered packaging...)

I like this, too, unless we can find a funny name that suits all.

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/20081018/746d8e06/attachment.sig>

From seg at haxxed.com  Sat Oct 18 07:32:32 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 18 Oct 2008 02:32:32 -0500
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F90794.6010806@redhat.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F90794.6010806@redhat.com>
Message-ID: <1224315152.26341.181.camel@localhost.localdomain>

On Fri, 2008-10-17 at 17:45 -0400, Chris Snook wrote:
> Another problem is prioritization.  Right now, if I'm downloading three DVD ISOs 
> and two liveCD images (not entirely unlikely) I can tell my torrent client that 
> I really want the i686 liveCD first, and I will get it inside the hour, and I 
> can play around for a bit while I'm waiting for the rest to complete.  If 
> they're all in a single torrent, I'm stuck sitting on my thumbs for a day while 
> it randomly pulls chunks that are mostly from other ISOs.

... Unless you use a client like Azureus that lets you prioritize
individual files. Hell, you could just tell it not to download any of
the other ISOs at all, until the first one is done.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/acabad83/attachment.sig>

From seg at haxxed.com  Sat Oct 18 07:50:51 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 18 Oct 2008 02:50:51 -0500
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224278235.21581.104.camel@rosebud>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>  <48F8FD28.5070805@fedoraproject.org>
	<1224278235.21581.104.camel@rosebud>
Message-ID: <1224316251.26341.197.camel@localhost.localdomain>

On Fri, 2008-10-17 at 21:17 +0000, seth vidal wrote:
> On Sat, 2008-10-18 at 02:31 +0530, Rahul Sundaram wrote:
> > John Reiser wrote:
> > >> Most torrent clients I've seen today allow you to pick and choose which
> > >> files you wish to download.
> > > 
> > > The original bittorrent client does *NOT* have this feature.
> > 
> > The "original" client went proprietary and is a dead end. Everybody 
> > should be using something more actively maintained.
> > 
> 
> in terms of clients - there are a lot of choices.
> in terms of trackers and good server-like-seeders there are NOT a lot of
> choices.
> 
> the original bittorrent client pre-proprietary is the best we have right
> now.

I'd suggest just biting the bullet, fire up a vncserver instance, and
run Azureus. It is incredibly flexible at managing many torrents at
once, it can run a tracker as well, and the GUI allows you a level of
insight into the status of a torrent that you just won't get from a text
client.

In "Advanced" mode it's downright overwhelming. But you need a power
user tool for a power user job... If you need someone to help tweak the
knobs, I may know someone... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/69c94683/attachment.sig>

From denis at poolshark.org  Sat Oct 18 07:55:31 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 18 Oct 2008 09:55:31 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <200810171252.41862.konrad@tylerc.org>
References: <1224272955.4142.25.camel@luminos.localdomain>	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
	<200810171252.41862.konrad@tylerc.org>
Message-ID: <48F99673.5070002@poolshark.org>

Conrad Meyer wrote:
> On Friday 17 October 2008 12:51:08 pm Jon Ciesla wrote:
>>> Most torrent clients I've seen today allow you to pick and choose which
>>> files you wish to download.  As such, does it make sense to collapse the
>>> DVD and CD torrents into a single torrent and allow people to use the
>>> client to pick which they want?  Are there pros/cons to this?
>> Does it work it bittorrent-curses?
> 
> I believe rtorrent can selectively enable or disable individual files in a 
> torrent, and it has a curses interface.

transmission has a cli mode as well as a daemon mode, both of which 
support marking specific files for download.




From nicolas.mailhot at laposte.net  Sat Oct 18 08:08:33 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 18 Oct 2008 10:08:33 +0200
Subject: The Big ACL Opening
In-Reply-To: <200810180855.32076.opensource@till.name>
References: <48F64212.2010505@redhat.com>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
	<200810180855.32076.opensource@till.name>
Message-ID: <1224317313.6806.4.camel@arekh.okg>

Le samedi 18 octobre 2008 ? 08:55 +0200, Till Maas a ?crit :
> On Sat October 18 2008, Lennart Poettering wrote:
> 
> > I fully understand that not everyone is aware of this connection,
> > especially outside of Germany. But uh, in Germany it is very obvious.
> 
> I live in Germany and am a native speaker, but for me this is not very 
> obvious. I also doubt, that anyone I know would think about someone within 
> Fedora beeing a nazi oder inhuman, because of the groupname uberpackager.

I don't live in Germany and I'm not a native speaker but I also never
was comfortable with ?ber for the aforementionned historical reasons. I
just didn't feel pointing the issue would be well received if not done
by a German himself.

-- 
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/20081018/42c631d8/attachment.sig>

From seg at haxxed.com  Sat Oct 18 08:09:05 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 18 Oct 2008 03:09:05 -0500
Subject: private group administration
In-Reply-To: <48F87E69.7040409@redhat.com>
References: <48F87E69.7040409@redhat.com>
Message-ID: <1218b5bc0810180109q35b5adcrf0c35f7b4e49fbe7@mail.gmail.com>

This is among the oldest of the old FAQs:

http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html



From snecklifter at gmail.com  Sat Oct 18 09:01:20 2008
From: snecklifter at gmail.com (Christopher Brown)
Date: Sat, 18 Oct 2008 10:01:20 +0100
Subject: The Big ACL Opening
In-Reply-To: <200810180900.18085.opensource@till.name>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
Message-ID: <364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>

2008/10/18 Till Maas <opensource at till.name>:
> On Sat October 18 2008, Nigel Jones wrote:
>
>> masterpackager? (i.e. you've mastered packaging...)
>
> I like this, too, unless we can find a funny name that suits all.

It would be nice to have something a bit more ... interesting. In
Japan, they wrap gifts in cloths called "furoshiki" so perhaps
furoshiki-packager?

-- 
Christopher Brown

http://www.chruz.com



From Axel.Thimm at ATrpms.net  Sat Oct 18 09:25:01 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 18 Oct 2008 12:25:01 +0300
Subject: opengl transitions in ooo (was: OpenOffice and go-oo)
In-Reply-To: <1223891707.10624.95.camel@vain.rhgalway>
References: <1223888234.4182.9.camel@ScaryMonster>
	<1223891707.10624.95.camel@vain.rhgalway>
Message-ID: <20081018092501.GA24572@victor.nirvana>

On Mon, Oct 13, 2008 at 10:55:07AM +0100, Caol?n McNamara wrote:
> On Mon, 2008-10-13 at 09:57 +0100, Aidan Delaney wrote:
> > the opengl slide transitions
> 
> They're still in a bit of a confused state, but I hope to see these in
> Fedora for F-11. I felt it was a bit much to take on for 3.0 with the
> simultaneous complexity of a three-layer OOo and more reliance on OOo
> extensions. 

I'd love to see them earlier, if possible. They had been used as
marketing material already in the 2.4.x timeline and people I have
been trying to convert to using Linux & OpenOffice are referring to
them and would like to see them.

I don't think they are really that useful just like compiz eye candy
isn't, but it makes a difference in some parts of the target audience
that currently marks this a vaporware on Fedora. E.g. from a marketing
POV we should be able to offer them.

Is there an easy way for a non ooo expert to help adding them for F10
already?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/87ee5ca6/attachment.sig>

From rawhide at fedoraproject.org  Sat Oct 18 10:09:59 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 18 Oct 2008 10:09:59 +0000 (UTC)
Subject: rawhide report: 20081018 changes
Message-ID: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>

Compose started at Sat Oct 18 06:01:17 UTC 2008

New package MegaMek
        A portable, network-enabled BattleTech engine
New package ipmitool
        Utility for IPMI control
New package system-switch-java
        A tool for changing the default Java toolset
Removed package packagekit-qt
Updated Packages:

OpenIPMI-2.0.14-3.fc10
----------------------
* Thu Oct 16 18:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-3
- split ipmitool to separate package
- add 'reload' functionality to init script
- add seraparate -gui subpackage


alacarte-0.11.6-4.fc10
----------------------
* Fri Oct 17 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.11.6-4
- Make undoing of deletion work


anaconda-11.4.1.50-1
--------------------
* Fri Oct 17 18:00:00 2008 Chris Lumens <clumens at redhat.com> - 11.4.1.50-1
- Update several font package names that we were missing. (clumens)
- Only bring up the netconfig dialog if the repo requires networking.
  (clumens)
- cmdline.py: Fix a small typo in a message (rh 467338) (hansg)
- Enable CCW devices used for installation (#253075) (dcantrell)
- I don't know what trq.map.trq-map is, but let's not include it. (clumens)
- If networking is needed for yum repos, bring it up before fetching
  repodata. (clumens)
- Force DPI to 96 when launching X. (#458738) (ajax)
- Lots of translation updates.


bluez-4.14-2.fc10
-----------------

cairo-dock-1.6.3-0.2.svn1357_trunk.fc10
---------------------------------------
* Sat Oct 18 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1357


eclipse-3.4.1-4.fc10
--------------------
* Fri Oct 17 18:00:00 2008 Andrew Overholt <overholt at redhat.com> 3.4.1-4
- Fix quoting bug in pdebuild.sh again.


eclipse-pydev-1.3.20-2.fc10
---------------------------
* Fri Oct 17 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 1:1.3.20-2
- Drop gcj support.
- Split mydev support to subpackage to correct dependencies.
- Drop eclipse-mylyn-ide BR - it is merged into eclipse-mylyn.


ecryptfs-utils-59-2.fc10
------------------------
* Fri Oct 17 18:00:00 2008 Eric Sandeen <sandeen at redhat.com> 59-2
- Remove duplicate doc files from rpm


filezilla-3.1.4.1-1.fc10
------------------------
* Fri Oct 17 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.4.1-1
- Update to 3.1.4.1


fmtools-1.0.2-4.fc10
--------------------
* Fri Oct 17 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.0.2-4
- Rebuild for F-10


geos-3.0.1-1.fc10
-----------------
* Fri Oct 17 18:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 3.0.1-1
- new stable bugfix
- fix another gcc43 header


ghostscript-8.63-4.fc10
-----------------------
* Fri Oct 17 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 8.63-4
- Try out a work-around for bug #465311.


gtk2-2.14.4-1.fc10
------------------
* Fri Oct 17 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.14.4-1
- Update to 2.14.4


hunspell-1.2.7-4.fc10
---------------------
* Fri Oct 17 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.2.7-4
- make wordlist2hunspell remove blank lines


ibus-table-0.1.1.20081014-1.fc10
--------------------------------
* Tue Oct 14 18:00:00 2008 Peng Huang <shawn.p.huang at gmail.com> - 0.1.1.20081014-1
- Update to 0.1.1.20081014.


imsettings-0.105.0-3.fc10
-------------------------
* Fri Oct 17 18:00:00 2008 Than Ngo <than at redhat.com> 0.105.0-3
- readd the workaround for KDE


inkscape-0.46-6.fc10
--------------------
* Fri Oct 17 18:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 0.46-6
- Fix color sliders with recent GTK (#467431)


ipsec-tools-0.7.1-5.fc10
------------------------
* Fri Oct 17 18:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 0.7.1-5
- fix CVE-2008-3652 (memory leak DoS)
- compile racoon as PIE
- another fix for teardown of the IPSEC SAs on DPD in some circumstances


java-1.6.0-openjdk-1.6.0.0-0.23.b12.fc10
----------------------------------------
* Tue Oct 14 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-0.23.b12
- Updated icedteasnapshot to nil.
- Updated release.
- Added jakarta-commons-logging requirement for visualvm.

* Thu Oct  2 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-0.22.b12
- Enabled building of jvisualvm tool.


logwatch-7.3.6-29.fc10
----------------------
* Fri Oct 17 18:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-29
- fix postfix script again (#462174)


mfiler3-2.1.1-1.fc10
--------------------
* Sat Oct 18 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.1.1-1
- 2.1.1


mod_perl-2.0.4-7
----------------
* Fri Oct 17 18:00:00 2008 Joe Orton <jorton at redhat.com> 2.0.4-7
- fix inline abuse (#459351)


nspluginwrapper-1.1.2-2.fc10
----------------------------
* Fri Oct 17 18:00:00 2008 Martin Stransky <stransky at redhat.com> 1.1.2-2
- added umask to plugin config (#463736)


nss_ldap-261-4.fc10
-------------------
* Fri Oct 17 18:00:00 2008 Nalin Dahyabhai <nalin at redhat.com> - 261-4
- add missing local-to-network conversion on port numbers when looking up
  services (#450634)

* Mon Sep 15 18:00:00 2008 Nalin Dahyabhai <nalin at redhat.com>
- return 0 (fail) instead of 1 (success) when setnetgrent() is called for
  a netgroup which doesn't actually exist or which has no members (#445972,
  upstream #374)


nted-1.4.2-1.fc10
-----------------
* Fri Oct 17 18:00:00 2008 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.4.2-1
- Update to upstream's 1.4.2 release.


obex-data-server-0.4-1.fc10
---------------------------
* Fri Oct 17 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.4-1
- Update to 0.4


obexd-0.6-1.fc10
----------------
* Fri Oct 17 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.6-1
- Update to 0.6


ocsinventory-1.02-0.9.rc3.fc10
------------------------------
* Fri Oct 17 18:00:00 2008 Remi Collet <Fedora at famillecollet.com> 1.02-0.9.rc3
- upstream r1423 patch - migration script


openssh-5.1p1-3.fc10
--------------------
* Fri Oct 17 18:00:00 2008 Tomas Mraz <tmraz at redhat.com> - 5.1p1-3
- fix compatibility with some servers (#466818)


perl-AnyEvent-4.300-1.fc10
--------------------------
* Fri Oct 17 18:00:00 2008 kwizart < kwizart at gmail.com > - 4.300-1
- Update to 4.3   (rpm version : 4.300 )


perl-XML-Grove-0.46alpha-37.fc10
--------------------------------
* Fri Oct 17 18:00:00 2008 Stepan Kasal <skasal at redhat.com> - 0.46alpha-37
- avoid packing DOM-ecmascript.pod twice


plymouth-0.6.0-0.2008.10.17.1.fc10
----------------------------------
* Fri Oct 17 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.10.17.1
- Clear screen in details plugin when it's done
- Make plymouth-update-initrd a small wrapper around mkinitrd instead
  of the broken monstrosity it was before.

* Fri Oct 17 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.10.15.3
- Move plymouth-set-default-plugin, plymouth-update-initrd, and
  plymouth-populate-initrd to plymouth-scripts subpackage
  (the last fix didn't actually help with bug 467356)

* Fri Oct 17 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.5.0-0.2008.10.15.2
- Move plymouth-set-default-plugin to -libs (might help with bug 467356)
- Fix up requires, provides and postun scripts


prelude-lml-0.9.14-1.fc10
-------------------------
* Fri Oct 17 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 0.9.14-1
- new upstream release fixing bz #463459


pyclutter-0.8.0-1.fc10
----------------------
* Wed Oct 15 18:00:00 2008 Allisson Azevedo <allisson at gmail.com> 0.8.0-1
- Update to 0.8.0


python-gammu-0.27-1.fc10
------------------------
* Sat Oct 11 18:00:00 2008 Xavier Lamien <lxtnow at gmail.com> - 0.27-1
- Update release.


python-ply-2.5-1.fc10
---------------------
* Fri Oct 17 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 2.5-1
- update to 2.5


selinux-policy-3.5.13-1.fc10
----------------------------
* Fri Oct 17 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-1
- Policy cleanup


slim-1.3.1-2.fc10
-----------------
* Wed Oct 15 18:00:00 2008 Marco Pesenti Gritti <mpg at redhat.com>  1.3.1-2
- Enable pam_selinux


system-config-printer-1.0.8-7.fc10
----------------------------------
* Fri Oct 17 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 1.0.8-7
- Added patch for pysmbc changes in git to prevent getdents crashing
  (bug #465975).


varnish-2.0.1-1.fc10
--------------------
* Fri Oct 17 18:00:00 2008 Ingvar Hagelund <ingvar at linpro.no> - 2.0.1-1
- 2.0.1 released, a bugfix release. New upstream sources


Summary:
Added Packages: 3
Removed Packages: 1
Modified Packages: 40
Broken deps for i386
----------------------------------------------------------
	python-basemap-0.99-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-grass-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-python-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	python-basemap-0.99-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	qgis-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	qgis-grass-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-grass-0.11.0-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	qgis-python-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-python-0.11.0-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	python-basemap-0.99-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-grass-0.11.0-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-grass-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-python-0.11.0-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-python-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	python-basemap-0.99-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-grass-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-python-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From Axel.Thimm at ATrpms.net  Sat Oct 18 10:10:07 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 18 Oct 2008 13:10:07 +0300
Subject: The Big ACL Opening
In-Reply-To: <20081016171451.GA7049@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <20081018101007.GB24572@victor.nirvana>

On Thu, Oct 16, 2008 at 07:14:51PM +0200, Lennart Poettering wrote:
> Hmm, am I the only one who finds the choice of the term "?berpackager"
> a bit questionnable?
> 
> I am assuming this refers to Nietzsche's "?bermensch" which to start
> with is not a particular sympathetic idea to many. What I find
> particularly problematic however is that at least in Germany this term
> more often than not implies some kind of connection to, uhh, certain
> dark times about 60 years ago.

I wouldn't give to the dark time in Germany the benefit of stealing
words and ideas. Nietsche was against the NS ideology, it was his
sister that aided the misinterpretation and distortion of his writings
for their purposes.

Banning Nietsche, Hoffmann, Haydn and any other misused authors and
artists because they were abused by bad people is a Bad Thing. As a
better known contemporary analogon look at the song by the Beatles
"Helter Skelter" that was misused by Manson and was considered his
property for several years therefore, until U2 covered it [1] starting
with "This is a song Charles Manson stole from The Beatles. We're
stealing it back."

So, don't allow ?ber- to become an NS prefix by declaring it as
such. Use it as much as possible in other contexts, so it gets clean
from any smell that might have remained. And BTW it is being used very
often in German words as a prefix meaning really harmless things
(anything that uses over- or trans- in English likely has an ?ber-
translation, like "translation" itself - "?bersetzung").

[1] actually there were other less known covers, too, but U2 really
    lifted it out of the Mansion occupation.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/94307656/attachment.sig>

From Axel.Thimm at ATrpms.net  Sat Oct 18 10:24:52 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 18 Oct 2008 13:24:52 +0300
Subject: The Big ACL Opening
In-Reply-To: <20081017225358.GA29935@tango.0pointer.de>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
Message-ID: <20081018102452.GC24572@victor.nirvana>

On Sat, Oct 18, 2008 at 12:53:59AM +0200, Lennart Poettering wrote:
> On Fri, 17.10.08 12:46, Jon Ciesla (limb at jcomserv.net) wrote:
> 
> > An interesting irony here is that while Nietzsche's Ubermensch is best
> > translated as Overman, for English, it's commonly mistranslated as
> > Superman, and so Superpackager "sounds" more like what Lennart was getting
> > at than does Uberpackager.  To me, anyway.
> 
> Uh, no. The problem I see is specifically with the german language
> prefix "?ber-" used (as prefix to a word of any other language) as
> some kind of superlative when used in reference to Nietzsche's
> "?bermensch" -- because that term at least Germany has been
> appropriated by the Nazis.

It was misused out of context. We shouldn't allow this
misinterpretation and wrong quotation to mark the term and the
author.

And ?ber- is just another prefix, it can mean a range of things like
over, above, trans, through, via, top etc. Here are some innocent
words:

?berschrift	heading
?bergabe	handover
sich ?bergeben	to throw up
?bergewicht	overweight
?berlegung	thought
?berma?		excess
?berbleibsel	remainder
...

> I fully understand that not everyone is aware of this connection,
> especially outside of Germany. But uh, in Germany it is very obvious.
> 
> Also note that the "?ber" in the first stanza of the "Deutschlandlied"
> played a role in the decision to make only the third stanza the German
> anthem. (i.e. "Deutschland, Deutschland, ?ber alles.")

This has also been misquoted and misinterpreted. The Germany that was
to be above all was a Germany that didn't exists at the time this
anthem was written and the text is universally interpreted as the
author calling the different German countries and counties to lay down
their minor conflicts and to form a common country.

The imperialist reinterpretation was added 100 years later by the
singing Nazi troups.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/8a1f6de7/attachment.sig>

From rjones at redhat.com  Sat Oct 18 10:27:34 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 18 Oct 2008 11:27:34 +0100
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <200810172200.35964.ville.skytta@iki.fi>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<20081017170351.GA2681@free.fr>
	<ufay70nksd6.fsf@epithumia.math.uh.edu>
	<200810172200.35964.ville.skytta@iki.fi>
Message-ID: <20081018102734.GA415@amd.home.annexia.org>

On Fri, Oct 17, 2008 at 10:00:35PM +0300, Ville Skytt? wrote:
> I'm sure that there are a lot of things that are not at all Fedora specific 
> that rpmlint doesn't currently check but very well could.  Please do send 
> patches either to Bugzilla or upstream rpmlint Trac, or just file RFE's 
> (these usually preferably in upstream Trac) in case you have good ideas but 
> no code yet.

If I want rpmbuild to run rpmlint automatically on the packages that
rpmbuild makes, that would be a RFE/patch against rpm, right?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v



From rjones at redhat.com  Sat Oct 18 10:32:24 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 18 Oct 2008 11:32:24 +0100
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224278873.4142.39.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
	<1224274115.4142.28.camel@luminos.localdomain>
	<48F8F8AB.3070304@behdad.org>
	<1224278873.4142.39.camel@luminos.localdomain>
Message-ID: <20081018103224.GB415@amd.home.annexia.org>

On Fri, Oct 17, 2008 at 02:27:53PM -0700, Jesse Keating wrote:
> I'd imagine other desktops have similar workflows when dealing with
> torrent files, I'd think resorting to the command line to deal with them
> would be a last resort for the people who need help getting Fedora
> downloaded.

It's not quite so easy if you've got > 1 machine on your home network
and a typical NAT router.  I have the router set to point the
bittorrent ports at a single machine on the network, so normally I
have to copy the .torrent file over to that machine and then invoke
'bittorrent-curses foo.torrent' remotely.

I imagine this is a fairly common scenario, at least with stupid/old
routers like mine.

Rich.

PS. bittorrent-curses may not be the latest or greatest, but it
certainly seems to do the job.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From Axel.Thimm at ATrpms.net  Sat Oct 18 10:37:32 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 18 Oct 2008 13:37:32 +0300
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <20081017195230.GA13662@nostromo.devel.redhat.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<20081017195230.GA13662@nostromo.devel.redhat.com>
Message-ID: <20081018103732.GD24572@victor.nirvana>

On Fri, Oct 17, 2008 at 03:52:30PM -0400, Bill Nottingham wrote:
> Jesse Keating (jkeating at redhat.com) said: 
> > Most torrent clients I've seen today allow you to pick and choose which
> > files you wish to download.  As such, does it make sense to collapse the
> > DVD and CD torrents into a single torrent and allow people to use the
> > client to pick which they want?  Are there pros/cons to this?
> 
> By 'most', do you know specifically which ones do not?

My favourite one, mldonkey, doesn't support this AFAICT.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/da87de5f/attachment.sig>

From mschwendt at gmail.com  Sat Oct 18 10:58:41 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 18 Oct 2008 12:58:41 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081017225358.GA29935@tango.0pointer.de>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
Message-ID: <20081018125841.b69a392b.mschwendt@gmail.com>

On Sat, 18 Oct 2008 00:53:59 +0200, Lennart Poettering wrote:

> On Fri, 17.10.08 12:46, Jon Ciesla wrote:
> 
> > An interesting irony here is that while Nietzsche's Ubermensch is best
> > translated as Overman, for English, it's commonly mistranslated as
> > Superman, and so Superpackager "sounds" more like what Lennart was getting
> > at than does Uberpackager.  To me, anyway.
> 
> Uh, no. The problem I see is specifically with the german language
> prefix "?ber-" used (as prefix to a word of any other language) as
> some kind of superlative when used in reference to Nietzsche's
> "?bermensch" -- because that term at least Germany has been
> appropriated by the Nazis.
> 
> I fully understand that not everyone is aware of this connection,
> especially outside of Germany. But uh, in Germany it is very obvious.

I think this is ?bertreibung.

> Also note that the "?ber" in the first stanza of the "Deutschlandlied"
> played a role in the decision to make only the third stanza the German
> anthem. (i.e. "Deutschland, Deutschland, ?ber alles.")

The reason is the content of the first stanza, which bears a risk of
misunderstanding it, and its connection to the Third Reich. For anyone
interested: http://en.wikipedia.org/wiki/Deutschlandlied#Modern_misconceptions



From alexl at users.sourceforge.net  Sat Oct 18 11:17:48 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 18 Oct 2008 04:17:48 -0700
Subject: rawhide report: 20081018 changes
In-Reply-To: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	(Rawhide Report's message of "Sat\,
	18 Oct 2008 10\:09\:59 +0000 \(UTC\)")
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
Message-ID: <ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>

>>>>> Rawhide Report  writes:

[...]

Balint,

Can you please announce any soname bumps here on the list *before*
rebuilding to give other package maintainers a chance to rebuild their
dependent packages in time for the next rawhide compose?  

> geos-3.0.1-1.fc10 ----------------- 
> * Fri Oct 17 18:00:00 2008
> Balint Cristian <rezso at rdsor.ro> - 3.0.1-1 - new stable bugfix - fix
> another gcc43 header

At the very least it gives people a heads-up that some things might
break in the next rawhide.  Especially when those dependent packages
aren't owned by you such as qgis and python-basemap:

> Broken deps for i386
> ----------------------------------------------------------
> python-basemap-0.99-2.fc10.i386 requires libgeos-3.0.0.so
> qgis-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
> qgis-grass-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
> qgis-python-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so

Advance announcements of soname bumps on fedora-devel-list is
especially important when we are getting close to the final freeze.

Thanks,
Alex



From walters at verbum.org  Sat Oct 18 14:40:05 2008
From: walters at verbum.org (Colin Walters)
Date: Sat, 18 Oct 2008 10:40:05 -0400
Subject: private group administration
In-Reply-To: <200810180845.15175.opensource@till.name>
References: <48F87E69.7040409@redhat.com> <gdb9ls$kop$1@ger.gmane.org>
	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
	<200810180845.15175.opensource@till.name>
Message-ID: <faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>

2008/10/18 Till Maas <opensource at till.name>:
> On Sat October 18 2008, Colin Walters wrote:
>> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
>>
>> <mw_triad at users.sourceforge.net> wrote:
>> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
>> > a command that can do both.
>>
>> Groups are broken.  Use access control lists: "man setfacl"
>
> ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> everything within a certain directory is owned by everyone of a group,

The point is with ACLs you don't need the files to have a specific
ownership (user/group) as long as they have the right ACLs for access.
 A good way to do this is to avoid groups entirely and just add the
users you want individually.



From cra at WPI.EDU  Sat Oct 18 14:51:27 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 18 Oct 2008 10:51:27 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <20081018103224.GB415@amd.home.annexia.org>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
	<1224274115.4142.28.camel@luminos.localdomain>
	<48F8F8AB.3070304@behdad.org>
	<1224278873.4142.39.camel@luminos.localdomain>
	<20081018103224.GB415@amd.home.annexia.org>
Message-ID: <20081018145127.GI27052@angus.ind.WPI.EDU>

On Sat, Oct 18, 2008 at 11:32:24AM +0100, Richard W.M. Jones wrote:
> PS. bittorrent-curses may not be the latest or greatest, but it
> certainly seems to do the job.

Try rtorrent sometime.  It is curses-based too and much more 
featureful.



From skvidal at fedoraproject.org  Sat Oct 18 14:53:05 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 18 Oct 2008 10:53:05 -0400
Subject: private group administration
In-Reply-To: <faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
References: <48F87E69.7040409@redhat.com> <gdb9ls$kop$1@ger.gmane.org>
	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
	<200810180845.15175.opensource@till.name>
	<faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
Message-ID: <1224341585.21581.113.camel@rosebud>

On Sat, 2008-10-18 at 10:40 -0400, Colin Walters wrote:
> 2008/10/18 Till Maas <opensource at till.name>:
> > On Sat October 18 2008, Colin Walters wrote:
> >> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
> >>
> >> <mw_triad at users.sourceforge.net> wrote:
> >> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> >> > a command that can do both.
> >>
> >> Groups are broken.  Use access control lists: "man setfacl"
> >
> > ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> > everything within a certain directory is owned by everyone of a group,
> 
> The point is with ACLs you don't need the files to have a specific
> ownership (user/group) as long as they have the right ACLs for access.
>  A good way to do this is to avoid groups entirely and just add the
> users you want individually.

If there are enough people working on a project this does not scale.

-sv




From skvidal at fedoraproject.org  Sat Oct 18 14:54:59 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 18 Oct 2008 10:54:59 -0400
Subject: Sendmail still default?
In-Reply-To: <gdb9bj$jc9$2@ger.gmane.org>
References: <48F87794.3090108@redhat.com>  <gdb9bj$jc9$2@ger.gmane.org>
Message-ID: <1224341699.21581.115.camel@rosebud>

On Fri, 2008-10-17 at 19:07 -0500, Matthew Woehlke wrote:
> Lutz Lange wrote:
> > i've just wondered why sendmail is still the default MTA in Fedora.
> > Please enlighten me?
> 
> Some people (/me waves) were concerned about the element of surprise 
> when someone configures a new system, throws some (user) cron jobs on 
> it, and expects local mail delivery to Just Work.
> 


sendmail isn't the only mta in fedora that just works out of the box. I
know postfix does and I believe exim does as well.

-sv




From kushaldas at gmail.com  Sat Oct 18 15:16:17 2008
From: kushaldas at gmail.com (Kushal Das)
Date: Sat, 18 Oct 2008 20:46:17 +0530
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <1224164388.19681.28.camel@victoria-eth>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<48F7435B.40203@pingoured.fr> <1224164388.19681.28.camel@victoria-eth>
Message-ID: <b399909d0810180816v553a0777we534bcf440db39f3@mail.gmail.com>

2008/10/16 Paul W. Frields <stickster at gmail.com>:
> Would a koji scratch-build work for this purpose?
>
I have a very initial stage of code up and running which is taking
bugzilla numbers manually (due to limited speed of network). Currently
only doing koji builds and if successful then rpmlint on resultant
rpms. It is also commenting back to the bugzilla entries.

Bugs done like:
https://bugzilla.redhat.com/show_bug.cgi?id=450527
https://bugzilla.redhat.com/show_bug.cgi?id=460974

Rakesh and Debarshi are going to start up bits to do spec file sanity
checking (fedora-qa script will help here).

Kushal
-- 
http://fedoraproject.org
http://kushaldas.in
\



From mzerqung at 0pointer.de  Sat Oct 18 15:36:56 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sat, 18 Oct 2008 17:36:56 +0200
Subject: The Big ACL Opening
In-Reply-To: <6c3f5e6c0810171709w5b9bfd5dhe64e87e9fbb21cf7@mail.gmail.com>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
	<6c3f5e6c0810171709w5b9bfd5dhe64e87e9fbb21cf7@mail.gmail.com>
Message-ID: <20081018153656.GA24129@tango.0pointer.de>

On Fri, 17.10.08 20:09, Andrew Parker (andrewparker at bigfoot.com) wrote:

> I don't understand why this is an issue.  Uber has no negative
> connotations in English, does it? Do we have to have all our words
> vetted against every language before we can use them?

I already mentioned that you can never be entirely safe in choosing
words that offend nothing and nobody. But for you I am happy to repeat 
myself:

"You never can be entirely safe, there are always words that in some
languages or to some people may be offending or have a questionnable
connotation. However, since Nazism is almost universally agreed to be
without comparison and practically a superlative of evil there are
more than enough reasons to stay away from terminology related to
Nazism."

So no, I am not asking to carefully check every single word we use
against every single language and its possible connotations in that
language. All I am asking for is that we try to stay away from one of
the most extreme things you can associate your words with: Nazism. 

I don't want to be no word police, but uhm, this one was a bit too
obvious to me. 

Also, I am not sure why we really need to discuss this further. Toshio
already agreed to changing this term and it is not too much work. So
let's just do it and forget about it and not continue this discussion
here. I am here for the code, not for discussing Nazism.

Thanks.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From mzerqung at 0pointer.de  Sat Oct 18 15:51:21 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sat, 18 Oct 2008 17:51:21 +0200
Subject: The Big ACL Opening
In-Reply-To: <200810180855.32076.opensource@till.name>
References: <48F64212.2010505@redhat.com>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
	<200810180855.32076.opensource@till.name>
Message-ID: <20081018155121.GB24129@tango.0pointer.de>

On Sat, 18.10.08 08:55, Till Maas (opensource at till.name) wrote:

> I live in Germany and am a native speaker, but for me this is not
> very obvious.  I also doubt, that anyone I know would think about
> someone within Fedora beeing a nazi oder inhuman, because of the
> groupname uberpackager.

That is not the question. Of course it is nonsense to assume that
Fedora is a Nazi Club because it called a role in its organization an
"?berpackager". But concluding from it that we are a Club of
ignoramuses suffering by illiterateness and historical amnesia might
be far less off the truth.

Lennart



From lsof at nodata.co.uk  Sat Oct 18 15:54:18 2008
From: lsof at nodata.co.uk (nodata)
Date: Sat, 18 Oct 2008 17:54:18 +0200
Subject: The Big ACL Opening
In-Reply-To: <48F82FBC.5010003@nicubunu.ro>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48F82FBC.5010003@nicubunu.ro>
Message-ID: <1224345258.4077.3.camel@sb-home>

Am Freitag, den 17.10.2008, 09:25 +0300 schrieb Nicu Buculei:
> Lennart Poettering wrote:
> > 
> > Hmm, am I the only one who finds the choice of the term "?berpackager"
> > a bit questionnable?
> 
> Pretty much terms like "?bergeek" and "?berhacker" are part of the 
> online culture:
> http://uncyclopedia.org/wiki/Ubergeek
> http://en.wikipedia.org/wiki/Uberhacker

and spelt wrong. ?->Ue

> 
> -- 
> 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 thomas.moschny at gmail.com  Sat Oct 18 16:04:59 2008
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Sat, 18 Oct 2008 18:04:59 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <48F5C75A.9040603@redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48F5C75A.9040603@redhat.com>
Message-ID: <a9d183c80810180904l24c9a894s7c1ae6230edcf071@mail.gmail.com>

2008/10/15 Karsten Hopp <karsten at redhat.com>:
> I've uploaded the current logs to http://karsten.fedorapeople.org/
> After a quick glance at them I think that there are quite a few easy fixes,

from libtool2-failures/monotone-0.41-1.fc10.txt:

[...]
+ emacs -batch -f batch-byte-compile
/var/tmp/monotone-0.41-1.fc10.src.rpm-root/usr/share/emacs/site-lisp
[...]
Loading /usr/share/emacs/site-lisp/site-start.d/uim-init.el (source)...
uim.el: starting uim-el-helper-agent...
uim.el: uim-el-helper-agent is unreponsive.  Giving up.
error: Bad exit status from
/var/tmp/monotone-0.41-1.fc10.src.rpm/rpm-tmp.6uZuL9 (%install)

Doesn't look like a libtool issue. This can be fixed by adding
something like '-no-site-file -no-init-file', I guess?

- Thomas



From kwhiskerz at gmail.com  Sat Oct 18 16:07:10 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Sat, 18 Oct 2008 10:07:10 -0600
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
Message-ID: <gdd1je$i7l$1@ger.gmane.org>

evdev driver 7.0.1-2 makes keyboard input impossible. All key-presses are done in triplicate, including backspace, so it is impossible to correct the erroneous input.




From mzerqung at 0pointer.de  Sat Oct 18 16:10:38 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sat, 18 Oct 2008 18:10:38 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081018101007.GB24572@victor.nirvana>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<20081018101007.GB24572@victor.nirvana>
Message-ID: <20081018161037.GC24129@tango.0pointer.de>

On Sat, 18.10.08 13:10, Axel Thimm (Axel.Thimm at ATrpms.net) wrote:

> On Thu, Oct 16, 2008 at 07:14:51PM +0200, Lennart Poettering wrote:
> > Hmm, am I the only one who finds the choice of the term "?berpackager"
> > a bit questionnable?
> > 
> > I am assuming this refers to Nietzsche's "?bermensch" which to start
> > with is not a particular sympathetic idea to many. What I find
> > particularly problematic however is that at least in Germany this term
> > more often than not implies some kind of connection to, uhh, certain
> > dark times about 60 years ago.
> 
> I wouldn't give to the dark time in Germany the benefit of stealing
> words and ideas. Nietsche was against the NS ideology, it was his
> sister that aided the misinterpretation and distortion of his writings
> for their purposes.

"Nietzsche against NS ideology"??? This argument is bogus. Nietzsche
died 20 years before the Nazi party was founded. How could he have
been against them if they didn't really exist?

Discussing whether Nietzsche liked the Nazis or not is completely
irrelevant here. Don't make this some kind of Stammtisch discussion
about philosophy and Who's-A-Nazi.

> So, don't allow ?ber- to become an NS prefix by declaring it as
> such. Use it as much as possible in other contexts, so it gets clean
> from any smell that might have remained. And BTW it is being used very
> often in German words as a prefix meaning really harmless things
> (anything that uses over- or trans- in English likely has an ?ber-
> translation, like "translation" itself - "?bersetzung").

Unfortunately the Nazis didn't ask you for permission before they
appropriated "?bermensch" for their purposes. Sorry, but you won't
be able to clean the words "F?hrer", "Schutzstaffel" or "?bermensch"
from their Nazi associations. Trying to do that is both too big for
your boots and a sign of Geschichtsvergessenheit.

And of course, "?ber-" is a very common prefix in the german
language. In verbs, in adjectives, everywhere. But please, don't twist
my words: I find it questionnable to use the prefix as kind of
superlative in reference to the ?bermensch. That is all.

Let's end this discussion! Fedora-devel is not the place to discuss
Nazi vocabulary. Toshio already agreed to change the term. So I am
happy, no need for pointless bikeshedding discussions.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From kwhiskerz at gmail.com  Sat Oct 18 16:11:09 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Sat, 18 Oct 2008 10:11:09 -0600
Subject: =?utf-8?q?Correction!=C2=A0xorg-x11-drv-evdev-2=2E0=2E7-1?= bad!
Message-ID: <gdd1qt$jqs$1@ger.gmane.org>

All keystrokes are entered 3 times. 2.0.6-2 was fine, but no longer available, so how to revert?



From kaie at kuix.de  Sat Oct 18 16:18:32 2008
From: kaie at kuix.de (Kai Engert)
Date: Sat, 18 Oct 2008 18:18:32 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <7155.82.95.253.31.1224293485.squirrel@webmail.xs4all.nl>
References: <7155.82.95.253.31.1224293485.squirrel@webmail.xs4all.nl>
Message-ID: <48FA0C58.5030401@kuix.de>

Stefan Hartsuiker wrote:
> Op Za, 18 oktober, 2008 01:39, schreef Jesse Keating:
>   
>> On Sat, 2008-10-18 at 01:04 +0200, Till Maas wrote:
>>     
>>> I have a probably crazy idea: How about composing the DVD iso using a
>>> filesystem that contains the CD isos and a bootloader that can use the CD
>>> isos as installation source? Then a little bit of space of the DVD iso would
>>> be wasted and it would take a little more effort to burn only the CD isos,
>>> but then only one torrent would be needed and everyone can easily share
>>> bandwidth with everyone else.
>>>       
>> Split media installs (which that would result in for even the DVD case)
>> has some interesting side-effects, that really hurt when trying to add
>> external repos (particularly of updates) at install time.  I wouldn't
>> want to force it upon everybody.
>>     
> Uhm, maybe it's me, but if the system can boot from the dvd, why do you want
> to install from cd's?
>   

Because not everyone in the world has enough resources to afford recent 
hardware and a DVD drive.

Kai


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

From cra at WPI.EDU  Sat Oct 18 16:25:35 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 18 Oct 2008 12:25:35 -0400
Subject: private group administration
In-Reply-To: <1224341585.21581.113.camel@rosebud>
References: <48F87E69.7040409@redhat.com> <gdb9ls$kop$1@ger.gmane.org>
	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
	<200810180845.15175.opensource@till.name>
	<faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
	<1224341585.21581.113.camel@rosebud>
Message-ID: <20081018162535.GJ27052@angus.ind.WPI.EDU>

On Sat, Oct 18, 2008 at 10:53:05AM -0400, seth vidal wrote:
> On Sat, 2008-10-18 at 10:40 -0400, Colin Walters wrote:
> > 2008/10/18 Till Maas <opensource at till.name>:
> > > On Sat October 18 2008, Colin Walters wrote:
> > >> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
> > >>
> > >> <mw_triad at users.sourceforge.net> wrote:
> > >> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> > >> > a command that can do both.
> > >>
> > >> Groups are broken.  Use access control lists: "man setfacl"
> > >
> > > ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> > > everything within a certain directory is owned by everyone of a group,
> > 
> > The point is with ACLs you don't need the files to have a specific
> > ownership (user/group) as long as they have the right ACLs for access.
> >  A good way to do this is to avoid groups entirely and just add the
> > users you want individually.
> 
> If there are enough people working on a project this does not scale.

Right, with groups you can have files inherit the group from the 
directory they are in.  Is there any inheritance with ACLs?



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Oct 18 16:30:55 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 19 Oct 2008 01:30:55 +0900
Subject: Correction! xorg-x11-drv-evdev-2.0.7-1 bad!
In-Reply-To: <gdd1qt$jqs$1@ger.gmane.org>
References: <gdd1qt$jqs$1@ger.gmane.org>
Message-ID: <48FA0F3F.2050005@ioa.s.u-tokyo.ac.jp>

kwhiskerz wrote, at 10/19/2008 01:11 AM +9:00:
> All keystrokes are entered 3 times. 2.0.6-2 was fine, but no longer 
> available, so how to revert?

I guess you want to file a bug (as it is less than 2 weeks before F-10
development is frozen), however if you want to use the previous rpms
for now:

http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-evdev/

Mamoru



From Axel.Thimm at ATrpms.net  Sat Oct 18 16:53:38 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 18 Oct 2008 19:53:38 +0300
Subject: The Big ACL Opening
In-Reply-To: <20081018161037.GC24129@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<20081018101007.GB24572@victor.nirvana>
	<20081018161037.GC24129@tango.0pointer.de>
Message-ID: <20081018165338.GA31641@victor.nirvana>

On Sat, Oct 18, 2008 at 06:10:38PM +0200, Lennart Poettering wrote:
> On Sat, 18.10.08 13:10, Axel Thimm (Axel.Thimm at ATrpms.net) wrote:
> 
> > On Thu, Oct 16, 2008 at 07:14:51PM +0200, Lennart Poettering wrote:
> > > Hmm, am I the only one who finds the choice of the term "?berpackager"
> > > a bit questionnable?
> > > 
> > > I am assuming this refers to Nietzsche's "?bermensch" which to start
> > > with is not a particular sympathetic idea to many. What I find
> > > particularly problematic however is that at least in Germany this term
> > > more often than not implies some kind of connection to, uhh, certain
> > > dark times about 60 years ago.
> > 
> > I wouldn't give to the dark time in Germany the benefit of stealing
> > words and ideas. Nietsche was against the NS ideology, it was his
> > sister that aided the misinterpretation and distortion of his writings
> > for their purposes.
> 
> "Nietzsche against NS ideology"??? This argument is bogus. Nietzsche
> died 20 years before the Nazi party was founded. How could he have
> been against them if they didn't really exist?

The NS party was not founded out of thin air, antisemitian and
nationalist movements were around long before any party
foundation. Nietsches sister with her husband founded an Aryan village
with an unhappy ending in 1887

http://en.wikipedia.org/wiki/Bernhard_F?rster

She is also responsible for the misuse of Nietsches work by
antisemtitians and later the NS regime. And Nietsche wrote to his
sister in published letters that he both disliked the antisemitian and
nationalist movements as well as the antisemtitian interpretation of
his works as she was trying to promote it.

So, yes, Nietsche was against the NS ideology.

> Discussing whether Nietzsche liked the Nazis or not is completely
> irrelevant here. Don't make this some kind of Stammtisch discussion
> about philosophy and Who's-A-Nazi.

Sorry Lennard, but you did that. Dragging a philosopher's work into
the dirt begs for correction. Actually I'm trying to save you from
playing into the hands of the regime we all equally dislike.

> > So, don't allow ?ber- to become an NS prefix by declaring it as
> > such. Use it as much as possible in other contexts, so it gets clean
> > from any smell that might have remained. And BTW it is being used very
> > often in German words as a prefix meaning really harmless things
> > (anything that uses over- or trans- in English likely has an ?ber-
> > translation, like "translation" itself - "?bersetzung").
> 
> Unfortunately the Nazis didn't ask you for permission before they
> appropriated "?bermensch" for their purposes. Sorry, but you won't
> be able to clean the words "F?hrer", "Schutzstaffel" or "?bermensch"
> from their Nazi associations. Trying to do that is both too big for
> your boots and a sign of Geschichtsvergessenheit.

Please be less insultive, I really suggest you do look up the history
behind the use of ?bermensch and also the effords in the 60s/70s in
(west) Germany to properly analyse history and not hide away
pretending the NS regime did not take place.

You suggest I try to forget history and it's the opposite: There has
been a distortion of history by the bad people you dislike and by
your actions you are only feeding this displacement.

Just for fun, if you walk up the alps will you refrain from calling
the guide a Bergf?hrer? Or your driver's license a F?hrerschein?

Of course not, and that's why Ubergeek and Uberpackager are not Nazi
words either.

> And of course, "?ber-" is a very common prefix in the german
> language. In verbs, in adjectives, everywhere. But please, don't twist
> my words: I find it questionnable to use the prefix as kind of
> superlative in reference to the ?bermensch. That is all.
> 
> Let's end this discussion! Fedora-devel is not the place to discuss
> Nazi vocabulary. Toshio already agreed to change the term. So I am
> happy, no need for pointless bikeshedding discussions.

I need to repeat that succumbing to banning words just strongens their
negative connotations further. Don't flight the scene!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/7c1f9384/attachment.sig>

From lesmikesell at gmail.com  Sat Oct 18 16:55:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 18 Oct 2008 11:55:07 -0500
Subject: private group administration
In-Reply-To: <faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
References: <48F87E69.7040409@redhat.com>
	<gdb9ls$kop$1@ger.gmane.org>	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>	<200810180845.15175.opensource@till.name>
	<faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
Message-ID: <48FA14EB.4050004@gmail.com>

Colin Walters wrote:
>
>>> <mw_triad at users.sourceforge.net> wrote:
>>>> If 'chmod g+w file;chgrp foo file' is too much work then there should be
>>>> a command that can do both.
>>> Groups are broken.  Use access control lists: "man setfacl"
>> ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
>> everything within a certain directory is owned by everyone of a group,
> 
> The point is with ACLs you don't need the files to have a specific
> ownership (user/group) as long as they have the right ACLs for access.
>  A good way to do this is to avoid groups entirely and just add the
> users you want individually.

This is unmanageable as the people in groups change.  When you are 
designing operating systems you should understand that underlying data 
and work processes may need to survive and be usable for decades as the 
hardware and people change. I don't think anyone working with fedora 
gets that.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Oct 18 17:03:15 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 18 Oct 2008 12:03:15 -0500
Subject: Sendmail still default?
In-Reply-To: <1224341699.21581.115.camel@rosebud>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud>
Message-ID: <48FA16D3.5020204@gmail.com>

seth vidal wrote:
> On Fri, 2008-10-17 at 19:07 -0500, Matthew Woehlke wrote:
>> Lutz Lange wrote:
>>> i've just wondered why sendmail is still the default MTA in Fedora.
>>> Please enlighten me?
>> Some people (/me waves) were concerned about the element of surprise 
>> when someone configures a new system, throws some (user) cron jobs on 
>> it, and expects local mail delivery to Just Work.
>>
> 
> 
> sendmail isn't the only mta in fedora that just works out of the box. I
> know postfix does and I believe exim does as well.

And did anyone have an actual problem with sendmail other than noticing 
it taking time to start the daemon in the boot sequence.  That's a 
problem that can be solved on its own since you don't really need a 
daemon then.

Removing mail from the expected services is just the wrong thing to do, 
especially if the reasoning is that the service isn't understood or used 
to advantage.  Add a setup for a root alias in firstboot and a mail 
notifier in the gnome panel to make the system more useful instead of less.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From andrewparker at bigfoot.com  Sat Oct 18 17:07:46 2008
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Sat, 18 Oct 2008 13:07:46 -0400
Subject: The Big ACL Opening
In-Reply-To: <20081018153656.GA24129@tango.0pointer.de>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
	<6c3f5e6c0810171709w5b9bfd5dhe64e87e9fbb21cf7@mail.gmail.com>
	<20081018153656.GA24129@tango.0pointer.de>
Message-ID: <6c3f5e6c0810181007v37ace39aj65425a2c58e98145@mail.gmail.com>

On Sat, Oct 18, 2008 at 11:36 AM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:

> Also, I am not sure why we really need to discuss this further.

because you are mistranslating the english use of "uber"; taking
offense at your mistake; and expecting other people to take action to
prevent you from repeating your error.

> forget about it and not continue this discussion

i agree, and like you i reserve the right to put out a few more emails
on the subject too.



From a.badger at gmail.com  Sat Oct 18 17:09:11 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 18 Oct 2008 10:09:11 -0700
Subject: The Big ACL Opening
In-Reply-To: <1224306428.21581.108.camel@rosebud>
References: <48F64212.2010505@redhat.com>
	<48F79D1B.9080800@gmail.com>	<20081017103456.GA22692@tango.0pointer.de>	<200810172040.57322.ville.skytta@iki.fi>	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>	<20081017210147.GA24430@shell.devel.redhat.com>	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>	<20081017223126.GH27444@angus.ind.WPI.EDU>	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224306428.21581.108.camel@rosebud>
Message-ID: <48FA1837.8010009@gmail.com>

seth vidal wrote:
> On Sat, 2008-10-18 at 00:51 -0400, Paul W. Frields wrote:
>> On Fri, 2008-10-17 at 18:31 -0400, Chuck Anderson wrote:
>>> On Fri, Oct 17, 2008 at 03:54:25PM -0600, Stephen John Smoogen wrote:
>>>> On Fri, Oct 17, 2008 at 3:01 PM, Alan Cox <alan at redhat.com> wrote:
>>>>>> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
>>>>>> and superpackager.
>>>>> Super is probably sane enough but English has a long and distinguished
>>>>> history of stealing other peoples words and using them wrongly so uber- in
>>>>> English [ab]use is not atypical ;)
>>>>>
>>>> or adding them together... super-ultra-ginormous packager.
>>>>
>>>> super was used a lot so it was no longer super. I think that is when
>>>> Ultra was the new super.. Uber was the 80's new Super since it 'should
>>>> have' umlauts like any 'proper' Germanic word. I mean how else can you
>>>> have a rock band name without umlauts.  I think gi-normous  is the
>>>> current generations super...
>>> How about a more neutral term?
>>>
>>> experiencedpackager
>>> trustedpackager
>>>
>>> Here's some that imply scope rather than "l33tness"? (no, lets not use 
>>> l33tpackager as fun as it sounds).  Since those packagers can touch 
>>> (almost) all packages how about:
>>>
>>> globalpackager
>>> universepackager
>>> everypackager
>> "Allpackager," kind of like "allspice."
>>
> 
> OdinPackager? 
> WednesdayPackager?
> 
Okay but then I insist on renaming the intro level Packager group to
PugsleyPackager. :-)

-Toshio

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

From ville.skytta at iki.fi  Sat Oct 18 17:29:23 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Sat, 18 Oct 2008 20:29:23 +0300
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <20081018102734.GA415@amd.home.annexia.org>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<200810172200.35964.ville.skytta@iki.fi>
	<20081018102734.GA415@amd.home.annexia.org>
Message-ID: <200810182029.24059.ville.skytta@iki.fi>

On Saturday 18 October 2008, Richard W.M. Jones wrote:
> On Fri, Oct 17, 2008 at 10:00:35PM +0300, Ville Skytt? wrote:
> > I'm sure that there are a lot of things that are not at all Fedora
> > specific that rpmlint doesn't currently check but very well could. 
> > Please do send patches either to Bugzilla or upstream rpmlint Trac, or
> > just file RFE's (these usually preferably in upstream Trac) in case you
> > have good ideas but no code yet.
>
> If I want rpmbuild to run rpmlint automatically on the packages that
> rpmbuild makes, that would be a RFE/patch against rpm, right?

Right.



From nicolas.mailhot at laposte.net  Sat Oct 18 17:30:36 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 18 Oct 2008 19:30:36 +0200
Subject: Sendmail still default?
In-Reply-To: <48FA16D3.5020204@gmail.com>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud>  <48FA16D3.5020204@gmail.com>
Message-ID: <1224351036.11070.11.camel@arekh.okg>

Le samedi 18 octobre 2008 ? 12:03 -0500, Les Mikesell a ?crit :

> And did anyone have an actual problem with sendmail other than noticing 
> it taking time to start the daemon in the boot sequence.

I think each one of us who've replaced sendmail with something else has
(despite years of RH/Fedora trying force sendmail through our throats).

Even back when postfix was just a powertools option people knew sendmail
was a poor default.

As an engineer who likes neat technical stuff and contributes to Fedora
because it tends to produce neat technical stuff it makes me cringe each
time I'm reminded we ship sendmail instead of something properly
designed for an untrusted TCP/IP network world.

You may extend years of hole-fixing and patch a sieve enough it sort of
floats but it's still a poor excuse of a boat. Even if passengers only
see the "it floats" bit.

-- 
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/20081018/04bfaaf9/attachment.sig>

From jkeating at redhat.com  Sat Oct 18 17:38:02 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 18 Oct 2008 10:38:02 -0700
Subject: The Big ACL Opening
In-Reply-To: <364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
Message-ID: <1224351482.4219.0.camel@luminos.localdomain>

On Sat, 2008-10-18 at 10:01 +0100, Christopher Brown wrote:
> 
> It would be nice to have something a bit more ... interesting. In
> Japan, they wrap gifts in cloths called "furoshiki" so perhaps
> furoshiki-packager?

Wait wait, I know, kamikazepackager !  We swoop in like a divine wind
and fix all the problems!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/5a44ad90/attachment.sig>

From kevin.kofler at chello.at  Sat Oct 18 17:39:30 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 18 Oct 2008 17:39:30 +0000 (UTC)
Subject: The Big ACL Opening
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <loom.20081018T173644-863@post.gmane.org>

Lennart Poettering <mzerqung <at> 0pointer.de> writes:
> Hmm, am I the only one who finds the choice of the term "?berpackager"
> a bit questionnable?

No, you aren't. I also consider the "uberpackager" name to be stupid due to the 
connotations that term has picked up, +1 for renaming it to "superpackager".

        Kevin Kofler



From sahartsu at xs4all.nl  Sat Oct 18 17:52:48 2008
From: sahartsu at xs4all.nl (Stefan Hartsuiker)
Date: Sat, 18 Oct 2008 19:52:48 +0200 (CEST)
Subject: Collapsing DVD and CD torrents into one
Message-ID: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>

Op Za, 18 oktober, 2008 18:18, schreef Kai Engert:
> Stefan Hartsuiker wrote:
>> Op Za, 18 oktober, 2008 01:39, schreef Jesse Keating:
>>
>>> On Sat, 2008-10-18 at 01:04 +0200, Till Maas wrote:
>>>
>>>> I have a probably crazy idea: How about composing the DVD iso using a
>>>> filesystem that contains the CD isos and a bootloader that can use the CD
>>>> isos as installation source? Then a little bit of space of the DVD iso
>>>> would
>>>> be wasted and it would take a little more effort to burn only the CD isos,
>>>> but then only one torrent would be needed and everyone can easily share
>>>> bandwidth with everyone else.
>>>>
>>> Split media installs (which that would result in for even the DVD case)
>>> has some interesting side-effects, that really hurt when trying to add
>>> external repos (particularly of updates) at install time.  I wouldn't
>>> want to force it upon everybody.
>>>
>> Uhm, maybe it's me, but if the system can boot from the dvd, why do you want
>> to install from cd's?
>>
>
> Because not everyone in the world has enough resources to afford recent
> hardware and a DVD drive.
I know and that was not the reason for my confusion :)
What I understood from Till's first sentence above, is that he would like a
dvd that has a bootloader that can use the enclosed cd iso's as an
installation source. This then would imply that it only works if the system
can actually already boot from the dvd? Therefore it seems to me a bit
pointless.

This however does not mean that I am opposed to being able to easily create
the cd images or even have them on the dvd already. I merely do not see the
point of shipping such a dvd as I think he meant.

Regards,
Stefan Hartsuiker



From jkeating at redhat.com  Sat Oct 18 17:59:33 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 18 Oct 2008 10:59:33 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>
References: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>
Message-ID: <1224352773.4219.3.camel@luminos.localdomain>

On Sat, 2008-10-18 at 19:52 +0200, Stefan Hartsuiker wrote:
> I know and that was not the reason for my confusion :)
> What I understood from Till's first sentence above, is that he would like a
> dvd that has a bootloader that can use the enclosed cd iso's as an
> installation source. This then would imply that it only works if the system
> can actually already boot from the dvd? Therefore it seems to me a bit
> pointless.

Fedora would distribute one piece of media.  You would either boot from
it and install, or you would mount it (loop back) and burn the CD sized
isos held within, to boot from those and install from them.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/dfe478fd/attachment.sig>

From cra at WPI.EDU  Sat Oct 18 18:08:57 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 18 Oct 2008 14:08:57 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224352773.4219.3.camel@luminos.localdomain>
References: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>
	<1224352773.4219.3.camel@luminos.localdomain>
Message-ID: <20081018180857.GK27052@angus.ind.WPI.EDU>

On Sat, Oct 18, 2008 at 10:59:33AM -0700, Jesse Keating wrote:
> On Sat, 2008-10-18 at 19:52 +0200, Stefan Hartsuiker wrote:
> > I know and that was not the reason for my confusion :)
> > What I understood from Till's first sentence above, is that he would like a
> > dvd that has a bootloader that can use the enclosed cd iso's as an
> > installation source. This then would imply that it only works if the system
> > can actually already boot from the dvd? Therefore it seems to me a bit
> > pointless.
> 
> Fedora would distribute one piece of media.  You would either boot from
> it and install, or you would mount it (loop back) and burn the CD sized
> isos held within, to boot from those and install from them.

Bonus points if you can figure out how to make the DVD multi-session 
so that all the files from inside the embedded CD iso's show up as 
regular files in the DVD :-)



From lists at ralii.com  Sat Oct 18 18:21:37 2008
From: lists at ralii.com (Robert Locke)
Date: Sat, 18 Oct 2008 14:21:37 -0400
Subject: private group administration
In-Reply-To: <20081018162535.GJ27052@angus.ind.WPI.EDU>
References: <48F87E69.7040409@redhat.com> <gdb9ls$kop$1@ger.gmane.org>
	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
	<200810180845.15175.opensource@till.name>
	<faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
	<1224341585.21581.113.camel@rosebud>
	<20081018162535.GJ27052@angus.ind.WPI.EDU>
Message-ID: <1224354097.20129.1.camel@rlt60f8.laptop.redhat.com>


On Sat, 2008-10-18 at 12:25 -0400, Chuck Anderson wrote:
> On Sat, Oct 18, 2008 at 10:53:05AM -0400, seth vidal wrote:
> > On Sat, 2008-10-18 at 10:40 -0400, Colin Walters wrote:
> > > 2008/10/18 Till Maas <opensource at till.name>:
> > > > On Sat October 18 2008, Colin Walters wrote:
> > > >> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
> > > >>
> > > >> <mw_triad at users.sourceforge.net> wrote:
> > > >> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> > > >> > a command that can do both.
> > > >>
> > > >> Groups are broken.  Use access control lists: "man setfacl"
> > > >
> > > > ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> > > > everything within a certain directory is owned by everyone of a group,
> > > 
> > > The point is with ACLs you don't need the files to have a specific
> > > ownership (user/group) as long as they have the right ACLs for access.
> > >  A good way to do this is to avoid groups entirely and just add the
> > > users you want individually.
> > 
> > If there are enough people working on a project this does not scale.
> 
> Right, with groups you can have files inherit the group from the 
> directory they are in.  Is there any inheritance with ACLs?
> 

See 'setfacl d:' which can be used to set a "default" ACL on a directory
so that all "newly created files" will inherit it....

--Rob



From lesmikesell at gmail.com  Sat Oct 18 18:34:34 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 18 Oct 2008 13:34:34 -0500
Subject: Sendmail still default?
In-Reply-To: <1224351036.11070.11.camel@arekh.okg>
References: <48F87794.3090108@redhat.com>
	<gdb9bj$jc9$2@ger.gmane.org>	<1224341699.21581.115.camel@rosebud>
	<48FA16D3.5020204@gmail.com> <1224351036.11070.11.camel@arekh.okg>
Message-ID: <48FA2C3A.2060003@gmail.com>

Nicolas Mailhot wrote:
> Le samedi 18 octobre 2008 ? 12:03 -0500, Les Mikesell a ?crit :
> 
>> And did anyone have an actual problem with sendmail other than noticing 
>> it taking time to start the daemon in the boot sequence.
> 
> I think each one of us who've replaced sendmail with something else has
> (despite years of RH/Fedora trying force sendmail through our throats).
> 
> Even back when postfix was just a powertools option people knew sendmail
> was a poor default.

Sendmail was a poor default back when it always ran everything as root 
and accepted and delivered in the same process.  Maybe you didn't notice 
that has changed or the enforced separation of the queuing and delivery 
steps.

> As an engineer who likes neat technical stuff and contributes to Fedora
> because it tends to produce neat technical stuff it makes me cringe each
> time I'm reminded we ship sendmail instead of something properly
> designed for an untrusted TCP/IP network world.

Ummm, when was the last time you saw a network exploit for sendmail?  As 
I recall, postfix has also had some local exploits and probably more 
recently than sendmail.

> You may extend years of hole-fixing and patch a sieve enough it sort of
> floats but it's still a poor excuse of a boat. Even if passengers only
> see the "it floats" bit.

You seem to have missed the sea change.  And the capabilities added by 
the milter interface that it took the other contenders many years to 
duplicate properly.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mattdm at mattdm.org  Sat Oct 18 18:57:57 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 18 Oct 2008 14:57:57 -0400
Subject: text-to-speech doesn't work
In-Reply-To: <gdbd1f$r8e$1@ger.gmane.org>
References: <gdbd1f$r8e$1@ger.gmane.org>
Message-ID: <20081018185757.GA12113@jadzia.bu.edu>

On Fri, Oct 17, 2008 at 07:10:05PM -0600, kwhiskerz wrote:
> I am using Fedora release 9.92 (Rawhide). For some time now, likely late in Fedora 8, or during Fedora 9, text-to-speech ceased to work. This applies to both festival and espeak.
> festival --tts file.txt
> espeak -f file.txt --punct=""
> Neither gives any audible output. The programs just run indefinitely and nothing happens.

This probably falls under "fun with pulseaudio". See
<https://bugzilla.redhat.com/show_bug.cgi?id=467531>

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From jaroslav at aster.pl  Sat Oct 18 19:13:28 2008
From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=)
Date: Sat, 18 Oct 2008 21:13:28 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8FA5C.9060303@behdad.org>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8F95F.3050904@fedoraproject.org> <48F8FA5C.9060303@behdad.org>
Message-ID: <200810182113.29001.jaroslav@aster.pl>

Hi,

Friday 17 of October 2008 22:49:32 Behdad Esfahbod napisa?(a):
(...)
>
> I didn't intend to be rude, sorry if it looked that way.  I was showing by
> example that merging the CD and DVD images is making it hard for users to
> get what they want without what they don't want.

Why? I think it won't be harder than it is now. When I visit fedora download 
page I have to decide what do download (which url to click to get needed 
ISO). In the proposed scenario I have to download a torrent, open it, and 
then choose which ISO to download. As far as I see, this is exactly the same.

regards,

-- 
Jaros?aw G?rny
RHCE



From kwhiskerz at gmail.com  Sat Oct 18 19:30:46 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Sat, 18 Oct 2008 13:30:46 -0600
Subject: Correction! xorg-x11-drv-evdev-2.0.7-1 bad!
References: <gdd1qt$jqs$1@ger.gmane.org> <48FA0F3F.2050005@ioa.s.u-tokyo.ac.jp>
Message-ID: <gdddh6$ncm$1@ger.gmane.org>

Mamoru Tasaka wrote:

> http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-evdev/
> 
Thanks. I finally figured that out myself. Fortunately, I had only applied the update to the laptop, or I would have really been up $#|+ Creek.

Yes, I guess I will file a bug.



From hughsient at gmail.com  Sat Oct 18 19:51:57 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 18 Oct 2008 20:51:57 +0100
Subject: PackageKit soon to include the QPackageKit library, need advice
Message-ID: <1224359517.29507.46.camel@hughsie-laptop>

Upstream the PackageKit-Qt library binding has been merged into the
PackageKit scm and will be in the next release tarball. This allows us
to keep the libraries in sync and also means QPackageKit gets a lot of
the love that PackageKit gets.

Love includes things like a .pc file, consistent so versioning, make
check integration and also much better integration with upstream.

Now we have two libraries (soon to be three), I'm intending to rename:

PackageKit-libs  -> PackageKit-libs-glib
PackageKit-devel -> PackageKit-glib-devel

This allows us to create PackageKit-libs-qt and PackageKit-qt-devel and
then provide this for other QT and KDE applications to trivially build
against.

Does this conform to fedora naming conventions? I thought it was odd to
have -libs-foo and -foo-devel (switched order) but am trying to copy
convention from other frameworks in the repos.

This will obsolete qpackagekit, and kpackagekit will have to be rebuilt
against PackageKit-qt. This isn't a problem. kpackagekit is heading into
kde svn soon too, as this will be the future long term home of the KDE
bits.

Comments and suggestions welcome. Thanks.

Richard.




From drago01 at gmail.com  Sat Oct 18 19:57:24 2008
From: drago01 at gmail.com (drago01)
Date: Sat, 18 Oct 2008 21:57:24 +0200
Subject: PackageKit soon to include the QPackageKit library, need advice
In-Reply-To: <1224359517.29507.46.camel@hughsie-laptop>
References: <1224359517.29507.46.camel@hughsie-laptop>
Message-ID: <f6ca9fed0810181257r37424670vae3c713b0d3346b2@mail.gmail.com>

On Sat, Oct 18, 2008 at 9:51 PM, Richard Hughes <hughsient at gmail.com> wrote:
> Upstream the PackageKit-Qt library binding has been merged into the
> PackageKit scm and will be in the next release tarball. This allows us
> to keep the libraries in sync and also means QPackageKit gets a lot of
> the love that PackageKit gets.
>
> Love includes things like a .pc file, consistent so versioning, make
> check integration and also much better integration with upstream.
>
> Now we have two libraries (soon to be three), I'm intending to rename:
>
> PackageKit-libs  -> PackageKit-libs-glib

why not just PackageKit-glib ? like NetworkManager-glib, dbus-glib,
avahi-glib etc.

> PackageKit-devel -> PackageKit-glib-devel
>
> This allows us to create PackageKit-libs-qt and PackageKit-qt-devel and
> then provide this for other QT and KDE applications to trivially build
> against.

same here I would just drop the libs and call it PackageKit-qt



From dominik at greysector.net  Sat Oct 18 19:58:09 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 18 Oct 2008 21:58:09 +0200
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
In-Reply-To: <gdd1je$i7l$1@ger.gmane.org>
References: <gdd1je$i7l$1@ger.gmane.org>
Message-ID: <20081018195808.GA10897@mokona.greysector.net>

On Saturday, 18 October 2008 at 18:07, kwhiskerz wrote:
> evdev driver 7.0.1-2 makes keyboard input impossible. All key-presses
> are done in triplicate, including backspace, so it is impossible
> to correct the erroneous input.

$ rpm -q xorg-x11-drv-evdev
xorg-x11-drv-evdev-2.0.7-1.fc10.i386

You seem to have mixed up the version. Which one did you mean, again?
And what's the bug report number in bugzilla for your problem? Just
posting about it here won't help you.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From nicolas.mailhot at laposte.net  Sat Oct 18 20:06:08 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 18 Oct 2008 22:06:08 +0200
Subject: Sendmail still default?
In-Reply-To: <48FA2C3A.2060003@gmail.com>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud> <48FA16D3.5020204@gmail.com>
	<1224351036.11070.11.camel@arekh.okg>  <48FA2C3A.2060003@gmail.com>
Message-ID: <1224360368.12428.2.camel@arekh.okg>

Le samedi 18 octobre 2008 ? 13:34 -0500, Les Mikesell a ?crit :

> You seem to have missed the sea change.

I didn't notice the "sea change" changing anything about sendmail's
terrible monolithic architecture.

And again, upstream seems more convinced than you are about current
sendmail's irremediable faults.

-- 
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/20081018/79daddef/attachment.sig>

From kwhiskerz at gmail.com  Sat Oct 18 20:22:27 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Sat, 18 Oct 2008 14:22:27 -0600
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
References: <gdd1je$i7l$1@ger.gmane.org>
	<20081018195808.GA10897@mokona.greysector.net>
Message-ID: <gddgi3$fo$1@ger.gmane.org>

Dominik 'Rathann' Mierzejewski wrote:

> You seem to have mixed up the version. Which one did you mean, again?

I did. See the next message.

> And what's the bug report number in bugzilla for your problem? Just
> posting about it here won't help you.

Wishful thinking. I was hoping it would be that easy and someone would magically come up with the solution. I did file a bug report in the end: 467573.



From drago01 at gmail.com  Sat Oct 18 20:30:01 2008
From: drago01 at gmail.com (drago01)
Date: Sat, 18 Oct 2008 22:30:01 +0200
Subject: text-to-speech doesn't work
In-Reply-To: <gdbd1f$r8e$1@ger.gmane.org>
References: <gdbd1f$r8e$1@ger.gmane.org>
Message-ID: <f6ca9fed0810181330gf1e6c16r67b499ac266d520d@mail.gmail.com>

On Sat, Oct 18, 2008 at 3:10 AM, kwhiskerz <kwhiskerz at gmail.com> wrote:
> I am using Fedora release 9.92 (Rawhide). For some time now, likely late in Fedora 8, or during Fedora 9, text-to-speech ceased to work. This applies to both festival and espeak.
>
> festival --tts file.txt
> espeak -f file.txt --punct=""
>
> Neither gives any audible output. The programs just run indefinitely and nothing happens.
>

because they use OSS ... prepend padsp to the commands and they should work.



From skvidal at fedoraproject.org  Sat Oct 18 20:32:17 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 18 Oct 2008 20:32:17 +0000
Subject: private group administration
In-Reply-To: <20081018162535.GJ27052@angus.ind.WPI.EDU>
References: <48F87E69.7040409@redhat.com> <gdb9ls$kop$1@ger.gmane.org>
	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>
	<200810180845.15175.opensource@till.name>
	<faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
	<1224341585.21581.113.camel@rosebud>
	<20081018162535.GJ27052@angus.ind.WPI.EDU>
Message-ID: <1224361937.21581.121.camel@rosebud>

On Sat, 2008-10-18 at 12:25 -0400, Chuck Anderson wrote:
> On Sat, Oct 18, 2008 at 10:53:05AM -0400, seth vidal wrote:
> > On Sat, 2008-10-18 at 10:40 -0400, Colin Walters wrote:
> > > 2008/10/18 Till Maas <opensource at till.name>:
> > > > On Sat October 18 2008, Colin Walters wrote:
> > > >> On Fri, Oct 17, 2008 at 8:12 PM, Matthew Woehlke
> > > >>
> > > >> <mw_triad at users.sourceforge.net> wrote:
> > > >> > If 'chmod g+w file;chgrp foo file' is too much work then there should be
> > > >> > a command that can do both.
> > > >>
> > > >> Groups are broken.  Use access control lists: "man setfacl"
> > > >
> > > > ACLs inherit the brokenness of groups, e.g. it is not possible to enforce that
> > > > everything within a certain directory is owned by everyone of a group,
> > > 
> > > The point is with ACLs you don't need the files to have a specific
> > > ownership (user/group) as long as they have the right ACLs for access.
> > >  A good way to do this is to avoid groups entirely and just add the
> > > users you want individually.
> > 
> > If there are enough people working on a project this does not scale.
> 
> Right, with groups you can have files inherit the group from the 
> directory they are in.  Is there any inheritance with ACLs?

It's not about inheritance. It is about the number of individuals with
permissions before things start to become cumbersome to manage.

-sv




From pertusus at free.fr  Sat Oct 18 20:32:27 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 18 Oct 2008 22:32:27 +0200
Subject: PackageKit soon to include the QPackageKit library, need advice
In-Reply-To: <1224359517.29507.46.camel@hughsie-laptop>
References: <1224359517.29507.46.camel@hughsie-laptop>
Message-ID: <20081018203226.GB2656@free.fr>

On Sat, Oct 18, 2008 at 08:51:57PM +0100, Richard Hughes wrote:
> 
> Now we have two libraries (soon to be three), I'm intending to rename:
> 
> PackageKit-libs  -> PackageKit-libs-glib
> PackageKit-devel -> PackageKit-glib-devel

I'd personnally have put all the devel bits in PackageKit-devel, fine
granularity is not very important for devel packages, only for runtime,
in my opinion. And then runtime bits would be called without the libs
part, like:

PackageKit-glib
PackageKit-qt

--
Pat



From skvidal at fedoraproject.org  Sat Oct 18 20:34:37 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 18 Oct 2008 20:34:37 +0000
Subject: Sendmail still default?
In-Reply-To: <48FA16D3.5020204@gmail.com>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud>  <48FA16D3.5020204@gmail.com>
Message-ID: <1224362077.21581.123.camel@rosebud>

On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:

> And did anyone have an actual problem with sendmail other than noticing 
> it taking time to start the daemon in the boot sequence.  That's a 
> problem that can be solved on its own since you don't really need a 
> daemon then.
> 
> Removing mail from the expected services is just the wrong thing to do, 
> especially if the reasoning is that the service isn't understood or used 
> to advantage.  Add a setup for a root alias in firstboot and a mail 
> notifier in the gnome panel to make the system more useful instead of less.
> 

I never said anything about removing mail. I only said that making
postfix the default doesn't mean losing functionality.

Personally, I'm in favor of changing it just to see what shakes out that
we've forgotten or missed.

-sv




From jreiser at BitWagon.com  Sat Oct 18 20:36:09 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Sat, 18 Oct 2008 13:36:09 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <20081018180857.GK27052@angus.ind.WPI.EDU>
References: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>	<1224352773.4219.3.camel@luminos.localdomain>
	<20081018180857.GK27052@angus.ind.WPI.EDU>
Message-ID: <48FA48B9.9040207@BitWagon.com>

>> Fedora would distribute one piece of media.  You would either boot from
>> it and install, or you would mount it (loop back) and burn the CD sized
>> isos held within, to boot from those and install from them.

> Bonus points if you can figure out how to make the DVD multi-session 
> so that all the files from inside the embedded CD iso's show up as 
> regular files in the DVD :-)

Using multi-session recording of the DVD is not necessary.  As long as
you require loop-back mount, then you've got shell, cat, and dd.  So the
CD images can be constructed from files within a single-session DVD
by using one shell script per output platter:

      cat <leading-sectors> <directory-info> <file-list> \
   |  dd bs=32k of=/dev/cdrw

where <directory-info> is a file containing the directory portion of
the appropriate mkisofs.

-- 



From skvidal at fedoraproject.org  Sat Oct 18 20:39:01 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 18 Oct 2008 20:39:01 +0000
Subject: The Big ACL Opening
In-Reply-To: <48FA1837.8010009@gmail.com>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
	<20081017223126.GH27444@angus.ind.WPI.EDU>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224306428.21581.108.camel@rosebud>  <48FA1837.8010009@gmail.com>
Message-ID: <1224362341.21581.127.camel@rosebud>

On Sat, 2008-10-18 at 10:09 -0700, Toshio Kuratomi wrote:
> seth vidal wrote:
> > On Sat, 2008-10-18 at 00:51 -0400, Paul W. Frields wrote:
> >> On Fri, 2008-10-17 at 18:31 -0400, Chuck Anderson wrote:
> >>> On Fri, Oct 17, 2008 at 03:54:25PM -0600, Stephen John Smoogen wrote:
> >>>> On Fri, Oct 17, 2008 at 3:01 PM, Alan Cox <alan at redhat.com> wrote:
> >>>>>> FWIW, I really don't care, and am fine with uberpackager, ultrapacakger,
> >>>>>> and superpackager.
> >>>>> Super is probably sane enough but English has a long and distinguished
> >>>>> history of stealing other peoples words and using them wrongly so uber- in
> >>>>> English [ab]use is not atypical ;)
> >>>>>
> >>>> or adding them together... super-ultra-ginormous packager.
> >>>>
> >>>> super was used a lot so it was no longer super. I think that is when
> >>>> Ultra was the new super.. Uber was the 80's new Super since it 'should
> >>>> have' umlauts like any 'proper' Germanic word. I mean how else can you
> >>>> have a rock band name without umlauts.  I think gi-normous  is the
> >>>> current generations super...
> >>> How about a more neutral term?
> >>>
> >>> experiencedpackager
> >>> trustedpackager
> >>>
> >>> Here's some that imply scope rather than "l33tness"? (no, lets not use 
> >>> l33tpackager as fun as it sounds).  Since those packagers can touch 
> >>> (almost) all packages how about:
> >>>
> >>> globalpackager
> >>> universepackager
> >>> everypackager
> >> "Allpackager," kind of like "allspice."
> >>
> > 
> > OdinPackager? 
> > WednesdayPackager?
> > 
> Okay but then I insist on renaming the intro level Packager group to
> PugsleyPackager. :-)


Oh my god, we've tangentially referenced three cultural concepts away:

Allpackager -> all father (by pun)
all father -> odin (by norse pantheon)
odin -> wodin (nick name)
wodin -> wednesday (nick name)
wednesday -> pugsley (addams family)

our ability to make subtle references that even we eventually don't
understand kicks ass. :)

-sv





From lesmikesell at gmail.com  Sat Oct 18 20:44:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 18 Oct 2008 15:44:59 -0500
Subject: Sendmail still default?
In-Reply-To: <1224360368.12428.2.camel@arekh.okg>
References: <48F87794.3090108@redhat.com>
	<gdb9bj$jc9$2@ger.gmane.org>	<1224341699.21581.115.camel@rosebud>
	<48FA16D3.5020204@gmail.com>	<1224351036.11070.11.camel@arekh.okg>
	<48FA2C3A.2060003@gmail.com> <1224360368.12428.2.camel@arekh.okg>
Message-ID: <48FA4ACB.7060604@gmail.com>

Nicolas Mailhot wrote:
> Le samedi 18 octobre 2008 ? 13:34 -0500, Les Mikesell a ?crit :
> 
>> You seem to have missed the sea change.
> 
> I didn't notice the "sea change" changing anything about sendmail's
> terrible monolithic architecture.

How are separate processes receiving to a queue, processing the queue, 
delivering locally, with any number of concurrent milters all running 
under potentially different non-root id's except for the operations that 
require it, monolithic?

> And again, upstream seems more convinced than you are about current
> sendmail's irremediable faults.

The remedy was done years ago.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Sat Oct 18 20:50:15 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 18 Oct 2008 15:50:15 -0500
Subject: Sendmail still default?
In-Reply-To: <1224362077.21581.123.camel@rosebud>
References: <48F87794.3090108@redhat.com>
	<gdb9bj$jc9$2@ger.gmane.org>	<1224341699.21581.115.camel@rosebud>
	<48FA16D3.5020204@gmail.com> <1224362077.21581.123.camel@rosebud>
Message-ID: <48FA4C07.6010304@gmail.com>

seth vidal wrote:
> On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
> 
>> And did anyone have an actual problem with sendmail other than noticing 
>> it taking time to start the daemon in the boot sequence.  That's a 
>> problem that can be solved on its own since you don't really need a 
>> daemon then.
>>
>> Removing mail from the expected services is just the wrong thing to do, 
>> especially if the reasoning is that the service isn't understood or used 
>> to advantage.  Add a setup for a root alias in firstboot and a mail 
>> notifier in the gnome panel to make the system more useful instead of less.
>>
> 
> I never said anything about removing mail. I only said that making
> postfix the default doesn't mean losing functionality.

It would have been earlier, but if in fact the current version is 
capable of running MimeDefang as a milter maybe they are finally equivalent.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From skvidal at fedoraproject.org  Sat Oct 18 20:57:07 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 18 Oct 2008 20:57:07 +0000
Subject: Sendmail still default?
In-Reply-To: <48FA4C07.6010304@gmail.com>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud> <48FA16D3.5020204@gmail.com>
	<1224362077.21581.123.camel@rosebud>  <48FA4C07.6010304@gmail.com>
Message-ID: <1224363427.21581.130.camel@rosebud>

On Sat, 2008-10-18 at 15:50 -0500, Les Mikesell wrote:
> seth vidal wrote:
> > On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
> > 
> >> And did anyone have an actual problem with sendmail other than noticing 
> >> it taking time to start the daemon in the boot sequence.  That's a 
> >> problem that can be solved on its own since you don't really need a 
> >> daemon then.
> >>
> >> Removing mail from the expected services is just the wrong thing to do, 
> >> especially if the reasoning is that the service isn't understood or used 
> >> to advantage.  Add a setup for a root alias in firstboot and a mail 
> >> notifier in the gnome panel to make the system more useful instead of less.
> >>
> > 
> > I never said anything about removing mail. I only said that making
> > postfix the default doesn't mean losing functionality.
> 
> It would have been earlier, but if in fact the current version is 
> capable of running MimeDefang as a milter maybe they are finally equivalent.
> 

for a couple of years now:

http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/

-sv




From mclasen at redhat.com  Sat Oct 18 21:02:35 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 18 Oct 2008 17:02:35 -0400
Subject: text-to-speech doesn't work
In-Reply-To: <f6ca9fed0810181330gf1e6c16r67b499ac266d520d@mail.gmail.com>
References: <gdbd1f$r8e$1@ger.gmane.org>
	<f6ca9fed0810181330gf1e6c16r67b499ac266d520d@mail.gmail.com>
Message-ID: <1224363755.3319.1.camel@localhost.localdomain>

On Sat, 2008-10-18 at 22:30 +0200, drago01 wrote:
> On Sat, Oct 18, 2008 at 3:10 AM, kwhiskerz <kwhiskerz at gmail.com> wrote:
> > I am using Fedora release 9.92 (Rawhide). For some time now, likely late in Fedora 8, or during Fedora 9, text-to-speech ceased to work. This applies to both festival and espeak.
> >
> > festival --tts file.txt
> > espeak -f file.txt --punct=""
> >
> > Neither gives any audible output. The programs just run indefinitely and nothing happens.
> >
> 
> because they use OSS ... prepend padsp to the commands and they should work.
> 

festival can be made to work with alsa and/or PA by adding 

(Parameter.set 'Audio_Command "aplay $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
(Parameter.set 'Audio_Required_Format 'snd)


to /etc/festival/siteinit.scm. I've filed a bug to get this into the
package before F10.



From lesmikesell at gmail.com  Sat Oct 18 21:02:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 18 Oct 2008 16:02:28 -0500
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <20081018180857.GK27052@angus.ind.WPI.EDU>
References: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>	<1224352773.4219.3.camel@luminos.localdomain>
	<20081018180857.GK27052@angus.ind.WPI.EDU>
Message-ID: <48FA4EE4.6050503@gmail.com>

Chuck Anderson wrote:
> On Sat, Oct 18, 2008 at 10:59:33AM -0700, Jesse Keating wrote:
>> On Sat, 2008-10-18 at 19:52 +0200, Stefan Hartsuiker wrote:
>>> I know and that was not the reason for my confusion :)
>>> What I understood from Till's first sentence above, is that he would like a
>>> dvd that has a bootloader that can use the enclosed cd iso's as an
>>> installation source. This then would imply that it only works if the system
>>> can actually already boot from the dvd? Therefore it seems to me a bit
>>> pointless.
>> Fedora would distribute one piece of media.  You would either boot from
>> it and install, or you would mount it (loop back) and burn the CD sized
>> isos held within, to boot from those and install from them.
> 
> Bonus points if you can figure out how to make the DVD multi-session 
> so that all the files from inside the embedded CD iso's show up as 
> regular files in the DVD :-)

So the bootable chunk is like boot.iso which automatically mounts the 
rest of the dvd if present or lets you look elsewhere (like the nfs 
install) if not?  Will this also work if you copy the image to a 
suitably sized bootable USB drive?  The missing piece would be how you 
create the individual CD's if you download from Windows and can't use a 
DVD.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From andrewparker at bigfoot.com  Sat Oct 18 21:05:11 2008
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Sat, 18 Oct 2008 17:05:11 -0400
Subject: The Big ACL Opening
In-Reply-To: <loom.20081018T173644-863@post.gmane.org>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<loom.20081018T173644-863@post.gmane.org>
Message-ID: <6c3f5e6c0810181405j6662dc48m7330bd8df55357a4@mail.gmail.com>

On Sat, Oct 18, 2008 at 1:39 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Lennart Poettering <mzerqung <at> 0pointer.de> writes:
>> Hmm, am I the only one who finds the choice of the term "?berpackager"
>> a bit questionnable?
>
> No, you aren't. I also consider the "uberpackager" name to be stupid due to the
> connotations that term has picked up, +1 for renaming it to "superpackager".

the english usage of uber does not have those connotations.

http://www.merriam-webster.com/dictionary/uber

perhaps red hat should be renamed due to the atrocities performed by
the khmer rouge?



From rdieter at math.unl.edu  Sat Oct 18 21:11:50 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sat, 18 Oct 2008 16:11:50 -0500
Subject: PackageKit soon to include the QPackageKit library, need advice
References: <1224359517.29507.46.camel@hughsie-laptop>
Message-ID: <gddjdq$96a$1@ger.gmane.org>

Richard Hughes wrote:

> Upstream the PackageKit-Qt library binding has been merged into the
> PackageKit scm and will be in the next release tarball. This allows us
> to keep the libraries in sync and also means QPackageKit gets a lot of
> the love that PackageKit gets.

Excellent news!

> Now we have two libraries (soon to be three), I'm intending to rename:
> PackageKit-libs  -> PackageKit-libs-glib
> PackageKit-devel -> PackageKit-glib-devel
> This allows us to create PackageKit-libs-qt and PackageKit-qt-devel and
> then provide this for other QT and KDE applications to trivially build
> against.

I concur with drago01, and would personally opt for names of the form PackageKit-glib(-devel) and PackageKit-qt(-devel), but whatever floats your boat.

-- Rex



From lesmikesell at gmail.com  Sat Oct 18 21:13:39 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 18 Oct 2008 16:13:39 -0500
Subject: Sendmail still default?
In-Reply-To: <1224363427.21581.130.camel@rosebud>
References: <48F87794.3090108@redhat.com>
	<gdb9bj$jc9$2@ger.gmane.org>	<1224341699.21581.115.camel@rosebud>
	<48FA16D3.5020204@gmail.com>	<1224362077.21581.123.camel@rosebud>
	<48FA4C07.6010304@gmail.com> <1224363427.21581.130.camel@rosebud>
Message-ID: <48FA5183.1020407@gmail.com>

seth vidal wrote:
>
>>>> And did anyone have an actual problem with sendmail other than noticing 
>>>> it taking time to start the daemon in the boot sequence.  That's a 
>>>> problem that can be solved on its own since you don't really need a 
>>>> daemon then.
>>>>
>>>> Removing mail from the expected services is just the wrong thing to do, 
>>>> especially if the reasoning is that the service isn't understood or used 
>>>> to advantage.  Add a setup for a root alias in firstboot and a mail 
>>>> notifier in the gnome panel to make the system more useful instead of less.
>>>>
>>> I never said anything about removing mail. I only said that making
>>> postfix the default doesn't mean losing functionality.
>> It would have been earlier, but if in fact the current version is 
>> capable of running MimeDefang as a milter maybe they are finally equivalent.
>>
> 
> for a couple of years now:
> 
> http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
> 

Supporting the milter interface and actually running existing milters 
that expect sendmail on the other side are two different things.  For 
example, milters may need to know if the connection is authenticated or 
using SSL.  If you are going to claim sendmail compatibility or be a 
functional replacement you have to provide the same information, the 
same way whether it was described in the interface documentation or not. 
Postfix pre-2.4 didn't.  It looks like it does now, but I still don't 
remember any mentions of people actually using it on the MimeDefang
list.

And in any case, using MimeDefang as a sendmail milter eliminates most 
of the complaints anyone would have with sendmail itself since it lets 
you do the complex parts with control handled in perl instead of 
sendmail's internal language.


-- 
    Les Mikesell
     lesmikesell at gmail.com



From vonbrand at inf.utfsm.cl  Sat Oct 18 01:18:16 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 17 Oct 2008 22:18:16 -0300
Subject: The Big ACL Opening
In-Reply-To: <200810172040.57322.ville.skytta@iki.fi>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
Message-ID: <200810180118.m9I1IGD9014639@laptop14.inf.utfsm.cl>

Ville Skytt?? <ville.skytta at iki.fi> wrote:
> On Friday 17 October 2008, Lennart Poettering wrote:
> > Also, "Ultra" means "beyond" while "Super" means "above", IIRC. Super
> > hence appears more appropriate to me here, and less extreme. But
> > that's just me.

> Nope, me too.

I also prefer superpackager
-- 
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 2340000       Fax:  +56 32 2797513



From kwhiskerz at gmail.com  Sat Oct 18 23:24:28 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Sat, 18 Oct 2008 17:24:28 -0600
Subject: text-to-speech doesn't work
References: <gdbd1f$r8e$1@ger.gmane.org> <20081018185757.GA12113@jadzia.bu.edu>
Message-ID: <gddr7e$ug$1@ger.gmane.org>

Well, that's a step in the right direction. I didn't try editing the configuration file, but I did prepend padsp to the commands.

Result:
padsp espeak -f file.txt does not work
padsp festival --tts file.txt does work (but not within kttsd, only on the command line)

Although festival within kttsd is of the utmost importance, it would be nice, were espeak to work, too, as it is able to make use of the mbrola voices, enabling rendering of French and German, too.



From kwhiskerz at gmail.com  Sat Oct 18 23:39:11 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Sat, 18 Oct 2008 17:39:11 -0600
Subject: text-to-speech doesn't work
References: <gdbd1f$r8e$1@ger.gmane.org> <20081018185757.GA12113@jadzia.bu.edu>
	<gddr7e$ug$1@ger.gmane.org>
Message-ID: <gdds30$312$1@ger.gmane.org>

OK. Now, I did edit the festival config file. The result:

I no longer need to prepend padsp to festival --tts file.txt. However, it still won't work in kttsd.



From promac at gmail.com  Sun Oct 19 01:32:47 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sat, 18 Oct 2008 22:32:47 -0300
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <68720af30810171856ucad1d58ufc5ca16b28d81378@mail.gmail.com>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
	<68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
	<27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>
	<26499.198.175.55.5.1224256924.squirrel@mail.jcomserv.net>
	<68720af30810171856ucad1d58ufc5ca16b28d81378@mail.gmail.com>
Message-ID: <68720af30810181832h1439d931qb687edc23aa23c7e@mail.gmail.com>

On Fri, Oct 17, 2008 at 10:56 PM, Paulo Cavalcanti <promac at gmail.com> wrote:

>
>
> On Fri, Oct 17, 2008 at 12:22 PM, Jon Ciesla <limb at jcomserv.net> wrote:
>
>>
>> >
>> >> On Mon, Oct 13, 2008 at 2:48 PM, KH KH <kwizart at gmail.com> wrote:
>> >>
>> >>> 2008/10/13 Jon Ciesla <limb at jcomserv.net>:
>> >>> >
>> >>> >> Hi!
>> >>> >>
>> >>> >> As announced at http://www.yafray.org, yafaray replaces YafRay
>> >>> 0.0.9.
>> >>> >> Thus I'm thinking of submitting yafray as dead.package in Rawhide.
>> >>> (1)
>> >>> >>
>> >>> >> On the other side, I'm not going to work on yafaray soon. So, if
>> >>> anyone
>> >>> >> wants to start working on it, feel free.
>> >>> >>
>> >>> >> Nicolas (kwizart)
>> >>> >>
>> >>> >>
>> >>> >> (1), There is no reason why yafray should stop working with the
>> >>> current
>> >>> >> blender releases. But there might be a problem when theses two are
>> >>> >> installed together. (until now, blender either dlopen library or
>> >>> call
>> >>> >> binary, from yafray).
>> >>> >> This has to be discussed in the yafaray review. So, please cc'ed me
>> >>> on
>> >>> >> the review, along with your favorite reviewer. (or ask me as a
>> >>> reviewer).
>> >>> >
>> >>> > I may just do that.  One thing though, am I blind or is there nor
>> >>> yafaray
>> >>> > tarball, and I'll have to work from a svn checkout?  (bleah)
>> >>> Yes, that's right.
>> >>> I think it will be appropriate to use a script to create one source
>> >>> tarball.
>> >>> Good luck !
>> >>>
>> >>>
>> >> I can give you an .src.rpm that builds fine for F8, including the QT
>> >> interface.
>> >>
>> >>
>> http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc8.src.rpm<http://people.atrpms.net/%7Epcavalcanti/srpms/yafaray-0.1.0-3.fc8.src.rpm>
>> >
>> > Thanks, I'll have a look, and see if I can rip-of^H^H^H^H^H^Hborrow from
>> > this to solve some of the issues I've run into so far.
>>
>> Hmm, on F-9:
>>
>> scons: done building targets.
>> + sed -i -es,/var/tmp/yafaray-0.1.0-buildroot,,g
>> /var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafaraycore.so
>> + /usr/lib/rpm/find-debuginfo.sh /home/limb/rpmbuild/BUILD/yafaray
>> extracting debug info from
>> /var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafarayqt.so
>> extracting debug info from
>> /var/tmp/yafaray-0.1.0-buildroot/usr/lib/libyafaraycore.so
>> Failed to write file: invalid section alignment
>> error: Bad exit status from /var/tmp/rpm-tmp.80705 (%install)
>>
>>
>>
> The problem is that  check-buildroot is
> accusing  "%{buildroot}"  in libyafaraycore.so
>
> I just erased the reference to %{buildroot} from the library to
> be able to get an rpm. F9 seems to have a more strict check.
>
> This was the only problem I got, and it needs a better solution.
>
>
>

Well, I fixed it:

http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc9.src.rpm

It builds just fine in F9 now.

I hope it can help you.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081018/54b24166/attachment.htm>

From james at fedoraproject.org  Sun Oct 19 03:37:23 2008
From: james at fedoraproject.org (James Antill)
Date: Sat, 18 Oct 2008 23:37:23 -0400
Subject: Sendmail still default?
In-Reply-To: <48FA5183.1020407@gmail.com>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud> <48FA16D3.5020204@gmail.com>
	<1224362077.21581.123.camel@rosebud> <48FA4C07.6010304@gmail.com>
	<1224363427.21581.130.camel@rosebud>  <48FA5183.1020407@gmail.com>
Message-ID: <1224387443.15123.20.camel@code.and.org>

On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
> seth vidal wrote:

> > for a couple of years now:
> > 
> > http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
> > 
> 
> Supporting the milter interface and actually running existing milters 
> that expect sendmail on the other side are two different things.  For 
> example, milters may need to know if the connection is authenticated or 
> using SSL.  If you are going to claim sendmail compatibility or be a 
> functional replacement you have to provide the same information, the 
> same way whether it was described in the interface documentation or not. 
> Postfix pre-2.4 didn't.  It looks like it does now, but I still don't 
> remember any mentions of people actually using it on the MimeDefang
> list.

 So? We aren't talking about auto migrating people's existing sendmail
deployments, which would require a higher level of compatibility.
 We are just talking about changing the default, to one which the
majority of users are likely to prefer (I appreciate that you have a
different preference, but even you must realize you are in a minority).

> And in any case, using MimeDefang as a sendmail milter eliminates most 
> of the complaints anyone would have with sendmail itself since it lets 
> you do the complex parts with control handled in perl instead of 
> sendmail's internal language.

 Again, that would be your opinion ... and it is different to mine.

-- 
James Antill <james at fedoraproject.org>
Fedora



From james.antill at redhat.com  Sun Oct 19 03:58:42 2008
From: james.antill at redhat.com (James Antill)
Date: Sat, 18 Oct 2008 23:58:42 -0400
Subject: Sendmail still default?
In-Reply-To: <48FA2C3A.2060003@gmail.com>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud> <48FA16D3.5020204@gmail.com>
	<1224351036.11070.11.camel@arekh.okg>  <48FA2C3A.2060003@gmail.com>
Message-ID: <1224388722.15123.40.camel@code.and.org>

On Sat, 2008-10-18 at 13:34 -0500, Les Mikesell wrote:

> Sendmail was a poor default back when it always ran everything as root 
> and accepted and delivered in the same process.  Maybe you didn't notice 
> that has changed or the enforced separation of the queuing and delivery 
> steps.

 There is a significant difference between dropping privileges from one
giant piece of code, and having exec boundaries that do separate tasks.
Without arguing the more nuanced differences, one obvious and simple
(and beneficial) difference is that SELinux can easily confine into
separate domains on exec boundaries. Which is why everything is lumped
into one sendmail_t, while postfix has a number of separate domains.

> > As an engineer who likes neat technical stuff and contributes to Fedora
> > because it tends to produce neat technical stuff it makes me cringe each
> > time I'm reminded we ship sendmail instead of something properly
> > designed for an untrusted TCP/IP network world.
> 
> Ummm, when was the last time you saw a network exploit for sendmail?

 There has been at least one remote buffer overflow in sendmail since
postfix went 1.0.

> > You may extend years of hole-fixing and patch a sieve enough it sort of
> > floats but it's still a poor excuse of a boat. Even if passengers only
> > see the "it floats" bit.
> 
> You seem to have missed the sea change.

 Probably, because most of us were already using something better before
sendmail decided to do the minimum of fixes to it's code base.

>   And the capabilities added by 
> the milter interface that it took the other contenders many years to 
> duplicate properly.

 Yes, sendmail has always had "more features" in that it was the first
MTA to have a turing complete language embedded within it (and an awful
one at that).
 But other MTAs have had the features everyone needs for a long time
now, and postfix has been a better default for more than long enough for
us to change it.


 I'd also like to say that personally I still use exim, and I'm likely
to continue to do so ... but I'm more than happy to see postfix as the
default, because it's probably a better default than exim and an
obviously better one than the current default.

-- 
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/20081018/61318395/attachment.sig>

From Axel.Thimm at ATrpms.net  Sun Oct 19 06:38:26 2008
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 19 Oct 2008 09:38:26 +0300
Subject: The Big ACL Opening
In-Reply-To: <1224351482.4219.0.camel@luminos.localdomain>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
	<1224351482.4219.0.camel@luminos.localdomain>
Message-ID: <20081019063826.GA27271@victor.nirvana>

On Sat, Oct 18, 2008 at 10:38:02AM -0700, Jesse Keating wrote:
> On Sat, 2008-10-18 at 10:01 +0100, Christopher Brown wrote:
> > 
> > It would be nice to have something a bit more ... interesting. In
> > Japan, they wrap gifts in cloths called "furoshiki" so perhaps
> > furoshiki-packager?
> 
> Wait wait, I know, kamikazepackager !  We swoop in like a divine wind
> and fix all the problems!

Make that a ninjapackager, otherwise we only fix one big problem and
then we're gone (but we get high honours and our family a lifetime
pension ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081019/c401a811/attachment.sig>

From peter.hutterer at who-t.net  Sun Oct 19 06:56:23 2008
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Sun, 19 Oct 2008 17:26:23 +1030
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
In-Reply-To: <gdd1je$i7l$1@ger.gmane.org>
References: <gdd1je$i7l$1@ger.gmane.org>
Message-ID: <20081019065623.GA14426@who-t.net>

On Sat, Oct 18, 2008 at 10:07:10AM -0600, kwhiskerz wrote:
> evdev driver 7.0.1-2 makes keyboard input impossible. All key-presses are done in triplicate, including backspace, so it is impossible to correct the erroneous input.

http://who-t.blogspot.com/2008/10/new-keyboard-configuration-handling.html

Are you running xorg-x11-server-Xorg-1.5.2-5? Should have been pulled in by
the Requires.

If so, I would like to see your xorg.conf please, because I thought I covered
all cases that would lead to duplicate events.

Cheers,
  Peter



From gbillios at gmail.com  Sun Oct 19 08:20:19 2008
From: gbillios at gmail.com (George Billios)
Date: Sun, 19 Oct 2008 11:20:19 +0300
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
In-Reply-To: <20081019065623.GA14426@who-t.net>
References: <gdd1je$i7l$1@ger.gmane.org> <20081019065623.GA14426@who-t.net>
Message-ID: <48FAEDC3.2000101@gmail.com>



-------- Original Message  --------
Subject: Re:xorg-x11-drv-evdev-7.0.1-2 bad!
From: Peter Hutterer <peter.hutterer at who-t.net>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: Sun 19 Oct 2008 09:56:23 EEST

> On Sat, Oct 18, 2008 at 10:07:10AM -0600, kwhiskerz wrote:
>> evdev driver 7.0.1-2 makes keyboard input impossible. All key-presses are done in triplicate, including backspace, so it is impossible to correct the erroneous input.
> 
> http://who-t.blogspot.com/2008/10/new-keyboard-configuration-handling.html
> 
> Are you running xorg-x11-server-Xorg-1.5.2-5? Should have been pulled in by
> the Requires.
> 
> If so, I would like to see your xorg.conf please, because I thought I covered
> all cases that would lead to duplicate events.
> 
> Cheers,
>   Peter
> 


I will also send you mine by email because I was hit by the same problem
even if the updated xorg-x11-server-Xorg was installed.

In the mean time I would advice to reverse back to the old behaviour,
since it is way to close to the F10 release to do these kind of changes.



From llange at redhat.com  Sun Oct 19 09:11:11 2008
From: llange at redhat.com (Lutz Lange)
Date: Sun, 19 Oct 2008 11:11:11 +0200
Subject: private group administration
In-Reply-To: <48FA14EB.4050004@gmail.com>
References: <48F87E69.7040409@redhat.com>	<gdb9ls$kop$1@ger.gmane.org>	<faa16b610810171721u71fe6ce2ibf1c354f2aecea85@mail.gmail.com>	<200810180845.15175.opensource@till.name>	<faa16b610810180740n72cb6dd8w55fdb93cc43dc2c6@mail.gmail.com>
	<48FA14EB.4050004@gmail.com>
Message-ID: <48FAF9AF.7060008@redhat.com>

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

Les Mikesell schrieb:
> Colin Walters wrote:
>>
>>>> <mw_triad at users.sourceforge.net> wrote:
>>>>> If 'chmod g+w file;chgrp foo file' is too much work then there
>>>>> should be
>>>>> a command that can do both.
>>>> Groups are broken.  Use access control lists: "man setfacl"
>>> ACLs inherit the brokenness of groups, e.g. it is not possible to
>>> enforce that
>>> everything within a certain directory is owned by everyone of a group,
>>
>> The point is with ACLs you don't need the files to have a specific
>> ownership (user/group) as long as they have the right ACLs for access.
>>  A good way to do this is to avoid groups entirely and just add the
>> users you want individually.
> 
> This is unmanageable as the people in groups change.  When you are
> designing operating systems you should understand that underlying data
> and work processes may need to survive and be usable for decades as the
> hardware and people change. I don't think anyone working with fedora
> gets that.
> 

This is actually what students tell me as well. Using ACLs file
permissions are quite hard to manage over time. ACLs tend to stay on fs
entries when users get deleted. It is an extra burden on the admin to
search and remove them.

We should find a way to make it easier to maintain ACLs - especially in
case users are removed from the system. I'm sure a clean up script could
be devised for the case of user removal. This would ease the process.

Or does such a script/program exist already?

Cheers
Lutz

- --
Lutz Lange
GLS Instructor
Red Hat GmbH
Hauptst?tterstrasse 58
D-70178 Stuttgart - Germany

Tel.    +49 711 96 437 570
Mobile  +49 172 75 285 17
Fax     +49 711 96 437 111
Email:  llange at redhat.com
____________________________________________________________________
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD4DBQFI+vms15TuH1mPaRURAn7zAKCBwHqPprQOGJWc2xJRJhrIqMqLuwCWMylQ
19l0a/9fYRp8bFBpobbR+A==
=F5JM
-----END PGP SIGNATURE-----



From peter.hutterer at who-t.net  Sun Oct 19 10:19:12 2008
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Sun, 19 Oct 2008 20:49:12 +1030
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
In-Reply-To: <48FAEDC3.2000101@gmail.com>
References: <gdd1je$i7l$1@ger.gmane.org> <20081019065623.GA14426@who-t.net>
	<48FAEDC3.2000101@gmail.com>
Message-ID: <20081019101912.GB6480@who-t.net>

On Sun, Oct 19, 2008 at 11:20:19AM +0300, George Billios wrote:
> I will also send you mine by email because I was hit by the same problem
> even if the updated xorg-x11-server-Xorg was installed.

Summary from our short email exchange:
If you have an xorg.conf that registers an evdev device, this device will now
produce duplicate events. For most setups, you probably don't need it in your
xorg.conf because HAL picks it up anyway. If you really do, add option
"GrabDevice" "true" and that'll restore the old grabbing behaviour.

> In the mean time I would advice to reverse back to the old behaviour,
> since it is way to close to the F10 release to do these kind of changes.

No. the old behaviour is too broken, and it's good that it's finally fixed.
"Macintosh mouse button emulation" and the keys that control volume, suspend,
etc. are broken in the old behaviour, and that's a quite serious regression
from F9.

Cheers,
  Peter



From rawhide at fedoraproject.org  Sun Oct 19 10:21:28 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 19 Oct 2008 10:21:28 +0000 (UTC)
Subject: rawhide report: 20081019 changes
Message-ID: <20081019102128.9199A1F823B@releng2.fedora.phx.redhat.com>

Compose started at Sun Oct 19 06:01:11 UTC 2008

New package perl-qooxdoo-compat
        Perl backend for Qooxdoo
New package teamgit
        Visual tool for Git
Updated Packages:

dietlibc-0.31-6.20081017.fc10
-----------------------------
* Sat Oct 18 18:00:00 2008 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.31-6.20081017
- updated to 20081017 CVS snapshot
- relaxed some sanity checks on architecture not supported by Fedora
  and use '#warning' instead of '#error'
- fixed ARM dynlib code

* Wed Jul 16 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.31-6.20080517
- fix license tag


eclipse-pydev-1.3.22-1.fc10
---------------------------

eclipse-quickrex-3.5.0-9.fc10
-----------------------------
* Sat Oct 11 18:00:00 2008 Alphonse Van Assche <alcapcom at fedoraproject.org> 3.5.0-9
- Remove gcj compilation
- Add %{install_loc}


eclipse-rpm-editor-0.4.0-5.fc10
-------------------------------
* Sat Oct 11 18:00:00 2008 Alphonse Van Assche <alcapcom at fedoraproject.org> 0.4.0-5
- Fix specfile

* Tue Oct  7 18:00:00 2008 Alphonse Van Assche <alcapcom at fedoraproject.org> 0.4.0-4
- Remove gcj compilation
- Add %{install_loc}


gdesklets-goodweather-0.31-1.fc10
---------------------------------
* Sat Aug  2 18:00:00 2008 Tyler Owen <tyler.l.owen at gmail.com> - 0.31-1
- Fixed license tag to specify a version
- Upgrade to 08-0.31

* Thu Nov 15 17:00:00 2007 Tyler Owen <tyler.l.owen at gmail.com> - 0.3-3
- Updated License to match new Fedora scheme
- Updated files section


gnash-0.8.4-2.fc10
------------------
* Sat Oct 18 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 0.8.4-1
- update to 0.8.4

* Sat Oct 18 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.8.4-2
- update KDE 4 patch (undo the backporting and use original patch)
- patch to make autoreconf work
- add missing BR giflib-devel, gettext
- omit unrecognized --with-qtdir


gnome-chemistry-utils-0.9.93-1.fc10
-----------------------------------
* Sat Oct 18 18:00:00 2008 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.9.93-1
- Updated to 0.9.93


hunspell-1.2.7-5.fc10
---------------------
* Sat Oct 18 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.2.7-5
- sort as per "C" locale


jd-2.0.3-0.1.svn2402_trunk.fc10
-------------------------------
* Sun Oct 19 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2402


kdebase-workspace-4.1.2-6.fc10
------------------------------
* Sat Oct 18 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-6
- reenable panel-autohide-fix-flicker patch
- backport revision 866998 to fix the CPU consumption problem (kde#172549)
- backport panelview.cpp coordinate fixes (revisions 869882, 869925, 870041)
- backport revision 871058 (request config sync when panel controller goes away)


kernel-2.6.27.3-27.rc1.fc10
---------------------------
* Fri Oct 17 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.3-27.rc1
- Linux 2.6.27.3-rc1
  Dropped patches:
    linux-2.6.27-xfs-remount-fix.patch

* Fri Oct 17 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.2-26.rc1
- Fix resume on x86_64 UP systems with SMP kernel.

* Fri Oct 17 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.2-25.rc1
- DRM: fix ioctl security issue (CVE-2008-3831).

* Fri Oct 17 18:00:00 2008 Adam Jackson <ajax at redhat.com> 2.6.27.2-24.rc1
- Fix suspend on newer Vaios


krusader-2.0.0-0.2.beta1.fc10
-----------------------------
* Sat Oct 18 18:00:00 2008 Marcin Garski <mgarski[AT]post.pl> 2.0.0-0.2.beta1
- Incorporate minor bug fixes from Krusader's SVN


mono-2.0-11.1.fc10
------------------
* Sat Oct 18 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-11.1
- fix the last fix...


mt-daapd-0.2.4.2-4.fc10
-----------------------
* Sat Oct 18 18:00:00 2008 W. Michael Petullo <mike[at]flyn.org> - 0.2.4.2-4
- Change initscript priority to 98, so that mt-daapd starts after avahi.


nfs-utils-1.1.4-1.fc10
----------------------
* Sat Oct 18 18:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-1
- Updated to latest upstream version: 1.1.4


nfs-utils-lib-1.1.4-1.fc10
--------------------------
* Sat Oct 18 18:00:00 2008 Steve Dickson <steved at redhat.com> 1.1.4-1
- Fixed a bad assumtion in nss code.


phpMyAdmin-3.0.0-1.fc10
-----------------------
* Sun Oct 19 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 3.0.0-1
- Upstream released 3.0.0


python-tidy-0.2-4.fc10
----------------------
* Sat Oct 18 18:00:00 2008 Terje Rosten <terjeros at phys.ntnu.no> - 0.2-4
- Not 64 bits clean, #467246, thanks to Jose Pedro Oliveira
  for report and patch.


rpm-4.6.0-0.rc1.2
-----------------
* Sun Oct 19 18:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- permit tab as macro argument separator (#467567)


shorewall-4.2.0-1.fc10
----------------------
* Sun Oct 12 18:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.0-1
- Update to version 4.2.0
- New sysv init files which are no longer maintained as patches, but as a 
  Fedora specific file


smb4k-0.10.1-1.fc10
-------------------
* Sat Oct 18 18:00:00 2008 Marcin Garski <mgarski[AT]post.pl> 0.10.1-1
- Update to 0.10.1


util-vserver-0.30.215-5.fc10
----------------------------
* Sat Oct 18 18:00:00 2008 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.30.215-5
- fixed build with recent rpm

* Mon Sep  8 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.30.215-4
- fix license tag

* Sat Apr 19 18:00:00 2008 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.30.215-3
- reenabled %check


wxsvg-1.0-0.9.b11.fc10
----------------------
* Fri Oct 17 18:00:00 2008 Stewart Adam <s.adam at diffingo.com> - 1.0-0.9.b11
- Update to 1.0b11


Summary:
Added Packages: 2
Removed Packages: 0
Modified Packages: 23
Broken deps for i386
----------------------------------------------------------
	python-basemap-0.99-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-grass-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-python-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	python-basemap-0.99-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	qgis-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	qgis-grass-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-grass-0.11.0-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	qgis-python-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
	qgis-python-0.11.0-2.fc10.x86_64 requires libgeos-3.0.0.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	python-basemap-0.99-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-grass-0.11.0-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-grass-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-python-0.11.0-2.fc10.ppc requires libgeos-3.0.0.so
	qgis-python-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	python-basemap-0.99-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-grass-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	qgis-python-0.11.0-2.fc10.ppc64 requires libgeos-3.0.0.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From philippe-f.carriere at wanadoo.fr  Sun Oct 19 10:26:17 2008
From: philippe-f.carriere at wanadoo.fr (Philippe Carriere)
Date: Sun, 19 Oct 2008 12:26:17 +0200
Subject: ehci-hcd patch for alsa-driver-1.0.18rc3 snd-usb-us122l module
Message-ID: <1224411982.4002.27.camel@pollux.mecaflu.ec-lyon.fr>

Hi,

I guess (and hope) you plan to soon integrate the last
alsa-driver-1.0.18rc3 modules. I alerted the alsa devel team
(http://mailman.alsa-project.org/pipermail/alsa-devel/2008-October/011349.html) that the usb ehci-hcd module has to patched in order to have snd-usb-us122l module (the driver for the Tascam US-122l, USB 2.0 soundcard) to work. Unfortunately, the corresponding patch is not yet integrated to linux kernel and is not scheduled until 2.6.28 or still later.

>From mid-june 2008, I provided, on my personal website, patched kernel
for Fedora 9 (including patched ehci-hcd and part of what became
alsa-driver-1.0.18rc3) under 2.6.25 and presently 2.6.26 kernel for
support of Tascam US-122L. Now, an official integration in Fedora would
be the better way for standart users.

So the first question is: do you plan to integrate alsa-driver-1.0.18rc3
modules and if so, when ?
The next question is: which way you imagine for integrating the ehci-hcd
patch ? Directly adding the patch in kernel packaging (as I do) or
providing an alternative module (I am not very usual with the method to
do so) ?

I enclose the patch I just successly tested with rawhide Fedora 10 beta.
Note that this version is almost the same than the one I sent to
alsa-devel, essentially fitting exactly the line numbering.

Regards

Phil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081019/b446bd45/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ehci-hcd-2.6.27.2-23.rc1.fc10.patch
Type: text/x-patch
Size: 5599 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081019/b446bd45/attachment.bin>

From alexl at users.sourceforge.net  Sun Oct 19 11:02:24 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sun, 19 Oct 2008 04:02:24 -0700
Subject: rawhide report: 20081018 changes
In-Reply-To: <ulod1ijgo3.fsf@allele2.eebweb.arizona.edu> (Alex Lancaster's
	message of "Sat\, 18 Oct 2008 04\:17\:48 -0700")
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
Message-ID: <yvskqsj1a7.fsf@allele2.eebweb.arizona.edu>

>>>>> "AL" == Alex Lancaster  writes:

[...]

>> Broken deps for i386
>> ----------------------------------------------------------
>> python-basemap-0.99-2.fc10.i386 requires libgeos-3.0.0.so
>> qgis-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
>> qgis-grass-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so
>> qgis-python-0.11.0-2.fc10.i386 requires libgeos-3.0.0.so

AL> Advance announcements of soname bumps on fedora-devel-list is
AL> especially important when we are getting close to the final
AL> freeze.

I took the liberty of rebuilding these two packages to fix the broken
deps:

python-basemap:
https://koji.fedoraproject.org/koji/buildinfo?buildID=66750

qgis:
https://koji.fedoraproject.org/koji/buildinfo?buildID=66749

Alex



From dominik at greysector.net  Sun Oct 19 11:09:37 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sun, 19 Oct 2008 13:09:37 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081019063826.GA27271@victor.nirvana>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
	<1224351482.4219.0.camel@luminos.localdomain>
	<20081019063826.GA27271@victor.nirvana>
Message-ID: <20081019110936.GA13514@mokona.greysector.net>

On Sunday, 19 October 2008 at 08:38, Axel Thimm wrote:
> On Sat, Oct 18, 2008 at 10:38:02AM -0700, Jesse Keating wrote:
> > On Sat, 2008-10-18 at 10:01 +0100, Christopher Brown wrote:
> > > 
> > > It would be nice to have something a bit more ... interesting. In
> > > Japan, they wrap gifts in cloths called "furoshiki" so perhaps
> > > furoshiki-packager?
> > 
> > Wait wait, I know, kamikazepackager !  We swoop in like a divine wind
> > and fix all the problems!
> 
> Make that a ninjapackager, otherwise we only fix one big problem and

And that's how we became spot's minions.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From opensource at till.name  Sun Oct 19 11:14:00 2008
From: opensource at till.name (Till Maas)
Date: Sun, 19 Oct 2008 13:14:00 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224286760.4142.46.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<200810180104.18321.opensource@till.name>
	<1224286760.4142.46.camel@luminos.localdomain>
Message-ID: <200810191314.20208.opensource@till.name>

On Sat October 18 2008, Jesse Keating wrote:
> On Sat, 2008-10-18 at 01:04 +0200, Till Maas wrote:
> > I have a probably crazy idea: How about composing the DVD iso using a
> > filesystem that contains the CD isos and a bootloader that can use the CD
> > isos as installation source? Then a little bit of space of the DVD iso
> > would be wasted and it would take a little more effort to burn only the
> > CD isos, but then only one torrent would be needed and everyone can
> > easily share bandwidth with everyone else.
>
> Split media installs (which that would result in for even the DVD case)
> has some interesting side-effects, that really hurt when trying to add
> external repos (particularly of updates) at install time.  I wouldn't
> want to force it upon everybody.

Would it be possible to not do a split media installation, but to configure 
the kernel to allow more than 8 loop devices (if it is not already possible), 
to loop mount all CD iso images and to configure each as a seperate repo for 
anaconda, so that anaconda can access the contens of all iso images at once?

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/20081019/6e8a70f2/attachment.sig>

From opensource at till.name  Sun Oct 19 11:17:13 2008
From: opensource at till.name (Till Maas)
Date: Sun, 19 Oct 2008 13:17:13 +0200
Subject: private group administration
In-Reply-To: <1224354097.20129.1.camel@rlt60f8.laptop.redhat.com>
References: <48F87E69.7040409@redhat.com>
	<20081018162535.GJ27052@angus.ind.WPI.EDU>
	<1224354097.20129.1.camel@rlt60f8.laptop.redhat.com>
Message-ID: <200810191317.14475.opensource@till.name>

On Sat October 18 2008, Robert Locke wrote:
> On Sat, 2008-10-18 at 12:25 -0400, Chuck Anderson wrote:

> > Right, with groups you can have files inherit the group from the
> > directory they are in.  Is there any inheritance with ACLs?
>
> See 'setfacl d:' which can be used to set a "default" ACL on a directory
> so that all "newly created files" will inherit it....

But this does not work satisfactory all the times. Given you have a directory 
on one system that everybody within a certain groups should be able to access 
completely. Then you scp a file that is not group writable (e.g. from a cd) 
to it. Which default ACL for a group will makes the file writeable or 
chmodable for everyone from this group? Afaik there is no such ACL. The best 
approaches except giving everybody chmod/chown acces via sudo would be to 
mount vfat filesystem into the directory, because it accepts a gid/uid mount 
option to enforce a certain gid for all contents, or to use a fuse wrapper 
filesystem that manages the permissions, but I am not sure, whether this is 
possible or does already exist.

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/20081019/c85fde7b/attachment.sig>

From kwizart at gmail.com  Sun Oct 19 12:19:27 2008
From: kwizart at gmail.com (KH KH)
Date: Sun, 19 Oct 2008 14:19:27 +0200
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <68720af30810181832h1439d931qb687edc23aa23c7e@mail.gmail.com>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
	<68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
	<27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>
	<26499.198.175.55.5.1224256924.squirrel@mail.jcomserv.net>
	<68720af30810171856ucad1d58ufc5ca16b28d81378@mail.gmail.com>
	<68720af30810181832h1439d931qb687edc23aa23c7e@mail.gmail.com>
Message-ID: <e1760170810190519m4bbe150cre8e82bc5d7ddfb1f@mail.gmail.com>

2008/10/19 Paulo Cavalcanti <promac at gmail.com>:

>
> Well, I fixed it:
>
> http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc9.src.rpm
>
> It builds just fine in F9 now.
>
> I hope it can help you.
Hi Paulo!

I think this package should follow the usual package review process now.
It would be fine to close this topic, here on the mailing list, with
the bugzilla review request;
then, anyone can follow the conversation on the review.
But I think yafray and yafaray should co-exist for now.

Now, you will need to get sponsored for the package to be.
In the yafaray case, I would like to review it , as there is some
improvements required.
But your spec should be a good start.

Nicolas (kwizart)



From lsof at nodata.co.uk  Sun Oct 19 12:26:52 2008
From: lsof at nodata.co.uk (nodata)
Date: Sun, 19 Oct 2008 14:26:52 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224274237.4142.31.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>
	<1224274237.4142.31.camel@luminos.localdomain>
Message-ID: <1224419212.2948.6.camel@sb-home>

Am Freitag, den 17.10.2008, 13:10 -0700 schrieb Jesse Keating:
> On Fri, 2008-10-17 at 12:59 -0700, John Reiser wrote:
> > > Most torrent clients I've seen today allow you to pick and choose which
> > > files you wish to download.
> > 
> > The original bittorrent client does *NOT* have this feature.
> > 
> > -- 
> > 
> 
> Which one, the dead opensource one, or the continued closed source one?

The official one that many people still use.



From lsof at nodata.co.uk  Sun Oct 19 12:28:28 2008
From: lsof at nodata.co.uk (nodata)
Date: Sun, 19 Oct 2008 14:28:28 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224316251.26341.197.camel@localhost.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>  <48F8FD28.5070805@fedoraproject.org>
	<1224278235.21581.104.camel@rosebud>
	<1224316251.26341.197.camel@localhost.localdomain>
Message-ID: <1224419308.2948.9.camel@sb-home>

Am Samstag, den 18.10.2008, 02:50 -0500 schrieb Callum Lerwick:

> I'd suggest just biting the bullet, fire up a vncserver instance, and
> run Azureus. It is incredibly flexible 

What about users who don't want to install X just to download a file?

Azureus is also a resource hog. rtorrent uses far fewer resources.



From lsof at nodata.co.uk  Sun Oct 19 12:35:50 2008
From: lsof at nodata.co.uk (nodata)
Date: Sun, 19 Oct 2008 14:35:50 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <1224419750.2948.16.camel@sb-home>

Am Freitag, den 17.10.2008, 12:49 -0700 schrieb Jesse Keating:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?

Well, what's the benefit of your proposal?
Who does it benefit?

The usual way for people to download files is that they find the file
they want, click on it, and then they get the file. It's the same with
bittorrent. I want the DVD, I click the "DVD torrent", I get the DVD.

Most users will want the DVD *OR* the CDs. Why is it a Good Thing for
them to download both, and have to do even extra work to get what they
wanted? Surely we want to make it easier for them.



From gbillios at gmail.com  Sun Oct 19 12:47:10 2008
From: gbillios at gmail.com (George Billios)
Date: Sun, 19 Oct 2008 15:47:10 +0300
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
In-Reply-To: <20081019101912.GB6480@who-t.net>
References: <gdd1je$i7l$1@ger.gmane.org>
	<20081019065623.GA14426@who-t.net>	<48FAEDC3.2000101@gmail.com>
	<20081019101912.GB6480@who-t.net>
Message-ID: <48FB2C4E.3000903@gmail.com>



-------- Original Message  --------
Subject: Re:xorg-x11-drv-evdev-7.0.1-2 bad!
From: Peter Hutterer <peter.hutterer at who-t.net>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: Sun 19 Oct 2008 13:19:12 EEST

> On Sun, Oct 19, 2008 at 11:20:19AM +0300, George Billios wrote:
>> I will also send you mine by email because I was hit by the same problem
>> even if the updated xorg-x11-server-Xorg was installed.
> 
> Summary from our short email exchange:
> If you have an xorg.conf that registers an evdev device, this device will now
> produce duplicate events. For most setups, you probably don't need it in your
> xorg.conf because HAL picks it up anyway. If you really do, add option
> "GrabDevice" "true" and that'll restore the old grabbing behaviour.
> 
>> In the mean time I would advice to reverse back to the old behaviour,
>> since it is way to close to the F10 release to do these kind of changes.
> 
> No. the old behaviour is too broken, and it's good that it's finally fixed.
> "Macintosh mouse button emulation" and the keys that control volume, suspend,
> etc. are broken in the old behaviour, and that's a quite serious regression
> from F9.
> 
> Cheers,
>   Peter
> 

Well I must agree that no device section worked better than I expected
but it required manually editing the xorg.conf and deleting the
respective section.

What happens with all the people upgrading from F9? Will the Xorg rpm
handle this?




From mattdm at mattdm.org  Sun Oct 19 12:51:50 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 19 Oct 2008 08:51:50 -0400
Subject: text-to-speech doesn't work
In-Reply-To: <gdds30$312$1@ger.gmane.org>
References: <gdbd1f$r8e$1@ger.gmane.org> <20081018185757.GA12113@jadzia.bu.edu>
	<gddr7e$ug$1@ger.gmane.org> <gdds30$312$1@ger.gmane.org>
Message-ID: <20081019125150.GA6481@jadzia.bu.edu>

On Sat, Oct 18, 2008 at 05:39:11PM -0600, kwhiskerz wrote:
> I no longer need to prepend padsp to festival --tts file.txt. However, it still won't work in kttsd.

make sure a bug is filed for this.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From dwmw2 at infradead.org  Sun Oct 19 13:03:42 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 19 Oct 2008 14:03:42 +0100
Subject: Sendmail still default?
In-Reply-To: <48F88F62.5080004@gmail.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
Message-ID: <1224421422.6770.1466.camel@macbook.infradead.org>

On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
> 
> > Milter is supported by alternatives too
> 
> They pretend to, but won't actually run complex milters like
> MimeDefang.

Some of the better alternatives don't even _try_ to run milters, because
they are fully-featured enough in their own right, without needing to
rely on external software.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From promac at gmail.com  Sun Oct 19 13:59:03 2008
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sun, 19 Oct 2008 11:59:03 -0200
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <e1760170810190519m4bbe150cre8e82bc5d7ddfb1f@mail.gmail.com>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
	<68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
	<27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>
	<26499.198.175.55.5.1224256924.squirrel@mail.jcomserv.net>
	<68720af30810171856ucad1d58ufc5ca16b28d81378@mail.gmail.com>
	<68720af30810181832h1439d931qb687edc23aa23c7e@mail.gmail.com>
	<e1760170810190519m4bbe150cre8e82bc5d7ddfb1f@mail.gmail.com>
Message-ID: <68720af30810190659i4160a7d8p78848bb582528be3@mail.gmail.com>

On Sun, Oct 19, 2008 at 10:19 AM, KH KH <kwizart at gmail.com> wrote:

> 2008/10/19 Paulo Cavalcanti <promac at gmail.com>:
>
> >
> > Well, I fixed it:
> >
> > http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc9.src.rpm<http://people.atrpms.net/%7Epcavalcanti/srpms/yafaray-0.1.0-3.fc9.src.rpm>
> >
> > It builds just fine in F9 now.
> >
> > I hope it can help you.
> Hi Paulo!
>
> I think this package should follow the usual package review process now.
> It would be fine to close this topic, here on the mailing list, with
> the bugzilla review request;
> then, anyone can follow the conversation on the review.
> But I think yafray and yafaray should co-exist for now.
>
> Now, you will need to get sponsored for the package to be.
> In the yafaray case, I would like to review it , as there is some
> improvements required.
> But your spec should be a good start.
>
>
Hi,

in fact, according to my tests, yafray and yafaray can coexist. They use
different Blender menus.

However, yafaray needs to be integrated into blender. To accomplish this,
there is a new rpm,
yafaray-blender, that copies the appropriate scripts and libraries to
/usr/share/blender/scripts.

http://www.yafray.org/forum/viewtopic.php?t=1701

This additional rpm is created automatically within the new yafaray
.src.rpm:

http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-4.fc8.src.rpm

This new .src.rpm builds fine with mock for F8 and F9.

It would be really nice to have yafaray in Fedora, maybe for F10, since
Ubuntu already has it:

http://www.yafray.org/index.php?s=2

If you can review the package it will be good, but I think we need some
blender users to make
a thorough evaluation.

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081019/3412a6af/attachment.htm>

From opensource at till.name  Sun Oct 19 14:28:16 2008
From: opensource at till.name (Till Maas)
Date: Sun, 19 Oct 2008 16:28:16 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081018161037.GC24129@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081018101007.GB24572@victor.nirvana>
	<20081018161037.GC24129@tango.0pointer.de>
Message-ID: <200810191628.33633.opensource@till.name>

On Sat October 18 2008, Lennart Poettering wrote:

> And of course, "?ber-" is a very common prefix in the german
> language. In verbs, in adjectives, everywhere. But please, don't twist
> my words: I find it questionnable to use the prefix as kind of
> superlative in reference to the ?bermensch. That is all.
>
> Let's end this discussion! Fedora-devel is not the place to discuss
> Nazi vocabulary. Toshio already agreed to change the term. So I am
> happy, no need for pointless bikeshedding discussions.

I guess you do not see the personal implications about your suggestion and 
reasoning. The uber prefix is widely used by a lot of people without the 
intent to promote inhumanity or to downplay the crimes of the nazis[1]. So if 
you tell that it is wrong for the Fedora Project to use it, then it implies 
that it is wrong for everybody else to use it, too. Because Fedora is 
maintained by a lot of people who use the uber prefix as I described above, 
you kind of attack them personally imho. Therefore they also deserve to 
defend themself.

If you did not want this discussion, you should have probably chosen your 
words a little bit more wisely. Proposing to change the groupname because it 
_may be_ misinterpreted (which it sounded in the first half of your initial 
posting) is a lot different than to change it, because it is obviously wrong 
(which it sounds line in the remaining messages).

Btw. my lexicon "Meyers grosses Taschenlexikon" from 1995 says, 
that "?bermensch" is a non-existing human beeing and that it is used by 
philosophers. I would say, that it is probably used in philosophical 
questions like "If an ?bermensch would be involved in this discussion, what 
would he say?".

Regards,
Till

[1] 
You already told in your first posting that you know this, but here are also 
some references:

There are a lot of entries in the urban dictionary:
http://www.urbandictionary.com/define.php?term=%C3%9Cber%201337

There are books called "Uberhacker" and "Uberhacker II" in Amazon
http://www.amazon.com/Uberhacker-How-Break-into-Computers/dp/155950207X
http://www.amazon.com/Uberhacker-II-More-Break-Computer/dp/1559502398
-------------- 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/20081019/9d09d480/attachment.sig>

From opensource at till.name  Sun Oct 19 14:46:34 2008
From: opensource at till.name (Till Maas)
Date: Sun, 19 Oct 2008 16:46:34 +0200
Subject: The Big ACL Opening
In-Reply-To: <1224317313.6806.4.camel@arekh.okg>
References: <48F64212.2010505@redhat.com>
	<200810180855.32076.opensource@till.name>
	<1224317313.6806.4.camel@arekh.okg>
Message-ID: <200810191646.47184.opensource@till.name>

On Sat October 18 2008, Nicolas Mailhot wrote:
> Le samedi 18 octobre 2008 ? 08:55 +0200, Till Maas a ?crit :
> > On Sat October 18 2008, Lennart Poettering wrote:
> > > I fully understand that not everyone is aware of this connection,
> > > especially outside of Germany. But uh, in Germany it is very obvious.
> >
> > I live in Germany and am a native speaker, but for me this is not very
> > obvious. I also doubt, that anyone I know would think about someone
> > within Fedora beeing a nazi oder inhuman, because of the groupname
> > uberpackager.
>
> I don't live in Germany and I'm not a native speaker but I also never
> was comfortable with ?ber for the aforementionned historical reasons. I
> just didn't feel pointing the issue would be well received if not done
> by a German himself.

I do not doubt, that there are people, who are not comfortable with "?ber", 
because Lennart already made this clear. But I doubt that it is very obvious. 
Using the Hitler salute is something, that is something, that is very 
obviously wrong for the people living in Germany.

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/20081019/083f6d13/attachment.sig>

From lesmikesell at gmail.com  Sun Oct 19 14:47:18 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 19 Oct 2008 09:47:18 -0500
Subject: Sendmail still default?
In-Reply-To: <1224421422.6770.1466.camel@macbook.infradead.org>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
Message-ID: <48FB4876.90208@gmail.com>

David Woodhouse wrote:
> On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
>>> Milter is supported by alternatives too
>> They pretend to, but won't actually run complex milters like
>> MimeDefang.
> 
> Some of the better alternatives don't even _try_ to run milters, because
> they are fully-featured enough in their own right, without needing to
> rely on external software.

Which means that you can't run your choice of tests on a message during 
the smtp conversation before you accept it - at least without starting a 
new process for each one which is expensive for large programs like 
spamassassin.  And if you accept a message but don't deliver it, you are 
supposed to generate a bounce to the sender, but that is always the 
wrong thing to do if you think it might be spam or a virus.  Running 
your checks in time to do an smtp reject eliminates that problem.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From opensource at till.name  Sun Oct 19 14:57:51 2008
From: opensource at till.name (Till Maas)
Date: Sun, 19 Oct 2008 16:57:51 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48FA4EE4.6050503@gmail.com>
References: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>
	<20081018180857.GK27052@angus.ind.WPI.EDU> <48FA4EE4.6050503@gmail.com>
Message-ID: <200810191658.25431.opensource@till.name>

On Sat October 18 2008, Les Mikesell wrote:
> Chuck Anderson wrote:

> > Bonus points if you can figure out how to make the DVD multi-session
> > so that all the files from inside the embedded CD iso's show up as
> > regular files in the DVD :-)
>
> So the bootable chunk is like boot.iso which automatically mounts the
> rest of the dvd if present or lets you look elsewhere (like the nfs
> install) if not? 

Yes.

> Will this also work if you copy the image to a 
> suitably sized bootable USB drive?  

I guess it will currently not work, if you copy the image that contains the cd 
iso images, but you can copy the cd iso images onto a bootable USB drive. 
Nevertheless, this is something that can be made possible, if this approach 
is not rejected for other reasons.

> The missing piece would be how you 
> create the individual CD's if you download from Windows and can't use a
> DVD.

There exists software for Windows, that allows to include iso images as 
virtual optical drives. I do not currently know any name, but I have read a 
lot about them in a computer newsgroup. Also I believe that recents windows 
releases are distributed on DVDs.

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/20081019/c1708980/attachment.sig>

From giallu at gmail.com  Sun Oct 19 14:58:46 2008
From: giallu at gmail.com (Gianluca Sforna)
Date: Sun, 19 Oct 2008 16:58:46 +0200
Subject: The Big ACL Opening
In-Reply-To: <1224308827.8880.21.camel@fantail.jnet.net.nz>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017210147.GA24430@shell.devel.redhat.com>
	<80d7e4090810171454x90a9f04xb5639c84716b27d3@mail.gmail.com>
	<20081017223126.GH27444@angus.ind.WPI.EDU>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
Message-ID: <d5ad21470810190758p5207a6f8tddb458a73f27f792@mail.gmail.com>

On Sat, Oct 18, 2008 at 7:47 AM, Nigel Jones <dev at nigelj.com> wrote:
> masterpackager? (i.e. you've mastered packaging...)

This is probably not a poll, but if we are going to change the name I
like this one better than superpackager...


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From a.badger at gmail.com  Sun Oct 19 16:18:11 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 19 Oct 2008 09:18:11 -0700
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <20081016171451.GA7049@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <48FB5DC3.1060409@gmail.com>

So I'm going to do this tomorrow or have to put it off until after
change freeze.

The name I personally favour is masterpackager since it evokes the
apprentice, journeyman, master craftsman stages that seem most like what
we're modeling here.

I know this isn't as flamboyant as ultrapackager, superpackager, etc but
can everyone live with this?

-Toshio

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

From skvidal at fedoraproject.org  Sun Oct 19 16:30:00 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sun, 19 Oct 2008 12:30:00 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
Message-ID: <1224433800.25634.2.camel@rosebud>

On Sun, 2008-10-19 at 09:18 -0700, Toshio Kuratomi wrote:
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
> 
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
> 
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?
> 

Wait - so wednesday and pugsley are out?

/me is deeply affronted!

-sv




From jkeating at redhat.com  Sun Oct 19 16:33:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 19 Oct 2008 09:33:06 -0700
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
Message-ID: <1224433986.4219.10.camel@luminos.localdomain>

On Sun, 2008-10-19 at 09:18 -0700, Toshio Kuratomi wrote:
> 
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
> 
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?

I don't like that color of the bike shed.  I'd prefer it was chartreuse.
Please resubmit your plans once you've gotten the color the way I prefer
it. 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081019/4687488d/attachment.sig>

From dwmw2 at infradead.org  Sun Oct 19 16:38:35 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 19 Oct 2008 17:38:35 +0100
Subject: Sendmail still default?
In-Reply-To: <48FB4876.90208@gmail.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
Message-ID: <1224434315.6770.1477.camel@macbook.infradead.org>

On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
> Which means that you can't run your choice of tests on a message during 
> the smtp conversation before you accept it - at least without starting a 
> new process for each one which is expensive for large programs like 
> spamassassin.

As is often the case, it seems, you are entirely incorrect.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From vonbrand at inf.utfsm.cl  Sun Oct 19 16:42:48 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 19 Oct 2008 13:42:48 -0300
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
In-Reply-To: <gdd1je$i7l$1@ger.gmane.org>
References: <gdd1je$i7l$1@ger.gmane.org>
Message-ID: <200810191642.m9JGgmaq004249@laptop14.inf.utfsm.cl>

kwhiskerz <kwhiskerz at gmail.com> wrote:
> evdev driver 7.0.1-2 makes keyboard input impossible. All key-presses are
> done in triplicate, including backspace, so it is impossible to correct
> the erroneous input.

What I have here is xorg-x11-drv-evdev-2.0.7-1.fc10.x86_64, and that works
fine.
-- 
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 2340000       Fax:  +56 32 2797513



From j.w.r.degoede at hhs.nl  Sun Oct 19 17:08:47 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 19 Oct 2008 19:08:47 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
Message-ID: <48FB699F.8060901@hhs.nl>

Toshio Kuratomi wrote:
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
> 
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
> 

+1

Regards,

Hans



From kwhiskerz at gmail.com  Sun Oct 19 17:09:23 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Sun, 19 Oct 2008 11:09:23 -0600
Subject: xorg-x11-drv-evdev-7.0.1-2 bad! [solved]
References: <gdd1je$i7l$1@ger.gmane.org> <20081019065623.GA14426@who-t.net>
Message-ID: <gdfpk3$jit$1@ger.gmane.org>

Get rid of any xorg.conf file you have and all is fine. Works on both my computers.



From kanarip at kanarip.com  Sun Oct 19 17:35:57 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Sun, 19 Oct 2008 19:35:57 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224272955.4142.25.camel@luminos.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
Message-ID: <1224437757.25549.9.camel@ghandalf.kanarip.com>

On Fri, 2008-10-17 at 12:49 -0700, Jesse Keating wrote:
> Most torrent clients I've seen today allow you to pick and choose which
> files you wish to download.  As such, does it make sense to collapse the
> DVD and CD torrents into a single torrent and allow people to use the
> client to pick which they want?  Are there pros/cons to this?
> 

Not having read the entire thread yet, will collapsing CD/DVD torrents
allow you to track the number of completed downloads accurately for each
of these two categories?

Last time I did this, with the not-so-dead bittorrent-* code, I was
unable to track down the number of downloads and ended up with a few
hundred downloads "in progress" because virtually no-one had downloaded
the full set of media (all CDs *and* the DVD).

Kind regards,

Jeroen van Meeuwen
-kanarip



From tibbs at math.uh.edu  Sun Oct 19 17:50:30 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 19 Oct 2008 12:50:30 -0500
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
Message-ID: <ufaabd04gpl.fsf@epithumia.math.uh.edu>

>>>>> "TK" == Toshio Kuratomi <a.badger at gmail.com> writes:

TK> The name I personally favour is masterpackager since it evokes the
TK> apprentice, journeyman, master craftsman stages that seem most
TK> like what we're modeling here.

Or the master/slave relationship, which I must point out is about as
negative a connotation as the one some people insist on attaching to
our current choice.

Culturally insensitive to the end,

 - J<



From chris.stone at gmail.com  Sun Oct 19 18:00:49 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 19 Oct 2008 11:00:49 -0700
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <ufaabd04gpl.fsf@epithumia.math.uh.edu>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<ufaabd04gpl.fsf@epithumia.math.uh.edu>
Message-ID: <d9c612bf0810191100k719a9a87g23de53475349006d@mail.gmail.com>

On Sun, Oct 19, 2008 at 10:50 AM, Jason L Tibbitts III <tibbs at math.uh.edu>wrote:

> >>>>> "TK" == Toshio Kuratomi <a.badger at gmail.com> writes:
>
> TK> The name I personally favour is masterpackager since it evokes the
> TK> apprentice, journeyman, master craftsman stages that seem most
> TK> like what we're modeling here.
>
> Or the master/slave relationship, which I must point out is about as
> negative a connotation as the one some people insist on attaching to
> our current choice.
>
> Culturally insensitive to the end,
>

I like "packagelord" since we are heading towards a neo-feudalism like
economy thanks to the privately owned central banking and fractional reserve
monetary system the western world lives in today.  We need to get used to
the idea of being Lords and Serfs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081019/26ad42f4/attachment.htm>

From lesmikesell at gmail.com  Sun Oct 19 18:04:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 19 Oct 2008 13:04:04 -0500
Subject: Sendmail still default?
In-Reply-To: <1224434315.6770.1477.camel@macbook.infradead.org>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
Message-ID: <48FB7694.4050400@gmail.com>

David Woodhouse wrote:
> On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
>> Which means that you can't run your choice of tests on a message during 
>> the smtp conversation before you accept it - at least without starting a 
>> new process for each one which is expensive for large programs like 
>> spamassassin.
> 
> As is often the case, it seems, you are entirely incorrect.

One of my choices of tests on an inbound relay machine has been to check 
that the user exists using an smtp check against the internal delivery 
host.  How would I do that on an MTA that does not handle milters?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lists at sapience.com  Sun Oct 19 18:17:51 2008
From: lists at sapience.com (Mail Lists)
Date: Sun, 19 Oct 2008 14:17:51 -0400
Subject: Sendmail still default?
In-Reply-To: <48FB7694.4050400@gmail.com>
References: <48F87794.3090108@redhat.com>	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com>
Message-ID: <48FB79CF.2030405@sapience.com>

On 10/19/2008 02:04 PM, Les Mikesell wrote:

> One of my choices of tests on an inbound relay machine has been to check
> that the user exists using an smtp check against the internal delivery
> host.  How would I do that on an MTA that does not handle milters?
> 
  Not taking sides on milters or not but ..

  This can be achieved in sendmail (et al) with virtusertable. Doesnt
use an smtp check from border to inside as you stated, and it does need
a virtusertable on the border relay.




From walters at verbum.org  Sun Oct 19 18:29:09 2008
From: walters at verbum.org (Colin Walters)
Date: Sun, 19 Oct 2008 14:29:09 -0400
Subject: Sendmail still default?
In-Reply-To: <48FB79CF.2030405@sapience.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
Message-ID: <faa16b610810191129t43044d34y60aab2c43d8ddc24@mail.gmail.com>

On Sun, Oct 19, 2008 at 2:17 PM, Mail Lists <lists at sapience.com> wrote:
> On 10/19/2008 02:04 PM, Les Mikesell wrote:
>
>> One of my choices of tests on an inbound relay machine has been to check
>> that the user exists using an smtp check against the internal delivery
>> host.  How would I do that on an MTA that does not handle milters?
>>
>  Not taking sides on milters or not but ..
>
>  This can be achieved in sendmail (et al) with virtusertable. Doesnt
> use an smtp check from border to inside as you stated, and it does need
> a virtusertable on the border relay.

Everyone - Mail Lists has spoken.  End of thread!



From arjan at infradead.org  Sun Oct 19 18:37:16 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Sun, 19 Oct 2008 11:37:16 -0700
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FB79CF.2030405@sapience.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
Message-ID: <20081019113716.276106a8@infradead.org>


Forget about Sendmail. Or Exim. Or Postfix as default install.

Really.

There's two types of people using fedora:
1) People who don't run a mail server
2) People who very deliberately do

For 1), all three are wrong. Really. All you really need is some
minimalist commandline compatible thing that just forwards to some
smart host (or maybe does only local delivery). SSMTP or similar is
perfectly fine for this, while not taxing memory or boot time.

For 2) these folks have a VERY specific personal preference. This
entire discussion proves that. These folks already have to configure
their system from the default... making "pick a mail server of your
taste" part of that is the least of their worries.


Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
default choice is ignoring the reality... 


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From lists at sapience.com  Sun Oct 19 18:40:17 2008
From: lists at sapience.com (Mail Lists)
Date: Sun, 19 Oct 2008 14:40:17 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019113716.276106a8@infradead.org>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>
	<48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
Message-ID: <48FB7F11.6000900@sapience.com>

On 10/19/2008 02:37 PM, Arjan van de Ven wrote:
> Forget about Sendmail. Or Exim. Or Postfix as default install.
> 
> Really.

> 
> Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> default choice is ignoring the reality... 
> 
> 


  Agreed - tho it would be nice to ship dkim-milter and dk-milter along
with sendmail/postfix etc.



From dwmw2 at infradead.org  Sun Oct 19 18:48:22 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 19 Oct 2008 19:48:22 +0100
Subject: Sendmail still default?
In-Reply-To: <48FB7694.4050400@gmail.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com>
Message-ID: <1224442102.6770.1498.camel@macbook.infradead.org>

On Sun, 2008-10-19 at 13:04 -0500, Les Mikesell wrote:
> David Woodhouse wrote:
> > On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
> >> Which means that you can't run your choice of tests on a message during 
> >> the smtp conversation before you accept it - at least without starting a 
> >> new process for each one which is expensive for large programs like 
> >> spamassassin.
> > 
> > As is often the case, it seems, you are entirely incorrect.
> 
> One of my choices of tests on an inbound relay machine has been to check 
> that the user exists using an smtp check against the internal delivery 
> host.  How would I do that on an MTA that does not handle milters?

 require verify = recipient/callout=20s,use_sender

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From Lam at Lam.pl  Sun Oct 19 19:24:28 2008
From: Lam at Lam.pl (Leszek Matok)
Date: Sun, 19 Oct 2008 21:24:28 +0200
Subject: Sendmail still default?
In-Reply-To: <1224387443.15123.20.camel@code.and.org>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud> <48FA16D3.5020204@gmail.com>
	<1224362077.21581.123.camel@rosebud> <48FA4C07.6010304@gmail.com>
	<1224363427.21581.130.camel@rosebud> <48FA5183.1020407@gmail.com>
	<1224387443.15123.20.camel@code.and.org>
Message-ID: <20081019212428.1da0fa19@pensja.lam.pl>

Dnia 2008-10-18, o godz. 23:37:23 James Antill <james at fedoraproject.org>
napisa?(a):

> I appreciate that you have a
> different preference, but even you must realize you are in a minority
Please, show us numbers :)

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

From kzak at redhat.com  Sun Oct 19 19:26:24 2008
From: kzak at redhat.com (Karel Zak)
Date: Sun, 19 Oct 2008 21:26:24 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019113716.276106a8@infradead.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
Message-ID: <20081019192624.GC7547@nb.net.home>

On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
> Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> default choice is ignoring the reality... 

 (+1)

 Good point, but don't forget that Fedora is pretty ambivalent
 distribution. It's a "desktop distribution" where some people want to
 disable non-X console and other people use postfix, port packages to
 s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a
 base for Red Hat Enterprise distribution :-)

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From walters at verbum.org  Sun Oct 19 19:32:20 2008
From: walters at verbum.org (Colin Walters)
Date: Sun, 19 Oct 2008 15:32:20 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019192624.GC7547@nb.net.home>
References: <48F87794.3090108@redhat.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
Message-ID: <faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>

On Sun, Oct 19, 2008 at 3:26 PM, Karel Zak <kzak at redhat.com> wrote:
> On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
>> Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
>> default choice is ignoring the reality...
>
>  (+1)
>
>  Good point, but don't forget that Fedora is pretty ambivalent
>  distribution. It's a "desktop distribution" where some people want to
>  disable non-X console and other people use postfix,

That's right - desktops are different from servers.  Fedora's core
should be driven from the use cases, and where the use cases have
things in common, they're shared.  Where they don't, they're not.

Specifically regarding an MTA, as I said before I understand there's
the "workstation" use case where you're say doing web development and
you want to install Apache or Tomcat or something locally and run
logwatch on it.  We obviously will support that.  But it doesn't make
sense for the default desktop OS to be sending you email about all the
junk going on under the hood.



From arjan at infradead.org  Sun Oct 19 19:42:17 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Sun, 19 Oct 2008 12:42:17 -0700
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019192624.GC7547@nb.net.home>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
Message-ID: <20081019124217.3fc9379a@infradead.org>

On Sun, 19 Oct 2008 21:26:24 +0200
Karel Zak <kzak at redhat.com> wrote:

> On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
> > Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> > default choice is ignoring the reality... 
> 
>  (+1)
> 
>  Good point, but don't forget that Fedora is pretty ambivalent
>  distribution. It's a "desktop distribution" where some people want to
>  disable non-X console and other people use postfix, port packages to
>  s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a
>  base for Red Hat Enterprise distribution :-)

I'm all in favor having any and all of those as options.
Really.
For the people who want to run a mail server, they absolutely should.
But those already have to significantly customize their OS already.
Installing a MTA of their choice as part of that is no big deal,
and probably entirely expected by those who really want to run a mail
server.

But I stand by: The default: none of the above.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From seg at haxxed.com  Sun Oct 19 20:40:41 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 19 Oct 2008 15:40:41 -0500
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <20081018103224.GB415@amd.home.annexia.org>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>
	<1224274115.4142.28.camel@luminos.localdomain>
	<48F8F8AB.3070304@behdad.org>
	<1224278873.4142.39.camel@luminos.localdomain>
	<20081018103224.GB415@amd.home.annexia.org>
Message-ID: <1224448841.598.7.camel@localhost.localdomain>

On Sat, 2008-10-18 at 11:32 +0100, Richard W.M. Jones wrote:
> On Fri, Oct 17, 2008 at 02:27:53PM -0700, Jesse Keating wrote:
> > I'd imagine other desktops have similar workflows when dealing with
> > torrent files, I'd think resorting to the command line to deal with them
> > would be a last resort for the people who need help getting Fedora
> > downloaded.
> 
> It's not quite so easy if you've got > 1 machine on your home network
> and a typical NAT router.  I have the router set to point the
> bittorrent ports at a single machine on the network, so normally I
> have to copy the .torrent file over to that machine and then invoke
> 'bittorrent-curses foo.torrent' remotely.

This is the main reason I stopped using the text client.

GUI clients usually can manage multiple torrents under one port. And can
be set to use any port. I pick different ports on each machine and set
up forwards to each one. Problem solved.

Still a pain in the ass, but I haven't finished adding NAT-PMP support
to my router firmware yet...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081019/eaec63d6/attachment.sig>

From kzak at redhat.com  Sun Oct 19 20:54:21 2008
From: kzak at redhat.com (Karel Zak)
Date: Sun, 19 Oct 2008 22:54:21 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019124217.3fc9379a@infradead.org>
References: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<20081019124217.3fc9379a@infradead.org>
Message-ID: <20081019205421.GA14730@nb.net.home>

On Sun, Oct 19, 2008 at 12:42:17PM -0700, Arjan van de Ven wrote:
> On Sun, 19 Oct 2008 21:26:24 +0200
> Karel Zak <kzak at redhat.com> wrote:
> 
> > On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
> > > Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> > > default choice is ignoring the reality... 
> > 
> >  (+1)
> > 
> >  Good point, but don't forget that Fedora is pretty ambivalent
> >  distribution. It's a "desktop distribution" where some people want to
> >  disable non-X console and other people use postfix, port packages to
> >  s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a
> >  base for Red Hat Enterprise distribution :-)
> 
> I'm all in favor having any and all of those as options.
> Really.
> For the people who want to run a mail server, they absolutely should.
> But those already have to significantly customize their OS already.
> Installing a MTA of their choice as part of that is no big deal,
> and probably entirely expected by those who really want to run a mail
> server.
> 
> But I stand by: The default: none of the above.

 I agree. Definitely. (I use esmtp(1) for years).

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From dev at nigelj.com  Sun Oct 19 20:53:45 2008
From: dev at nigelj.com (Nigel Jones)
Date: Mon, 20 Oct 2008 09:53:45 +1300
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <ufaabd04gpl.fsf@epithumia.math.uh.edu>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<ufaabd04gpl.fsf@epithumia.math.uh.edu>
Message-ID: <1224449625.8880.27.camel@fantail.jnet.net.nz>

On Sun, 2008-10-19 at 12:50 -0500, Jason L Tibbitts III wrote:
> >>>>> "TK" == Toshio Kuratomi <a.badger at gmail.com> writes:
> 
> TK> The name I personally favour is masterpackager since it evokes the
> TK> apprentice, journeyman, master craftsman stages that seem most
> TK> like what we're modeling here.
> 
> Or the master/slave relationship, which I must point out is about as
> negative a connotation as the one some people insist on attaching to
> our current choice.
Then lets just scrap the 'superior' packager group if your worried about
that...

But honestly, there are at least 27 meanings of master
(http://www.answers.com/master) including:

n.
'12. A worker qualified to teach apprentices and carry on the craft
independently'
'13. An expert'

adj.
'4. Highly skilled or proficient'

Admittedly this is the problem with the English language, words such as
'Master' have many different implications.

+1 to Toshio's proposal (which looks like my suggestion :P)

- N.J.
> 
> Culturally insensitive to the end,
> 
>  - J<
> 
-- 
Nigel Jones <dev at nigelj.com>



From cmadams at hiwaay.net  Sun Oct 19 21:51:34 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 19 Oct 2008 16:51:34 -0500
Subject: The Big ACL Opening
In-Reply-To: <20081019063826.GA27271@victor.nirvana>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
	<1224351482.4219.0.camel@luminos.localdomain>
	<20081019063826.GA27271@victor.nirvana>
Message-ID: <20081019215134.GB1262690@hiwaay.net>

Once upon a time, Axel Thimm <Axel.Thimm at ATrpms.net> said:
> Make that a ninjapackager, otherwise we only fix one big problem and
> then we're gone (but we get high honours and our family a lifetime
> pension ;)

Nobody would ever see the ninjapackager do anything; the piratepackager
would do the job and make sure everybody knew about it!
-- 
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  Sun Oct 19 22:15:25 2008
From: ssorce at redhat.com (Simo Sorce)
Date: Sun, 19 Oct 2008 18:15:25 -0400
Subject: Sendmail still default?
In-Reply-To: <48FA5183.1020407@gmail.com>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<1224341699.21581.115.camel@rosebud> <48FA16D3.5020204@gmail.com>
	<1224362077.21581.123.camel@rosebud> <48FA4C07.6010304@gmail.com>
	<1224363427.21581.130.camel@rosebud>  <48FA5183.1020407@gmail.com>
Message-ID: <1224454525.30024.32.camel@hopeson>

On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:

> And in any case, using MimeDefang as a sendmail milter eliminates most 
> of the complaints anyone would have with sendmail itself since it lets 
> you do the complex parts with control handled in perl instead of 
> sendmail's internal language.

Man, if you imply perl is anything better, no wonders you defend
sendmail :-)

SCNR.



From cdahlin at redhat.com  Mon Oct 20 01:11:41 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sun, 19 Oct 2008 21:11:41 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
Message-ID: <48FBDACD.30402@redhat.com>

Toshio Kuratomi wrote:
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
>
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
>
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?
>
> -Toshio
>
>   
Ah, we always end up painting that bike shed, don't we?

Granted, its a /racist/ bike shed, but still... :)

--CJD



From cdahlin at redhat.com  Mon Oct 20 01:19:14 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sun, 19 Oct 2008 21:19:14 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48F8FA5C.9060303@behdad.org>
References: <1224272955.4142.25.camel@luminos.localdomain>	<37370.198.175.55.5.1224273068.squirrel@mail.jcomserv.net>	<1224274115.4142.28.camel@luminos.localdomain>	<48F8F8AB.3070304@behdad.org>	<48F8F95F.3050904@fedoraproject.org>
	<48F8FA5C.9060303@behdad.org>
Message-ID: <48FBDC92.5030203@redhat.com>

Behdad Esfahbod wrote:
> Rahul Sundaram wrote:
>   
>> Behdad Esfahbod wrote:
>>     
>>> Jesse Keating wrote:
>>>       
>>>> On Fri, 2008-10-17 at 14:51 -0500, Jon Ciesla wrote:
>>>>         
>>>>> Does it work it bittorrent-curses?
>>>>>           
>>>> I don't think so, but bittorrent-* from bittorrent.com is essentially
>>>> dead code to us, since they closed source any newer versions.  I don't
>>>> think we should consider it the 'least common denominator' anymore.
>>>>         
>>> Then why don't you tell us what one can use from the cmdline as easily as
>>> bittorrent-curses?
>>>
>>> I agree with seth: mindlessness.  How am I going to explain to a
>>> friend of
>>> mine who wants to download Fedora then?  "Take the torrent from the
>>> site, but
>>> then only download the file with dvd in the name".
>>>
>>> Why don't we also include nonfree codecs in the image and make some
>>> cash while
>>> at it?
>>>       
>> Stop being rude without any provocation at all. Jesse Keating *is*
>> asking for feedback, so you can be courteous while disagreeing.
>>     
>
> I didn't intend to be rude, sorry if it looked that way.  I was showing by
> example that merging the CD and DVD images is making it hard for users to get
> what they want without what they don't want.  I don't think the example was
> too far.
>
> behdad
>
>   
To answer your question: rtorrent works from the command line.

--CJD



From james at fedoraproject.org  Mon Oct 20 01:48:13 2008
From: james at fedoraproject.org (James Antill)
Date: Sun, 19 Oct 2008 21:48:13 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019113716.276106a8@infradead.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
Message-ID: <1224467293.15123.54.camel@code.and.org>

On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
> Forget about Sendmail. Or Exim. Or Postfix as default install.
> 
> Really.
> 
> There's two types of people using fedora:
> 1) People who don't run a mail server

 I think you meant to add _incoming_ in there, having mail that's
generated on the local machine go somewhere _reliably_ is a basic
feature required by all users.

> For 1), all three are wrong. Really. All you really need is some
> minimalist commandline compatible thing that just forwards to some
> smart host (or maybe does only local delivery).

 Or both, and the forwarding has to work when the network is down.

>  SSMTP or similar is
> perfectly fine for this, while not taxing memory or boot time.

 Yeh, right. SSMTP doesn't have a spool, so anything sending email when
the network is down gets their email silently deleted. hell, SSMTP
doesn't even support aliases.
 Look, feel free to have the default be postfix; configured to sendmail
locally and/or remotely ... with no daemon and thus. no inbound
processing. SSMTP is just worthless for most users, hell having nothing
at all would be better (but be ready for every package that needs to
send email to point out not having an smtp sender installed by default
is retarded).

> For 2) these folks have a VERY specific personal preference.

 Not true.

>  This
> entire discussion proves that.

 Right, when almost everyone is saying change to postfix and one or two
people are saying "what's so wrong with sendmail" ... that must mean we
should do nothing *sigh*.

-- 
James Antill <james at fedoraproject.org>
Fedora



From skvidal at fedoraproject.org  Mon Oct 20 01:47:58 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Sun, 19 Oct 2008 21:47:58 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
References: <48F87794.3090108@redhat.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
Message-ID: <1224467278.25634.4.camel@rosebud>

On Sun, 2008-10-19 at 15:32 -0400, Colin Walters wrote:
>  But it doesn't make
> sense for the default desktop OS to be sending you email about all the
> junk going on under the hood.


I understand where you are coming from but I have to say the above
statement is, imo, fundamentally wrong.

-sv




From mattdm at mattdm.org  Mon Oct 20 02:13:40 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 19 Oct 2008 22:13:40 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <1224467278.25634.4.camel@rosebud>
References: <48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
Message-ID: <20081020021340.GA7740@jadzia.bu.edu>

On Sun, Oct 19, 2008 at 09:47:58PM -0400, seth vidal wrote:
> >  But it doesn't make sense for the default desktop OS to be sending you
> > email about all the junk going on under the hood.
> I understand where you are coming from but I have to say the above
> statement is, imo, fundamentally wrong.

I agree with Seth. Since most desktop users don't have a centralized
logserver but do have an e-mail account somewhere, it makes perfect sense.
We need to work some on getting e-mail going somewhere useful, though, and
on making the e-mails sent be not "junk".



-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From smooge at gmail.com  Mon Oct 20 02:14:33 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Sun, 19 Oct 2008 20:14:33 -0600
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <1224467278.25634.4.camel@rosebud>
References: <48F87794.3090108@redhat.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
Message-ID: <80d7e4090810191914p12fb8c43p1204dc3b70159514@mail.gmail.com>

On Sun, Oct 19, 2008 at 7:47 PM, seth vidal <skvidal at fedoraproject.org> wrote:
> On Sun, 2008-10-19 at 15:32 -0400, Colin Walters wrote:
>>  But it doesn't make
>> sense for the default desktop OS to be sending you email about all the
>> junk going on under the hood.
>
>
> I understand where you are coming from but I have to say the above
> statement is, imo, fundamentally wrong.
>

I am in mixed boat about this... trying to go through 100+ logwatches
every day is a headache as it is :). But knowing that there is a
failed cron job on some desktop because the rootkit was b0rked is
valuable... but I am not the average user.

So the first question that comes to mind.. is if the user doesn't know
that the email is being generated.. does it matter it exists? And what
environments are we dealing with?

1) Home use. Does Grandma want to know about logwatch or noisy cron
jobs? Does she even know that there is email in the root user mailbox
since she shouldn't ever log into it?

2) Small scale environment. (2-30 systems).
3) Medium environment (30-100) systems.
4) Large environment 100-1000 systems
5) Ginormouse 1000+ systems.

Each has its use case. When you get to the large to ginormous ones..
you really need to work on the tools for centralized logging, with
agents and things to track usage.

The small to medium are the ones which are probably the ones that need
more work. The Small one might have someone who knows to look at the
root mail spool but most of the time its going to be someone who has
his worn "Linux for Dummies" book from the last person who set up the
lab.

Email only makes sense for this person if
a) its easy to setup.
b) it gives useful information.
c) and they know what to do with it.

It really doesn't matter if a box has postfix, exim, ssmtp, smail, etc
if the email is just stuck on the local machine and the user has no
idea where it is, how to get it, or what it does. And in that case,
does generating the email in the first place help anything? If this
were some new service versus one that we system administrators have
been raised to think as a god-given right.. and we were looking at
adding it to the desktop environment would we? [I am talking about the
default state where email stays local, and the local user probably has
no idea its there.]

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From lists at ralii.com  Mon Oct 20 02:16:06 2008
From: lists at ralii.com (Robert Locke)
Date: Sun, 19 Oct 2008 22:16:06 -0400
Subject: private group administration
In-Reply-To: <200810191317.14475.opensource@till.name>
References: <48F87E69.7040409@redhat.com>
	<20081018162535.GJ27052@angus.ind.WPI.EDU>
	<1224354097.20129.1.camel@rlt60f8.laptop.redhat.com>
	<200810191317.14475.opensource@till.name>
Message-ID: <1224468966.5042.6.camel@rlt60f8.laptop.redhat.com>


On Sun, 2008-10-19 at 13:17 +0200, Till Maas wrote:
> On Sat October 18 2008, Robert Locke wrote:
> > On Sat, 2008-10-18 at 12:25 -0400, Chuck Anderson wrote:
> 
> > > Right, with groups you can have files inherit the group from the
> > > directory they are in.  Is there any inheritance with ACLs?
> >
> > See 'setfacl d:' which can be used to set a "default" ACL on a directory
> > so that all "newly created files" will inherit it....
> 
> But this does not work satisfactory all the times. Given you have a directory 
> on one system that everybody within a certain groups should be able to access 
> completely. Then you scp a file that is not group writable (e.g. from a cd) 
> to it. Which default ACL for a group will makes the file writeable or 
> chmodable for everyone from this group? Afaik there is no such ACL. The best 
> approaches except giving everybody chmod/chown acces via sudo would be to 
> mount vfat filesystem into the directory, because it accepts a gid/uid mount 
> option to enforce a certain gid for all contents, or to use a fuse wrapper 
> filesystem that manages the permissions, but I am not sure, whether this is 
> possible or does already exist.

Little confused on your scenario.

A newly created file will get the ownership of the process creating it
(user/primary group), unless the directory is SGID then it will get the
group of the directory.  The permissions assigned will be based on the
creating programs desire minus umask.  The ACLs assigned will be based
on the "Default ACLs" of the directory (if any were set). But this only
applies to "newly" created files, so let's talk about copying....

If you use "cp -a" or "cp -p" or "mv", these endeavor to "preserve" the
permissions from whence the file came from, and what I described above
does not apply.  A simple cp without arguments would be creating "new"
files, and the above would apply.

Does that clarify why you are not getting the Default ACL sometimes?

--Rob



From Matt_Domsch at dell.com  Mon Oct 20 02:17:36 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sun, 19 Oct 2008 21:17:36 -0500
Subject: rawhide report: 20081018 changes
In-Reply-To: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
Message-ID: <20081020021736.GA11851@auslistsprd01.us.dell.com>

On Sat, Oct 18, 2008 at 10:09:59AM +0000, Rawhide Report wrote:
> Compose started at Sat Oct 18 06:01:17 UTC 2008
> 
> New package ipmitool
>         Utility for IPMI control
> Updated Packages:
> 
> OpenIPMI-2.0.14-3.fc10
> ----------------------
> * Thu Oct 16 18:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-3
> - split ipmitool to separate package

Yea! Thank you!  I've argued unsuccessfully for years that ipmitool
should have been its own package.
-Matt

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



From james at fedoraproject.org  Mon Oct 20 03:03:33 2008
From: james at fedoraproject.org (James Antill)
Date: Sun, 19 Oct 2008 23:03:33 -0400
Subject: repodata and comps.xml filenames in hexadecimal?
In-Reply-To: <48F7C1AD.2050806@tmus.dk>
References: <48F78DF5.8000308@wolves.durham.nc.us>
	<1224184118.4122.92.camel@luminos.localdomain>
	<48F7C1AD.2050806@tmus.dk>
Message-ID: <1224471813.15123.59.camel@code.and.org>

On Thu, 2008-10-16 at 20:35 -0200, Thomas M Steenholdt wrote:
> Jesse Keating wrote:
> > On Thu, 2008-10-16 at 14:54 -0400, G.Wolfe Woodbury wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> I know someone is working on a rewrite of some of the stuff dealing with
> >> repodata and comps.xml.  I notice today that the names of the files in
> >> repodata have the hexadecimal checksums prepended.   Is this the new
> >> "standard" or is there a bug in the generation scripts?
> > 
> > It's a new standard.  The repodata files are uniquely named which helps
> > many things such as proxies.
> > 
> > 
> 
> Is there a reason why the uniqueness part is prepended rather than 
> appended? It's kinda hard to tell which file is which when browsing 
> repositories.
> 
> http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/repodata/

 There was a reason, but noone can remember it atm. :)

> I realize that you probably won't browse the repodata directory too 
> often, but just in case it didn't make a difference, I thought it would 
> be kinda nice to be able to tell one from the other, on the few 
> occations where you actually might need to do so... :-)

 It's kinda more user visible than that, because on a 80 character wide
terminal all you can see is the sha1 sum codes when the file is
downloading (although you can see the name when one has finished).
 So either myself or seth will probably take a look at changing it to be
something like primary-<sha1>.sqlite.bz2 etc. ... but we'll have to live
with it as is for at least Fedora 10.

-- 
James Antill <james at fedoraproject.org>
Fedora



From gmaxwell at gmail.com  Mon Oct 20 03:03:34 2008
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Sun, 19 Oct 2008 23:03:34 -0400
Subject: Wikimedia's usage of Ubuntu
Message-ID: <e692861c0810192003rf00a929ua399a89f8667ac9f@mail.gmail.com>

I have been mostly tuning out the noise on these lists related to the
Ubuntu/Wikimedia press event and I don't wish to stir them up again,
but I expect the participants here will find the following both
informative and as useful reference material for correcting FUD which
might circulate related to this in the future.

http://meta.wikimedia.org/wiki/Wikimedia_Ubuntu_migration_FAQ



From cdahlin at redhat.com  Mon Oct 20 03:20:06 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sun, 19 Oct 2008 23:20:06 -0400
Subject: Wikimedia's usage of Ubuntu
In-Reply-To: <e692861c0810192003rf00a929ua399a89f8667ac9f@mail.gmail.com>
References: <e692861c0810192003rf00a929ua399a89f8667ac9f@mail.gmail.com>
Message-ID: <48FBF8E6.10408@redhat.com>

Gregory Maxwell wrote:
> I have been mostly tuning out the noise on these lists related to the
> Ubuntu/Wikimedia press event and I don't wish to stir them up again,
> but I expect the participants here will find the following both
> informative and as useful reference material for correcting FUD which
> might circulate related to this in the future.
>
> http://meta.wikimedia.org/wiki/Wikimedia_Ubuntu_migration_FAQ
>
>   
They said they don't like yum.

Seth, its all your fault >:(

--CJD



From ivazqueznet at gmail.com  Mon Oct 20 03:25:00 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sun, 19 Oct 2008 23:25:00 -0400
Subject: Wikimedia's usage of Ubuntu
In-Reply-To: <48FBF8E6.10408@redhat.com>
References: <e692861c0810192003rf00a929ua399a89f8667ac9f@mail.gmail.com>
	<48FBF8E6.10408@redhat.com>
Message-ID: <1224473100.13861.306.camel@ignacio.lan>

On Sun, 2008-10-19 at 23:20 -0400, Casey Dahlin wrote:
> Gregory Maxwell wrote:
> > I have been mostly tuning out the noise on these lists related to the
> > Ubuntu/Wikimedia press event and I don't wish to stir them up again,
> > but I expect the participants here will find the following both
> > informative and as useful reference material for correcting FUD which
> > might circulate related to this in the future.
> >
> > http://meta.wikimedia.org/wiki/Wikimedia_Ubuntu_migration_FAQ
> >
> >   
> They said they don't like yum.
> 
> Seth, its all your fault >:(

Heck, if I was stuck with the yum in FC3/4 then I'd hate Fedora too.

-- 
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/20081019/5e3bba39/attachment.sig>

From arjan at infradead.org  Mon Oct 20 04:06:20 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Sun, 19 Oct 2008 21:06:20 -0700
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <1224467293.15123.54.camel@code.and.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
Message-ID: <20081019210620.66572efb@infradead.org>

On Sun, 19 Oct 2008 21:48:13 -0400
James Antill <james at fedoraproject.org> wrote:

> On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
> > Forget about Sendmail. Or Exim. Or Postfix as default install.
> > 
> > Really.
> > 
> > There's two types of people using fedora:
> > 1) People who don't run a mail server
> 
>  I think you meant to add _incoming_ in there, having mail that's
> generated on the local machine go somewhere _reliably_ is a basic
> feature required by all users.

most users on the client side use a mail client that has its own
queuing.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From cmadams at hiwaay.net  Mon Oct 20 04:26:36 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Sun, 19 Oct 2008 23:26:36 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019210620.66572efb@infradead.org>
References: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
	<20081019210620.66572efb@infradead.org>
Message-ID: <20081020042636.GA1073485@hiwaay.net>

Once upon a time, Arjan van de Ven <arjan at infradead.org> said:
> most users on the client side use a mail client that has its own
> queuing.

Most _interactive_ users do.  Most automated tasks (e.g. cron) do not
have any queueing.
-- 
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 tim.lauridsen at googlemail.com  Mon Oct 20 04:55:00 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Mon, 20 Oct 2008 06:55:00 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
Message-ID: <48FC0F24.7080208@googlemail.com>

Toshio Kuratomi wrote:
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
>
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
>
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?
>
> -Toshio
>
>   
master ninja overload super chief packager :) 

Tim



From cdahlin at redhat.com  Mon Oct 20 05:06:45 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 20 Oct 2008 01:06:45 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC0F24.7080208@googlemail.com>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>	<48FB5DC3.1060409@gmail.com>
	<48FC0F24.7080208@googlemail.com>
Message-ID: <48FC11E5.8050703@redhat.com>

Tim Lauridsen wrote:
> Toshio Kuratomi wrote:
>> So I'm going to do this tomorrow or have to put it off until after
>> change freeze.
>>
>> The name I personally favour is masterpackager since it evokes the
>> apprentice, journeyman, master craftsman stages that seem most like what
>> we're modeling here.
>>
>> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
>> can everyone live with this?
>>
>> -Toshio
>>
>>   
> master ninja overload super chief packager :)
> Tim
>
Jellicle Packager

...I'm sorry, that was uncalled for.

--CJD



From tim.lauridsen at googlemail.com  Mon Oct 20 05:10:35 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Mon, 20 Oct 2008 07:10:35 +0200
Subject: Wikimedia's usage of Ubuntu
In-Reply-To: <48FBF8E6.10408@redhat.com>
References: <e692861c0810192003rf00a929ua399a89f8667ac9f@mail.gmail.com>
	<48FBF8E6.10408@redhat.com>
Message-ID: <48FC12CB.7090906@googlemail.com>

Casey Dahlin wrote:
> Gregory Maxwell wrote:
>> I have been mostly tuning out the noise on these lists related to the
>> Ubuntu/Wikimedia press event and I don't wish to stir them up again,
>> but I expect the participants here will find the following both
>> informative and as useful reference material for correcting FUD which
>> might circulate related to this in the future.
>>
>> http://meta.wikimedia.org/wiki/Wikimedia_Ubuntu_migration_FAQ
>>
>>   
> They said they don't like yum.
>
> Seth, its all your fault >:(
>
> --CJD
>
Why don't you go to the 'dora' store ? I dont like the like the color of 
the shopping baskets.
Why do you shop at the 'untu' store, i want to get fresh milk, i can 
store in 3 years and the owner gives me a bag of free candy.

:)

Tim



From orcanbahri at yahoo.com  Mon Oct 20 05:10:48 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Sun, 19 Oct 2008 22:10:48 -0700 (PDT)
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC0F24.7080208@googlemail.com>
Message-ID: <14686.46378.qm@web32808.mail.mud.yahoo.com>




--- On Mon, 10/20/08, Tim Lauridsen <tim.lauridsen at googlemail.com> wrote:

> From: Tim Lauridsen <tim.lauridsen at googlemail.com>
> Subject: Re: uberpackager rename (was Re: The Big ACL Opening)
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> Date: Monday, October 20, 2008, 12:55 AM
> Toshio Kuratomi wrote:
> > So I'm going to do this tomorrow or have to put it
> off until after
> > change freeze.
> >
> > The name I personally favour is masterpackager since
> it evokes the
> > apprentice, journeyman, master craftsman stages that
> seem most like what
> > we're modeling here.
> >
> > I know this isn't as flamboyant as ultrapackager,
> superpackager, etc but
> > can everyone live with this?
> >
> > -Toshio
> >
> >   
> master ninja overload super chief packager :) 
> 
> Tim
> 
How about GASP? which stands for Gasp Advanced Super Packager. Or something along that way. Is the recursive name idea no longer vogue?
Well I think it's still better than Uberfuhrer.

-oget

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From opensource at till.name  Mon Oct 20 07:18:08 2008
From: opensource at till.name (Till Maas)
Date: Mon, 20 Oct 2008 09:18:08 +0200
Subject: Sendmail still default?
In-Reply-To: <gdb9bj$jc9$2@ger.gmane.org>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
Message-ID: <200810200918.19031.opensource@till.name>

On Sat October 18 2008, Matthew Woehlke wrote:
[E-mail was changed]

> Um... which is actually another reason for local mail being default; in
> the event a user's mail recipient is not configured, it goes to a local
> spool only readable by root and that user. If Sue sets up a computer and
> adds an account for Bob, it's not really ideal if Bob's mail gets sent
> to sue at EXAMPLE.com because Bob doesn't have a recipient specified.

Sending log file contents that may contain sensitive data via unencrypted 
e-mail is not a good thing to do imho.

> Please do not quote my e-mail address unobfuscated in message bodies.

I guess the owner of your used mydomain.com e-mail has this wish, too. Unless 
it is one of your e-mail addresses, you should better use @example.com e-mail 
addresses. The example.com domain is there, to be used if you need an example 
domain.

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/20081020/99286e87/attachment.sig>

From pbrobinson at gmail.com  Mon Oct 20 08:30:41 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 20 Oct 2008 09:30:41 +0100
Subject: rawhide report: 20081018 changes
In-Reply-To: <20081020021736.GA11851@auslistsprd01.us.dell.com>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<20081020021736.GA11851@auslistsprd01.us.dell.com>
Message-ID: <5256d0b0810200130p54838f5av737b946ed2543d1f@mail.gmail.com>

>> New package ipmitool
>>         Utility for IPMI control
>> Updated Packages:
>>
>> OpenIPMI-2.0.14-3.fc10
>> ----------------------
>> * Thu Oct 16 18:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-3
>> - split ipmitool to separate package
>
> Yea! Thank you!  I've argued unsuccessfully for years that ipmitool
> should have been its own package.
> -Matt

What was it part of before? I just thought it had never been packaged.

Peter



From nicolas.mailhot at laposte.net  Mon Oct 20 08:44:35 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 20 Oct 2008 10:44:35 +0200 (CEST)
Subject: Sendmail still default?
In-Reply-To: <48FB4876.90208@gmail.com>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
Message-ID: <6a8fd7f24a34de9d67203f9be447c98e.squirrel@arekh.dyndns.org>



Le Dim 19 octobre 2008 16:47, Les Mikesell a ?crit :
>
> David Woodhouse wrote:
>> On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
>>>> Milter is supported by alternatives too
>>> They pretend to, but won't actually run complex milters like
>>> MimeDefang.
>>
>> Some of the better alternatives don't even _try_ to run milters,
>> because
>> they are fully-featured enough in their own right, without needing
>> to
>> rely on external software.
>
> Which means that you can't run your choice of tests on a message
> during
> the smtp conversation before you accept it - at least without starting
> a
> new process for each one which is expensive for large programs like
> spamassassin.

Actually, you don't need milters to do this in postfix (but you can
use milters if you prefer)

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Mon Oct 20 08:47:08 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 20 Oct 2008 10:47:08 +0200 (CEST)
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081019113716.276106a8@infradead.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
Message-ID: <493e75106098e6b9b43dc64fb5e7951e.squirrel@arekh.dyndns.org>



Le Dim 19 octobre 2008 20:37, Arjan van de Ven a ?crit :

> Anybody trying to argue for the politics of Exim/Postfix/Sendmail as
> default choice is ignoring the reality...

Fedora is about advancing the state of free software right?
And free software does not limit itself to the desktop.

Or I don't see why all the fuss about wikipedia switching side is.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Mon Oct 20 08:51:32 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 20 Oct 2008 10:51:32 +0200 (CEST)
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <1224467293.15123.54.camel@code.and.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
Message-ID: <2e1016076dc37ee5246b6a393869ff5d.squirrel@arekh.dyndns.org>



Le Lun 20 octobre 2008 03:48, James Antill a ?crit :
>
> On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
>> Forget about Sendmail. Or Exim. Or Postfix as default install.
>>
>> Really.
>>
>> There's two types of people using fedora:
>> 1) People who don't run a mail server
>
>  I think you meant to add _incoming_ in there, having mail that's
> generated on the local machine go somewhere _reliably_ is a basic
> feature required by all users.

Also filtering mail on MUA startup is just trainwreak recipe.
If you want your MUA to start fast you need to pre-filter junk mail in
the background (no not everyone uses gmail and gmail is not perfect
anyway).

So far, I haven't seen anything beating fetchmail + local MTA +
server-side filters + local imap or local maildir delivery in Fedora.

-- 
Nicolas Mailhot



From hughsient at gmail.com  Mon Oct 20 08:57:47 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 20 Oct 2008 09:57:47 +0100
Subject: PackageKit soon to include the QPackageKit library, need advice
In-Reply-To: <gddjdq$96a$1@ger.gmane.org>
References: <1224359517.29507.46.camel@hughsie-laptop>
	<gddjdq$96a$1@ger.gmane.org>
Message-ID: <1224493067.4582.5.camel@hughsie-laptop>

On Sat, 2008-10-18 at 16:11 -0500, Rex Dieter wrote:
> I concur with drago01, and would personally opt for names of the form
> PackageKit-glib(-devel) and PackageKit-qt(-devel), but whatever floats
> your boat.

Sounds good to me, thanks guys.

Richard.




From kraxel at redhat.com  Mon Oct 20 09:02:04 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Mon, 20 Oct 2008 11:02:04 +0200
Subject: Fedora 10 Snapshot 2
In-Reply-To: <1224272190.4142.22.camel@luminos.localdomain>
References: <1224272190.4142.22.camel@luminos.localdomain>
Message-ID: <48FC490C.6020509@redhat.com>

Jesse Keating wrote:
> This week brings us Fedora 10 Snapshot 2.  This time not only will we
> have Live images, we'll also have DVD and split CD install images.  Due
> to the amount of data to sync around, we're going to stagger the torrent
> releases, making them available as they finish syncing to the torrent
> server.  Please keep watching http://torrent.fedoraproject.org/ for new
> torrents to start showing up in the next few hours.

How about jigdo?  With the Beta DVD iso images at hand jigdo-lite has to
fetch only the packages changed since then, which is probably a small
fraction of the complete set ...

cheers,
  Gerd




From kraxel at redhat.com  Mon Oct 20 09:08:17 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Mon, 20 Oct 2008 11:08:17 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
Message-ID: <48FC4A81.3020809@redhat.com>

Toshio Kuratomi wrote:
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?

packagewizards?

cheers,
  Gerd



From dominik at greysector.net  Mon Oct 20 09:24:52 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 20 Oct 2008 11:24:52 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC4A81.3020809@redhat.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com> <48FC4A81.3020809@redhat.com>
Message-ID: <20081020092452.GA21183@mokona.greysector.net>

On Monday, 20 October 2008 at 11:08, Gerd Hoffmann wrote:
> Toshio Kuratomi wrote:
> > I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> > can everyone live with this?
> 
> packagewizards?

I like the sound of that!

"Do not meddle in the affairs of the (package)wizards, for they are subtle
and quick to anger."

A big +1.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From schaiba at gmail.com  Mon Oct 20 09:26:26 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Mon, 20 Oct 2008 12:26:26 +0300
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC4A81.3020809@redhat.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<48FC4A81.3020809@redhat.com>
Message-ID: <778179b00810200226x445cb7b0k96f9fc1ed1616432@mail.gmail.com>

On Mon, Oct 20, 2008 at 12:08 PM, Gerd Hoffmann <kraxel at redhat.com> wrote:

> Toshio Kuratomi wrote:
> > I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> > can everyone live with this?
>
> packagewizards?
>
> cheers,
>  Gerd
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Sounds cool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/1b4ea610/attachment.htm>

From dwmw2 at infradead.org  Mon Oct 20 09:52:49 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 20 Oct 2008 10:52:49 +0100
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
Message-ID: <1224496369.6770.1544.camel@macbook.infradead.org>

On Sun, 2008-10-19 at 09:18 -0700, Toshio Kuratomi wrote:
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
> 
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
> 
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?

No, I'm offended by the idea that a common root used in many geek words
can so easily be declared 'unclean' and eradicated. This is political
correctness at its worst, and I find it horrifically offensive. And
that's a _current_ issue, not one from the previous millennium.

I have no particular attachment to the '?berpackager' name, but I object
strongly to the change on _principle_. Please leave it as it was.

-- 
dwmw2



From rawhide at fedoraproject.org  Mon Oct 20 10:07:50 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 20 Oct 2008 10:07:50 +0000 (UTC)
Subject: rawhide report: 20081020 changes
Message-ID: <20081020100751.059FD1B8001@releng2.fedora.phx.redhat.com>

Compose started at Mon Oct 20 06:01:24 UTC 2008

New package fbterm
        FbTerm is a fast terminal emulator for linux with frame buffer device
New package perl-Sysadm-Install
        Typical installation tasks for system administrators
Updated Packages:

Perlbal-1.70-2.fc10
-------------------
* Sun Oct 19 18:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 1.70-2
- Use Perlbal::XS::HTTPHeaders to speed up header parsing


TeXmacs-1.0.7-1.fc10
--------------------
* Sun Oct 19 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 1.0.7-1
- new release 1.0.7


bluez-4.15-1.fc10
-----------------
* Mon Oct 20 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.15-1
- Update to 4.15


bug-buddy-2.24.1-1.fc10
-----------------------
* Sun Oct 19 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-1
- Update to 2.24.1


control-center-2.24.0.1-8.fc10
------------------------------
* Sun Oct 19 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0.1-8
- Fix a ui glitch in the keybinding capplet


crypto-utils-2.4.1-1
--------------------

fwbackups-1.43.2-3.fc10
-----------------------
* Sun Oct 19 18:00:00 2008 Stewart Adam <s.adam at diffingo.com> 1.43.2-3
- Add patch for trayNotify bug


fwbuilder-3.0.0-2.fc10
----------------------
* Sun Oct 19 18:00:00 2008 Ralf Ertzinger <ralf at skytale.met> 3.0.0-2
- Just keep fedora-fwbuilder.desktop (fixes BZ467618)


global-5.7.2-1.fc10
-------------------
* Sun Oct 19 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 5.7.2-1
- new release 5.7.2


gnome-keyring-2.24.1-1.fc10
---------------------------
* Sun Oct 19 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


gnu-smalltalk-3.1-1.fc10
------------------------
* Sun Oct 19 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 3.1-1
- New upstream release


gscan2pdf-0.9.26-1.fc10
-----------------------
* Tue Sep 30 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.9.26-1
- v 0.9.26


intltool-0.40.5-1.fc10
----------------------
* Sun Oct 19 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.40.5-1
- Update to 0.40.5


libxcb-1.1.91-5.fc10
--------------------
* Sun Oct 19 18:00:00 2008 Adam Jackson <ajax at redhat.com> 1.1.91-5
- Add pthread-stubs.pc


m17n-contrib-1.1.7-5.fc10
-------------------------
* Mon Oct 20 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 1.1.7-5.fc10
- add obsoletes for ibus-m17n subpackages


m17n-db-1.5.2-4.fc10
--------------------
* Mon Oct 20 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 1.5.2-4.fc10
- add obsoletes for ibus-m17n subpackages
- fix m17n-gen-ibus-engine to check for lang 't'


mantis-1.1.4-1.fc10
-------------------
* Sun Oct 19 18:00:00 2008 Gianluca Sforna <giallu gmail com> - 1.1.4-1
- new upstream release

* Tue Oct 14 18:00:00 2008 Gianluca Sforna <giallu gmail com> - 1.1.3-1
- new upstream release
- drop upstreamed patch


mesa-7.2-0.9.fc10
-----------------
* Sun Oct 19 18:00:00 2008 Dave Airlie <airlied at redhat.com> 7.2-0.9
- r300: re-enable zerocopy TFP for non-kms system
- r300: fix sw fallbacks on !kms + fix debug

* Tue Oct 14 18:00:00 2008 Adam Jackson <ajax at redhat.com>
- spec-only fix: exit builtin needs a numeric arg, not string.


moto4lin-0.3-11.fc10
--------------------
* Sun Oct 19 18:00:00 2008 Sean Reifschneider <jafo at tummy.com> - 0.3-11
- Updating release to build new version.


perl-PDF-API2-0.71.001-2.fc10
-----------------------------
* Sun Oct 19 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.71.001-2
- bump for cvs tag

* Sun Oct 19 18:00:00 2008 Bernard Johnson <bjohnson at symetrix.com> - 0.71.001-1
- v 0.71.001


perl-mogilefs-server-2.20-4.fc10
--------------------------------
* Sun Oct 19 18:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.20-4
- Add the 'None' backend

* Sun Oct 19 18:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.20-3
- Remove the included dependencies before building, not after

* Sun Oct 19 18:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.20-2
- Remove included dependencies

* Sun Oct 19 18:00:00 2008 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.20-1
- Upstream released new version


polyml-5.2-1.fc10
-----------------
* Sun Oct 19 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - 5.2-1
- new release 5.2


python-basemap-0.99-4.fc10
--------------------------
* Sun Oct 19 18:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.99-4
- Update -setup.py patch for geos 3.0.1

* Sun Oct 19 18:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.99-3
- Rebuild for new geos, fixes broken deps


qgis-0.11.0-3.fc10
------------------
* Sun Oct 19 18:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.11.0-3
- Rebuild for new geos, fixes broken deps


seahorse-2.24.1-1.fc10
----------------------
* Sun Oct 19 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.24.1-1
- Update to 2.24.1


seahorse-plugins-2.24.1-2.fc10
------------------------------
* Sun Oct 19 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> 2.24.1-2
- Update to 2.24.1


squid-3.0.STABLE9-2.fc10
------------------------
* Sun Oct 19 18:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> - 7:3.0.STABLE9-2
- disable coss support, not officially supported in 3.0

* Sun Oct 19 18:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> - 7:3.0.STABLE9-1
- update to latest upstream


ucview-0.22-2.fc10
------------------
* Sun Oct 19 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 0.22-2
- Rebuild against unicap 0.93


util-vserver-0.30.215-6.fc10
----------------------------

xorg-x11-drv-ati-6.9.0-28.fc10
------------------------------
* Sun Oct 19 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-28
- fix set tex offset for non modesetting cases


xorg-x11-server-1.5.2-7.fc10
----------------------------
* Mon Oct 20 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.2-7
- xserver-1.5.2-no-duplicate-devices.patch: don't re-add devices through HAL
  if they are already added (#467462).

* Sun Oct 19 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.2-6
- Update xserver-1.5.2-disable-kbd-mouse.patch: if no config file is present,
  we need to force AllowEmptyInput on.


Summary:
Added Packages: 2
Removed Packages: 0
Modified Packages: 31
Broken deps for i386
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From gilboad at gmail.com  Mon Oct 20 10:37:59 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 20 Oct 2008 12:37:59 +0200
Subject: Chaning the default icewm theme.
Message-ID: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>

Hello all,

I maintain the icewm package under both Fedora and EPEL.
A couple of months ago I modified an existing theme to mimic the look of
Clearlooks and I'm thinking about using it as the default theme in the
next release of IceWM for both platforms.

A couple of problems/questions:
1. Should I include the theme in the main icewm package and use it as
the default theme? The theme is rather small (~27K compressed. ~600K
expanded.)
2. The Fedora theme uses the Fedora icon as it's "start" button. I tried
contacting the Fedora-legal theme and get their permission to use this
icon - but got no replays. Do I require explicit permissions to use this
icon? (I've got the same problem in RHEL/CentOS - but I'll ask the same
question in the EPEL ML.)
3. I was thinking about circumventing the legal/distribution issue by
adding a BR to the default theme on each of the platforms and use the %
post scripts to create a symbolic link between the platform's "logo" and
the missing image within my theme (An ideal solution - the theme will
auto-magically use what-ever logo your
distribution/clone/liveCD/respin/etc is using), however, I couldn't find
any common ground between the different platforms. Where does Fedora
keep it's icons? RHEL/CentOS?

Thanks in advance,
- Gilboa



From sundaram at fedoraproject.org  Mon Oct 20 10:44:30 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 20 Oct 2008 16:14:30 +0530
Subject: Chaning the default icewm theme.
In-Reply-To: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>
References: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>
Message-ID: <48FC610E.6000604@fedoraproject.org>

Gilboa Davara wrote:
> Hello all,
> 
> I maintain the icewm package under both Fedora and EPEL.
> A couple of months ago I modified an existing theme to mimic the look of
> Clearlooks and I'm thinking about using it as the default theme in the
> next release of IceWM for both platforms.

Why not something based on Nodoka instead?

> 
> A couple of problems/questions:
> 1. Should I include the theme in the main icewm package and use it as
> the default theme? The theme is rather small (~27K compressed. ~600K
> expanded.)

Separate package is probably a good idea for people with other preferences.

> 2. The Fedora theme uses the Fedora icon as it's "start" button. I tried
> contacting the Fedora-legal theme and get their permission to use this
> icon - but got no replays. Do I require explicit permissions to use this
> icon? (I've got the same problem in RHEL/CentOS - but I'll ask the same
> question in the EPEL ML.)

Drop a mail to logo AT fedoraproject.org as indicated in 
http://fedoraproject.org/wiki/Logo

> 3. I was thinking about circumventing the legal/distribution issue 

Don't circumvent it.

Rahul



From karsten at redhat.com  Mon Oct 20 11:05:31 2008
From: karsten at redhat.com (Karsten Hopp)
Date: Mon, 20 Oct 2008 13:05:31 +0200
Subject: Status of libtool 2.2.X?
In-Reply-To: <a9d183c80810180904l24c9a894s7c1ae6230edcf071@mail.gmail.com>
References: <48ECE6CC.6030001@cora.nwra.com>	<20081008171428.GA7911@nostromo.devel.redhat.com>	<20081008171607.GE3447@yoda.jdub.homelinux.org>	<48ECEFB9.1080600@redhat.com>
	<48F5C75A.9040603@redhat.com>
	<a9d183c80810180904l24c9a894s7c1ae6230edcf071@mail.gmail.com>
Message-ID: <48FC65FB.4060309@redhat.com>

Thomas Moschny schrieb:
> 2008/10/15 Karsten Hopp <karsten at redhat.com>:
>> I've uploaded the current logs to http://karsten.fedorapeople.org/
>> After a quick glance at them I think that there are quite a few easy fixes,
> 
> from libtool2-failures/monotone-0.41-1.fc10.txt:
> 
> [...]
> + emacs -batch -f batch-byte-compile
> /var/tmp/monotone-0.41-1.fc10.src.rpm-root/usr/share/emacs/site-lisp
> [...]
> Loading /usr/share/emacs/site-lisp/site-start.d/uim-init.el (source)...
> uim.el: starting uim-el-helper-agent...
> uim.el: uim-el-helper-agent is unreponsive.  Giving up.
> error: Bad exit status from
> /var/tmp/monotone-0.41-1.fc10.src.rpm/rpm-tmp.6uZuL9 (%install)
> 
> Doesn't look like a libtool issue. This can be fixed by adding
> something like '-no-site-file -no-init-file', I guess?
> 
> - Thomas
> 

You're right, libtool isn't involved in that failure. I'll remove monotone
from my list.


     Karsten



From gilboad at gmail.com  Mon Oct 20 11:17:17 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 20 Oct 2008 13:17:17 +0200
Subject: Chaning the default icewm theme.
In-Reply-To: <48FC610E.6000604@fedoraproject.org>
References: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>
	<48FC610E.6000604@fedoraproject.org>
Message-ID: <1224501437.23491.20.camel@gilboa-home-dev.localdomain>

On Mon, 2008-10-20 at 16:14 +0530, Rahul Sundaram wrote:
> Gilboa Davara wrote:
> > Hello all,
> > 
> > I maintain the icewm package under both Fedora and EPEL.
> > A couple of months ago I modified an existing theme to mimic the look of
> > Clearlooks and I'm thinking about using it as the default theme in the
> > next release of IceWM for both platforms.
> 
> Why not something based on Nodoka instead?

To be honest, I don't really like Nodoka (/Ducks) - plus, while I did
find a good base for a Clearlooks theme made for Ubuntu (/Ducks once
again), I didn't really find anything that was even close to looking
like Nodoka. (Goes to check again)
Plus, at least for now, I rather have one theme across all platforms.

> 
> > 
> > A couple of problems/questions:
> > 1. Should I include the theme in the main icewm package and use it as
> > the default theme? The theme is rather small (~27K compressed. ~600K
> > expanded.)
> 
> Separate package is probably a good idea for people with other preferences.

OK. /-1 on the main package idea.
Though, I should add that:
A. icewm comes by default with a number of rather basic themes .
B. The default theme is rather... no-so-pretty. (RedHat Linux 4 anyone?)

> 
> > 2. The Fedora theme uses the Fedora icon as it's "start" button. I tried
> > contacting the Fedora-legal theme and get their permission to use this
> > icon - but got no replays. Do I require explicit permissions to use this
> > icon? (I've got the same problem in RHEL/CentOS - but I'll ask the same
> > question in the EPEL ML.)
> 
> Drop a mail to logo AT fedoraproject.org as indicated in 
> http://fedoraproject.org/wiki/Logo

Already did (twice?). Didn't really get an answer :(

> 
> > 3. I was thinking about circumventing the legal/distribution issue 
> 
> Don't circumvent it.

Lets try it again.
Assuming that my theme can auto-locate the distribution's logo and use
it. What's wrong with that? Legal issues aside, shouldn't icewm/CentOS
look somewhat different than icewm/RHEL or icewm/Fedora?

> 
> Rahul
> 

- Gilboa



From sundaram at fedoraproject.org  Mon Oct 20 11:29:26 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 20 Oct 2008 16:59:26 +0530
Subject: Chaning the default icewm theme.
In-Reply-To: <1224501437.23491.20.camel@gilboa-home-dev.localdomain>
References: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>	<48FC610E.6000604@fedoraproject.org>
	<1224501437.23491.20.camel@gilboa-home-dev.localdomain>
Message-ID: <48FC6B96.70009@fedoraproject.org>

Gilboa Davara wrote:

> Plus, at least for now, I rather have one theme across all platforms.
>  Drop a mail to logo AT fedoraproject.org as indicated in 
>> http://fedoraproject.org/wiki/Logo
> 
> Already did (twice?). Didn't really get an answer :(

Send a mail to fedora-art list then.

>>> 3. I was thinking about circumventing the legal/distribution issue 
>> Don't circumvent it.
> 
> Lets try it again.
> Assuming that my theme can auto-locate the distribution's logo and use
> it. What's wrong with that? Legal issues aside, shouldn't icewm/CentOS
> look somewhat different than icewm/RHEL or icewm/Fedora?

I don't see any reason why it should look different.

Rahul









From gilboad at gmail.com  Mon Oct 20 12:30:29 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 20 Oct 2008 14:30:29 +0200
Subject: Chaning the default icewm theme.
In-Reply-To: <48FC6B96.70009@fedoraproject.org>
References: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>
	<48FC610E.6000604@fedoraproject.org>
	<1224501437.23491.20.camel@gilboa-home-dev.localdomain>
	<48FC6B96.70009@fedoraproject.org>
Message-ID: <1224505829.23491.32.camel@gilboa-home-dev.localdomain>

On Mon, 2008-10-20 at 16:59 +0530, Rahul Sundaram wrote:
> Gilboa Davara wrote:
> 
> > Plus, at least for now, I rather have one theme across all platforms.
> >  Drop a mail to logo AT fedoraproject.org as indicated in 
> >> http://fedoraproject.org/wiki/Logo
> > 
> > Already did (twice?). Didn't really get an answer :(
> 
> Send a mail to fedora-art list then.

OK. If all else fails, I'll do it.
Any idea who can help me get access to RH's hat icon?

> 
> >>> 3. I was thinking about circumventing the legal/distribution issue 
> >> Don't circumvent it.
> > 
> > Lets try it again.
> > Assuming that my theme can auto-locate the distribution's logo and use
> > it. What's wrong with that? Legal issues aside, shouldn't icewm/CentOS
> > look somewhat different than icewm/RHEL or icewm/Fedora?
> 
> I don't see any reason why it should look different.
> 
> Rahul

... Because in KDE and GNOME the "start button" uses the distribution's
icon in both KDE and GNOME.
GNOME: [1], [2], [3] (Fedora, RHEL, CentOS)
KDE: [4], [5], [6] (Fedora, RHEL, CentOS)

- Gilboa
[1] http://news.softpedia.com/images/extra/LINUX/large/fedora9installationguide-large_027.png
[2] http://www.linux-mag.com/images/2007-04/redhat/Screenshot2.png
[3] http://it.seas.harvard.edu/operations/support/services/network-connectivity/screenshots_centos/centos5_open_terminal.png
[4] http://upload.wikimedia.org/wikipedia/commons/d/de/Fedora9-KDE4.png
[5] http://lh5.ggpht.com/_txTorNiMelE/Rt12LIPzEgI/AAAAAAAAAEc/6X_mDq_X9AU/snapshot1.png
[6] http://www.linuxworld.co.uk/images/linux/centos-linux.jpg




From lesmikesell at gmail.com  Mon Oct 20 12:50:08 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 07:50:08 -0500
Subject: Sendmail still default?
In-Reply-To: <6a8fd7f24a34de9d67203f9be447c98e.squirrel@arekh.dyndns.org>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>
	<6a8fd7f24a34de9d67203f9be447c98e.squirrel@arekh.dyndns.org>
Message-ID: <48FC7E80.6040300@gmail.com>

Nicolas Mailhot wrote:
> 
> Le Dim 19 octobre 2008 16:47, Les Mikesell a ?crit :
>> David Woodhouse wrote:
>>> On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
>>>>> Milter is supported by alternatives too
>>>> They pretend to, but won't actually run complex milters like
>>>> MimeDefang.
>>> Some of the better alternatives don't even _try_ to run milters,
>>> because
>>> they are fully-featured enough in their own right, without needing
>>> to
>>> rely on external software.
>> Which means that you can't run your choice of tests on a message
>> during
>> the smtp conversation before you accept it - at least without starting
>> a
>> new process for each one which is expensive for large programs like
>> spamassassin.
> 
> Actually, you don't need milters to do this in postfix (but you can
> use milters if you prefer)

If you do it without milters, can you get the efficiency factor that 
MimeDefang manages by unpacking the mime parts only once even if you do 
multiple scans for spam and viruses?  Can it multiplex a small number of 
milter backends doing 'slow' steps with a much larger number of mailers 
doing fast operations? (MimeDefang may be the only milter designed for 
that).

-- 
   Les Mikesell
    lesmikesell at gmail.com






From limb at jcomserv.net  Mon Oct 20 12:56:26 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 20 Oct 2008 07:56:26 -0500 (CDT)
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
Message-ID: <39052.198.175.55.5.1224507386.squirrel@mail.jcomserv.net>


> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
>
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
>
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?

+1.

> -Toshio
>
> --
> 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 20 13:03:50 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 08:03:50 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020042636.GA1073485@hiwaay.net>
References: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>
	<48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<1224467293.15123.54.camel@code.and.org>	<20081019210620.66572efb@infradead.org>
	<20081020042636.GA1073485@hiwaay.net>
Message-ID: <48FC81B6.7020503@gmail.com>

Chris Adams wrote:
> Once upon a time, Arjan van de Ven <arjan at infradead.org> said:
>> most users on the client side use a mail client that has its own
>> queuing.
> 
> Most _interactive_ users do.  Most automated tasks (e.g. cron) do not
> have any queueing.

Even if you are trying to dumb the system down to a Mac's 
pseudo-single-user style, you still need crontab and mail to work - as 
it does on a Mac.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Oct 20 13:08:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 08:08:59 -0500
Subject: Sendmail still default?
In-Reply-To: <1224454525.30024.32.camel@hopeson>
References: <48F87794.3090108@redhat.com>
	<gdb9bj$jc9$2@ger.gmane.org>	<1224341699.21581.115.camel@rosebud>
	<48FA16D3.5020204@gmail.com>	<1224362077.21581.123.camel@rosebud>
	<48FA4C07.6010304@gmail.com>	<1224363427.21581.130.camel@rosebud>
	<48FA5183.1020407@gmail.com> <1224454525.30024.32.camel@hopeson>
Message-ID: <48FC82EB.7000401@gmail.com>

Simo Sorce wrote:
> On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
> 
>> And in any case, using MimeDefang as a sendmail milter eliminates most 
>> of the complaints anyone would have with sendmail itself since it lets 
>> you do the complex parts with control handled in perl instead of 
>> sendmail's internal language.
> 
> Man, if you imply perl is anything better, no wonders you defend
> sendmail :-)
> 

Perl has done a lot of work for me (and lots of others) over the last 
couple of decades, while most of the languages that claim to be better 
haven't been able to work consistently from one year to the next, making 
you rewrite everything because they can't pick a syntax that works. 
Perl has only had one real syntax change from version 1 though 5, when 
it started interpolating @ in double-quoted strings.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Mon Oct 20 13:11:08 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 08:11:08 -0500
Subject: Sendmail still default?
In-Reply-To: <200810200918.19031.opensource@till.name>
References: <48F87794.3090108@redhat.com> <gdb9bj$jc9$2@ger.gmane.org>
	<200810200918.19031.opensource@till.name>
Message-ID: <48FC836C.7000200@gmail.com>

Till Maas wrote:
> On Sat October 18 2008, Matthew Woehlke wrote:
> [E-mail was changed]
> 
>> Um... which is actually another reason for local mail being default; in
>> the event a user's mail recipient is not configured, it goes to a local
>> spool only readable by root and that user. If Sue sets up a computer and
>> adds an account for Bob, it's not really ideal if Bob's mail gets sent
>> to sue at EXAMPLE.com because Bob doesn't have a recipient specified.
> 
> Sending log file contents that may contain sensitive data via unencrypted 
> e-mail is not a good thing to do imho.

Modern MTA's can encrypt transmission if configured to.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dtardon at redhat.com  Mon Oct 20 13:22:02 2008
From: dtardon at redhat.com (David Tardon)
Date: Mon, 20 Oct 2008 15:22:02 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
Message-ID: <20081020132159.GA7606@localhost.localdomain>

On Sun, Oct 19, 2008 at 09:18:11AM -0700, Toshio Kuratomi wrote:
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
> 
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
> 
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?
> 
> -Toshio
> 

What about rootpackager? :)

David



From limb at jcomserv.net  Mon Oct 20 13:26:52 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 20 Oct 2008 08:26:52 -0500 (CDT)
Subject: yafray "renamed" to yafaray - pick it ?
In-Reply-To: <68720af30810190659i4160a7d8p78848bb582528be3@mail.gmail.com>
References: <48F35B08.3040600@gmail.com>
	<62511.198.175.55.5.1223917793.squirrel@mail.jcomserv.net>
	<e1760170810131048t2ee7f4d9lfc417b28fa14d02a@mail.gmail.com>
	<68720af30810161546r55482d2eq3b26052b566e18a2@mail.gmail.com>
	<27678.198.175.55.5.1224255694.squirrel@mail.jcomserv.net>
	<26499.198.175.55.5.1224256924.squirrel@mail.jcomserv.net>
	<68720af30810171856ucad1d58ufc5ca16b28d81378@mail.gmail.com>
	<68720af30810181832h1439d931qb687edc23aa23c7e@mail.gmail.com>
	<e1760170810190519m4bbe150cre8e82bc5d7ddfb1f@mail.gmail.com>
	<68720af30810190659i4160a7d8p78848bb582528be3@mail.gmail.com>
Message-ID: <64844.198.175.55.5.1224509212.squirrel@mail.jcomserv.net>


> On Sun, Oct 19, 2008 at 10:19 AM, KH KH <kwizart at gmail.com> wrote:
>
>> 2008/10/19 Paulo Cavalcanti <promac at gmail.com>:
>>
>> >
>> > Well, I fixed it:
>> >
>> > http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-3.fc9.src.rpm<http://people.atrpms.net/%7Epcavalcanti/srpms/yafaray-0.1.0-3.fc9.src.rpm>
>> >
>> > It builds just fine in F9 now.
>> >
>> > I hope it can help you.
>> Hi Paulo!
>>
>> I think this package should follow the usual package review process now.
>> It would be fine to close this topic, here on the mailing list, with
>> the bugzilla review request;
>> then, anyone can follow the conversation on the review.
>> But I think yafray and yafaray should co-exist for now.
>>
>> Now, you will need to get sponsored for the package to be.
>> In the yafaray case, I would like to review it , as there is some
>> improvements required.
>> But your spec should be a good start.
>>
>>
> Hi,
>
> in fact, according to my tests, yafray and yafaray can coexist. They use
> different Blender menus.
>
> However, yafaray needs to be integrated into blender. To accomplish this,
> there is a new rpm,
> yafaray-blender, that copies the appropriate scripts and libraries to
> /usr/share/blender/scripts.
>
> http://www.yafray.org/forum/viewtopic.php?t=1701
>
> This additional rpm is created automatically within the new yafaray
> .src.rpm:
>
> http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-4.fc8.src.rpm
>
> This new .src.rpm builds fine with mock for F8 and F9.
>
> It would be really nice to have yafaray in Fedora, maybe for F10, since
> Ubuntu already has it:
>
> http://www.yafray.org/index.php?s=2
>
> If you can review the package it will be good, but I think we need some
> blender users to make
> a thorough evaluation.

Nicolas, I will be happy to assist with the review, and sponsor Paulo once
the requisite bits are done.  Paulo, please make sure to CC Nicolas and
myself on the review request bug.

> Thanks.
>
> --
> Paulo Roma Cavalcanti
> LCG - UFRJ
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From a.badger at gmail.com  Mon Oct 20 13:33:28 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 20 Oct 2008 06:33:28 -0700
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <1224496369.6770.1544.camel@macbook.infradead.org>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
Message-ID: <48FC88A8.4010003@gmail.com>

David Woodhouse wrote:
> On Sun, 2008-10-19 at 09:18 -0700, Toshio Kuratomi wrote:
>> So I'm going to do this tomorrow or have to put it off until after
>> change freeze.
>>
>> The name I personally favour is masterpackager since it evokes the
>> apprentice, journeyman, master craftsman stages that seem most like what
>> we're modeling here.
>>
>> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
>> can everyone live with this?
> 
> No, I'm offended by the idea that a common root used in many geek words
> can so easily be declared 'unclean' and eradicated. This is political
> correctness at its worst, and I find it horrifically offensive. And
> that's a _current_ issue, not one from the previous millennium.
> 
> I have no particular attachment to the '?berpackager' name, but I object
> strongly to the change on _principle_. Please leave it as it was.
> 
I'll comment on this:

I kinda agree with you on the principle of the thing.

However, I also just plain don't like uberpackager.  uber has the
connotation of "superior" where I think the group name should be
shooting for the meanings of "more experienced", "proven" and "trusted".

So "ultrapackager", "superpackager", and other prefixes that mean
"superior" would be changing the name just because we want to
self-censor our use of the prefix "uber" due to feeling the word is unclean.

I see changing to "masterpackager", "provenpackager", "trustedpackager",
"experiencedpackager" as a change to be closer to what differentiates
the group from "packager".  The fact that it doesn't have the
connotations of uber that started the discussion is an additional plus.

Note that if tibbs is serious about the master/slave connotation, I'd be
happy to change to "provenpackager" instead of "masterpackager" at this
time.  But once the change is made, I'd be less inclined to change since
it would be a change just for the political correctness aspect, not to
be closer to the true meaning of the group.

-Toshio

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

From enrico.scholz at informatik.tu-chemnitz.de  Mon Oct 20 13:50:03 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Mon, 20 Oct 2008 15:50:03 +0200
Subject: Sendmail still default?
In-Reply-To: <48FB7694.4050400@gmail.com> (Les Mikesell's message of "Sun,
	19 Oct 2008 13:04:04 -0500")
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com>
Message-ID: <87od1fnzp0.fsf@fc5.bigo.ensc.de>

Les Mikesell <lesmikesell at gmail.com> writes:

> One of my choices of tests on an inbound relay machine has been to
> check that the user exists using an smtp check against the internal
> delivery host.  How would I do that on an MTA that does not handle
> milters?

Milters are bad for rcpt verification (at least in sendmail) because they
happen before alias/virtusertable expansion. Custom 'Local_check_rcpt'
rules plus tables like

| Kdom0_lookup     hash -o /etc/mail/dom0-users
| Kdom1_lookup socket inet:480 at mail-filter

are better and easier to implement.


Enrico



From katzj at redhat.com  Mon Oct 20 13:54:10 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Oct 2008 09:54:10 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224352773.4219.3.camel@luminos.localdomain>
References: <17507.82.95.253.31.1224352368.squirrel@webmail.xs4all.nl>
	<1224352773.4219.3.camel@luminos.localdomain>
Message-ID: <1224510850.19054.18.camel@aglarond.local>

On Sat, 2008-10-18 at 10:59 -0700, Jesse Keating wrote:
> On Sat, 2008-10-18 at 19:52 +0200, Stefan Hartsuiker wrote:
> > I know and that was not the reason for my confusion :)
> > What I understood from Till's first sentence above, is that he would like a
> > dvd that has a bootloader that can use the enclosed cd iso's as an
> > installation source. This then would imply that it only works if the system
> > can actually already boot from the dvd? Therefore it seems to me a bit
> > pointless.
> 
> Fedora would distribute one piece of media.  You would either boot from
> it and install, or you would mount it (loop back) and burn the CD sized
> isos held within, to boot from those and install from them.

You can't (easily) loopback mount on other OS's which would make burning
the CD images a lot harder for people if they were only embedded within
the DVD image.

Jeremy



From katzj at redhat.com  Mon Oct 20 13:58:01 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Oct 2008 09:58:01 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <200810180104.18321.opensource@till.name>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<200810180104.18321.opensource@till.name>
Message-ID: <1224511081.19054.23.camel@aglarond.local>

On Sat, 2008-10-18 at 01:04 +0200, Till Maas wrote:
> On Fri October 17 2008, Jesse Keating wrote:
> > Most torrent clients I've seen today allow you to pick and choose which
> > files you wish to download.  As such, does it make sense to collapse the
> > DVD and CD torrents into a single torrent and allow people to use the
> > client to pick which they want?  Are there pros/cons to this?
> 
> I have a probably crazy idea: How about composing the DVD iso using a 
> filesystem that contains the CD isos and a bootloader that can use the CD 
> isos as installation source? Then a little bit of space of the DVD iso would 
> be wasted and it would take a little more effort to burn only the CD isos, 
> but then only one torrent would be needed and everyone can easily share 
> bandwidth with everyone else.

It's quite a bit more effort to burn them if you're trying to burn from
a non-Linux platform.

Also, it means that DVD vs CD become significantly different install
paths requiring different code and a lot different testing :-/

Jeremy



From katzj at redhat.com  Mon Oct 20 14:00:56 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Oct 2008 10:00:56 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <200810191314.20208.opensource@till.name>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<200810180104.18321.opensource@till.name>
	<1224286760.4142.46.camel@luminos.localdomain>
	<200810191314.20208.opensource@till.name>
Message-ID: <1224511256.19054.26.camel@aglarond.local>

On Sun, 2008-10-19 at 13:14 +0200, Till Maas wrote:
> On Sat October 18 2008, Jesse Keating wrote:
> > On Sat, 2008-10-18 at 01:04 +0200, Till Maas wrote:
> > > I have a probably crazy idea: How about composing the DVD iso using a
> > > filesystem that contains the CD isos and a bootloader that can use the CD
> > > isos as installation source? Then a little bit of space of the DVD iso
> > > would be wasted and it would take a little more effort to burn only the
> > > CD isos, but then only one torrent would be needed and everyone can
> > > easily share bandwidth with everyone else.
> >
> > Split media installs (which that would result in for even the DVD case)
> > has some interesting side-effects, that really hurt when trying to add
> > external repos (particularly of updates) at install time.  I wouldn't
> > want to force it upon everybody.
> 
> Would it be possible to not do a split media installation, but to configure 
> the kernel to allow more than 8 loop devices (if it is not already possible), 
> to loop mount all CD iso images and to configure each as a seperate repo for 
> anaconda, so that anaconda can access the contens of all iso images at once?

Each CD isn't its own separate repo.  Doing so would mean that we would
a) require you to put in each CD before letting you select your packages
and b) mean that the repos were pretty inconsistent internally.
Instead, each CD is a part of one repo and there's some knowledge
encoded in the metadata as to which disc each package is on.  

And while anything is possible, as I mentioned, doing something like
this (having the CD isos just loopback mounted off the DVD) would make
DVD vs CD installs substantially different in terms of how the code
works.  And that code is twisty turny enough as it is

Jeremy



From katzj at redhat.com  Mon Oct 20 14:01:37 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Oct 2008 10:01:37 -0400
Subject: Fedora 10 Snapshot 2
In-Reply-To: <48FC490C.6020509@redhat.com>
References: <1224272190.4142.22.camel@luminos.localdomain>
	<48FC490C.6020509@redhat.com>
Message-ID: <1224511297.19054.27.camel@aglarond.local>

On Mon, 2008-10-20 at 11:02 +0200, Gerd Hoffmann wrote:
> Jesse Keating wrote:
> > This week brings us Fedora 10 Snapshot 2.  This time not only will we
> > have Live images, we'll also have DVD and split CD install images.  Due
> > to the amount of data to sync around, we're going to stagger the torrent
> > releases, making them available as they finish syncing to the torrent
> > server.  Please keep watching http://torrent.fedoraproject.org/ for new
> > torrents to start showing up in the next few hours.
> 
> How about jigdo?  With the Beta DVD iso images at hand jigdo-lite has to
> fetch only the packages changed since then, which is probably a small
> fraction of the complete set ...

jigdo only helps if the packages continue to be available -- with the
amount that rawhide churns, packages that are there for the snapshot
today are quite possibly gone tomorrow

Jeremy



From lesmikesell at gmail.com  Mon Oct 20 15:31:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 10:31:49 -0500
Subject: Sendmail still default?
In-Reply-To: <87od1fnzp0.fsf@fc5.bigo.ensc.de>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>
	<87od1fnzp0.fsf@fc5.bigo.ensc.de>
Message-ID: <48FCA465.5090602@gmail.com>

Enrico Scholz wrote:
> Les Mikesell <lesmikesell at gmail.com> writes:
> 
>> One of my choices of tests on an inbound relay machine has been to
>> check that the user exists using an smtp check against the internal
>> delivery host.  How would I do that on an MTA that does not handle
>> milters?
> 
> Milters are bad for rcpt verification (at least in sendmail) because they
> happen before alias/virtusertable expansion. Custom 'Local_check_rcpt'
> rules plus tables like

In my case, this happens on external relays that have neither aliases 
nor users of its own.  The idea is to make sure the internal target 
would accept the address as a user or alias without having to update the 
external relay's virtuser database every time an internal user or alias 
changes.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pknirsch at redhat.com  Mon Oct 20 15:34:06 2008
From: pknirsch at redhat.com (Phil Knirsch)
Date: Mon, 20 Oct 2008 17:34:06 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FC81B6.7020503@gmail.com>
References: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>	<48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<1224467293.15123.54.camel@code.and.org>	<20081019210620.66572efb@infradead.org>	<20081020042636.GA1073485@hiwaay.net>
	<48FC81B6.7020503@gmail.com>
Message-ID: <48FCA4EE.5000709@redhat.com>

Les Mikesell wrote:
> Chris Adams wrote:
>> Once upon a time, Arjan van de Ven <arjan at infradead.org> said:
>>> most users on the client side use a mail client that has its own
>>> queuing.
>>
>> Most _interactive_ users do.  Most automated tasks (e.g. cron) do not
>> have any queueing.
> 
> Even if you are trying to dumb the system down to a Mac's 
> pseudo-single-user style, you still need crontab and mail to work - as 
> it does on a Mac.
> 

What happens to emails generated on a Max OSX via crontab or any other 
automated system? Does it run sendmail or some equivalent of it?

Just curious how they solve it as on a Mac i'd bet you that hardly any 
typical user will know what root is.

Regards, 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  | IT executives: Red Hat #1 in value. Again.
                             | http://www.redhat.com/promo/vendor/



From chris.stone at gmail.com  Mon Oct 20 15:43:49 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 20 Oct 2008 08:43:49 -0700
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC88A8.4010003@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<48FC88A8.4010003@gmail.com>
Message-ID: <d9c612bf0810200843x10a986a0h20be3c7848d88170@mail.gmail.com>

2008/10/20 Toshio Kuratomi <a.badger at gmail.com>

> David Woodhouse wrote:
> > On Sun, 2008-10-19 at 09:18 -0700, Toshio Kuratomi wrote:
> >> So I'm going to do this tomorrow or have to put it off until after
> >> change freeze.
> >>
> >> The name I personally favour is masterpackager since it evokes the
> >> apprentice, journeyman, master craftsman stages that seem most like what
> >> we're modeling here.
> >>
> >> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> >> can everyone live with this?
> >
> > No, I'm offended by the idea that a common root used in many geek words
> > can so easily be declared 'unclean' and eradicated. This is political
> > correctness at its worst, and I find it horrifically offensive. And
> > that's a _current_ issue, not one from the previous millennium.
> >
> > I have no particular attachment to the '?berpackager' name, but I object
> > strongly to the change on _principle_. Please leave it as it was.
> >
> I'll comment on this:
>
> I kinda agree with you on the principle of the thing.
>
> However, I also just plain don't like uberpackager.  uber has the
> connotation of "superior" where I think the group name should be
> shooting for the meanings of "more experienced", "proven" and "trusted".
>
> So "ultrapackager", "superpackager", and other prefixes that mean
> "superior" would be changing the name just because we want to
> self-censor our use of the prefix "uber" due to feeling the word is
> unclean.
>
> I see changing to "masterpackager", "provenpackager", "trustedpackager",
> "experiencedpackager" as a change to be closer to what differentiates
> the group from "packager".  The fact that it doesn't have the
> connotations of uber that started the discussion is an additional plus.
>
> Note that if tibbs is serious about the master/slave connotation, I'd be
> happy to change to "provenpackager" instead of "masterpackager" at this
> time.  But once the change is made, I'd be less inclined to change since
> it would be a change just for the political correctness aspect, not to
> be closer to the true meaning of the group.
>
> -Toshio
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

qualitypackger (for quality assurance)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/7557ea5f/attachment.htm>

From jkeating at redhat.com  Mon Oct 20 15:51:16 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 20 Oct 2008 08:51:16 -0700
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224437757.25549.9.camel@ghandalf.kanarip.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<1224437757.25549.9.camel@ghandalf.kanarip.com>
Message-ID: <1224517876.4219.11.camel@luminos.localdomain>

On Sun, 2008-10-19 at 19:35 +0200, Jeroen van Meeuwen wrote:
> Not having read the entire thread yet, will collapsing CD/DVD torrents
> allow you to track the number of completed downloads accurately for each
> of these two categories?

That's a good point, I don't think we would be able to.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/9d3e6927/attachment.sig>

From dwmw2 at infradead.org  Mon Oct 20 16:02:01 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 20 Oct 2008 17:02:01 +0100
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC88A8.4010003@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<48FC88A8.4010003@gmail.com>
Message-ID: <1224518521.16910.22.camel@macbook.infradead.org>

On Mon, 2008-10-20 at 06:33 -0700, Toshio Kuratomi wrote:
> However, I also just plain don't like uberpackager.  uber has the
> connotation of "superior" where I think the group name should be
> shooting for the meanings of "more experienced", "proven" and
> "trusted".

To be honest, that sounds like onanistic political correctness too, and
is almost as offensive to me as the other reason for changing it.

-- 
dwmw2



From kevin.kofler at chello.at  Mon Oct 20 16:04:12 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 20 Oct 2008 16:04:12 +0000 (UTC)
Subject: Chaning the default icewm theme.
References: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>
Message-ID: <loom.20081020T155258-733@post.gmane.org>

Gilboa Davara <gilboad <at> gmail.com> writes:
> 2. The Fedora theme uses the Fedora icon as it's "start" button. I tried
> contacting the Fedora-legal theme and get their permission to use this
> icon - but got no replays. Do I require explicit permissions to use this
> icon? (I've got the same problem in RHEL/CentOS - but I'll ask the same
> question in the EPEL ML.)

You cannot distribute the Fedora logo or the Red Hat red hat as part of your 
theme. The logo has to be in the fedora-logos package (for RHEL, that would be 
the redhat-logos package, but good luck getting an icon added there - most 
likely it would only be added if your theme ends up in an RHEL release and so 
the icon is needed, likewise centos-logos will probably only add the icon if 
your theme is actually shipped in CentOS, not EPEL or something) and some 
fallback has to be provided, either inside the theme if it is possible, or in 
generic-logos.

The way it's done in KDE 4 is that:
* kde-settings contains a Fedora-KDE icon theme which inherits from Oxygen and 
which is shipped empty. So by default (*), you get the KDE logo from Oxygen as 
the start button. Fedora-KDE is also set as the default icon theme for KDE by 
kde-settings.
* fedora-logos drops the Fedora logo into that icon theme, so it overrides 
Oxygen's KDE logo.
* In our case, no fallback icon is needed in generic-logos because icon theme 
inheritance takes care of it automatically.

(*) but that default is only invoked in the absence of fedora-logos

One thing you can do for RHEL/CentOS (which should also work in Fedora) is to 
find an icon in redhat-logos which has a fallback with the same file name in 
generic-logos (and fedora-logos and centos-logos), then just symlink to that 
and add a Requires: system-logos. But you can't use your own fallback (e.g. 
IceWM logo) that way, you get whatever is in generic-logos.

        Kevin Kofler



From icon at fedoraproject.org  Mon Oct 20 16:09:33 2008
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Mon, 20 Oct 2008 12:09:33 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <d9c612bf0810200843x10a986a0h20be3c7848d88170@mail.gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<48FC88A8.4010003@gmail.com>
	<d9c612bf0810200843x10a986a0h20be3c7848d88170@mail.gmail.com>
Message-ID: <f8f6300f0810200909u685d038aga1553f3f36756e86@mail.gmail.com>

2008/10/20 Christopher Stone <chris.stone at gmail.com>:
> qualitypackger (for quality assurance)

...and also budgetpackager, comfortpackager, and dayspackager? :)

(I know, but this whole conversation is extremely silly, too)

Cheers,
-- 
Konstantin Ryabitsev
Montr?al, Qu?bec



From kevin.kofler at chello.at  Mon Oct 20 16:06:34 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 20 Oct 2008 16:06:34 +0000 (UTC)
Subject: uberpackager rename (was Re: The Big ACL Opening)
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
Message-ID: <loom.20081020T160448-179@post.gmane.org>

David Woodhouse <dwmw2 <at> infradead.org> writes:
> No, I'm offended by the idea that a common root used in many geek words

... by ignorant Americans who are unaware of the true meaning of that term!

> can so easily be declared 'unclean' and eradicated. This is political
> correctness at its worst, and I find it horrifically offensive. And
> that's a _current_ issue, not one from the previous millennium.

The current issue is that it makes Fedora look ignorant.

        Kevin Kofler



From lesmikesell at gmail.com  Mon Oct 20 16:10:49 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 11:10:49 -0500
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224511256.19054.26.camel@aglarond.local>
References: <1224272955.4142.25.camel@luminos.localdomain>	<200810180104.18321.opensource@till.name>	<1224286760.4142.46.camel@luminos.localdomain>	<200810191314.20208.opensource@till.name>
	<1224511256.19054.26.camel@aglarond.local>
Message-ID: <48FCAD89.4040808@gmail.com>

Jeremy Katz wrote:
> 
> And while anything is possible, as I mentioned, doing something like
> this (having the CD isos just loopback mounted off the DVD) would make
> DVD vs CD installs substantially different in terms of how the code
> works.  And that code is twisty turny enough as it is

Isn't that exactly the way an NFS or HD install works when you point it 
to a directory of CD iso images?  I'd think consolidating the techniques 
would simplify things.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mike at miketc.net  Mon Oct 20 16:11:40 2008
From: mike at miketc.net (Mike Chambers)
Date: Mon, 20 Oct 2008 11:11:40 -0500
Subject: [Fwd: services wizard]
Message-ID: <1224519100.5749.1.camel@scrappy.miketc.net>

Meant to send this to the devel list.  Was just wanting thoughts on how
effective it would be to have them for them all, if not some of them
already.



-------- Forwarded Message --------
> From: Mike Chambers <mike at miketc.net>
> To: Fedora <fedora-list at redhat.com>
> Subject: services wizard
> Date: Sun, 19 Oct 2008 23:56:18 -0500
> 
> Hi there,
> 
> Was thinking and wondering, if it would be good to have configuration
> wizards for services that you want to configure (such as email server
> (sendmail/postfix), http, and so on) that would ask basic questions and
> would go certain directions (or just one way) depending on how much you
> answer?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From behdad at behdad.org  Mon Oct 20 16:11:28 2008
From: behdad at behdad.org (Behdad Esfahbod)
Date: Mon, 20 Oct 2008 12:11:28 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <f8f6300f0810200909u685d038aga1553f3f36756e86@mail.gmail.com>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>	<1224496369.6770.1544.camel@macbook.infradead.org>	<48FC88A8.4010003@gmail.com>	<d9c612bf0810200843x10a986a0h20be3c7848d88170@mail.gmail.com>
	<f8f6300f0810200909u685d038aga1553f3f36756e86@mail.gmail.com>
Message-ID: <48FCADB0.4050803@behdad.org>

Konstantin Ryabitsev wrote:
> 2008/10/20 Christopher Stone <chris.stone at gmail.com>:
>> qualitypackger (for quality assurance)
> 
> ...and also budgetpackager, comfortpackager, and dayspackager? :)
> 
> (I know, but this whole conversation is extremely silly, too)

Then please stop it.

behdad

> Cheers,



From rc040203 at freenet.de  Mon Oct 20 16:19:27 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 20 Oct 2008 18:19:27 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCA4EE.5000709@redhat.com>
References: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com>	<48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
	<20081019210620.66572efb@infradead.org>
	<20081020042636.GA1073485@hiwaay.net> <48FC81B6.7020503@gmail.com>
	<48FCA4EE.5000709@redhat.com>
Message-ID: <1224519567.3300.18.camel@beck.corsepiu.local>

On Mon, 2008-10-20 at 17:34 +0200, Phil Knirsch wrote:
> Les Mikesell wrote:
> > Chris Adams wrote:
> >> Once upon a time, Arjan van de Ven <arjan at infradead.org> said:
> >>> most users on the client side use a mail client that has its own
> >>> queuing.
> >>
> >> Most _interactive_ users do.  Most automated tasks (e.g. cron) do not
> >> have any queueing.
> > 
> > Even if you are trying to dumb the system down to a Mac's 
> > pseudo-single-user style, you still need crontab and mail to work - as 
> > it does on a Mac.
> > 
> 
> What happens to emails generated on a Max OSX via crontab or any other 
> automated system?
No clue about the MACs, but what about "mailx"?

It is mandated by POSIX and should be sufficient for local mail
delivery.

Ralf







From cdahlin at redhat.com  Mon Oct 20 16:48:11 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 20 Oct 2008 12:48:11 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC88A8.4010003@gmail.com>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>	<48FB5DC3.1060409@gmail.com>	<1224496369.6770.1544.camel@macbook.infradead.org>
	<48FC88A8.4010003@gmail.com>
Message-ID: <48FCB64B.3000005@redhat.com>

Toshio Kuratomi wrote:
> David Woodhouse wrote:
>   
>> On Sun, 2008-10-19 at 09:18 -0700, Toshio Kuratomi wrote:
>>     
>>> So I'm going to do this tomorrow or have to put it off until after
>>> change freeze.
>>>
>>> The name I personally favour is masterpackager since it evokes the
>>> apprentice, journeyman, master craftsman stages that seem most like what
>>> we're modeling here.
>>>
>>> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
>>> can everyone live with this?
>>>       
>> No, I'm offended by the idea that a common root used in many geek words
>> can so easily be declared 'unclean' and eradicated. This is political
>> correctness at its worst, and I find it horrifically offensive. And
>> that's a _current_ issue, not one from the previous millennium.
>>
>> I have no particular attachment to the '?berpackager' name, but I object
>> strongly to the change on _principle_. Please leave it as it was.
>>
>>     
> I'll comment on this:
>
> I kinda agree with you on the principle of the thing.
>
> However, I also just plain don't like uberpackager.  uber has the
> connotation of "superior" where I think the group name should be
> shooting for the meanings of "more experienced", "proven" and "trusted".
>
>   
I think that's really missing the joke.

Yes, uber- implies superior, but its meant ironically. Hence the choice 
of such a goofy geek slang. On the surface it means superior, but in 
reality we're poking fun at ourselves.

In that vein, I nominate "packager gold club member"

--CJD



From opensource at till.name  Mon Oct 20 16:49:51 2008
From: opensource at till.name (Till Maas)
Date: Mon, 20 Oct 2008 18:49:51 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <loom.20081020T160448-179@post.gmane.org>
References: <48F64212.2010505@redhat.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<loom.20081020T160448-179@post.gmane.org>
Message-ID: <200810201849.59972.opensource@till.name>

On Monday 20 October 2008 18:06:34 Kevin Kofler wrote:
> David Woodhouse <dwmw2 <at> infradead.org> writes:
> > No, I'm offended by the idea that a common root used in many geek words
>
> ... by ignorant Americans who are unaware of the true meaning of that term!

It is also used by German geeks:
http://www.das-labor.org/wiki/Ubershowcase

And from my first survey here in Germany, I concluded regarding the badness of 
the uber prefix, that the nazis especially formed the term "Untermensch" and 
not the term "?bermensch".

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/20081020/e9b5aeba/attachment.sig>

From dimi at lattica.com  Mon Oct 20 16:55:29 2008
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Oct 2008 12:55:29 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <200810201849.59972.opensource@till.name>
References: <48F64212.2010505@redhat.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<loom.20081020T160448-179@post.gmane.org>
	<200810201849.59972.opensource@till.name>
Message-ID: <1224521729.5342.381.camel@dimi.lattica.com>


On Mon, 2008-10-20 at 18:49 +0200, Till Maas wrote:
> And from my first survey here in Germany, I concluded regarding the
> badness of  the uber prefix, that the nazis especially formed the term
> "Untermensch" and  not the term "?bermensch".

Indeed, I believe it was "untermenchen" and "herrenvolk".

I personally feel this discussion is silly. "Uber" is just fine with me.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From notting at redhat.com  Mon Oct 20 17:08:19 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 20 Oct 2008 13:08:19 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
Message-ID: <20081020170819.GB21020@nostromo.devel.redhat.com>

Toshio Kuratomi (a.badger at gmail.com) said: 
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
> 
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
> 
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?

As long as we're naming the other group blasterpackager.

Bill



From a.badger at gmail.com  Mon Oct 20 17:12:30 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 20 Oct 2008 10:12:30 -0700
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <1224518521.16910.22.camel@macbook.infradead.org>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>	<1224496369.6770.1544.camel@macbook.infradead.org>	<48FC88A8.4010003@gmail.com>
	<1224518521.16910.22.camel@macbook.infradead.org>
Message-ID: <48FCBBFE.3010508@gmail.com>

David Woodhouse wrote:
> On Mon, 2008-10-20 at 06:33 -0700, Toshio Kuratomi wrote:
>> However, I also just plain don't like uberpackager.  uber has the
>> connotation of "superior" where I think the group name should be
>> shooting for the meanings of "more experienced", "proven" and
>> "trusted".
> 
> To be honest, that sounds like onanistic political correctness too, and
> is almost as offensive to me as the other reason for changing it.
> 
Well, it may be wanking but I don't consider it political correctness.
There's a difference in meaning between the words used and one is more
specific and a better description than the other.

Having an argument over the definition of political correctness is
probably even more off topic, though.  So I'll face your criticism and
say as long as it's just *almost* as offensive I can live with it :-)

-Toshio

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

From mzerqung at 0pointer.de  Mon Oct 20 17:19:30 2008
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Mon, 20 Oct 2008 19:19:30 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <1224496369.6770.1544.camel@macbook.infradead.org>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
Message-ID: <20081020171930.GA32654@tango.0pointer.de>

On Mon, 20.10.08 10:52, David Woodhouse (dwmw2 at infradead.org) wrote:

> > The name I personally favour is masterpackager since it evokes the
> > apprentice, journeyman, master craftsman stages that seem most like what
> > we're modeling here.
> > 
> > I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> > can everyone live with this?
> 
> No, I'm offended by the idea that a common root used in many geek words
> can so easily be declared 'unclean' and eradicated. This is political
> correctness at its worst, and I find it horrifically offensive. And
> that's a _current_ issue, not one from the previous millennium.

"horrifically offensive". Oh my, you are easy to offend! 

> I have no particular attachment to the '?berpackager' name, but I object
> strongly to the change on _principle_. Please leave it as it was.

I am amazed how pointless and ignorant and cheap the principles are
you chose as yours. If being against anything that could remotely
smell like political correctness is one of your principles, then oh my
-- I really hope you don't have any other problems. It sounds like you
are proud of being ignorant.

   ?Those are my principles, and if you don't like them... well, I have
   others.? -- Grouch Marx

I know that americans and britons think that prefixing words with
"?ber" in reference to the ?bermensch is awesome and cool. And maybe
it is. But formalizing this in our workflow -- that is followed in
countries where people generally do see the connotation because it is
taught in school -- is another step.

It wasn't my intention to start this noisy bike-shed discussion. I
am sorry for that.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From jkeating at redhat.com  Mon Oct 20 17:50:44 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 20 Oct 2008 10:50:44 -0700
Subject: post-beta snapshots
In-Reply-To: <1224269795.4142.14.camel@luminos.localdomain>
References: <1224269795.4142.14.camel@luminos.localdomain>
Message-ID: <1224525044.30113.0.camel@luminos.localdomain>

On Fri, 2008-10-17 at 11:56 -0700, Jesse Keating wrote:
> I'm thinking we need to adjust this slightly, attempt the snapshot on
> Wed instead, fix anything we can leading to Thursday, spend Thursday
> creating the content, Thursday night staging the content and releasing
> it on Friday.  This puts the snapshot content a day older than rawhide,
> but that should be fine.
> 
> Anybody think this is a bad idea?

Given that there was no feedback here, Rel Eng approved this adjustment
at our meeting today.  The last step is getting a nod of approval from
FESCo so that we can make it happen for this last snapshot.

FESCo, what say you?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/57540ea2/attachment.sig>

From katzj at redhat.com  Mon Oct 20 18:03:17 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Oct 2008 14:03:17 -0400
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <48FCAD89.4040808@gmail.com>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<200810180104.18321.opensource@till.name>
	<1224286760.4142.46.camel@luminos.localdomain>
	<200810191314.20208.opensource@till.name>
	<1224511256.19054.26.camel@aglarond.local> <48FCAD89.4040808@gmail.com>
Message-ID: <1224525797.13204.3.camel@aglarond.local>

On Mon, 2008-10-20 at 11:10 -0500, Les Mikesell wrote:
> Jeremy Katz wrote:
> > And while anything is possible, as I mentioned, doing something like
> > this (having the CD isos just loopback mounted off the DVD) would make
> > DVD vs CD installs substantially different in terms of how the code
> > works.  And that code is twisty turny enough as it is
> 
> Isn't that exactly the way an NFS or HD install works when you point it 
> to a directory of CD iso images?  I'd think consolidating the techniques 
> would simplify things.

No, because one is reading off of a hard drive/NFS and one of them is
reading off of a spinning, ejectable medium.  Eject-able is a pretty key
difference especially as we continue to enable more ways to add more
repos (including hopefully multiple *media* based repos in F11)

Jeremy



From notting at redhat.com  Mon Oct 20 18:06:22 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 20 Oct 2008 14:06:22 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020021340.GA7740@jadzia.bu.edu>
References: <1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
Message-ID: <20081020180622.GC21020@nostromo.devel.redhat.com>

Matthew Miller (mattdm at mattdm.org) said: 
> > I understand where you are coming from but I have to say the above
> > statement is, imo, fundamentally wrong.
> 
> I agree with Seth. Since most desktop users don't have a centralized
> logserver but do have an e-mail account somewhere, it makes perfect sense.
> We need to work some on getting e-mail going somewhere useful, though, and
> on making the e-mails sent be not "junk".

I'm trying to think of a single thing that logwatch (or cron) would send
about now that would be useful to forward to a random desktop user's yahoo
address. I'm failing.

Bill



From seg at haxxed.com  Mon Oct 20 18:11:25 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Oct 2008 13:11:25 -0500
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FC0F24.7080208@googlemail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<48FC0F24.7080208@googlemail.com>
Message-ID: <1224526285.598.12.camel@localhost.localdomain>

On Mon, 2008-10-20 at 06:55 +0200, Tim Lauridsen wrote:
> Toshio Kuratomi wrote:
> > So I'm going to do this tomorrow or have to put it off until after
> > change freeze.
> >
> > The name I personally favour is masterpackager since it evokes the
> > apprentice, journeyman, master craftsman stages that seem most like what
> > we're modeling here.
> >
> > I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> > can everyone live with this?
> >
> > -Toshio
> >
> >   
> master ninja overload super chief packager :) 

packagemonkey!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/aed48ce3/attachment.sig>

From lesmikesell at gmail.com  Mon Oct 20 18:23:40 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 13:23:40 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020180622.GC21020@nostromo.devel.redhat.com>
References: <1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>
	<48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<20081019192624.GC7547@nb.net.home>	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
Message-ID: <48FCCCAC.6050304@gmail.com>

Bill Nottingham wrote:
> Matthew Miller (mattdm at mattdm.org) said: 
>>> I understand where you are coming from but I have to say the above
>>> statement is, imo, fundamentally wrong.
>> I agree with Seth. Since most desktop users don't have a centralized
>> logserver but do have an e-mail account somewhere, it makes perfect sense.
>> We need to work some on getting e-mail going somewhere useful, though, and
>> on making the e-mails sent be not "junk".
> 
> I'm trying to think of a single thing that logwatch (or cron) would send
> about now that would be useful to forward to a random desktop user's yahoo
> address. I'm failing.

Most people would probably like to know if smartctl thinks their disk 
drive is likely to fail or if a raid member has already failed and they 
are running in degraded mode.   And maybe if a bazillion ssh login 
attempts have failed.   As for cron, that would be up to what the user 
has scheduled.  It just needs to behave as documented and expected.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From walters at verbum.org  Mon Oct 20 18:26:42 2008
From: walters at verbum.org (Colin Walters)
Date: Mon, 20 Oct 2008 14:26:42 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCCCAC.6050304@gmail.com>
References: <1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
Message-ID: <faa16b610810201126l1ac51868uf831fa6540b51a6e@mail.gmail.com>

On Mon, Oct 20, 2008 at 2:23 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>
> Most people would probably like to know if smartctl thinks their disk drive
> is likely to fail or if a raid member has already failed and they are
> running in degraded mode.

Should be exposed through HAL and then the desktop can listen for that
event and present it in a suitable way - e.g. a notification bubble.



From seg at haxxed.com  Mon Oct 20 18:27:30 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Oct 2008 13:27:30 -0500
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224419308.2948.9.camel@sb-home>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>  <48F8FD28.5070805@fedoraproject.org>
	<1224278235.21581.104.camel@rosebud>
	<1224316251.26341.197.camel@localhost.localdomain>
	<1224419308.2948.9.camel@sb-home>
Message-ID: <1224527250.598.20.camel@localhost.localdomain>

On Sun, 2008-10-19 at 14:28 +0200, nodata wrote:
> Am Samstag, den 18.10.2008, 02:50 -0500 schrieb Callum Lerwick:
> 
> > I'd suggest just biting the bullet, fire up a vncserver instance, and
> > run Azureus. It is incredibly flexible 
> 
> What about users who don't want to install X just to download a file?

I was talking about Fedora's own master seeders. Users can use whatever
they want.

> Azureus is also a resource hog. rtorrent uses far fewer resources.

Yes, it is a bloaty pig. But it's the only client I've ever seen that is
really *designed* to be a master seeder.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/a7e0c3e2/attachment.sig>

From notting at redhat.com  Mon Oct 20 18:28:12 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 20 Oct 2008 14:28:12 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCCCAC.6050304@gmail.com>
References: <1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
Message-ID: <20081020182812.GD21020@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
>> I'm trying to think of a single thing that logwatch (or cron) would send
>> about now that would be useful to forward to a random desktop user's yahoo
>> address. I'm failing.
>
> Most people would probably like to know if smartctl thinks their disk  
> drive is likely to fail or if a raid member has already failed and they  
> are running in degraded mode.   And maybe if a bazillion ssh login  
> attempts have failed.

... which should be pop-up alerts of some sort on the machine itself. Not
sent halfway across the world waiting for you to connect to the internet.

Bill



From lesmikesell at gmail.com  Mon Oct 20 18:43:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 13:43:42 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020182812.GD21020@nostromo.devel.redhat.com>
References: <1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>
	<48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<20081019192624.GC7547@nb.net.home>	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>	<20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
Message-ID: <48FCD15E.4090003@gmail.com>

Bill Nottingham wrote:
>  
>>> I'm trying to think of a single thing that logwatch (or cron) would send
>>> about now that would be useful to forward to a random desktop user's yahoo
>>> address. I'm failing.
>> Most people would probably like to know if smartctl thinks their disk  
>> drive is likely to fail or if a raid member has already failed and they  
>> are running in degraded mode.   And maybe if a bazillion ssh login  
>> attempts have failed.
> 
> ... which should be pop-up alerts of some sort on the machine itself. Not
> sent halfway across the world waiting for you to connect to the internet.
> 

You are kind of missing the point of a machine with a network, automated 
scheduling and the native ability to run single apps in a remote window. 
  Users don't need to sit in front of every machine  they have for it to 
be doing something useful for them.  The user may in fact be halfway 
around the world when you'd present that pop-up that he'll never see in 
some window manager he's not running.  Messages you want should come to 
you, rather than having to do the reverse.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From walters at verbum.org  Mon Oct 20 18:50:32 2008
From: walters at verbum.org (Colin Walters)
Date: Mon, 20 Oct 2008 14:50:32 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCD15E.4090003@gmail.com>
References: <1224434315.6770.1477.camel@macbook.infradead.org>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com>
Message-ID: <faa16b610810201150q368d5705gc930c5e97877427a@mail.gmail.com>

On Mon, Oct 20, 2008 at 2:43 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
>
> You are kind of missing the point of a machine with a network, automated
> scheduling and the native ability to run single apps in a remote window.
>  Users don't need to sit in front of every machine  they have for it to be
> doing something useful for them.  The user may in fact be halfway around the
> world when you'd present that pop-up that he'll never see in some window
> manager he's not running.  Messages you want should come to you, rather than
> having to do the reverse.

So set up logwatch or whatever other server machine monitoring
software you prefer.



From seg at haxxed.com  Mon Oct 20 18:51:49 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Oct 2008 13:51:49 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCCCAC.6050304@gmail.com>
References: <1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
Message-ID: <1224528709.598.26.camel@localhost.localdomain>

On Mon, 2008-10-20 at 13:23 -0500, Les Mikesell wrote:
> And maybe if a bazillion ssh login attempts have failed.

No. SSH scanning is commonplace nowadays. All my exposed machines are
constantly pounded on by rumplestiltskin bots. Alerting on this would
equate to "Congratulations, you are using the internet!" every 5
minutes...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/6ca8eb1b/attachment.sig>

From mjg at redhat.com  Mon Oct 20 19:05:49 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 20 Oct 2008 20:05:49 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCD15E.4090003@gmail.com>
References: <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com>
Message-ID: <20081020190549.GA14319@srcf.ucam.org>

On Mon, Oct 20, 2008 at 01:43:42PM -0500, Les Mikesell wrote:

> You are kind of missing the point of a machine with a network, automated 
> scheduling and the native ability to run single apps in a remote window. 
>  Users don't need to sit in front of every machine  they have for it to 
> be doing something useful for them.  The user may in fact be halfway 
> around the world when you'd present that pop-up that he'll never see in 
> some window manager he's not running.  Messages you want should come to 
> you, rather than having to do the reverse.

Once you're beyond the typical desktop use case, then yes, an MTA 
probably makes sense. But that's not an argument for an MTA in the 
default desktop install.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From valent.turkovic at gmail.com  Mon Oct 20 19:15:52 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 20 Oct 2008 21:15:52 +0200
Subject: Off Topic: where I can see how I translate old gdm conf files
	to new ones?
In-Reply-To: <485DF400.2030102@gmail.com>
References: <485DF400.2030102@gmail.com>
Message-ID: <64b14b300810201215g5d0b1c52gdada628e5db7093@mail.gmail.com>

2008/6/22 Casimiro de Almeida Barreto <casimiro.barreto at gmail.com>:
> Hello,
>
> After upgrading to Fedora Rel 9 I've had trouble to drop the -nolisten in
> the Xserver (old defaults.conf is not working anymore) and I need to set the
> command=/usr/bin/X ...
>
> Gdm was shipped without proper documentation (no man pages, nothing for the
> missing gdmsetup and other programs...
>
> Best regards and sorry for the inconvenience...
>
> Casimiro Barreto
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Try checking out upstream GDM bug:
http://bugzilla.gnome.org/show_bug.cgi?id=553250

and also gdm mailing list:
http://mail.gnome.org/mailman/listinfo/gdm-list

Cheers,
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 lesmikesell at gmail.com  Mon Oct 20 19:17:39 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 14:17:39 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020190549.GA14319@srcf.ucam.org>
References: <48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<20081019192624.GC7547@nb.net.home>	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>	<20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>
Message-ID: <48FCD953.3080707@gmail.com>

Matthew Garrett wrote:
> On Mon, Oct 20, 2008 at 01:43:42PM -0500, Les Mikesell wrote:
> 
>> You are kind of missing the point of a machine with a network, automated 
>> scheduling and the native ability to run single apps in a remote window. 
>>  Users don't need to sit in front of every machine  they have for it to 
>> be doing something useful for them.  The user may in fact be halfway 
>> around the world when you'd present that pop-up that he'll never see in 
>> some window manager he's not running.  Messages you want should come to 
>> you, rather than having to do the reverse.
> 
> Once you're beyond the typical desktop use case, then yes, an MTA 
> probably makes sense. But that's not an argument for an MTA in the 
> default desktop install.

OK, if you really are so elitist that you think typical users can't 
figure out how to use standard programs, consider the case where you 
install the software for one of your incapable friends or family members 
and you'd like those impending failure warnings to come to you since the 
user won't understand them anyway.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Mon Oct 20 19:24:14 2008
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 20 Oct 2008 15:24:14 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCD953.3080707@gmail.com>
References: <20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com>
Message-ID: <20081020192414.GF21020@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
>> Once you're beyond the typical desktop use case, then yes, an MTA  
>> probably makes sense. But that's not an argument for an MTA in the  
>> default desktop install.
>
> OK, if you really are so elitist that you think typical users can't  
> figure out how to use standard programs, consider the case where you  
> install the software for one of your incapable friends or family members  
> and you'd like those impending failure warnings to come to you since the  
> user won't understand them anyway.

Then you, the *administrator* of that machine (because, truly, that's
your role) can configure it to do so. It doesn't mean it should do so
out of the box.

Bill



From wolfy at nobugconsulting.ro  Mon Oct 20 19:27:06 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Mon, 20 Oct 2008 22:27:06 +0300
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <1224526285.598.12.camel@localhost.localdomain>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>	<48FC0F24.7080208@googlemail.com>
	<1224526285.598.12.camel@localhost.localdomain>
Message-ID: <48FCDB8A.50702@nobugconsulting.ro>

On 10/20/2008 09:11 PM, Callum Lerwick wrote:
> On Mon, 2008-10-20 at 06:55 +0200, Tim Lauridsen wrote:
>   
>> Toshio Kuratomi wrote:
>>     
>>> So I'm going to do this tomorrow or have to put it off until after
>>> change freeze.
>>>
>>> The name I personally favour is masterpackager since it evokes the
>>> apprentice, journeyman, master craftsman stages that seem most like what
>>> we're modeling here.
>>>
>>> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
>>> can everyone live with this?
>>>
>>> -Toshio
>>>
>>>   
>>>       
>> master ninja overload super chief packager :) 
>>     
>
> packagemonkey!
in this case the other group should be leaderofthepack 
(http://en.wikipedia.org/wiki/Leader_of_the_Pack for details) :)



From kwhiskerz at gmail.com  Mon Oct 20 19:23:36 2008
From: kwhiskerz at gmail.com (kwhiskerz)
Date: Mon, 20 Oct 2008 13:23:36 -0600
Subject: text-to-speech doesn't work
References: <gdbd1f$r8e$1@ger.gmane.org> <20081018185757.GA12113@jadzia.bu.edu>
	<gddr7e$ug$1@ger.gmane.org> <gdds30$312$1@ger.gmane.org>
	<20081019125150.GA6481@jadzia.bu.edu>
Message-ID: <gdilrq$j7p$1@ger.gmane.org>

Matthew Miller wrote:

> 
> make sure a bug is filed for this.
> 
I finally did, one for festival and another for espeak.



From cdahlin at redhat.com  Mon Oct 20 19:25:32 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 20 Oct 2008 15:25:32 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <loom.20081020T160448-179@post.gmane.org>
References: <48F64212.2010505@redhat.com>	<20081016171451.GA7049@tango.0pointer.de>	<48FB5DC3.1060409@gmail.com>	<1224496369.6770.1544.camel@macbook.infradead.org>
	<loom.20081020T160448-179@post.gmane.org>
Message-ID: <48FCDB2C.7030402@redhat.com>

Kevin Kofler wrote:
> David Woodhouse <dwmw2 <at> infradead.org> writes:
>   
>> No, I'm offended by the idea that a common root used in many geek words
>>     
>
> ... by ignorant Americans who are unaware of the true meaning of that term!
>
>   

Right! Because all true meaning comes from Europe. Any meaning which 
might exist in America is just pretend. Only European meanings are true.

--CJD

"Row, row, fight the powah"



From walters at verbum.org  Mon Oct 20 19:33:16 2008
From: walters at verbum.org (Colin Walters)
Date: Mon, 20 Oct 2008 15:33:16 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020192414.GF21020@nostromo.devel.redhat.com>
References: <20081019192624.GC7547@nb.net.home>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com>
	<20081020192414.GF21020@nostromo.devel.redhat.com>
Message-ID: <faa16b610810201233s335e8358t12a4c73c324cceef@mail.gmail.com>

On Mon, Oct 20, 2008 at 3:24 PM, Bill Nottingham <notting at redhat.com> wrote:
>
> Then you, the *administrator* of that machine (because, truly, that's
> your role) can configure it to do so. It doesn't mean it should do so
> out of the box.

That said, I do wish Fedora made it easier to do the remote admin for
family/friends type thing.  I'm not really thinking of setting up mail
servers, but more putting together something like Copilot
(https://www.copilot.com/) from the tools we have (Vino, ssh,
Telepathy).  But that's another discussion...



From orcanbahri at yahoo.com  Mon Oct 20 19:40:50 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Mon, 20 Oct 2008 12:40:50 -0700 (PDT)
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FCDB2C.7030402@redhat.com>
Message-ID: <672056.72050.qm@web32801.mail.mud.yahoo.com>

--- On Mon, 10/20/08, Casey Dahlin <cdahlin at redhat.com> wrote:

> From: Casey Dahlin <cdahlin at redhat.com>
> Subject: Re: uberpackager rename (was Re: The Big ACL Opening)
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> Date: Monday, October 20, 2008, 3:25 PM
> Kevin Kofler wrote:
> > David Woodhouse <dwmw2 <at> infradead.org>
> writes:
> >   
> >> No, I'm offended by the idea that a common
> root used in many geek words
> >>     
> >
> > ... by ignorant Americans who are unaware of the true
> meaning of that term!
> >
> >   
> 
> Right! Because all true meaning comes from Europe. Any
> meaning which 
> might exist in America is just pretend. Only European
> meanings are true.
> 
Yes, unfortunately that's a fact. We chose to use a European language as the primary language here in US, which was (IMHO) wrong since there were many native tongues that could be used. Hence I think we deserve such "accusations". 

"Uber" is not the only word that got a wrong transfer into English. Another example, which is a lot worse, is "Gift"*. I don't see any reason of promoting the usage of such wrong transfers. It hurts languages, both English and that language the word is transferred from.

> --CJD
> 


*For the curious, the true meaning of "gift" is "poison".

-oget

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From dominik at greysector.net  Mon Oct 20 19:45:10 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 20 Oct 2008 21:45:10 +0200
Subject: Collapsing DVD and CD torrents into one
In-Reply-To: <1224527250.598.20.camel@localhost.localdomain>
References: <1224272955.4142.25.camel@luminos.localdomain>
	<48F8EE89.1030907@BitWagon.com>
	<48F8FD28.5070805@fedoraproject.org>
	<1224278235.21581.104.camel@rosebud>
	<1224316251.26341.197.camel@localhost.localdomain>
	<1224419308.2948.9.camel@sb-home>
	<1224527250.598.20.camel@localhost.localdomain>
Message-ID: <20081020194510.GA24494@mokona.greysector.net>

On Monday, 20 October 2008 at 20:27, Callum Lerwick wrote:
> On Sun, 2008-10-19 at 14:28 +0200, nodata wrote:
> > Am Samstag, den 18.10.2008, 02:50 -0500 schrieb Callum Lerwick:
> > 
> > > I'd suggest just biting the bullet, fire up a vncserver instance, and
> > > run Azureus. It is incredibly flexible 
> > 
> > What about users who don't want to install X just to download a file?
> 
> I was talking about Fedora's own master seeders. Users can use whatever
> they want.
> 
> > Azureus is also a resource hog. rtorrent uses far fewer resources.
> 
> Yes, it is a bloaty pig. But it's the only client I've ever seen that is
> really *designed* to be a master seeder.

AFAIR rtorrent has an "initial" seeding mode, too. I've seen a capital "I"
beside some torrents when running it.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From dimi at lattica.com  Mon Oct 20 20:12:17 2008
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Oct 2008 16:12:17 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <672056.72050.qm@web32801.mail.mud.yahoo.com>
References: <672056.72050.qm@web32801.mail.mud.yahoo.com>
Message-ID: <1224533537.5342.415.camel@dimi.lattica.com>


On Mon, 2008-10-20 at 12:40 -0700, Orcan Ogetbil wrote:
> "Uber" is not the only word that got a wrong transfer into English.
> Another example, which is a lot worse, is "Gift"*. I don't see any
> reason of promoting the usage of such wrong transfers. It hurts
> languages, both English and that language the word is transferred
> from.

This is getting nuts! HTF is "gift" hurting English and the Icelandic
at the same time?!?

I agree with Dave that all this PC crap is getting to be very annoying.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From lesmikesell at gmail.com  Mon Oct 20 20:16:38 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 15:16:38 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020192414.GF21020@nostromo.devel.redhat.com>
References: <20081019192624.GC7547@nb.net.home>	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>	<20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081020192414.GF21020@nostromo.devel.redhat.com>
Message-ID: <48FCE726.10309@gmail.com>

Bill Nottingham wrote:
> Les Mikesell (lesmikesell at gmail.com) said: 
>>> Once you're beyond the typical desktop use case, then yes, an MTA  
>>> probably makes sense. But that's not an argument for an MTA in the  
>>> default desktop install.
>> OK, if you really are so elitist that you think typical users can't  
>> figure out how to use standard programs, consider the case where you  
>> install the software for one of your incapable friends or family members  
>> and you'd like those impending failure warnings to come to you since the  
>> user won't understand them anyway.
> 
> Then you, the *administrator* of that machine (because, truly, that's
> your role) can configure it to do so. It doesn't mean it should do so
> out of the box.

But it is even more important for the more common case where the user is 
his own administrator.  The right way to handle that case is not to 
change it conceptually by re-inventing a less capable - and unexpected - 
message transport and storage facility, but to make the standard 
capability more obvious by adding a choice for the root alias at 
firstboot configuration and a mail notifier applet to the default 
desktop.  This gives you a configuration that both an administrator and 
a first-time user can understand and use, and even the first-time user 
will see that the capabilities are better than he'd have on a stock MS 
windows box.

-- 
   Les Mikesell
     lesmikesell at gmail.com




From lesmikesell at gmail.com  Mon Oct 20 20:55:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 20 Oct 2008 15:55:19 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <faa16b610810201233s335e8358t12a4c73c324cceef@mail.gmail.com>
References: <20081019192624.GC7547@nb.net.home>	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>	<20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>	<20081020192414.GF21020@nostromo.devel.redhat.com>
	<faa16b610810201233s335e8358t12a4c73c324cceef@mail.gmail.com>
Message-ID: <48FCF037.6080000@gmail.com>

Colin Walters wrote:
> On Mon, Oct 20, 2008 at 3:24 PM, Bill Nottingham <notting at redhat.com> wrote:
>> Then you, the *administrator* of that machine (because, truly, that's
>> your role) can configure it to do so. It doesn't mean it should do so
>> out of the box.
> 
> That said, I do wish Fedora made it easier to do the remote admin for
> family/friends type thing.  I'm not really thinking of setting up mail
> servers, but more putting together something like Copilot
> (https://www.copilot.com/) from the tools we have (Vino, ssh,
> Telepathy).  But that's another discussion...

I think policykit introduces some really ugly issues issues here - or at 
least if it works the same as in ubuntu in terms of giving unwarranted 
privileges to console sessions and requiring a console session to use 
the GUI admin tools if you don't log in as root.  You could use VNC or 
NX/freenx session shadowing with an already logged in console user 
session, but that's not exactly right for administration since it might 
really be an unprivileged user sitting there.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From chasd at silveroaks.com  Mon Oct 20 21:00:39 2008
From: chasd at silveroaks.com (chasd)
Date: Mon, 20 Oct 2008 16:00:39 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081020160005.9120B619358@hormel.redhat.com>
References: <20081020160005.9120B619358@hormel.redhat.com>
Message-ID: <8266FE07-1552-4A0F-82EA-ADBD180D5886@silveroaks.com>

For informational purposes, not meant as more fuel for any kind of  
fire or as any kind of suggested solution . . .

On Oct 20, 2008, Phil Knirsch wrote:

> What happens to emails generated on a Max OSX via crontab or any  
> other automated system?

Apple uses launchd for that.
The daily and weekly cleanups are run at 03:15, the monthly at 05:30.
Since many people turn off or sleep their systems, these rarely get  
run on most Macs.
There are usually flame wars on Mac lists about how important these  
are to run manually if your usage patterns don't kick them off  
automatically.

It calls /usr/sbin/periodic with config files in /etc/periodic
The man page for periodic has "BSD System Manager's Manual" at the top.
Of the few BSD machines I have had to admin, I've never run across  
"periodic" - it was a new one on me.

> Does it run sendmail or some equivalent of it?

There is an /etc/postfix directory with an alias file that contains :

# Person who should get root's mail. Don't receive mail as root!
#root:          you

postfix isn't used AFAIK, and definitely not used for user notification.
I never see it in the Activity Monitor or with ps

> Just curious how they solve it as on a Mac i'd bet you that hardly  
> any typical user will know what root is.

There is no root as most know it on OS X.
The GUI uses a UAC kind of thing to promote privileges, and you can  
use sudo on the CLI.  To have either work your account needs to be in  
the wheel group. You get in the wheel group by checking a "administer  
this computer" type checkbox in System Preferences => Users.
Or you can use NetInfo on 10.0 through 10.4 if you prefer that or are  
an old NeXT admin ;)

OS X has a /Applications/Utilities/Console application that lets you  
sift through log files in a GUI.
A better solution IMHO than logwatch ( for a desktop user ). No daily  
"junk" as it has been called, but if you need to research an issue,  
the log files are easy to look at without "cat" or "less". The person  
looking still needs to know what they are looking at - raw log data  
not a filtered executive overview.

The SMART reporting is very poor. You have to manually run / 
Applications/Utilities/Disk Utility to see if there are problems  
reported by SMART ( no daemon ), and the report is binary, thumbs up  
or thumbs down without any detail. Usually by the time you check the  
SMART status, an experienced person has a good seat-of-the-pants  
hunch the hard drive is going south and uses Disk Utility for  
confirmation. I don't know if the desktop SMART notification floated  
earlier in this thread is currently implemented or if it was a  
proposal, but either way that it is far superior to e-mail  
notification, and does not exist on OS X ( or Windows that I know of ).


-- 
Charles Dostale




From bpepple at fedoraproject.org  Mon Oct 20 21:12:54 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 20 Oct 2008 17:12:54 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <48FB5DC3.1060409@gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
Message-ID: <1224537174.16700.0.camel@kennedy>

On Sun, 2008-10-19 at 09:18 -0700, Toshio Kuratomi wrote:
> So I'm going to do this tomorrow or have to put it off until after
> change freeze.
> 
> The name I personally favour is masterpackager since it evokes the
> apprentice, journeyman, master craftsman stages that seem most like what
> we're modeling here.
> 
> I know this isn't as flamboyant as ultrapackager, superpackager, etc but
> can everyone live with this?

Yeah, I've no problem with your proposal.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/319651ad/attachment.sig>

From bpepple at fedoraproject.org  Mon Oct 20 21:34:27 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 20 Oct 2008 17:34:27 -0400
Subject: post-beta snapshots
In-Reply-To: <1224525044.30113.0.camel@luminos.localdomain>
References: <1224269795.4142.14.camel@luminos.localdomain>
	<1224525044.30113.0.camel@luminos.localdomain>
Message-ID: <1224538467.16700.3.camel@kennedy>

On Mon, 2008-10-20 at 10:50 -0700, Jesse Keating wrote:
> On Fri, 2008-10-17 at 11:56 -0700, Jesse Keating wrote:
> > I'm thinking we need to adjust this slightly, attempt the snapshot on
> > Wed instead, fix anything we can leading to Thursday, spend Thursday
> > creating the content, Thursday night staging the content and releasing
> > it on Friday.  This puts the snapshot content a day older than rawhide,
> > but that should be fine.
> > 
> > Anybody think this is a bad idea?
> 
> Given that there was no feedback here, Rel Eng approved this adjustment
> at our meeting today.  The last step is getting a nod of approval from
> FESCo so that we can make it happen for this last snapshot.
> 
> FESCo, what say you?

+1, looks reasonable to me.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/e91dbd9a/attachment.sig>

From dwmw2 at infradead.org  Mon Oct 20 22:11:29 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 20 Oct 2008 23:11:29 +0100
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <20081020171930.GA32654@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<20081020171930.GA32654@tango.0pointer.de>
Message-ID: <1224540689.16910.45.camel@macbook.infradead.org>

On Mon, 2008-10-20 at 19:19 +0200, Lennart Poettering wrote:
> > I have no particular attachment to the '?berpackager' name, but I object
> > strongly to the change on _principle_. Please leave it as it was.
> 
> I am amazed how pointless and ignorant and cheap the principles are
> you chose as yours. 

First they came for our words, and I remained silent, because I had no
particular attachment to the words I'd chosen...

-- 
dwmw2



From triad at df.lth.se  Mon Oct 20 22:16:59 2008
From: triad at df.lth.se (Linus Walleij)
Date: Tue, 21 Oct 2008 00:16:59 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081016171451.GA7049@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
Message-ID: <1224541019.8119.5.camel@c83-254-32-222.bredband.comhem.se>

tor 2008-10-16 klockan 19:14 +0200 skrev Lennart Poettering:

> Hmm, am I the only one who finds the choice of the term "?berpackager"
> a bit questionnable?

No, after recently re-reading the new excellent Swedish translation of
"also spracht Zarathustra" I see I remember correctly that Nietzsche is
very clear that the "?ber" state is not reachable, just possible to
strive for.

Using a term like "?berpackager" profanes the original meaning, it's the
same mistake done by his sister and other problematic people over the
years.

So we really need to change this. ?berpackagers cannot exist by
definition, but everyone should strive to become one nonetheless.

Linus
(This is written a bit tongue-in-cheek.)



From kevin.kofler at chello.at  Mon Oct 20 22:31:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 20 Oct 2008 22:31:44 +0000 (UTC)
Subject: Regarding install options
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<1223952014.3029.166.camel@beck.corsepiu.local>
	<1223999856.1710.4.camel@luminos.localdomain>
Message-ID: <loom.20081020T223113-658@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> So lets see some comps patches for the @core group, because @core is
> what you describe, and what you'd get if you unchecked all the boxes
> during an interactive install, or just had %packages --nobase in
> kickstart.  Please tell me how this doesn't meet your definition of
> 'minimal'.

It isn't available without kickstart.

         Kevin Kofler



From kevin.kofler at chello.at  Mon Oct 20 22:41:25 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 20 Oct 2008 22:41:25 +0000 (UTC)
Subject: Regarding install options
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
Message-ID: <loom.20081020T223259-693@post.gmane.org>

Ralf Corsepius <rc040203 <at> freenet.de> writes:
> And yes, the fact yum pulls in python is a real problem on small
> systems. Even worse are the system-config-* tools, most of which pull in
> many more packages and don't even work without X.

Help us get the zypper stack in then:
https://bugzilla.redhat.com/show_bug.cgi?id=447740
I can ask Lorenzo what still needs to be done.

Unfortunately, it will probably never be considered as a default, even for a 
minimal installation. :-( But it could be used on custom kickstarts.

I'd also suggest the good old apt-rpm, but unfortunately I'm not sure if it 
works with the new RPM in F10 (Panu told me at FUDCon Brno that there's some 
fun stuff like Lua version conflicts).

        Kevin Kofler



From jkeating at redhat.com  Mon Oct 20 22:42:28 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 20 Oct 2008 15:42:28 -0700
Subject: Regarding install options
In-Reply-To: <loom.20081020T223113-658@post.gmane.org>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<1223952014.3029.166.camel@beck.corsepiu.local>
	<1223999856.1710.4.camel@luminos.localdomain>
	<loom.20081020T223113-658@post.gmane.org>
Message-ID: <1224542548.30113.7.camel@luminos.localdomain>

On Mon, 2008-10-20 at 22:31 +0000, Kevin Kofler wrote:
> It isn't available without kickstart.

Incorrect.  You can de-select every check box in the 'Customize now'
screen and have %packages --nobase.  You can check just the Base group
and have %packages.

Again, what is missing?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/afe0bd1b/attachment.sig>

From kevin.kofler at chello.at  Mon Oct 20 22:28:13 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 20 Oct 2008 22:28:13 +0000 (UTC)
Subject: Regarding install options
References: <1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928764.3327.40.camel@luminos.localdomain>
Message-ID: <loom.20081020T222543-834@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> Yes, since removing the install classes, the bugs against these classes
> being wrong in one way shape or form have all but disappeared.

Sure. So let's remove the kernel, it will instantly "fix" 993 open bugs. :-D

Removing something just because it is not perfect is rarely a good solution, 
usually it's better to have a buggy feature than not to have it at all.

        Kevin Kofler



From jkeating at redhat.com  Mon Oct 20 23:40:47 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 20 Oct 2008 16:40:47 -0700
Subject: Regarding install options
In-Reply-To: <loom.20081020T222543-834@post.gmane.org>
References: <1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928764.3327.40.camel@luminos.localdomain>
	<loom.20081020T222543-834@post.gmane.org>
Message-ID: <1224546047.30113.8.camel@luminos.localdomain>

On Mon, 2008-10-20 at 22:28 +0000, Kevin Kofler wrote:
> Sure. So let's remove the kernel, it will instantly "fix" 993 open bugs. :-D
> 
> Removing something just because it is not perfect is rarely a good solution, 
> usually it's better to have a buggy feature than not to have it at all.

Except that the "feature" only led to bugs being filed, and people
always picking "custom" because they felt they always feel somewhere
between the listed classes.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/5a01e8b1/attachment.sig>

From dr.diesel at gmail.com  Mon Oct 20 23:44:22 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Mon, 20 Oct 2008 19:44:22 -0400
Subject: Make subpixel smoothing default?
Message-ID: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>

I didn't even know this option existed, and man does it look better!
Considering 95% of displays are now LCDs should this option be the
default?



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org



From katzj at redhat.com  Tue Oct 21 00:37:26 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Oct 2008 20:37:26 -0400
Subject: Regarding install options
In-Reply-To: <loom.20081020T222543-834@post.gmane.org>
References: <1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928764.3327.40.camel@luminos.localdomain>
	<loom.20081020T222543-834@post.gmane.org>
Message-ID: <1224549446.13204.140.camel@aglarond.local>

On Mon, 2008-10-20 at 22:28 +0000, Kevin Kofler wrote:
> Jesse Keating <jkeating <at> redhat.com> writes:
> > Yes, since removing the install classes, the bugs against these classes
> > being wrong in one way shape or form have all but disappeared.
> 
> Sure. So let's remove the kernel, it will instantly "fix" 993 open bugs. :-D
> 
> Removing something just because it is not perfect is rarely a good solution, 
> usually it's better to have a buggy feature than not to have it at all.

It wasn't about removing "bugs".  It was about the fact that it was
fundamentally the wrong sort of place to put such a question.  People's
opinions of partitioning vs packaging vs how to install the bootloader,
as it turns out, aren't heavily tied together.  So rather than try to
give an option to preset multiple later options (as well as hide some of
them), it's better to just make the later options more accessible.
Which is what we've attempted to do.

Jeremy



From ianweller at gmail.com  Tue Oct 21 01:35:11 2008
From: ianweller at gmail.com (Ian Weller)
Date: Mon, 20 Oct 2008 20:35:11 -0500
Subject: Make subpixel smoothing default?
In-Reply-To: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
Message-ID: <20081021013511.GA7959@gmail.com>

On Mon, Oct 20, 2008 at 07:44:22PM -0400, Dr. Diesel wrote:
> I didn't even know this option existed, and man does it look better!
> Considering 95% of displays are now LCDs should this option be the
> default?
> 
For the record, it made things look like utter crap on my display. And
it's an LCD. If people want it, they can get it.

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081020/753ff4b4/attachment.sig>

From james.antill at redhat.com  Tue Oct 21 03:21:23 2008
From: james.antill at redhat.com (James Antill)
Date: Mon, 20 Oct 2008 23:21:23 -0400
Subject: Regarding install options
In-Reply-To: <loom.20081020T223259-693@post.gmane.org>
References: <b53a79450810092212o13d9e06fg3f519c31b77c78b@mail.gmail.com>
	<1223655604.4410.153.camel@luminos.localdomain>
	<1223675348.3564.1271.camel@beck.corsepiu.local>
	<1223675533.4410.183.camel@luminos.localdomain>
	<1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<loom.20081020T223259-693@post.gmane.org>
Message-ID: <1224559283.23198.15.camel@code.and.org>

On Mon, 2008-10-20 at 22:41 +0000, Kevin Kofler wrote:
> Ralf Corsepius <rc040203 <at> freenet.de> writes:
> > And yes, the fact yum pulls in python is a real problem on small
> > systems. Even worse are the system-config-* tools, most of which pull in
> > many more packages and don't even work without X.
> 
> Help us get the zypper stack in then:
> https://bugzilla.redhat.com/show_bug.cgi?id=447740
> I can ask Lorenzo what still needs to be done.

 AIUI zypper doesn't resolve file deps.  (SuSE just don't have them) ...
so while I personally wouldn't mind being able to yum install it and
play with it, I don't think we should recommend it's use.

 And that's even if having two different depsolvers/pacakge-managers
supported at once wasn't complete crack, which it is.

> Unfortunately, it will probably never be considered as a default, even for a 
> minimal installation. :-( But it could be used on custom kickstarts.
> 
> I'd also suggest the good old apt-rpm, but unfortunately I'm not sure if it 
> works with the new RPM in F10 (Panu told me at FUDCon Brno that there's some 
> fun stuff like Lua version conflicts).

 apt seems to crash a lot, for me, YMMV. And that's even if having two different...

-- 
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/20081020/e430d093/attachment.sig>

From peter.hutterer at who-t.net  Tue Oct 21 04:31:44 2008
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Tue, 21 Oct 2008 15:01:44 +1030
Subject: xorg-x11-drv-evdev-7.0.1-2 bad!
In-Reply-To: <48FB2C4E.3000903@gmail.com>
References: <gdd1je$i7l$1@ger.gmane.org> <20081019065623.GA14426@who-t.net>
	<48FAEDC3.2000101@gmail.com> <20081019101912.GB6480@who-t.net>
	<48FB2C4E.3000903@gmail.com>
Message-ID: <20081021043144.GA12547@who-t.net>

On Sun, Oct 19, 2008 at 03:47:10PM +0300, George Billios wrote:
> > Summary from our short email exchange:
> > If you have an xorg.conf that registers an evdev device, this device will now
> > produce duplicate events. For most setups, you probably don't need it in your
> > xorg.conf because HAL picks it up anyway. If you really do, add option
> > "GrabDevice" "true" and that'll restore the old grabbing behaviour.
> > 
[...]
> 
> Well I must agree that no device section worked better than I expected
> but it required manually editing the xorg.conf and deleting the
> respective section.
> 
> What happens with all the people upgrading from F9? Will the Xorg rpm
> handle this?

xorg-x11-drv-evdev-2.0.7-2 (just pushed, still warm) handles the last
use-case, avoiding duplicate events.

So we're basically back to all the old behaviours, but without the grab now.
F9 upgraders should only notice the difference if HAL is broken or they look
into the log files.

Cheers,
  Peter



From dwmw2 at infradead.org  Tue Oct 21 08:05:33 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 21 Oct 2008 09:05:33 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <2e1016076dc37ee5246b6a393869ff5d.squirrel@arekh.dyndns.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
	<2e1016076dc37ee5246b6a393869ff5d.squirrel@arekh.dyndns.org>
Message-ID: <1224576333.16910.55.camel@macbook.infradead.org>

On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
> 
> Also filtering mail on MUA startup is just trainwreak recipe.
> If you want your MUA to start fast you need to pre-filter junk mail in
> the background (no not everyone uses gmail and gmail is not perfect
> anyway).
> 
> So far, I haven't seen anything beating fetchmail + local MTA +
> server-side filters + local imap or local maildir delivery in Fedora.

But if you're using fetchmail, it's too late to filter -- because you
should be rejecting the stuff you don't want at SMTP time.

Filtering wants to be done on the _real_ mail server that accepts
incoming mail. Doing it after fetchmail is almost as bad as doing it in
the MUA.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From alan at redhat.com  Tue Oct 21 08:20:01 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Oct 2008 04:20:01 -0400
Subject: The Big ACL Opening
In-Reply-To: <20081017225358.GA29935@tango.0pointer.de>
References: <48F64212.2010505@redhat.com> <48F79D1B.9080800@gmail.com>
	<20081017103456.GA22692@tango.0pointer.de>
	<200810172040.57322.ville.skytta@iki.fi>
	<11750.198.175.55.5.1224265570.squirrel@mail.jcomserv.net>
	<20081017225358.GA29935@tango.0pointer.de>
Message-ID: <20081021082001.GA9214@shell.devel.redhat.com>

On Sat, Oct 18, 2008 at 12:53:59AM +0200, Lennart Poettering wrote:
> I fully understand that not everyone is aware of this connection,
> especially outside of Germany. But uh, in Germany it is very obvious.

So we'd like our word back and giving the word away forever to the people
who misappropriated it isn't the way to do that. Uber.. in various borrowed
words in English goes back to the 1800s

Alan



From alan at redhat.com  Tue Oct 21 08:49:08 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Oct 2008 04:49:08 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <672056.72050.qm@web32801.mail.mud.yahoo.com>
References: <48FCDB2C.7030402@redhat.com>
	<672056.72050.qm@web32801.mail.mud.yahoo.com>
Message-ID: <20081021084908.GC9214@shell.devel.redhat.com>

On Mon, Oct 20, 2008 at 12:40:50PM -0700, Orcan Ogetbil wrote:
> "Uber" is not the only word that got a wrong transfer into English. Another example, which is a lot worse, is "Gift"*. I don't see any reason of promoting the usage of such wrong transfers. It hurts languages, both English and that language the word is transferred from.

(gift horse...)


But this is quite normal and part of the flow of Language even within a
language. In Shakespeare's time "nice" meant the exact opposite and went through
the exact kind of process that "bad" did to "cool" for a while, only in the case
of "nice" the meaning change stuck.

Alan



From benny+usenet at amorsen.dk  Tue Oct 21 09:34:12 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Tue, 21 Oct 2008 11:34:12 +0200
Subject: uberpackager rename
In-Reply-To: <672056.72050.qm@web32801.mail.mud.yahoo.com> (Orcan Ogetbil's
	message of "Mon\, 20 Oct 2008 12\:40\:50 -0700 \(PDT\)")
References: <48FCDB2C.7030402@redhat.com>
	<672056.72050.qm@web32801.mail.mud.yahoo.com>
Message-ID: <m3iqrm5m23.fsf@ursa.amorsen.dk>

Orcan Ogetbil <orcanbahri at yahoo.com> writes:

> *For the curious, the true meaning of "gift" is "poison".

Or "married".


/Benny



From mschwendt at gmail.com  Tue Oct 21 09:50:20 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 11:50:20 +0200
Subject: The Big ACL Opening
In-Reply-To: <1224351482.4219.0.camel@luminos.localdomain>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
	<1224351482.4219.0.camel@luminos.localdomain>
Message-ID: <20081021115020.391540b4.mschwendt@gmail.com>

On Sat, 18 Oct 2008 10:38:02 -0700, Jesse Keating wrote:

> On Sat, 2008-10-18 at 10:01 +0100, Christopher Brown wrote:
> > 
> > It would be nice to have something a bit more ... interesting. In
> > Japan, they wrap gifts in cloths called "furoshiki" so perhaps
> > furoshiki-packager?
> 
> Wait wait, I know, kamikazepackager !  We swoop in like a divine wind
> and fix all the problems!

The announcements of "The Big ACL Opening" talk about what is changed.
They don't mention how the changed ACLs are to be used in the future
and how they fit into our existing bureaucracy.

Now you talk about fixing "all the problems".
So, where is the full documentation on this? For example, will sponsors
finally be able to touch all their sponsorees' packages if necessary?



From mschwendt at gmail.com  Tue Oct 21 10:06:16 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 12:06:16 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <d9c612bf0810200843x10a986a0h20be3c7848d88170@mail.gmail.com>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<48FC88A8.4010003@gmail.com>
	<d9c612bf0810200843x10a986a0h20be3c7848d88170@mail.gmail.com>
Message-ID: <20081021120616.52eccc0a.mschwendt@gmail.com>

On Mon, 20 Oct 2008 08:43:49 -0700, Christopher Stone wrote:

> qualitypackger (for quality assurance)

Gah! So many mails about how to name the group while it is not
clear how to use the group's permissions.



From nicolas.mailhot at laposte.net  Tue Oct 21 10:39:12 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 21 Oct 2008 12:39:12 +0200 (CEST)
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <1224576333.16910.55.camel@macbook.infradead.org>
References: <48F87794.3090108@redhat.com> <48F88769.2010308@gmail.com>
	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
	<2e1016076dc37ee5246b6a393869ff5d.squirrel@arekh.dyndns.org>
	<1224576333.16910.55.camel@macbook.infradead.org>
Message-ID: <745d0762a3660f324070ff48edd82c98.squirrel@arekh.dyndns.org>



Le Mar 21 octobre 2008 10:05, David Woodhouse a ?crit :
>
> On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
>>
>> Also filtering mail on MUA startup is just trainwreak recipe.
>> If you want your MUA to start fast you need to pre-filter junk mail
>> in
>> the background (no not everyone uses gmail and gmail is not perfect
>> anyway).
>>
>> So far, I haven't seen anything beating fetchmail + local MTA +
>> server-side filters + local imap or local maildir delivery in
>> Fedora.
>
> But if you're using fetchmail, it's too late to filter -- because you
> should be rejecting the stuff you don't want at SMTP time.
>
> Filtering wants to be done on the _real_ mail server that accepts
> incoming mail.

Sure but many people do not have an ISP that provides clueful
filtering, and even gmail is not so yummy when you take the privacy
and no warranty bits into account.

> Doing it after fetchmail is almost as bad as doing it
> in the MUA.

It's not. It means that when you start your MUA, everything is already
available and filtered, instead for waiting for (10s or more) seconds
with a massive CPU pike. That makes a huge user experience difference.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Oct 21 10:42:43 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 21 Oct 2008 12:42:43 +0200 (CEST)
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <20081021084908.GC9214@shell.devel.redhat.com>
References: <48FCDB2C.7030402@redhat.com>
	<672056.72050.qm@web32801.mail.mud.yahoo.com>
	<20081021084908.GC9214@shell.devel.redhat.com>
Message-ID: <086a6e47e93ba0c08df7a8840a6ae7a9.squirrel@arekh.dyndns.org>



Le Mar 21 octobre 2008 10:49, Alan Cox a ?crit :
>
> On Mon, Oct 20, 2008 at 12:40:50PM -0700, Orcan Ogetbil wrote:
>> "Uber" is not the only word that got a wrong transfer into English.
>> Another example, which is a lot worse, is "Gift"*. I don't see any
>> reason of promoting the usage of such wrong transfers. It hurts
>> languages, both English and that language the word is transferred
>> from.
>
> (gift horse...)
>
>
> But this is quite normal and part of the flow of Language even within
> a
> language. In Shakespeare's time "nice" meant the exact opposite and
> went through
> the exact kind of process that "bad" did to "cool" for a while, only
> in the case
> of "nice" the meaning change stuck.

Anyway there is a huge difference between an old well accepted
transfer and a US-only geek/metal-only FAD that uses a prefix which is
sensitive in other countries.

Many transfers do not withstand the test of time and get stupid fast.

-- 
Nicolas Mailhot



From rawhide at fedoraproject.org  Tue Oct 21 10:50:28 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 21 Oct 2008 10:50:28 +0000 (UTC)
Subject: rawhide report: 20081021 changes
Message-ID: <20081021105028.9C9EF1B8001@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct 21 06:01:14 UTC 2008

New package boswars-addons
        Addon maps for Bos Wars real-time strategy game
New package cherokee
        Flexible and Fast Webserver
New package getdata
        Library for reading and writing dirfile data
New package iml
        Finds solutions to systems of linear equations over integers
New package pymol
        PyMOL Molecular Graphics System
New package rakarrack
        Audio effects processing rack for guitar
New package simdock
        Fast and customizable dockbar
Removed package gdesklets-calendar
Updated Packages:

OpenIPMI-2.0.14-4.fc10
----------------------
* Mon Oct 20 18:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-4
- fix description of the package


PackageKit-0.3.8-1.fc10
-----------------------
* Mon Oct 20 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.8-1
- New upstream version
- Many new and updated translations.
- Merge in the QPackageKit QT library from Adrien BUSTANY

* Mon Oct 20 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.7-2
- Rename as newest upstream has QT binding also:
 * PackageKit-libs -> PackageKit-glib
 * PackageKit-devel -> PackageKit-glib-devel
- Add a BR for comps, and create a link that from the comps icons for the
  new category group icons.
- Create a subpackage for devel files required for out-of-tree backends.

* Mon Oct 20 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.3.7-3
- -browser-plugin: Requires: mozilla-filesystem


alienarena-7.20-1.fc10
----------------------
* Mon Oct 20 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 7.20-1
- sync up with Paul Bredbury's spec file
- update to 7.20


alienarena-data-20081016-1.fc10
-------------------------------
* Mon Oct 20 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 20081016-1
- update to 20081016
- sync up with Paul Bredbury's spec


amanda-2.6.0p2-2.fc10
---------------------

anyremote-4.11-1.fc10
---------------------
* Mon Oct 20 18:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 4.11-1
- Fixed issues with non-correct handling of files and directories names with 
  braces and brackets in some configuration files. 
  Several small changes in code.


asymptote-1.46-1.fc10
---------------------
* Mon Oct 20 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.46-1
- update to 1.46


at-spi-1.24.0-5.fc10
--------------------
* Tue Oct 21 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1.24.0-5
- Prevent a crash in evo when changing components


basesystem-10.0-1
-----------------
* Mon Oct 20 18:00:00 2008 Phil Knirsch <pknirsch at redhat.com> 10.0-1
- Bump version and rebuild for Fedora 10 (#451289)


bluez-gnome-1.8-6.fc10
----------------------
* Mon Oct 20 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-6
- Add missing patch

* Thu Oct 16 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-5
- Fix potential crasher in the wizard


bsd-games-2.17-25.fc10
----------------------
* Mon Oct 20 18:00:00 2008 Wart <wart at kobold.org> 2.17-25
- Fix robots high score file permissions (BZ# 467726)


cairo-dock-1.6.3-0.2.svn1358_trunk.fc10
---------------------------------------
* Tue Oct 21 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1359


cheese-2.24.1-1.fc10
--------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 2.24.1-1
- Update to 2.24.1


cluster-2.99.11-1.fc10
----------------------
* Mon Oct 20 18:00:00 2008 Fabio M. Di Nitto <fdinitto at redhat.com> - 2.99.11-1
- new upstream release.
- drop obsoleted patches.
- include very important gfs1 bug fix.
- include fix for fence_egenera (CVE-2008-4192).


eclipse-mylyn-3.0.1-3.fc10
--------------------------
* Sat Oct 18 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.0.1-3
- Add >= for jdom to ensure proper OSGi metadata


eel2-2.24.1-1.fc10
------------------
* Mon Oct 20 18:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.24.1-1
- Update to 2.24.1


ekiga-3.0.1-2.fc10
------------------
* Mon Oct 20 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-2
- Fix dependency issue

* Mon Oct 20 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> - 3.0.1-1
- Update to 3.0.1


empathy-2.24.1-1.fc10
---------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


eog-2.24.1-1.fc10
-----------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


epiphany-2.24.1-1.fc10
----------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


evince-2.24.1-1.fc10
--------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


file-roller-2.24.1-1.fc10
-------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


fontconfig-2.6.0-3.fc10
-----------------------
* Mon Oct 20 18:00:00 2008 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.0-3
- Add fontconfig-2.6.0-indic.patch
- Resolves: #464470


fpc-2.2.2-2.fc10
----------------
* Sun Oct 19 18:00:00 2008 Joost van der Sluis <joost at cnoc.nl> 2.2.2-2
- Pass -z noexecstack to the linker from within the configuration file fpc.cfg (fpc-bug #11563)
- Added patch to fix fpc-bug #11837 for usage with newer gtk2-versions


ganyremote-5.4-1.fc10
---------------------
* Fri Oct 17 18:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.4-1
- Enhanced edit configuration file window. Support application details 
  auto wrap. Added Bulgarian translation (thanks to Stanislav Popov)


gcalctool-5.24.1-2.fc10
-----------------------
* Sun Oct 19 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 5.24.1-2
- Update to 5.24.1


gcin-1.4.2-4.fc10
-----------------
* Tue Oct 21 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 1.4.2-4
- add gcin-1.4.2-gtk-immodules-lang.patch to not enable gcin gtk immodule for all
  langs (#453093)
- spec file cleanup
- update xinput conf file to set icon and setup program


gconf-editor-2.24.1-1.fc10
--------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


gdm-2.24.0-11.fc10
------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 1:2.24.0-11
- Respect system keyboard setting


glibc-2.8.90-14
---------------
* Sun Oct 19 18:00:00 2008 Jakub Jelinek <jakub at redhat.com> 2.8.90-14
- update from trunk
  - fix dynamic TLS handling (#467309)
  - fix sys/signalfd.h for C++ (#467172)
  - fix sprof (#458861)
  - fix _mcount and socket syscalls on s390x (#464146)
  - try harder to allocate memory in valloc and pvalloc (#461481)
- fix power6 32-bit libs (#467311)


gnash-0.8.4-3.fc10
------------------
* Sun Oct 19 18:00:00 2008 Patrice Dumas <pertusus at free.fr> 0.8.4-3
- add a desktop file


gnome-desktop-2.24.0-9.fc10
---------------------------
* Mon Oct 20 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-9
- Fix icon flicker at start of cross fade

* Mon Oct 20 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-8
- consoliate window repaint code to one place
- Lengthen duration of animation if getting to the first frame
  takes a long time.


gnome-games-2.24.1-1.fc10
-------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-1
- Update to 2.24.1


gnome-menus-2.24.0-2.fc10
-------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.0-2
- Fix a translation error in Marathi


gnome-packagekit-0.3.8-1.fc10
-----------------------------
* Mon Oct 20 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.8-1
- New upstream version


gnome-system-monitor-2.24.1-1.fc10
----------------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


gnome-terminal-2.24.1-1.fc10
----------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


gnome-themes-2.24.1-1.fc10
--------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


gnome-utils-2.24.1-1.fc10
-------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 1:2.24.1-1
- Update to 2.24.1


gphoto2-2.4.3-1.fc10
--------------------
* Mon Oct 20 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 2.4.3-1
- update to 2.4.3


gtk2-engines-2.16.1-1.fc10
--------------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.16.1-1
- Update to 2.16.1


gucharmap-2.24.1-1.fc10
-----------------------
* Mon Oct 20 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-1
- Update to 2.24.1


gupnp-0.12.2-2.fc10
-------------------
* Mon Oct 20 18:00:00 2008 Colin Walters <walters at verbum.org> 0.12.2-2
- devel package requires gssdp-devel


gupnp-av-0.2.1-4.fc10
---------------------
* Mon Oct 20 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.2.1-4
- Add some requires for the devel package


gvfs-1.0.2-1.fc10
-----------------
* Mon Oct 20 18:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 1.0.2-1
- Update to 1.0.2


hal-0.5.12-4.20081013git.fc10
-----------------------------
* Mon Oct 20 18:00:00 2008 Matthew Garrett <mjg at redhat.com> - 0.5.12-4.20081013git
- Add input.keys capability to appropriate button devices


hunspell-ca-0.20081019-1.fc10
-----------------------------
* Mon Oct 20 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20081019-1
- latest version


kanyremote-5.4-1.fc10
---------------------
* Fri Oct 17 18:00:00 2008 Mikhail Fedotov <anyremote at mail.ru> - 5.4-1
- Enhanced edit configuration file window. Support application details 
  auto wrap. Added Bulgarian translation (thanks to Stanislav Popov)


kdeadmin-4.1.2-4.fc10
---------------------
* Mon Oct 20 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-4
- make %description for kcron, knetworkconf more clear (#467650)
- Requires: kdebase-workspace (for kcm modules)
- cleanup extraneous scriptlets


kernel-2.6.27.3-30.rc1.fc10
---------------------------
* Mon Oct 20 18:00:00 2008 Dave Airlie <airlied at redhat.com> 
- radeon: fix writeback + some warning fixes

* Mon Oct 20 18:00:00 2008 Dave Airlie <airlied at redhat.com> 
- radeon: fix VRAM sizing issue

* Sun Oct 19 18:00:00 2008 Dave Jones <davej at redhat.com>
- Disable debug printks in the memstick drivers.


knetworkmanager-0.7-0.7.20080926svn.fc10
----------------------------------------
* Mon Oct 20 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.7-0.7.20080926svn
- fix icon hack (from 0.7-0.4)


kpackagekit-0.3.1-3.fc10
------------------------
* Mon Oct 20 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.rog> 0.3.1-3
- patch kpackagekit.desktop (guessed correct X-DBUS-ServiceName value), 
  fixes: KDEInit could not launch "/usr/bin/kpackagekit" 
- cleanup %files


kst-1.7.0-3.fc10
----------------
* Fri Oct 17 18:00:00 2008 Matthew Truch <matt at truch.net> - 1.7.0-3
- Include patch from upstream to fix savePeriod.


libgcrypt-1.4.3-2.fc10
----------------------
* Mon Oct 20 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> 1.4.3-2
- disable asm on sparc64


libgnomedb-3.1.2-1.fc10
-----------------------
* Mon Oct 20 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 1:3.1.2-1
- Update to upstream 3.1.2
- 64-bit patch upstreamed
- Some directories renamed


libgphoto2-2.4.3-1.fc10
-----------------------
* Mon Oct 20 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 2.4.3-1
- update to libgphoto2-2.4.3


Broken deps for i386
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.x86_64 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.ppc requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From twoerner at redhat.com  Tue Oct 21 10:50:48 2008
From: twoerner at redhat.com (Thomas Woerner)
Date: Tue, 21 Oct 2008 12:50:48 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <1224576333.16910.55.camel@macbook.infradead.org>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>
	<48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<1224467293.15123.54.camel@code.and.org>	<2e1016076dc37ee5246b6a393869ff5d.squirrel@arekh.dyndns.org>
	<1224576333.16910.55.camel@macbook.infradead.org>
Message-ID: <48FDB408.5070708@redhat.com>

What about this (maybe silly) idea:

The default desktop installation is not providing a mta like sendmail, 
postfix or exim. A tiny local program is using syslog to collect local 
emails in a file in /var/log in mailbox format. This way emails e.g. 
from cron or mdadm are not lost and a local email reader could be used 
to read the emails. Additionally logrotate would help to keep the amount 
of emails at an acceptable level. SELinux shouldn't be a problem for 
this solution.

A symlink to /var/spool/mail would be nice, but I think that SELinux 
does not like this at all.

If a user needs fetchmail or a real mta, he has to install sendmail, 
postfix or exim. fetchmail could have a requirement for MTA.

What do you think?

Ciao,
Thomas

David Woodhouse wrote:
> On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
>> Also filtering mail on MUA startup is just trainwreak recipe.
>> If you want your MUA to start fast you need to pre-filter junk mail in
>> the background (no not everyone uses gmail and gmail is not perfect
>> anyway).
>>
>> So far, I haven't seen anything beating fetchmail + local MTA +
>> server-side filters + local imap or local maildir delivery in Fedora.
> 
> But if you're using fetchmail, it's too late to filter -- because you
> should be rejecting the stuff you don't want at SMTP time.
> 
> Filtering wants to be done on the _real_ mail server that accepts
> incoming mail. Doing it after fetchmail is almost as bad as doing it in
> the MUA.
> 


-- 
Thomas Woerner
Software Engineer            Phone: +49-711-96437-310
Red Hat GmbH                 Fax  : +49-711-96437-111
Hauptstaetterstr. 58         Email: Thomas Woerner <twoerner at redhat.com>
D-70178 Stuttgart            Web  : http://www.redhat.de/



From opensource at till.name  Tue Oct 21 10:59:33 2008
From: opensource at till.name (Till Maas)
Date: Tue, 21 Oct 2008 12:59:33 +0200
Subject: Sendmail still default?
In-Reply-To: <48FC836C.7000200@gmail.com>
References: <48F87794.3090108@redhat.com>
	<200810200918.19031.opensource@till.name> <48FC836C.7000200@gmail.com>
Message-ID: <200810211259.45068.opensource@till.name>

On Mon October 20 2008, Les Mikesell wrote:
> Till Maas wrote:
> > On Sat October 18 2008, Matthew Woehlke wrote:
> > [E-mail was changed]
> >
> >> Um... which is actually another reason for local mail being default; in
> >> the event a user's mail recipient is not configured, it goes to a local
> >> spool only readable by root and that user. If Sue sets up a computer and
> >> adds an account for Bob, it's not really ideal if Bob's mail gets sent
> >> to sue at EXAMPLE.com because Bob doesn't have a recipient specified.
> >
> > Sending log file contents that may contain sensitive data via unencrypted
> > e-mail is not a good thing to do imho.
>
> Modern MTA's can encrypt transmission if configured to.

Yes, this is possible, but how does this help a non technical user that does 
not know how to this? Also only the encryption of the e-mail itself and 
decrypting on a trusted machine really protects the sensitive data. This is 
probably to complicated for the targeted user, so it would be a lot easier to 
keep the data on the local 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/20081021/44661c70/attachment.sig>

From rjones at redhat.com  Tue Oct 21 11:06:37 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 21 Oct 2008 12:06:37 +0100
Subject: rawhide report: 20081021 changes
In-Reply-To: <20081021105028.9C9EF1B8001@releng2.fedora.phx.redhat.com>
References: <20081021105028.9C9EF1B8001@releng2.fedora.phx.redhat.com>
Message-ID: <20081021110637.GA4833@amd.home.annexia.org>

On Tue, Oct 21, 2008 at 10:50:28AM +0000, Rawhide Report wrote:
> libgphoto2-2.4.3-1.fc10

Seems like it's dying before reaching the end of the list of packages
again.  I rebuilt ocaml-bitstring yesterday, which didn't get listed.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From fedora at matbooth.co.uk  Tue Oct 21 11:30:13 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 21 Oct 2008 12:30:13 +0100
Subject: rawhide report: 20081021 changes
In-Reply-To: <20081021110637.GA4833@amd.home.annexia.org>
References: <20081021105028.9C9EF1B8001@releng2.fedora.phx.redhat.com>
	<20081021110637.GA4833@amd.home.annexia.org>
Message-ID: <9497e9990810210430n416b8733w62fe187ef29c6dd8@mail.gmail.com>

On Tue, Oct 21, 2008 at 12:06 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Tue, Oct 21, 2008 at 10:50:28AM +0000, Rawhide Report wrote:
>> libgphoto2-2.4.3-1.fc10
>
> Seems like it's dying before reaching the end of the list of packages
> again.  I rebuilt ocaml-bitstring yesterday, which didn't get listed.
>
> Rich.
>

The obvious fix is to rename your package so it starts with a letter
further up the alphabet. ;-)


-- 
Mat Booth
www.matbooth.co.uk



From dwmw2 at infradead.org  Tue Oct 21 11:43:52 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 21 Oct 2008 12:43:52 +0100
Subject: Sendmail still default?
In-Reply-To: <200810211259.45068.opensource@till.name>
References: <48F87794.3090108@redhat.com>
	<200810200918.19031.opensource@till.name> <48FC836C.7000200@gmail.com>
	<200810211259.45068.opensource@till.name>
Message-ID: <1224589432.16910.73.camel@macbook.infradead.org>

On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
> Yes, this is possible, but how does this help a non technical user
> that does not know how to this?

Our Exim package should be using TLS by default on all outgoing
connections (to mail servers which support it). And supporting TLS on
incoming connections too.

If there are any _other_ ways it can be improved to help the users who
are technical enough to want it, but not particularly familiar with it,
then please file RFE bugs. We already ship sample config snippets for
decent greylisting, spamassassin, clamav, etc.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pertusus at free.fr  Tue Oct 21 11:47:52 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 21 Oct 2008 13:47:52 +0200
Subject: The Big ACL Opening
In-Reply-To: <20081021115020.391540b4.mschwendt@gmail.com>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
	<1224351482.4219.0.camel@luminos.localdomain>
	<20081021115020.391540b4.mschwendt@gmail.com>
Message-ID: <20081021114752.GB3059@free.fr>

On Tue, Oct 21, 2008 at 11:50:20AM +0200, Michael Schwendt wrote:
> 
> Now you talk about fixing "all the problems".
> So, where is the full documentation on this? For example, will sponsors
> finally be able to touch all their sponsorees' packages if necessary?

Yes, since all sponsors should be uberpackagers. Though today sponsors
are already able to touch all their sponsorees' packages unless they
have closed acls, which is the case only for a small amount of packages.

--
Pat



From mattdm at mattdm.org  Tue Oct 21 11:58:07 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 21 Oct 2008 07:58:07 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <672056.72050.qm@web32801.mail.mud.yahoo.com>
References: <48FCDB2C.7030402@redhat.com>
	<672056.72050.qm@web32801.mail.mud.yahoo.com>
Message-ID: <20081021115807.GA24935@jadzia.bu.edu>

On Mon, Oct 20, 2008 at 12:40:50PM -0700, Orcan Ogetbil wrote:
> *For the curious, the true meaning of "gift" is "poison".

This seems unlikely. It's more probable that it's just a very old false
cognate, or perhaps that the German word is the one that drifted in meaning.


(Oops. I wasn't going to touch this thread.)

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From galibert at pobox.com  Tue Oct 21 12:13:37 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 21 Oct 2008 14:13:37 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FDB408.5070708@redhat.com>
References: <1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
	<2e1016076dc37ee5246b6a393869ff5d.squirrel@arekh.dyndns.org>
	<1224576333.16910.55.camel@macbook.infradead.org>
	<48FDB408.5070708@redhat.com>
Message-ID: <20081021121337.GA48081@dspnet.fr.eu.org>

On Tue, Oct 21, 2008 at 12:50:48PM +0200, Thomas Woerner wrote:
> What about this (maybe silly) idea:
> 
> The default desktop installation is not providing a mta like sendmail, 
> postfix or exim. A tiny local program is using syslog to collect local 
> emails in a file in /var/log in mailbox format. This way emails e.g. 
> from cron or mdadm are not lost and a local email reader could be used 
> to read the emails. Additionally logrotate would help to keep the amount 
> of emails at an acceptable level. SELinux shouldn't be a problem for 
> this solution.

Your tiny local program is not going to stay tiny long.  Feature creep
(multiple log files, routing, filtering, locking...) is going to make
it equivalent to a mail delivery agent.  So just use one.

  OG.



From andrewparker at bigfoot.com  Tue Oct 21 12:18:03 2008
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Tue, 21 Oct 2008 08:18:03 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <20081020171930.GA32654@tango.0pointer.de>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de> <48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<20081020171930.GA32654@tango.0pointer.de>
Message-ID: <6c3f5e6c0810210518nd9d7660g1bb4fedf85130b41@mail.gmail.com>

On Mon, Oct 20, 2008 at 1:19 PM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:

> I am amazed how pointless and ignorant and cheap the principles are
> you chose as yours.

Lennart, being obnoxious does not promote your view, it does the
opposite.  Please refrain from emails like this.



From opensource at till.name  Tue Oct 21 12:27:12 2008
From: opensource at till.name (Till Maas)
Date: Tue, 21 Oct 2008 14:27:12 +0200
Subject: Sendmail still default?
In-Reply-To: <1224589432.16910.73.camel@macbook.infradead.org>
References: <48F87794.3090108@redhat.com>
	<200810211259.45068.opensource@till.name>
	<1224589432.16910.73.camel@macbook.infradead.org>
Message-ID: <200810211427.30249.opensource@till.name>

On Tue October 21 2008, David Woodhouse wrote:
> On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
> > Yes, this is possible, but how does this help a non technical user
> > that does not know how to this?
>
> Our Exim package should be using TLS by default on all outgoing
> connections (to mail servers which support it). And supporting TLS on
> incoming connections too.
>
> If there are any _other_ ways it can be improved to help the users who
> are technical enough to want it, but not particularly familiar with it,
> then please file RFE bugs. We already ship sample config snippets for
> decent greylisting, spamassassin, clamav, etc.

I do not know, because I use gpg for encryption. And this was also not what 
this sub thread initially was about. It was about adding an option to the 
installer that may make unexperienced users send sensitive data via untrusted 
or unencrypted paths.

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/20081021/47d953be/attachment.sig>

From opensource at till.name  Tue Oct 21 12:38:21 2008
From: opensource at till.name (Till Maas)
Date: Tue, 21 Oct 2008 14:38:21 +0200
Subject: Sendmail still default?
In-Reply-To: <1224589432.16910.73.camel@macbook.infradead.org>
References: <48F87794.3090108@redhat.com>
	<200810211259.45068.opensource@till.name>
	<1224589432.16910.73.camel@macbook.infradead.org>
Message-ID: <200810211438.33693.opensource@till.name>

On Tue October 21 2008, David Woodhouse wrote:

> If there are any _other_ ways it can be improved to help the users who
> are technical enough to want it, but not particularly familiar with it,
> then please file RFE bugs. We already ship sample config snippets for
> decent greylisting, spamassassin, clamav, etc.

Uh, I should have thought faster while writing my previous mail, here is my 
RFE to make it easier to gpg encode mails:

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

Thanks & 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/20081021/a36085ac/attachment.sig>

From lesmikesell at gmail.com  Tue Oct 21 13:02:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 08:02:59 -0500
Subject: Sendmail still default?
In-Reply-To: <1224589432.16910.73.camel@macbook.infradead.org>
References: <48F87794.3090108@redhat.com>	<200810200918.19031.opensource@till.name>
	<48FC836C.7000200@gmail.com>	<200810211259.45068.opensource@till.name>
	<1224589432.16910.73.camel@macbook.infradead.org>
Message-ID: <48FDD303.3090808@gmail.com>

David Woodhouse wrote:
> On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
>> Yes, this is possible, but how does this help a non technical user
>> that does not know how to this?
> 
> Our Exim package should be using TLS by default on all outgoing
> connections (to mail servers which support it). And supporting TLS on
> incoming connections too.

Sendmail should do that too.

> If there are any _other_ ways it can be improved to help the users who
> are technical enough to want it, but not particularly familiar with it,
> then please file RFE bugs. We already ship sample config snippets for
> decent greylisting, spamassassin, clamav, etc.

Including a MimeDefang package configured to do the same for sendmail 
would be good.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Tue Oct 21 12:29:36 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 21 Oct 2008 08:29:36 -0400
Subject: post-beta snapshots
In-Reply-To: <1224525044.30113.0.camel@luminos.localdomain>
References: <1224269795.4142.14.camel@luminos.localdomain>
	<1224525044.30113.0.camel@luminos.localdomain>
Message-ID: <20081021122936.GA29006@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> Given that there was no feedback here, Rel Eng approved this adjustment
> at our meeting today.  The last step is getting a nod of approval from
> FESCo so that we can make it happen for this last snapshot.

Sure, go for it.

Bill



From mjg at redhat.com  Tue Oct 21 13:20:03 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 21 Oct 2008 14:20:03 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCD953.3080707@gmail.com>
References: <20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com>
Message-ID: <20081021132003.GA28344@srcf.ucam.org>

On Mon, Oct 20, 2008 at 02:17:39PM -0500, Les Mikesell wrote:
> Matthew Garrett wrote:
> >Once you're beyond the typical desktop use case, then yes, an MTA 
> >probably makes sense. But that's not an argument for an MTA in the 
> >default desktop install.
> 
> OK, if you really are so elitist that you think typical users can't 
> figure out how to use standard programs, consider the case where you 
> install the software for one of your incapable friends or family members 
> and you'd like those impending failure warnings to come to you since the 
> user won't understand them anyway.

I'm pretty solidly of the opinion that email is nowhere near being the 
most sensible way to get important information to a typical desktop 
user. If a failure is important then the user needs to know about it as 
soon as possible - mail provides no guarantees about timely delivery. We 
have plenty of desktop infrastructure to give important alerts to users, 
we're just failing to do so.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From mjg at redhat.com  Tue Oct 21 13:23:29 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 21 Oct 2008 14:23:29 +0100
Subject: Make subpixel smoothing default?
In-Reply-To: <20081021013511.GA7959@gmail.com>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
Message-ID: <20081021132329.GB28344@srcf.ucam.org>

On Mon, Oct 20, 2008 at 08:35:11PM -0500, Ian Weller wrote:

> For the record, it made things look like utter crap on my display. And
> it's an LCD. If people want it, they can get it.

Bug number?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From rc040203 at freenet.de  Tue Oct 21 13:26:32 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 21 Oct 2008 15:26:32 +0200
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <20081021115807.GA24935@jadzia.bu.edu>
References: <48FCDB2C.7030402@redhat.com>
	<672056.72050.qm@web32801.mail.mud.yahoo.com>
	<20081021115807.GA24935@jadzia.bu.edu>
Message-ID: <1224595592.3300.73.camel@beck.corsepiu.local>

On Tue, 2008-10-21 at 07:58 -0400, Matthew Miller wrote:
> On Mon, Oct 20, 2008 at 12:40:50PM -0700, Orcan Ogetbil wrote:
> > *For the curious, the true meaning of "gift" is "poison".
> 
> This seems unlikely. It's more probable that it's just a very old false
> cognate, or perhaps that the German word is the one that drifted in meaning.

The German word "?ber" corresponds more or less 1:1 to the English word
"over" and in everyday live is being used where English speakers would
use "over" or "above".






From lesmikesell at gmail.com  Tue Oct 21 13:11:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 08:11:05 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <745d0762a3660f324070ff48edd82c98.squirrel@arekh.dyndns.org>
References: <48F87794.3090108@redhat.com>
	<48F88769.2010308@gmail.com>	<a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>
	<48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<1224467293.15123.54.camel@code.and.org>	<2e1016076dc37ee5246b6a393869ff5d.squirrel@arekh.dyndns.org>	<1224576333.16910.55.camel@macbook.infradead.org>
	<745d0762a3660f324070ff48edd82c98.squirrel@arekh.dyndns.org>
Message-ID: <48FDD4E9.7090600@gmail.com>

Nicolas Mailhot wrote:
> 
>>> Also filtering mail on MUA startup is just trainwreak recipe.
>>> If you want your MUA to start fast you need to pre-filter junk mail
>>> in
>>> the background (no not everyone uses gmail and gmail is not perfect
>>> anyway).
>>>
>>> So far, I haven't seen anything beating fetchmail + local MTA +
>>> server-side filters + local imap or local maildir delivery in
>>> Fedora.
>> But if you're using fetchmail, it's too late to filter -- because you
>> should be rejecting the stuff you don't want at SMTP time.
>>
>> Filtering wants to be done on the _real_ mail server that accepts
>> incoming mail.
> 
> Sure but many people do not have an ISP that provides clueful
> filtering, and even gmail is not so yummy when you take the privacy
> and no warranty bits into account.
> 
>> Doing it after fetchmail is almost as bad as doing it
>> in the MUA.
> 
> It's not. It means that when you start your MUA, everything is already
> available and filtered, instead for waiting for (10s or more) seconds
> with a massive CPU pike. That makes a huge user experience difference.

The problems are that you don't have a reasonable choice about what to 
do with questionable items at that point and the mail has already been 
accepted from the sender, establishing that you are a valid target if it 
really is spam, probably getting it put on widely sold lists. If your 
filter generates a bounce it will probably go to a forged address and 
contribute to the problem.  On the other hand if you don't generate a 
bounce and your filter is mistaken, you lose legitimate messages - or 
you have to save them in a folder that you manually check.  If you can 
scan during the smtp conversation with the sender you can just reject at 
that point making it someone else's problem.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Oct 21 13:52:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 08:52:27 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021132003.GA28344@srcf.ucam.org>
References: <20081019192624.GC7547@nb.net.home>	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>	<20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>
Message-ID: <48FDDE9B.2090608@gmail.com>

Matthew Garrett wrote:
> On Mon, Oct 20, 2008 at 02:17:39PM -0500, Les Mikesell wrote:
>> Matthew Garrett wrote:
>>> Once you're beyond the typical desktop use case, then yes, an MTA 
>>> probably makes sense. But that's not an argument for an MTA in the 
>>> default desktop install.
>> OK, if you really are so elitist that you think typical users can't 
>> figure out how to use standard programs, consider the case where you 
>> install the software for one of your incapable friends or family members 
>> and you'd like those impending failure warnings to come to you since the 
>> user won't understand them anyway.
> 
> I'm pretty solidly of the opinion that email is nowhere near being the 
> most sensible way to get important information to a typical desktop 
> user. If a failure is important then the user needs to know about it as 
> soon as possible - mail provides no guarantees about timely delivery. We 
> have plenty of desktop infrastructure to give important alerts to users, 
> we're just failing to do so.

If local delivery of mail fails, there's no reason to think any other 
notification method would have succeeded.  The important point is that 
the user may not be present when the event occurs, and that desktop 
infrastructure may not even be running - and even if it is, the 
interested party may want the notification to be forwarded elsewhere.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Oct 21 14:01:46 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 09:01:46 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FCA4EE.5000709@redhat.com>
References: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>	<48F88F62.5080004@gmail.com>	<1224421422.6770.1466.camel@macbook.infradead.org>	<48FB4876.90208@gmail.com>	<1224434315.6770.1477.camel@macbook.infradead.org>	<48FB7694.4050400@gmail.com>	<48FB79CF.2030405@sapience.com>	<20081019113716.276106a8@infradead.org>	<1224467293.15123.54.camel@code.and.org>	<20081019210620.66572efb@infradead.org>	<20081020042636.GA1073485@hiwaay.net>	<48FC81B6.7020503@gmail.com>
	<48FCA4EE.5000709@redhat.com>
Message-ID: <48FDE0CA.3050704@gmail.com>

Phil Knirsch wrote:
> Les Mikesell wrote:
>> Chris Adams wrote:
>>> Once upon a time, Arjan van de Ven <arjan at infradead.org> said:
>>>> most users on the client side use a mail client that has its own
>>>> queuing.
>>>
>>> Most _interactive_ users do.  Most automated tasks (e.g. cron) do not
>>> have any queueing.
>>
>> Even if you are trying to dumb the system down to a Mac's 
>> pseudo-single-user style, you still need crontab and mail to work - as 
>> it does on a Mac.
>>
> 
> What happens to emails generated on a Max OSX via crontab or any other 
> automated system? Does it run sendmail or some equivalent of it?

10.5 runs postfix.

> Just curious how they solve it as on a Mac i'd bet you that hardly any 
> typical user will know what root is.

I don't think anything in the default install sends mail, but if as a 
user you use 'crontab -e' to create a crontab entry, the output is 
delivered to /var/mail/yourlogin and the command line mail and mailx 
programs know where to find it as expected on any unix-like system.
Or you can set MAILTO=  in the crontab if you want it elsewhere. 
Following standards is a good thing...

-- 
   Les Mikesell
    lesmikesell at gmail.com





From mjg at redhat.com  Tue Oct 21 14:07:13 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 21 Oct 2008 15:07:13 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FDDE9B.2090608@gmail.com>
References: <1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com>
Message-ID: <20081021140713.GA29430@srcf.ucam.org>

On Tue, Oct 21, 2008 at 08:52:27AM -0500, Les Mikesell wrote:
> Matthew Garrett wrote:
> >I'm pretty solidly of the opinion that email is nowhere near being the 
> >most sensible way to get important information to a typical desktop 
> >user. If a failure is important then the user needs to know about it as 
> >soon as possible - mail provides no guarantees about timely delivery. We 
> >have plenty of desktop infrastructure to give important alerts to users, 
> >we're just failing to do so.
> 
> If local delivery of mail fails, there's no reason to think any other 
> notification method would have succeeded.  The important point is that 
> the user may not be present when the event occurs, and that desktop 
> infrastructure may not even be running - and even if it is, the 
> interested party may want the notification to be forwarded elsewhere.

Local delivery of mail is a poor solution, since it provides no 
indication of priority difference between "You've got spam" and "Your 
hard drive is failing". If there's nobody to present it to, it can be 
queued and presented at login - if the user is running on their system 
but doesn't have the desktop infrastructure running, then by definition 
they're already outside the standard desktop usecase.

I'm not arguing about the utility of an MTA for various situations. I'm 
arguing that for one specific and very common situation, using an MTA to 
deliver system alerts is a poor way of handling it. We should fix that. 
As a happy side effect, it removes the need for a default MTA in the 
desktop install. People who want an MTA then get to choose whichever MTA 
they want and net human happiness is increased.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From dr.diesel at gmail.com  Tue Oct 21 14:16:48 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Tue, 21 Oct 2008 09:16:48 -0500
Subject: Make subpixel smoothing default?
In-Reply-To: <20081021013511.GA7959@gmail.com>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
Message-ID: <2a28d2ab0810210716u7c6af595q51e757f60fc052b1@mail.gmail.com>

2008/10/20 Ian Weller <ianweller at gmail.com>:
> On Mon, Oct 20, 2008 at 07:44:22PM -0400, Dr. Diesel wrote:
>> I didn't even know this option existed, and man does it look better!
>> Considering 95% of displays are now LCDs should this option be the
>> default?
>>
> For the record, it made things look like utter crap on my display. And
> it's an LCD. If people want it, they can get it.
>

I'm willing to bet the vast majority will find it looks better, if in
your case, they can turn it off...


-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org



From arjan at infradead.org  Tue Oct 21 14:29:50 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 21 Oct 2008 07:29:50 -0700
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FDDE9B.2090608@gmail.com>
References: <20081019192624.GC7547@nb.net.home>
	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com>
Message-ID: <20081021072950.5dec77aa@infradead.org>

On Tue, 21 Oct 2008 08:52:27 -0500
Les Mikesell <lesmikesell at gmail.com> wrote:

> > I'm pretty solidly of the opinion that email is nowhere near being
> > the most sensible way to get important information to a typical
> > desktop user. If a failure is important then the user needs to know
> > about it as soon as possible - mail provides no guarantees about
> > timely delivery. We have plenty of desktop infrastructure to give
> > important alerts to users, we're just failing to do so.
> 
> If local delivery of mail fails, there's no reason to think any other 
> notification method would have succeeded. 

local mail is rather taxing on a system. If a harddisk is marginal for
example... a mail delivery will cause the entire pagecache to be
written to the disk, and guess what... the MTA will get stuck on that.

And that assumes that the local user even reads "root" email.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From alan at redhat.com  Tue Oct 21 14:33:43 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Oct 2008 10:33:43 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021140713.GA29430@srcf.ucam.org>
References: <20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
Message-ID: <20081021143343.GA16367@shell.devel.redhat.com>

On Tue, Oct 21, 2008 at 03:07:13PM +0100, Matthew Garrett wrote:
> queued and presented at login - if the user is running on their system 
> but doesn't have the desktop infrastructure running, then by definition 
> they're already outside the standard desktop usecase.

You mean like boot, shutdown, being logged out, ...

> As a happy side effect, it removes the need for a default MTA in the 
> desktop install. People who want an MTA then get to choose whichever MTA 

Actually that I question somewhat. Both POSIX and the LSB require local mail
delivery services. A suprising number of applications that don't currently
specify sendmail dependancies appear to use it. Have a grep...

And if we are going to worry about desktop experiences then perhaps making
evolution not totally suck, fixing the way the desktop totally disintegrates
when you run out of disk space, a working gdm again and a few other items
would be far better use of time than macdinking with log delivery.

My own experience is that if you are using gnome and run out of local disk and
or quota the fact your mail is not delivered is the least of the problems, 
and managing to log in and then having to restore half your desktop settings
are far bigger ones.

Alan



From jkeating at redhat.com  Tue Oct 21 14:34:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 21 Oct 2008 07:34:07 -0700
Subject: The Big ACL Opening
In-Reply-To: <20081021115020.391540b4.mschwendt@gmail.com>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
	<1224351482.4219.0.camel@luminos.localdomain>
	<20081021115020.391540b4.mschwendt@gmail.com>
Message-ID: <1224599647.30113.11.camel@luminos.localdomain>

On Tue, 2008-10-21 at 11:50 +0200, Michael Schwendt wrote:
> 
> Now you talk about fixing "all the problems".
> So, where is the full documentation on this? For example, will sponsors
> finally be able to touch all their sponsorees' packages if necessary?

This particular change is not yet made, however I think some of the work
Casey and Toshio did for the change we did make would make this bit
easier, to have it specific rather than implicit via the uberpackager
group as Patrice suggests.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/eb5ed4a2/attachment.sig>

From mattdm at mattdm.org  Tue Oct 21 14:38:30 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 21 Oct 2008 10:38:30 -0400
Subject: Make subpixel smoothing default?
In-Reply-To: <2a28d2ab0810210716u7c6af595q51e757f60fc052b1@mail.gmail.com>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<2a28d2ab0810210716u7c6af595q51e757f60fc052b1@mail.gmail.com>
Message-ID: <20081021143830.GB10875@jadzia.bu.edu>

On Tue, Oct 21, 2008 at 09:16:48AM -0500, Dr. Diesel wrote:
> >> I didn't even know this option existed, and man does it look better!
> >> Considering 95% of displays are now LCDs should this option be the
> >> default?
> > For the record, it made things look like utter crap on my display. And
> > it's an LCD. If people want it, they can get it.
> I'm willing to bet the vast majority will find it looks better, if in
> your case, they can turn it off...

It depends a lot on your monitor. If you've got relatively large pixels, the
colored fringes can be very visible and distracting. If you've got a
high-PPI monitor, it can look quite good -- but then, of course, you need
it less.

I also find that it looks much worse for light text on black background
(i.e. old-school terminal windows) than for dark text on light (the typical
modern default terminals and most modern web sites).

But here's my concern with making it the default: if you get the subpixel
layout wrong, it looks very very bad. What percentage of monitors are RGB
instead of BGR? (Might it be possible for HAL (or something) to tell the
desktop enviroment this?) What about tablets? -- if you rotate the screen
90?, your text is definitely horribly wrong in one of the orientations.


<http://www.lagom.nl/lcd-test/subpixel.php> is useful here, by the way. It'd
be nice if the desktop UIs for this option presented a similar test (if
indeed there is no good way to get the information automatically.)


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mattdm at mattdm.org  Tue Oct 21 14:40:26 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 21 Oct 2008 10:40:26 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021072950.5dec77aa@infradead.org>
References: <20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com>
	<20081021072950.5dec77aa@infradead.org>
Message-ID: <20081021144026.GC10875@jadzia.bu.edu>

On Tue, Oct 21, 2008 at 07:29:50AM -0700, Arjan van de Ven wrote:
> And that assumes that the local user even reads "root" email.

This definitely needs to be addressed as part of this discussion. There's
two parts, really:

 1) Root mail needs to go somewhere useful.
 2) The world needs something better than Logwatch.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From nicolas.mailhot at laposte.net  Tue Oct 21 14:40:23 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 21 Oct 2008 16:40:23 +0200 (CEST)
Subject: Make subpixel smoothing default?
In-Reply-To: <20081021132329.GB28344@srcf.ucam.org>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<20081021132329.GB28344@srcf.ucam.org>
Message-ID: <7babc0950077e4e6fa4f1154d7e3ed34.squirrel@arekh.dyndns.org>



Le Mar 21 octobre 2008 15:23, Matthew Garrett a ?crit :
>
> On Mon, Oct 20, 2008 at 08:35:11PM -0500, Ian Weller wrote:
>
>> For the record, it made things look like utter crap on my display.
>> And
>> it's an LCD. If people want it, they can get it.
>
> Bug number?

Subpixel works well on laptops. On desktops people tend to be more
sensitive to the color fringes even if they do have a LCD. Grayscale
works best in that case.

-- 
Nicolas Mailhot



From mschwendt at gmail.com  Tue Oct 21 14:48:47 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 16:48:47 +0200
Subject: rawhide report: 20081021 changes
In-Reply-To: <20081021110637.GA4833@amd.home.annexia.org>
References: <20081021105028.9C9EF1B8001@releng2.fedora.phx.redhat.com>
	<20081021110637.GA4833@amd.home.annexia.org>
Message-ID: <20081021164847.5667317b.mschwendt@gmail.com>

On Tue, 21 Oct 2008 12:06:37 +0100, Richard W.M. Jones wrote:

> On Tue, Oct 21, 2008 at 10:50:28AM +0000, Rawhide Report wrote:
> > libgphoto2-2.4.3-1.fc10
> 
> Seems like it's dying before reaching the end of the list of packages
> again.  I rebuilt ocaml-bitstring yesterday, which didn't get listed.

The next entry would have been (note the special character in his
first name!):

libgsf-1.14.10-1.fc10
---------------------
* Tue Oct 21 00:00:00 2008 Caol?n McNamara <caolanm at redhat.com> 1.14.10-1
- latest version



From pertusus at free.fr  Tue Oct 21 14:50:35 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 21 Oct 2008 16:50:35 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021143343.GA16367@shell.devel.redhat.com>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
Message-ID: <20081021145035.GB26273@free.fr>

On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
> 
> Actually that I question somewhat. Both POSIX and the LSB require local mail
> delivery services. A suprising number of applications that don't currently
> specify sendmail dependancies appear to use it. Have a grep...

Every package with application that calls /usr/sbin/sendmail should 
require that file. Isn't it the case? If you know about cases like that,
tell, I'll file bugs.

Now this is only part of the story since currently programs that don't
do local delivery, or are not configured for local delivery out-of-the-box 
provides /usr/sbin/sendmail. I think that is is right, but maybe a
virtual dependency, like mail(local) is needed somewhere to force
installation of an app that does local delivery, either as a dependency,
or as part of the default install, though there is no agreement on that
currently.

--
Pat



From mattdm at mattdm.org  Tue Oct 21 14:53:15 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 21 Oct 2008 10:53:15 -0400
Subject: Make subpixel smoothing default?
In-Reply-To: <7babc0950077e4e6fa4f1154d7e3ed34.squirrel@arekh.dyndns.org>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<20081021132329.GB28344@srcf.ucam.org>
	<7babc0950077e4e6fa4f1154d7e3ed34.squirrel@arekh.dyndns.org>
Message-ID: <20081021145315.GA14556@jadzia.bu.edu>

On Tue, Oct 21, 2008 at 04:40:23PM +0200, Nicolas Mailhot wrote:
> Subpixel works well on laptops. On desktops people tend to be more
> sensitive to the color fringes even if they do have a LCD. Grayscale
> works best in that case.

Interesting observation. I expect this is due at least in part to what I
noted about resolution and pixels-per-inch: my nice big LCD screen has 89ppi
(full pixels), whereas my Vaio U101 has 180ppi. The later is an extremely
nice little screen, but even a more typical laptop generally has over 100.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From pertusus at free.fr  Tue Oct 21 15:00:55 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 21 Oct 2008 17:00:55 +0200
Subject: The Big ACL Opening
In-Reply-To: <1224599647.30113.11.camel@luminos.localdomain>
References: <48F64212.2010505@redhat.com>
	<1224305476.28644.15.camel@victoria-eth.internal.frields.org>
	<1224308827.8880.21.camel@fantail.jnet.net.nz>
	<200810180900.18085.opensource@till.name>
	<364d303b0810180201y4d7010c3t196896fdf30445d0@mail.gmail.com>
	<1224351482.4219.0.camel@luminos.localdomain>
	<20081021115020.391540b4.mschwendt@gmail.com>
	<1224599647.30113.11.camel@luminos.localdomain>
Message-ID: <20081021150055.GC26273@free.fr>

On Tue, Oct 21, 2008 at 07:34:07AM -0700, Jesse Keating wrote:
> On Tue, 2008-10-21 at 11:50 +0200, Michael Schwendt wrote:
> > 
> > Now you talk about fixing "all the problems".
> > So, where is the full documentation on this? For example, will sponsors
> > finally be able to touch all their sponsorees' packages if necessary?
> 
> This particular change is not yet made, however I think some of the work
> Casey and Toshio did for the change we did make would make this bit
> easier, to have it specific rather than implicit via the uberpackager
> group as Patrice suggests.

Well, I think that having all sponsor be uberpackager is enough to give
them enough rights to touch the sponsoree packages, and it would be
consistent with 
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages#afterinclude
to have them able to touch almost everybody packages.

(in fact, many packagers who aren't considered to be "Experienced
packagers" will be uberpackagers, although they are not necessarily up
to the task, just because it was the only possible status in the past).

But what would still be missing would be something that allow to setup
watchbugzilla and watchcommit per-person and not per-package, such that
someone can monitor someone else new packages/packages the person
co-maintains. The sponsor would automatically monitor the person 
he sponsored (and could stop do so when he wants to).

--
Pat



From lesmikesell at gmail.com  Tue Oct 21 15:02:02 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 10:02:02 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021072950.5dec77aa@infradead.org>
References: <20081019192624.GC7547@nb.net.home>	<faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>	<1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>	<20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>
	<20081021072950.5dec77aa@infradead.org>
Message-ID: <48FDEEEA.4070508@gmail.com>

Arjan van de Ven wrote:
> On Tue, 21 Oct 2008 08:52:27 -0500
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
>>> I'm pretty solidly of the opinion that email is nowhere near being
>>> the most sensible way to get important information to a typical
>>> desktop user. If a failure is important then the user needs to know
>>> about it as soon as possible - mail provides no guarantees about
>>> timely delivery. We have plenty of desktop infrastructure to give
>>> important alerts to users, we're just failing to do so.
>> If local delivery of mail fails, there's no reason to think any other 
>> notification method would have succeeded. 
> 
> local mail is rather taxing on a system. 

Which is why mail is a sensible delivery mechanism.  It already knows 
how to deliver elsewhere if you want.

> If a harddisk is marginal for
> example... a mail delivery will cause the entire pagecache to be
> written to the disk, and guess what... the MTA will get stuck on that.

Which is why it is important to get the warning messages from smartctl 
and the disk space check _before_ you are toast.  Face it - nothing is 
going to save you after the disk fries or is completely out of space.

> And that assumes that the local user even reads "root" email.

That's the piece that needs to be fixed.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mattdm at mattdm.org  Tue Oct 21 14:27:31 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 21 Oct 2008 10:27:31 -0400
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <1224595592.3300.73.camel@beck.corsepiu.local>
References: <48FCDB2C.7030402@redhat.com>
	<672056.72050.qm@web32801.mail.mud.yahoo.com>
	<20081021115807.GA24935@jadzia.bu.edu>
	<1224595592.3300.73.camel@beck.corsepiu.local>
Message-ID: <20081021142731.GA10875@jadzia.bu.edu>

On Tue, Oct 21, 2008 at 03:26:32PM +0200, Ralf Corsepius wrote:
> > On Mon, Oct 20, 2008 at 12:40:50PM -0700, Orcan Ogetbil wrote:
> > > *For the curious, the true meaning of "gift" is "poison".
> > This seems unlikely. It's more probable that it's just a very old false
> > cognate, or perhaps that the German word is the one that drifted in meaning.
> The German word "?ber" corresponds more or less 1:1 to the English word
> "over" and in everyday live is being used where English speakers would
> use "over" or "above".

Yeah, you're talking to a guy with a t-shirt that says "?bergeek".

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From galibert at pobox.com  Tue Oct 21 14:27:03 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 21 Oct 2008 16:27:03 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021132003.GA28344@srcf.ucam.org>
References: <faa16b610810191232w54a12dafy6f289d4212a0da39@mail.gmail.com>
	<1224467278.25634.4.camel@rosebud>
	<20081020021340.GA7740@jadzia.bu.edu>
	<20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
Message-ID: <20081021142703.GA70905@dspnet.fr.eu.org>

On Tue, Oct 21, 2008 at 02:20:03PM +0100, Matthew Garrett wrote:
> I'm pretty solidly of the opinion that email is nowhere near being the 
> most sensible way to get important information to a typical desktop 
> user. If a failure is important then the user needs to know about it as 
> soon as possible - mail provides no guarantees about timely delivery. We 
> have plenty of desktop infrastructure to give important alerts to users, 
> we're just failing to do so.

Important does not always mean urgent, and there are a lot of cases
when the person in front of the keyboard, if any, is not the one
interested in the information.

Another way to say it is "stop thinking in Microsoft Windows terms".

  OG.



From lesmikesell at gmail.com  Tue Oct 21 15:10:37 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 10:10:37 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021140713.GA29430@srcf.ucam.org>
References: <1224467278.25634.4.camel@rosebud>	<20081020021340.GA7740@jadzia.bu.edu>	<20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>
	<20081021140713.GA29430@srcf.ucam.org>
Message-ID: <48FDF0ED.9020705@gmail.com>

Matthew Garrett wrote:
> 
>>> I'm pretty solidly of the opinion that email is nowhere near being the 
>>> most sensible way to get important information to a typical desktop 
>>> user. If a failure is important then the user needs to know about it as 
>>> soon as possible - mail provides no guarantees about timely delivery. We 
>>> have plenty of desktop infrastructure to give important alerts to users, 
>>> we're just failing to do so.
>> If local delivery of mail fails, there's no reason to think any other 
>> notification method would have succeeded.  The important point is that 
>> the user may not be present when the event occurs, and that desktop 
>> infrastructure may not even be running - and even if it is, the 
>> interested party may want the notification to be forwarded elsewhere.
> 
> Local delivery of mail is a poor solution, since it provides no 
> indication of priority difference between "You've got spam" and "Your 
> hard drive is failing". 

That's a solvable problem within the context of email, whereas starting 
from scratch and re-inventing delivery to arbitrary user-selectable 
endpoints is somewhat insane.

> If there's nobody to present it to, it can be 
> queued and presented at login - if the user is running on their system 
> but doesn't have the desktop infrastructure running, then by definition 
> they're already outside the standard desktop usecase.

Does that mean their system should die with no attempt at notification? 
  Or that desktop administration should be confusingly different than 
standard systems?

> I'm not arguing about the utility of an MTA for various situations. I'm 
> arguing that for one specific and very common situation, using an MTA to 
> deliver system alerts is a poor way of handling it. We should fix that. 

No, you should fix it so mail delivery is useful.

> As a happy side effect, it removes the need for a default MTA in the 
> desktop install.

Unless, of course, you care to follow standards.

> People who want an MTA then get to choose whichever MTA 
> they want and net human happiness is increased.

That has been the case for some time already.  As long as the 
alternative presents a command-line compatible /usr/sbin/sendmail, 
standard programs will work.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Oct 21 15:14:40 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 10:14:40 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021145035.GB26273@free.fr>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>
	<20081021140713.GA29430@srcf.ucam.org>	<20081021143343.GA16367@shell.devel.redhat.com>
	<20081021145035.GB26273@free.fr>
Message-ID: <48FDF1E0.2080802@gmail.com>

Patrice Dumas wrote:
> On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
>> Actually that I question somewhat. Both POSIX and the LSB require local mail
>> delivery services. A suprising number of applications that don't currently
>> specify sendmail dependancies appear to use it. Have a grep...
> 
> Every package with application that calls /usr/sbin/sendmail should 
> require that file. Isn't it the case? If you know about cases like that,
> tell, I'll file bugs.

If POSIX requires it, it should be a safe assumption on any system that 
claims compliance.

> Now this is only part of the story since currently programs that don't
> do local delivery, or are not configured for local delivery out-of-the-box 
> provides /usr/sbin/sendmail. I think that is is right, but maybe a
> virtual dependency, like mail(local) is needed somewhere to force
> installation of an app that does local delivery, either as a dependency,
> or as part of the default install, though there is no agreement on that
> currently.

Apps that send mail don't and shouldn't know where delivery is going to 
happen.  That is entirely up to the transport.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Tue Oct 21 15:16:13 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 21 Oct 2008 11:16:13 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FDEEEA.4070508@gmail.com>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com>
	<20081021072950.5dec77aa@infradead.org>
	<48FDEEEA.4070508@gmail.com>
Message-ID: <20081021151613.GA2968@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
> Which is why mail is a sensible delivery mechanism.  It already knows  
> how to deliver elsewhere if you want.

With built-in mechanisms to allow for easy spoofing of critical events
to the user from anyone on the internet, no less!

This is outside of the issue that any such critical notification delivered
via e-mail makes it nigh-impossible to safely and sanely undertake
specific actions on user input acting on the notice.

Should the information be sent via e-mail to an adminstrator, and
stored for later viewing in general? Yes. Does that mean e-mail is
the best mechanism for presenting it? No.

Bill



From nicolas.mailhot at laposte.net  Tue Oct 21 15:17:04 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 21 Oct 2008 17:17:04 +0200 (CEST)
Subject: Make subpixel smoothing default?
In-Reply-To: <20081021145315.GA14556@jadzia.bu.edu>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<20081021132329.GB28344@srcf.ucam.org>
	<7babc0950077e4e6fa4f1154d7e3ed34.squirrel@arekh.dyndns.org>
	<20081021145315.GA14556@jadzia.bu.edu>
Message-ID: <af452d8dd4d5100476e7c6ebbb7c044f.squirrel@arekh.dyndns.org>



Le Mar 21 octobre 2008 16:53, Matthew Miller a ?crit :
>
> On Tue, Oct 21, 2008 at 04:40:23PM +0200, Nicolas Mailhot wrote:
>> Subpixel works well on laptops. On desktops people tend to be more
>> sensitive to the color fringes even if they do have a LCD. Grayscale
>> works best in that case.
>
> Interesting observation. I expect this is due at least in part to what
> I
> noted about resolution and pixels-per-inch: my nice big LCD screen has
> 89ppi
> (full pixels), whereas my Vaio U101 has 180ppi. The later is an
> extremely
> nice little screen, but even a more typical laptop generally has over
> 100.

That and people who use laptops have usually already compromised a lot
on the screen part, so they accept fringing better.

-- 
Nicolas Mailhot



From lesmikesell at gmail.com  Tue Oct 21 15:37:22 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 10:37:22 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021151613.GA2968@nostromo.devel.redhat.com>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>	<20081021072950.5dec77aa@infradead.org>	<48FDEEEA.4070508@gmail.com>
	<20081021151613.GA2968@nostromo.devel.redhat.com>
Message-ID: <48FDF732.6090201@gmail.com>

Bill Nottingham wrote:
> Les Mikesell (lesmikesell at gmail.com) said: 
>> Which is why mail is a sensible delivery mechanism.  It already knows  
>> how to deliver elsewhere if you want.
> 
> With built-in mechanisms to allow for easy spoofing of critical events
> to the user from anyone on the internet, no less!

I'm surprised you are able to do that with fedora's default mail 
configuration that only accepts from localhost...  Perhaps you should 
let us in on the secret.

> This is outside of the issue that any such critical notification delivered
> via e-mail makes it nigh-impossible to safely and sanely undertake
> specific actions on user input acting on the notice.

What?  If there was a specific way to fix the problem you should just do 
it without bothering a user.

> Should the information be sent via e-mail to an adminstrator, and
> stored for later viewing in general? Yes. Does that mean e-mail is
> the best mechanism for presenting it? No.

If you have a bad email mechanism, fix that problem.

--
   Les Mikesell
     lesmikesell at gmail.com



From ajax at redhat.com  Tue Oct 21 15:38:43 2008
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 21 Oct 2008 11:38:43 -0400
Subject: Make subpixel smoothing default?
In-Reply-To: <20081021143830.GB10875@jadzia.bu.edu>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<2a28d2ab0810210716u7c6af595q51e757f60fc052b1@mail.gmail.com>
	<20081021143830.GB10875@jadzia.bu.edu>
Message-ID: <1224603523.4998.29.camel@atropine.boston.devel.redhat.com>

On Tue, 2008-10-21 at 10:38 -0400, Matthew Miller wrote:

> It depends a lot on your monitor. If you've got relatively large pixels, the
> colored fringes can be very visible and distracting. If you've got a
> high-PPI monitor, it can look quite good -- but then, of course, you need
> it less.
> 
> I also find that it looks much worse for light text on black background
> (i.e. old-school terminal windows) than for dark text on light (the typical
> modern default terminals and most modern web sites).
>
> But here's my concern with making it the default: if you get the subpixel
> layout wrong, it looks very very bad. What percentage of monitors are RGB
> instead of BGR? (Might it be possible for HAL (or something) to tell the
> desktop enviroment this?) What about tablets? -- if you rotate the screen
> 90?, your text is definitely horribly wrong in one of the orientations.

Monitors are overwhelmingly RGB left to right.  EDID has an extension
for telling you about this, but it's typically not provided, so for the
most part we just guess RGB and tend to be right.

In RANDR 1.2 pixel layout is available as a per-output property, so in
principle you can get this right on every piece of glass.  If you have
one rotated and one normal though, there's no getting it right, short of
fixing gtk to re-render glyphs where the window straddles or crosses
screen boundaries, or just falling back to grayscale AA for everything.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/cba92343/attachment.sig>

From notting at redhat.com  Tue Oct 21 15:44:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 21 Oct 2008 11:44:01 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FDF732.6090201@gmail.com>
References: <20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com>
	<20081021072950.5dec77aa@infradead.org>
	<48FDEEEA.4070508@gmail.com>
	<20081021151613.GA2968@nostromo.devel.redhat.com>
	<48FDF732.6090201@gmail.com>
Message-ID: <20081021154401.GA3312@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
> Bill Nottingham wrote:
>> Les Mikesell (lesmikesell at gmail.com) said: 
>>> Which is why mail is a sensible delivery mechanism.  It already knows 
>>>  how to deliver elsewhere if you want.
>>
>> With built-in mechanisms to allow for easy spoofing of critical events
>> to the user from anyone on the internet, no less!
>
> I'm surprised you are able to do that with fedora's default mail  
> configuration that only accepts from localhost...  Perhaps you should  
> let us in on the secret.

????

We're talking about arbitrary mail delivery. It could be forwarded
to any e-mail account, anywhere. (After all, that's what you're asking
for with redirection of root e-mail.)  Ergo, anyone with knowledge of
1) your e-mail address 2) your machine could send you a spoof/phishing/etc.

>> Should the information be sent via e-mail to an adminstrator, and
>> stored for later viewing in general? Yes. Does that mean e-mail is
>> the best mechanism for presenting it? No.
>
> If you have a bad email mechanism, fix that problem.

I think attempting to have all cron/alert/whatever mail gpg-signed
with a host-specific key would be waaaaaaaaaaaay overkill.

Bill



From alan at redhat.com  Tue Oct 21 16:13:57 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Oct 2008 12:13:57 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021145035.GB26273@free.fr>
References: <48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
	<20081021145035.GB26273@free.fr>
Message-ID: <20081021161357.GA27320@shell.devel.redhat.com>

On Tue, Oct 21, 2008 at 04:50:35PM +0200, Patrice Dumas wrote:
> On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
> > 
> > Actually that I question somewhat. Both POSIX and the LSB require local mail
> > delivery services. A suprising number of applications that don't currently
> > specify sendmail dependancies appear to use it. Have a grep...
> 
> Every package with application that calls /usr/sbin/sendmail should 
> require that file. Isn't it the case? If you know about cases like that,
> tell, I'll file bugs.

Try grep. That is how I did a scan.




From vonbrand at inf.utfsm.cl  Tue Oct 21 16:24:28 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 21 Oct 2008 13:24:28 -0300
Subject: uberpackager rename (was Re: The Big ACL Opening)
In-Reply-To: <loom.20081020T160448-179@post.gmane.org>
References: <48F64212.2010505@redhat.com>
	<20081016171451.GA7049@tango.0pointer.de>
	<48FB5DC3.1060409@gmail.com>
	<1224496369.6770.1544.camel@macbook.infradead.org>
	<loom.20081020T160448-179@post.gmane.org>
Message-ID: <200810211624.m9LGOSrW005261@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> David Woodhouse <dwmw2 <at> infradead.org> writes:
> > No, I'm offended by the idea that a common root used in many geek words

> ... by ignorant Americans who are unaware of the true meaning of that
> term!

So? It is not /that/ far off the true meaning in any case.

> > can so easily be declared 'unclean' and eradicated. This is political
> > correctness at its worst, and I find it horrifically offensive. And
> > that's a _current_ issue, not one from the previous millennium.

> The current issue is that it makes Fedora look ignorant.

There might be bad political overtones for some, but ignorant?
-- 
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 2340000       Fax:  +56 32 2797513



From vonbrand at inf.utfsm.cl  Tue Oct 21 16:28:27 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 21 Oct 2008 13:28:27 -0300
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <1224519567.3300.18.camel@beck.corsepiu.local>
References: <a788154c292440378d83f2e7ee953850.squirrel@arekh.dyndns.org>
	<48F88F62.5080004@gmail.com>
	<1224421422.6770.1466.camel@macbook.infradead.org>
	<48FB4876.90208@gmail.com>
	<1224434315.6770.1477.camel@macbook.infradead.org>
	<48FB7694.4050400@gmail.com> <48FB79CF.2030405@sapience.com>
	<20081019113716.276106a8@infradead.org>
	<1224467293.15123.54.camel@code.and.org>
	<20081019210620.66572efb@infradead.org>
	<20081020042636.GA1073485@hiwaay.net>
	<48FC81B6.7020503@gmail.com> <48FCA4EE.5000709@redhat.com>
	<1224519567.3300.18.camel@beck.corsepiu.local>
Message-ID: <200810211628.m9LGSR0v005325@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Mon, 2008-10-20 at 17:34 +0200, Phil Knirsch wrote:

[...]

> > What happens to emails generated on a Max OSX via crontab or any other 
> > automated system?

> No clue about the MACs, but what about "mailx"?
> 
> It is mandated by POSIX and should be sufficient for local mail
> delivery.

Its manpage here doesn't mention local delivery, just caching and
disconnected operation for IMAP.

[Local delivery is normally handled by a separate program in any case,
 today typically procmail]
-- 
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 2340000       Fax:  +56 32 2797513



From stlwrt at gmail.com  Tue Oct 21 16:35:27 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Tue, 21 Oct 2008 19:35:27 +0300
Subject: Make subpixel smoothing default?
In-Reply-To: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
Message-ID: <d25f375f0810210935s30dec5b0r5ac238ffef63c853@mail.gmail.com>

Isn't subpixel rendering patent-encumbered thing? AFAIK by default
there's only grayscale antialiasing unless you install
freetype-freeworld

On Tue, Oct 21, 2008 at 2:44 AM, Dr. Diesel <dr.diesel at gmail.com> wrote:
> I didn't even know this option existed, and man does it look better!
> Considering 95% of displays are now LCDs should this option be the
> default?
>
>
>
> --
> projecthuh.com
> All of my bits are free, are yours?  Fedoraproject.org
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com



From poelstra at redhat.com  Tue Oct 21 16:40:39 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 21 Oct 2008 09:40:39 -0700
Subject: Fedora Release Engineering Meeting Recap 2008-10-20 
Message-ID: <48FE0607.4020607@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-oct-20

Please make corrections and clarifications to the wiki page.

== Fedora 10 Snap 2 ==
* bittorrent went much better compared to Snap1
** pre-seeders helped
* 700 downloads so far
* Finding that a little more time is needed to get bittorrent setup for 
good user experience
* Last snapshot is Snapshot 3 this week before Final Development Freeze 
next week
* '''DECISION''':
** Rel-eng approves adjusting snapshots to start on Wed to give extra 
time to stage/prepare the torrents
** Moving on to FESCo for final approval, may happen in time for Snapshot 3

== Signing Server ==
* proposal: https://fedoraproject.org/wiki/User:Mitr
** basically, it's 1 dedicated server/VM guest to do the signatures, and 
1 network server to help with security, interface with koji, etc.
* Everyone should read proposal and give feedback before next week's 
meeting

== IRC Transcript ==



From mike at miketc.net  Tue Oct 21 15:21:38 2008
From: mike at miketc.net (Mike Chambers)
Date: Tue, 21 Oct 2008 10:21:38 -0500
Subject: Rawhide compose fail?
Message-ID: <1224602498.9249.0.camel@scrappy.miketc.net>

Did a rawhide build fail today/this morning, therefore no images or
anything else for now?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From orion at cora.nwra.com  Tue Oct 21 16:42:05 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 21 Oct 2008 10:42:05 -0600
Subject: Impossible to run Sun Java plugin on 64-bit Fedora 9/10?
Message-ID: <48FE065D.4020703@cora.nwra.com>

Looks like -

* no firefox.i386 for x86_64 Fedora
* nspluginwrapper does not handle Sun java plugin

So, no Sun Java plugin for x86_64 Fedora 9?  Is that correct?

-- 
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 pbrobinson at gmail.com  Tue Oct 21 16:56:15 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 21 Oct 2008 17:56:15 +0100
Subject: Make subpixel smoothing default?
In-Reply-To: <d25f375f0810210935s30dec5b0r5ac238ffef63c853@mail.gmail.com>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<d25f375f0810210935s30dec5b0r5ac238ffef63c853@mail.gmail.com>
Message-ID: <5256d0b0810210956t7377a8dcve1dbe68d27b429a5@mail.gmail.com>

> Isn't subpixel rendering patent-encumbered thing? AFAIK by default
> there's only grayscale antialiasing unless you install
> freetype-freeworld

Yes, there's been some discussion on this on the cairo mailing list
over the month or two. It seems there cooking up some patch to support
it. It was originally planned for cairo 1.8 but was dropped for some
reason.

Peter



From arjan at infradead.org  Tue Oct 21 16:58:30 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 21 Oct 2008 09:58:30 -0700
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021161357.GA27320@shell.devel.redhat.com>
References: <48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
	<20081021145035.GB26273@free.fr>
	<20081021161357.GA27320@shell.devel.redhat.com>
Message-ID: <20081021095830.793c3c27@infradead.org>

On Tue, 21 Oct 2008 12:13:57 -0400
Alan Cox <alan at redhat.com> wrote:

> On Tue, Oct 21, 2008 at 04:50:35PM +0200, Patrice Dumas wrote:
> > On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
> > > 
> > > Actually that I question somewhat. Both POSIX and the LSB require
> > > local mail delivery services. A suprising number of applications
> > > that don't currently specify sendmail dependancies appear to use
> > > it. Have a grep...
> > 
> > Every package with application that calls /usr/sbin/sendmail should 
> > require that file. Isn't it the case? If you know about cases like
> > that, tell, I'll file bugs.
> 
> Try grep. That is how I did a scan.
> 

fwiw ssmtp and all those guys do provide a /usr/bin/sendmail, but one
that doesn't queue just does local delivery.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From lesmikesell at gmail.com  Tue Oct 21 17:09:41 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 12:09:41 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021154401.GA3312@nostromo.devel.redhat.com>
References: <20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>	<20081021072950.5dec77aa@infradead.org>	<48FDEEEA.4070508@gmail.com>	<20081021151613.GA2968@nostromo.devel.redhat.com>	<48FDF732.6090201@gmail.com>
	<20081021154401.GA3312@nostromo.devel.redhat.com>
Message-ID: <48FE0CD5.6050306@gmail.com>

Bill Nottingham wrote:

>>>> Which is why mail is a sensible delivery mechanism.  It already knows 
>>>>  how to deliver elsewhere if you want.
>>> With built-in mechanisms to allow for easy spoofing of critical events
>>> to the user from anyone on the internet, no less!
>> I'm surprised you are able to do that with fedora's default mail  
>> configuration that only accepts from localhost...  Perhaps you should  
>> let us in on the secret.
> 
> ????
> 
> We're talking about arbitrary mail delivery. It could be forwarded
> to any e-mail account, anywhere. (After all, that's what you're asking
> for with redirection of root e-mail.)  Ergo, anyone with knowledge of
> 1) your e-mail address 2) your machine could send you a spoof/phishing/etc.

But that's true whether or not you use it yourself.  And it is 
relatively difficult to spoof the originating host IP since it is 
recorded by the receiving server.

>>> Should the information be sent via e-mail to an adminstrator, and
>>> stored for later viewing in general? Yes. Does that mean e-mail is
>>> the best mechanism for presenting it? No.
>> If you have a bad email mechanism, fix that problem.
> 
> I think attempting to have all cron/alert/whatever mail gpg-signed
> with a host-specific key would be waaaaaaaaaaaay overkill.

The value of unix-like systems is that they provide the user with a 
standard toolbox to be used in an appropriate way for any situation. 
Good working defaults are just a plus - the tools, and the fact that 
they follow standards, are the critical part.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From mjg at redhat.com  Tue Oct 21 17:13:56 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 21 Oct 2008 18:13:56 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021143343.GA16367@shell.devel.redhat.com>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
Message-ID: <20081021171356.GA1755@srcf.ucam.org>

On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
> On Tue, Oct 21, 2008 at 03:07:13PM +0100, Matthew Garrett wrote:
> > queued and presented at login - if the user is running on their system 
> > but doesn't have the desktop infrastructure running, then by definition 
> > they're already outside the standard desktop usecase.
> 
> You mean like boot, shutdown, being logged out, ...

Times when mail delivery isn't a terribly effective solution either.

> And if we are going to worry about desktop experiences then perhaps making
> evolution not totally suck, fixing the way the desktop totally disintegrates
> when you run out of disk space, a working gdm again and a few other items
> would be far better use of time than macdinking with log delivery.

Also, we should stop doing any kernel development until ipw4965 actually 
works. I'm pretty sure we don't need another slab allocator.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From jkeating at redhat.com  Tue Oct 21 17:14:24 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 21 Oct 2008 10:14:24 -0700
Subject: Rawhide compose fail?
In-Reply-To: <1224602498.9249.0.camel@scrappy.miketc.net>
References: <1224602498.9249.0.camel@scrappy.miketc.net>
Message-ID: <1224609265.30113.16.camel@luminos.localdomain>

On Tue, 2008-10-21 at 10:21 -0500, Mike Chambers wrote:
> 
> Did a rawhide build fail today/this morning, therefore no images or
> anything else for now?

That's right, however I fixed the glitch and there are now images on the
master mirror, that will sync out to mirrors as they check in.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/6d4e9243/attachment.sig>

From seg at haxxed.com  Tue Oct 21 17:15:08 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 21 Oct 2008 12:15:08 -0500
Subject: Make subpixel smoothing default?
In-Reply-To: <20081021143830.GB10875@jadzia.bu.edu>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<2a28d2ab0810210716u7c6af595q51e757f60fc052b1@mail.gmail.com>
	<20081021143830.GB10875@jadzia.bu.edu>
Message-ID: <1224609308.598.42.camel@localhost.localdomain>

On Tue, 2008-10-21 at 10:38 -0400, Matthew Miller wrote:
> It depends a lot on your monitor. If you've got relatively large pixels, the
> colored fringes can be very visible and distracting. If you've got a
> high-PPI monitor, it can look quite good -- but then, of course, you need
> it less.
> 
> I also find that it looks much worse for light text on black background
> (i.e. old-school terminal windows) than for dark text on light (the typical
> modern default terminals and most modern web sites).

I find that subpixel and hinting seem to interact sub-optimally. Setting
the hinting on "full" seems to work best, (This seems to be default
now?) but some fonts still look really bad. What seems to happen is
freetype is not keeping stroke widths a minimum of 3 subpixels wide,
which makes for nasty color fringing on thin vertical strokes. (Should
they always be a *multiple* of 3 subpixels wide? Some experimentation is
needed here...)

Have the autohinting hackers looked in to this at all?

> But here's my concern with making it the default: if you get the subpixel
> layout wrong, it looks very very bad. What percentage of monitors are RGB
> instead of BGR?

I have an old laptop with a BGR LCD, but I'm probably the only one...

We could probably do with a friendly subpixel tuner...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/f361e728/attachment.sig>

From mattdm at mattdm.org  Tue Oct 21 17:16:30 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 21 Oct 2008 13:16:30 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021154401.GA3312@nostromo.devel.redhat.com>
References: <48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com>
	<20081021072950.5dec77aa@infradead.org>
	<48FDEEEA.4070508@gmail.com>
	<20081021151613.GA2968@nostromo.devel.redhat.com>
	<48FDF732.6090201@gmail.com>
	<20081021154401.GA3312@nostromo.devel.redhat.com>
Message-ID: <20081021171630.GA29527@jadzia.bu.edu>

On Tue, Oct 21, 2008 at 11:44:01AM -0400, Bill Nottingham wrote:
> I think attempting to have all cron/alert/whatever mail gpg-signed
> with a host-specific key would be waaaaaaaaaaaay overkill.

Although relatively easily-accomplished overkill. :)

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mschwendt at gmail.com  Tue Oct 21 17:19:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 19:19:33 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <1223674536.3564.1262.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
Message-ID: <20081021191933.9db80422.mschwendt@gmail.com>

On Fri, 10 Oct 2008 23:35:36 +0200, Ralf Corsepius wrote:

> >  CentOS's
> > goals are better oriented to the needs of someone that wants to deploy a
> > system and run it for years.  Fedora is good for people who want to get
> > the latest technologies from upstream as soon as they're stable enough
> > to integrate into a running system.
> Right. But why can't Fedora do better? I feel Fedora could do better.
> 
> > > This situation seems to be reflected in the Fedora project itself.
> > > Guess, how many Fedora infrastructure servers are run under the latest
> > > "stable" Fedora release?
> > 
> > As few as possible.
> IMO, a fundamental management/infrastructure mistake - If these people
> were using Fedora, they would be facing the issues Fedora users are
> facing everyday and likely would being to understand why people complain
> about Fedora.

How many of the packagers run Rawhide?
How often do they run it compared with other Fedora/CentOS/RHEL releases?

How many don't try Rawhide until one of the test releases?

How many skip even the test releases and only try FN+1 after its
final release?

How many use multi-boot machines where they switch between FN-1, FN
and FN+1 as is necessary for testing and also for testing updates?

How many publish untested mass-builds of updates (as aided by
%{dist}-madness)?

> >   The reason is not about stability.  It is about
> > updates.  Once Fedora stops getting updates we'd have to upgrade to the
> > next Fedora release with all of the churn that causes for vastly
> > unrelated pieces of the OS. 
> Gotcha! If not even the Fedora project can handle the issues, why do you
> expect users to be able to solve them? I think technically the issues
> can be overcome. It's a matter of will.



From mjg at redhat.com  Tue Oct 21 17:20:45 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 21 Oct 2008 18:20:45 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FDF0ED.9020705@gmail.com>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<48FDF0ED.9020705@gmail.com>
Message-ID: <20081021172045.GB1755@srcf.ucam.org>

On Tue, Oct 21, 2008 at 10:10:37AM -0500, Les Mikesell wrote:
> Matthew Garrett wrote:
> >Local delivery of mail is a poor solution, since it provides no 
> >indication of priority difference between "You've got spam" and "Your 
> >hard drive is failing". 
> 
> That's a solvable problem within the context of email, whereas starting 
> from scratch and re-inventing delivery to arbitrary user-selectable 
> endpoints is somewhat insane.

I'm sure the anti-spam companies would be delighted to hear it. Yes, 
it's a solvable problem - but you're conflating two things, important 
system updates and personal email. I think trying to present these two 
quite different things in the same way is a bad idea.

> >If there's nobody to present it to, it can be 
> >queued and presented at login - if the user is running on their system 
> >but doesn't have the desktop infrastructure running, then by definition 
> >they're already outside the standard desktop usecase.
> 
> Does that mean their system should die with no attempt at notification? 
>  Or that desktop administration should be confusingly different than 
> standard systems?

I'm reasonably sure that I didn't suggest that, no.

> >I'm not arguing about the utility of an MTA for various situations. I'm 
> >arguing that for one specific and very common situation, using an MTA to 
> >deliver system alerts is a poor way of handling it. We should fix that. 
> 
> No, you should fix it so mail delivery is useful.

And then have to modify every single MUA so it automatically flags 
high-priority system information. I'm not convinced getting that into 
gmail is going to happen.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From dbhole at redhat.com  Tue Oct 21 17:30:38 2008
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 21 Oct 2008 13:30:38 -0400
Subject: Impossible to run Sun Java plugin on 64-bit Fedora 9/10?
In-Reply-To: <48FE065D.4020703@cora.nwra.com>
References: <48FE065D.4020703@cora.nwra.com>
Message-ID: <20081021173038.GI5909@redhat.com>

* Orion Poplawski <orion at cora.nwra.com> [2008-10-21 12:42]:
> Looks like -
>
> * no firefox.i386 for x86_64 Fedora
> * nspluginwrapper does not handle Sun java plugin
>
> So, no Sun Java plugin for x86_64 Fedora 9?  Is that correct?
>

Right, no 32-bit firefox would mean no Sun Java plugin. There will 
still be an OpenJDK plugin which will be available for x86_64 
however.

Deepak

> -- 
> 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
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From mschwendt at gmail.com  Tue Oct 21 17:33:28 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 19:33:28 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1223677428.3564.1292.camel@beck.corsepiu.local>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
Message-ID: <20081021193328.75db5ee0.mschwendt@gmail.com>

On Sat, 11 Oct 2008 00:23:48 +0200, Ralf Corsepius wrote:

> > You're going to have to expound on that. I do not see Centos in any
> > way as in competition with Fedora.
>
> EPEL drains away resources from Fedora.

I wish it were like that. EPEL is just another build target. It's a
dumping-ground for Fedora pkg spec files. It's getting filled with
trial-and-error builds. Just observe how many build deps are missing, the
build jobs fail, and the packager strips a spec till it builds. With no
evidence that the packagers spend much time on EPEL that is missing
elsewhere -- it's not as if they do back-porting or similar work where
Fedora Legacy failed due to lack of man-power/volunteers. Version upgrades
are done in EPEL in the same careless way as in Fedora, except that this
road will lead to a dead end somewhere, because EPEL and RHEL are
separately controlled and developed. [We've had similar cases with Fedora
Extras before, where upgrades in Core became necessary.]



From orion at cora.nwra.com  Tue Oct 21 17:36:42 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 21 Oct 2008 11:36:42 -0600
Subject: Impossible to run Sun Java plugin on 64-bit Fedora 9/10?
In-Reply-To: <20081021173038.GI5909@redhat.com>
References: <48FE065D.4020703@cora.nwra.com> <20081021173038.GI5909@redhat.com>
Message-ID: <48FE132A.6030506@cora.nwra.com>

Deepak Bhole wrote:
> * Orion Poplawski <orion at cora.nwra.com> [2008-10-21 12:42]:
>> Looks like -
>>
>> * no firefox.i386 for x86_64 Fedora
>> * nspluginwrapper does not handle Sun java plugin
>>
>> So, no Sun Java plugin for x86_64 Fedora 9?  Is that correct?
>>
> 
> Right, no 32-bit firefox would mean no Sun Java plugin. There will 
> still be an OpenJDK plugin which will be available for x86_64 
> however.

Got it.  Unfortunately, I'm trying to work around 
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=200 which is a 
show stopper for us.


-- 
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 at gmail.com  Tue Oct 21 17:37:04 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 19:37:04 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
Message-ID: <20081021193704.e48f2d21.mschwendt@gmail.com>

On Fri, 10 Oct 2008 17:08:53 -0600, Stephen John Smoogen wrote:

> Ok. Ralf.. if you hate Fedora and all its projects so much, why do you
> fricking stay around. Every fricking thread its "Fedora has too much
> bueracracy. Fedora has a broken build system. EPEL steals resources..
> " What are you doing?

> Then DO SOMETHING. Get your indians together and make your camp
> somewhere and show us chiefs how it is supposed to be done.

A "put up or shut up" attitude has only been harmful in several occasions
before. You cannot win volunteers with remarks like that.



From walters at verbum.org  Tue Oct 21 17:43:53 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 21 Oct 2008 13:43:53 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021143343.GA16367@shell.devel.redhat.com>
References: <20081020021340.GA7740@jadzia.bu.edu> <48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
Message-ID: <faa16b610810211043p7f3335f7g55c1ffbcc1b03bb8@mail.gmail.com>

On Tue, Oct 21, 2008 at 10:33 AM, Alan Cox <alan at redhat.com> wrote:
>
> And if we are going to worry about desktop experiences then perhaps making
> evolution not totally suck, fixing the way the desktop totally disintegrates
> when you run out of disk space, a working gdm again and a few other items
> would be far better use of time than macdinking with log delivery.

I agree there are some dire things broken in the desktop.  The disk
space one is particularly evil - we should have at least a
notification nowadays (http://cgwalters.livejournal.com/2008/02/09/).

However, startup speed is something that impacts nearly everyone and
is an immediately visible part of the interaction with the computer.
It makes sense to prioritize fixing it.



From pemboa at gmail.com  Tue Oct 21 17:45:50 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 21 Oct 2008 12:45:50 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081021193704.e48f2d21.mschwendt@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br> <48EF59BB.7000205@odu.neva.ru>
	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
Message-ID: <16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>

On Tue, Oct 21, 2008 at 12:37 PM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Fri, 10 Oct 2008 17:08:53 -0600, Stephen John Smoogen wrote:
>
>> Ok. Ralf.. if you hate Fedora and all its projects so much, why do you
>> fricking stay around. Every fricking thread its "Fedora has too much
>> bueracracy. Fedora has a broken build system. EPEL steals resources..
>> " What are you doing?
>
>> Then DO SOMETHING. Get your indians together and make your camp
>> somewhere and show us chiefs how it is supposed to be done.
>
> A "put up or shut up" attitude has only been harmful in several occasions
> before. You cannot win volunteers with remarks like that.


Well, seems like the community is being solely gobbled up by
individuals who are both negative and non constructive.

The Fedora community faces criticism and lack of assistance from
without and within. Is it time to just terminate things? Or is there a
way forward?

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From dbhole at redhat.com  Tue Oct 21 18:02:13 2008
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 21 Oct 2008 14:02:13 -0400
Subject: Impossible to run Sun Java plugin on 64-bit Fedora 9/10?
In-Reply-To: <48FE132A.6030506@cora.nwra.com>
References: <48FE065D.4020703@cora.nwra.com> <20081021173038.GI5909@redhat.com>
	<48FE132A.6030506@cora.nwra.com>
Message-ID: <20081021180212.GJ5909@redhat.com>

* Orion Poplawski <orion at cora.nwra.com> [2008-10-21 13:36]:
> Deepak Bhole wrote:
>> * Orion Poplawski <orion at cora.nwra.com> [2008-10-21 12:42]:
>>> Looks like -
>>>
>>> * no firefox.i386 for x86_64 Fedora
>>> * nspluginwrapper does not handle Sun java plugin
>>>
>>> So, no Sun Java plugin for x86_64 Fedora 9?  Is that correct?
>>>
>>
>> Right, no 32-bit firefox would mean no Sun Java plugin. There will still 
>> be an OpenJDK plugin which will be available for x86_64 however.
>
> Got it.  Unfortunately, I'm trying to work around 
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=200 which is a show 
> stopper for us.
>

Talk about timing! I am working on fixing that very bug right now
:) It is a parsing issue on plugin side, and I am fairly certain it is 
resolvable by F10. I'll let you know once I have fixed it.

Cheers,
Deepak

>
> -- 
> 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 choeger at cs.tu-berlin.de  Tue Oct 21 18:01:57 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Tue, 21 Oct 2008 20:01:57 +0200
Subject: Why does yum always need a global lock?
Message-ID: <1224612117.4047.3.camel@choeger6>

Hi,

what does yum make requiring a global lock for _every_ operation as
root? I can search/info/download as normal user, while updating the
system but not as root. Why that?
Why do we need to lock yum for more than rpm transactions (shouldn't rpm
do that at all) and cache write operations?

regards

christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/1dc2a3f6/attachment.sig>

From ml at deadbabylon.de  Tue Oct 21 18:05:25 2008
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 21 Oct 2008 20:05:25 +0200
Subject: KDE-SIG weekly report (43/2008)
Message-ID: <200810212005.30334.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/2008

Time: 2008-10-21 16:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-21

Meeting log: http://fedoraproject.org/w/uploads/3/32/KDE-SIG-2008-10-21.txt

----------------------------------------------------------------------------------

= Participants =

- JaroslavReznik
- KevinKofler
- RexDieter
- SebastianVahl
- ThanNgo

----------------------------------------------------------------------------------

= Agenda =

*  usermode-gtk and system-config-tools in KDE (#466768) [1]
* Preparing the final development freeze (2008-10-28)  [2]
* Solar artwork 
* Panel autohide [3]


= Summary =

usermode-gtk and system-config-tools in KDE (#466768): 
- - - - -
* Most of the system-config-tools are missing a dependency on usermode-gtk. 
* But this one is needed to make the package work as a non-root user. 
* We'll have to file bugs against each system-config-tool for the missing 
dependency. 
* As a temporary workaround usermode-gtk will be manually included in the KDE 
live images. 

Preparing the final development freeze (2008-10-28): 
- - - - -
* KDE should be in a good shape for the final release of Fedora 10. 
* We'll consider some backports for kdepim which were published by upstream 
after KDE 4.1.2. 

Panel autohide: 
- - - - -
* An update of kdebase-workspace with backported autohide functionality for 
plasma's panel is queued for updates-testing (but not pushed yet). 
* This update also fixes all but one known problems with this functionality 
(for the missing one we're awaiting feedback from the reporter) 

Solar artwork: 
- - - - -
* The latest version of solar-kde-theme is available here: 
* We'll need a review as soon as possible. [4]
* The KSplash theme has to be prepared to work with a generic logo.

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-28

----------------------------------------------------------------------------------

= Links =

[1] https://bugzilla.redhat.com/show_bug.cgi?id=466768
[2] https://fedoraproject.org/wiki/Releases/10/Schedule
[3] https://admin.fedoraproject.org/updates/kdebase-workspace-4.1.2-6.fc9
[4] http://jreznik.fedorapeople.org/kde/f10/kdm-theme/pkg/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/ee571fb4/attachment.sig>

From poelstra at redhat.com  Tue Oct 21 18:06:36 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 21 Oct 2008 11:06:36 -0700
Subject: Features & Final Development Freeze
Message-ID: <48FE1A2C.90708@redhat.com>

This message went directly to the feature owners below, but it didn't 
get to fedora-devel-announce.

https://fedoraproject.org/wiki/Features/BetterStartup now at 100%
https://fedoraproject.org/wiki/Features/Sugar now at 100%

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hello Feature People  :)

If all goes as planned, the final development freeze will arrive a week
from Tuesday on October 28, 2008.

Final Development Freeze, defined here:
http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy means
that all features and their associated feature pages must be at 100%
completion by this date.  The following features  pages do not currently
meet this criteria and should by updated by October 28, 2008:

https://fedoraproject.org/wiki/Features/BetterStartup
https://fedoraproject.org/wiki/Features/BetterWebcamSupport
https://fedoraproject.org/wiki/Features/EchoIconTheme
https://fedoraproject.org/wiki/Features/EFI
https://fedoraproject.org/wiki/Features/KernelModesetting


Yes, we know "this is Fedora" and "stuff is never 100% done" and all the
usual arguments about "what does percentage completion really mean,
etc., etc." :-)  However, for the average user and members of the other
Fedora teams it is important and very helpful to make one last update to
your feature page to make it reflect everything that was completed for
Fedora 10.  The things that weren't completed should be removed or
clearly labeled as slated for a future release.

Feature pages not updated and at 100% will be raised to FESCo on October
29, 2008.

Thanks,
John




_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From bpepple at fedoraproject.org  Tue Oct 21 18:32:13 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 21 Oct 2008 14:32:13 -0400
Subject: Plan for tomorrows (20081022) FESCO meeting
Message-ID: <1224613933.7107.8.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, Wednesday at 17:00
UTC in #fedora-meeting on irc.freenode.org:

/topic FESCo-Meeting -- sponsor nominations -- Andreas Thienemann (ixs)

/topic FESCo-Meeting -- adjusting post-beta snapshots -
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01994.html - all

/topic FESCo-Meeting -- Features - Sbin Sanity -
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00337.html - Ville Skytt?

/topic FESCo-Meeting -- Features - all

/topic FESCo meeting -- Free discussion around Fedora

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.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/8859e589/attachment.sig>

From skvidal at fedoraproject.org  Tue Oct 21 18:37:33 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 21 Oct 2008 14:37:33 -0400
Subject: Why does yum always need a global lock?
In-Reply-To: <1224612117.4047.3.camel@choeger6>
References: <1224612117.4047.3.camel@choeger6>
Message-ID: <1224614253.3304.24.camel@rosebud>

On Tue, 2008-10-21 at 20:01 +0200, Christoph H?ger wrote:
> Hi,
> 
> what does yum make requiring a global lock for _every_ operation as
> root? I can search/info/download as normal user, while updating the
> system but not as root. Why that?

B/c none of the /var/cache/yum dir is writable as a user. But as root it
is all writable. Changing the metadata while another yum operation is
going on will result in unpredictable results.

> Why do we need to lock yum for more than rpm transactions (shouldn't rpm
> do that at all) and cache write operations?

b/c we write out other data.

-sv





From lesmikesell at gmail.com  Tue Oct 21 19:21:33 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 14:21:33 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
Message-ID: <48FE2BBD.2030802@gmail.com>

Arthur Pemberton wrote:
> 
>> A "put up or shut up" attitude has only been harmful in several occasions
>> before. You cannot win volunteers with remarks like that.
> 
> 
> Well, seems like the community is being solely gobbled up by
> individuals who are both negative and non constructive.

That shouldn't be surprising for a project that doesn't value backwards 
compatibility, stability, or interoperability with any third party 
components.

> The Fedora community faces criticism and lack of assistance from
> without and within. Is it time to just terminate things? Or is there a
> way forward?

Either maintain compatible interfaces or don't be so sensitive to 
criticism from your existing users whose work and learning you just 
threw away.

-- 
    Les Mikesell
     lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Oct 21 19:35:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 14:35:04 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <faa16b610810211043p7f3335f7g55c1ffbcc1b03bb8@mail.gmail.com>
References: <20081020021340.GA7740@jadzia.bu.edu>
	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>
	<20081021140713.GA29430@srcf.ucam.org>	<20081021143343.GA16367@shell.devel.redhat.com>
	<faa16b610810211043p7f3335f7g55c1ffbcc1b03bb8@mail.gmail.com>
Message-ID: <48FE2EE8.9090209@gmail.com>

Colin Walters wrote:
> On Tue, Oct 21, 2008 at 10:33 AM, Alan Cox <alan at redhat.com> wrote:
>> And if we are going to worry about desktop experiences then perhaps making
>> evolution not totally suck, fixing the way the desktop totally disintegrates
>> when you run out of disk space, a working gdm again and a few other items
>> would be far better use of time than macdinking with log delivery.
> 
> I agree there are some dire things broken in the desktop.  The disk
> space one is particularly evil - we should have at least a
> notification nowadays (http://cgwalters.livejournal.com/2008/02/09/).
> 
> However, startup speed is something that impacts nearly everyone and
> is an immediately visible part of the interaction with the computer.
> It makes sense to prioritize fixing it.

You can certainly defer the sendmail daemon startup so you don't have to 
wait for it - and it doesn't need to run at all if you aren't accepting 
inbound messages and nothing is in the queue.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Tue Oct 21 19:33:12 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 14:33:12 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021172045.GB1755@srcf.ucam.org>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCCCAC.6050304@gmail.com>	<20081020182812.GD21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>
	<20081021140713.GA29430@srcf.ucam.org>	<48FDF0ED.9020705@gmail.com>
	<20081021172045.GB1755@srcf.ucam.org>
Message-ID: <48FE2E78.1050702@gmail.com>

Matthew Garrett wrote:
>
>>> Local delivery of mail is a poor solution, since it provides no 
>>> indication of priority difference between "You've got spam" and "Your 
>>> hard drive is failing". 
>> That's a solvable problem within the context of email, whereas starting 
>> from scratch and re-inventing delivery to arbitrary user-selectable 
>> endpoints is somewhat insane.
> 
> I'm sure the anti-spam companies would be delighted to hear it. Yes, 
> it's a solvable problem - but you're conflating two things, important 
> system updates and personal email. I think trying to present these two 
> quite different things in the same way is a bad idea.

I think it is a bad idea for you to decide which of those things is more 
important to me or anyone else, or where I want them delivered.  Just 
supply the tools, please, with some convenient default setting so the 
system messages are available.

>>> If there's nobody to present it to, it can be 
>>> queued and presented at login - if the user is running on their system 
>>> but doesn't have the desktop infrastructure running, then by definition 
>>> they're already outside the standard desktop usecase.
>> Does that mean their system should die with no attempt at notification? 
>>  Or that desktop administration should be confusingly different than 
>> standard systems?
> 
> I'm reasonably sure that I didn't suggest that, no.

If you don't use email, you will have to invent something new that will 
almost certainly be less capable and less useful.

>>> I'm not arguing about the utility of an MTA for various situations. I'm 
>>> arguing that for one specific and very common situation, using an MTA to 
>>> deliver system alerts is a poor way of handling it. We should fix that. 
>> No, you should fix it so mail delivery is useful.
> 
> And then have to modify every single MUA so it automatically flags 
> high-priority system information. I'm not convinced getting that into 
> gmail is going to happen.

No, you don't have to modify every MUA.  You just have to let people use 
the one they have had years to tune to their liking already.  And supply 
some reasonable default for the one or two users you might pick up that 
don't already have a preference or an assortment of accounts already 
created for different priority messages.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From walters at verbum.org  Tue Oct 21 19:41:50 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 21 Oct 2008 15:41:50 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FE2E78.1050702@gmail.com>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<48FDF0ED.9020705@gmail.com> <20081021172045.GB1755@srcf.ucam.org>
	<48FE2E78.1050702@gmail.com>
Message-ID: <faa16b610810211241w6e3d38edh4f36e70c4a21fe5f@mail.gmail.com>

On Tue, Oct 21, 2008 at 3:33 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Matthew Garrett wrote:
>>
>>>> Local delivery of mail is a poor solution, since it provides no
>>>> indication of priority difference between "You've got spam" and "Your hard
>>>> drive is failing".
>>>
>>> That's a solvable problem within the context of email, whereas starting
>>> from scratch and re-inventing delivery to arbitrary user-selectable
>>> endpoints is somewhat insane.
>>
>> I'm sure the anti-spam companies would be delighted to hear it. Yes, it's
>> a solvable problem - but you're conflating two things, important system
>> updates and personal email. I think trying to present these two quite
>> different things in the same way is a bad idea.
>
> I think it is a bad idea for you to decide

Let's be clear - this is a meritocracy, not a vote-by-email-repetition system.



From lesmikesell at gmail.com  Tue Oct 21 19:53:59 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 21 Oct 2008 14:53:59 -0500
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <faa16b610810211241w6e3d38edh4f36e70c4a21fe5f@mail.gmail.com>
References: <20081020180622.GC21020@nostromo.devel.redhat.com>	<48FCD15E.4090003@gmail.com>
	<20081020190549.GA14319@srcf.ucam.org>	<48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org>	<48FDDE9B.2090608@gmail.com>
	<20081021140713.GA29430@srcf.ucam.org>	<48FDF0ED.9020705@gmail.com>
	<20081021172045.GB1755@srcf.ucam.org>	<48FE2E78.1050702@gmail.com>
	<faa16b610810211241w6e3d38edh4f36e70c4a21fe5f@mail.gmail.com>
Message-ID: <48FE3357.3000709@gmail.com>

Colin Walters wrote:
> 
>>>>> Local delivery of mail is a poor solution, since it provides no
>>>>> indication of priority difference between "You've got spam" and "Your hard
>>>>> drive is failing".
>>>> That's a solvable problem within the context of email, whereas starting
>>>> from scratch and re-inventing delivery to arbitrary user-selectable
>>>> endpoints is somewhat insane.
>>> I'm sure the anti-spam companies would be delighted to hear it. Yes, it's
>>> a solvable problem - but you're conflating two things, important system
>>> updates and personal email. I think trying to present these two quite
>>> different things in the same way is a bad idea.
>> I think it is a bad idea for you to decide
> 
> Let's be clear - this is a meritocracy, not a vote-by-email-repetition system.

If you don't permit the 'merit' to be decided by potential users of the 
system you are designing a vote-by-feet system.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From martin.sourada at gmail.com  Tue Oct 21 20:40:20 2008
From: martin.sourada at gmail.com (Martin Sourada)
Date: Tue, 21 Oct 2008 22:40:20 +0200
Subject: Make subpixel smoothing default?
In-Reply-To: <af452d8dd4d5100476e7c6ebbb7c044f.squirrel@arekh.dyndns.org>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<20081021132329.GB28344@srcf.ucam.org>
	<7babc0950077e4e6fa4f1154d7e3ed34.squirrel@arekh.dyndns.org>
	<20081021145315.GA14556@jadzia.bu.edu>
	<af452d8dd4d5100476e7c6ebbb7c044f.squirrel@arekh.dyndns.org>
Message-ID: <1224621620.8905.8.camel@pc-notebook>

On Tue, 2008-10-21 at 17:17 +0200, Nicolas Mailhot wrote:
> That and people who use laptops have usually already compromised a lot
> on the screen part, so they accept fringing better.
For me the sub-pixel hinting is superior to just the grey-scale one
(98dpi). For one the fonts look much more crisp (grey-scale hinting
leaves them blurry), in bigger sizes there is an unwanted colour "halo"
around the letters though. But in order to look nice it requires to have
correct subixel order set. If you set it wrong, it looks awful. I don't
know if we can guess the right order for LCDs...

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/82338e6b/attachment.sig>

From dbhole at redhat.com  Tue Oct 21 21:13:08 2008
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 21 Oct 2008 17:13:08 -0400
Subject: Impossible to run Sun Java plugin on 64-bit Fedora 9/10?
In-Reply-To: <20081021180212.GJ5909@redhat.com>
References: <48FE065D.4020703@cora.nwra.com> <20081021173038.GI5909@redhat.com>
	<48FE132A.6030506@cora.nwra.com> <20081021180212.GJ5909@redhat.com>
Message-ID: <20081021211308.GK5909@redhat.com>

* Deepak Bhole <dbhole at redhat.com> [2008-10-21 14:02]:
> * Orion Poplawski <orion at cora.nwra.com> [2008-10-21 13:36]:
> > Deepak Bhole wrote:
> >> * Orion Poplawski <orion at cora.nwra.com> [2008-10-21 12:42]:
> >>> Looks like -
> >>>
> >>> * no firefox.i386 for x86_64 Fedora
> >>> * nspluginwrapper does not handle Sun java plugin
> >>>
> >>> So, no Sun Java plugin for x86_64 Fedora 9?  Is that correct?
> >>>
> >>
> >> Right, no 32-bit firefox would mean no Sun Java plugin. There will still 
> >> be an OpenJDK plugin which will be available for x86_64 however.
> >
> > Got it.  Unfortunately, I'm trying to work around 
> > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=200 which is a show 
> > stopper for us.
> >
> 
> Talk about timing! I am working on fixing that very bug right now
> :) It is a parsing issue on plugin side, and I am fairly certain it is 
> resolvable by F10. I'll let you know once I have fixed it.
> 

Fixed in the tip! I have commented on the bug above accordingly.

Let me know if you encounter any other sites that don't work with the
plugin, and I'd be happy to fix it.

Cheers,
Deepak

> Cheers,
> Deepak
> 
> >
> > -- 
> > 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
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From gmaxwell at gmail.com  Tue Oct 21 21:34:10 2008
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Tue, 21 Oct 2008 17:34:10 -0400
Subject: Make subpixel smoothing default?
In-Reply-To: <1224609308.598.42.camel@localhost.localdomain>
References: <2a28d2ab0810201644n492d5891g9965744158909602@mail.gmail.com>
	<20081021013511.GA7959@gmail.com>
	<2a28d2ab0810210716u7c6af595q51e757f60fc052b1@mail.gmail.com>
	<20081021143830.GB10875@jadzia.bu.edu>
	<1224609308.598.42.camel@localhost.localdomain>
Message-ID: <e692861c0810211434j1f2ea418k5b04ad012f839b2e@mail.gmail.com>

2008/10/21 Callum Lerwick <seg at haxxed.com>:
> On Tue, 2008-10-21 at 10:38 -0400, Matthew Miller wrote:
>> It depends a lot on your monitor. If you've got relatively large pixels, the
>> colored fringes can be very visible and distracting. If you've got a
>> high-PPI monitor, it can look quite good -- but then, of course, you need
>> it less.
>>
>> I also find that it looks much worse for light text on black background
>> (i.e. old-school terminal windows) than for dark text on light (the typical
>> modern default terminals and most modern web sites).
>
> I find that subpixel and hinting seem to interact sub-optimally. Setting
> the hinting on "full" seems to work best, (This seems to be default
> now?) but some fonts still look really bad. What seems to happen is
> freetype is not keeping stroke widths a minimum of 3 subpixels wide,
> which makes for nasty color fringing on thin vertical strokes. (Should
> they always be a *multiple* of 3 subpixels wide? Some experimentation is
> needed here...)

Hm. I would have expected functioning hinting to defeat subpixel
rendering by snapping edges to integer pixel boundaries.  Obviously
this would reduce the color bleed but nor more nor less than simply
turning off subpixel rendering.



From mschwendt at gmail.com  Tue Oct 21 21:39:12 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 23:39:12 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081011213341.GA8235@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
Message-ID: <20081021233912.137e86ed.mschwendt@gmail.com>

On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:

> My proposal was clear: start the project when somebody has volunteered
> for each of the packages that are in @code and @base (and maybe other
> comps groups, I don't remember exactly). And keep a page with the
> packages maintained such as not to give wrong expectations.

Be careful with a project based on promises. Somebody might volunteer to
maintain a package, but leave the project already prior to the first
important security-fix due to lack of time or because of more important
obligations. Learn from Fedora Legacy's fate. Not enough commitment from
the target group. Too much bureaucracy for the few people who prepared
updates [= a slow review process in bugzilla even for small patches copied
from RHEL, lack of trust, all contributors had to wait for reviews,
bottle-necks in the build'n'release process]. With every week a security
update had to wait somewhere in a review ticket, some more people
(including contributors) left the target group.



From smooge at gmail.com  Tue Oct 21 21:54:20 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 21 Oct 2008 15:54:20 -0600
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081021233912.137e86ed.mschwendt@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<20081021233912.137e86ed.mschwendt@gmail.com>
Message-ID: <80d7e4090810211454m2e62fc50oada001a36d1d7e5c@mail.gmail.com>

On Tue, Oct 21, 2008 at 3:39 PM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:
>
>> My proposal was clear: start the project when somebody has volunteered
>> for each of the packages that are in @code and @base (and maybe other
>> comps groups, I don't remember exactly). And keep a page with the
>> packages maintained such as not to give wrong expectations.
>
> Be careful with a project based on promises. Somebody might volunteer to
> maintain a package, but leave the project already prior to the first
> important security-fix due to lack of time or because of more important
> obligations. Learn from Fedora Legacy's fate. Not enough commitment from
> the target group. Too much bureaucracy for the few people who prepared
> updates [= a slow review process in bugzilla even for small patches copied
> from RHEL, lack of trust, all contributors had to wait for reviews,
> bottle-necks in the build'n'release process]. With every week a security
> update had to wait somewhere in a review ticket, some more people
> (including contributors) left the target group.
>

Now that we are constructive talking.. how can we lower the
bureaucracy and build trust in an environment where its all based on
who knows who and relationships take a long time to build up (I mean
this for any project from the Linux kernel, etc.) And you are correct,
my attitude towards Ralph earlier stunk.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From mschwendt at gmail.com  Tue Oct 21 21:58:28 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 23:58:28 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <48F1C83F.5040200@fedoraproject.org>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
Message-ID: <20081021235828.5e739cae.mschwendt@gmail.com>

On Sun, 12 Oct 2008 15:19:51 +0530, Rahul Sundaram wrote:

> It seems that there isn't enough people interested in doing the work.

Ack. For potential contributors apparently it is easier to build their own
private updates from tarballs (or RHEL/Fedora N+1 src.rpms). Even current
Fedora users often (see various web forums) try to fix issues themselves
with builds from source code instead of submitting problem reports in
bugzilla and working together with the Fedora packagers. You can see
rumours that claim how rebuilds from source work while rpms from Fedora
would not work, and getting those people to help in finding and preparing
officially fixed rpms is hard.

One big problem is accountability. With roles like "package maintainer"
or "reviewer" (who approves something) come responsibilities. Few people
want to make an extra effort as would be necessary for pkgs to be
published as official Fedora Updates.



From pertusus at free.fr  Tue Oct 21 21:59:06 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 21 Oct 2008 23:59:06 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081021233912.137e86ed.mschwendt@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<20081021233912.137e86ed.mschwendt@gmail.com>
Message-ID: <20081021215906.GD2873@free.fr>

On Tue, Oct 21, 2008 at 11:39:12PM +0200, Michael Schwendt wrote:
> On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:
> 
> > My proposal was clear: start the project when somebody has volunteered
> > for each of the packages that are in @code and @base (and maybe other
> > comps groups, I don't remember exactly). And keep a page with the
> > packages maintained such as not to give wrong expectations.
> 
> Be careful with a project based on promises. Somebody might volunteer to
> maintain a package, but leave the project already prior to the first
> important security-fix due to lack of time or because of more important
> obligations. Learn from Fedora Legacy's fate. Not enough commitment from
> the target group. Too much bureaucracy for the few people who prepared
> updates [= a slow review process in bugzilla even for small patches copied
> from RHEL, lack of trust, all contributors had to wait for reviews,
> bottle-necks in the build'n'release process]. With every week a security
> update had to wait somewhere in a review ticket, some more people
> (including contributors) left the target group.

My proposal has always been to use the exact same procedures than in
fedora, so nothing like in fedora legacy.

--
Pat



From mschwendt at gmail.com  Tue Oct 21 21:50:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 21 Oct 2008 23:50:33 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081011221705.GC8235@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
Message-ID: <20081021235033.108288ba.mschwendt@gmail.com>

On Sun, 12 Oct 2008 00:17:05 +0200, Patrice Dumas wrote:

> I was interested in
> legacy at some point, but everything was so different than in fedora
> extras that it deterred me.

Fedora Legacy was close to dead already much earlier, failing to deliver
updates for Red Hat Linux 7.3 and 9. Originally, it had started with parts
of the fedora.us infrastructure (the Fedora Extras predecessor), using the
same bugzilla, the same review'n'release process in bugzilla, a human-driven
build-system, but not inheriting the existing web of trust. Even simple
updates took four or more weeks to be looked at in bugzilla.



From mschwendt at gmail.com  Tue Oct 21 22:08:02 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 22 Oct 2008 00:08:02 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <loom.20081013T001327-394@post.gmane.org>
References: <1223804148.3564.1355.camel@beck.corsepiu.local>
	<48F1C83F.5040200@fedoraproject.org>
	<20081012100248.GB3936@free.fr> <gcsrr8$9mn$1@ger.gmane.org>
	<20081012131811.GA2700@free.fr> <gct38m$scd$1@ger.gmane.org>
	<20081012200238.GA2688@free.fr>
	<loom.20081012T205859-315@post.gmane.org>
	<20081012212120.GD2688@free.fr>
	<48F273D1.6070604@shmuelhome.mine.nu>
	<20081012222613.GF2688@free.fr>
	<48F280FA.8010507@shmuelhome.mine.nu>
	<loom.20081012T230422-741@post.gmane.org>
	<48F288A3.8000601@shmuelhome.mine.nu>
	<loom.20081013T001327-394@post.gmane.org>
Message-ID: <20081022000802.a5fe07a9.mschwendt@gmail.com>

On Mon, 13 Oct 2008 00:22:42 +0000 (UTC), Kevin Kofler wrote:

> it was overreaching bureaucracy which killed Fedora 
> Legacy (e.g. excessive QA requirements, paranoia such as not trusting 
> Bugzilla's authentication mechanisms, instead requiring GPG signing of Bugzilla 
> comments, which raised the barrier to entry), not lack of interested 
> developers.

Well, if there had been many "interested developers", they could have
simply appeared as boycotters of GPG clear-text signing in bugzilla
while at the same time offering update candidate rpms and reviews.
Hasn't happened IMO.



From pertusus at free.fr  Tue Oct 21 20:36:49 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 21 Oct 2008 22:36:49 +0200
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021161357.GA27320@shell.devel.redhat.com>
References: <20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
	<20081021145035.GB26273@free.fr>
	<20081021161357.GA27320@shell.devel.redhat.com>
Message-ID: <20081021203649.GC2873@free.fr>

On Tue, Oct 21, 2008 at 12:13:57PM -0400, Alan Cox wrote:
> 
> Try grep. That is how I did a scan.

A grep in what? In a strings on all binaries?

--
Pat



From alan at redhat.com  Tue Oct 21 22:33:51 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Oct 2008 18:33:51 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021171356.GA1755@srcf.ucam.org>
References: <48FCCCAC.6050304@gmail.com>
	<20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
	<20081021171356.GA1755@srcf.ucam.org>
Message-ID: <20081021223351.GA4287@shell.devel.redhat.com>

On Tue, Oct 21, 2008 at 06:13:56PM +0100, Matthew Garrett wrote:
> > And if we are going to worry about desktop experiences then perhaps making
> > evolution not totally suck, fixing the way the desktop totally disintegrates
> > when you run out of disk space, a working gdm again and a few other items
> > would be far better use of time than macdinking with log delivery.
> 
> Also, we should stop doing any kernel development until ipw4965 actually 
> works. I'm pretty sure we don't need another slab allocator.

And how many years as gnome out of disk been broken, or evolution crap ?

No we don't need another slab allocator, but last time I checked nobody in
Red Hat was writing one either. They are all far too busy working on stuff
that needs doing.

Alan



From alan at redhat.com  Tue Oct 21 22:36:54 2008
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Oct 2008 18:36:54 -0400
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021203649.GC2873@free.fr>
References: <48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
	<20081021145035.GB26273@free.fr>
	<20081021161357.GA27320@shell.devel.redhat.com>
	<20081021203649.GC2873@free.fr>
Message-ID: <20081021223654.GB4287@shell.devel.redhat.com>

On Tue, Oct 21, 2008 at 10:36:49PM +0200, Patrice Dumas wrote:
> On Tue, Oct 21, 2008 at 12:13:57PM -0400, Alan Cox wrote:
> > 
> > Try grep. That is how I did a scan.
> 
> A grep in what? In a strings on all binaries?

source packages



From mschwendt at gmail.com  Tue Oct 21 22:48:04 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 22 Oct 2008 00:48:04 +0200
Subject: reviving Fedora Legacy
In-Reply-To: <1223878609.3564.1480.camel@beck.corsepiu.local>
References: <200810111658.49564.opensource@till.name>
	<4f629b520810111455i2f457a0dh3234aec731534cb4@mail.gmail.com>
	<20081011220135.GK2305@br-online.de>
	<20081011221705.GC8235@free.fr>
	<20081011222850.GM10204@angus.ind.WPI.EDU>
	<1223804148.3564.1355.camel@beck.corsepiu.local>
	<20081012105804.GA6353@orient.maison.lan>
	<48F1E0B7.4000004@shmuelhome.mine.nu>
	<20081012123341.GD3936@free.fr>
	<20081012154755.GP10204@angus.ind.WPI.EDU>
	<604aa7910810121802vf2174afu1222a21c6b37fab5@mail.gmail.com>
	<48F2A2C8.2020306@rincon.com>
	<1223878609.3564.1480.camel@beck.corsepiu.local>
Message-ID: <20081022004804.f715d308.mschwendt@gmail.com>

On Mon, 13 Oct 2008 08:16:49 +0200, Ralf Corsepius wrote:

> On Sun, 2008-10-12 at 18:22 -0700, Bob Arendt wrote:
>
> > I really don't see how a Fedora Legacy can be maintained.
>
> Ask yourselves: How can EPEL be maintained?

It's a relatively new project. It still has to prove that it will be
maintained properly after two or more years. Let's wait and see how the
EPEL packagers will react to the first build troubles, where they will get
failures because current Fedora and upstream are versions ahead of RHEL
and they cannot simply push a version upgrade into EPEL.

EPEL itself doesn't even have the man-power to fix the repoclosure
report. The person who broke it almost half a year ago could simply
revert the broken changes, but even that doesn't happen.



From mjg at redhat.com  Tue Oct 21 23:48:14 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 22 Oct 2008 00:48:14 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <20081021223351.GA4287@shell.devel.redhat.com>
References: <20081020182812.GD21020@nostromo.devel.redhat.com>
	<48FCD15E.4090003@gmail.com> <20081020190549.GA14319@srcf.ucam.org>
	<48FCD953.3080707@gmail.com> <20081021132003.GA28344@srcf.ucam.org>
	<48FDDE9B.2090608@gmail.com> <20081021140713.GA29430@srcf.ucam.org>
	<20081021143343.GA16367@shell.devel.redhat.com>
	<20081021171356.GA1755@srcf.ucam.org>
	<20081021223351.GA4287@shell.devel.redhat.com>
Message-ID: <20081021234814.GA7842@srcf.ucam.org>

On Tue, Oct 21, 2008 at 06:33:51PM -0400, Alan Cox wrote:
> On Tue, Oct 21, 2008 at 06:13:56PM +0100, Matthew Garrett wrote:
> > Also, we should stop doing any kernel development until ipw4965 actually 
> > works. I'm pretty sure we don't need another slab allocator.
> 
> And how many years as gnome out of disk been broken, or evolution crap ?

To be fair to evolution, it's getting on for being in the region of half 
as big as the kernel. Making it non-crap isn't a five minute job, and 
asking people to spend three years failing to get very far through it 
isn't likely to win many friends. We have insane quantities of crap code 
in the distribution and stopping feature development in order to fix all 
of it wouldn't actually result in customers beating our door dwn.

> No we don't need another slab allocator, but last time I checked nobody in
> Red Hat was writing one either. They are all far too busy working on stuff
> that needs doing.

We needed Ubuntu on Sparc64? A functional desktop is something that 
needs doing. We can quibble over what's actually required for a 
functional desktop (and I'll agree that evolution isn't a shining 
example of functionality), but I'm fairly convinced that getting system 
alerts to a relevant user in a timely manner is one component of it. 
Doing so via mail worked fine when most Unix systems were maintained by 
people who understood cron, but that's not current reality.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From mjg at redhat.com  Tue Oct 21 23:51:05 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 22 Oct 2008 00:51:05 +0100
Subject: None of the Above (was Re: Sendmail still default?)
In-Reply-To: <48FE3357.3000709@gmail.com>
References: <20081020190549.GA14319@srcf.ucam.org> <48FCD953.3080707@gmail.com>
	<20081021132003.GA28344@srcf.ucam.org> <48FDDE9B.2090608@gmail.com>
	<20081021140713.GA29430@srcf.ucam.org> <48FDF0ED.9020705@gmail.com>
	<20081021172045.GB1755@srcf.ucam.org> <48FE2E78.1050702@gmail.com>
	<faa16b610810211241w6e3d38edh4f36e70c4a21fe5f@mail.gmail.com>
	<48FE3357.3000709@gmail.com>
Message-ID: <20081021235105.GB7842@srcf.ucam.org>

On Tue, Oct 21, 2008 at 02:53:59PM -0500, Les Mikesell wrote:
> Colin Walters wrote:
> >Let's be clear - this is a meritocracy, not a vote-by-email-repetition 
> >system.
> 
> If you don't permit the 'merit' to be decided by potential users of the 
> system you are designing a vote-by-feet system.

Nobody's talking about removing MTAs from the repository. Potential 
users are always free to decide how their system works.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From bpepple at fedoraproject.org  Tue Oct 21 23:54:32 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 21 Oct 2008 19:54:32 -0400
Subject: Package Review SIG Meeting (2008-10-23)
Message-ID: <1224633272.14826.8.camel@kennedy>

Package Review SIG Meeting
irc.freenode.net #fedora-meeting
Thursday @ 18:00 UTC/2 PM EDT

This will be our first meeting, and we'll be working on creating some
action items (making package review process easier, creating reports of
package review stats, etc) to help improve the backlog of package
reviews.  If you've in interest in seeing package reviews getting done
quicker, please join us!

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/c40d14a1/attachment.sig>

From mschwendt at gmail.com  Wed Oct 22 00:00:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 22 Oct 2008 02:00:33 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <80d7e4090810211454m2e62fc50oada001a36d1d7e5c@mail.gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<20081021233912.137e86ed.mschwendt@gmail.com>
	<80d7e4090810211454m2e62fc50oada001a36d1d7e5c@mail.gmail.com>
Message-ID: <20081022020033.f4ea5423.mschwendt@gmail.com>

On Tue, 21 Oct 2008 15:54:20 -0600, Stephen John Smoogen wrote:

> Now that we are constructive talking.. how can we lower the
> bureaucracy and build trust in an environment where its all based on
> who knows who and relationships take a long time to build up (I mean
> this for any project from the Linux kernel, etc.)

Well, that's the interesting part of starting such a project. ;) How many
of the "interested developers" will be new people who would register in
FAS for the first time? How much information about themselves are they
willing to disclose? Inside the Fedora project you need to ask yourself
anyway how much you trust fellow contributors? Some are with the project
for several years, but you need to rely on the sponsorship process as you
don't know everyone (and you don't verify regularly that it's still the
same person who uses a fedora account or that the intentions are still
good).

How many volunteer specialists are available to support some of the huge
core packages? Copying and rediff'ing patches only is one thing, porting
patches between versions is something completely different. In an older
discussion I've suggested a dry-run for such a project. It could start
with F8 EOL, albeit a boring period and a lot to do (evaluating
vulnerability notifications alone is a lot of work). How patient would
contributors stay before they would give up or switch to another dist?

If reviewing is needed, the core team of a LTS project could sign off
patches submitted by completely new contributors, who haven't been active
in Fedora before. It ought not create significant delays in getting
something published, as contributors will likely become unsatisfactory
soon with productivity issues or find other reasons to leave. There are
existing procedures, such as the sponsor- or mentor-model for new
people. Existing infrastructure would help, too: pkg cvs commit diffs
posted to a mailing-list, for example, which is not a separate list on a
server in some other domain. This adds the possibility that some
completely unexpected pair of eyes skims over the diffs, rather than just
a small number of contributors. More convenient than having to do rpmdiff
manually. Source tarballs can be checksum-compared with newer Fedora
branches in lookaside cache.



From mschwendt at gmail.com  Wed Oct 22 00:08:53 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 22 Oct 2008 02:08:53 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081021215906.GD2873@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<20081021233912.137e86ed.mschwendt@gmail.com>
	<20081021215906.GD2873@free.fr>
Message-ID: <20081022020853.53efbf50.mschwendt@gmail.com>

On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:

> My proposal has always been to use the exact same procedures than in
> fedora, so nothing like in fedora legacy.

In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
sudden. You would either work at Red Hat, or you would have to use the
current kernel-maintainers as your proxy for quite a long time before they
would approve a "commits" request in pkgdb.



From pertusus at free.fr  Wed Oct 22 00:52:17 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 22 Oct 2008 02:52:17 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081022020853.53efbf50.mschwendt@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<20081021233912.137e86ed.mschwendt@gmail.com>
	<20081021215906.GD2873@free.fr>
	<20081022020853.53efbf50.mschwendt@gmail.com>
Message-ID: <20081022005217.GE2873@free.fr>

On Wed, Oct 22, 2008 at 02:08:53AM +0200, Michael Schwendt wrote:
> On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:
> 
> > My proposal has always been to use the exact same procedures than in
> > fedora, so nothing like in fedora legacy.
> 
> In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
> sudden. You would either work at Red Hat, or you would have to use the
> current kernel-maintainers as your proxy for quite a long time before they
> would approve a "commits" request in pkgdb.

The idea here is to open ACLs for release that are no longer supported.

--
Pat



From tibbs at math.uh.edu  Wed Oct 22 01:42:35 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 21 Oct 2008 20:42:35 -0500
Subject: Summary of the 2008-10-21 Packaging Committee meeting
Message-ID: <ufar669flro.fsf@epithumia.math.uh.edu>

Meeting minutes and full logs of the 2008-10-21 FPC meeting are
online:

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

Issues pending FESCo ratification:

* Eclipse plugin guideline modification
** Reported on-list; archive is at
   https://www.redhat.com/archives/fedora-packaging/2008-October/msg00121.html
** These tweak the guidelines to fix a few typos, clean the templates
   up a bit and accommodate changes in Eclipse 3.4.

* Desktop File guideline modification
** https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor
** This removes language which many interpreted as requiring most
   desktop files to be installed with --vendor=fedora.

Other discussions:

* Cpack guidelines
** https://fedoraproject.org/wiki/PackagingDrafts/CmakeCpack
** The committee was unclear as to how this applied to packaging
   guidelines at all, as it seems to contain tips for upstream
   developers instead of instructions for Fedora packagers.

* Tweaks to the specfile template for fonts
** https://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction_(fontconfig)
** This alters the template for font packages to deal with issues
   surrounding the /etc/fonts/conf.avail directory.
** FPC agreed with the proposal but had some suggestions; these will
   be addressed and the issue will be raised later.

* New guideline relating to generically named packages and files.
** Tough to actually write a guideline involving the use of common
   sense as applied to things like this.
** Jason will draft a proposal for consideration soon.

 - J<



From cdahlin at redhat.com  Wed Oct 22 01:52:25 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 21 Oct 2008 21:52:25 -0400
Subject: Regarding install options
In-Reply-To: <1223937363.3056.10.camel@luminos.localdomain>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>	<1223911751.3327.15.camel@luminos.localdomain>	<20081013161316.GL3139@free.fr>	<1223916009.3327.28.camel@luminos.localdomain>	<20081013164536.GN3139@free.fr>	<1223921280.3327.34.camel@luminos.localdomain>	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>	<20081013203244.GG2738@free.fr>	<1223930747.3327.41.camel@luminos.localdomain>	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
Message-ID: <48FE8759.6010302@redhat.com>

Jesse Keating wrote:
> On Tue, 2008-10-14 at 00:10 +0200, Patrice Dumas wrote:
>   
>> On Mon, Oct 13, 2008 at 01:45:47PM -0700, Jesse Keating wrote:
>>     
>>> On Mon, 2008-10-13 at 22:32 +0200, Patrice Dumas wrote:
>>>       
>>>> I had a look recently, and I think that comps are in a good shape for
>>>> minimal installs. (there is an issue with anaconda deps being draggued 
>>>> in but it is an orthogonal issue). However chosing @core or @core +
>>>> @base is an unsolved (and unsolvable, in my opinion) issue.
>>>>         
>>> How so?  You uncheck everything to get @core, you uncheck everything but
>>> the Base group to get @core + @base
>>>       
>> It isn't what I meant, I meant it is unsolvable to tell whether minimal
>> is @core or @code + @base.
>>     
>
> Right, because "minimal" is defined in the eye of the installer, IE the
> person doing the installing.
>
>   
I've spent 3 days just trying to /find/ all the crap Anaconda put on a 
computer that I didn't check off. Now, when I install Fedora on a 
server, I reboot and start over if I see anything that looks even 
remotely desktop-related. This is a broken use case. Solutions are:

1) Add the "dependencies have been added" screen that every other 
package install tool in the distro has but Anaconda insists on going 
without.
2) Have checkboxes in the package screen be tri-state. (checked if you 
want it, unchecked if you don't want it, red x if yum is not allowed to 
install it for any reason). This one's not pretty, but it'd work.
3) Provide a default install. Believe me, I won't agree with what you 
put in it at all. I will, however, be happier than I am now.
4) Document the procedure a few emails up on how to install just @core 
or @core + @base . I didn't even know the system would run right if you 
unchecked everything.

Spending a little energy and not pleasing everyone is a lot better than 
spending no energy and epic failing.

--CJD



From cdahlin at redhat.com  Wed Oct 22 01:54:06 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 21 Oct 2008 21:54:06 -0400
Subject: Regarding install options
In-Reply-To: <1223928764.3327.40.camel@luminos.localdomain>
References: <1223677508.3564.1295.camel@beck.corsepiu.local>	<1223677870.4410.185.camel@luminos.localdomain>	<1223791786.3564.1322.camel@beck.corsepiu.local>	<1223855755.3327.12.camel@luminos.localdomain>	<1223882953.3564.1509.camel@beck.corsepiu.local>	<1223911751.3327.15.camel@luminos.localdomain>	<20081013161316.GL3139@free.fr>	<1223916009.3327.28.camel@luminos.localdomain>	<20081013164536.GN3139@free.fr>	<1223921280.3327.34.camel@luminos.localdomain>	<20081013194800.GB2738@free.fr>
	<1223928764.3327.40.camel@luminos.localdomain>
Message-ID: <48FE87BE.2090705@redhat.com>

Jesse Keating wrote:
> On Mon, 2008-10-13 at 21:48 +0200, Patrice Dumas wrote:
>   
>> Indeed that will happen. But does doing nothing really prevent it from
>> happening? 
>>     
>
> Yes, since removing the install classes, the bugs against these classes
> being wrong in one way shape or form have all but disappeared.
>
>   
Which means you've successfully removed the user's ability to 
legitimately complain. Doesn't mean they aren't even more annoyed now 
then they are then.

--CJD



From kevin.kofler at chello.at  Wed Oct 22 02:06:29 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 22 Oct 2008 02:06:29 +0000 (UTC)
Subject: CMake, CPack (was: Re: Summary of the 2008-10-21 Packaging Committee
	meeting)
References: <ufar669flro.fsf@epithumia.math.uh.edu>
Message-ID: <loom.20081022T015254-609@post.gmane.org>

Jason L Tibbitts III <tibbs <at> math.uh.edu> writes:
> * Cpack guidelines
> ** https://fedoraproject.org/wiki/PackagingDrafts/CmakeCpack
> ** The committee was unclear as to how this applied to packaging
>    guidelines at all, as it seems to contain tips for upstream
>    developers instead of instructions for Fedora packagers.

Indeed, CPack is unsuitable for building official Fedora packages for several 
reasons (it does not generate source RPMs [1], it treats the specfile as an 
implementation detail and hides it from the developer and it's extremely 
unlikely the specfiles it generates are compliant with our guidelines, I've 
seen horrible things in autogenerated specfiles).

Fedora specfiles should be either handwritten entirely or generated with a 
specfile generator (e.g. cpan2spec) and then hand-edited to follow the 
guidelines (and of course to actually build, e.g. by filling in the missing 
fields if the generator you used is just a template generator like the one in 
the rpmdevtools).

It is not hard to write a specfile for the average CMake-using package: please 
see this template:
https://fedoraproject.org/w/uploads/4/40/SIGs_KDE_KDE4FAQ_kde4_foo.spec
for KDE 4 applications; for non-KDE applications using CMake, use the %build 
and %install sections (and %check where applicable) from:
https://fedoraproject.org/wiki/Packaging/cmake
instead.

[1] http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29

        Kevin Kofler



From dbn.lists at gmail.com  Wed Oct 22 02:20:40 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 21 Oct 2008 19:20:40 -0700
Subject: Status of libtool 2.2.X?
In-Reply-To: <1224252827.11508.1.camel@atropine.boston.devel.redhat.com>
References: <48ECE6CC.6030001@cora.nwra.com>
	<20081008171428.GA7911@nostromo.devel.redhat.com>
	<20081008171607.GE3447@yoda.jdub.homelinux.org>
	<48ECEFB9.1080600@redhat.com> <48F5C75A.9040603@redhat.com>
	<1224252827.11508.1.camel@atropine.boston.devel.redhat.com>
Message-ID: <91705d080810211920h1cf39f69gf147d17d3d18d875@mail.gmail.com>

2008/10/17 Adam Jackson <ajax at redhat.com>:
> On Wed, 2008-10-15 at 12:35 +0200, Karsten Hopp wrote:
>
>> My last rebuild showed only ~100 failures, I'm not sure what I've done differently
>> this time. I suspect that the removal of libtool-ltdl and all related packages from
>> my full-install might have caused this and I'm in the process of rebuilding those with libtool-2.
>> I've uploaded the current logs to http://karsten.fedorapeople.org/
>> After a quick glance at them I think that there are quite a few easy fixes, but I still
>> have to find out what causes p.e. the cracklib failure.
>
> I don't know what's going on with the libXp and xorg-x11-drv-* failures,
> we're not doing anything tricky.  Someone have a clue?

The problem appears to be `autoreconf' vs. `autoreconf -i'.

The process goes like this with bare autoreconf:

1) aclocal runs and updates aclocal.m4 with the new AC_PROG_LIBTOOL
definition it finds

2) libtoolize is skipped because -i/--install not given, leaving you
with an old ltmain.sh

3) fail

You can see the process if you add the -v switch to autoreconf.

Here's some background on why this happens:

http://lists.gnu.org/archive/html/libtool/2008-07/msg00024.html

--
Dan



From cweyl at alumni.drew.edu  Wed Oct 22 03:52:12 2008
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 21 Oct 2008 20:52:12 -0700
Subject: license change: perl-Class-InsideOut...
Message-ID: <7dd7ab490810212052w49a1dbfbl623df37531e61731@mail.gmail.com>

...has changed from "the same terms as Perl itself" to "Apache 2.0".

Carry on.

                                   -Chris

-- 
Chris Weyl
Ex astris, scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081021/0469e7f2/attachment.htm>

From choeger at cs.tu-berlin.de  Wed Oct 22 07:02:21 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Wed, 22 Oct 2008 09:02:21 +0200
Subject: Why does yum always need a global lock?
In-Reply-To: <1224614253.3304.24.camel@rosebud>
References: <1224612117.4047.3.camel@choeger6>
	<1224614253.3304.24.camel@rosebud>
Message-ID: <1224658941.7651.4.camel@s4.math.tu-berlin.de>

Would you be interested in making it more fine-grained at all? As its
python I basically _could_ do some work.

Am Dienstag, den 21.10.2008, 14:37 -0400 schrieb seth vidal:
> On Tue, 2008-10-21 at 20:01 +0200, Christoph H?ger wrote:
> > Hi,
> > 
> > what does yum make requiring a global lock for _every_ operation as
> > root? I can search/info/download as normal user, while updating the
> > system but not as root. Why that?
> 
> B/c none of the /var/cache/yum dir is writable as a user. But as root it
> is all writable. Changing the metadata while another yum operation is
> going on will result in unpredictable results.
> 
> > Why do we need to lock yum for more than rpm transactions (shouldn't rpm
> > do that at all) and cache write operations?
> 
> b/c we write out other data.
> 
> -sv

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/4aa0db61/attachment.sig>

From pertusus at free.fr  Wed Oct 22 08:05:36 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 22 Oct 2008 10:05:36 +0200
Subject: Summary of the 2008-10-21 Packaging Committee meeting
In-Reply-To: <ufar669flro.fsf@epithumia.math.uh.edu>
References: <ufar669flro.fsf@epithumia.math.uh.edu>
Message-ID: <20081022080536.GC2675@free.fr>

On Tue, Oct 21, 2008 at 08:42:35PM -0500, Jason L Tibbitts III wrote:
> 
> * New guideline relating to generically named packages and files.
> ** Tough to actually write a guideline involving the use of common
>    sense as applied to things like this.
> ** Jason will draft a proposal for consideration soon.

Tired to tell everytime the same, I have put an argumentation here:
https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace

I think that it would be better to tackle this issue cross distribution,
that is when we see a real conflict or a generic name used, talk to the
distribution list to agree on a name.

There is another issue to be considered, it is the case of existing
software already in fedora. For example ImageMagick puts in %_bindir:
animate compare composite conjure convert display identify import
montage stream, and there are also 2 letter command names, like gv.

A case which is also unclear is the case of sl. This package is a kind
of a joke, when you type sl, there is an ascii art steam locomotive 
that goes through the screen. It is meant to annoy you when you wanted 
to type 'ls' and you typed 'sl'. It uses a precious 2 letter command 
name, however it has to in order to do its job and it could be replaced 
if something serious wanted to use  it, so I think it may go in fedora,
but it isn't that obvious. Review is here:
https://bugzilla.redhat.com/show_bug.cgi?id=466997
I'd recommand not saying anything that precise and let common sense
apply, but this is an unclear case in my opinion.

A last word, I think that it is sad that we have to do a guideline here,
since upstream and packagers should understand the issue, and we already
have too many guidelines, but I also don't know how to solve it
differently, I am tired of looking at every submission and whine if it
smells like a generic name is used.

--
Pat



From mschwendt at gmail.com  Wed Oct 22 09:16:21 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 22 Oct 2008 11:16:21 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081022005217.GE2873@free.fr>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<20081021233912.137e86ed.mschwendt@gmail.com>
	<20081021215906.GD2873@free.fr>
	<20081022020853.53efbf50.mschwendt@gmail.com>
	<20081022005217.GE2873@free.fr>
Message-ID: <20081022111621.ba43b372.mschwendt@gmail.com>

On Wed, 22 Oct 2008 02:52:17 +0200, Patrice Dumas wrote:

> On Wed, Oct 22, 2008 at 02:08:53AM +0200, Michael Schwendt wrote:
> > On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:
> > 
> > > My proposal has always been to use the exact same procedures than in
> > > fedora, so nothing like in fedora legacy.
> > 
> > In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
> > sudden. You would either work at Red Hat, or you would have to use the
> > current kernel-maintainers as your proxy for quite a long time before they
> > would approve a "commits" request in pkgdb.
> 
> The idea here is to open ACLs for release that are no longer supported.

I do understand that, but we talk past eachother. Let's assume you start
with the F-8 branch opened up to all packagers. Then you still need a
procedure where previously unknown people join the project and be
sponsored or something like that to get direct access to the pkgs and
buildsys and so on.



From pertusus at free.fr  Wed Oct 22 09:29:40 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 22 Oct 2008 11:29:40 +0200
Subject: [Fwd: Wikipidia - Goodbye  Red Hat and Fedora]
In-Reply-To: <20081022111621.ba43b372.mschwendt@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<0d44s5x8co.ln2@ppp1053.in.ipex.cz> <20081010144426.GC3236@free.fr>
	<200810111658.49564.opensource@till.name>
	<20081011213341.GA8235@free.fr>
	<20081021233912.137e86ed.mschwendt@gmail.com>
	<20081021215906.GD2873@free.fr>
	<20081022020853.53efbf50.mschwendt@gmail.com>
	<20081022005217.GE2873@free.fr>
	<20081022111621.ba43b372.mschwendt@gmail.com>
Message-ID: <20081022092939.GD2675@free.fr>

On Wed, Oct 22, 2008 at 11:16:21AM +0200, Michael Schwendt wrote:
> 
> I do understand that, but we talk past eachother. Let's assume you start
> with the F-8 branch opened up to all packagers. Then you still need a
> procedure where previously unknown people join the project and be
> sponsored or something like that to get direct access to the pkgs and
> buildsys and so on.

I see, you mean that, given the different target, people wanting to
participate to a fedora EOL would be different from people participating 
in fedora (say, like, people wanting to participate in EPEL but not 
in fedora). I didn't thought about that, but it seems to me that going
through bugzilla should be enough? The EOL SIG should take care of the
patches.

--
Pat



From ankit at redhat.com  Wed Oct 22 09:40:20 2008
From: ankit at redhat.com (Ankitkumar Rameshchandra Patel)
Date: Wed, 22 Oct 2008 15:10:20 +0530
Subject: Virt* , s-c-display ,
	desktop-effects - Translation submission issues!
Message-ID: <48FEF504.8030606@redhat.com>

Hi,

Yesterday, 21st October 2008, was the deadline for completing the fedora 
10 software translations. 
http://poelstra.fedorapeople.org/schedules/f-10/f-10-trans-tasks.html

Packages like virt*, s-c-display, desktop-effects got some issues with 
respect to the submissions of the translations.

So, we have filed bugs, where we (FLP - Fedora Localization Project 
team) attached the translations of different languages respectively. 
Now, it seems the translations are not yet landed into the actual 
upstream repositories!

Could someone, who has got the access, please take those translations 
from the bugs and commit them in the VCS?

Here are the list of bugs, we filed against respective packages:

[desktop-effect]
https://bugzilla.redhat.com/show_bug.cgi?id=438033

[system-config-display]
https://bugzilla.redhat.com/show_bug.cgi?id=438122

[virt-ctrl]
https://bugzilla.redhat.com/show_bug.cgi?id=467817

[virt-manager]
https://bugzilla.redhat.com/show_bug.cgi?id=467808

[virt-df]
https://bugzilla.redhat.com/show_bug.cgi?id=467809

[virt-inst]
https://bugzilla.redhat.com/show_bug.cgi?id=467810

[virt-mem]
https://bugzilla.redhat.com/show_bug.cgi?id=467811

[virt-p2v]
https://bugzilla.redhat.com/show_bug.cgi?id=467818

[virt-top]
https://bugzilla.redhat.com/show_bug.cgi?id=467816


Thanks in advance!

-- 
Regards,
Ankit Patel
http://www.indianoss.org/



From wolfy at nobugconsulting.ro  Wed Oct 22 10:46:02 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Wed, 22 Oct 2008 13:46:02 +0300
Subject: kde needs mysql-server ??
Message-ID: <48FF046A.3000501@nobugconsulting.ro>

Hey

    Do we really need mysql-server on a _desktop_ running kde ?

[root at pc37 tmp]# rpm -q --whatrequires mysql-server
akonadi-1.0.0-3.fc10.i386
[root at pc37 tmp]# rpm -q --whatrequires akonadi-1.0.0-3.fc10.i386
no package requires akonadi-1.0.0-3.fc10.i386
[root at pc37 tmp]# rpm -e akonadi
error: Failed dependencies:
        libakonadiprotocolinternals.so.1 is needed by (installed) 
kdepimlibs-4.1.2-2.fc10.i386
[root at pc37 tmp]# rpm -q --whatrequires libakonadiprotocolinternals.so.1
akonadi-1.0.0-3.fc10.i386
kdepimlibs-4.1.2-2.fc10.i386
[root at pc37 tmp]# rpm -q --whatrequires akonadi
no package requires akonadi
[root at pc37 tmp]# rpm -q --whatrequires kdepimlibs
kdebase-runtime-4.1.2-5.fc10.i386
kdebase-libs-4.1.2-5.fc10.i386

Guess what requires kdebase-[libs|runtime] :)

I know that hard disk space is less expensive than it used to be, but....



From skvidal at fedoraproject.org  Wed Oct 22 12:17:31 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 22 Oct 2008 08:17:31 -0400
Subject: Why does yum always need a global lock?
In-Reply-To: <1224658941.7651.4.camel@s4.math.tu-berlin.de>
References: <1224612117.4047.3.camel@choeger6>
	<1224614253.3304.24.camel@rosebud>
	<1224658941.7651.4.camel@s4.math.tu-berlin.de>
Message-ID: <1224677851.3304.57.camel@rosebud>

On Wed, 2008-10-22 at 09:02 +0200, Christoph H?ger wrote:
> Would you be interested in making it more fine-grained at all? As its
> python I basically _could_ do some work.

Yes, we are interested in that. 

-sv




From pmatilai at laiskiainen.org  Wed Oct 22 12:46:12 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 22 Oct 2008 15:46:12 +0300 (EEST)
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <20081018102734.GA415@amd.home.annexia.org>
References: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
	<20081017170351.GA2681@free.fr>
	<ufay70nksd6.fsf@epithumia.math.uh.edu>
	<200810172200.35964.ville.skytta@iki.fi>
	<20081018102734.GA415@amd.home.annexia.org>
Message-ID: <alpine.DEB.1.10.0810221542030.6314@gotcha.dreamhost.com>

On Sat, 18 Oct 2008, Richard W.M. Jones wrote:

> On Fri, Oct 17, 2008 at 10:00:35PM +0300, Ville Skytt? wrote:
>> I'm sure that there are a lot of things that are not at all Fedora specific
>> that rpmlint doesn't currently check but very well could.  Please do send
>> patches either to Bugzilla or upstream rpmlint Trac, or just file RFE's
>> (these usually preferably in upstream Trac) in case you have good ideas but
>> no code yet.
>
> If I want rpmbuild to run rpmlint automatically on the packages that
> rpmbuild makes, that would be a RFE/patch against rpm, right?

Yup, there's no place you could hook up a script to check the resulting 
packages currently. Seems like a very reasonable RFE to me, feel free to 
file in rpm.org Trac.

 	- Panu -



From rdieter at math.unl.edu  Wed Oct 22 12:53:35 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 07:53:35 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com>
Message-ID: <gdn7of$v73$1@ger.gmane.org>

Les Mikesell wrote:

> Arthur Pemberton wrote:
>> 
>>> A "put up or shut up" attitude has only been harmful in several
>>> occasions before. You cannot win volunteers with remarks like that.
>> 
>> 
>> Well, seems like the community is being solely gobbled up by
>> individuals who are both negative and non constructive.
> 
> That shouldn't be surprising for a project that doesn't value backwards
> compatibility, stability, or interoperability with any third party
> components.

Blame too those upstream projects who introduce these changes, fedora is
just a collection of all those items.  

Is there similar outrage against them as well?  Where is it?

-- Rex



From rdieter at math.unl.edu  Wed Oct 22 12:57:01 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 07:57:01 -0500
Subject: kde needs mysql-server ??
References: <48FF046A.3000501@nobugconsulting.ro>
Message-ID: <gdn7ut$v73$2@ger.gmane.org>

Manuel Wolfshant wrote:

>     Do we really need mysql-server on a _desktop_ running kde ?
> 
> [root at pc37 tmp]# rpm -q --whatrequires mysql-server
> akonadi-1.0.0-3.fc10.i386

In short (atm), yes:
http://techbase.kde.org/Projects/PIM/Akonadi

-- Rex



From rjones at redhat.com  Wed Oct 22 13:07:11 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 22 Oct 2008 14:07:11 +0100
Subject: Virt* , s-c-display , desktop-effects - Translation submission
	issues!
In-Reply-To: <48FEF504.8030606@redhat.com>
References: <48FEF504.8030606@redhat.com>
Message-ID: <20081022130711.GA10497@amd.home.annexia.org>

On Wed, Oct 22, 2008 at 03:10:20PM +0530, Ankitkumar Rameshchandra Patel wrote:
[...]

Unfortunately I was out at a conference yesterday, but ...

> [virt-df]
> https://bugzilla.redhat.com/show_bug.cgi?id=467809
>
> [virt-p2v]
> https://bugzilla.redhat.com/show_bug.cgi?id=467818
>
> [virt-top]
> https://bugzilla.redhat.com/show_bug.cgi?id=467816

I did some of the translations for these three yesterday morning, and
rebuilt in Fedora.  But then I had to leave and I notice having just
got back that there are about another 20 translations waiting :-(

I think we've missed the 21st deadline for F10, but I will try to do
these later on today anyway.

> [virt-ctrl]
> https://bugzilla.redhat.com/show_bug.cgi?id=467817

This isn't in Fedora, but I appreciate any translations :-)

> [virt-mem]
> https://bugzilla.redhat.com/show_bug.cgi?id=467811

I did some of the PO files for this as well, but there's another
unrelated problem which stops me from uploading a new version into
Fedora.  I'm rewriting it at the moment (although it's basically a
"translation" .. of the code so hopefully many messages will still be
applicable).

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



From lesmikesell at gmail.com  Wed Oct 22 13:16:12 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 22 Oct 2008 08:16:12 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gdn7of$v73$1@ger.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>	<48FE2BBD.2030802@gmail.com>
	<gdn7of$v73$1@ger.gmane.org>
Message-ID: <48FF279C.2000501@gmail.com>

Rex Dieter wrote:
> Les Mikesell wrote:
> 
>> Arthur Pemberton wrote:
>>>> A "put up or shut up" attitude has only been harmful in several
>>>> occasions before. You cannot win volunteers with remarks like that.
>>>
>>> Well, seems like the community is being solely gobbled up by
>>> individuals who are both negative and non constructive.
>> That shouldn't be surprising for a project that doesn't value backwards
>> compatibility, stability, or interoperability with any third party
>> components.
> 
> Blame too those upstream projects who introduce these changes, fedora is
> just a collection of all those items.  

So you'll ship any sort of breakage with no regard to the interfaces you 
promoted last month?

> Is there similar outrage against them as well?  Where is it?

There are reasons that people run distributions instead of compiling the 
head of every upstream source themselves.  Consider the contrast between 
RHEL's shielding users from incompatible upstream changes for many years 
at a time to what fedora ships.   I realize that it isn't easy or even 
always possible to add new features without breaking old ones or 
interfaces, but that's what people want.  And it is what they are used 
to from commercial OS's.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dwmw2 at infradead.org  Wed Oct 22 13:38:09 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 22 Oct 2008 14:38:09 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48FF279C.2000501@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>
Message-ID: <1224682689.4856.31.camel@macbook.infradead.org>

On Wed, 2008-10-22 at 08:16 -0500, Les Mikesell wrote:
> Rex Dieter wrote:
> > Les Mikesell wrote:
> > 
> >> Arthur Pemberton wrote:
> >>>> A "put up or shut up" attitude has only been harmful in several
> >>>> occasions before. You cannot win volunteers with remarks like that.
> >>>
> >>> Well, seems like the community is being solely gobbled up by
> >>> individuals who are both negative and non constructive.
> >> That shouldn't be surprising for a project that doesn't value backwards
> >> compatibility, stability, or interoperability with any third party
> >> components.
> > 
> > Blame too those upstream projects who introduce these changes, fedora is
> > just a collection of all those items.  
> 
> So you'll ship any sort of breakage with no regard to the interfaces you 
> promoted last month?

Of course not. We take care to ensure that when interfaces change, every
Fedora package is updated to cope.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From rdieter at math.unl.edu  Wed Oct 22 13:39:19 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 08:39:19 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>	<48FE2BBD.2030802@gmail.com>
	<gdn7of$v73$1@ger.gmane.org> <48FF279C.2000501@gmail.com>
Message-ID: <gdnae7$9tt$1@ger.gmane.org>

Les Mikesell wrote:

> Rex Dieter wrote:

>> Blame too those upstream projects who introduce these changes, fedora is
>> just a collection of all those items.
> 
> So you'll ship any sort of breakage with no regard to the interfaces you
> promoted last month?

Thanks for putting words into my and fedora's mouth.  OK, I'll bite a bit...
when it's the choice of shipping an older unsupported version of software
vs. latest/supported, sometimes, yeah.  It's a tough choice to have to
make.

Unanswered:
> Is there similar outrage against upstreams as well?  Where is it?

-- Rex



From lesmikesell at gmail.com  Wed Oct 22 13:57:52 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 22 Oct 2008 08:57:52 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224682689.4856.31.camel@macbook.infradead.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>	<48FE2BBD.2030802@gmail.com>
	<gdn7of$v73$1@ger.gmane.org>	<48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
Message-ID: <48FF3160.7060207@gmail.com>

David Woodhouse wrote:
> 
>>>>>> A "put up or shut up" attitude has only been harmful in several
>>>>>> occasions before. You cannot win volunteers with remarks like that.
>>>>> Well, seems like the community is being solely gobbled up by
>>>>> individuals who are both negative and non constructive.
>>>> That shouldn't be surprising for a project that doesn't value backwards
>>>> compatibility, stability, or interoperability with any third party
>>>> components.
>>> Blame too those upstream projects who introduce these changes, fedora is
>>> just a collection of all those items.  
>> So you'll ship any sort of breakage with no regard to the interfaces you 
>> promoted last month?
> 
> Of course not. We take care to ensure that when interfaces change, every
> Fedora package is updated to cope.

Leaving everything all 3rd party work that tries to cooperate and a 
user's own previous work useless.  If a commercial system did that, 
they'd be out of business in a heartbeat.  A free distribution doesn't 
have the same reasons to care about cooperation, but from the user's 
perspective its all the same - if you can't count on interfaces being 
maintained, a platform simply isn't worth the effort.

Whatever happened to the concept of an LSB definition that was complete 
enough to permit apps to run unchanged across distributions?  We need 
something like that spanning at least 3 concurrent versions of fedora.

-- 
   Les Mikesell
    lesmikesell at gmail.com






From enrico.scholz at informatik.tu-chemnitz.de  Wed Oct 22 13:59:15 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Wed, 22 Oct 2008 15:59:15 +0200
Subject: kde needs mysql-server ??
In-Reply-To: <gdn7ut$v73$2@ger.gmane.org> (Rex Dieter's message of "Wed,
	22 Oct 2008 07:57:01 -0500")
References: <48FF046A.3000501@nobugconsulting.ro> <gdn7ut$v73$2@ger.gmane.org>
Message-ID: <87wsg0pw7g.fsf@fc5.bigo.ensc.de>

Rex Dieter <rdieter at math.unl.edu> writes:

>>     Do we really need mysql-server on a _desktop_ running kde ?
>> 
>> [root at pc37 tmp]# rpm -q --whatrequires mysql-server
>> akonadi-1.0.0-3.fc10.i386
>
> In short (atm), yes:
> http://techbase.kde.org/Projects/PIM/Akonadi

Do you mean:

http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F

?  --> akonadi doees not need a local mysql-server but can use a mysql
server running somewhere else.


Enrico



From rdieter at math.unl.edu  Wed Oct 22 14:01:45 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 09:01:45 -0500
Subject: kde needs mysql-server ??
References: <48FF046A.3000501@nobugconsulting.ro> <gdn7ut$v73$2@ger.gmane.org>
	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>
Message-ID: <gdnbo9$f91$1@ger.gmane.org>

Enrico Scholz wrote:

> Do you mean:
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F 
> ?  --> akonadi doees not need a local mysql-server but can use a mysql
> server running somewhere else.

Theoretically, yes.  The default config is to use a local one, however.

-- Rex



From pertusus at free.fr  Wed Oct 22 13:06:45 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 22 Oct 2008 15:06:45 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gdn7of$v73$1@ger.gmane.org>
References: <48EF59BB.7000205@odu.neva.ru> <48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
Message-ID: <20081022130645.GB3425@free.fr>

On Wed, Oct 22, 2008 at 07:53:35AM -0500, Rex Dieter wrote:
> 
> Blame too those upstream projects who introduce these changes, fedora is
> just a collection of all those items.  

It is not that simple. The distinction between fedora and upstream in
many cases is rather fuzzy. For example the hal/dbus/consoleKit/*Kit is
put in fedora when it is at early development stages, and many of the
developpers involved in these are also involved in fedora. And the
changes are pushed in fedora without taking seriously the backward
compatibility issues. For example wdm and xdm (and slim) are broken
since consolekit replaced pam_console, and although there is a rather
simple solution to integrate those dm it has never been planned and it
is still not fixed, though a fix exist for months. As long as it worked
in gdm it was fine for fedora. You can tell, hey, xdm, wdm and slim can
copy what gdm does, but when the solution implemented in gdm is specific
and not consistent with the previous designs, it is not so easy. Fedora
controls some upstream so can do anything in these, but doesn't control
all of them.

I am not saying that it is a wrong approach, being able to have a
platform for experimentation is indeed valuable, but you cannot charge
upstream for all regressions in fedora, especially when improper or
unplanned integration is linked with the regression, or the unstability
is linked with different features being proposed in packages controlled
by people in fedora and packages with an independent upstream.

In comparison, the transition to upstart was smooth, and a reason may be
that fedora wasn't the testing ground for that feature that originated
from ubuntu (though fedora people helped upstream at the time it was
integrated in fedora).

--
Pat



From dwmw2 at infradead.org  Wed Oct 22 14:42:08 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 22 Oct 2008 15:42:08 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48FF3160.7060207@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
Message-ID: <1224686528.4856.50.camel@macbook.infradead.org>

On Wed, 2008-10-22 at 08:57 -0500, Les Mikesell wrote:
> >> So you'll ship any sort of breakage with no regard to the
> >> interfaces you promoted last month?
> > 
> > Of course not. We take care to ensure that when interfaces change, 
> > every Fedora package is updated to cope.
> 
> Leaving everything all 3rd party work that tries to cooperate and a 
> user's own previous work useless. 

I've never found that to be the case, no. Any third party work that
"tried to co-operate" would be packaged as a Fedora package, and would
be included in my above statement.

And even my own personal hacks -- if it's a project of any significance
at all, then it's probably worth packaging. As much as I like to think
I'm unique (and I know others like to tell themselves that too), I'm
not. So if there's any piece of software which is _so_ useful to me that
I actually get off my lazy arse and _write_ it, then it's a fairly safe
bet it's going to be useful to someone else too.

>  If a commercial system did that, they'd be out of business in a
> heartbeat. 

The ability to cope with change is _precisely_ what distinguishes free
software from the commercial systems that it is slowly, but surely,
replacing.

The only people who really have a problem with it are those who fail to
work properly with whatever they call their 'upstream' project(s).

>  A free distribution doesn't have the same reasons to care about
> cooperation, but from the user's perspective its all the same - if you
> can't count on interfaces being maintained, a platform simply isn't
> worth the effort.

There is a difference between internal and external APIs. Basic stuff
like GTK and glibc _don't_ break in incompatible ways very often. Those
are the kinds of things that external software uses.

If you're involved in the horrid details of the latest PackageKit API
change, then you really have no business being an _external_ piece of
software anyway. Whatever it is, it should be packaged and included in
the Fedora repository, and then we'll be able to take care of it when we
break it.

To be honest, Les, I think you're just spouting crap again. It's an
unfortunate habit with you, isn't it?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From jkeating at redhat.com  Wed Oct 22 14:45:59 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 22 Oct 2008 07:45:59 -0700
Subject: Regarding install options
In-Reply-To: <48FE8759.6010302@redhat.com>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr> <1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
	<48FE8759.6010302@redhat.com>
Message-ID: <1224686759.3417.12.camel@luminos.localdomain>

On Tue, 2008-10-21 at 21:52 -0400, Casey Dahlin wrote:
> I've spent 3 days just trying to /find/ all the crap Anaconda put on a 
> computer that I didn't check off.


You spend 3 days reading the install log?  Do you have reading
comprehension problems?  I wouldn't think so given the emails and blog
posts you produce...

>  Now, when I install Fedora on a 
> server, I reboot and start over if I see anything that looks even 
> remotely desktop-related. This is a broken use case.
>  Solutions are:
> 
> 1) Add the "dependencies have been added" screen that every other 
> package install tool in the distro has but Anaconda insists on going 
> without.

Have you filed this RFE in bugzilla against anaconda?  Unless you make
this an autoclosing summary you've just broken a feature that people
have been asking for for quite a while, the ability to just walk away
once depsolving starts.  If depsolving is successful the install should
just start without any further interaction.  Also, fun to figure out for
kickstarts.

> 2) Have checkboxes in the package screen be tri-state. (checked if you 
> want it, unchecked if you don't want it, red x if yum is not allowed to 
> install it for any reason). This one's not pretty, but it'd work.

And just how is yum supposed to know that it can't install it?  Where
does that information come from, and if we have that information, why
would we ever even display the package then?  "Here is something you
can't click!  neener neener neeeeener!"

> 3) Provide a default install. 

We have one, it's what happens if you go next next next.  It's defined
in comps by the groups that are marked as default and the packages
therein that are defined as mandatory and default.  It's also what you
get in kickstarts if you do %packages --default.

> Believe me, I won't agree with what you 
> put in it at all. I will, however, be happier than I am now.

Then be happy.

> 4) Document the procedure a few emails up on how to install just @core 
> or @core + @base . I didn't even know the system would run right if you 
> unchecked everything.

It all depends on your definition of "run".  It'll boot.  Does one
really need to document the process of unchecking boxes?  (or checking
the Base group box)

> 
> Spending a little energy and not pleasing everyone is a lot better than 
> spending no energy and epic failing.

You have an epic ability to blow things out of proportion.  Maybe if you
looked at the anaconda source, or comps, and provided patches for what
you'd like to see, not only would it be helpful, but you'd also have
more code to rant about in your blogs!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/346fa484/attachment.sig>

From jkeating at redhat.com  Wed Oct 22 14:47:22 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 22 Oct 2008 07:47:22 -0700
Subject: Regarding install options
In-Reply-To: <48FE87BE.2090705@redhat.com>
References: <1223677508.3564.1295.camel@beck.corsepiu.local>
	<1223677870.4410.185.camel@luminos.localdomain>
	<1223791786.3564.1322.camel@beck.corsepiu.local>
	<1223855755.3327.12.camel@luminos.localdomain>
	<1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928764.3327.40.camel@luminos.localdomain>
	<48FE87BE.2090705@redhat.com>
Message-ID: <1224686842.3417.14.camel@luminos.localdomain>

On Tue, 2008-10-21 at 21:54 -0400, Casey Dahlin wrote:
> Which means you've successfully removed the user's ability to 
> legitimately complain. Doesn't mean they aren't even more annoyed now 
> then they are then.

No, it means we've stopped playing word games with users.  Now when/if
they have a complaint about the package set they get when they uncheck
all boxes, we can deal with it at a comps level, rather than trying to
play word games at the installer level with what all of comps a
"minimal" install should be.

Seriously, we give people the freedom to define their own "minimal" and
it works well.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/7f96a205/attachment.sig>

From mike at miketc.net  Wed Oct 22 14:52:11 2008
From: mike at miketc.net (Mike Chambers)
Date: Wed, 22 Oct 2008 09:52:11 -0500
Subject: Rawhide install 10/21
Message-ID: <1224687131.2636.5.camel@scrappy.miketc.net>

Tried doing an install last night (early this morning) after work, and
when getting to the network config screen, it still wouldn't accept a
static IP.  I had to change it to dhcp, then the next screen on what
source to install from, tried nfs and got some kind of yum type error (I
couldn't remember the exact error, sorry) and had to reboot.  I tried
again, this time first picking dhcp as default and using the http
default install and it went fine.  I thought I might have gotten an
error if I performed an nfs install again so I didn't try (thinking, the
2nd error was related to the network error or something).

Other than that, the install sent fine, cept the fonts (not sure of
size, 12, 14 maybe) on a lot of the screens was just a tad blurred for
me (on an nvidia chipset), whereas before they were fine.  I think this
may have to do with a change recently, as the screen resolution seemed
bigger than before and maybe had something to do with it?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From lesmikesell at gmail.com  Wed Oct 22 15:01:29 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 22 Oct 2008 10:01:29 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gdnae7$9tt$1@ger.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>	<48FE2BBD.2030802@gmail.com>	<gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com> <gdnae7$9tt$1@ger.gmane.org>
Message-ID: <48FF4049.1080904@gmail.com>

Rex Dieter wrote:
>
>>> Blame too those upstream projects who introduce these changes, fedora is
>>> just a collection of all those items.
>> So you'll ship any sort of breakage with no regard to the interfaces you
>> promoted last month?
> 
> Thanks for putting words into my and fedora's mouth.

Actually I'm trying to give a user's perspective.  As a closed black 
box, fedora might work.  I want to use 3rd party drivers, components, 
apps, etc. but can't deal with them breaking every few months.

> OK, I'll bite a bit...
> when it's the choice of shipping an older unsupported version of software
> vs. latest/supported, sometimes, yeah.  It's a tough choice to have to
> make.

Older/newer isn't quite the point here - it is more about why it is 
necessary to break old functionality to add new or improved.  Start with 
the premise that fedora repositories don't and cannot contain all the 
software that I want to run and perhaps you can see why interface change 
is painful.

> Unanswered:
>> Is there similar outrage against upstreams as well?  Where is it?

Yes, to whatever extent upstream refuses to respect their own interfaces 
as contracts with other programmers they deserve outrage as well.  But, 
you don't have to ship that stuff.  Maybe if no one did, they'd decide 
it was worth stabilizing interfaces to a point where others could cooperate.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Wed Oct 22 15:08:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 22 Oct 2008 08:08:07 -0700
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48FF4049.1080904@gmail.com>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com>	<gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com> <gdnae7$9tt$1@ger.gmane.org>
	<48FF4049.1080904@gmail.com>
Message-ID: <1224688087.3417.15.camel@luminos.localdomain>

On Wed, 2008-10-22 at 10:01 -0500, Les Mikesell wrote:
> Yes, to whatever extent upstream refuses to respect their own interfaces 
> as contracts with other programmers they deserve outrage as well.  But, 
> you don't have to ship that stuff.  Maybe if no one did, they'd decide 
> it was worth stabilizing interfaces to a point where others could cooperate.

Or more likely, everybody /but/ Fedora would ship it and then Fedora
would be laughed at for being too old and slow to adopt new upstream
releases.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/f5ed64c7/attachment.sig>

From tibbs at math.uh.edu  Wed Oct 22 15:36:56 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 22 Oct 2008 10:36:56 -0500
Subject: Summary of the 2008-10-21 Packaging Committee meeting
In-Reply-To: <20081022080536.GC2675@free.fr>
References: <ufar669flro.fsf@epithumia.math.uh.edu>
	<20081022080536.GC2675@free.fr>
Message-ID: <ufay70giquf.fsf@epithumia.math.uh.edu>

>>>>> "PD" == Patrice Dumas <pertusus at free.fr> writes:

PD> Tired to tell everytime the same, I have put an argumentation
PD> here:
PD> https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace

Well, I don't recall seeing a draft guideline anywhere; if you want to
submit one, be my guest.  I believe this needs to be in the actual
guidelines.

PD> I think that it would be better to tackle this issue cross
PD> distribution, that is when we see a real conflict or a generic
PD> name used, talk to the distribution list to agree on a name.

My intent was that packagers would consult FPC in the case of
questions, and that FPC could take appropriate action, including
checking what other distros do and attempting to coordinate when
possible.

PD> A last word, I think that it is sad that we have to do a guideline
PD> here, since upstream and packagers should understand the issue,
PD> and we already have too many guidelines, but I also don't know how
PD> to solve it differently, I am tired of looking at every submission
PD> and whine if it smells like a generic name is used.

These things are not always obvious to packagers, which is why we have
guidelines and reviewers.  The intent is to make the guideline as
short as possible (because the alternative is to make it impossibly
huge), but I don't think we can continue without some kind of
guideline here.

And as for getting tired of this issue, I guess the only thing I can
offer is sympathy and advise that you get used to it.  Many upstreams
simply will not care, because to them people who use other similarly-
or identically-named programs simply won't compile theirs.  We,
however, have to consider the uniqueness of filenames across the
entire distribution, not just sets of installed packages.

 - J<



From gilboad at gmail.com  Wed Oct 22 15:22:18 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 22 Oct 2008 17:22:18 +0200
Subject: Chaning the default icewm theme.
In-Reply-To: <loom.20081020T155258-733@post.gmane.org>
References: <1224499079.23491.11.camel@gilboa-home-dev.localdomain>
	<loom.20081020T155258-733@post.gmane.org>
Message-ID: <1224688938.12078.2.camel@gilboa-work-dev.localdomain>

On Mon, 2008-10-20 at 16:04 +0000, Kevin Kofler wrote:
> Gilboa Davara <gilboad <at> gmail.com> writes:
> > 2. The Fedora theme uses the Fedora icon as it's "start" button. I tried
> > contacting the Fedora-legal theme and get their permission to use this
> > icon - but got no replays. Do I require explicit permissions to use this
> > icon? (I've got the same problem in RHEL/CentOS - but I'll ask the same
> > question in the EPEL ML.)
> 
> You cannot distribute the Fedora logo or the Red Hat red hat as part of your 
> theme. The logo has to be in the fedora-logos package (for RHEL, that would be 
> the redhat-logos package, but good luck getting an icon added there - most 
> likely it would only be added if your theme ends up in an RHEL release and so 
> the icon is needed, likewise centos-logos will probably only add the icon if 
> your theme is actually shipped in CentOS, not EPEL or something) and some 
> fallback has to be provided, either inside the theme if it is possible, or in 
> generic-logos.
> 
> The way it's done in KDE 4 is that:
> * kde-settings contains a Fedora-KDE icon theme which inherits from Oxygen and 
> which is shipped empty. So by default (*), you get the KDE logo from Oxygen as 
> the start button. Fedora-KDE is also set as the default icon theme for KDE by 
> kde-settings.
> * fedora-logos drops the Fedora logo into that icon theme, so it overrides 
> Oxygen's KDE logo.
> * In our case, no fallback icon is needed in generic-logos because icon theme 
> inheritance takes care of it automatically.
> 
> (*) but that default is only invoked in the absence of fedora-logos
> 
> One thing you can do for RHEL/CentOS (which should also work in Fedora) is to 
> find an icon in redhat-logos which has a fallback with the same file name in 
> generic-logos (and fedora-logos and centos-logos), then just symlink to that 
> and add a Requires: system-logos. But you can't use your own fallback (e.g. 
> IceWM logo) that way, you get whatever is in generic-logos.
> 
>         Kevin Kofler
> 

Kevin,

Thanks for the info.
I'll give it a try.

- Gilboa



From choeger at cs.tu-berlin.de  Wed Oct 22 15:47:27 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Wed, 22 Oct 2008 17:47:27 +0200
Subject: Why does yum always need a global lock?
In-Reply-To: <1224677851.3304.57.camel@rosebud>
References: <1224612117.4047.3.camel@choeger6>
	<1224614253.3304.24.camel@rosebud>
	<1224658941.7651.4.camel@s4.math.tu-berlin.de>
	<1224677851.3304.57.camel@rosebud>
Message-ID: <1224690447.18658.6.camel@choeger6>

ok, that sounds like some motivation for me do to it. 

I've had a quick look over the source code and could not yet figure out,
which functions really modify stuff in /var/cache/yum, but at a first
glance it seem to be a few. You do not have a list of them flying
around, don't you? ;)

My approach would be to create a decorator (called @needslock or
something) and add it to every function that needs it. That decorator
would look like the one in the attachment.
Is that the yum-way fo doing it?

regards

Christoph


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 487 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/47df4521/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/47df4521/attachment.sig>

From kevin at scrye.com  Wed Oct 22 15:48:02 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 22 Oct 2008 09:48:02 -0600
Subject: Plan for tomorrows (20081022) FESCO meeting
In-Reply-To: <1224613933.7107.8.camel@kennedy>
References: <1224613933.7107.8.camel@kennedy>
Message-ID: <20081022094802.38716237@ohm.scrye.com>

On Tue, 21 Oct 2008 14:32:13 -0400
bpepple at fedoraproject.org (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, Wednesday at 17:00
> UTC in #fedora-meeting on irc.freenode.org:

I am out traveling/vacationing, and thus might miss the meeting. 
I'll try and make it, but if not... 

> /topic FESCo-Meeting -- sponsor nominations -- Andreas Thienemann
> (ixs)

+1 from me. 

> /topic FESCo-Meeting -- adjusting post-beta snapshots -
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01994.html
> - all

+1 from me. 

> /topic FESCo-Meeting -- Features - Sbin Sanity -
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00337.html
> - Ville Skytt?

Are the feature owners going to be there to defend their feature?
I think that those folks having problems with tab completion or sudo
now will be much more able to modify their setup than the millions of
people who get confused because they can't run ifconfig after 'su' or
just as their user to gather information. 

So, my vote would be to keep the feature as it is, but add
documentation or other info to help the folks that are negatively
impacted by this feature to get their setup back to the way they like. 
Release notes? 

> /topic FESCo-Meeting -- Features - all
>
> /topic FESCo meeting -- Free discussion around Fedora
> 
> 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.

We may want to discuss and answer: 
https://fedorahosted.org/fesco/ticket/8#comment:2
We said we want no 'compat-python24' in Fedora, but what about a
private copy of it to allow zope to work?

> Later,
> /B

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/978fd9ae/attachment.sig>

From crobinso at redhat.com  Wed Oct 22 15:53:28 2008
From: crobinso at redhat.com (Cole Robinson)
Date: Wed, 22 Oct 2008 11:53:28 -0400
Subject: Virt* , s-c-display , desktop-effects - Translation submission
 issues!
In-Reply-To: <48FEF504.8030606@redhat.com>
References: <48FEF504.8030606@redhat.com>
Message-ID: <48FF4C78.7070509@redhat.com>

Ankitkumar Rameshchandra Patel wrote:
> Hi,
>  

> [virt-manager]
> https://bugzilla.redhat.com/show_bug.cgi?id=467808
> 
> [virt-inst]
> https://bugzilla.redhat.com/show_bug.cgi?id=467810
> 

I was waiting for all the translations to trickle in
before committing upstream, which I will do shortly.

Thanks,
Cole



From pertusus at free.fr  Wed Oct 22 15:53:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 22 Oct 2008 17:53:34 +0200
Subject: Summary of the 2008-10-21 Packaging Committee meeting
In-Reply-To: <ufay70giquf.fsf@epithumia.math.uh.edu>
References: <ufar669flro.fsf@epithumia.math.uh.edu>
	<20081022080536.GC2675@free.fr>
	<ufay70giquf.fsf@epithumia.math.uh.edu>
Message-ID: <20081022155334.GE3425@free.fr>

On Wed, Oct 22, 2008 at 10:36:56AM -0500, Jason L Tibbitts III wrote:
> >>>>> "PD" == Patrice Dumas <pertusus at free.fr> writes:
> 
> PD> Tired to tell everytime the same, I have put an argumentation
> PD> here:
> PD> https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace
> 
> Well, I don't recall seeing a draft guideline anywhere; if you want to
> submit one, be my guest.  I believe this needs to be in the actual
> guidelines.

Actually that is also my opinion (maybe it wasn't clear...), though I am
reluctant, we have to face that too many upstream don't care.

I can help you with the guideline, but I don't have that much time
during the week, I have time on week-ends.

--
Pat



From lesmikesell at gmail.com  Wed Oct 22 15:55:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 22 Oct 2008 10:55:36 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224686528.4856.50.camel@macbook.infradead.org>
References: <48EF5054.3040106@ispbrasil.com.br>	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>	<1223674536.3564.1262.camel@beck.corsepiu.local>	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>	<48FE2BBD.2030802@gmail.com>
	<gdn7of$v73$1@ger.gmane.org>	<48FF279C.2000501@gmail.com>	<1224682689.4856.31.camel@macbook.infradead.org>	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
Message-ID: <48FF4CF8.5090404@gmail.com>

David Woodhouse wrote:
> 
>>>> So you'll ship any sort of breakage with no regard to the
>>>> interfaces you promoted last month?
>>> Of course not. We take care to ensure that when interfaces change, 
>>> every Fedora package is updated to cope.
>> Leaving everything all 3rd party work that tries to cooperate and a 
>> user's own previous work useless. 
> 
> I've never found that to be the case, no. Any third party work that
> "tried to co-operate" would be packaged as a Fedora package, and would
> be included in my above statement.

Give me a break... Nvidia, VMware, Sun Java, java apps, and on and on. 
If something _has_ to be included as a Fedora package to work from one 
release to the next, Fedora has failed for me.

>>  If a commercial system did that, they'd be out of business in a
>> heartbeat. 
> 
> The ability to cope with change is _precisely_ what distinguishes free
> software from the commercial systems that it is slowly, but surely,
> replacing.

How is having to modify and recompile every package every few months 
'coping' with change?  It is fairly rare to ever have to replace a 
binary on a windows or mac due to an OS update.  The mac even maintains 
backwards compatibility across an update to a different CPU and wildly 
different OS - and includes tools to migrate your settings and apps. 
Without the stability factor that enterprise and long-term distributions 
contribute, free software wouldn't be replacing anything.

> The only people who really have a problem with it are those who fail to
> work properly with whatever they call their 'upstream' project(s).

What should that mean to the user of the third party products that don't 
'work properly' with fedora?  Why would anyone need to 'work properly' 
as opposed to following standard interfaces to interoperate correctly?

>>  A free distribution doesn't have the same reasons to care about
>> cooperation, but from the user's perspective its all the same - if you
>> can't count on interfaces being maintained, a platform simply isn't
>> worth the effort.
> 
> There is a difference between internal and external APIs. Basic stuff
> like GTK and glibc _don't_ break in incompatible ways very often. Those
> are the kinds of things that external software uses.

What does mean in terms of being able to install vendor drivers, VMware, 
Sun's Java with integration into the system path scheme, or something 
from a random 3rd party repo?

> If you're involved in the horrid details of the latest PackageKit API
> change, then you really have no business being an _external_ piece of
> software anyway.   Whatever it is, it should be packaged and included in
> the Fedora repository, and then we'll be able to take care of it when we
> break it.

That is completely unrealistic, given a Fedora policy that excludes 
things from the repository for various reasons, and just wrong to 
require the system to be self-contained on general principles.

> To be honest, Les, I think you're just spouting crap again. It's an
> unfortunate habit with you, isn't it?

Its only crap if you believe that a distribution should require every 
piece of software that it will run to 'work properly' with the 
distribution provider according to the distribution provider's 
definition.  I don't - I believe interfaces are what makes software work.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From tcallawa at redhat.com  Wed Oct 22 15:59:31 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 22 Oct 2008 11:59:31 -0400
Subject: Plan for tomorrows (20081022) FESCO meeting
In-Reply-To: <20081022094802.38716237@ohm.scrye.com>
References: <1224613933.7107.8.camel@kennedy>
	<20081022094802.38716237@ohm.scrye.com>
Message-ID: <1224691171.3342.30.camel@localhost.localdomain>

On Wed, 2008-10-22 at 09:48 -0600, Kevin Fenzi wrote:
> We said we want no 'compat-python24' in Fedora, but what about a
> private copy of it to allow zope to work?

For what its worth, this would violate the Packaging Guidelines:

http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_projects

We wouldn't let it bundle in an old copy of libc if it needed libc5. Its
time Zope moved into the 21st century.

~spot



From mackay_d at bellsouth.net  Wed Oct 22 16:03:07 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Wed, 22 Oct 2008 11:03:07 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gdnae7$9tt$1@ger.gmane.org>
References: <48EF5054.3040106@ispbrasil.com.br>
	<48EF59BB.7000205@odu.neva.ru>	<48EFAF3A.9080709@gmail.com>
	<1223674536.3564.1262.camel@beck.corsepiu.local>
	<16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>  <gdnae7$9tt$1@ger.gmane.org>
Message-ID: <1224691387.5412.52.camel@vorpal.macdev.com>


On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
> Unanswered:
> > Is there similar outrage against upstreams as well?  Where is it?

On this list, it's shouted down.  I commented some time ago about the
rather toxic behavior of the python developers vis-a-vis breaking
compatibility at virtually every release.  You would have thought that I
had urinated in the holy water.

It's an ugly little wart on the free software movement.  There's nowhere
near the incentive to take care of your user base without a direct
financial gain.  Not, mind you, that commercial ventures haven't done
the same, but the consequences to them are more severe and direct.

Dave




From james at fedoraproject.org  Wed Oct 22 16:08:45 2008
From: james at fedoraproject.org (James Antill)
Date: Wed, 22 Oct 2008 12:08:45 -0400
Subject: Why does yum always need a global lock?
In-Reply-To: <1224690447.18658.6.camel@choeger6>
References: <1224612117.4047.3.camel@choeger6>
	<1224614253.3304.24.camel@rosebud>
	<1224658941.7651.4.camel@s4.math.tu-berlin.de>
	<1224677851.3304.57.camel@rosebud> <1224690447.18658.6.camel@choeger6>
Message-ID: <1224691725.3898.15.camel@code.and.org>

On Wed, 2008-10-22 at 17:47 +0200, Christoph H?ger wrote:
> ok, that sounds like some motivation for me do to it. 
> 
> I've had a quick look over the source code and could not yet figure out,
> which functions really modify stuff in /var/cache/yum, but at a first
> glance it seem to be a few. You do not have a list of them flying
> around, don't you? ;)

 Without thinking about it too long, the big problems are:

1. As soon as you open a repomd.xml for a repo. you need to make sure
that repo. metadata doesn't change. dito. problems with two yum
instances using the same repoid to mean different repos.
 IMO this should be fixed without adding locking (), but you could do it
the locking way.

2. The package downloading isn't safe from multiple yums. 
        2b. Auto cleanup shouldn't delete stuff that was download by
        another yum instance :)

 This _really_ needs to be done without locking, so background processes
can start downloading lots of updates without killing the cmd line UI if
it starts up.

3. plugins, like fastest mirror, assuming locking.
 Probably just audit/fix the plugins to not require locking.

4. Complete transaction/yum.log should be looked at.

5. Need to make sure we dtrt. wrt. yum not being locked by rpm being
locked, this is true now ... but less tested.

> My approach would be to create a decorator (called @needslock or
> something) and add it to every function that needs it. That decorator
> would look like the one in the attachment.
> Is that the yum-way fo doing it?

 You can't do it this way, locking requirements aren't localized to
specific functions ... if you want to go the locking route you'll have
to add locks per. operation and take them when certain functions are run
but only drop them when the repo/YumBase is deleted. You also need to
make sure it doesn't deadlock.

-- 
James Antill <james at fedoraproject.org>
Fedora



From berrange at redhat.com  Wed Oct 22 16:20:53 2008
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 22 Oct 2008 17:20:53 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224691387.5412.52.camel@vorpal.macdev.com>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com> <gdnae7$9tt$1@ger.gmane.org>
	<1224691387.5412.52.camel@vorpal.macdev.com>
Message-ID: <20081022162053.GI24340@redhat.com>

On Wed, Oct 22, 2008 at 11:03:07AM -0500, David G. Mackay wrote:
> 
> On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
> > Unanswered:
> > > Is there similar outrage against upstreams as well?  Where is it?
> 
> On this list, it's shouted down.  I commented some time ago about the
> rather toxic behavior of the python developers vis-a-vis breaking
> compatibility at virtually every release.  You would have thought that I
> had urinated in the holy water.
> 
> It's an ugly little wart on the free software movement.  There's nowhere
> near the incentive to take care of your user base without a direct
> financial gain.  Not, mind you, that commercial ventures haven't done
> the same, but the consequences to them are more severe and direct.

You don't get to dictate what the upstream project's priorities are.
If you don't like the fact that apps break with every new python
release (I don't like it either), then pick a different programming
language with an upstream whose priorities better align with your
needs. eg, Perl or Java or OCaml or any number of other languages.
Open source is about freedom of choice & that applies to everyone,
users, developers, packagers alike. The python developers/community
have decided the level of stability they want between each of their
releases - they decided to accept a certain level of breakage. You
have the freedom to decide whether this matches your needs and if 
not, no one is forcing you to use python.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



From schaiba at gmail.com  Wed Oct 22 16:25:12 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Wed, 22 Oct 2008 19:25:12 +0300
Subject: kde needs mysql-server ??
In-Reply-To: <gdnbo9$f91$1@ger.gmane.org>
References: <48FF046A.3000501@nobugconsulting.ro>
	<gdn7ut$v73$2@ger.gmane.org>	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>
	<gdnbo9$f91$1@ger.gmane.org>
Message-ID: <48FF53E8.6030501@gmail.com>

Rex Dieter wrote:
> Enrico Scholz wrote:
>
>   
>> Do you mean:
>>     
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F 
>   
>> ?  --> akonadi doees not need a local mysql-server but can use a mysql
>> server running somewhere else.
>>     
>
> Theoretically, yes.  The default config is to use a local one, however.
>
> -- Rex
>
>   
Try removing mysql-server and see how many important packages it pulls 
after it...that is, important for a desktop user.



From kevin at scrye.com  Wed Oct 22 16:20:23 2008
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 22 Oct 2008 10:20:23 -0600
Subject: Plan for tomorrows (20081022) FESCO meeting
In-Reply-To: <1224691171.3342.30.camel@localhost.localdomain>
References: <1224613933.7107.8.camel@kennedy>
	<20081022094802.38716237@ohm.scrye.com>
	<1224691171.3342.30.camel@localhost.localdomain>
Message-ID: <20081022102023.1c0a282d@ohm.scrye.com>

On Wed, 22 Oct 2008 11:59:31 -0400
tcallawa at redhat.com ("Tom \"spot\" Callaway") wrote:

> On Wed, 2008-10-22 at 09:48 -0600, Kevin Fenzi wrote:
> > We said we want no 'compat-python24' in Fedora, but what about a
> > private copy of it to allow zope to work?
> 
> For what its worth, this would violate the Packaging Guidelines:
> 
> http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_projects
> 
> We wouldn't let it bundle in an old copy of libc if it needed libc5.
> Its time Zope moved into the 21st century.

Ah ha. I looked for such a guideline, but couldn't find it for some
reason. 

Thanks for clarifying. 

> 
> ~spot
> 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/30df9b20/attachment.sig>

From pertusus at free.fr  Wed Oct 22 16:30:11 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 22 Oct 2008 18:30:11 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224686528.4856.50.camel@macbook.infradead.org>
References: <1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
Message-ID: <20081022163011.GF3425@free.fr>

On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
> 
> I've never found that to be the case, no. Any third party work that
> "tried to co-operate" would be packaged as a Fedora package, and would
> be included in my above statement.

Packages included in fedora have been broken for months or years now.
You may think that these are not important packages, but still they are
in fedora. Now as I told already fixing these packages or coming up with
a design more backward compatible may entail some costs too, but
having packages in fedora isn't a insurance against breakage. Gnome
packages and major desktop package, sure will get a lot of love, but
packages that are not 'mainstream' fedora won't be taken in
consideration that much.

--
Pat



From chris.stone at gmail.com  Wed Oct 22 16:24:39 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Wed, 22 Oct 2008 09:24:39 -0700
Subject: kde needs mysql-server ??
In-Reply-To: <gdnbo9$f91$1@ger.gmane.org>
References: <48FF046A.3000501@nobugconsulting.ro> <gdn7ut$v73$2@ger.gmane.org>
	<87wsg0pw7g.fsf@fc5.bigo.ensc.de> <gdnbo9$f91$1@ger.gmane.org>
Message-ID: <d9c612bf0810220924q53f8da5n144105e9940853f7@mail.gmail.com>

On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter at math.unl.edu> wrote:

> Enrico Scholz wrote:
>
> > Do you mean:
>
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F
> > ?  --> akonadi doees not need a local mysql-server but can use a mysql
> > server running somewhere else.
>
> Theoretically, yes.  The default config is to use a local one, however.
>
> -- Rex
>
>
mysql-server should not be a requirement then.  If it is possible to run the
server on another machine, then the mysql-server should be removed from the
Requires.

I do the exact same thing with one of my packages, poker-server.
poker-server *requires* a mysql-server, but does not require that it be run
on the same machine.  Therefore mysql-server should *NOT* be in the Requires
list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/3dd868b8/attachment.htm>

From ville.skytta at iki.fi  Wed Oct 22 16:55:55 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 22 Oct 2008 19:55:55 +0300
Subject: Plan for tomorrows (20081022) FESCO meeting
In-Reply-To: <20081022094802.38716237@ohm.scrye.com>
References: <1224613933.7107.8.camel@kennedy>
	<20081022094802.38716237@ohm.scrye.com>
Message-ID: <200810221955.56380.ville.skytta@iki.fi>

On Wednesday 22 October 2008, Kevin Fenzi wrote:
> On Tue, 21 Oct 2008 14:32:13 -0400
>
> > /topic FESCo-Meeting -- Features - Sbin Sanity -
> > https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00337.h
> >tml - Ville Skytt?
>
> Are the feature owners going to be there to defend their feature?
> I think that those folks having problems with tab completion or sudo
> now will be much more able to modify their setup than the millions of
> people who get confused because they can't run ifconfig after 'su' or
> just as their user to gather information.
>
> So, my vote would be to keep the feature as it is, but add
> documentation or other info to help the folks that are negatively
> impacted by this feature to get their setup back to the way they like.
> Release notes?

One of the crucial points is that once */sbin is in PATH for everyone, things 
will start assuming that those things indeed are always in PATH.  After that, 
local modifications that remove */sbin from PATH will result in breakage and 
thus _cannot_ be feasibly done.

Reverting this feature *now* is just about the last possibility to do it 
without inflicting breakage.  It will delay getting "millions of people who 
get confused" unconfused somewhat (== until F-11 I guess, and incremental 
improvements are easy to make later on as/if we find places to do them - even 
to earlier distro versions), but as I've said many times, IMNSHO (and not 
only mine) slight delay is a lot better than either the messy "*/sbin in PATH 
for good" result, or later trying to pry */sbin ouf of there, causing 
breakage.



From rdieter at math.unl.edu  Wed Oct 22 17:05:34 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 12:05:34 -0500
Subject: kde needs mysql-server ??
References: <48FF046A.3000501@nobugconsulting.ro> <gdn7ut$v73$2@ger.gmane.org>
	<87wsg0pw7g.fsf@fc5.bigo.ensc.de> <gdnbo9$f91$1@ger.gmane.org>
	<d9c612bf0810220924q53f8da5n144105e9940853f7@mail.gmail.com>
Message-ID: <gdnmgu$rmb$1@ger.gmane.org>

Christopher Stone wrote:

> On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
>> Enrico Scholz wrote:
>> > Do you mean:

http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F
>> > ?  --> akonadi doees not need a local mysql-server but can use a mysql
>> > server running somewhere else.
>>
>> Theoretically, yes.  The default config is to use a local one, however.

> mysql-server should not be a requirement then.  If it is possible to run
> the server on another machine, then the mysql-server should be removed
> from the Requires.

And make default config not work?  It's a balancing act, where there is no
100% correct solution, I'm afraid.

Soft dependencies, could theoretically help in cases like this too.

-- Rex



From kwizart at gmail.com  Wed Oct 22 17:06:36 2008
From: kwizart at gmail.com (Nicolas Chauvet (kwizart))
Date: Wed, 22 Oct 2008 19:06:36 +0200
Subject: directfb version bump (with ABI bump)
Message-ID: <48FF5D9C.8090401@gmail.com>

Hello!


I would just warn the fedora-devel ml that a version bump for directfb
is scheduled before the end of the week.
This update has been tracked in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=456509
With this new version comes an ABI bump from the previous 1.0.0. thus, a
rebuild of dependents packages is required.

Here is the list of the dependent(s) package(s):
xine-lib-extras


So, this is more a warning if some packages would use the directfb
binaries directly for any reasons, and for third parties.
Specially:
gstreamer-plugins-bad


Nicolas (kwizart)




From rdieter at math.unl.edu  Wed Oct 22 17:07:28 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 12:07:28 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
References: <1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
	<20081022163011.GF3425@free.fr>
Message-ID: <gdnmkh$rmb$2@ger.gmane.org>

Patrice Dumas wrote:

> On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
>> 
>> I've never found that to be the case, no. Any third party work that
>> "tried to co-operate" would be packaged as a Fedora package, and would
>> be included in my above statement.
> 
> Packages included in fedora have been broken for months or years now.

Keep in mind that this discussion (imo) is more about general intentions,
not specific cases.

-- Rex



From lesmikesell at gmail.com  Wed Oct 22 17:16:08 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 22 Oct 2008 12:16:08 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081022162053.GI24340@redhat.com>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>	<1223677428.3564.1292.camel@beck.corsepiu.local>	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>	<20081021193704.e48f2d21.mschwendt@gmail.com>	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>	<48FE2BBD.2030802@gmail.com>
	<gdn7of$v73$1@ger.gmane.org>	<48FF279C.2000501@gmail.com>
	<gdnae7$9tt$1@ger.gmane.org>	<1224691387.5412.52.camel@vorpal.macdev.com>
	<20081022162053.GI24340@redhat.com>
Message-ID: <48FF5FD8.5080201@gmail.com>

Daniel P. Berrange wrote:
> 
>>>> Is there similar outrage against upstreams as well?  Where is it?
>> On this list, it's shouted down.  I commented some time ago about the
>> rather toxic behavior of the python developers vis-a-vis breaking
>> compatibility at virtually every release.  You would have thought that I
>> had urinated in the holy water.
>>
>> It's an ugly little wart on the free software movement.  There's nowhere
>> near the incentive to take care of your user base without a direct
>> financial gain.  Not, mind you, that commercial ventures haven't done
>> the same, but the consequences to them are more severe and direct.
> 
> You don't get to dictate what the upstream project's priorities are.

But it should be something open for discussion, and something considered 
when integrating a package into a distribution and when/if the 
incompatible changes should be propagated.

> If you don't like the fact that apps break with every new python
> release (I don't like it either), then pick a different programming
> language with an upstream whose priorities better align with your
> needs. eg, Perl or Java or OCaml or any number of other languages.

That decision would be a lot more obvious if the history of backwards 
compatibility of a project was tracked publicly, perhaps with the 
packagers of affected apps keeping track of the time they spend just to 
maintain functionality.  That would help a new user decide where to 
invest his own time.

> Open source is about freedom of choice & that applies to everyone,
> users, developers, packagers alike. The python developers/community
> have decided the level of stability they want between each of their
> releases - they decided to accept a certain level of breakage. You
> have the freedom to decide whether this matches your needs and if 
> not, no one is forcing you to use python.

It is pretty hard not to use python in a fedora or RH-based distro.   Or 
to use any other version than what the distro updates to internally - 
which means that any 3rd party or local additions will take extra work 
to keep precisely in step.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From sundaram at fedoraproject.org  Wed Oct 22 17:16:31 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 22 Oct 2008 22:46:31 +0530
Subject: kde needs mysql-server ??
In-Reply-To: <gdnbo9$f91$1@ger.gmane.org>
References: <48FF046A.3000501@nobugconsulting.ro>
	<gdn7ut$v73$2@ger.gmane.org>	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>
	<gdnbo9$f91$1@ger.gmane.org>
Message-ID: <48FF5FEF.2030403@fedoraproject.org>

Rex Dieter wrote:
> Enrico Scholz wrote:
> 
>> Do you mean:
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F 
>> ?  --> akonadi doees not need a local mysql-server but can use a mysql
>> server running somewhere else.
> 
> Theoretically, yes.  The default config is to use a local one, however.

Then, instead of a direct dependency, it might be better to add the 
package to the comps group, leaving the users to remove the package if 
it is not required for their local configuration.

Rahul



From dwmw2 at infradead.org  Wed Oct 22 17:25:11 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 22 Oct 2008 18:25:11 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <gdnmkh$rmb$2@ger.gmane.org>
References: <1223677428.3564.1292.camel@beck.corsepiu.local>
	<80d7e4090810101608t640785f2u3a89a5bebd741454@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
	<20081022163011.GF3425@free.fr>  <gdnmkh$rmb$2@ger.gmane.org>
Message-ID: <1224696311.4856.63.camel@macbook.infradead.org>

On Wed, 2008-10-22 at 12:07 -0500, Rex Dieter wrote:
> Patrice Dumas wrote:
> 
> > On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
> >> 
> >> I've never found that to be the case, no. Any third party work that
> >> "tried to co-operate" would be packaged as a Fedora package, and would
> >> be included in my above statement.
> > 
> > Packages included in fedora have been broken for months or years now.
> 
> Keep in mind that this discussion (imo) is more about general
> intentions, not specific cases.

Of _course_ it's not about specific cases. That would require actual
substantiated facts which can be verified or disproved; not just
handwaving and ranting.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From rdieter at math.unl.edu  Wed Oct 22 17:33:39 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 12:33:39 -0500
Subject: kde needs mysql-server ??
References: <48FF046A.3000501@nobugconsulting.ro>
	<gdn7ut$v73$2@ger.gmane.org>	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>
	<gdnbo9$f91$1@ger.gmane.org> <48FF5FEF.2030403@fedoraproject.org>
Message-ID: <gdno5j$2uf$1@ger.gmane.org>

Rahul Sundaram wrote:

> Rex Dieter wrote:
>> Enrico Scholz wrote:
>> 
>>> Do you mean:
>>
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F
>>> ?  --> akonadi doees not need a local mysql-server but can use a mysql
>>> server running somewhere else.
>> 
>> Theoretically, yes.  The default config is to use a local one, however.
> 
> Then, instead of a direct dependency, it might be better to add the
> package to the comps group, leaving the users to remove the package if
> it is not required for their local configuration.

That's an option we'll consider.

-- Rex



From james.antill at redhat.com  Wed Oct 22 17:38:37 2008
From: james.antill at redhat.com (James Antill)
Date: Wed, 22 Oct 2008 13:38:37 -0400
Subject: kde needs mysql-server ??
In-Reply-To: <48FF5FEF.2030403@fedoraproject.org>
References: <48FF046A.3000501@nobugconsulting.ro>
	<gdn7ut$v73$2@ger.gmane.org>	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>
	<gdnbo9$f91$1@ger.gmane.org>  <48FF5FEF.2030403@fedoraproject.org>
Message-ID: <1224697117.3898.18.camel@code.and.org>

On Wed, 2008-10-22 at 22:46 +0530, Rahul Sundaram wrote:
> Rex Dieter wrote:
> > Enrico Scholz wrote:
> > 
> >> Do you mean:
> > http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F 
> >> ?  --> akonadi doees not need a local mysql-server but can use a mysql
> >> server running somewhere else.
> > 
> > Theoretically, yes.  The default config is to use a local one, however.
> 
> Then, instead of a direct dependency, it might be better to add the 
> package to the comps group, leaving the users to remove the package if 
> it is not required for their local configuration.

 Queue BZs about the fact that "yum groupremove KDE" now deletes the
local mysql-server in 3, 2, ...

-- 
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/20081022/8f5cc7ef/attachment.sig>

From rdieter at math.unl.edu  Wed Oct 22 17:41:04 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 12:41:04 -0500
Subject: kde needs mysql-server ??
References: <48FF046A.3000501@nobugconsulting.ro>
	<gdn7ut$v73$2@ger.gmane.org>	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>
	<gdnbo9$f91$1@ger.gmane.org> <48FF5FEF.2030403@fedoraproject.org>
	<1224697117.3898.18.camel@code.and.org>
Message-ID: <gdnojg$9uq$1@ger.gmane.org>

James Antill wrote:

>  Queue BZs about the fact that "yum groupremove KDE" now deletes the
> local mysql-server in 3, 2, ...

it already removes a bunch of stuff that overlaps with other desktops too,
that's not news.

-- Rex




From rdieter at math.unl.edu  Wed Oct 22 17:50:18 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 12:50:18 -0500
Subject: kde needs mysql-server ??
References: <48FF046A.3000501@nobugconsulting.ro>
Message-ID: <gdnp4q$9uq$2@ger.gmane.org>

Manuel Wolfshant wrote:

>     Do we really need mysql-server on a _desktop_ running kde ?

fyi, backend storage is a wee bit of a mess in kde-land at the moment, see
http://pusling.com/blog/?p=85

-- Rex



From dominik at greysector.net  Wed Oct 22 18:02:01 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 22 Oct 2008 20:02:01 +0200
Subject: directfb version bump (with ABI bump)
In-Reply-To: <48FF5D9C.8090401@gmail.com>
References: <48FF5D9C.8090401@gmail.com>
Message-ID: <20081022180200.GA10950@mokona.greysector.net>

On Wednesday, 22 October 2008 at 19:06, Nicolas Chauvet (kwizart) wrote:
> Hello!
> 
> 
> I would just warn the fedora-devel ml that a version bump for directfb
> is scheduled before the end of the week.

I don't see an F-10 branch in pkgdb so I'm assuming you want to break ABI
just before a new release. Is there a good reason for this?

> This update has been tracked in this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=456509
> With this new version comes an ABI bump from the previous 1.0.0. thus, a
> rebuild of dependents packages is required.

Have you consulted this with Matthias? Can it be delayed until after F-10
is out?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From skvidal at fedoraproject.org  Wed Oct 22 18:02:41 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 22 Oct 2008 14:02:41 -0400
Subject: Why does yum always need a global lock?
In-Reply-To: <1224690447.18658.6.camel@choeger6>
References: <1224612117.4047.3.camel@choeger6>
	<1224614253.3304.24.camel@rosebud>
	<1224658941.7651.4.camel@s4.math.tu-berlin.de>
	<1224677851.3304.57.camel@rosebud> <1224690447.18658.6.camel@choeger6>
Message-ID: <1224698561.3304.69.camel@rosebud>

On Wed, 2008-10-22 at 17:47 +0200, Christoph H?ger wrote:
> ok, that sounds like some motivation for me do to it. 
> 
> I've had a quick look over the source code and could not yet figure out,
> which functions really modify stuff in /var/cache/yum, but at a first
> glance it seem to be a few. You do not have a list of them flying
> around, don't you? ;)
> 
> My approach would be to create a decorator (called @needslock or
> something) and add it to every function that needs it. That decorator
> would look like the one in the attachment.
> Is that the yum-way fo doing it?
> 

If you want to talk about this more - please join
yum-devel at lists.baseurl.org

fedora-devel is the wrong list for it.

thanks,
-sv




From pemboa at gmail.com  Wed Oct 22 18:05:50 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 22 Oct 2008 13:05:50 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <48FF5FD8.5080201@gmail.com>
References: <16de708d0810101453t88cf170pbc5674775560cb2a@mail.gmail.com>
	<20081021193704.e48f2d21.mschwendt@gmail.com>
	<16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com> <gdnae7$9tt$1@ger.gmane.org>
	<1224691387.5412.52.camel@vorpal.macdev.com>
	<20081022162053.GI24340@redhat.com> <48FF5FD8.5080201@gmail.com>
Message-ID: <16de708d0810221105m56414277kda29cd5c3882f765@mail.gmail.com>

On Wed, Oct 22, 2008 at 12:16 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Daniel P. Berrange wrote:
>>
>>>>> Is there similar outrage against upstreams as well?  Where is it?
>>>
>>> On this list, it's shouted down.  I commented some time ago about the
>>> rather toxic behavior of the python developers vis-a-vis breaking
>>> compatibility at virtually every release.  You would have thought that I
>>> had urinated in the holy water.
>>>
>>> It's an ugly little wart on the free software movement.  There's nowhere
>>> near the incentive to take care of your user base without a direct
>>> financial gain.  Not, mind you, that commercial ventures haven't done
>>> the same, but the consequences to them are more severe and direct.
>>
>> You don't get to dictate what the upstream project's priorities are.
>
> But it should be something open for discussion, and something considered
> when integrating a package into a distribution and when/if the incompatible
> changes should be propagated.


Have any of your discussions of this nature yielded fruitful results?
If not, your approach is failed, even if the intent is good. In which
case you need to come up with a more productive approach.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From nathanael at gnat.ca  Wed Oct 22 18:52:16 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 22 Oct 2008 12:52:16 -0600
Subject: Window / Screen question
Message-ID: <48FF7660.9060807@gnat.ca>

Hi,

   This isn't a fedora question specifically, however just thought I'd 
run it by to get some feedback.

   I've had a multi-card/multi-monitor setup for a few months now. It 
has been a royal pain. (Only the closed drivers can handle it 
unfortunately). I was talking to the radeon/ati driver people and have 
been informed that multi-card setups don't get much love from either the 
driver developers or upstream/xorg. So I've figured I may move from 3 
monitors back to 2 larger (24") monitors. So after that history, here 
comes the idea...

   I'm wondering if it is possible to have 'fake' monitor 
borders/dimensions. So you instruct xorg/gnome/xinerama or whatever that 
the 1900 pixel width is 2/3rd + 1/3rd. If I were to click maximize 
within either of those imaginary borders, it would maximize to that size 
instead of the 1900 px width. If I double clicked, it would then go 
fullscreen...

Does this sound at all useful? Opinions / critiques...

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From stlwrt at gmail.com  Wed Oct 22 19:05:50 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Wed, 22 Oct 2008 22:05:50 +0300
Subject: Window / Screen question
In-Reply-To: <48FF7660.9060807@gnat.ca>
References: <48FF7660.9060807@gnat.ca>
Message-ID: <d25f375f0810221205xcb92741oa70a3868692a517c@mail.gmail.com>

Sounds like tiling windowmanagers. dwm from http://suckless.org ?

On Wed, Oct 22, 2008 at 9:52 PM, Nathanael D. Noblet <nathanael at gnat.ca> wrote:
> Hi,
>
>  This isn't a fedora question specifically, however just thought I'd run it
> by to get some feedback.
>
>  I've had a multi-card/multi-monitor setup for a few months now. It has been
> a royal pain. (Only the closed drivers can handle it unfortunately). I was
> talking to the radeon/ati driver people and have been informed that
> multi-card setups don't get much love from either the driver developers or
> upstream/xorg. So I've figured I may move from 3 monitors back to 2 larger
> (24") monitors. So after that history, here comes the idea...
>
>  I'm wondering if it is possible to have 'fake' monitor borders/dimensions.
> So you instruct xorg/gnome/xinerama or whatever that the 1900 pixel width is
> 2/3rd + 1/3rd. If I were to click maximize within either of those imaginary
> borders, it would maximize to that size instead of the 1900 px width. If I
> double clicked, it would then go fullscreen...
>
> Does this sound at all useful? Opinions / critiques...
>
> --
> Nathanael d. Noblet
> Gnat Solutions, Inc
> T: 403.875.4613
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com



From nathanael at gnat.ca  Wed Oct 22 19:23:22 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 22 Oct 2008 13:23:22 -0600
Subject: Window / Screen question
In-Reply-To: <d25f375f0810221205xcb92741oa70a3868692a517c@mail.gmail.com>
References: <48FF7660.9060807@gnat.ca>
	<d25f375f0810221205xcb92741oa70a3868692a517c@mail.gmail.com>
Message-ID: <48FF7DAA.8060502@gnat.ca>


> On Wed, Oct 22, 2008 at 9:52 PM, Nathanael D. Noblet <nathanael at gnat.ca> wrote:
>> Hi,
>>
>>  This isn't a fedora question specifically, however just thought I'd run it
>> by to get some feedback.
>>
>>  I've had a multi-card/multi-monitor setup for a few months now. It has been
>> a royal pain. (Only the closed drivers can handle it unfortunately). I was
>> talking to the radeon/ati driver people and have been informed that
>> multi-card setups don't get much love from either the driver developers or
>> upstream/xorg. So I've figured I may move from 3 monitors back to 2 larger
>> (24") monitors. So after that history, here comes the idea...
>>
>>  I'm wondering if it is possible to have 'fake' monitor borders/dimensions.
>> So you instruct xorg/gnome/xinerama or whatever that the 1900 pixel width is
>> 2/3rd + 1/3rd. If I were to click maximize within either of those imaginary
>> borders, it would maximize to that size instead of the 1900 px width. If I
>> double clicked, it would then go fullscreen...
>>
>> Does this sound at all useful? Opinions / critiques...

 > Sounds like tiling windowmanagers. dwm from http://suckless.org ?

Does gnome support this? That would be very nice.

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From csnook at redhat.com  Wed Oct 22 19:46:30 2008
From: csnook at redhat.com (Chris Snook)
Date: Wed, 22 Oct 2008 15:46:30 -0400
Subject: Sendmail still default?
In-Reply-To: <48F87794.3090108@redhat.com>
References: <48F87794.3090108@redhat.com>
Message-ID: <48FF8316.2040903@redhat.com>

Lutz Lange wrote:
> i've just wondered why sendmail is still the default MTA in Fedora.
> Please enlighten me?

Changing defaults only makes sense if we're going to get rid of the 
current default or we're going to put a lot of work into the 
alternative.  Sendmail isn't about to disappear, and we don't do a lot 
of distro-specific work on MTAs, so there's little point to changing. 
If you prefer a different MTA, use it.

-- Chris



From denis at poolshark.org  Wed Oct 22 19:54:36 2008
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 22 Oct 2008 21:54:36 +0200
Subject: Plan for tomorrows (20081022) FESCO meeting
In-Reply-To: <1224691171.3342.30.camel@localhost.localdomain>
References: <1224613933.7107.8.camel@kennedy>	<20081022094802.38716237@ohm.scrye.com>
	<1224691171.3342.30.camel@localhost.localdomain>
Message-ID: <48FF84FC.2000808@poolshark.org>

Tom "spot" Callaway wrote:
> Its time Zope moved into the 21st century.

What do Zope developers say about the python upgrade ?

And to play devil's advocate, what would be their incentive to upgrade 
if, for example, they're perfectly happy with 2.4 ("if it ain't broken, 
don't fix it") and the upgrade would invalidate, say, 6 months of test 
validation and qualification ? I'm not saying that's true (I have no 
idea), this is just for argument's sake :-)

I remember back in a previous job where we used a gigantic (as in, 
gigantic) Perl script to run all sorts of hardware verification stuff. 
Every single minor Perl update meant 1 week of chasing and nailing down 
bugs. Granted, that was years ago and stuff is more stable now, but I 
can imagine some people would not be happy being "coerced" into 
upgrading a critical component...

denis



From rawhide at fedoraproject.org  Wed Oct 22 20:06:29 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 22 Oct 2008 20:06:29 +0000 (UTC)
Subject: rawhide report: 20081022 changes
Message-ID: <20081022200630.028C51B8001@releng2.fedora.phx.redhat.com>

Compose started at Wed Oct 22 14:38:16 UTC 2008

New package openlayers
        A JavaScript library for displaying map data in web browsers
Removed package qpackagekit
Updated Packages:

MAKEDEV-3.24-1
--------------
* Wed Oct 22 18:00:00 2008 Chris Lumens <clumens at redhat.com> 3.24-1
- Fix speed up patch (jakub, #466485).


NetworkManager-0.7.0-0.11.svn4201.fc10
--------------------------------------
* Tue Oct 21 18:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.11.svn4201
- Fix issues with hostname during anaconda installation (rh #461933)
- Fix Ad-Hoc WPA connections (rh #461197)
- Don't require gnome-panel or gnome-panel-devel (rh #427834)
- Fix determination of WPA encryption capabilities on some cards
- Fix conflicts with PPTP and vpnc plugins
- Allow .cer file extensions when choosing certificates


PackageKit-0.3.8-2.fc10
-----------------------
* Tue Oct 21 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.3.8-2
- Obsoletes: packagekit-qt(-devel)/qpackagekit(-devel)
- cleanup deps


augeas-0.3.2-1.fc10
-------------------
* Tue Oct 21 18:00:00 2008 David Lutterkort <dlutter at redhat.com> - 0.3.2-1
- New version


bluez-4.16-1.fc10
-----------------
* Tue Oct 21 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.16-11
- Update to 4.16


coreutils-6.12-16.fc10
----------------------
* Tue Oct 21 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 6.12-16
- make possible to disable capability in ls due to
  performance impact when not cached(#467508)
- do not patch generated manpages - generate them at build
  time
- do not mistakenly display -g and -G runuser option in su
  --help output


cups-1.3.9-2.fc10
-----------------
* Tue Oct 21 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 1:1.3.9-2
- Fixed textonly filter to send FF correctly.


desktop-backgrounds-9.0.0-3
---------------------------
* Tue Oct 21 18:00:00 2008 Ray Strode <rstrode at redhat.com> 9.0.0-3
- Move waves wallpapers to a subpackage


Broken deps for i386
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.i386 requires libcamel-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.i386 requires libcamel-provider-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.i386 requires libcamel-1.2.so.13
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-provider-1.2.so.13
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-1.2.so.13
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.i386 requires libcamel-1.2.so.13
	evolution-brutus-1.2.27-1.fc10.x86_64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.x86_64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.x86_64 requires libcamel-provider-1.2.so.13()(64bit)
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.x86_64 requires iml = 0:1.0.2-3.fc10
	planner-eds-0.14.3-5.fc10.x86_64 requires libcamel-1.2.so.13()(64bit)
	planner-eds-0.14.3-5.fc10.x86_64 requires libcamel-provider-1.2.so.13()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.ppc requires libcamel-1.2.so.13
	evolution-brutus-1.2.27-1.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.ppc requires libcamel-provider-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.ppc requires libcamel-1.2.so.13
	iml-devel-1.0.2-3.fc10.ppc requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	planner-eds-0.14.3-5.fc10.ppc requires libcamel-provider-1.2.so.13
	planner-eds-0.14.3-5.fc10.ppc requires libcamel-1.2.so.13
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.ppc64 requires libcamel-provider-1.2.so.13()(64bit)
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	planner-eds-0.14.3-5.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	planner-eds-0.14.3-5.fc10.ppc64 requires libcamel-provider-1.2.so.13()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From kevin.kofler at chello.at  Wed Oct 22 20:10:14 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 22 Oct 2008 20:10:14 +0000 (UTC)
Subject: directfb version bump (with ABI bump)
References: <48FF5D9C.8090401@gmail.com>
	<20081022180200.GA10950@mokona.greysector.net>
Message-ID: <loom.20081022T200836-822@post.gmane.org>

Dominik 'Rathann' Mierzejewski <dominik <at> greysector.net> writes:
> I don't see an F-10 branch in pkgdb so I'm assuming you want to break ABI
> just before a new release. Is there a good reason for this?

Is there a good reason not to? I could understand the objection if this 
affected a lot of packages, but there's exactly 1 dependent package in all of 
Fedora, which isn't even installed by default (it's called -extras for a 
reason) and which I can take care of rebuilding (I comaintain xine-lib).

        Kevin Kofler



From rdieter at math.unl.edu  Wed Oct 22 20:10:14 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 22 Oct 2008 15:10:14 -0500
Subject: kde needs mysql-server ??
References: <48FF046A.3000501@nobugconsulting.ro> <gdn7ut$v73$2@ger.gmane.org>
	<87wsg0pw7g.fsf@fc5.bigo.ensc.de> <gdnbo9$f91$1@ger.gmane.org>
	<d9c612bf0810220924q53f8da5n144105e9940853f7@mail.gmail.com>
	<gdnmgu$rmb$1@ger.gmane.org>
Message-ID: <gdo1b6$aqg$1@ger.gmane.org>

Rex Dieter wrote:

> Christopher Stone wrote:
> 
>> On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
>>> Enrico Scholz wrote:
>>> > Do you mean:
> 
>
http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F
>>> > ?  --> akonadi doees not need a local mysql-server but can use a mysql
>>> > server running somewhere else.
>>>
>>> Theoretically, yes.  The default config is to use a local one, however.
> 
>> mysql-server should not be a requirement then.  If it is possible to run
>> the server on another machine, then the mysql-server should be removed
>> from the Requires.
> 
> And make default config not work?  It's a balancing act, where there is no
> 100% correct solution, I'm afraid.

OK, discussed with fellow kde-sig'ers, we'll drop the hard dependency *for
now*.  Deciding factors included:
* nothing in fedora (and kde-4.1.x) actively uses akonadi yet.
* (bonus) mysql-server is big, omitting will save us some live image space

When kdepim-4.2.0 lands, we'll re-evaluate.

-- Rex



From dominik at greysector.net  Wed Oct 22 20:19:50 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 22 Oct 2008 22:19:50 +0200
Subject: directfb version bump (with ABI bump)
In-Reply-To: <loom.20081022T200836-822@post.gmane.org>
References: <48FF5D9C.8090401@gmail.com>
	<20081022180200.GA10950@mokona.greysector.net>
	<loom.20081022T200836-822@post.gmane.org>
Message-ID: <20081022201949.GB10950@mokona.greysector.net>

On Wednesday, 22 October 2008 at 22:10, Kevin Kofler wrote:
> Dominik 'Rathann' Mierzejewski <dominik <at> greysector.net> writes:
> > I don't see an F-10 branch in pkgdb so I'm assuming you want to break ABI
> > just before a new release. Is there a good reason for this?
> 
> Is there a good reason not to? I could understand the objection if this 
> affected a lot of packages, but there's exactly 1 dependent package in all of 
> Fedora, which isn't even installed by default (it's called -extras for a 
> reason) and which I can take care of rebuilding (I comaintain xine-lib).

I guess I'm objecting out of principle. One shouldn't break ABI a couple of
weeks before final release. However, if you don't mind (being the only one
affected), I won't complain any further.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From wolfy at nobugconsulting.ro  Wed Oct 22 20:21:57 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Wed, 22 Oct 2008 23:21:57 +0300
Subject: kde needs mysql-server ??
In-Reply-To: <gdo1b6$aqg$1@ger.gmane.org>
References: <48FF046A.3000501@nobugconsulting.ro>
	<gdn7ut$v73$2@ger.gmane.org>	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>
	<gdnbo9$f91$1@ger.gmane.org>	<d9c612bf0810220924q53f8da5n144105e9940853f7@mail.gmail.com>	<gdnmgu$rmb$1@ger.gmane.org>
	<gdo1b6$aqg$1@ger.gmane.org>
Message-ID: <48FF8B65.7070901@nobugconsulting.ro>

On 10/22/2008 11:10 PM, Rex Dieter wrote:
> Rex Dieter wrote:
>
>   
>> Christopher Stone wrote:
>>
>>     
>>> On Wed, Oct 22, 2008 at 7:01 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
>>>       
>>>> Enrico Scholz wrote:
>>>>         
>>>>> Do you mean:
>>>>>           
>>     
> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F
>   
>>>>> ?  --> akonadi doees not need a local mysql-server but can use a mysql
>>>>> server running somewhere else.
>>>>>           
>>>> Theoretically, yes.  The default config is to use a local one, however.
>>>>         
>>> mysql-server should not be a requirement then.  If it is possible to run
>>> the server on another machine, then the mysql-server should be removed
>>> from the Requires.
>>>       
>> And make default config not work?  It's a balancing act, where there is no
>> 100% correct solution, I'm afraid.
>>     
>
> OK, discussed with fellow kde-sig'ers, we'll drop the hard dependency *for
> now*.  
thanks

> Deciding factors included:
> * [...]
> * (bonus) mysql-server is big,
THAT is the reason for my initial question



From sundaram at fedoraproject.org  Wed Oct 22 20:39:26 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 23 Oct 2008 02:09:26 +0530
Subject: kde needs mysql-server ??
In-Reply-To: <1224697117.3898.18.camel@code.and.org>
References: <48FF046A.3000501@nobugconsulting.ro>	<gdn7ut$v73$2@ger.gmane.org>	<87wsg0pw7g.fsf@fc5.bigo.ensc.de>	<gdnbo9$f91$1@ger.gmane.org>
	<48FF5FEF.2030403@fedoraproject.org>
	<1224697117.3898.18.camel@code.and.org>
Message-ID: <48FF8F7E.2030701@fedoraproject.org>

James Antill wrote:
> On Wed, 2008-10-22 at 22:46 +0530, Rahul Sundaram wrote:
>> Rex Dieter wrote:
>>> Enrico Scholz wrote:
>>>
>>>> Do you mean:
>>> http://techbase.kde.org/Projects/PIM/Akonadi#Can_Akonadi_use_a_normal_MySQL_server_running_on_my_system.3F 
>>>> ?  --> akonadi doees not need a local mysql-server but can use a mysql
>>>> server running somewhere else.
>>> Theoretically, yes.  The default config is to use a local one, however.
>> Then, instead of a direct dependency, it might be better to add the 
>> package to the comps group, leaving the users to remove the package if 
>> it is not required for their local configuration.
> 
>  Queue BZs about the fact that "yum groupremove KDE" now deletes the
> local mysql-server in 3, 2, ...

This is just one of the symptom of the general issue of how groups are 
defined. That needs to be fixed somehow.

Rahul



From cdahlin at redhat.com  Wed Oct 22 20:43:58 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 22 Oct 2008 16:43:58 -0400
Subject: Window / Screen question
In-Reply-To: <48FF7DAA.8060502@gnat.ca>
References: <48FF7660.9060807@gnat.ca>	<d25f375f0810221205xcb92741oa70a3868692a517c@mail.gmail.com>
	<48FF7DAA.8060502@gnat.ca>
Message-ID: <48FF908E.5000906@redhat.com>

Nathanael D. Noblet wrote:
>
>> On Wed, Oct 22, 2008 at 9:52 PM, Nathanael D. Noblet 
>> <nathanael at gnat.ca> wrote:
>>> Hi,
>>>
>>>  This isn't a fedora question specifically, however just thought I'd 
>>> run it
>>> by to get some feedback.
>>>
>>>  I've had a multi-card/multi-monitor setup for a few months now. It 
>>> has been
>>> a royal pain. (Only the closed drivers can handle it unfortunately). 
>>> I was
>>> talking to the radeon/ati driver people and have been informed that
>>> multi-card setups don't get much love from either the driver 
>>> developers or
>>> upstream/xorg. So I've figured I may move from 3 monitors back to 2 
>>> larger
>>> (24") monitors. So after that history, here comes the idea...
>>>
>>>  I'm wondering if it is possible to have 'fake' monitor 
>>> borders/dimensions.
>>> So you instruct xorg/gnome/xinerama or whatever that the 1900 pixel 
>>> width is
>>> 2/3rd + 1/3rd. If I were to click maximize within either of those 
>>> imaginary
>>> borders, it would maximize to that size instead of the 1900 px 
>>> width. If I
>>> double clicked, it would then go fullscreen...
>>>
>>> Does this sound at all useful? Opinions / critiques...
>
> > Sounds like tiling windowmanagers. dwm from http://suckless.org ?
>
> Does gnome support this? That would be very nice.
>
I don't know that I agree with Nathaniel's recommendation. Tiled window 
managers do a lot of neat things, and are worth checking out, but I 
don't think they solve your problem specifically.

XRandR might be able to be coaxed into doing what you want. You also 
might be able to get Compiz to display 3 workspaces across 2 monitors.

--CJD



From mackay_d at bellsouth.net  Wed Oct 22 21:42:39 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Wed, 22 Oct 2008 16:42:39 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
Message-ID: <1224711759.5412.66.camel@vorpal.macdev.com>

On Wed, 2008-10-22 at 17:20 +0100, Daniel P. Berrange wrote:
> On Wed, Oct 22, 2008 at 11:03:07AM -0500, David G. Mackay wrote:
> > 
> > On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
> > > Unanswered:
> > > > Is there similar outrage against upstreams as well?  Where is
it?
> > 
> > On this list, it's shouted down.  I commented some time ago about
the
> > rather toxic behavior of the python developers vis-a-vis breaking
> > compatibility at virtually every release.  You would have thought
that I
> > had urinated in the holy water.
> > 
> > It's an ugly little wart on the free software movement.  There's
nowhere
> > near the incentive to take care of your user base without a direct
> > financial gain.  Not, mind you, that commercial ventures haven't
done
> > the same, but the consequences to them are more severe and direct.
> 
> You don't get to dictate what the upstream project's priorities are.

Dictate, no, criticize, yes.

> If you don't like the fact that apps break with every new python
> release (I don't like it either), then pick a different programming
> language with an upstream whose priorities better align with your
> needs. eg, Perl or Java or OCaml or any number of other languages.

Well, for me, it means that I will use python for smaller projects, and
probably java for large/persistent projects.  However, there are ripple
effects in that people that have developed tools that I want to use in
python, i. e. zope, are also placed in an untenable position.

> Open source is about freedom of choice & that applies to everyone,
> users, developers, packagers alike. The python developers/community
> have decided the level of stability they want between each of their
> releases - they decided to accept a certain level of breakage. You
> have the freedom to decide whether this matches your needs and if 
> not, no one is forcing you to use python.

True, but that cuts both ways.  If one of the goals is to get more
people to use open source, then making sure that it is usable ought to
be something of a priority.  If enterprises are going to make major
investments to develop software, then the current state of turmoil in
the open source software ecology is not attractive.

Dave





From skvidal at fedoraproject.org  Wed Oct 22 22:03:53 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 22 Oct 2008 18:03:53 -0400
Subject: providing what they require
Message-ID: <1224713033.3304.87.camel@rosebud>

Here is a list of pkgs and their requirement that they also provide.

http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt

Now, it would be handy if rpm filtered these out automagically at build
time, and that's something to think about. If you notice if any of your
packages do something like this manually, please stop it.


here's the script I used to generate the output:

http://skvidal.fedorapeople.org/misc/provides-what-they-require.py


-sv




From smooge at gmail.com  Wed Oct 22 22:08:36 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 22 Oct 2008 16:08:36 -0600
Subject: providing what they require
In-Reply-To: <1224713033.3304.87.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
Message-ID: <80d7e4090810221508p23e6044fgd7b773436171e8a2@mail.gmail.com>

On Wed, Oct 22, 2008 at 4:03 PM, seth vidal <skvidal at fedoraproject.org> wrote:
> Here is a list of pkgs and their requirement that they also provide.
>
> http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
>
> Now, it would be handy if rpm filtered these out automagically at build
> time, and that's something to think about. If you notice if any of your
> packages do something like this manually, please stop it.
>
>
> here's the script I used to generate the output:
>
> http://skvidal.fedorapeople.org/misc/provides-what-they-require.py
>

My brain no work. This means that they require themselves to
build/install? Or something else?


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From jonathan.underwood at gmail.com  Wed Oct 22 22:28:19 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 22 Oct 2008 23:28:19 +0100
Subject: providing what they require
In-Reply-To: <1224713033.3304.87.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
Message-ID: <645d17210810221528o5820738brf20297cb81a94ee@mail.gmail.com>

2008/10/22 seth vidal <skvidal at fedoraproject.org>:
> Here is a list of pkgs and their requirement that they also provide.
>
> http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
>
> Now, it would be handy if rpm filtered these out automagically at build
> time, and that's something to think about. If you notice if any of your
> packages do something like this manually, please stop it.
>
>

Um, how to stop it? - most of those Provides are automatically
generated by rpm. I know there is some messy instructions on how to
filter those for perl packages in the guidelines, but it seems more
widespread than perl packages...



From mschwendt at gmail.com  Wed Oct 22 22:41:49 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 23 Oct 2008 00:41:49 +0200
Subject: providing what they require
In-Reply-To: <645d17210810221528o5820738brf20297cb81a94ee@mail.gmail.com>
References: <1224713033.3304.87.camel@rosebud>
	<645d17210810221528o5820738brf20297cb81a94ee@mail.gmail.com>
Message-ID: <20081023004149.8b90f588.mschwendt@gmail.com>

On Wed, 22 Oct 2008 23:28:19 +0100, Jonathan Underwood wrote:

> 2008/10/22 seth vidal <skvidal at fedoraproject.org>:
> > Here is a list of pkgs and their requirement that they also provide.
> >
> > http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
> >
> > Now, it would be handy if rpm filtered these out automagically at build
> > time, and that's something to think about. If you notice if any of your
> > packages do something like this manually, please stop it.
> >
> >
> 
> Um, how to stop it? - most of those Provides are automatically
> generated by rpm. I know there is some messy instructions on how to
> filter those for perl packages in the guidelines, but it seems more
> widespread than perl packages...

Don't misunderstand Seth's list. The Provides are necessary and must not
be stripped, because external packages may require them. The Requires
in a pkg could be stripped if it's the same pkg that Provides the
needed things.

The "thunderbird" pkg contains a "find-external-requires" script which
does the thing that's proposed here. It ought to be rpmbuild, though,
that does this for all pkgs.



From pertusus at free.fr  Wed Oct 22 18:46:38 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 22 Oct 2008 20:46:38 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224696311.4856.63.camel@macbook.infradead.org>
References: <16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
	<20081022163011.GF3425@free.fr> <gdnmkh$rmb$2@ger.gmane.org>
	<1224696311.4856.63.camel@macbook.infradead.org>
Message-ID: <20081022184638.GB3089@free.fr>

On Wed, Oct 22, 2008 at 06:25:11PM +0100, David Woodhouse wrote:
> 
> Of _course_ it's not about specific cases. That would require actual
> substantiated facts which can be verified or disproved; not just
> handwaving and ranting.

I answered to Rex giving a specific case, regarding ConsoleKit and
various dm breakage. You want the bugzilla entries or you trust me?

--
Pat



From pemboa at gmail.com  Wed Oct 22 22:46:46 2008
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 22 Oct 2008 17:46:46 -0500
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224711759.5412.66.camel@vorpal.macdev.com>
References: <1224711759.5412.66.camel@vorpal.macdev.com>
Message-ID: <16de708d0810221546y19c015d2ua124fe0c98a3677@mail.gmail.com>

On Wed, Oct 22, 2008 at 4:42 PM, David G. Mackay <mackay_d at bellsouth.net> wrote:
> On Wed, 2008-10-22 at 17:20 +0100, Daniel P. Berrange wrote:
>> On Wed, Oct 22, 2008 at 11:03:07AM -0500, David G. Mackay wrote:
>> >
>> > On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
>> > > Unanswered:
>> > > > Is there similar outrage against upstreams as well?  Where is
> it?
>> >
>> > On this list, it's shouted down.  I commented some time ago about
> the
>> > rather toxic behavior of the python developers vis-a-vis breaking
>> > compatibility at virtually every release.  You would have thought
> that I
>> > had urinated in the holy water.
>> >
>> > It's an ugly little wart on the free software movement.  There's
> nowhere
>> > near the incentive to take care of your user base without a direct
>> > financial gain.  Not, mind you, that commercial ventures haven't
> done
>> > the same, but the consequences to them are more severe and direct.
>>
>> You don't get to dictate what the upstream project's priorities are.
>
> Dictate, no, criticize, yes.
>
>> If you don't like the fact that apps break with every new python
>> release (I don't like it either), then pick a different programming
>> language with an upstream whose priorities better align with your
>> needs. eg, Perl or Java or OCaml or any number of other languages.
>
> Well, for me, it means that I will use python for smaller projects, and
> probably java for large/persistent projects.  However, there are ripple
> effects in that people that have developed tools that I want to use in
> python, i. e. zope, are also placed in an untenable position.


>From what I understand, Python is designed to be parallel installable.
Just a tidbit of info I had come across.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From skvidal at fedoraproject.org  Wed Oct 22 22:49:01 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 22 Oct 2008 18:49:01 -0400
Subject: providing what they require
In-Reply-To: <20081023004149.8b90f588.mschwendt@gmail.com>
References: <1224713033.3304.87.camel@rosebud>
	<645d17210810221528o5820738brf20297cb81a94ee@mail.gmail.com>
	<20081023004149.8b90f588.mschwendt@gmail.com>
Message-ID: <1224715741.3304.91.camel@rosebud>

On Thu, 2008-10-23 at 00:41 +0200, Michael Schwendt wrote:
> On Wed, 22 Oct 2008 23:28:19 +0100, Jonathan Underwood wrote:
> 
> > 2008/10/22 seth vidal <skvidal at fedoraproject.org>:
> > > Here is a list of pkgs and their requirement that they also provide.
> > >
> > > http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
> > >
> > > Now, it would be handy if rpm filtered these out automagically at build
> > > time, and that's something to think about. If you notice if any of your
> > > packages do something like this manually, please stop it.
> > >
> > >
> > 
> > Um, how to stop it? - most of those Provides are automatically
> > generated by rpm. I know there is some messy instructions on how to
> > filter those for perl packages in the guidelines, but it seems more
> > widespread than perl packages...
> 
> Don't misunderstand Seth's list. The Provides are necessary and must not
> be stripped, because external packages may require them. The Requires
> in a pkg could be stripped if it's the same pkg that Provides the
> needed things.
> 
> The "thunderbird" pkg contains a "find-external-requires" script which
> does the thing that's proposed here. It ought to be rpmbuild, though,
> that does this for all pkgs.

Yes - if the pkg provides something it requires then the requires can be
removed.

A simple addition to the rpmbuild process to remove these items from the
requires wouldn't hurt.

-sv




From skvidal at fedoraproject.org  Wed Oct 22 22:49:41 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 22 Oct 2008 18:49:41 -0400
Subject: providing what they require
In-Reply-To: <80d7e4090810221508p23e6044fgd7b773436171e8a2@mail.gmail.com>
References: <1224713033.3304.87.camel@rosebud>
	<80d7e4090810221508p23e6044fgd7b773436171e8a2@mail.gmail.com>
Message-ID: <1224715781.3304.93.camel@rosebud>

On Wed, 2008-10-22 at 16:08 -0600, Stephen John Smoogen wrote:
> On Wed, Oct 22, 2008 at 4:03 PM, seth vidal <skvidal at fedoraproject.org> wrote:
> > Here is a list of pkgs and their requirement that they also provide.
> >
> > http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
> >
> > Now, it would be handy if rpm filtered these out automagically at build
> > time, and that's something to think about. If you notice if any of your
> > packages do something like this manually, please stop it.
> >
> >
> > here's the script I used to generate the output:
> >
> > http://skvidal.fedorapeople.org/misc/provides-what-they-require.py
> >
> 
> My brain no work. This means that they require themselves to
> build/install? Or something else?
> 

These pkgs have a requirement against something that they, themselves
provide.

So the requirement is unnecessary.

-sv




From jonathan.underwood at gmail.com  Wed Oct 22 22:53:46 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 22 Oct 2008 23:53:46 +0100
Subject: providing what they require
In-Reply-To: <20081023004149.8b90f588.mschwendt@gmail.com>
References: <1224713033.3304.87.camel@rosebud>
	<645d17210810221528o5820738brf20297cb81a94ee@mail.gmail.com>
	<20081023004149.8b90f588.mschwendt@gmail.com>
Message-ID: <645d17210810221553g58e459d6t86a3578e9514f3cc@mail.gmail.com>

2008/10/22 Michael Schwendt <mschwendt at gmail.com>:
> On Wed, 22 Oct 2008 23:28:19 +0100, Jonathan Underwood wrote:
>
>> 2008/10/22 seth vidal <skvidal at fedoraproject.org>:
>> > Here is a list of pkgs and their requirement that they also provide.
>> >
>> > http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
>> >
>> > Now, it would be handy if rpm filtered these out automagically at build
>> > time, and that's something to think about. If you notice if any of your
>> > packages do something like this manually, please stop it.
>> >
>> >
>>
>> Um, how to stop it? - most of those Provides are automatically
>> generated by rpm. I know there is some messy instructions on how to
>> filter those for perl packages in the guidelines, but it seems more
>> widespread than perl packages...
>
> Don't misunderstand Seth's list. The Provides are necessary and must not
> be stripped, because external packages may require them. The Requires
> in a pkg could be stripped if it's the same pkg that Provides the
> needed things.
>

Uh, yeah, I typo'd Provides - I meant Requires, of course.

> The "thunderbird" pkg contains a "find-external-requires" script which
> does the thing that's proposed here. It ought to be rpmbuild, though,
> that does this for all pkgs.

Yeah. So should we bother munging spec files for this if it's going to
be fixed in rpmbuild anyway? I guess not.



From mrsam at courier-mta.com  Wed Oct 22 23:29:01 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Wed, 22 Oct 2008 19:29:01 -0400
Subject: providing what they require
References: <1224713033.3304.87.camel@rosebud>
	<80d7e4090810221508p23e6044fgd7b773436171e8a2@mail.gmail.com>
	<1224715781.3304.93.camel@rosebud>
Message-ID: <cone.1224718141.763434.27204.500@commodore.email-scan.com>

seth vidal writes:

> On Wed, 2008-10-22 at 16:08 -0600, Stephen John Smoogen wrote:
>> On Wed, Oct 22, 2008 at 4:03 PM, seth vidal <skvidal at fedoraproject.org> wrote:
>> > Here is a list of pkgs and their requirement that they also provide.
>> >
>> > http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
>> >
>> > Now, it would be handy if rpm filtered these out automagically at build
>> > time, and that's something to think about. If you notice if any of your
>> > packages do something like this manually, please stop it.
>> >
>> >
>> > here's the script I used to generate the output:
>> >
>> > http://skvidal.fedorapeople.org/misc/provides-what-they-require.py
>> >
>> 
>> My brain no work. This means that they require themselves to
>> build/install? Or something else?
>> 
> 
> These pkgs have a requirement against something that they, themselves
> provide.
> 
> So the requirement is unnecessary.

Ummm. This is going to be any package that installs a shared library, and 
some binary that's linked against the shared library. That pretty much 
includes everything.

If this needs to be fixed, in should be fixed in rpmbuild.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/058a1bdc/attachment.sig>

From kevin.kofler at chello.at  Wed Oct 22 23:29:13 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 22 Oct 2008 23:29:13 +0000 (UTC)
Subject: Virt* , s-c-display , desktop-effects - Translation
	submission	issues!
References: <48FEF504.8030606@redhat.com>
	<20081022130711.GA10497@amd.home.annexia.org>
Message-ID: <loom.20081022T232703-444@post.gmane.org>

Richard W.M. Jones <rjones <at> redhat.com> writes:
> I think we've missed the 21st deadline for F10, but I will try to do
> these later on today anyway.

The final development freeze is only on the 28th. The translation deadline is 
intentionally one week earlier so packagers have time to rebuild their 
packages. (And worst case, a translation-only update probably also qualifies 
for a freeze exemption, you'd just have to ask rel-eng to get the package 
tagged f10-final. But if you get it in by the 28th, you don't even have to do 
that, it'll make F10 automatically.)

        Kevin Kofler



From jkeating at redhat.com  Wed Oct 22 23:43:27 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 22 Oct 2008 16:43:27 -0700
Subject: providing what they require
In-Reply-To: <cone.1224718141.763434.27204.500@commodore.email-scan.com>
References: <1224713033.3304.87.camel@rosebud>
	<80d7e4090810221508p23e6044fgd7b773436171e8a2@mail.gmail.com>
	<1224715781.3304.93.camel@rosebud>
	<cone.1224718141.763434.27204.500@commodore.email-scan.com>
Message-ID: <1224719007.3417.29.camel@luminos.localdomain>

On Wed, 2008-10-22 at 19:29 -0400, Sam Varshavchik wrote:
> If this needs to be fixed, in should be fixed in rpmbuild.

That's the idea, and what Seth was suggesting.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/8744bb75/attachment.sig>

From nathanael at gnat.ca  Thu Oct 23 00:20:51 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 22 Oct 2008 18:20:51 -0600
Subject: Window / Screen question
In-Reply-To: <48FF908E.5000906@redhat.com>
References: <48FF7660.9060807@gnat.ca>	<d25f375f0810221205xcb92741oa70a3868692a517c@mail.gmail.com>	<48FF7DAA.8060502@gnat.ca>
	<48FF908E.5000906@redhat.com>
Message-ID: <48FFC363.90409@gnat.ca>

Casey Dahlin wrote:
> Nathanael D. Noblet wrote:
>>
>>> On Wed, Oct 22, 2008 at 9:52 PM, Nathanael D. Noblet 
>>> <nathanael at gnat.ca> wrote:
>>>> Hi,
>>>>
>>>>  This isn't a fedora question specifically, however just thought I'd 
>>>> run it
>>>> by to get some feedback.
>>>>
>>>>  I've had a multi-card/multi-monitor setup for a few months now. It 
>>>> has been
>>>> a royal pain. (Only the closed drivers can handle it unfortunately). 
>>>> I was
>>>> talking to the radeon/ati driver people and have been informed that
>>>> multi-card setups don't get much love from either the driver 
>>>> developers or
>>>> upstream/xorg. So I've figured I may move from 3 monitors back to 2 
>>>> larger
>>>> (24") monitors. So after that history, here comes the idea...
>>>>
>>>>  I'm wondering if it is possible to have 'fake' monitor 
>>>> borders/dimensions.
>>>> So you instruct xorg/gnome/xinerama or whatever that the 1900 pixel 
>>>> width is
>>>> 2/3rd + 1/3rd. If I were to click maximize within either of those 
>>>> imaginary
>>>> borders, it would maximize to that size instead of the 1900 px 
>>>> width. If I
>>>> double clicked, it would then go fullscreen...
>>>>
>>>> Does this sound at all useful? Opinions / critiques...
>>
>> > Sounds like tiling windowmanagers. dwm from http://suckless.org ?
>>
>> Does gnome support this? That would be very nice.
>>
> I don't know that I agree with Nathaniel's recommendation. Tiled window 
> managers do a lot of neat things, and are worth checking out, but I 
> don't think they solve your problem specifically.

I think you mean Pavel's suggestion...?

> XRandR might be able to be coaxed into doing what you want. You also 
> might be able to get Compiz to display 3 workspaces across 2 monitors.

with configuration, or code?



-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From jspaleta at gmail.com  Thu Oct 23 01:04:26 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 22 Oct 2008 17:04:26 -0800
Subject: rawhide report: 20081018 changes
In-Reply-To: <ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
Message-ID: <604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>

On Sat, Oct 18, 2008 at 3:17 AM, Alex Lancaster
<alexl at users.sourceforge.net> wrote:
>> geos-3.0.1-1.fc10 -----------------
>> * Fri Oct 17 18:00:00 2008
>> Balint Cristian <rezso at rdsor.ro> - 3.0.1-1 - new stable bugfix - fix
>> another gcc43 header
>
> At the very least it gives people a heads-up that some things might
> break in the next rawhide.  Especially when those dependent packages
> aren't owned by you such as qgis and python-basemap:


Hey guess what the geos bump is an API change.  You quick fix of the
build script for python-basemap doesn't actually work the code checks
the geos version via a library call. So your "fix" gets basemap
building...but it will not import.  Please, please, please test
patches in runtime before merging them.

-jef"Geos moving to 3.0 at this late date is a problem for me. Not
cool. This should have come in MUCH earlier in devel cycle"spaleta



From jspaleta at gmail.com  Thu Oct 23 01:17:37 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 22 Oct 2008 17:17:37 -0800
Subject: rawhide report: 20081018 changes
In-Reply-To: <604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
Message-ID: <604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>

On Wed, Oct 22, 2008 at 5:04 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> -jef"Geos moving to 3.0 at this late date is a problem for me. Not
> cool. This should have come in MUCH earlier in devel cycle"spaleta



So yeah... not the packagers fault.... clearly upstream "fixed" their
code to report version 3.0 instead of 2.3..well after the 3.0 release.

Alex if you have the time, please hunt down and patch the runtime
version query that is keeping this from importing.  I'm not gonna be
able to get to this till the weekend it seems.

-jef



From cmadams at hiwaay.net  Thu Oct 23 01:19:37 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 22 Oct 2008 20:19:37 -0500
Subject: providing what they require
In-Reply-To: <1224713033.3304.87.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
Message-ID: <20081023011937.GA1339141@hiwaay.net>

Once upon a time, seth vidal <skvidal at fedoraproject.org> said:
> Here is a list of pkgs and their requirement that they also provide.

Okay, but what is the problem?  If you want to know what requires
libfoo.so.42 and do "rpm -q --whatrequires libfoo.so.42", why shouldn't
it include "foo-42-13.fc10.i386" in the list if some binary in package
foo is linked against libfoo.so.42?

I'm not saying it isn't mostly redundant, but I don't see what the big
deal is.  Is it causing a problem in yum depsolving or something?
-- 
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 kevin.kofler at chello.at  Thu Oct 23 01:23:13 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 23 Oct 2008 01:23:13 +0000 (UTC)
Subject: rawhide report: 20081018 changes
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
Message-ID: <loom.20081023T012222-564@post.gmane.org>

Jeff Spaleta <jspaleta <at> gmail.com> writes:
> Alex if you have the time, please hunt down and patch the runtime
> version query that is keeping this from importing.  I'm not gonna be
> able to get to this till the weekend it seems.

Well, I'm not Alex, but I can see what I can do, it looks like an easy fix to 
me. Though I don't have a Rawhide machine to test the result on.

        Kevin Kofler



From jkeating at redhat.com  Thu Oct 23 01:27:51 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 22 Oct 2008 18:27:51 -0700
Subject: rawhide report: 20081018 changes
In-Reply-To: <loom.20081023T012222-564@post.gmane.org>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	<loom.20081023T012222-564@post.gmane.org>
Message-ID: <1224725271.3417.31.camel@luminos.localdomain>

On Thu, 2008-10-23 at 01:23 +0000, Kevin Kofler wrote:
> Well, I'm not Alex, but I can see what I can do, it looks like an easy fix to 
> me. Though I don't have a Rawhide machine to test the result on.

Should be easy enough to test inside a mock chroot.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/8b6bb57a/attachment.sig>

From jspaleta at gmail.com  Thu Oct 23 01:50:37 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 22 Oct 2008 17:50:37 -0800
Subject: rawhide report: 20081018 changes
In-Reply-To: <loom.20081023T012222-564@post.gmane.org>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	<loom.20081023T012222-564@post.gmane.org>
Message-ID: <604aa7910810221850m43160d2dy9f7cae59b24aaf90@mail.gmail.com>

On Wed, Oct 22, 2008 at 5:23 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Well, I'm not Alex, but I can see what I can do, it looks like an easy fix to
> me. Though I don't have a Rawhide machine to test the result on.

I got it. I was able to pull the source here. I'll have a fix
committed tonite after testing it.

-jef



From kevin.kofler at chello.at  Thu Oct 23 01:57:36 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 23 Oct 2008 01:57:36 +0000 (UTC)
Subject: rawhide report: 20081018 changes
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	<loom.20081023T012222-564@post.gmane.org>
	<604aa7910810221850m43160d2dy9f7cae59b24aaf90@mail.gmail.com>
Message-ID: <loom.20081023T015609-568@post.gmane.org>

Jeff Spaleta <jspaleta <at> gmail.com> writes:
> I got it. I was able to pull the source here. I'll have a fix
> committed tonite after testing it.

Actually, I already committed this:
http://cvs.fedoraproject.org/viewvc/rpms/python-basemap/devel/python-basemap-0.99-geos-3.0.1-runtime-check.patch?revision=1.1&view=markup
and the build is now running. Does this look sane? (As for testing, it can be 
done once it's built, it's not like it can get much worse than not working at 
all. ;-) )

        Kevin Kofler



From mattdm at mattdm.org  Thu Oct 23 02:10:06 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 22 Oct 2008 22:10:06 -0400
Subject: Window / Screen question
In-Reply-To: <48FF7660.9060807@gnat.ca>
References: <48FF7660.9060807@gnat.ca>
Message-ID: <20081023021006.GA11612@jadzia.bu.edu>

On Wed, Oct 22, 2008 at 12:52:16PM -0600, Nathanael D. Noblet wrote:
>   I'm wondering if it is possible to have 'fake' monitor 
> borders/dimensions. So you instruct xorg/gnome/xinerama or whatever that 
> the 1900 pixel width is 2/3rd + 1/3rd. If I were to click maximize within 
> either of those imaginary borders, it would maximize to that size instead 
> of the 1900 px width. If I double clicked, it would then go fullscreen...
> Does this sound at all useful? Opinions / critiques...

XFCE has a feature almost like this in its Workspace Margins. You could tell
it to leave a 633-pixel margin at the right side of the screen, and windows
will be maximized to the area except for that. You can't double-click to go
full-screen, but you can still resize (or move) the window manually into
that area.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mattdm at mattdm.org  Thu Oct 23 02:12:30 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 22 Oct 2008 22:12:30 -0400
Subject: providing what they require
In-Reply-To: <20081023011937.GA1339141@hiwaay.net>
References: <1224713033.3304.87.camel@rosebud>
	<20081023011937.GA1339141@hiwaay.net>
Message-ID: <20081023021230.GB11612@jadzia.bu.edu>

On Wed, Oct 22, 2008 at 08:19:37PM -0500, Chris Adams wrote:
> Okay, but what is the problem?  If you want to know what requires
> libfoo.so.42 and do "rpm -q --whatrequires libfoo.so.42", why shouldn't
> it include "foo-42-13.fc10.i386" in the list if some binary in package
> foo is linked against libfoo.so.42?
> I'm not saying it isn't mostly redundant, but I don't see what the big
> deal is.  Is it causing a problem in yum depsolving or something?

I imagine it's a speed thing.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From cdahlin at redhat.com  Thu Oct 23 06:10:35 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 23 Oct 2008 02:10:35 -0400
Subject: Regarding install options
In-Reply-To: <1224686759.3417.12.camel@luminos.localdomain>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>	<1223911751.3327.15.camel@luminos.localdomain>	<20081013161316.GL3139@free.fr>	<1223916009.3327.28.camel@luminos.localdomain>	<20081013164536.GN3139@free.fr>	<1223921280.3327.34.camel@luminos.localdomain>	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>	<20081013203244.GG2738@free.fr>	<1223930747.3327.41.camel@luminos.localdomain>	<20081013221048.GL2738@free.fr>	<1223937363.3056.10.camel@luminos.localdomain>	<48FE8759.6010302@redhat.com>
	<1224686759.3417.12.camel@luminos.localdomain>
Message-ID: <4900155B.4060704@redhat.com>

Jesse Keating wrote:
> On Tue, 2008-10-21 at 21:52 -0400, Casey Dahlin wrote:
>   
>> I've spent 3 days just trying to /find/ all the crap Anaconda put on a 
>> computer that I didn't check off.
>>     
>
>
> You spend 3 days reading the install log?  Do you have reading
> comprehension problems?  I wouldn't think so given the emails and blog
> posts you produce...
>
>   
Having been around longer and now knowing what all of that is, it takes 
less time these days. Do we expect everyone who just doesn't want what 
they didn't ask for to know what libpango does? Or do we just expect 
them to try each and every package in there and see which ones do and do 
not try to take yum with them?
>>  Now, when I install Fedora on a 
>> server, I reboot and start over if I see anything that looks even 
>> remotely desktop-related. This is a broken use case.
>>  Solutions are:
>>
>> 1) Add the "dependencies have been added" screen that every other 
>> package install tool in the distro has but Anaconda insists on going 
>> without.
>>     
>
> Have you filed this RFE in bugzilla against anaconda?  Unless you make
> this an autoclosing summary you've just broken a feature that people
> have been asking for for quite a while, the ability to just walk away
> once depsolving starts.  If depsolving is successful the install should
> just start without any further interaction.  Also, fun to figure out for
> kickstarts.
>
>   
You've posed a problem and a solution.
>> 2) Have checkboxes in the package screen be tri-state. (checked if you 
>> want it, unchecked if you don't want it, red x if yum is not allowed to 
>> install it for any reason). This one's not pretty, but it'd work.
>>     
>
> And just how is yum supposed to know that it can't install it?  Where
> does that information come from, and if we have that information, why
> would we ever even display the package then?  "Here is something you
> can't click!  neener neener neeeeener!"
>
>   
All reasons it isn't pretty.

>> 3) Provide a default install. 
>>     
>
> We have one, it's what happens if you go next next next.  It's defined
> in comps by the groups that are marked as default and the packages
> therein that are defined as mandatory and default.  It's also what you
> get in kickstarts if you do %packages --default.
>
>   
I meant "minimal" instead of "default." Typo

>> Believe me, I won't agree with what you 
>> put in it at all. I will, however, be happier than I am now.
>>     
>
> Then be happy.
>
>   
>> 4) Document the procedure a few emails up on how to install just @core 
>> or @core + @base . I didn't even know the system would run right if you 
>> unchecked everything.
>>     
>
> It all depends on your definition of "run".  It'll boot.  Does one
> really need to document the process of unchecking boxes?  (or checking
> the Base group box)
>
>   
None of this is apparent to a user who doesn't know about Fedora. Again, 
the line here is not just technical and non-technical. Will the Debian 
administrator who is trying out Fedora think of this procedure the first 
time out? Likely he'll try to select all the packages he wants and end 
up getting a hundred things he didn't. Install nothing and add later is 
not the first instinct of the user.
>> Spending a little energy and not pleasing everyone is a lot better than 
>> spending no energy and epic failing.
>>     
>
> You have an epic ability to blow things out of proportion.  Maybe if you
> looked at the anaconda source, or comps, and provided patches for what
> you'd like to see, not only would it be helpful, but you'd also have
> more code to rant about in your blogs!
>
>   
Oh, were those /your/ cheerios I was pissing in?

--CJD



From ville.skytta at iki.fi  Thu Oct 23 06:44:52 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 23 Oct 2008 09:44:52 +0300
Subject: providing what they require
In-Reply-To: <1224715741.3304.91.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
Message-ID: <200810230944.53271.ville.skytta@iki.fi>

On Thursday 23 October 2008, seth vidal wrote:

> Yes - if the pkg provides something it requires then the requires can be
> removed.
>
> A simple addition to the rpmbuild process to remove these items from the
> requires wouldn't hurt.

When I suggested this on rpm-maint a little over a year ago, there were some 
objections because that would render rpm's --filerequire less useful/correct 
than it is today.  Maybe it wasn't implemented because of that or just 
because of lack of manpower at the time.

http://lists.rpm.org/pipermail/rpm-maint/2007-July/001578.html

The objection is valid per se, --filerequire would suffer (but not become 
entirely useless).  I wouldn't personally mind inflicting some inaccuracy 
into it if the gains are large enough.  I got a 7.3% decrease estimate in 
overall number of dependencies in Fedora which should be order-of-magnitude 
correct (see above post for more details).

But if this can't be done in rpm(build), it probably can in createrepo as I 
don't think something like --filerequire is (or even can be) implemented in 
any tools using the metadata.



From alexl at users.sourceforge.net  Thu Oct 23 08:17:52 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Thu, 23 Oct 2008 01:17:52 -0700
Subject: Make announcing soname bumps mandatory (was Re: rawhide report:
	20081018 changes)
In-Reply-To: <604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	(Jeff Spaleta's message of "Wed\, 22 Oct 2008 17\:17\:37 -0800")
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
Message-ID: <b11vy7endb.fsf_-_@allele2.eebweb.arizona.edu>

>>>>> "JS" == Jeff Spaleta  writes:

JS> On Wed, Oct 22, 2008 at 5:04 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:

>> -jef"Geos moving to 3.0 at this late date is a problem for me. Not
>> cool. This should have come in MUCH earlier in devel cycle"spaleta

Yes, indeed bumping to 3.0 so late is not a good idea, nevertheless it
shouldn't be forbidden.  What should be forbidden is not announcing it
beforehand.  This is why I specifically reminded Balint to, at the
very least, announce it here on fedora-devel-list as per policy:

https://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#When_breaking_Application_binary_interface

I think that the above policy should be made mandatory rather than
"nice to" (unless you happen to be building all affected package
yourself in which case an e-mail is superfluous).  At the very least
it would get maintainers in the habit of running repoquery more
regularly and so they would get a better sense of what other packages
depended on their package (many maintainers seem unaware of this).
Ideally this would be automated and provided in regular reports, or
somehow incorporated into PackageDB.

Unfortunately this bumping the sonames without notifying the list
and/or without co-ordinating with other package maintainers keeps
cropping up and the evolution maintainers are particularly guilty of
this.  I don't think that the rebuild of evolution/e-d-s was announced
here either and it has caused more breakage in rawhide 20081022:

Broken deps for i386
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.i386 requires libcamel-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.i386 requires libcamel-provider-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.i386 requires libcamel-1.2.so.13
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-provider-1.2.so.13
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-1.2.so.13


JS> So yeah... not the packagers fault.... clearly upstream "fixed"
JS> their code to report version 3.0 instead of 2.3..well after the
JS> 3.0 release.

I just wanted to fix the broken deps with the most minimal packaging
fix, because without it building it wouldn't even be installable.

JS> Alex if you have the time, please hunt down and patch the runtime
JS> version query that is keeping this from importing.  I'm not gonna
JS> be able to get to this till the weekend it seems.

Looks like Kevin beat me to it...

Alex



From dwmw2 at infradead.org  Thu Oct 23 08:30:57 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Oct 2008 09:30:57 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081022184638.GB3089@free.fr>
References: <16de708d0810211045o1ec35ac8h188b648c1341eb20@mail.gmail.com>
	<48FE2BBD.2030802@gmail.com> <gdn7of$v73$1@ger.gmane.org>
	<48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
	<20081022163011.GF3425@free.fr> <gdnmkh$rmb$2@ger.gmane.org>
	<1224696311.4856.63.camel@macbook.infradead.org>
	<20081022184638.GB3089@free.fr>
Message-ID: <1224750657.4856.118.camel@macbook.infradead.org>

On Wed, 2008-10-22 at 20:46 +0200, Patrice Dumas wrote:
> On Wed, Oct 22, 2008 at 06:25:11PM +0100, David Woodhouse wrote:
> > 
> > Of _course_ it's not about specific cases. That would require actual
> > substantiated facts which can be verified or disproved; not just
> > handwaving and ranting.
> 
> I answered to Rex giving a specific case, regarding ConsoleKit and
> various dm breakage. You want the bugzilla entries or you trust me?

/me looks back...

On Wed, 2008-10-22 at 15:06 +0200, Patrice Dumas wrote:
> It is not that simple. The distinction between fedora and upstream in
> many cases is rather fuzzy. For example the hal/dbus/consoleKit/*Kit is
> put in fedora when it is at early development stages, and many of the
> developpers involved in these are also involved in fedora. And the
> changes are pushed in fedora without taking seriously the backward
> compatibility issues. For example wdm and xdm (and slim) are broken
> since consolekit replaced pam_console, and although there is a rather
> simple solution to integrate those dm it has never been planned and it
> is still not fixed, though a fix exist for months. As long as it worked
> in gdm it was fine for fedora. You can tell, hey, xdm, wdm and slim can
> copy what gdm does, but when the solution implemented in gdm is specific
> and not consistent with the previous designs, it is not so easy. Fedora
> controls some upstream so can do anything in these, but doesn't control
> all of them.

Yeah, that sucks. We should do better than that.

Although I've always been a little dubious about our 'Feature Process',
it does seem that it addresses this kind of problem. For the feature to
reach 100% completion, it should obviously involve fixes for the other
display managers. And there is a 'reversion plan' in case we don't
manage to complete the feature in time for the release. 

>From what you say above, it sounds like the ConsoleKit feature should be
declared incomplete, and we should be reverting it unless the feature
owners finish the job.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pertusus at free.fr  Thu Oct 23 09:20:26 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 23 Oct 2008 11:20:26 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224750657.4856.118.camel@macbook.infradead.org>
References: <gdn7of$v73$1@ger.gmane.org> <48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
	<20081022163011.GF3425@free.fr> <gdnmkh$rmb$2@ger.gmane.org>
	<1224696311.4856.63.camel@macbook.infradead.org>
	<20081022184638.GB3089@free.fr>
	<1224750657.4856.118.camel@macbook.infradead.org>
Message-ID: <20081023092026.GA3108@free.fr>

On Thu, Oct 23, 2008 at 09:30:57AM +0100, David Woodhouse wrote:
> 
> Yeah, that sucks. We should do better than that.
> 
> Although I've always been a little dubious about our 'Feature Process',
> it does seem that it addresses this kind of problem. For the feature to
> reach 100% completion, it should obviously involve fixes for the other
> display managers. And there is a 'reversion plan' in case we don't
> manage to complete the feature in time for the release. 

Here, simply keeping up using pam_console would have worked. But lead to
much less testing of fast user switching. The whole story can be tracked
down from this bug, from 2007-02-09:
https://bugzilla.redhat.com/show_bug.cgi?id=228110

Later a pam module was added for login. And even later a solution has
been found for dm, building on what was done for xinit, that plays 
well with wdm/xdm/slim, though it is still not applied:
https://bugzilla.redhat.com/show_bug.cgi?id=452156

>From my point of view, this comment (certainly biased, it is a comment
from me) summary the situation, and it is really a fedora issue,
not only an upstream issue:
https://bugzilla.redhat.com/show_bug.cgi?id=452156#c15

> From what you say above, it sounds like the ConsoleKit feature should be
> declared incomplete, and we should be reverting it unless the feature
> owners finish the job.

If this is the case, then we would only have had ConsoleKit in F-11...

At the time the issue happened, there was no feature process, but I
can't see how it would have changed anything. A feature process cannot
prevent lack of planning, focus on gnome, lack of integration with
existing frameworks and lack of consideration for alternative setups, if
this attitude is endorsed by the project on a whole, which is the case
for fedora, see for example
https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
and look at all the conversations on this mailing list or fesco
decisions.

A FESCo vote (at least of today FESCo) would certainly be to let the
minor dm be broken (hopefully they will be fixed for the RHEL release),
so even if a Feature was not considered finished I doubt the changes
would have been reversed. Once again, I don't think that such an
attitude is fundamentaly problematic, this allowed to have much more
testing for gdm, kdm and fast user switching, which is good. But this is
also, in my opinion, a good example of what fedora really is, and my
personnal point of view is that it is becoming even more so.

As a side note I thought that having more packages, and packages that
are not mainstream, with the corresponding packagers being part of the
community would lead to a push to another direction, but for
good or bad, this didn't happened -- and I think that in the fedora
community, those, like me, not in complete agreement with the 
'mainstream' fedora (more testing than planning, innovation breaking 
old frameworks, focus on major desktop components) are, in my opinion,
getting less and less consideration. The corresponding packages are 
simply broken intermitently, always on the struggle to catch up with 
the constant changes.

--
Pat



From mschwendt at gmail.com  Thu Oct 23 10:24:16 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 23 Oct 2008 12:24:16 +0200
Subject: pguiman has no maintainer
In-Reply-To: <20080828215641.03e13d63.mschwendt@gmail.com>
References: <20080828215641.03e13d63.mschwendt@gmail.com>
Message-ID: <20081023122416.31f14c62.mschwendt@gmail.com>

On Thu, 28 Aug 2008 21:56:41 +0200, Michael Schwendt wrote:

> https://admin.fedoraproject.org/pkgdb/packages/name/pguiman
> 
> Maintainer "odvorace" gives "user unknown" at Red Hat.
> Pkg ACLs are locked down.

Who takes care of issues like this?
Is it necessary to follow the lengthy AWOL procedure?
https://bugzilla.redhat.com/468160



From rawhide at fedoraproject.org  Thu Oct 23 11:16:06 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 23 Oct 2008 11:16:06 +0000 (UTC)
Subject: rawhide report: 20081023 changes
Message-ID: <20081023111607.037A91B8001@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct 23 06:01:10 UTC 2008

New package e16-keyedit
        GUI for editing keybindings in Enlightenment, DR16
New package logstalgia
        Web server access log visualizer
New package remoot
        ReMoot is a remote control wrapper
New package tcl-tcludp
        Tcl extension for UDP support
New package tcl-tclvfs
        Tcl extension for Virtual Filesystem support
New package tcl-tileqt
        QT widget support for Tile Toolkit
Updated Packages:

akonadi-1.0.0-4.fc10
--------------------
* Wed Oct 22 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.0.0-4
- drop Requires: mysql-server (for now), mention in %description


amsn-0.97-4.fc10
----------------
* Wed Oct 22 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> - 0.97-4
- Patch the webcam part to use libv4l so that it will work with the new gspca
  driver in F-10


Broken deps for i386
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.i386 requires libcamel-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.i386 requires libcamel-provider-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.i386 requires libcamel-1.2.so.13
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	kvm-74-5.fc10.i386 requires etherboot-roms-kvm
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-provider-1.2.so.13
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-1.2.so.13
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.i386 requires libcamel-1.2.so.13
	evolution-brutus-1.2.27-1.fc10.x86_64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.x86_64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.x86_64 requires libcamel-provider-1.2.so.13()(64bit)
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.x86_64 requires iml = 0:1.0.2-3.fc10
	kvm-74-5.fc10.x86_64 requires etherboot-roms-kvm
	planner-eds-0.14.3-5.fc10.x86_64 requires libcamel-1.2.so.13()(64bit)
	planner-eds-0.14.3-5.fc10.x86_64 requires libcamel-provider-1.2.so.13()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.ppc requires libcamel-1.2.so.13
	evolution-brutus-1.2.27-1.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.ppc requires libcamel-provider-1.2.so.13
	evolution-zimbra-0.1.1-2.fc10.ppc requires libcamel-1.2.so.13
	iml-devel-1.0.2-3.fc10.ppc requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	planner-eds-0.14.3-5.fc10.ppc requires libcamel-provider-1.2.so.13
	planner-eds-0.14.3-5.fc10.ppc requires libcamel-1.2.so.13
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	evolution-brutus-1.2.27-1.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	evolution-zimbra-0.1.1-2.fc10.ppc64 requires libcamel-provider-1.2.so.13()(64bit)
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	planner-eds-0.14.3-5.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	planner-eds-0.14.3-5.fc10.ppc64 requires libcamel-provider-1.2.so.13()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)





From dwmw2 at infradead.org  Thu Oct 23 11:38:20 2008
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Oct 2008 12:38:20 +0100
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <20081023092026.GA3108@free.fr>
References: <gdn7of$v73$1@ger.gmane.org> <48FF279C.2000501@gmail.com>
	<1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
	<20081022163011.GF3425@free.fr> <gdnmkh$rmb$2@ger.gmane.org>
	<1224696311.4856.63.camel@macbook.infradead.org>
	<20081022184638.GB3089@free.fr>
	<1224750657.4856.118.camel@macbook.infradead.org>
	<20081023092026.GA3108@free.fr>
Message-ID: <1224761900.4856.156.camel@macbook.infradead.org>

On Thu, 2008-10-23 at 11:20 +0200, Patrice Dumas wrote:
> > From what you say above, it sounds like the ConsoleKit feature should be
> > declared incomplete, and we should be reverting it unless the feature
> > owners finish the job.
> 
> If this is the case, then we would only have had ConsoleKit in F-11...
> 
> At the time the issue happened, there was no feature process, but I
> can't see how it would have changed anything. A feature process cannot
> prevent lack of planning, focus on gnome, lack of integration with
> existing frameworks and lack of consideration for alternative setups,

I think that's a fundamental part of what the feature process _should_
be doing. The whole point of the feature process, as I see it, is about
precisely the _planning_ you say we lack. Otherwise, we're just be
throwing new stuff in willy-nilly and just writing it up in the release
notes after the fact.

In this case, there seems to have been a disagreement about _how_ the
other display managers should be fixed. Regardless of that, I think it's
clear that they _SHOULD_ have been fixed...

>  if this attitude is endorsed by the project on a whole, which is the case
> for fedora, see for example
> https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
> and look at all the conversations on this mailing list or fesco
> decisions.

... but I also think Jeremy was right in the above-mentioned #c19, where
he dropped the bug status to 'tracker'. That's 'SHOULD', not 'MUST'.

> A FESCo vote (at least of today FESCo) would certainly be to let the
> minor dm be broken 

Maybe. I, for one, would vote against it -- I'd expect those responsible
for the PackageKit 'feature' to fix it _somehow_, rather than just
leaving it broken. Even if there is some argument that the fix could be
done a better way.
 
> (hopefully they will be fixed for the RHEL release),

I hope that's not an issue for FESCo members -- although it _should_ be
a factor in the decision-making process of @redhat.com folks working on
stuff. "We're going to have to do the sensible thing in RHEL in the end
anyway; let's do it right away and not screw Fedora over".

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pertusus at free.fr  Thu Oct 23 12:20:34 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 23 Oct 2008 14:20:34 +0200
Subject: [Fwd: Wikipidia - Goodbye Red Hat and Fedora]
In-Reply-To: <1224761900.4856.156.camel@macbook.infradead.org>
References: <1224682689.4856.31.camel@macbook.infradead.org>
	<48FF3160.7060207@gmail.com>
	<1224686528.4856.50.camel@macbook.infradead.org>
	<20081022163011.GF3425@free.fr> <gdnmkh$rmb$2@ger.gmane.org>
	<1224696311.4856.63.camel@macbook.infradead.org>
	<20081022184638.GB3089@free.fr>
	<1224750657.4856.118.camel@macbook.infradead.org>
	<20081023092026.GA3108@free.fr>
	<1224761900.4856.156.camel@macbook.infradead.org>
Message-ID: <20081023122034.GA2980@free.fr>

On Thu, Oct 23, 2008 at 12:38:20PM +0100, David Woodhouse wrote:
> 
> I think that's a fundamental part of what the feature process _should_
> be doing. The whole point of the feature process, as I see it, is about
> precisely the _planning_ you say we lack. Otherwise, we're just be

This is partly that kind of planning, but the planning I am referring to
is more about upstream planning integration within the existing
frameworks.

In this precise case, there was a single point of control, the bug
report, and there was some kind of planning regarding the inclusion in
fedora.

But in any case, most of the changes don't fall under the feature
process, because they are upstream changes, so I can't see how this
could be controlled in Fedora, if the package maintainers are not
willing to be controlled.

> throwing new stuff in willy-nilly and just writing it up in the release
> notes after the fact.
> 
> In this case, there seems to have been a disagreement about _how_ the
> other display managers should be fixed. Regardless of that, I think it's
> clear that they _SHOULD_ have been fixed...

That's not obvious to me that the main issue is how this should have
been fixed in fedora. ConsoleKit could also have been planned from 
the beginning with a consideration to how dm worked, for pam support, and
with a proposal for dm maintainers (or the packagers in fedora) for an
implementation. Instead we were pointed to a gdm patch after the fact.

> >  if this attitude is endorsed by the project on a whole, which is the case
> > for fedora, see for example
> > https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
> > and look at all the conversations on this mailing list or fesco
> > decisions.
> 
> ... but I also think Jeremy was right in the above-mentioned #c19, where
> he dropped the bug status to 'tracker'. That's 'SHOULD', not 'MUST'.

Note that I didn't said that he was wrong.

> > A FESCo vote (at least of today FESCo) would certainly be to let the
> > minor dm be broken 
> 
> Maybe. I, for one, would vote against it -- I'd expect those responsible
> for the PackageKit 'feature' to fix it _somehow_, rather than just
> leaving it broken. Even if there is some argument that the fix could be
> done a better way.

But this is not that easy, especially in that case. I think that the kdm
patch, although functional is not right, because it hardcodes the
device path. As a package maintainer I would have preferred a broken wdm
rather than this patch. And I talked with the xdm upstream maintainer
and he was not going to accept such patch either.

That being said, I agree that people bringing forward the feature could
have been of more help and should have taken more attention to the help
I was asking for and the stuff I proposed. But they seem to be very
busy, so it is not easy.

> > (hopefully they will be fixed for the RHEL release),
> 
> I hope that's not an issue for FESCo members -- although it _should_ be
> a factor in the decision-making process of @redhat.com folks working on
> stuff. "We're going to have to do the sensible thing in RHEL in the end
> anyway; let's do it right away and not screw Fedora over".

I think that many people in the fedora community, especially @RH people
and people in the board prefer a fast moving fedora, even if some 
packages considered of less importance (like xdm) are screwed, 
that give some testing for RHEL rather than a careful avoidance of 
regressions. This is not the same thing, but quite consistent with 
the opposition toward leaving infra open after EOL, with the argument 
being 'Fedora is fast moving and RHEL/EPEL is stable, choose one of 
the two, another way is chimeric'. I don't want to start a flamewar
about RH hidden agendas and so on and so forth, it is just how I
personnally feel. And to repeat myself once again this may be a very
good path, though it is certainly not the one I would have followed if
I was in the position of deciding.

I also think in the today's fedora community, be it from @RH or not,
(except from some reactionary people like me who come from a past 
fedora and still haven't given up) there are a lot of people who 
want something fast moving even if some packages considered of 
less importance are screwed, without any reference to RHEL, but 
because they are enthousiast desktop people, the way fedora is 
fast moving suit them.

--
Pat



From pertusus at free.fr  Thu Oct 23 12:22:40 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 23 Oct 2008 14:22:40 +0200
Subject: pguiman has no maintainer
In-Reply-To: <20081023122416.31f14c62.mschwendt@gmail.com>
References: <20080828215641.03e13d63.mschwendt@gmail.com>
	<20081023122416.31f14c62.mschwendt@gmail.com>
Message-ID: <20081023122240.GB2980@free.fr>

On Thu, Oct 23, 2008 at 12:24:16PM +0200, Michael Schwendt wrote:
> On Thu, 28 Aug 2008 21:56:41 +0200, Michael Schwendt wrote:
> 
> > https://admin.fedoraproject.org/pkgdb/packages/name/pguiman
> > 
> > Maintainer "odvorace" gives "user unknown" at Red Hat.
> > Pkg ACLs are locked down.
> 
> Who takes care of issues like this?
> Is it necessary to follow the lengthy AWOL procedure?
> https://bugzilla.redhat.com/468160

If the mail of the user is not known anymore first steps can be skipped.

--
Pat



From martin.marques at gmail.com  Thu Oct 23 13:41:46 2008
From: martin.marques at gmail.com (=?UTF-8?Q?Mart=C3=ADn_Marqu=C3=A9s?=)
Date: Thu, 23 Oct 2008 11:41:46 -0200
Subject: dependencies between {swfdec-mozilla,
	gnash-plugin} and nspluginwrapper
Message-ID: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>

Yesterday I started to finish configuring some things that were left
behind on my new laptop (amd64), and bumpped up with flash support for
firefox.

The thing is that swfdec didn't work, and gnash neither.

Solution: remove nspluginwrapper.

So I wanted to ask before opening a bug report: shouldn't there be a
dependency on all 3 packages (don't know about others) so that you can
only have one of the 3 packages (al least the plugins:
nspluginwrapper, swfdec-mozilla, gnash-plugin) installed?

-- 
Mart?n Marqu?s
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador



From tcallawa at redhat.com  Thu Oct 23 13:55:08 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 23 Oct 2008 09:55:08 -0400
Subject: R-devel going away
Message-ID: <1224770108.3601.40.camel@localhost.localdomain>

This email serves as an announcement that I plan to swallow up R-devel
into the base R package. Why?

* It is causing no end of user complaints. The typical R user expects to
be able to do a "CPAN" (really, I should say "CRAN") style package
install through the R interface:

install.packages("RSQLite")

This doesn't work unless you have R-devel installed. The average R user
is a professor or a student, and neither of them are going to
necessarily possess the necessary Linux/Fedora knowledge to be able to
understand why this doesn't work like the R documentation says it
should. 

* The size of the R-devel is tiny, about 440K installed. It will not
bloat the main package to absorb the .h files and a .pc file into the
main package. There are no libraries in the R-devel package.

* The primary users of R-devel are R addon packages. They can continue
to BuildRequires: R-devel safely (hooray for Provides/Requires).

* libRmath (the R shared library) will still be a separate package.
libRmath-devel will still be a separate package. As far as I know,
nothing in Fedora uses libRmath, nor is libRmath-devel necessary for
building R addons.

Now, I recognize that this is a violation of the Fedora Packaging
Guidelines, and I've given a lot of thought to this over the last few
days, and technically, this is a reversal of my earlier stance (which is
to stick to the guidelines). However, I think this is a key
functionality that Fedora R users expect to just work, and I want to try
to make sure that they get the best R experience out of the box that
they can. 

As Martyn Plummer pointed out:

   There are currently 1533 packages/bundles on CRAN, not counting the
   recommended packages that are already distributed with R. Of these
   packages, 420 require to the R headers. Fedora only supplies RPMs for
9
   of them.

I'm not entirely sure if I need FESCo or FPC approval to take this
action, if so, this is my notice of requesting it. ;)

I'm also looking for feedback and comments, of course. 

Thanks,

~spot (Fedora R maintainer)



From notting at redhat.com  Thu Oct 23 14:13:27 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 23 Oct 2008 10:13:27 -0400
Subject: providing what they require
In-Reply-To: <1224713033.3304.87.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
Message-ID: <20081023141327.GB4912@nostromo.devel.redhat.com>

seth vidal (skvidal at fedoraproject.org) said: 
> Here is a list of pkgs and their requirement that they also provide.
> 
> http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
> 
> Now, it would be handy if rpm filtered these out automagically at build
> time, and that's something to think about. If you notice if any of your
> packages do something like this manually, please stop it.

Stop doing manual filtering of the requires? This was needed in the
past when we had multiple apps with their own xulrunner copies, to
avoid brokenness on upgrade.

Bill



From skvidal at fedoraproject.org  Thu Oct 23 14:16:17 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 23 Oct 2008 10:16:17 -0400
Subject: providing what they require
In-Reply-To: <20081023141327.GB4912@nostromo.devel.redhat.com>
References: <1224713033.3304.87.camel@rosebud>
	<20081023141327.GB4912@nostromo.devel.redhat.com>
Message-ID: <1224771377.9694.6.camel@rosebud>

On Thu, 2008-10-23 at 10:13 -0400, Bill Nottingham wrote:
> seth vidal (skvidal at fedoraproject.org) said: 
> > Here is a list of pkgs and their requirement that they also provide.
> > 
> > http://skvidal.fedorapeople.org/misc/provides-what-required-rawhide.txt
> > 
> > Now, it would be handy if rpm filtered these out automagically at build
> > time, and that's something to think about. If you notice if any of your
> > packages do something like this manually, please stop it.
> 
> Stop doing manual filtering of the requires? This was needed in the
> past when we had multiple apps with their own xulrunner copies, to
> avoid brokenness on upgrade.

No, I meant if you added an explicit require for an item that the
package provides. Stop that.

-sv





From rdieter at math.unl.edu  Thu Oct 23 14:19:29 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 23 Oct 2008 09:19:29 -0500
Subject: dependencies between {swfdec-mozilla,
	gnash-plugin} and nspluginwrapper
References: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
Message-ID: <gdq15h$ehi$1@ger.gmane.org>

Mart?n Marqu?s wrote:

> Yesterday I started to finish configuring some things that were left
> behind on my new laptop (amd64), and bumpped up with flash support for
> firefox.
> 
> The thing is that swfdec didn't work, and gnash neither.
> 
> Solution: remove nspluginwrapper.

nspluginwrapper has meachanism to id items not to wrap
(see /etc/sysconfig/nspluginwrapper), which is likely the better short-term
fix here.  Long term, investigate the buggy interaction between those and
nspluginwrapper.

-- Rex



From notting at redhat.com  Thu Oct 23 14:20:31 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 23 Oct 2008 10:20:31 -0400
Subject: dependencies between {swfdec-mozilla, gnash-plugin} and
	nspluginwrapper
In-Reply-To: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
References: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
Message-ID: <20081023142031.GD4912@nostromo.devel.redhat.com>

Mart?n Marqu?s (martin.marques at gmail.com) said: 
> Yesterday I started to finish configuring some things that were left
> behind on my new laptop (amd64), and bumpped up with flash support for
> firefox.
> 
> The thing is that swfdec didn't work, and gnash neither.
> 
> Solution: remove nspluginwrapper.
> 
> So I wanted to ask before opening a bug report: shouldn't there be a
> dependency on all 3 packages (don't know about others) so that you can
> only have one of the 3 packages (al least the plugins:
> nspluginwrapper, swfdec-mozilla, gnash-plugin) installed?

nspluginwrapper doesn't actually provide any media handling, so it's
not something that really can be 'Required' on the same level.

Furthermore, given that you'd want nspluginwrapper for other things
while simultaneously using swfdec, or gnash, or whatever else, you
really want to get to the bottom of why it doesn't work with them,
and fix it.

Bill



From pertusus at free.fr  Thu Oct 23 14:21:33 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 23 Oct 2008 16:21:33 +0200
Subject: dependencies between {swfdec-mozilla, gnash-plugin} and
	nspluginwrapper
In-Reply-To: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
References: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
Message-ID: <20081023142133.GE2980@free.fr>

On Thu, Oct 23, 2008 at 11:41:46AM -0200, Mart?n Marqu?s wrote:
> Yesterday I started to finish configuring some things that were left
> behind on my new laptop (amd64), and bumpped up with flash support for
> firefox.
> 
> The thing is that swfdec didn't work, and gnash neither.
> 
> Solution: remove nspluginwrapper.
> 
> So I wanted to ask before opening a bug report: shouldn't there be a
> dependency on all 3 packages (don't know about others) so that you can
> only have one of the 3 packages (al least the plugins:
> nspluginwrapper, swfdec-mozilla, gnash-plugin) installed?

I don't know about nspluginwrapper, but swfdec and gnash should cohabit.
Only one will be active in the browser, but I don't think that a
Conflict is useful, nor warranted between gnash and swfdec.

I'll try to have a look at what happens with nspluginwrapper.

--
Pat



From mattdm at mattdm.org  Thu Oct 23 14:21:47 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 23 Oct 2008 10:21:47 -0400
Subject: Regarding install options
In-Reply-To: <4900155B.4060704@redhat.com>
References: <1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
	<48FE8759.6010302@redhat.com>
	<1224686759.3417.12.camel@luminos.localdomain>
	<4900155B.4060704@redhat.com>
Message-ID: <20081023142147.GA19911@jadzia.bu.edu>

On Thu, Oct 23, 2008 at 02:10:35AM -0400, Casey Dahlin wrote:
> Having been around longer and now knowing what all of that is, it takes 
> less time these days. Do we expect everyone who just doesn't want what they 
> didn't ask for to know what libpango does? Or do we just expect them to try 
> each and every package in there and see which ones do and do not try to 
> take yum with them?

yum-protect-packages plugin will help there. :)

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mattdm at mattdm.org  Thu Oct 23 14:27:50 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 23 Oct 2008 10:27:50 -0400
Subject: R-devel going away
In-Reply-To: <1224770108.3601.40.camel@localhost.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>
Message-ID: <20081023142750.GA20579@jadzia.bu.edu>

On Thu, Oct 23, 2008 at 09:55:08AM -0400, Tom spot Callaway wrote:
> * It is causing no end of user complaints. The typical R user expects to
> be able to do a "CPAN" (really, I should say "CRAN") style package
> install through the R interface:
> install.packages("RSQLite")
> This doesn't work unless you have R-devel installed. The average R user
> is a professor or a student, and neither of them are going to
> necessarily possess the necessary Linux/Fedora knowledge to be able to
> understand why this doesn't work like the R documentation says it
> should. 

Where do R packages installed this way go? I'd rather have people say "hey,
we're missing an R package" and then have that packaged up for Fedora, so we
can then later do a consistant install via kickstart. (Like perl modules,
they're generally relatively easy to package.)

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From pingou at pingoured.fr  Thu Oct 23 14:30:48 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 23 Oct 2008 16:30:48 +0200
Subject: R-devel going away
In-Reply-To: <20081023142750.GA20579@jadzia.bu.edu>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<20081023142750.GA20579@jadzia.bu.edu>
Message-ID: <49008A98.1010204@pingoured.fr>

Matthew Miller wrote:
> On Thu, Oct 23, 2008 at 09:55:08AM -0400, Tom spot Callaway wrote:
>> * It is causing no end of user complaints. The typical R user expects to
>> be able to do a "CPAN" (really, I should say "CRAN") style package
>> install through the R interface:
>> install.packages("RSQLite")
>> This doesn't work unless you have R-devel installed. The average R user
>> is a professor or a student, and neither of them are going to
>> necessarily possess the necessary Linux/Fedora knowledge to be able to
>> understand why this doesn't work like the R documentation says it
>> should. 
> 
> Where do R packages installed this way go? I'd rather have people say "hey,
> we're missing an R package" and then have that packaged up for Fedora, so we
> can then later do a consistant install via kickstart. (Like perl modules,
> they're generally relatively easy to package.)
> 
Would the lake of packager be a suffisant answer ?

FYI:
http://rpms.famillecollet.com/rpmphp/rpm.php?type=R

Regards,

Pierre




From enrico.scholz at informatik.tu-chemnitz.de  Thu Oct 23 14:34:35 2008
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Thu, 23 Oct 2008 16:34:35 +0200
Subject: R-devel going away
In-Reply-To: <1224770108.3601.40.camel@localhost.localdomain> (Tom Callaway's
	message of "Thu, 23 Oct 2008 09:55:08 -0400")
References: <1224770108.3601.40.camel@localhost.localdomain>
Message-ID: <87mygvcrd0.fsf@fc5.bigo.ensc.de>

"Tom \"spot\" Callaway"
<tcallawa-H+wXaHxf7aLQT0dZR+AlfA at public.gmane.org> writes:

> This email serves as an announcement that I plan to swallow up R-devel
> into the base R package. Why?

Better solutions:

* add it to comps.xml
* move 'R' to R-core, and add 'R' which depends on 'R-core' + 'R-devel'


> * The size of the R-devel is tiny, about 440K installed.

You miss its dependencies:

bzip2-devel
gcc-c++
gcc-gfortran
libICE-devel
libSM-devel
libX11-devel
libXmu-devel
libXt-devel
libjpeg-devel
libpng-devel
ncurses-devel
pkgconfig
readline-devel
tcl-devel
tetex-latex
texinfo
tk-devel



Enrico



From tibbs at math.uh.edu  Thu Oct 23 14:34:56 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 23 Oct 2008 09:34:56 -0500
Subject: R-devel going away
In-Reply-To: <20081023142750.GA20579@jadzia.bu.edu>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<20081023142750.GA20579@jadzia.bu.edu>
Message-ID: <ufaej27fkhb.fsf@epithumia.math.uh.edu>

>>>>> "MM" == Matthew Miller <mattdm at mattdm.org> writes:

MM> Where do R packages installed this way go?

Into the installing user's home directory.

Honestly I don't mind either way; as an admin, I know that R-devel
needs to be installed for users to get full functionality.  But I also
know that a C compiler needs to be installed, and so forth, and I
don't think that gcc should necessarily be in R's dependency chain.

 - J<



From tcallawa at redhat.com  Thu Oct 23 14:42:19 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 23 Oct 2008 10:42:19 -0400
Subject: R-devel going away
In-Reply-To: <87mygvcrd0.fsf@fc5.bigo.ensc.de>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<87mygvcrd0.fsf@fc5.bigo.ensc.de>
Message-ID: <1224772939.3601.54.camel@localhost.localdomain>

On Thu, 2008-10-23 at 16:34 +0200, Enrico Scholz wrote:
> Better solutions:
> 
> * add it to comps.xml
> * move 'R' to R-core, and add 'R' which depends on 'R-core' +
> 'R-devel'
> 
> 
> > * The size of the R-devel is tiny, about 440K installed.
> 
> You miss its dependencies:
> 
> bzip2-devel
> gcc-c++
> gcc-gfortran
> libICE-devel
> libSM-devel
> libX11-devel
> libXmu-devel
> libXt-devel
> libjpeg-devel
> libpng-devel
> ncurses-devel
> pkgconfig
> readline-devel
> tcl-devel
> tetex-latex
> texinfo
> tk-devel

These are very good points, thanks Enrico. What would people think about
doing the suggested R/R-core/R-devel split instead? Users would still be
able to get everything with yum install R, it would meet the guidelines,
and minimal installs with R can simply have R-core.

~spot



From pingou at pingoured.fr  Thu Oct 23 14:46:09 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 23 Oct 2008 16:46:09 +0200
Subject: R-devel going away
In-Reply-To: <1224772939.3601.54.camel@localhost.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>	<87mygvcrd0.fsf@fc5.bigo.ensc.de>
	<1224772939.3601.54.camel@localhost.localdomain>
Message-ID: <49008E31.7050204@pingoured.fr>

Tom "spot" Callaway wrote:
> These are very good points, thanks Enrico. What would people think about
> doing the suggested R/R-core/R-devel split instead? Users would still be
> able to get everything with yum install R, it would meet the guidelines,
> and minimal installs with R can simply have R-core.

Sounds like a good idea to me :)


Pierre
~ pingou



From j.w.r.degoede at hhs.nl  Thu Oct 23 14:50:19 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 23 Oct 2008 16:50:19 +0200
Subject: R-devel going away
In-Reply-To: <1224772939.3601.54.camel@localhost.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>	<87mygvcrd0.fsf@fc5.bigo.ensc.de>
	<1224772939.3601.54.camel@localhost.localdomain>
Message-ID: <49008F2B.9070908@hhs.nl>

Tom "spot" Callaway wrote:
> On Thu, 2008-10-23 at 16:34 +0200, Enrico Scholz wrote:
>> Better solutions:
>>
>> * add it to comps.xml
>> * move 'R' to R-core, and add 'R' which depends on 'R-core' +
>> 'R-devel'
>>
>>
>>> * The size of the R-devel is tiny, about 440K installed.
>> You miss its dependencies:
>>
>> bzip2-devel
>> gcc-c++
>> gcc-gfortran
>> libICE-devel
>> libSM-devel
>> libX11-devel
>> libXmu-devel
>> libXt-devel
>> libjpeg-devel
>> libpng-devel
>> ncurses-devel
>> pkgconfig
>> readline-devel
>> tcl-devel
>> tetex-latex
>> texinfo
>> tk-devel
> 
> These are very good points, thanks Enrico. What would people think about
> doing the suggested R/R-core/R-devel split instead? Users would still be
> able to get everything with yum install R, it would meet the guidelines,
> and minimal installs with R can simply have R-core.
> 

+1

(esp after seeing the R-devel Requirements)

Regards,

Hans



From loganjerry at gmail.com  Thu Oct 23 15:22:58 2008
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 23 Oct 2008 09:22:58 -0600
Subject: providing what they require
In-Reply-To: <1224771377.9694.6.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
	<20081023141327.GB4912@nostromo.devel.redhat.com>
	<1224771377.9694.6.camel@rosebud>
Message-ID: <870180fe0810230822y4157ae83v41d4eb0f78ce441e@mail.gmail.com>

On Thu, Oct 23, 2008 at 8:16 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> No, I meant if you added an explicit require for an item that the
> package provides. Stop that.

Two of my packages appear in the list.  One is mona.  It provides a
handful of libraries, which have dependencies between them; i.e.,
library 1 is linked to library 2 which is linked to library 3, etc.
So every library but the top-level one appears in the automatically
generated Requires.  The other is check.  I have no idea what is going
on there.  If anyone has a clue, clue me in, please.

Isn't part of the problem that /usr/lib/rpm/find-requires doesn't
filter out the files it examines from its result set?  That seems to
be what is happening with mona.
-- 
Jerry James
http://loganjerry.googlepages.com/



From skvidal at fedoraproject.org  Thu Oct 23 15:29:18 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 23 Oct 2008 11:29:18 -0400
Subject: providing what they require
In-Reply-To: <870180fe0810230822y4157ae83v41d4eb0f78ce441e@mail.gmail.com>
References: <1224713033.3304.87.camel@rosebud>
	<20081023141327.GB4912@nostromo.devel.redhat.com>
	<1224771377.9694.6.camel@rosebud>
	<870180fe0810230822y4157ae83v41d4eb0f78ce441e@mail.gmail.com>
Message-ID: <1224775758.9694.8.camel@rosebud>

On Thu, 2008-10-23 at 09:22 -0600, Jerry James wrote:
> On Thu, Oct 23, 2008 at 8:16 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> > No, I meant if you added an explicit require for an item that the
> > package provides. Stop that.
> 
> Two of my packages appear in the list.  One is mona.  It provides a
> handful of libraries, which have dependencies between them; i.e.,
> library 1 is linked to library 2 which is linked to library 3, etc.
> So every library but the top-level one appears in the automatically
> generated Requires.  The other is check.  I have no idea what is going
> on there.  If anyone has a clue, clue me in, please.
> 
> Isn't part of the problem that /usr/lib/rpm/find-requires doesn't
> filter out the files it examines from its result set?  That seems to
> be what is happening with mona.

Yes! And that's what I was suggesting be fixed.

I was also asking packagers to make sure they are not accidentally
setting an explicit require that they don't actually need.

that's all.

-sv




From jkeating at redhat.com  Thu Oct 23 16:56:07 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 23 Oct 2008 09:56:07 -0700
Subject: Regarding install options
In-Reply-To: <4900155B.4060704@redhat.com>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr> <1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
	<48FE8759.6010302@redhat.com>
	<1224686759.3417.12.camel@luminos.localdomain>
	<4900155B.4060704@redhat.com>
Message-ID: <1224780968.26785.8.camel@luminos.localdomain>

On Thu, 2008-10-23 at 02:10 -0400, Casey Dahlin wrote:
> Having been around longer and now knowing what all of that is, it takes 
> less time these days. Do we expect everyone who just doesn't want what 
> they didn't ask for to know what libpango does? Or do we just expect 
> them to try each and every package in there and see which ones do and do 
> not try to take yum with them?

Yet you expect the comps maintainers to be able to make a decision about
what every other person needs without knowing those people?  That's a
laugh.

> >>  Now, when I install Fedora on a 
> >> server, I reboot and start over if I see anything that looks even 
> >> remotely desktop-related. This is a broken use case.
> >>  Solutions are:
> >>
> >> 1) Add the "dependencies have been added" screen that every other 
> >> package install tool in the distro has but Anaconda insists on going 
> >> without.
> >>     
> >
> > Have you filed this RFE in bugzilla against anaconda?  Unless you make
> > this an autoclosing summary you've just broken a feature that people
> > have been asking for for quite a while, the ability to just walk away
> > once depsolving starts.  If depsolving is successful the install should
> > just start without any further interaction.  Also, fun to figure out for
> > kickstarts.
> >
> >   
> You've posed a problem and a solution.

There was no solution there.

> >> 2) Have checkboxes in the package screen be tri-state. (checked if you 
> >> want it, unchecked if you don't want it, red x if yum is not allowed to 
> >> install it for any reason). This one's not pretty, but it'd work.
> >>     
> >
> > And just how is yum supposed to know that it can't install it?  Where
> > does that information come from, and if we have that information, why
> > would we ever even display the package then?  "Here is something you
> > can't click!  neener neener neeeeener!"
> >
> >   
> All reasons it isn't pretty.

You still didn't answer the question.  How is yum supposed to know it's
'not allowed to install it'.  Where have you ran into a situation where
anaconda showed you a checkbox you were not allowed to check?  I'm
honestly curious why this is even being talked about.

> 
> >> 3) Provide a default install. 
> >>     
> >
> > We have one, it's what happens if you go next next next.  It's defined
> > in comps by the groups that are marked as default and the packages
> > therein that are defined as mandatory and default.  It's also what you
> > get in kickstarts if you do %packages --default.
> >
> >   
> I meant "minimal" instead of "default." Typo
> 
> >> Believe me, I won't agree with what you 
> >> put in it at all. I will, however, be happier than I am now.
> >>     
> >
> > Then be happy.
> >
> >   
> >> 4) Document the procedure a few emails up on how to install just @core 
> >> or @core + @base . I didn't even know the system would run right if you 
> >> unchecked everything.
> >>     
> >
> > It all depends on your definition of "run".  It'll boot.  Does one
> > really need to document the process of unchecking boxes?  (or checking
> > the Base group box)
> >
> >   
> None of this is apparent to a user who doesn't know about Fedora.

Neither will the meaning of 'minimal' be.  Will it have networking?
Will it have yum?  Will it have ssh?  Will it speak my language?  So on,
and so forth.

>  Again, 
> the line here is not just technical and non-technical. Will the Debian 
> administrator who is trying out Fedora think of this procedure the first 
> time out? Likely he'll try to select all the packages he wants and end 
> up getting a hundred things he didn't. Install nothing and add later is 
> not the first instinct of the user.

Neither is not reviewing the selection and being "surprised" when there
is a lot of stuff installed.  The software screen even says:

"The default installation of Fedora includes a set of software
applicable for general internet usage.  What additional tasks would you
like your system to include support for?"

In what way does that sound like "just adding what else I need will
result in a very minimal install with just what I added"?

> >> Spending a little energy and not pleasing everyone is a lot better than 
> >> spending no energy and epic failing.
> >>     
> >
> > You have an epic ability to blow things out of proportion.  Maybe if you
> > looked at the anaconda source, or comps, and provided patches for what
> > you'd like to see, not only would it be helpful, but you'd also have
> > more code to rant about in your blogs!
> >
> >   
> Oh, were those /your/ cheerios I was pissing in?
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081023/830292e6/attachment.sig>

From jkeating at redhat.com  Thu Oct 23 17:05:58 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 23 Oct 2008 10:05:58 -0700
Subject: Make announcing soname bumps mandatory (was Re: rawhide
 report: 20081018 changes)
In-Reply-To: <b11vy7endb.fsf_-_@allele2.eebweb.arizona.edu>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	<b11vy7endb.fsf_-_@allele2.eebweb.arizona.edu>
Message-ID: <1224781558.26785.11.camel@luminos.localdomain>

On Thu, 2008-10-23 at 01:17 -0700, Alex Lancaster wrote:
> I think that the above policy should be made mandatory rather than
> "nice to" (unless you happen to be building all affected package
> yourself in which case an e-mail is superfluous).  At the very least
> it would get maintainers in the habit of running repoquery more
> regularly and so they would get a better sense of what other packages
> depended on their package (many maintainers seem unaware of this).
> Ideally this would be automated and provided in regular reports, or
> somehow incorporated into PackageDB.


Something that I'm planning for our infrastructure in the future is the
ability to do a build in the buildsystem, have it go through some
post-build examination such as:
  Did a soname change?
  Did provides change?
  Did requires change?
  Did files get removed?
  Did files get added?

so on and so forth, all geared toward "would this cause problems if
introduced into the package set?".  The maintainer would get a report
and if some things triggered poorly (like so name changes) the build
wouldn't get tagged into the collection, and the maintainer would have
to interact with something to either force the tag (which could then
trigger the emails you're talking about, soname bumping etc...) or throw
the build away and do something different.

Of course this type of functionality is blocking on a few things, like
an automated testing environment.  But hey, we'll get there at some
point!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081023/a839d054/attachment.sig>

From ianweller at gmail.com  Thu Oct 23 03:00:06 2008
From: ianweller at gmail.com (Ian Weller)
Date: Wed, 22 Oct 2008 22:00:06 -0500
Subject: fedora-wiki list for wiki users and contributors
Message-ID: <20081023025924.GA21231@gmail.com>

Hi all,

A new moderate-traffic mailing list for users and contributors of the
Fedora Project Wiki has been set up.

Among the discussions will be policy, announcements, and editing tips.
The list has been created to bring together the wider wiki community
split apart between different sub-projects of Fedora.

If you are interested in these sorts of discussions, please subscribe to
fedora-wiki at lists.fedoraproject.org at
  https://admin.fedoraproject.org/mailman/listinfo/fedora-wiki
We'll be glad to see you!

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081022/3b154a92/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 ivazqueznet at gmail.com  Thu Oct 23 17:17:41 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 23 Oct 2008 13:17:41 -0400
Subject: Make announcing soname bumps mandatory (was Re: rawhide
	report: 20081018 changes)
In-Reply-To: <1224781558.26785.11.camel@luminos.localdomain>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	<b11vy7endb.fsf_-_@allele2.eebweb.arizona.edu>
	<1224781558.26785.11.camel@luminos.localdomain>
Message-ID: <1224782261.3483.9.camel@ignacio.lan>

On Thu, 2008-10-23 at 10:05 -0700, Jesse Keating wrote:
> Something that I'm planning for our infrastructure in the future is the
> ability to do a build in the buildsystem, have it go through some
> post-build examination such as:
>   Did a soname change?
>   Did provides change?
>   Did requires change?
>   Did files get removed?
>   Did files get added?

There's my cue...

https://fedorahosted.org/bodhi/ticket/79

-- 
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/20081023/f5e0ba97/attachment.sig>

From buc at odusz.so-cdu.ru  Thu Oct 23 17:28:41 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Thu, 23 Oct 2008 21:28:41 +0400
Subject: Too early emails about updates?
Message-ID: <4900B449.2010605@odu.neva.ru>

Recently something was changed in a way how update reports go to 
fedora-package-announce list.

Previously, at a time when I received such emails, the correspond 
updates was already presented at the primary Fedora repository. Now, I 
receive emails, but the updates are still missing.

Certainly nobody can demand that recent updates appear on mirrors too 
soon. But at the primary site, the previous behaviour (ie. first in 
repo, then email report) would be preferable. Some people download 
updates manually (fe. "yum --downloadonly" into a local repository, then 
check source/changelog, then update local hosts etc.). This disorder 
causes them to remember that they should re-check repositories later.


~buc






From fedora at leemhuis.info  Thu Oct 23 17:31:48 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 23 Oct 2008 19:31:48 +0200
Subject: Regarding install options
In-Reply-To: <1224780968.26785.8.camel@luminos.localdomain>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>	<1223911751.3327.15.camel@luminos.localdomain>	<20081013161316.GL3139@free.fr>	<1223916009.3327.28.camel@luminos.localdomain>	<20081013164536.GN3139@free.fr>	<1223921280.3327.34.camel@luminos.localdomain>	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>	<20081013203244.GG2738@free.fr>	<1223930747.3327.41.camel@luminos.localdomain>	<20081013221048.GL2738@free.fr>	<1223937363.3056.10.camel@luminos.localdomain>	<48FE8759.6010302@redhat.com>	<1224686759.3417.12.camel@luminos.localdomain>	<4900155B.4060704@redhat.com>
	<1224780968.26785.8.camel@luminos.localdomain>
Message-ID: <4900B504.7030000@leemhuis.info>

On 23.10.2008 18:56, Jesse Keating wrote:
> 
> Neither will the meaning of 'minimal' be.  Will it have networking?
> Will it have yum?  Will it have ssh?  Will it speak my language?  So on,
> and so forth.

Not sure if my mind plays tricks with me, but I got the impression that 
I hear something like the above as a "shoot the discussion down" 
argument every few days right now... This is starting to annoy me, as 
statements like the above don't lead anywhere: Decisions have to be 
made; repeatably pointing out that it's hard to do them doesn't bring us 
a tiny bit further. So please:

Just let a group of interested people make a decision and realize it as 
a feature for F11! Then we hopefully can get rid of this topic (which 
seems to pop up every few weeks...).

Just my 2 cent.

Cu
knurd

(?) Just like other decisions get made every day in Fedora. "Chose the 
default" decisions are a good example, that are just as hard to make 
often: Epiphany or Firefox? Pidgin or Empathy? Thunderbird or Evolution? 
Some people won't like the decision in the end, but it's better for 
everyone to make one !



From jkeating at redhat.com  Thu Oct 23 17:40:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 23 Oct 2008 10:40:32 -0700
Subject: Regarding install options
In-Reply-To: <4900B504.7030000@leemhuis.info>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr> <1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
	<48FE8759.6010302@redhat.com>
	<1224686759.3417.12.camel@luminos.localdomain>
	<4900155B.4060704@redhat.com>
	<1224780968.26785.8.camel@luminos.localdomain>
	<4900B504.7030000@leemhuis.info>
Message-ID: <1224783632.26785.29.camel@luminos.localdomain>

On Thu, 2008-10-23 at 19:31 +0200, Thorsten Leemhuis wrote:
> Not sure if my mind plays tricks with me, but I got the impression that 
> I hear something like the above as a "shoot the discussion down" 
> argument every few days right now... This is starting to annoy me, as 
> statements like the above don't lead anywhere: Decisions have to be 
> made; repeatably pointing out that it's hard to do them doesn't bring us 
> a tiny bit further. So please:
> 
> Just let a group of interested people make a decision and realize it as 
> a feature for F11! Then we hopefully can get rid of this topic (which 
> seems to pop up every few weeks...).

The "Feature" exists.  You get it by de-selecting every box in anaconda.
A committee of interested people aren't going to magically make new UI
show up in anaconda, that has to be done through the anaconda upstream
and maintainers.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081023/bbecb85e/attachment.sig>

From jkeating at redhat.com  Thu Oct 23 17:42:06 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 23 Oct 2008 10:42:06 -0700
Subject: Make announcing soname bumps mandatory (was Re: rawhide
 report: 20081018 changes)
In-Reply-To: <1224782261.3483.9.camel@ignacio.lan>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	<b11vy7endb.fsf_-_@allele2.eebweb.arizona.edu>
	<1224781558.26785.11.camel@luminos.localdomain>
	<1224782261.3483.9.camel@ignacio.lan>
Message-ID: <1224783726.26785.31.camel@luminos.localdomain>

On Thu, 2008-10-23 at 13:17 -0400, Ignacio Vazquez-Abrams wrote:
> There's my cue...
> 
> https://fedorahosted.org/bodhi/ticket/79

Right, checking deps is one of those automated tests.  The trick is
getting it done after the build, but before the tag, so that if
everything is successful it just goes right in, but if it's not
successful it can either be waived (think groups of packages all updated
at the same time for new sonames), or thrown out.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081023/d0e15248/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Oct 23 17:50:20 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 24 Oct 2008 02:50:20 +0900
Subject: Too early emails about updates?
In-Reply-To: <4900B449.2010605@odu.neva.ru>
References: <4900B449.2010605@odu.neva.ru>
Message-ID: <4900B95C.1050001@ioa.s.u-tokyo.ac.jp>

Dmitry Butskoy wrote, at 10/24/2008 02:28 AM +9:00:
> Recently something was changed in a way how update reports go to 
> fedora-package-announce list.
> 
> Previously, at a time when I received such emails, the correspond 
> updates was already presented at the primary Fedora repository. Now, I 
> receive emails, but the updates are still missing.

Yes, I also received a strange mail one hours ago.

updates_at_fedoraproject.org says that manedit-1.2.1-1.fc9 is pushed
to stable:
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00682.html

However:
[tasaka1 at localhost ~]$ koji latest-pkg dist-f9-updates manedit
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
manedit-1.1.1-2.fc9                       dist-f9-updates       mtasaka
[tasaka1 at localhost ~]$ koji latest-pkg dist-f9-updates-testing manedit
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
manedit-1.2.1-1.fc9                       dist-f9-updates-testing  mtasaka

Usually I received the updates notification mail after the mail that
tagging as dist-f9-updates was done. Now I have not received that
manedit-1.2.1-1.fc9 is tagged as dist-f9-updates yet (and indeed
it is not tagged).

Mamoru



From fedora at leemhuis.info  Thu Oct 23 18:05:24 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 23 Oct 2008 20:05:24 +0200
Subject: Regarding install options
In-Reply-To: <1224783632.26785.29.camel@luminos.localdomain>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>	<1223911751.3327.15.camel@luminos.localdomain>	<20081013161316.GL3139@free.fr>	<1223916009.3327.28.camel@luminos.localdomain>	<20081013164536.GN3139@free.fr>	<1223921280.3327.34.camel@luminos.localdomain>	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>	<20081013203244.GG2738@free.fr>	<1223930747.3327.41.camel@luminos.localdomain>	<20081013221048.GL2738@free.fr>	<1223937363.3056.10.camel@luminos.localdomain>	<48FE8759.6010302@redhat.com>	<1224686759.3417.12.camel@luminos.localdomain>	<4900155B.4060704@redhat.com>	<1224780968.26785.8.camel@luminos.localdomain>	<4900B504.7030000@leemhuis.info>
	<1224783632.26785.29.camel@luminos.localdomain>
Message-ID: <4900BCE4.6040102@leemhuis.info>

On 23.10.2008 19:40, Jesse Keating wrote:
> On Thu, 2008-10-23 at 19:31 +0200, Thorsten Leemhuis wrote:
>> Not sure if my mind plays tricks with me, but I got the impression that 
>> I hear something like the above as a "shoot the discussion down" 
>> argument every few days right now... This is starting to annoy me, as 
>> statements like the above don't lead anywhere: Decisions have to be 
>> made; repeatably pointing out that it's hard to do them doesn't bring us 
>> a tiny bit further. So please:
>>
>> Just let a group of interested people make a decision and realize it as 
>> a feature for F11! Then we hopefully can get rid of this topic (which 
>> seems to pop up every few weeks...).
> 
> The "Feature" exists. You get it by de-selecting every box in anaconda.

I unsure if I agree or not, but one things seems obvious to me: The 
current solution doesn't satisfy a lot of people (actually "it confuses 
people" might be the the better description). So if there are people 
that want to work out a better solution please let them just do that; if 
you think that clutters the UI then bring that point up; but just 
repeatably stating that it's hard to pick the "minimal package set" 
doesn't bring us any further.

> A committee of interested people aren't going to magically make new UI
> show up in anaconda, that has to be done through the anaconda upstream
> and maintainers.

Sounds yet again like you want to shoot the discussion down, as you make 
it sound like getting things into anaconda is something totally 
impossible. But luckily Fedora and anaconda are open-source projects; 
Red Hat even opened RHL/started Fedora to give the community a chance to 
influence and improve things like that. So give them a chance to do 
that; yes, it's maybe won't be easy to realize with a clean UI, but I'm 
optimistic it's possible somehow.

Cu
knurd



From vonbrand at inf.utfsm.cl  Thu Oct 23 15:07:14 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 23 Oct 2008 12:07:14 -0300
Subject: providing what they require
In-Reply-To: <645d17210810221553g58e459d6t86a3578e9514f3cc@mail.gmail.com>
References: <1224713033.3304.87.camel@rosebud>
	<645d17210810221528o5820738brf20297cb81a94ee@mail.gmail.com>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<645d17210810221553g58e459d6t86a3578e9514f3cc@mail.gmail.com>
Message-ID: <200810231507.m9NF7EDg004061@laptop14.inf.utfsm.cl>

Jonathan Underwood <jonathan.underwood at gmail.com> wrote:

[...]

> Yeah. So should we bother munging spec files for this if it's going to
> be fixed in rpmbuild anyway? I guess not.

The specfile is for communicating with /humans/, so its clarity and
non-redundancy are vital.
-- 
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 2340000       Fax:  +56 32 2797513



From james at fedoraproject.org  Thu Oct 23 18:22:07 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 23 Oct 2008 14:22:07 -0400
Subject: R-devel going away
In-Reply-To: <1224772939.3601.54.camel@localhost.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<87mygvcrd0.fsf@fc5.bigo.ensc.de>
	<1224772939.3601.54.camel@localhost.localdomain>
Message-ID: <1224786127.3898.97.camel@code.and.org>

On Thu, 2008-10-23 at 10:42 -0400, Tom "spot" Callaway wrote:

> > > * The size of the R-devel is tiny, about 440K installed.

 Also, even without the deps.: yum list-installed-sizes \*-devel

...440K is way past the 50% mark for the size of a *-devel package.

> These are very good points, thanks Enrico. What would people think about
> doing the suggested R/R-core/R-devel split instead? Users would still be
> able to get everything with yum install R, it would meet the guidelines,
> and minimal installs with R can simply have R-core.

 Well it kinda fits the "people expect foo-core + additions" _assuming_
CRAN is a requirement, but really why don't we just package more of the
R modules so CRAN usage isn't a requirement?

-- 
James Antill <james at fedoraproject.org>
Fedora



From jkeating at redhat.com  Thu Oct 23 18:26:11 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 23 Oct 2008 11:26:11 -0700
Subject: Regarding install options
In-Reply-To: <4900BCE4.6040102@leemhuis.info>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr> <1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
	<48FE8759.6010302@redhat.com>
	<1224686759.3417.12.camel@luminos.localdomain>
	<4900155B.4060704@redhat.com>
	<1224780968.26785.8.camel@luminos.localdomain>
	<4900B504.7030000@leemhuis.info>
	<1224783632.26785.29.camel@luminos.localdomain>
	<4900BCE4.6040102@leemhuis.info>
Message-ID: <1224786372.22443.10.camel@luminos.localdomain>

On Thu, 2008-10-23 at 20:05 +0200, Thorsten Leemhuis wrote:
> > The "Feature" exists. You get it by de-selecting every box in anaconda.
> 
> I unsure if I agree or not, but one things seems obvious to me: The 
> current solution doesn't satisfy a lot of people (actually "it confuses 
> people" might be the the better description). 

And so did the "minimal" offerings of past.

> So if there are people 
> that want to work out a better solution please let them just do that; if 
> you think that clutters the UI then bring that point up; but just 
> repeatably stating that it's hard to pick the "minimal package set" 
> doesn't bring us any further.

I've stated over and over again that you're welcome to try.  I even
pointed out that Comps is the place to do it, and that is even open for
commit access.  So far, I haven't seen any real discussion or changes
there.

> > A committee of interested people aren't going to magically make new UI
> > show up in anaconda, that has to be done through the anaconda upstream
> > and maintainers.
> 
> Sounds yet again like you want to shoot the discussion down, as you make 
> it sound like getting things into anaconda is something totally 
> impossible.

Not at all.  However this particular thing I don't see a lot of chance
of getting in, at least not in the previously suggested ways.

>  But luckily Fedora and anaconda are open-source projects; 

As I stated.

> Red Hat even opened RHL/started Fedora to give the community a chance to 
> influence and improve things like that. So give them a chance to do 
> that; yes, it's maybe won't be easy to realize with a clean UI, but I'm 
> optimistic it's possible somehow.

Isn't that why I said to go through the anaconda upstream and
maintainers to get such a change in?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081023/e7740439/attachment.sig>

From vonbrand at inf.utfsm.cl  Thu Oct 23 18:43:41 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 23 Oct 2008 15:43:41 -0300
Subject: Regarding install options
In-Reply-To: <4900B504.7030000@leemhuis.info>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223911751.3327.15.camel@luminos.localdomain>
	<20081013161316.GL3139@free.fr>
	<1223916009.3327.28.camel@luminos.localdomain>
	<20081013164536.GN3139@free.fr>
	<1223921280.3327.34.camel@luminos.localdomain>
	<20081013194800.GB2738@free.fr>
	<1223928665.29527.2.camel@arekh.okg>
	<20081013203244.GG2738@free.fr>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
	<48FE8759.6010302@redhat.com>
	<1224686759.3417.12.camel@luminos.localdomain>
	<4900155B.4060704@redhat.com>
	<1224780968.26785.8.camel@luminos.localdomain>
	<4900B504.7030000@leemhuis.info>
Message-ID: <200810231843.m9NIhg3t004015@laptop14.inf.utfsm.cl>

Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> On 23.10.2008 18:56, Jesse Keating wrote:
> > Neither will the meaning of 'minimal' be.  Will it have networking?
> > Will it have yum?  Will it have ssh?  Will it speak my language?  So on,
> > and so forth.
> 
> Not sure if my mind plays tricks with me, but I got the impression
> that I hear something like the above as a "shoot the discussion down"
> argument every few days right now... This is starting to annoy me, as
> statements like the above don't lead anywhere: Decisions have to be
> made; repeatably pointing out that it's hard to do them doesn't bring
> us a tiny bit further. So please:
> 
> Just let a group of interested people make a decision and realize it
> as a feature for F11! Then we hopefully can get rid of this topic
> (which seems to pop up every few weeks...).

That /has/ been done (yes, I've been around since Red Hat 3.x days), and it
made /never/ everybody happy, thus the recurring flamewars on the
topic. When they say here that it _can't_ be solved it is not out of
lazyness, it is out of (often bitter) experience.

What is minimal for me is sorely lacking while barroquely bloated for the
next interested party.
-- 
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 2340000       Fax:  +56 32 2797513



From mattdm at mattdm.org  Thu Oct 23 19:28:02 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 23 Oct 2008 15:28:02 -0400
Subject: R-devel going away
In-Reply-To: <ufaej27fkhb.fsf@epithumia.math.uh.edu>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<20081023142750.GA20579@jadzia.bu.edu>
	<ufaej27fkhb.fsf@epithumia.math.uh.edu>
Message-ID: <20081023192802.GA17205@jadzia.bu.edu>

On Thu, Oct 23, 2008 at 09:34:56AM -0500, Jason L Tibbitts III wrote:
> MM> Where do R packages installed this way go?
> Into the installing user's home directory.

In that case, sounds fine to me.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From a.badger at gmail.com  Thu Oct 23 20:31:39 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 23 Oct 2008 13:31:39 -0700
Subject: R-devel going away
In-Reply-To: <1224772939.3601.54.camel@localhost.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>	<87mygvcrd0.fsf@fc5.bigo.ensc.de>
	<1224772939.3601.54.camel@localhost.localdomain>
Message-ID: <4900DF2B.4000808@gmail.com>

Tom "spot" Callaway wrote:
> On Thu, 2008-10-23 at 16:34 +0200, Enrico Scholz wrote:
>> Better solutions:
>>
>> * add it to comps.xml
>> * move 'R' to R-core, and add 'R' which depends on 'R-core' +
>> 'R-devel'
>>
>>
>>> * The size of the R-devel is tiny, about 440K installed.
>> You miss its dependencies:
>>
[long list of dependencies]

> 
> These are very good points, thanks Enrico. What would people think about
> doing the suggested R/R-core/R-devel split instead? Users would still be
> able to get everything with yum install R, it would meet the guidelines,
> and minimal installs with R can simply have R-core.
> 
Not an R user but I like this plan.

-Toshio

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

From jamatos at fc.up.pt  Thu Oct 23 18:41:41 2008
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Thu, 23 Oct 2008 19:41:41 +0100
Subject: R-devel going away
In-Reply-To: <1224786127.3898.97.camel@code.and.org>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<1224772939.3601.54.camel@localhost.localdomain>
	<1224786127.3898.97.camel@code.and.org>
Message-ID: <200810231941.41824.jamatos@fc.up.pt>

On Thursday 23 October 2008 19:22:07 James Antill wrote:
> ?Well it kinda fits the "people expect foo-core + additions" _assuming_
> CRAN is a requirement, but really why don't we just package more of the
> R modules so CRAN usage isn't a requirement?

There are more than 1500 modules (the have been growing at an exponential rate 
in the last years). So while we would like to see more R packages in Fedora in 
are not even near to have a reasonable subset of R packaged.

So for the moment CRAN is really a requirement to use R in Fedora.

> --
> James Antill <james at fedoraproject.org>
> Fedora

-- 
Jos? Ab?lio



From bpepple at fedoraproject.org  Thu Oct 23 19:53:33 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 23 Oct 2008 15:53:33 -0400
Subject: FESCo Meeting Summary for 2008-10-22
Message-ID: <1224791613.4174.4.camel@kennedy>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Bill Nottingham       (notting)
* Jon Stanley           (jds2001)
* Dennis Gilmore        (dgilmore)
* Josh Boyer            (jwb)
* David Woodhouse       (dwmw2)
* Karsten Hopp          (kick_)

=== Absent ===
* Kevin Fenzi           (nirik)

== Summary ==
=== New Sponsor ===
* FESCo has approved the sponsor requests for Andreas Thienemann.
** Note: any Fedora packager that wishes to become a sponsor, can
contact the FESCo chair or go directly to:
http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors

=== Fedora Packaging Committee Guideline Proposals ===
* FESCo had no objections to the guideline proposals approved by the
FPC. http://fedoraproject.org/wiki/Packaging/Minutes/20081021

=== Post-Beta Snapshots ===
* FESCo had no objections to the adjustment proposed by the Release
Engineering team.
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01994.html

=== Features ===
* FESCo rejected a proposal to revert the Sbin Sanity(1) feature.
      * For: kick_
      * Against: dwmw2, j-rod, bpepple, notting, dgilmore, nirik
      * Abstain: jwb
     1. https://fedoraproject.org/wiki/Features/SbinSanity

* The Echo Icon Feature was pulled, after a review by the Art team.
https://fedoraproject.org/wiki/Features/EchoIconTheme

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-22.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081023/b726e9a2/attachment.sig>

From james at fedoraproject.org  Thu Oct 23 21:10:12 2008
From: james at fedoraproject.org (James Antill)
Date: Thu, 23 Oct 2008 17:10:12 -0400
Subject: R-devel going away
In-Reply-To: <200810231941.41824.jamatos@fc.up.pt>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<1224772939.3601.54.camel@localhost.localdomain>
	<1224786127.3898.97.camel@code.and.org>
	<200810231941.41824.jamatos@fc.up.pt>
Message-ID: <1224796212.3898.106.camel@code.and.org>

On Thu, 2008-10-23 at 19:41 +0100, Jos? Matos wrote:
> On Thursday 23 October 2008 19:22:07 James Antill wrote:
> >  Well it kinda fits the "people expect foo-core + additions" _assuming_
> > CRAN is a requirement, but really why don't we just package more of the
> > R modules so CRAN usage isn't a requirement?
> 
> There are more than 1500 modules (the have been growing at an exponential rate 
> in the last years). So while we would like to see more R packages in Fedora in 
> are not even near to have a reasonable subset of R packaged.

 My main concern was that you could use that argument a lot (there are
probably still more unpackaged libc using things than packaged).
 But I ran:

 repoquery --whatrequires '*-devel' | \
   fgrep -v -- '-devel-' | \
   fgrep -v -- '-static-'

...and there's a lot of stuff there, including a lot of the "small"
languages (and perl-core, although that's not actually required by perl
which seems like a bug). So this isn't unusual (bad spot for asking,
instead of just doing it like everyone else ;).

-- 
James Antill <james at fedoraproject.org>
Fedora



From mschwendt at gmail.com  Thu Oct 23 21:17:33 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 23 Oct 2008 21:17:33 -0000
Subject: Broken dependencies in Fedora 9 - 2008-10-23
Message-ID: <20081023211733.14041.26503@localhost.localdomain>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    berrange AT redhat.com
        perl-Test-AutoBuild

    dev AT nigelj.com
        mediawiki-SpecialInterwiki

    dhuff AT redhat.com
        appliance-tools

    ebmunson AT us.ibm.com
        libhugetlbfs
        lsvpd

    gauret AT free.fr
        grisbi

    katzj AT redhat.com
        livecd-tools

    lxtnow AT gmail.com
        gnome-desktop-sharp
        gspiceui

    matthias AT rpmforge.net
        pigment-python

    oliver AT linux-kernel.at
        syck

    orion AT cora.nwra.com
        paraview

    shawn.p.huang AT gmail.com
        scim-bridge

    wart AT kobold.org
        cyphesis
        sear


======================================================================
Broken packages in fedora-9-i386:

    cyphesis-selinux-0.5.15-6.fc9.i386  requires  cyphesis = 0:0.5.15-6.fc9
    grisbi-0.5.9-5.fc9.i386  requires  tetex-unicode
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.i386  requires  libpigment-gtk-0.3.so.4
    sear-0.6.3-10.fc9.i386  requires  libmercator-0.2.so.4
    syck-php-0.61-4.3.fc9.i386  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc64:

    cyphesis-selinux-0.5.15-6.fc9.ppc64  requires  cyphesis = 0:0.5.15-6.fc9
    grisbi-0.5.9-5.fc9.ppc64  requires  tetex-unicode
    libhugetlbfs-test-1.1-6.fc9.ppc64  requires  libhugetlbfs = 0:1.1-6.fc9
    perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch  requires  darcs >= 0:1.0.0
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.ppc64  requires  libpigment-0.3.so.4()(64bit)
    sear-0.6.3-10.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    syck-php-0.61-4.3.fc9.ppc64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-ppc:

    cyphesis-selinux-0.5.15-6.fc9.ppc  requires  cyphesis = 0:0.5.15-6.fc9
    grisbi-0.5.9-5.fc9.ppc  requires  tetex-unicode
    libhugetlbfs-test-1.1-6.fc9.ppc  requires  libhugetlbfs = 0:1.1-6.fc9
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-0.3.so.4
    pigment-python-0.3.3-1.fc9.ppc  requires  libpigment-gtk-0.3.so.4
    sear-0.6.3-10.fc9.ppc  requires  libmercator-0.2.so.4
    syck-php-0.61-4.3.fc9.ppc  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-9-x86_64:

    cyphesis-selinux-0.5.15-6.fc9.x86_64  requires  cyphesis = 0:0.5.15-6.fc9
    grisbi-0.5.9-5.fc9.x86_64  requires  tetex-unicode
    libhugetlbfs-test-1.1-6.fc9.x86_64  requires  libhugetlbfs = 0:1.1-6.fc9
    paraview-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    paraview-mpi-3.2.1-6.fc9.i386  requires  paraview-data = 0:3.2.1-6.fc9
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-gtk-0.3.so.4()(64bit)
    pigment-python-0.3.3-1.fc9.x86_64  requires  libpigment-0.3.so.4()(64bit)
    scim-bridge-qt-0.4.15-5.fc9.i386  requires  scim-bridge = 0:0.4.15-5.fc9
    sear-0.6.3-10.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    syck-php-0.61-4.3.fc9.x86_64  requires  php = 0:5.2.5


======================================================================
Broken packages in fedora-updates-9-i386:

    cyphesis-0.5.15-8.fc9.i386  requires  libmercator-0.2.so.4
    lsvpd-1.6.4-1.fc9.i386  requires  libvpd_cxx-2.0.so.1
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-9-ppc64:

    appliance-tools-002-4.fc9.noarch  requires  qemu-img
    cyphesis-0.5.15-8.fc9.ppc64  requires  libmercator-0.2.so.4()(64bit)
    gspiceui-0.9.65-2.fc9.ppc64  requires  gwave
    livecd-tools-017.1-1.fc9.ppc64  requires  yaboot
    lsvpd-1.6.4-1.fc9.ppc64  requires  libvpd_cxx-2.0.so.1()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-9-ppc:

    cyphesis-0.5.15-8.fc9.ppc  requires  libmercator-0.2.so.4
    lsvpd-1.6.4-1.fc9.ppc  requires  libvpd_cxx-2.0.so.1
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-9-x86_64:

    cyphesis-0.5.15-8.fc9.x86_64  requires  libmercator-0.2.so.4()(64bit)
    lsvpd-1.6.4-1.fc9.x86_64  requires  libvpd_cxx-2.0.so.1()(64bit)
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch  requires  mediawiki < 0:1.11


======================================================================
Broken packages in fedora-updates-testing-9-i386:

    gnome-desktop-sharp-2.20.1-2.fc9.i386  requires  mono(gtk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.i386  requires  mono(gdk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.i386  requires  mono(pango-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.i386  requires  mono(atk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.i386  requires  mono(glib-sharp) = 0:2.12.0.0


======================================================================
Broken packages in fedora-updates-testing-9-ppc:

    gnome-desktop-sharp-2.20.1-2.fc9.ppc  requires  mono(gtk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.ppc  requires  mono(gdk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.ppc  requires  mono(pango-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.ppc  requires  mono(atk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.ppc  requires  mono(glib-sharp) = 0:2.12.0.0


======================================================================
Broken packages in fedora-updates-testing-9-x86_64:

    gnome-desktop-sharp-2.20.1-2.fc9.x86_64  requires  mono(atk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.x86_64  requires  mono(gtk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.x86_64  requires  mono(gdk-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.x86_64  requires  mono(pango-sharp) = 0:2.12.0.0
    gnome-desktop-sharp-2.20.1-2.fc9.x86_64  requires  mono(glib-sharp) = 0:2.12.0.0



From a.badger at gmail.com  Thu Oct 23 21:51:23 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 23 Oct 2008 14:51:23 -0700
Subject: pguiman has no maintainer
In-Reply-To: <20081023122416.31f14c62.mschwendt@gmail.com>
References: <20080828215641.03e13d63.mschwendt@gmail.com>
	<20081023122416.31f14c62.mschwendt@gmail.com>
Message-ID: <4900F1DB.9040108@gmail.com>

Michael Schwendt wrote:
> On Thu, 28 Aug 2008 21:56:41 +0200, Michael Schwendt wrote:
> 
>> https://admin.fedoraproject.org/pkgdb/packages/name/pguiman
>>
>> Maintainer "odvorace" gives "user unknown" at Red Hat.
>> Pkg ACLs are locked down.
> 
> Who takes care of issues like this?
> Is it necessary to follow the lengthy AWOL procedure?
> https://bugzilla.redhat.com/468160
> 
I've opened the acl.

Would FESCo like to short circuit the NonResponsiveMaintainers policy in
this case?  It seems like most of the steps in the procedure have been
followed except that the opening of the bugzilla bug was done last
instead of first.

-Toshio

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

From mschwendt at gmail.com  Thu Oct 23 21:54:56 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 23 Oct 2008 21:54:56 -0000
Subject: Broken dependencies in Fedora 8 - 2008-10-23
Message-ID: <20081023215456.14764.21740@localhost.localdomain>

======================================================================
The results in this summary consider Test Updates!
======================================================================

Summary of broken packages (by owner):

    Axel.Thimm AT ATrpms.net
        mediawiki-openid

    berrange AT redhat.com
        perl-Test-AutoBuild

    dev AT nigelj.com
        mediawiki-SpecialInterwiki

    ebmunson AT us.ibm.com
        libhugetlbfs

    ianweller AT gmail.com
        mediawiki-HNP
        mediawiki-ParserFunctions
        mediawiki-StubManager

    ismael AT olea.org
        mediawiki-imagemap

    jesusfreak91 AT gmail.com
        nxt_python

    konrad AT tylerc.org
        joda-time

    lxtnow AT gmail.com
        gspiceui

    oliver AT linux-kernel.at
        syck

    rmeggins AT redhat.com
        idm-console-framework

    silfreed AT silfreed.net
        pytrainer

    t.sailer AT alumni.ethz.ch
        ghdl


======================================================================
Broken packages in fedora-8-i386:

    libhugetlbfs-test-1.1-4.fc8.i386  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.i386  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc64:

    libhugetlbfs-test-1.1-4.fc8.ppc64  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.ppc64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-ppc:

    libhugetlbfs-test-1.1-4.fc8.ppc  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.ppc  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-8-x86_64:

    libhugetlbfs-test-1.1-4.fc8.x86_64  requires  libhugetlbfs = 0:1.1-4.fc8
    syck-php-0.61-2.fc8.x86_64  requires  php = 0:5.2.4


======================================================================
Broken packages in fedora-updates-8-i386:

    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    pytrainer-1.6.0.5-3.fc8.noarch  requires  firefox = 0:2.0.0.14


======================================================================
Broken packages in fedora-updates-8-ppc64:

    gspiceui-0.9.65-2.fc8.ppc64  requires  gwave
    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-HNP-1.1.2-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-ParserFunctions-1.1.1-1.20080520svn35130.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    mediawiki-StubManager-1.2.0-1.fc8.noarch  requires  mediawiki >= 0:1.10
    mediawiki-imagemap-0-0.1.r37906.fc8.noarch  requires  mediawiki >= 0:1.13
    mediawiki-openid-0.8.2-7.0.1.noarch  requires  mediawiki
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    perl-Test-AutoBuild-darcs-1.2.2-1.fc8.noarch  requires  darcs >= 0:1.0.0
    pytrainer-1.6.0.5-3.fc8.noarch  requires  firefox = 0:2.0.0.14


======================================================================
Broken packages in fedora-updates-8-ppc:

    idm-console-framework-1.1.2-1.fc8.noarch  requires  java > 0:1.5.0
    joda-time-1.5.2-7.tzdata2008d.fc8.noarch  requires  java > 0:1.5.0
    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    pytrainer-1.6.0.5-3.fc8.noarch  requires  firefox = 0:2.0.0.14


======================================================================
Broken packages in fedora-updates-8-x86_64:

    mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc8.noarch  requires  mediawiki < 0:1.11
    nxt_python-0.7-3.fc8.noarch  requires  pyusb
    pytrainer-1.6.0.5-3.fc8.noarch  requires  firefox = 0:2.0.0.14


======================================================================
Broken packages in fedora-updates-testing-8-i386:

    ghdl-grt-0.27-0.110svn.3.fc8.i386  requires  libgnat >= 0:4.3


======================================================================
Broken packages in fedora-updates-testing-8-ppc:

    ghdl-grt-0.27-0.110svn.3.fc8.ppc  requires  libgnat >= 0:4.3


======================================================================
Broken packages in fedora-updates-testing-8-x86_64:

    ghdl-grt-0.27-0.110svn.3.fc8.x86_64  requires  libgnat >= 0:4.3



From orion at cora.nwra.com  Thu Oct 23 21:56:51 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 23 Oct 2008 15:56:51 -0600
Subject: Broken dependencies in Fedora 9 - 2008-10-23
In-Reply-To: <20081023211721.14041.61137@localhost.localdomain>
References: <20081023211721.14041.61137@localhost.localdomain>
Message-ID: <4900F323.4060509@cora.nwra.com>

Michael Schwendt wrote:
> Your following packages in the repository suffer from broken dependencies:
> 
> ======================================================================
> The results in this summary consider Test Updates!
> ======================================================================
> 
> package: paraview-3.2.1-6.fc9.i386 from fedora-9-x86_64
>   unresolved deps:
>      paraview-data = 0:3.2.1-6.fc9
> 
> package: paraview-mpi-3.2.1-6.fc9.i386 from fedora-9-x86_64
>   unresolved deps:
>      paraview-data = 0:3.2.1-6.fc9

?  These are old versions...


$ yum list paraview\*
Loaded plugins: dellsysidplugin, downloadonly
Installed Packages
paraview.i386                            3.2.2-1.fc9            installed
paraview-data.i386                       3.2.2-1.fc9            installed
Available Packages
paraview-devel.i386                      3.2.2-1.fc9 
updates-newkey
paraview-mpi.i386                        3.2.2-1.fc9 
updates-newkey
paraview-mpi-devel.i386                  3.2.1-6.fc9            fedora

Ah, so I dropped paraview-mpi-devel, but I obsolete/provide it in 
paraview-devel:

%package        devel
Summary:        Development files for ParaView
Group:          Applications/Engineering
Requires:       %{name} = %{version}-%{release}
Obsoletes:      %{name}-mpi-devel < %{version}-%{release}
Provides:       %{name}-mpi-devel = %{version}-%{release}

So, what's up?

-- 
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 at gmail.com  Thu Oct 23 22:10:10 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 24 Oct 2008 00:10:10 +0200
Subject: Broken dependencies in Fedora 9 - 2008-10-23
In-Reply-To: <4900F323.4060509@cora.nwra.com>
References: <20081023211721.14041.61137@localhost.localdomain>
	<4900F323.4060509@cora.nwra.com>
Message-ID: <20081024001010.25def400.mschwendt@gmail.com>

On Thu, 23 Oct 2008 15:56:51 -0600, Orion Poplawski wrote:

> Michael Schwendt wrote:
> > Your following packages in the repository suffer from broken dependencies:
> > 
> > ======================================================================
> > The results in this summary consider Test Updates!
> > ======================================================================
> > 
> > package: paraview-3.2.1-6.fc9.i386 from fedora-9-x86_64
> >   unresolved deps:
> >      paraview-data = 0:3.2.1-6.fc9
> > 
> > package: paraview-mpi-3.2.1-6.fc9.i386 from fedora-9-x86_64
> >   unresolved deps:
> >      paraview-data = 0:3.2.1-6.fc9
> 
> ?  These are old versions...
> 
> 
> $ yum list paraview\*
> Loaded plugins: dellsysidplugin, downloadonly
> Installed Packages
> paraview.i386                            3.2.2-1.fc9            installed
> paraview-data.i386                       3.2.2-1.fc9            installed
> Available Packages
> paraview-devel.i386                      3.2.2-1.fc9 
> updates-newkey
> paraview-mpi.i386                        3.2.2-1.fc9 
> updates-newkey
> paraview-mpi-devel.i386                  3.2.1-6.fc9            fedora

That's the wrong arch repo.
 
> Ah, so I dropped paraview-mpi-devel, but I obsolete/provide it in 
> paraview-devel:
> 
> %package        devel
> Summary:        Development files for ParaView
> Group:          Applications/Engineering
> Requires:       %{name} = %{version}-%{release}
> Obsoletes:      %{name}-mpi-devel < %{version}-%{release}
> Provides:       %{name}-mpi-devel = %{version}-%{release}
> 
> So, what's up?

See bodhi comment. This is multiarch breakage. paraview-mpi.i386 no
longer is made available for x86_64 because of your modified inter-package
dependencies.



From konrad at tylerc.org  Thu Oct 23 22:11:30 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 23 Oct 2008 15:11:30 -0700
Subject: Broken dependencies in Fedora 8 - 2008-10-23
In-Reply-To: <20081023215456.14764.21740@localhost.localdomain>
References: <20081023215456.14764.21740@localhost.localdomain>
Message-ID: <200810231511.30780.konrad@tylerc.org>

On Thursday 23 October 2008 02:54:56 pm Michael Schwendt wrote:
> ======================================================================
> The results in this summary consider Test Updates!
> ======================================================================
>
> Summary of broken packages (by owner):
> ...
>     konrad AT tylerc.org
>         joda-time

This is only broken on ppc/ppc64, and only because the java maintainers chose 
not to have any java package > 1.5.0 on ppc for Fedora 8. Furthermore as 
Fedora 8 is nearing EOL I don't think it's really a big deal, as it's fine on 
Fedora 9.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From amdunn at gmail.com  Thu Oct 23 22:18:57 2008
From: amdunn at gmail.com (Alan Dunn)
Date: Thu, 23 Oct 2008 18:18:57 -0400
Subject: Bodhi and commit ACLs
Message-ID: <f90695ee0810231518t9616f8fu6a9add0bd5beba50@mail.gmail.com>

I am under the impression that if I have commit access for a package I
should be able to submit updates for it through Bodhi. I was recently
given commit access for ocaml-lablgtk so I could fix a bug in the F-9
package, but it seems that I can't actually submit an update for it.
Am I wrong about how this works, or is something broken? (Or did
something change recently?)

- Alan



From lmacken at redhat.com  Thu Oct 23 22:56:15 2008
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 23 Oct 2008 18:56:15 -0400
Subject: Bodhi and commit ACLs
In-Reply-To: <f90695ee0810231518t9616f8fu6a9add0bd5beba50@mail.gmail.com>
References: <f90695ee0810231518t9616f8fu6a9add0bd5beba50@mail.gmail.com>
Message-ID: <20081023225614.GH12437@x300>

On Thu, Oct 23, 2008 at 06:18:57PM -0400, Alan Dunn wrote:
> I am under the impression that if I have commit access for a package I
> should be able to submit updates for it through Bodhi. I was recently
> given commit access for ocaml-lablgtk so I could fix a bug in the F-9
> package, but it seems that I can't actually submit an update for it.
> Am I wrong about how this works, or is something broken? (Or did
> something change recently?)

At the moment bodhi allows anyone with commit access to the devel branch
to submit updates.  Yes, this is not ideal, but will require some
significant refactoring to do this verification properly.

If you go ahead and apply for commit access to the devel branch, you
should be all set.

    https://admin.fedoraproject.org/pkgdb/packages/name/ocaml-lablgtk 

luke



From mschwendt at gmail.com  Thu Oct 23 23:28:32 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 24 Oct 2008 01:28:32 +0200
Subject: pguiman has no maintainer
In-Reply-To: <4900F1DB.9040108@gmail.com>
References: <20080828215641.03e13d63.mschwendt@gmail.com>
	<20081023122416.31f14c62.mschwendt@gmail.com>
	<4900F1DB.9040108@gmail.com>
Message-ID: <20081024012832.68745033.mschwendt@gmail.com>

On Thu, 23 Oct 2008 14:51:23 -0700, Toshio Kuratomi wrote:

> >> https://admin.fedoraproject.org/pkgdb/packages/name/pguiman
> >>
> >> Maintainer "odvorace" gives "user unknown" at Red Hat.
> >> Pkg ACLs are locked down.
> > 
> > Who takes care of issues like this?
> > Is it necessary to follow the lengthy AWOL procedure?
> > https://bugzilla.redhat.com/468160
> > 
> I've opened the acl.
> 
> Would FESCo like to short circuit the NonResponsiveMaintainers policy in
> this case?  It seems like most of the steps in the procedure have been
> followed except that the opening of the bugzilla bug was done last
> instead of first.

I didn't start any formal process. This is only one of a few packages
where I stumbled into locked ACLs while fixing lots of unowned
directories. Mailing the owner then failed.

There's another open ticket which is unanswered for several months.
The app crashes and possibly doesn't work much, given that it's only
0.0.1.

The missing packager is also the upstream developer.



From lmacken at redhat.com  Thu Oct 23 23:52:52 2008
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 23 Oct 2008 19:52:52 -0400
Subject: Too early emails about updates?
In-Reply-To: <4900B449.2010605@odu.neva.ru>
References: <4900B449.2010605@odu.neva.ru>
Message-ID: <20081023235252.GI12437@x300>

On Thu, Oct 23, 2008 at 09:28:41PM +0400, Dmitry Butskoy wrote:
> Recently something was changed in a way how update reports go to  
> fedora-package-announce list.
>
> Previously, at a time when I received such emails, the correspond  
> updates was already presented at the primary Fedora repository. Now, I  
> receive emails, but the updates are still missing.
>
> Certainly nobody can demand that recent updates appear on mirrors too  
> soon. But at the primary site, the previous behaviour (ie. first in  
> repo, then email report) would be preferable. Some people download  
> updates manually (fe. "yum --downloadonly" into a local repository, then  
> check source/changelog, then update local hosts etc.). This disorder  
> causes them to remember that they should re-check repositories later.

Nothing has changed recently with regard to how/when update
notifications are sent out.  After composing the repositories, bodhi
waits until they hit the master mirror, and then sends out the notices
to the fedora-package-announce list (among doing many other things as
well).

With regard to today's updates push, a stale koji session caused an
explosion to occur before the build tags were even moved.  Then,
resuming the push skipped the moving of the builds and went ahead and
sent their notices even when they did not appear in the repositories.
I'm going to be making bodhi's masher a bit more robust with regard to
handling and recovering from unexpected issues like this soon.  I've
since fixed all of the tags, and fresh repositories are mashing as we
speak.

Thanks for speaking up about this.  Since bodhi waits for the repos to
hit the mirrors before sending update announcements, if you notice
missing packages, please file a ticket against bodhi or rel-eng asap so
we can fix it.

Thanks,

luke



From jonstanley at gmail.com  Thu Oct 23 23:54:07 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 23 Oct 2008 19:54:07 -0400
Subject: pguiman has no maintainer
In-Reply-To: <20081024012832.68745033.mschwendt@gmail.com>
References: <20080828215641.03e13d63.mschwendt@gmail.com>
	<20081023122416.31f14c62.mschwendt@gmail.com>
	<4900F1DB.9040108@gmail.com>
	<20081024012832.68745033.mschwendt@gmail.com>
Message-ID: <da159fda0810231654v14631e14y39f2d1eb09366e53@mail.gmail.com>

Short circuiting is fine here since maintainer was @redhat and mail
bounces and user didn't update their FAS acct and no other contact
method is known.

This counts as a +1 from a FESCo member, sorry for the top post, I'm
out right now.

On 10/23/08, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Thu, 23 Oct 2008 14:51:23 -0700, Toshio Kuratomi wrote:
>
>> >> https://admin.fedoraproject.org/pkgdb/packages/name/pguiman
>> >>
>> >> Maintainer "odvorace" gives "user unknown" at Red Hat.
>> >> Pkg ACLs are locked down.
>> >
>> > Who takes care of issues like this?
>> > Is it necessary to follow the lengthy AWOL procedure?
>> > https://bugzilla.redhat.com/468160
>> >
>> I've opened the acl.
>>
>> Would FESCo like to short circuit the NonResponsiveMaintainers policy in
>> this case?  It seems like most of the steps in the procedure have been
>> followed except that the opening of the bugzilla bug was done last
>> instead of first.
>
> I didn't start any formal process. This is only one of a few packages
> where I stumbled into locked ACLs while fixing lots of unowned
> directories. Mailing the owner then failed.
>
> There's another open ticket which is unanswered for several months.
> The app crashes and possibly doesn't work much, given that it's only
> 0.0.1.
>
> The missing packager is also the upstream developer.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

-- 
Sent from my mobile device

Jon Stanley
Fedora Bug Wrangler
jstanley at fedoraproject.org



From petersen at redhat.com  Fri Oct 24 00:21:04 2008
From: petersen at redhat.com (Jens Petersen)
Date: Thu, 23 Oct 2008 20:21:04 -0400 (EDT)
Subject: Broken dependencies in Fedora 9 - 2008-10-23
In-Reply-To: <862113848.3210051224807561172.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <704320094.3210131224807664351.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

> package: scim-bridge-qt-0.4.15-5.fc9.i386 from fedora-9-x86_64
>   unresolved deps:
>      scim-bridge = 0:0.4.15-5.fc9

Yes, it seems scim-bridge-0.4.15-8.fc9 in f9 updates was not pushed multilib...

Should we open a ticket with releng about that?

Jens

ps CC me or the package owner in case we miss followups.



From mjs at clemson.edu  Fri Oct 24 01:37:26 2008
From: mjs at clemson.edu (Matthew Saltzman)
Date: Thu, 23 Oct 2008 21:37:26 -0400
Subject: R-devel going away
In-Reply-To: <200810231941.41824.jamatos@fc.up.pt>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<1224772939.3601.54.camel@localhost.localdomain>
	<1224786127.3898.97.camel@code.and.org>
	<200810231941.41824.jamatos@fc.up.pt>
Message-ID: <1224812246.5246.44.camel@valkyrie.localdomain>


On Thu, 2008-10-23 at 19:41 +0100, Jos? Matos wrote:
> On Thursday 23 October 2008 19:22:07 James Antill wrote:
> >  Well it kinda fits the "people expect foo-core + additions" _assuming_
> > CRAN is a requirement, but really why don't we just package more of the
> > R modules so CRAN usage isn't a requirement?
> 
> There are more than 1500 modules (the have been growing at an exponential rate 
> in the last years). So while we would like to see more R packages in Fedora in 
> are not even near to have a reasonable subset of R packaged.
> 
> So for the moment CRAN is really a requirement to use R in Fedora.

This situation seems to cry out for a solution like cpan2rpm for the
Perl Archive.
-- 
                Matthew Saltzman

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



From tibbs at math.uh.edu  Fri Oct 24 01:39:32 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 23 Oct 2008 20:39:32 -0500
Subject: R-devel going away
In-Reply-To: <1224812246.5246.44.camel@valkyrie.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<1224772939.3601.54.camel@localhost.localdomain>
	<1224786127.3898.97.camel@code.and.org>
	<200810231941.41824.jamatos@fc.up.pt>
	<1224812246.5246.44.camel@valkyrie.localdomain>
Message-ID: <ufazlkueppn.fsf@epithumia.math.uh.edu>

>>>>> "MS" == Matthew Saltzman <mjs at clemson.edu> writes:

MS> This situation seems to cry out for a solution like cpan2rpm for
MS> the Perl Archive.

I believe the existing R2spec handles this nicely.

 - J<



From andy at gohanman.com  Fri Oct 24 01:57:50 2008
From: andy at gohanman.com (Andy Theuninck)
Date: Thu, 23 Oct 2008 20:57:50 -0500
Subject: Packaging Guidelines: /opt
Message-ID: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>

I'm trying to put a package together for webmin. It wants to install
to libexec, but if I do that rpmlint (rightly) complains that there
are non-executable text files. Perl files & HTML files are intermixed
and separating them out would be a patching nightmare. With a bit of
sed scripting, I can coax the whole thing into a different base
directory.

The official packaging guidelines say Fedora follows the Filesystem
Hierarchy Standard, and as I read FHS /opt would be the most
appropriate place to dump this mess. If I try to use /opt/webmin
though, rpmlint pitches a fit about using /opt. Nothing in the
guidelines says I can't use /opt. Can I just ignore all these errors?

Also, neither the packing guidelines nor FHS make any mention of /var.
Maybe that's a more appropriate spot.

These are the packaging guidelines I've been referring to:
http://fedoraproject.org/wiki/Packaging/Guidelines



From konrad at tylerc.org  Fri Oct 24 02:15:51 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 23 Oct 2008 19:15:51 -0700
Subject: Packaging Guidelines: /opt
In-Reply-To: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
Message-ID: <200810231915.52105.konrad@tylerc.org>

On Thursday 23 October 2008 06:57:50 pm Andy Theuninck wrote:
> I'm trying to put a package together for webmin. It wants to install
> to libexec, but if I do that rpmlint (rightly) complains that there
> are non-executable text files. Perl files & HTML files are intermixed
> and separating them out would be a patching nightmare. With a bit of
> sed scripting, I can coax the whole thing into a different base
> directory.
>
> The official packaging guidelines say Fedora follows the Filesystem
> Hierarchy Standard, and as I read FHS /opt would be the most
> appropriate place to dump this mess. If I try to use /opt/webmin
> though, rpmlint pitches a fit about using /opt. Nothing in the
> guidelines says I can't use /opt. Can I just ignore all these errors?
>
> Also, neither the packing guidelines nor FHS make any mention of /var.
> Maybe that's a more appropriate spot.
>
> These are the packaging guidelines I've been referring to:
> http://fedoraproject.org/wiki/Packaging/Guidelines

Actually, the FHS explicitly mentions /var [0] and /opt [1]. And you can't use 
either for a package included in Fedora. (Or at least, you can't install your 
package to a /var/PKGNAME prefix.)

[0]: http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE31
[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE14

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From a.badger at gmail.com  Fri Oct 24 02:26:22 2008
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 23 Oct 2008 19:26:22 -0700
Subject: Packaging Guidelines: /opt
In-Reply-To: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
Message-ID: <4901324E.3070905@gmail.com>

Andy Theuninck wrote:
> I'm trying to put a package together for webmin. It wants to install
> to libexec, but if I do that rpmlint (rightly) complains that there
> are non-executable text files. Perl files & HTML files are intermixed
> and separating them out would be a patching nightmare. With a bit of
> sed scripting, I can coax the whole thing into a different base
> directory.
> 
Separating different types of files and getting upstream to accept the
patches is the right thing to do.

Failing to get buyin from upstream, separating them and symlinking is
acceptable but not encouraged.

This brief section of the guidelines has useful information about where
things might belong in this case::
  http://fedoraproject.org/wiki/Packaging/Guidelines#Web_Applications

If you look at moin and other web packages, you'll see that they place a
lot of files into /usr/share, perhaps how you're intending to use /opt.
 However, you do have to make sure you aren't putting executables,
binaries, or files that need to be written there.

> The official packaging guidelines say Fedora follows the Filesystem
> Hierarchy Standard, and as I read FHS /opt would be the most
> appropriate place to dump this mess. If I try to use /opt/webmin
> though, rpmlint pitches a fit about using /opt. Nothing in the
> guidelines says I can't use /opt. Can I just ignore all these errors?
> 

The FHS says: /opt is reserved for the installation of add-on
application software packages.

Anything packaged by Fedora is part of the system packaging rather than
an addon so we stay out of /opt.

> Also, neither the packing guidelines nor FHS make any mention of /var.
> Maybe that's a more appropriate spot.
> 
For some content, yes.  But not for the bulk of it.

The Guidelines section I linked to earlier mentions that /var is not the
place for (most of) these files.

-Toshio

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

From mattdm at mattdm.org  Fri Oct 24 02:30:06 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 23 Oct 2008 22:30:06 -0400
Subject: Packaging Guidelines: /opt
In-Reply-To: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
Message-ID: <20081024023006.GA1953@jadzia.bu.edu>

On Thu, Oct 23, 2008 at 08:57:50PM -0500, Andy Theuninck wrote:
> Hierarchy Standard, and as I read FHS /opt would be the most
> appropriate place to dump this mess. If I try to use /opt/webmin

I'm surprised the Fedora packaging guidelines don't mention this explicitly,
but historically Red Hat and Fedora have read "add-on application software
packages" to mean third-party packages -- i.e., not things we package.

> Also, neither the packing guidelines nor FHS make any mention of /var.
> Maybe that's a more appropriate spot.

These files aren't intended to change, are they? In that case /var really
shouldn't be in the picture. 

There's some precedent for packages using /usr/lib/packagename for this
purpose -- bugzilla, for example, and, um, anaconda.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mattdm at mattdm.org  Fri Oct 24 02:32:42 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 23 Oct 2008 22:32:42 -0400
Subject: Packaging Guidelines: /opt
In-Reply-To: <20081024023006.GA1953@jadzia.bu.edu>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
	<20081024023006.GA1953@jadzia.bu.edu>
Message-ID: <20081024023242.GA2472@jadzia.bu.edu>

On Thu, Oct 23, 2008 at 10:30:06PM -0400, Matthew Miller wrote:
> There's some precedent for packages using /usr/lib/packagename for this
> purpose -- bugzilla, for example, and, um, anaconda.

I mean /usr/share. And looks like the only thing anaconda puts there is
completely legitimate image data so ignore that part.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From fedora at leemhuis.info  Fri Oct 24 05:11:32 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 24 Oct 2008 07:11:32 +0200
Subject: FESCo Meeting Summary for 2008-10-22
In-Reply-To: <1224791613.4174.4.camel@kennedy>
References: <1224791613.4174.4.camel@kennedy>
Message-ID: <49015904.6080803@leemhuis.info>

On 23.10.2008 21:53, Brian Pepple wrote:
> === Features ===
> * FESCo rejected a proposal to revert the Sbin Sanity(1) feature.
>       * For: kick_
>       * Against: dwmw2, j-rod, bpepple, notting, dgilmore, nirik
>       * Abstain: jwb
>      1. https://fedoraproject.org/wiki/Features/SbinSanity

I think FESCo is doing a big mistake here.

So FWIW, I totally agree with what Ville said in
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html

I'm willing to help Ville and Matthew making a real solution, where sbin 
stays "root commands" only, and where package that are right now get 
into he search path for ordinary users (either with symlinks or by 
moving the binaries). But it's IMHO best for everyone if we do that for 
F11. Come on, we had /sbin not in the path for more then how many years, 
so what is one half year more (especially as everyone that dislikes it 
is used to enable it already)?


But what's even worse: The summary IMHO misses two important details:

> dwmw2> | If they want to come to us _quickly_ (i.e. next week) with a concrete, ready-to-ship alternative, then we can consider it.
> dgilmore> | if there was a concrete workable alternative then i think we can consider it

Something like that really should have been mentioned in the summary.

CU
knurd



From lakshmipathi.g at gmail.com  Fri Oct 24 06:04:50 2008
From: lakshmipathi.g at gmail.com (lakshmi pathi)
Date: Fri, 24 Oct 2008 11:34:50 +0530
Subject: Need a help
Message-ID: <ae2f51270810232304j49e20ef6x2c6bed20db4c5c75@mail.gmail.com>

Hi,
I'm looking for a developer who is intersted creating a binary and
source rpm for undelete tool.
(I was told ,it was easy to learn and try on my own,but i'm finding it
difficult and not getting it correctly
so decided to get help our big community :) )

I welcome any open source programmers,to take up this task.I also wish
to submit the
same for review on fedora packages.

You can download the complete source from
http://sourceforge.net/projects/giis
or
www.giis.co.in


ps: If this not the correct distribution list for such activities
,please redirect me to correct DL
and ignore this mail.

Cheers,
Lakshmipathi.G



From jonathan at jonmasters.org  Fri Oct 24 06:04:54 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Fri, 24 Oct 2008 02:04:54 -0400
Subject: FESCo Meeting Summary for 2008-10-22
In-Reply-To: <49015904.6080803@leemhuis.info>
References: <1224791613.4174.4.camel@kennedy> <49015904.6080803@leemhuis.info>
Message-ID: <1224828294.26966.221.camel@perihelion.int.jonmasters.org>

On Fri, 2008-10-24 at 07:11 +0200, Thorsten Leemhuis wrote:
> On 23.10.2008 21:53, Brian Pepple wrote:
> > === Features ===
> > * FESCo rejected a proposal to revert the Sbin Sanity(1) feature.
> >       * For: kick_
> >       * Against: dwmw2, j-rod, bpepple, notting, dgilmore, nirik
> >       * Abstain: jwb
> >      1. https://fedoraproject.org/wiki/Features/SbinSanity
> 
> I think FESCo is doing a big mistake here.
> 
> So FWIW, I totally agree with what Ville said in
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html

If you're writing scripts and not explicitly calling out the binary
location, then it's not surprising if your scripts break later. I know
it's nice to always assume a particular PATH, but it's not good practice
any more than including or not including sbin in the PATH to begin with.
And people using tab-completion can get used to the new binary names.

FWIW, I think including sbin in the path is only about *10 years too
late*, everyone else is already laughing that Fedora didn't do this, so
really it doesn't need to wait for yet another 1.5 years to get done :)

Jon.




From nicolas.mailhot at laposte.net  Fri Oct 24 06:27:56 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 24 Oct 2008 08:27:56 +0200
Subject: Packaging Guidelines: /opt
In-Reply-To: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
Message-ID: <1224829676.1562.1.camel@arekh.okg>

Le jeudi 23 octobre 2008 ? 20:57 -0500, Andy Theuninck a ?crit :

> The official packaging guidelines say Fedora follows the Filesystem
> Hierarchy Standard, and as I read FHS /opt would be the most
> appropriate place to dump this mess. 

opt is the right place to dump messes and is good enough for ISVs with
no ambitions but Fedora does not package messes so you have to try
harder.
-- 
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/20081024/0925b73c/attachment.sig>

From nicolas.mailhot at laposte.net  Fri Oct 24 06:29:54 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 24 Oct 2008 08:29:54 +0200
Subject: Packaging Guidelines: /opt
In-Reply-To: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
Message-ID: <1224829794.1562.2.camel@arekh.okg>

Le jeudi 23 octobre 2008 ? 20:57 -0500, Andy Theuninck a ?crit :

> Also, neither the packing guidelines nor FHS make any mention of /var.
> Maybe that's a more appropriate spot.

"Applications must generally not add directories to the top level
of /var. Such directories should only be added if they have some
system-wide implication, and in consultation with the FHS mailing list."

There, read again
-- 
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/20081024/55bd69bd/attachment.sig>

From rc040203 at freenet.de  Fri Oct 24 06:32:30 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 24 Oct 2008 08:32:30 +0200
Subject: FESCo Meeting Summary for 2008-10-22
In-Reply-To: <1224828294.26966.221.camel@perihelion.int.jonmasters.org>
References: <1224791613.4174.4.camel@kennedy> <49015904.6080803@leemhuis.info>
	<1224828294.26966.221.camel@perihelion.int.jonmasters.org>
Message-ID: <1224829950.6682.9.camel@beck.corsepiu.local>

On Fri, 2008-10-24 at 02:04 -0400, Jon Masters wrote:
> On Fri, 2008-10-24 at 07:11 +0200, Thorsten Leemhuis wrote:
> > On 23.10.2008 21:53, Brian Pepple wrote:
> > > === Features ===
> > > * FESCo rejected a proposal to revert the Sbin Sanity(1) feature.
> > >       * For: kick_
> > >       * Against: dwmw2, j-rod, bpepple, notting, dgilmore, nirik
> > >       * Abstain: jwb
> > >      1. https://fedoraproject.org/wiki/Features/SbinSanity
> > 
> > I think FESCo is doing a big mistake here.
+1

> > So FWIW, I totally agree with what Ville said in
> > https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html
> 
> If you're writing scripts and not explicitly calling out the binary
> location, then it's not surprising if your scripts break later. I know
> it's nice to always assume a particular PATH, but it's not good practice
> any more than including or not including sbin in the PATH to begin with.
> And people using tab-completion can get used to the new binary names.
> 
> FWIW, I think including sbin in the path is only about *10 years too
> late*, everyone else is already laughing that Fedora didn't do this, so
> really it doesn't need to wait for yet another 1.5 years to get done :)
I disagree. Fedora not having gone this naive road is one detail why
users are using Fedora.





From cdahlin at redhat.com  Fri Oct 24 06:33:54 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 24 Oct 2008 02:33:54 -0400
Subject: Packaging Guidelines: /opt
In-Reply-To: <1224829676.1562.1.camel@arekh.okg>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
	<1224829676.1562.1.camel@arekh.okg>
Message-ID: <49016C52.9000900@redhat.com>

Nicolas Mailhot wrote:
> Le jeudi 23 octobre 2008 ? 20:57 -0500, Andy Theuninck a ?crit :
>
>   
>> The official packaging guidelines say Fedora follows the Filesystem
>> Hierarchy Standard, and as I read FHS /opt would be the most
>> appropriate place to dump this mess. 
>>     
>
> opt is the right place to dump messes and is good enough for ISVs with
> no ambitions but Fedora does not package messes so you have to try
> harder.
>   
Easy, he's here because he wants to do the right thing, and he's not 
upstream, so there's no reason to clueby4 him just yet.

You might do what apache does and simply place the files where they go, 
then symlink them to a conf directory in /etc . You'd be doing it on a 
much larger scale than apache, but until you get upstream to suck less, 
you at least have a precedent for it (though doing it for apache hasn't 
particularly encouraged them to change their goofy-as-hell recommended 
file layout).

--CJD



From jamatos at fc.up.pt  Fri Oct 24 06:52:17 2008
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Fri, 24 Oct 2008 07:52:17 +0100
Subject: [Fedora-r-devel-list] Re: R-devel going away
In-Reply-To: <22af238a0810231508j183fd334m6a1dc272e518f6b0@mail.gmail.com>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<200810231941.41824.jamatos@fc.up.pt>
	<22af238a0810231508j183fd334m6a1dc272e518f6b0@mail.gmail.com>
Message-ID: <200810240752.18594.jamatos@fc.up.pt>

On Thursday 23 October 2008 23:08:53 George N. White III wrote:
>
> There have always been conflicts between the CRAN package system and
> Fedora or other linux packaging Guidelines.   Users can install CRAN
> packages without root privileges, but then the search function won't know
> about the user's packages, and packages that rely on other library (gsl,
> hdf5, etc) still need -dev RPM's.   Linux distros should not be trying to
> enforce guidelines
> for mainstream packages with their own robust package management and
> archive networks.

Playing devil's advocate I should remark that first each language is building 
its own repository and packaging system in a sense we have lots of equivalents 
of (yum+rpm) for each language (perl,  php, python, R, tex, ...).

On the other hand for the system to be really useful it must use the least 
possible denominator (read the dumbest wins- pun intended ;-) ).

> Instead, they should look for ways to improve support
> for users who rely on those 3rd party systems.  For example:
>
> R-base: basic runtime without dev dependencies, for sites that provide
> binary CRAN packages (e.g., on a shared directory) so users don't need to
> do compiles.
>
> R-core: R-base + -dev dependencies for those who want to install source
> packages from CRAN (e.g., most individual R users)
>
> R-X-sup(plement): -dev dependencies needed to build package X (e.g.,
> R-hdf5-sup requires hdf5-dev for the hdf5 package from CRAN, gsl-dev
> for gsl, etc.).  These aren't strictly necessary, but would serve to
> link package versions on CRAN with the versions of the support libs in
> Fed,
> something that can take some effort (e.g., peeking in the sources) to
> determine.   For sites
> where users need to ask admins to install libraries, this simplifies
> the problem of telling the admin which libs to install.

I am not sure if this is right path or the right balance.

Another possible choice is to expand R2spec in scope and not only create rpm 
spec files but to discover the different dependencies and how they are solved 
inside.

There is no reason that we can not rebuild the whole CRAN (or almost all of 
it) automatically.

> In the long run, linux distros should look at devising ways to capture
> information from these
> 3rd party package managers to help resolve dependencies automatically.

As everything with free software the survival of the fittest means that this 
will only happen if there are people interested in spending resources to make 
this possible.
-- 
Jos? Ab?lio





From aphukan.fedora at gmail.com  Fri Oct 24 07:10:10 2008
From: aphukan.fedora at gmail.com (Amitakhya Phukan)
Date: Fri, 24 Oct 2008 12:40:10 +0530
Subject: Need a help
In-Reply-To: <ae2f51270810232304j49e20ef6x2c6bed20db4c5c75@mail.gmail.com>
References: <ae2f51270810232304j49e20ef6x2c6bed20db4c5c75@mail.gmail.com>
Message-ID: <490174D2.4070005@gmail.com>

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

lakshmi pathi wrote:
> Hi, I'm looking for a developer who is intersted creating a binary
> and source rpm for undelete tool. (I was told ,it was easy to learn
> and try on my own,but i'm finding it difficult and not getting it
> correctly so decided to get help our big community :) )
>
> I welcome any open source programmers,to take up this task.I also
> wish to submit the same for review on fedora packages.
>
> You can download the complete source from
> http://sourceforge.net/projects/giis or www.giis.co.in
>
>
> ps: If this not the correct distribution list for such activities
> ,please redirect me to correct DL and ignore this mail.
>
> Cheers, Lakshmipathi.G
>
Hi,

Doesn't this help ??

http://docs.fedoraproject.org/drafts/rpm-guide-en/

Regards,
Amit.

p.s: Try searching the Red Hat docs and manuals as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkBdNIACgkQisV6fTFpwA3LrQCdEgnz927LC+AHVeCxDFTLEbdv
o6YAn18T1ZNb5J88Nn4LBbPWch7ZMsHl
=55Uw
-----END PGP SIGNATURE-----



From jamatos at fc.up.pt  Fri Oct 24 07:18:45 2008
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Fri, 24 Oct 2008 08:18:45 +0100
Subject: R-devel going away
In-Reply-To: <49008A98.1010204@pingoured.fr>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<20081023142750.GA20579@jadzia.bu.edu>
	<49008A98.1010204@pingoured.fr>
Message-ID: <200810240818.46092.jamatos@fc.up.pt>

On Thursday 23 October 2008 15:30:48 Pierre-Yves wrote:
> Would the lake of packager be a suffisant answer ?
>
> FYI:
> http://rpms.famillecollet.com/rpmphp/rpm.php?type=R

It would be interesting to get a monthly report like this in fedora-r-devel 
periodically (monthly).

I am aware that I have packages to update and I was expecting for R-2.8.0 to 
be released to update them. In any case a table like that always helps in 
those cases where the update slipped under the radar. :-)

> Regards,
>
> Pierre

-- 
Jos? Ab?lio



From forum at ru.bir.ru  Fri Oct 24 07:22:08 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Fri, 24 Oct 2008 11:22:08 +0400
Subject: Need a help
In-Reply-To: <ae2f51270810232304j49e20ef6x2c6bed20db4c5c75@mail.gmail.com>
References: <ae2f51270810232304j49e20ef6x2c6bed20db4c5c75@mail.gmail.com>
Message-ID: <gdrt30$5ei$1@ger.gmane.org>

Hello.

I can package it.
I try do it in few days and submit for review.

lakshmi pathi ?????:
> Hi,
> I'm looking for a developer who is intersted creating a binary and
> source rpm for undelete tool.
> (I was told ,it was easy to learn and try on my own,but i'm finding it
> difficult and not getting it correctly
> so decided to get help our big community :) )
> 
> I welcome any open source programmers,to take up this task.I also wish
> to submit the
> same for review on fedora packages.
> 
> You can download the complete source from
> http://sourceforge.net/projects/giis
> or
> www.giis.co.in
> 
> 
> ps: If this not the correct distribution list for such activities
> ,please redirect me to correct DL
> and ignore this mail.
> 
> Cheers,
> Lakshmipathi.G
> 



From rakesh.pandit at gmail.com  Fri Oct 24 07:26:47 2008
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Fri, 24 Oct 2008 12:56:47 +0530
Subject: help required for thoggen
Message-ID: <b401d2530810240026i109561c1xb60c2be5f26f68fa@mail.gmail.com>

http://thoggen.net/
Can we have it in fedora. It rips DVD and supports Ogg/Theora (supported).
Later on they are planning to add support to AVI/divx/mpeg4 And the
required gstream codecs are on Livna or RPMFusion

The program is very good and useful. So, I wanted it in.
I am not sure about whether it legally acceptable?

Comments ?

-- 
rakesh



From pingou at pingoured.fr  Fri Oct 24 07:43:19 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Fri, 24 Oct 2008 09:43:19 +0200
Subject: [Fedora-r-devel-list] Re: R-devel going away
In-Reply-To: <200810240752.18594.jamatos@fc.up.pt>
References: <1224770108.3601.40.camel@localhost.localdomain>	<200810231941.41824.jamatos@fc.up.pt>	<22af238a0810231508j183fd334m6a1dc272e518f6b0@mail.gmail.com>
	<200810240752.18594.jamatos@fc.up.pt>
Message-ID: <49017C97.6040808@pingoured.fr>

Jos? Matos wrote:
> On Thursday 23 October 2008 23:08:53 George N. White III wrote:
>> There have always been conflicts between the CRAN package system and
>> Fedora or other linux packaging Guidelines.   Users can install CRAN
>> packages without root privileges, but then the search function won't know
>> about the user's packages, and packages that rely on other library (gsl,
>> hdf5, etc) still need -dev RPM's.   Linux distros should not be trying to
>> enforce guidelines
>> for mainstream packages with their own robust package management and
>> archive networks.
> 
> Playing devil's advocate I should remark that first each language is building 
> its own repository and packaging system in a sense we have lots of equivalents 
> of (yum+rpm) for each language (perl,  php, python, R, tex, ...).
> 
> On the other hand for the system to be really useful it must use the least 
> possible denominator (read the dumbest wins- pun intended ;-) ).
> 
>> Instead, they should look for ways to improve support
>> for users who rely on those 3rd party systems.  For example:
>>
>> R-base: basic runtime without dev dependencies, for sites that provide
>> binary CRAN packages (e.g., on a shared directory) so users don't need to
>> do compiles.
>>
>> R-core: R-base + -dev dependencies for those who want to install source
>> packages from CRAN (e.g., most individual R users)
>>
>> R-X-sup(plement): -dev dependencies needed to build package X (e.g.,
>> R-hdf5-sup requires hdf5-dev for the hdf5 package from CRAN, gsl-dev
>> for gsl, etc.).  These aren't strictly necessary, but would serve to
>> link package versions on CRAN with the versions of the support libs in
>> Fed,
>> something that can take some effort (e.g., peeking in the sources) to
>> determine.   For sites
>> where users need to ask admins to install libraries, this simplifies
>> the problem of telling the admin which libs to install.
> 
> I am not sure if this is right path or the right balance.
> 
> Another possible choice is to expand R2spec in scope and not only create rpm 
> spec files but to discover the different dependencies and how they are solved 
> inside.
> 
> There is no reason that we can not rebuild the whole CRAN (or almost all of 
> it) automatically.

R2spec [1] can handles the generation of spec for R-libraries pretty 
easily, but the spec always needs some revision behind.

However, I had started some time ago a small script to update the spec 
file when there is a new release of an already package R-library. This 
might be something that I should develop maybe a bit more now 
(especially since Bioconductor 2.3 has been released with R 2.8.0)

Should that be included in R2spec or in a separate tool ?

> 
>> In the long run, linux distros should look at devising ways to capture
>> information from these
>> 3rd party package managers to help resolve dependencies automatically.
> 
> As everything with free software the survival of the fittest means that this 
> will only happen if there are people interested in spending resources to make 
> this possible.

--
For those who do not know it
R2spec https://fedorahosted.org/r2spec
Present in Fedora 8,9 and rawhide (10) and in EPEL 4 and 5.
--

Regards,
Pierre



From fedora at leemhuis.info  Fri Oct 24 07:51:32 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 24 Oct 2008 09:51:32 +0200
Subject: help required for thoggen
In-Reply-To: <b401d2530810240026i109561c1xb60c2be5f26f68fa@mail.gmail.com>
References: <b401d2530810240026i109561c1xb60c2be5f26f68fa@mail.gmail.com>
Message-ID: <49017E84.80609@leemhuis.info>

On 24.10.2008 09:26, Rakesh Pandit wrote:
> http://thoggen.net/
> Can we have it in fedora. It rips DVD and supports Ogg/Theora (supported).
> Later on they are planning to add support to AVI/divx/mpeg4 And the
> required gstream codecs are on Livna or RPMFusion
> 
> The program is very good and useful. So, I wanted it in.
> I am not sure about whether it legally acceptable?

Just FYI, thoggen is in RPM Fusion (came from freshrpms), so that 
package might be a good base for a Fedora package in case thoggen is 
acceptable in Fedora.

Ohh, and of course I'm all for moving packages from RPM Fusion to Fedora 
if possible. Xine is also in RPM Fusion, but might be acceptable in 
Fedora as well (we already have xine-lib in Fedora); somebody just needs 
to take a closer look and submit it for review; the maintainers of xine 
in freshrpms and livna afaics just didn't get around to drive that forward.

CU
knurd



From lakshmipathi.g at gmail.com  Fri Oct 24 08:04:20 2008
From: lakshmipathi.g at gmail.com (lakshmi pathi)
Date: Fri, 24 Oct 2008 13:34:20 +0530
Subject: Need a help
Message-ID: <ae2f51270810240104g51621c20qd6c372667b928a7b@mail.gmail.com>

Hi,
Just I want clarify a bit on my previous mail,
*Its not a paid job :)

Cheers,
Lakshmipathi.G


---------------------
Date: Fri, 24 Oct 2008 11:34:50 +0530
From: "lakshmi pathi" <lakshmipathi.g at gmail.com>
Subject: Need a help
To: fedora-devel-list at redhat.com
Message-ID:
       <ae2f51270810232304j49e20ef6x2c6bed20db4c5c75 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,
I'm looking for a developer who is intersted creating a binary and
source rpm for undelete tool.
(I was told ,it was easy to learn and try on my own,but i'm finding it
difficult and not getting it correctly
so decided to get help our big community :) )

I welcome any open source programmers,to take up this task.I also wish
to submit the
same for review on fedora packages.

You can download the complete source from
http://sourceforge.net/projects/giis
or
www.giis.co.in


ps: If this not the correct distribution list for such activities
,please redirect me to correct DL
and ignore this mail.

Cheers,
Lakshmipathi.G



From pmatilai at laiskiainen.org  Fri Oct 24 08:21:21 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 24 Oct 2008 11:21:21 +0300 (EEST)
Subject: providing what they require
In-Reply-To: <200810230944.53271.ville.skytta@iki.fi>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
	<200810230944.53271.ville.skytta@iki.fi>
Message-ID: <alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>

On Thu, 23 Oct 2008, Ville Skytt? wrote:

> On Thursday 23 October 2008, seth vidal wrote:
>
>> Yes - if the pkg provides something it requires then the requires can be
>> removed.
>>
>> A simple addition to the rpmbuild process to remove these items from the
>> requires wouldn't hurt.
>
> When I suggested this on rpm-maint a little over a year ago, there were some
> objections because that would render rpm's --filerequire less useful/correct
> than it is today.  Maybe it wasn't implemented because of that or just
> because of lack of manpower at the time.

Pruning out automatically generated self-requires is about three lines of 
code, couple more to make it configurable. That's not the issue.

> http://lists.rpm.org/pipermail/rpm-maint/2007-July/001578.html
>
> The objection is valid per se, --filerequire would suffer (but not become
> entirely useless).  I wouldn't personally mind inflicting some inaccuracy
> into it if the gains are large enough.  I got a 7.3% decrease estimate in
> overall number of dependencies in Fedora which should be order-of-magnitude
> correct (see above post for more details).

FWIW the number of self-requires on Fedora is vastly larger than what 
plain upstream rpm would create, due to the patch that generates soname 
dependencies from symlinks to dso's. For example:

[pmatilai at localhost ~]$ rpm -q --filerequire cdparanoia-libs
/usr/lib64/libcdda_interface.so	R libcdda_interface.so.0()(64bit)
/usr/lib64/libcdda_interface.so.0	R libcdda_interface.so.0()(64bit)
/usr/lib64/libcdda_interface.so.0.10.0	R libc.so.6()(64bit) R 
libc.so.6(GLIBC_2.2.5)(64bit) R libc.so.6(GLIBC_2.3)(64bit) R 
libc.so.6(GLIBC_2.4)(64bit) R libm.so.6()(64bit) R 
libm.so.6(GLIBC_2.2.5)(64bit) R rtld(GNU_HASH)

Of course those would be gone too if self-requires were pruned.

> But if this can't be done in rpm(build), it probably can in createrepo as I
> don't think something like --filerequire is (or even can be) implemented in
> any tools using the metadata.

As it is now, every dependency in a package gets unconditionally recorded, 
regardless of where the provider comes from. It's a very straightforward 
rule. And yes it causes some unwanted side-effects, such as the one noted 
by Bill here 
http://lists.rpm.org/pipermail/rpm-maint/2007-July/001580.html and header 
bloat. Changing that is possible and even trivial, it just "breaks" fairly 
long time rpm behavior and opens up a different can of worms (a 
dirt-simple rule comes bunch of special cases). Making it configurable 
via macro would push the decision to vendors and packagers, but ...

While speaking of require/provide bloat, Seth's script filters out one 
major source of them:
         if n.startswith('config('): # these are funky
             continue

IMO they're not funky, they're absolutely useless. The idea behind those 
is that you can provide alternate configuration for a package, which is 
fine and well, except it's very broken by design:

Say you have package foo with some configuration and myconfig-foo with a 
custom config for it. The idea is that you can install foo with 
--noconfigs but as foo requires (automatically) config(foo), this should 
not be possible unless there's another package in the transaction 
providing config(foo). Except that the provide is not pruned at runtime 
with --noconfigs like it should... But lets imagine it did that: so you 
provide your own configuration in the transaction, ie "rpm -Uvh 
--noconfigs foo.rpm myconfig-foo.rpm". --noconfigs is a per-transaction 
flag, so the config files from myconfig-foo wouldn't be installed either. 
Oops. And for this misfeature, every package with a config file in it, 
carries an extra provide + require on itself.

 	- Panu -



From forum at ru.bir.ru  Fri Oct 24 08:21:28 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Fri, 24 Oct 2008 12:21:28 +0400
Subject: Need a help
In-Reply-To: <ae2f51270810240104g51621c20qd6c372667b928a7b@mail.gmail.com>
References: <ae2f51270810240104g51621c20qd6c372667b928a7b@mail.gmail.com>
Message-ID: <gds0i9$gsh$1@ger.gmane.org>

lakshmi pathi ?????:
> Hi,
> Just I want clarify a bit on my previous mail,
> *Its not a paid job :)

Off course! Who speak about paid?? It is a world of free software :)
But I want clarify - you want to do it by yourself? And search only help 
and documentation? In this case you may ask question in this list.



From fedora at matbooth.co.uk  Fri Oct 24 09:16:10 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Fri, 24 Oct 2008 09:16:10 +0000
Subject: Regarding install options
In-Reply-To: <200810231843.m9NIhg3t004015@laptop14.inf.utfsm.cl>
References: <1223882953.3564.1509.camel@beck.corsepiu.local>
	<1223930747.3327.41.camel@luminos.localdomain>
	<20081013221048.GL2738@free.fr>
	<1223937363.3056.10.camel@luminos.localdomain>
	<48FE8759.6010302@redhat.com>
	<1224686759.3417.12.camel@luminos.localdomain>
	<4900155B.4060704@redhat.com>
	<1224780968.26785.8.camel@luminos.localdomain>
	<4900B504.7030000@leemhuis.info>
	<200810231843.m9NIhg3t004015@laptop14.inf.utfsm.cl>
Message-ID: <9497e9990810240216x7f5c8709gd56fd3668b0f2c0f@mail.gmail.com>

On Thu, Oct 23, 2008 at 6:43 PM, Horst H. von Brand
<vonbrand at inf.utfsm.cl> wrote:
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>> On 23.10.2008 18:56, Jesse Keating wrote:
>> > Neither will the meaning of 'minimal' be.  Will it have networking?
>> > Will it have yum?  Will it have ssh?  Will it speak my language?  So on,
>> > and so forth.
>>
>> Not sure if my mind plays tricks with me, but I got the impression
>> that I hear something like the above as a "shoot the discussion down"
>> argument every few days right now... This is starting to annoy me, as
>> statements like the above don't lead anywhere: Decisions have to be
>> made; repeatably pointing out that it's hard to do them doesn't bring
>> us a tiny bit further. So please:
>>
>> Just let a group of interested people make a decision and realize it
>> as a feature for F11! Then we hopefully can get rid of this topic
>> (which seems to pop up every few weeks...).
>
> That /has/ been done (yes, I've been around since Red Hat 3.x days), and it
> made /never/ everybody happy, thus the recurring flamewars on the
> topic. When they say here that it _can't_ be solved it is not out of
> lazyness, it is out of (often bitter) experience.
>
> What is minimal for me is sorely lacking while barroquely bloated for the
> next interested party.
> --
> 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 2340000       Fax:  +56 32 2797513
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


I have to agree with Jesse and Horst because I remember the "minimal"
install option too and any option I chose always disappointed because
I found I had to add stuff to the minimal installs and remove stuff
from the other installs.

So I like what we currently have more. It builds up less expectation
and therefore disappoints less. ;-)  And that is all you can hope for
given the extreme visability of the feature.



-- 
Mat Booth
www.matbooth.co.uk



From Juha.Tuomala at iki.fi  Fri Oct 24 09:43:12 2008
From: Juha.Tuomala at iki.fi (Juha Tuomala)
Date: Fri, 24 Oct 2008 12:43:12 +0300
Subject: kde needs mysql-server ??
In-Reply-To: <48FF046A.3000501@nobugconsulting.ro>
References: <48FF046A.3000501@nobugconsulting.ro>
Message-ID: <200810241243.12892.Juha.Tuomala@iki.fi>



On Wednesday 22 October 2008 13:46:02 Manuel Wolfshant wrote:
> 
>     Do we really need mysql-server on a _desktop_ running kde ?
> 

A related discussion in dot a while ago:

  http://dot.kde.org/1209500572/1209540984/


Tuju

-- 
Varo hattup?isi? autoilijoita.



From rawhide at fedoraproject.org  Fri Oct 24 10:25:40 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 24 Oct 2008 10:25:40 +0000 (UTC)
Subject: rawhide report: 20081024 changes
Message-ID: <20081024102540.CAD6E1F824A@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct 24 06:01:04 UTC 2008

New package R-nws
        R functions for NetWorkSpaces and Sleigh
New package etherboot
        Etherboot collection of boot roms
New package openalchemist
        Reflection game
New package perl-Catalyst-Model-XMLRPC
        XMLRPC model class for Catalyst
New package rxtx
        Parallel communication for the Java Development Toolkit
Updated Packages:

OpenIPMI-2.0.14-5.fc10
----------------------
* Thu Oct 23 18:00:00 2008 Jan Safranek <jsafrane at redhat.com> - 2.0.14-5
- fix typos in the descriptions
- add .desktop file for openipmigui tool


PackageKit-0.3.8-3.fc10
-----------------------
* Thu Oct 23 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.8-3
- Add a patch from upstream to pkcon install foo


R-car-1.2-4.fc10
----------------
* Thu Oct 23 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> 1.2-4
- Update to 1.2-9


R-multcomp-1.0-2.fc10
---------------------
* Thu Oct 23 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 1.0-2
- Update to 1.0-3


R-systemfit-1.0-4.fc10
----------------------
* Thu Oct 23 18:00:00 2008 Orion Poplawski <orion at cora.nwra.com> - 1.0-4
- Update to 1.0-7
- New source URL


WebKit-1.0.0-0.15.svn37790.fc10
-------------------------------
* Thu Oct 23 18:00:00 2008 Peter Gordon <peter at thecodergeek.com> 1.0.0-0.15.svn37790
- Update to new upstream snapshot (SVN 37790).
- Default to freetype font backend for improved CJK/Unicode support. (#448693)
- Add some notes to the build options comments block.
- Add a build-time conditional for jit

* Sun Aug 24 18:00:00 2008 Peter Gordon <peter at thecodergeek.com> 1.0.0-0.14.svn35904
- Update to new upstream snapshot (SVN 35904)

* Fri Jul  4 18:00:00 2008 Peter Gordon <peter at thecodergeek.com>
- Remove outdated and unnecessary GCC 4.3 patch:
  - gcc43.patch
- Fix the curl-devel BuildRequire conditional. (It is only needed when building
  against curl instead of libsoup.)


amanda-2.6.0p2-3.fc10
---------------------
* Thu Oct 23 18:00:00 2008 Daniel Novotny <dnovotny at redhat.com> 2.6.0p2-3
- added trailing || : in the %pre client script


audit-1.7.8-2.fc10
------------------
* Thu Oct 23 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.8-2
- Fix segfault when using file input to aureport
- Quieten down messages about missing gssapi support


bash-3.2-28.fc10
----------------
* Thu Oct 23 18:00:00 2008 Roman Rakus <rrakus at redhat.com> - 3.2-28
- Removing Requires for mktemp and ncurses, which cause
  dependencing loop
- Enabling #define SSH_SOURCE_BASHRC, because ssh changed.
  Resolves: #458839
- Catch signals right after calling execve()
  Resolves: #455548


bluez-gnome-1.8-7.fc10
----------------------
* Thu Oct 23 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-7
- Add support for pairing a few GPS devices (#464446)


classpathx-mail-1.1.1-7.1.fc10
------------------------------
* Thu Oct 23 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1.1-7.1
- reintroduce release numbering scheme that has been missing since -5

* Thu Oct 23 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1.1-7
- remove javadoc scriptlets (Resolves: #205191)
- replace /usr/sbin with %{_sbindir}


comps-extras-15-1
-----------------
* Thu Oct 23 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 15-1
- revert back to non-echo icons
- add icons for Haskell, Ruby


dhcp-4.0.0-30.fc10
------------------
* Thu Oct 23 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 12:4.0.0-30
- Fix dhclient.conf man page and sample config file to say 'supersede
  domain-search', which is what was actually demonstrated (#467955)


directfb-1.2.6-3.fc10
---------------------
* Wed Oct 22 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.2.6-3
- Disable the sorelease downgrade
- Exclude directfb-config - Fix multiarch conflicts #341011.

* Mon Oct 20 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.2.6-2
- Disable ppc asm
- Drop the asm/type.h patch (fixed upstream)

* Mon Sep 29 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.2.6-1
- Update to 1.2.6

* Wed Jul 16 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.2.0-1
- Update to 1.2.0 (final)
- Add BR libvncserver-devel
- Enable Unique WM
- Enabled multi (Requires linux-fusion kernel module)

* Sat Jun 21 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.2.0-0.1.rc1
- Update to 1.2.0-rc1

* Sat Jun 21 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.1.1-1
- Update to 1.1.1
- Add --enable-multi


eclipse-3.4.1-5.fc10
--------------------
* Thu Oct 23 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 3.4.1-5
- Fix splashscreen (#467259).


eclipse-mylyn-3.0.3-2.fc10
--------------------------

evolution-brutus-1.2.27-2.fc10
------------------------------
* Thu Oct 23 18:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.2.27-2
- Rebuild for new camel library from e-d-s


evolution-data-server-2.24.1-2.fc10
-----------------------------------
* Thu Oct 23 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.24.1-2.fc10
- Add patch for RH bug #467804 (remove console spew).


evolution-zimbra-0.1.1-3.fc10
-----------------------------
* Thu Oct 23 18:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.1.1-3
- Rebuild for new camel library from e-d-s


filezilla-3.1.5-1.fc10
----------------------
* Fri Oct 24 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.5-1
- Update to 3.1.5


generic-logos-10.0.0-1.fc10
---------------------------
* Thu Oct 23 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 10.0.0-1
- update for current fedora-logos, with Solar theme


ghc-6.8.3-10.fc10
-----------------
* Thu Oct 23 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 6.8.3-9
- use gen_contents_index to re-index haddock
- add %pkg_docdir to cabal_configure
- requires(post) haddock09 for doc
- improve doc file lists
- no longer need to create ghost package.conf.old
- remove or rename alternatives files more consistently

* Thu Oct 23 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 6.8.3-10
- remove redundant --haddockdir (interfacedir in Cabal-1.2) from cabal_configure


gkrellm-2.3.2-1.fc10
--------------------
* Thu Oct 23 18:00:00 2008 Hans de Goede <hdegoede at redhat.com> 2.3.2-1
- New upstream release 2.3.2
- Drop upstreamed memleak patch


gthumb-2.10.10-3.fc10
---------------------
* Thu Oct 23 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.10.10-3
- Avoid tons of GTK+ warnings


gtk2hs-0.9.13-3.fc10
--------------------
* Fri Oct 24 18:00:00 2008 Jens Petersen <petersen at redhat.com> - 0.9.13-3
- install docs in ghc haddock dir with htmldocdir and use ghc_reindex_haddock
- rename gtk2hs-doc to ghc-gtk2hs-doc
- use pkg_name, pkg_libdir, and pkg_docdir for Haskell packaging guidelines
- don't override __spec_install_post


ibus-0.1.1.20081023-1.fc10
--------------------------
* Thu Oct 23 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081023-1
- Update to 0.1.1.20081023.


ibus-chewing-0.1.1.20081023-1.fc10
----------------------------------
* Thu Oct 23 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20080923-1
- Update to 0.1.1.20080923.


ibus-hangul-0.1.1.20081023-1.fc10
---------------------------------
* Thu Oct 23 18:00:00 2008 Huang Peng <shawn.p.huang at gmail.com> - 0.1.1.20081023-1
- Update to 0.1.1.20081023.


imsettings-0.105.1-1.fc10
-------------------------
* Thu Oct 23 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.105.1-1
- New upstream release.
  - Fix another freeze issue. (#452849)
- imsettings-r210.patch: removed.


jakarta-commons-beanutils-1.7.0-10.3.fc10
-----------------------------------------
* Thu Oct 23 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.7.0-10.3
- Fedora-specific: enable GCJ support

* Thu Oct 23 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.7.0-10.2
- Fedora-specific: BuildRequires: java-1.6.0-devel

* Thu Oct 23 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.7.0-10.1
- Fedora-specific: remove repolib
- Fedora-specific: enable JDK6 support

* Mon Oct 20 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.7.0-10
- add flag to build with maven

* Fri Sep 19 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.7.0-9
- add jdk6 patch
- fix repolib


java-1.6.0-openjdk-1.6.0.0-1.0.b12.fc10
---------------------------------------
* Wed Oct 22 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.0.b12
- Removed option to build with alternate jar.

* Tue Oct 21 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.0.b12
- Updated icedteaver.
- Updated Release.
- Changed to use IcedTeaPlugin.so instead of gcjwebplugin.so. Includes 
LiveConnect support.
- Updated mauvedate.
- Added xulrunner-devel and xulrunner-devel-unstable as build requirements.
- Enabled building of pulse-java, not default sound implementation though.
- Added build requirements for pulse-java.
- Resolves: rhbz#468043 
- Resolves: rhbz#375161 
- Resolves: rhbz#432184 
- Resolves: rhbz#302071 
- Resolves: rhbz#457536 
- Resolves: rhbz#460236 
- Resolves: rhbz#460084
- Resolves: rhbz#467794


ktorrent-3.1.4-1.fc10
---------------------
* Thu Oct 23 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 3.1.4-1
- ktorrent-3.1.4 (#468233)


libX11-1.1.4-5.fc10
-------------------
* Fri Oct 24 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.1.4-5
- libX11-1.1.4-keysysm.patch: add a bunch of keysyms for remote controls and
  special keys.


libasyncns-0.6-1.fc10
---------------------
* Fri Oct 24 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.6-1
- New release

* Sat Aug 23 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.5-1
- New release


libcgroup-0.32.1-1.fc10
-----------------------
* Thu Oct 23 18:00:00 2008 Dhaval Giani <dhaval at linux.vnet.ibm.com> 0.32.1-1
- Update to latest upstream


libgnome-2.24.1-6.fc10
----------------------
* Thu Oct 23 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 2.24.1-6
- sed the pot file to avoid multilib issues (#468161)


libgxim-0.3.1-1.fc10
--------------------
* Thu Oct 23 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.3.1-1
- New upstream release.


libv4l-0.5.2-1.fc10
-------------------
* Thu Oct 23 18:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.2-1
- New upstream release 0.5.2


liferea-1.4.20-4.fc10
---------------------
* Thu Oct 23 18:00:00 2008 Steven M. Parrish <smparrish at shallowcreek.net> 1.4.20-4
- Packaged the WebKit libs seperately so the default install uses
- XulRunner.  If the user wants to enable WebKit they need to 
- install the -WebKit sub-package


mc-4.6.2-7.pre1.fc10
--------------------
* Thu Oct 23 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.6.2-7.pre1
- allow switching of trailing spaces/tab highlighting with crtl-v,
  patch from Jan Engelhardt (#464738)
- update the UTF-8 patch accordingly


mm-1.4.2-4.fc10
---------------
* Thu Oct 23 18:00:00 2008 Andreas Thienemann <andreas at bawue.net> - 1.4.2-5
- Updated mm-config file to remove multilib conflict.


nautilus-actions-1.9-0.3.svn20081020.fc10
-----------------------------------------
* Thu Oct 23 18:00:00 2008 Deji Akingunola <dakingun at gmail.com> - 1.9-0.3.svn20081020
- Update to a svn snapshot to fix bug #450988


ngircd-0.12.1-1.fc10
--------------------
* Thu Oct 23 18:00:00 2008 Andreas Thienemann <andreas at bawue.net> 0.12.1-1
- Updated to 0.12.1
- Updated configuration sample


objectweb-asm-3.1-5.1.fc10
--------------------------
* Thu Oct 23 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:3.1-5.1
- build for Fedora

* Thu Oct 23 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:3.1-5
- add OSGi manifest (Alexander Kurtakov)

* Mon Oct 20 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:3.1-4
- remove Class-Path from MANIFEST.MF
- add unversioned javadoc symlink
- remove javadoc scriptlets
- fix directory ownership
- remove build requirement on dos2unix


octave-3.0.2-2.fc10
-------------------
* Thu Oct 23 18:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> 3.0.2-2
- patch for sh arch: it adds '-little' flag


openoffice-lv-0.7.4-1.fc10
--------------------------
* Thu Oct 23 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.7.4-1
- latest version


opensp-1.5.2-9.fc10
-------------------
* Thu Oct 23 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1.5.2-9
- convert doc files to UTF-8 (#226217)


perl-5.10.0-49.fc10
-------------------
* Thu Oct 23 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.10.0-49
- update File::Temp to 0.20


perl-CGI-Ajax-0.707-1.fc10
--------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.707-1
- update to 0.707-1


perl-Catalyst-Runtime-5.7015-1.fc10
-----------------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 5.7015-1
- update to 5.7015


perl-Gtk2-Sexy-0.04-1.fc10
--------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.04-1
- update to 0.04


perl-HTML-Template-Pro-0.71-1.fc10
----------------------------------
* Thu Oct 23 18:00:00 2008 Lubomir Rintel (Good Data) <lubo.rintel at gooddata.com> - 0.71-1
- New upstream version


perl-List-Compare-0.37-1.fc10
-----------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.37-1
- update to 0.37


perl-Module-Install-ExtraTests-0.004-2.fc10
-------------------------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.004-2
- bump

* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.004-1
- update to 0.004


perl-RPC-XML-0.64-1.fc10
------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.64-1
- update to 0.64-1
- drop tests patch (fixed!)
- add BR on Net::Server


perl-Sub-Exporter-0.980-1.fc10
------------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.980-1
- update to 0.980


perl-Template-Alloy-1.013-1.fc10
--------------------------------
* Thu Oct 23 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.013-1
- update to 1.013


php-pear-Image-Color-1.0.2-5.fc10
---------------------------------
* Thu Oct 23 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.0.2-5
- Update LICENSE to 3.01


php-pear-Image-Graph-0.7.2-4.fc10
---------------------------------
* Thu Oct 23 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 0.7.2-4
- Merge subpackages
- Convert example files to UTF-8


php-pear-Image-GraphViz-1.2.1-4.fc10
------------------------------------
* Thu Oct 23 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 1.2.1-4
- Update LICENSE to 3.01


php-pear-Numbers-Words-0.15.0-4.fc10
------------------------------------
* Thu Oct 23 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 0.15.0-4
- Update LICENSE file to version 3.01


php-pear-PHPUnit-3.3.2-1.fc10
-----------------------------
* Thu Oct 23 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 3.3.2-1
- Upstream sync
- Remove no longer needed Obsolete/Provides


php-pear-Structures-DataGrid-0.9.0-3.fc10
-----------------------------------------
* Thu Oct 23 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 0.9.0-3
- Move examples to %doc
- Fix up %files section


php-pear-XML-RSS-0.9.10-5.fc10
------------------------------
* Thu Oct 23 18:00:00 2008 Christopher Stone <chris.stone at gmail.com> 0.9.10-5
- Update LICENSE to 3.01


plymouth-0.6.0-0.2008.10.23.2.fc10
----------------------------------
* Thu Oct 23 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.23.2
- Bump so name of libply to hopefully force plymouth to get installed
  before kernel (or at least make plymouth-libs and plymouth get installed
  on the same side of kernel in the transaction).

* Thu Oct 23 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.23.1
- Add patch from Charlie to align progress bar to milestones during boot up
- force tty to be sane on exit (bug 467207)

* Thu Oct 23 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.21.3
- add empty files section for text-and-details-only so the subpackage
  shows up.


policycoreutils-2.0.57-5.fc10
-----------------------------
* Thu Oct 23 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-5
- Allow addition of local modifications of fcontext policy.


pulseaudio-0.9.13-4.fc10
------------------------
* Fri Oct 24 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.9.13-4
- Backport another fix from current git master

* Thu Oct 23 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.9.13-3
- Backport a couple of fixes from current git master


puppet-0.24.6-1.fc10
--------------------
* Wed Oct 22 18:00:00 2008 Todd Zullinger <tmz at pobox.com> - 0.24.6-1
- Update to 0.24.6
- Require ruby-shadow on Fedora and RHEL >= 5
- Simplify Fedora/RHEL version checks for ruby(abi) and BuildArch
- Require chkconfig and initstripts for preun, post, and postun scripts
- Conditionally restart puppet in %postun
- Ensure %preun, %post, and %postun scripts exit cleanly
- Create puppet user/group according to Fedora packaging guidelines
- Quiet a few rpmlint complaints
- Remove useless %pbuild macro
- Make specfile more like the Fedora/EPEL template


purple-facebookchat-1.37-1.fc10
-------------------------------
* Thu Oct 23 18:00:00 2008 Mat??j Cepl <mcepl at redhat.com> 1.37-1
- Upstream release.


purple-microblog-0.1.2-2.20081023svn165.fc10
--------------------------------------------
* Thu Oct 23 18:00:00 2008 Mat??j Cepl <mcepl at redhat.com> 0.1.2-2.20081023svn165
- Rebase to the new SVN checkout
- Remove patches (they were accepted upstream)


python-mwlib-0.8.5-2.fc10
-------------------------
* Thu Oct 23 18:00:00 2008 Ian Weller <ianweller at gmail.com> 0.8.5-2
- Silly me, I forgot to upload Source0 in CVS

* Thu Oct 23 18:00:00 2008 Ian Weller <ianweller at gmail.com> 0.8.5-1
- Bump to 0.8.5


python-simplejson-2.0.3-2.fc10
------------------------------
* Thu Oct 23 18:00:00 2008 Luke Macken <lmacken at redhat.com> 2.0.3-2
- Use nose to run the simplejson test suite


python-tw-forms-0.9.2-1.fc10
----------------------------
* Thu Oct 23 18:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.9.2-1
- Update to tw.forms 0.9.2


rpmlint-0.85-1.fc10
-------------------
* Thu Oct 23 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.85-1
- 0.85, fixes #355861, #450011, #455371, #456843, #461421, #461423, #461434.
- Mute some explicit-lib-dependency false positives (#458290).
- Sync Fedora license list with Wiki revision 1.19.
- Dist regex patch applied/superseded upstream.


rubygem-cobbler-0.1.2-1.fc10
----------------------------
* Thu Oct 23 18:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 0.1.2-1
- Fixed a bug in how the remove method was generated.


rubygem-gettext-1.93.0-7.fc10
-----------------------------
* Thu Oct 23 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.93.0-7
- Handle gettext .mo files under %{geminstdir}/data/locale by
  modifying find-lang.sh


rubygem-hoe-1.8.1-2.fc10
------------------------
* Thu Oct 23 18:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 1.8.1-2
- Last build failed.

* Thu Oct 23 18:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 1.8.1-1
- Release 1.8.1 of the gem.


rubygem-rubyforge-1.0.1-1.fc10
------------------------------
* Thu Oct 23 18:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 1.0.1-1
- Release 1.0.1 of Rubyforge.


sectool-0.9.1-2
---------------
* Thu Oct 23 18:00:00 2008 Peter Vrabec <pvrabec at redhat.com> - 0.9.1-2
- add missing requirement (468033)
- fix deps of cron test (468033)


selinux-policy-3.5.13-5.fc10
----------------------------

setroubleshoot-plugins-2.0.10-1.fc10
------------------------------------
* Thu Oct 23 18:00:00 2008 <dwalsh at redhat.com> - 2.0.10-1
- Add qemu plugins for real


stapitrace-1.0.0-19.20080622cvs_alpha.fc10
------------------------------------------
* Wed Oct 15 18:00:00 2008 Dave Nomura <dcnltc at us.ibm.com>
- upgrade to utrace2


subversion-api-docs-1.5.3-1.fc10
--------------------------------
* Fri Oct 24 18:00:00 2008 Bojan Smojver <bojan at rexursive.com> 1.5.3-1
- bump up to 1.5.3


swfdec-0.8.2-1.fc10
-------------------
* Thu Oct 23 18:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.8.2-1
- Update to 0.8.2.


system-config-keyboard-1.2.15-4.fc10
------------------------------------
* Thu Oct 23 18:00:00 2008 Chris Lumens <clumens at redhat.com> 1.2.15-4
- Fix a traceback when running under firstboot reconfig mode.


telepathy-gabble-0.7.12-1.fc10
------------------------------
* Thu Oct 23 18:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.12-1
- Update to 0.7.12.


tomcat5-5.5.27-4.9.fc10
-----------------------

up-imapproxy-1.2.7-0.1.rc1.fc10
-------------------------------
* Thu Oct 23 18:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> 1.2.7.rc1-1
- updated to 1.2.7.rc1 - security updates, buffer overflow etc.

* Thu Oct 23 18:00:00 2008 Rakesh Pandit <rakesh at fedoraproject.org> 1.2.7-0.1.rc1
- fixed version and release fields (acc. to guidelines)


wine-1.1.6-1.fc10
-----------------
* Thu Oct 23 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.1.6-1
- version upgrade
- fix multiarch problems (#466892,#467480)


wordpress-2.6.3-1.fc10
----------------------
* Fri Oct 24 18:00:00 2008 Adrian Reber <adrian at lisas.de> - 2.6.3-1
- updated to 2.6.3


xine-lib-1.1.15-2.fc10
----------------------
* Thu Oct 23 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.1.15-2
- respin


xkeyboard-config-1.4-4.fc10
---------------------------
* Fri Oct 24 18:00:00 2008 Peter Hutterer  <peter.hutterer at redhat.com> - 1.4-4
- xkeyboard-config-1.4-battery.patch: add XF86 syms for Battery, Bluetooth,
  Wlan and UWB to usinet.


xorg-x11-drv-ati-6.9.0-31.fc10
------------------------------

xorg-x11-proto-devel-7.4-4.fc10
-------------------------------
* Thu Oct 23 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 7.4-4
- xproto 7.0.14


yum-3.2.19-6.fc10
-----------------
* Thu Oct 23 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 3.2.19-6
- update HEAD patch


yum-utils-1.1.17-2.fc10
-----------------------
* Thu Oct 23 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org>
- small patch to repodiff to keep rawhide builds from falling over until 1.1.18


Summary:
Added Packages: 5
Removed Packages: 0
Modified Packages: 96
Broken deps for i386
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-provider-1.2.so.13
	planner-eds-0.14.3-5.fc10.i386 requires libcamel-1.2.so.13
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3



Broken deps for x86_64
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.x86_64 requires iml = 0:1.0.2-3.fc10
	planner-eds-0.14.3-5.fc10.x86_64 requires libcamel-1.2.so.13()(64bit)
	planner-eds-0.14.3-5.fc10.x86_64 requires libcamel-provider-1.2.so.13()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3



Broken deps for ppc
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.ppc requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	planner-eds-0.14.3-5.fc10.ppc requires libcamel-provider-1.2.so.13
	planner-eds-0.14.3-5.fc10.ppc requires libcamel-1.2.so.13
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3



Broken deps for ppc64
----------------------------------------------------------
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	planner-eds-0.14.3-5.fc10.ppc64 requires libcamel-1.2.so.13()(64bit)
	planner-eds-0.14.3-5.fc10.ppc64 requires libcamel-provider-1.2.so.13()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3





From valent.turkovic at gmail.com  Fri Oct 24 11:05:00 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 24 Oct 2008 13:05:00 +0200
Subject: state of Fedora kernel and Desktop use?
Message-ID: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>

Hi devels & all,
I'll be brief so not to take much of your time.

I read this article [1] about general Linux kernel development and how
desktop use is ignored by mainstream kernel developers, and how
desktop performance is suffering because of that.

I took out this quote to summarize:
"I think the kernel developers at large haven't got the faintest idea
just how big the problems in userspace are. It is a very small brave
minority that are happy to post to lkml, and I keep getting users
telling me on IRC, in person, and via my own mailing list, what their
problems are. And they've even become fearful of me, even though I've
never viewed myself as a real kernel developer."

What is the status of Fedora kernel regarding specific patches that
make desktop perform better? Is is true that mostly big vendor issues
get resolved and that kernel devels don't care enough for desktop
users?

Cheers,
Valent.

[1] http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_boring.htm

-- 
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  Fri Oct 24 11:16:57 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 24 Oct 2008 13:16:57 +0200
Subject: New PiTiVi Release!
In-Reply-To: <48F748C2.6060005@nicubunu.ro>
References: <935ead450810151412s201a34eascb51e2ffecd9277f@mail.gmail.com>
	<935ead450810151844t74325336x6ec44d3d87c6123b@mail.gmail.com>
	<48F748C2.6060005@nicubunu.ro>
Message-ID: <64b14b300810240416j5680ffb2geac42319f67d2607@mail.gmail.com>

On Thu, Oct 16, 2008 at 3:59 PM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> Jeffrey Ollie wrote:
>>
>> On Wed, Oct 15, 2008 at 4:12 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
>>>
>>> Finally, there is a new PiTiVi release and I've built it for F-9 and
>>> rawhide.  Please, take a moment to download it and give it a workout.
>>> Please report bugs upstream (http://pitivi.org/wiki/Main_Page)
>>
>> Until the packages make their way to the mirrors, they can be downloaded
>> here:
>>
>> F-10: http://koji.fedoraproject.org/koji/buildinfo?buildID=66472
>> F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=66475
>
> I think I am stupid or something, as I am unable to find a way to insert an
> Ogg Theora video and an Ogg Vorbis audio file and render them as one Ogg
> clip with both video and audio...

What do the upstream devels says? Is this a 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 nicu_fedora at nicubunu.ro  Fri Oct 24 11:34:04 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 24 Oct 2008 14:34:04 +0300
Subject: New PiTiVi Release!
In-Reply-To: <64b14b300810240416j5680ffb2geac42319f67d2607@mail.gmail.com>
References: <935ead450810151412s201a34eascb51e2ffecd9277f@mail.gmail.com>	<935ead450810151844t74325336x6ec44d3d87c6123b@mail.gmail.com>	<48F748C2.6060005@nicubunu.ro>
	<64b14b300810240416j5680ffb2geac42319f67d2607@mail.gmail.com>
Message-ID: <4901B2AC.4070505@nicubunu.ro>

Valent Turkovic wrote:
> On Thu, Oct 16, 2008 at 3:59 PM, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
>> I think I am stupid or something, as I am unable to find a way to insert an
>> Ogg Theora video and an Ogg Vorbis audio file and render them as one Ogg
>> clip with both video and audio...
> 
> What do the upstream devels says? Is this a bug?

Most likely is a base feature not implemented yet... as seen on Planet 
Gnome, Collabora Multimedia is looking to hire developers  to work on 
video editing (PiTivi).

-- 
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 alsadi at gmail.com  Fri Oct 24 11:46:17 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 24 Oct 2008 14:46:17 +0300
Subject: kde needs mysql-server ??
In-Reply-To: <200810241243.12892.Juha.Tuomala@iki.fi>
References: <48FF046A.3000501@nobugconsulting.ro>
	<200810241243.12892.Juha.Tuomala@iki.fi>
Message-ID: <385866f0810240446j2ccd6cd8s749f39c9da60ccb0@mail.gmail.com>

they must consider sqlite, it's very crazy for desktop applications
like amarok or contacts ..etc. to serve a database and to connect to
itself



From csnook at redhat.com  Fri Oct 24 11:58:20 2008
From: csnook at redhat.com (Chris Snook)
Date: Fri, 24 Oct 2008 07:58:20 -0400
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
Message-ID: <4901B85C.1070000@redhat.com>

Valent Turkovic wrote:
> Hi devels & all,
> I'll be brief so not to take much of your time.
> 
> I read this article [1] about general Linux kernel development and how
> desktop use is ignored by mainstream kernel developers, and how
> desktop performance is suffering because of that.
> 
> I took out this quote to summarize:
> "I think the kernel developers at large haven't got the faintest idea
> just how big the problems in userspace are. It is a very small brave
> minority that are happy to post to lkml, and I keep getting users
> telling me on IRC, in person, and via my own mailing list, what their
> problems are. And they've even become fearful of me, even though I've
> never viewed myself as a real kernel developer."
> 
> What is the status of Fedora kernel regarding specific patches that
> make desktop perform better? Is is true that mostly big vendor issues
> get resolved and that kernel devels don't care enough for desktop
> users?
> 
> Cheers,
> Valent.
> 
> [1] http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_boring.htm
> 

We do plenty of desktop optimization.  Con Kolivas was whining because we were 
being conservative about desktop optimizations that had a high risk of harming 
enterprise workloads, but the truth is that we're conservative about all 
optimizations that have a high risk of harming *any* workload, which is how we 
should be.

As for specific patches, we try to keep as close in sync with upstream as 
possible.  Fedora-specific patches are more likely to be features that aren't 
quite ready for the vast range of kernel configurations possible upstream, but 
we're confident of in the limited configurations we use in Fedora.  Performance 
optimizations tend to track rather closely.  Some distributions use experimental 
patches that haven't been merged upstream to optimize for some specific 
workload, but Fedora is used far too widely for that, and the payoff of those 
patches is generally rather small anyway.  For things that make a huge 
difference, there's enough motivation to get them upstream quickly, so we get 
them quickly too.

-- Chris



From jwboyer at gmail.com  Fri Oct 24 11:59:02 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 24 Oct 2008 07:59:02 -0400
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
Message-ID: <20081024115902.GA2197@yoda.jdub.homelinux.org>

On Fri, Oct 24, 2008 at 01:05:00PM +0200, Valent Turkovic wrote:
>Hi devels & all,
>I'll be brief so not to take much of your time.
>
>I read this article [1] about general Linux kernel development and how
>desktop use is ignored by mainstream kernel developers, and how
>desktop performance is suffering because of that.
>
>I took out this quote to summarize:
>"I think the kernel developers at large haven't got the faintest idea
>just how big the problems in userspace are. It is a very small brave
>minority that are happy to post to lkml, and I keep getting users
>telling me on IRC, in person, and via my own mailing list, what their
>problems are. And they've even become fearful of me, even though I've
>never viewed myself as a real kernel developer."
>
>What is the status of Fedora kernel regarding specific patches that
>make desktop perform better? Is is true that mostly big vendor issues

The status is the same here as it is for every other kind of patch.
Fedora tries very hard to not carry additional patches.  With the
exception of a few things like exec-shield, if the patches aren't
upstream or headed there rapidly, they generally aren't carried.

It's easier to talk about specific patches when they are pointed out.
Neither the interview, nor you did that so I don't really know what
sort of patches you're talking about.

josh



From fedora at matbooth.co.uk  Fri Oct 24 12:14:48 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Fri, 24 Oct 2008 12:14:48 +0000
Subject: rawhide report: 20081024 changes
In-Reply-To: <20081024102540.CAD6E1F824A@releng2.fedora.phx.redhat.com>
References: <20081024102540.CAD6E1F824A@releng2.fedora.phx.redhat.com>
Message-ID: <9497e9990810240514k5c4bc0c3r47279baed8c9cc94@mail.gmail.com>

On Fri, Oct 24, 2008 at 10:25 AM, Rawhide Report
<rawhide at fedoraproject.org> wrote:
> java-1.6.0-openjdk-1.6.0.0-1.0.b12.fc10
> ---------------------------------------
> - Changed to use IcedTeaPlugin.so instead of gcjwebplugin.so. Includes
> LiveConnect support.


Thanks for the effort put in to bring LiveConnect support to OpenJDK.
This has been one of the things keeping me on Sun's JDK in Fedora.


-- 
Mat Booth
www.matbooth.co.uk



From valent.turkovic at gmail.com  Fri Oct 24 12:31:06 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 24 Oct 2008 14:31:06 +0200
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <20081024115902.GA2197@yoda.jdub.homelinux.org>
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
	<20081024115902.GA2197@yoda.jdub.homelinux.org>
Message-ID: <64b14b300810240531g13c711f6sd32e4741efd9240f@mail.gmail.com>

On Fri, Oct 24, 2008 at 1:59 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Fri, Oct 24, 2008 at 01:05:00PM +0200, Valent Turkovic wrote:
>>Hi devels & all,
>>I'll be brief so not to take much of your time.
>>
>>I read this article [1] about general Linux kernel development and how
>>desktop use is ignored by mainstream kernel developers, and how
>>desktop performance is suffering because of that.
>>
>>I took out this quote to summarize:
>>"I think the kernel developers at large haven't got the faintest idea
>>just how big the problems in userspace are. It is a very small brave
>>minority that are happy to post to lkml, and I keep getting users
>>telling me on IRC, in person, and via my own mailing list, what their
>>problems are. And they've even become fearful of me, even though I've
>>never viewed myself as a real kernel developer."
>>
>>What is the status of Fedora kernel regarding specific patches that
>>make desktop perform better? Is is true that mostly big vendor issues
>
> The status is the same here as it is for every other kind of patch.
> Fedora tries very hard to not carry additional patches.  With the
> exception of a few things like exec-shield, if the patches aren't
> upstream or headed there rapidly, they generally aren't carried.
>
> It's easier to talk about specific patches when they are pointed out.
> Neither the interview, nor you did that so I don't really know what
> sort of patches you're talking about.

Interview focused on specific issues - "Staircase Deadline CPU scheduler"

to quote again from the artcle (page 2/3)

"The Staircase Deadline CPU scheduler. Initially started as a side
project from the Staircase CPU scheduler I soon realised that it was
possible to have excellent interactivity while fixing the horrible
fairness issues that an unfair design had. Furthermore, it actually
improved interactivity issues elsewhere that ended up being fairness
problems, and fairness is of course paramount to servers and multiuser
environments."

and also:

"One very vocal user found that the unfair behaviour in the mainline
scheduler was something he came to expect. A flamewar of sorts erupted
at the time, because to fix 100% of the problems with the CPU
scheduler we had to sacrifice interactivity on some workloads. It
wasn't a dramatic loss of interactivity, but it was definitely there.
Rather than use 'nice' to proportion CPU according to where the user
told the operating system it should be, the user believed it was the
kernel's responsibility to guess. As it turns out, it is the fact that
guessing means that no matter how hard and how smart you make the CPU
scheduler, it will get it wrong some of the time. The more it tries to
guess, the worse will be the corner cases of misbehaving."

Sorry for quoting, but I'm not a developer, just a curious user :)

Thank you very much for replying.

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 ivazqueznet at gmail.com  Fri Oct 24 12:39:45 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 24 Oct 2008 08:39:45 -0400
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <64b14b300810240531g13c711f6sd32e4741efd9240f@mail.gmail.com>
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
	<20081024115902.GA2197@yoda.jdub.homelinux.org>
	<64b14b300810240531g13c711f6sd32e4741efd9240f@mail.gmail.com>
Message-ID: <1224851985.13774.2.camel@ignacio.lan>

On Fri, 2008-10-24 at 14:31 +0200, Valent Turkovic wrote:
> Sorry for quoting, but I'm not a developer, just a curious user :)

And not to belittle your status as a user, but at some point you are
going to have to trust that the developers are Doing The Right Thing.

-- 
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/20081024/01088cad/attachment.sig>

From jonrob at fedoraproject.org  Fri Oct 24 12:46:07 2008
From: jonrob at fedoraproject.org (Jonathan Roberts)
Date: Fri, 24 Oct 2008 13:46:07 +0100
Subject: GConf .schema packaging procedure
Message-ID: <507738ef0810240546x7e035d9fn6d612fca1a8de4b5@mail.gmail.com>

Hi,

Could anyone point me at some guidelines for packaging .schemas files?

I'm packaging:

http://jonrob.fedorapeople.org/RPMS/go-home-applet.spec

And review bug is at:

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

.schemas is being installed in /etc/ for this package, triggering
non-conffile-in-etc warning.

Kindly,

Jon



From valent.turkovic at gmail.com  Fri Oct 24 12:57:10 2008
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 24 Oct 2008 14:57:10 +0200
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <1224851985.13774.2.camel@ignacio.lan>
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
	<20081024115902.GA2197@yoda.jdub.homelinux.org>
	<64b14b300810240531g13c711f6sd32e4741efd9240f@mail.gmail.com>
	<1224851985.13774.2.camel@ignacio.lan>
Message-ID: <64b14b300810240557n2ee20df2qa934791229f16e65@mail.gmail.com>

2008/10/24 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Fri, 2008-10-24 at 14:31 +0200, Valent Turkovic wrote:
>> Sorry for quoting, but I'm not a developer, just a curious user :)
>
> And not to belittle your status as a user, but at some point you are
> going to have to trust that the developers are Doing The Right Thing.

I never said I don't trust them, far from it, just that I'm curious.

I'm really impressed how well Fedora 9 and current rawhide work, but
when I read CK's interview I was sad that he quit doing his patches.
Desktop linux (Fedora included) needs all the people that it can,
especially ones who focus also on the desktop and issues regarding
desktop use. He claimed that desktop performance was seriously
impaired when 2.6 kernel was released and that then nobody was even
paying attention on desktop workloads and that enterpise workload
patches were seriously hurting desktop performance and workloads.

If there is some other resource  (his personal blog, interview or
something) about Linux kernel and desktop workloads that that some
kernel developer wrote please point me in that direction.

Cheers,
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 jmoyer at redhat.com  Fri Oct 24 13:01:45 2008
From: jmoyer at redhat.com (Jeff Moyer)
Date: Fri, 24 Oct 2008 09:01:45 -0400
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <64b14b300810240557n2ee20df2qa934791229f16e65@mail.gmail.com>
	(Valent Turkovic's message of "Fri, 24 Oct 2008 14:57:10 +0200")
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
	<20081024115902.GA2197@yoda.jdub.homelinux.org>
	<64b14b300810240531g13c711f6sd32e4741efd9240f@mail.gmail.com>
	<1224851985.13774.2.camel@ignacio.lan>
	<64b14b300810240557n2ee20df2qa934791229f16e65@mail.gmail.com>
Message-ID: <x49y70e6tae.fsf@segfault.boston.devel.redhat.com>

"Valent Turkovic" <valent.turkovic at gmail.com> writes:

> 2008/10/24 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
>> On Fri, 2008-10-24 at 14:31 +0200, Valent Turkovic wrote:
>>> Sorry for quoting, but I'm not a developer, just a curious user :)
>>
>> And not to belittle your status as a user, but at some point you are
>> going to have to trust that the developers are Doing The Right Thing.
>
> I never said I don't trust them, far from it, just that I'm curious.
>
> I'm really impressed how well Fedora 9 and current rawhide work, but
> when I read CK's interview I was sad that he quit doing his patches.
> Desktop linux (Fedora included) needs all the people that it can,
> especially ones who focus also on the desktop and issues regarding
> desktop use. He claimed that desktop performance was seriously
> impaired when 2.6 kernel was released and that then nobody was even
> paying attention on desktop workloads and that enterpise workload
> patches were seriously hurting desktop performance and workloads.

You do realize that this whole Linux thing started because some
developer wanted to run UNIX on his desktop, right?  That hasn't
changed.

http://www.techworld.com/opsys/news/index.cfm?newsid=9652

Cheers,

Jeff



From mclasen at redhat.com  Fri Oct 24 13:13:11 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 24 Oct 2008 09:13:11 -0400
Subject: GConf .schema packaging procedure
In-Reply-To: <507738ef0810240546x7e035d9fn6d612fca1a8de4b5@mail.gmail.com>
References: <507738ef0810240546x7e035d9fn6d612fca1a8de4b5@mail.gmail.com>
Message-ID: <1224853991.3345.11.camel@localhost.localdomain>

On Fri, 2008-10-24 at 13:46 +0100, Jonathan Roberts wrote:
> Hi,
> 
> Could anyone point me at some guidelines for packaging .schemas files?
> 
> I'm packaging:
> 
> http://jonrob.fedorapeople.org/RPMS/go-home-applet.spec
> 
> And review bug is at:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=451768
> 
> .schemas is being installed in /etc/ for this package, triggering
> non-conffile-in-etc warning.
> 


I think most of it should be covered in the packaging guidelines, but
what I always do is to find a simple spec to copy from, e.g. this one

http://cvs.fedoraproject.org/viewvc/rpms/gcalctool/devel/gcalctool.spec?view=markup

There is a few parts here, you need to have %post, %preun and %preun
sections that handle the installation and deinstallation, and
corresponding Requires for GConf2. 

Schema files are definitively not conffiles, so the non-conffile warning
should be ignored. 



From andy at gohanman.com  Fri Oct 24 14:09:57 2008
From: andy at gohanman.com (Andy Theuninck)
Date: Fri, 24 Oct 2008 09:09:57 -0500
Subject: Packaging Guidelines: /opt
In-Reply-To: <4901324E.3070905@gmail.com>
References: <f8a02f3e0810231857m458cc3e1i5e80f3a73778ed8f@mail.gmail.com>
	<4901324E.3070905@gmail.com>
Message-ID: <f8a02f3e0810240709t17591d6frab96e8ce2915940e@mail.gmail.com>

Thanks for the hints. As far as upstream goes, [as I understand it]
the main goal is to support as many OSes as possible with the default.
And from that prospective, I can understand the advantage of sticking
everything into a single directory.

Moving as much as possible over to /usr/share and symlinking against
the files that are actually needed should be a workable solution (and
maybe an entertaining exercise in bash scripting).

~Andy

2008/10/23 Toshio Kuratomi <a.badger at gmail.com>:
> Andy Theuninck wrote:
>> I'm trying to put a package together for webmin. It wants to install
>> to libexec, but if I do that rpmlint (rightly) complains that there
>> are non-executable text files. Perl files & HTML files are intermixed
>> and separating them out would be a patching nightmare. With a bit of
>> sed scripting, I can coax the whole thing into a different base
>> directory.
>>
> Separating different types of files and getting upstream to accept the
> patches is the right thing to do.
>
> Failing to get buyin from upstream, separating them and symlinking is
> acceptable but not encouraged.
>
> This brief section of the guidelines has useful information about where
> things might belong in this case::
>  http://fedoraproject.org/wiki/Packaging/Guidelines#Web_Applications
>
> If you look at moin and other web packages, you'll see that they place a
> lot of files into /usr/share, perhaps how you're intending to use /opt.
>  However, you do have to make sure you aren't putting executables,
> binaries, or files that need to be written there.
>
>> The official packaging guidelines say Fedora follows the Filesystem
>> Hierarchy Standard, and as I read FHS /opt would be the most
>> appropriate place to dump this mess. If I try to use /opt/webmin
>> though, rpmlint pitches a fit about using /opt. Nothing in the
>> guidelines says I can't use /opt. Can I just ignore all these errors?
>>
>
> The FHS says: /opt is reserved for the installation of add-on
> application software packages.
>
> Anything packaged by Fedora is part of the system packaging rather than
> an addon so we stay out of /opt.
>
>> Also, neither the packing guidelines nor FHS make any mention of /var.
>> Maybe that's a more appropriate spot.
>>
> For some content, yes.  But not for the bulk of it.
>
> The Guidelines section I linked to earlier mentions that /var is not the
> place for (most of) these files.
>
> -Toshio
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From cra at WPI.EDU  Fri Oct 24 14:28:22 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Fri, 24 Oct 2008 10:28:22 -0400
Subject: FESCo Meeting Summary for 2008-10-22
In-Reply-To: <49015904.6080803@leemhuis.info>
References: <1224791613.4174.4.camel@kennedy> <49015904.6080803@leemhuis.info>
Message-ID: <20081024142822.GK24040@angus.ind.WPI.EDU>

On Fri, Oct 24, 2008 at 07:11:32AM +0200, Thorsten Leemhuis wrote:
> On 23.10.2008 21:53, Brian Pepple wrote:
>> === Features ===
>> * FESCo rejected a proposal to revert the Sbin Sanity(1) feature.
>>       * For: kick_
>>       * Against: dwmw2, j-rod, bpepple, notting, dgilmore, nirik
>>       * Abstain: jwb
>>      1. https://fedoraproject.org/wiki/Features/SbinSanity
>
> I think FESCo is doing a big mistake here.
>
> So FWIW, I totally agree with what Ville said in
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html

+1

This is really easy to revert now with little harm.  It will be MUCH 
harder to revert this later to incrementally improve the /sbin 
situation.



From langel at redhat.com  Fri Oct 24 15:57:51 2008
From: langel at redhat.com (Lillian Angel)
Date: Fri, 24 Oct 2008 11:57:51 -0400
Subject: Anyone want to take azureus?
Message-ID: <4901F07F.2080708@redhat.com>

Hi,

I am currently the maintainer of Azureus. I am wondering if anyone would 
like to take this package off my hands, since I do not have much time to 
take care of it.


Cheers,
Lillian



From debarshi.ray at gmail.com  Fri Oct 24 16:12:58 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 24 Oct 2008 21:42:58 +0530
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
Message-ID: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>

Upstream has dropped the separate libgdl-gnome-1.so from gdl-2.24.0.
This will affect Fedora once libgdl-2.24.0 hits Rawhide. As far as I
know its dependencies are gnome-build and anjuta, which I will take
care of.

Happy hacking,
Debarshi



From cheekyboinc at foresightlinux.org  Fri Oct 24 16:20:15 2008
From: cheekyboinc at foresightlinux.org (Stefan Posdzich)
Date: Fri, 24 Oct 2008 18:20:15 +0200
Subject: Anyone want to take azureus?
In-Reply-To: <20081024160006.F311961ABAC@hormel.redhat.com>
References: <20081024160006.F311961ABAC@hormel.redhat.com>
Message-ID: <20081024182015.412ea049@cheeky>

> Anyone want to take azureus?

I would like to take the package!

regards
Stefan



From jkeating at redhat.com  Fri Oct 24 16:23:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 24 Oct 2008 09:23:41 -0700
Subject: Fedora 10 Snapshot 3
Message-ID: <1224865422.5564.7.camel@luminos.localdomain>

This is the final snapshot before our final devel freeze and subsequent
preview release.  On the torrent site you'll find install images and
live images for testing.  http://torrent.fedoraproject.org/

The i686 Live is just over 700M in size, so you /may/ have trouble
burning it if your media is very strict about it's size.

Of important note, these images do have a bug in them,
https://bugzilla.redhat.com/show_bug.cgi?id=468360 where some realtek
network cards will not initialize properly.  This bug has been fixed in
today's rawhide, which was too late for the snapshot.  If you use the
snapshot and fail to have networking, you'll need to update the kernel.

Thanks for the testing!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081024/7c406cc5/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 dominik at greysector.net  Fri Oct 24 16:28:04 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 24 Oct 2008 18:28:04 +0200
Subject: help required for thoggen
In-Reply-To: <b401d2530810240026i109561c1xb60c2be5f26f68fa@mail.gmail.com>
References: <b401d2530810240026i109561c1xb60c2be5f26f68fa@mail.gmail.com>
Message-ID: <20081024162804.GA29574@mokona.greysector.net>

On Friday, 24 October 2008 at 09:26, Rakesh Pandit wrote:
> http://thoggen.net/
> Can we have it in fedora. It rips DVD and supports Ogg/Theora (supported).

AFAIK decoding MPEG-2 is not allowed in Fedora yet. AC3/A52 probably too.
DTS definitely isn't. However, MP2 is patent-free already, I think.
Anyway, without MPEG-2 and at least AC3 you can't "rip" DVDs, so I don't
think it can go into Fedora if it is to be usable at all.

> Later on they are planning to add support to AVI/divx/mpeg4 And the
> required gstream codecs are on Livna or RPMFusion
> 
> The program is very good and useful. So, I wanted it in.
> I am not sure about whether it legally acceptable?

fedora-legal-list might be a better place to ask.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From martin.marques at gmail.com  Fri Oct 24 16:34:21 2008
From: martin.marques at gmail.com (=?UTF-8?Q?Mart=C3=ADn_Marqu=C3=A9s?=)
Date: Fri, 24 Oct 2008 14:34:21 -0200
Subject: dependencies between {swfdec-mozilla,
	gnash-plugin} and nspluginwrapper
In-Reply-To: <gdq15h$ehi$1@ger.gmane.org>
References: <e73de96e0810230641g669b1fb1k4ae70fb2c4c7bb9d@mail.gmail.com>
	<gdq15h$ehi$1@ger.gmane.org>
Message-ID: <e73de96e0810240934j39e4dddau9edb846b8ac694df@mail.gmail.com>

2008/10/23 Rex Dieter <rdieter at math.unl.edu>:
> Mart?n Marqu?s wrote:
>
>> Yesterday I started to finish configuring some things that were left
>> behind on my new laptop (amd64), and bumpped up with flash support for
>> firefox.
>>
>> The thing is that swfdec didn't work, and gnash neither.
>>
>> Solution: remove nspluginwrapper.
>
> nspluginwrapper has meachanism to id items not to wrap
> (see /etc/sysconfig/nspluginwrapper), which is likely the better short-term
> fix here.  Long term, investigate the buggy interaction between those and
> nspluginwrapper.

What should I look for there?

Just installed again nspluginwrapper and flash is gone.
/etc/sysconfig/nspluginwrapper has this:

export IGNORE_WRAP="libtotem*:libjavaplugin*:gecko-mediaplayer*:mplayerplug-in*:librhythmbox*"

export IGNORE_LINK=""

What next?


-- 
Mart?n Marqu?s
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador



From ville.skytta at iki.fi  Fri Oct 24 16:35:37 2008
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Fri, 24 Oct 2008 19:35:37 +0300
Subject: GConf .schema packaging procedure
In-Reply-To: <1224853991.3345.11.camel@localhost.localdomain>
References: <507738ef0810240546x7e035d9fn6d612fca1a8de4b5@mail.gmail.com>
	<1224853991.3345.11.camel@localhost.localdomain>
Message-ID: <200810241935.37499.ville.skytta@iki.fi>

On Friday 24 October 2008, Matthias Clasen wrote:

> Schema files are definitively not conffiles, so the non-conffile warning
> should be ignored.

There's a rpmlint bug open about this: https://bugzilla.redhat.com/235487

Repeating the question from the bug: if they are not configuration files, why 
are they being installed in /etc/gconf/schemas instead of let's 
say /usr/share/gconf/schemas?  FWIW, Debian installs them to the latter.



From notting at redhat.com  Fri Oct 24 16:56:10 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 24 Oct 2008 12:56:10 -0400
Subject: GConf .schema packaging procedure
In-Reply-To: <200810241935.37499.ville.skytta@iki.fi>
References: <507738ef0810240546x7e035d9fn6d612fca1a8de4b5@mail.gmail.com>
	<1224853991.3345.11.camel@localhost.localdomain>
	<200810241935.37499.ville.skytta@iki.fi>
Message-ID: <20081024165610.GA1884@nostromo.devel.redhat.com>

Ville Skytt? (ville.skytta at iki.fi) said: 
> On Friday 24 October 2008, Matthias Clasen wrote:
> 
> > Schema files are definitively not conffiles, so the non-conffile warning
> > should be ignored.
> 
> There's a rpmlint bug open about this: https://bugzilla.redhat.com/235487
> 
> Repeating the question from the bug: if they are not configuration files, why 
> are they being installed in /etc/gconf/schemas instead of let's 
> say /usr/share/gconf/schemas?  FWIW, Debian installs them to the latter.

Well, once they're processed, the mandatory/defaults/so forth are all
in /etc, as they should be as system-specific configuration.

Bill



From mclasen at redhat.com  Fri Oct 24 17:02:35 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 24 Oct 2008 13:02:35 -0400
Subject: GConf .schema packaging procedure
In-Reply-To: <200810241935.37499.ville.skytta@iki.fi>
References: <507738ef0810240546x7e035d9fn6d612fca1a8de4b5@mail.gmail.com>
	<1224853991.3345.11.camel@localhost.localdomain>
	<200810241935.37499.ville.skytta@iki.fi>
Message-ID: <1224867755.5222.6.camel@localhost.localdomain>

On Fri, 2008-10-24 at 19:35 +0300, Ville Skytt? wrote:
> On Friday 24 October 2008, Matthias Clasen wrote:
> 
> > Schema files are definitively not conffiles, so the non-conffile warning
> > should be ignored.
> 
> There's a rpmlint bug open about this: https://bugzilla.redhat.com/235487
> 
> Repeating the question from the bug: if they are not configuration files, why 
> are they being installed in /etc/gconf/schemas instead of let's 
> say /usr/share/gconf/schemas?  FWIW, Debian installs them to the latter.
> 

Because changing this now would be a giant amount of busy work, while a
gconf replacement is already under development, which will do away with
the need for schema installation.



From vpivaini at cs.helsinki.fi  Fri Oct 24 17:18:45 2008
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Fri, 24 Oct 2008 20:18:45 +0300
Subject: Unofficial OpenOffice translations (Was: OpenOffice and go-oo)
In-Reply-To: <1223888234.4182.9.camel@ScaryMonster>
References: <1223888234.4182.9.camel@ScaryMonster>
Message-ID: <200810242018.45718.vpivaini@cs.helsinki.fi>

Hi,

Inspired by this thread I took a look at the Finnish translations of 
OpenOffice in Fedora and also contacted the people who lead the Finnish L10n 
project of OpenOffice.

Apparently there are two sets of translations available for OpenOffice. Sun 
has the official translations, which are also in Fedora's OpenOffice. Then 
there's an unofficial collection of translations, to my knowledge someone 
called Pavel Janik collects those translations from the maintainers of each 
language and also does unofficial builds with them included. Those 
translations are available here:

ftp://ftp.linux.cz/pub/localization/OpenOffice.org/devel/build/Files/DEV300/

It seems the unofficial translations are in some cases much more complete than 
the unofficial translations. This is because the Sun Contributor Agreement 
process is considered to be too cumbersome and many contributors have not 
signed the SCA.

If someone who has not signed the SCA has contributed to the translations then 
these translations can't be submitted to Sun's official version anymore 
(unless someone goes through the trouble of identifying and taking out those 
parts of the translation which are made without the agreement). This is the 
case with the Finnish translations and so the Finnish translations included 
in Sun's official source code and Fedora have not been updated in three 
years! The situation is probably similar with other languages as well.

The unofficial translations provided by Pavel Janik are used in the Debian 
derivatives for example. Could Fedora also start using those, so we would get 
a more completely translated OpenOffice?


-- 
Ville-Pekka Vainio



From ob.system at gmail.com  Fri Oct 24 17:24:18 2008
From: ob.system at gmail.com (Oscar Victorio Calixto Bacho)
Date: Fri, 24 Oct 2008 12:24:18 -0500
Subject: Anyone want to take azureus?
In-Reply-To: <20081024182015.412ea049@cheeky>
References: <20081024160006.F311961ABAC@hormel.redhat.com>
	<20081024182015.412ea049@cheeky>
Message-ID: <6a28481b0810241024y19e1f3ch9138784b1e0cfff4@mail.gmail.com>

2008/10/24 Stefan Posdzich <cheekyboinc at foresightlinux.org>

> > Anyone want to take azureus?
>
> I would like to take the package!
>

 What about Azureus 4.0 ?

Cheers

Oscar Bacho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081024/e56f09e7/attachment.htm>

From langel at redhat.com  Fri Oct 24 17:51:50 2008
From: langel at redhat.com (Lillian Angel)
Date: Fri, 24 Oct 2008 13:51:50 -0400
Subject: Anyone want to take azureus?
In-Reply-To: <20081024182015.412ea049@cheeky>
References: <20081024160006.F311961ABAC@hormel.redhat.com>
	<20081024182015.412ea049@cheeky>
Message-ID: <49020B36.2090604@redhat.com>

Stefan Posdzich wrote:
>> Anyone want to take azureus?
>>     
>
> I would like to take the package!
>
>   

It is all yours. I will orphan the package and you can grab it.  There 
is a new bug open to update it to 4.0. This will require a revamp of the 
package (probably a huge cleanup).


Thanks so much!
Lillian



From orion at cora.nwra.com  Fri Oct 24 17:57:45 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 24 Oct 2008 11:57:45 -0600
Subject: rawhide report: 20081024 changes
In-Reply-To: <9497e9990810240514k5c4bc0c3r47279baed8c9cc94@mail.gmail.com>
References: <20081024102540.CAD6E1F824A@releng2.fedora.phx.redhat.com>
	<9497e9990810240514k5c4bc0c3r47279baed8c9cc94@mail.gmail.com>
Message-ID: <49020C99.6080300@cora.nwra.com>

Mat Booth wrote:
> On Fri, Oct 24, 2008 at 10:25 AM, Rawhide Report
> <rawhide at fedoraproject.org> wrote:
>> java-1.6.0-openjdk-1.6.0.0-1.0.b12.fc10
>> ---------------------------------------
>> - Changed to use IcedTeaPlugin.so instead of gcjwebplugin.so. Includes
>> LiveConnect support.
> 
> 
> Thanks for the effort put in to bring LiveConnect support to OpenJDK.
> This has been one of the things keeping me on Sun's JDK in Fedora.

Seconded.  This now works with several sites that were not working before.


-- 
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 sundaram at fedoraproject.org  Fri Oct 24 18:00:01 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 24 Oct 2008 23:30:01 +0530
Subject: rawhide report: 20081024 changes
In-Reply-To: <49020C99.6080300@cora.nwra.com>
References: <20081024102540.CAD6E1F824A@releng2.fedora.phx.redhat.com>	<9497e9990810240514k5c4bc0c3r47279baed8c9cc94@mail.gmail.com>
	<49020C99.6080300@cora.nwra.com>
Message-ID: <49020D21.3040204@fedoraproject.org>

Orion Poplawski wrote:
> Mat Booth wrote:
>> On Fri, Oct 24, 2008 at 10:25 AM, Rawhide Report
>> <rawhide at fedoraproject.org> wrote:
>>> java-1.6.0-openjdk-1.6.0.0-1.0.b12.fc10
>>> ---------------------------------------
>>> - Changed to use IcedTeaPlugin.so instead of gcjwebplugin.so. Includes
>>> LiveConnect support.
>>
>>
>> Thanks for the effort put in to bring LiveConnect support to OpenJDK.
>> This has been one of the things keeping me on Sun's JDK in Fedora.
> 
> Seconded.  This now works with several sites that were not working before.

It would be good to get bug reports on any site which does not work. I 
suppose we will run across some.

Rahul




From orion at cora.nwra.com  Fri Oct 24 18:11:06 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 24 Oct 2008 12:11:06 -0600
Subject: odf-converter for fedora
Message-ID: <49020FBA.9030701@cora.nwra.com>

Has anyone looked into building odf-converter for Fedora?

-- 
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 overholt at redhat.com  Fri Oct 24 18:16:01 2008
From: overholt at redhat.com (Andrew Overholt)
Date: Fri, 24 Oct 2008 14:16:01 -0400
Subject: rawhide report: 20081024 changes
In-Reply-To: <49020D21.3040204@fedoraproject.org>
References: <20081024102540.CAD6E1F824A@releng2.fedora.phx.redhat.com>
	<9497e9990810240514k5c4bc0c3r47279baed8c9cc94@mail.gmail.com>
	<49020C99.6080300@cora.nwra.com>
	<49020D21.3040204@fedoraproject.org>
Message-ID: <20081024181601.GA10124@redhat.com>

* Rahul Sundaram <sundaram at fedoraproject.org> [2008-10-24 14:01]:
> Orion Poplawski wrote:
>> Mat Booth wrote:
>>> On Fri, Oct 24, 2008 at 10:25 AM, Rawhide Report
>>> <rawhide at fedoraproject.org> wrote:
>>>> java-1.6.0-openjdk-1.6.0.0-1.0.b12.fc10
>>>> ---------------------------------------
>>>> - Changed to use IcedTeaPlugin.so instead of gcjwebplugin.so. Includes
>>>> LiveConnect support.
>>>
>>> Thanks for the effort put in to bring LiveConnect support to OpenJDK.
>>> This has been one of the things keeping me on Sun's JDK in Fedora.
>>
>> Seconded.  This now works with several sites that were not working before.
>
> It would be good to get bug reports on any site which does not work. I  
> suppose we will run across some.

Deepak had also talked about asking the testing folks to bang on it one
of these test days.

Andrew

P.S. Deepak (and before him Tom Fitzsimmons) has been working really
hard on this and it's great to see his work come to fruition.



From alsadi at gmail.com  Fri Oct 24 18:54:59 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 24 Oct 2008 21:54:59 +0300
Subject: odf-converter for fedora
In-Reply-To: <49020FBA.9030701@cora.nwra.com>
References: <49020FBA.9030701@cora.nwra.com>
Message-ID: <385866f0810241154m4d3d1318xab37e77d040f88dd@mail.gmail.com>

from < http://www.oooninja.com/2008/01/openxml-translator-odf-converter-11.html
<<EOQ
The odf-converter only integrates into Novell and Ubuntu editions of
OpenOffice.org. The odf-converter may work with the Go-Oo edition, but
I am not sure. It does not work with the upstream version (the version
from the OpenOffice.org web site that most people use) or with the
Fedora version, so don't even try.

EOQ

we had a long talk about go-oo vs. upstream
I took the side of reconsidering go-oo, and this could be another
point into that side

see http://fedoraproject.org/wiki/FWN/LatestIssue#OpenOffice_and_go-oo



From alsadi at gmail.com  Fri Oct 24 19:02:14 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 24 Oct 2008 22:02:14 +0300
Subject: odf-converter for fedora
In-Reply-To: <385866f0810241154m4d3d1318xab37e77d040f88dd@mail.gmail.com>
References: <49020FBA.9030701@cora.nwra.com>
	<385866f0810241154m4d3d1318xab37e77d040f88dd@mail.gmail.com>
Message-ID: <385866f0810241202t572abe05r27effe2ba8fa3318@mail.gmail.com>

but for the record a benchmark done by the same site says the fedora's
oo.o is the fastest 2.4.1 oo.o
http://www.oooninja.com/2008/09/fastest-openofficeorg-edition-benchmark.html



From vpivaini at cs.helsinki.fi  Fri Oct 24 19:05:52 2008
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Fri, 24 Oct 2008 22:05:52 +0300
Subject: Unofficial OpenOffice translations (Was: OpenOffice and go-oo)
In-Reply-To: <200810242018.45718.vpivaini@cs.helsinki.fi>
References: <1223888234.4182.9.camel@ScaryMonster>
	<200810242018.45718.vpivaini@cs.helsinki.fi>
Message-ID: <200810242205.52582.vpivaini@cs.helsinki.fi>

Ville-Pekka Vainio wrote:
>
> It seems the unofficial translations are in some cases much more complete
> than the unofficial translations.

Yeah right. I meant "It seems the unofficial translations are in some cases 
much more complete than the _official_ translations."


-- 
Ville-Pekka Vainio



From drago01 at gmail.com  Fri Oct 24 19:08:00 2008
From: drago01 at gmail.com (drago01)
Date: Fri, 24 Oct 2008 21:08:00 +0200
Subject: odf-converter for fedora
In-Reply-To: <49020FBA.9030701@cora.nwra.com>
References: <49020FBA.9030701@cora.nwra.com>
Message-ID: <f6ca9fed0810241208t3e5ec9a2w464ae63678edd4ea@mail.gmail.com>

On Fri, Oct 24, 2008 at 8:11 PM, Orion Poplawski <orion at cora.nwra.com> wrote:
> Has anyone looked into building odf-converter for Fedora?

its no longer needed in F10+ because oo3 already supports this out of the box.



From skvidal at fedoraproject.org  Fri Oct 24 19:57:41 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 24 Oct 2008 15:57:41 -0400
Subject: providing what they require
In-Reply-To: <alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
	<200810230944.53271.ville.skytta@iki.fi>
	<alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>
Message-ID: <1224878261.29258.22.camel@rosebud>

On Fri, 2008-10-24 at 11:21 +0300, Panu Matilainen wrote:

> Pruning out automatically generated self-requires is about three lines of 
> code, couple more to make it configurable. That's not the issue.
> 

Let's do this, then. :)

> FWIW the number of self-requires on Fedora is vastly larger than what 
> plain upstream rpm would create, due to the patch that generates soname 
> dependencies from symlinks to dso's. For example:
> 
> [pmatilai at localhost ~]$ rpm -q --filerequire cdparanoia-libs
> /usr/lib64/libcdda_interface.so	R libcdda_interface.so.0()(64bit)
> /usr/lib64/libcdda_interface.so.0	R libcdda_interface.so.0()(64bit)
> /usr/lib64/libcdda_interface.so.0.10.0	R libc.so.6()(64bit) R 
> libc.so.6(GLIBC_2.2.5)(64bit) R libc.so.6(GLIBC_2.3)(64bit) R 
> libc.so.6(GLIBC_2.4)(64bit) R libm.so.6()(64bit) R 
> libm.so.6(GLIBC_2.2.5)(64bit) R rtld(GNU_HASH)
> 
> Of course those would be gone too if self-requires were pruned.

which sounds fine, then.

> As it is now, every dependency in a package gets unconditionally recorded, 
> regardless of where the provider comes from. It's a very straightforward 
> rule. And yes it causes some unwanted side-effects, such as the one noted 
> by Bill here 
> http://lists.rpm.org/pipermail/rpm-maint/2007-July/001580.html and header 
> bloat. Changing that is possible and even trivial, it just "breaks" fairly 
> long time rpm behavior and opens up a different can of worms (a 
> dirt-simple rule comes bunch of special cases). Making it configurable 
> via macro would push the decision to vendors and packagers, but ...
> 


Explain to me what it breaks in terms of backward compat? I'm thinking
that maybe for F11-cycle it could be worth breaking that compat.


> IMO they're not funky, they're absolutely useless. The idea behind those 
> is that you can provide alternate configuration for a package, which is 
> fine and well, except it's very broken by design:
> 
> Say you have package foo with some configuration and myconfig-foo with a 
> custom config for it. The idea is that you can install foo with 
> --noconfigs but as foo requires (automatically) config(foo), this should 
> not be possible unless there's another package in the transaction 
> providing config(foo). Except that the provide is not pruned at runtime 
> with --noconfigs like it should... But lets imagine it did that: so you 
> provide your own configuration in the transaction, ie "rpm -Uvh 
> --noconfigs foo.rpm myconfig-foo.rpm". --noconfigs is a per-transaction 
> flag, so the config files from myconfig-foo wouldn't be installed either. 
> Oops. And for this misfeature, every package with a config file in it, 
> carries an extra provide + require on itself.

Do we have a single case of something using config() in fedora?
Hell, ANYWHERE? any distro at all?

If not then maybe this is a feature that can take a long walk off a
short pier?

-sv




From skvidal at fedoraproject.org  Fri Oct 24 20:21:48 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 24 Oct 2008 16:21:48 -0400
Subject: providing what they require
In-Reply-To: <1224878261.29258.22.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
	<200810230944.53271.ville.skytta@iki.fi>
	<alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>
	<1224878261.29258.22.camel@rosebud>
Message-ID: <1224879708.29258.31.camel@rosebud>

On Fri, 2008-10-24 at 15:57 -0400, seth vidal wrote:


> Do we have a single case of something using config() in fedora?
> Hell, ANYWHERE? any distro at all?
> 
> If not then maybe this is a feature that can take a long walk off a
> short pier?

Okay in F9 GA i686 there are 137K requires - 1126 of them are config()
requires. .8% - not huge but something - about 15K, gzipped of the
metadata.

For provides there are 40K in GA and 1127 config() provides. Again -
about 15K gzipped in the metadata. That's 2.7% of the provides. 

It's not a huge win but it's 2 less items to go through per package.

Panu, how do you feel about taking config() requires/provides out back
and shooting them in F11?

-sv
 



From rjones at redhat.com  Fri Oct 24 20:32:18 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 24 Oct 2008 21:32:18 +0100
Subject: Package review swapsies (5+ packages)
Message-ID: <20081024203218.GA14582@amd.home.annexia.org>

I will swap, one-for-one, package reviews for these 5 key MinGW
cross-compiler[1] packages:

https://bugzilla.redhat.com/show_bug.cgi?id=467260
- mingw32-filesystem - base filesystem and environment
https://bugzilla.redhat.com/show_bug.cgi?id=454408
- mingw32-binutils - binutils like 'as', 'ld', 'objdump'
https://bugzilla.redhat.com/show_bug.cgi?id=454410
- mingw32-gcc - the cross-compiler itself
https://bugzilla.redhat.com/show_bug.cgi?id=454412
- mingw32-runtime - runtime libraries
https://bugzilla.redhat.com/show_bug.cgi?id=454414
- mingw32-w32api - Win32 API header files and library stubs

And for anyone who is really ambitious, I will swap one-for-one with
any of the following 37 package reviews:

https://bugzilla.redhat.com/buglist.cgi?quicksearch=mingw32

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From rjones at redhat.com  Fri Oct 24 20:34:21 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 24 Oct 2008 21:34:21 +0100
Subject: Package review swapsies (5+ packages)
In-Reply-To: <20081024203218.GA14582@amd.home.annexia.org>
References: <20081024203218.GA14582@amd.home.annexia.org>
Message-ID: <20081024203421.GB14582@amd.home.annexia.org>

On Fri, Oct 24, 2008 at 09:32:18PM +0100, Richard W.M. Jones wrote:
> I will swap, one-for-one, package reviews for these 5 key MinGW
> cross-compiler[1] packages:

That footnote was meant to be:

[1] http://fedoraproject.org/wiki/MinGW

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From triad at df.lth.se  Fri Oct 24 20:48:59 2008
From: triad at df.lth.se (Linus Walleij)
Date: Fri, 24 Oct 2008 22:48:59 +0200
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
Message-ID: <1224881339.17871.14.camel@c83-254-32-222.bredband.comhem.se>

fre 2008-10-24 klockan 13:05 +0200 skrev Valent Turkovic:

> What is the status of Fedora kernel regarding specific patches that
> make desktop perform better?

The CFS was merged ages ago and there is a very wide consensus that it
gives the same kind of interactivity boost as CK:s rotating staircase.

On top of that the control groups for CPU slicing will be available in
F10. There is no consensus of how to make use for it in the desktop
scenarios though, so won't add much as for now. Control groups look like
they will be able to e.g. prioritize things like the memory hierarchy
and network traffic for the desktop use case (as well as other use
cases) in the long (well, some year or two) run, but it is being
intensely developed right now.

Swap prefetch was the most interesting patch from the CK tree IMHO:
http://lwn.net/Articles/242765/
Sadly I don't know what has happend in this regard :-/ Anyone else?

While we're at interactivity, there is this thing called "ionice" that
interacts with the CFQ I/O scheduler from userspace. It is probably a
good idea  to "ionice -c1" (realtime) things like your Gstreamer or
mplayer, and "ionice -c3" (idle) your transmission bittorrent client,
updatedb or backup tasks. I do this manually from time to time, but
cannot really claim I notice any big differences. Such heuristic
ionice:ing is nowhere to be seen, does anyone know if it is being looked
into anywhere at all?

All in all, there are popping up some real nice interactivity features
in the kernel, but AFAIK noone is really working on using them in the
desktop usecase.

Just my Euro 0.01...
Linus



From bruno at wolff.to  Fri Oct 24 21:31:45 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 24 Oct 2008 16:31:45 -0500
Subject: state of Fedora kernel and Desktop use?
In-Reply-To: <1224881339.17871.14.camel@c83-254-32-222.bredband.comhem.se>
References: <64b14b300810240405of94fdc7q5c2f2ff1c870a68f@mail.gmail.com>
	<1224881339.17871.14.camel@c83-254-32-222.bredband.comhem.se>
Message-ID: <20081024213145.GA15578@wolff.to>

On Fri, Oct 24, 2008 at 22:48:59 +0200,
  Linus Walleij <triad at df.lth.se> wrote:
> fre 2008-10-24 klockan 13:05 +0200 skrev Valent Turkovic:
> 
> All in all, there are popping up some real nice interactivity features
> in the kernel, but AFAIK noone is really working on using them in the
> desktop usecase.

It's not working so nice in rawhide. I am seeing copying data to an encrypted
usb drive lock up the X server for times on the order of a minute (presumably
when it needs to page something in). Very annoying. At least it recovers.
When combined with high memory use, sometimes the whole machine locks up
and a reboot is necessary to clear things up.



From dr.diesel at gmail.com  Fri Oct 24 23:06:59 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 24 Oct 2008 19:06:59 -0400
Subject: Rawhide Realtek bug?
Message-ID: <2a28d2ab0810241606s5e896a29ucbd79fe45c003c0c@mail.gmail.com>

Is this a bug, anyone else?  This just happened on the last day or two
rawhide, notice the MAC address?

[root at localhost ~]# lspci | grep Ethernet
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E
PCI Express Fast Ethernet controller (rev 01)
[root at localhost ~]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:18 Base address:0xa000

[root at localhost ~]# uname -r
2.6.27.3-39.fc10.i686
[root at localhost ~]#


-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org



From konrad at tylerc.org  Fri Oct 24 23:10:48 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 24 Oct 2008 16:10:48 -0700
Subject: Rawhide Realtek bug?
In-Reply-To: <2a28d2ab0810241606s5e896a29ucbd79fe45c003c0c@mail.gmail.com>
References: <2a28d2ab0810241606s5e896a29ucbd79fe45c003c0c@mail.gmail.com>
Message-ID: <200810241610.48367.konrad@tylerc.org>

On Friday 24 October 2008 04:06:59 pm Dr. Diesel wrote:
> Is this a bug, anyone else?  This just happened on the last day or two
> rawhide, notice the MAC address?
>
> [root at localhost ~]# lspci | grep Ethernet
> 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E
> PCI Express Fast Ethernet controller (rev 01)
> [root at localhost ~]# ifconfig eth0
> eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>           BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>           Interrupt:18 Base address:0xa000
>
> [root at localhost ~]# uname -r
> 2.6.27.3-39.fc10.i686
> [root at localhost ~]#
>
>
> --
> projecthuh.com
> All of my bits are free, are yours?  Fedoraproject.org

See Jesse Keating's email from earlier today (maybe yesterday if you're in a 
different time zone).

"""
Of important note, these images do have a bug in them,
https://bugzilla.redhat.com/show_bug.cgi?id=468360 where some realtek
network cards will not initialize properly.  This bug has been fixed in
today's rawhide, which was too late for the snapshot.  If you use the
snapshot and fail to have networking, you'll need to update the kernel.
"""

-- 
Conrad Meyer <konrad at tylerc.org>




From sundaram at fedoraproject.org  Fri Oct 24 23:12:13 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 25 Oct 2008 04:42:13 +0530
Subject: Rawhide Realtek bug?
In-Reply-To: <2a28d2ab0810241606s5e896a29ucbd79fe45c003c0c@mail.gmail.com>
References: <2a28d2ab0810241606s5e896a29ucbd79fe45c003c0c@mail.gmail.com>
Message-ID: <4902564D.60702@fedoraproject.org>

Dr. Diesel wrote:
> Is this a bug, anyone else?  This just happened on the last day or two
> rawhide, notice the MAC address?

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

Rahul



From dr.diesel at gmail.com  Fri Oct 24 23:41:04 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Fri, 24 Oct 2008 19:41:04 -0400
Subject: Rawhide Realtek bug?
In-Reply-To: <4902564D.60702@fedoraproject.org>
References: <2a28d2ab0810241606s5e896a29ucbd79fe45c003c0c@mail.gmail.com>
	<4902564D.60702@fedoraproject.org>
Message-ID: <2a28d2ab0810241641x67989501rcd2844c7c609f26e@mail.gmail.com>

On Fri, Oct 24, 2008 at 7:12 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Dr. Diesel wrote:
>>
>> Is this a bug, anyone else?  This just happened on the last day or two
>> rawhide, notice the MAC address?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=468360
>
> Rahul

Many thanks!

Pinged the bug, with patch disabled kernel:

[root at localhost ~]# uname -r
2.6.27.3-44.fc10.i686
[root at localhost ~]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:18 Base address:0xa000

[root at localhost ~]# lspci | grep Ethernet
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E
PCI Express Fast Ethernet controller (rev 01)
[root at localhost ~]#




-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org



From mattdm at mattdm.org  Sat Oct 25 00:31:11 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 24 Oct 2008 20:31:11 -0400
Subject: FESCo Meeting Summary for 2008-10-22
In-Reply-To: <49015904.6080803@leemhuis.info>
References: <1224791613.4174.4.camel@kennedy> <49015904.6080803@leemhuis.info>
Message-ID: <20081025003111.GA7934@jadzia.bu.edu>

On Fri, Oct 24, 2008 at 07:11:32AM +0200, Thorsten Leemhuis wrote:
> I'm willing to help Ville and Matthew making a real solution, where sbin 
> stays "root commands" only, and where package that are right now get into 
> he search path for ordinary users (either with symlinks or by moving the 
> binaries). But it's IMHO best for everyone if we do that for F11. Come on, 
> we had /sbin not in the path for more then how many years, so what is one 
> half year more (especially as everyone that dislikes it is used to enable 
> it already)?

I'm pretty much resigned to leaving it as it now stands (sbin in the path)
and proposing "Sbin Sanity, Now With Actual Sanity" for the F11 development
process.


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From pertusus at free.fr  Sat Oct 25 09:39:08 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 25 Oct 2008 11:39:08 +0200
Subject: orphaning acpi
Message-ID: <20081025093908.GA2608@free.fr>

Hello,

I am orphaning the acpi package,
http://grahame.angrygoats.net/moinmoin/AcpiClient

because
* there are lots of bug reports wrongly directed to that component, it
 is annoying, and the symptom of a wrong name for the package
* acpitool does the same and more, and acpi didn't catch up with
  acpitool
* if the old /proc/acpi interface is dropped from the kernel it won't
  work anymore

If somebody wants to take it anyway, it is a very low maintainance
package (no change since mar 2006, license tag is wrong, but otherwise 
everything should right, and for a long time), at least as long as the 
old acpi interface is kept in the kernel. But be prepared to do some 
triaging!

--
Pat



From pertusus at free.fr  Sat Oct 25 10:23:43 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 25 Oct 2008 12:23:43 +0200
Subject: PackageMaintainers/Policy/EOL out of date
Message-ID: <20081025102343.GB2608@free.fr>

Hello,

The page 
https://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL
is out of date, pre-merge. I would like to update it, however I cannot
find an explanation of the current scheedule, there is only something
about the releases, 
https://fedoraproject.org/wiki/Releases/Schedule
I can't find the description of the EOL. Unless I am wrong, F-N+2 is EOL
one month after the release of F-N, but I don't know exaclty when events
relevant for packagers happen, like when new branches for packages
aren't created anymore, or when the builds are stopped for real happen.

If you give me some information or link to a page explaining the
EOL schedule, I'll update.

--
Pat



From rawhide at fedoraproject.org  Sat Oct 25 10:56:49 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 25 Oct 2008 10:56:49 +0000 (UTC)
Subject: rawhide report: 20081025 changes
Message-ID: <20081025105649.CE8651B8001@releng2.fedora.phx.redhat.com>

Compose started at Sat Oct 25 06:01:12 UTC 2008

New package beediff
        Visual tool for comparing and merging files
New package clojure
        A dynamic programming language that targets the Java Virtual Machine
New package jmol
        An open-source Java viewer for chemical structures in 3D
New package php-pear-Auth
        Authentication provider for PHP
New package rubygem-pam
        Ruby bindings for pam
New package rubygem-sqlite3-ruby
        Allows Ruby scripts to interface with a SQLite3 database
New package solar-kde-theme
        Solar KDE Theme
New package ume-launcher
        A clutter-based desktop launcher
New package v4l2ucp
        Video4linux universal control panel
Updated Packages:

PackageKit-0.3.8-6.fc10
-----------------------
* Fri Oct 24 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.3.8-6
- Customize Vendor.conf for Fedora

* Fri Oct 24 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.8-5
- Bump as I forgot to add the patch.

* Fri Oct 24 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.8-4
- Add a patch from upstream to change the servicepack metadata format to be
  forwards compatible so we don't let the user create invalid packs.


PyYAML-3.06-1.fc10
------------------
* Fri Oct 24 18:00:00 2008 John Eckersberg <jeckersb at redhat.com> - 3.06-1
- New upstream release


anaconda-11.4.1.51-1
--------------------
* Fri Oct 24 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.51-1
- Catch UnicodeDecodeError so traceback messages display anyway. (dcantrell)
- Do not write NM_CONTROLLED=yes to ifcfg files (#468028) (dcantrell)
- Log D-Bus messages at ERROR or INFO level. (dcantrell)
- Write dhcpclass to the dhclient conf file for the device (#468436)
  (dcantrell)
- Tell NetworkManager not to touch network interfaces when / is a netfs
  (hans)
- Catch more X failures and fallback to text (#467158). (clumens)
- Fix a typo when using network --gateway (#468364). (clumens)
- Fix icon (#468273) (katzj)
- Remove extra debug info. (pjones)
- Fix the damn spinner in the progress bar. (pjones)
- Fix whitespace. (pjones)
- Fix "looking for installation images" when there's no disc at all. (pjones)
- Make sure dialog deletions take effect sooner (#455676). (clumens)
- Make cdrom drive door status messages be INFO not DEBUG. (pjones)
- Don't switch to tty6 on vnc installs. (clumens)
- Update font list (#462295). (clumens)
- Don't display the entire lengthy device description (#467825). (clumens)
- Fix ext4 detection on existing partitions (#467047) (rvykydal)
- Make sure we handle the /tmp/method file for FTP correctly (#467753).
  (clumens)
- Do not write NM_CONTROLLED=yes to ifcfg files (#468028) (dcantrell)
- Revert "dhclient-script not needed for NetworkManager" (clumens)
- Skip Installation Repo when writing out repo kickstart lines. (clumens)
- Correct media check docs (#468061). (clumens)
- Many translation updates


anacron-2.3-65.fc10
-------------------
* Fri Oct 24 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> 2.3-65
- rewrite init script - using fedora guidelines SysVInitScript


at-3.1.10-26.fc10
-----------------
* Fri Oct 24 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 3.1.10-26
- update init script according to SysVInitScript


audit-1.7.8-3.fc10
------------------

augeas-0.3.3-1.fc10
-------------------
* Fri Oct 24 18:00:00 2008 David Lutterkort <dlutter at redhat.com> - 0.3.3-1
- New version


compat-db-4.6.21-5.fc10
-----------------------
* Fri Oct 24 18:00:00 2008 Jindrich Novy <jnovy at redhat.com> 4.6.21-5
- drop support for 4.3.29
- split compat-db to compat-db45 and compat-db46 subpackages
  to avoid dependency bloat (#459710)


compiz-fusion-0.7.6-7.fc10
--------------------------
* Fri Oct 24 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.7.6-7
- Fix up winrules plugin (backport from git head)


cronie-1.2-4.fc10
-----------------
* Fri Oct 24 18:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 1.2-4
- update init script


deluge-1.0.3-1.fc10
-------------------
* Fri Oct 24 18:00:00 2008 Peter Gordon <peter at thecodergeek.com> - 1.0.3-1
- Update to new upstream release (1.0.3)


efax-0.9a-3.001114.fc10
-----------------------
* Fri Oct 24 18:00:00 2008 Than Ngo <than at redhat.com> 0.9a-3.001114
- fix efax segfaults while sending fax, thanks to Jeff Bastian


fedora-logos-10.0.0-1.fc10
--------------------------
* Fri Oct 24 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 10.0.0-1
- New solar art


ganglia-3.1.1-1.fc10
--------------------
* Fri Oct 24 18:00:00 2008 Jarod Wilson <jarod at redhat.com> 3.1.1-1
- Update to 3.1.1

* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> 3.1.0-2
- Include unowned directories.


gdal-1.5.3-1.fc10
-----------------
* Fri Oct 24 18:00:00 2008 Balint Cristian <rezso at rdsor.ro> - 1.5.3-1
- new stable
- ship static package too
- fix some doc generation
- libdap patch for fc10 only


glib2-2.18.2-2.fc10
-------------------
* Fri Oct 24 18:00:00 2008 Alexander Larsson <alexl at redhat.com> - 2.18.2-2
- Don't return generic fallback icons for files,
  as this means custom mimetypes don't work (from svn)


gnome-desktop-2.24.1-2.fc10
---------------------------
* Fri Oct 24 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-2
- properly initialize variable in gnome_bg_get_pixmap_from_root
  (bug 460758)


gnome-packagekit-0.3.8-2.fc10
-----------------------------
* Fri Oct 24 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.8-2
- Fix the untitled window in gpk-update-viewer. Fixes #468200
- Fix the resize problem on small form factor devices. Fixes #467987


gnome-power-manager-2.24.1-2.fc10
---------------------------------
* Fri Oct 24 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 2.24.1-2
- Backport some patches from trunk to fix:
 - Duplicate buttons from X and HAL
 - Use the Sessionmanager rather than the old gnome_client_request_save
 - Ignore policy actions when the session is not active


gnome-settings-daemon-2.24.0-14.fc10
------------------------------------
* Fri Oct 24 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.0-14
- At fontconfig-devel buildrequires (bug 468304)


gstreamer-plugins-good-0.10.11-1.fc10
-------------------------------------
* Sat Oct 25 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.10.11-1
- Update to 0.10.11
- Update libv4l patch


gtk2-2.14.4-3.fc10
------------------
* Fri Oct 24 18:00:00 2008 Alexander Larsson <alexl at redhat.com> - 2.14.4-3
- Manually check for fallback file icon since we're not
  always returning that from gio anymore (from upstream)


gvfs-1.0.2-2.fc10
-----------------
* Fri Oct 24 18:00:00 2008 Alexander Larsson <alexl at redhat.com> - 1.0.2-2
- Don't return generic fallback icons for files,
  as this means custom mimetypes don't work (from svn)


hal-cups-utils-0.6.17-4.fc10
----------------------------
* Fri Oct 24 18:00:00 2008 Tim Waugh <twaugh at redhat.com> 0.6.17-4
- Don't fail due to missing usb Python module (bug #468408).


kdebase-workspace-4.1.2-7.fc10
------------------------------
* Sat Oct 25 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-7
- F10: use KDM default face icon from solar-kde-theme, require it


kernel-2.6.27.3-44.fc10
-----------------------
* Thu Oct 23 18:00:00 2008 Jarod Wilson <jarod at redhat.com> 2.6.27.3-42
- Disable r8169 2.6.28 update patch, causes much bustification

* Thu Oct 23 18:00:00 2008 Hans de Goede <hdegoede.redhat.com> 2.6.27.3-39
- Disable the obsolete zc0301 driver (superseeded by gspca_zc3xx)

* Thu Oct 23 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.3-44
- Disable the snd-aw2 driver until upstream comes up with a fix.

* Thu Oct 23 18:00:00 2008 Adam Jackson <ajax at redhat.com> 2.6.27.3-43
- Hush more PCI BAR allocation failures


libepc-0.3.8-1.fc10
-------------------
* Fri Oct 24 18:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.3.8-1
- Update to 0.3.8.
- Drop build patch.  Fixed upstream.


libgdl-2.24.0-1.fc10
--------------------
* Fri Oct 24 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 2.24.0-1
- Version bump to 2.24.0.
- Rpaths removed by upstream.
- libgdl-gnome-1.so has been dropped.


libmtp-0.3.3-2.fc10
-------------------
* Fri Oct 24 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.3-2
- Add support for the Nokia N82


logwatch-7.3.6-31.fc10
----------------------
* Fri Oct 24 18:00:00 2008 Ivana Varekova <varekova at redhat.com> 7.3.6-31
- parse another bunch of postfix logs(#467378)


lyx-1.6.0-0.10.rc4.fc10
-----------------------
* Fri Oct 24 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.6.0-0.10.rc4
- lyx-1.6.0rc4


mod_fcgid-2.2-6.fc10
--------------------
* Tue Oct 21 18:00:00 2008 Paul Howarth <paul at city-fan.org> 2.2-6
- SELinux policy module rewritten to merge fastcgi and system script domains
  in preparation for merge into main selinux-policy package (#462318)
- Try to determine supported SELinux policy types by reading /etc/selinux/config


moodle-1.9.3-1.fc10
-------------------
* Wed Oct 22 18:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1.9.3-1
- Updated to 1.9.3.
- Updated language packs to 22 Oct 2008 versions.


mx4j-3.0.1-7.8.fc10
-------------------
* Fri Oct 24 18:00:00 2008 David Walluck <dwalluck at redhat.com> 1:3.0.1-7.8
- add %{_javadocdir}/%{name} to file list

* Fri Oct 24 18:00:00 2008 David Walluck <dwalluck at redhat.com> 1:3.0.1-7.7
- own %{_libdir}/gcj/%{name}
- add %{_javadocdir}/%{name} to file list
- remove javadoc scriptlets
- replace /usr/sbin with %{_sbindir}

* Wed Jul  9 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1:3.0.1-7.6
- really fix license tag

* Wed Jul  9 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1:3.0.1-7.5
- drop repotag
- fix license tag

* Mon Feb 18 17:00:00 2008 Fedora Release Engineering <rel-eng at fedoraproject.org> - 1:3.0.1-7jpp.4
- Autorebuild for GCC 4.3


nautilus-2.24.1-2.fc10
----------------------
* Fri Oct 24 18:00:00 2008 Alexander Larsson <alexl at redhat.com> - 2.24.1-2
- Manually check for fallback file icon since we're not
  always returning that from gio anymore (from upstream)


openoffice.org-3.0.0-9.6.fc10
-----------------------------
* Thu Oct 23 18:00:00 2008 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.0-9.6
- add openoffice.org-3.0.0.ooo95318.system-showicons.patch to honour
  gtk-menu-images setting
- Resolves: rhbz#468288 associate text/csv with oocalc


opensp-1.5.2-10.fc10
--------------------
* Fri Oct 24 18:00:00 2008 Ondrej Vasik <ovasik at redhat.com> 1.5.2-10
- move conversion to prep, do not convert html doc(#226217)


pards-0.4-7.fc9
---------------
* Sat Oct  4 18:00:00 2008 Masahiro Hasegawa <masahase at gmail.com> - 0.4-7
- fix spec


planner-0.14.3-6.fc10
---------------------
* Thu Oct 23 18:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.14.3-6
- Rebuild for new camel library from e-d-s


plymouth-0.6.0-0.2008.10.24.1.fc10
----------------------------------
* Fri Oct 24 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.24.1
- Add updated progress bar for solar plugin from Charlie
- Log plymouth:debug output to boot log
- Ignore sigpipe signals in daemon


qdox-1.6.1-5.2.fc10
-------------------
* Fri Oct 24 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.6.1-5.2
- Fedora-specific: enable GCJ support

* Fri Oct 24 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.6.1-5.1
- Fedora-specific: remove repolib
- Fedora-specific: use java_cup not java-cup
- Fedora-specific: don't use jmock

* Tue Jul 29 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.6.1-5
- remove bootstrap binaries
- patch build for newer jflex
- patch build to disable failing tests on JDK6
- BuildRequires: jmock
- fix version in ant build.xml
- fix location of byaccj and jflex output files
- fix apidoc location
- correctly set CLASSPATH and OPT_JAR_LIST

* Mon Jul 28 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.6.1-4
- fix jflex part of build
- GCJ fixes
- fix javadoc Requires

* Sat Jul 26 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.6.1-3
- build without maven
- fix repolib permissions


qgtkstyle-0.0-0.2.20081024svn820.fc10
-------------------------------------
* Fri Oct 24 18:00:00 2008 Shawn Starr <spstarr at fedoraproject.org> 0.0-0.2.20081024svn820
- New upstream snapshot.
- Various speed improvements and stability.


redhat-menus-10.0.0-2.fc10
--------------------------
* Fri Oct 24 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 10.0.0-2
- One more directory rename. Thank you, gnome-menus


rpm-4.6.0-0.rc1.5
-----------------
* Sat Oct 25 18:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- Make noarch sub-packages actually work
- Fix defaultdocdir logic in installplatform to avoid hardwiring mandir

* Fri Oct 24 18:00:00 2008 Jindrich Novy <jnovy at redhat.com>
- update compat-db dependencies (#459710)


sblim-cmpi-base-1.5.7-1.fc10
----------------------------
* Fri Oct 24 18:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.5.7-1
- Update to 1.5.7
  Resolves: #468325


sblim-cmpi-devel-1.0.5-1.fc10
-----------------------------
* Fri Oct 24 18:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.0.5-1
- Update to 1.0.5
  Resolves: #468326


sblim-testsuite-1.2.5-1.fc10
----------------------------
* Fri Oct 24 18:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.2.5-1
- Update to 1.2.5
  Resolves: #468327


sblim-wbemcli-1.6.0-1.fc10
--------------------------
* Fri Oct 24 18:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.6.0-1
- Update to 1.6.0
  Resolves: #468328


selinux-policy-3.5.13-7.fc10
----------------------------
* Thu Oct 23 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-7
- Dontaudit domains trying to write to .xsession-errors

* Thu Oct 23 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-6
- Allow nsplugin to look at autofs_t directory


squid-3.0.STABLE10-1.fc10
-------------------------
* Fri Oct 24 18:00:00 2008 Henrik Nordstrom <henrik at henriknordstrom.net> - 7:3.0.STABLE10-1
- upgrade to latest upstream


swfdec-mozilla-0.8.2-1.fc10
---------------------------
* Thu Oct 23 18:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.8.2-1
- Update to 0.8.2.
- Update source url.


totem-2.24.2-3.fc10
-------------------
* Fri Oct 24 18:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 2.24.2-3
- rebuild for new libepc.


Summary:
Added Packages: 9
Removed Packages: 0
Modified Packages: 52
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
	gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.i386 requires libgnome-desktop-2.so.2
	ume-launcher-0.6.3-1.fc9.i386 requires libclutter-glx-0.6.so.0



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-python2-gdl-2.19.1-20.fc10.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.x86_64 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	ume-launcher-0.6.3-1.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit)



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.ppc requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-python2-gdl-2.19.1-20.fc10.ppc requires libgdl-gnome-1.so.0
	iml-devel-1.0.2-3.fc10.ppc requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.ppc requires libgnome-desktop-2.so.2
	ume-launcher-0.6.3-1.fc9.ppc requires libclutter-glx-0.6.so.0



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	ume-launcher-0.6.3-1.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit)





From pertusus at free.fr  Sat Oct 25 11:04:30 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 25 Oct 2008 13:04:30 +0200
Subject: what QA gets mailed to the packagers?
Message-ID: <20081025110430.GC2608@free.fr>

Hello,

Still trying to bring the wiki up-to-date, I'd like to fix
https://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages

Some points are likely to be out of date, but I don't know exactly what
is done now, regarding:

* nagmails sent for EVR
* nagmails sent for dependency issues

Are those still generated? Is there other similar automatic QA added
since pre-merge time?

--
Pat



From alexl at users.sourceforge.net  Sat Oct 25 11:45:51 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 25 Oct 2008 04:45:51 -0700
Subject: libgdl soname breakage? (was Re: rawhide report: 20081025 changes)
In-Reply-To: <20081025105649.CE8651B8001@releng2.fedora.phx.redhat.com>
	(Rawhide Report's message of "Sat\,
	25 Oct 2008 10\:56\:49 +0000 \(UTC\)")
References: <20081025105649.CE8651B8001@releng2.fedora.phx.redhat.com>
Message-ID: <dtej24aoeo.fsf@allele2.eebweb.arizona.edu>

Grr.  As fast as I try to swot down broken deps in rawhide in advance
of the fast-approaching freeze, they keep popping up again.  A major
culprit today appears to be:

> libgdl-2.24.0-1.fc10
> --------------------
> * Fri Oct 24 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 2.24.0-1
> - Version bump to 2.24.0.
> - Rpaths removed by upstream.
> - libgdl-gnome-1.so has been dropped.

which causes broken deps in several packages:

>  Broken deps for i386
>  ----------------------------------------------------------
> 	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
> 	gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
> 	gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0

Removing libgdl-gnome-1.so seems to be a rather drastic step,
especially if these apps need it and it isn't provided by any other
package.  Is this just a packaging error?  I note that Debarshi Ray
who rebuilt libgdl is also the maintainer of 2 of the 3 broken
packages: anjuta and gnome-build, so I assume that he'll hopefully
have plan to fix this breakage. ;)

Otherwise this change should probably be reverted.

Again, please announce any ABI changes on f-d-l in advance.

Alex



From fedora at matbooth.co.uk  Sat Oct 25 13:31:11 2008
From: fedora at matbooth.co.uk (Mat Booth)
Date: Sat, 25 Oct 2008 14:31:11 +0100
Subject: libgdl soname breakage? (was Re: rawhide report: 20081025
	changes)
In-Reply-To: <dtej24aoeo.fsf@allele2.eebweb.arizona.edu>
References: <20081025105649.CE8651B8001@releng2.fedora.phx.redhat.com>
	<dtej24aoeo.fsf@allele2.eebweb.arizona.edu>
Message-ID: <9497e9990810250631k54754490g58f6fc444d1a983@mail.gmail.com>

On Sat, Oct 25, 2008 at 12:45 PM, Alex Lancaster
<alexl at users.sourceforge.net> wrote:
> Grr.  As fast as I try to swot down broken deps in rawhide in advance
> of the fast-approaching freeze, they keep popping up again.  A major
> culprit today appears to be:
>
>> libgdl-2.24.0-1.fc10
>> --------------------
>> * Fri Oct 24 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 2.24.0-1
>> - Version bump to 2.24.0.
>> - Rpaths removed by upstream.
>> - libgdl-gnome-1.so has been dropped.
>
> which causes broken deps in several packages:
>
>>  Broken deps for i386
>>  ----------------------------------------------------------
>>       1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
>>       gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
>>       gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0
>
> Removing libgdl-gnome-1.so seems to be a rather drastic step,
> especially if these apps need it and it isn't provided by any other
> package.  Is this just a packaging error?  I note that Debarshi Ray
> who rebuilt libgdl is also the maintainer of 2 of the 3 broken
> packages: anjuta and gnome-build, so I assume that he'll hopefully
> have plan to fix this breakage. ;)
>
> Otherwise this change should probably be reverted.
>
> Again, please announce any ABI changes on f-d-l in advance.
>
> Alex
>

Yeah, Debarshi says he'll take care of Anjuta and gnome-build.

https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02330.html

-- 
Mat Booth
www.matbooth.co.uk



From wtogami at redhat.com  Sat Oct 25 14:04:40 2008
From: wtogami at redhat.com (Warren Togami)
Date: Sat, 25 Oct 2008 10:04:40 -0400
Subject: R-devel going away
In-Reply-To: <1224770108.3601.40.camel@localhost.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>
Message-ID: <49032778.2080800@redhat.com>

Tom "spot" Callaway wrote:
> This email serves as an announcement that I plan to swallow up R-devel
> into the base R package. Why?
> 
> * It is causing no end of user complaints. The typical R user expects to
> be able to do a "CPAN" (really, I should say "CRAN") style package
> install through the R interface:
> 

Isn't this exactly counter to the logic behind splitting perl into 
perl-devel, that ended up angering jpo to the point of him quitting Fedora?

The rest of this explanation seems to make sense.  But does this mean we 
make a mistake earlier in the perl split?

Warren Togami
wtogami at redhat.com



From fedora at leemhuis.info  Sat Oct 25 15:04:44 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 25 Oct 2008 17:04:44 +0200
Subject: Second steps of the transition from Livna to RPM Fusion begins:
 Enabling RPM Fusion for users of livna-testing!
Message-ID: <4903358C.6010609@leemhuis.info>

Hi!

Find below a cut'n'pasted and slightly enhanced version of a post from
my blog FYI:


As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ),
the merger of Dribble, Freshrpms and Livna gets closer to its official
release/start. Most of the packages from Livna have been imported and
build for RPM Fusion already, hence we now begin to slowly enable RPM 
Fusion for users of Livna by activating the RPM Fusion free and
nonfree repos for users of livna's F8 and F9 testing repos *now*.

The process works like this: I added the rpmfusion-release packages for 
RPM Fusion's free and nonfree repos to the livna repo for F8 and F9; 
afterwards I built new livna-release for F8 and F9 that is available in 
  livna-testing for F8 and F9 now; those two livna-release packages 
track the two rpmfusion-release packages in with a hard dep. That way 
all users that installed livna properly (e.g. by installing the 
livna-release package) and enabled the testing repos will now get RPM 
Fusion enabled automatically.

Note, nearly all of livna's packages have been imported and build for 
RPM Fusion, but a few are still missing. So you should leave livna repos 
enabled for now if you want everything. Once all the packages have a new 
home we'll let the rpmfusion-nonfree-release package obsolete livna-release.

The plan is to move regular livna users of F8 and F9 over to RPM Fusion 
with the same trick sooner or later. But some things in RPM Fusion still 
need to get brought in shape before we start considering that. But if 
you want you can already help by using and testing RPM Fusion for F8 and 
F9 by running this command:

> rpm -ivh \
> http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \
> http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

It's even easier now if you already have livna enabled already:

> yum install rpmfusion-free-release rpmfusion-nonfree-release

RPM Fusion's Bugtracker (please report all issues here and not on the
mailing lists!):
http://bugzilla.rpmfusion.org/

Mailing lists for RPM Fusion users (includes users of the devel branch)
http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users

Please spread the news! tia!

CU
knurd

P.S.: Just a reminder while at it: Some of you might have noticed 
already, the livna mailing lists (like freeworld{,-graphics}@livna.org) 
are dead since a few weeks;  the hard disk in Anvil's mailman host died 
afaik (I don't know more details; sorry). But Livna will be superseded 
by RPM Fusion soon anyway, so simply use the those lists from rpmfusion 
from now on. They should serve well for the remaining time, as all the 
livna contributors should  be subscribed there as well. Sorry for the 
trouble.

P.P.S.: Sorry for crossposting this to five lists, but it seemed the 
right thing to do for this announcement...



From nicolas.mailhot at laposte.net  Sat Oct 25 16:23:16 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Oct 2008 18:23:16 +0200
Subject: Second steps of the transition from Livna to RPM Fusion
 begins: Enabling RPM Fusion for users of livna-testing!
In-Reply-To: <4903358C.6010609@leemhuis.info>
References: <4903358C.6010609@leemhuis.info>
Message-ID: <1224951796.31574.12.camel@arekh.okg>

Le samedi 25 octobre 2008 ? 17:04 +0200, Thorsten Leemhuis a ?crit :
> Hi!
> 
> Find below a cut'n'pasted and slightly enhanced version of a post from
> my blog FYI:

> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ),
> the merger of Dribble, Freshrpms and Livna gets closer to its official
> release/start. 

BTW,

If rpmfusion can not use the modern proxy-friendly createro it should
really define http_caching=packages in its yum repo files.

-- 
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/20081025/72d02102/attachment.sig>

From fedora at leemhuis.info  Sat Oct 25 16:47:59 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 25 Oct 2008 18:47:59 +0200
Subject: Second steps of the transition from Livna to RPM Fusion begins:
 Enabling RPM Fusion for users of livna-testing!
In-Reply-To: <1224951796.31574.12.camel@arekh.okg>
References: <4903358C.6010609@leemhuis.info>
	<1224951796.31574.12.camel@arekh.okg>
Message-ID: <49034DBF.5020109@leemhuis.info>

On 25.10.2008 18:23, Nicolas Mailhot wrote:
> Le samedi 25 octobre 2008 ? 17:04 +0200, Thorsten Leemhuis a ?crit :
>> Find below a cut'n'pasted and slightly enhanced version of a post from
>> my blog FYI:
>> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ),
>> the merger of Dribble, Freshrpms and Livna gets closer to its official
>> release/start. 
> 
> BTW,
> If rpmfusion can not use the modern proxy-friendly createro it should
> really define http_caching=packages in its yum repo files.

Updating createrepo seems like the way better plan to me instead of that 
workaround. Could you be so kind and tell me which createrepo version we 
need a least to get a "proxy-friendly createro"? Or is the answer "just 
use the latest and greatest" (host is a rhel5 or centos5)?

Cu
knurd



From nicolas.mailhot at laposte.net  Sat Oct 25 17:16:27 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Oct 2008 19:16:27 +0200
Subject: Second steps of the transition from Livna to RPM Fusion
 begins: Enabling RPM Fusion for users of livna-testing!
In-Reply-To: <49034DBF.5020109@leemhuis.info>
References: <4903358C.6010609@leemhuis.info>
	<1224951796.31574.12.camel@arekh.okg> <49034DBF.5020109@leemhuis.info>
Message-ID: <1224954987.32197.3.camel@arekh.okg>

Le samedi 25 octobre 2008 ? 18:47 +0200, Thorsten Leemhuis a ?crit :
> On 25.10.2008 18:23, Nicolas Mailhot wrote:
> > Le samedi 25 octobre 2008 ? 17:04 +0200, Thorsten Leemhuis a ?crit :
> >> Find below a cut'n'pasted and slightly enhanced version of a post from
> >> my blog FYI:
> >> As you'll likely have heard by now: RPM Fusion ( http://rpmfusion.org ),
> >> the merger of Dribble, Freshrpms and Livna gets closer to its official
> >> release/start. 
> > 
> > BTW,
> > If rpmfusion can not use the modern proxy-friendly createro it should
> > really define http_caching=packages in its yum repo files.
> 
> Updating createrepo seems like the way better plan to me instead of that 
> workaround. Could you be so kind and tell me which createrepo version we 
> need a least to get a "proxy-friendly createro"? Or is the answer "just 
> use the latest and greatest" (host is a rhel5 or centos5)?

All I can say is that the one used for the rawhide repository works. I
think it's run on a rhel5 host too.

A working version will have long hashes in the repodata filenames.

-- 
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/20081025/1590a970/attachment.sig>

From Matt_Domsch at dell.com  Sat Oct 25 18:53:39 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sat, 25 Oct 2008 13:53:39 -0500
Subject: what QA gets mailed to the packagers?
In-Reply-To: <20081025110430.GC2608@free.fr>
References: <20081025110430.GC2608@free.fr>
Message-ID: <20081025185339.GA12243@auslistsprd01.us.dell.com>

On Sat, Oct 25, 2008 at 01:04:30PM +0200, Patrice Dumas wrote:
> Hello,
> 
> Still trying to bring the wiki up-to-date, I'd like to fix
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
> 
> Some points are likely to be out of date, but I don't know exactly what
> is done now, regarding:
> 
> * nagmails sent for EVR
> * nagmails sent for dependency issues
> 
> Are those still generated? Is there other similar automatic QA added
> since pre-merge time?

fails to build from source (not exactly automatic, but similar).

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



From mrsam at courier-mta.com  Sat Oct 25 19:49:12 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sat, 25 Oct 2008 15:49:12 -0400
Subject: Additional syscalls support in valgrind
Message-ID: <cone.1224964152.979703.5133.500@commodore.email-scan.com>

The current valgrind rpm includes patches that add various newer syscall 
support to valgrind.

Is this the case where they've been sent upstream, but not rolled yet rolled 
into the main release, or is there a reason why they have not been submitted 
upstream.

I've hacked up valgrind to grok two more syscalls, so I'm wondering what to 
do with my patches.


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

From mschwendt at gmail.com  Sat Oct 25 20:32:15 2008
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 25 Oct 2008 22:32:15 +0200
Subject: Bodhi and commit ACLs
In-Reply-To: <20081023225614.GH12437@x300>
References: <f90695ee0810231518t9616f8fu6a9add0bd5beba50@mail.gmail.com>
	<20081023225614.GH12437@x300>
Message-ID: <20081025223215.aa86895b.mschwendt@gmail.com>

On Thu, 23 Oct 2008 18:56:15 -0400, Luke Macken wrote:

> On Thu, Oct 23, 2008 at 06:18:57PM -0400, Alan Dunn wrote:
> > I am under the impression that if I have commit access for a package I
> > should be able to submit updates for it through Bodhi. I was recently
> > given commit access for ocaml-lablgtk so I could fix a bug in the F-9
> > package, but it seems that I can't actually submit an update for it.
> > Am I wrong about how this works, or is something broken? (Or did
> > something change recently?)
> 
> At the moment bodhi allows anyone with commit access to the devel branch
> to submit updates.  Yes, this is not ideal, but will require some
> significant refactoring to do this verification properly.
> 
> If you go ahead and apply for commit access to the devel branch, you
> should be all set.
> 
>     https://admin.fedoraproject.org/pkgdb/packages/name/ocaml-lablgtk 

Pardon? When was it changed to be like this? And who was involved
in that decision?

Previously, the maintainers of multiple dependent packages could work
together on a group update (i.e. build their packages) and then let a
single maintainer submit the group of builds in bodhi. Do I understand
you correctly, that this is no longer possible unless this maintainer has
commit access to the devel branch of each relevant pkg?

Doesn't this restriction also imply that it's now impossible
to publish an emergency fix for a stable branch in a cases where 
somebody from the "uberpackager" ACL group prepares the update?
Or is bodhi aware of that group?



From alexl at users.sourceforge.net  Sat Oct 25 23:11:15 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 25 Oct 2008 16:11:15 -0700
Subject: libgdl soname breakage?
In-Reply-To: <9497e9990810250631k54754490g58f6fc444d1a983@mail.gmail.com> (Mat
	Booth's message of "Sat\, 25 Oct 2008 14\:31\:11 +0100")
References: <20081025105649.CE8651B8001@releng2.fedora.phx.redhat.com>
	<dtej24aoeo.fsf@allele2.eebweb.arizona.edu>
	<9497e9990810250631k54754490g58f6fc444d1a983@mail.gmail.com>
Message-ID: <g27i7w9soc.fsf@allele2.eebweb.arizona.edu>

>>>>> "MB" == Mat Booth  writes:

[...]


>> Removing libgdl-gnome-1.so seems to be a rather drastic step,
>> especially if these apps need it and it isn't provided by any other
>> package.  Is this just a packaging error?  I note that Debarshi Ray
>> who rebuilt libgdl is also the maintainer of 2 of the 3 broken
>> packages: anjuta and gnome-build, so I assume that he'll hopefully
>> have plan to fix this breakage. ;)
>> 
>> Otherwise this change should probably be reverted.
>> 
>> Again, please announce any ABI changes on f-d-l in advance.

>> Alex


MB> Yeah, Debarshi says he'll take care of Anjuta and gnome-build.

MB> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02330.html

I read f-d-l via gmane and somehow the feed was lagging so I didn't
see this message from Debarshi.  Apologies.

Nevetheless it appears that more than gnome-build and anjuta are
affected, so is gnome-python2.

Alex



From alexl at users.sourceforge.net  Sat Oct 25 23:15:15 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 25 Oct 2008 16:15:15 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	(Debarshi Ray's message of "Fri\, 24 Oct 2008 21\:42\:58 +0530")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
Message-ID: <723aik9sho.fsf@allele2.eebweb.arizona.edu>

>>>>> Debarshi Ray  writes:

> Upstream has dropped the separate libgdl-gnome-1.so from gdl-2.24.0.
> This will affect Fedora once libgdl-2.24.0 hits Rawhide. As far as I
> know its dependencies are gnome-build and anjuta, which I will take
> care of.

> Happy hacking, Debarshi

Hi Debarshi,

Thanks.  Unfortunately it appears that this affects gnome-python2 as well:

>  Broken deps for i386
>  ----------------------------------------------------------
> 	gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0

Can this be fixed as well?  Also, you might consider chain-build in
rawhide to rebuild a series of packages against each other so that the
rawhide push passes repoclosure and doesn't have any broken deps, even
transiently.  Otherwise you could also ask rel-eng for a buildroot
override.

Alex



From alexl at users.sourceforge.net  Sat Oct 25 23:50:24 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 25 Oct 2008 16:50:24 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <723aik9sho.fsf@allele2.eebweb.arizona.edu> (Alex Lancaster's
	message of "Sat\, 25 Oct 2008 16\:15\:15 -0700")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
Message-ID: <jhvdvg8can.fsf@allele2.eebweb.arizona.edu>

>>>>> "AL" == Alex Lancaster  writes:

>>>>> Debarshi Ray  writes:
>> Upstream has dropped the separate libgdl-gnome-1.so from
>> gdl-2.24.0.  This will affect Fedora once libgdl-2.24.0 hits
>> Rawhide. As far as I know its dependencies are gnome-build and
>> anjuta, which I will take care of.

>> Happy hacking, Debarshi

AL> Hi Debarshi,

AL> Thanks.  Unfortunately it appears that this affects gnome-python2
AL> as well:

Actually gnome-python2-gdl is part of gnome-python2-extras.

>> Broken deps for i386
>> ----------------------------------------------------------
>> gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0

Alex



From kevin.kofler at chello.at  Sat Oct 25 23:51:50 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 25 Oct 2008 23:51:50 +0000 (UTC)
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
Message-ID: <loom.20081025T234848-356@post.gmane.org>

Alex Lancaster <alexl <at> users.sourceforge.net> writes:
> Can this be fixed as well?  Also, you might consider chain-build in
> rawhide to rebuild a series of packages against each other so that the
> rawhide push passes repoclosure and doesn't have any broken deps, even
> transiently.  Otherwise you could also ask rel-eng for a buildroot
> override.

Buildroot overrides are not useful for Rawhide. They're what is used to build 
chains of dependent packages in releases. (You can't just chain-build them 
because updates-candidate doesn't populate the buildroots.)

Basically, chain-building works if and only if sequential building (with enough 
waiting for the buildroot's "newRepo" task to complete) works without needing 
manual tagging. So you can chain-build in Rawhide, you have to request manual 
tagging and wait for rel-eng to act on it and then for the automatic newRepo to 
happen in releases.

        Kevin Kofler



From alexl at users.sourceforge.net  Sat Oct 25 23:59:57 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 25 Oct 2008 16:59:57 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <jhvdvg8can.fsf@allele2.eebweb.arizona.edu> (Alex Lancaster's
	message of "Sat\, 25 Oct 2008 16\:50\:24 -0700")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<jhvdvg8can.fsf@allele2.eebweb.arizona.edu>
Message-ID: <v5r6648buq.fsf@allele2.eebweb.arizona.edu>

>>>>> "AL" == Alex Lancaster  writes:

>>>>> "AL" == Alex Lancaster  writes:
>>>>> Debarshi Ray  writes:
>>> Upstream has dropped the separate libgdl-gnome-1.so from
>>> gdl-2.24.0.  This will affect Fedora once libgdl-2.24.0 hits
>>> Rawhide. As far as I know its dependencies are gnome-build and
>>> anjuta, which I will take care of.

>>> Happy hacking, Debarshi

AL> Hi Debarshi,

AL> Thanks.  Unfortunately it appears that this affects gnome-python2
AL> as well:

AL> Actually gnome-python2-gdl is part of gnome-python2-extras.

>>> Broken deps for i386
>>> ----------------------------------------------------------
>>> gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0

And sure enough gnome-python2-extras fails to rebuild after this
change because it can't find certain gdl files:

http://koji.fedoraproject.org/koji/taskinfo?taskID=903364

Please look into this fixing this ASAP.  Is there a new
gnome-python2-extras that fixes this?

Alex



From alexl at users.sourceforge.net  Sun Oct 26 00:01:38 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 25 Oct 2008 17:01:38 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <loom.20081025T234848-356@post.gmane.org> (Kevin Kofler's message
	of "Sat\, 25 Oct 2008 23\:51\:50 +0000 \(UTC\)")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<loom.20081025T234848-356@post.gmane.org>
Message-ID: <yemygs8brx.fsf@allele2.eebweb.arizona.edu>

>>>>> "KK" == Kevin Kofler  writes:

KK> Alex Lancaster <alexl <at> users.sourceforge.net> writes:
>> Can this be fixed as well?  Also, you might consider chain-build in
>> rawhide to rebuild a series of packages against each other so that
>> the rawhide push passes repoclosure and doesn't have any broken
>> deps, even transiently.  Otherwise you could also ask rel-eng for a
>> buildroot override.

KK> Buildroot overrides are not useful for Rawhide. They're what is
KK> used to build chains of dependent packages in releases. (You can't
KK> just chain-build them because updates-candidate doesn't populate
KK> the buildroots.)

KK> Basically, chain-building works if and only if sequential building
KK> (with enough waiting for the buildroot's "newRepo" task to
KK> complete) works without needing manual tagging. So you can
KK> chain-build in Rawhide, you have to request manual tagging and
KK> wait for rel-eng to act on it and then for the automatic newRepo
KK> to happen in releases.

OK, I guess that was what I was suggesting was a manual tagging (would
that be dist-f10-build?) rather than a "build root override" per se.
As for chain-build, thanks for the clarification, you would need to
already have a new gdl tagged for dist-f10-build before the new builds
would use that?

Alex



From kevin.kofler at chello.at  Sun Oct 26 03:08:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 26 Oct 2008 03:08:46 +0000 (UTC)
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<jhvdvg8can.fsf@allele2.eebweb.arizona.edu>
	<v5r6648buq.fsf@allele2.eebweb.arizona.edu>
Message-ID: <loom.20081026T030808-722@post.gmane.org>

Alex Lancaster <alexl <at> users.sourceforge.net> writes:
> And sure enough gnome-python2-extras fails to rebuild after this
> change because it can't find certain gdl files:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=903364
> 
> Please look into this fixing this ASAP.  Is there a new
> gnome-python2-extras that fixes this?

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

Patch:
http://bugzilla.gnome.org/attachment.cgi?id=119997&action=view

        Kevin Kofler



From rawhide at fedoraproject.org  Sun Oct 26 11:48:57 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 26 Oct 2008 11:48:57 +0000 (UTC)
Subject: rawhide report: 20081026 changes
Message-ID: <20081026114857.65B021B8001@releng2.fedora.phx.redhat.com>

Compose started at Sun Oct 26 06:01:25 UTC 2008

New package gupnp-tools
        GUPnP-tools is a collection of dev tools utilising GUPnP and GTK+
Updated Packages:

alienarena-7.20-2.fc10
----------------------
* Sat Oct 25 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 7.20-2 
- drop old "don't search data path" patch
- call alienarena-wrapper in .desktop file


ardour-2.6-3.fc10
-----------------
* Sat Oct 25 18:00:00 2008 Anthony Green <green at redhat.com> 2.6-3
- BuildRequire libcurl-devel.

* Sat Oct 25 18:00:00 2008 Anthony Green <green at redhat.com> 2.6-2
- Upgrade gcc43 patch to apply with fuzz = 0.

* Sat Oct 25 18:00:00 2008 Anthony Green <green at redhat.com> 2.6-1
- New upstream release 2.6.
- Update SConstruct patch.


audit-1.7.8-4.fc10
------------------
* Sat Oct 25 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.8-4
- If kernel is in immutable mode, auditd should not send enable command

* Fri Oct 24 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.8-3
- Fix ausearch interpretting i386 syscalls on x86_64 machine


cairo-dock-1.6.3-0.2.svn1363_trunk.fc10
---------------------------------------
* Sun Oct 26 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1363


erlang-R12B-4.3.fc10
--------------------
* Sat Oct 25 18:00:00 2008 Gerard Milmeister <gemi at bluewin.ch> - R12B-4.1
- new release R12B-4


evince-2.24.1-3.fc10
--------------------
* Sat Oct 25 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 2.24.1-2
- Drop dependency on desktop-file-utils (#463048).

* Sat Oct 25 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-3
- Require dbus-glib-devel, not just dbus-devel (#465281, Dan Winship)


fedora-logos-10.0.0-2.fc10
--------------------------
* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 10.0.0-2
- Add (current version of) Fedora logo for SolarComet KSplash theme


generic-logos-10.0.0-2.fc10
---------------------------
* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 10.0.0-2
- Add (current version of) KDE logo for SolarComet KSplash theme


hspell-1.0-11.fc10
------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.0-11
- Fix Patch0:/%patch mismatch.

* Thu Jul 31 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0-10
- fix license tag

* Wed May 14 18:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 1.0-9
- Resolves: rhbz#313231 build hspell.so instead of a .a


java-1.6.0-openjdk-1.6.0.0-1.1.b12.fc10
---------------------------------------
* Fri Oct 24 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.1.b12
- Updated sources to include latest liveconnect fixes.

* Fri Oct 24 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.1.b12
- Removed --enable-pulse-java. Causes some TCK tests to fail.


jd-2.0.3-0.1.svn2416_trunk.fc10
-------------------------------
* Sun Oct 26 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2416


kde-settings-4.1-1.fc10
-----------------------
* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1-1
- default to Solar artwork


kdepim-4.1.2-4.fc10
-------------------
* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-4
- add missing BR soprano-devel


kernel-2.6.27.4-47.rc3.fc10
---------------------------
* Fri Oct 24 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-47.rc3
- Fix LBA48 on pata_it821x RAID volumes.

* Fri Oct 24 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-46.rc3
- Fix I/O errors on jmicron USB/ATA bridges (#465539)

* Fri Oct 24 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-45.rc3
- 2.6.27.4-rc3
  Dropped patches:
    linux-2.6-x86-acpi-fix-resume-on-64-bit-UP-systems.patch
  Upstream reverts:
    ext-avoid-printk-floods-in-the-face-of-directory-corruption.patch


kid3-1.1-1.fc10
---------------
* Sat Oct 25 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.1-1
- 1.1.


libmtp-0.3.3-4.fc10
-------------------
* Sat Oct 25 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.3-4
- Update device list from CVS and fix the build

* Sat Oct 25 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.3-3
- Add support for more Nokia phones from their WMP10 drivers


libsndfile-1.0.17-6.fc10
------------------------
* Sat Oct 25 18:00:00 2008 Andreas Thienemann <andreas at bawue.net> - 1.0.17-6
- Removed spurious #endif in the libsndfile.h wrapper. Thx to Edward
  Sheldrake for finding it. Fixes #468508.
- Fix build for autoconf-2.63

* Thu Oct 23 18:00:00 2008 Andreas Thienemann <andreas at bawue.net> - 1.0.17-5
- Fixed multilib conflict. #342401
- Made flac support actually work correctly.


mksh-36-1.fc10
--------------
* Sat Oct 25 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 36-1
- Upgrade to 36


mono-2.0.1-12.fc10
------------------
* Fri Oct 24 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0.12
- Update to 2.0.1
- remove selinux patch
- remove s390 disable

* Tue Oct 21 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.0-11.2
- fixed no ownership of etc-mono-mconfig directory


ncdu-1.4-1.fc10
---------------
* Sat Oct 25 18:00:00 2008 Richard Fearn <richardfearn at gmail.com> - 1.4-1
- new upstream version


obex-data-server-0.4.1-1.fc10
-----------------------------
* Sun Oct 26 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.4.1-1
- Update to 0.4.1


perl-DBD-Mock-1.37-1.fc10
-------------------------
* Sat Oct 25 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.37-1
- update to 1.37


perl-DateTime-Format-DBI-0.032-1.fc10
-------------------------------------
* Sat Oct 25 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.032-1
- update to 0.032
- drop more_dbds.patch -- incorperated upstream


rcssbase-12.1.2-1.fc10
----------------------
* Sat Oct 25 18:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 12.1.2-1
- Updated to the latest release version


rcsslogplayer-12.1.2-1.fc10
---------------------------
* Sun Oct 26 18:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 12.1.2-1
- Updated to the latest released package


rcssserver-12.1.4-1.fc10
------------------------
* Sun Oct 26 18:00:00 2008 Hedayat Vatankhah <hedayat at grad.com> 12.1.4-1
- Updated to the latest version.


selinux-policy-3.5.13-8.fc10
----------------------------
* Fri Oct 24 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-8
- Allow mozilla to run with unconfined_execmem_t


solar-kde-theme-0.1.8-2.fc10
----------------------------
* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.8-2
- fix wallpaper symlinks in the KSplash theme

* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.8-1
- use latest version of Solar wallpapers, includes 5:4 (1600x1280) image

* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.7-1
- fix coordinates of KSplash animations not to segfault on small resolutions

* Sun Oct 26 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.6-1
- symlink all copies of wallpapers instead of hardlinking
- put wallpapers in directories with their actual resolution for KSplash
  (fixes ksplashx segfault)
- remove Fedora logo, add Requires: system-logos instead
- use bz2 instead of gz for the tarball


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 28
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
	gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.i386 requires libgnome-desktop-2.so.2
	ume-launcher-0.6.3-1.fc9.i386 requires libclutter-glx-0.6.so.0



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-python2-gdl-2.19.1-20.fc10.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.x86_64 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	ume-launcher-0.6.3-1.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit)



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.ppc requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-python2-gdl-2.19.1-20.fc10.ppc requires libgdl-gnome-1.so.0
	iml-devel-1.0.2-3.fc10.ppc requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.ppc requires libgnome-desktop-2.so.2
	ume-launcher-0.6.3-1.fc9.ppc requires libclutter-glx-0.6.so.0



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	ume-launcher-0.6.3-1.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit)





From vonbrand at inf.utfsm.cl  Sun Oct 26 15:16:36 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 26 Oct 2008 12:16:36 -0300
Subject: FESCo Meeting Summary for 2008-10-22
In-Reply-To: <1224829950.6682.9.camel@beck.corsepiu.local>
References: <1224791613.4174.4.camel@kennedy> <49015904.6080803@leemhuis.info>
	<1224828294.26966.221.camel@perihelion.int.jonmasters.org>
	<1224829950.6682.9.camel@beck.corsepiu.local>
Message-ID: <200810261516.m9QFGawt005271@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Fri, 2008-10-24 at 02:04 -0400, Jon Masters wrote:
> > On Fri, 2008-10-24 at 07:11 +0200, Thorsten Leemhuis wrote:
> > > On 23.10.2008 21:53, Brian Pepple wrote:
> > > > === Features ===
> > > > * FESCo rejected a proposal to revert the Sbin Sanity(1) feature.
> > > >       * For: kick_
> > > >       * Against: dwmw2, j-rod, bpepple, notting, dgilmore, nirik
> > > >       * Abstain: jwb
> > > >      1. https://fedoraproject.org/wiki/Features/SbinSanity
> > > 
> > > I think FESCo is doing a big mistake here.
> +1
> 
> > > So FWIW, I totally agree with what Ville said in
> > > https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html
> > 
> > If you're writing scripts and not explicitly calling out the binary
> > location, then it's not surprising if your scripts break later. I know
> > it's nice to always assume a particular PATH, but it's not good practice
> > any more than including or not including sbin in the PATH to begin with.
> > And people using tab-completion can get used to the new binary names.
> > 
> > FWIW, I think including sbin in the path is only about *10 years too
> > late*, everyone else is already laughing that Fedora didn't do this, so
> > really it doesn't need to wait for yet another 1.5 years to get done :)

> I disagree. Fedora not having gone this naive road is one detail why
> users are using Fedora.

Heartily agree. I've been using Unixy systems since 1984 or so, and /never/
found a valid reason for {,/usr}/sbin in PATH for "normal users".
-- 
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 2340000       Fax:  +56 32 2797513



From hughsient at gmail.com  Sun Oct 26 16:45:44 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 26 Oct 2008 16:45:44 +0000
Subject: splitting gnome-packagekit
Message-ID: <1225039544.3472.14.camel@hughsie-laptop>

Another packaging question, apologies.

In https://bugzilla.redhat.com/show_bug.cgi?id=468250, it was suggested
that we split of the admin tools from the base package. At the moment
there is the log viewer and the service pack creator, which are very
much admin tools. They'll also soon be an advanced update viewer, which
lets you select packages based on CVE's and more advanced criteria.

These programs are probably not for the average user, and so it was
suggested we split these files off as either:

gnome-packagekit-admin
gnome-packagekit-tools
gnome-packagekit-extra

Is there any guidelines for this? The first seems the most logical to
me. Advice welcomed. Thanks.

Richard.




From tim.lauridsen at googlemail.com  Sun Oct 26 17:25:17 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Sun, 26 Oct 2008 18:25:17 +0100
Subject: splitting gnome-packagekit
In-Reply-To: <1225039544.3472.14.camel@hughsie-laptop>
References: <1225039544.3472.14.camel@hughsie-laptop>
Message-ID: <4904A7FD.8020102@googlemail.com>

Richard Hughes wrote:
> Another packaging question, apologies.
>
> In https://bugzilla.redhat.com/show_bug.cgi?id=468250, it was suggested
> that we split of the admin tools from the base package. At the moment
> there is the log viewer and the service pack creator, which are very
> much admin tools. They'll also soon be an advanced update viewer, which
> lets you select packages based on CVE's and more advanced criteria.
>
> These programs are probably not for the average user, and so it was
> suggested we split these files off as either:
>
> gnome-packagekit-admin
> gnome-packagekit-tools
> gnome-packagekit-extra
>
> Is there any guidelines for this? The first seems the most logical to
> me. Advice welcomed. Thanks.
>
> Richard.
>
>
>   
gnome-packagekit-extra is the best IMO.
because it is extra tools,  gnome-packagekit-admin sounds like something 
to admin packagekit, and an advanced update viewer, dont sound like
an admin tool i my book.

Tim



From camilo at mesias.co.uk  Sun Oct 26 18:05:03 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Sun, 26 Oct 2008 19:05:03 +0100
Subject: preupgrade F9 -> rawhide?
Message-ID: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>

Is preupgrade from F9 to rawhide supposed to work at the moment, and
where can I report problems?

I've tried to run it and got a few depsolving problems for packages
from livna... but when it gets to the boot images stage there are
problems:

Traceback (most recent call last):
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 198, in
on_assistant_apply
    self._do_main()
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 206, in _do_main
    self.main_preupgrade()
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 349, in main_preupgrade
    self.pu.retrieve_treeinfo()
  File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line
395, in retrieve_treeinfo
    self.instimage = cp.get('stage2', 'instimage')
  File "/usr/lib/python2.5/ConfigParser.py", line 520, in get
    raise NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'instimage' in section: 'stage2'

Any ideas?

-Cam



From nicolas.mailhot at laposte.net  Sun Oct 26 19:47:03 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 26 Oct 2008 20:47:03 +0100
Subject: [LONG] The fonts SIG irregular status report
Message-ID: <1225050423.4173.7.camel@arekh.okg>

Hi all,

I haven't been too active on the SIG lately for lack of free time.
However others (who rock) have been busy working on fonts packages, so
here is a long delayed status update that will try to clear the backlog:


?? General status

? We have 56 entries in the wishlist. Even counting entries the packager
forgot to recategorize (grrr) I think the wishlist is still growing
faster than we package fonts. More active packagers are obviously
needed.
http://fedoraproject.org/wiki/Category:Font_wishlist

? We have 58 entries in the packaged list.
http://fedoraproject.org/wiki/Category:Packaged_fonts
It is still nicely growing, and Fedora 9 level reviews like this one are
already obsolete
http://www.advogato.org/person/yosch/diary.html?start=4

? We've created 55 new packages since the start of the cycle (a wishlist
entry can translate in several packages). That's pretty awesome and way
past the 32 packages mark of the last report (and way past previous
Fedora cycle accomplishments). Special kuddos to Dennis Jang for
packaging the huge UN Korean font set (though he needs to update his
wiki pages). Others didn't attain the level of awesomeness of Dennis but
still did pretty well.
http://fedoraproject.org/wiki/Fonts_inclusion_history


?? Package status

??? Packaged, with bugs still open:
? sportrop-fonts,
https://bugzilla.redhat.com/show_bug.cgi?id=456345  
? asana-math-fonts,
https://bugzilla.redhat.com/show_bug.cgi?id=455153
? icelandic-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=445261

? Packagers please close your review bugs when the packaging is
finished.


??? Packaged, but not referenced in Fedora 10 comps
? myanmar3-unicode-fonts

That was short :) most packagers seem to apply
http://fedoraproject.org/wiki/Comps_fonts_rules
without prodding on my part. Good job and please fix this one.


??? Packaged, with wiki page not finalized or missing

? thibault-fonts-essays1743,
? thibault-fonts-isabella,
? thibault-fonts-rockets,
? thibault-fonts-staypuft,
? un-fonts,
? un-extra-fonts,
? icelandic-fonts
? smc-fonts
? darkgarden-fonts
? sportrop-fonts
? myanmar3-unicode-fonts

? Please make sure each font package has a completed wiki page (Packaged
fonts category) that can be used by the docs team in release notes and
other documents


??? Reviewed fonts waiting for packager action
? bitstream-vera-fonts (old FE-MERGE ticket, needs someone to help
Behdad co-maintain the package)
https://bugzilla.redhat.com/show_bug.cgi?id=225618
? sil-gentium-basic-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=456527
? hiran-perizia-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=457709
? cf-bonveno-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=457955
? arabeyes-thabit-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=461139
? arabeyes-mothana-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=462711
? alee-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=466193
? hiran-rufscript-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=467507

? You know what you need to do


??? Approved fonts not pushed yet
? unikurd-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=457281


??? Waiting for a reviewer
? heuristica-fonts (just cleared by FE-LEGAL)
  https://bugzilla.redhat.com/show_bug.cgi?id=452317
? oldstandard-fonts
  https://bugzilla.redhat.com/show_bug.cgi?id=457947
  (not an easy font to package and not baked yet IMHO. I put some
comments in the bug but didn't start formal review, so this one is still
open)

? We need some reviewers. I can't review every single font package out
there (especially since I'm not allowed to review my own).

In other news more interesting material was added to the SIG wiki and a
guideline change on fontconfig file location is still proceeding. And
the big F11 package renaming is still planned, I just don't have the
energy left to write about it.

I hope you liked this report. It took a lot of work to be written. If
you want some changes in the next edition, just ping me.

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/20081026/ccc217a7/attachment.sig>

From konrad at tylerc.org  Sun Oct 26 19:45:18 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Sun, 26 Oct 2008 12:45:18 -0700
Subject: FESCo Meeting Summary for 2008-10-22
In-Reply-To: <200810261516.m9QFGawt005271@laptop14.inf.utfsm.cl>
References: <1224791613.4174.4.camel@kennedy>
	<1224829950.6682.9.camel@beck.corsepiu.local>
	<200810261516.m9QFGawt005271@laptop14.inf.utfsm.cl>
Message-ID: <200810261245.19023.konrad@tylerc.org>

On Sunday 26 October 2008 08:16:36 am Horst H. von Brand wrote:
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> > I disagree. Fedora not having gone this naive road is one detail why
> > users are using Fedora.
>
> Heartily agree. I've been using Unixy systems since 1984 or so, and /never/
> found a valid reason for {,/usr}/sbin in PATH for "normal users".

Did "normal users" have personal computers in 1984? Nowadays a lot of people 
own and admin their own computer. Many commands that exist in {,/usr}/sbin 
are useful even to non-root users on a shared system, such as ifconfig.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From nicolas.mailhot at laposte.net  Sun Oct 26 21:19:44 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 26 Oct 2008 22:19:44 +0100
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <1225050423.4173.7.camel@arekh.okg>
References: <1225050423.4173.7.camel@arekh.okg>
Message-ID: <1225055984.5093.1.camel@arekh.okg>

Le dimanche 26 octobre 2008 ? 20:47 +0100, Nicolas Mailhot a ?crit :

> ? We have 56 entries in the wishlist.

Actually we have 57 since Behdad requested FersiWeb fonts and no one has
worked on it so far
http://fedoraproject.org/wiki/Farsiweb_fonts

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/20081026/a0b5eb68/attachment.sig>

From bojan at rexursive.com  Sun Oct 26 23:59:09 2008
From: bojan at rexursive.com (Bojan Smojver)
Date: Mon, 27 Oct 2008 10:59:09 +1100
Subject: ViewVC has been split into viewvc/viewvc-httpd
Message-ID: <1225065549.2783.9.camel@shrek.rexursive.com>

Just a heads up that as of today, ViewVC has been split into viewvc
(which depends on webserver) and viewvc-httpd (which depends on
mod_python), in order to address bug #457691.

So, if you are running viewvc under Apache/mod_python on F8/F9, you'll
have to install viewvc-httpd package in F10 to get the same thing.

-- 
Bojan



From wwoods at redhat.com  Mon Oct 27 05:08:15 2008
From: wwoods at redhat.com (Will Woods)
Date: Mon, 27 Oct 2008 01:08:15 -0400
Subject: preupgrade F9 -> rawhide?
In-Reply-To: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
References: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
Message-ID: <1225084095.3077.24.camel@zebes.localdomain>

On Sun, 2008-10-26 at 19:05 +0100, Camilo Mesias wrote:
> Is preupgrade from F9 to rawhide supposed to work at the moment, and
> where can I report problems?
> 
> I've tried to run it and got a few depsolving problems for packages
> from livna... but when it gets to the boot images stage there are
> problems:

You're using an old version of preupgrade. Use 0.9.8 from
updates-testing.

-w



From noriko at redhat.com  Mon Oct 27 06:09:25 2008
From: noriko at redhat.com (Noriko Mizumoto)
Date: Mon, 27 Oct 2008 16:09:25 +1000
Subject: Virt* , s-c-display ,desktop-effects - Translation submission
 issues!
In-Reply-To: <48FEF504.8030606@redhat.com>
References: <48FEF504.8030606@redhat.com>
Message-ID: <49055B15.1070507@redhat.com>

Hi

It is one day to go for Final Development freeze, 28-Oct.
Could you please please check the following bugs and include all 
translation submitted against?

It is highly appreciated if the comment is added in the bug when done.

> [desktop-effect]
> https://bugzilla.redhat.com/show_bug.cgi?id=438033
No response, 3 languages translation attached as of 27-Oct, 04:00 UTC time.

> 
> [system-config-display]
> https://bugzilla.redhat.com/show_bug.cgi?id=438122
This has been included, thank you very much!!

> 
> [virt-ctrl]
> https://bugzilla.redhat.com/show_bug.cgi?id=467817
No response, 9 languages translation attached as of 27-Oct, 04:00 UTC time.

> 
> [virt-manager]
> https://bugzilla.redhat.com/show_bug.cgi?id=467808
Hi Cole,
12 languages translation attached as of 27-Oct, 04:00 UTC time.
There are some languages attached after Translation Deadline of 21-Oct.
Is any chance that those can be included?

> 
> [virt-df]
> https://bugzilla.redhat.com/show_bug.cgi?id=467809
This has been included, thank you very much!!
After the built, Polish translation came in and attached on 24-Oct. If 
by any chance for rebuild, could you please pick this one too?

> 
> [virt-inst]
> https://bugzilla.redhat.com/show_bug.cgi?id=467810
Hi Cole,
2 languages translation attached as of 27-Oct, 04:00 UTC time.
Could you confirm if those have been included?

> 
> [virt-mem]
> https://bugzilla.redhat.com/show_bug.cgi?id=467811
This has been included, thank you very much!!
After the built, Polish and Italian translation came in and attached. If 
by any chance for rebuild, could you please pick these too?

> 
> [virt-p2v]
> https://bugzilla.redhat.com/show_bug.cgi?id=467818
No response, 2 languages translation attached as of 27-Oct, 04:00 UTC time.

> 
> [virt-top]
> https://bugzilla.redhat.com/show_bug.cgi?id=467816
This 'virt-top' package translation is identical with the one of 
'virt-ctrl'. Thus most of translation files can be found at #467817.
Please instruct us if any other place to submit.

Thanks!

noriko

> 
> 
> Thanks in advance!
> 



From alexl at users.sourceforge.net  Mon Oct 27 06:44:07 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sun, 26 Oct 2008 23:44:07 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <723aik9sho.fsf@allele2.eebweb.arizona.edu> (Alex Lancaster's
	message of "Sat\, 25 Oct 2008 16\:15\:15 -0700")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
Message-ID: <sabcq7d1k.fsf@allele2.eebweb.arizona.edu>

>>>>> "AL" == Alex Lancaster  writes:

>>>>> Debarshi Ray  writes:
>> Upstream has dropped the separate libgdl-gnome-1.so from
>> gdl-2.24.0.  This will affect Fedora once libgdl-2.24.0 hits
>> Rawhide. As far as I know its dependencies are gnome-build and
>> anjuta, which I will take care of.


[...]

Debarshi,

gnome-build, anjuta are still broken in rawhide as of 20081016 and I
don't see any new builds in koji.  The development freeze is coming in
one day, can you please fix these builds ASAP as you promised above
before the freeze?

Alex



From camilo at mesias.co.uk  Mon Oct 27 06:48:05 2008
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Mon, 27 Oct 2008 07:48:05 +0100
Subject: preupgrade F9 -> rawhide?
In-Reply-To: <1225084095.3077.24.camel@zebes.localdomain>
References: <d551e0e20810261105u1fce4b2am7ead022a5c2f9c83@mail.gmail.com>
	<1225084095.3077.24.camel@zebes.localdomain>
Message-ID: <d551e0e20810262348m2a94520eh562373b2df491b30@mail.gmail.com>

OK...

yum update --enablerepo=updates-testing-newkey preupgrade

I'll give preupgrade-0.9.8-2.fc9.noarch.rpm a try...

-Cam



From debarshi.ray at gmail.com  Mon Oct 27 06:55:45 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 27 Oct 2008 12:25:45 +0530
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <sabcq7d1k.fsf@allele2.eebweb.arizona.edu>
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<sabcq7d1k.fsf@allele2.eebweb.arizona.edu>
Message-ID: <3170f42f0810262355i2ebc6b41ycde93f071af960d7@mail.gmail.com>

> Debarshi,
>
> gnome-build, anjuta are still broken in rawhide as of 20081016 and I
> don't see any new builds in koji.  The development freeze is coming in
> one day, can you please fix these builds ASAP as you promised above
> before the freeze?

Actually I had to go out of station over the weekend, and the libgdl
build was done just before I left. I am back now, and have the Koji
and Bugzilla links opened in the other browser tabs. Will push the
builds today evening.

Happy hacking,
Debarshi



From nicu_fedora at nicubunu.ro  Mon Oct 27 07:11:01 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 27 Oct 2008 09:11:01 +0200
Subject: Unofficial OpenOffice translations (Was: OpenOffice and go-oo)
In-Reply-To: <200810242018.45718.vpivaini@cs.helsinki.fi>
References: <1223888234.4182.9.camel@ScaryMonster>
	<200810242018.45718.vpivaini@cs.helsinki.fi>
Message-ID: <49056985.7050902@nicubunu.ro>

Ville-Pekka Vainio wrote:
> 
> It seems the unofficial translations are in some cases much more complete than 
> the unofficial translations. This is because the Sun Contributor Agreement 
> process is considered to be too cumbersome and many contributors have not 
> signed the SCA.

Is not necessarily about the SCA, but more about extra features, like 
the build system.

Some months ago, when it was clear that our (Romanian) translation will 
not be ready for 3.0, it was decided to target 3.1, but Sun was not 
accepting translations for 3.1, they were focused on 3.0.
Also Pavel provide localized builds for *each* language every two weeks 
(is not easy to build OOo yourself), so it is a very useful convenience 
for translators who need the builds for QA their progressing work.

-- 
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 alexl at users.sourceforge.net  Mon Oct 27 07:29:44 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Mon, 27 Oct 2008 00:29:44 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <3170f42f0810262355i2ebc6b41ycde93f071af960d7@mail.gmail.com>
	(Debarshi Ray's message of "Mon\, 27 Oct 2008 12\:25\:45 +0530")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<sabcq7d1k.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0810262355i2ebc6b41ycde93f071af960d7@mail.gmail.com>
Message-ID: <am1vy27axj.fsf@allele2.eebweb.arizona.edu>

>>>>> Debarshi Ray  writes:

>> Debarshi,
>> 
>> gnome-build, anjuta are still broken in rawhide as of 20081016 and
>> I don't see any new builds in koji.  The development freeze is
>> coming in one day, can you please fix these builds ASAP as you
>> promised above before the freeze?

> Actually I had to go out of station over the weekend, and the libgdl
> build was done just before I left. I am back now, and have the Koji
> and Bugzilla links opened in the other browser tabs. Will push the
> builds today evening.

Thanks.  While you're at, can you also take a look at
gnome-python2-extras which your bump of the soname of libgdl also
broke?  I am trying to apply the patch for gnome-python2-extras to get
it working with new libgdl that Kevin Kofler pointed out at:

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

but it won't apply, because I think it's against a SVN version.

Alex



From rjones at redhat.com  Mon Oct 27 09:22:00 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 27 Oct 2008 09:22:00 +0000
Subject: Virt* , s-c-display ,desktop-effects - Translation submission
	issues!
In-Reply-To: <49055B15.1070507@redhat.com>
References: <48FEF504.8030606@redhat.com> <49055B15.1070507@redhat.com>
Message-ID: <20081027092200.GA19222@amd.home.annexia.org>

On Mon, Oct 27, 2008 at 04:09:25PM +1000, Noriko Mizumoto wrote:
> Hi
>
> It is one day to go for Final Development freeze, 28-Oct.
> Could you please please check the following bugs and include all  
> translation submitted against?

Yes, I'll do these if I have time today ...

>> [virt-ctrl]
>> https://bugzilla.redhat.com/show_bug.cgi?id=467817
> No response, 9 languages translation attached as of 27-Oct, 04:00 UTC time.

This isn't in Fedora.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From erik at vanpienbroek.nl  Mon Oct 27 10:34:39 2008
From: erik at vanpienbroek.nl (Erik van Pienbroek)
Date: Mon, 27 Oct 2008 11:34:39 +0100
Subject: ViewVC has been split into viewvc/viewvc-httpd
In-Reply-To: <1225065549.2783.9.camel@shrek.rexursive.com>
References: <1225065549.2783.9.camel@shrek.rexursive.com>
Message-ID: <1225103679.3247.6.camel@erik>

Op maandag 27-10-2008 om 10:59 uur [tijdzone +1100], schreef Bojan
Smojver:
> Just a heads up that as of today, ViewVC has been split into viewvc
> (which depends on webserver) and viewvc-httpd (which depends on
> mod_python), in order to address bug #457691.
> 
> So, if you are running viewvc under Apache/mod_python on F8/F9, you'll
> have to install viewvc-httpd package in F10 to get the same thing.

In what package is the Apache configuration file now? Will this change
break stuff for Apache users who already had an older version installed?

Regards,

Erik van Pienbroek




From christoph.wickert at googlemail.com  Mon Oct 27 09:34:42 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 27 Oct 2008 10:34:42 +0100
Subject: Need a build chain in koji, not a chainbuild [URGENT]
Message-ID: <1225100083.3813.28.camel@wicktop.localdomain>

I'm working hard on the Xfce 4.4.3 update. Since it is only a bugfix
release we'd like it to appear in F10. My problem is that it has a long
dependency chain. I first have to build the basic libs and then I can
start with some apps, then the rest.

Now I'm stuck already at the second package because it needs the first
one. How long do I have to wait until the first package appears at 
http://koji.fedoraproject.org/static-repos/dist-rawhide-current/
or at http://download.fedora.redhat.com/pub/fedora/linux/development/ ?

Please don't tell me to use a chainbuild, because IMO for a long
dependency chain this is to risky. I have _no_ way to test if a package
builds, nether with mock, nor with a scratchbuild. If one package fails,
the complete chain is broken. This has become even worse with immutable
tags (although I understand the need for immutable tags).

What to do in situations like these? I'm not talking about this
particular situation but about problems like these in general.

Regards,
Christoph





From kzak at redhat.com  Mon Oct 27 10:04:58 2008
From: kzak at redhat.com (Karel Zak)
Date: Mon, 27 Oct 2008 11:04:58 +0100
Subject: gnome-applet-vm: request for co-maintainer(s)
Message-ID: <20081027100458.GB27835@nb.net.home>


 Unfortunately, I don't have enough time to work on gnome-applet-vm
 (virtual machines monitor) package ... so, I'm looking for Fedora and
 upstream co-maintainer for the applet. Any volunteer(s)?

 Project homepage: http://hosted.fedoraproject.org/gnome-applet-vm/

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From rawhide at fedoraproject.org  Mon Oct 27 10:28:35 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 27 Oct 2008 10:28:35 +0000 (UTC)
Subject: rawhide report: 20081027 changes
Message-ID: <20081027102835.6DC561F824B@releng2.fedora.phx.redhat.com>

Compose started at Mon Oct 27 06:01:12 UTC 2008

New package R-GeneR
        R for genes and sequences analysis
New package libnxml
        C library for parsing, writing and creating XML
Updated Packages:

R-2.8.0-2.fc10
--------------
* Sun Oct 26 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 2.8.0-2
- enable libtiff interface

* Sun Oct 26 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 2.8.0-1
- Update to 2.8.0
- New subpackage layout: R-core is functional userspace, R is metapackage 
  requiring everything
- Fix system bzip2 detection


alienarena-7.20-4.fc10
----------------------
* Sun Oct 26 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 7.20-4
- re-enable "don't search data path" patch

* Sun Oct 26 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 7.20-3
- use LD_LIBRARY_PATH in scripts


asymptote-1.47-1.fc10
---------------------
* Sun Oct 26 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.47-1
- update to 1.47


beagle-0.3.8-8.fc10
-------------------
* Sun Oct 26 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> - 0.3.8-8
- Fix user creation, possible security issue (RH #468610)


beldi-0.9.23-1.fc10
-------------------
* Sun Oct 26 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.9.23-1
- Upgrade to 0.9.23
- Add NEWS and new ChangeLog


blender-2.48a-3.fc10
--------------------
* Sun Oct 26 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 2.48a-3
- Create %{_libdir}/blender/scripts/ to claim ownership

* Sun Oct 26 18:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 2.48a-1
- New upstream release


bluez-4.17-1.fc10
-----------------
* Sun Oct 26 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.17-1
- Update to 4.17


bluez-gnome-1.8-8.fc10
----------------------
* Sun Oct 26 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 1.8-8
- Avoid the devices jumping around in the treeview


clamav-0.94-1.fc10
------------------
* Sun Oct 26 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> - 0.94-1
- Upgrade to 0.94 (SECURITY), fixes #461461:
- CVE-2008-1389 Invalid memory access in the CHM unpacker
- CVE-2008-3912 Out-of-memory NULL pointer dereference in mbox/msg
- CVE-2008-3913 Memory leak in code path in freshclam's manager.c
- CVE-2008-3914 Multiple file descriptor leaks on the code paths


conntrack-tools-0.9.8-1.fc10
----------------------------
* Sun Oct 26 18:00:00 2008 Paul P. Komkoff Jr <i at stingr.net> - 0.9.8-1
- new upstream version
- remove rollup patch


crypto-utils-2.4.1-2
--------------------
* Sun Oct 26 18:00:00 2008 Elio Maldonado <emaldona at redhat.com> - 2.4.1-2
- enabled renewal for certs in the nss database
- disabled renewal for certs in pem files
- added man page examples
- requires nss 3.12.2 or higher


eclipse-pydev-1.3.23-1.fc10
---------------------------
* Sun Oct 26 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 1:1.3.23-1
- 1.3.23


ext3grep-0.10.0-1.fc10
----------------------
* Sun Oct 26 18:00:00 2008 Milos Jakubicek <xjakub at fi.muni.cz> - 0.10.0-1
- Upstream version 0.10.0


fpc-2.2.2-3.fc10
----------------
* Sat Oct 25 18:00:00 2008 Joost van der Sluis <joost at cnoc.nl> 2.2.2-3
- Do not distribute the RTL and packages with debug-info included
- Fix the location of the fpc-binary in the samplecfg script


fuse-encfs-1.5-1.fc10
---------------------
* Sun Oct 26 18:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 1.5-1
- Ver. 1.5
- Dropped upstreamed patches


geany-0.15-1.fc10
-----------------
* Sun Oct 26 18:00:00 2008 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 0.15-1
- Update to 0.15
- Update URL
- Add intltool to BuildRequires


gnome-session-2.24.1-3.fc10
---------------------------
* Sun Oct 26 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 2.24.1-3
- Make the capplet resizable (#468577)


iw-0.9.6-1.fc10
---------------
* Sun Oct 26 18:00:00 2008 Adel Gadllah <adel.gadllah at gmail.com> 0.9.6-1
- Update to 0.9.6


kernel-2.6.27.4-51.fc10
-----------------------
* Sun Oct 26 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-51
- Linux 2.6.27.4

* Sat Oct 25 18:00:00 2008 Dave Jones <davej at redhat.com> 2.6.27.4-48.rc3
- tcp: Restore ordering of TCP options for the sake of inter-operability

* Sat Oct 25 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-50.rc3
- Two patches for the r8169 network driver that should fix bug #460747

* Sat Oct 25 18:00:00 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.4-49.rc3
- Scheduler fixes from 2.6.28, fixing performance problems:
    Disable HRTICK scheduler feature.
    Keep the scheduler clock from going backwards.


libgadu-1.8.2-1.fc10
--------------------
* Sun Oct 26 18:00:00 2008 Dominik Mierzejewski <rpm at greysector.net> 1.8.2-1
- updated to 1.8.2 (security update)
- preserve timestamps during make install
- put defattr at the top of files section (fixes rpmlint error)


libnetfilter_conntrack-0.0.97-1.fc10
------------------------------------
* Sun Oct 26 18:00:00 2008 Paul P. Komkoff Jr <i at stingr.net> - 0.0.97-1
- new upstream version

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.0.96-3
- Fix Patch0:/%patch mismatch.


libnetfilter_log-0.0.15-1.fc10
------------------------------
* Sun Oct 26 18:00:00 2008 Paul P. Komkoff Jr <i at stingr.net> - 0.0.15-1
- new upstream version
- hard dependency on libnfnetlink version


libnetfilter_queue-0.0.16-3.fc10
--------------------------------
* Sun Oct 26 18:00:00 2008 Paul P. Komkoff Jr <i at stingr.net> - 0.0.16-3
- fix patch/patch0
- depend on specific libnfnetlink version


linuxwacom-0.8.0.3-3.fc10
-------------------------
* Sun Oct 26 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> 0.8.0.3-3
- Update HAL fdi file to also match the Wacom Bluetooth tablet


lirc-0.8.4a-1.fc10
------------------
* Sun Oct 26 18:00:00 2008 - Jarod Wilson <jarod at redhat.com> - 0.8.4a-1
- Update to lirc 0.8.4a release (fixes mode2 irrecord failures)
- Really fix the mceusb remote config file this time


man-pages-ko-20050219-7.fc10
----------------------------
* Mon Oct 27 18:00:00 2008 Ding-Yi Chen <dchen at redhat dot com> - 2:20050219-7
- Fix Bug 468501 - There were file conflicts when cheeking the packages 
  to be installed in Fedora-10-beta-x86_6.


openvrml-0.17.10-1.0.fc10
-------------------------
* Sun Oct 26 18:00:00 2008 Braden McDaniel  <braden at endoframe.com> - 0.17.10-1.0
- Updated to 0.17.10.


perl-CGI-Ex-2.24-1.fc10
-----------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 2.24-1
- update to 2.24


perl-CSS-Tiny-1.15-1.fc10
-------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.15-1
- update to 1.15


perl-Catalyst-Plugin-Authentication-0.10008-1.fc10
--------------------------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.10008-1
- update to 0.10008


perl-Hash-Case-1.006-1.fc10
---------------------------
* Sat Oct 25 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.006-1
- update to 1.006


perl-Log-Dispatch-Config-1.02-1.fc10
------------------------------------
* Sat Oct 25 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.02-1
- update to 1.02


perl-Log-Dispatch-FileRotate-1.19-1.fc10
----------------------------------------
* Sun Oct 26 18:00:00 2008 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1.19-1
- Upstream update.


perl-Object-InsideOut-3.51-1.fc10
---------------------------------
* Sat Oct 25 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 3.51-1
- update to 3.51
- replace filter-provides.sh style filtering with inline


perl-POE-Component-IRC-5.88-1.fc10
----------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 5.88-1
- update to 5.88


perl-POE-Component-SSLify-0.14-1.fc10
-------------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.14-1
- update to 0.14


perl-POE-Component-Server-SOAP-1.13-1.fc10
------------------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.13-1
- update to 1.13


perl-POE-Component-Server-SimpleHTTP-1.48-1.fc10
------------------------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.48-1
- update to 1.48


perl-POE-Component-SimpleLog-1.05-1.fc10
----------------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.05-1
- update to 1.05


perl-POE-Filter-Zlib-2.01-1.fc10
--------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 2.01-1
- update to 2.01


perl-Sub-Exporter-0.981-1.fc10
------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 0.981-1
- update to 0.981


perl-Test-Distribution-2.00-2.fc10
----------------------------------
* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 2.00-2
- Changes -> Changes.pod in doc

* Sun Oct 26 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 2.00-1
- update to 2.00


plymouth-0.6.0-0.2008.10.24.2.fc10
----------------------------------
* Sun Oct 26 18:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.6.0-0.2008.10.24.2
- More requires changing to avoid loops (#467356)


python-beaker-1.0.3-1.fc10
--------------------------

rpy-1.0.3-4.fc10
----------------
* Sun Oct 26 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.3-4
- rebuild against R-2.8.0


rss2email-2.64-1.1
------------------
* Sun Oct 26 18:00:00 2008 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 2.64-1
- update to 2.64
- drop rss2email-warn-if-problems-with-local-mta.patch, something similar now
  upstream


shorewall-4.2.1-1.fc10
----------------------

totem-2.24.3-1.fc10
-------------------
* Sun Oct 26 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.3-1
- Update to 2.24.3
- Fixes for recent YouTube website changes (#468578)


viewvc-1.0.7-2.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Bojan Smojver <bojan at rexursive.com> - 1.0.7-2
- Depend on webserver to avoid pulling in Apache/mod_python (bug #457691)
- Provide viewvc-httpd package for mod_python specific configuration


wine-1.1.7-1.fc10
-----------------
* Sun Oct 26 18:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.1.7-1
- version upgrade


xorg-x11-drv-vmmouse-12.6.1-1.fc10
----------------------------------
* Mon Oct 27 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 12.6.1-1
- vmmouse 12.6.1


xorg-x11-server-1.5.2-9.fc10
----------------------------
* Mon Oct 27 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 1.5.2-9
- xserver-1.5.2-more-sanity-checks.patch: more sanity checks to stop vmmouse
  from segfaulting the server. #434807

* Wed Oct 22 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com>
- fix typo in xserver-1.5.2-no-duplicate-devices.patch

* Wed Oct 22 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com>
- Update xserver-1.5.2-disable-kbd-mouse.patch: add line to xorg.conf man-page
  stating that devices are disabled if AEI is on.


Summary:
Added Packages: 2
Removed Packages: 0
Modified Packages: 52
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
	gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0
	gurlchecker-0.10.1-9.fc10.i386 requires libclamav.so.4(CLAMAV_PUBLIC)
	gurlchecker-0.10.1-9.fc10.i386 requires libclamav.so.4
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	klamav-0.44-2.fc10.i386 requires libclamav.so.4(CLAMAV_PUBLIC)
	klamav-0.44-2.fc10.i386 requires libclamav.so.4
	klamav-0.44-2.fc10.i386 requires libclamav.so.4(CLAMAV_PRIVATE)
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.i386 requires libgnome-desktop-2.so.2
	ume-launcher-0.6.3-1.fc9.i386 requires libclutter-glx-0.6.so.0



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.i386 requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-python2-gdl-2.19.1-20.fc10.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	gurlchecker-0.10.1-9.fc10.x86_64 requires libclamav.so.4(CLAMAV_PUBLIC)(64bit)
	gurlchecker-0.10.1-9.fc10.x86_64 requires libclamav.so.4()(64bit)
	iml-devel-1.0.2-3.fc10.i386 requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.x86_64 requires iml = 0:1.0.2-3.fc10
	klamav-0.44-2.fc10.x86_64 requires libclamav.so.4(CLAMAV_PUBLIC)(64bit)
	klamav-0.44-2.fc10.x86_64 requires libclamav.so.4(CLAMAV_PRIVATE)(64bit)
	klamav-0.44-2.fc10.x86_64 requires libclamav.so.4()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit)
	ume-launcher-0.6.3-1.fc9.x86_64 requires libgnome-desktop-2.so.2()(64bit)



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.ppc requires libgdl-gnome-1.so.0
	gnome-build-0.2.4-1.fc9.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-python2-gdl-2.19.1-20.fc10.ppc requires libgdl-gnome-1.so.0
	gurlchecker-0.10.1-9.fc10.ppc requires libclamav.so.4(CLAMAV_PUBLIC)
	gurlchecker-0.10.1-9.fc10.ppc requires libclamav.so.4
	iml-devel-1.0.2-3.fc10.ppc requires iml = 0:1.0.2-3.fc10
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	klamav-0.44-2.fc10.ppc requires libclamav.so.4(CLAMAV_PUBLIC)
	klamav-0.44-2.fc10.ppc requires libclamav.so.4
	klamav-0.44-2.fc10.ppc requires libclamav.so.4(CLAMAV_PRIVATE)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.ppc requires libgnome-desktop-2.so.2
	ume-launcher-0.6.3-1.fc9.ppc requires libclutter-glx-0.6.so.0



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gnome-build-0.2.4-1.fc9.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	gurlchecker-0.10.1-9.fc10.ppc64 requires libclamav.so.4(CLAMAV_PUBLIC)(64bit)
	gurlchecker-0.10.1-9.fc10.ppc64 requires libclamav.so.4()(64bit)
	iml-devel-1.0.2-3.fc10.ppc64 requires iml = 0:1.0.2-3.fc10
	klamav-0.44-2.fc10.ppc64 requires libclamav.so.4(CLAMAV_PUBLIC)(64bit)
	klamav-0.44-2.fc10.ppc64 requires libclamav.so.4(CLAMAV_PRIVATE)(64bit)
	klamav-0.44-2.fc10.ppc64 requires libclamav.so.4()(64bit)
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	rubygem-hoe-1.8.1-2.fc10.noarch requires rubygem(rake) >= 0:0.8.3
	ume-launcher-0.6.3-1.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit)
	ume-launcher-0.6.3-1.fc9.ppc64 requires libgnome-desktop-2.so.2()(64bit)





From pm at datasphere.ch  Mon Oct 27 11:05:42 2008
From: pm at datasphere.ch (Patrick MONNERAT)
Date: Mon, 27 Oct 2008 12:05:42 +0100
Subject: Blocking bug in Bodhi
Message-ID: <1225105542.3751.12.camel@linuxdev.datasphere.ch>

Hi list,

	There is a bug in Bodhi that prevents me to submit an update. I
submitted a bug report at https://fedorahosted.org/bodhi/ticket/253,
without reaction.

	Here is the problem: after having submitted an update request for
ocspd-1.5.1-0.3.rc1.fc9, I wanted to alter this request using the web
interface: all tentatives leaded to "500 internal error". I thus decided
to cancel+delete the request, then recreate it. But re-creation is
impossible: when attempting it, error message "ocspd-1.5.1-0.3.rc1.fc9
update already exists!" is displayed, although the previous update
request has been deleted. When clicking on the link in the error
message, an empty list with message "There are no updates for
ocspd-1.5.1-0.3.rc1.fc9" is displayed.

	As a consequence, I can't submit this update anymore. Please help !

Thanks in advance



From caolanm at redhat.com  Mon Oct 27 12:17:39 2008
From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara)
Date: Mon, 27 Oct 2008 12:17:39 +0000
Subject: Unofficial OpenOffice translations (Was: OpenOffice and go-oo)
In-Reply-To: <49056985.7050902@nicubunu.ro>
References: <1223888234.4182.9.camel@ScaryMonster>
	<200810242018.45718.vpivaini@cs.helsinki.fi>
	<49056985.7050902@nicubunu.ro>
Message-ID: <1225109859.13911.102.camel@vain.rhgalway>

On Mon, 2008-10-27 at 09:11 +0200, Nicu Buculei wrote:
> Is not necessarily about the SCA, but more about extra features, like 
> the build system.
> 
> Some months ago, when it was clear that our (Romanian) translation will 
> not be ready for 3.0, it was decided to target 3.1, but Sun was not 
> accepting translations for 3.1, they were focused on 3.0.
> Also Pavel provide localized builds for *each* language every two weeks 
> (is not easy to build OOo yourself), so it is a very useful convenience 
> for translators who need the builds for QA their progressing work.

Yup pjanik's translation-focused work is a great resource and has helped
loads of translators and translations get bootstrapped up. But just to
be clear here, pjaniks builds are a additional *third*
translation-focused stream, separate to ooo-build (go-ooo.org) and Sun's
vanilla builds. i.e. what pops out at
http://ftp.linux.cz/pub/localization/OpenOffice.org/... is a vanilla Ooo
with the additional sdf files applied.

We could also add late translations (or LGPL translations that have
contributors that didn't sign the Sun SCA) as extra Sources: in
our .spec, as we did for a F-9 update for some Serbian translations when
someone asked to have them included. Though I'm not particularly
enthused about adding never-to-be-merged translations after I only got
our last F-9 out-of-stream translations merged into upstream in this
release.

C.



From rdieter at math.unl.edu  Mon Oct 27 13:26:27 2008
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 27 Oct 2008 08:26:27 -0500
Subject: Need a build chain in koji, not a chainbuild [URGENT]
References: <1225100083.3813.28.camel@wicktop.localdomain>
Message-ID: <ge4fi3$8si$1@ger.gmane.org>

Christoph Wickert wrote:


> Now I'm stuck already at the second package because it needs the first
> one. How long do I have to wait until the first package 

~20-30 minutes.  To be sure, you can examine the newRepo tasks in koji to be
sure.

-- Rex




From mtasaka at ioa.s.u-tokyo.ac.jp  Mon Oct 27 13:47:29 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Mon, 27 Oct 2008 22:47:29 +0900
Subject: rpms/libcaca/devel .cvsignore, 1.3, 1.4 libcaca.spec, 1.16, 1.17
 sources, 1.3, 1.4
In-Reply-To: <20081027102102.3C4DD70134@cvs1.fedora.phx.redhat.com>
References: <20081027102102.3C4DD70134@cvs1.fedora.phx.redhat.com>
Message-ID: <4905C671.4010404@ioa.s.u-tokyo.ac.jp>

Matthias Saou wrote, at 10/27/2008 07:21 PM +9:00:
> Author: thias
> 
> Update of /cvs/extras/rpms/libcaca/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv6826
> 
> Modified Files:
> 	.cvsignore libcaca.spec sources 
> Log Message:
> Update to 0.99beta16.

With this change:

[root at localhost i386]# rpm -qp --provides libcaca-0.99-0.4.beta11.fc9.i386.rpm 
warning: libcaca-0.99-0.4.beta11.fc9.i386.rpm: Header V3 DSA signature: NOKEY, key ID 0b86274e
libcaca.so.0  
libcucul.so.0  
libcaca = 0.99-0.4.beta11.fc9
[root at localhost i386]# rpm -qp --provides libcaca-0.99-0.5.beta16.fc10.i386.rpm 
libcaca++.so.0  
libcaca.so.0  
libcaca = 0.99-0.5.beta16.fc10
libcaca(x86-32) = 0.99-0.5.beta16.fc10
[root at localhost i386]# repoquery --repoid=koji-10 --whatrequires libcucul.so.0
xine-lib-extras-0:1.1.15-2.fc10.i386

Mamoru



From mike at miketc.net  Mon Oct 27 13:52:54 2008
From: mike at miketc.net (Mike Chambers)
Date: Mon, 27 Oct 2008 08:52:54 -0500
Subject: Evolution Junk Mail errors
Message-ID: <1225115574.6174.6.camel@scrappy.miketc.net>

I asked before and someone else stated that they were seeing junk mail
errors as well.  I removed evolution-bogofilter for the time beeing.
Any others seeing this as well?  Wondering if I need to use a brand new
evolution settings from scratch instead of using backups all the time.,
and might not see the errors?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From debarshi.ray at gmail.com  Mon Oct 27 14:47:09 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 27 Oct 2008 20:17:09 +0530
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <v5r6648buq.fsf@allele2.eebweb.arizona.edu>
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<jhvdvg8can.fsf@allele2.eebweb.arizona.edu>
	<v5r6648buq.fsf@allele2.eebweb.arizona.edu>
Message-ID: <3170f42f0810270747w5dc35031w22cecd469a95e113@mail.gmail.com>

> AL> Thanks.  Unfortunately it appears that this affects gnome-python2
> AL> as well:
>
> [...]
>
>>>> Broken deps for i386
>>>> ----------------------------------------------------------
>>>> gnome-python2-gdl-2.19.1-20.fc10.i386 requires libgdl-gnome-1.so.0
>
> And sure enough gnome-python2-extras fails to rebuild after this
> change because it can't find certain gdl files:

I filed this: https://bugzilla.redhat.com/468698

Due to the lack of comments on the GNOME bugzilla about the proposed
patch, I am reluctant to apply that patch on the Fedora package, of
which I am neither the maintainer nor the co-maintainer.

Happy hacking,
Debarshi



From christoph.wickert at googlemail.com  Mon Oct 27 14:51:47 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 27 Oct 2008 15:51:47 +0100
Subject: Need a build chain in koji, not a chainbuild [URGENT]
In-Reply-To: <ge4fi3$8si$1@ger.gmane.org>
References: <1225100083.3813.28.camel@wicktop.localdomain>
	<ge4fi3$8si$1@ger.gmane.org>
Message-ID: <1225119107.3813.86.camel@wicktop.localdomain>

Am Montag, den 27.10.2008, 08:26 -0500 schrieb Rex Dieter:
> Christoph Wickert wrote:
> 
> 
> > Now I'm stuck already at the second package because it needs the first
> > one. How long do I have to wait until the first package 
> 
> ~20-30 minutes.  To be sure, you can examine the newRepo tasks in koji to be
> sure.

Thanks for your reply. There infrastructure things are not well
documented and sometimes hard to understand for outsiders.

I have cut the chain into some groups and I hope that everything will
turn out right.

Regards,
Christoph



From alexl at users.sourceforge.net  Mon Oct 27 15:10:27 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Mon, 27 Oct 2008 08:10:27 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <3170f42f0810270747w5dc35031w22cecd469a95e113@mail.gmail.com>
	(Debarshi Ray's message of "Mon\, 27 Oct 2008 20\:17\:09 +0530")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<jhvdvg8can.fsf@allele2.eebweb.arizona.edu>
	<v5r6648buq.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0810270747w5dc35031w22cecd469a95e113@mail.gmail.com>
Message-ID: <9zvdve5b18.fsf@allele2.eebweb.arizona.edu>

>>>>> Debarshi Ray  writes:

AL> Thanks.  Unfortunately it appears that this affects gnome-python2
AL> as well:
>> 
>> [...]
>> 
>>>>> Broken deps for i386
>>>>> ----------------------------------------------------------
>>>>> gnome-python2-gdl-2.19.1-20.fc10.i386 requires
>>>>> libgdl-gnome-1.so.0
>> 
>> And sure enough gnome-python2-extras fails to rebuild after this
>> change because it can't find certain gdl files:

> I filed this: https://bugzilla.redhat.com/468698

> Due to the lack of comments on the GNOME bugzilla about the proposed
> patch, I am reluctant to apply that patch on the Fedora package, of
> which I am neither the maintainer nor the co-maintainer.

Thanks for filing the bug.  The patch doesn't apply in any case.
Nevertheless, it would be good to pester the maintainer of the
gnome-python2-extras and help him look into it, given that it was your
soname bump of libgdl that caused the problem in the first place. :)

I'm not trying to pick on you (because at least you announced the
change on f-d-l), but, in general, it would be good if maintainers got
in the habit of always running repoquery when an soname bump is going
to happen to check exactly which packages a given soname depends on,
rather than guess.  Then the maintainer can co-ordinate with the
maintainers of the affected packages *in advance* (or rebuild them
yourself if sufficiently comfortable with the package), rather than
having broken deps in rawhide which last for several days (or weeks in
some cases).

Alex



From jonathan.underwood at gmail.com  Mon Oct 27 15:17:29 2008
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 27 Oct 2008 15:17:29 +0000
Subject: Need a build chain in koji, not a chainbuild [URGENT]
In-Reply-To: <1225100083.3813.28.camel@wicktop.localdomain>
References: <1225100083.3813.28.camel@wicktop.localdomain>
Message-ID: <645d17210810270817w7bd50795j11b7debb99d069bc@mail.gmail.com>

2008/10/27 Christoph Wickert <christoph.wickert at googlemail.com>:
> Please don't tell me to use a chainbuild, because IMO for a long
> dependency chain this is to risky. I have _no_ way to test if a package
> builds, nether with mock, nor with a scratchbuild. If one package fails,
> the complete chain is broken.

Is it not the case that if one package build fails the whole chain
build is aborted? If not, it probably should be.



From jkeating at redhat.com  Mon Oct 27 15:49:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 27 Oct 2008 08:49:13 -0700
Subject: what QA gets mailed to the packagers?
In-Reply-To: <20081025110430.GC2608@free.fr>
References: <20081025110430.GC2608@free.fr>
Message-ID: <1225122554.2157.4.camel@luminos.localdomain>

On Sat, 2008-10-25 at 13:04 +0200, Patrice Dumas wrote:
> * nagmails sent for EVR

This got lost at some point, and I have some scripts I'm working on to
bring them back.  The difficult part is deciding how to appropriately
code the relationship of say f8 updates testing to f9 updates and such.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/2370f5d7/attachment.sig>

From mitr at volny.cz  Mon Oct 27 16:25:58 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Mon, 27 Oct 2008 16:25:58 +0000
Subject: RFC: Fedora signing server design
Message-ID: <1225124758.11485.26.camel@amilo>

Hello,
I'm working on a signing server for Fedora that stores keys and
passphrases without making them directly accessible to everybody who
should be able to sign data with Fedora keys, and I'd appreciate a
review of the design.

The current design is at https://fedoraproject.org/wiki/User:Mitr , with
detailed protocol specifications linked at the end of the page.

Thanks,
	Mirek



From christoph.wickert at googlemail.com  Mon Oct 27 16:53:08 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 27 Oct 2008 17:53:08 +0100
Subject: Need a build chain in koji, not a chainbuild [URGENT]
In-Reply-To: <645d17210810270817w7bd50795j11b7debb99d069bc@mail.gmail.com>
References: <1225100083.3813.28.camel@wicktop.localdomain>
	<645d17210810270817w7bd50795j11b7debb99d069bc@mail.gmail.com>
Message-ID: <1225126388.3813.100.camel@wicktop.localdomain>

Am Montag, den 27.10.2008, 15:17 +0000 schrieb Jonathan Underwood:
> 2008/10/27 Christoph Wickert <christoph.wickert at googlemail.com>:
> > Please don't tell me to use a chainbuild, because IMO for a long
> > dependency chain this is to risky. I have _no_ way to test if a package
> > builds, nether with mock, nor with a scratchbuild. If one package fails,
> > the complete chain is broken.
> 
> Is it not the case that if one package build fails the whole chain
> build is aborted? 

Yes, that's what I meant with "the whole chain is broken".

Christoph



From pertusus at free.fr  Mon Oct 27 16:55:59 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 27 Oct 2008 17:55:59 +0100
Subject: Need a build chain in koji, not a chainbuild [URGENT]
In-Reply-To: <1225126388.3813.100.camel@wicktop.localdomain>
References: <1225100083.3813.28.camel@wicktop.localdomain>
	<645d17210810270817w7bd50795j11b7debb99d069bc@mail.gmail.com>
	<1225126388.3813.100.camel@wicktop.localdomain>
Message-ID: <20081027165559.GI2975@free.fr>

On Mon, Oct 27, 2008 at 05:53:08PM +0100, Christoph Wickert wrote:
> Am Montag, den 27.10.2008, 15:17 +0000 schrieb Jonathan Underwood:
> > 2008/10/27 Christoph Wickert <christoph.wickert at googlemail.com>:
> > > Please don't tell me to use a chainbuild, because IMO for a long
> > > dependency chain this is to risky. I have _no_ way to test if a package
> > > builds, nether with mock, nor with a scratchbuild. If one package fails,
> > > the complete chain is broken.
> > 
> > Is it not the case that if one package build fails the whole chain
> > build is aborted? 
> 
> Yes, that's what I meant with "the whole chain is broken".

If I recall well in that case the packagfes already built are put in the
repo. So the remaining of th echain is aborted but what is already built
is not removed.

--
Pat



From jkeating at redhat.com  Mon Oct 27 17:07:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 27 Oct 2008 10:07:41 -0700
Subject: Need a build chain in koji, not a chainbuild [URGENT]
In-Reply-To: <20081027165559.GI2975@free.fr>
References: <1225100083.3813.28.camel@wicktop.localdomain>
	<645d17210810270817w7bd50795j11b7debb99d069bc@mail.gmail.com>
	<1225126388.3813.100.camel@wicktop.localdomain>
	<20081027165559.GI2975@free.fr>
Message-ID: <1225127261.2157.11.camel@luminos.localdomain>

On Mon, 2008-10-27 at 17:55 +0100, Patrice Dumas wrote:
> If I recall well in that case the packagfes already built are put in the
> repo. So the remaining of th echain is aborted but what is already built
> is not removed.

That is my understanding as well, since once in the collection, and in
the buildroot, it may have been used for building something else, not
part of your chain, and thus removing it is the wrong solution.

Long term, I really think we need to do chains in their own custom build
collection so that they can be atomic and they can be aborted in whole.
Also it would allow us to use chains on targets that don't self update
such as updates candidates.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/bf0428bb/attachment.sig>

From christoph.wickert at googlemail.com  Mon Oct 27 18:02:04 2008
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 27 Oct 2008 19:02:04 +0100
Subject: Need a build chain in koji, not a chainbuild [SOLVED]
In-Reply-To: <1225127261.2157.11.camel@luminos.localdomain>
References: <1225100083.3813.28.camel@wicktop.localdomain>
	<645d17210810270817w7bd50795j11b7debb99d069bc@mail.gmail.com>
	<1225126388.3813.100.camel@wicktop.localdomain>
	<20081027165559.GI2975@free.fr>
	<1225127261.2157.11.camel@luminos.localdomain>
Message-ID: <1225130524.3813.119.camel@wicktop.localdomain>

Am Montag, den 27.10.2008, 10:07 -0700 schrieb Jesse Keating:
> On Mon, 2008-10-27 at 17:55 +0100, Patrice Dumas wrote:
> > If I recall well in that case the packagfes already built are put in the
> > repo. So the remaining of th echain is aborted but what is already built
> > is not removed.
> 
> That is my understanding as well, since once in the collection, and in
> the buildroot, it may have been used for building something else, not
> part of your chain, and thus removing it is the wrong solution.

This is correct: Packages that are built are going to the repo, sooner
or later. But the current chain-build behavior is not very logical when
it comes to groups. One can separate different groups with colons, which
are built in parallel.

Example of building a package called baz.
      * Normal (sequentially) chain-build:
        make chain-build CHAIN='foo bar'
      * Grouped chain-build
        make chain-build CHAIN='foo bar : foobar' 
In this example foo and bar are built in parallel, then foobar and baz
are build in parallel too, while one (at least me) would expect it to be
built after the previous packages in the chain. If baz fails because
foobar is not ready yet, foobar will be canceled. Pretty confusing.

So every time you start using groups, you have to use trailing colons
        make chain-build CHAIN='foo bar : foobar :'

Thanks to the people who helped me on IRC to figure this out. I will try
to update the wiki to make this more clear later when I finished with
Xfce.

> Long term, I really think we need to do chains in their own custom build
> collection so that they can be atomic and they can be aborted in whole.
> Also it would allow us to use chains on targets that don't self update
> such as updates candidates.

+1

Christoph



From tcallawa at redhat.com  Mon Oct 27 18:17:33 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 27 Oct 2008 14:17:33 -0400
Subject: help required for thoggen
In-Reply-To: <20081024162804.GA29574@mokona.greysector.net>
References: <b401d2530810240026i109561c1xb60c2be5f26f68fa@mail.gmail.com>
	<20081024162804.GA29574@mokona.greysector.net>
Message-ID: <1225131453.3270.13.camel@localhost.localdomain>

On Fri, 2008-10-24 at 18:28 +0200, Dominik 'Rathann' Mierzejewski wrote:
> However, MP2 is patent-free already, I think.

You think incorrectly. ;)

~spot



From bpepple at fedoraproject.org  Mon Oct 27 19:31:35 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 27 Oct 2008 15:31:35 -0400
Subject: Package Review SIG Meeting Summary 2008-10-23
Message-ID: <1225135895.21297.7.camel@kennedy>

=== Present ===
* Brian Pepple          (bpepple)
* Jon Ciesla            (limburgher)
* Rakesh Pandit         (chacha_chaudry)
* Kushal Das            (kushal)
* Jason Tibbitts        (ubertibbs)
* Rex Dieter            (rdieter)

== Summary ==
=== Package Review Statistics ===
      * bpepple, limburger, and chacha_chaudhry will work on a script to
        generate weekly package review statistics.

=== Brain-Storming ===
      * The group brain-stormed for a bit on ways to improve
        participation in package reviews.  Some ideas were:
             1. Monthly (or some other time frame) swag drawing for
                folks that complete a certain number of reviews in a
                month.
             2. Advertise better the concept of reviewing at least a
                percentage of what they submit.
             3. Prioritize the package review queue by the ratio of
                reviews done / package submissions.
             4. Engaging SIG's to review packages. (Ex. Like how the KDE
                sig keeps an eye on kde-related packages)
             5. Coordinate some package review days (and do a better job
                of it than we have in the past)
             6. Hold an IRC workshop (or maybe a trac at FUDCon) on
                package reviewing.

=== Future Meetings ===
      * Instead of IRC meetings, the group will use the devel-list to
        conduct future business.

IRC log can be found at:
http://bpepple.fedorapeople.org/prs/package-review-sig-2008-10-23.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/4a50c338/attachment.sig>

From rjones at redhat.com  Mon Oct 27 19:39:20 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 27 Oct 2008 19:39:20 +0000
Subject: RFC: Fedora signing server design
In-Reply-To: <1225124758.11485.26.camel@amilo>
References: <1225124758.11485.26.camel@amilo>
Message-ID: <20081027193920.GA20154@amd.home.annexia.org>

On Mon, Oct 27, 2008 at 04:25:58PM +0000, Miloslav Trma? wrote:
> I'm working on a signing server for Fedora that stores keys and
> passphrases without making them directly accessible to everybody who
> should be able to sign data with Fedora keys, and I'd appreciate a
> review of the design.

Did you read this about how CAcert designed their secure signing
system?

  http://www.cacert.org/help.php?id=7

Quite interesting and relevant I think.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From bojan at rexursive.com  Mon Oct 27 20:02:01 2008
From: bojan at rexursive.com (Bojan Smojver)
Date: Mon, 27 Oct 2008 20:02:01 +0000 (UTC)
Subject: ViewVC has been split into viewvc/viewvc-httpd
References: <1225065549.2783.9.camel@shrek.rexursive.com>
	<1225103679.3247.6.camel@erik>
Message-ID: <loom.20081027T195935-473@post.gmane.org>

Erik van Pienbroek <erik <at> vanpienbroek.nl> writes:

> In what package is the Apache configuration file now?

viewvc-httpd.

> Will this change
> break stuff for Apache users who already had an older version installed?

If they deploy viewvc-httpd, it shouldn't.

--
Bojan



From pertusus at free.fr  Mon Oct 27 20:02:26 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 27 Oct 2008 21:02:26 +0100
Subject: Need a build chain in koji, not a chainbuild [SOLVED]
In-Reply-To: <1225130524.3813.119.camel@wicktop.localdomain>
References: <1225100083.3813.28.camel@wicktop.localdomain>
	<645d17210810270817w7bd50795j11b7debb99d069bc@mail.gmail.com>
	<1225126388.3813.100.camel@wicktop.localdomain>
	<20081027165559.GI2975@free.fr>
	<1225127261.2157.11.camel@luminos.localdomain>
	<1225130524.3813.119.camel@wicktop.localdomain>
Message-ID: <20081027200225.GA2666@free.fr>

On Mon, Oct 27, 2008 at 07:02:04PM +0100, Christoph Wickert wrote:
> 
> Example of building a package called baz.
>       * Normal (sequentially) chain-build:
>         make chain-build CHAIN='foo bar'
>       * Grouped chain-build
>         make chain-build CHAIN='foo bar : foobar' 
> In this example foo and bar are built in parallel, then foobar and baz
> are build in parallel too, while one (at least me) would expect it to be
> built after the previous packages in the chain. If baz fails because
> foobar is not ready yet, foobar will be canceled. Pretty confusing.
> 
> So every time you start using groups, you have to use trailing colons
>         make chain-build CHAIN='foo bar : foobar :'
> 
> Thanks to the people who helped me on IRC to figure this out. I will try
> to update the wiki to make this more clear later when I finished with
> Xfce.

I porposed something for make help some time ago, please see if you can
enhance it, but it tried to explain things like you do (I aws very
confused by the previous documentation). I'll update 
http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained_builds
such that it matches make help output, but please propose any
enhancement.

--
Pat



From wwoods at redhat.com  Mon Oct 27 21:07:59 2008
From: wwoods at redhat.com (Will Woods)
Date: Mon, 27 Oct 2008 17:07:59 -0400
Subject: X on tty1 in Rawhide/F10
Message-ID: <1225141679.3523.48.camel@metroid.rdu.redhat.com>

Hi folks,

If you're running F10Beta/Rawhide, you may have noticed already, but I
wanted to make sure everyone knows this is intentional:

X HAS MOVED FROM VT7 TO VT1.

GDM specifically starts X on tty1, and upstart does not start a getty on
tty1 in runlevel 5. 

Other display managers might need to be changed to match (or they might
Just Work since tty1 will be the first unused tty). 

If you maintain one of the other display managers, it would be good to
make sure that your packages do the right thing.

Thanks!

-w



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3153 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/9da9f6e9/attachment.bin>

From jreiser at BitWagon.com  Mon Oct 27 21:19:31 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Mon, 27 Oct 2008 14:19:31 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
Message-ID: <49063063.8050802@BitWagon.com>

> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
> 
> X HAS MOVED FROM VT7 TO VT1.
> 
> GDM specifically starts X on tty1, and upstart does not start a getty on
> tty1 in runlevel 5. 

I'm running today's rawhide, but I still see X11 on vty7 (Ctrl-Alt-F7),
init log on vty1, and text login on vty2 through vty6.

"rpm -qa" says:
   gdm-2.4.0-11.fc10.i386
   xorg-x11-server-Xorg-1.5.2-9.fc10.i386
   xorg-x11-xinit-1.0.9-4.fc10.i386
/etc/inittab says:
   id:5:initdefault:

The anaconda-11.4.1.51 installer also runs X11 on vty7, with anaconda "console"
on vty1, shell on vty2, various logs on vty3 through vty5, and "No signal" on vty6.

-- 



From wwoods at redhat.com  Mon Oct 27 21:54:14 2008
From: wwoods at redhat.com (Will Woods)
Date: Mon, 27 Oct 2008 17:54:14 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49063063.8050802@BitWagon.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<49063063.8050802@BitWagon.com>
Message-ID: <1225144454.3523.59.camel@metroid.rdu.redhat.com>

On Mon, 2008-10-27 at 14:19 -0700, John Reiser wrote:
> > If you're running F10Beta/Rawhide, you may have noticed already, but I
> > wanted to make sure everyone knows this is intentional:
> > 
> > X HAS MOVED FROM VT7 TO VT1.
> > 
> > GDM specifically starts X on tty1, and upstart does not start a getty on
> > tty1 in runlevel 5. 
> 
> I'm running today's rawhide, but I still see X11 on vty7 (Ctrl-Alt-F7),
> init log on vty1, and text login on vty2 through vty6.

Are you running GDM as your display manager? It's on tty1 on my system -
same gdm / xinit versions as you. When was the last time you rebooted?

> The anaconda-11.4.1.51 installer also runs X11 on vty7, with anaconda "console"
> on vty1, shell on vty2, various logs on vty3 through vty5, and "No signal" on vty6.

You're correct; this information does not apply to anaconda. (At least
not yet.)

One thing though: Anaconda typically runs X on tty6. 

tty1: console
tty2: shell
tty3: anaconda.log
tty4: syslog
tty5: redirected output from commands run by anaconda
tty6: X

Not sure why it would show up as tty7 on your system.

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3153 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/fc4a4271/attachment.bin>

From mw_triad at users.sourceforge.net  Mon Oct 27 22:01:04 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 27 Oct 2008 17:01:04 -0500
Subject: kde needs mysql-server ??
In-Reply-To: <385866f0810240446j2ccd6cd8s749f39c9da60ccb0@mail.gmail.com>
References: <48FF046A.3000501@nobugconsulting.ro>	<200810241243.12892.Juha.Tuomala@iki.fi>
	<385866f0810240446j2ccd6cd8s749f39c9da60ccb0@mail.gmail.com>
Message-ID: <ge5dn0$6tb$1@ger.gmane.org>

Muayyad AlSadi wrote:
> they must consider sqlite, it's very crazy for desktop applications
> like amarok or contacts ..etc. to serve a database and to connect to
> itself

Ah, did you actually read http://techbase.kde.org/Projects/PIM/Akonadi? 
(Summary: they *did* consider sqlite, at least according to the FAQ)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
When on POSIX, do as POSIX mandates.



From cra at WPI.EDU  Mon Oct 27 22:06:13 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 27 Oct 2008 18:06:13 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
Message-ID: <20081027220613.GC19205@angus.ind.WPI.EDU>

On Mon, Oct 27, 2008 at 05:07:59PM -0400, Will Woods wrote:
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
> 
> X HAS MOVED FROM VT7 TO VT1.

So what goodness does this provide for us?



From opensource at till.name  Mon Oct 27 22:11:10 2008
From: opensource at till.name (Till Maas)
Date: Mon, 27 Oct 2008 23:11:10 +0100
Subject: RFC: Fedora signing server design
In-Reply-To: <1225124758.11485.26.camel@amilo>
References: <1225124758.11485.26.camel@amilo>
Message-ID: <200810272311.18726.opensource@till.name>

On Mon October 27 2008, Miloslav Trma? wrote:

> I'm working on a signing server for Fedora that stores keys and
> passphrases without making them directly accessible to everybody who
> should be able to sign data with Fedora keys, and I'd appreciate a
> review of the design.

Are you cooperation with Jesse Keating? Afaik he works on this, too.

> The current design is at https://fedoraproject.org/wiki/User:Mitr , with
> detailed protocol specifications linked at the end of the page.

This would better fit on:
https://fedorahosted.org/sigul

This is the project page for the key signing server that is planned to be 
implemented for Fedora.

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/20081027/2d821bcd/attachment.sig>

From poelstra at redhat.com  Sat Oct 25 02:18:09 2008
From: poelstra at redhat.com (John Poelstra)
Date: Fri, 24 Oct 2008 19:18:09 -0700
Subject: Blocker Bug Review Meeting :: Monday @ 14:00 UTC
Message-ID: <490281E1.1090305@redhat.com>

A meeting is being held to review the current blocker bugs in 
anticipation of the Final Development Freeze this Tuesday, October 28th.

All teams (thus the cc to f-a-b) in Fedora are welcome to join in and help.

WHEN: Monday, October 27, 2008 @ 14:00 UTC (10 AM EDT) and going as long 
as we need to
WHERE: irc.freenode.net #fedora-blocker

Fedora 10 Blocker: 
https://bugzilla.redhat.com/showdependencytree.cgi?id=438943&hide_resolved=1
Fedora 10 Preview Blocker: 
https://bugzilla.redhat.com/showdependencytree.cgi?id=446449&hide_resolved=1

There still remain approximately 600 rawhide bugs that have not been 
triaged for potential blocker status and should be considered as well. 
These bugs are here: http://tinyurl.com/6llac8

Other tracker bugs of interest are here: 
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers

John

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From dimitris at glezos.com  Mon Oct 27 22:09:22 2008
From: dimitris at glezos.com (Dimitris Glezos)
Date: Tue, 28 Oct 2008 00:09:22 +0200
Subject: Translation packagers: Rebuild before devel freeze
Message-ID: <6d4237680810271509l38670d03ta243b3e61d90d632@mail.gmail.com>

Reminding maintainers of Fedora-translatable packages to issue a build
before the Development Freeze of tomorrow, 28/10, in order to have all
translations submitted until the translation deadline of 21/10
included in Fedora 10 (otherwise our translator's hard work will go to
the gutter). If you haven't received any translations since the last
build, a rebuild is not necessary.

Feel free to drop an email to fedora-trans-list at redhat.com if you have
any questions.

Thanks for caring for translations*. (=

-?

*and, subsequently, 60%+ of our users.


-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From mitr at volny.cz  Mon Oct 27 22:16:25 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Mon, 27 Oct 2008 22:16:25 +0000
Subject: RFC: Fedora signing server design
In-Reply-To: <20081027193920.GA20154@amd.home.annexia.org>
References: <1225124758.11485.26.camel@amilo>
	<20081027193920.GA20154@amd.home.annexia.org>
Message-ID: <1225145785.11485.79.camel@amilo>

Richard W.M. Jones p??e v Po 27. 10. 2008 v 19:39 +0000:
> Did you read this about how CAcert designed their secure signing
> system?
> 
>   http://www.cacert.org/help.php?id=7
> 
> Quite interesting and relevant I think.
Indeed, thanks for the link.
	Mirek



From mitr at volny.cz  Mon Oct 27 22:17:00 2008
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Mon, 27 Oct 2008 23:17:00 +0100
Subject: RFC: Fedora signing server design
In-Reply-To: <200810272311.18726.opensource@till.name>
References: <1225124758.11485.26.camel@amilo>
	<200810272311.18726.opensource@till.name>
Message-ID: <1225145820.11485.81.camel@amilo>

Till Maas p??e v Po 27. 10. 2008 v 23:11 +0100:
> On Mon October 27 2008, Miloslav Trma? wrote:
> > I'm working on a signing server for Fedora that stores keys and
> > passphrases without making them directly accessible to everybody who
> > should be able to sign data with Fedora keys, and I'd appreciate a
> > review of the design.
> 
> Are you cooperation with Jesse Keating? Afaik he works on this, too.
Yes.
	Mirek



From dbn.lists at gmail.com  Mon Oct 27 22:18:09 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 27 Oct 2008 15:18:09 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081027220613.GC19205@angus.ind.WPI.EDU>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<20081027220613.GC19205@angus.ind.WPI.EDU>
Message-ID: <91705d080810271518w5c9a9f23md30cd77e25ee9b9e@mail.gmail.com>

On Mon, Oct 27, 2008 at 3:06 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On Mon, Oct 27, 2008 at 05:07:59PM -0400, Will Woods wrote:
>> If you're running F10Beta/Rawhide, you may have noticed already, but I
>> wanted to make sure everyone knows this is intentional:
>>
>> X HAS MOVED FROM VT7 TO VT1.
>
> So what goodness does this provide for us?

http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-startup/

--
Dan



From orion at cora.nwra.com  Mon Oct 27 22:29:19 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 27 Oct 2008 16:29:19 -0600
Subject: odf-converter for fedora
In-Reply-To: <385866f0810241154m4d3d1318xab37e77d040f88dd@mail.gmail.com>
References: <49020FBA.9030701@cora.nwra.com>
	<385866f0810241154m4d3d1318xab37e77d040f88dd@mail.gmail.com>
Message-ID: <490640BF.6000601@cora.nwra.com>

Muayyad AlSadi wrote:
> from < http://www.oooninja.com/2008/01/openxml-translator-odf-converter-11.html
> <<EOQ
> The odf-converter only integrates into Novell and Ubuntu editions of
> OpenOffice.org. The odf-converter may work with the Go-Oo edition, but
> I am not sure. It does not work with the upstream version (the version
> from the OpenOffice.org web site that most people use) or with the
> Fedora version, so don't even try.

The command line tool works fine.  It does seem like it tries to install 
some Filter/Type configs for OO (see below).  With them installed in 
%{_libdir}/openoffice.org/share/registry/modules/org/openoffice/TypeDetection/{Filter,Types} 
OO allows me to try to open a docx file, but then says it needs to be 
repaird.   So perhaps it really doesn't integrate into Fedora OO.  I 
wonder why.

MOOXFilter_cpp.xcu:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE oor:component-data SYSTEM "../../../../component-update.dtd">
<oor:component-data xmlns:oor="http://openoffice.org/2001/registry" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
oor:package="org.openoffice.TypeDetection" oor:name="Filter">
         <node oor:name="Filters">

         <node oor:name="MOOX" oor:op="replace">
                 <prop oor:name="Flags"><value>IMPORT EXPORT TEMPLATE 
OWN ALIEN DEFAULT PREFERRED</value></prop>
                 <prop oor:name="UIComponent"/>
                 <prop oor:name="FilterService"/>
                 <prop 
oor:name="UserData"><value>CXML,Preprocess=&lt;vnd.sun.star.expand:/usr/bin/OdfConverter 
/DOCX2ODT /I %SOURCE% /O 
%TARGET%&gt;,Postprocess=&lt;vnd.sun.star.expand:/usr/bin/OdfConverter 
/ODT2DOCX /I %SOURCE% /O %TARGET%&gt;</value></prop>
                 <prop 
oor:name="FileFormatVersion"><value>6800</value></prop>
                 <prop oor:name="Type"><value>MOOXTYPE</value></prop>
                 <prop oor:name="TemplateName"/>
                 <prop 
oor:name="DocumentService"><value>com.sun.star.text.TextDocument</value></prop>
                 <prop oor:name="UIName">
                         <value xml:lang="x-default">Microsoft Word 2007 
Document</value>
                 </prop>
         </node>
         </node>
</oor:component-data>


MOOXTypeDetection.xcu:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE oor:component-data SYSTEM "../../../../component-update.dtd">
<oor:component-data xmlns:oor="http://openoffice.org/2001/registry" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
oor:package="org.openoffice.TypeDetection" oor:name="Types">
         <node oor:name="Types">
         <node oor:name="MOOXTYPE" oor:op="replace">
                 <prop oor:name="URLPattern"><value>*.docx 
*.DOCX</value></prop>
                 <prop oor:name="Extensions"><value>docx</value></prop>
                 <prop 
oor:name="MediaType"><value>application/vnd.openxmlformats-officedocument.wordprocessingml.document</value></prop>
                 <prop oor:name="Preferred"><value>false</value></prop>
                 <prop oor:name="PreferredFilter"><value>MOOX</value></prop>
                 <prop oor:name="UIName">
                         <value xml:lang="x-default">Microsoft Word 2007 
Document</value>
                 </prop>
                 <prop 
oor:name="ClipboardFormat"><value>doctype:wordDocument</value></prop>
         </node>
         </node>
</oor:component-data>

-- 
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 mclasen at redhat.com  Mon Oct 27 22:48:56 2008
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 27 Oct 2008 18:48:56 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
Message-ID: <1225147736.5763.7.camel@localhost.localdomain>

On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
> Hi folks,
> 
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
> 
> X HAS MOVED FROM VT7 TO VT1.
> 
> GDM specifically starts X on tty1, and upstart does not start a getty on
> tty1 in runlevel 5. 
> 

One consequence that is worth pointing out is that there is nothing on
vt7 now. Some people seemed to expect a getty there, but that is not the
case. 



From dr.diesel at gmail.com  Mon Oct 27 22:48:15 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Mon, 27 Oct 2008 18:48:15 -0400
Subject: ERROR with rpm_check_debug vs depsolve
Message-ID: <2a28d2ab0810271548g430e8671pca7ab964a39c0e08@mail.gmail.com>

Couldn't find it on Bugzilla, do I need to report this?  10/27/08 Rawhide.

Thanks
Andy


Transaction Summary
=======================================================================================================================
Install      7 Package(s)
Update     117 Package(s)
Remove       0 Package(s)

Total size: 272 M
Downloading Packages:
Downloading DeltaRPMs:
Rebuilding rpms from deltarpms
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
libdb-4.3.so is needed by (installed) cyrus-sasl-lib-2.1.22-18.fc10.i386
libdb-4.5.so is needed by (installed) rpm-libs-4.6.0-0.rc1.3.i386
libdb-4.5.so is needed by (installed) rpm-4.6.0-0.rc1.3.i386
libdb-4.5.so is needed by (installed) rpm-devel-4.6.0-0.rc1.3.i386
libdb-4.5.so is needed by (installed) rpm-build-4.6.0-0.rc1.3.i386
libdb-4.3.so is needed by (installed) cyrus-sasl-lib-2.1.22-18.fc10.i386
libdb-4.5.so is needed by (installed) rpm-libs-4.6.0-0.rc1.3.i386
libdb-4.5.so is needed by (installed) rpm-4.6.0-0.rc1.3.i386
libdb-4.5.so is needed by (installed) rpm-devel-4.6.0-0.rc1.3.i386
libdb-4.5.so is needed by (installed) rpm-build-4.6.0-0.rc1.3.i386
Complete!
(1, [u'Please report this error in bugzilla'])
[root at localhost ~]#


-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/284a564f/attachment.htm>

From skvidal at fedoraproject.org  Mon Oct 27 23:00:36 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 27 Oct 2008 19:00:36 -0400
Subject: ERROR with rpm_check_debug vs depsolve
In-Reply-To: <2a28d2ab0810271548g430e8671pca7ab964a39c0e08@mail.gmail.com>
References: <2a28d2ab0810271548g430e8671pca7ab964a39c0e08@mail.gmail.com>
Message-ID: <1225148436.8033.61.camel@rosebud>

On Mon, 2008-10-27 at 18:48 -0400, Dr. Diesel wrote:
> Couldn't find it on Bugzilla, do I need to report this?  10/27/08
> Rawhide.
> 
> Thanks
> Andy


yum 3.2.20 should have finished in rawhide
please test that before bugzilla'ing

if it is still bad then bz.

thank you

-sv




From dr.diesel at gmail.com  Mon Oct 27 23:31:20 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Mon, 27 Oct 2008 19:31:20 -0400
Subject: ERROR with rpm_check_debug vs depsolve
In-Reply-To: <1225148436.8033.61.camel@rosebud>
References: <2a28d2ab0810271548g430e8671pca7ab964a39c0e08@mail.gmail.com>
	<1225148436.8033.61.camel@rosebud>
Message-ID: <2a28d2ab0810271631i389eae36l4748fb0ffe8111e2@mail.gmail.com>

On Mon, Oct 27, 2008 at 7:00 PM, seth vidal <skvidal at fedoraproject.org>wrote:

> On Mon, 2008-10-27 at 18:48 -0400, Dr. Diesel wrote:
> > Couldn't find it on Bugzilla, do I need to report this?  10/27/08
> > Rawhide.
> >
> > Thanks
> > Andy
>
>
> yum 3.2.20 should have finished in rawhide
> please test that before bugzilla'ing
>
> if it is still bad then bz.
>
> thank you
>
> -sv


I'll bz it, this is with yum-3.2.20-1.fc10.noarch.

Thanks!

Packages skipped because of dependency problems:
    compat-db45-4.5.20-5.fc10.i386 from rawhide
    rpm-4.6.0-0.rc1.5.i386 from rawhide
    rpm-build-4.6.0-0.rc1.5.i386 from rawhide
    rpm-devel-4.6.0-0.rc1.5.i386 from rawhide
    rpm-libs-4.6.0-0.rc1.5.i386 from rawhide
    rpm-python-4.6.0-0.rc1.5.i386 from rawhide

Dependencies Resolved
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 229, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 181, in main
    return_code = base.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 356, in doTransaction
    self.listTransaction())
  File "/usr/share/yum-cli/output.py", line 797, in listTransaction
    evr = txmbr.po.printVer()
  File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 149, in
__getattr__
    raise KeyError, str(e)
KeyError: 'no such column: po'
[root at localhost ~]#




-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/a81c9a27/attachment.htm>

From dr.diesel at gmail.com  Mon Oct 27 23:37:13 2008
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Mon, 27 Oct 2008 19:37:13 -0400
Subject: ERROR with rpm_check_debug vs depsolve
In-Reply-To: <2a28d2ab0810271631i389eae36l4748fb0ffe8111e2@mail.gmail.com>
References: <2a28d2ab0810271548g430e8671pca7ab964a39c0e08@mail.gmail.com>
	<1225148436.8033.61.camel@rosebud>
	<2a28d2ab0810271631i389eae36l4748fb0ffe8111e2@mail.gmail.com>
Message-ID: <2a28d2ab0810271637i56e87f30n5939cbb89ed72e4b@mail.gmail.com>

On Mon, Oct 27, 2008 at 7:31 PM, Dr. Diesel <dr.diesel at gmail.com> wrote:

>
>
> On Mon, Oct 27, 2008 at 7:00 PM, seth vidal <skvidal at fedoraproject.org>wrote:
>
>> On Mon, 2008-10-27 at 18:48 -0400, Dr. Diesel wrote:
>> > Couldn't find it on Bugzilla, do I need to report this?  10/27/08
>> > Rawhide.
>> >
>> > Thanks
>> > Andy
>>
>>
>> yum 3.2.20 should have finished in rawhide
>> please test that before bugzilla'ing
>>
>> if it is still bad then bz.
>>
>> thank you
>>
>> -sv
>
>
> I'll bz it, this is with yum-3.2.20-1.fc10.noarch.
>
> Thanks!
>
> Packages skipped because of dependency problems:
>     compat-db45-4.5.20-5.fc10.i386 from rawhide
>     rpm-4.6.0-0.rc1.5.i386 from rawhide
>     rpm-build-4.6.0-0.rc1.5.i386 from rawhide
>     rpm-devel-4.6.0-0.rc1.5.i386 from rawhide
>     rpm-libs-4.6.0-0.rc1.5.i386 from rawhide
>     rpm-python-4.6.0-0.rc1.5.i386 from rawhide
>
> Dependencies Resolved
> Traceback (most recent call last):
>   File "/usr/bin/yum", line 29, in <module>
>     yummain.user_main(sys.argv[1:], exit_code=True)
>   File "/usr/share/yum-cli/yummain.py", line 229, in user_main
>     errcode = main(args)
>   File "/usr/share/yum-cli/yummain.py", line 181, in main
>     return_code = base.doTransaction()
>   File "/usr/share/yum-cli/cli.py", line 356, in doTransaction
>     self.listTransaction())
>   File "/usr/share/yum-cli/output.py", line 797, in listTransaction
>     evr = txmbr.po.printVer()
>   File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 149, in
> __getattr__
>     raise KeyError, str(e)
> KeyError: 'no such column: po'
> [root at localhost ~]#
>
>
 FYI:

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

-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081027/90decc61/attachment.htm>

From crobinso at redhat.com  Tue Oct 28 02:04:20 2008
From: crobinso at redhat.com (Cole Robinson)
Date: Mon, 27 Oct 2008 22:04:20 -0400
Subject: Virt* , s-c-display ,desktop-effects - Translation submission
 issues!
In-Reply-To: <49055B15.1070507@redhat.com>
References: <48FEF504.8030606@redhat.com> <49055B15.1070507@redhat.com>
Message-ID: <49067324.9000908@redhat.com>

Noriko Mizumoto wrote:
> Hi
>
> It is one day to go for Final Development freeze, 28-Oct.
> Could you please please check the following bugs and include all
> translation submitted against?
>
> It is highly appreciated if the comment is added in the bug when done.
>
>
>>
>> [virt-manager]
>> https://bugzilla.redhat.com/show_bug.cgi?id=467808
> Hi Cole,
> 12 languages translation attached as of 27-Oct, 04:00 UTC time.
> There are some languages attached after Translation Deadline of 21-Oct.
> Is any chance that those can be included?
>
>
>>
>> [virt-inst]
>> https://bugzilla.redhat.com/show_bug.cgi?id=467810
> Hi Cole,
> 2 languages translation attached as of 27-Oct, 04:00 UTC time.
> Could you confirm if those have been included?
>
>

These were built earlier today, FYI.

Thanks,
Cole



From jreiser at BitWagon.com  Tue Oct 28 02:55:25 2008
From: jreiser at BitWagon.com (John Reiser)
Date: Mon, 27 Oct 2008 19:55:25 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225144454.3523.59.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<49063063.8050802@BitWagon.com>
	<1225144454.3523.59.camel@metroid.rdu.redhat.com>
Message-ID: <49067F1D.8010405@BitWagon.com>

>> I'm running today's rawhide, but I still see X11 on vty7 (Ctrl-Alt-F7),
>> init log on vty1, and text login on vty2 through vty6.
> 
> Are you running GDM as your display manager? It's on tty1 on my system -
> same gdm / xinit versions as you. When was the last time you rebooted?

A reboot brought up gdm on vty1.

>> The anaconda-11.4.1.51 installer also runs X11 on vty7, with anaconda "console"
>> on vty1, shell on vty2, various logs on vty3 through vty5, and "No signal" on vty6.
> 
> You're correct; this information does not apply to anaconda. (At least
> not yet.)
> 
> One thing though: Anaconda typically runs X on tty6. 
> 
> tty1: console
> tty2: shell
> tty3: anaconda.log
> tty4: syslog
> tty5: redirected output from commands run by anaconda
> tty6: X
> 
> Not sure why it would show up as tty7 on your system.

Perhaps because of "blank graphical welcome screen for DVD install"
which is  https://bugzilla.redhat.com/show_bug.cgi?id=466370

I see vty1-5 as above, "No signal" on vty6.  vty7 has a blank screen
except for a blinking underline text cursor in the upper left corner.

-- 



From james at fedoraproject.org  Tue Oct 28 04:36:01 2008
From: james at fedoraproject.org (James Antill)
Date: Tue, 28 Oct 2008 00:36:01 -0400
Subject: ERROR with rpm_check_debug vs depsolve
In-Reply-To: <2a28d2ab0810271637i56e87f30n5939cbb89ed72e4b@mail.gmail.com>
References: <2a28d2ab0810271548g430e8671pca7ab964a39c0e08@mail.gmail.com>
	<1225148436.8033.61.camel@rosebud>
	<2a28d2ab0810271631i389eae36l4748fb0ffe8111e2@mail.gmail.com>
	<2a28d2ab0810271637i56e87f30n5939cbb89ed72e4b@mail.gmail.com>
Message-ID: <1225168561.1483.27.camel@code.and.org>

On Mon, 2008-10-27 at 19:37 -0400, Dr. Diesel wrote:
> 
[...]
>         
>           File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py",
>         line 149, in __getattr__
>             raise KeyError, str(e)
>         KeyError: 'no such column: po'
>         [root at localhost ~]# 
>          

>  FYI:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=468785

 Thanks, that should be fixed for the rawhide tomorrow (and, yes 3.2.20
fixes the original problem :).

-- 
James Antill <james at fedoraproject.org>
Fedora



From kevin.kofler at chello.at  Tue Oct 28 04:52:46 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 28 Oct 2008 04:52:46 +0000 (UTC)
Subject: Need a build chain in koji, not a chainbuild [URGENT]
References: <1225100083.3813.28.camel@wicktop.localdomain>
Message-ID: <loom.20081028T045205-350@post.gmane.org>

Christoph Wickert <christoph.wickert <at> googlemail.com> writes:
> This has become even worse with immutable tags (although I understand the
> need for immutable tags).

Tags are not really immutable, "make tag TAG_OPTS=-F" has been reenabled.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Oct 28 04:54:12 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 28 Oct 2008 04:54:12 +0000 (UTC)
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<jhvdvg8can.fsf@allele2.eebweb.arizona.edu>
	<v5r6648buq.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0810270747w5dc35031w22cecd469a95e113@mail.gmail.com>
	<9zvdve5b18.fsf@allele2.eebweb.arizona.edu>
Message-ID: <loom.20081028T045349-171@post.gmane.org>

Alex Lancaster <alexl <at> users.sourceforge.net> writes:
> Thanks for filing the bug.  The patch doesn't apply in any case.
> Nevertheless, it would be good to pester the maintainer of the
> gnome-python2-extras and help him look into it, given that it was your
> soname bump of libgdl that caused the problem in the first place. :)

The gnome-python2-extras maintainer got it to build.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Oct 28 04:55:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 28 Oct 2008 04:55:44 +0000 (UTC)
Subject: what QA gets mailed to the packagers?
References: <20081025110430.GC2608@free.fr>
	<1225122554.2157.4.camel@luminos.localdomain>
Message-ID: <loom.20081028T045444-364@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> This got lost at some point, and I have some scripts I'm working on to
> bring them back.  The difficult part is deciding how to appropriately
> code the relationship of say f8 updates testing to f9 updates and such.

My patch for that is still out there:
http://repo.calcforge.org/f10/check-upgrade-paths.py.diff

        Kevin Kofler



From kevin.kofler at chello.at  Tue Oct 28 06:01:55 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 28 Oct 2008 06:01:55 +0000 (UTC)
Subject: FYI: libical 0.40 moves libicalvcal headers
Message-ID: <loom.20081028T055601-265@post.gmane.org>

Hi,

I just built libical 0.40 for F10 (discussed with the libical maintainer 
already). Rationale:
* should be fully API- and ABI-compatible (same sonames),
* at least 0.33 will be required to build KDE 4.2 (F10 currently has only 
0.32), so upstream KDE developers who work on Fedora have asked us to build a 
newer version so they can keep working on KDE development on Fedora,
* having a version >= 0.33 also allows us to build kdepimlibs 4.1.2 against the 
system libical (with a patch).

There is, however, one minor change: the libicalvcal headers are now 
under /usr/include/libical along with the other libical headers, 
not /usr/include/libicalvcal as they used to. It is possible to make 
compatibility symlinks (of the individual files, not the directory, replacing 
directories with symlinks is a big no-no with RPM), so should we add them? Or 
does this change not affect any package anyway?

        Kevin Kofler



From rc040203 at freenet.de  Tue Oct 28 07:40:55 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 08:40:55 +0100
Subject: FC9: mock -r fedora-rawhide-i386 init fails
Message-ID: <1225179655.3897.38.camel@beck.corsepiu.local>

Hi,

Since this morning, initializing fedora-rawhide-i386 mock chroots fail
for me on FC9:

# mock -r fedora-rawhide-i386 init
INFO: mock.py version 0.9.9 starting...
...
ERROR: Command failed: 
 # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-i386/root/
groupinstall buildsys-build
...
/bin/sh: error while loading shared libraries: libtinfo.so.5: cannot
open shared object file: No such file or directory
error: %post(bash-3.2-28.fc10.i386) scriptlet failed, exit status 127
...


I am able to reproduce this error on different fedora-9-i386 and
fedora-9-x86_64 machines.

For whatever reason, so far, on fedora-9-x86_64, "mock -r
fedora-rawhide-x86_64 init" doesn't fail, nor have I encountered this
error on a fedora-rawhide-i386/fedora-9.92-i386 test-machine.

Ralf




From kanarip at kanarip.com  Tue Oct 28 08:52:17 2008
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Tue, 28 Oct 2008 09:52:17 +0100
Subject: R-devel going away
In-Reply-To: <1224772939.3601.54.camel@localhost.localdomain>
References: <1224770108.3601.40.camel@localhost.localdomain>	<87mygvcrd0.fsf@fc5.bigo.ensc.de>
	<1224772939.3601.54.camel@localhost.localdomain>
Message-ID: <4906D2C1.9060107@kanarip.com>

Tom "spot" Callaway wrote:
> On Thu, 2008-10-23 at 16:34 +0200, Enrico Scholz wrote:
>> Better solutions:
>>
>> * add it to comps.xml
>> * move 'R' to R-core, and add 'R' which depends on 'R-core' +
>> 'R-devel'
>>
>>
>>> * The size of the R-devel is tiny, about 440K installed.
>> You miss its dependencies:
>>
>> (...snip...)
> 
> These are very good points, thanks Enrico. What would people think about
> doing the suggested R/R-core/R-devel split instead? Users would still be
> able to get everything with yum install R, it would meet the guidelines,
> and minimal installs with R can simply have R-core.
> 

Big-time R user and I like this plan. +1

Kind regards,

Jeroen van Meeuwen
-kanarip



From pertusus at free.fr  Tue Oct 28 09:10:32 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 28 Oct 2008 10:10:32 +0100
Subject: R-devel going away
In-Reply-To: <49032778.2080800@redhat.com>
References: <1224770108.3601.40.camel@localhost.localdomain>
	<49032778.2080800@redhat.com>
Message-ID: <20081028091032.GB2674@free.fr>

On Sat, Oct 25, 2008 at 10:04:40AM -0400, Warren Togami wrote:
>
> Isn't this exactly counter to the logic behind splitting perl into  
> perl-devel, that ended up angering jpo to the point of him quitting 
> Fedora?

Not exactly, since the split in R-devel would still be there. R would be
for end users, but for packagers, this package should not be used. 

There is another difference, it is that cpan is not in perl-devel, but
requires perl-devel.

> The rest of this explanation seems to make sense.  But does this mean we  
> make a mistake earlier in the perl split?

I don't remember anybody making the same proposal. But I guess that it
could be doable to do the same for perl, although more tricky. Maybe the
perl meta package could be perl-core + cpan.

--
Pat



From pbrobinson at gmail.com  Tue Oct 28 09:50:36 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 28 Oct 2008 09:50:36 +0000
Subject: [Off topic] Codeweavers giving away free licenses
Message-ID: <5256d0b0810280250w272723cat2b07989e4c35fc4b@mail.gmail.com>

This I realise is somewhat off topic but as it may allow people to
move from that other OS to Fedora I thought there were some links :-)

Codeweavers is giving away Crossover Linux Pro today due to a
challenge their CEO issued to the US President.

http://lameduck.codeweavers.com/

Enjoy for those that are interested, apologies to those that aren't

Peter



From dan at danny.cz  Tue Oct 28 09:54:30 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 28 Oct 2008 10:54:30 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
Message-ID: <1225187670.5969.6.camel@localhost.localdomain>

Will Woods p??e v Po 27. 10. 2008 v 17:07 -0400:
> Hi folks,
> 
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
> 
> X HAS MOVED FROM VT7 TO VT1.
> 
> GDM specifically starts X on tty1, and upstart does not start a getty on
> tty1 in runlevel 5. 
> 

How can I disable this "feature"? I really do not want change my habits
after 10+ years with X on vt7.

> Other display managers might need to be changed to match (or they might
> Just Work since tty1 will be the first unused tty). 
> 
> If you maintain one of the other display managers, it would be good to
> make sure that your packages do the right thing.


		Dan




From rawhide at fedoraproject.org  Tue Oct 28 10:02:58 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 28 Oct 2008 10:02:58 +0000 (UTC)
Subject: rawhide report: 20081028 changes
Message-ID: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>

Compose started at Tue Oct 28 06:01:09 UTC 2008

New package cfdg
        Context Free Design Grammar
New package cryptopp
        Public domain C++ class library of cryptographic schemes
New package hamcrest
        Hamcrest matcher object framework
New package rubygem-main
        A class factory and dsl for generating command line programs real quick
New package rubygem-markaby
        Markup as Ruby, write HTML in your native Ruby tongue
New package rubygem-pervasives
        Access to pristine object state
New package rubygem-picnic
        Easier distribution of Camping-based applications
New package rubygem-reststop
        Convenient RESTfulness for all your Camping controller needs
New package sl
        Joke command for when you type 'sl' instead of 'ls'
New package smokeping
        Latency Logging and Graphing System
New package xvarstar
        XVarStar is an astronomical program used for searching GCVS
Removed package pguiman
Removed package ume-launcher
Updated Packages:

NetworkManager-0.7.0-0.11.svn4229.fc10
--------------------------------------
* Mon Oct 27 18:00:00 2008 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.11.svn4229
- More reliable mobile broadband card initialization
- Handle mobile broadband PINs correctly when PPP passwords are also used
- Additional PolicyKit integration for editing system connections
- Close the applet menu if a keyring password is needed (rh #353451)


NetworkManager-openvpn-0.7.0-16.svn4229.fc10
--------------------------------------------
* Mon Oct 27 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-16.svn4229
- Rebuild for updated NetworkManager


NetworkManager-pptp-0.7.0-0.11.svn4229.fc10
-------------------------------------------
* Mon Oct 27 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-11.svn4229
- Rebuild for updated NetworkManager
- Ensure that certain PPP options are always overriden


NetworkManager-vpnc-0.7.0-0.11.svn4229.fc10
-------------------------------------------
* Mon Oct 27 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-0.11.svn4229
- Rebuild for updated NetworkManager


PackageKit-0.3.9-1.fc10
-----------------------
* Mon Oct 27 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-1
- New upstream version
- Many new and updated translations.
- Lots of bugfixes (#468486, #466006, #468602), no new features.


R-Biobase-2.2.0-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 2.2.0-1
- Update to version 2.2.0 for R >= 2.8.0


R-DynDoc-1.20.0-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.20.0-1
- Update to version 1.20.0 for R >= 2.8.0


R-affyio-1.10.0-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.10.0-1
- Update to version 1.10.0 for R >= 2.8.0


R-maanova-1.12.0-1.fc10
-----------------------
* Mon Oct 27 18:00:00 2008 Pingou <pingoufc4 at yahoo.fr> 1.12.0-1
- Update to 1.12.0 for R >= 2.8.0


R-multtest-1.22.0-1.fc10
------------------------
* Mon Oct 27 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.22.0-1
- New version 1.22.0 for R >= 2.8.0

* Wed Jun 25 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.20.0-3
- change the url


R-qvalue-1.16.0-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.16.0-1
- Update to version 1.16.0

* Wed Jun 25 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.14.0-3
- Change the url


R-tkWidgets-1.20.0-1.fc10
-------------------------
* Mon Oct 27 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.20.0-1
- Update to 1.20.0 for R >= 2.8.0

* Wed Jun 25 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.18.0-2
- Change urls


R-widgetTools-1.18.0-1.fc10
---------------------------
* Mon Oct 27 18:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 1.18.0-1
- Update to version 1.18.0 for R >= 2.8.0


Terminal-0.2.8.3-1.fc10
-----------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.2.8.3-1
- Update to 0.2.8.3
- BuildRequire intltool
- Fix rpm group


amsn-0.97.2-1.fc10
------------------
* Mon Oct 27 18:00:00 2008 Sander Hoentjen <sander at hoentjen.eu> - 0.97.2-1
- Update to latest release


anaconda-11.4.1.52-1
--------------------
* Mon Oct 27 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.52-1
- Let DNS lookups work from %post scripts (#468132) (dcantrell)
- Do not use /.tmp for temporary files (#468720) (dcantrell)
- Don't treat encrypted PVs as available if we don't have the key. (#465240)
  (dlehman)
- Do all new device passphrase prompting from partitioningComplete. (dlehman)
- Fix the obviously stupid typo. (clumens)
- There's a new version of the firewall command for F10 (#467753). (clumens)
- Another fix for printing package summaries in text mode (#468283).
  (clumens)
- Fix traceback in network.bringUp() (#468651) (dcantrell)
- lvresize requires a --force arg now (#468478) (katzj)
- Include return code on resize failure error message (#468479) (katzj)


aqsis-1.4.1-4.fc10
------------------
* Tue Oct 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.4.1-4
- Add Requires(post/preun): xdg-utils


ardour-2.6.1-1.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Anthony Green <green at redhat.com> 2.6.1-1
- New upstream release 2.6.1.


audit-1.7.8-5.fc10
------------------
* Mon Oct 27 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.8-5
- Fix ausearch/report recent and now time keyword lookups (#468668)


banshee-1.2.1-3.fc10
--------------------
* Tue Oct 28 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.2.1-3
- bump for new gnome-sharp


beagle-0.3.8-9.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.3.8-9
- rebuild against new gnome-sharp


blam-1.8.5-3.fc10
-----------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.8.5-3
- rebuild against new gnome-sharp


bluez-4.17-2.fc10
-----------------
* Mon Oct 27 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 4.17-2
- Own /var/lib/bluetooth (#468717)


cairo-dock-1.6.3-0.3.rc1.fc10
-----------------------------
* Tue Oct 28 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.6.3-0.3.rc1
- 1.6.3 rc1


catfish-0.3.2-1.fc10
--------------------
* Tue Oct 28 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> 0.3.2-1
- 0.3.2


cdcollect-0.6.0-6.fc10
----------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 0.6.0-6
- rebuild for new gnome-sharp


cjet-0.8.9-7.fc10
-----------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.8.9-7
- Fix Patch0:/%patch mismatch.


compiz-0.7.6-17.fc10
--------------------
* Mon Oct 27 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 0.7.6-17
- Update some translations for the desktop-effects capplet


desktop-backgrounds-9.0.0-4
---------------------------
* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> 9.0.0-4
- Make compat subpackage depend on solar backgrounds
  (bug 468749)


eclipse-pydev-1.3.24-1.fc10
---------------------------
* Mon Oct 27 18:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 1:1.3.24-1
- 1.3.24


exo-0.3.4-3.fc10
----------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.3.4-3
- Add two Debian patches to fix broken regex and gcc_hardening
- Fix rpm group
- Update gtk-update-icon-cache scriptlets
- Configure with --disable-static


f-spot-0.4.4-6.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.4.4-6
- rebuild against new gnome-sharp


festival-1.96-6.fc10
--------------------
* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 1.96-6
- interoperate with other apps by using pacat for audio output
  (bug 467531)


fig2sxd-0.20-1.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.20-1
- bump to latest version


firstboot-1.102-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 Chris Lumens <clumens at redhat.com> 1.102-1
- Be smarter about finding a graphics theme to use.


frysk-0.4-2.fc10
----------------
* Mon Oct 27 18:00:00 2008 Andrew Cagney <andrew.cagney at gmail.com> -  0.4-2
- drop EPL from licence list; cdtparser deleted
- re-enable SMP make
- disable -Werror flag to gcj

* Mon Oct 20 18:00:00 2008 Andrew Cagney <andrew.cagney at gmail.com> -  0.4-1
- add sparc and arm to ExcludeArch.


gbrainy-1.00-2.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.00-2
- rebuild for new gnome-sharp


generic-logos-10.0.0-3.fc10
---------------------------
* Mon Oct 27 18:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> - 10.0.0-3
- Solar Comet generic splash logo redesign


gftp-2.0.18-4.fc10
------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2:2.0.18-4
- fix bookmarks (bz 463006)


glib2-2.18.2-3.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.18.2-3
- Use asm implementation for atomic ops on x86


gnome-build-2.24.1-1.fc10
-------------------------
* Tue Oct 28 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 2.24.1-1
- Version bump to 2.24.1.
- Configure script problems fixed by upstream. Closes GNOME Bugzilla bug


gnome-desktop-2.24.1-3.fc10
---------------------------
* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-3
- Don't leak memory when crossfading if nautilus is disabled
  (bug 468339)


gnome-desktop-sharp-2.24.0-3.fc10
---------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.24.0-3
- and BR: libgnomeprintui22-devel

* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.24.0-2
- add gnome-sharp-devel as BuildRequires

* Thu Oct 16 18:00:00 2008 Dan Winship <dwinship at redhat.com> - 2.24.0-1
- Update to 2.24.0


gnome-do-0.6.1.0-2.fc10
-----------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.6.1.0-2
- rebuild against new gnome-sharp


gnome-lirc-properties-0.3.1-1.fc10
----------------------------------
* Mon Oct 27 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.1-1
- Update to 0.3.1

* Mon Oct 27 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.0-5
- Fix chkconfig not being called to auto-start lirc in some cases

* Mon Oct 27 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.0-4
- Fix USB hiddev devices causing backtraces

* Mon Oct 27 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.3.0-3
- Don't detect power buttons


gnome-packagekit-0.3.9-4.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-4
- Barr. Actually apply the patch. Sleep time.

* Mon Oct 27 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-3
- Fix the size request of gpk-application to fix rh#467987

* Mon Oct 27 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-2
- Split out the service pack creator and the backend status programs
  into a gnome-packagekit-extra package as it's not suitable for the
  default desktop.

* Mon Oct 27 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-1
- New upstream version
- Many new and updated translations.
- Lots of bugfixes (#467746, #467582)


gnome-python2-extras-2.19.1-23.fc10
-----------------------------------
* Mon Oct 27 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-23
- Give us --force-tag back.

* Mon Oct 27 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-22
- Fix build break with libgdl-2.24.0 (GNOME bug #553911).
- Bump libgdl_version to 2.24.0.

* Mon Oct 27 18:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-21
- Provide Python bindings for libgdl on ppc64 (RH bug #468693).


gnome-sharp-2.24.0-1.fc10
-------------------------
* Thu Oct 16 18:00:00 2008 Dan Winship <dwinship at redhat.com> - 2.24.0-1
- Update to 2.24.0


gnome-subtitles-0.8-6.fc10
--------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.8-6
- don't use smp_mflags

* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.8-5
- rebuild against new gnome-sharp


gssdp-0.6.3-1.fc10
------------------
* Mon Oct 27 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.6.3-1
- New upstream version


gtk-sharp-1.0.10-20.fc10
------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.10-20
- fix gtkhtml check for rawhide
- BR: libgnomeprintui22-devel

* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.10-19
- add missing BR: gnome-desktop-sharp

* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.10-18
- rebuild for new gnome-sharp

* Fri Jul 25 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.10-17
- fix license tag

* Wed May  7 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.0.10-16
- Removed ppc build for now

* Wed May  7 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.0.10-15
- added BR gnome-sharp-devel and vte-devel

* Wed May  7 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.0.10-14
- doh! forgot excludearch ppc64

* Tue May  6 18:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.0.10-13
- rebuild
- removed debug package


gtk-xfce-engine-2.4.3-1.fc10
----------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 2.4.3-1
- Update to 2.4.3
- Require filesystem package instead of owning %{_datadir}/themes
- Don't own %{_libdir}/gtk-2.0/2.10.0/engines/


gtksourceview-sharp-2.0.12-6.fc10
---------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0-0.12-6
- rebuild for new gnome-sharp


gupnp-0.12.3-1.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Peter Robinson <pbrobinson at gmail.com> 0.12.3-1
- New upstream release


gurlchecker-0.10.1-10.fc10
--------------------------
* Tue Oct 28 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.10.1-10
- rebuild for clamav 0.94


hal-0.5.12-8.20081027git.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-8.20081027git
- Update to git snapshot 20081027git to fix #468692


iml-1.0.2-4.fc10
----------------
* Mon Oct 27 18:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 1.0.2-4
- Oops, don't depend on the main package which no longer exists in -devel.


imsettings-0.105.1-2.fc10
-------------------------
* Mon Oct 27 18:00:00 2008 Akira TAGOH <tagoh at redhat.com> - 0.105.1-2
- imsettings-fix-unpredictable-session-order.patch: Run imsettings-applet with
  --disable-xsettings for GNOME/XFCE. (#466206)


jd-2.0.3-0.1.svn2423_trunk.fc10
-------------------------------
* Tue Oct 28 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2423


junit4-4.5-3.1.fc10
-------------------
* Mon Oct 20 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:4.5-3.1
- build for Fedora

* Mon Oct 20 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:4.5-3
- reorder %files list

* Mon Oct 20 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:4.5-2
- fix GCJ support
- fix javadoc symlink

* Mon Oct 20 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:4.5-1
- 4.5


kde-settings-4.1-2.fc10
-----------------------
* Mon Oct 27 18:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 4.1-2
- Fedoraproject homepages for Konqueror


kernel-2.6.27.4-58.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- fix rs4xx bus mastering.

* Tue Oct 28 18:00:00 2008 Dave Airlie <airlied at redhat.com>
- add support for wait rendering API

* Mon Oct 27 18:00:00 2008 Jeremy Katz <katzj at redhat.com>
- Make olpc-battery built in so that its usable (#467759)

* Mon Oct 27 18:00:00 2008 Eric Sandeen <sandeen at redhat.com>
- Delay capable() checks in ext4 until necessary. (#467216)

* Mon Oct 27 18:00:00 2008 Dave Jones <davej at redhat.com>
- ACPI: Ignore the RESET_REG_SUP bit when using ACPI reset mechanism. (461228)

* Mon Oct 27 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.4-52
- drm-modesetting-radeon.patch - fix some kms issues + add better CS scheme


klamav-0.44-3.fc10
------------------
* Tue Oct 28 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.44-3
- rebuild for clamav 0.94
- add klamav-clamav094.patch from Gentoo


koffice-1.6.3-17.fc10
---------------------
* Mon Oct 27 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1:1.6.3-17
- move libkiviocommon to -kivio (avoids libpython/multilib issues)


lat-1.2.3-4.fc10
----------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.2.3-4
- rebuild for new gnome-sharp


lazarus-0.9.26-1.fc10
---------------------
* Thu Oct 23 18:00:00 2008 Joost van der Sluis <joost at cnoc.nl> 0.9.26-1
- Updated to version 0.9.26
- Removed scripts which are vulnerable to symlink-attacks (bug 460642)
- Build bigide instead of the standard ide
- Build ideintf and the registration for gtk2
- Install the manfiles 
- Install the mime-types
- Install the global .xml configuration files


lcms-1.17-6.fc10
----------------
* Tue Oct 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.17-6
- Add lcms-fix_s390_lcms_h.patch - Fix #468245


libasyncns-0.7-1.fc10
---------------------
* Tue Oct 28 18:00:00 2008 Lennart Poettering <lpoetter at redhat.com> 0.7-1
- New release


libcaca-0.99-0.5.beta16.fc10
----------------------------
* Mon Oct 27 18:00:00 2008 Matthias Saou <http://freshrpms.net/> 0.99-0.5.beta16
- Update to 0.99beta16.
- Update Source URL.


libgda-3.1.2-6.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Denis Leroy <denis at poolshark.org> - 1:3.1.2-6
- Added patch to fix providers path on x86_64 (#468510)


libgdl-2.24.0-2.fc10
--------------------
* Tue Oct 28 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 2.24.0-2
- Updated Source0 URL.


libical-0.40-1.fc10
-------------------
* Tue Oct 28 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.40-1
- Update to 0.40.
- Add patch from upstream to fix crash in icalvalue.c.
- Update makefile patch, remove the test part (already applied).
- Package libical.pc, add Requires: pkgconfig to -devel.


libtirpc-0.1.9-6.fc10
---------------------
* Mon Oct 27 18:00:00 2008 Steve Dickson  <steved at redhat.com> 0.1.8-6
- Fix bad assumption taddr2uaddr processing that 
  caused a segfault (bz468014)


libv4l-0.5.3-1.fc10
-------------------
* Mon Oct 27 18:00:00 2008 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.3-1
- New upstream release 0.5.3


libxfce4mcs-4.4.3-1.fc10
------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- Fix rpm group of base package


libxfce4util-4.4.3-1.fc10
-------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3


libxfcegui4-4.4.3-1.fc10
------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3


linuxwacom-0.8.0.3-4.fc10
-------------------------
* Tue Oct 28 18:00:00 2008 Peter Hutterer <peter.hutterer at redhat.com> 0.8.0.3-4
- 10-linuxwacom.fdi: specify "stylus" as default type. (#465349)


mail-notification-5.4-4.fc10
----------------------------
* Mon Oct 27 18:00:00 2008 Dmitry Butskoy <Dmitry at Butskoy.name> - 5.4-4
- fix plugin permissions (#468524)


mkinitrd-6.0.68-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.68-1
- Add buslogic and mptbase to "stabilized" module list.
- load crc32c module for iscsistart (hansg)
  Resolves: rhbz#467379
- Don't run findstoragedriverinsys twice for the same device (hansg)
  Resolves: rhbz#467390
- Use iscsi session info for /, not the first one in "iscsiadm -m session"
  output (hasng)
  Resolves: rhbz#245645


mlocate-0.21.1-1
----------------
* Tue Oct 28 18:00:00 2008 Miloslav Trma?? <mitr at redhat.com> - 0.21.1-1
- Update to mlocate-0.21
  Resolves: #461208


mono-tools-2.0-8.fc10
---------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0-8
- rebuild for new gnome-sharp


mousepad-0.2.14-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.2.14-1
- Update to 0.2.14
- BuildRequire intltool
- Drop category X-Fedora from desktop file


nautilus-2.24.1-3.fc10
----------------------
* Mon Oct 27 18:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> - 2.24.1-3
- Updated XDS support in tree view patch (sync with gnomebz #171655)


nautilus-sound-converter-0.7.0-1.fc10
-------------------------------------
* Mon Oct 27 18:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.7.0-1
- Update to 0.7.0.


netlabel_tools-0.18-1.fc10
--------------------------
* Mon Oct 27 18:00:00 2008 Peter Vrabec <pvrabec at redhat.com> - 0.18-1
- upgrade (#439833)


netpbm-10.35.54-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 Jindrich Novy <jnovy at rehdat.com> 10.35.54-1
- update to 10.35.54
- adds better randomization for ppmforge, pgmnoise, pgmcrater
- fixes array bounds violation in pnm_createBlackTuple() with PBM, PGM
- fixes crash in pnmtoddif with any PGM input


ocaml-csv-1.1.7-1.fc10
----------------------
* Mon Oct 27 18:00:00 2008 Richard W.M. Jones <rjones at redhat.com> - 1.1.7-1
- New upstream version 1.1.7.


ochusha-0.5.99.67.1-0.4.cvs20081026T0316.fc10
---------------------------------------------
* Tue Oct 28 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.5.99.67.1-0.4.cvs20081023T0304
- Install ochusha-prefs-gtkrc to set default font
- ... and use wrapper script

* Tue Oct 28 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS

* Mon Oct 20 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.5.99.67.1-0.2.cvs20081020_1
- Upstream development restarted, try latest
- Use system-wide oniguruma
- Drop 2 patches (upstreamed)
- Also try to disable disable-lock-check.patch for trial
- Spec file clean up
- Move all libraries to %_libdir/%name, no need to make them system-wide,
  set rpath


pbm2l7k-990321-5.fc10
---------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 990321-5
- Fix Patch0:/%patch mismatch.


perl-Image-ExifTool-7.51-1.fc10
-------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 7.51-1
- update to 7.51


perl-Math-Random-MT-Auto-6.14-1.fc10
------------------------------------
* Mon Oct 27 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 6.14-1
- update to 6.14
- switch to inline req filtering


perl-Module-Versions-Report-1.06-1.fc10
---------------------------------------
* Mon Oct 27 18:00:00 2008 Chris Weyl <cweyl at alumni.drew.edu> 1.06-1
- update to 1.06


picviz-0.4-1.fc10
-----------------
* Mon Oct 27 18:00:00 2008 Tomas Heinrich <theinric at redhat.com> 0.4-1
- update to new upstream version


plymouth-0.6.0-0.2008.10.27.5.fc10
----------------------------------
* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.5
- Make "Solar" lock icon the same as the "Spinfinity" one.

* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.4
- Make plymouth-libs own /usr/lib/plymouth (bug 458071)

* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.3
- Default to "Solar" instead of "Spinfinity"

* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.2
- Don't set plymouth default plugin to text in %post

* Mon Oct 27 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.1
- Add Charlie patch to dither in lower color modes (bug 468276)


policycoreutils-2.0.57-6.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-6
- Add usermode-gtk requires


pykickstart-1.46-1.fc10
-----------------------
* Mon Oct 27 18:00:00 2008 Chris Lumens <clumens at redhat.com> - 1.46-1
- Add support for firewall --service (#467005).


python-virtinst-0.400.0-4.fc10
------------------------------
* Mon Oct 27 18:00:00 2008 Cole Robinson <crobinso at redhat.com> - 0.400.0-4.fc10
- Updated translations (bz 467810)
- Specific os entry for XP 64 (bz 467851)
- Disk pool 'dos' format fix


rhpl-0.218-1
------------
* Mon Oct 27 18:00:00 2008 Jeremy Katz <katzj at redhat.com> - 0.218-1
- Updated translations
- Write out all aspects of the keyboard to /etc/sysconfig/keyboard for ajax


rhythmbox-0.11.6-15.6002.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-15.r6002
- Update to rev 6002


rubygem-hoe-1.8.2-1.fc10
------------------------
* Mon Oct 27 18:00:00 2008 Darryl Pierce <dpierce at redhat.com> - 1.8.2-1
- Release 1.8.2 of Hoe.


rubygem-rake-0.8.3-1.fc10
-------------------------
* Mon Oct 27 18:00:00 2008 David Lutterkort <lutter at redhat.com> - 0.8.3-1
- Cleanup multiply listed files
- Set permissions in doc/, lib/ and test/ to 644


rubygem-zoom-0.4.1-4.fc10
-------------------------
* Mon Oct 27 18:00:00 2008 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.1-4
- Better way to set CFLAGS and create debuginfo rpm correctly


solar-kde-theme-0.1.10-1.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 Than Ngo <than at redhat.com> 0.1.9-2
- install screenshot in correct place

* Mon Oct 27 18:00:00 2008 Than Ngo <than at redhat.com> 0.1.9-1
- fix KDM/Wallpaper screenshot issue in KDM theme

* Mon Oct 27 18:00:00 2008 Than Ngo <than at redhat.com> 0.1.10-1
- fix layout issue


specspo-16-1
------------
* Mon Oct 27 18:00:00 2008 Stepan Kasal <skasal at redhat.com> - 16-1
- fix typo s/fromating/formatting/
- restore en_GB.po, which was replaced by es.po by mistake


subversion-1.5.4-3
------------------
* Mon Oct 27 18:00:00 2008 Joe Orton <jorton at redhat.com> 1.5.4-3
- update to 1.5.4


system-config-boot-0.2.21-3.fc10
--------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.2.21-3
- add Requires: usermode-gtk


system-config-date-1.9.32-2.fc10
--------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.9.32-2
- add Requires: usermode-gtk


system-config-firewall-1.2.12-2.fc10
------------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.2.12-2
- add Requires: usermode-gtk


system-config-lvm-1.1.4-3.1.fc10
--------------------------------
* Mon Oct 27 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 1.1.4-3.1
- Require usermode-gtk


system-config-network-1.5.92-3.fc10
-----------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 
- don't try to write out Description if vendor is NULL (bz 468355)
  (thanks to Kazunori Asayama)

* Mon Oct 27 18:00:00 2008 Matthias Clasen  <mclasen at redhat.com> 
- Require usermode-gtk


system-config-users-1.2.80-2.fc10
---------------------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.2.80-2
- add Requires: usermode-gtk


tomboy-0.12.0-5.fc10
--------------------
* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.12.0-5
- add BR: gnome-desktop-sharp-devel

* Mon Oct 27 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.12.0-4
- rebuild for new gnome-sharp

* Thu Oct 23 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 0.12.0-3
- Apply upstream patch to fix crasher when gnome-panel-devel
  isn't installed.


virt-manager-0.6.0-3.fc10
-------------------------
* Mon Oct 27 18:00:00 2008 Cole Robinson <crobinso at redhat.com> - 0.6.0-3.fc10
- Add dbus-x11 to Requires (bug 467886)
- Fedora translation updates (bug 467808)
- Don't add multiple sound devices if install fails
- Only popup volume path copy option on right click
- Fix a variable typo


weechat-0.2.6-5.fc10
--------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.2.6-5
- Fix Patch0:/%patch mismatch.


wqy-zenhei-fonts-0.8.34-0.cvs20081027.fc10
------------------------------------------
* Mon Oct 27 18:00:00 2008 Qianqian Fang <fangqq at gmail.com> 0.8.34-0.cvs20081027
- upstream new version prelease


xenner-0.46-3.fc10
------------------

xfce-mcs-manager-4.4.3-1.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- BuildRequire intltool


xfce-utils-4.4.3-1.fc10
-----------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- Prefer gnome-screensaver over xscreensaver if installed
- Make xflock4 check for running screensaver instead of installed ones
- Rework pulseaudio patch
- Configure with --disable-static
- Run gtk-update-icon-cache in %post and %postun


xfce4-appfinder-4.4.3-1.fc10
----------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- Update gtk-update-icon-cache scriptlets


xfce4-icon-theme-4.4.3-1.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- BuildRequire intltool


xfce4-panel-4.4.3-1.fc10
------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- Remove mailwatch-plugin from default panel config again
- BuildRequire intltool
- Update gtk-update-icon-cache scriptlets
- Fix BuildRoot tag


xfprint-4.4.3-1.fc10
--------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- BuildRequire intltool
- Update gtk-update-icon-cache scriptlets
- Configure with --disable-static


xfwm4-4.4.3-1.fc10
------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- Update gtk-update-icon-cache scriptlets


xfwm4-themes-4.4.3-1.fc10
-------------------------
* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- Require filesystem package instead of owning %{_datadir}/themes


xine-lib-1.1.15-3.fc10
----------------------
* Tue Oct 28 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 1.1.15-3
- rebuild for new libcaca


xorg-x11-drv-ati-6.9.0-34.fc10
------------------------------
* Tue Oct 28 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-34
- remove some left over debug

* Tue Oct 28 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-33
- add support for wait for rendering

* Mon Oct 27 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-32
- move to CS2 mechanism - using chunks to avoid multiple relocations
- add kernel requires about 2.6.27.4-52 for new CS mechanism


xorg-x11-server-1.5.2-10.fc10
-----------------------------

xulrunner-1.9.0.2-5.fc10
------------------------
* Mon Oct 27 18:00:00 2008 Christopher Aillon <caillon at redhat.com> 1.9.0.2-5
- Password manager fixes from upstream


yum-3.2.20-2.fc10
-----------------
* Mon Oct 27 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 3.2.20-1
- 3.2.20

* Mon Oct 27 18:00:00 2008 James Antill <james at fedoraproject.org> - 3.2.20-2
- Fix listTransaction for skipped packages.


Summary:
Added Packages: 11
Removed Packages: 2
Modified Packages: 130
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.i386 requires libgbf-widgets-1.so.1
	1:anjuta-2.4.2-1.fc10.i386 requires libgbf-1.so.1
	hamcrest-demo-1.1-5.1.fc10.i386 requires testng
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	system-config-audit-0.4.8-9.fc10.i386 requires audit-libs = 0:1.7.8-5



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.i386 requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.i386 requires libgbf-widgets-1.so.1
	1:anjuta-2.4.2-1.fc10.i386 requires libgbf-1.so.1
	1:anjuta-2.4.2-1.fc10.x86_64 requires libgdl-gnome-1.so.0()(64bit)
	1:anjuta-2.4.2-1.fc10.x86_64 requires libgbf-1.so.1()(64bit)
	1:anjuta-2.4.2-1.fc10.x86_64 requires libgbf-widgets-1.so.1()(64bit)
	hamcrest-demo-1.1-5.1.fc10.x86_64 requires testng
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	system-config-audit-0.4.8-9.fc10.x86_64 requires audit-libs = 0:1.7.8-5



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc requires libgdl-gnome-1.so.0
	1:anjuta-2.4.2-1.fc10.ppc requires libgbf-widgets-1.so.1
	1:anjuta-2.4.2-1.fc10.ppc requires libgbf-1.so.1
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgbf-1.so.1()(64bit)
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgbf-widgets-1.so.1()(64bit)
	hamcrest-demo-1.1-5.1.fc10.ppc requires testng
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	system-config-audit-0.4.8-9.fc10.ppc requires audit-libs = 0:1.7.8-5



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgdl-gnome-1.so.0()(64bit)
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgbf-1.so.1()(64bit)
	1:anjuta-2.4.2-1.fc10.ppc64 requires libgbf-widgets-1.so.1()(64bit)
	hamcrest-demo-1.1-5.1.fc10.ppc64 requires testng
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	system-config-audit-0.4.8-9.fc10.ppc64 requires audit-libs = 0:1.7.8-5





From choeger at cs.tu-berlin.de  Tue Oct 28 10:55:55 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Tue, 28 Oct 2008 11:55:55 +0100
Subject: evolution requests unlock keyring
Message-ID: <1225191355.3272.3.camel@choeger5.umpa.netz>

Hi,

I'm running evolution-2.24.0-3.fc10.i386 on my fedora 10 beta
installation. When I start evolution the first time, it simply asks me
to unlock my default keyring (in german) as it ever did, and other apps
still do, but then it keeps asking me (in english) to provide my login
passwd to unlock the keyring. Is that a bug or does it try to get
several passwords?
Is there a way to log which passwds the keyring ist asked for by what
app?

regards

christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/7cf5b209/attachment.sig>

From m at cotdp.com  Tue Oct 28 11:31:40 2008
From: m at cotdp.com (Michael Cutler)
Date: Tue, 28 Oct 2008 11:31:40 +0000 (GMT)
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
Message-ID: <315339.8427.qm@web26104.mail.ukl.yahoo.com>

Hello,

I have been testing the FC10 beta and the more recent snapshots. The installation package selection and options available in the text-mode installer are really very important to me. I run through the installer literally hundreds of times over the lifetime of a Fedora release and not always can it be kickstarted.

One of the major changes I noted from FC9 to the latest spin of FC10 is the lack of network configuration during the install. Specifically during a "minimal" install whereby all packages are unticked leaving only the '@core' group installed. NetworkManager isn't included in the '@core' group and the defaults set by /etc/sysconfig/network-scripts/ifcfg-ethX prohibit the 'network' service from starting the interfaces in NetworkManager's absence.

e.g. /etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0
HWADDR=00:1f:d0:88:0a:fd
ONBOOT=no
NM_CONTROLLED=yes
TYPE=Ethernet

Note that NetworkManger has not been installed, yet the ifcfg-eth0 implies that the interface should be NetworkManager controlled. The 'network' services see's "ONBOOT=no" and ignores this interface. So, using a very simple installation-path the system comes up without any network connectivity, the user must manually edit this file changing "ONBOOT=no" to "ONBOOT=yes" and adding the line "BOOTPROTO=dhcp" before restarting the 'network' service.

I raised this as a bug: https://bugzilla.redhat.com/show_bug.cgi?id=468028

After some feedback, I decided to bring the discussion to this mailing list.

I can understand the push for the use of the NetworkManager, however I totally disagree that default installations should be crippled such that they require manual editing of config files ala NetBSD. The way I see it there are two clear solutions:

(1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.

(2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.

In my opinion, Fedora is all about the ease of use, in every way from installation to the day-to-day running be it on a laptop, desktop or server-class machine. I believe that if the network configuration has been removed to simplify the installation procedure, it must be replaced with some 'smarts' to restore some of the ease of use of Fedora.

Regards,
--
Michael Cutler
http://fedoraproject.org/wiki/User:Mcutler



      



From buc at odusz.so-cdu.ru  Tue Oct 28 11:40:51 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 14:40:51 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225187670.5969.6.camel@localhost.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
Message-ID: <4906FA43.4050902@odu.neva.ru>

Dan Hor?k wrote:
> Will Woods p??e v Po 27. 10. 2008 v 17:07 -0400:
>   
>> Hi folks,
>>
>> If you're running F10Beta/Rawhide, you may have noticed already, but I
>> wanted to make sure everyone knows this is intentional:
>>
>> X HAS MOVED FROM VT7 TO VT1.
>>
>> GDM specifically starts X on tty1, and upstart does not start a getty on
>> tty1 in runlevel 5. 
>>
>>     
>
> How can I disable this "feature"? I really do not want change my habits
> after 10+ years with X on vt7.
>   

+1

I hope it might be possible, by changing the order in upstart -- ie. 
first run mingetty, then gdm (as for years before). Perhaps also restore 
mingetty on tty1 ...

By the way, I cannot understand why gdm, when running before mingetty 
(for better startup speed), must be run on tty1 only. It seems that it 
should be possible to run it before, but cause it to use tty7.

It is insignificant for end users on what tty X run. But for other 
users, it is better to preserve compatibility with 10+ years.

I can help to make changes for invoking X on tty7 instead of tty1 .

Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From alexl at users.sourceforge.net  Tue Oct 28 11:43:57 2008
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Tue, 28 Oct 2008 04:43:57 -0700
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <3170f42f0810262355i2ebc6b41ycde93f071af960d7@mail.gmail.com>
	(Debarshi Ray's message of "Mon\, 27 Oct 2008 12\:25\:45 +0530")
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<sabcq7d1k.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0810262355i2ebc6b41ycde93f071af960d7@mail.gmail.com>
Message-ID: <rq4p2x3pxe.fsf@allele2.eebweb.arizona.edu>

>>>>> Debarshi Ray  writes:

>> Debarshi,
>> 
>> gnome-build, anjuta are still broken in rawhide as of 20081016 and
>> I don't see any new builds in koji.  The development freeze is
>> coming in one day, can you please fix these builds ASAP as you
>> promised above before the freeze?

> Actually I had to go out of station over the weekend, and the libgdl
> build was done just before I left. I am back now, and have the Koji
> and Bugzilla links opened in the other browser tabs. Will push the
> builds today evening.

As far as I can see, anjuta has not yet been rebuilt:

https://koji.fedoraproject.org/koji/packageinfo?packageID=1302

and still causing broken deps in rawhide... :-(

Does this require a new upstream version?  It's really not a good idea
to bump soname, and then leave the dependent packages to be broken for
about 5 days.  Either rebuild the dependent packags immediately after
pushing the soname, or wait until you have time to do them all at
once.

Alex



From janina at rednote.net  Tue Oct 28 12:48:50 2008
From: janina at rednote.net (Janina Sajka)
Date: Tue, 28 Oct 2008 08:48:50 -0400
Subject: Telnet Failure With F-10 Beta
Message-ID: <20081028124850.GA8215@sonata.rednote.net>

I tried (and failed) to start a telnet install of the F-10 beta on two
x86_64 machines. Furthermore, logs on the dhcp server do not indicate
that the target machine ever requested an ip address.

Is there a bug here? Anyone have any suggestions?

Thanks.

Janina


-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org

IPv6 is the answer!



From cra at WPI.EDU  Tue Oct 28 13:17:57 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 09:17:57 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4906FA43.4050902@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
Message-ID: <20081028131757.GG24297@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 02:40:51PM +0300, Dmitry Butskoy wrote:
> I hope it might be possible, by changing the order in upstart -- ie.  
> first run mingetty, then gdm (as for years before). Perhaps also restore  
> mingetty on tty1 ...
>
> By the way, I cannot understand why gdm, when running before mingetty  
> (for better startup speed), must be run on tty1 only. It seems that it  
> should be possible to run it before, but cause it to use tty7.
>
> It is insignificant for end users on what tty X run. But for other  
> users, it is better to preserve compatibility with 10+ years.
>
> I can help to make changes for invoking X on tty7 instead of tty1 .

It seems an insignificant use case to keep compatibility with X on 
tty7 compared to the benefits of progress--in this case one less VT 
change on bootup means less flicker and faster bootup.  I've been 
using Fedora/Red Hat for 10+ years and once the reason was pointed out 
to me, I completely agree that this is a good move.  I'll adjust.



From dbn.lists at gmail.com  Tue Oct 28 13:27:50 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 28 Oct 2008 06:27:50 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4906FA43.4050902@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
Message-ID: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>

On Tue, Oct 28, 2008 at 4:40 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
>
> By the way, I cannot understand why gdm, when running before mingetty (for
> better startup speed), must be run on tty1 only. It seems that it should be
> possible to run it before, but cause it to use tty7.

It's not for speed, it's so there will be no VT switching when booting.

> It is insignificant for end users on what tty X run. But for other users, it
> is better to preserve compatibility with 10+ years.

Why is it significant what tty any program runs on? Isn't the
assumption that getty will be on tty1 just as faulty as the assumption
X will be on tty7?

--
Dan



From buc at odusz.so-cdu.ru  Tue Oct 28 13:28:36 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 16:28:36 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028131757.GG24297@angus.ind.WPI.EDU>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>
	<20081028131757.GG24297@angus.ind.WPI.EDU>
Message-ID: <49071384.3080300@odu.neva.ru>

Chuck Anderson wrote:
> On Tue, Oct 28, 2008 at 02:40:51PM +0300, Dmitry Butskoy wrote:
>   
>> I hope it might be possible, by changing the order in upstart -- ie.  
>> first run mingetty, then gdm (as for years before). Perhaps also restore  
>> mingetty on tty1 ...
>>
>> By the way, I cannot understand why gdm, when running before mingetty  
>> (for better startup speed), must be run on tty1 only. It seems that it  
>> should be possible to run it before, but cause it to use tty7.
>>
>> It is insignificant for end users on what tty X run. But for other  
>> users, it is better to preserve compatibility with 10+ years.
>>
>> I can help to make changes for invoking X on tty7 instead of tty1 .
>>     
>
> It seems an insignificant use case to keep compatibility with X on 
> tty7 compared to the benefits of progress--in this case one less VT 
> change on bootup means less flicker and faster bootup. 

I mean "X before console's tty" as well, but instead of "first X on 
tty1, then consoles on tty2-6", I propose "first X on tty7, then 
consoles on tty1-6". In other words, preserve both the compatibility and 
the faster bootup.


~buc



From limb at jcomserv.net  Tue Oct 28 13:31:37 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 28 Oct 2008 08:31:37 -0500 (CDT)
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49071384.3080300@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<20081028131757.GG24297@angus.ind.WPI.EDU>
	<49071384.3080300@odu.neva.ru>
Message-ID: <998110263a109ced827ecfd8cdd3748d.squirrel@mail.jcomserv.net>


> Chuck Anderson wrote:
>> On Tue, Oct 28, 2008 at 02:40:51PM +0300, Dmitry Butskoy wrote:
>>
>>> I hope it might be possible, by changing the order in upstart -- ie.
>>> first run mingetty, then gdm (as for years before). Perhaps also
>>> restore
>>> mingetty on tty1 ...
>>>
>>> By the way, I cannot understand why gdm, when running before mingetty
>>> (for better startup speed), must be run on tty1 only. It seems that it
>>> should be possible to run it before, but cause it to use tty7.
>>>
>>> It is insignificant for end users on what tty X run. But for other
>>> users, it is better to preserve compatibility with 10+ years.
>>>
>>> I can help to make changes for invoking X on tty7 instead of tty1 .
>>>
>>
>> It seems an insignificant use case to keep compatibility with X on
>> tty7 compared to the benefits of progress--in this case one less VT
>> change on bootup means less flicker and faster bootup.
>
> I mean "X before console's tty" as well, but instead of "first X on
> tty1, then consoles on tty2-6", I propose "first X on tty7, then
> consoles on tty1-6". In other words, preserve both the compatibility and
> the faster bootup.

Heck, even just one tty can help with fixing X issues.

>
> ~buc
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From cra at WPI.EDU  Tue Oct 28 13:41:34 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 09:41:34 -0400
Subject: Telnet Failure With F-10 Beta
In-Reply-To: <20081028124850.GA8215@sonata.rednote.net>
References: <20081028124850.GA8215@sonata.rednote.net>
Message-ID: <20081028134134.GH24297@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 08:48:50AM -0400, Janina Sajka wrote:
> I tried (and failed) to start a telnet install of the F-10 beta on two
> x86_64 machines. Furthermore, logs on the dhcp server do not indicate
> that the target machine ever requested an ip address.
> 
> Is there a bug here? Anyone have any suggestions?

Try a more recent snapshot like F10 Snap3 or today's rawhide.



From buc at odusz.so-cdu.ru  Tue Oct 28 13:43:21 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 16:43:21 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
Message-ID: <490716F9.8050202@odu.neva.ru>

Dan Nicholson wrote:
> On Tue, Oct 28, 2008 at 4:40 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
>   
>> By the way, I cannot understand why gdm, when running before mingetty (for
>> better startup speed), must be run on tty1 only. It seems that it should be
>> possible to run it before, but cause it to use tty7.
>>     
>
> It's not for speed, it's so there will be no VT switching when booting.
>   

Does such a one switching cost so much?

> Why is it significant what tty any program runs on? Isn't the
> assumption that getty will be on tty1 just as faulty as the assumption
> X will be on tty7?
>   

Nope.

First, it is long precedent.

Second, there are non-GUI installations (including those where X invoked 
by "startx" from runlevel 3). Hence it looks strange to count tty 
consoles starting from 2 (instead of 1). Some people will be shocked, 
whereas such a shocking seems not necessary for the faster bootup feature.


~buc



From cra at WPI.EDU  Tue Oct 28 13:43:37 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 09:43:37 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49071384.3080300@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<20081028131757.GG24297@angus.ind.WPI.EDU>
	<49071384.3080300@odu.neva.ru>
Message-ID: <20081028134337.GI24297@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 04:28:36PM +0300, Dmitry Butskoy wrote:
>> It seems an insignificant use case to keep compatibility with X on  
>> tty7 compared to the benefits of progress--in this case one less VT  
>> change on bootup means less flicker and faster bootup. 
>
> I mean "X before console's tty" as well, but instead of "first X on  
> tty1, then consoles on tty2-6", I propose "first X on tty7, then  
> consoles on tty1-6". In other words, preserve both the compatibility and  
> the faster bootup.

The system boots up in tty1 first.  Having X change to tty7 is a VT 
change, hence flicker and delay.



From fedora at shmuelhome.mine.nu  Tue Oct 28 13:44:33 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Tue, 28 Oct 2008 15:44:33 +0200
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
Message-ID: <49071741.30003@shmuelhome.mine.nu>

Dan Nicholson wrote:
> Why is it significant what tty any program runs on? Isn't the
> assumption that getty will be on tty1 just as faulty as the assumption
> X will be on tty7?
>
> --
> Dan
>   
Because you are changing a user interface. What is going to happen when 
the user switches to tty1 and nothing happens? The basic logic of 
putting X on tty7 is to get it out of the way. Humans will use the 
lowest numbered ttys first. Besides breaking existing documentation, 
including advice on various forums, is not a good idea.



From buc at odusz.so-cdu.ru  Tue Oct 28 13:55:49 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 16:55:49 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028134337.GI24297@angus.ind.WPI.EDU>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<20081028131757.GG24297@angus.ind.WPI.EDU>	<49071384.3080300@odu.neva.ru>
	<20081028134337.GI24297@angus.ind.WPI.EDU>
Message-ID: <490719E5.3080901@odu.neva.ru>

Chuck Anderson wrote:
> The system boots up in tty1 first.  Having X change to tty7 is a VT 
> change, hence flicker and delay.
>   

Well,

Is it possible for users who do not use "graphical boot" (there are such 
users...), use "traditional" tty7 instead?

IOW, if X is already running, leave it on tty1, else invoke it on tty7. 
If tty1 is already busy (by X), do not invoke mingetty on it.


~buc




From opensource at till.name  Tue Oct 28 14:09:28 2008
From: opensource at till.name (Till Maas)
Date: Tue, 28 Oct 2008 15:09:28 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
Message-ID: <200810281509.40552.opensource@till.name>

On Tue October 28 2008, Dan Nicholson wrote:
> On Tue, Oct 28, 2008 at 4:40 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> > By the way, I cannot understand why gdm, when running before mingetty
> > (for better startup speed), must be run on tty1 only. It seems that it
> > should be possible to run it before, but cause it to use tty7.
>
> It's not for speed, it's so there will be no VT switching when booting.

Imho then the kernel should be patched to start booting graphically using tty7 
and not tty1. Then you have no switching and do not disturb text-only 
machines.

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/20081028/5affe7c4/attachment.sig>

From dbn.lists at gmail.com  Tue Oct 28 13:49:35 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 28 Oct 2008 06:49:35 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49071741.30003@shmuelhome.mine.nu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
Message-ID: <91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>

On Tue, Oct 28, 2008 at 6:44 AM, shmuel siegel
<fedora at shmuelhome.mine.nu> wrote:
> Dan Nicholson wrote:
>>
>> Why is it significant what tty any program runs on? Isn't the
>> assumption that getty will be on tty1 just as faulty as the assumption
>> X will be on tty7?
>>
>> --
>> Dan
>>
>
> Because you are changing a user interface. What is going to happen when the
> user switches to tty1 and nothing happens? The basic logic of putting X on
> tty7 is to get it out of the way. Humans will use the lowest numbered ttys
> first. Besides breaking existing documentation, including advice on various
> forums, is not a good idea.

The basic logic of X starting on tty7 is because it was the first open
VT because getty is already running on tty1-6. I can show you the code
in the X server where it picks the first available VT. This is just
changing it so that X will start on tty1. What interface is that
breaking? A broken assumption that tty1 == !X?

--
Dan



From kraxel at redhat.com  Tue Oct 28 14:37:03 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Tue, 28 Oct 2008 15:37:03 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
Message-ID: <4907238F.9030802@redhat.com>

Dan Nicholson wrote:
> Why is it significant what tty any program runs on? Isn't the
> assumption that getty will be on tty1 just as faulty as the assumption
> X will be on tty7?

It has been that way for a *long* time.  When something goes wrong I
can't fix in X11 usually hit "Ctrl-Alt-F1" to get the login prompt, like
 *lots* of other people I assume.  That suddenly stops working.  Be
prepared for lots of people wondering where the text console is gone to.

cheers,
  Gerd



From dbn.lists at gmail.com  Tue Oct 28 14:24:10 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 28 Oct 2008 07:24:10 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490719E5.3080901@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<20081028131757.GG24297@angus.ind.WPI.EDU>
	<49071384.3080300@odu.neva.ru>
	<20081028134337.GI24297@angus.ind.WPI.EDU>
	<490719E5.3080901@odu.neva.ru>
Message-ID: <91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>

On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> Chuck Anderson wrote:
>>
>> The system boots up in tty1 first.  Having X change to tty7 is a VT
>> change, hence flicker and delay.
>>
>
> Well,
>
> Is it possible for users who do not use "graphical boot" (there are such
> users...), use "traditional" tty7 instead?
>
> IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
> tty1 is already busy (by X), do not invoke mingetty on it.

Users who do not want a graphical boot set rc 3 as their default
runlevel, and everything is the same as it always was with getty on
tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
started on tty1 and getty is not. That's all there is to it.

--
Dan



From kraxel at redhat.com  Tue Oct 28 14:44:49 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Tue, 28 Oct 2008 15:44:49 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028134337.GI24297@angus.ind.WPI.EDU>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<20081028131757.GG24297@angus.ind.WPI.EDU>	<49071384.3080300@odu.neva.ru>
	<20081028134337.GI24297@angus.ind.WPI.EDU>
Message-ID: <49072561.3010603@redhat.com>


> The system boots up in tty1 first.  Having X change to tty7 is a VT 
> change, hence flicker and delay.

Make plymouth do the graphical splash screen on tty7 then.  The vt
switch to tty7 happens early at boot when the screen is still blank and
nobody will notice.

cheers,
  Gerd



From fedora at shmuelhome.mine.nu  Tue Oct 28 14:49:33 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Tue, 28 Oct 2008 16:49:33 +0200
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
Message-ID: <4907267D.6030209@shmuelhome.mine.nu>

Dan Nicholson wrote:
> On Tue, Oct 28, 2008 at 6:44 AM, shmuel siegel
> <fedora at shmuelhome.mine.nu> wrote:
>   
>> Dan Nicholson wrote:
>>     
>>> Why is it significant what tty any program runs on? Isn't the
>>> assumption that getty will be on tty1 just as faulty as the assumption
>>> X will be on tty7?
>>>
>>> --
>>> Dan
>>>
>>>       
>> Because you are changing a user interface. What is going to happen when the
>> user switches to tty1 and nothing happens? The basic logic of putting X on
>> tty7 is to get it out of the way. Humans will use the lowest numbered ttys
>> first. Besides breaking existing documentation, including advice on various
>> forums, is not a good idea.
>>     
>
> The basic logic of X starting on tty7 is because it was the first open
> VT because getty is already running on tty1-6. I can show you the code
> in the X server where it picks the first available VT. This is just
> changing it so that X will start on tty1. What interface is that
> breaking? A broken assumption that tty1 == !X?
>
> --
> Dan
>
>   
Did you ever think that maybe, just maybe, the code did that 
deliberately? Maybe someone thought that it would be a good idea for 
usable consoles numbers to start at 1?  Or someone thought that once 
people started down a certain path with conventions, it shouldn't be 
changed unless the people saw a real benefit. I don't think that it is a 
broken assumption that I should know where my usable consoles are. 
Forcing the user to guess where the console is is a broken interface. 
Maybe this cartoon will make the point 
http://www.lesher.ws/queryinterface.html.



From chris.stone at gmail.com  Tue Oct 28 14:48:42 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Tue, 28 Oct 2008 07:48:42 -0700
Subject: [Off topic] Codeweavers giving away free licenses
In-Reply-To: <5256d0b0810280250w272723cat2b07989e4c35fc4b@mail.gmail.com>
References: <5256d0b0810280250w272723cat2b07989e4c35fc4b@mail.gmail.com>
Message-ID: <d9c612bf0810280748m1c9f4a3bg2a3978c13997c9ba@mail.gmail.com>

On Tue, Oct 28, 2008 at 2:50 AM, Peter Robinson <pbrobinson at gmail.com>wrote:

> This I realise is somewhat off topic but as it may allow people to
> move from that other OS to Fedora I thought there were some links :-)
>
> Codeweavers is giving away Crossover Linux Pro today due to a
> challenge their CEO issued to the US President.
>
> http://lameduck.codeweavers.com/
>
> Enjoy for those that are interested, apologies to those that aren't
>
>
Sweet, thanks for the link!  We should also thank the benevolent people who
own our central banks, for without their help, Bush would not have been able
to orchestrate the global world financial meltdown.

So let's give a warm-hearted applause to our shadow lords, the Rothschilds.
Thank God, Obama will be taxing all of our billionaires and millionaires to
pay interest on the debt in order to further increase the power and
influence of our World Kings, and increase the Rothschild fortune by another
few hundred trillion dollars or so.

Remember, if our governments need to create money, they should not just
print interest free bills, instead we must all pay interest to our central
banker overlords, for they are the masters who create money out of thin air,
and purchase the political influence of our elected officials.

Best Regards,
Chris (who will probably be shot soon for exposing the truth)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/0bdec635/attachment.htm>

From buc at odusz.so-cdu.ru  Tue Oct 28 14:49:35 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 17:49:35 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<20081028131757.GG24297@angus.ind.WPI.EDU>	<49071384.3080300@odu.neva.ru>	<20081028134337.GI24297@angus.ind.WPI.EDU>	<490719E5.3080901@odu.neva.ru>
	<91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
Message-ID: <4907267F.1050301@odu.neva.ru>

Dan Nicholson wrote:
> On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
>   
>> Chuck Anderson wrote:
>>     
>>> The system boots up in tty1 first.  Having X change to tty7 is a VT
>>> change, hence flicker and delay.
>>>
>>>       
>> Well,
>>
>> Is it possible for users who do not use "graphical boot" (there are such
>> users...), use "traditional" tty7 instead?
>>
>> IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
>> tty1 is already busy (by X), do not invoke mingetty on it.
>>     
>
> Users who do not want a graphical boot set rc 3 as their default
> runlevel,

Not all, I do not use graphical boot and set rc 5 ;)

Though I boot my desktop (==workstation) approximately once in month... 
(It explains why I do not need neither graphical, nor fastest boot...)

>  and everything is the same as it always was with getty on
> tty1-6. If you then run startx, it will start on tty7.

Well, if I change the "consoles/X" order in upstart, then gdm will 
appear at tty7 as before?


~buc



From opensource at till.name  Tue Oct 28 14:51:55 2008
From: opensource at till.name (Till Maas)
Date: Tue, 28 Oct 2008 15:51:55 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<490719E5.3080901@odu.neva.ru>
	<91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
Message-ID: <200810281552.02479.opensource@till.name>

On Tue October 28 2008, Dan Nicholson wrote:

> Users who do not want a graphical boot set rc 3 as their default
> runlevel, and everything is the same as it always was with getty on
> tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
> started on tty1 and getty is not. That's all there is to it.

What happens if one boots into runlevel 3 and then changes into runlevel 5? 
Will the login on tty1 then be killed and replaced by X?

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/20081028/9ec9a9ee/attachment.sig>

From dan at danny.cz  Tue Oct 28 14:57:27 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 28 Oct 2008 15:57:27 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4907267F.1050301@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>	<20081028131757.GG24297@angus.ind.WPI.EDU>
	<49071384.3080300@odu.neva.ru>	<20081028134337.GI24297@angus.ind.WPI.EDU>
	<490719E5.3080901@odu.neva.ru>
	<91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
	<4907267F.1050301@odu.neva.ru>
Message-ID: <1225205847.3589.46.camel@eagle.danny.cz>


Dmitry Butskoy p??e v ?t 28. 10. 2008 v 17:49 +0300:
> Dan Nicholson wrote:
> > On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> >   
> >> Chuck Anderson wrote:
> >>     
> >>> The system boots up in tty1 first.  Having X change to tty7 is a VT
> >>> change, hence flicker and delay.
> >>>
> >>>       
> >> Well,
> >>
> >> Is it possible for users who do not use "graphical boot" (there are such
> >> users...), use "traditional" tty7 instead?
> >>
> >> IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
> >> tty1 is already busy (by X), do not invoke mingetty on it.
> >>     
> >
> > Users who do not want a graphical boot set rc 3 as their default
> > runlevel,
> 
> Not all, I do not use graphical boot and set rc 5 ;)
> 
> Though I boot my desktop (==workstation) approximately once in month... 
> (It explains why I do not need neither graphical, nor fastest boot...)
> 
> >  and everything is the same as it always was with getty on
> > tty1-6. If you then run startx, it will start on tty7.
> 
> Well, if I change the "consoles/X" order in upstart, then gdm will 
> appear at tty7 as before?
> 

AFAIK there was/is a some code in GDM that explicitly passed the "vt 7"
option to the X server. It was not done in upstart on the "init" level.


		Dan




From janina at rednote.net  Tue Oct 28 15:00:49 2008
From: janina at rednote.net (Janina Sajka)
Date: Tue, 28 Oct 2008 11:00:49 -0400
Subject: Telnet Failure With F-10 Beta
In-Reply-To: <20081028134134.GH24297@angus.ind.WPI.EDU>
References: <20081028124850.GA8215@sonata.rednote.net>
	<20081028134134.GH24297@angus.ind.WPI.EDU>
Message-ID: <20081028150049.GB8215@sonata.rednote.net>

Chuck Anderson writes:
> On Tue, Oct 28, 2008 at 08:48:50AM -0400, Janina Sajka wrote:
> > I tried (and failed) to start a telnet install of the F-10 beta on two
> > x86_64 machines. Furthermore, logs on the dhcp server do not indicate
> > that the target machine ever requested an ip address.
> > 
> > Is there a bug here? Anyone have any suggestions?
> 
> Try a more recent snapshot like F10 Snap3 or today's rawhide.


Gladly. Could use a pointer on where to find the snapshots, though.
We're down with pungi, but not the location of snapshots.

Janina

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org

IPv6 is the answer!



From cdahlin at redhat.com  Tue Oct 28 15:08:03 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 11:08:03 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4907267D.6030209@shmuelhome.mine.nu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
Message-ID: <49072AD3.1010603@redhat.com>

shmuel siegel wrote:
> Dan Nicholson wrote:
>> On Tue, Oct 28, 2008 at 6:44 AM, shmuel siegel
>> <fedora at shmuelhome.mine.nu> wrote:
>>  
>>> Dan Nicholson wrote:
>>>    
>>>> Why is it significant what tty any program runs on? Isn't the
>>>> assumption that getty will be on tty1 just as faulty as the assumption
>>>> X will be on tty7?
>>>>
>>>> -- 
>>>> Dan
>>>>
>>>>       
>>> Because you are changing a user interface. What is going to happen 
>>> when the
>>> user switches to tty1 and nothing happens? The basic logic of 
>>> putting X on
>>> tty7 is to get it out of the way. Humans will use the lowest 
>>> numbered ttys
>>> first. Besides breaking existing documentation, including advice on 
>>> various
>>> forums, is not a good idea.
>>>     
>>
>> The basic logic of X starting on tty7 is because it was the first open
>> VT because getty is already running on tty1-6. I can show you the code
>> in the X server where it picks the first available VT. This is just
>> changing it so that X will start on tty1. What interface is that
>> breaking? A broken assumption that tty1 == !X?
>>
>> -- 
>> Dan
>>
>>   
> Did you ever think that maybe, just maybe, the code did that 
> deliberately? Maybe someone thought that it would be a good idea for 
> usable consoles numbers to start at 1?  Or someone thought that once 
> people started down a certain path with conventions, it shouldn't be 
> changed unless the people saw a real benefit. I don't think that it is 
> a broken assumption that I should know where my usable consoles are. 
> Forcing the user to guess where the console is is a broken interface. 
> Maybe this cartoon will make the point 
> http://www.lesher.ws/queryinterface.html.
>
Just stop for a second.

Roll back from the keyboard a bit. Take a deep breath. Clear your mind 
of what you were doing. Relax. Listen to the gentle whirr of your 
computer, and close your eyes.

Feeling relaxed? Ok, now open your eyes, and ask yourself the following 
question:

"Do I /really/ care?"

Look at the F keys on your keyboard. The whole of your gripe lies within 
the space of 6 inches. Lets not have a flame war today. Lets just move 
our habits 6 inches to the left and let life be good.

--CJD



From mrmazda at ij.net  Tue Oct 28 15:22:50 2008
From: mrmazda at ij.net (Felix Miata)
Date: Tue, 28 Oct 2008 11:22:50 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <200810281552.02479.opensource@till.name>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<490719E5.3080901@odu.neva.ru>	<91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
	<200810281552.02479.opensource@till.name>
Message-ID: <49072E4A.5010001@ij.net>

On 2008/10/28 15:51 (GMT+0100) Till Maas composed:

> On Tue October 28 2008, Dan Nicholson wrote:

>> Users who do not want a graphical boot set rc 3 as their default
>> runlevel, and everything is the same as it always was with getty on
>> tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
>> started on tty1 and getty is not. That's all there is to it.

> What happens if one boots into runlevel 3 and then changes into runlevel 5? 
> Will the login on tty1 then be killed and replaced by X?

I just did yum update, rebooted into runlevel 3, logged in on tty1, did
telinit 5, got kdm on vt7, switched to tty1, and found a normal shell prompt
following typical X startup messages, and kdm still on vt7. :-p
-- 
"Everyone should be quick to listen, slow to speak, and
slow to become angry."		James 1:19 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From galibert at pobox.com  Tue Oct 28 15:24:03 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 28 Oct 2008 16:24:03 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4907267D.6030209@shmuelhome.mine.nu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
Message-ID: <20081028152402.GA48208@dspnet.fr.eu.org>

On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> Did you ever think that maybe, just maybe, the code did that 
> deliberately? Maybe someone thought that it would be a good idea for 
> usable consoles numbers to start at 1?  Or someone thought that once 
> people started down a certain path with conventions, it shouldn't be 
> changed unless the people saw a real benefit.

Haven't you heard?  If you're not a graphical-only desktop-type single
user working on a laptop, you're not relevant.

  OG.



From mrmazda at ij.net  Tue Oct 28 15:32:10 2008
From: mrmazda at ij.net (Felix Miata)
Date: Tue, 28 Oct 2008 11:32:10 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49072AD3.1010603@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>
	<49072AD3.1010603@redhat.com>
Message-ID: <4907307A.5060807@ij.net>

On 2008/10/28 11:08 (GMT-0400) Casey Dahlin composed:

> Look at the F keys on your keyboard. The whole of your gripe lies within 
> the space of 6 inches. Lets not have a flame war today. Lets just move 
> our habits 6 inches to the left and let life be good.

Can't do it. My Function keys are where they belong over on the left in a
column of pairs. F1 is the upper left most key on the keyboard, most easy to
find via touch.

F1  F2

F3  F4  Esc	...

F5  F6  TAB	...

F7  F8  Ctrl	...

F9  F10 Shift	...

F11 F12 Alt	...
-- 
"Everyone should be quick to listen, slow to speak, and
slow to become angry."		James 1:19 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From buc at odusz.so-cdu.ru  Tue Oct 28 15:33:04 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 18:33:04 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49072AD3.1010603@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>
	<49072AD3.1010603@redhat.com>
Message-ID: <490730B0.2090309@odu.neva.ru>

Casey Dahlin wrote:
> Just stop for a second.
>
> Roll back from the keyboard a bit. Take a deep breath. Clear your mind 
> of what you were doing. Relax. Listen to the gentle whirr of your 
> computer, and close your eyes.
>
> Feeling relaxed? Ok, now open your eyes, and ask yourself the 
> following question:
>
> "Do I /really/ care?"

Yes!

>
> Look at the F keys on your keyboard. The whole of your gripe lies 
> within the space of 6 inches. Lets not have a flame war today.

Actually, you try to start just now...

> Lets just move our habits 6 inches

Nope. Lets preserve our habits. This habits costs nothing for Joe Users 
(who use X only).

> to the left and let life be good.

Why your life should be good, but my life not? </rhetoric>

I agree, that sometimes changes are incompatible. But in this case 
exactly, we can preserve compatibility with some amount of old users.


~buc



From rc040203 at freenet.de  Tue Oct 28 15:39:47 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 16:39:47 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028152402.GA48208@dspnet.fr.eu.org>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
Message-ID: <1225208387.3897.88.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> > Did you ever think that maybe, just maybe, the code did that 
> > deliberately? Maybe someone thought that it would be a good idea for 
> > usable consoles numbers to start at 1?  Or someone thought that once 
> > people started down a certain path with conventions, it shouldn't be 
> > changed unless the people saw a real benefit.
> 
> Haven't you heard?  If you're not a graphical-only desktop-type single
> user working on a laptop, you're not relevant.
Exactly - nothing much to add.

Time to evaluate other distros.




From dan at danny.cz  Tue Oct 28 14:52:35 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 28 Oct 2008 15:52:35 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<20081028131757.GG24297@angus.ind.WPI.EDU>
	<49071384.3080300@odu.neva.ru>
	<20081028134337.GI24297@angus.ind.WPI.EDU>
	<490719E5.3080901@odu.neva.ru>
	<91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
Message-ID: <1225205555.3589.42.camel@eagle.danny.cz>


Dan Nicholson p??e v ?t 28. 10. 2008 v 07:24 -0700:
> On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> > Chuck Anderson wrote:
> >>
> >> The system boots up in tty1 first.  Having X change to tty7 is a VT
> >> change, hence flicker and delay.
> >>
> >
> > Well,
> >
> > Is it possible for users who do not use "graphical boot" (there are such
> > users...), use "traditional" tty7 instead?
> >
> > IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
> > tty1 is already busy (by X), do not invoke mingetty on it.
> 
> Users who do not want a graphical boot set rc 3 as their default
> runlevel, and everything is the same as it always was with getty on
> tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
> started on tty1 and getty is not. That's all there is to it.

Hm, but I am using runlevel 5 as default and do not use graphical boot
and I want to keep the old behaviour. I can survive a short delay and
some flickering during the vt switching. How can I set that?


		Dan




From rc040203 at freenet.de  Tue Oct 28 15:44:49 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 16:44:49 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49072AD3.1010603@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>  <49072AD3.1010603@redhat.com>
Message-ID: <1225208689.3897.94.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 11:08 -0400, Casey Dahlin wrote:

> "Do I /really/ care?"
Yes ... please elaborate in detail, where the benefits of this changes are to users.

I don't see any.



From galibert at pobox.com  Tue Oct 28 15:44:20 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 28 Oct 2008 16:44:20 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49072AD3.1010603@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu> <49072AD3.1010603@redhat.com>
Message-ID: <20081028154419.GB48208@dspnet.fr.eu.org>

On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
> "Do I /really/ care?"
> 
> Look at the F keys on your keyboard. The whole of your gripe lies within 
> the space of 6 inches. Lets not have a flame war today. Lets just move 
> our habits 6 inches to the left and let life be good.

6 inches to the left is the phone.

Yes, I care.  The self-declared "desktop" guys, which for most of them
don't seem to have met a user in their life, have decided a while ago
that whoever doesn't fit their imaginary use case is irrelevant and
can be ignored.  10+ years old conventions and habits are unimportant
and can be ignored if it gives them less work to do what they want to
have.  This is just one more in a series.

Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
for the desktop, and the server experience grows increasingly worse.

And joy is to be had for all.

  OG.



From dcbw at redhat.com  Tue Oct 28 16:00:25 2008
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 28 Oct 2008 12:00:25 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028154419.GB48208@dspnet.fr.eu.org>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu> <49072AD3.1010603@redhat.com>
	<20081028154419.GB48208@dspnet.fr.eu.org>
Message-ID: <1225209625.2387.61.camel@localhost.localdomain>

On Tue, 2008-10-28 at 16:44 +0100, Olivier Galibert wrote:
> On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
> > "Do I /really/ care?"
> > 
> > Look at the F keys on your keyboard. The whole of your gripe lies within 
> > the space of 6 inches. Lets not have a flame war today. Lets just move 
> > our habits 6 inches to the left and let life be good.
> 
> 6 inches to the left is the phone.
> 
> Yes, I care.  The self-declared "desktop" guys, which for most of them
> don't seem to have met a user in their life, have decided a while ago
> that whoever doesn't fit their imaginary use case is irrelevant and
> can be ignored.  10+ years old conventions and habits are unimportant
> and can be ignored if it gives them less work to do what they want to
> have.  This is just one more in a series.
> 
> Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
> for the desktop, and the server experience grows increasingly worse.

Partly because they make hard decisions and ignore certain segments of
the Linux user-base to produce well-polished, easy-to-use distribution.

Ubuntu enabled NetworkManager way before we did so in Fedora.  I
personally wouldn't have done that as early as they did (and I didn't
push for it in Fedora for that reason), and doing so didn't work for
some of Ubuntu's users.  But they kept it on anyway because for most of
their target audience, it improved their lives.  Otherwise they would
have turned it off years ago.

Were there Ubuntu users who were pissed off that arcane kernel boot
messages were covered up by a pretty bootsplash?  Did they get angry and
go away?

Ubuntu is Ubuntu precisely because of the controversial choices that the
people driving the distribution made.  Is their popularity the result of
the "correctness" of any of these hard choices?  Maybe.

Dan




From joost at cnoc.nl  Tue Oct 28 16:01:42 2008
From: joost at cnoc.nl (Joost van der Sluis)
Date: Tue, 28 Oct 2008 17:01:42 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49072AD3.1010603@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>  <49072AD3.1010603@redhat.com>
Message-ID: <1225209702.12819.3.camel@wsjoost>

Op dinsdag 28-10-2008 om 11:08 uur [tijdzone -0400], schreef Casey
Dahlin:
> "Do I /really/ care?"

In some other open-source projects I'm involved in we are used to answer
this question with: 'So you guarantee that you will answer all users
with the question where their text-console went to? We can assign all
bug-reports that 'Linux crashed' to you, because X is not responsive
anymore and people can not switch to their beloved console at tty1? And
you will tell all reviewers which will complain this that it saves you
some flicker during boot?'

In that case I don't care. But in the case that this will be used
against Fedora, I do care. But then again, I said it, it's your problem
now.

Maybe it's something to note in the release notes, though. Or add it to
some FAQ.

Joost



From chris.stone at gmail.com  Tue Oct 28 16:06:56 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Tue, 28 Oct 2008 09:06:56 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225208387.3897.88.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
Message-ID: <d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>

On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:

> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> > > Did you ever think that maybe, just maybe, the code did that
> > > deliberately? Maybe someone thought that it would be a good idea for
> > > usable consoles numbers to start at 1?  Or someone thought that once
> > > people started down a certain path with conventions, it shouldn't be
> > > changed unless the people saw a real benefit.
> >
> > Haven't you heard?  If you're not a graphical-only desktop-type single
> > user working on a laptop, you're not relevant.
> Exactly - nothing much to add.
>
> Time to evaluate other distros.
>

I can think of better reasons to switch distros other than what tty X is run
on.

Let's keep this thread going, lots of great entertainment value!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/63ea681a/attachment.htm>

From rc040203 at freenet.de  Tue Oct 28 16:15:33 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 17:15:33 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225209625.2387.61.camel@localhost.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu> <49072AD3.1010603@redhat.com>
	<20081028154419.GB48208@dspnet.fr.eu.org>
	<1225209625.2387.61.camel@localhost.localdomain>
Message-ID: <1225210533.3897.105.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 12:00 -0400, Dan Williams wrote:
> On Tue, 2008-10-28 at 16:44 +0100, Olivier Galibert wrote:
> > On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
> > > "Do I /really/ care?"
> > > 
> > > Look at the F keys on your keyboard. The whole of your gripe lies within 
> > > the space of 6 inches. Lets not have a flame war today. Lets just move 
> > > our habits 6 inches to the left and let life be good.
> > 
> > 6 inches to the left is the phone.
> > 
> > Yes, I care.  The self-declared "desktop" guys, which for most of them
> > don't seem to have met a user in their life, have decided a while ago
> > that whoever doesn't fit their imaginary use case is irrelevant and
> > can be ignored.  10+ years old conventions and habits are unimportant
> > and can be ignored if it gives them less work to do what they want to
> > have.  This is just one more in a series.
> > 
> > Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
> > for the desktop, and the server experience grows increasingly worse.
> 
> Partly because they make hard decisions and ignore certain segments of
> the Linux user-base to produce well-polished, easy-to-use distribution.

I strongestly disagree - These people are unable to comprehend how they
are running down Fedora and prefer pushing around users.

> Ubuntu enabled NetworkManager way before we did so in Fedora. 
Well chosen example: Ubuntu had been so stupid to adopt an immature
tool aiming at single-user/single-seat laptop users, first.

One reason for why I am not using Ubuntu.

>  I
> personally wouldn't have done that as early as they did (and I didn't
> push for it in Fedora for that reason), and doing so didn't work for
> some of Ubuntu's users.  But they kept it on anyway because for most of
> their target audience, it improved their lives.  Otherwise they would
> have turned it off years ago.
> 
> Were there Ubuntu users who were pissed off that arcane kernel boot
> messages were covered up by a pretty bootsplash?  Did they get angry and
> go away?
> 
> Ubuntu is Ubuntu precisely because of the controversial choices that the
> people driving the distribution made.  Is their popularity the result of
> the "correctness" of any of these hard choices?  Maybe.
Ask yourselves why we are not NOT using Ubuntu - If people wanted Fedora
to be Ubuntu, we weren't using Fedora.

Ralf




From cheekyboinc at foresightlinux.org  Tue Oct 28 16:17:11 2008
From: cheekyboinc at foresightlinux.org (Stefan Posdzich)
Date: Tue, 28 Oct 2008 17:17:11 +0100
Subject: Orphaning azureus
In-Reply-To: <20081024190916.A41D98E0003@hormel.redhat.com>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
Message-ID: <20081028171711.3c1f1cc9@cheeky>

I have tried now some days with this package and i cant get warm with it
(+ java).
I will orphan it again, i hope it will find someone who can handle
this kind of apps!

https://admin.fedoraproject.org/pkgdb/packages/name/azureus

https://bugzilla.redhat.com/buglist.cgi?quicksearch=azureus

best regards
Stefan



From buc at odusz.so-cdu.ru  Tue Oct 28 16:17:35 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 19:17:35 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225208387.3897.88.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
Message-ID: <49073B1F.4010604@odu.neva.ru>

Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
>   
>> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
>>     
>>> Did you ever think that maybe, just maybe, the code did that 
>>> deliberately? Maybe someone thought that it would be a good idea for 
>>> usable consoles numbers to start at 1?  Or someone thought that once 
>>> people started down a certain path with conventions, it shouldn't be 
>>> changed unless the people saw a real benefit.
>>>       
>> Haven't you heard?  If you're not a graphical-only desktop-type single
>> user working on a laptop, you're not relevant.
>>     
> Exactly - nothing much to add.
>
> Time to evaluate other distros.
>
>   

Time to unite "good old community" people...

Unfortunately, most 10+ experienced users already have made a career, 
hence they have a work, and they are busy. Too busy to start even a SIG 
group. Some essential organizational efforts are necessary for obtaining 
their participation...


~buc



From rc040203 at freenet.de  Tue Oct 28 16:19:07 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 17:19:07 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
Message-ID: <1225210747.3897.110.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
> On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203 at freenet.de>
> wrote:
>         On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
>         > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
>         wrote:
>         > > Did you ever think that maybe, just maybe, the code did
>         that
>         > > deliberately? Maybe someone thought that it would be a
>         good idea for
>         > > usable consoles numbers to start at 1?  Or someone thought
>         that once
>         > > people started down a certain path with conventions, it
>         shouldn't be
>         > > changed unless the people saw a real benefit.
>         >
>         > Haven't you heard?  If you're not a graphical-only
>         desktop-type single
>         > user working on a laptop, you're not relevant.
>         
>         Exactly - nothing much to add.
>         
>         Time to evaluate other distros.
>         
>         
> 
> I can think of better reasons to switch distros other than what tty X
> is run on.
True, but it's one brick in a lengthy series of stupid and silly
decisions, which have been gradually running down Fedora into this
single-user windows clone it has evolved into.

> Let's keep this thread going, lots of great entertainment value!
Right, the "great RH tyrants who are finally showing up!" :)





From chris.stone at gmail.com  Tue Oct 28 16:30:06 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Tue, 28 Oct 2008 09:30:06 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225210747.3897.110.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
Message-ID: <d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>

On Tue, Oct 28, 2008 at 9:19 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:

> On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
> > On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203 at freenet.de>
> > wrote:
> >         On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> >         > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
> >         wrote:
> >         > > Did you ever think that maybe, just maybe, the code did
> >         that
> >         > > deliberately? Maybe someone thought that it would be a
> >         good idea for
> >         > > usable consoles numbers to start at 1?  Or someone thought
> >         that once
> >         > > people started down a certain path with conventions, it
> >         shouldn't be
> >         > > changed unless the people saw a real benefit.
> >         >
> >         > Haven't you heard?  If you're not a graphical-only
> >         desktop-type single
> >         > user working on a laptop, you're not relevant.
> >
> >         Exactly - nothing much to add.
> >
> >         Time to evaluate other distros.
> >
> >
> >
> > I can think of better reasons to switch distros other than what tty X
> > is run on.
> True, but it's one brick in a lengthy series of stupid and silly
> decisions, which have been gradually running down Fedora into this
> single-user windows clone it has evolved into.
>

I'm not sure why you think it is stupid and silly.  Perhaps I have not read
this tread closely enough.  I personally think it is totally irrelevant and
I could care less if X is run on tty1, tty7 or tty4 for that matter.

Is there some technical reason to keep X on tty7 other than "that's the way
it has always been"?

I don't see how tty7 or tty1 makes any difference to a desktop user, or a
server user, or a newbie or an expert.

Linux has evolved away from many anachronistic traditions of  Unix, I don't
see how this is any different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/14a3686f/attachment.htm>

From jkeating at redhat.com  Tue Oct 28 16:38:51 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 09:38:51 -0700
Subject: Default network configuration during installation,
 NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
Message-ID: <1225211932.2157.53.camel@luminos.localdomain>

On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
> 
> (1). Include NetworkManager in the '@core' group, such that every
> install will include NetworkManager and a minimal install as described
> above will bring the system up with network connectivity.

And here we have another fun argument about how 'minimal' should the
minimal install be!  We've chucked yum in @core, might as well chuck
NetworkManager too...

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/4ab22ac2/attachment.sig>

From dcbw at redhat.com  Tue Oct 28 16:38:48 2008
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 28 Oct 2008 12:38:48 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225210533.3897.105.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu> <49072AD3.1010603@redhat.com>
	<20081028154419.GB48208@dspnet.fr.eu.org>
	<1225209625.2387.61.camel@localhost.localdomain>
	<1225210533.3897.105.camel@beck.corsepiu.local>
Message-ID: <1225211928.9216.5.camel@localhost.localdomain>

On Tue, 2008-10-28 at 17:15 +0100, Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 12:00 -0400, Dan Williams wrote:
> > On Tue, 2008-10-28 at 16:44 +0100, Olivier Galibert wrote:
> > > On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
> > > > "Do I /really/ care?"
> > > > 
> > > > Look at the F keys on your keyboard. The whole of your gripe lies within 
> > > > the space of 6 inches. Lets not have a flame war today. Lets just move 
> > > > our habits 6 inches to the left and let life be good.
> > > 
> > > 6 inches to the left is the phone.
> > > 
> > > Yes, I care.  The self-declared "desktop" guys, which for most of them
> > > don't seem to have met a user in their life, have decided a while ago
> > > that whoever doesn't fit their imaginary use case is irrelevant and
> > > can be ignored.  10+ years old conventions and habits are unimportant
> > > and can be ignored if it gives them less work to do what they want to
> > > have.  This is just one more in a series.
> > > 
> > > Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
> > > for the desktop, and the server experience grows increasingly worse.
> > 
> > Partly because they make hard decisions and ignore certain segments of
> > the Linux user-base to produce well-polished, easy-to-use distribution.
> 
> I strongestly disagree - These people are unable to comprehend how they
> are running down Fedora and prefer pushing around users.
> 
> > Ubuntu enabled NetworkManager way before we did so in Fedora. 
> Well chosen example: Ubuntu had been so stupid to adopt an immature
> tool aiming at single-user/single-seat laptop users, first.
> 
> One reason for why I am not using Ubuntu.
> 
> >  I
> > personally wouldn't have done that as early as they did (and I didn't
> > push for it in Fedora for that reason), and doing so didn't work for
> > some of Ubuntu's users.  But they kept it on anyway because for most of
> > their target audience, it improved their lives.  Otherwise they would
> > have turned it off years ago.
> > 
> > Were there Ubuntu users who were pissed off that arcane kernel boot
> > messages were covered up by a pretty bootsplash?  Did they get angry and
> > go away?
> > 
> > Ubuntu is Ubuntu precisely because of the controversial choices that the
> > people driving the distribution made.  Is their popularity the result of
> > the "correctness" of any of these hard choices?  Maybe.
> Ask yourselves why we are not NOT using Ubuntu - If people wanted Fedora

Because they compromise free software in a short-sighted manner by
recommending and including proprietary illegally-distributed codecs and
bundled binary drivers (or ndiswrapper) and because they don't
contribute much back to the community?

I don't particularly care where my VTs are at.  I learn and adapt,
otherwise I'd still be using WordStar or PFWrite or some other crappy
DOS application for writing documents, and WinSOCK for my SLIP dialup at
9600bps.

Dan




From dan at danny.cz  Tue Oct 28 16:45:08 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 28 Oct 2008 17:45:08 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49073B1F.4010604@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
Message-ID: <1225212308.3589.59.camel@eagle.danny.cz>


Dmitry Butskoy p??e v ?t 28. 10. 2008 v 19:17 +0300:
> Ralf Corsepius wrote:
> > On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> >   
> >> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> >>     
> >>> Did you ever think that maybe, just maybe, the code did that 
> >>> deliberately? Maybe someone thought that it would be a good idea for 
> >>> usable consoles numbers to start at 1?  Or someone thought that once 
> >>> people started down a certain path with conventions, it shouldn't be 
> >>> changed unless the people saw a real benefit.
> >>>       
> >> Haven't you heard?  If you're not a graphical-only desktop-type single
> >> user working on a laptop, you're not relevant.
> >>     
> > Exactly - nothing much to add.
> >
> > Time to evaluate other distros.
> >
> >   
> 
> Time to unite "good old community" people...

Count me in :-)

> 
> Unfortunately, most 10+ experienced users already have made a career, 
> hence they have a work, and they are busy. Too busy to start even a SIG 
> group. Some essential organizational efforts are necessary for obtaining 
> their participation...

I cannot understand why it is so big trouble to let the old (or better
classic) behaviour be still an option, when somebody decides that his
way is the right way.


		Dan




From dcbw at redhat.com  Tue Oct 28 16:48:48 2008
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 28 Oct 2008 12:48:48 -0400
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <1225211932.2157.53.camel@luminos.localdomain>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
Message-ID: <1225212528.9923.3.camel@localhost.localdomain>

On Tue, 2008-10-28 at 09:38 -0700, Jesse Keating wrote:
> On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
> > 
> > (1). Include NetworkManager in the '@core' group, such that every
> > install will include NetworkManager and a minimal install as described
> > above will bring the system up with network connectivity.
> 
> And here we have another fun argument about how 'minimal' should the
> minimal install be!  We've chucked yum in @core, might as well chuck
> NetworkManager too...

Right, but we still don't turn NM on by default with chkconfig.  Which
means even if you bring it into @core, your networking still won't work
unless you turn NM on post-install manually.

The issue here (IIRC) was that Anaconda won't set up an ifcfg file for
you if you don't use network to install, because the network
configuration screen got removed as it was mostly redundant for installs
where NM is active.

If you're not installing over the network (and thus there's no network
configuration to save out) should the "network config" screen come back?
Or should anaconda just activate all devices onboot with DHCP?  The
latter sounds like a loss.  If you want stuff set up post-boot without
NetworkManager, maybe it's not unreasonable that you have to configure
it yourself.  What's the difference if that happens post-install or
during install?

Dan




From jkeating at redhat.com  Tue Oct 28 16:53:32 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 09:53:32 -0700
Subject: Frozen for Fedora 10
Message-ID: <1225212812.2157.60.camel@luminos.localdomain>

Last night at 0555 UTC we froze for Fedora 10.  The rawhide from
20081028 is the frozen content.  At this point, builds for F10 are not
automatically brought into Rawhide, and won't be in the Fedora 10
release.  To request a freeze override, please use the Final Freeze
Policy[1]

If you're closing bugs by doing builds, please ensure that those builds
get properly tagged for our final release.

To check the status of your particular build/package, you can look at
the contents of the 'f10-final' tag in Koji.  This is the tag for the
Fedora 10 release, and what rawhide will compose from until F10 is done.

koji latest-pkg f10-final <foo>

It's the last mile folks, lets make it awesome!

[1]: https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/8aae7ad2/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  Tue Oct 28 16:56:14 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 17:56:14 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225212308.3589.59.camel@eagle.danny.cz>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
	<1225212308.3589.59.camel@eagle.danny.cz>
Message-ID: <1225212975.3897.127.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 17:45 +0100, Dan Hor?k wrote:
> Dmitry Butskoy p??e v ?t 28. 10. 2008 v 19:17 +0300:
> > Ralf Corsepius wrote:
> > > On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> > >   
> > >> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> > >>     
> > >>> Did you ever think that maybe, just maybe, the code did that 
> > >>> deliberately? Maybe someone thought that it would be a good idea for 
> > >>> usable consoles numbers to start at 1?  Or someone thought that once 
> > >>> people started down a certain path with conventions, it shouldn't be 
> > >>> changed unless the people saw a real benefit.
> > >>>       
> > >> Haven't you heard?  If you're not a graphical-only desktop-type single
> > >> user working on a laptop, you're not relevant.
> > >>     
> > > Exactly - nothing much to add.
> > >
> > > Time to evaluate other distros.
> > >
> > >   
> > 
> > Time to unite "good old community" people...
> 
> Count me in :-)
me too :-)

> > Unfortunately, most 10+ experienced users already have made a career, 
> > hence they have a work, and they are busy. Too busy to start even a SIG 
> > group. Some essential organizational efforts are necessary for obtaining 
> > their participation...
> 
> I cannot understand why it is so big trouble to let the old (or better
> classic) behaviour be still an option, when somebody decides that his
> way is the right way.
Good idea. Have a "single-user/single-seat" vs. ""multiuser" toggle in
the install ;)

Ralf





From dcbw at redhat.com  Tue Oct 28 16:57:53 2008
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 28 Oct 2008 12:57:53 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225212308.3589.59.camel@eagle.danny.cz>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
	<1225212308.3589.59.camel@eagle.danny.cz>
Message-ID: <1225213073.9923.13.camel@localhost.localdomain>

On Tue, 2008-10-28 at 17:45 +0100, Dan Hor?k wrote:
> Dmitry Butskoy p??e v ?t 28. 10. 2008 v 19:17 +0300:
> > Ralf Corsepius wrote:
> > > On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> > >   
> > >> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> > >>     
> > >>> Did you ever think that maybe, just maybe, the code did that 
> > >>> deliberately? Maybe someone thought that it would be a good idea for 
> > >>> usable consoles numbers to start at 1?  Or someone thought that once 
> > >>> people started down a certain path with conventions, it shouldn't be 
> > >>> changed unless the people saw a real benefit.
> > >>>       
> > >> Haven't you heard?  If you're not a graphical-only desktop-type single
> > >> user working on a laptop, you're not relevant.
> > >>     
> > > Exactly - nothing much to add.
> > >
> > > Time to evaluate other distros.
> > >
> > >   
> > 
> > Time to unite "good old community" people...
> 
> Count me in :-)
> 
> > 
> > Unfortunately, most 10+ experienced users already have made a career, 
> > hence they have a work, and they are busy. Too busy to start even a SIG 
> > group. Some essential organizational efforts are necessary for obtaining 
> > their participation...
> 
> I cannot understand why it is so big trouble to let the old (or better
> classic) behaviour be still an option, when somebody decides that his
> way is the right way.

Each additional option adds another codepath that must be tested and
maintained, another set of options that must be tested both
independently and together, and potentially another UI widget that just
clutters up dialogs.  Or a config file option which must be maintained
indefinitely otherwise people will complain when it's removed.  At some
point, carrying older options along becomes unsustainable versus the
resources required to add capabilities or even just fix existing bugs.

I don't know anyone that has a Zip disk any more; how much effort should
be put into developing, testing, and ensuring that Zip disks or ORB
drives work perfectly, or should people just convert over to CD/RW
instead?

Dan




From cdahlin at redhat.com  Tue Oct 28 17:01:59 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 13:01:59 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225209702.12819.3.camel@wsjoost>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>
	<49072AD3.1010603@redhat.com> <1225209702.12819.3.camel@wsjoost>
Message-ID: <49074587.7090504@redhat.com>

Joost van der Sluis wrote:
> Op dinsdag 28-10-2008 om 11:08 uur [tijdzone -0400], schreef Casey
> Dahlin:
>   
>> "Do I /really/ care?"
>>     
>
> In some other open-source projects I'm involved in we are used to answer
> this question with: 'So you guarantee that you will answer all users
> with the question where their text-console went to? We can assign all
> bug-reports that 'Linux crashed' to you, because X is not responsive
> anymore and people can not switch to their beloved console at tty1? And
> you will tell all reviewers which will complain this that it saves you
> some flicker during boot?'
>
>   

Gladly. Send 'em my way.

--CJD



From jspaleta at gmail.com  Tue Oct 28 17:02:32 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Oct 2008 09:02:32 -0800
Subject: rawhide report: 20081018 changes
In-Reply-To: <loom.20081023T015609-568@post.gmane.org>
References: <20081018100959.D71A41B8001@releng2.fedora.phx.redhat.com>
	<ulod1ijgo3.fsf@allele2.eebweb.arizona.edu>
	<604aa7910810221804k1df39d50y4d8403b3e8e5ab1a@mail.gmail.com>
	<604aa7910810221817s2c169c05s2f8c77c4346265eb@mail.gmail.com>
	<loom.20081023T012222-564@post.gmane.org>
	<604aa7910810221850m43160d2dy9f7cae59b24aaf90@mail.gmail.com>
	<loom.20081023T015609-568@post.gmane.org>
Message-ID: <604aa7910810281002o4da41c12tc0584112513e0b4d@mail.gmail.com>

On Wed, Oct 22, 2008 at 5:57 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> done once it's built, it's not like it can get much worse than not working at
> all. ;-) )


it can...if you are using it for science!  Not working at all is far
far better than working and giving you the wrong calculation.

I tested some of the exposed geos functions involving great circle
calculations and things seem okay.

But I did find that the examples scripts in the package haven't been
ported yet...la la la. Silly upstream need to file some patches with
them.

-jef



From dan at danny.cz  Tue Oct 28 16:48:43 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 28 Oct 2008 17:48:43 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
Message-ID: <1225212523.3589.63.camel@eagle.danny.cz>


Christopher Stone p??e v ?t 28. 10. 2008 v 09:30 -0700:
> On Tue, Oct 28, 2008 at 9:19 AM, Ralf Corsepius <rc040203 at freenet.de>
> wrote:
>         
>         On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
>         > On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius
>         <rc040203 at freenet.de>
>         > wrote:
>         >         On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert
>         wrote:
>         >         > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel
>         siegel
>         >         wrote:
>         >         > > Did you ever think that maybe, just maybe, the
>         code did
>         >         that
>         >         > > deliberately? Maybe someone thought that it
>         would be a
>         >         good idea for
>         >         > > usable consoles numbers to start at 1?  Or
>         someone thought
>         >         that once
>         >         > > people started down a certain path with
>         conventions, it
>         >         shouldn't be
>         >         > > changed unless the people saw a real benefit.
>         >         >
>         >         > Haven't you heard?  If you're not a graphical-only
>         >         desktop-type single
>         >         > user working on a laptop, you're not relevant.
>         >
>         >         Exactly - nothing much to add.
>         >
>         >         Time to evaluate other distros.
>         >
>         >
>         >
>         > I can think of better reasons to switch distros other than
>         what tty X
>         > is run on.
>         
>         True, but it's one brick in a lengthy series of stupid and
>         silly
>         decisions, which have been gradually running down Fedora into
>         this
>         single-user windows clone it has evolved into.
> 
> I'm not sure why you think it is stupid and silly.  Perhaps I have not
> read this tread closely enough.  I personally think it is totally
> irrelevant and I could care less if X is run on tty1, tty7 or tty4 for
> that matter.
> 
> Is there some technical reason to keep X on tty7 other than "that's
> the way it has always been"?
> 

Maybe because you want to switch to the first vt with Ctrl-Alt-F1 and
not Ctrl-Alt-F2?

> 
> I don't see how tty7 or tty1 makes any difference to a desktop user,
> or a server user, or a newbie or an expert.

> Linux has evolved away from many anachronistic traditions of  Unix, I
> don't see how this is any different.


		Dan




From cdahlin at redhat.com  Tue Oct 28 17:04:39 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 13:04:39 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225212975.3897.127.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<49073B1F.4010604@odu.neva.ru>	<1225212308.3589.59.camel@eagle.danny.cz>
	<1225212975.3897.127.camel@beck.corsepiu.local>
Message-ID: <49074627.3040505@redhat.com>

Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 17:45 +0100, Dan Hor?k wrote:
>   
>> Dmitry Butskoy p??e v ?t 28. 10. 2008 v 19:17 +0300:
>>     
>>> Ralf Corsepius wrote:
>>>       
>>>> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
>>>>   
>>>>         
>>>>> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
>>>>>     
>>>>>           
>>>>>> Did you ever think that maybe, just maybe, the code did that 
>>>>>> deliberately? Maybe someone thought that it would be a good idea for 
>>>>>> usable consoles numbers to start at 1?  Or someone thought that once 
>>>>>> people started down a certain path with conventions, it shouldn't be 
>>>>>> changed unless the people saw a real benefit.
>>>>>>       
>>>>>>             
>>>>> Haven't you heard?  If you're not a graphical-only desktop-type single
>>>>> user working on a laptop, you're not relevant.
>>>>>     
>>>>>           
>>>> Exactly - nothing much to add.
>>>>
>>>> Time to evaluate other distros.
>>>>
>>>>   
>>>>         
>>> Time to unite "good old community" people...
>>>       
>> Count me in :-)
>>     
> me too :-)
>
>   
>>> Unfortunately, most 10+ experienced users already have made a career, 
>>> hence they have a work, and they are busy. Too busy to start even a SIG 
>>> group. Some essential organizational efforts are necessary for obtaining 
>>> their participation...
>>>       
>> I cannot understand why it is so big trouble to let the old (or better
>> classic) behaviour be still an option, when somebody decides that his
>> way is the right way.
>>     
> Good idea. Have a "single-user/single-seat" vs. ""multiuser" toggle in
> the install ;)
>
> Ralf
>
>
>   
I think that's much. Theres a 1-liner conf file change to fix it.

--CJD



From walters at verbum.org  Tue Oct 28 17:03:41 2008
From: walters at verbum.org (Colin Walters)
Date: Tue, 28 Oct 2008 13:03:41 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225212975.3897.127.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
	<1225212308.3589.59.camel@eagle.danny.cz>
	<1225212975.3897.127.camel@beck.corsepiu.local>
Message-ID: <faa16b610810281003h70ed6922o3d62303a6a26214c@mail.gmail.com>

On Tue, Oct 28, 2008 at 12:56 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>
> Good idea. Have a "single-user/single-seat" vs. ""multiuser" toggle in
> the install ;)

Ralf, the desktop team has done quite a bit of work relating to
multiple user scenarios such as fast user switching, GNOME user share,
ConsoleKit building a better foundation for multiseat, etc.  About the
only thing that isn't yet fully fleshed out for multiuser is
NetworkManager, but the old system of "run system-config-network"
wasn't really any better.  The system settings work going on in NM
should improve things further.



From wwoods at redhat.com  Tue Oct 28 17:07:00 2008
From: wwoods at redhat.com (Will Woods)
Date: Tue, 28 Oct 2008 13:07:00 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
Message-ID: <1225213620.3407.34.camel@metroid.rdu.redhat.com>

On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
> Hi folks,
> 
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
> 
> X HAS MOVED FROM VT7 TO VT1.

OK look. If you absolutely cannot deal with this DRASTIC change in
behavior:
 
1) add "start on started prefdm" to /etc/event.d/tty1
2) (GNOME) edit /etc/gdm/custom.conf and add
     FirstVT=7
   to the top of the file. Or:
   (KDE) edit /etc/kde/kdm/kdmrc and set
     ServerVTs=-7
     ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
3) Sigh contentedly at the restoration of your precious tradition.

If you use runlevel 3 + startx, nothing has changed. 

Y'know, it took me all of 10 minutes to figure this out on my own. How
long has this thread gone on? I guess y'all have a lot of free time on
your hands? Because, hey, we've got this release coming out soon - maybe
you could help test it or something?

Just a thought.

-w

p.s.:
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Preview
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Blocker
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Target

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3153 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/3868e0fe/attachment.bin>

From buc at odusz.so-cdu.ru  Tue Oct 28 17:09:30 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 20:09:30 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>
	<d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
Message-ID: <4907474A.4040003@odu.neva.ru>

Christopher Stone wrote:
>
> I don't see how tty7 or tty1 makes any difference to a desktop user, 
> or a server user, or a newbie or an expert.

It makes a difference for "old" user.

Some old age users (35+) began when the desktop was poor and monitors 
were bad. Very often they started on a serial "dumb" tty (like vt100), 
and use Vi to type their programs and cmdline for everything else.

For the same reason, why you cannot cause your grandmother to love 
modern club music (she still prefer classic or rock-n-roll), the old 
Linux users still prefer (yes, it is so!) to use Linux consoles. Someone 
use it rarely, someone every day.

Certainly it is impossible to not use GUI now, and surely they use GUI. 
But because of it habits, they switch to consoles often enough. In other 
words, they do Ctrl-Alt-Fn to go to a console, and Alt-F7 to go to X. 
And they press this keys every day every hour.

When you go to change tty7 to tty1, you cause them to change their 
habits from Ctrl-ALt-F1/Alt-F7 to Ctlr-Alt-F2/Alt-F1. It is not good. 
Why? Try to cause your grandmother to listen modern music, she will 
answer you...

Please note, that Linux (and Fedora) is not for "young people" only. It 
is for "all the people". Not for "young enthusiasts", there are a lot of 
"already not young" enthusiasts. The community consisting only from 
young men, is impractical in the real serious world...


~buc



From cdahlin at redhat.com  Tue Oct 28 17:15:28 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 13:15:28 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225210747.3897.110.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
Message-ID: <490748B0.6060506@redhat.com>

Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
>   
>> On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203 at freenet.de>
>> wrote:
>>         On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
>>         > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
>>         wrote:
>>         > > Did you ever think that maybe, just maybe, the code did
>>         that
>>         > > deliberately? Maybe someone thought that it would be a
>>         good idea for
>>         > > usable consoles numbers to start at 1?  Or someone thought
>>         that once
>>         > > people started down a certain path with conventions, it
>>         shouldn't be
>>         > > changed unless the people saw a real benefit.
>>         >
>>         > Haven't you heard?  If you're not a graphical-only
>>         desktop-type single
>>         > user working on a laptop, you're not relevant.
>>         
>>         Exactly - nothing much to add.
>>         
>>         Time to evaluate other distros.
>>         
>>         
>>
>> I can think of better reasons to switch distros other than what tty X
>> is run on.
>>     
> True, but it's one brick in a lengthy series of stupid and silly
> decisions, which have been gradually running down Fedora into this
> single-user windows clone it has evolved into.
>
>   
Are you serious? Really? You must have a very tenuous grasp of OS internals.

Who does this affect?
1) People using the console a lot who also run X (remember, runlevel 3 
hasn't changed). Desktop users don't use consoles, server users don't 
use X (I hope). Only a few species of geek remain.
2) People recovering from X crashes. Bugs. Errors. Things we could be 
fixing and making not happen rather than accommodating this bizzare F1 
fetish.

--CJD



From buc at odusz.so-cdu.ru  Tue Oct 28 17:14:09 2008
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 28 Oct 2008 20:14:09 +0300
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225213620.3407.34.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225213620.3407.34.camel@metroid.rdu.redhat.com>
Message-ID: <49074861.2010200@odu.neva.ru>

Will Woods wrote:
>  
> 1) add "start on started prefdm" to /etc/event.d/tty1
> 2) (GNOME) edit /etc/gdm/custom.conf and add
>      FirstVT=7
>    to the top of the file. Or:
>    (KDE) edit /etc/kde/kdm/kdmrc and set
>      ServerVTs=-7
>      ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
>   

Could it be mentioned in ReleaseNotes?


~buc



From dan at danny.cz  Tue Oct 28 17:17:52 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 28 Oct 2008 18:17:52 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225213620.3407.34.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225213620.3407.34.camel@metroid.rdu.redhat.com>
Message-ID: <1225214272.3589.69.camel@eagle.danny.cz>


Will Woods p??e v ?t 28. 10. 2008 v 13:07 -0400:
> On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
> > Hi folks,
> > 
> > If you're running F10Beta/Rawhide, you may have noticed already, but I
> > wanted to make sure everyone knows this is intentional:
> > 
> > X HAS MOVED FROM VT7 TO VT1.
> 
> OK look. If you absolutely cannot deal with this DRASTIC change in
> behavior:
>  
> 1) add "start on started prefdm" to /etc/event.d/tty1
> 2) (GNOME) edit /etc/gdm/custom.conf and add
>      FirstVT=7
>    to the top of the file. Or:
>    (KDE) edit /etc/kde/kdm/kdmrc and set
>      ServerVTs=-7
>      ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
> 3) Sigh contentedly at the restoration of your precious tradition.

Thanks a lot, Will.


		Dan




From bdwheele at indiana.edu  Tue Oct 28 17:20:04 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Tue, 28 Oct 2008 13:20:04 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4907474A.4040003@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
	<4907474A.4040003@odu.neva.ru>
Message-ID: <1225214404.12732.48.camel@nibbler.dlib.indiana.edu>

I've been quietly lurking for ages now, but this is really too much.

So the argument is "you can't teach and old dog new tricks"?

I am an "old" user by this definition (though I prefer emacs to vi) and
I don't see any problems with this at all.  It looks substantially nicer
than it did before (Kudos to everyone involved with this) and would
appear to the newer-to-linux set.

It also brings a vast improvement for me:  when the x server restarts my
monitor takes a bit to resync ... causing a delay of 1+ seconds on each
restart before the picture is usable.

Hitting alt-f2 isn't any harder than hitting alt-f1, and if you've got X
as you're primary display (via runlevel 5) then I'd argue that X _is_
the first virtual console.  

My only complaint is that I'd like to be able to set a console to 80x25
but I haven't figured out how to do that yet.

Brian



On Tue, 2008-10-28 at 20:09 +0300, Dmitry Butskoy wrote:
> Christopher Stone wrote:
> >
> > I don't see how tty7 or tty1 makes any difference to a desktop user, 
> > or a server user, or a newbie or an expert.
> 
> It makes a difference for "old" user.
> 
> Some old age users (35+) began when the desktop was poor and monitors 
> were bad. Very often they started on a serial "dumb" tty (like vt100), 
> and use Vi to type their programs and cmdline for everything else.
> 
> For the same reason, why you cannot cause your grandmother to love 
> modern club music (she still prefer classic or rock-n-roll), the old 
> Linux users still prefer (yes, it is so!) to use Linux consoles. Someone 
> use it rarely, someone every day.
> 
> Certainly it is impossible to not use GUI now, and surely they use GUI. 
> But because of it habits, they switch to consoles often enough. In other 
> words, they do Ctrl-Alt-Fn to go to a console, and Alt-F7 to go to X. 
> And they press this keys every day every hour.
> 
> When you go to change tty7 to tty1, you cause them to change their 
> habits from Ctrl-ALt-F1/Alt-F7 to Ctlr-Alt-F2/Alt-F1. It is not good. 
> Why? Try to cause your grandmother to listen modern music, she will 
> answer you...
> 
> Please note, that Linux (and Fedora) is not for "young people" only. It 
> is for "all the people". Not for "young enthusiasts", there are a lot of 
> "already not young" enthusiasts. The community consisting only from 
> young men, is impractical in the real serious world...
> 
> 
> ~buc
> 



From bpepple at fedoraproject.org  Tue Oct 28 17:24:08 2008
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 28 Oct 2008 13:24:08 -0400
Subject: Plan for tomorrows (20081029) FESCO meeting
Message-ID: <1225214648.9818.1.camel@truman>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Wednesday at 17:00
UTC in #fedora-meeting on irc.freenode.org:

/topic FESCo-Meeting -- Feature not at 100% by Freeze -
https://fedoraproject.org/wiki/Features/EFI - all

/topic FESCo meeting -- Free discussion around Fedora

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.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/0662b5c5/attachment.sig>

From seg at haxxed.com  Tue Oct 28 17:30:12 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Oct 2008 12:30:12 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490748B0.6060506@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
Message-ID: <1225215012.598.47.camel@localhost.localdomain>

On Tue, 2008-10-28 at 13:15 -0400, Casey Dahlin wrote:
> 2) People recovering from X crashes. Bugs. Errors. Things we could be 
> fixing and making not happen rather than accommodating this bizzare F1 
> fetish.

Are we not running at least one getty on VT2 when X is running? Making
it harder to log in to the box when X crashes (hope you have another
machine to SSH in with...) just makes it harder to fix X bugs. If not,
this scenario seems moot to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/37be5b73/attachment.sig>

From chris.stone at gmail.com  Tue Oct 28 17:34:51 2008
From: chris.stone at gmail.com (Christopher Stone)
Date: Tue, 28 Oct 2008 10:34:51 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225214404.12732.48.camel@nibbler.dlib.indiana.edu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
	<4907474A.4040003@odu.neva.ru>
	<1225214404.12732.48.camel@nibbler.dlib.indiana.edu>
Message-ID: <d9c612bf0810281034s69108536v3dd93c5d2eef26ab@mail.gmail.com>

On Tue, Oct 28, 2008 at 10:20 AM, Brian Wheeler <bdwheele at indiana.edu>wrote:

> My only complaint is that I'd like to be able to set a console to 80x25
> but I haven't figured out how to do that yet.
>

See /usr/share/doc/kernel-doc-2.6.26/Documentation/svga.txt in the
kernel-doc package.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/2752ab1e/attachment.htm>

From jeff at ocjtech.us  Tue Oct 28 17:35:31 2008
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 28 Oct 2008 12:35:31 -0500
Subject: Telnet Failure With F-10 Beta
In-Reply-To: <20081028150049.GB8215@sonata.rednote.net>
References: <20081028124850.GA8215@sonata.rednote.net>
	<20081028134134.GH24297@angus.ind.WPI.EDU>
	<20081028150049.GB8215@sonata.rednote.net>
Message-ID: <935ead450810281035g3b90debct481554365b8996a2@mail.gmail.com>

On Tue, Oct 28, 2008 at 10:00 AM, Janina Sajka <janina at rednote.net> wrote:
>
> Gladly. Could use a pointer on where to find the snapshots, though.
> We're down with pungi, but not the location of snapshots.

So as not to overwhelm the mirrors, the snapshots are available
through bittorrent only:

torrent.fedoraproject.org

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From dbn.lists at gmail.com  Tue Oct 28 17:36:32 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 28 Oct 2008 10:36:32 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225213620.3407.34.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225213620.3407.34.camel@metroid.rdu.redhat.com>
Message-ID: <91705d080810281036r79f755e6if0eefe431653aba4@mail.gmail.com>

2008/10/28 Will Woods <wwoods at redhat.com>:
> On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
>> Hi folks,
>>
>> If you're running F10Beta/Rawhide, you may have noticed already, but I
>> wanted to make sure everyone knows this is intentional:
>>
>> X HAS MOVED FROM VT7 TO VT1.
>
> OK look. If you absolutely cannot deal with this DRASTIC change in
> behavior:
>
> 1) add "start on started prefdm" to /etc/event.d/tty1
> 2) (GNOME) edit /etc/gdm/custom.conf and add
>     FirstVT=7
>   to the top of the file. Or:
>   (KDE) edit /etc/kde/kdm/kdmrc and set
>     ServerVTs=-7
>     ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
> 3) Sigh contentedly at the restoration of your precious tradition.
>
> If you use runlevel 3 + startx, nothing has changed.

I don't think this is quite how it works in the plymouth/gdm new world
order. Especially since newer gdm doesn't support FirstVT anymore.

plymouth drops a file /var/spool/gdm/force-display-on-active-vt, which
gdm checks for when starting its slave. Instead, I think this can all
be handled from upstart with a preference FORCEACTIVEVT in
/etc/sysconfig/desktop (names/files open for suggestion).

Attached is an untested patch which:

1. Writes /var/spool/gdm/force-display-on-active-vt from prefdm if
$FORCEACTIVEVT = yes
2. Starts getty on tty1 in rc5 if $FORCEACTIVEVT=no

So, you can get the old behavior back with

echo 'FORCEACTIVEVT=no' >> /etc/sysconfig/desktop

This requires that writing /var/spool/gdm/force-display-on-active-vt
is removed from plymouth.

--
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initscripts-old-active-vt.patch
Type: text/x-diff
Size: 1109 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/078b72d4/attachment.bin>

From bdwheele at indiana.edu  Tue Oct 28 17:36:05 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Tue, 28 Oct 2008 13:36:05 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <d9c612bf0810281034s69108536v3dd93c5d2eef26ab@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
	<4907474A.4040003@odu.neva.ru>
	<1225214404.12732.48.camel@nibbler.dlib.indiana.edu>
	<d9c612bf0810281034s69108536v3dd93c5d2eef26ab@mail.gmail.com>
Message-ID: <1225215365.12732.50.camel@nibbler.dlib.indiana.edu>

On Tue, 2008-10-28 at 10:34 -0700, Christopher Stone wrote:
> On Tue, Oct 28, 2008 at 10:20 AM, Brian Wheeler <bdwheele at indiana.edu>
> wrote:
>         My only complaint is that I'd like to be able to set a console
>         to 80x25
>         but I haven't figured out how to do that yet.
> 
> See /usr/share/doc/kernel-doc-2.6.26/Documentation/svga.txt in the
> kernel-doc package.


Thanks, I'll check it out!

> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From seg at haxxed.com  Tue Oct 28 17:36:16 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Oct 2008 12:36:16 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225214404.12732.48.camel@nibbler.dlib.indiana.edu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<d9c612bf0810280930n36649e6cm1d0309495ce063e2@mail.gmail.com>
	<4907474A.4040003@odu.neva.ru>
	<1225214404.12732.48.camel@nibbler.dlib.indiana.edu>
Message-ID: <1225215376.598.51.camel@localhost.localdomain>

On Tue, 2008-10-28 at 13:20 -0400, Brian Wheeler wrote:
> It also brings a vast improvement for me:  when the x server restarts my
> monitor takes a bit to resync ... causing a delay of 1+ seconds on each
> restart before the picture is usable.

My monitor takes 3 seconds to resync. So with the old 3 switches, that's
a full 12 seconds of black screen...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/0a027653/attachment.sig>

From seg at haxxed.com  Tue Oct 28 17:36:44 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Oct 2008 12:36:44 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225208387.3897.88.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
Message-ID: <1225215404.598.53.camel@localhost.localdomain>

On Tue, 2008-10-28 at 16:39 +0100, Ralf Corsepius wrote:
> Time to evaluate other distros.

Please do.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/3ea1035b/attachment.sig>

From dbn.lists at gmail.com  Tue Oct 28 17:37:40 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 28 Oct 2008 10:37:40 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225215012.598.47.camel@localhost.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215012.598.47.camel@localhost.localdomain>
Message-ID: <91705d080810281037h79cddca4qa2c8a2300a41781d@mail.gmail.com>

2008/10/28 Callum Lerwick <seg at haxxed.com>:
> On Tue, 2008-10-28 at 13:15 -0400, Casey Dahlin wrote:
>> 2) People recovering from X crashes. Bugs. Errors. Things we could be
>> fixing and making not happen rather than accommodating this bizzare F1
>> fetish.
>
> Are we not running at least one getty on VT2 when X is running? Making
> it harder to log in to the box when X crashes (hope you have another
> machine to SSH in with...) just makes it harder to fix X bugs. If not,
> this scenario seems moot to me.

Yes tty2-6 still have getty on them just like they always have.

--
Dan



From ml at deadbabylon.de  Tue Oct 28 17:38:10 2008
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 28 Oct 2008 18:38:10 +0100
Subject: KDE-SIG weekly report (44/2008)
Message-ID: <200810281838.16162.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/2008

Time: 2008-10-28 16:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-10-28

Meeting log: https://fedoraproject.org/w/uploads/8/84/KDE-SIG-2008-10-28.txt

----------------------------------------------------------------------------------

= Participants =

- KevinKofler 
- RexDieter 
- SebastianVahl 
- StevenParrish 
- ThanNgo

----------------------------------------------------------------------------------

= Agenda =

* Live images oversized due to recent inclusion of m17n-* and scim-* [1]
* TTY mods to kdmrc (switch X to tty1 per faster startup)

= Summary =

Live images oversized due to recent inclusion of m17n-* and scim-*: 
- - - - -
* The current inclusion of input-methods group in fedora-live-base.ks breaks 
the size of the KDE live images. 
* The english-only KDE live images don't have much need for these packages. 
* As a short term solution scim-python-pinyin will be replaced by the smaller 
scim-pinyin on the live images. 
* We should also talk to the Fedora I18N Group about size constraints. 
* Another big but mostly unneeded package is solar-backgrounds (KDE does not 
support the different times of day). 
* We'll suggest splitting solar-backgrounds into a *-common subpackage with 
shared artwork which will be required by solar-kde then. 
* Also the solar-backgrounds dependency should be moved from libgnome to a 
package higher up in the GNOME stack (which isn't included on the KDE spin). 

TTY mods to kdmrc (switch X to tty1 per faster startup): 
- - - - -
* RexDieter has tested some modifications of kdmrc to use tty1 for KDM (like 
GDM is doing). 
* This change will be included in the next release of kde-setting


----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-11-04

----------------------------------------------------------------------------------

= Links =

[1] 
http://fedoraproject.org/w/index.php?title=SebastianVahl/CurrentPackageList&oldid=56579
[2] 
http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=commitdiff;h=bd870f59d70eacb0362462976444381a7924f067
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/994482d3/attachment.sig>

From rc040203 at freenet.de  Tue Oct 28 17:38:16 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 18:38:16 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490748B0.6060506@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
Message-ID: <1225215496.3897.158.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 13:15 -0400, Casey Dahlin wrote:
> Ralf Corsepius wrote:
> > On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
> >   
> >> On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203 at freenet.de>
> >> wrote:
> >>         On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> >>         > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
> >>         wrote:
> >>         > > Did you ever think that maybe, just maybe, the code did
> >>         that
> >>         > > deliberately? Maybe someone thought that it would be a
> >>         good idea for
> >>         > > usable consoles numbers to start at 1?  Or someone thought
> >>         that once
> >>         > > people started down a certain path with conventions, it
> >>         shouldn't be
> >>         > > changed unless the people saw a real benefit.
> >>         >
> >>         > Haven't you heard?  If you're not a graphical-only
> >>         desktop-type single
> >>         > user working on a laptop, you're not relevant.
> >>         
> >>         Exactly - nothing much to add.
> >>         
> >>         Time to evaluate other distros.
> >>         
> >>         
> >>
> >> I can think of better reasons to switch distros other than what tty X
> >> is run on.
> >>     
> > True, but it's one brick in a lengthy series of stupid and silly
> > decisions, which have been gradually running down Fedora into this
> > single-user windows clone it has evolved into.
> >
> >   
> Are you serious? Really?
Yes, I am.

>  You must have a very tenuous grasp of OS internals.
> 
> Who does this affect?
E.g. application devs, documentation writers, experienced users.

The only party to which this change doesn't make a difference is total
newcomers.

> 1) People using the console a lot who also run X (remember, runlevel 3 
> hasn't changed).
That's my standard use case, because I do need X11 running most of the
time on my machines. I log into them on consoles and launch a desktop
via startx, when I need it.

>  Desktop users don't use consoles, server users don't 
> use X (I hope). Only a few species of geek remain.
Not true. Most "Win converts" (I prefer them call them Win-kiddies) are
working on "personal machines" and are running X11-Desktops. 
For other users (feel free to call them them "geeks", X11/gdm etc. are
just avoidable ballast.

> 2) People recovering from X crashes. Bugs. Errors. Things we could be 
> fixing and making not happen rather than accommodating this bizzare F1 
> fetish.

Once more, your "F1 fetish" to me is a silly, avoidable change, whose
only feature it is to break documentations, habits and to add further
hassle.  A completely superfluous change.





From seg at haxxed.com  Tue Oct 28 17:38:24 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Oct 2008 12:38:24 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490730B0.2090309@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu> <49072AD3.1010603@redhat.com>
	<490730B0.2090309@odu.neva.ru>
Message-ID: <1225215504.598.55.camel@localhost.localdomain>

On Tue, 2008-10-28 at 18:33 +0300, Dmitry Butskoy wrote:
> Casey Dahlin wrote:
> > Just stop for a second.
> >
> > Roll back from the keyboard a bit. Take a deep breath. Clear your mind 
> > of what you were doing. Relax. Listen to the gentle whirr of your 
> > computer, and close your eyes.
> >
> > Feeling relaxed? Ok, now open your eyes, and ask yourself the 
> > following question:
> >
> > "Do I /really/ care?"
> 
> Yes!

YHBT, HAND.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/c8afee5d/attachment.sig>

From jkeating at redhat.com  Tue Oct 28 17:45:11 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 10:45:11 -0700
Subject: F10 builds targetted for dist-f10-updates-candidate
Message-ID: <1225215911.2157.67.camel@luminos.localdomain>

In order to properly prepare F10 updates, all F10 builds are now
targetted at dist-f10-updates-candidate.  This is a setting in the
'common' directory of your package modules, so you'll want to make sure
you're using an up to date common.

The buildroot for dist-f10-updates-candidate is comprised of dist-f10
content, which means builds done in dist-f10-updates-candidate
will /not/ automatically be usable in the buildroot.  You'll need to
request a buildroot override in order to do build sets.

Also, any build that we break the freeze for and tag for Fedora 10
release will also be available in the buildroot.

I have locked the dist-f10 tag so that no more builds can automatically
get tagged.  If you have a build that fails due to a locked tag, you can
either ping releng, or manually tag it yourself for
dist-f10-updates-candidate:

# koji tag-pkg dist-f10-updates-candidate <build-n-v-r>
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/3fa3ab02/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 cdahlin at redhat.com  Tue Oct 28 17:54:27 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 13:54:27 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4907267F.1050301@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<20081028131757.GG24297@angus.ind.WPI.EDU>	<49071384.3080300@odu.neva.ru>	<20081028134337.GI24297@angus.ind.WPI.EDU>	<490719E5.3080901@odu.neva.ru>	<91705d080810280724r4c660187x8865ad3e3a33dbe1@mail.gmail.com>
	<4907267F.1050301@odu.neva.ru>
Message-ID: <490751D3.1050107@redhat.com>

Dmitry Butskoy wrote:
> Dan Nicholson wrote:
>> On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc at odusz.so-cdu.ru> 
>> wrote:
>>  
>>> Chuck Anderson wrote:
>>>    
>>>> The system boots up in tty1 first.  Having X change to tty7 is a VT
>>>> change, hence flicker and delay.
>>>>
>>>>       
>>> Well,
>>>
>>> Is it possible for users who do not use "graphical boot" (there are 
>>> such
>>> users...), use "traditional" tty7 instead?
>>>
>>> IOW, if X is already running, leave it on tty1, else invoke it on 
>>> tty7. If
>>> tty1 is already busy (by X), do not invoke mingetty on it.
>>>     
>>
>> Users who do not want a graphical boot set rc 3 as their default
>> runlevel,
>
> Not all, I do not use graphical boot and set rc 5 ;)
>
> Though I boot my desktop (==workstation) approximately once in 
> month... (It explains why I do not need neither graphical, nor fastest 
> boot...)
>
>>  and everything is the same as it always was with getty on
>> tty1-6. If you then run startx, it will start on tty7.
>
> Well, if I change the "consoles/X" order in upstart, then gdm will 
> appear at tty7 as before?
>
>
> ~buc
>
Should be.

--CJD



From wwoods at redhat.com  Tue Oct 28 17:54:26 2008
From: wwoods at redhat.com (Will Woods)
Date: Tue, 28 Oct 2008 13:54:26 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <91705d080810281036r79f755e6if0eefe431653aba4@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225213620.3407.34.camel@metroid.rdu.redhat.com>
	<91705d080810281036r79f755e6if0eefe431653aba4@mail.gmail.com>
Message-ID: <1225216466.3407.47.camel@metroid.rdu.redhat.com>

On Tue, 2008-10-28 at 10:36 -0700, Dan Nicholson wrote:
> 2008/10/28 Will Woods <wwoods at redhat.com>:
> > On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
> >> Hi folks,
> >>
> >> If you're running F10Beta/Rawhide, you may have noticed already, but I
> >> wanted to make sure everyone knows this is intentional:
> >>
> >> X HAS MOVED FROM VT7 TO VT1.
> >
> > OK look. If you absolutely cannot deal with this DRASTIC change in
> > behavior:
> >
> > 1) add "start on started prefdm" to /etc/event.d/tty1
> > 2) (GNOME) edit /etc/gdm/custom.conf and add
> >     FirstVT=7
> >   to the top of the file. Or:
> >   (KDE) edit /etc/kde/kdm/kdmrc and set
> >     ServerVTs=-7
> >     ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
> > 3) Sigh contentedly at the restoration of your precious tradition.
> >
> > If you use runlevel 3 + startx, nothing has changed.
> 
> I don't think this is quite how it works in the plymouth/gdm new world
> order. Especially since newer gdm doesn't support FirstVT anymore.

Really? Because I *did* test it before sending mail, and it worked as
expected; X was on VT7 again. But maybe things are different when we
start right after plymouth..
..anyway, it's worth documenting how to change it back. 

This is probably a good time to mention that the Docs Project would
surely love help in documenting these sorts of changes for the release
notes:

http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3153 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/c1fc9ca3/attachment.bin>

From jkeating at redhat.com  Tue Oct 28 17:54:53 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 10:54:53 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225215496.3897.158.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
Message-ID: <1225216493.2157.68.camel@luminos.localdomain>

On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
> 
> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
> only feature it is to break documentations, habits and to add further
> hassle.  A completely superfluous change.

As noted multiple times on this thread, the change prevents the
multi-second monitor refresh issues when mode is changed by vt switches.
We can save people 3+ seconds in their boot up to usability time which
is no small feat.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/e905bfd6/attachment.sig>

From mw_triad at users.sourceforge.net  Tue Oct 28 18:05:12 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 28 Oct 2008 13:05:12 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225216493.2157.68.camel@luminos.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
Message-ID: <ge7k8o$2jp$1@ger.gmane.org>

Jesse Keating wrote:
> As noted multiple times on this thread, the change prevents the
> multi-second monitor refresh issues when mode is changed by vt switches.
> We can save people 3+ seconds in their boot up to usability time which
> is no small feat.

As noted at least once, why not ask the kernel to just consider vt7 as 
current *to start with*?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
ESNR: signal to noise ratio too low (try a mailer without disclaimers)



From jonstanley at gmail.com  Tue Oct 28 18:06:19 2008
From: jonstanley at gmail.com (Jon Stanley)
Date: Tue, 28 Oct 2008 14:06:19 -0400
Subject: Telnet Failure With F-10 Beta
In-Reply-To: <20081028150049.GB8215@sonata.rednote.net>
References: <20081028124850.GA8215@sonata.rednote.net>
	<20081028134134.GH24297@angus.ind.WPI.EDU>
	<20081028150049.GB8215@sonata.rednote.net>
Message-ID: <da159fda0810281106r3f305982pbe083d92ab208a7e@mail.gmail.com>

On Tue, Oct 28, 2008 at 11:00 AM, Janina Sajka <janina at rednote.net> wrote:

> We're down with pungi, but not the location of snapshots.

Though if you're down with pungi, it's easier to just recompose from
today's rawhide than download media that you could generate quicker
and more current yourself.



From fedora at shmuelhome.mine.nu  Tue Oct 28 18:04:25 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Tue, 28 Oct 2008 20:04:25 +0200
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225216493.2157.68.camel@luminos.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
Message-ID: <49075429.1040508@shmuelhome.mine.nu>

Jesse Keating wrote:
> On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
>   
>> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
>> only feature it is to break documentations, habits and to add further
>> hassle.  A completely superfluous change.
>>     
>
> As noted multiple times on this thread, the change prevents the
> multi-second monitor refresh issues when mode is changed by vt switches.
> We can save people 3+ seconds in their boot up to usability time which
> is no small feat.
>
>   
There were also many alternatives mentioned in this thread. And reasons 
were given as to why this change is a bad idea. I haven't seen any 
response to the alternatives. The typical response to the objections 
were either "don't start a flame war" or "who cares about your use 
case". Is feedback wanted?



From cra at WPI.EDU  Tue Oct 28 18:18:55 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 14:18:55 -0400
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <1225212528.9923.3.camel@localhost.localdomain>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
Message-ID: <20081028181855.GJ19205@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
> If you're not installing over the network (and thus there's no network
> configuration to save out) should the "network config" screen come back?
> Or should anaconda just activate all devices onboot with DHCP?  The
> latter sounds like a loss.  If you want stuff set up post-boot without
> NetworkManager, maybe it's not unreasonable that you have to configure
> it yourself.  What's the difference if that happens post-install or
> during install?

I think it is a perfectly reasonable default to have DHCP enabled by 
default for all network interfaces, whether NetworkManager is used or 
not.



From jkeating at redhat.com  Tue Oct 28 18:29:40 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 11:29:40 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49075429.1040508@shmuelhome.mine.nu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<49075429.1040508@shmuelhome.mine.nu>
Message-ID: <1225218581.2157.87.camel@luminos.localdomain>

On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
> There were also many alternatives mentioned in this thread. And reasons 
> were given as to why this change is a bad idea. I haven't seen any 
> response to the alternatives. The typical response to the objections 
> were either "don't start a flame war" or "who cares about your use 
> case". Is feedback wanted?

well this thread has gone pretty out of control, so any chance of
getting the people who were actually doing the work to look in on it is
probably not going to happen.

A more technical discussion, posed to the people who were making the
changes could perhaps result in a discussion about why the alternatives
either won't work, or weren't considered.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/ea44e045/attachment.sig>

From fedora at shmuelhome.mine.nu  Tue Oct 28 18:38:28 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Tue, 28 Oct 2008 20:38:28 +0200
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225218581.2157.87.camel@luminos.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>	<1225216493.2157.68.camel@luminos.localdomain>	<49075429.1040508@shmuelhome.mine.nu>
	<1225218581.2157.87.camel@luminos.localdomain>
Message-ID: <49075C24.6060208@shmuelhome.mine.nu>

Jesse Keating wrote:
> well this thread has gone pretty out of control, 
We agree on this.
> so any chance of
> getting the people who were actually doing the work to look in on it is
> probably not going to happen.
>
> A more technical discussion, posed to the people who were making the
> changes could perhaps result in a discussion about why the alternatives
> either won't work, or weren't considered.
>   
So who should we talk to?




From lesmikesell at gmail.com  Tue Oct 28 18:37:15 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 28 Oct 2008 13:37:15 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490748B0.6060506@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
Message-ID: <49075BDB.1010401@gmail.com>

Casey Dahlin wrote:
> >>>     
>> True, but it's one brick in a lengthy series of stupid and silly
>> decisions, which have been gradually running down Fedora into this
>> single-user windows clone it has evolved into.
>>
>>   
> Are you serious? Really? You must have a very tenuous grasp of OS 
> internals.

No, every change requires extensive documentation and retraining or you 
will have confused and disgruntled users.

> Who does this affect?
> 1) People using the console a lot who also run X (remember, runlevel 3 
> hasn't changed). Desktop users don't use consoles, server users don't 
> use X (I hope). Only a few species of geek remain.

This dichotomy exists only in your imagination.  Desktop users sometimes 
interact with servers, server users nearly always interact with desktops.

> 2) People recovering from X crashes. Bugs. Errors. Things we could be 
> fixing and making not happen rather than accommodating this bizzare F1 
> fetish.

People reading documentation.  Please change the behavior _after_ 
updating all existing documentation.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dbn.lists at gmail.com  Tue Oct 28 18:42:11 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 28 Oct 2008 11:42:11 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225216466.3407.47.camel@metroid.rdu.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225213620.3407.34.camel@metroid.rdu.redhat.com>
	<91705d080810281036r79f755e6if0eefe431653aba4@mail.gmail.com>
	<1225216466.3407.47.camel@metroid.rdu.redhat.com>
Message-ID: <91705d080810281142i2294cc4euc70c5482ac3919d0@mail.gmail.com>

2008/10/28 Will Woods <wwoods at redhat.com>:
> On Tue, 2008-10-28 at 10:36 -0700, Dan Nicholson wrote:
>> 2008/10/28 Will Woods <wwoods at redhat.com>:
>> > On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
>> >> Hi folks,
>> >>
>> >> If you're running F10Beta/Rawhide, you may have noticed already, but I
>> >> wanted to make sure everyone knows this is intentional:
>> >>
>> >> X HAS MOVED FROM VT7 TO VT1.
>> >
>> > OK look. If you absolutely cannot deal with this DRASTIC change in
>> > behavior:
>> >
>> > 1) add "start on started prefdm" to /etc/event.d/tty1
>> > 2) (GNOME) edit /etc/gdm/custom.conf and add
>> >     FirstVT=7
>> >   to the top of the file. Or:
>> >   (KDE) edit /etc/kde/kdm/kdmrc and set
>> >     ServerVTs=-7
>> >     ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
>> > 3) Sigh contentedly at the restoration of your precious tradition.
>> >
>> > If you use runlevel 3 + startx, nothing has changed.
>>
>> I don't think this is quite how it works in the plymouth/gdm new world
>> order. Especially since newer gdm doesn't support FirstVT anymore.
>
> Really? Because I *did* test it before sending mail, and it worked as
> expected; X was on VT7 again. But maybe things are different when we
> start right after plymouth..
> ..anyway, it's worth documenting how to change it back.

Since plymouth writes the /var/spool/gdm file on boot and then gdm
removes it, any subsequent starts will put X on the first available
VT, which is tty7 in the common configuration. With my patch, prefdm
writes the file every time it's executed. I don't know if that's the
correct behavior for all cases where prefdm would be run.

I'm looking at upstream gdm right now, and FirstVT isn't respected.
Looking at the rawhide patches, I don't see anything that would enable
that functionality again.

> This is probably a good time to mention that the Docs Project would
> surely love help in documenting these sorts of changes for the release
> notes:
>
> http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process

Good to know.

--
Dan



From jkeating at redhat.com  Tue Oct 28 18:44:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 11:44:00 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49075C24.6060208@shmuelhome.mine.nu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<49075429.1040508@shmuelhome.mine.nu>
	<1225218581.2157.87.camel@luminos.localdomain>
	<49075C24.6060208@shmuelhome.mine.nu>
Message-ID: <1225219440.2157.90.camel@luminos.localdomain>

On Tue, 2008-10-28 at 20:38 +0200, shmuel siegel wrote:
> So who should we talk to?

This was a change driven by the Fedora Desktop team, who can be find on
the mailing list
https://www.redhat.com/mailman/listinfo/fedora-desktop-list or in
gimpnet IRC

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/1b6f1456/attachment.sig>

From mhw at WittsEnd.com  Tue Oct 28 18:57:45 2008
From: mhw at WittsEnd.com (Michael H. Warfield)
Date: Tue, 28 Oct 2008 14:57:45 -0400
Subject: Blocker Bug Review Meeting :: Monday @ 14:00 UTC
In-Reply-To: <490281E1.1090305@redhat.com>
References: <490281E1.1090305@redhat.com>
Message-ID: <1225220265.12100.80.camel@canyon.wittsend.com>

	How do you add a bug to the blocker list?  The following two bugzilla
bugs are basically duplicates of each other and are a "failure to boot"
bug wrt mkinitrd:

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

	If I understand the blocker criterion here: 

	https://fedoraproject.org/wiki/QA/ReleaseCriteria

Quote:

==
A note on MUST and SHOULD 
Items described with the word "MUST" are required to work for all
releases, including Test releases.
Additionally, the items described with the word "SHOULD" are required
for all final releases.
==

==
Boot 
      * The installed system MUST boot and start up properly.
==

	Those bugs are "failure to boot" which fails to meet the condition that
the install "MUST" boot.  There are several scenarios involving SCSI
drivers (and maybe one PATA) in both real and VMware environments which
fail this.

	The blocker document says: "Refer to the RoadMap for links to tracker
bugs and contact the ReleaseEngineering team if you wish to nominate any
bugs as blockers for a release that meet the following criteria."

	It doesn't say how to contact the ReleaseEngineering team or give an
E-Mail address and I would like to nominate these bugs.

	Mike


On Fri, 2008-10-24 at 19:18 -0700, John Poelstra wrote:
> A meeting is being held to review the current blocker bugs in 
> anticipation of the Final Development Freeze this Tuesday, October 28th.
> 
> All teams (thus the cc to f-a-b) in Fedora are welcome to join in and help.
> 
> WHEN: Monday, October 27, 2008 @ 14:00 UTC (10 AM EDT) and going as long 
> as we need to
> WHERE: irc.freenode.net #fedora-blocker
> 
> Fedora 10 Blocker: 
> https://bugzilla.redhat.com/showdependencytree.cgi?id=438943&hide_resolved=1
> Fedora 10 Preview Blocker: 
> https://bugzilla.redhat.com/showdependencytree.cgi?id=446449&hide_resolved=1
> 
> There still remain approximately 600 rawhide bugs that have not been 
> triaged for potential blocker status and should be considered as well. 
> These bugs are here: http://tinyurl.com/6llac8
> 
> Other tracker bugs of interest are here: 
> https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
> 
> John
> 
> _______________________________________________
> Fedora-devel-announce mailing list
> Fedora-devel-announce at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-announce
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/160719ea/attachment.sig>

From jkeating at redhat.com  Tue Oct 28 19:03:56 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 12:03:56 -0700
Subject: Blocker Bug Review Meeting :: Monday @ 14:00 UTC
In-Reply-To: <1225220265.12100.80.camel@canyon.wittsend.com>
References: <490281E1.1090305@redhat.com>
	<1225220265.12100.80.camel@canyon.wittsend.com>
Message-ID: <1225220636.2157.92.camel@luminos.localdomain>

On Tue, 2008-10-28 at 14:57 -0400, Michael H. Warfield wrote:
> Boot 
>       * The installed system MUST boot and start up properly.
> ==
> 
>         Those bugs are "failure to boot" which fails to meet the condition that
> the install "MUST" boot.  There are several scenarios involving SCSI
> drivers (and maybe one PATA) in both real and VMware environments which
> fail this.

As with all criteria, there is a judgment call to be made, and that is
how many systems this can effect.  Currently, with the exception for
vmware, this seems to be a pretty small set of people effected, but
folks are working on these bugs.  I don't believe we'd slip the Preview
release for these bugs, and I'm still not sure about slipping the final
release either.  I'm looking to get more info from the maintainers
involved before making any final decisions.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/25063d14/attachment.sig>

From mhw at WittsEnd.com  Tue Oct 28 19:10:42 2008
From: mhw at WittsEnd.com (Michael H. Warfield)
Date: Tue, 28 Oct 2008 15:10:42 -0400
Subject: Blocker Bug Review Meeting :: Monday @ 14:00 UTC
In-Reply-To: <1225220636.2157.92.camel@luminos.localdomain>
References: <490281E1.1090305@redhat.com>
	<1225220265.12100.80.camel@canyon.wittsend.com>
	<1225220636.2157.92.camel@luminos.localdomain>
Message-ID: <1225221042.12100.85.camel@canyon.wittsend.com>

On Tue, 2008-10-28 at 12:03 -0700, Jesse Keating wrote:
> On Tue, 2008-10-28 at 14:57 -0400, Michael H. Warfield wrote:
> > Boot 
> >       * The installed system MUST boot and start up properly.
> > ==
> > 
> >         Those bugs are "failure to boot" which fails to meet the condition that
> > the install "MUST" boot.  There are several scenarios involving SCSI
> > drivers (and maybe one PATA) in both real and VMware environments which
> > fail this.

> As with all criteria, there is a judgment call to be made, and that is
> how many systems this can effect.  Currently, with the exception for
> vmware, this seems to be a pretty small set of people effected, but
> folks are working on these bugs.  I don't believe we'd slip the Preview
> release for these bugs, and I'm still not sure about slipping the final
> release either.  I'm looking to get more info from the maintainers
> involved before making any final decisions.

	Fair enough.  That's a lot more than I knew earlier and is what I was
hoping to see.

	Many thanks!

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/6d98bce3/attachment.sig>

From orion at cora.nwra.com  Tue Oct 28 19:20:46 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 28 Oct 2008 13:20:46 -0600
Subject: bash %postun script failure in anaconda install and mock
In-Reply-To: <1225179655.3897.38.camel@beck.corsepiu.local>
References: <1225179655.3897.38.camel@beck.corsepiu.local>
Message-ID: <4907660E.5090201@cora.nwra.com>

Ralf Corsepius wrote:
> Hi,
> 
> Since this morning, initializing fedora-rawhide-i386 mock chroots fail
> for me on FC9:
> 
> # mock -r fedora-rawhide-i386 init
> INFO: mock.py version 0.9.9 starting...
> ...
> ERROR: Command failed: 
>  # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-i386/root/
> groupinstall buildsys-build
> ...
> /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot
> open shared object file: No such file or directory
> error: %post(bash-3.2-28.fc10.i386) scriptlet failed, exit status 127

Hm, I just saw (20081027 install):

Installing bash-3.2-28.fc10.x86_64
/bin/sh: error while loading shared libraries: libtinfo.so.5: cannot 
open shared object file: No such file or directory
warning: %post(bash-3.2-28.fc10.x86_64) scriptlet failed, exit status 127

in my rawhide anaconda install log too.

I made a note of it here: https://bugzilla.redhat.com/show_bug.cgi?id=433579

because it seems like a transaction ordering issue.  Bash has a 
Requires(post) on /bin/sh, /bin/sh is provided by bash, which requires 
libtinfo.so.5, which is provided by ncurses-libs and needs to be 
installed first.  But ncurses-libs is getting installed after bash. 
Perhaps the circularity of the argument is giving rpm trouble.


-- 
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 cdahlin at redhat.com  Tue Oct 28 20:06:55 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 16:06:55 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49075BDB.1010401@gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>
	<49075BDB.1010401@gmail.com>
Message-ID: <490770DF.8020304@redhat.com>

Les Mikesell wrote:
> Casey Dahlin wrote:
>> >>>    
>>> True, but it's one brick in a lengthy series of stupid and silly
>>> decisions, which have been gradually running down Fedora into this
>>> single-user windows clone it has evolved into.
>>>
>>>   
>> Are you serious? Really? You must have a very tenuous grasp of OS 
>> internals.
>
> No, every change requires extensive documentation and retraining or 
> you will have confused and disgruntled users.
>
>> Who does this affect?
>> 1) People using the console a lot who also run X (remember, runlevel 
>> 3 hasn't changed). Desktop users don't use consoles, server users 
>> don't use X (I hope). Only a few species of geek remain.
>
> This dichotomy exists only in your imagination.  Desktop users 
> sometimes interact with servers, server users nearly always interact 
> with desktops.
>

The users are the same. The computers, however, are different.

>> 2) People recovering from X crashes. Bugs. Errors. Things we could be 
>> fixing and making not happen rather than accommodating this bizzare 
>> F1 fetish.
>
> People reading documentation.  Please change the behavior _after_ 
> updating all existing documentation.
>
Documentation changes need to go out /at/ the time of change. Not 
before, not after (though they do need to be prepared ahead of time). I 
know for the documentation we control the effort will be made to keep 
that up to date. There's been a recent influx of new contributors 
recently that care about this area a lot and are doing their best.

For documentation we don't control, well, there will always be issues.

I should also point out that for people that know about VTs, the mental 
fallback pattern probably handles this well. *Ctrl+Alt+F1* "Huh?" 
*Ctrl+Alt+F1* "What the..." *Ctrl+Alt+F2* "Hmm, that's weird" 
*Ctrl+Alt+F1* "Oh, ok."

--CJD



From dominik at greysector.net  Tue Oct 28 20:17:57 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 28 Oct 2008 21:17:57 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <faa16b610810281003h70ed6922o3d62303a6a26214c@mail.gmail.com>
References: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
	<1225212308.3589.59.camel@eagle.danny.cz>
	<1225212975.3897.127.camel@beck.corsepiu.local>
	<faa16b610810281003h70ed6922o3d62303a6a26214c@mail.gmail.com>
Message-ID: <20081028201756.GA28444@mokona.greysector.net>

On Tuesday, 28 October 2008 at 18:03, Colin Walters wrote:
> On Tue, Oct 28, 2008 at 12:56 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >
> > Good idea. Have a "single-user/single-seat" vs. ""multiuser" toggle in
> > the install ;)
> 
> Ralf, the desktop team has done quite a bit of work relating to
> multiple user scenarios such as fast user switching, GNOME user share,
> ConsoleKit building a better foundation for multiseat, etc.  About the
> only thing that isn't yet fully fleshed out for multiuser is
> NetworkManager, but the old system of "run system-config-network"
> wasn't really any better.  The system settings work going on in NM
> should improve things further.

As long as I keep loosing my network connection upon log-out,
NetworkManager is not an option and has no place on my machines.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From notting at redhat.com  Tue Oct 28 20:22:24 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 28 Oct 2008 16:22:24 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028154419.GB48208@dspnet.fr.eu.org>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu> <49072AD3.1010603@redhat.com>
	<20081028154419.GB48208@dspnet.fr.eu.org>
Message-ID: <20081028202224.GA8452@nostromo.devel.redhat.com>

Olivier Galibert (galibert at pobox.com) said: 
> > Look at the F keys on your keyboard. The whole of your gripe lies within 
> > the space of 6 inches. Lets not have a flame war today. Lets just move 
> > our habits 6 inches to the left and let life be good.
> 
> 6 inches to the left is the phone.
> 
> Yes, I care.  The self-declared "desktop" guys, which for most of them
> don't seem to have met a user in their life, have decided a while ago
> that whoever doesn't fit their imaginary use case is irrelevant and
> can be ignored.

Don't worry, they're coming for your spouses and children next! Seriously,
I'm not sure how this sort of statement provides useful context to the
discussion.

1) Reducing the amount of flicker and useless mode switching on startup
is definitely a good thing
2) From a logical standpoint, the first tty should be for the most important
user interaction. If you're booting in text mode, that's a getty. If
you're booting with a GUI login... that's the GUI.

Bill



From notting at redhat.com  Tue Oct 28 20:26:24 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 28 Oct 2008 16:26:24 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <200810281509.40552.opensource@till.name>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<200810281509.40552.opensource@till.name>
Message-ID: <20081028202624.GB8452@nostromo.devel.redhat.com>

Till Maas (opensource at till.name) said: 
> Imho then the kernel should be patched to start booting graphically using tty7 
> and not tty1. Then you have no switching and do not disturb text-only 
> machines.

Having the kernel parse its own commandline for a runlevel (a concept that has
nothing to do with the kernel, and doesn't even exist under some init systems)
and then choosing to rearrange the tty init sequence based on that?

I'll pass.

Bill



From notting at redhat.com  Tue Oct 28 20:31:53 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 28 Oct 2008 16:31:53 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225215496.3897.158.camel@beck.corsepiu.local>
References: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
Message-ID: <20081028203153.GC8452@nostromo.devel.redhat.com>

Ralf Corsepius (rc040203 at freenet.de) said: 
> > Who does this affect?
> E.g. application devs, documentation writers, experienced users.

Much like passwd auth to PAM. Heck, passwd -> shadow.  twm -> fvwm
-> AnotherLevel -> GNOME.

The only thing constant is change.

Bill



From notting at redhat.com  Tue Oct 28 20:34:07 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 28 Oct 2008 16:34:07 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028201756.GA28444@mokona.greysector.net>
References: <49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
	<1225212308.3589.59.camel@eagle.danny.cz>
	<1225212975.3897.127.camel@beck.corsepiu.local>
	<faa16b610810281003h70ed6922o3d62303a6a26214c@mail.gmail.com>
	<20081028201756.GA28444@mokona.greysector.net>
Message-ID: <20081028203407.GD8452@nostromo.devel.redhat.com>

Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> As long as I keep loosing my network connection upon log-out,
> NetworkManager is not an option and has no place on my machines.

Right-click -> "Edit connections", pick your preferred setting, 
click on 'System setting'.

(Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)

Bill



From fedora at shmuelhome.mine.nu  Tue Oct 28 20:35:43 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Tue, 28 Oct 2008 22:35:43 +0200
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028202224.GA8452@nostromo.devel.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>
	<49072AD3.1010603@redhat.com>	<20081028154419.GB48208@dspnet.fr.eu.org>
	<20081028202224.GA8452@nostromo.devel.redhat.com>
Message-ID: <4907779F.30609@shmuelhome.mine.nu>

Bill Nottingham wrote:
> 1) Reducing the amount of flicker and useless mode switching on startup
> is definitely a good thing
> 2) From a logical standpoint, the first tty should be for the most important
> user interaction. If you're booting in text mode, that's a getty. If
> you're booting with a GUI login... that's the GUI.
>
> Bill
We disagree on the second point. I don't see where the GUI login cares 
which tty is being used. But humans switching to console mode do want to 
know which parameter to use.



From cdahlin at redhat.com  Tue Oct 28 20:39:05 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 16:39:05 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028202624.GB8452@nostromo.devel.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<200810281509.40552.opensource@till.name>
	<20081028202624.GB8452@nostromo.devel.redhat.com>
Message-ID: <49077869.9030706@redhat.com>

Bill Nottingham wrote:
> Till Maas (opensource at till.name) said: 
>   
>> Imho then the kernel should be patched to start booting graphically using tty7 
>> and not tty1. Then you have no switching and do not disturb text-only 
>> machines.
>>     
>
> Having the kernel parse its own commandline for a runlevel (a concept that has
> nothing to do with the kernel, and doesn't even exist under some init systems)
> and then choosing to rearrange the tty init sequence based on that?
>
> I'll pass.
>
> Bill
>
>   
I don't think that's what he meant. I think he meant simply for tty7 to 
always be the active tty on boot. That's a bit easier to stomach.

--CJD



From dominik at greysector.net  Tue Oct 28 20:38:09 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 28 Oct 2008 21:38:09 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028203407.GD8452@nostromo.devel.redhat.com>
References: <91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
	<1225212308.3589.59.camel@eagle.danny.cz>
	<1225212975.3897.127.camel@beck.corsepiu.local>
	<faa16b610810281003h70ed6922o3d62303a6a26214c@mail.gmail.com>
	<20081028201756.GA28444@mokona.greysector.net>
	<20081028203407.GD8452@nostromo.devel.redhat.com>
Message-ID: <20081028203808.GB28444@mokona.greysector.net>

On Tuesday, 28 October 2008 at 21:34, Bill Nottingham wrote:
> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > As long as I keep loosing my network connection upon log-out,
> > NetworkManager is not an option and has no place on my machines.
> 
> Right-click -> "Edit connections", pick your preferred setting, 
> click on 'System setting'.
> 
> (Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)

Wrong. wpa_supplicant works just fine without NM. In fact, because of this
deficiency (and the fact that NM fails to associate with my WPA network
at work 9 out of 10 times), I'm using wpa_supplicant directly, without
NM. At least it works.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From lesmikesell at gmail.com  Tue Oct 28 20:40:55 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 28 Oct 2008 15:40:55 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490770DF.8020304@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<49075BDB.1010401@gmail.com>
	<490770DF.8020304@redhat.com>
Message-ID: <490778D7.5080609@gmail.com>

Casey Dahlin wrote:
> 
>>> Who does this affect?
>>> 1) People using the console a lot who also run X (remember, runlevel 
>>> 3 hasn't changed). Desktop users don't use consoles, server users 
>>> don't use X (I hope). Only a few species of geek remain.
>>
>> This dichotomy exists only in your imagination.  Desktop users 
>> sometimes interact with servers, server users nearly always interact 
>> with desktops.
>>
> 
> The users are the same. The computers, however, are different.

The user is the one that needs consistency.

>>> 2) People recovering from X crashes. Bugs. Errors. Things we could be 
>>> fixing and making not happen rather than accommodating this bizzare 
>>> F1 fetish.
>>
>> People reading documentation.  Please change the behavior _after_ 
>> updating all existing documentation.
>>
> Documentation changes need to go out /at/ the time of change. Not 
> before, not after (though they do need to be prepared ahead of time). I 
> know for the documentation we control the effort will be made to keep 
> that up to date. There's been a recent influx of new contributors 
> recently that care about this area a lot and are doing their best.

But you find documentation by doing a google search. How do you plan to 
replace all of that, along with the memory of people who read it earlier?

> For documentation we don't control, well, there will always be issues.
> 
> I should also point out that for people that know about VTs, the mental 
> fallback pattern probably handles this well. *Ctrl+Alt+F1* "Huh?" 
> *Ctrl+Alt+F1* "What the..." *Ctrl+Alt+F2* "Hmm, that's weird" 
> *Ctrl+Alt+F1* "Oh, ok."

Yes, that might be a reasonable description of someone's encounter with 
fedora.  At least someone who is already used to the inability to stick 
to a user interface.  But is that the way you want people to respond to 
an operating system - punch keys at random until something appears to work?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From notting at redhat.com  Tue Oct 28 20:43:15 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 28 Oct 2008 16:43:15 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49077869.9030706@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<200810281509.40552.opensource@till.name>
	<20081028202624.GB8452@nostromo.devel.redhat.com>
	<49077869.9030706@redhat.com>
Message-ID: <20081028204315.GF8452@nostromo.devel.redhat.com>

Casey Dahlin (cdahlin at redhat.com) said: 
>>> Imho then the kernel should be patched to start booting graphically 
>>> using tty7 and not tty1. Then you have no switching and do not 
>>> disturb text-only machines.
>>
>> Having the kernel parse its own commandline for a runlevel (a concept that has
>> nothing to do with the kernel, and doesn't even exist under some init systems)
>> and then choosing to rearrange the tty init sequence based on that?
>
> I don't think that's what he meant. I think he meant simply for tty7 to  
> always be the active tty on boot. That's a bit easier to stomach.

If you don't add the bits I mentioned, then you'll get a blank tty7
when you boot in text mode. Which is presumably not what you want.

Bill



From cdahlin at redhat.com  Tue Oct 28 20:48:56 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 16:48:56 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490778D7.5080609@gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<49075BDB.1010401@gmail.com>	<490770DF.8020304@redhat.com>
	<490778D7.5080609@gmail.com>
Message-ID: <49077AB8.5010604@redhat.com>

Les Mikesell wrote:
> Casey Dahlin wrote:
>>
>>>> Who does this affect?
>>>> 1) People using the console a lot who also run X (remember, 
>>>> runlevel 3 hasn't changed). Desktop users don't use consoles, 
>>>> server users don't use X (I hope). Only a few species of geek remain.
>>>
>>> This dichotomy exists only in your imagination.  Desktop users 
>>> sometimes interact with servers, server users nearly always interact 
>>> with desktops.
>>>
>>
>> The users are the same. The computers, however, are different.
>
> The user is the one that needs consistency.
>
Ctrl+Alt+F1 brings up the primary user interface. Sounds consistent to me.

>>>> 2) People recovering from X crashes. Bugs. Errors. Things we could 
>>>> be fixing and making not happen rather than accommodating this 
>>>> bizzare F1 fetish.
>>>
>>> People reading documentation.  Please change the behavior _after_ 
>>> updating all existing documentation.
>>>
>> Documentation changes need to go out /at/ the time of change. Not 
>> before, not after (though they do need to be prepared ahead of time). 
>> I know for the documentation we control the effort will be made to 
>> keep that up to date. There's been a recent influx of new 
>> contributors recently that care about this area a lot and are doing 
>> their best.
>
> But you find documentation by doing a google search. How do you plan 
> to replace all of that, along with the memory of people who read it 
> earlier?
>
You're right. Stop the release, we need to ship Red Hat 7.3 instead.
>> For documentation we don't control, well, there will always be issues.
>>
>> I should also point out that for people that know about VTs, the 
>> mental fallback pattern probably handles this well. *Ctrl+Alt+F1* 
>> "Huh?" *Ctrl+Alt+F1* "What the..." *Ctrl+Alt+F2* "Hmm, that's weird" 
>> *Ctrl+Alt+F1* "Oh, ok."
>
> Yes, that might be a reasonable description of someone's encounter 
> with fedora.  At least someone who is already used to the inability to 
> stick to a user interface.  But is that the way you want people to 
> respond to an operating system - punch keys at random until something 
> appears to work?
People have more in common with chimpanzees than you realize.

--CJD



From cdahlin at redhat.com  Tue Oct 28 20:54:20 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 16:54:20 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028204315.GF8452@nostromo.devel.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<200810281509.40552.opensource@till.name>	<20081028202624.GB8452@nostromo.devel.redhat.com>	<49077869.9030706@redhat.com>
	<20081028204315.GF8452@nostromo.devel.redhat.com>
Message-ID: <49077BFC.40807@redhat.com>

Bill Nottingham wrote:
> Casey Dahlin (cdahlin at redhat.com) said: 
>   
>>>> Imho then the kernel should be patched to start booting graphically 
>>>> using tty7 and not tty1. Then you have no switching and do not 
>>>> disturb text-only machines.
>>>>         
>>> Having the kernel parse its own commandline for a runlevel (a concept that has
>>> nothing to do with the kernel, and doesn't even exist under some init systems)
>>> and then choosing to rearrange the tty init sequence based on that?
>>>       
>> I don't think that's what he meant. I think he meant simply for tty7 to  
>> always be the active tty on boot. That's a bit easier to stomach.
>>     
>
> If you don't add the bits I mentioned, then you'll get a blank tty7
> when you boot in text mode. Which is presumably not what you want.
>
> Bill
>
>   
We could either offer a getty on tty7 (not too hard) or we could instead 
add a small API to the kernel that would allow remapping which F key 
went to which tty, so you could have ctrl+alt+f1 bring up tty7. That way 
we could remap things so the user got the correct behavior.

We wouldn't have to actually /do/ this, but if the API were there, we 
can tell the people who care to go figure it out.

--CJD



From opensource at till.name  Tue Oct 28 21:00:25 2008
From: opensource at till.name (Till Maas)
Date: Tue, 28 Oct 2008 22:00:25 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49077869.9030706@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<20081028202624.GB8452@nostromo.devel.redhat.com>
	<49077869.9030706@redhat.com>
Message-ID: <200810282200.35971.opensource@till.name>

On Tue October 28 2008, Casey Dahlin wrote:
> Bill Nottingham wrote:
> > Till Maas (opensource at till.name) said:
> >> Imho then the kernel should be patched to start booting graphically
> >> using tty7 and not tty1. Then you have no switching and do not disturb
> >> text-only machines.
> >
> > Having the kernel parse its own commandline for a runlevel (a concept
> > that has nothing to do with the kernel, and doesn't even exist under some
> > init systems) and then choosing to rearrange the tty init sequence based
> > on that?
> >
> > I'll pass.

> I don't think that's what he meant. I think he meant simply for tty7 to
> always be the active tty on boot. That's a bit easier to stomach.

I meant that if rhgb is passed to the kernel, then tty7 should be the active 
tty on boot and be used for the graphical display and then after booting 
finished, X can be started on tty7 without a flicker. If X is not going to be 
started, I guess it does not hurt to either switch to tty1 or add another 
getty to tty7.

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/20081028/8ea14a24/attachment.sig>

From opensource at till.name  Tue Oct 28 21:07:43 2008
From: opensource at till.name (Till Maas)
Date: Tue, 28 Oct 2008 22:07:43 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028202224.GA8452@nostromo.devel.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<20081028154419.GB48208@dspnet.fr.eu.org>
	<20081028202224.GA8452@nostromo.devel.redhat.com>
Message-ID: <200810282207.44292.opensource@till.name>

On Tue October 28 2008, Bill Nottingham wrote:

> 2) From a logical standpoint, the first tty should be for the most
> important user interaction. If you're booting in text mode, that's a getty.
> If you're booting with a GUI login... that's the GUI.

But this does not work if someone firsts boots into text mode and then starts 
the GUI, either via startx or switching the runlevel. I doubt that someone 
starts the GUI from the TUI without the intent to use the GUI afterwards. The 
logic does also not work if someone wants to use any other tty than the 
current one, because the one the user switches to will always become the one 
used for the most important user interaction. ;-)

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/20081028/0636a1e0/attachment.sig>

From debarshi.ray at gmail.com  Tue Oct 28 21:10:57 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 29 Oct 2008 02:40:57 +0530
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <sabcq7d1k.fsf@allele2.eebweb.arizona.edu>
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<sabcq7d1k.fsf@allele2.eebweb.arizona.edu>
Message-ID: <3170f42f0810281410g4dc741b9jbeaa929b6a45ac0a@mail.gmail.com>

> gnome-build, anjuta are still broken in rawhide as of 20081016 and I
> don't see any new builds in koji.  The development freeze is coming in
> one day, can you please fix these builds ASAP as you promised above
> before the freeze?

Anjuta 2.24 needed some testing and I did not want to push it into
Rawhide before testing some of its basic functionality. This,
unfortunately, takes some time and I filed a ticket with the Release
Engineering team: https://fedorahosted.org/rel-eng/ticket/888

Happy hacking,
Debarshi



From paul at xelerance.com  Tue Oct 28 21:35:13 2008
From: paul at xelerance.com (Paul Wouters)
Date: Tue, 28 Oct 2008 17:35:13 -0400 (EDT)
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028203153.GC8452@nostromo.devel.redhat.com>
References: <91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<20081028203153.GC8452@nostromo.devel.redhat.com>
Message-ID: <Pine.LNX.4.64.0810281734350.22224@newtla.xelerance.com>

On Tue, 28 Oct 2008, Bill Nottingham wrote:

> Ralf Corsepius (rc040203 at freenet.de) said: 
> > > Who does this affect?
> > E.g. application devs, documentation writers, experienced users.
> 
> Much like passwd auth to PAM. Heck, passwd -> shadow.  twm -> fvwm
> -> AnotherLevel -> GNOME.
> 
> The only thing constant is change.

One day, my homedir will not have dot files that prevent me to login X 
upon upgrading :)

Paul



From henriquecsj at gmail.com  Tue Oct 28 21:32:08 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Tue, 28 Oct 2008 14:32:08 -0700 (PDT)
Subject: Scilab on Fedora and CeCILL license
Message-ID: <559178.81389.qm@web45413.mail.sp1.yahoo.com>

Hi all,
Some time ago (FC6, F7?) SciLab[1] was in the Fedora repos but it looks out now.
Scilab is an amazing scientific software and I'm interested in packaging it but first I want to know if is someone working on it and if the CeCILL license[2] is Fedora compatible.

[1] - http://www.scilab.org/
[2] - http://www.cecill.info/index.en.html

Regards


 
Henrique "LonelySpooky" Junior
________________________________
"In a world without walls and fences, who needs windows and gates?!"



      Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses




From jlb17 at duke.edu  Tue Oct 28 21:40:01 2008
From: jlb17 at duke.edu (Joshua Baker-LePain)
Date: Tue, 28 Oct 2008 17:40:01 -0400 (EDT)
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028213134.21EB661A0DA@hormel.redhat.com>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
Message-ID: <alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>

On Tue, 28 Oct 2008 at 5:31pm, Bill Nottingham <notting at redhat.com> wrote

> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > As long as I keep loosing my network connection upon log-out,
> > NetworkManager is not an option and has no place on my machines.
> 
> Right-click -> "Edit connections", pick your preferred setting, 
> click on 'System setting'.

Right-click on what?  I run fvwm.  How are non-DE users supposed to 
interact with NM?

> (Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)

Yes, yes it does.  And it should.

(P.S.  Sorry for the thread breakage -- I'm a digest subscriber.)

-- 
Joshua Baker-LePain
QB3 Shared Cluster Sysadmin
UCSF



From henriquecsj at gmail.com  Tue Oct 28 21:41:54 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Tue, 28 Oct 2008 19:41:54 -0200
Subject: Orphaning azureus
In-Reply-To: <20081028171711.3c1f1cc9@cheeky>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
	<20081028171711.3c1f1cc9@cheeky>
Message-ID: <4f629b520810281441i397ff7ch3621f2a73fe92a2f@mail.gmail.com>

Its a shame... =(

2008/10/28 Stefan Posdzich <cheekyboinc at foresightlinux.org>

> I have tried now some days with this package and i cant get warm with it
> (+ java).
> I will orphan it again, i hope it will find someone who can handle
> this kind of apps!
>
> https://admin.fedoraproject.org/pkgdb/packages/name/azureus
>
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=azureus
>
> best regards
> Stefan
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Henrique "LonelySpooky" Junior
http://www.lonelyspooky.com
-------------------------------------------------------------
"In a world without walls and fences, who needs windows and gates?!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/6e99084d/attachment.htm>

From tibbs at math.uh.edu  Tue Oct 28 21:42:01 2008
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 28 Oct 2008 16:42:01 -0500
Subject: Scilab on Fedora and CeCILL license
In-Reply-To: <559178.81389.qm@web45413.mail.sp1.yahoo.com>
References: <559178.81389.qm@web45413.mail.sp1.yahoo.com>
Message-ID: <ufa1vy0wg5y.fsf@epithumia.math.uh.edu>

>>>>> "HJ" == Henrique Junior <henriquecsj at gmail.com> writes:

HJ> Hi all, Some time ago (FC6, F7?) SciLab[1] was in the Fedora repos
HJ> but it looks out now. Scilab is an amazing scientific software and
HJ> I'm interested in packaging it but first I want to know if is
HJ> someone working on it and if the CeCILL license[2] is Fedora
HJ> compatible.

The CeCILL license is listed as being acceptable on
http://fedoraproject.org/wiki/Licensing.

I do not believe that scilab has ever been in Fedora as its license
has only recently become acceptable.

 - J<



From cdahlin at redhat.com  Tue Oct 28 21:43:39 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 17:43:39 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
Message-ID: <4907878B.3050008@redhat.com>

Joshua Baker-LePain wrote:
> On Tue, 28 Oct 2008 at 5:31pm, Bill Nottingham <notting at redhat.com> wrote
>
>> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: > As 
>> long as I keep loosing my network connection upon log-out,
>> > NetworkManager is not an option and has no place on my machines.
>>
>> Right-click -> "Edit connections", pick your preferred setting, click 
>> on 'System setting'.
>
> Right-click on what?  I run fvwm.  How are non-DE users supposed to 
> interact with NM?
Obviously someone who uses fvwm like yourself needs to solve this problem

--CJD



From cra at WPI.EDU  Tue Oct 28 21:45:19 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 17:45:19 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028203153.GC8452@nostromo.devel.redhat.com>
References: <49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<20081028203153.GC8452@nostromo.devel.redhat.com>
Message-ID: <20081028214519.GK19205@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
> Ralf Corsepius (rc040203 at freenet.de) said: 
> > > Who does this affect?
> > E.g. application devs, documentation writers, experienced users.
> 
> Much like passwd auth to PAM. Heck, passwd -> shadow.  twm -> fvwm
> -> AnotherLevel -> GNOME.
> 
> The only thing constant is change.

Every day it's the same old thing!  Variety!  I wan't something 
/different/!  Bring me the hasenfeffer!



From nicolas.mailhot at laposte.net  Tue Oct 28 21:48:45 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Oct 2008 22:48:45 +0100
Subject: Scilab on Fedora and CeCILL license
In-Reply-To: <ufa1vy0wg5y.fsf@epithumia.math.uh.edu>
References: <559178.81389.qm@web45413.mail.sp1.yahoo.com>
	<ufa1vy0wg5y.fsf@epithumia.math.uh.edu>
Message-ID: <1225230525.18658.0.camel@arekh.okg>

Le mardi 28 octobre 2008 ? 16:42 -0500, Jason L Tibbitts III a ?crit :

> The CeCILL license is listed as being acceptable on
> http://fedoraproject.org/wiki/Licensing.

Also
http://www.fsf.org/licensing/licenses/index_html#CeCILL

-- 
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/20081028/194aca19/attachment.sig>

From dominik at greysector.net  Tue Oct 28 21:54:05 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 28 Oct 2008 22:54:05 +0100
Subject: Scilab on Fedora and CeCILL license
In-Reply-To: <559178.81389.qm@web45413.mail.sp1.yahoo.com>
References: <559178.81389.qm@web45413.mail.sp1.yahoo.com>
Message-ID: <20081028215405.GC28444@mokona.greysector.net>

On Tuesday, 28 October 2008 at 22:32, Henrique Junior wrote:
> Hi all,
> Some time ago (FC6, F7?) SciLab[1] was in the Fedora repos
> but it looks out now.
> Scilab is an amazing scientific software and I'm interested
> in packaging it but first I want to know if is someone working
> on it and if the CeCILL license[2] is Fedora compatible.

Hi and welcome. Your enthusiasm is appreciated.

Yes, CeCILL license is acceptable in Fedora.

As for packagin scilab, I suggest you join forces with Nicolas Chauvet
(kwizart) and D Haley, who are working on packaging scilab and its
dependencies. It's going to be an uphill road, as some of the subdependecies
are turning out to be non-free. See bug 464781[1] for some current work
on this.

Regards,
R.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=464781

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From cdahlin at redhat.com  Tue Oct 28 21:56:46 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 28 Oct 2008 17:56:46 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028214519.GK19205@angus.ind.WPI.EDU>
References: <49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>	<20081028203153.GC8452@nostromo.devel.redhat.com>
	<20081028214519.GK19205@angus.ind.WPI.EDU>
Message-ID: <49078A9E.9060508@redhat.com>

Chuck Anderson wrote:
> On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
>   
>> Ralf Corsepius (rc040203 at freenet.de) said: 
>>     
>>>> Who does this affect?
>>>>         
>>> E.g. application devs, documentation writers, experienced users.
>>>       
>> Much like passwd auth to PAM. Heck, passwd -> shadow.  twm -> fvwm
>> -> AnotherLevel -> GNOME.
>>
>> The only thing constant is change.
>>     
>
> Every day it's the same old thing!  Variety!  I wan't something 
> /different/!  Bring me the hasenfeffer!
>
>   
I have no idea what you just said.

--CJD



From wwoods at redhat.com  Tue Oct 28 21:56:35 2008
From: wwoods at redhat.com (Will Woods)
Date: Tue, 28 Oct 2008 17:56:35 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
Message-ID: <1225230995.6359.2.camel@zebes.localdomain>

On Tue, 2008-10-28 at 17:40 -0400, Joshua Baker-LePain wrote:
> On Tue, 28 Oct 2008 at 5:31pm, Bill Nottingham <notting at redhat.com> wrote
> 
> > Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > > As long as I keep loosing my network connection upon log-out,
> > > NetworkManager is not an option and has no place on my machines.
> > 
> > Right-click -> "Edit connections", pick your preferred setting, 
> > click on 'System setting'.
> 
> Right-click on what?  I run fvwm.  How are non-DE users supposed to 
> interact with NM?

System->Preferences->Network Configuration. Or just run
"nm-connection-editor" by hand if your windowmanager is too old and
crusty for newfangled things like "menus".

-w

(how did this turn into a NetworkManager thread, anyway?)



From cra at WPI.EDU  Tue Oct 28 22:02:40 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 18:02:40 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49078A9E.9060508@redhat.com>
References: <4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<20081028203153.GC8452@nostromo.devel.redhat.com>
	<20081028214519.GK19205@angus.ind.WPI.EDU>
	<49078A9E.9060508@redhat.com>
Message-ID: <20081028220240.GM19205@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 05:56:46PM -0400, Casey Dahlin wrote:
> Chuck Anderson wrote:
>> On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
>>   
>>> Ralf Corsepius (rc040203 at freenet.de) said:     
>>>>> Who does this affect?
>>>>>         
>>>> E.g. application devs, documentation writers, experienced users.
>>>>       
>>> Much like passwd auth to PAM. Heck, passwd -> shadow.  twm -> fvwm
>>> -> AnotherLevel -> GNOME.
>>>
>>> The only thing constant is change.
>>>     
>>
>> Every day it's the same old thing!  Variety!  I wan't something  
>> /different/!  Bring me the hasenfeffer!
>>
>>   
> I have no idea what you just said.

Sorry, a little Bugs Bunny joke.



From rc040203 at freenet.de  Tue Oct 28 22:04:41 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 23:04:41 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <faa16b610810281003h70ed6922o3d62303a6a26214c@mail.gmail.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<49073B1F.4010604@odu.neva.ru>
	<1225212308.3589.59.camel@eagle.danny.cz>
	<1225212975.3897.127.camel@beck.corsepiu.local>
	<faa16b610810281003h70ed6922o3d62303a6a26214c@mail.gmail.com>
Message-ID: <1225231481.3897.227.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 13:03 -0400, Colin Walters wrote:
> On Tue, Oct 28, 2008 at 12:56 PM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> >
> > Good idea. Have a "single-user/single-seat" vs. ""multiuser" toggle in
> > the install ;)
> 
> Ralf, the desktop team has done quite a bit of work relating to
> multiple user scenarios such as fast user switching, GNOME user share,
> ConsoleKit building a better foundation for multiseat, etc.
We will see how things have evolved with FC10. My experiences with FC9's
desktop so far have not been "overwhelming" and my experiments with
rawhide over the last couple of weeks, haven't been much better.

>   About the only thing that isn't yet fully fleshed out for multiuser is
> NetworkManager,
Correct, no network profiles, no support for autofs mounted homes, no
separation of "system-wide/user" choices, permanent issues with
gnome-keyring, SELinux, broken or unreadable dialogs, no documentation,
etc.

>  but the old system of "run system-config-network"
> wasn't really any better.
Yes, one buggered system is being replaced with a bad one.

The major advantage of the old "system-config-network": It at least
behaved deterministic. Using NM is like "herding a sack of fleas" as we
say in German.

>   The system settings work going on in NM
> should improve things further.




From konrad at tylerc.org  Tue Oct 28 22:05:20 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 28 Oct 2008 15:05:20 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225230995.6359.2.camel@zebes.localdomain>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<1225230995.6359.2.camel@zebes.localdomain>
Message-ID: <200810281505.20253.konrad@tylerc.org>

On Tuesday 28 October 2008 02:56:35 pm Will Woods wrote:
> (how did this turn into a NetworkManager thread, anyway?)

"Change is bad! Complain, complain, whine, whine!"

-- 
Conrad Meyer <konrad at tylerc.org>




From mw_triad at users.sourceforge.net  Tue Oct 28 22:14:56 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 28 Oct 2008 17:14:56 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028204315.GF8452@nostromo.devel.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<200810281509.40552.opensource@till.name>	<20081028202624.GB8452@nostromo.devel.redhat.com>	<49077869.9030706@redhat.com>
	<20081028204315.GF8452@nostromo.devel.redhat.com>
Message-ID: <ge82t0$ql6$1@ger.gmane.org>

Bill Nottingham wrote:
> Casey Dahlin said: 
>> I don't think that's what he meant. I think he meant simply for tty7 to  
>> always be the active tty on boot. That's a bit easier to stomach.
> 
> If you don't add the bits I mentioned, then you'll get a blank tty7
> when you boot in text mode. Which is presumably not what you want.

So add an explicit switch to tty1 in runlevel 3. It shouldn't flicker 
because it's not changing display modes (at least, I don't remember 
flicker switching between mingetty VT's; can't check right now because 
X->VGA switching doesn't work on this machine). Where's the problem?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
ESNR: signal to noise ratio too low (try a mailer without disclaimers)



From dcantrell at redhat.com  Tue Oct 28 22:31:27 2008
From: dcantrell at redhat.com (David Cantrell)
Date: Tue, 28 Oct 2008 12:31:27 -1000
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
Message-ID: <20081028223126.GD197@rabbet.honolulu.burdell.org>

On Tue, Oct 28, 2008 at 11:31:40AM +0000, Michael Cutler wrote:
> (1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.

I'm not opposed to this, but I'm also not opposed to it staying where it is.

> (2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.

I'm not in favor of this.  The situation you're describing is exactly why we
wanted to get rid of the network configuration screen.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/0b9f8b5a/attachment.sig>

From jspaleta at gmail.com  Tue Oct 28 22:36:22 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Oct 2008 14:36:22 -0800
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028181855.GJ19205@angus.ind.WPI.EDU>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
	<20081028181855.GJ19205@angus.ind.WPI.EDU>
Message-ID: <604aa7910810281536t334447feqbecea6f6ac5a2873@mail.gmail.com>

On Tue, Oct 28, 2008 at 10:18 AM, Chuck Anderson <cra at wpi.edu> wrote:
> I think it is a perfectly reasonable default to have DHCP enabled by
> default for all network interfaces, whether NetworkManager is used or
> not.


Is this solvable with initscript logic? Can the network initscript
taste to see if NM is actually installed and if not ignore the
NetworkManager=yes flag?

-jef



From lesmikesell at gmail.com  Tue Oct 28 22:37:54 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 28 Oct 2008 17:37:54 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49077AB8.5010604@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<49075BDB.1010401@gmail.com>	<490770DF.8020304@redhat.com>	<490778D7.5080609@gmail.com>
	<49077AB8.5010604@redhat.com>
Message-ID: <49079442.4090202@gmail.com>

Casey Dahlin wrote:

>>
>> The user is the one that needs consistency.
>>
> Ctrl+Alt+F1 brings up the primary user interface. Sounds consistent to me.

It could have been, when you didn't have an existing user base.

>> But you find documentation by doing a google search. How do you plan 
>> to replace all of that, along with the memory of people who read it 
>> earlier?
>>
> You're right. Stop the release, we need to ship Red Hat 7.3 instead.

I'd actually like that very much, if you dropped in the security fixes 
and some decent fonts.  I have a couple of machines that have never 
crashed since that release and one that was up for over 4 years non-stop 
until I had to move it.  When you can improve on that, you would have a 
reason for change.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dcantrell at redhat.com  Tue Oct 28 22:38:49 2008
From: dcantrell at redhat.com (David Cantrell)
Date: Tue, 28 Oct 2008 12:38:49 -1000
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <1225212528.9923.3.camel@localhost.localdomain>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
Message-ID: <20081028223848.GE197@rabbet.honolulu.burdell.org>

On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
> On Tue, 2008-10-28 at 09:38 -0700, Jesse Keating wrote:
> > On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
> > > 
> > > (1). Include NetworkManager in the '@core' group, such that every
> > > install will include NetworkManager and a minimal install as described
> > > above will bring the system up with network connectivity.
> > 
> > And here we have another fun argument about how 'minimal' should the
> > minimal install be!  We've chucked yum in @core, might as well chuck
> > NetworkManager too...
> 
> Right, but we still don't turn NM on by default with chkconfig.  Which
> means even if you bring it into @core, your networking still won't work
> unless you turn NM on post-install manually.
> 
> The issue here (IIRC) was that Anaconda won't set up an ifcfg file for
> you if you don't use network to install, because the network
> configuration screen got removed as it was mostly redundant for installs
> where NM is active.
> 
> If you're not installing over the network (and thus there's no network
> configuration to save out) should the "network config" screen come back?
> Or should anaconda just activate all devices onboot with DHCP?  The
> latter sounds like a loss.  If you want stuff set up post-boot without
> NetworkManager, maybe it's not unreasonable that you have to configure
> it yourself.  What's the difference if that happens post-install or
> during install?

This is a good point.  I really don't think it's unreasonable to require any
of the following:

1) Users have to use NetworkManager to bring up a network interface.
2) Users have to run system-config-network to set up networking.
3) Users have to edit ifcfg-DEVICE files by hand.

Over the past several years, we [anaconda team] has been trying to move as
many system configuration screens out of anaconda as we can.  Only what we
need to ensure the system either (a) installs correctly or (b) reboots and
is usable.  We're down to:

   language
   keyboard
   root password
   timezone
   hostname
   boot loader (automatic unless you ask to configure it)

There are some other ideas that we could come up with too.  What if firstboot
asked you how you want to configure your network interface?  As in, exposing
the s-c-network UI or something from NetworkManager?  Just brainstorming.
These really just make what's already there more accessible after an initial
install.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/e33a49db/attachment.sig>

From rc040203 at freenet.de  Tue Oct 28 22:38:09 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 28 Oct 2008 23:38:09 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225218581.2157.87.camel@luminos.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<49075429.1040508@shmuelhome.mine.nu>
	<1225218581.2157.87.camel@luminos.localdomain>
Message-ID: <1225233489.3897.244.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 11:29 -0700, Jesse Keating wrote:
> On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
> > There were also many alternatives mentioned in this thread. And reasons 
> > were given as to why this change is a bad idea. I haven't seen any 
> > response to the alternatives. The typical response to the objections 
> > were either "don't start a flame war" or "who cares about your use 
> > case". Is feedback wanted?
> 
> well this thread has gone pretty out of control, so any chance of
> getting the people who were actually doing the work to look in on it is
> probably not going to happen.
Understood, the almighty RHs knows better, the community is dumb :(

> A more technical discussion, posed to the people who were making the
> changes could perhaps result in a discussion about why the alternatives
> either won't work, or weren't considered.

The point is: To you, your claimed 3 seconds bootup speed up is a great
achievement. To me, this "achievement" is negligible.

To me, the fact of X11 going to F1 is a usability regression.




From dcantrell at redhat.com  Tue Oct 28 22:39:31 2008
From: dcantrell at redhat.com (David Cantrell)
Date: Tue, 28 Oct 2008 12:39:31 -1000
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028181855.GJ19205@angus.ind.WPI.EDU>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
	<20081028181855.GJ19205@angus.ind.WPI.EDU>
Message-ID: <20081028223930.GF197@rabbet.honolulu.burdell.org>

On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
> On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
> > If you're not installing over the network (and thus there's no network
> > configuration to save out) should the "network config" screen come back?
> > Or should anaconda just activate all devices onboot with DHCP?  The
> > latter sounds like a loss.  If you want stuff set up post-boot without
> > NetworkManager, maybe it's not unreasonable that you have to configure
> > it yourself.  What's the difference if that happens post-install or
> > during install?
> 
> I think it is a perfectly reasonable default to have DHCP enabled by 
> default for all network interfaces, whether NetworkManager is used or 
> not.

Seriously?

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/e30e4945/attachment.sig>

From konrad at tylerc.org  Tue Oct 28 22:43:50 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 28 Oct 2008 15:43:50 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225233489.3897.244.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225218581.2157.87.camel@luminos.localdomain>
	<1225233489.3897.244.camel@beck.corsepiu.local>
Message-ID: <200810281543.50541.konrad@tylerc.org>

On Tuesday 28 October 2008 03:38:09 pm Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 11:29 -0700, Jesse Keating wrote:
> > On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
> > > There were also many alternatives mentioned in this thread. And reasons
> > > were given as to why this change is a bad idea. I haven't seen any
> > > response to the alternatives. The typical response to the objections
> > > were either "don't start a flame war" or "who cares about your use
> > > case". Is feedback wanted?
> >
> > well this thread has gone pretty out of control, so any chance of
> > getting the people who were actually doing the work to look in on it is
> > probably not going to happen.
>
> Understood, the almighty RHs knows better, the community is dumb :(

No, you're just complaining needlessly in this instance (and others). And I'm 
not a RHer.

> > A more technical discussion, posed to the people who were making the
> > changes could perhaps result in a discussion about why the alternatives
> > either won't work, or weren't considered.
>
> The point is: To you, your claimed 3 seconds bootup speed up is a great
> achievement. To me, this "achievement" is negligible.
>
> To me, the fact of X11 going to F1 is a usability regression.

And no one else cares. The worst thing about Fedora isn't all these tiny 
changes, it's the huge threads of one or two people complaining about it that 
happen after the change.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From cra at WPI.EDU  Tue Oct 28 22:45:44 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 18:45:44 -0400
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028223930.GF197@rabbet.honolulu.burdell.org>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
	<20081028181855.GJ19205@angus.ind.WPI.EDU>
	<20081028223930.GF197@rabbet.honolulu.burdell.org>
Message-ID: <20081028224544.GP19205@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
> On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
> > I think it is a perfectly reasonable default to have DHCP enabled by 
> > default for all network interfaces, whether NetworkManager is used or 
> > not.
> 
> Seriously?

Yes, why not?



From dcantrell at redhat.com  Tue Oct 28 22:47:59 2008
From: dcantrell at redhat.com (David Cantrell)
Date: Tue, 28 Oct 2008 12:47:59 -1000
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028224544.GP19205@angus.ind.WPI.EDU>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
	<20081028181855.GJ19205@angus.ind.WPI.EDU>
	<20081028223930.GF197@rabbet.honolulu.burdell.org>
	<20081028224544.GP19205@angus.ind.WPI.EDU>
Message-ID: <20081028224758.GG197@rabbet.honolulu.burdell.org>

On Tue, Oct 28, 2008 at 06:45:44PM -0400, Chuck Anderson wrote:
> On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
> > On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
> > > I think it is a perfectly reasonable default to have DHCP enabled by 
> > > default for all network interfaces, whether NetworkManager is used or 
> > > not.
> > 
> > Seriously?
> 
> Yes, why not?

Right away I can think of the user with 185 network interfaces complaining
about boot up taking too long because he's having to wait for each one to time
out.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/289ef710/attachment.sig>

From kwizart at gmail.com  Tue Oct 28 22:49:07 2008
From: kwizart at gmail.com (KH KH)
Date: Tue, 28 Oct 2008 23:49:07 +0100
Subject: Scilab on Fedora and CeCILL license
In-Reply-To: <559178.81389.qm@web45413.mail.sp1.yahoo.com>
References: <559178.81389.qm@web45413.mail.sp1.yahoo.com>
Message-ID: <e1760170810281549pe348d2eqdd3c9ad87d79721f@mail.gmail.com>

2008/10/28 Henrique Junior <henriquecsj at gmail.com>:
> Hi all,
> Some time ago (FC6, F7?) SciLab[1] was in the Fedora repos but it looks out now.
> Scilab is an amazing scientific software and I'm interested in packaging it but first I want to know if is someone working on it and if the CeCILL license[2] is Fedora compatible.

I have a package quite ready but it miss some dependencies.
At least some of them haven't been submitted for review until recently.
matio: https://bugzilla.redhat.com/show_bug.cgi?id=466737

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

jogl: https://bugzilla.redhat.com/show_bug.cgi?id=439630
The review will also concern gluegen and cpptasks

flexdock: https://bugzilla.redhat.com/show_bug.cgi?id=464781
I was unable to package this one without Jimi which is nonfree and
needs to be riped out.
This one is really non-trivial if doable.

There is probably a problem with some java dependencies that cannot be
compiled without others nonfree dependencies.
The nonfree choice have to be completely ripped out along with the
included "tweaked/prebuilt" jar files, so even if that's not needed
for scilab properly, we may either have nonfree dependencies, or
packages that fails to build from sources.
If such problem appears we could miss the scilab java gui.

If someone want to help, there are probably specs around that need to
be raised to the fedora guidelines:
https://fedoraproject.org/wiki/Packaging/Java

Missing Fedora dependencies:
(search also in http://wiki.scilab.org/Dependencies_of_Scilab_5.X )
- jhall also known as javahelp2 at jpackage.org is nonfree, unless
there is a replacement choice that I'm not aware, this can lead to a
problem.
- SKINL: Skin Look and Feel . it searches for a  skinlf.jar
- jeuclid
- saxon
- Sablotron
- Giws
Any can pick one of theses, but please warn if you have something
close to be ready.

Nicolas (kwizart)




> [1] - http://www.scilab.org/
> [2] - http://www.cecill.info/index.en.html
>
> Regards
>
>
>
> Henrique "LonelySpooky" Junior
> ________________________________
> "In a world without walls and fences, who needs windows and gates?!"
>
>
>
>      Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
> http://br.new.mail.yahoo.com/addresses
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From lesmikesell at gmail.com  Tue Oct 28 22:51:51 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 28 Oct 2008 17:51:51 -0500
Subject: Default network configuration during installation,
 NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028223126.GD197@rabbet.honolulu.burdell.org>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<20081028223126.GD197@rabbet.honolulu.burdell.org>
Message-ID: <49079787.3000906@gmail.com>

David Cantrell wrote:
> On Tue, Oct 28, 2008 at 11:31:40AM +0000, Michael Cutler wrote:
>> (1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
> 
> I'm not opposed to this, but I'm also not opposed to it staying where it is.
> 
>> (2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.
> 
> I'm not in favor of this.  The situation you're describing is exactly why we
> wanted to get rid of the network configuration screen.
> 

Isn't the system already capable of knowing if link is up on an 
interface and not waiting for dhcp if it isn't connected?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From cra at WPI.EDU  Tue Oct 28 22:55:58 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 18:55:58 -0400
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028224758.GG197@rabbet.honolulu.burdell.org>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
	<20081028181855.GJ19205@angus.ind.WPI.EDU>
	<20081028223930.GF197@rabbet.honolulu.burdell.org>
	<20081028224544.GP19205@angus.ind.WPI.EDU>
	<20081028224758.GG197@rabbet.honolulu.burdell.org>
Message-ID: <20081028225558.GQ19205@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 12:47:59PM -1000, David Cantrell wrote:
> On Tue, Oct 28, 2008 at 06:45:44PM -0400, Chuck Anderson wrote:
> > On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
> > > On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
> > > > I think it is a perfectly reasonable default to have DHCP enabled by 
> > > > default for all network interfaces, whether NetworkManager is used or 
> > > > not.
> > > 
> > > Seriously?
> > 
> > Yes, why not?
> 
> Right away I can think of the user with 185 network interfaces complaining
> about boot up taking too long because he's having to wait for each one to time
> out.

What ever happened to the "no link detected" logic?



From lesmikesell at gmail.com  Tue Oct 28 22:57:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 28 Oct 2008 17:57:06 -0500
Subject: Default network configuration during installation,
 NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028224758.GG197@rabbet.honolulu.burdell.org>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>	<1225211932.2157.53.camel@luminos.localdomain>	<1225212528.9923.3.camel@localhost.localdomain>	<20081028181855.GJ19205@angus.ind.WPI.EDU>	<20081028223930.GF197@rabbet.honolulu.burdell.org>	<20081028224544.GP19205@angus.ind.WPI.EDU>
	<20081028224758.GG197@rabbet.honolulu.burdell.org>
Message-ID: <490798C2.9040308@gmail.com>

David Cantrell wrote:
> On Tue, Oct 28, 2008 at 06:45:44PM -0400, Chuck Anderson wrote:
>> On Tue, Oct 28, 2008 at 12:39:31PM -1000, David Cantrell wrote:
>>> On Tue, Oct 28, 2008 at 02:18:55PM -0400, Chuck Anderson wrote:
>>>> I think it is a perfectly reasonable default to have DHCP enabled by 
>>>> default for all network interfaces, whether NetworkManager is used or 
>>>> not.
>>> Seriously?
>> Yes, why not?
> 
> Right away I can think of the user with 185 network interfaces complaining
> about boot up taking too long because he's having to wait for each one to time
> out.

Assume that only the ones that he wants to use are connected.  And that 
he wants to do the initial install via NFS.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From cra at WPI.EDU  Tue Oct 28 22:57:54 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 28 Oct 2008 18:57:54 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081028220240.GM19205@angus.ind.WPI.EDU>
References: <20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<20081028203153.GC8452@nostromo.devel.redhat.com>
	<20081028214519.GK19205@angus.ind.WPI.EDU>
	<49078A9E.9060508@redhat.com>
	<20081028220240.GM19205@angus.ind.WPI.EDU>
Message-ID: <20081028225754.GR19205@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 06:02:40PM -0400, Chuck Anderson wrote:
> On Tue, Oct 28, 2008 at 05:56:46PM -0400, Casey Dahlin wrote:
> > Chuck Anderson wrote:
> >> On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
> >>   
> >>> Ralf Corsepius (rc040203 at freenet.de) said:     
> >>>>> Who does this affect?
> >>>>>         
> >>>> E.g. application devs, documentation writers, experienced users.
> >>>>       
> >>> Much like passwd auth to PAM. Heck, passwd -> shadow.  twm -> fvwm
> >>> -> AnotherLevel -> GNOME.
> >>>
> >>> The only thing constant is change.
> >>>     
> >>
> >> Every day it's the same old thing!  Variety!  I wan't something  
> >> /different/!  Bring me the hasenfeffer!
> >>
> >>   
> > I have no idea what you just said.
> 
> Sorry, a little Bugs Bunny joke.

Search youtube for "Shiskabugs" :-)



From fenn at stanford.edu  Tue Oct 28 23:00:11 2008
From: fenn at stanford.edu (Tim Fenn)
Date: Tue, 28 Oct 2008 16:00:11 -0700
Subject: looking for pymol tester/comaintainer for EL5
Message-ID: <20081028160011.61d9b3ca@atbws1.stanford.edu>

With a good chunk of help, I now have fedora builds of pymol available
(see bugzilla ID 462251 for the full details). However, I'd like to
have some help with building/testing for EL5, as I'd like to make it
available but don't have an EL box to explicitly test on.

Many thanks,
Tim

-- 
CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS



From rc040203 at freenet.de  Tue Oct 28 23:10:22 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 29 Oct 2008 00:10:22 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <490770DF.8020304@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com> <49075BDB.1010401@gmail.com>
	<490770DF.8020304@redhat.com>
Message-ID: <1225235422.3897.260.camel@beck.corsepiu.local>

On Tue, 2008-10-28 at 16:06 -0400, Casey Dahlin wrote:
> Les Mikesell wrote:
> > Casey Dahlin wrote:
> >> >>>    
> >>> True, but it's one brick in a lengthy series of stupid and silly
> >>> decisions, which have been gradually running down Fedora into this
> >>> single-user windows clone it has evolved into.
> >>>
> >>>   
> >> Are you serious? Really? You must have a very tenuous grasp of OS 
> >> internals.
> >
> > No, every change requires extensive documentation and retraining or 
> > you will have confused and disgruntled users.
> >
> >> Who does this affect?
> >> 1) People using the console a lot who also run X (remember, runlevel 
> >> 3 hasn't changed). Desktop users don't use consoles, server users 
> >> don't use X (I hope). Only a few species of geek remain.
> >
> > This dichotomy exists only in your imagination.  Desktop users 
> > sometimes interact with servers, server users nearly always interact 
> > with desktops.

I'd go one step further ...

> The users are the same. The computers, however, are different.

In many cases, the user is the same, the computer is the same, but the
situations and roles of both machine and user vary.

Never attached your "netbook/laptop" to your "home desktop with the big
screen and used your "netbook/laptop" as file server?

Ralf







From jkeating at redhat.com  Tue Oct 28 23:37:36 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 28 Oct 2008 16:37:36 -0700
Subject: rawhide report: 20081028 changes
In-Reply-To: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
References: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
Message-ID: <1225237056.2157.101.camel@luminos.localdomain>

On Tue, 2008-10-28 at 10:02 +0000, Rawhide Report wrote:
> 
> 
> libcaca-0.99-0.5.beta16.fc10
> ----------------------------
> * Mon Oct 27 18:00:00 2008 Matthias Saou <http://freshrpms.net/>
> 0.99-0.5.beta16
> - Update to 0.99beta16.
> - Update Source URL.

This build dropped a provided soname, libcucul.so.0()(64bit)  This
breaks a few things, which aren't in Fedora proper so they didn't show
up in the dep check.  Please look into why the soname dropped between
builds.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081028/9b1be232/attachment.sig>

From debarshi.ray at gmail.com  Tue Oct 28 23:46:35 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 29 Oct 2008 05:16:35 +0530
Subject: libgdl-2.24.0: libgdl-gnome-1.so dropped
In-Reply-To: <rq4p2x3pxe.fsf@allele2.eebweb.arizona.edu>
References: <3170f42f0810240912g7d941cb1hdcd90b230934da90@mail.gmail.com>
	<723aik9sho.fsf@allele2.eebweb.arizona.edu>
	<sabcq7d1k.fsf@allele2.eebweb.arizona.edu>
	<3170f42f0810262355i2ebc6b41ycde93f071af960d7@mail.gmail.com>
	<rq4p2x3pxe.fsf@allele2.eebweb.arizona.edu>
Message-ID: <3170f42f0810281646v5cf7065fp51258f5e02d1573d@mail.gmail.com>

> As far as I can see, anjuta has not yet been rebuilt:
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=1302
>
> and still causing broken deps in rawhide... :-(
>
> Does this require a new upstream version?  It's really not a good idea
> to bump soname, and then leave the dependent packages to be broken for
> about 5 days.  Either rebuild the dependent packags immediately after
> pushing the soname, or wait until you have time to do them all at
> once.

Since there are multiple packages contributing to broken dependencies
in Rawhide, and some of them don't get fixed for weeks (ruby-rpm comes
to my mind), I can not agree with the above rationale.

The reason Anjuta 2.23.x were not built and we directly jumped to
Anjuta 2.24 has been mentioned on the Trac ticket [1]. At this point
in the development cycle I wanted to be sure about Anjuta 2.24's
functionality before pushing it. 2.24.1 is already a bug fix release,
but if Rawhide users can unearth some more problems, I will gladly
take them up.

Happy hacking,
Debarshi

[1] https://fedorahosted.org/rel-eng/ticket/888



From kwizart at gmail.com  Wed Oct 29 00:01:30 2008
From: kwizart at gmail.com (KH KH)
Date: Wed, 29 Oct 2008 01:01:30 +0100
Subject: rawhide report: 20081028 changes
In-Reply-To: <1225237056.2157.101.camel@luminos.localdomain>
References: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
	<1225237056.2157.101.camel@luminos.localdomain>
Message-ID: <e1760170810281701r8086ddfuc95b3b123f154dc1@mail.gmail.com>

2008/10/29 Jesse Keating <jkeating at redhat.com>:
> On Tue, 2008-10-28 at 10:02 +0000, Rawhide Report wrote:
>>
>>
>> libcaca-0.99-0.5.beta16.fc10
>> ----------------------------
>> * Mon Oct 27 18:00:00 2008 Matthias Saou <http://freshrpms.net/>
>> 0.99-0.5.beta16
>> - Update to 0.99beta16.
>> - Update Source URL.
>
> This build dropped a provided soname, libcucul.so.0()(64bit)  This
> breaks a few things, which aren't in Fedora proper so they didn't show
> up in the dep check.  Please look into why the soname dropped between
> builds.
That was "expected" since the NEWS says:
---------------
\section news0_99_beta15 Changes between 0.9.beta15 and 0.99.beta14

 - libcucul was merged back into libcaca for more clarity
---------------
Packages maintainers will be warned.

Nicolas (kwizart)


>
> --
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From henriquecsj at gmail.com  Wed Oct 29 00:07:26 2008
From: henriquecsj at gmail.com (Henrique Junior)
Date: Tue, 28 Oct 2008 17:07:26 -0700 (PDT)
Subject: Res: Scilab on Fedora and CeCILL license
Message-ID: <267957.64148.qm@web45412.mail.sp1.yahoo.com>

Hi, Nicolas
Are you trying the new SciLab 5.x?
I'm downloading it now to see the changes from 4.x to 5.x but the upstream claims that great changes have been made.

 
Henrique "LonelySpooky" Junior
________________________________
"In a world without walls and fences, who needs windows and gates?!"



----- Mensagem original ----
> De: KH KH <kwizart at gmail.com>
> Para: Development discussions related to Fedora <fedora-devel-list at redhat.com>
> Enviadas: Ter?a-feira, 28 de Outubro de 2008 20:49:07
> Assunto: Re: Scilab on Fedora and CeCILL license
> 
> 2008/10/28 Henrique Junior :
> > Hi all,
> > Some time ago (FC6, F7?) SciLab[1] was in the Fedora repos but it looks out 
> now.
> > Scilab is an amazing scientific software and I'm interested in packaging it 
> but first I want to know if is someone working on it and if the CeCILL 
> license[2] is Fedora compatible.
> 
> I have a package quite ready but it miss some dependencies.
> At least some of them haven't been submitted for review until recently.
> matio: https://bugzilla.redhat.com/show_bug.cgi?id=466737
> 
> jrosetta: https://bugzilla.redhat.com/show_bug.cgi?id=468797
> 
> jogl: https://bugzilla.redhat.com/show_bug.cgi?id=439630
> The review will also concern gluegen and cpptasks
> 
> flexdock: https://bugzilla.redhat.com/show_bug.cgi?id=464781
> I was unable to package this one without Jimi which is nonfree and
> needs to be riped out.
> This one is really non-trivial if doable.
> 
> There is probably a problem with some java dependencies that cannot be
> compiled without others nonfree dependencies.
> The nonfree choice have to be completely ripped out along with the
> included "tweaked/prebuilt" jar files, so even if that's not needed
> for scilab properly, we may either have nonfree dependencies, or
> packages that fails to build from sources.
> If such problem appears we could miss the scilab java gui.
> 
> If someone want to help, there are probably specs around that need to
> be raised to the fedora guidelines:
> https://fedoraproject.org/wiki/Packaging/Java
> 
> Missing Fedora dependencies:
> (search also in http://wiki.scilab.org/Dependencies_of_Scilab_5.X )
> - jhall also known as javahelp2 at jpackage..org is nonfree, unless
> there is a replacement choice that I'm not aware, this can lead to a
> problem.
> - SKINL: Skin Look and Feel . it searches for a  skinlf.jar
> - jeuclid
> - saxon
> - Sablotron
> - Giws
> Any can pick one of theses, but please warn if you have something
> close to be ready.
> 
> Nicolas (kwizart)
> 
> 
> 
> 
> > [1] - http://www.scilab.org/
> > [2] - http://www.cecill.info/index.en.html
> >
> > Regards
> >
> >
> >
> > Henrique "LonelySpooky" Junior
> > ________________________________
> > "In a world without walls and fences, who needs windows and gates?!"
> >
> >
> >
> >      Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua 
> cara @ymail.com ou @rocketmail.com.
> > http://br.new.mail.yahoo.com/addresses
> >
> >
> > --
> > fedora-devel-list mailing list
> > 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



      Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses




From kevin.kofler at chello.at  Wed Oct 29 00:22:44 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 29 Oct 2008 00:22:44 +0000 (UTC)
Subject: rawhide report: 20081028 changes
References: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
	<1225237056.2157.101.camel@luminos.localdomain>
Message-ID: <loom.20081029T002009-881@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> This build dropped a provided soname, libcucul.so.0()(64bit)  This
> breaks a few things, which aren't in Fedora proper so they didn't show
> up in the dep check.  Please look into why the soname dropped between
> builds.

Normally a rebuild of the affected packages should be enough. It did the trick 
for xine-lib-extras (the one package in Fedora which was affected, and which I 
promptly rebuilt because Mamoru Tasaka warned me about it) at least.

        Kevin Kofler



From noriko at redhat.com  Wed Oct 29 00:34:27 2008
From: noriko at redhat.com (Noriko Mizumoto)
Date: Wed, 29 Oct 2008 10:34:27 +1000
Subject: Virt* , s-c-display ,desktop-effects - Translation submission
 issues!
In-Reply-To: <49067324.9000908@redhat.com>
References: <48FEF504.8030606@redhat.com> <49055B15.1070507@redhat.com>
	<49067324.9000908@redhat.com>
Message-ID: <4907AF93.8000805@redhat.com>

Cole Robinson ????????:
> Noriko Mizumoto wrote:
>> Hi
>>
>> It is one day to go for Final Development freeze, 28-Oct.
>> Could you please please check the following bugs and include all
>> translation submitted against?
>>
>> It is highly appreciated if the comment is added in the bug when done.
>>
>>
>>> [virt-manager]
>>> https://bugzilla.redhat.com/show_bug.cgi?id=467808
>> Hi Cole,
>> 12 languages translation attached as of 27-Oct, 04:00 UTC time.
>> There are some languages attached after Translation Deadline of 21-Oct.
>> Is any chance that those can be included?
>>
>>
>>> [virt-inst]
>>> https://bugzilla.redhat.com/show_bug.cgi?id=467810
>> Hi Cole,
>> 2 languages translation attached as of 27-Oct, 04:00 UTC time.
>> Could you confirm if those have been included?
>>
>>
> 
> These were built earlier today, FYI.
> 
> Thanks,
> Cole

Thank you so much!!

noriko

> 
> --
> Fedora-trans-list mailing list
> Fedora-trans-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-trans-list



From notting at redhat.com  Wed Oct 29 00:55:48 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 28 Oct 2008 20:55:48 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <ge82t0$ql6$1@ger.gmane.org>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<200810281509.40552.opensource@till.name>
	<20081028202624.GB8452@nostromo.devel.redhat.com>
	<49077869.9030706@redhat.com>
	<20081028204315.GF8452@nostromo.devel.redhat.com>
	<ge82t0$ql6$1@ger.gmane.org>
Message-ID: <20081029005548.GA12270@nostromo.devel.redhat.com>

Matthew Woehlke (mw_triad at users.sourceforge.net) said: 
>> If you don't add the bits I mentioned, then you'll get a blank tty7
>> when you boot in text mode. Which is presumably not what you want.
>
> So add an explicit switch to tty1 in runlevel 3. It shouldn't flicker  
> because it's not changing display modes (at least, I don't remember  
> flicker switching between mingetty VT's; can't check right now because  
> X->VGA switching doesn't work on this machine). Where's the problem?

You're having the kernel operate on Fedora specific commandline options
to start on a completely different tty, one that could be configured
by anyone locally to do something else entirely. (Unless you do it in
userspace, which means you jump away and then jump back for text mode,
which...)

Bill



From notting at redhat.com  Wed Oct 29 01:01:42 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 28 Oct 2008 21:01:42 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
Message-ID: <20081029010142.GB12270@nostromo.devel.redhat.com>

Joshua Baker-LePain (jlb17 at duke.edu) said: 
>> > NetworkManager is not an option and has no place on my machines.
>>
>> Right-click -> "Edit connections", pick your preferred setting, click 
>> on 'System setting'.
>
> Right-click on what?  I run fvwm.  How are non-DE users supposed to  
> interact with NM?

He was asking how to make NM work after logging out, which does sort
of presume he's already using it. If you are seriously asking about how
to configure NM when you aren't actually using it, well...

>> (Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)
>
> Yes, yes it does.  And it should.

Not in the context of init.d/network, which is what I meant. (Well, not
outside of gross hacks.)

Bill



From poelstra at redhat.com  Wed Oct 29 01:55:05 2008
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 28 Oct 2008 18:55:05 -0700
Subject: Fedora Release Engineering Meeting Recap 2008-10-27
Message-ID: <4907C279.8000609@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-oct-27

Please make corrections and clarifications to the wiki page.

== Highlights ==
* Final freeze is tomorrow (2008-10-28)
** setting up the f10-final tag today and cloning dist-f10 over to 
it--keeping it in sync with dist-f10 until around rawhide production time
** dist-rawhide will be made to inherit from f10-final and tomorrow's 
rawhide will be the frozen content
** all packages need ACKs to be build there after
* Drafted Fedora 11 Schedule--please review
** https://fedorahosted.org/rel-eng/ticket/843
* wwoods to create test matrix for Preview Release

== IRC Transcript ==



From cmadams at hiwaay.net  Wed Oct 29 02:36:11 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 28 Oct 2008 21:36:11 -0500
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028223848.GE197@rabbet.honolulu.burdell.org>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
	<20081028223848.GE197@rabbet.honolulu.burdell.org>
Message-ID: <20081029023611.GC1316935@hiwaay.net>

Once upon a time, David Cantrell <dcantrell at redhat.com> said:
> This is a good point.  I really don't think it's unreasonable to require any
> of the following:
> 
> 1) Users have to use NetworkManager to bring up a network interface.
> 2) Users have to run system-config-network to set up networking.
> 3) Users have to edit ifcfg-DEVICE files by hand.
> 
> Over the past several years, we [anaconda team] has been trying to move as
> many system configuration screens out of anaconda as we can.  Only what we
> need to ensure the system either (a) installs correctly or (b) reboots and
> is usable.  We're down to:
> 
>    language
>    keyboard
>    root password
>    timezone
>    hostname
>    boot loader (automatic unless you ask to configure it)

This means you can no longer start an install and SSH in once it is done
to perform the rest of configuration.  I'll start an install on a
computer in another room, and when I can ping its static IP, I can SSH
in and work on it (I don't have to walk back and forth, checking on it
periodically or do any more configuration at the console).  If that is
the desired case, then you might as well:

- disable sshd by default
- set "PermitRootLogin no" in /etc/ssh/sshd_config by default
- remove the SSH opening in the firewall

-- 
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 dcbw at redhat.com  Wed Oct 29 03:54:30 2008
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 28 Oct 2008 23:54:30 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
Message-ID: <1225252470.27745.7.camel@localhost.localdomain>

On Tue, 2008-10-28 at 17:40 -0400, Joshua Baker-LePain wrote:
> On Tue, 28 Oct 2008 at 5:31pm, Bill Nottingham <notting at redhat.com> wrote
> 
> > Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > > As long as I keep loosing my network connection upon log-out,
> > > NetworkManager is not an option and has no place on my machines.
> > 
> > Right-click -> "Edit connections", pick your preferred setting, 
> > click on 'System setting'.
> 
> Right-click on what?  I run fvwm.  How are non-DE users supposed to 
> interact with NM?
> 
> > (Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)

When I enable the keyfile plugin for system settings (next update now
that moving connections between user and system works) then yes, all of
WPA, Mobile Broadband, VPN, and wired 802.1x will work _before login_
and _across logins_.  Yay for progress!

Dan




From cra at WPI.EDU  Wed Oct 29 04:40:43 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 29 Oct 2008 00:40:43 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225252470.27745.7.camel@localhost.localdomain>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<1225252470.27745.7.camel@localhost.localdomain>
Message-ID: <20081029044043.GA22966@angus.ind.WPI.EDU>

On Tue, Oct 28, 2008 at 11:54:30PM -0400, Dan Williams wrote:
> On Tue, 2008-10-28 at 17:40 -0400, Joshua Baker-LePain wrote:
> > On Tue, 28 Oct 2008 at 5:31pm, Bill Nottingham <notting at redhat.com> wrote
> > 
> > > Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > > > As long as I keep loosing my network connection upon log-out,
> > > > NetworkManager is not an option and has no place on my machines.
> > > 
> > > Right-click -> "Edit connections", pick your preferred setting, 
> > > click on 'System setting'.
> > 
> > Right-click on what?  I run fvwm.  How are non-DE users supposed to 
> > interact with NM?
> > 
> > > (Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)
> 
> When I enable the keyfile plugin for system settings (next update now
> that moving connections between user and system works) then yes, all of
> WPA, Mobile Broadband, VPN, and wired 802.1x will work _before login_
> and _across logins_.  Yay for progress!

Has any work been done on a command line tool (like nm-tool) so that 
you can interact with NM and connect to networks without logging into 
a GUI?  I'd love to see that...



From rajeeshknambiar at gmail.com  Wed Oct 29 04:58:05 2008
From: rajeeshknambiar at gmail.com (Rajeesh K Nambiar)
Date: Wed, 29 Oct 2008 10:28:05 +0530
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <20081028223848.GE197@rabbet.honolulu.burdell.org>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<1225211932.2157.53.camel@luminos.localdomain>
	<1225212528.9923.3.camel@localhost.localdomain>
	<20081028223848.GE197@rabbet.honolulu.burdell.org>
Message-ID: <815462c80810282158n20b4fff0keedff85885b541a7@mail.gmail.com>

2008/10/29 David Cantrell <dcantrell at redhat.com>
>
> On Tue, Oct 28, 2008 at 12:48:48PM -0400, Dan Williams wrote:
> > On Tue, 2008-10-28 at 09:38 -0700, Jesse Keating wrote:
> > > On Tue, 2008-10-28 at 11:31 +0000, Michael Cutler wrote:
> > > >
> > > > (1). Include NetworkManager in the '@core' group, such that every
> > > > install will include NetworkManager and a minimal install as described
> > > > above will bring the system up with network connectivity.
> > >
> > > And here we have another fun argument about how 'minimal' should the
> > > minimal install be!  We've chucked yum in @core, might as well chuck
> > > NetworkManager too...
> >
> > Right, but we still don't turn NM on by default with chkconfig.  Which
> > means even if you bring it into @core, your networking still won't work
> > unless you turn NM on post-install manually.
> >
> > The issue here (IIRC) was that Anaconda won't set up an ifcfg file for
> > you if you don't use network to install, because the network
> > configuration screen got removed as it was mostly redundant for installs
> > where NM is active.
> >
> > If you're not installing over the network (and thus there's no network
> > configuration to save out) should the "network config" screen come back?
> > Or should anaconda just activate all devices onboot with DHCP?  The
> > latter sounds like a loss.  If you want stuff set up post-boot without
> > NetworkManager, maybe it's not unreasonable that you have to configure
> > it yourself.  What's the difference if that happens post-install or
> > during install?
>
> This is a good point.  I really don't think it's unreasonable to require any
> of the following:
>
> 1) Users have to use NetworkManager to bring up a network interface.
> 2) Users have to run system-config-network to set up networking.
> 3) Users have to edit ifcfg-DEVICE files by hand.
>
> Over the past several years, we [anaconda team] has been trying to move as
> many system configuration screens out of anaconda as we can.  Only what we
> need to ensure the system either (a) installs correctly or (b) reboots and
> is usable.  We're down to:
>
>   language
>   keyboard
>   root password
>   timezone
>   hostname
>   boot loader (automatic unless you ask to configure it)
>
> There are some other ideas that we could come up with too.  What if firstboot
> asked you how you want to configure your network interface?  As in, exposing
> the s-c-network UI or something from NetworkManager?  Just brainstorming.
> These really just make what's already there more accessible after an initial
> install.
>

I would say firstboot is the best place for network configuration,
ofcourse unless installed via network. I know a lot of people install
Fedora using CD/DVDs and with no initial network connection.

> --
> David Cantrell <dcantrell at redhat.com>
> Red Hat / Honolulu, HI
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

--
Cheers,
Rajeesh



From dkelson at gurulabs.com  Wed Oct 29 05:36:34 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Tue, 28 Oct 2008 23:36:34 -0600
Subject: Reasons to preseve X on tty7
Message-ID: <1225258594.3742.73.camel@mentor.gurulabs.com>

I would argue strongly that this change should not be made for the
following reasons (in no particular order):

* The default behavior of X on tty7 has been in place since the
beginning (almost a decade and a half).

* Long standing behaviors and defaults should not be changed unless
there is a VERY good reason with a significant upside. Developers should
tread respectfully in such hallowed places.

* This specific Linux behavior is well documented in hundreds of
thousand of publications ranging from college text books, HOWTOs, Linux
books sold in retail stores, blogs, forums, guides, and training
manuals. Making a change invalidates all that published knowledge.

* Fedora (and presumably RHEL6) now behaves differently from all the
major distributions. The axiom about those who ignore history are bound
to repeat holds here. UNIX "distros" did the same thing, introducing
frivolous incompatibilities. This fractures the user community, creating
separate pockets of knowledge and experience for each system.

* The "exception to the rule" (such as this one) dramatically increases
the costs of cross-distribution support. It turns 300-page books into
1000-page books. Similarly one must remember and commit to memory all
the "exceptions" and swap them in and out of your mental working set as
needed.

* Fedora is now inconsistent with itself in regards to where X is
running depending on if you booted to runlevel 3 and used startx or if
you booted to runlevel 5. When your uptime is 3 weeks, how do you
remember which method you used to start the GUI?

* Having tty1 be the user's "primary console" (as mentioned in BZ
465547) is not a worthy goal as desktop (GUI only) users should not and
do not care what tty X is on.

* Experienced users will try CONTROL-ALT-F1 and nothing will happen, the
first thing that comes to mind is "something is broke". 

* With the current rawhide behavior, what happens when you combine this
with fast user switching? The first user's desktop is on tty1, and then
is the second desktop is on tty7, and the third on tty8? I tried to test
this in my lab but I suspect video driver problems (radeon) because my
test machine would lock up.

* Having the X server start on tty7 *from the very beginning* would get
one less "flicker" without making an incompatible change.

I support progress, but I hate to see two steps forward and one back. I
understand change is natural but the change should be well reasoned with
implications considered and weighed.

To put my comments in "context" and to show that I'm not just a nutter
with an uniformed opinion, and in a way of introduction, here's a bit
about myself. I've used (typically in production) every single version
of Red Hat and/or Fedora ever created (go Mother's Day!). I started an
ISP and grew it to 10,000 users using (initially) Red Hat 4.2 (not
RHEL), and I was the first person/customer of Red Hat to earn an RHCE
(Feb 1999). I have minor patches in many different projects and several
hundred bugs in bugzilla.redhat.com. I was the official GNOME RPM
maintainer for a few years around the turn of the century creating GNOME
RPMs for several distributions for each new GNOME release.

For the past 9 years I have made a living writing Linux courseware for
multiple Linux distributions and teaching Linux training classes along
with the rest of the dozen full time instructors at Guru Labs, a company
I founded with a college friend of mine. I've sold tens of thousands of
Linux training books. Unfortunately, I don't have the time to
participate on the lists as much as I would like too. However, because
of my daily work I get to observe the low level changes and development
process of many different Linux distributions giving me a broad
perspective.

Our coureware features extensive labs which have thousands of lab steps
that exercise virtually all the major software components and features
thereof. As we update/validate our courseware to work on the latest
Linux distribution versions, our courseware ends up acting like a giant
regression test. We end up patching and/or filing many many bug reports
in many bug trackers.

Uneeded and frivolous incompatibilities between Linux distros are
particularly annoying to me on many levels. One practical reason is the
bloat it causes in our courseware. The LSB is fine for developers who
want to run binaries across multiple distributions, but Linux Sys Admins
deserve something akin to the LSB that provides greater consistency at
the Sys Admin level by removing squashing these frivolous
incompatibilities. This is something that has been brewing in the back
of my mind and I (using Guru Labs funding/resources and other interested
parties) might tackle at some point.

Dax Kelson
Guru Labs



From skvidal at fedoraproject.org  Wed Oct 29 05:42:23 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 01:42:23 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <1225258943.21485.28.camel@rosebud>

On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):
> 


I'm sure we'll be inundated with 'fedora is all about the bleeding edge'
comments but I have to give Dax my support with this comment. He's not
saying "preserve compatibility/behavior at all costs". He's saying that
the stated reason for this behavior change is not enough to justify the
cost of the loss of consistency with the past.

In short: +1

-sv




From nathanael at gnat.ca  Wed Oct 29 05:43:33 2008
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Tue, 28 Oct 2008 23:43:33 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258943.21485.28.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225258943.21485.28.camel@rosebud>
Message-ID: <4907F805.8050209@gnat.ca>

seth vidal wrote:
> On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
>> I would argue strongly that this change should not be made for the
>> following reasons (in no particular order):
>>
> 
> 
> I'm sure we'll be inundated with 'fedora is all about the bleeding edge'
> comments but I have to give Dax my support with this comment. He's not
> saying "preserve compatibility/behavior at all costs". He's saying that
> the stated reason for this behavior change is not enough to justify the
> cost of the loss of consistency with the past.
> 
> In short: +1

But fedora is all about the bleeding edge!

;)

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From orcanbahri at yahoo.com  Wed Oct 29 06:19:54 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Tue, 28 Oct 2008 23:19:54 -0700 (PDT)
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <555910.26860.qm@web32807.mail.mud.yahoo.com>

--- On Wed, 10/29/08, Dax Kelson <dkelson at gurulabs.com> wrote:

> From: Dax Kelson <dkelson at gurulabs.com>
> Subject: Reasons to preseve X on tty7
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> Date: Wednesday, October 29, 2008, 1:36 AM
> I would argue strongly that this change should not be made
> for the
> following reasons (in no particular order):
> 
> * The default behavior of X on tty7 has been in place since
> the
> beginning (almost a decade and a half).
> 
> * Long standing behaviors and defaults should not be
> changed unless
> there is a VERY good reason with a significant upside.
> Developers should
> tread respectfully in such hallowed places.
> 
> * This specific Linux behavior is well documented in
> hundreds of
> thousand of publications ranging from college text books,
> HOWTOs, Linux
> books sold in retail stores, blogs, forums, guides, and
> training
> manuals. Making a change invalidates all that published
> knowledge.
> 
> * Fedora (and presumably RHEL6) now behaves differently
> from all the
> major distributions. The axiom about those who ignore
> history are bound
> to repeat holds here. UNIX "distros" did the same
> thing, introducing
> frivolous incompatibilities. This fractures the user
> community, creating
> separate pockets of knowledge and experience for each
> system.
> 
> * The "exception to the rule" (such as this one)
> dramatically increases
> the costs of cross-distribution support. It turns 300-page
> books into
> 1000-page books. Similarly one must remember and commit to
> memory all
> the "exceptions" and swap them in and out of your
> mental working set as
> needed.
> 
> * Fedora is now inconsistent with itself in regards to
> where X is
> running depending on if you booted to runlevel 3 and used
> startx or if
> you booted to runlevel 5. When your uptime is 3 weeks, how
> do you
> remember which method you used to start the GUI?
> 
> * Having tty1 be the user's "primary console"
> (as mentioned in BZ
> 465547) is not a worthy goal as desktop (GUI only) users
> should not and
> do not care what tty X is on.
> 
> * Experienced users will try CONTROL-ALT-F1 and nothing
> will happen, the
> first thing that comes to mind is "something is
> broke". 
> 
> * With the current rawhide behavior, what happens when you
> combine this
> with fast user switching? The first user's desktop is
> on tty1, and then
> is the second desktop is on tty7, and the third on tty8? I
> tried to test
> this in my lab but I suspect video driver problems (radeon)
> because my
> test machine would lock up.
> 
> * Having the X server start on tty7 *from the very
> beginning* would get
> one less "flicker" without making an incompatible
> change.
> 
> I support progress, but I hate to see two steps forward and
> one back. I
> understand change is natural but the change should be well
> reasoned with
> implications considered and weighed.
> 
> To put my comments in "context" and to show that
> I'm not just a nutter
> with an uniformed opinion, and in a way of introduction,
> here's a bit
> about myself. I've used (typically in production) every
> single version
> of Red Hat and/or Fedora ever created (go Mother's
> Day!). I started an
> ISP and grew it to 10,000 users using (initially) Red Hat
> 4.2 (not
> RHEL), and I was the first person/customer of Red Hat to
> earn an RHCE
> (Feb 1999). I have minor patches in many different projects
> and several
> hundred bugs in bugzilla.redhat.com. I was the official
> GNOME RPM
> maintainer for a few years around the turn of the century
> creating GNOME
> RPMs for several distributions for each new GNOME release.
> 
> For the past 9 years I have made a living writing Linux
> courseware for
> multiple Linux distributions and teaching Linux training
> classes along
> with the rest of the dozen full time instructors at Guru
> Labs, a company
> I founded with a college friend of mine. I've sold tens
> of thousands of
> Linux training books. Unfortunately, I don't have the
> time to
> participate on the lists as much as I would like too.
> However, because
> of my daily work I get to observe the low level changes and
> development
> process of many different Linux distributions giving me a
> broad
> perspective.
> 
> Our coureware features extensive labs which have thousands
> of lab steps
> that exercise virtually all the major software components
> and features
> thereof. As we update/validate our courseware to work on
> the latest
> Linux distribution versions, our courseware ends up acting
> like a giant
> regression test. We end up patching and/or filing many many
> bug reports
> in many bug trackers.
> 
> Uneeded and frivolous incompatibilities between Linux
> distros are
> particularly annoying to me on many levels. One practical
> reason is the
> bloat it causes in our courseware. The LSB is fine for
> developers who
> want to run binaries across multiple distributions, but
> Linux Sys Admins
> deserve something akin to the LSB that provides greater
> consistency at
> the Sys Admin level by removing squashing these frivolous
> incompatibilities. This is something that has been brewing
> in the back
> of my mind and I (using Guru Labs funding/resources and
> other interested
> parties) might tackle at some point.
> 
> Dax Kelson
> Guru Labs
> 


While I respect your opinions and experience I do think that the reasoning for this behavior change is good enough. I remember the first time I was told how to switch to tty1 some 7-8 years ago. Immediately after switching to tty1 my curiosity boosted up and I tried all the combinations ctrl+alt+F2 through ctrl+alt+F12. I am sure many of us went through a similar experience. 

If someone tries one of these combinations (s)he *will* try the other combinations. There are not too many of them. It won't take too long until the user will end up where (s)he wanted. And if people still think that this change will bring an utter catastrophe we might as well put a warning message (just for F10 and maybe for F11) at tty7 saying that X is not here anymore and is moved to tty1. Won't this solve all the problems?

Orcan



      



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Oct 29 06:22:13 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 29 Oct 2008 15:22:13 +0900
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <49080115.7050704@ioa.s.u-tokyo.ac.jp>

Dax Kelson wrote, at 10/29/2008 02:36 PM +9:00:

> * Fedora is now inconsistent with itself in regards to where X is
> running depending on if you booted to runlevel 3 and used startx or if
> you booted to runlevel 5. When your uptime is 3 weeks, how do you
> remember which method you used to start the GUI?

Well, actually I usually reboot with runlevel 3 then after switch runlevel
to 5. In such case tty1 is console and I have never noticed that
tty1 behavior changed until I read the discussion from yesterday...

I also think that tty1 should be console as before. So +1

Mamoru



From Christian.Iseli at unil.ch  Wed Oct 29 06:51:08 2008
From: Christian.Iseli at unil.ch (Christian Iseli)
Date: Wed, 29 Oct 2008 07:51:08 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258943.21485.28.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225258943.21485.28.camel@rosebud>
Message-ID: <20081029075108.62b77cbb@ludwig-alpha.unil.ch>

On Wed, 29 Oct 2008 01:42:23 -0400, seth vidal wrote:
> > I would argue strongly that this change should not be made for the
> > following reasons (in no particular order):
> >   
> I'm sure we'll be inundated with 'fedora is all about the bleeding
> edge' comments but I have to give Dax my support with this comment.
> He's not saying "preserve compatibility/behavior at all costs". He's
> saying that the stated reason for this behavior change is not enough
> to justify the cost of the loss of consistency with the past.
> 
> In short: +1

I think one flicker doesn't weigh much in contrast of what gets lost in
terms of historical background and compatibility...

+1 from me too

Cheers,
					Christian



From peter at thecodergeek.com  Wed Oct 29 07:16:42 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 29 Oct 2008 00:16:42 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258943.21485.28.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225258943.21485.28.camel@rosebud>
Message-ID: <1225264602.5765.1.camel@tuxhugs>

On Wed, 2008-10-29 at 01:42 -0400, Seth Vidal wrote:
> I'm sure we'll be inundated with 'fedora is all about the bleeding edge'
> comments but I have to give Dax my support with this comment. He's not
> saying "preserve compatibility/behavior at all costs". He's saying that
> the stated reason for this behavior change is not enough to justify the
> cost of the loss of consistency with the past.

I could not have said it better myself, Seth. Another +1 for Dax's
argument from me.
-- 
Peter Gordon (codergeek42)
???????????
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/61d04459/attachment.sig>

From jspaleta at gmail.com  Wed Oct 29 07:40:49 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Oct 2008 23:40:49 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>

On Tue, Oct 28, 2008 at 9:36 PM, Dax Kelson
> * With the current rawhide behavior, what happens when you combine > this with fast user switching?
> The first user's desktop is on tty1, and then
> is the second desktop is on tty7, and the third on tty8? I tried to test
> this in my lab but I suspect video driver problems (radeon) because > my test machine would lock up.

I can confirm... second user's gdm login appears on vt7.

But is this actually a problem? All the UI elements for screen locking
and logging out provide a switch user option back to the first user. I
never needed to use the vt1 or vt7 short cut keys. The gui is self
consistent with regard to user switching regardless of what vts are
used.

As a graphical interface user, the only time I need to worry about
knowing about vt's is if I need to explicitly drop out of the gui.
And I only need to do that if things lock up so badly that I cant
start a terminal...but not so badly that the keyboard isn't locked up
as well.

The only reason I know the vt's are there is because I know the vt's
are there. And since I know the vt's are there.. I know to cycle
through them.

-jef"is just going to turn off all his gettys and see if he can adapt"spaleta



From pmatilai at laiskiainen.org  Wed Oct 29 08:05:26 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 29 Oct 2008 10:05:26 +0200 (EET)
Subject: providing what they require
In-Reply-To: <1224878261.29258.22.camel@rosebud>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
	<200810230944.53271.ville.skytta@iki.fi>
	<alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>
	<1224878261.29258.22.camel@rosebud>
Message-ID: <alpine.DEB.1.10.0810290903480.17696@gotcha.dreamhost.com>

On Fri, 24 Oct 2008, seth vidal wrote:
> On Fri, 2008-10-24 at 11:21 +0300, Panu Matilainen wrote:
>
>> Pruning out automatically generated self-requires is about three lines of
>> code, couple more to make it configurable. That's not the issue.
>
> Let's do this, then. :)
>
>> FWIW the number of self-requires on Fedora is vastly larger than what
>> plain upstream rpm would create, due to the patch that generates soname
>> dependencies from symlinks to dso's. For example:
>>
>> [pmatilai at localhost ~]$ rpm -q --filerequire cdparanoia-libs
>> /usr/lib64/libcdda_interface.so	R libcdda_interface.so.0()(64bit)
>> /usr/lib64/libcdda_interface.so.0	R libcdda_interface.so.0()(64bit)
>> /usr/lib64/libcdda_interface.so.0.10.0	R libc.so.6()(64bit) R
>> libc.so.6(GLIBC_2.2.5)(64bit) R libc.so.6(GLIBC_2.3)(64bit) R
>> libc.so.6(GLIBC_2.4)(64bit) R libm.so.6()(64bit) R
>> libm.so.6(GLIBC_2.2.5)(64bit) R rtld(GNU_HASH)
>>
>> Of course those would be gone too if self-requires were pruned.
>
> which sounds fine, then.
>
>> As it is now, every dependency in a package gets unconditionally recorded,
>> regardless of where the provider comes from. It's a very straightforward
>> rule. And yes it causes some unwanted side-effects, such as the one noted
>> by Bill here
>> http://lists.rpm.org/pipermail/rpm-maint/2007-July/001580.html and header
>> bloat. Changing that is possible and even trivial, it just "breaks" fairly
>> long time rpm behavior and opens up a different can of worms (a
>> dirt-simple rule comes bunch of special cases). Making it configurable
>> via macro would push the decision to vendors and packagers, but ...
>
> Explain to me what it breaks in terms of backward compat? I'm thinking
> that maybe for F11-cycle it could be worth breaking that compat.

Note "breaks", not breaks. Bigger "breakage" happens when somebody sets 
"%define _use_internal_dependency_generator 0" in their spec: it just 
means bunch of information doesn't exist in the package at all. Some of it 
is actually important (file colors), large amount of it is used by nothing 
at all, it's just "information". Much like changelogs are - nothing in the 
world *needs* them, but they're nice to have for humans. Except in the 
case of file requires and bunch of other stuff, it's exposed directly in 
the API. Not that it matters that much because nothing can depend on that 
data as it might not be there (rpm v3 packages, packages built using 
external dep generator), so those API's are practically unused...

And back to the self-requires: --filerequire becomes inaccurate if they're 
removed. Fedora doesn't care, somebody else seems to do... for performing 
partial package installations (which is not very "rpm" activity if you ask 
me), and doing dependency graphs on files (which OTOH seems fairly 
reasonable).

If we add an option to rpm to ditch self-requires, should we actually add 
a switch to disable generation of per-file dependency data completely with 
it, maybe link the two options to one? Yum and the like wont notice a 
thing, and it'll make packages & their metadata a little bit smaller.

Self-requires are just the tip of the iceberg when it comes to "useless
bloat" in headers, try the following for entertaining lesson on what sort
of junk the headers carry:
$ rpm -qa --qf "%{name}-%{version}\n[\t%{CLASSDICT}\n]\n"

One of my favorites:
         PNG image data, 313 x 225, 8-bit/color RGBA, non-interlaced
         PNG image data, 339 x 210, 8-bit/color RGBA, non-interlaced
         PNG image data, 349 x 274, 8-bit/color RGBA, non-interlaced
         ...

Rpm knows not only that it's image data, it even knows the picture
dimensions... That a file is an image (or a font, executable, dso ...)
might actually be useful information even in rpm context, it's dimensions
and color encoding probably not. Oh and btw, this file class and file
require/provide information is loaded into memory on installation despite
nothing using it (amounting to ~5-10% of memory use in the case I
tested, and yes I'm going to do something about it).

If you want to get filosophical about it: what is an rpm package and what 
information should it carry and what not? From depsolver POV, pretty much 
all it needs is lists of files and external dependencies. Depsolvers don't 
*need* info like "upstream URL" and changelogs either.

>> IMO they're not funky, they're absolutely useless. The idea behind those
>> is that you can provide alternate configuration for a package, which is
>> fine and well, except it's very broken by design:
>>
>> Say you have package foo with some configuration and myconfig-foo with a
>> custom config for it. The idea is that you can install foo with
>> --noconfigs but as foo requires (automatically) config(foo), this should
>> not be possible unless there's another package in the transaction
>> providing config(foo). Except that the provide is not pruned at runtime
>> with --noconfigs like it should... But lets imagine it did that: so you
>> provide your own configuration in the transaction, ie "rpm -Uvh
>> --noconfigs foo.rpm myconfig-foo.rpm". --noconfigs is a per-transaction
>> flag, so the config files from myconfig-foo wouldn't be installed either.
>> Oops. And for this misfeature, every package with a config file in it,
>> carries an extra provide + require on itself.
>
> Do we have a single case of something using config() in fedora?
> Hell, ANYWHERE? any distro at all?
>
> If not then maybe this is a feature that can take a long walk off a
> short pier?

I don't think anybody uses it because it's pretty much impossible to use 
as designed. There's a reason --noconfigs is a hidden cli switch unlike 
--excludedocs...

 	- Panu -



From fedora at leemhuis.info  Wed Oct 29 08:09:55 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 29 Oct 2008 09:09:55 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
Message-ID: <49081A53.1050504@leemhuis.info>

On 29.10.2008 08:40, Jeff Spaleta wrote:
> On Tue, Oct 28, 2008 at 9:36 PM, Dax Kelson
>> * With the current rawhide behavior, what happens when you combine > this with fast user switching?
>> The first user's desktop is on tty1, and then
>> is the second desktop is on tty7, and the third on tty8? I tried to test
>> this in my lab but I suspect video driver problems (radeon) because > my test machine would lock up.
> 
> I can confirm... second user's gdm login appears on vt7.
> 
> But is this actually a problem? All the UI elements for screen locking
> and logging out provide a switch user option back to the first user. I
> never needed to use the vt1 or vt7 short cut keys. The gui is self
> consistent with regard to user switching regardless of what vts are
> used. [...]

I hereby propose we add a Checkbox (?) "Old-School Linux user" somewhere
to anaconda; users that want to preserve the traditional behavior for 
this and other things (like "show grub by default") can then just check 
that to get the old behavior.

CU
knurd

P.S.: You wonder if I meant that serious? I'm not sure myself. I think
the answer is: A little bit maybe ;-)



From gilboad at gmail.com  Wed Oct 29 08:19:42 2008
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 29 Oct 2008 10:19:42 +0200
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <1225268382.8403.5.camel@gilboa-home-dev.localdomain>

On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):
> 

/+1.

- Gilboa



From alcapcom at gmail.com  Wed Oct 29 08:36:33 2008
From: alcapcom at gmail.com (Alphonse Van Assche)
Date: Wed, 29 Oct 2008 09:36:33 +0100
Subject: Orphaning azureus
In-Reply-To: <20081028171711.3c1f1cc9@cheeky>
References: <20081024190916.A41D98E0003@hormel.redhat.com>
	<20081028171711.3c1f1cc9@cheeky>
Message-ID: <49082091.4090206@gmail.com>

Stefan Posdzich a ?crit :
> I have tried now some days with this package and i cant get warm with it
> (+ java).
> I will orphan it again, i hope it will find someone who can handle
> this kind of apps!
>
> https://admin.fedoraproject.org/pkgdb/packages/name/azureus
>
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=azureus
>
> best regards
> Stefan
>
>   
If nobody want it, I would like to take care of it.

Alphonse



 



From schaiba at gmail.com  Wed Oct 29 08:40:51 2008
From: schaiba at gmail.com (Aioanei Rares)
Date: Wed, 29 Oct 2008 10:40:51 +0200
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <778179b00810290140u61987ea8rd01b2eb9b56ae1c8@mail.gmail.com>

On Wed, Oct 29, 2008 at 7:36 AM, Dax Kelson <dkelson at gurulabs.com> wrote:

> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):
>
> * The default behavior of X on tty7 has been in place since the
> beginning (almost a decade and a half).
>
> * Long standing behaviors and defaults should not be changed unless
> there is a VERY good reason with a significant upside. Developers should
> tread respectfully in such hallowed places.
>
> * This specific Linux behavior is well documented in hundreds of
> thousand of publications ranging from college text books, HOWTOs, Linux
> books sold in retail stores, blogs, forums, guides, and training
> manuals. Making a change invalidates all that published knowledge.
>
> * Fedora (and presumably RHEL6) now behaves differently from all the
> major distributions. The axiom about those who ignore history are bound
> to repeat holds here. UNIX "distros" did the same thing, introducing
> frivolous incompatibilities. This fractures the user community, creating
> separate pockets of knowledge and experience for each system.
>
> * The "exception to the rule" (such as this one) dramatically increases
> the costs of cross-distribution support. It turns 300-page books into
> 1000-page books. Similarly one must remember and commit to memory all
> the "exceptions" and swap them in and out of your mental working set as
> needed.
>
> * Fedora is now inconsistent with itself in regards to where X is
> running depending on if you booted to runlevel 3 and used startx or if
> you booted to runlevel 5. When your uptime is 3 weeks, how do you
> remember which method you used to start the GUI?
>
> * Having tty1 be the user's "primary console" (as mentioned in BZ
> 465547) is not a worthy goal as desktop (GUI only) users should not and
> do not care what tty X is on.
>
> * Experienced users will try CONTROL-ALT-F1 and nothing will happen, the
> first thing that comes to mind is "something is broke".
>
> * With the current rawhide behavior, what happens when you combine this
> with fast user switching? The first user's desktop is on tty1, and then
> is the second desktop is on tty7, and the third on tty8? I tried to test
> this in my lab but I suspect video driver problems (radeon) because my
> test machine would lock up.
>
> * Having the X server start on tty7 *from the very beginning* would get
> one less "flicker" without making an incompatible change.
>
> I support progress, but I hate to see two steps forward and one back. I
> understand change is natural but the change should be well reasoned with
> implications considered and weighed.
>
> To put my comments in "context" and to show that I'm not just a nutter
> with an uniformed opinion, and in a way of introduction, here's a bit
> about myself. I've used (typically in production) every single version
> of Red Hat and/or Fedora ever created (go Mother's Day!). I started an
> ISP and grew it to 10,000 users using (initially) Red Hat 4.2 (not
> RHEL), and I was the first person/customer of Red Hat to earn an RHCE
> (Feb 1999). I have minor patches in many different projects and several
> hundred bugs in bugzilla.redhat.com. I was the official GNOME RPM
> maintainer for a few years around the turn of the century creating GNOME
> RPMs for several distributions for each new GNOME release.
>
> For the past 9 years I have made a living writing Linux courseware for
> multiple Linux distributions and teaching Linux training classes along
> with the rest of the dozen full time instructors at Guru Labs, a company
> I founded with a college friend of mine. I've sold tens of thousands of
> Linux training books. Unfortunately, I don't have the time to
> participate on the lists as much as I would like too. However, because
> of my daily work I get to observe the low level changes and development
> process of many different Linux distributions giving me a broad
> perspective.
>
> Our coureware features extensive labs which have thousands of lab steps
> that exercise virtually all the major software components and features
> thereof. As we update/validate our courseware to work on the latest
> Linux distribution versions, our courseware ends up acting like a giant
> regression test. We end up patching and/or filing many many bug reports
> in many bug trackers.
>
> Uneeded and frivolous incompatibilities between Linux distros are
> particularly annoying to me on many levels. One practical reason is the
> bloat it causes in our courseware. The LSB is fine for developers who
> want to run binaries across multiple distributions, but Linux Sys Admins
> deserve something akin to the LSB that provides greater consistency at
> the Sys Admin level by removing squashing these frivolous
> incompatibilities. This is something that has been brewing in the back
> of my mind and I (using Guru Labs funding/resources and other interested
> parties) might tackle at some point.
>
> Dax Kelson
> Guru Labs
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


+1
-- 
Aioanei Rares
schaiba at fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/dbe758e5/attachment.htm>

From hughsient at gmail.com  Wed Oct 29 09:16:20 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 29 Oct 2008 09:16:20 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <1225271780.3636.27.camel@hughsie-laptop>

On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):

Does it matter? Seriously, we need to start X on ttyX and start ONE
mingetty on ttyX+1. Loading mingetty on 6 terminals takes time.

Who uses more than one mingetty anyway? Surely the sort of person
comfortable with the RSI-inducing ctrl-alt-Fx is the sort of person that
can edit a config file and increase the number if we provide one by
default.

I was thinking about trying to tackle the boot time of fedora (and get
to the 5 second nirvana), but I fear that bikeshedding like this will
mean we are still loading sendmail, isdn, nfslock, and all other legacy
stuff in ten years time.

Richard.




From fedora at shmuelhome.mine.nu  Wed Oct 29 09:25:50 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Wed, 29 Oct 2008 11:25:50 +0200
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225271780.3636.27.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
Message-ID: <49082C1E.3030007@shmuelhome.mine.nu>

Richard Hughes wrote:
> On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
>   
>> I would argue strongly that this change should not be made for the
>> following reasons (in no particular order):
>>     
>
> Does it matter? Seriously, we need to start X on ttyX and start ONE
> mingetty on ttyX+1. Loading mingetty on 6 terminals takes time.
>
> Who uses more than one mingetty anyway? Surely the sort of person
> comfortable with the RSI-inducing ctrl-alt-Fx is the sort of person that
> can edit a config file and increase the number if we provide one by
> default.
>
> I was thinking about trying to tackle the boot time of fedora (and get
> to the 5 second nirvana), but I fear that bikeshedding like this will
> mean we are still loading sendmail, isdn, nfslock, and all other legacy
> stuff in ten years time.
>
> Richard.
>
>
>   
You are responding to an issue that no one is bringing up. No one is 
talking about how many mingettys are launched. On the other hand you are 
declaring as a resolved starting point the very thing that is being 
questioned. The question is "who gets tty1".



From j.w.r.degoede at hhs.nl  Wed Oct 29 09:35:39 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Oct 2008 10:35:39 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225271780.3636.27.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
Message-ID: <49082E6B.7080304@hhs.nl>

Richard Hughes wrote:
> I was thinking about trying to tackle the boot time of fedora (and get
> to the 5 second nirvana)

Great go for it! The solution to bikeshed color discussions is to just ignore 
them and make the changes in rawhide. If too much people scream too loudly one 
can always revert the changes or come up with a better way :)

> mean we are still loading sendmail, isdn, nfslock, and all other legacy
> stuff in ten years time.
> 

Talking about the nfs (and related rpc daemons) I recently had a good idea for 
those, some will hate it, but those are the people who so no to anything 
looking like progress, so I say lets just ignore them.

This idea is taken from some work I've done recently to stop the iscsi related 
daemons from starting unnecessary be default, something which has become 
relevant as the libvirt stuff drags in iscsi-initiator-utils on very 
installation that has libvirt, of which there are quite a few.

So the idea is to patch all the initscripts which currently only get started by 
default for NFS, to as the first thing in their start method grep for nfs in 
/etc/fstab and if that is not found exit quietly without doing anything further.

Then to make manual mounting of nfs exports not in fstab work properly, the 
suggested fix is to patch mount to check if the necessary daemons are running 
and if not start them. Since this will probably turn out to be distro specific 
I think it would be best to have a checknfsdaemons shell script in some 
standard location provided by the distro and let mount call that before each 
nfs mount. (Oh the horror an additional entire fork and exec on each nfs mount, 
hello people this is going over the network, forget about the fork and exec 
cost, thank you).

Regards,

Hans



From hughsient at gmail.com  Wed Oct 29 09:31:47 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 29 Oct 2008 09:31:47 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <49082C1E.3030007@shmuelhome.mine.nu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
Message-ID: <1225272707.3636.42.camel@hughsie-laptop>

On Wed, 2008-10-29 at 11:25 +0200, shmuel siegel wrote:
> You are responding to an issue that no one is bringing up. No one is 
> talking about how many mingettys are launched. On the other hand you
> are declaring as a resolved starting point the very thing that is
> being questioned. The question is "who gets tty1".

Who cares? If X lives on tty7 and you get an extra flicker, then that's
bad. If it lives on ttyX and it doesn't flicker, it's good.

The sort of person that even knows what a tty is, is probably in a
position where they can change it to whatever they want. Seriously, had
anyone done any research on the number of Fedora users who even use
ttys?

This isn't a community decision decided by +1 or -1's. This is the
package maintainer (and upstream) changing with a good reason.

Richard.




From pertusus at free.fr  Wed Oct 29 09:38:18 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 29 Oct 2008 10:38:18 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <49082E6B.7080304@hhs.nl>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
Message-ID: <20081029093818.GB2834@free.fr>

On Wed, Oct 29, 2008 at 10:35:39AM +0100, Hans de Goede wrote:
> Richard Hughes wrote:
>> I was thinking about trying to tackle the boot time of fedora (and get
>> to the 5 second nirvana)
>
> Great go for it! The solution to bikeshed color discussions is to just 
> ignore them and make the changes in rawhide. If too much people scream 
> too loudly one can always revert the changes or come up with a better way 
> :)

I think that it should be done the other way around, propose the changes
that affect the whole distro on th is list, listen to what people have
to say, or, more importantly what code they have to propose if they
don't like a given design, and then implement it with all the concerned
parties.

--
Pat



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Wed Oct 29 09:45:32 2008
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Wed, 29 Oct 2008 10:45:32 +0100
Subject: rawhide report: 20081028 changes
In-Reply-To: <1225237056.2157.101.camel@luminos.localdomain>
References: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
	<1225237056.2157.101.camel@luminos.localdomain>
Message-ID: <20081029104532.138c5511@python3.es.egwn.lan>

Jesse Keating wrote :

> On Tue, 2008-10-28 at 10:02 +0000, Rawhide Report wrote:
> > 
> > 
> > libcaca-0.99-0.5.beta16.fc10
> > ----------------------------
> > * Mon Oct 27 18:00:00 2008 Matthias Saou <http://freshrpms.net/>
> > 0.99-0.5.beta16
> > - Update to 0.99beta16.
> > - Update Source URL.
> 
> This build dropped a provided soname, libcucul.so.0()(64bit)  This
> breaks a few things, which aren't in Fedora proper so they didn't show
> up in the dep check.  Please look into why the soname dropped between
> builds.

The two libraries, libcaca and libcucul, got merged into libcaca. Note
that this version installs "compatibility" symlinks as "libcucul.so.0
-> libcaca.so.0", but those aren't detected as provides by rpm.

Dependant external programs simply need to be rebuilt. Another (ugly)
solution might be to add explicit "Provides:" for libcucul sonames to
the package.

If this is too much of a hassle so late in the Fedora 10 cycle, then
I'd have no objection to have this build reverted.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 9 (Sulphur) - Linux kernel 2.6.26.5-45.fc9.x86_64
Load : 0.10 0.08 0.15



From hughsient at gmail.com  Wed Oct 29 09:45:15 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 29 Oct 2008 09:45:15 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029093818.GB2834@free.fr>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<20081029093818.GB2834@free.fr>
Message-ID: <1225273515.3636.48.camel@hughsie-laptop>

On Wed, 2008-10-29 at 10:38 +0100, Patrice Dumas wrote:
> I think that it should be done the other way around, propose the
> changes that affect the whole distro on th is list, listen to what
> people have to say, or, more importantly what code they have to
> propose if they don't like a given design, and then implement it with
> all the concerned parties.

I don't think it can work like that.

1. send a mail saying sendmail won't be on the default desktop install
2. heat hands on ensuing flames

The problem with fedora-devel-list is that the 0.01% of most technical
users are there, most unable to understand that normal people don't use
an smtp server or setup nfs.

If we include everything we've ever started by default in the future
versions, and any of the latest cool new stuff, our boot times are going
to get longer, and our base install bigger.

Design by committee just doesn't work.

Richard.




From opensource at till.name  Wed Oct 29 09:46:21 2008
From: opensource at till.name (Till Maas)
Date: Wed, 29 Oct 2008 10:46:21 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225272707.3636.42.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
Message-ID: <200810291046.30621.opensource@till.name>

On Wed October 29 2008, Richard Hughes wrote:

> The sort of person that even knows what a tty is, is probably in a
> position where they can change it to whatever they want. Seriously, had
> anyone done any research on the number of Fedora users who even use
> ttys?

I use it every now and then to get pam_mount running, because then I need to 
login as root, which is something I do not want to do via gdm. Also I need it 
if the GUI does not start, which happens every now and then. This also 
happens if I help some other Linux user. Then changing lots of the system 
only to be able to debug the system decreases my motivation a lot. This is 
also true for testing new Fedora releases, e.g. via a LiveCD. If I always 
have to create my own LiveCD to test something, my motivation also goes away 
pretty fast.

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/20081029/ada1ac75/attachment.sig>

From jeremy at jeremysanders.net  Wed Oct 29 09:54:29 2008
From: jeremy at jeremysanders.net (Jeremy Sanders)
Date: Wed, 29 Oct 2008 09:54:29 +0000
Subject: Reasons to preseve X on tty7
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
Message-ID: <ge9bsl$2fp$1@ger.gmane.org>

Hans de Goede wrote:

> So the idea is to patch all the initscripts which currently only get
> started by default for NFS, to as the first thing in their start method
> grep for nfs in /etc/fstab and if that is not found exit quietly without
> doing anything further.

And this would break for people who are using autofs to mount nfs partition.
You also need to start nfsd if /etc/exports contains something.

-- 
http://jeremysanders.net/




From hughsient at gmail.com  Wed Oct 29 09:45:15 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 29 Oct 2008 09:45:15 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029093818.GB2834@free.fr>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<20081029093818.GB2834@free.fr>
Message-ID: <1225273515.3636.48.camel@hughsie-laptop>

On Wed, 2008-10-29 at 10:38 +0100, Patrice Dumas wrote:
> I think that it should be done the other way around, propose the
> changes that affect the whole distro on th is list, listen to what
> people have to say, or, more importantly what code they have to
> propose if they don't like a given design, and then implement it with
> all the concerned parties.

I don't think it can work like that.

1. send a mail saying sendmail won't be on the default desktop install
2. heat hands on ensuing flames

The problem with fedora-devel-list is that the 0.01% of most technical
users are there, most unable to understand that normal people don't use
an smtp server or setup nfs.

If we include everything we've ever started by default in the future
versions, and any of the latest cool new stuff, our boot times are going
to get longer, and our base install bigger.

Design by committee just doesn't work.

Richard.




From kraxel at redhat.com  Wed Oct 29 09:57:14 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 10:57:14 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225216493.2157.68.camel@luminos.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
Message-ID: <4908337A.5030705@redhat.com>

Jesse Keating wrote:
> On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
>> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
>> only feature it is to break documentations, habits and to add further
>> hassle.  A completely superfluous change.
> 
> As noted multiple times on this thread, the change prevents the
> multi-second monitor refresh issues when mode is changed by vt switches.

The flicker / resync delay comes from the *mode switch*, not the *vt
switch*.  And, no, a vt switch does *not* imply a mode switch.

The reason you'll have flicker today when switching from/to X11 is that
X11 does a mode switch when you switch from/to the terminal X11 is
running on.

I havn't played with kernel mode setting yet, but I'd expect kernel mode
setting killing that mode switch because ...

  (a) you'll drive all your text consoles and the X11 screen in the
      very same video mode and
  (b) X11 doesn't play with video modes any more because that is the
     kernels job now and
  (c) the kernel knows it doesn't need to switch the video mode.

If that isn't the case you are doing something very wrong.

Make an experiment, using "poor mans kernel mode setting" aka linux
framebuffer:

 (1) Grab any box next to you.  F8, F9, RHEL-5, whatever,
     doesn't matter, should work with any.
 (2) Setup the machine to boot using vesafb: add
     vga=0x314 (800x600) or vga=0x317 (1024x768) to the kernel
     command line.
 (3) Setup X11 to use the fbdev driver.

Reboot the machine.  When it is done, switch between X11 and text
consoles.  Notice the mode switch and thus the flicker is gone.

Probably you have to make plymouth draw its nice graphics on tty7
instead of tty1 to maintain the fancy cross fading effect when starting
X11 in tty7.  Shouldn't be a big deal though, if plymouth does that vt
switch right after KMS entered graphics mode and before printing
anything on the screen it should went unnoticed.

cheers,
  Gerd



From pertusus at free.fr  Wed Oct 29 10:00:01 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 29 Oct 2008 11:00:01 +0100
Subject: rawhide report: 20081028 changes
In-Reply-To: <20081029104532.138c5511@python3.es.egwn.lan>
References: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
	<1225237056.2157.101.camel@luminos.localdomain>
	<20081029104532.138c5511@python3.es.egwn.lan>
Message-ID: <20081029100000.GD2834@free.fr>

On Wed, Oct 29, 2008 at 10:45:32AM +0100, Matthias Saou wrote:
> 
> The two libraries, libcaca and libcucul, got merged into libcaca. Note
> that this version installs "compatibility" symlinks as "libcucul.so.0
> -> libcaca.so.0", but those aren't detected as provides by rpm.

If there is no associated soname, but only a symlink, I think that it is
normal that rpm doesn't detect it, and the linker shouldn't either.
If libcaca now provides the soname, then there is a bug somewhere.

> Dependant external programs simply need to be rebuilt. Another (ugly)
> solution might be to add explicit "Provides:" for libcucul sonames to
> the package.

But would the linker find the link? If not then the Provides should not
be there and packages should be rebuilt, to pick the new soname.

--
Pat



From j.w.r.degoede at hhs.nl  Wed Oct 29 10:08:13 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Oct 2008 11:08:13 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <ge9bsl$2fp$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <ge9bsl$2fp$1@ger.gmane.org>
Message-ID: <4908360D.8060900@hhs.nl>

Jeremy Sanders wrote:
> Hans de Goede wrote:
> 
>> So the idea is to patch all the initscripts which currently only get
>> started by default for NFS, to as the first thing in their start method
>> grep for nfs in /etc/fstab and if that is not found exit quietly without
>> doing anything further.
> 
> And this would break for people who are using autofs to mount nfs partition.

Then we need to also teach autofs to start these services on demand. Having all 
the daemons on for the 1% of Linux users who use NFS (esp on things like 
laptops) is not the answer. We are moving more and more to a system where Linux 
adjusts dynamically to its environment (think NetworkManager, think device hot 
plugging, etc.)

> You also need to start nfsd if /etc/exports contains something.

Or rather not start it if it does not contain anything or does not exist, 
currently the script creates an empty /etc/exports if it does not exist to 
ensure that nfsd will start to serve no purpose what so ever (serving an emty 
/etc/exports is pretty useless), that really is the world upside down.

Regards,

Hans



From pertusus at free.fr  Wed Oct 29 10:06:27 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 29 Oct 2008 11:06:27 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908360D.8060900@hhs.nl>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <ge9bsl$2fp$1@ger.gmane.org>
	<4908360D.8060900@hhs.nl>
Message-ID: <20081029100627.GE2834@free.fr>

On Wed, Oct 29, 2008 at 11:08:13AM +0100, Hans de Goede wrote:
>
> Or rather not start it if it does not contain anything or does not exist, 
> currently the script creates an empty /etc/exports if it does not exist 
> to ensure that nfsd will start to serve no purpose what so ever (serving 
> an emty /etc/exports is pretty useless), that really is the world upside 
> down.

nfsd should never be started automatically. Is it the case? I think that
it is a packaging bug.

--
Pat



From j.w.r.degoede at hhs.nl  Wed Oct 29 10:19:35 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Oct 2008 11:19:35 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029100627.GE2834@free.fr>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org>	<4908360D.8060900@hhs.nl>
	<20081029100627.GE2834@free.fr>
Message-ID: <490838B7.7030605@hhs.nl>

Patrice Dumas wrote:
> On Wed, Oct 29, 2008 at 11:08:13AM +0100, Hans de Goede wrote:
>> Or rather not start it if it does not contain anything or does not exist, 
>> currently the script creates an empty /etc/exports if it does not exist 
>> to ensure that nfsd will start to serve no purpose what so ever (serving 
>> an emty /etc/exports is pretty useless), that really is the world upside 
>> down.
> 
> nfsd should never be started automatically. Is it the case? I think that
> it is a packaging bug.
> 

Actually I just checked again and no it does not, the initscript file is named 
poorly though it is named nfs not nfsd which confused me into thinking that it 
gets started as part of other daemons needed for nfs client use.

Regards,

Hans



From hughsient at gmail.com  Wed Oct 29 10:18:25 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 29 Oct 2008 10:18:25 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <ge9bsl$2fp$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org>
Message-ID: <1225275505.3636.52.camel@hughsie-laptop>

On Wed, 2008-10-29 at 09:54 +0000, Jeremy Sanders wrote:
> And this would break for people who are using autofs to mount nfs
> partition.
> You also need to start nfsd if /etc/exports contains something.

Classic example of what I said earlier. What percentage of people are
using NFS on their machine right now? 0.5% - even less?

If you're setting up NFS on your machine, then you're quite capable of
turning a service on. There's no need for it to be on by default.

Richard.




From kraxel at redhat.com  Wed Oct 29 10:20:06 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 11:20:06 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <555910.26860.qm@web32807.mail.mud.yahoo.com>
References: <555910.26860.qm@web32807.mail.mud.yahoo.com>
Message-ID: <490838D6.4000407@redhat.com>

Orcan Ogetbil wrote:
> While I respect your opinions and experience I do think that the
> reasoning for this behavior change is good enough. I remember the
> first time I was told how to switch to tty1 some 7-8 years ago.
> Immediately after switching to tty1 my curiosity boosted up and I
> tried all the combinations ctrl+alt+F2 through ctrl+alt+F12. I am
> sure many of us went through a similar experience.

Yep, but usually you try that *once* and not *each time* you wanna have
a text console.

For me usually it is like this:

  * Oops, something busted in X11.
  * Try to get a text console via Ctrl-Alt-F1, see if I can fix it up.
Then either:
  * Log in, fix, switch back to X11
or:
  * Ctrl-Alt-F1 has no effect.  Damn.  Reboot time.

cheers,
  Gerd



From j.w.r.degoede at hhs.nl  Wed Oct 29 10:26:41 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Oct 2008 11:26:41 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <490838D6.4000407@redhat.com>
References: <555910.26860.qm@web32807.mail.mud.yahoo.com>
	<490838D6.4000407@redhat.com>
Message-ID: <49083A61.1010208@hhs.nl>

Gerd Hoffmann wrote:
> Orcan Ogetbil wrote:
>> While I respect your opinions and experience I do think that the
>> reasoning for this behavior change is good enough. I remember the
>> first time I was told how to switch to tty1 some 7-8 years ago.
>> Immediately after switching to tty1 my curiosity boosted up and I
>> tried all the combinations ctrl+alt+F2 through ctrl+alt+F12. I am
>> sure many of us went through a similar experience.
> 
> Yep, but usually you try that *once* and not *each time* you wanna have
> a text console.
> 
> For me usually it is like this:
> 
>   * Oops, something busted in X11.
>   * Try to get a text console via Ctrl-Alt-F1, see if I can fix it up.
> Then either:
>   * Log in, fix, switch back to X11
> or:
>   * Ctrl-Alt-F1 has no effect.  Damn.  Reboot time.
> 

/me must resist to make a comment about the difference between humans and 
animals being the capability to adapt to a changing environment.

There I resisted :)

Regards,

Hans



From jeremy at jeremysanders.net  Wed Oct 29 10:23:53 2008
From: jeremy at jeremysanders.net (Jeremy Sanders)
Date: Wed, 29 Oct 2008 10:23:53 +0000
Subject: Reasons to preseve X on tty7
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <ge9bsl$2fp$1@ger.gmane.org>
	<4908360D.8060900@hhs.nl>
Message-ID: <ge9djp$9lo$1@ger.gmane.org>

Hans de Goede wrote:

> Then we need to also teach autofs to start these services on demand.
> Having all the daemons on for the 1% of Linux users who use NFS (esp on
> things like laptops) is not the answer. We are moving more and more to a
> system where Linux adjusts dynamically to its environment (think
> NetworkManager, think device hot plugging, etc.)

Then please make sure you do this before making tiny optimisations.

I suspect it will be hard as autofs is partly in the kernel. You'd need to
ask an autofs expert whether this is possible without serious redesign.

I don't have a vanilla fedora install to verify, but isn't the nfs service
switched off in the default install anyway? I had to switch it on in my F8
kickstart files.

-- 
http://jeremysanders.net/




From rc040203 at freenet.de  Wed Oct 29 10:27:23 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 29 Oct 2008 11:27:23 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <ge9bsl$2fp$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org>
Message-ID: <1225276043.3897.337.camel@beck.corsepiu.local>

On Wed, 2008-10-29 at 09:54 +0000, Jeremy Sanders wrote:
> Hans de Goede wrote:
> 
> > So the idea is to patch all the initscripts which currently only get
> > started by default for NFS, to as the first thing in their start method
> > grep for nfs in /etc/fstab and if that is not found exit quietly without
> > doing anything further.
> 
> And this would break for people who are using autofs to mount nfs partition.
> You also need to start nfsd if /etc/exports contains something.
Exactly ... another silly proposal.




From dcbw at redhat.com  Wed Oct 29 10:29:51 2008
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 29 Oct 2008 06:29:51 -0400
Subject: Default network configuration during installation,
	NetworkManager and the /etc/sysconfig/network-script's
In-Reply-To: <49079787.3000906@gmail.com>
References: <315339.8427.qm@web26104.mail.ukl.yahoo.com>
	<20081028223126.GD197@rabbet.honolulu.burdell.org>
	<49079787.3000906@gmail.com>
Message-ID: <1225276191.28968.19.camel@localhost.localdomain>

On Tue, 2008-10-28 at 17:51 -0500, Les Mikesell wrote:
> David Cantrell wrote:
> > On Tue, Oct 28, 2008 at 11:31:40AM +0000, Michael Cutler wrote:
> >> (1). Include NetworkManager in the '@core' group, such that every install will include NetworkManager and a minimal install as described above will bring the system up with network connectivity.
> > 
> > I'm not opposed to this, but I'm also not opposed to it staying where it is.
> > 
> >> (2). Add some logic to the installer, if NetworkManager isnt to be installed, adjust the /etc/sysconfig/network-scripts appropriately such that network connectivity comes up after install. However this could be more problematic that I first thought, how many interfaces do you enable? If I have 4 NIC's, 3 not connected do I need to wait for the 'network' service to give up on the other three NIC's before bringing the system up etc.
> > 
> > I'm not in favor of this.  The situation you're describing is exactly why we
> > wanted to get rid of the network configuration screen.
> > 
> 
> Isn't the system already capable of knowing if link is up on an 
> interface and not waiting for dhcp if it isn't connected?

No, it depends on the driver.  There are some drivers that still do not
do link checking (some pcnet32, some ne2000 variants), or if they do,
only on a 30 second or 60 second poll (3c59x as of 2 years ago).  Maybe
we don't care about those drivers.

Dan




From rc040203 at freenet.de  Wed Oct 29 10:33:17 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 29 Oct 2008 11:33:17 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <ge9djp$9lo$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org> <4908360D.8060900@hhs.nl>
	<ge9djp$9lo$1@ger.gmane.org>
Message-ID: <1225276397.3897.342.camel@beck.corsepiu.local>

On Wed, 2008-10-29 at 10:23 +0000, Jeremy Sanders wrote:
> Hans de Goede wrote:
> 
> > Then we need to also teach autofs to start these services on demand.
> > Having all the daemons on for the 1% of Linux users who use NFS (esp on
> > things like laptops) is not the answer. We are moving more and more to a
> > system where Linux adjusts dynamically to its environment (think
> > NetworkManager, think device hot plugging, etc.)
>
> Then please make sure you do this before making tiny optimisations.
> 
> I suspect it will be hard as autofs is partly in the kernel. You'd need to
> ask an autofs expert whether this is possible without serious redesign.
IMO, the solution is to have bootup (network-) profiles to conditionally
configure "starting up" services depending upon what the user demanded
during boot up.







From kraxel at redhat.com  Wed Oct 29 10:37:12 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 11:37:12 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <49083A61.1010208@hhs.nl>
References: <555910.26860.qm@web32807.mail.mud.yahoo.com>	<490838D6.4000407@redhat.com>
	<49083A61.1010208@hhs.nl>
Message-ID: <49083CD8.8070104@redhat.com>

Hans de Goede wrote:
>>   * Oops, something busted in X11.
>>   * Try to get a text console via Ctrl-Alt-F1, see if I can fix it up.
>> Then either:
>>   * Log in, fix, switch back to X11
>> or:
>>   * Ctrl-Alt-F1 has no effect.  Damn.  Reboot time.
> 
> /me must resist to make a comment about the difference between humans
> and animals being the capability to adapt to a changing environment.

*I* know that I better try F2 too after reading that thread.  There are
Fedora users out there which are used to the traditional behavior and
don't follow fedora-devel ...

cheers,
  Gerd




From rc040203 at freenet.de  Wed Oct 29 10:36:54 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 29 Oct 2008 11:36:54 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225275505.3636.52.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org> <1225275505.3636.52.camel@hughsie-laptop>
Message-ID: <1225276614.3897.346.camel@beck.corsepiu.local>

On Wed, 2008-10-29 at 10:18 +0000, Richard Hughes wrote:
> On Wed, 2008-10-29 at 09:54 +0000, Jeremy Sanders wrote:
> > And this would break for people who are using autofs to mount nfs
> > partition.
> > You also need to start nfsd if /etc/exports contains something.
> 
> Classic example of what I said earlier. What percentage of people are
> using NFS on their machine right now? 0.5% - even less?
Does it matter? If you want Fedora to be a universally applicable
distro, it shouldn't.

> If you're setting up NFS on your machine, then you're quite capable of
> turning a service on. There's no need for it to be on by default.
Setting up NFS is trivial.





From pmatilai at laiskiainen.org  Wed Oct 29 10:37:32 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 29 Oct 2008 12:37:32 +0200 (EET)
Subject: Fedora 11: moving to posix file capabilities?
Message-ID: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>


Hate to interrupt the tty1 vs tty7 debate but...

We have kernel support for storing capabilities on filesystem since 2.6.24 
and recent libcap, both in F9 already. I just committed file capability 
support to rpm.org HEAD, filling in the final(?) missing piece. 
Capability support is not going to be in rpm 4.6.0 but no reason they 
can't be pulled into 4.6.1 which is easily in F11 timeframe.

Are we ready to start considering moving away from SUID bits to 
capabilities, in Fedora 11 maybe?

 	- Panu -



From j.w.r.degoede at hhs.nl  Wed Oct 29 10:48:27 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Oct 2008 11:48:27 +0100
Subject: F10 builds targetted for dist-f10-updates-candidate
In-Reply-To: <1225215911.2157.67.camel@luminos.localdomain>
References: <1225215911.2157.67.camel@luminos.localdomain>
Message-ID: <49083F7B.9040708@hhs.nl>



Jesse Keating wrote:
> In order to properly prepare F10 updates, all F10 builds are now
> targetted at dist-f10-updates-candidate.  This is a setting in the
> 'common' directory of your package modules, so you'll want to make sure
> you're using an up to date common.
> 
> The buildroot for dist-f10-updates-candidate is comprised of dist-f10
> content, which means builds done in dist-f10-updates-candidate
> will /not/ automatically be usable in the buildroot.  You'll need to
> request a buildroot override in order to do build sets.
> 
> Also, any build that we break the freeze for and tag for Fedora 10
> release will also be available in the buildroot.
> 
> I have locked the dist-f10 tag so that no more builds can automatically
> get tagged.  If you have a build that fails due to a locked tag, you can
> either ping releng, or manually tag it yourself for
> dist-f10-updates-candidate:
> 
> # koji tag-pkg dist-f10-updates-candidate <build-n-v-r>
> 

Will we be able to create updates in bodhi for F-10 now then?

I don't mind some smaller fixes / updates being shunted to F-10 updates because
of the freeze. But last time around (if I remember correctly) one could
actually create the updates in bodhi for quite a while, which meant one had to
remember or write down a list of packages to create updates for once bodhi
finally was able to do updates for the upcoming release.

Regards,

Hans



From aphukan.fedora at gmail.com  Wed Oct 29 11:09:42 2008
From: aphukan.fedora at gmail.com (Amitakhya Phukan)
Date: Wed, 29 Oct 2008 16:39:42 +0530
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <49084476.1080309@gmail.com>

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

Dax Kelson wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):
[snip]

Hi,

++1

Regards,
Amit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkIRHYACgkQisV6fTFpwA0hnACfVchRvf4UR0suc9KyJ/PZ0QeC
IgsAn3Ka+Ke5bprvq+hUwFqjyzw0OiHy
=uQ7b
-----END PGP SIGNATURE-----



From galibert at pobox.com  Wed Oct 29 11:11:07 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Wed, 29 Oct 2008 12:11:07 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225275505.3636.52.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <ge9bsl$2fp$1@ger.gmane.org>
	<1225275505.3636.52.camel@hughsie-laptop>
Message-ID: <20081029111107.GA52003@dspnet.fr.eu.org>

On Wed, Oct 29, 2008 at 10:18:25AM +0000, Richard Hughes wrote:
> On Wed, 2008-10-29 at 09:54 +0000, Jeremy Sanders wrote:
> > And this would break for people who are using autofs to mount nfs
> > partition.
> > You also need to start nfsd if /etc/exports contains something.
> 
> Classic example of what I said earlier. What percentage of people are
> using NFS on their machine right now? 0.5% - even less?

67.3%.

  O "I love statistics" G.



From pertusus at free.fr  Wed Oct 29 09:56:42 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 29 Oct 2008 10:56:42 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225273515.3636.48.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
Message-ID: <20081029095642.GC2834@free.fr>

On Wed, Oct 29, 2008 at 09:45:15AM +0000, Richard Hughes wrote:
> 
> I don't think it can work like that.
> 
> 1. send a mail saying sendmail won't be on the default desktop install
> 2. heat hands on ensuing flames

This shown up to be controversial, so in the end someone has to decide.
But at least asking may bring in interesting issues and also help. There
is noise, of course, and bikesheding, but not only.

> The problem with fedora-devel-list is that the 0.01% of most technical
> users are there, most unable to understand that normal people don't use
> an smtp server or setup nfs.

But they are also the most able to do interesting proposals and help with 
the code.
 
> If we include everything we've ever started by default in the future
> versions, and any of the latest cool new stuff, our boot times are going
> to get longer, and our base install bigger.
> 
> Design by committee just doesn't work.

It is not design by commitee I am advocating, but using the resources
here to try to also please old timers and advanced users. In the end
somebody has to take decisions in an authoritative way, sure, but may be
more informed and have more support if community is asked in the process.
The flamewars will always be there, but additionally you can have a
better design and more participations if a consultation is done before
the fact.

--
Pat



From k.georgiou at imperial.ac.uk  Wed Oct 29 11:20:13 2008
From: k.georgiou at imperial.ac.uk (Kostas Georgiou)
Date: Wed, 29 Oct 2008 11:20:13 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <49082E6B.7080304@hhs.nl>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
Message-ID: <20081029112012.GA15952@imperial.ac.uk>

On Wed, Oct 29, 2008 at 10:35:39AM +0100, Hans de Goede wrote:

> Richard Hughes wrote:
>
>> mean we are still loading sendmail, isdn, nfslock, and all other legacy
>> stuff in ten years time.
>>
>
> Talking about the nfs (and related rpc daemons) I recently had a good 
> idea for those, some will hate it, but those are the people who so no to 
> anything looking like progress, so I say lets just ignore them.
>
> This idea is taken from some work I've done recently to stop the iscsi 
> related daemons from starting unnecessary be default, something which has 
> become relevant as the libvirt stuff drags in iscsi-initiator-utils on 
> very installation that has libvirt, of which there are quite a few.
>
> So the idea is to patch all the initscripts which currently only get 
> started by default for NFS, to as the first thing in their start method 
> grep for nfs in /etc/fstab and if that is not found exit quietly without 
> doing anything further.
>
> Then to make manual mounting of nfs exports not in fstab work properly, 
> the suggested fix is to patch mount to check if the necessary daemons are 
> running and if not start them. Since this will probably turn out to be 
> distro specific I think it would be best to have a checknfsdaemons shell 
> script in some standard location provided by the distro and let mount 
> call that before each nfs mount. (Oh the horror an additional entire fork 
> and exec on each nfs mount, hello people this is going over the network, 
> forget about the fork and exec cost, thank you).

You are forgetting autofs in your scheme, my systems never have nfs in
/etc/fstab but if nfs doesn't start the machines are useless. Why not
let people do /sbin/chkconfig nfs on|off instead of trying to guess what
they want.

Kostas Georgiou



From sundaram at fedoraproject.org  Wed Oct 29 11:23:20 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Oct 2008 16:53:20 +0530
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49074861.2010200@odu.neva.ru>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225213620.3407.34.camel@metroid.rdu.redhat.com>
	<49074861.2010200@odu.neva.ru>
Message-ID: <490847A8.3010909@fedoraproject.org>

Dmitry Butskoy wrote:
> Will Woods wrote:
>>  
>> 1) add "start on started prefdm" to /etc/event.d/tty1
>> 2) (GNOME) edit /etc/gdm/custom.conf and add
>>      FirstVT=7
>>    to the top of the file. Or:
>>    (KDE) edit /etc/kde/kdm/kdmrc and set
>>      ServerVTs=-7
>>      ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
>>   
> 
> Could it be mentioned in ReleaseNotes?

Yes, Join the docs project. It only takes a couple of minutes to sign up 
and edit the wiki.

http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process

Rahul



From kevin.kofler at chello.at  Wed Oct 29 11:24:13 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 29 Oct 2008 11:24:13 +0000 (UTC)
Subject: rawhide report: 20081028 changes
References: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
	<1225237056.2157.101.camel@luminos.localdomain>
	<20081029104532.138c5511@python3.es.egwn.lan>
Message-ID: <loom.20081029T112240-50@post.gmane.org>

Matthias Saou <thias <at> 
spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net> writes:
> If this is too much of a hassle so late in the Fedora 10 cycle, then
> I'd have no objection to have this build reverted.

IMHO there's no need to revert anything, the third-party stuff simply needs to 
be rebuilt. There's plenty of time for the third-party repos to rebuild their 
stuff (and I'm sure you can take care of RPM Fusion ;-) ).

        Kevin Kofler



From atkac at redhat.com  Wed Oct 29 12:26:29 2008
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 29 Oct 2008 13:26:29 +0100
Subject: Package review - How handle licence in source code only?
Message-ID: <20081029122629.GA20614@evileye.atkac.englab.brq.redhat.com>

Hi all,

I'm reviewing dnsperf package -
https://bugzilla.redhat.com/show_bug.cgi?id=467798. Licence of code is
written only in source code itself:

...
 * Copyright (C) 2004 - 2008 Nominum, Inc.
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation for any purpose with or without fee is hereby granted,
 * provided that the above copyright notice and this permission notice
 * appear in all copies.
...

What should be correct licence tag? The licence is BSD compatible so
can I recommend BSD licence tag?

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.



From jreznik at redhat.com  Wed Oct 29 11:35:24 2008
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Wed, 29 Oct 2008 07:35:24 -0400 (EDT)
Subject: Package review - How handle licence in source code only?
In-Reply-To: <1953485846.153401225279986353.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1158743221.153601225280124350.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

Hi,
the best solution I think is to ask authors to
clarify license and ask them to include LICENSE
file in source tarball.

R.
---
Jaroslav Reznik <jreznik at redhat.com>
Software Engineer - Base OS Core Services Brno
Red Hat, Inc.
+420 532 294 275

----- "Adam Tkac" <atkac at redhat.com> wrote:

> Hi all,
> 
> I'm reviewing dnsperf package -
> https://bugzilla.redhat.com/show_bug.cgi?id=467798. Licence of code
> is
> written only in source code itself:
> 
> ...
>  * Copyright (C) 2004 - 2008 Nominum, Inc.
>  *
>  * Permission to use, copy, modify, and distribute this software and
> its
>  * documentation for any purpose with or without fee is hereby
> granted,
>  * provided that the above copyright notice and this permission
> notice
>  * appear in all copies.
> ...
> 
> What should be correct licence tag? The licence is BSD compatible so
> can I recommend BSD licence tag?
> 
> Regards, Adam
> 
> -- 
> Adam Tkac, Red Hat, Inc.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From dominik at greysector.net  Wed Oct 29 11:37:36 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 29 Oct 2008 12:37:36 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225272707.3636.42.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
Message-ID: <20081029113735.GA1293@mokona.greysector.net>

On Wednesday, 29 October 2008 at 10:31, Richard Hughes wrote:
> On Wed, 2008-10-29 at 11:25 +0200, shmuel siegel wrote:
> > You are responding to an issue that no one is bringing up. No one is 
> > talking about how many mingettys are launched. On the other hand you
> > are declaring as a resolved starting point the very thing that is
> > being questioned. The question is "who gets tty1".
> 
> Who cares? If X lives on tty7 and you get an extra flicker, then that's
> bad. If it lives on ttyX and it doesn't flicker, it's good.
> 
> The sort of person that even knows what a tty is, is probably in a
> position where they can change it to whatever they want. Seriously, had
> anyone done any research on the number of Fedora users who even use
> ttys?
> 
> This isn't a community decision decided by +1 or -1's. This is the
> package maintainer (and upstream) changing with a good reason.

Well, the community is saying that reason is not good enough.
I think it's fair to ask the package maintainer to reconsider.
Making changes that break years-long traditional behaviour
without community consultation is arrogant at best.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From dominik at greysector.net  Wed Oct 29 11:46:51 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 29 Oct 2008 12:46:51 +0100
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
Message-ID: <20081029114651.GB1293@mokona.greysector.net>

On Wednesday, 29 October 2008 at 11:37, Panu Matilainen wrote:
> 
> Hate to interrupt the tty1 vs tty7 debate but...
> 
> We have kernel support for storing capabilities on filesystem since 2.6.24 
> and recent libcap, both in F9 already. I just committed file capability 
> support to rpm.org HEAD, filling in the final(?) missing piece. 
> Capability support is not going to be in rpm 4.6.0 but no reason they 
> can't be pulled into 4.6.1 which is easily in F11 timeframe.
> 
> Are we ready to start considering moving away from SUID bits to 
> capabilities, in Fedora 11 maybe?

Make it a feature: https://fedoraproject.org/wiki/Features/Policy

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From airlied at redhat.com  Wed Oct 29 11:57:41 2008
From: airlied at redhat.com (Dave Airlie)
Date: Wed, 29 Oct 2008 21:57:41 +1000
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <1225281461.21057.0.camel@optimus>

On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):
> 
> * The default behavior of X on tty7 has been in place since the
> beginning (almost a decade and a half).
> 

-1

Can one man make a difference? I voted for Kodos.

Dave.



From skvidal at fedoraproject.org  Wed Oct 29 12:03:14 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 08:03:14 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225275505.3636.52.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org> <1225275505.3636.52.camel@hughsie-laptop>
Message-ID: <1225281794.21485.31.camel@rosebud>

On Wed, 2008-10-29 at 10:18 +0000, Richard Hughes wrote:
> On Wed, 2008-10-29 at 09:54 +0000, Jeremy Sanders wrote:
> > And this would break for people who are using autofs to mount nfs
> > partition.
> > You also need to start nfsd if /etc/exports contains something.
> 
> Classic example of what I said earlier. What percentage of people are
> using NFS on their machine right now? 0.5% - even less?
> 

What percentage of _which_ people? If you want to count pure machines
using nfs vs "people" using nfs I think you're going to find your
percentage machine-wise is closer to 30-40%.

Those lab clusters of 300+ machines really weigh down your stats.

-sv




From skvidal at fedoraproject.org  Wed Oct 29 12:08:02 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 08:08:02 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
Message-ID: <1225282082.21485.33.camel@rosebud>

On Wed, 2008-10-29 at 12:37 +0200, Panu Matilainen wrote:
> Hate to interrupt the tty1 vs tty7 debate but...
> 
> We have kernel support for storing capabilities on filesystem since 2.6.24 
> and recent libcap, both in F9 already. I just committed file capability 
> support to rpm.org HEAD, filling in the final(?) missing piece. 
> Capability support is not going to be in rpm 4.6.0 but no reason they 
> can't be pulled into 4.6.1 which is easily in F11 timeframe.
> 
> Are we ready to start considering moving away from SUID bits to 
> capabilities, in Fedora 11 maybe?

How does that mesh with networked file systems (nfs, samba)?

-sv




From limb at jcomserv.net  Wed Oct 29 12:06:18 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 29 Oct 2008 07:06:18 -0500 (CDT)
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <20081028160011.61d9b3ca@atbws1.stanford.edu>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
Message-ID: <257782764662c0a1e590139cabf37e28.squirrel@mail.jcomserv.net>


> With a good chunk of help, I now have fedora builds of pymol available
> (see bugzilla ID 462251 for the full details). However, I'd like to
> have some help with building/testing for EL5, as I'd like to make it
> available but don't have an EL box to explicitly test on.

I'll bite.  Point me to a SRPM and a list of what I should do to test,
aside from building.

> Many thanks,
> Tim
>
> --
> CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From limb at jcomserv.net  Wed Oct 29 12:11:43 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 29 Oct 2008 07:11:43 -0500 (CDT)
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <20081028160011.61d9b3ca@atbws1.stanford.edu>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
Message-ID: <c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>


> With a good chunk of help, I now have fedora builds of pymol available
> (see bugzilla ID 462251 for the full details). However, I'd like to
> have some help with building/testing for EL5, as I'd like to make it
> available but don't have an EL box to explicitly test on.


Found it from the review.

Build error:

+ desktop-file-install
--dir=/var/tmp/pymol-1.1-10.20081015svn3468-root-jciesla/usr/share/applications
/home/jciesla/rpmbuild/SOURCES/pymol.desktop
Must specify the vendor namespace for these files with --vendor
error: Bad exit status from /var/tmp/rpm-tmp.25017 (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.25017 (%install)


> Many thanks,
> Tim
>
> --
> CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From hughsient at gmail.com  Wed Oct 29 12:18:08 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 29 Oct 2008 12:18:08 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225281794.21485.31.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org> <1225275505.3636.52.camel@hughsie-laptop>
	<1225281794.21485.31.camel@rosebud>
Message-ID: <1225282688.3980.4.camel@hughsie-laptop>

On Wed, 2008-10-29 at 08:03 -0400, seth vidal wrote:
> What percentage of _which_ people? If you want to count pure machines
> using nfs vs "people" using nfs I think you're going to find your
> percentage machine-wise is closer to 30-40%.
> 
> Those lab clusters of 300+ machines really weigh down your stats.

Sure, but they aren't going to be using a desktop live CD, they'll be
using a kickstart file or some sort of automated cloning service.

The admin configures all this stuff and creates a config setting up NFS,
not the end user.

Richard.




From kraxel at redhat.com  Wed Oct 29 12:21:12 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 13:21:12 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225281794.21485.31.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl>	<ge9bsl$2fp$1@ger.gmane.org>
	<1225275505.3636.52.camel@hughsie-laptop>
	<1225281794.21485.31.camel@rosebud>
Message-ID: <49085538.5000303@redhat.com>

seth vidal wrote:
> On Wed, 2008-10-29 at 10:18 +0000, Richard Hughes wrote:
>> On Wed, 2008-10-29 at 09:54 +0000, Jeremy Sanders wrote:
>>> And this would break for people who are using autofs to mount nfs
>>> partition.
>>> You also need to start nfsd if /etc/exports contains something.
>> Classic example of what I said earlier. What percentage of people are
>> using NFS on their machine right now? 0.5% - even less?
> 
> What percentage of _which_ people? If you want to count pure machines
> using nfs vs "people" using nfs I think you're going to find your
> percentage machine-wise is closer to 30-40%.

Even on my Laptop I use NFS, to share /home between host and virtual
machine guests.  When including the guests into the stats I'm scoring 5
machines for the laptop only ;)

cheers,
  Gerd




From bdwheele at indiana.edu  Wed Oct 29 12:26:30 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 08:26:30 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225281461.21057.0.camel@optimus>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
Message-ID: <1225283190.23396.10.camel@nibbler.dlib.indiana.edu>

I'm going to agree with the -1.  

Almost all of the "reasons" from the original email boil down to "we've
always done it this way".  

I don't see what the big deal really is.  We'd have this same argument
if someone decided to change the number of getty processes.  I
personally think 6 is too many, but since they don't take up much space,
I don't care that much.

On the topic of documentation:  it should be documented in the release
notes and elsewhere.  The only people that are really going to run into
this problem are people troubleshooting, and if they're worth anything
for troubleshooting, they're going to either know its been changed or be
smart enough to try tty2.

Brian




On Wed, 2008-10-29 at 21:57 +1000, Dave Airlie wrote:
> On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> > I would argue strongly that this change should not be made for the
> > following reasons (in no particular order):
> > 
> > * The default behavior of X on tty7 has been in place since the
> > beginning (almost a decade and a half).
> > 
> 
> -1
> 
> Can one man make a difference? I voted for Kodos.
> 
> Dave.
> 



From joe at nall.com  Wed Oct 29 12:27:51 2008
From: joe at nall.com (Joe Nall)
Date: Wed, 29 Oct 2008 07:27:51 -0500
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
Message-ID: <7863543B-361F-41B1-A559-796823CA5E26@nall.com>


On Oct 29, 2008, at 5:37 AM, Panu Matilainen wrote:

>
> Hate to interrupt the tty1 vs tty7 debate but...
>
> We have kernel support for storing capabilities on filesystem since  
> 2.6.24 and recent libcap, both in F9 already. I just committed file  
> capability support to rpm.org HEAD, filling in the final(?) missing  
> piece. Capability support is not going to be in rpm 4.6.0 but no  
> reason they can't be pulled into 4.6.1 which is easily in F11  
> timeframe.
>
> Are we ready to start considering moving away from SUID bits to  
> capabilities, in Fedora 11 maybe?

Not until this bug is fixed :)

prelink erases file-based capabilities

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

joe



From skvidal at fedoraproject.org  Wed Oct 29 12:28:30 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 08:28:30 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225282688.3980.4.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org> <1225275505.3636.52.camel@hughsie-laptop>
	<1225281794.21485.31.camel@rosebud>
	<1225282688.3980.4.camel@hughsie-laptop>
Message-ID: <1225283310.21485.41.camel@rosebud>

On Wed, 2008-10-29 at 12:18 +0000, Richard Hughes wrote:
> On Wed, 2008-10-29 at 08:03 -0400, seth vidal wrote:
> > What percentage of _which_ people? If you want to count pure machines
> > using nfs vs "people" using nfs I think you're going to find your
> > percentage machine-wise is closer to 30-40%.
> > 
> > Those lab clusters of 300+ machines really weigh down your stats.
> 
> Sure, but they aren't going to be using a desktop live CD, they'll be
> using a kickstart file or some sort of automated cloning service.
> 
> The admin configures all this stuff and creates a config setting up NFS,
> not the end user.

I agree. I've also not objected to turning off nfsd (which it already
is, btw). I'm objecting to your claim that no one uses nfs. I think that
is not a well founded claim.

-sv




From dan at danny.cz  Wed Oct 29 12:30:37 2008
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Wed, 29 Oct 2008 13:30:37 +0100
Subject: unable to switch vt
Message-ID: <1225283437.3593.45.camel@eagle.danny.cz>

Hi,

I hope this to be a bug and not a really bad joke. I am completely
unable to switch vt with current rawhide kernel
(2.6.27.4-65.fc10.x86_64) and it works with an older one
(2.6.27.3-27.rc1.fc10.x86_64), there is no reaction on pressing
Ctrl-Alt-F[1-6]

I have
- no graphical boot, console is vesafb
- default runlevel 5
- updated /etc/event.d/tty1 to be same as tty[2-6] as suggested by
wwoods (I want X on vt7)
- I am logged in GNOME

with last kernel from koji

[root at localhost ~]# ps ax | grep gdm
 2596 ?        Ss     0:00 /usr/sbin/gdm-binary -nodaemon
 2657 ?        S      0:00 /usr/libexec/gdm-simple-slave
--display-id /org/gnome/DisplayManager/Display1 --force-active-vt
 2658 ?        Ss     0:05 /usr/bin/Xorg :0 -nr -verbose
-auth /var/run/gdm/auth-for-gdm-Ng4bML/database -nolisten tcp vt1

[root at localhost ~]# tail -5 /var/log/Xorg.0.log
Failed to switch consoles (Input/output error)
Failed to switch consoles (Input/output error)
Failed to switch consoles (Input/output error)
(EE) intel(0): First SDVOB output reported failure to sync
Failed to switch consoles (Input/output error)


vs. with older kernel

[root at localhost /]# ps ax | grep gdm
 2598 ?        Ss     0:00 /usr/sbin/gdm-binary -nodaemon
 2658 ?        S      0:00 /usr/libexec/gdm-simple-slave
--display-id /org/gnome/DisplayManager/Display1
 2659 tty7     Ss+    0:05 /usr/bin/Xorg :0 -br -verbose
-auth /var/run/gdm/auth-for-gdm-K8iWt5/database -nolisten tcp

and no errors in Xorg.log


snippet from grub.conf:

title Fedora Rawhide
        root (hd0,0)
        kernel /vmlinuz-2.6.27.3-27.rc1.fc10.x86_64 ro
root=/dev/Linux/Rawhide vga=792
        initrd /initrd-2.6.27.3-27.rc1.fc10.x86_64.img
title Fedora Rawhide last kernel
        root (hd0,0)
        kernel /vmlinuz-2.6.27.4-65.fc10.x86_64 ro
root=/dev/Linux/Rawhide vga=792
        initrd /initrd-2.6.27.4-65.fc10.x86_64.img


		Dan




From mackay_d at bellsouth.net  Wed Oct 29 12:31:47 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Wed, 29 Oct 2008 07:31:47 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225273515.3636.48.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
Message-ID: <1225283507.5412.178.camel@vorpal.macdev.com>


On Wed, 2008-10-29 at 09:45 +0000, Richard Hughes wrote:

> Design by committee just doesn't work.

So all of those ISO and IEEE standards are worthless?

Dave




From fedora at shmuelhome.mine.nu  Wed Oct 29 12:34:59 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Wed, 29 Oct 2008 14:34:59 +0200
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
Message-ID: <49085873.6070107@shmuelhome.mine.nu>

Brian Wheeler wrote:
> I'm going to agree with the -1.  
>
> Almost all of the "reasons" from the original email boil down to "we've
> always done it this way".  
>
>   
And what about the other reasons?

There have been two reasons given for maintaining the change.
1) Your use case doesn't interest me.
2) We've thought of a way to accomplish our goal. There have been no 
responses to the question if other methods would accomplish the same 
objective.



From jg at laptop.org  Wed Oct 29 12:36:44 2008
From: jg at laptop.org (Jim Gettys)
Date: Wed, 29 Oct 2008 08:36:44 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
Message-ID: <1225283804.7036.73.camel@jg-vaio>

FWIW: we investigated memory usage of VT's, and it was significant; we
reduced the number of VT's available on the OLPC (3 or 4, IIRC), and
moved the VT X was on, without any problems.

Of course, our environment is atypical, but that can be said about
everyone's environment...
                         - Jim


On Wed, 2008-10-29 at 08:26 -0400, Brian Wheeler wrote:
> I'm going to agree with the -1.  
> 
> Almost all of the "reasons" from the original email boil down to "we've
> always done it this way".  
> 
> I don't see what the big deal really is.  We'd have this same argument
> if someone decided to change the number of getty processes.  I
> personally think 6 is too many, but since they don't take up much space,
> I don't care that much.
> 
> On the topic of documentation:  it should be documented in the release
> notes and elsewhere.  The only people that are really going to run into
> this problem are people troubleshooting, and if they're worth anything
> for troubleshooting, they're going to either know its been changed or be
> smart enough to try tty2.
> 
> Brian
> 
> 
> 
> 
> On Wed, 2008-10-29 at 21:57 +1000, Dave Airlie wrote:
> > On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> > > I would argue strongly that this change should not be made for the
> > > following reasons (in no particular order):
> > > 
> > > * The default behavior of X on tty7 has been in place since the
> > > beginning (almost a decade and a half).
> > > 
> > 
> > -1
> > 
> > Can one man make a difference? I voted for Kodos.
> > 
> > Dave.
> > 
> 
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child



From bdwheele at indiana.edu  Wed Oct 29 12:42:58 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 08:42:58 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <49085873.6070107@shmuelhome.mine.nu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49085873.6070107@shmuelhome.mine.nu>
Message-ID: <1225284178.23396.19.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 14:34 +0200, shmuel siegel wrote:
> Brian Wheeler wrote:
> > I'm going to agree with the -1.  
> >
> > Almost all of the "reasons" from the original email boil down to "we've
> > always done it this way".  
> >
> >   
> And what about the other reasons?
> 
> There have been two reasons given for maintaining the change.
> 1) Your use case doesn't interest me.
> 2) We've thought of a way to accomplish our goal. There have been no 
> responses to the question if other methods would accomplish the same 
> objective.
> 

I'm still trying to figure out why there's all the love for X on tty7.

Things change.  We adapt.  Having the primary interface on tty1 makes
much more sense than it being on tty7.  On a semi-serious note, the tty7
choice is a historical accident...not a design choice.

OSS has been replaced.
Static /dev has been replaced.
SysV init has been replaced.
IDE drives aren't /dev/hd* anymore.
We're using LVM instead of raw partitions.

All of these things (and more) caused a bit of trouble when they were
first introduced and then became the norm.  


Brian




From anders at trudheim.co.uk  Wed Oct 29 12:42:54 2008
From: anders at trudheim.co.uk (Anders Karlsson)
Date: Wed, 29 Oct 2008 13:42:54 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029113735.GA1293@mokona.greysector.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
Message-ID: <20081029124254.GD3628@localhost.localdomain>

* Dominik 'Rathann' Mierzejewski <dominik at greysector.net> [20081029 12:38]:
> 
> Well, the community is saying that reason is not good enough.
> I think it's fair to ask the package maintainer to reconsider.
> Making changes that break years-long traditional behaviour
> without community consultation is arrogant at best.

Breaking with tradition created things like OS-X (which fwiw is what
any sane desktop out there today is trying to emulate).

Doing something because "it's always been done like that" is a really
bad reason. Doing something on technical merit and changing when a
better way to do something is found is what I think should be done.

Which tty you run X on I don't really care, as I think the end goal
should be to ditch X and do what OS-X did.

The biggest innovations happened by not following the sheep.

/Anders



From bdwheele at indiana.edu  Wed Oct 29 12:46:40 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 08:46:40 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283804.7036.73.camel@jg-vaio>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225283804.7036.73.camel@jg-vaio>
Message-ID: <1225284400.23396.23.camel@nibbler.dlib.indiana.edu>

Interesting.  Besides making sure that X ends up on tty7, is there any
reason why we have 6 VTs?  For all the years I've been using linux in a
personal and professional capacity, I think the most ttys I've had
active at any given time was _maybe_ 4...otherwise I was doing
everything in X.

Brian

On Wed, 2008-10-29 at 08:36 -0400, Jim Gettys wrote:
> FWIW: we investigated memory usage of VT's, and it was significant; we
> reduced the number of VT's available on the OLPC (3 or 4, IIRC), and
> moved the VT X was on, without any problems.
> 
> Of course, our environment is atypical, but that can be said about
> everyone's environment...
>                          - Jim
> 
> 
> On Wed, 2008-10-29 at 08:26 -0400, Brian Wheeler wrote:
> > I'm going to agree with the -1.  
> > 
> > Almost all of the "reasons" from the original email boil down to "we've
> > always done it this way".  
> > 
> > I don't see what the big deal really is.  We'd have this same argument
> > if someone decided to change the number of getty processes.  I
> > personally think 6 is too many, but since they don't take up much space,
> > I don't care that much.
> > 
> > On the topic of documentation:  it should be documented in the release
> > notes and elsewhere.  The only people that are really going to run into
> > this problem are people troubleshooting, and if they're worth anything
> > for troubleshooting, they're going to either know its been changed or be
> > smart enough to try tty2.
> > 
> > Brian
> > 
> > 
> > 
> > 
> > On Wed, 2008-10-29 at 21:57 +1000, Dave Airlie wrote:
> > > On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> > > > I would argue strongly that this change should not be made for the
> > > > following reasons (in no particular order):
> > > > 
> > > > * The default behavior of X on tty7 has been in place since the
> > > > beginning (almost a decade and a half).
> > > > 
> > > 
> > > -1
> > > 
> > > Can one man make a difference? I voted for Kodos.
> > > 
> > > Dave.
> > > 
> > 
> -- 
> Jim Gettys <jg at laptop.org>
> One Laptop Per Child
> 



From skvidal at fedoraproject.org  Wed Oct 29 12:51:02 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 08:51:02 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029124254.GD3628@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
Message-ID: <1225284662.21485.46.camel@rosebud>

On Wed, 2008-10-29 at 13:42 +0100, Anders Karlsson wrote:
> * Dominik 'Rathann' Mierzejewski <dominik at greysector.net> [20081029 12:38]:
> > 
> > Well, the community is saying that reason is not good enough.
> > I think it's fair to ask the package maintainer to reconsider.
> > Making changes that break years-long traditional behaviour
> > without community consultation is arrogant at best.
> 
> Breaking with tradition created things like OS-X (which fwiw is what
> any sane desktop out there today is trying to emulate).
> 
> Doing something because "it's always been done like that" is a really
> bad reason. Doing something on technical merit and changing when a
> better way to do something is found is what I think should be done.
> 
> Which tty you run X on I don't really care, as I think the end goal
> should be to ditch X and do what OS-X did.
> 
> The biggest innovations happened by not following the sheep.

Actually, the biggest innovations aren't innovations. More times than
not they are evolutionary steps taken by slowly modifying an existing
design. They only look like innovations when viewed from the future.

A great example: A very bright individual once said to me "we need a
revolutionary change like the CD was from the cassette tape for music".
To which I responded:
   1. the cd was preceded by the less successful laser disc
   2. they were both preceded by wildly successful vinyl record.

The concept of spinning media storing data and allowing you to seek to
any location on the media nearly instantly is not a new idea.

There's no one working in computing today ANYWHERE who is doing
revolutionary work. I'd argue there is no such thing as revolutionary
work AT ALL. Stop looking for it where it is not.

-sv




From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Oct 29 13:00:46 2008
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 29 Oct 2008 22:00:46 +0900
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
Message-ID: <49085E7E.7080009@ioa.s.u-tokyo.ac.jp>

Panu Matilainen wrote, at 10/29/2008 07:37 PM +9:00:
> 
> Hate to interrupt the tty1 vs tty7 debate but...
> 
> We have kernel support for storing capabilities on filesystem since 
> 2.6.24 and recent libcap, both in F9 already. I just committed file 
> capability support to rpm.org HEAD, filling in the final(?) missing 
> piece. Capability support is not going to be in rpm 4.6.0 but no reason 
> they can't be pulled into 4.6.1 which is easily in F11 timeframe.
> 
> Are we ready to start considering moving away from SUID bits to 
> capabilities, in Fedora 11 maybe?
> 

For reference, one of them problems we met is:
https://bugzilla.redhat.com/show_bug.cgi?id=455713

Regards,
Mamoru



From kraxel at redhat.com  Wed Oct 29 13:02:45 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 14:02:45 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <49085EF5.1000306@redhat.com>

  Hi,

> * Fedora is now inconsistent with itself in regards to where X is
> running depending on if you booted to runlevel 3 and used startx or if
> you booted to runlevel 5. When your uptime is 3 weeks, how do you
> remember which method you used to start the GUI?

Just noticed one more self-inconsistency: Going to runlevel 3, then back
to runlevel 5 moves X11 from tty1 to tty7.

cheers,
  Gerd




From lesmikesell at gmail.com  Wed Oct 29 13:03:06 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 08:03:06 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283507.5412.178.camel@vorpal.macdev.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl>	<20081029093818.GB2834@free.fr>	<1225273515.3636.48.camel@hughsie-laptop>
	<1225283507.5412.178.camel@vorpal.macdev.com>
Message-ID: <49085F0A.4010901@gmail.com>

David G. Mackay wrote:
> On Wed, 2008-10-29 at 09:45 +0000, Richard Hughes wrote:
> 
>> Design by committee just doesn't work.
> 
> So all of those ISO and IEEE standards are worthless?

Not to mention POSIX and the LSB...

-- 
   Les Mikesell
    lesmikesell at gmail.com



From rc040203 at freenet.de  Wed Oct 29 13:04:38 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 29 Oct 2008 14:04:38 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225273515.3636.48.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
Message-ID: <1225285478.3897.373.camel@beck.corsepiu.local>

On Wed, 2008-10-29 at 09:45 +0000, Richard Hughes wrote:
> On Wed, 2008-10-29 at 10:38 +0100, Patrice Dumas wrote:
> > I think that it should be done the other way around, propose the
> > changes that affect the whole distro on th is list, listen to what
> > people have to say, or, more importantly what code they have to
> > propose if they don't like a given design, and then implement it with
> > all the concerned parties.
> 
> I don't think it can work like that.
> 
> 1. send a mail saying sendmail won't be on the default desktop install
> 2. heat hands on ensuing flames
> 
> The problem with fedora-devel-list is that the 0.01% of most technical
> users are there, most unable to understand that normal people don't use
> an smtp server or setup nfs.
The majority of the desktop users are using Windows. The majority of the
non-technical population probably also hasn't heard about Fedora,
either.

> If we include everything we've ever started by default in the future
> versions, and any of the latest cool new stuff, our boot times are going
> to get longer,
 Well, then something must have gone utterly wrong with Fedora's
development ... 

>  and our base install bigger.
Yes, the new developments have blown them up. All contributed to the
bloat and the increasing demands on HW resources. 

The older "features" didn't. vt1-6+vt7 have been around for ca. 15
years, nfs, sendmail, autofs, etc. also are around in Linux for very
long times.

> Design by committee just doesn't work.
Design by tyranny and design by suppression of minorities
doesn't work either.




From lesmikesell at gmail.com  Wed Oct 29 13:06:21 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 08:06:21 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225284662.21485.46.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
Message-ID: <49085FCD.9060707@gmail.com>

seth vidal wrote:
> On Wed, 2008-10-29 at 13:42 +0100, Anders Karlsson wrote:
>> * Dominik 'Rathann' Mierzejewski <dominik at greysector.net> [20081029 12:38]:
>>> Well, the community is saying that reason is not good enough.
>>> I think it's fair to ask the package maintainer to reconsider.
>>> Making changes that break years-long traditional behaviour
>>> without community consultation is arrogant at best.
>> Breaking with tradition created things like OS-X (which fwiw is what
>> any sane desktop out there today is trying to emulate).
>>
>> Doing something because "it's always been done like that" is a really
>> bad reason. Doing something on technical merit and changing when a
>> better way to do something is found is what I think should be done.
>>
>> Which tty you run X on I don't really care, as I think the end goal
>> should be to ditch X and do what OS-X did.
>>
>> The biggest innovations happened by not following the sheep.
> 
> Actually, the biggest innovations aren't innovations. More times than
> not they are evolutionary steps taken by slowly modifying an existing
> design. They only look like innovations when viewed from the future.
> 
> A great example: A very bright individual once said to me "we need a
> revolutionary change like the CD was from the cassette tape for music".
> To which I responded:
>    1. the cd was preceded by the less successful laser disc
>    2. they were both preceded by wildly successful vinyl record.
> 
> The concept of spinning media storing data and allowing you to seek to
> any location on the media nearly instantly is not a new idea.
> 
> There's no one working in computing today ANYWHERE who is doing
> revolutionary work. I'd argue there is no such thing as revolutionary
> work AT ALL. Stop looking for it where it is not.

I don't quite understand the obsession with making boot time faster 
anyway.  Machines should only boot when they have a new kernel to 
install.  If they aren't needed all the time they should sleep or 
hibernate, waking up with everything still running.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jg at laptop.org  Wed Oct 29 13:07:13 2008
From: jg at laptop.org (Jim Gettys)
Date: Wed, 29 Oct 2008 09:07:13 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225284400.23396.23.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225283804.7036.73.camel@jg-vaio>
	<1225284400.23396.23.camel@nibbler.dlib.indiana.edu>
Message-ID: <1225285633.7036.79.camel@jg-vaio>

Heh.  I was using xterm and X for my console in 1985, IIRC; it sure beat
line printer consoles....  

I look at Linux VT's and their kernel complexity with a mixture of awe
and stupefaction that so much effort has gone in that direction....  I
guess it is an artifact of how Linux came about; X wasn't available
early on, from what I've read.

What is more, then you make sure X starts early in the boot sequence,
and starts fast, and "just works".
                        - Jim


On Wed, 2008-10-29 at 08:46 -0400, Brian Wheeler wrote:
> Interesting.  Besides making sure that X ends up on tty7, is there any
> reason why we have 6 VTs?  For all the years I've been using linux in a
> personal and professional capacity, I think the most ttys I've had
> active at any given time was _maybe_ 4...otherwise I was doing
> everything in X.
> 
> Brian
> 
> On Wed, 2008-10-29 at 08:36 -0400, Jim Gettys wrote:
> > FWIW: we investigated memory usage of VT's, and it was significant; we
> > reduced the number of VT's available on the OLPC (3 or 4, IIRC), and
> > moved the VT X was on, without any problems.
> > 
> > Of course, our environment is atypical, but that can be said about
> > everyone's environment...
> >                          - Jim
> > 
> > 
> > On Wed, 2008-10-29 at 08:26 -0400, Brian Wheeler wrote:
> > > I'm going to agree with the -1.  
> > > 
> > > Almost all of the "reasons" from the original email boil down to "we've
> > > always done it this way".  
> > > 
> > > I don't see what the big deal really is.  We'd have this same argument
> > > if someone decided to change the number of getty processes.  I
> > > personally think 6 is too many, but since they don't take up much space,
> > > I don't care that much.
> > > 
> > > On the topic of documentation:  it should be documented in the release
> > > notes and elsewhere.  The only people that are really going to run into
> > > this problem are people troubleshooting, and if they're worth anything
> > > for troubleshooting, they're going to either know its been changed or be
> > > smart enough to try tty2.
> > > 
> > > Brian
> > > 
> > > 
> > > 
> > > 
> > > On Wed, 2008-10-29 at 21:57 +1000, Dave Airlie wrote:
> > > > On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> > > > > I would argue strongly that this change should not be made for the
> > > > > following reasons (in no particular order):
> > > > > 
> > > > > * The default behavior of X on tty7 has been in place since the
> > > > > beginning (almost a decade and a half).
> > > > > 
> > > > 
> > > > -1
> > > > 
> > > > Can one man make a difference? I voted for Kodos.
> > > > 
> > > > Dave.
> > > > 
> > > 
> > -- 
> > Jim Gettys <jg at laptop.org>
> > One Laptop Per Child
> > 
> 
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child



From pingou at pingoured.fr  Wed Oct 29 13:08:08 2008
From: pingou at pingoured.fr (Pierre-Yves)
Date: Wed, 29 Oct 2008 14:08:08 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <49085FCD.9060707@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>
	<49085FCD.9060707@gmail.com>
Message-ID: <49086038.6060800@pingoured.fr>

Les Mikesell wrote:
> I don't quite understand the obsession with making boot time faster 
> anyway.  Machines should only boot when they have a new kernel to 
> install.  If they aren't needed all the time they should sleep or 
> hibernate, waking up with everything still running.
> 

My problem here are your two last words *still running*...
Maybe especially on my laptop.

Regards,

Pierre



From katzj at redhat.com  Wed Oct 29 12:53:26 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 29 Oct 2008 08:53:26 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <ge9bsl$2fp$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org>
Message-ID: <1225284806.13184.45.camel@aglarond.local>

On Wed, 2008-10-29 at 09:54 +0000, Jeremy Sanders wrote:
> You also need to start nfsd if /etc/exports contains something.

nfsd is the server side.  And we already don't start it by default; you
have to chkconfig it on after you configure /etc/exports.  

Jeremy



From katzj at redhat.com  Wed Oct 29 13:04:15 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 29 Oct 2008 09:04:15 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <49082E6B.7080304@hhs.nl>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>  <49082E6B.7080304@hhs.nl>
Message-ID: <1225285455.13184.55.camel@aglarond.local>

On Wed, 2008-10-29 at 10:35 +0100, Hans de Goede wrote:
> So the idea is to patch all the initscripts which currently only get started by 
> default for NFS, to as the first thing in their start method grep for nfs in 
> /etc/fstab and if that is not found exit quietly without doing anything further.

To be clear -- this is the rpc* and portmap services, yes?  If so, it's
not entirely clear that it'll work... you need portmap also if you're
using NIS and so you can't just use nfs mounts in /etc/fstab.

Although to be fair, if you're setting up nfs in /etc/fstab, you've
already done manual editing.  I'm not sure that you're worse off if you
also have to set up services to start.  That's pretty much the norm for
if you edit config files...

> Then to make manual mounting of nfs exports not in fstab work properly, the 
> suggested fix is to patch mount to check if the necessary daemons are running 
> and if not start them. Since this will probably turn out to be distro specific 
> I think it would be best to have a checknfsdaemons shell script in some 
> standard location provided by the distro and let mount call that before each 
> nfs mount. (Oh the horror an additional entire fork and exec on each nfs mount, 
> hello people this is going over the network, forget about the fork and exec 
> cost, thank you).

Yeah, I've talked with steved about having portmap, etc auto-started as
someone running mount and just having it hang has always been my bigger
concern with turning these off by default.  But I think I actually saw a
useful error message from mount the other day (... as I've been
experimenting with some services turned off to see what impact they have
even for someone who uses old and crufty things like nfs :-)

Jeremy



From dominik at greysector.net  Wed Oct 29 13:35:10 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 29 Oct 2008 14:35:10 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225284178.23396.19.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49085873.6070107@shmuelhome.mine.nu>
	<1225284178.23396.19.camel@nibbler.dlib.indiana.edu>
Message-ID: <20081029133510.GD1293@mokona.greysector.net>

On Wednesday, 29 October 2008 at 13:42, Brian Wheeler wrote:
> On Wed, 2008-10-29 at 14:34 +0200, shmuel siegel wrote:
> > Brian Wheeler wrote:
> > > I'm going to agree with the -1.  
> > >
> > > Almost all of the "reasons" from the original email boil down to "we've
> > > always done it this way".  
> > >
> > >   
> > And what about the other reasons?
> > 
> > There have been two reasons given for maintaining the change.
> > 1) Your use case doesn't interest me.
> > 2) We've thought of a way to accomplish our goal. There have been no 
> > responses to the question if other methods would accomplish the same 
> > objective.
> > 
> 
> I'm still trying to figure out why there's all the love for X on tty7.
> 
> Things change.  We adapt.  Having the primary interface on tty1 makes
> much more sense than it being on tty7.  On a semi-serious note, the tty7
> choice is a historical accident...not a design choice.
> 
> OSS has been replaced.
> Static /dev has been replaced.

Which has the downside of losing devices I create manually upon reboot.

> SysV init has been replaced.

And there was much screaming. Custom inittabs stopped working.

> IDE drives aren't /dev/hd* anymore.

That was relatively painless if you used labels.

> We're using LVM instead of raw partitions.

Thankfully anaconda still lets you use raw partitions. Who said I need LVM?
I don't see any advantages in using it.

You forgot about NetworkManager, which still doesn't work right, 4 releases
after it was introduced.

Oh and PackageKit, which presents a different set of groups than what you
can see in Anaconda.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From lesmikesell at gmail.com  Wed Oct 29 13:43:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 08:43:27 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <49086038.6060800@pingoured.fr>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>	<49085FCD.9060707@gmail.com>
	<49086038.6060800@pingoured.fr>
Message-ID: <4908687F.2060100@gmail.com>

Pierre-Yves wrote:
> Les Mikesell wrote:
>> I don't quite understand the obsession with making boot time faster 
>> anyway.  Machines should only boot when they have a new kernel to 
>> install.  If they aren't needed all the time they should sleep or 
>> hibernate, waking up with everything still running.
>>
> 
> My problem here are your two last words *still running*...
> Maybe especially on my laptop.
> 

It has worked for me on a Mac Powerbook for 4 or 5 years and windows XP 
for the last 2 at least.  Close the lid in one place, it sleeps.  Open 
it somewhere else, it wakes up, adjusts to the new wired or wireless 
network connection and everything goes about its business.  At least 
things like browsers and email clients that know enough to reconnect 
broken connections.  I go months without booting anything.  For the 
things that actually do have to keep running, I park them on 
UPS-protected linux boxes with freenx and reconnect as needed with the 
NX clients that are cross-platform (and actually do the bulk of my work 
there).

-- 
   Les Mikesell
     lesmikesell at gmail.com



From dominik at greysector.net  Wed Oct 29 13:52:52 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 29 Oct 2008 14:52:52 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029124254.GD3628@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
Message-ID: <20081029135251.GE1293@mokona.greysector.net>

On Wednesday, 29 October 2008 at 13:42, Anders Karlsson wrote:
> * Dominik 'Rathann' Mierzejewski <dominik at greysector.net> [20081029 12:38]:
> > 
> > Well, the community is saying that reason is not good enough.
> > I think it's fair to ask the package maintainer to reconsider.
> > Making changes that break years-long traditional behaviour
> > without community consultation is arrogant at best.
> 
> Breaking with tradition created things like OS-X (which fwiw is what
> any sane desktop out there today is trying to emulate).

Oh, spare me that. It's utterly unfriendly to me. The interface is
inconvenient and and filled with useless annoying visual effects,
and the dialog boxes are a maze. I don't want my desktop to look
or behave like Mac OS X.

> Doing something because "it's always been done like that" is a really
> bad reason. Doing something on technical merit and changing when a
> better way to do something is found is what I think should be done.

Current solution is inconsistent with itself, so it doesn't just
change on which tty X is running, it makes it dependent on how you
start your X session (not to mention starting a second X session).

> Which tty you run X on I don't really care, as I think the end goal
> should be to ditch X and do what OS-X did.

You're thinking in single-seat single-user desktop terms again. When
Fedora goals stop including multi-purposefulness and start saying
"OS for the desktop" then I'll sadly say my farewells, but for now,
stop treating us like second class citizens here and pushing your
limited use-case at all cost.

> The biggest innovations happened by not following the sheep.

Oh, so now we're the sheep? Nice argumentation level.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From bruno at wolff.to  Wed Oct 29 13:54:15 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 29 Oct 2008 08:54:15 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <555910.26860.qm@web32807.mail.mud.yahoo.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<555910.26860.qm@web32807.mail.mud.yahoo.com>
Message-ID: <20081029135415.GA6665@wolff.to>

I always thought it was odd it was on vt7 instead of vt1 or vt12. Why pick
one in the middle to be special. (Note that when I used to use vts I
had 12 configured.)



From dominik at greysector.net  Wed Oct 29 14:03:56 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 29 Oct 2008 15:03:56 +0100
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081029010142.GB12270@nostromo.devel.redhat.com>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
Message-ID: <20081029140356.GF1293@mokona.greysector.net>

On Wednesday, 29 October 2008 at 02:01, Bill Nottingham wrote:
> Joshua Baker-LePain (jlb17 at duke.edu) said: 
> >> > NetworkManager is not an option and has no place on my machines.
> >>
> >> Right-click -> "Edit connections", pick your preferred setting, click 
> >> on 'System setting'.
> >
> > Right-click on what?  I run fvwm.  How are non-DE users supposed to  
> > interact with NM?
> 
> He was asking how to make NM work after logging out, which does sort
> of presume he's already using it. If you are seriously asking about how
> to configure NM when you aren't actually using it, well...
> 
> >> (Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)
> >
> > Yes, yes it does.  And it should.
> 
> Not in the context of init.d/network, which is what I meant. (Well, not
> outside of gross hacks.)

Yes, it works in that context. /etc/sysconfig/network-scripts/ifup-wireless
needs a small patch which I posted in bugzilla and which has been ignored
for years. The patch isn't actually mine, it was posted on one of fedora lists.
I can't find that bugzilla report right now so I'm attaching the patch here
instead.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-------------- next part --------------
--- ifup-wireless.orig	2005-09-30 20:51:15.000000000 +0200
+++ ifup-wireless	2006-04-07 16:09:01.000000000 +0200
@@ -30,6 +30,35 @@
 
 # Only meant to be called from ifup.
 
+if wpa_cli -i $DEVICE status >/dev/null 2>&1; then
+    eval $(wpa_cli -i${DEVICE} status | grep wpa_state 2>/dev/null) 
+    if [ "$wpa_state" != "COMPLETED" ]; then
+	/sbin/ip link set $DEVICE down
+	/sbin/ip link set $DEVICE up
+	wpa_cli scan >/dev/null 2>&1
+    fi
+    old_state=""
+    cnt=0
+    while true; do
+	eval $(wpa_cli -i${DEVICE} status | grep 'wpa_state|ssid' 2>/dev/null) 
+	if [ "$wpa_state" = "COMPLETED" ]; then
+	    echo $"Connected to $ssid"
+	    break
+	fi
+	if [ "$old_state" != "$wpa_state" ]; then
+	    echo -n "$wpa_state "
+	    old_state=$wpa_state
+	fi
+
+	sleep 1
+	cnt=$[$cnt + 1]
+	if [ $cnt -gt 90 ]; then
+	    echo -n $"Timeout "
+	    exit 10
+	fi
+    done 
+else
+
 # Mode need to be first : some settings apply only in a specific mode !
 if [ -n "$MODE" ] ; then
     iwconfig $DEVICE mode $MODE
@@ -97,3 +126,5 @@
     # use any essid
     iwconfig $DEVICE essid any >/dev/null 2>&1
 fi
+
+fi

From mattdm at mattdm.org  Wed Oct 29 14:07:17 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 29 Oct 2008 10:07:17 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <7863543B-361F-41B1-A559-796823CA5E26@nall.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<7863543B-361F-41B1-A559-796823CA5E26@nall.com>
Message-ID: <20081029140717.GA17393@jadzia.bu.edu>

On Wed, Oct 29, 2008 at 07:27:51AM -0500, Joe Nall wrote:
> Not until this bug is fixed :)
> prelink erases file-based capabilities
> https://bugzilla.redhat.com/show_bug.cgi?id=456105

>From Jakub's 2004 paper on prelink, I see that it saves 1-2 seconds in
startup time for openoffice swriter. Half a second or less on kword,
konqueror, evolution, and epiphany. As computers get faster, prelink will
still save relative time, but the absolute difference will become less and
less perceptible. I know a second here and there adds up, but given the
downsides, sooner or later prelink should be revisited.


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From dbn.lists at gmail.com  Wed Oct 29 14:06:19 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Wed, 29 Oct 2008 07:06:19 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>

On Tue, Oct 28, 2008 at 10:36 PM, Dax Kelson <dkelson at gurulabs.com> wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):

Not arguing for or against this, but I just want to point out one
thing that a lot of people seem to be mistaken about.

> * The default behavior of X on tty7 has been in place since the
> beginning (almost a decade and a half).

This is actually convention, not any enforced behavior. There is
nothing magic about tty7. It just so happens that the typical init
configuration has been gettys on the first 6 ttys. When X starts, it
simply chooses the next available VT. This has always been
configurable - /etc/inittab with sysvinit and now
/etc/event.d/tty[1-6] with upstart. Personally, I always thought that
6 consoles was more than I've ever wanted, so for me the "default" X
was tty4.

--
Dan



From dbn.lists at gmail.com  Wed Oct 29 14:12:34 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Wed, 29 Oct 2008 07:12:34 -0700
Subject: unable to switch vt
In-Reply-To: <1225283437.3593.45.camel@eagle.danny.cz>
References: <1225283437.3593.45.camel@eagle.danny.cz>
Message-ID: <91705d080810290712n604ff983oaa3e6b335148f410@mail.gmail.com>

On Wed, Oct 29, 2008 at 5:30 AM, Dan Hor?k <dan at danny.cz> wrote:
> Hi,
>
> I hope this to be a bug and not a really bad joke. I am completely
> unable to switch vt with current rawhide kernel
> (2.6.27.4-65.fc10.x86_64) and it works with an older one
> (2.6.27.3-27.rc1.fc10.x86_64), there is no reaction on pressing
> Ctrl-Alt-F[1-6]
>
> I have
> - no graphical boot, console is vesafb
> - default runlevel 5
> - updated /etc/event.d/tty1 to be same as tty[2-6] as suggested by
> wwoods (I want X on vt7)

Unfortunately, that's not all it takes due to the way plymouth and gdm interact.

https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02516.html

If you really want X on vt7, you will need to add 'rm
/var/spool/gdm/force-display-on-active-vt' in prefdm or somewhere else
before gdm starts, or it will still force X to start on tty1. If you
run `ck-list-sessions', it will probably show that you're on tty1 in
X.

--
Dan



From mrmazda at ij.net  Wed Oct 29 14:14:23 2008
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 29 Oct 2008 10:14:23 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029133510.GD1293@mokona.greysector.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<49085873.6070107@shmuelhome.mine.nu>	<1225284178.23396.19.camel@nibbler.dlib.indiana.edu>
	<20081029133510.GD1293@mokona.greysector.net>
Message-ID: <49086FBF.7010105@ij.net>

On 2008/10/29 14:35 (GMT+0100) Dominik 'Rathann' Mierzejewski composed:

> On Wednesday, 29 October 2008 at 13:42, Brian Wheeler wrote:

>> IDE drives aren't /dev/hd* anymore.

> That was relatively painless if you used labels.

If you used labels, and if you did not use partitions as a backup strategy,
and if you did not use partitions for multibooting various distros, in which
case you had to either quit using Fedora altogether, or add a bunch of disks.

>> We're using LVM instead of raw partitions.

> Thankfully anaconda still lets you use raw partitions. Who said I need LVM?
> I don't see any advantages in using it.

The only advantage I found in LVM (not that ostensible others don't exist)
was in getting around the libata/scsi 14 partition per HD limit. I found that
advantage overwhelmed by LVM's inability to synergize with my backup strategy
and multiboot. So now instead of having current Fedora on lots of machines
that actually get used, I have Rawhide on one box that sees little use other
than to check on what's going on in Rawhide; F8 on one box with a 2nd HD with
only 11 partitions; and F7 or older on a few others, all of which have >15
partitions.
-- 
"Everyone should be quick to listen, slow to speak, and
slow to become angry."		James 1:19 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From pertusus at free.fr  Wed Oct 29 14:14:15 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 29 Oct 2008 15:14:15 +0100
Subject: rawhide report: 20081028 changes
In-Reply-To: <20081029104532.138c5511@python3.es.egwn.lan>
References: <20081028100258.F337A1F824B@releng2.fedora.phx.redhat.com>
	<1225237056.2157.101.camel@luminos.localdomain>
	<20081029104532.138c5511@python3.es.egwn.lan>
Message-ID: <20081029141414.GF2834@free.fr>

On Wed, Oct 29, 2008 at 10:45:32AM +0100, Matthias Saou wrote:
> 
> The two libraries, libcaca and libcucul, got merged into libcaca. Note
> that this version installs "compatibility" symlinks as "libcucul.so.0
> -> libcaca.so.0", but those aren't detected as provides by rpm.

Looking at the package, it seems to me that those *.so.* links are useless 
(and may even be confusing). 

The devel symlinks
 /usr/lib/libcucul.so -> libcaca.so
 /usr/lib/libcucul++.so -> libcaca++.so
are very important for backward compatibility, to be able to still
link against libcucul and get it right.

> Dependant external programs simply need to be rebuilt. Another (ugly)
> solution might be to add explicit "Provides:" for libcucul sonames to
> the package.

No, since the linker won't be able to find it, the soname is now
  SONAME               libcaca.so.0
even for programs linked against libcucul.

--
Pat



From mrmazda at ij.net  Wed Oct 29 14:18:00 2008
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 29 Oct 2008 10:18:00 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225272707.3636.42.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
Message-ID: <49087098.5090407@ij.net>

On 2008/10/29 09:31 (GMT) Richard Hughes composed:

> This isn't a community decision decided by +1 or -1's. This is the
> package maintainer (and upstream) changing with a good reason.

The +1s indicate that either the good reason is not good reason, or other
good reasons outweigh the good reason, or both.
-- 
"Everyone should be quick to listen, slow to speak, and
slow to become angry."		James 1:19 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From j.w.r.degoede at hhs.nl  Wed Oct 29 14:22:42 2008
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Oct 2008 15:22:42 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225285455.13184.55.camel@aglarond.local>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl>
	<1225285455.13184.55.camel@aglarond.local>
Message-ID: <490871B2.5010405@hhs.nl>

Jeremy Katz wrote:
> On Wed, 2008-10-29 at 10:35 +0100, Hans de Goede wrote:
>> So the idea is to patch all the initscripts which currently only get started by 
>> default for NFS, to as the first thing in their start method grep for nfs in 
>> /etc/fstab and if that is not found exit quietly without doing anything further.
> 
> To be clear -- this is the rpc* and portmap services, yes? 

Yes

> If so, it's
> not entirely clear that it'll work... you need portmap also if you're
> using NIS and so you can't just use nfs mounts in /etc/fstab.
> 

I know portmapper is special, I think we can fix this by adding a check if its 
running (by using the subsys lockfile, cheap) and if not start it, to all
services using portmap.

So the nis case would be fixed by the ypbind script starting portmapper (using 
service portmapper on) if not already running).

>> Then to make manual mounting of nfs exports not in fstab work properly, the 
>> suggested fix is to patch mount to check if the necessary daemons are running 
>> and if not start them. Since this will probably turn out to be distro specific 
>> I think it would be best to have a checknfsdaemons shell script in some 
>> standard location provided by the distro and let mount call that before each 
>> nfs mount. (Oh the horror an additional entire fork and exec on each nfs mount, 
>> hello people this is going over the network, forget about the fork and exec 
>> cost, thank you).
> 
> Yeah, I've talked with steved about having portmap, etc auto-started as
> someone running mount and just having it hang has always been my bigger
> concern with turning these off by default.  But I think I actually saw a
> useful error message from mount the other day (... as I've been
> experimenting with some services turned off to see what impact they have
> even for someone who uses old and crufty things like nfs :-)

A decent error is a must, having autostart would be nice though and should not 
be to difficult.

Regards,

Hans



From mrmazda at ij.net  Wed Oct 29 14:21:38 2008
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 29 Oct 2008 10:21:38 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225276614.3897.346.camel@beck.corsepiu.local>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl>	<ge9bsl$2fp$1@ger.gmane.org>
	<1225275505.3636.52.camel@hughsie-laptop>
	<1225276614.3897.346.camel@beck.corsepiu.local>
Message-ID: <49087172.6010104@ij.net>

On 2008/10/29 11:36 (GMT+0100) Ralf Corsepius composed:

> Setting up NFS is trivial.

It used to be. Several weeks ago, NFS mounting became impossible on all my
systems in both openSUSE Factory and Rawhide. Factory started working again a
week ago, but Rawhide still does not.
-- 
"Everyone should be quick to listen, slow to speak, and
slow to become angry."		James 1:19 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From mrmazda at ij.net  Wed Oct 29 14:25:13 2008
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 29 Oct 2008 10:25:13 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
Message-ID: <49087249.8050905@ij.net>

On 2008/10/29 08:26 (GMT-0400) Brian Wheeler composed:

> Almost all of the "reasons" from the original email boil down to "we've
> always done it this way".  

Don't boil it down. The reasons are good why we've always done it this way
and should keep the status quo. I haven't seen sufficient reason in this
thread to dismiss those reasons.
-- 
"Everyone should be quick to listen, slow to speak, and
slow to become angry."		James 1:19 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From hughsient at gmail.com  Wed Oct 29 14:24:56 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 29 Oct 2008 14:24:56 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283310.21485.41.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org> <1225275505.3636.52.camel@hughsie-laptop>
	<1225281794.21485.31.camel@rosebud>
	<1225282688.3980.4.camel@hughsie-laptop>
	<1225283310.21485.41.camel@rosebud>
Message-ID: <1225290296.3980.9.camel@hughsie-laptop>

On Wed, 2008-10-29 at 08:28 -0400, seth vidal wrote:
> I agree. I've also not objected to turning off nfsd (which it already
> is, btw). I'm objecting to your claim that no one uses nfs. I think
> that is not a well founded claim.

Sure, apologies, I should have been more specific and said "when
installing from desktop media".

Richard.




From pertusus at free.fr  Wed Oct 29 14:31:12 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 29 Oct 2008 15:31:12 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <490871B2.5010405@hhs.nl>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<1225285455.13184.55.camel@aglarond.local>
	<490871B2.5010405@hhs.nl>
Message-ID: <20081029143112.GH2834@free.fr>

On Wed, Oct 29, 2008 at 03:22:42PM +0100, Hans de Goede wrote:
>
> I know portmapper is special, I think we can fix this by adding a check 
> if its running (by using the subsys lockfile, cheap) and if not start it, 
> to all
> services using portmap.
>
> So the nis case would be fixed by the ypbind script starting portmapper 
> (using service portmapper on) if not already running).

Is it the way dependent services should be handled? I don't think that
something special should be done for portmap/ypbind/nfs. I thought that
the switch to upstart was in part motivated by this kind of feature.

Otherwise said, I think that it is wrong to do it in the scripts, it
should be done in the boot sequence configuration.

--
Pat



From bruno at wolff.to  Wed Oct 29 14:31:26 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 29 Oct 2008 09:31:26 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <49086FBF.7010105@ij.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49085873.6070107@shmuelhome.mine.nu>
	<1225284178.23396.19.camel@nibbler.dlib.indiana.edu>
	<20081029133510.GD1293@mokona.greysector.net>
	<49086FBF.7010105@ij.net>
Message-ID: <20081029143126.GA18611@wolff.to>

On Wed, Oct 29, 2008 at 10:14:23 -0400,
  Felix Miata <mrmazda at ij.net> wrote:
> 
> If you used labels, and if you did not use partitions as a backup strategy,
> and if you did not use partitions for multibooting various distros, in which
> case you had to either quit using Fedora altogether, or add a bunch of disks.

I saw somewhere (probably LWN) a mention that this limit was being lifted.
I don't know when it will arrive in Fedora, but expect it by F11.



From bdwheele at indiana.edu  Wed Oct 29 14:32:50 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 10:32:50 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <49087249.8050905@ij.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
Message-ID: <1225290770.23396.32.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 10:25 -0400, Felix Miata wrote:
> On 2008/10/29 08:26 (GMT-0400) Brian Wheeler composed:
> 
> > Almost all of the "reasons" from the original email boil down to "we've
> > always done it this way".  
> 
> Don't boil it down. The reasons are good why we've always done it this way
> and should keep the status quo. I haven't seen sufficient reason in this
> thread to dismiss those reasons.

_What_ are the good reasons why we've done it this way?  Its only tty7
because someone arbitrarily decided to run 6 getty processes way back
when.  If someone had decided that 4 was sufficient, then we'd be
arguing about tty5.

At least with X being on tty1 it makes sense since its the primary
terminal for most people.  

The only non-"but that's the way it's always been" argument I've seen
thus far is documentation...which is something that can be changed.

Brian


> -- 
> "Everyone should be quick to listen, slow to speak, and
> slow to become angry."		James 1:19 NIV
> 
>  Team OS/2 ** Reg. Linux User #211409
> 
> Felix Miata  ***  http://fm.no-ip.com/
> 



From mjg at redhat.com  Wed Oct 29 14:53:32 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 29 Oct 2008 14:53:32 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <49085FCD.9060707@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud> <49085FCD.9060707@gmail.com>
Message-ID: <20081029145332.GA28076@srcf.ucam.org>

On Wed, Oct 29, 2008 at 08:06:21AM -0500, Les Mikesell wrote:

> I don't quite understand the obsession with making boot time faster 
> anyway.  Machines should only boot when they have a new kernel to 
> install.  If they aren't needed all the time they should sleep or 
> hibernate, waking up with everything still running.

And when we've reached the flying-car future where suspend/resume is 
actually reliable on Linux, I'll agree. But we're not even slightly 
there, and as a result the boot process remains an interesting area of 
optimisation.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From lesmikesell at gmail.com  Wed Oct 29 14:55:19 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 09:55:19 -0500
Subject: WPA without NetworkManager
In-Reply-To: <20081029140356.GF1293@mokona.greysector.net>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
Message-ID: <49087957.70905@gmail.com>

Dominik 'Rathann' Mierzejewski wrote:
> 
>>>>> NetworkManager is not an option and has no place on my machines.
>>>> Right-click -> "Edit connections", pick your preferred setting, click 
>>>> on 'System setting'.
>>> Right-click on what?  I run fvwm.  How are non-DE users supposed to  
>>> interact with NM?
>> He was asking how to make NM work after logging out, which does sort
>> of presume he's already using it. If you are seriously asking about how
>> to configure NM when you aren't actually using it, well...
>>
>>>> (Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)
>>> Yes, yes it does.  And it should.
>> Not in the context of init.d/network, which is what I meant. (Well, not
>> outside of gross hacks.)
> 
> Yes, it works in that context. /etc/sysconfig/network-scripts/ifup-wireless
> needs a small patch which I posted in bugzilla and which has been ignored
> for years. The patch isn't actually mine, it was posted on one of fedora lists.
> I can't find that bugzilla report right now so I'm attaching the patch here
> instead.

I thought I saw having network manager run before login and the ability 
to boot from iscsi mentioned in the release notes for the beta RHEL 5.3 
updates.  Isn't fedora supposed to be ahead of RHEL in features?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Oct 29 14:59:27 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 09:59:27 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029135251.GE1293@mokona.greysector.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>
	<20081029135251.GE1293@mokona.greysector.net>
Message-ID: <49087A4F.5030207@gmail.com>

Dominik 'Rathann' Mierzejewski wrote:
> 
>>> Well, the community is saying that reason is not good enough.
>>> I think it's fair to ask the package maintainer to reconsider.
>>> Making changes that break years-long traditional behaviour
>>> without community consultation is arrogant at best.
>> Breaking with tradition created things like OS-X (which fwiw is what
>> any sane desktop out there today is trying to emulate).
> 
> Oh, spare me that. It's utterly unfriendly to me. The interface is
> inconvenient and and filled with useless annoying visual effects,
> and the dialog boxes are a maze. I don't want my desktop to look
> or behave like Mac OS X.

Mac's don't boot particularly fast...  On the other hand they do sleep 
and wake up quickly and gracefully so there is rarely a reason to boot.

And they run X nicely, and it behaves the way you expect X to behave...

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin.kofler at chello.at  Wed Oct 29 15:01:32 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 29 Oct 2008 15:01:32 +0000 (UTC)
Subject: Package review - How handle licence in source code only?
References: <20081029122629.GA20614@evileye.atkac.englab.brq.redhat.com>
Message-ID: <loom.20081029T145916-670@post.gmane.org>

Adam Tkac <atkac <at> redhat.com> writes:
> I'm reviewing dnsperf package -
> https://bugzilla.redhat.com/show_bug.cgi?id=467798. Licence of code is
> written only in source code itself:

Assuming _all_ the source files carry the notice, this is not a problem, things 
become a bit murkier when some files are missing the notice, but usually you 
can assume they just forgot to add it to those files. (What _is_ a problem, 
though, is when some sources include some conflicting or non-Free license.)

>  * Copyright (C) 2004 - 2008 Nominum, Inc.
>  *
>  * Permission to use, copy, modify, and distribute this software and its
>  * documentation for any purpose with or without fee is hereby granted,
>  * provided that the above copyright notice and this permission notice
>  * appear in all copies.
> ...
> 
> What should be correct licence tag? The licence is BSD compatible so
> can I recommend BSD licence tag?

This sounds like a variant of the MIT X11 license, so it should be:
License: MIT

        Kevin Kofler



From lesmikesell at gmail.com  Wed Oct 29 15:17:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 10:17:28 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029145332.GA28076@srcf.ucam.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>
	<49085FCD.9060707@gmail.com> <20081029145332.GA28076@srcf.ucam.org>
Message-ID: <49087E88.3030102@gmail.com>

Matthew Garrett wrote:
> On Wed, Oct 29, 2008 at 08:06:21AM -0500, Les Mikesell wrote:
> 
>> I don't quite understand the obsession with making boot time faster 
>> anyway.  Machines should only boot when they have a new kernel to 
>> install.  If they aren't needed all the time they should sleep or 
>> hibernate, waking up with everything still running.
> 
> And when we've reached the flying-car future where suspend/resume is 
> actually reliable on Linux, I'll agree. But we're not even slightly 
> there, and as a result the boot process remains an interesting area of 
> optimisation.

Well, if you don't drive away all the potential users with incompatible 
and arbitrary changes by the time you get around to working on the 
improvements that actually matter...

-- 
   Les Mikesell
    lesmikesell at gmail.com




From mw_triad at users.sourceforge.net  Wed Oct 29 15:20:17 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 10:20:17 -0500
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081029005548.GA12270@nostromo.devel.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<200810281509.40552.opensource@till.name>	<20081028202624.GB8452@nostromo.devel.redhat.com>	<49077869.9030706@redhat.com>	<20081028204315.GF8452@nostromo.devel.redhat.com>	<ge82t0$ql6$1@ger.gmane.org>
	<20081029005548.GA12270@nostromo.devel.redhat.com>
Message-ID: <ge9uvh$8qo$1@ger.gmane.org>

(Please do not quote my e-mail address unobfuscated in message bodies.)

Bill Nottingham wrote:
> Matthew Woehlke (ahem at stop.that) said: 
>>> If you don't add the bits I mentioned, then you'll get a blank tty7
>>> when you boot in text mode. Which is presumably not what you want.
>> So add an explicit switch to tty1 in runlevel 3. It shouldn't flicker  
>> because it's not changing display modes (at least, I don't remember  
>> flicker switching between mingetty VT's; can't check right now because  
>> X->VGA switching doesn't work on this machine). Where's the problem?
> 
> You're having the kernel operate on Fedora specific commandline options
> to start on a completely different tty, one that could be configured
> by anyone locally to do something else entirely. (Unless you do it in
> userspace, which means you jump away and then jump back for text mode,
> which...)

Aside from the obvious question if this wouldn't start out as a 
Fedora-specific kernel patch, why do you assume Fedora will be the only 
distro with this problem? Or is plymouth (and similar technologies) 
expected to remain Fedora-only forever?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From jkeating at redhat.com  Wed Oct 29 15:22:57 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 29 Oct 2008 08:22:57 -0700
Subject: WPA without NetworkManager
In-Reply-To: <49087957.70905@gmail.com>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<49087957.70905@gmail.com>
Message-ID: <1225293777.1783.2.camel@luminos.localdomain>

On Wed, 2008-10-29 at 09:55 -0500, Les Mikesell wrote:
> I thought I saw having network manager run before login

NetworkManager does run before login, quite early in fact, and you can
even configure it to wait for actual configuration of the IP address
before moving on in the boot process.

However, if you're trying to boot iscsi via a wpa secured connection,
perhaps you're doing it wrong?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/ee1418da/attachment.sig>

From mackay_d at bellsouth.net  Wed Oct 29 15:24:09 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Wed, 29 Oct 2008 10:24:09 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225284662.21485.46.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
Message-ID: <1225293850.5412.181.camel@vorpal.macdev.com>


On Wed, 2008-10-29 at 08:51 -0400, seth vidal wrote:
> There's no one working in computing today ANYWHERE who is doing
> revolutionary work. I'd argue there is no such thing as revolutionary
> work AT ALL. Stop looking for it where it is not.

What about quantum computing?  A fundamental paradigm shift seems like
it ought to count.

Dave




From jkeating at redhat.com  Wed Oct 29 15:24:50 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 29 Oct 2008 08:24:50 -0700
Subject: F10 builds targetted for dist-f10-updates-candidate
In-Reply-To: <49083F7B.9040708@hhs.nl>
References: <1225215911.2157.67.camel@luminos.localdomain>
	<49083F7B.9040708@hhs.nl>
Message-ID: <1225293890.1783.3.camel@luminos.localdomain>

On Wed, 2008-10-29 at 11:48 +0100, Hans de Goede wrote:
> Will we be able to create updates in bodhi for F-10 now then?
> 
> I don't mind some smaller fixes / updates being shunted to F-10 updates because
> of the freeze. But last time around (if I remember correctly) one could
> actually create the updates in bodhi for quite a while, which meant one had to
> remember or write down a list of packages to create updates for once bodhi
> finally was able to do updates for the upcoming release.

Luke told me on IRC that bodhi should be ready for F10 update requests.
Luke?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/d2ee444b/attachment.sig>

From dominik at greysector.net  Wed Oct 29 15:26:24 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 29 Oct 2008 16:26:24 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
Message-ID: <20081029152623.GG1293@mokona.greysector.net>

On Wednesday, 29 October 2008 at 15:32, Brian Wheeler wrote:
> On Wed, 2008-10-29 at 10:25 -0400, Felix Miata wrote:
> > On 2008/10/29 08:26 (GMT-0400) Brian Wheeler composed:
> > 
> > > Almost all of the "reasons" from the original email boil down to "we've
> > > always done it this way".  
> > 
> > Don't boil it down. The reasons are good why we've always done it this way
> > and should keep the status quo. I haven't seen sufficient reason in this
> > thread to dismiss those reasons.
> 
> _What_ are the good reasons why we've done it this way?  Its only tty7
> because someone arbitrarily decided to run 6 getty processes way back
> when.  If someone had decided that 4 was sufficient, then we'd be
> arguing about tty5.
> 
> At least with X being on tty1 it makes sense since its the primary
> terminal for most people.  
> 
> The only non-"but that's the way it's always been" argument I've seen
> thus far is documentation...which is something that can be changed.

The other is that it won't be tty1 in every case (init 5 after init 3, manual
startx), which can be confusing. Make it so that it's ALWAYS on tty1 and maybe
people will complain less, as long as it's documented properly.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From skvidal at fedoraproject.org  Wed Oct 29 15:28:44 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 11:28:44 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225293850.5412.181.camel@vorpal.macdev.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
	<1225293850.5412.181.camel@vorpal.macdev.com>
Message-ID: <1225294124.21485.54.camel@rosebud>

On Wed, 2008-10-29 at 10:24 -0500, David G. Mackay wrote:
> On Wed, 2008-10-29 at 08:51 -0400, seth vidal wrote:
> > There's no one working in computing today ANYWHERE who is doing
> > revolutionary work. I'd argue there is no such thing as revolutionary
> > work AT ALL. Stop looking for it where it is not.
> 
> What about quantum computing?  A fundamental paradigm shift seems like
> it ought to count.

IBIWISI.

-sv




From herrold at owlriver.com  Wed Oct 29 15:30:43 2008
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 29 Oct 2008 11:30:43 -0400 (EDT)
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908360D.8060900@hhs.nl>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <ge9bsl$2fp$1@ger.gmane.org>
	<4908360D.8060900@hhs.nl>
Message-ID: <alpine.LRH.2.00.0810291122590.954@arj.bjyevire.pbz>

On Wed, 29 Oct 2008, Hans de Goede wrote:

> Then we need to also teach autofs to start these services on 
> demand.

The problem with this, and with the earlier example of reading 
(and parseing [and reparseing on every change]) /etc/exports, 
is that such a solution needs to account for corner cases -- 
think: LDAP 'add a mount, and deploy homes on demand and on 
the fly' at a given chassis, etc.

There is no sensible end, nor reasonable purpose to automate 
ALL possible configuration setups, because it is an NP 
complete problem and exceeding fragile. (and, as I read this, 
putting to side the timeouts and performance hit this imposes)

> Having all the daemons on for the 1% of Linux users who use NFS  ...

and 67 % of all statistics are fabricated on the spot and have 
no basis in fact.

Source for '1%' please? -- I simply don't believe it, having 
deployed and managed 'homes' for thousands of users of Linux 
in NFS environments.

-- Russ herrold



From mrmazda at ij.net  Wed Oct 29 15:31:59 2008
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 29 Oct 2008 11:31:59 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029143126.GA18611@wolff.to>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49085873.6070107@shmuelhome.mine.nu>
	<1225284178.23396.19.camel@nibbler.dlib.indiana.edu>
	<20081029133510.GD1293@mokona.greysector.net>
	<49086FBF.7010105@ij.net> <20081029143126.GA18611@wolff.to>
Message-ID: <490881EF.9060709@ij.net>

On 2008/10/29 09:31 (GMT-0500) Bruno Wolff III composed:

> On Wed, Oct 29, 2008 at 10:14:23 -0400,

>   Felix Miata <mrmazda at ij.net> wrote:

>> If you used labels, and if you did not use partitions as a backup strategy,
>> and if you did not use partitions for multibooting various distros, in which
>> case you had to either quit using Fedora altogether, or add a bunch of disks.

> I saw somewhere (probably LWN) a mention that this limit was being lifted.

It's getting there. This is from one of my openSUSE Factory boxes:
# fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x65df4d9d

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          13      104391   17  Hidden HPFS/NTFS
/dev/sda2   *          14          14        8032+   a  OS/2 Boot Manager
/dev/sda3              15          46      257040    6  FAT16
/dev/sda4              48       19456   155902792+   5  Extended
/dev/sda5              48          73      208813+  83  Linux
/dev/sda6              75         890     6554488+   b  W95 FAT32
/dev/sda7             891         922      257008+   6  FAT16
/dev/sda8             924        1054     1052226   82  Linux swap / Solaris
/dev/sda9            1055        1666     4915858+  83  Linux
/dev/sda10           1667        2278     4915858+  83  Linux
/dev/sda11           2279        2890     4915858+  83  Linux
/dev/sda12           2891        3094     1638598+  83  Linux
/dev/sda13           3095        3987     7172991   83  Linux
/dev/sda14           3988        4017      240943+  83  Linux
/dev/sda15           4018        4157     1124518+  83  Linux
/dev/sda16           4158        4795     5124703+  83  Linux
/dev/sda17          14561       15172     4915858+  83  Linux
/dev/sda18          15173       15784     4915858+  83  Linux
/dev/sda19          15785       16396     4915858+  83  Linux
/dev/sda20          16397       17008     4915858+  83  Linux
/dev/sda21          17009       17620     4915858+  83  Linux
/dev/sda22          17621       18232     4915858+  83  Linux
/dev/sda23          18233       18844     4915858+  83  Linux
/dev/sda24          18845       19456     4915858+  83  Linux

# blkid | sort
/dev/dm-11: LABEL="P06S16A" UUID="4049-D21E" TYPE="vfat"
/dev/dm-12: LABEL="S16A-05boot" UUID="8b2a7ecc-0d71-434e-a4b9-2cc7a5313a7c" TYPE="ext2"
/dev/dm-13: SEC_TYPE="msdos" LABEL="P07S16A" UUID="788D-75F6" TYPE="vfat"
/dev/dm-14: LABEL="P06S16A" UUID="4049-D21E" TYPE="vfat"
/dev/dm-15: TYPE="swap" LABEL="S16A-08swapper" UUID="1e29f127-cef6-4f18-9fe5-14b69e0a9141"
/dev/dm-16: SEC_TYPE="msdos" LABEL="P07S16A" UUID="788D-75F6" TYPE="vfat"
/dev/dm-17: LABEL="S16A-09cooker" UUID="317f1cc2-49ad-41f0-a7cf-f483d0ceb51f" TYPE="ext3"
/dev/dm-18: TYPE="swap" LABEL="S16A-08swapper" UUID="1e29f127-cef6-4f18-9fe5-14b69e0a9141"
/dev/dm-19: LABEL="S16A-10factory" UUID="ab2713d8-5c1d-4758-97c4-0905dabeca12" TYPE="ext3"
/dev/dm-1: TYPE="hpfs"
/dev/dm-20: LABEL="S16A-09cooker" UUID="317f1cc2-49ad-41f0-a7cf-f483d0ceb51f" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-21: LABEL="S16A-11rawhide" UUID="67908018-803c-4cc2-b978-fe3b3c34d729" TYPE="ext3" SEC_TYPE="ext2"
/dev/dm-22: LABEL="S16A-10factory" UUID="ab2713d8-5c1d-4758-97c4-0905dabeca12" TYPE="ext3" SEC_TYPE="ext2"
/dev/dm-23: LABEL="S16A-12home" UUID="af9a1d43-5154-4cb0-91d9-1a62d3050ef2" TYPE="ext3" SEC_TYPE="ext2"
/dev/dm-24: LABEL="S16A-11rawhide" UUID="67908018-803c-4cc2-b978-fe3b3c34d729" TYPE="ext3" SEC_TYPE="ext2"
/dev/dm-25: LABEL="S16A-13pub" UUID="3592b844-1697-45c5-9910-740a0b031509" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-26: LABEL="S16A-12home" UUID="af9a1d43-5154-4cb0-91d9-1a62d3050ef2" TYPE="ext3"
/dev/dm-27: LABEL="S16A-14srv" UUID="a2ab6e97-39e0-4e64-8698-1330ba7349ac" TYPE="ext3"
/dev/dm-28: LABEL="S16A-13pub" UUID="3592b844-1697-45c5-9910-740a0b031509" TYPE="ext3"
/dev/dm-29: LABEL="S16A-15usrlcl" UUID="f493be58-e847-49ad-924b-1387c6ddabfd" TYPE="ext3"
/dev/dm-30: LABEL="S16A-14srv" UUID="a2ab6e97-39e0-4e64-8698-1330ba7349ac" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-31: LABEL="S16A-15usrlcl" UUID="f493be58-e847-49ad-924b-1387c6ddabfd" TYPE="ext3" SEC_TYPE="ext2"
/dev/dm-32: LABEL="S16A-16usrsrc" UUID="b762cacc-06a8-4151-a025-0eaa6db921b1" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-33: LABEL="S16A-16usrsrc" UUID="b762cacc-06a8-4151-a025-0eaa6db921b1" TYPE="ext3" SEC_TYPE="ext2"
/dev/dm-34: LABEL="S16A-suse100" UUID="d8e3f45a-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-35: LABEL="S16A-suse100" UUID="d8e3f45a-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-36: LABEL="S16A-suse101" UUID="d7207d78-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-37: LABEL="S16A-suse101" UUID="d7207d78-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-38: LABEL="S16A-suse102" UUID="d5edbab0-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-39: LABEL="S16A-suse102" UUID="d5edbab0-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-40: LABEL="S16A-suse103" UUID="d42d7e18-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-41: LABEL="S16A-suse103" UUID="d42d7e18-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-42: UUID="cae3706a-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3" LABEL="S16A-suse110"
/dev/dm-43: UUID="cae3706a-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3" LABEL="S16A-suse110"
/dev/dm-44: UUID="770a9e05-080a-4dc6-aa69-e1c974ec0a08" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-45: UUID="770a9e05-080a-4dc6-aa69-e1c974ec0a08" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-46: UUID="d8ec551b-66af-4add-af86-e518ea3c78df" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-47: UUID="d8ec551b-66af-4add-af86-e518ea3c78df" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-48: UUID="e2b4f204-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3" LABEL="S16A-mdv2008-1"
/dev/dm-49: LABEL="S16A-mdv2008-1" UUID="e2b4f204-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/dm-4: TYPE="hpfs"
/dev/dm-5: SEC_TYPE="msdos" LABEL="P03S16A" UUID="3C46-BA75" TYPE="vfat"
/dev/dm-8: SEC_TYPE="msdos" LABEL="P03S16A" UUID="3C46-BA75" TYPE="vfat"
/dev/dm-9: LABEL="S16A-05boot" UUID="8b2a7ecc-0d71-434e-a4b9-2cc7a5313a7c" TYPE="ext2"
/dev/hda20: LABEL="S16A-20factory" UUID="cae3706a-3373-11dd-93b9-006094a32e3c" SEC_TYPE="ext2" TYPE="ext3"
/dev/hda8: TYPE="swap" UUID="a7272cb8-e8a3-467c-85f6-5705302bf919"
/dev/sda10: LABEL="S16A-10factory" UUID="ab2713d8-5c1d-4758-97c4-0905dabeca12" TYPE="ext3"
/dev/sda11: LABEL="S16A-11rawhide" UUID="67908018-803c-4cc2-b978-fe3b3c34d729" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda12: LABEL="S16A-12home" UUID="af9a1d43-5154-4cb0-91d9-1a62d3050ef2" TYPE="ext3"
/dev/sda13: LABEL="S16A-13pub" UUID="3592b844-1697-45c5-9910-740a0b031509" TYPE="ext3"
/dev/sda14: LABEL="S16A-14srv" UUID="a2ab6e97-39e0-4e64-8698-1330ba7349ac" TYPE="ext3"
/dev/sda15: LABEL="S16A-15usrlcl" UUID="f493be58-e847-49ad-924b-1387c6ddabfd" TYPE="ext3"
/dev/sda1: TYPE="hpfs"
/dev/sda3: SEC_TYPE="msdos" LABEL="P03S16A" UUID="3C46-BA75" TYPE="vfat"
/dev/sda5: LABEL="S16A-05boot" UUID="8b2a7ecc-0d71-434e-a4b9-2cc7a5313a7c" TYPE="ext2"
/dev/sda6: LABEL="P06S16A" UUID="4049-D21E" TYPE="vfat"
/dev/sda7: SEC_TYPE="msdos" LABEL="P07S16A" UUID="788D-75F6" TYPE="vfat"
/dev/sda8: TYPE="swap" LABEL="S16A-08swapper" UUID="1e29f127-cef6-4f18-9fe5-14b69e0a9141"
/dev/sda9: LABEL="S16A-09cooker" UUID="317f1cc2-49ad-41f0-a7cf-f483d0ceb51f" SEC_TYPE="ext2" TYPE="ext3"

# cat /etc/mtab | sort | grep ,
/dev/dm-12 /disks/hda/boot ext2 rw,noatime,nodiratime,noacl 0 0
/dev/dm-14 /disks/D vfat rw,noexec,nosuid,nodev,dmask=0000,fmask=0111,utf8=true 0 0
/dev/dm-16 /disks/E msdos rw,noexec,nosuid,nodev,dmask=0000,fmask=0111 0 0
/dev/dm-19 / ext3 rw,noatime,nodiratime,acl 0 0
/dev/dm-20 /disks/hda/cooker ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-21 /disks/hda/fedora ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-23 /home ext3 rw,noatime,nodiratime,acl 0 0
/dev/dm-25 /pub ext3 rw,noatime,nodiratime,acl 0 0
/dev/dm-27 /srv ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-29 /usr/local ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-32 /usr/src ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-34 /disks/hda/suse100 ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-36 /disks/hda/suse101 ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-38 /disks/hda/suse102 ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-40 /disks/hda/suse103 ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-42 /disks/hda/suse110 ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-48 /disks/hda/mdv2008-1 ext3 rw,noatime,nodiratime,noacl 0 0
/dev/dm-8 /disks/C msdos rw,noexec,nosuid,nodev,dmask=0000,fmask=0111 0 0
devpts /dev/pts devpts rw,mode=0620,gid=5 0 0

# cat /etc/mtab | sort | grep , | wc -l
19

It would be more than 19 if not for unformatted partitions, unmountable 0x0A, & broken hpfs mounting under device mapper.
-- 
"Everyone should be quick to listen, slow to speak, and
slow to become angry."		James 1:19 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From skvidal at fedoraproject.org  Wed Oct 29 15:36:13 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 11:36:13 -0400
Subject: providing what they require
In-Reply-To: <alpine.DEB.1.10.0810290903480.17696@gotcha.dreamhost.com>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
	<200810230944.53271.ville.skytta@iki.fi>
	<alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>
	<1224878261.29258.22.camel@rosebud>
	<alpine.DEB.1.10.0810290903480.17696@gotcha.dreamhost.com>
Message-ID: <1225294573.21485.60.camel@rosebud>

On Wed, 2008-10-29 at 10:05 +0200, Panu Matilainen wrote:

> Note "breaks", not breaks. Bigger "breakage" happens when somebody sets 
> "%define _use_internal_dependency_generator 0" in their spec: it just 
> means bunch of information doesn't exist in the package at all. Some of it 
> is actually important (file colors), large amount of it is used by nothing 
> at all, it's just "information". Much like changelogs are - nothing in the 
> world *needs* them, but they're nice to have for humans. Except in the 
> case of file requires and bunch of other stuff, it's exposed directly in 
> the API. Not that it matters that much because nothing can depend on that 
> data as it might not be there (rpm v3 packages, packages built using 
> external dep generator), so those API's are practically unused...

I'd bet it is more than 'practically unused' but completely unused. In
fact, if there are users of the rpm api that we don't know about I'd be
a little surprised. rpm package management development is a fairly small
world :)


> If we add an option to rpm to ditch self-requires, should we actually add 
> a switch to disable generation of per-file dependency data completely with 
> it, maybe link the two options to one? Yum and the like wont notice a 
> thing, and it'll make packages & their metadata a little bit smaller.

Can you give me an example of per-file dep data that I might need? Just
to see where we might break compat/expected behavior in an odd way.

> Self-requires are just the tip of the iceberg when it comes to "useless
> bloat" in headers, try the following for entertaining lesson on what sort
> of junk the headers carry:
> $ rpm -qa --qf "%{name}-%{version}\n[\t%{CLASSDICT}\n]\n"
> 
> One of my favorites:
>          PNG image data, 313 x 225, 8-bit/color RGBA, non-interlaced
>          PNG image data, 339 x 210, 8-bit/color RGBA, non-interlaced
>          PNG image data, 349 x 274, 8-bit/color RGBA, non-interlaced
>          ...
> 
> Rpm knows not only that it's image data, it even knows the picture
> dimensions... That a file is an image (or a font, executable, dso ...)
> might actually be useful information even in rpm context, it's dimensions
> and color encoding probably not. Oh and btw, this file class and file
> require/provide information is loaded into memory on installation despite
> nothing using it (amounting to ~5-10% of memory use in the case I
> tested, and yes I'm going to do something about it).

Niiiiiiiiiiiiiice.

> 
> If you want to get filosophical about it: what is an rpm package and what 
> information should it carry and what not? From depsolver POV, pretty much 
> all it needs is lists of files and external dependencies. Depsolvers don't 
> *need* info like "upstream URL" and changelogs either.
> 

Some of this data is useful for making subtle distinctions when
depsolving. Yum does odd things when there are multiple providers to
score up a package based on things like sourcerpm. :)


> I don't think anybody uses it because it's pretty much impossible to use 
> as designed. There's a reason --noconfigs is a hidden cli switch unlike 
> --excludedocs...

Then maybe a set of things to have missing from rpm in F11?

-sv




From dominik at greysector.net  Wed Oct 29 15:40:36 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 29 Oct 2008 16:40:36 +0100
Subject: WPA without NetworkManager
In-Reply-To: <1225293777.1783.2.camel@luminos.localdomain>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<49087957.70905@gmail.com>
	<1225293777.1783.2.camel@luminos.localdomain>
Message-ID: <20081029154036.GI1293@mokona.greysector.net>

On Wednesday, 29 October 2008 at 16:22, Jesse Keating wrote:
> On Wed, 2008-10-29 at 09:55 -0500, Les Mikesell wrote:
> > I thought I saw having network manager run before login
> 
> NetworkManager does run before login, quite early in fact, and you can
> even configure it to wait for actual configuration of the IP address
> before moving on in the boot process.
> 
> However, if you're trying to boot iscsi via a wpa secured connection,
> perhaps you're doing it wrong?

While that configuration seems uncommon, there's no reason it shouldn't
be possible to make it work. I was talking about plain WPA, however.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From mw_triad at users.sourceforge.net  Wed Oct 29 15:46:06 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 10:46:06 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225273515.3636.48.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl>	<20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
Message-ID: <gea0fu$8qo$2@ger.gmane.org>

Richard Hughes wrote:
> The problem with fedora-devel-list is that the 0.01% of most technical
> users are there, most unable to understand that normal people don't use
> an smtp server or setup nfs.

...And the "0.01% of most technical users" want to know when Fedora 
decided to become Ubuntu.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From jkeating at redhat.com  Wed Oct 29 15:49:41 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 29 Oct 2008 08:49:41 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029152623.GG1293@mokona.greysector.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
	<20081029152623.GG1293@mokona.greysector.net>
Message-ID: <1225295381.1783.4.camel@luminos.localdomain>

On Wed, 2008-10-29 at 16:26 +0100, Dominik 'Rathann' Mierzejewski wrote:
> 
> The other is that it won't be tty1 in every case (init 5 after init 3, manual
> startx), which can be confusing. Make it so that it's ALWAYS on tty1 and maybe
> people will complain less, as long as it's documented properly.

It also isn't /always/ TTY7 if you've done manual configuration, or have
multi-users, or any number of other scenarios.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/1202eb53/attachment.sig>

From janina at rednote.net  Wed Oct 29 15:50:49 2008
From: janina at rednote.net (Janina Sajka)
Date: Wed, 29 Oct 2008 11:50:49 -0400
Subject: Telnet Failure With F-10 Beta
In-Reply-To: <20081028134134.GH24297@angus.ind.WPI.EDU>
References: <20081028124850.GA8215@sonata.rednote.net>
	<20081028134134.GH24297@angus.ind.WPI.EDU>
Message-ID: <20081029155049.GA4723@sonata.rednote.net>

Chuck Anderson writes:
> On Tue, Oct 28, 2008 at 08:48:50AM -0400, Janina Sajka wrote:
> > I tried (and failed) to start a telnet install of the F-10 beta on two
> > x86_64 machines. Furthermore, logs on the dhcp server do not indicate
> > that the target machine ever requested an ip address.
> > 
> > Is there a bug here? Anyone have any suggestions?
> 
> Try a more recent snapshot like F10 Snap3 or today's rawhide.
OK. Snap3 failed.

Yesterday's rawhide, from October 28, did better. It got the ipv4
address over dhcp, but gave "connection refused" to a telnet connection
request.

PS: We tried the ipv6=auto switch, but it did not get an address. Note
that we ARE running radvd, and this machine always gets its ipv6 address
that way in F-9.

Janina

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org

IPv6 is the answer!



From jkeating at redhat.com  Wed Oct 29 15:55:13 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 29 Oct 2008 08:55:13 -0700
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4908337A.5030705@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<4908337A.5030705@redhat.com>
Message-ID: <1225295713.1783.5.camel@luminos.localdomain>

On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
> Shouldn't be a big deal though, if plymouth does that vt
> switch right after KMS entered graphics mode and before printing
> anything on the screen it should went unnoticed.

Good explanation, except that KMS only works for a very limited set of
ATI graphics cards, and nowhere else.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/9baafe99/attachment.sig>

From dimi at lattica.com  Wed Oct 29 15:57:19 2008
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 29 Oct 2008 11:57:19 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225271780.3636.27.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
Message-ID: <1225295839.32201.37.camel@dimi.lattica.com>


On Wed, 2008-10-29 at 09:16 +0000, Richard Hughes wrote:
> I was thinking about trying to tackle the boot time of fedora (and get
> to the 5 second nirvana), but I fear that bikeshedding like this will
> mean we are still loading sendmail, isdn, nfslock, and all other
> legacy stuff in ten years time.

Just listening to all this discussions make my hairs stand on ends.
Whatever change is proposed, there are 10 people jumping on it why
it shouldn't be done!

This is most frustrating. Again and again, we keep putting the needs
of the fringe users ahead of what is needed by regular users. Like
most others OSS projects, there seems to be a total lack of weighing
when it comes down to these things.

What is important? Well, it's not rocket science (and don't ask for
studies, I don't care for that kind of discussion):
  1. Feedback
     Users need to know that the computer listens to them and it
     does something as a result. Many thumbs up to NetworkManager
     and PackageKit for providing much needed feedback.
     Thumbs down to System | Shut down ... that many times doesn't
     do anything. How hard is it shut down a system?!?
  2. Latency
     It goes hand-in-hand with (1). People have 0 tolerance to wait
     for anything, we can not be too fast. To the point where they
     sometimes prefer fast-and-buggy than slow-and-correct (within
     limits of course). Here we suck big time: horrible boot times,
     slow shutdown, slow app startup (1-2s to start a stupid TextEditor
     in Gnome on a modern machine!). 
  3. Relevance
     Get important stuff working. What's important today? 
     Well, it's Web, Email, Music, Video. The rest is bonus.
     Here things are getting a bit better: FF3 is fast, Evo is getting
     better. However, on F9 I still can't listen to music properly,
     as it skips continuously on my 2-CPU 4GB box even with no load. 
     And this only if I start pulseaudio with --no-cpu-limit, otherwise
     I get no music 'cause pulseaudio kills itself the moment I start
     doing pretty much anything on the box! With no auto-restart.
     Don't even get me started on Skype.

What we shouldn't concern ourselves with:
  * what vt X starts on. startup time trumps it
  * any sort of mail delivery agent, unless it's <10ms to start.
  * people that have / on NFS. Those can do a bit more work.
  * any other feature that slows down the startup from a local HD 
    for a regular desktop user that just wants to surf the web.

My $0.02.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mattdm at mattdm.org  Wed Oct 29 16:01:59 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 29 Oct 2008 12:01:59 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225295839.32201.37.camel@dimi.lattica.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<1225295839.32201.37.camel@dimi.lattica.com>
Message-ID: <20081029160159.GA30189@jadzia.bu.edu>

On Wed, Oct 29, 2008 at 11:57:19AM -0400, Dimi Paun wrote:
> Just listening to all this discussions make my hairs stand on ends.
> Whatever change is proposed, there are 10 people jumping on it why
> it shouldn't be done!

That's good. The default should be some level of respect for the user base.


> This is most frustrating. Again and again, we keep putting the needs
> of the fringe users ahead of what is needed by regular users. Like
> most others OSS projects, there seems to be a total lack of weighing
> when it comes down to these things.

The awesome part is you can define "fringe users" as "other people's use
cases" and "normal users" as "what I want". 


> What is important? Well, it's not rocket science (and don't ask for
> studies, I don't care for that kind of discussion):

Exactly! No need to actually study when we can just make stuff up!

>   3. Relevance
>      Get important stuff working. What's important today? 
>      Well, it's Web, Email, Music, Video. The rest is bonus.

1) What makes those things _work_ on desktop systems?

2) What's important tomorrow?

> 

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mjg at redhat.com  Wed Oct 29 16:08:43 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 29 Oct 2008 16:08:43 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <49087A4F.5030207@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<20081029135251.GE1293@mokona.greysector.net>
	<49087A4F.5030207@gmail.com>
Message-ID: <20081029160843.GA29661@srcf.ucam.org>

On Wed, Oct 29, 2008 at 09:59:27AM -0500, Les Mikesell wrote:

> And they run X nicely, and it behaves the way you expect X to behave...

In that pressing ctrl+alt+F1 doesn't get you to a text console?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From ajax at redhat.com  Wed Oct 29 16:09:46 2008
From: ajax at redhat.com (Adam Jackson)
Date: Wed, 29 Oct 2008 12:09:46 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4908337A.5030705@redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<4908337A.5030705@redhat.com>
Message-ID: <1225296586.5409.78.camel@atropine.boston.devel.redhat.com>

On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
> Jesse Keating wrote:
> > On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
> >> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
> >> only feature it is to break documentations, habits and to add further
> >> hassle.  A completely superfluous change.
> > 
> > As noted multiple times on this thread, the change prevents the
> > multi-second monitor refresh issues when mode is changed by vt switches.
> 
> The flicker / resync delay comes from the *mode switch*, not the *vt
> switch*.  And, no, a vt switch does *not* imply a mode switch.

The resync delay, yes.  If there is a mode switch, then that'll take
time.

However, just plain vt switch _does_ paint the whole screen.  If you're
trying to crossfade from plymouth to gdm, then you want to not clear to
black before starting X, which means you can't change vt.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/210aea7f/attachment.sig>

From mjg at redhat.com  Wed Oct 29 16:11:34 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 29 Oct 2008 16:11:34 +0000
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <4908337A.5030705@redhat.com>
References: <91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<4908337A.5030705@redhat.com>
Message-ID: <20081029161134.GB29661@srcf.ucam.org>

On Wed, Oct 29, 2008 at 10:57:14AM +0100, Gerd Hoffmann wrote:
> Jesse Keating wrote:
> > On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
> >> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
> >> only feature it is to break documentations, habits and to add further
> >> hassle.  A completely superfluous change.
> > 
> > As noted multiple times on this thread, the change prevents the
> > multi-second monitor refresh issues when mode is changed by vt switches.
> 
> The flicker / resync delay comes from the *mode switch*, not the *vt
> switch*.  And, no, a vt switch does *not* imply a mode switch.

vt switching implies a screen repaint, which will cause a visible visual 
artifact. You're correct that in the kms world that doesn't imply a mode 
switch, but that's not really the point.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From jspaleta at gmail.com  Wed Oct 29 16:11:16 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 08:11:16 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <49081A53.1050504@leemhuis.info>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
Message-ID: <604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>

On Wed, Oct 29, 2008 at 12:09 AM, Thorsten Leemhuis
<fedora at leemhuis.info> wrote:
> I hereby propose we add a Checkbox (?) "Old-School Linux user" somewhere
> to anaconda; users that want to preserve the traditional behavior for this
> and other things (like "show grub by default") can then just check that to
> get the old behavior.


Just as long as "old school" also gets rid of udev and everything hal
or dbus related and brings back magicdev AND linuxconf! Oh and turns
off selinux off...gives me ipchains as a firewall and disables ssh and
gives me rsh instead as the only remote shell....and gives me a fvwm
desktop using xdm as the login manager.

-jef"seriously the udev/hal stuff was a far more fundamental and far
reaching technology shift than which vt X is running on. The flipside
to all the arguments here is all gettys could be off by default unless
local admins want them on..and at that point its a customization and
admins can do whatever the hell they want with their gettys.  I admin
a small number of systems, and the reality is I can actually live with
gettys off by default. If I need them I can enable them on the systems
that need them."spaleta



From mw_triad at users.sourceforge.net  Wed Oct 29 16:11:46 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 11:11:46 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
Message-ID: <gea202$mbt$1@ger.gmane.org>

Brian Wheeler wrote:
> On Wed, 2008-10-29 at 10:25 -0400, Felix Miata wrote:
>> On 2008/10/29 08:26 (GMT-0400) Brian Wheeler composed:
>>
>>> Almost all of the "reasons" from the original email boil down to "we've
>>> always done it this way".  
>> Don't boil it down. The reasons are good why we've always done it this way
>> and should keep the status quo. I haven't seen sufficient reason in this
>> thread to dismiss those reasons.
> 
> _What_ are the good reasons why we've done it this way?  Its only tty7
> because someone arbitrarily decided to run 6 getty processes way back
> when.  If someone had decided that 4 was sufficient, then we'd be
> arguing about tty5.
> 
> At least with X being on tty1 it makes sense since its the primary
> terminal for most people.  

As has been pointed out, this is *irrelevant* for people that don't 
usually fiddle with VT's. Those that do expect a text terminal on VT1.

It's not so much that VT7 is "magic" as that the expectation is text 
VT's, then X VT's, with both in contiguous blocks. You're breaking this.

> The only non-"but that's the way it's always been" argument I've seen
> thus far is documentation...which is something that can be changed.

...for Fedora, when all other distros do something different? (Oh, wait, 
it's not even consistent in Fedora!) So now you have to document:

All non-Fedora distros, Fedora that's ever been in runlevel 3
...and...
Fedora booted in runlevel 5 and never changed to another runlevel

Really, is that desirable?

(This whole thread is absurd. I don't personally like the change but I 
could probably stomach it. What *really* irritates me is that the people 
pushing it don't appear to care about the objections; they're not 
responding intelligently to them, they're just trying to bury them under 
the "wave of progress", not to mention the "vocal minority" argument. 
Add to that how the make-everyone-happy proposed solutions are being 
ignored... If I wanted a distro that throws out things that 
traditionally work and imposes decisions on me, I'd go use Ubuntu, 
thanks. It bothers me to see the extent to which people seem to be 
pushing Fedora in that direction, especially when Fedora is supposed to 
be "Red Hat Alpha", but is making decisions that are bad for an 
Enterprise distribution like Red Hat.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From notting at redhat.com  Wed Oct 29 16:14:53 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 12:14:53 -0400
Subject: providing what they require
In-Reply-To: <alpine.DEB.1.10.0810290903480.17696@gotcha.dreamhost.com>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
	<200810230944.53271.ville.skytta@iki.fi>
	<alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>
	<1224878261.29258.22.camel@rosebud>
	<alpine.DEB.1.10.0810290903480.17696@gotcha.dreamhost.com>
Message-ID: <20081029161452.GA19343@nostromo.devel.redhat.com>

Panu Matilainen (pmatilai at laiskiainen.org) said: 
> $ rpm -qa --qf "%{name}-%{version}\n[\t%{CLASSDICT}\n]\n"
>
> One of my favorites:
>         PNG image data, 313 x 225, 8-bit/color RGBA, non-interlaced
>         PNG image data, 339 x 210, 8-bit/color RGBA, non-interlaced
>         PNG image data, 349 x 274, 8-bit/color RGBA, non-interlaced
>         ...
>
> Rpm knows not only that it's image data, it even knows the picture
> dimensions...

Only in the sense that that's the raw output of file(1) - to rely
on that, you have to hope that that never changes. Which is unlikely.
(Ergo ... useless.)

Bill



From kraxel at redhat.com  Wed Oct 29 16:20:14 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 17:20:14 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225295713.1783.5.camel@luminos.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>	<1225216493.2157.68.camel@luminos.localdomain>	<4908337A.5030705@redhat.com>
	<1225295713.1783.5.camel@luminos.localdomain>
Message-ID: <49088D3E.6030402@redhat.com>

Jesse Keating wrote:
> On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
>> Shouldn't be a big deal though, if plymouth does that vt
>> switch right after KMS entered graphics mode and before printing
>> anything on the screen it should went unnoticed.
> 
> Good explanation, except that KMS only works for a very limited set of
> ATI graphics cards, and nowhere else.

But without KMS the X11 start will mode-switch and thus flicker anyway,
no matter whenever tty1 or tty7 is used, right?

cheers,
  Gerd



From kraxel at redhat.com  Wed Oct 29 16:25:07 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 17:25:07 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225296586.5409.78.camel@atropine.boston.devel.redhat.com>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>	<1225216493.2157.68.camel@luminos.localdomain>	<4908337A.5030705@redhat.com>
	<1225296586.5409.78.camel@atropine.boston.devel.redhat.com>
Message-ID: <49088E63.3020108@redhat.com>

Adam Jackson wrote:
> On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
>> Jesse Keating wrote:
>>> On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
>>>> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
>>>> only feature it is to break documentations, habits and to add further
>>>> hassle.  A completely superfluous change.
>>> As noted multiple times on this thread, the change prevents the
>>> multi-second monitor refresh issues when mode is changed by vt switches.
>> The flicker / resync delay comes from the *mode switch*, not the *vt
>> switch*.  And, no, a vt switch does *not* imply a mode switch.
> 
> The resync delay, yes.  If there is a mode switch, then that'll take
> time.
> 
> However, just plain vt switch _does_ paint the whole screen.  If you're
> trying to crossfade from plymouth to gdm, then you want to not clear to
> black before starting X, which means you can't change vt.

Read the mail again.  All of it.  Last paragraph suggests to run
plymouth on tty7 to keep the cross-fading effect.

thanks,
  Gerd



From dimi at lattica.com  Wed Oct 29 16:25:12 2008
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 29 Oct 2008 12:25:12 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
Message-ID: <1225297512.32201.45.camel@dimi.lattica.com>


On Wed, 2008-10-29 at 08:11 -0800, Jeff Spaleta wrote:
> The flipside to all the arguments here is all gettys could be off by
> default unless local admins want them on..and at that point its a
> customization and admins can do whatever the hell they want with their
> gettys.

Well said Jeff, this is quite reasonable. You have my +1 :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sstarr at platform.com  Wed Oct 29 16:29:54 2008
From: sstarr at platform.com (Shawn Starr)
Date: Wed, 29 Oct 2008 09:29:54 -0700
Subject: X on tty1 in Rawhide/F10
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE0109214A@catoexm05.noam.corp.platform.com>

> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of 
> Ralf Corsepius
> Sent: Tuesday, October 28, 2008 6:38 PM
> To: Development discussions related to Fedora
> Subject: Re: X on tty1 in Rawhide/F10
> 
> To me, the fact of X11 going to F1 is a usability regression.
> 
> 

It is a regression.  Why in heck would switching from from tty0 to tty1 I see X then switch to tty2 see console again? There's a good reason for it being on tty7, so it's out ot the fscking (especially when X CRASHES on VT switch back to X :P [See ATI, composite mess and all that jazz]).

Yes, even if there is a workaround, a lot of us 'old' folk are programmed from the old days of seeing X on tty7. 

This just seems pretty stupid to put it on tty1 *WHEN* TTY2 is console!  text, X, text, text, text.... c'mon people think smart!

Shawn.



From jspaleta at gmail.com  Wed Oct 29 16:32:29 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 08:32:29 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <gea202$mbt$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
	<gea202$mbt$1@ger.gmane.org>
Message-ID: <604aa7910810290932m252c8a28pca37156ac252d5bb@mail.gmail.com>

On Wed, Oct 29, 2008 at 8:11 AM, Matthew Woehlke
> it don't appear to care about the objections; they're not responding
> intelligently to them,

I don't have an intelligent response to any argument which essentially
comes down to "tradition."  Have the traditionalists pulled put forth
any consensus document like an RFC to support that at some point in
time a group of people actually talk through the need for doing gettys
a certain way?

Traditions which codify a collection of arbitrary decisions..are
traditions I will gladly help throw into the fire.


-jef



From dimi at lattica.com  Wed Oct 29 16:33:13 2008
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 29 Oct 2008 12:33:13 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029160159.GA30189@jadzia.bu.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<1225295839.32201.37.camel@dimi.lattica.com>
	<20081029160159.GA30189@jadzia.bu.edu>
Message-ID: <1225297993.32201.55.camel@dimi.lattica.com>


On Wed, 2008-10-29 at 12:01 -0400, Matthew Miller wrote:
> > What is important? Well, it's not rocket science (and don't ask for
> > studies, I don't care for that kind of discussion):
> 
> Exactly! No need to actually study when we can just make stuff up!

Or better yet, let's indulge in some satisfying mental masturbation
about what a user or a computer is, what's the meaning of life, and
what can we do to address _all_ of the world's problems at once.

Seriously, if we have studies, let's use them. Sure. But I've been
long enough in the Linux community to know that if you want something
stopped in its tracks, you just start a meta-discussion that can
last forever. And everybody has a chance of showing just how fscking
intelligent they are in understanding all the subtle nuances in the
semantics of such difficult concept as "user", "normal", and so on.

Meanwhile nothing gets done, and the entire mess perpetuates itself
by years in a lot of cases. Sorry, seen too many such discussions to
still believe they lead anywhere productive.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From langel at redhat.com  Wed Oct 29 16:38:37 2008
From: langel at redhat.com (Lillian Angel)
Date: Wed, 29 Oct 2008 12:38:37 -0400
Subject: Orphaning azureus
In-Reply-To: <49082091.4090206@gmail.com>
References: <20081024190916.A41D98E0003@hormel.redhat.com>	<20081028171711.3c1f1cc9@cheeky>
	<49082091.4090206@gmail.com>
Message-ID: <4908918D.6010109@redhat.com>

Alphonse Van Assche wrote:
> Stefan Posdzich a ?crit :
>> I have tried now some days with this package and i cant get warm with it
>> (+ java).
>> I will orphan it again, i hope it will find someone who can handle
>> this kind of apps!
>>
>> https://admin.fedoraproject.org/pkgdb/packages/name/azureus
>>
>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=azureus
>>
>> best regards
>> Stefan
>>
>>   
> If nobody want it, I would like to take care of it.
>
> Alphonse
>
>


Please do!


Lillian



From fedora at shmuelhome.mine.nu  Wed Oct 29 16:43:49 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Wed, 29 Oct 2008 18:43:49 +0200
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225297993.32201.55.camel@dimi.lattica.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<1225295839.32201.37.camel@dimi.lattica.com>	<20081029160159.GA30189@jadzia.bu.edu>
	<1225297993.32201.55.camel@dimi.lattica.com>
Message-ID: <490892C5.9060601@shmuelhome.mine.nu>

Dimi Paun wrote:
> On Wed, 2008-10-29 at 12:01 -0400, Matthew Miller wrote:
>   
>>> What is important? Well, it's not rocket science (and don't ask for
>>> studies, I don't care for that kind of discussion):
>>>       
>> Exactly! No need to actually study when we can just make stuff up!
>>     
>
> Or better yet, let's indulge in some satisfying mental masturbation
> about what a user or a computer is, what's the meaning of life, and
> what can we do to address _all_ of the world's problems at once.
>
> Seriously, if we have studies, let's use them. Sure. But I've been
> long enough in the Linux community to know that if you want something
> stopped in its tracks, you just start a meta-discussion that can
> last forever. And everybody has a chance of showing just how fscking
> intelligent they are in understanding all the subtle nuances in the
> semantics of such difficult concept as "user", "normal", and so on.
>
> Meanwhile nothing gets done, and the entire mess perpetuates itself
> by years in a lot of cases. Sorry, seen too many such discussions to
> still believe they lead anywhere productive.
>
>   
Sorry, you are on the wrong thread for this argument. In this case 
something was done which many people object to. They have given their 
reasons and even proposed alternatives. It is the side that says keep 
the change that is forestalling any meaningful discussion.



From walters at verbum.org  Wed Oct 29 16:53:16 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 12:53:16 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
Message-ID: <faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>

On Wed, Oct 29, 2008 at 6:37 AM, Panu Matilainen
<pmatilai at laiskiainen.org> wrote:
>
> Hate to interrupt the tty1 vs tty7 debate but...
>
> We have kernel support for storing capabilities on filesystem since 2.6.24
> and recent libcap, both in F9 already. I just committed file capability
> support to rpm.org HEAD, filling in the final(?) missing piece. Capability
> support is not going to be in rpm 4.6.0 but no reason they can't be pulled
> into 4.6.1 which is easily in F11 timeframe.
>
> Are we ready to start considering moving away from SUID bits to
> capabilities, in Fedora 11 maybe?

Note that from the desktop direction we've been moving the OS away
from exec-based domain transitions to message passing (e.g. PolicyKit)
for a variety of reasons.  I think it might be worth considering
introducing a rule actually in Fedora for "no new SUID/fcap binaries",
or at least they would have to pass some sort of robust review
process.



From wwoods at redhat.com  Wed Oct 29 16:57:28 2008
From: wwoods at redhat.com (Will Woods)
Date: Wed, 29 Oct 2008 12:57:28 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE0109214A@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE0109214A@catoexm05.noam.corp.platform.com>
Message-ID: <1225299449.18751.4.camel@metroid.rdu.redhat.com>

On Wed, 2008-10-29 at 09:29 -0700, Shawn Starr wrote:
> 
> This just seems pretty stupid to put it on tty1 *WHEN* TTY2 is
> console!  text, X, text, text, text.... c'mon people think smart!

You're either kidding, or you haven't actually tested this. There's no
tty0. It goes X, text, text, text..

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3153 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/f140fb6d/attachment.bin>

From lesmikesell at gmail.com  Wed Oct 29 17:09:05 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 12:09:05 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
Message-ID: <490898B1.8080000@gmail.com>

Jeff Spaleta wrote:
> 
> The flipside
> to all the arguments here is all gettys could be off by default unless
> local admins want them on..and at that point its a customization and
> admins can do whatever the hell they want with their gettys.  

Doing that to reduce memory/process overhead would actually be the only 
real justification that I've seen so far for making a change like this 
(as opposed to switching vt's earlier so you can fade in the mode change).

Why not turn off the getty startup by default and let people who want 
them 'chkconfig' them back on?  That gets you a real benefit for the 
people who don't ever use vts and consistency all the way around for 
people that do.

-- 
  Les Mikesell
    lesmikesell at gmail.com



From dkelson at gurulabs.com  Wed Oct 29 17:15:11 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 11:15:11 -0600
Subject: A suggestion regarding new features
Message-ID: <1225300511.3846.44.camel@mentor.gurulabs.com>

Progress is great, new shiny frobnicators are wonderful. What many
people (myself included) object to is when old behaviors and
compatibility is broken NEEDLESSLY.  Let's have our cake and eat it too!

When implementing new features what about using a decision tree that
looks like the following:

======================================================

Step 1. Does $NEWFEATURE implementation change old behaviors or break
compatibility? 

a) NO -> Great go for it! Let's all eat cake!
b) YES -> See step 2

Step 2. Can $NEWFEATURE be implemented so that it doesn't change old
behaviors or break compatibility?

a) NO -> Uh oh, see step 3.
b) YES preserve both -> Excellent. Let's all eat cake!
c) YES preserve compatibility -> Great no "exceptions". Let's all eat
cake!

Examples of "2c" include GRUB, udev/hal, ALSA, hda -> sda, LVM, FACLS
on /dev files, CUPS, POSIX CAPs to replace SUID, etc. All distros moved
these features in relative unison so I can toss that old knowledge out
of my brain (and documentation).

Step 3. Does the benefit of $NEWFEATURE outweigh the cost of changing
the old behavior or breaking compatibility? Obviously this can be
subjective.

a) NO -> Good effort. Have you considered picking one of the other many
areas in Linux that need improving and working on that?
b) YES -> OK, $NEWFEATURE must be really awesome. Please double check
that you can't resolve this in Step 2. So Step 2 is a no go? OK, let's
do it.

======================================================

Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST
PLACE.

Many people have voiced concerns that to many $NEWFEATURES are going
straight to Step 3 without exploring a Step 1 or Step 2 resolution. 

No sane person would prefer a Step 3 resolution versus a Step 2
resolution.

The issue with "BetterStartup" having the side effect of moving X to
tty1 vs tty7 can go from the current Step 3 $NEWFEATURE back to a "Step
2b" $NEWFEATURE.  Let's all eat cake!

How? It has already been pointed out that a VT switch doesn't imply a
flicker (aka a mode change). You can switch VTs without "flicker". After
the kernel has set the mode (which happens for all VTs), then plymouth
starts X on tty7 and starts X. No flicker, plus we have preserved
compatibility and not changed behaviors.

Dax Kelson
Guru Labs



From jspaleta at gmail.com  Wed Oct 29 17:16:41 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 09:16:41 -0800
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
Message-ID: <604aa7910810291016y40ef178cl35faec95102df5bc@mail.gmail.com>

On Wed, Oct 29, 2008 at 8:53 AM, Colin Walters
> Note that from the desktop direction we've been moving the OS away
> from exec-based domain transitions to message passing (e.g. PolicyKit)
> for a variety of reasons.  I think it might be worth considering
> introducing a rule actually in Fedora for "no new SUID/fcap binaries",
> or at least they would have to pass some sort of robust review
> process.


I think I like that idea.  As part of that is there a way we could get
a comprehensive list of the suid binaries we currently carry that
would be grandfather'd in?  So we can know how concerted extra effort
would need to be done to help existing packages come into compliance?

-jef



From rc040203 at freenet.de  Wed Oct 29 17:16:47 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 29 Oct 2008 18:16:47 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
Message-ID: <1225300607.3897.394.camel@beck.corsepiu.local>

On Wed, 2008-10-29 at 10:32 -0400, Brian Wheeler wrote:
> On Wed, 2008-10-29 at 10:25 -0400, Felix Miata wrote:
> > On 2008/10/29 08:26 (GMT-0400) Brian Wheeler composed:
> > 
> > > Almost all of the "reasons" from the original email boil down to "we've
> > > always done it this way".  
> > 
> > Don't boil it down. The reasons are good why we've always done it this way
> > and should keep the status quo. I haven't seen sufficient reason in this
> > thread to dismiss those reasons.
> 
> _What_ are the good reasons why we've done it this way?  Its only tty7
> because someone arbitrarily decided to run 6 getty processes way back
> when.  If someone had decided that 4 was sufficient, then we'd be
> arguing about tty5.
> 
> At least with X being on tty1 it makes sense since its the primary
> terminal for most people.  
Well, this change adds non-determinism to what tty1 actually is.

Play around a little with booting rawhide into runlevel 3 rsp. 5 and
switching between runlevel 3 and 5. I did so today and occasionally
ended up with X11 on tty7 sometimes on tty1 and sometimes with the
machine going down the hard way.

> The only non-"but that's the way it's always been" argument I've seen
> thus far is documentation
Correct, it is a convention, just like any other arbitrary convention on
key interpretation, just like "Ctrl-Alt-Del", "Ctrl-Alt-Backspace" or
"Del" and "Backspace" (linux veterans might recall the dispute on Del
vs. Backspace) rsp. the DEC/Vt100 keycodes in terminals (Which Linux
new-comers might never have heard about).

> ...which is something that can be changed.
Why should it be changed?

So far there simply is no technical reason for why it should be changed.

Ralf




From lesmikesell at gmail.com  Wed Oct 29 17:17:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 12:17:42 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225293850.5412.181.camel@vorpal.macdev.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>
	<1225293850.5412.181.camel@vorpal.macdev.com>
Message-ID: <49089AB6.8040403@gmail.com>

David G. Mackay wrote:
> On Wed, 2008-10-29 at 08:51 -0400, seth vidal wrote:
>> There's no one working in computing today ANYWHERE who is doing
>> revolutionary work. I'd argue there is no such thing as revolutionary
>> work AT ALL. Stop looking for it where it is not.
> 
> What about quantum computing?  A fundamental paradigm shift seems like
> it ought to count.

I would have called podcast subscriptions revolutionary.  Or the ability 
to scan a bar code with a cell phone and get competitive pricing for the 
item in more or less real time.  There may not be a single innovation 
involved but instead a massive group that relies on following the same 
conventions to gain new value.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From dkelson at gurulabs.com  Wed Oct 29 17:20:36 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 11:20:36 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
Message-ID: <1225300836.3846.49.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 08:11 -0800, Jeff Spaleta wrote:

> Just as long as "old school" also gets rid of udev and everything hal
> or dbus related and brings back magicdev AND linuxconf! Oh and turns
> off selinux off...gives me ipchains as a firewall and disables ssh and
> gives me rsh instead as the only remote shell....and gives me a fvwm
> desktop using xdm as the login manager.
> 
> -jef"seriously the udev/hal stuff was a far more fundamental and far
> reaching technology shift than which vt X is running on. The flipside
> to all the arguments here is all gettys could be off by default unless
> local admins want them on..and at that point its a customization and
> admins can do whatever the hell they want with their gettys.  I admin
> a small number of systems, and the reality is I can actually live with
> gettys off by default. If I need them I can enable them on the systems
> that need them."spaleta

Most (all?) of the technologies you mentioned are cross-distribution.
Everybody switched, compatibility across distributions was maintained.
Books and brains were free to drop the old ways and just document and
learn the new ways.

This X tty change is not comparable. Apples and Oranges.

Dax Kelson
Guru Labs



From rc040203 at freenet.de  Wed Oct 29 17:21:00 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 29 Oct 2008 18:21:00 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
Message-ID: <1225300860.3897.398.camel@beck.corsepiu.local>

On Wed, 2008-10-29 at 08:11 -0800, Jeff Spaleta wrote:
> The flipside
> to all the arguments here is all gettys could be off by default unless
> local admins want them on.
You will likely comprehend the absurdity of this proposal when X server
races the next time.




From dkelson at gurulabs.com  Wed Oct 29 17:22:08 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 11:22:08 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225271780.3636.27.camel@hughsie-laptop>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
Message-ID: <1225300928.3846.52.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 09:16 +0000, Richard Hughes wrote:
> On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> > I would argue strongly that this change should not be made for the
> > following reasons (in no particular order):
> 
> Does it matter? 

Yes it matters. I gave 9 distinct, independent reasons (spread over 10
bullet points). 

Dax Kelson
Guru labs



From daryll.strauss at gmail.com  Wed Oct 29 17:23:20 2008
From: daryll.strauss at gmail.com (Daryll Strauss)
Date: Wed, 29 Oct 2008 10:23:20 -0700
Subject: Oops. F10 Beta ate my laptop
Message-ID: <55668b8c0810291023p1e337da1v326c36c3e8255ef0@mail.gmail.com>

Hi Folks,

I had a chance to install F10 Beta on a new laptop a couple weeks back.
Because it was a laptop, I chose the encrypt disk option. I was updating my
system with the latest code as it arrived, usually the same day. Everything
has been great, until today.

Last night another 50 or so packages updated, and since it included a
kernel, I shut down. This morning when I booted the laptop, it starts up and
shows that it is booting Fedora 9.92. I see the blue/white bar appear and
make progress.

Normally it would stop shortly after this starts and prompt me for my
password. That never happened. Instead it the blue bar progressed all the
way to the right side of the screen, the Fedora 9.92 text turned white, and
then the it just sat there.

I tried hitting escape during the process, but that brings up an empty
console with a blinking cursor, but no text. So I don't seem to have any
more diagnostic information available.

One other caveat in terms of complete disclosure. I was running the nVidia
drivers. With my previous updates that hasn't been an issue. The kernel
updates and I don't get X when the system restarts. I then reinstall the
nVidia package and reboot the system where everything comes up normally. I
don't believe this is related to the problem, but I hate when my customers
leave details out of their requests. Nothing else is particularly unusual
about the system.

I'm not sure what to try next. If there's more diagnostics I can collect,
let me know. If someone has a suggestion as how to get my laptop back to a
bootable state, that would great. It would be a PITA if I had to reinstall,
but not the end of the world.

Let me know,
- |Daryll
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/12c8eb61/attachment.htm>

From dkelson at gurulabs.com  Wed Oct 29 17:28:03 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 11:28:03 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225295839.32201.37.camel@dimi.lattica.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<1225295839.32201.37.camel@dimi.lattica.com>
Message-ID: <1225301283.3846.59.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 11:57 -0400, Dimi Paun wrote:

> What we shouldn't concern ourselves with:
>   * what vt X starts on. startup time trumps it

This isn't the only choice!

How about "flicker free fast startup" with X remaining on tty7?

If that fails, you sit down make an informed, weighed decision on what
to do. Not a quick rash choice.

Dax Kelson
Guru Labs



From dkelson at gurulabs.com  Wed Oct 29 17:30:13 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 11:30:13 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225284178.23396.19.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49085873.6070107@shmuelhome.mine.nu>
	<1225284178.23396.19.camel@nibbler.dlib.indiana.edu>
Message-ID: <1225301413.3846.62.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 08:42 -0400, Brian Wheeler wrote:

> 
> I'm still trying to figure out why there's all the love for X on tty7.
> 
> Things change.  We adapt.  Having the primary interface on tty1 makes
> much more sense than it being on tty7.  On a semi-serious note, the tty7
> choice is a historical accident...not a design choice.
> 
> OSS has been replaced.
> Static /dev has been replaced.
> SysV init has been replaced.
> IDE drives aren't /dev/hd* anymore.
> We're using LVM instead of raw partitions.
> 
> All of these things (and more) caused a bit of trouble when they were
> first introduced and then became the norm.  
> 
> 
> Brian

Brian, 

You are comparing apples and oranges. Like I responded to Jeff. 

Most all of the technologies you mentioned are cross-distribution.
Everybody switched, compatibility across distributions was maintained.
Books and brains were free to drop the old ways and just document and
learn the new ways.

This X tty change is not comparable.

Dax Kelson
Guru Labs



From alan at redhat.com  Wed Oct 29 17:31:01 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Oct 2008 13:31:01 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283507.5412.178.camel@vorpal.macdev.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
	<1225283507.5412.178.camel@vorpal.macdev.com>
Message-ID: <20081029173101.GB3042@shell.devel.redhat.com>

On Wed, Oct 29, 2008 at 07:31:47AM -0500, David G. Mackay wrote:
> > Design by committee just doesn't work.
> 
> So all of those ISO and IEEE standards are worthless?

Most of the good ones have a design list a few names long. Same with the
good RFC stuff. May have had 100 people twiddle with the spec but only a tiny
few wrote it. Compare IPv6 an OSI Level 4 ...

Alan



From alan at redhat.com  Wed Oct 29 17:32:42 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Oct 2008 13:32:42 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225284400.23396.23.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225283804.7036.73.camel@jg-vaio>
	<1225284400.23396.23.camel@nibbler.dlib.indiana.edu>
Message-ID: <20081029173242.GC3042@shell.devel.redhat.com>

On Wed, Oct 29, 2008 at 08:46:40AM -0400, Brian Wheeler wrote:
> Interesting.  Besides making sure that X ends up on tty7, is there any
> reason why we have 6 VTs?  For all the years I've been using linux in a

Because it was the number of getty tasks someone had in the example inittab
for SysVInit I suspect. It is useful to have a couple even for debug hiding
where you can direct a user but the number is arbitary and the fact X happens
to be VT7 is just a further arbitary fallout from this.

Alan




From dkelson at gurulabs.com  Wed Oct 29 17:33:50 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 11:33:50 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
Message-ID: <1225301630.3846.66.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 08:26 -0400, Brian Wheeler wrote:
> I'm going to agree with the -1.  
> 
> Almost all of the "reasons" from the original email boil down to "we've
> always done it this way".  

Absolute not! I gave 9 distinct, independent reasons. Only one of which
was regarding tradition.

Listen, it's easy to win arguments if you rephrase/restate all the
opposing arguments into one straw man.

Dax Kelson
Guru Labs



From selinux at gmail.com  Wed Oct 29 17:34:34 2008
From: selinux at gmail.com (Tom London)
Date: Wed, 29 Oct 2008 10:34:34 -0700
Subject: Oops. F10 Beta ate my laptop
In-Reply-To: <55668b8c0810291023p1e337da1v326c36c3e8255ef0@mail.gmail.com>
References: <55668b8c0810291023p1e337da1v326c36c3e8255ef0@mail.gmail.com>
Message-ID: <4c4ba1530810291034r42d499fcna28d804236f11c26@mail.gmail.com>

2008/10/29 Daryll Strauss <daryll.strauss at gmail.com>:
>
> Hi Folks,
>
> I had a chance to install F10 Beta on a new laptop a couple weeks back.
> Because it was a laptop, I chose the encrypt disk option. I was updating my
> system with the latest code as it arrived, usually the same day. Everything
> has been great, until today.
>
> Last night another 50 or so packages updated, and since it included a
> kernel, I shut down. This morning when I booted the laptop, it starts up and
> shows that it is booting Fedora 9.92. I see the blue/white bar appear and
> make progress.
>
> Normally it would stop shortly after this starts and prompt me for my
> password. That never happened. Instead it the blue bar progressed all the
> way to the right side of the screen, the Fedora 9.92 text turned white, and
> then the it just sat there.
>
> I tried hitting escape during the process, but that brings up an empty
> console with a blinking cursor, but no text. So I don't seem to have any
> more diagnostic information available.
>
> One other caveat in terms of complete disclosure. I was running the nVidia
> drivers. With my previous updates that hasn't been an issue. The kernel
> updates and I don't get X when the system restarts. I then reinstall the
> nVidia package and reboot the system where everything comes up normally. I
> don't believe this is related to the problem, but I hate when my customers
> leave details out of their requests. Nothing else is particularly unusual
> about the system.
>
> I'm not sure what to try next. If there's more diagnostics I can collect,
> let me know. If someone has a suggestion as how to get my laptop back to a
> bootable state, that would great. It would be a PITA if I had to reinstall,
> but not the end of the world.
>
> Let me know,
> - |Daryll
>

See this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=468856

Believe there is an issue with the Rawhide mkinird and encrypted disk
partitions.

If you have a previous kernel, you should be able to boot with that.

BZ describes reverting mkinitrd and rebuilding the initrd, but I
suspect a "fix" is in the works.

Hope this helps.

tom
-- 
Tom London



From billcrawford1970 at gmail.com  Wed Oct 29 17:36:07 2008
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 29 Oct 2008 17:36:07 +0000
Subject: Window / Screen question
In-Reply-To: <48FF7660.9060807@gnat.ca>
References: <48FF7660.9060807@gnat.ca>
Message-ID: <200810291736.07730.billcrawford1970@gmail.com>

On Wednesday 22 October 2008 19:52:16 Nathanael D. Noblet wrote:
> Hi,
>
>    This isn't a fedora question specifically, however just thought I'd
> run it by to get some feedback.
>
>    I've had a multi-card/multi-monitor setup for a few months now. It
> has been a royal pain. (Only the closed drivers can handle it
> unfortunately). I was talking to the radeon/ati driver people and have
> been informed that multi-card setups don't get much love from either the
> driver developers or upstream/xorg. So I've figured I may move from 3
> monitors back to 2 larger (24") monitors. So after that history, here
> comes the idea...

Having similar problems here, but without adding nomodeset/nofb options to the 
kernel command line I can't even boot this machine into current rawhide. With 
nomodeset alone, I get to a command line but there's an oops when it tries to 
load the radeon driver.

>    I'm wondering if it is possible to have 'fake' monitor
> borders/dimensions. So you instruct xorg/gnome/xinerama or whatever that
> the 1900 pixel width is 2/3rd + 1/3rd. If I were to click maximize
> within either of those imaginary borders, it would maximize to that size
> instead of the 1900 px width. If I double clicked, it would then go
> fullscreen...
>
> Does this sound at all useful? Opinions / critiques...

This sounds very like a debugging mode metacity used to have where it would 
pretend you had two side by side half-width screens (so apps would maximise to 
half the desktop) but it wasn't configurable, just a way to test xinerama code 
in metacity. Would be extremely useful, for me at least, if I get the 1920 by 
1200 monitor I'd like :-q

> --
> Nathanael d. Noblet
> Gnat Solutions, Inc
> T: 403.875.4613




From skvidal at fedoraproject.org  Wed Oct 29 17:31:45 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 13:31:45 -0400
Subject: A suggestion regarding new features
In-Reply-To: <1225300511.3846.44.camel@mentor.gurulabs.com>
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
Message-ID: <1225301505.21485.65.camel@rosebud>

On Wed, 2008-10-29 at 11:15 -0600, Dax Kelson wrote:

> Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST
> PLACE.
> 
> Many people have voiced concerns that to many $NEWFEATURES are going
> straight to Step 3 without exploring a Step 1 or Step 2 resolution. 
> 
> No sane person would prefer a Step 3 resolution versus a Step 2
> resolution.

I disagree with this last statement. Many sane people would prefer going
straight to step3. Mainly b/c it is easier. think about it - if you
don't have to lug around years of legacy it is much less work.

It's the difference b/t fixing something old and buying a new one.

Step 3 is a consumable society solution.
Steps 1 and 2 are about keeping older systems working while slowly
migrating to newer solutions.

Step 3 is an artifact of a generation (of which I am one) raised to
believe it is better to buy a new one than to fix the old one. But it is
not insane, let's be clear, it is very sane in that it is the path of
least resistance in terms of maintenance. The problems is it is not
sustainable when you're trying to make things work for a user/developer
community that is as diverse  as ours is.

-sv




From alan at redhat.com  Wed Oct 29 17:40:20 2008
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Oct 2008 13:40:20 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE0109214A@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE0109214A@catoexm05.noam.corp.platform.com>
Message-ID: <20081029174020.GD3042@shell.devel.redhat.com>

On Wed, Oct 29, 2008 at 09:29:54AM -0700, Shawn Starr wrote:
> It is a regression.  Why in heck would switching from from tty0 to tty1 I see X then switch to tty2 see console again? There's a good reason for it being on tty7, so it's out ot the fscking (especially when X CRASHES on VT switch back to X :P [See ATI, composite mess and all that jazz]).

tty1 is the first tty. tty0 is an alias for "the current console"



From dkelson at gurulabs.com  Wed Oct 29 17:41:37 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 11:41:37 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810290932m252c8a28pca37156ac252d5bb@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
	<gea202$mbt$1@ger.gmane.org>
	<604aa7910810290932m252c8a28pca37156ac252d5bb@mail.gmail.com>
Message-ID: <1225302097.3846.74.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 08:32 -0800, Jeff Spaleta wrote:
> On Wed, Oct 29, 2008 at 8:11 AM, Matthew Woehlke
> > it don't appear to care about the objections; they're not responding
> > intelligently to them,
> 
> I don't have an intelligent response to any argument which essentially
> comes down to "tradition."  Have the traditionalists pulled put forth
> any consensus document like an RFC to support that at some point in
> time a group of people actually talk through the need for doing gettys
> a certain way?
> 
> Traditions which codify a collection of arbitrary decisions..are
> traditions I will gladly help throw into the fire.

Jef,

Not you too. My arguments are NOT "essentially" tradition. One of my 9
distinct arguments was Fedora becomes inconsistent with itself.

Another was that Fedora becomes incompatible with other Linux
distributions. Do we really want to go down the path where we have to
have "Fedora experts", "SUSE experts, "Ubuntu experts", etc and there is
no such thing as a "Linux expert"? That were the path of frivolous
incompatibilities leads.

The shepherds of the the various Linux distros should keep this in mind.
Their own distribution doesn't exist in a vacuum. If if they don't
use/work on other distributions, their users do.

Dax Kelson
Guru Labs



From walters at verbum.org  Wed Oct 29 17:42:16 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 13:42:16 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225300836.3846.49.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
Message-ID: <faa16b610810291042h25cd69b3rf2488bcb901a886d@mail.gmail.com>

On Wed, Oct 29, 2008 at 1:20 PM, Dax Kelson <dkelson at gurulabs.com> wrote:
>
> Most (all?) of the technologies you mentioned are cross-distribution.
> Everybody switched, compatibility across distributions was maintained.

Right, because it was driven by the desktop, which besides the kernel
is the only point of technology sharing between vendors that we have.
Everything in between distributions tend to reinvent in their own
little sandbox, which is a tendency we have to fight strongly.

If you like, we can make GDM depend on plymouth =)



From daryll at daryll.net  Wed Oct 29 17:43:16 2008
From: daryll at daryll.net (Daryll Strauss)
Date: Wed, 29 Oct 2008 10:43:16 -0700
Subject: Oops. F10 Beta ate my laptop
In-Reply-To: <4c4ba1530810291034r42d499fcna28d804236f11c26@mail.gmail.com>
References: <55668b8c0810291023p1e337da1v326c36c3e8255ef0@mail.gmail.com>
	<4c4ba1530810291034r42d499fcna28d804236f11c26@mail.gmail.com>
Message-ID: <55668b8c0810291043w568166a2pf9cfa3957b82bc87@mail.gmail.com>

You are correct kind Sir. Once I hit the space bar quickly enough to catch
grub, I went back to kernel 51 and it boots just fine. I need to make sure I
save that one! Thanks for the help and speedy reply.

- |Daryll

On Wed, Oct 29, 2008 at 10:34 AM, Tom London <selinux at gmail.com> wrote:

>
>
> See this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=468856
>
> Believe there is an issue with the Rawhide mkinird and encrypted disk
> partitions.
>
> If you have a previous kernel, you should be able to boot with that.
>
> BZ describes reverting mkinitrd and rebuilding the initrd, but I
> suspect a "fix" is in the works.
>
> Hope this helps.
>
> tom
> --
> Tom London
>
> --
> 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/20081029/c0489689/attachment.htm>

From sstarr at platform.com  Wed Oct 29 17:44:16 2008
From: sstarr at platform.com (Shawn Starr)
Date: Wed, 29 Oct 2008 10:44:16 -0700
Subject: X on tty1 in Rawhide/F10
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499A60@catoexm05.noam.corp.platform.com>

> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Alan Cox
> Sent: Wednesday, October 29, 2008 1:40 PM
> To: Development discussions related to Fedora
> Subject: Re: X on tty1 in Rawhide/F10
> 
> 
> On Wed, Oct 29, 2008 at 09:29:54AM -0700, Shawn Starr wrote:
> > It is a regression.  Why in heck would switching from from 
> tty0 to tty1 I see X then switch to tty2 see console again? 
> There's a good reason for it being on tty7, so it's out ot 
> the fscking (especially when X CRASHES on VT switch back to X 
> :P [See ATI, composite mess and all that jazz]).
> 
> tty1 is the first tty. tty0 is an alias for "the current console"

Nevermind...nothing to see here...

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 



From jspaleta at gmail.com  Wed Oct 29 17:47:18 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 09:47:18 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225300836.3846.49.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
Message-ID: <604aa7910810291047h44a44c7flf4e704d374417c67@mail.gmail.com>

On Wed, Oct 29, 2008 at 9:20 AM, Dax Kelson <dkelson at gurulabs.com> wrote:
> Most (all?) of the technologies you mentioned are cross-distribution.

Believe what you want.  Different distros pick up different technology
changes at different times.  They do not all move as a block.
PolicyKit and its authorization concepts being a current area where we
lead the integration and we are breaking established traditional
practises to get to something better. PolicyKit still blows my mind I
haven't really figure out how to work with it as an admin. I'm still
getting comfortable with how to script interaction with HAL and DBUS
to deal with removable devices as an admin and not a user.  Far more
disruptive and more important than dickering over what vt anything
defaults to appearing on.

the cross distro tty behavior issue with regard to tty initialization
is a FANTASY. Its is concensus by inaction and a lack of discussion.
People took an arbitrary inittab example and have propagated
it..mindlessly. No attempt at cross-distribution standardization
addresses this as an expectation on behavior.

jef"At some point...all phones were rotary dial..until someone made a
push button phone. Dear god, my fingers have to move in a completely
different pattern to do get exactly the same work done.....that's
incompatible...think of the children....down with push button
phones!"spaleta



From jspaleta at gmail.com  Wed Oct 29 17:50:31 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 09:50:31 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225300860.3897.398.camel@beck.corsepiu.local>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
Message-ID: <604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>

On Wed, Oct 29, 2008 at 9:21 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> You will likely comprehend the absurdity of this proposal when X server
> races the next time.

As a user...wtf do I know about a race condition?

As a tester...im going to turn on a going to turn on gettys no matter
what the defaults are.
where the getty is..is arbitrary...for my needs to interact with it.

As an admin....serial consoles are great.

-jef



From cmadams at hiwaay.net  Wed Oct 29 17:52:38 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 29 Oct 2008 12:52:38 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029173242.GC3042@shell.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225283804.7036.73.camel@jg-vaio>
	<1225284400.23396.23.camel@nibbler.dlib.indiana.edu>
	<20081029173242.GC3042@shell.devel.redhat.com>
Message-ID: <20081029175238.GB1371252@hiwaay.net>

Once upon a time, Alan Cox <alan at redhat.com> said:
> Because it was the number of getty tasks someone had in the example inittab
> for SysVInit I suspect. It is useful to have a couple even for debug hiding
> where you can direct a user but the number is arbitary and the fact X happens
> to be VT7 is just a further arbitary fallout from this.

I think 6 gettys goes back before SysVInit, maybe to SLS.

I used to boot in level 3, log in on tty1, and run startx to get X, but
I stopped doing that years ago.  However, from that time, on the rare
occasions I need a text console while in X, I switch to tty2, not tty1.
On my servers with serial consoles, I typically disable most of the
console gettys anyway.

Didn't somebody have an on-demand console daemon for Linux at some
point?  You'd just run it, and when someone switched to a new VT where
nothing was running, it would start a getty.  I always thought that
would be much better than an arbitrary 6.

I don't see this as a big deal.  I've been using X since before Linux
existed, and I just see non-X ttys (on a system running X) as an extra
thing (none of the other systems I've used X on support that; the
console is either text or X, not both).

The argument appears to be coming from a (very!) vocal minority (what
percentage of Fedora users are on this list, and what percentage of list
members are objecting?).  The vast majority of users have no idea or
care about VT switching in my experience and will not care that X
switched from one tty to another (if you tried to explain it to them,
you'd just get blank stares).  If it speeds up the boot process and
causes less flicker and monitor reset (which does disconcert regular
users), they'll be happy.

As for the argument that speeding up boot and making the boot smoother
is meaningless because you should never need to reboot, there are still
a lot of users that have to dual-boot.  Speeding up boot (and shutdown!)
is a good thing for them.

A better solution to this issue of "where is my X or text tty" would be
to allow console managers to register for a different set of keystrokes;
e.g. gettys could register for [CTRL-]ALT-F<1,2,...> and X for
[CTRL-]ALT-<1,2,...> (or something like that).  The first getty to
register would get F1 and the first X to register would get 1.

-- 
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 dkelson at gurulabs.com  Wed Oct 29 18:02:23 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 12:02:23 -0600
Subject: A suggestion regarding new features
In-Reply-To: <1225301505.21485.65.camel@rosebud>
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
	<1225301505.21485.65.camel@rosebud>
Message-ID: <1225303343.3846.91.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 13:31 -0400, seth vidal wrote:
> On Wed, 2008-10-29 at 11:15 -0600, Dax Kelson wrote:
> 
> > Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST
> > PLACE.
> > 
> > Many people have voiced concerns that to many $NEWFEATURES are going
> > straight to Step 3 without exploring a Step 1 or Step 2 resolution. 
> > 
> > No sane person would prefer a Step 3 resolution versus a Step 2
> > resolution.
> 
> I disagree with this last statement. Many sane people would prefer going
> straight to step3. Mainly b/c it is easier. think about it - if you
> don't have to lug around years of legacy it is much less work.
> 
> It's the difference b/t fixing something old and buying a new one.
> 
> Step 3 is a consumable society solution.
> Steps 1 and 2 are about keeping older systems working while slowly
> migrating to newer solutions.
> 
> Step 3 is an artifact of a generation (of which I am one) raised to
> believe it is better to buy a new one than to fix the old one. But it is
> not insane, let's be clear, it is very sane in that it is the path of
> least resistance in terms of maintenance. The problems is it is not
> sustainable when you're trying to make things work for a user/developer
> community that is as diverse  as ours is.

You are right. To clarify, it is based on your role/perspective. 

Going straight to step 3 is sane from the perspective of the developer
saving time. However, there are many circumstances where doing a Step 1
or Step 2 is NOT a herculean carry-atlas-on-your-shoulders effort. Often
it is very minor. The developer time is spent once, the user/sys admin
time is spent over and over again.

I'm not sure you are arguing to always go Step 3, but if you are, not
all developers agree with you. Apparently some care about user/sys admin
time. Consider the adoption of rsyslog (a Step 2 solution) over
syslog-ng (Step 3).

I would prefer if the shepherds of my distribution of choice didn't
treat it as a consumable.

There are costs to incompatibility and needless churn that may not be
obvious on first glance.

Dax Kelson
Guru Labs



From dkelson at gurulabs.com  Wed Oct 29 18:06:13 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 12:06:13 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810291047h44a44c7flf4e704d374417c67@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
	<604aa7910810291047h44a44c7flf4e704d374417c67@mail.gmail.com>
Message-ID: <1225303573.3846.94.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 09:47 -0800, Jeff Spaleta wrote:
> On Wed, Oct 29, 2008 at 9:20 AM, Dax Kelson <dkelson at gurulabs.com> wrote:
> > Most (all?) of the technologies you mentioned are cross-distribution.

> 
> the cross distro tty behavior issue with regard to tty initialization
> is a FANTASY. Its is concensus by inaction and a lack of discussion.
> People took an arbitrary inittab example and have propagated
> it..mindlessly. No attempt at cross-distribution standardization
> addresses this as an expectation on behavior.

How the behavior arrived is, for the most part, irrelevant. We have what
we have. Don't break it NEEDLESSLY.

Dax Kelson
Guru Labs



From zaitcev at redhat.com  Wed Oct 29 18:08:00 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 29 Oct 2008 12:08:00 -0600
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49075429.1040508@shmuelhome.mine.nu>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<49075429.1040508@shmuelhome.mine.nu>
Message-ID: <20081029120800.ac164a32.zaitcev@redhat.com>

On Tue, 28 Oct 2008 20:04:25 +0200, shmuel siegel <fedora at shmuelhome.mine.nu> wrote:

> There were also many alternatives mentioned in this thread. And reasons 
> were given as to why this change is a bad idea. [...]

I haven't seen a single one so far. Granted, I only skimmed the
flamewar, looking at messages to which people with clue replied.

-- Pete



From dkelson at gurulabs.com  Wed Oct 29 18:09:27 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 12:09:27 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029175238.GB1371252@hiwaay.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225283804.7036.73.camel@jg-vaio>
	<1225284400.23396.23.camel@nibbler.dlib.indiana.edu>
	<20081029173242.GC3042@shell.devel.redhat.com>
	<20081029175238.GB1371252@hiwaay.net>
Message-ID: <1225303767.3846.97.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 12:52 -0500, Chris Adams wrote:

> The argument appears to be coming from a (very!) vocal minority (what
> percentage of Fedora users are on this list, and what percentage of list
> members are objecting?).  The vast majority of users have no idea or
> care about VT switching in my experience and will not care that X
> switched from one tty to another (if you tried to explain it to them,
> you'd just get blank stares).  If it speeds up the boot process and
> causes less flicker and monitor reset (which does disconcert regular
> users), they'll be happy.
> 
> As for the argument that speeding up boot and making the boot smoother
> is meaningless because you should never need to reboot, there are still
> a lot of users that have to dual-boot.  Speeding up boot (and shutdown!)
> is a good thing for them.

Chris,

The problem is that we can have both. Let's all eat cake! This change of
X's VT is un-needed. 

Dax Kelson
Guru Labs



From skvidal at fedoraproject.org  Wed Oct 29 18:11:12 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 14:11:12 -0400
Subject: A suggestion regarding new features
In-Reply-To: <1225303343.3846.91.camel@mentor.gurulabs.com>
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
	<1225301505.21485.65.camel@rosebud>
	<1225303343.3846.91.camel@mentor.gurulabs.com>
Message-ID: <1225303872.21485.69.camel@rosebud>

On Wed, 2008-10-29 at 12:02 -0600, Dax Kelson wrote:

> You are right. To clarify, it is based on your role/perspective. 
> 
> Going straight to step 3 is sane from the perspective of the developer
> saving time. However, there are many circumstances where doing a Step 1
> or Step 2 is NOT a herculean carry-atlas-on-your-shoulders effort. Often
> it is very minor. The developer time is spent once, the user/sys admin
> time is spent over and over again.
> 
> I'm not sure you are arguing to always go Step 3, but if you are, not
> all developers agree with you. Apparently some care about user/sys admin
> time. Consider the adoption of rsyslog (a Step 2 solution) over
> syslog-ng (Step 3).
> 

I'm not arguing to always go to step 3. I'm explaining how it is not
INSANE. 
I'm mostly trying to make sure that the arguments made for and against
changes here are phrased so everyone understands one another. If we
cannot understand one another than we're not going to be able to figure
this out.

> I would prefer if the shepherds of my distribution of choice didn't
> treat it as a consumable.

I agree with your preference. A userbase and institutional knowledge
about a platform are not consumables. They are hard to produce and hard
to replicate.



> There are costs to incompatibility and needless churn that may not be
> obvious on first glance.

Agreed.

-sv




From zaitcev at redhat.com  Wed Oct 29 18:12:23 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 29 Oct 2008 12:12:23 -0600
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225208387.3897.88.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
Message-ID: <20081029121223.92fdcdcf.zaitcev@redhat.com>

On Tue, 28 Oct 2008 16:39:47 +0100, Ralf Corsepius <rc040203 at freenet.de> wrote:

> Time to evaluate other distros.

I am quaking in my boots.

The old behaviour was retarded, an appendix from the times when
X was an afterthought.

-- Pete



From bdwheele at indiana.edu  Wed Oct 29 18:13:03 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 14:13:03 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225301630.3846.66.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
Message-ID: <1225303983.23396.82.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 11:33 -0600, Dax Kelson wrote:
> On Wed, 2008-10-29 at 08:26 -0400, Brian Wheeler wrote:
> > I'm going to agree with the -1.  
> > 
> > Almost all of the "reasons" from the original email boil down to "we've
> > always done it this way".  
> 
> Absolute not! I gave 9 distinct, independent reasons. Only one of which
> was regarding tradition.
> 
> Listen, it's easy to win arguments if you rephrase/restate all the
> opposing arguments into one straw man.
> 

Ok, lets go through them.

Your first one is the tradition argument.

So is the second one ("developers should tread respectfully in such
hallowed places")

The third one is documentation.  That's a fair argument, but its not
insurmountable.  I can't think of any of the linux books/faqs/etc I've
used over the last 15 years that haven't become out of date at least
partially...and usually fairly quickly.

The fourth is "no other distros are doing this" is kind of a tradition
argument, but its also a compatibility issue.  There are all kinds of
differences between the distros, so I'm not sure how this advances your
argument that it shouldn't change. 

Fifth argument is just documentation (again) combined with the one
above.

The 6th argument is dealing with a non-standard startup.  When you don't
use the defaults, all bets are off.

The 7th is "nobody should care what tty X is on".  Indeed, why are
people so upset that it has changed?  Its not an argument for or
against, its an argument that this thread shouldn't be taking place at
all.

Eighth is tradition again.  "experienced users will try..."

Ninth is fast user switching.  Interesting side effect, but with
"argument 7" its moot.  Who cares if the 2nd user display is on tty7?

Tenth is "switching to vt7 causes no flicker".  Switching VTs takes
time, even if the flicker is not present.  Its not an argument, so much
as its a workaround.  Its a workaround with a (time) cost.


So, it boils down to tradition, documentation, and compatibility with
other distros.

Tradition is important, but I'd vote that a faster, flicker-free startup
trumps it.

Documentation is also important, but it is just documentation.  The move
from SysV Init is far more in-depth than the X vt thingy.

Compatibility isn't a driving priority, especially for something that's
low-level and used primarily by those who've been around for a long
time...


*shrug* 

I don't really get why there's so much anger about this change.  I
booted the rawhide and was very impressed by the speed of the startup
(as well as lack of flicker/monitor resync time).  It seems like a
reasonable trade off.  

Brian







From lesmikesell at gmail.com  Wed Oct 29 18:16:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 13:16:23 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029175238.GB1371252@hiwaay.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<1225283804.7036.73.camel@jg-vaio>	<1225284400.23396.23.camel@nibbler.dlib.indiana.edu>	<20081029173242.GC3042@shell.devel.redhat.com>
	<20081029175238.GB1371252@hiwaay.net>
Message-ID: <4908A877.9080805@gmail.com>

Chris Adams wrote:

> The vast majority of users have no idea or
> care about VT switching in my experience and will not care that X
> switched from one tty to another (if you tried to explain it to them,
> you'd just get blank stares).

The reason those people don't need to care about vt's is that they'll go 
to whoever recommended linux to them in the first place if they have a 
problem with X.  And those are the people who care about consistency.

> If it speeds up the boot process and
> causes less flicker and monitor reset (which does disconcert regular
> users), they'll be happy.

But it doesn't - the flicker is caused by switching modes at the wrong time.

> As for the argument that speeding up boot and making the boot smoother
> is meaningless because you should never need to reboot, there are still
> a lot of users that have to dual-boot.  Speeding up boot (and shutdown!)
> is a good thing for them.

And they'd probably  be better off with VMware instead, running 
whichever OS handles sleeping better as the host.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Wed Oct 29 18:18:15 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 13:18:15 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>	<49081A53.1050504@leemhuis.info>	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
Message-ID: <4908A8E7.20604@gmail.com>

Jeff Spaleta wrote:
> On Wed, Oct 29, 2008 at 9:21 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> You will likely comprehend the absurdity of this proposal when X server
>> races the next time.
> 
> As a user...wtf do I know about a race condition?
> 
> As a tester...im going to turn on a going to turn on gettys no matter
> what the defaults are.
> where the getty is..is arbitrary...for my needs to interact with it.
> 
> As an admin....serial consoles are great.

As an admin you likely have the option of ssh'ing in from a different 
machine in case the console hardware is broken.

-- 
   Les Mikesell
     lesmikesell at gmail.com




From zaitcev at redhat.com  Wed Oct 29 18:22:51 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 29 Oct 2008 12:22:51 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225300836.3846.49.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
Message-ID: <20081029122251.80c75d94.zaitcev@redhat.com>

On Wed, 29 Oct 2008 11:20:36 -0600, Dax Kelson <dkelson at gurulabs.com> wrote:

> Most (all?) of the technologies you mentioned are cross-distribution.
> Everybody switched, compatibility across distributions was maintained.
> Books and brains were free to drop the old ways and just document and
> learn the new ways.

Actually I'm pretty certain everyone is going to move to tty1 once
benefits are realized. The kernel modesetting and graphical boot
are not exclusive to Fedora.

-- Pete



From skvidal at fedoraproject.org  Wed Oct 29 18:35:41 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 14:35:41 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <faa16b610810291042h25cd69b3rf2488bcb901a886d@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
	<faa16b610810291042h25cd69b3rf2488bcb901a886d@mail.gmail.com>
Message-ID: <1225305341.21485.72.camel@rosebud>

On Wed, 2008-10-29 at 13:42 -0400, Colin Walters wrote:
> On Wed, Oct 29, 2008 at 1:20 PM, Dax Kelson <dkelson at gurulabs.com> wrote:
> >
> > Most (all?) of the technologies you mentioned are cross-distribution.
> > Everybody switched, compatibility across distributions was maintained.
> 
> Right, because it was driven by the desktop, which besides the kernel
> is the only point of technology sharing between vendors that we have.
> Everything in between distributions tend to reinvent in their own
> little sandbox, which is a tendency we have to fight strongly.
> 

Seriously? Daemons like Apache/Dovecot/postfix/xmpp, etc? the service
startup interfaces? Packaging standards? None of these are desktop or
kernel but there is remarkable consistency b/t distros thanks to things
like the FHS and common use.

-sv




From fenn at stanford.edu  Wed Oct 29 18:37:35 2008
From: fenn at stanford.edu (Tim Fenn)
Date: Wed, 29 Oct 2008 11:37:35 -0700
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
Message-ID: <20081029113735.140c599c@atbws1.stanford.edu>

On Wed, 29 Oct 2008 07:11:43 -0500 (CDT) "Jon Ciesla"
<limb at jcomserv.net> wrote:

> 
> > With a good chunk of help, I now have fedora builds of pymol
> > available (see bugzilla ID 462251 for the full details). However,
> > I'd like to have some help with building/testing for EL5, as I'd
> > like to make it available but don't have an EL box to explicitly
> > test on.
> 
> 
> Found it from the review.
> 
> Build error:
> 
> + desktop-file-install
> --dir=/var/tmp/pymol-1.1-10.20081015svn3468-root-jciesla/usr/share/applications
> /home/jciesla/rpmbuild/SOURCES/pymol.desktop
> Must specify the vendor namespace for these files with --vendor
> error: Bad exit status from /var/tmp/rpm-tmp.25017 (%install)
> 

Right, I'd guess the build will be successful with a simple
--vendor=fedora tag?

Once it successfully builds and installs OK, try opening the program and
running a few demos (wizard->demo->whatever), rotating/translating
objects with the mouse - that should be sufficient to ensure proper
operation.

Thanks for the help,

Tim

-- 
CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS



From smooge at gmail.com  Wed Oct 29 18:29:44 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 29 Oct 2008 12:29:44 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225293850.5412.181.camel@vorpal.macdev.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
	<1225293850.5412.181.camel@vorpal.macdev.com>
Message-ID: <80d7e4090810291129y148a4234y199a9da31c617817@mail.gmail.com>

On Wed, Oct 29, 2008 at 9:24 AM, David G. Mackay <mackay_d at bellsouth.net> wrote:
>
> On Wed, 2008-10-29 at 08:51 -0400, seth vidal wrote:
>> There's no one working in computing today ANYWHERE who is doing
>> revolutionary work. I'd argue there is no such thing as revolutionary
>> work AT ALL. Stop looking for it where it is not.
>
> What about quantum computing?  A fundamental paradigm shift seems like
> it ought to count.
>

quantum computing is more like going back to analog computing from the
1940's. In the end, it will be masked by a lot of stuff that makes it
seem like its digital because cultures are change averse... thats a
reason why cultures exist.. to help preserve memory over a constantly
changing universe. When you arbitrarily change something 'fundamental'
to a culture you get a reaction in the opposite way.. the reaction is
usually dis appropriately stronger than the original change because
people are wired to maintain culture for survival.

The important thing is that individuals usually do not hold the same
things to be fundamental as other individuals. Changing the TTY
affects some people who work there a lot more than those who never use
it.. but it might also affect someone who has it in the root of their
soul: "If my computer is fucked-up, CNTRL-ALT-F1 to try and get it
back." Changing a bed-rock principle that is pretty much in every
chapter 1 linux book is a BIG deal and not something that can be
washed over with a couple of emails. Most of the wars during the
Reformation were started over smaller things.

Does this mean the change can't happen? No it just means that you need
to be aware that you need to build a cultural consensus.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From dkelson at gurulabs.com  Wed Oct 29 18:42:45 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 12:42:45 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029122251.80c75d94.zaitcev@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
	<20081029122251.80c75d94.zaitcev@redhat.com>
Message-ID: <1225305765.3846.113.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 12:22 -0600, Pete Zaitcev wrote:
> On Wed, 29 Oct 2008 11:20:36 -0600, Dax Kelson <dkelson at gurulabs.com> wrote:
> 
> > Most (all?) of the technologies you mentioned are cross-distribution.
> > Everybody switched, compatibility across distributions was maintained.
> > Books and brains were free to drop the old ways and just document and
> > learn the new ways.
> 
> Actually I'm pretty certain everyone is going to move to tty1 once
> benefits are realized. The kernel modesetting and graphical boot
> are not exclusive to Fedora.
> 
> -- Pete

So far we've had a defacto standard that people have come to rely on. It
would be horrible disservice to Linux as a whole if all the distros went
their separate ways.

Is there a mailing list or infrastructure where the shepherds of various
distros can discuss a major changes for the sake of compatibility? If
not, there should be.

Dax Kelson
Guru Labs



From jspaleta at gmail.com  Wed Oct 29 18:45:43 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 10:45:43 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225305765.3846.113.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
	<20081029122251.80c75d94.zaitcev@redhat.com>
	<1225305765.3846.113.camel@mentor.gurulabs.com>
Message-ID: <604aa7910810291145x393573f4g55d987080d7fc044@mail.gmail.com>

On Wed, Oct 29, 2008 at 10:42 AM, Dax Kelson
> Is there a mailing list or infrastructure where the shepherds of various
> distros can discuss a major changes for the sake of compatibility? If
> not, there should be.


I take exception to the idea that a line edit in a config file like
inittab...to change default behavior..constitutes a major change.

-jef



From cdahlin at redhat.com  Wed Oct 29 18:47:51 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 14:47:51 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225233489.3897.244.camel@beck.corsepiu.local>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>	<1225187670.5969.6.camel@localhost.localdomain>	<4906FA43.4050902@odu.neva.ru>	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>	<49071741.30003@shmuelhome.mine.nu>	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>	<4907267D.6030209@shmuelhome.mine.nu>	<20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>	<1225216493.2157.68.camel@luminos.localdomain>	<49075429.1040508@shmuelhome.mine.nu>	<1225218581.2157.87.camel@luminos.localdomain>
	<1225233489.3897.244.camel@beck.corsepiu.local>
Message-ID: <4908AFD7.90709@redhat.com>

Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 11:29 -0700, Jesse Keating wrote:
>   
>> On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
>>     
>>> There were also many alternatives mentioned in this thread. And reasons 
>>> were given as to why this change is a bad idea. I haven't seen any 
>>> response to the alternatives. The typical response to the objections 
>>> were either "don't start a flame war" or "who cares about your use 
>>> case". Is feedback wanted?
>>>       
>> well this thread has gone pretty out of control, so any chance of
>> getting the people who were actually doing the work to look in on it is
>> probably not going to happen.
>>     
> Understood, the almighty RHs knows better, the community is dumb :(
>
>   
You know these kinds of conspiracy delusions are associated with some 
forms of schizophrenia.

--CJD



From sundaram at fedoraproject.org  Wed Oct 29 18:47:05 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Oct 2008 00:17:05 +0530
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225305765.3846.113.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>	<49081A53.1050504@leemhuis.info>	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>	<1225300836.3846.49.camel@mentor.gurulabs.com>	<20081029122251.80c75d94.zaitcev@redhat.com>
	<1225305765.3846.113.camel@mentor.gurulabs.com>
Message-ID: <4908AFA9.8030607@fedoraproject.org>

Dax Kelson wrote:

> Is there a mailing list or infrastructure where the shepherds of various
> distros can discuss a major changes for the sake of compatibility? If
> not, there should be.

http://lists.freedesktop.org/mailman/listinfo/distributions

Rahul



From mw_triad at users.sourceforge.net  Wed Oct 29 18:50:41 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 13:50:41 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
Message-ID: <geaba1$t2c$1@ger.gmane.org>

Brian Wheeler wrote:
> I don't really get why there's so much anger about this change.

At least in my case, it's not so much about the change, as the way it's 
been handled... Ignore or bury dissenting opinions, ignore suggestions 
at compromise, and attack the dissenters as "minority" / "unimportant". 
And that this attitude is starting to feel like a trend.

I'll also grant that for the majority, it's probably hard to understand 
why a minority group feels oppressed :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From kwhiskerz at gmail.com  Wed Oct 29 18:57:50 2008
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Wed, 29 Oct 2008 12:57:50 -0600
Subject: 2 ext4 queries
Message-ID: <geabnf$ugs$1@ger.gmane.org>

1. Is it safe to use ext4 for important data? I Do mean ext4, not ext4dev.

2. Will a partition formatted as ext4 need to be reformatted down the road, as ext4 matures, or will one presently formatted as ext4 house the data correctly and in accord with future enhancements to ext4?



From pertusus at free.fr  Wed Oct 29 19:00:47 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 29 Oct 2008 20:00:47 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225305765.3846.113.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
	<20081029122251.80c75d94.zaitcev@redhat.com>
	<1225305765.3846.113.camel@mentor.gurulabs.com>
Message-ID: <20081029190047.GA2670@free.fr>

On Wed, Oct 29, 2008 at 12:42:45PM -0600, Dax Kelson wrote:
> 
> So far we've had a defacto standard that people have come to rely on. It
> would be horrible disservice to Linux as a whole if all the distros went
> their separate ways.
> 
> Is there a mailing list or infrastructure where the shepherds of various
> distros can discuss a major changes for the sake of compatibility? If
> not, there should be.

There is a mailing list where people from all the distros gather:
distributions at lists.freedesktop.org

--
Pat



From dkelson at gurulabs.com  Wed Oct 29 19:01:11 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 13:01:11 -0600
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <1225295713.1783.5.camel@luminos.localdomain>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<1225187670.5969.6.camel@localhost.localdomain>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<49071741.30003@shmuelhome.mine.nu>
	<91705d080810280649t7b7ee78dsb583df01cd1941c4@mail.gmail.com>
	<4907267D.6030209@shmuelhome.mine.nu>
	<20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<4908337A.5030705@redhat.com>
	<1225295713.1783.5.camel@luminos.localdomain>
Message-ID: <1225306871.3846.118.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 08:55 -0700, Jesse Keating wrote:
> On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
> > Shouldn't be a big deal though, if plymouth does that vt
> > switch right after KMS entered graphics mode and before printing
> > anything on the screen it should went unnoticed.
> 
> Good explanation, except that KMS only works for a very limited set of
> ATI graphics cards, and nowhere else.
> 

Jesse,

While that is the current state, it isn't the final state. The goal is
have KMS eventually work on all/nearly all cards. Don't dismiss Gerd's
suggestion based on the current state.

Dax Kelson
Guru Labs



From sgrubb at redhat.com  Wed Oct 29 19:02:11 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 29 Oct 2008 15:02:11 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
Message-ID: <200810291502.11358.sgrubb@redhat.com>

On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
> We have kernel support for storing capabilities on filesystem since 2.6.24
> and recent libcap, both in F9 already.

And we have also been busy updating everything else to support this:

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


> I just committed file capability support to rpm.org HEAD, filling in the
> final(?) missing piece. Capability support is not going to be in rpm 4.6.0
> but no reason they can't be pulled into 4.6.1 which is easily in F11
> timeframe. 

We tried to support this in F-10 by having a test run with ping. We figured 
that is a simple well defined app that could be used as a test subject. We 
opened bz 455713 to document the change over. Turns out that people compile 
their own kernels and do not necessarily turn this on. So, what do we do in 
that case?


> Are we ready to start considering moving away from SUID bits to
> capabilities, in Fedora 11 maybe?

We tried and got turned back. How does rpm work on kernels that do not support 
file capabilities? I'd like to see us get past the initial objections so that 
we can start removing some of the setuid bits.

-Steve



From jspaleta at gmail.com  Wed Oct 29 19:00:33 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 11:00:33 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <490898B1.8080000@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<490898B1.8080000@gmail.com>
Message-ID: <604aa7910810291200w20c6bcf2kba93e26bdb82a264@mail.gmail.com>

On Wed, Oct 29, 2008 at 9:09 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Doing that to reduce memory/process overhead would actually be the only real
> justification that I've seen so far for making a change like this (as
> opposed to switching vt's earlier so you can fade in the mode change).

Care to generate the numbers on the difference with the gettys
completely off by default?


-jef



From sgrubb at redhat.com  Wed Oct 29 19:13:11 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 29 Oct 2008 15:13:11 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
Message-ID: <200810291513.11983.sgrubb@redhat.com>

On Wednesday 29 October 2008 12:53:16 Colin Walters wrote:
> > Are we ready to start considering moving away from SUID bits to
> > capabilities, in Fedora 11 maybe?
>
> Note that from the desktop direction we've been moving the OS away
> from exec-based domain transitions to message passing (e.g. PolicyKit)
> for a variety of reasons.

>From a security point of view...I don't like this at all. 

1) We've spent a lot of time on getting audit right. We can tell what account 
was logged in under and find every single application that was started as a 
result of that login. Message passing breaks this. 

2) There is no accountability for what actions are performed for each user. 
The audit system cannot tell who something was done for.

3) There is yet another MAC policy with no auditing of access decisions.

4) Setuid apps get special treatment from ld.so and other things so that 
certain actions cannot be performed like ptrace or LD_PRELOAD.

5) Setuid apps can be found quite easily and they are well known and well 
reviewed for bugs. If you want admin only use, its easy to take off the 
setuid bit.

-Steve



From dkelson at gurulabs.com  Wed Oct 29 19:13:34 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 13:13:34 -0600
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291502.11358.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
Message-ID: <1225307614.3846.126.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 15:02 -0400, Steve Grubb wrote:
> On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
> > We have kernel support for storing capabilities on filesystem since 2.6.24
> > and recent libcap, both in F9 already.
> 
> And we have also been busy updating everything else to support this:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=449984
> 
> 
> > I just committed file capability support to rpm.org HEAD, filling in the
> > final(?) missing piece. Capability support is not going to be in rpm 4.6.0
> > but no reason they can't be pulled into 4.6.1 which is easily in F11
> > timeframe. 
> 
> We tried to support this in F-10 by having a test run with ping. We figured 
> that is a simple well defined app that could be used as a test subject. We 
> opened bz 455713 to document the change over. Turns out that people compile 
> their own kernels and do not necessarily turn this on. So, what do we do in 
> that case?

Modify ping to work in either scenario. Get the patches accepted
upstream. This is not dissimilar from efforts of getting SELinux
integrated (init patches, -Z patches, etc).

Dax Kelson
Guru Labs



From benny+usenet at amorsen.dk  Wed Oct 29 19:13:58 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 29 Oct 2008 20:13:58 +0100
Subject: WPA without NetworkManager
In-Reply-To: <1225293777.1783.2.camel@luminos.localdomain> (Jesse Keating's
	message of "Wed\, 29 Oct 2008 08\:22\:57 -0700")
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<49087957.70905@gmail.com>
	<1225293777.1783.2.camel@luminos.localdomain>
Message-ID: <m3ljw7tds9.fsf@ursa.amorsen.dk>

Jesse Keating <jkeating at redhat.com> writes:

> However, if you're trying to boot iscsi via a wpa secured connection,
> perhaps you're doing it wrong?

iscsi on a 802.1x-secured port isn't quite so far-fetched.


/Benny



From sgrubb at redhat.com  Wed Oct 29 19:21:32 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 29 Oct 2008 15:21:32 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225307614.3846.126.camel@mentor.gurulabs.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<1225307614.3846.126.camel@mentor.gurulabs.com>
Message-ID: <200810291521.32293.sgrubb@redhat.com>

On Wednesday 29 October 2008 15:13:34 Dax Kelson wrote:
> > We tried to support this in F-10 by having a test run with ping. We
> > figured that is a simple well defined app that could be used as a test
> > subject. We opened bz 455713 to document the change over. Turns out that
> > people compile their own kernels and do not necessarily turn this on. So,
> > what do we do in that case?
>
> Modify ping to work in either scenario. 

Its not a ping issue, its an installation issue. :)   I can either chmod 4755 
or capset cap_net_raw=ep  during the installation. Upstream is not involved 
in this.

-Steve



From michael at laptop.org  Wed Oct 29 19:22:24 2008
From: michael at laptop.org (Michael Stone)
Date: Wed, 29 Oct 2008 15:22:24 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
Message-ID: <20081029192224.GD20573@didacte.laptop.org>

On Wed, Oct 29, 2008 at 12:53:16PM -0400, Colin Walters wrote:
>On Wed, Oct 29, 2008 at 6:37 AM, Panu Matilainen
><pmatilai at laiskiainen.org> wrote:
>>
>> Hate to interrupt the tty1 vs tty7 debate but...
>>
>> We have kernel support for storing capabilities on filesystem since 2.6.24
>> and recent libcap, both in F9 already. I just committed file capability
>> support to rpm.org HEAD, filling in the final(?) missing piece. Capability
>> support is not going to be in rpm 4.6.0 but no reason they can't be pulled
>> into 4.6.1 which is easily in F11 timeframe.
>>
>> Are we ready to start considering moving away from SUID bits to
>> capabilities, in Fedora 11 maybe?
>
>Note that from the desktop direction we've been moving the OS away
>from exec-based domain transitions to message passing (e.g. PolicyKit)
>for a variety of reasons.  

Colin,

Could you please suggest some links to your favorite writeups of those
reasons? Also, do you have data on what effect (if any) this trend has
on steady-state system memory consumption?

Thanks,

Michael



From bruno at wolff.to  Wed Oct 29 19:24:31 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 29 Oct 2008 14:24:31 -0500
Subject: Oops. F10 Beta ate my laptop
In-Reply-To: <55668b8c0810291043w568166a2pf9cfa3957b82bc87@mail.gmail.com>
References: <55668b8c0810291023p1e337da1v326c36c3e8255ef0@mail.gmail.com>
	<4c4ba1530810291034r42d499fcna28d804236f11c26@mail.gmail.com>
	<55668b8c0810291043w568166a2pf9cfa3957b82bc87@mail.gmail.com>
Message-ID: <20081029192431.GA29012@wolff.to>

On Wed, Oct 29, 2008 at 10:43:16 -0700,
  Daryll Strauss <daryll at daryll.net> wrote:
> You are correct kind Sir. Once I hit the space bar quickly enough to catch
> grub, I went back to kernel 51 and it boots just fine. I need to make sure I
> save that one! Thanks for the help and speedy reply.

Note that you don't need to stay on that kernel. That boot option works because
the initrd for that kernel was build with an older version of mkinitrd
(presumably when it was installed). You can use the older version of mkinitrd
to rebuilt the initrd for later kernels if you are interested in testing
them sooner rather than later.

If you have encryption over raid, then there is some tweaking to be done.



From walters at verbum.org  Wed Oct 29 19:25:15 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 15:25:15 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291513.11983.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
	<200810291513.11983.sgrubb@redhat.com>
Message-ID: <faa16b610810291225k4f77afc2o7d7dbb49f9948c63@mail.gmail.com>

On Wed, Oct 29, 2008 at 3:13 PM, Steve Grubb <sgrubb at redhat.com> wrote:
>
> 1) We've spent a lot of time on getting audit right. We can tell what account
> was logged in under and find every single application that was started as a
> result of that login. Message passing breaks this.

True, though how interesting is the question of "what binaries were
executed" as opposed to the system having enough intelligence to
display security-relevant information? Also:

> 2) There is no accountability for what actions are performed for each user.
> The audit system cannot tell who something was done for.

Should be easy to add such auditing; actually I think we do want to
have dbus audit on system activation regardless of PolicyKit.

> 3) There is yet another MAC policy with no auditing of access decisions.

Duplicate of 2)?

> 4) Setuid apps get special treatment from ld.so and other things so that
> certain actions cannot be performed like ptrace or LD_PRELOAD.

Right, but with message passing you don't have to worry about
ptrace/LD_PRELOAD and all the other problems inherent in a
parent-child exec relationship.

> 5) Setuid apps can be found quite easily and they are well known and well
> reviewed for bugs. If you want admin only use, its easy to take off the
> setuid bit.

It's actually quite a bit easier to review say PolicyKit mechanisms
for bugs because they don't have to worry about dropping privileges,
etc.  As for the sysadmin impact, yes, there is a concern there but
there is documentation:
http://hal.freedesktop.org/docs/PolicyKit/PolicyKit.conf.5.html


Anyways, I don't want to completely derail this discussion on fcap
into suid-vs-PolicyKit; using fcap for things like ping makes sense.
I just wanted to note that we would prefer upstream work to focus
around PolicyKit or a system-user daemon split like NetworkManager.



From cdahlin at redhat.com  Wed Oct 29 19:33:51 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 15:33:51 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <4908BA9F.6000301@redhat.com>

Dax Kelson wrote:
*snip*
> Uneeded and frivolous incompatibilities between Linux distros are
> particularly annoying to me on many levels. One practical reason is the
> bloat it causes in our courseware. The LSB is fine for developers who
> want to run binaries across multiple distributions, but Linux Sys Admins
> deserve something akin to the LSB that provides greater consistency at
> the Sys Admin level by removing squashing these frivolous
> incompatibilities. This is something that has been brewing in the back
> of my mind and I (using Guru Labs funding/resources and other interested
> parties) might tackle at some point.
>   
I don't really agree with your expectations of Linux as a whole.

This idea has come about that there is an operating system called Linux 
and there are many flavors of it called distros. This is not, IMHO, the 
case. There are many different operating systems, and they all happen to 
use the Linux kernel.

I don't expect Ubuntu to be any more compatible with Fedora than 
Windows. The two come out pretty similar only because we happen to agree 
on more than we disagree on (believe it or not), and because 
wheel-inventing costs effort, even if you think you can make a shinier one.

If somehow I could be transported 30 years into the future, and I could 
be sat down in front of Fedora, I'd be honestly disappointed if I 
recognized it. I don't much like the idea that all privileged operations 
are proxied through one all-capable and identityless account, and 
between /usr, /usr/local, and /opt I'm certain there is at least one too 
many places to put programs. Every single thing about this OS will 
change some day. We'll even switch kernels at some point if we last long 
enough (could be 50 years, could be 100) Drastic change is going to 
come, and its going to come to the disto that dares. And the rewards 
will be great.

--CJD



From lesmikesell at gmail.com  Wed Oct 29 19:33:00 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 14:33:00 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
Message-ID: <4908BA6C.5030806@gmail.com>

Brian Wheeler wrote:
>  
> The 7th is "nobody should care what tty X is on".  Indeed, why are
> people so upset that it has changed?  Its not an argument for or
> against, its an argument that this thread shouldn't be taking place at
> all.

How do you get back once you have switched to a text vt?

> Compatibility isn't a driving priority, especially for something that's
> low-level and used primarily by those who've been around for a long
> time...

Unless you'd like to keep those long time users.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mattdm at mattdm.org  Wed Oct 29 19:34:26 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 29 Oct 2008 15:34:26 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908BA6C.5030806@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
Message-ID: <20081029193426.GA24722@jadzia.bu.edu>

On Wed, Oct 29, 2008 at 02:33:00PM -0500, Les Mikesell wrote:
>>  The 7th is "nobody should care what tty X is on".  Indeed, why are
>> people so upset that it has changed?  Its not an argument for or
>> against, its an argument that this thread shouldn't be taking place at
>> all.
> How do you get back once you have switched to a text vt?

Hit alt-F* until you find where X is?

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From lesmikesell at gmail.com  Wed Oct 29 19:44:28 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 14:44:28 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029193426.GA24722@jadzia.bu.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<1225301630.3846.66.camel@mentor.gurulabs.com>	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>	<4908BA6C.5030806@gmail.com>
	<20081029193426.GA24722@jadzia.bu.edu>
Message-ID: <4908BD1C.6030501@gmail.com>

Matthew Miller wrote:
> On Wed, Oct 29, 2008 at 02:33:00PM -0500, Les Mikesell wrote:
>>>  The 7th is "nobody should care what tty X is on".  Indeed, why are
>>> people so upset that it has changed?  Its not an argument for or
>>> against, its an argument that this thread shouldn't be taking place at
>>> all.
>> How do you get back once you have switched to a text vt?
> 
> Hit alt-F* until you find where X is?
> 

Thanks, I would never have thought of that.  That will save lots of time.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sandeen at redhat.com  Wed Oct 29 19:44:47 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 29 Oct 2008 14:44:47 -0500
Subject: 2 ext4 queries
In-Reply-To: <geabnf$ugs$1@ger.gmane.org>
References: <geabnf$ugs$1@ger.gmane.org>
Message-ID: <4908BD2F.5010907@redhat.com>

Petrus de Calguarium wrote:
> 1. Is it safe to use ext4 for important data? I Do mean ext4, not ext4dev.

While ext4 is largely out of its development phase, it is still a
relatively new filesystem so you would do well (as you would with any
filesystem, to be honest) to test it in your environment before you
deploy it for real data, and keep good backups.

> 2. Will a partition formatted as ext4 need to be reformatted down the road, as ext4 matures, or will one presently formatted as ext4 house the data correctly and in accord with future enhancements to ext4?
> 

That's unlikely.  ext4 filesystems formatted today should always be
compatible with ext4 code in the future.  It is possible that newer
features will be added later which require different filesystem geometry
at mkfs time, but that situation will probably be rare.

-Eric



From walters at verbum.org  Wed Oct 29 19:33:32 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 15:33:32 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081029192224.GD20573@didacte.laptop.org>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
	<20081029192224.GD20573@didacte.laptop.org>
Message-ID: <faa16b610810291233w600231a3ve6a6249ca73c7a8a@mail.gmail.com>

On Wed, Oct 29, 2008 at 3:22 PM, Michael Stone <michael at laptop.org> wrote:

> Could you please suggest some links to your favorite writeups of those
> reasons?

The PolicyKit docs have some:
http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html

> Also, do you have data on what effect (if any) this trend has
> on steady-state system memory consumption?

That's a good question - I think with system activation by default
activated mechanisms will stay around, though obviously the kernel can
page them out.  The clock applet mechanism
(http://svn.gnome.org/svn/gnome-panel/trunk/applets/clock/gnome-clock-applet-mechanism.c)
has its own 30-second timeout but it's kind of a hack.  It's something
we should look at addressing - unfortunately just calling exit() after
30 seconds I believe creates race conditions, and to fix it correctly
will need special DBus support.  There was a thread a while ago about
this on the DBus list IIRC.



From walters at verbum.org  Wed Oct 29 19:33:32 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 15:33:32 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081029192224.GD20573@didacte.laptop.org>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
	<20081029192224.GD20573@didacte.laptop.org>
Message-ID: <faa16b610810291233w600231a3ve6a6249ca73c7a8a@mail.gmail.com>

On Wed, Oct 29, 2008 at 3:22 PM, Michael Stone <michael at laptop.org> wrote:

> Could you please suggest some links to your favorite writeups of those
> reasons?

The PolicyKit docs have some:
http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html

> Also, do you have data on what effect (if any) this trend has
> on steady-state system memory consumption?

That's a good question - I think with system activation by default
activated mechanisms will stay around, though obviously the kernel can
page them out.  The clock applet mechanism
(http://svn.gnome.org/svn/gnome-panel/trunk/applets/clock/gnome-clock-applet-mechanism.c)
has its own 30-second timeout but it's kind of a hack.  It's something
we should look at addressing - unfortunately just calling exit() after
30 seconds I believe creates race conditions, and to fix it correctly
will need special DBus support.  There was a thread a while ago about
this on the DBus list IIRC.



From lesmikesell at gmail.com  Wed Oct 29 19:59:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 14:59:23 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908BA9F.6000301@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com>
Message-ID: <4908C09B.6080609@gmail.com>

Casey Dahlin wrote:
>    
> I don't really agree with your expectations of Linux as a whole.
> 
> This idea has come about that there is an operating system called Linux 
> and there are many flavors of it called distros. This is not, IMHO, the 
> case. There are many different operating systems, and they all happen to 
> use the Linux kernel.

Maybe you don't remember it, but there was a time when there actually 
were a lot of different operating systems in use, and they had really 
annoying arbitrary differences.  Fortunately most of them died and the 
ones that continued converged on some standards.  Different Linux 
distributions are not different operating systems and they certainly 
can't claim to be that and at the same time have a mantra of 'upstream'.

> If somehow I could be transported 30 years into the future, and I could 
> be sat down in front of Fedora, I'd be honestly disappointed if I 
> recognized it.

You are imagining the wrong scenario. I'd like to avoid having to deal 
with all of the silly and meaningless changes that break things for the 
next 30 years too, but that's not going to happen.  The real world 
situation is that people have large and complex systems built around 
existing OS behavior whether formally standardized or just inherited 
from SysV that will break with program interface and device name 
changes, and there are large numbers of people to retrain for every user 
interface change.  Now, plan your next 30 years in the context of 
keeping things working through them instead of being magically 
transported past everything that breaks.  If you need to imagine 
something, imagine that your bank and credit card accounts are 
maintained on the OS you design and that the customer service people you 
call are trying to guess the latest user interface changes as they try 
to help you.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From bdwheele at indiana.edu  Wed Oct 29 19:59:48 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 15:59:48 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908BA6C.5030806@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
Message-ID: <1225310388.23396.99.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 14:33 -0500, Les Mikesell wrote:
> Brian Wheeler wrote:
> >  
> > The 7th is "nobody should care what tty X is on".  Indeed, why are
> > people so upset that it has changed?  Its not an argument for or
> > against, its an argument that this thread shouldn't be taking place at
> > all.
> 
> How do you get back once you have switched to a text vt?
> 

Alt-F1

or

chvt `ps -ef | perl -ne "if(m/Xorg/) { m/tty(\d+)/; print \$1; last;}"`

:)


> > Compatibility isn't a driving priority, especially for something that's
> > low-level and used primarily by those who've been around for a long
> > time...
> 
> Unless you'd like to keep those long time users.
> 

Well, I'm a long time user and I don't see what the big deal is.  There
are several people on this list which seem to announce that "<insert
change here> is the one that's going to drive long time users away"
and/or "time to look for a new distribution" semi-regularly... yet they
(long time users) are still here.

Brian

/Anyone else miss the threads when ESR was doing the shed painting?
/Me neither.



From mw_triad at users.sourceforge.net  Wed Oct 29 20:05:14 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 15:05:14 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<1225301630.3846.66.camel@mentor.gurulabs.com>	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
Message-ID: <geaflr$e29$1@ger.gmane.org>

Brian Wheeler wrote:
> Well, I'm a long time user and I don't see what the big deal is.  There
> are several people on this list which seem to announce that "<insert
> change here> is the one that's going to drive long time users away"
> and/or "time to look for a new distribution" semi-regularly... yet they
> (long time users) are still here.

Maybe they just haven't found anything better (yet)?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From limb at jcomserv.net  Wed Oct 29 20:06:26 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 29 Oct 2008 15:06:26 -0500 (CDT)
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <20081029113735.140c599c@atbws1.stanford.edu>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
Message-ID: <184a01e885d325a10895a8b90ce88207.squirrel@mail.jcomserv.net>

> On Wed, 29 Oct 2008 07:11:43 -0500 (CDT) "Jon Ciesla"
> <limb at jcomserv.net> wrote:
>
>>
>> > With a good chunk of help, I now have fedora builds of pymol
>> > available (see bugzilla ID 462251 for the full details). However,
>> > I'd like to have some help with building/testing for EL5, as I'd
>> > like to make it available but don't have an EL box to explicitly
>> > test on.
>>
>>
>> Found it from the review.
>>
>> Build error:
>>
>> + desktop-file-install
>> --dir=/var/tmp/pymol-1.1-10.20081015svn3468-root-jciesla/usr/share/applications
>> /home/jciesla/rpmbuild/SOURCES/pymol.desktop
>> Must specify the vendor namespace for these files with --vendor
>> error: Bad exit status from /var/tmp/rpm-tmp.25017 (%install)
>>
>
> Right, I'd guess the build will be successful with a simple
> --vendor=fedora tag?
>
> Once it successfully builds and installs OK, try opening the program and
> running a few demos (wizard->demo->whatever), rotating/translating
> objects with the mouse - that should be sufficient to ensure proper
> operation.

Apply the attached patch and drop the trailing space from line 1 of
pymol.desktop.

But I can't install, no python-pmw available?

> Thanks for the help,
>
> Tim
>
> --
> CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS
>


-- 
novus ordo absurdum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pymol.patch
Type: text/x-patch
Size: 747 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/d6789f6d/attachment.bin>

From bdwheele at indiana.edu  Wed Oct 29 20:12:06 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 16:12:06 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908C09B.6080609@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com>  <4908C09B.6080609@gmail.com>
Message-ID: <1225311126.23396.113.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 14:59 -0500, Les Mikesell wrote:

> Maybe you don't remember it, but there was a time when there actually 
> were a lot of different operating systems in use, and they had really 
> annoying arbitrary differences.  

Linux is just a fad...Ultrix will live forever!  My DECstation 5000/120
with PMAG-AA framebuffer doesn't have any screen flicker like this Linux
toy!

You're, of course, right that there were lots of annoying differences.
There are annoying differences between the distributions right now as
well.  Which VT X is running is probably the least irritating.  

Plus, how many different distros does any one person regularly run?
Between work and home, I'm running RHEL and Fedora.  I roll my eyes when
I run an LVM command on the RHEL4 boxes that isn't there, but its not a
big deal.

People adapt, just like when I had to deal with Tru64, Solaris, and
Linux.  "ps" is a harsh mistress when it comes to flags.


Brian



From bdwheele at indiana.edu  Wed Oct 29 20:12:28 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 16:12:28 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <geaflr$e29$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
	<geaflr$e29$1@ger.gmane.org>
Message-ID: <1225311148.23396.115.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 15:05 -0500, Matthew Woehlke wrote:
> Brian Wheeler wrote:
> > Well, I'm a long time user and I don't see what the big deal is.  There
> > are several people on this list which seem to announce that "<insert
> > change here> is the one that's going to drive long time users away"
> > and/or "time to look for a new distribution" semi-regularly... yet they
> > (long time users) are still here.
> 
> Maybe they just haven't found anything better (yet)?


Which is fair.  Everyone should be able to switch whenever they choose.

But if someone gets pissed off about this trivial change (or something
similar) and they switch to "Super Awesome Linux 2000" ... would they
switch again when it makes the same change as Fedora?



From lesmikesell at gmail.com  Wed Oct 29 20:16:04 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 15:16:04 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <geaflr$e29$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<1225301630.3846.66.camel@mentor.gurulabs.com>	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>	<4908BA6C.5030806@gmail.com>	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
	<geaflr$e29$1@ger.gmane.org>
Message-ID: <4908C484.5040809@gmail.com>

Matthew Woehlke wrote:
> B
>> Well, I'm a long time user and I don't see what the big deal is.  There
>> are several people on this list which seem to announce that "<insert
>> change here> is the one that's going to drive long time users away"
>> and/or "time to look for a new distribution" semi-regularly... yet they
>> (long time users) are still here.
> 
> Maybe they just haven't found anything better (yet)?

Or, speaking for myself, not actually running fedora anymore, just 
watching to see how much damage is going to make its way into the next 
RHEL and clones.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From mw_triad at users.sourceforge.net  Wed Oct 29 20:16:24 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 15:16:24 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908BA9F.6000301@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com>
Message-ID: <geagas$h8b$1@ger.gmane.org>

Casey Dahlin wrote:
> I don't expect Ubuntu to be any more compatible with Fedora than 
> Windows. The two come out pretty similar only because we happen to agree 
> on more than we disagree on (believe it or not), and because 
> wheel-inventing costs effort, even if you think you can make a shinier one.

That's a horrible analogy; Windows doesn't even attempt POSIX 
compatibility. Now, if you were comparing Fedora to Solaris, that would 
be better :-).

And I happen to expect a LOT of compatibility between Ubuntu and Fedora 
(and Solaris). They're all POSIX, after all. (That said, I'm reasonably 
confident that POSIX doesn't specify VT assignments...)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From jkeating at redhat.com  Wed Oct 29 20:21:00 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 29 Oct 2008 13:21:00 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908BA6C.5030806@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
Message-ID: <1225311660.1783.15.camel@luminos.localdomain>

On Wed, 2008-10-29 at 14:33 -0500, Les Mikesell wrote:
> How do you get back once you have switched to a text vt?

Hit alt+left until you find X.  Shouldn't take but a few keystrokes, and
you don't have to risk RSI by trying to reach up to an F# key.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/15f95a60/attachment.sig>

From bdwheele at indiana.edu  Wed Oct 29 20:23:07 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 16:23:07 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908C484.5040809@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
	<geaflr$e29$1@ger.gmane.org>  <4908C484.5040809@gmail.com>
Message-ID: <1225311787.23396.121.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 15:16 -0500, Les Mikesell wrote:
> Matthew Woehlke wrote:
> > B
> >> Well, I'm a long time user and I don't see what the big deal is.  There
> >> are several people on this list which seem to announce that "<insert
> >> change here> is the one that's going to drive long time users away"
> >> and/or "time to look for a new distribution" semi-regularly... yet they
> >> (long time users) are still here.
> > 
> > Maybe they just haven't found anything better (yet)?
> 
> Or, speaking for myself, not actually running fedora anymore, just 
> watching to see how much damage is going to make its way into the next 
> RHEL and clones.

So, out of curiosity...Do you run X on your RHEL machines?  Are you
going to switch from RHEL when this change makes it into RHEL6 or
whatever?  

X isn't running on mine (unless I start it manually for some reason) so
it doesn't make any difference in my case.  Frankly, I'm more concerned
with the inittab changes and the way Tivoli Storage Manager starts
up...but its something I'll fix once and be done with.

For my desktop/laptop machines (all fedora), I'm actually thrilled with
the new startup stuff.

Brian




From katzj at redhat.com  Wed Oct 29 20:23:16 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 29 Oct 2008 16:23:16 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908BD1C.6030501@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com> <20081029193426.GA24722@jadzia.bu.edu>
	<4908BD1C.6030501@gmail.com>
Message-ID: <1225311796.13184.90.camel@aglarond.local>

On Wed, 2008-10-29 at 14:44 -0500, Les Mikesell wrote:
> Matthew Miller wrote:
> > On Wed, Oct 29, 2008 at 02:33:00PM -0500, Les Mikesell wrote:
> >>>  The 7th is "nobody should care what tty X is on".  Indeed, why are
> >>> people so upset that it has changed?  Its not an argument for or
> >>> against, its an argument that this thread shouldn't be taking place at
> >>> all.
> >> How do you get back once you have switched to a text vt?
> > 
> > Hit alt-F* until you find where X is?
>
> Thanks, I would never have thought of that.  That will save lots of time.

Given the non-determinism already X being able to grab a tty, I already
play the "hit alt-F* until I find X" and have had to for a long time.

Jeremy



From cdahlin at redhat.com  Wed Oct 29 20:27:02 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 16:27:02 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908C09B.6080609@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>
Message-ID: <4908C716.2090906@redhat.com>

Les Mikesell wrote:
> Casey Dahlin wrote:
>>    I don't really agree with your expectations of Linux as a whole.
>>
>> This idea has come about that there is an operating system called 
>> Linux and there are many flavors of it called distros. This is not, 
>> IMHO, the case. There are many different operating systems, and they 
>> all happen to use the Linux kernel.
>
> Maybe you don't remember it, but there was a time when there actually 
> were a lot of different operating systems in use, and they had really 
> annoying arbitrary differences.  Fortunately most of them died and the 
> ones that continued converged on some standards.  Different Linux 
> distributions are not different operating systems and they certainly 
> can't claim to be that and at the same time have a mantra of 'upstream'.
>

I'd say I can count on one hand the number of distros that aren't 
niche-only or effectively "living dead." We have the best of both 
worlds. Lots of OSes, but nobody cares about most of them so its all good :)

>> If somehow I could be transported 30 years into the future, and I 
>> could be sat down in front of Fedora, I'd be honestly disappointed if 
>> I recognized it.
>
> You are imagining the wrong scenario. I'd like to avoid having to deal 
> with all of the silly and meaningless changes that break things for 
> the next 30 years too, but that's not going to happen.  The real world 
> situation is that people have large and complex systems built around 
> existing OS behavior whether formally standardized or just inherited 
> from SysV that will break with program interface and device name 
> changes, and there are large numbers of people to retrain for every 
> user interface change.  Now, plan your next 30 years in the context of 
> keeping things working through them instead of being magically 
> transported past everything that breaks.  If you need to imagine 
> something, imagine that your bank and credit card accounts are 
> maintained on the OS you design and that the customer service people 
> you call are trying to guess the latest user interface changes as they 
> try to help you.
>
My bank had better be running RHEL, which is kept frozen in time for 
precisely this reason. Fedora should be about doing it /right/, 
regardless of how we did it yesterday. Keep in mind, the OS /is/ free.

--CJD



From lesmikesell at gmail.com  Wed Oct 29 20:28:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 15:28:07 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>
	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
Message-ID: <4908C757.1000902@gmail.com>

Brian Wheeler wrote:
> 
> Plus, how many different distros does any one person regularly run?
> Between work and home, I'm running RHEL and Fedora.  I roll my eyes when
> I run an LVM command on the RHEL4 boxes that isn't there, but its not a
> big deal.

I'd expect most people who install fedora themselves to have at least a 
couple of other OS's running concurrently.  Has anyone done a poll about 
this recently?


-- 
   Les Mikesell
    lesmikesell at gmail.com



From skvidal at fedoraproject.org  Wed Oct 29 20:29:49 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 16:29:49 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225311787.23396.121.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
	<geaflr$e29$1@ger.gmane.org>  <4908C484.5040809@gmail.com>
	<1225311787.23396.121.camel@nibbler.dlib.indiana.edu>
Message-ID: <1225312189.21485.81.camel@rosebud>

On Wed, 2008-10-29 at 16:23 -0400, Brian Wheeler wrote:
> On Wed, 2008-10-29 at 15:16 -0500, Les Mikesell wrote:
> > Matthew Woehlke wrote:
> > > B
> > >> Well, I'm a long time user and I don't see what the big deal is.  There
> > >> are several people on this list which seem to announce that "<insert
> > >> change here> is the one that's going to drive long time users away"
> > >> and/or "time to look for a new distribution" semi-regularly... yet they
> > >> (long time users) are still here.
> > > 
> > > Maybe they just haven't found anything better (yet)?
> > 
> > Or, speaking for myself, not actually running fedora anymore, just 
> > watching to see how much damage is going to make its way into the next 
> > RHEL and clones.
> 
> So, out of curiosity...Do you run X on your RHEL machines?  Are you
> going to switch from RHEL when this change makes it into RHEL6 or
> whatever?  

To be fair, one of the points of participating in the fedora community
and discussion is to influence where rhel is going. We TELL people this
upfront.

So his case isn't without merit. I may not agree with Les often but it's
not like he's coming completely out of left field.

-sv




From smooge at gmail.com  Wed Oct 29 20:26:26 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 29 Oct 2008 14:26:26 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225311148.23396.115.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
	<geaflr$e29$1@ger.gmane.org>
	<1225311148.23396.115.camel@nibbler.dlib.indiana.edu>
Message-ID: <80d7e4090810291326p6a77c577vbda34919ec2e3752@mail.gmail.com>

On Wed, Oct 29, 2008 at 2:12 PM, Brian Wheeler <bdwheele at indiana.edu> wrote:
> On Wed, 2008-10-29 at 15:05 -0500, Matthew Woehlke wrote:
>> Brian Wheeler wrote:
>> > Well, I'm a long time user and I don't see what the big deal is.  There
>> > are several people on this list which seem to announce that "<insert
>> > change here> is the one that's going to drive long time users away"
>> > and/or "time to look for a new distribution" semi-regularly... yet they
>> > (long time users) are still here.
>>
>> Maybe they just haven't found anything better (yet)?
>
>
> Which is fair.  Everyone should be able to switch whenever they choose.
>
> But if someone gets pissed off about this trivial change (or something
> similar) and they switch to "Super Awesome Linux 2000" ... would they
> switch again when it makes the same change as Fedora?

No they probably not change.. because their cultural norms would have
become reset to new things. They might grouse, but the impetus of
major change isnt there. Now after 2 years some change in that
environment might make them change again but it will be something
completely different.

And 'minor' changes are rarely minor in the minds the effected people.
If you came in every 6 months and found that something in your
workplace was completely different.. your brain would get grouchy.. it
doesn't matter if your company is called Kaos, LLC and its job is to
change all the time.

6 months ago, all the phones went from 2 digit extensions to 8 digit
ones and you didn't find out any of the changes because its in your
voicemail you can't dial. Your office is now on the 3rd floor, but no
one told you. The office walls seem to change colors every couple of
weeks as two different directors call in different painters to get the
look just right. And the building manager and your boss keep saying
these are minor things and why aren't you seeing how much better it is
for everyone... and if you had been in the 8 different planning
committees you would have known all these changes (not that you could
have changed them.. just known about them.)


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From bdwheele at indiana.edu  Wed Oct 29 20:34:04 2008
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Wed, 29 Oct 2008 16:34:04 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225312189.21485.81.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
	<geaflr$e29$1@ger.gmane.org>  <4908C484.5040809@gmail.com>
	<1225311787.23396.121.camel@nibbler.dlib.indiana.edu>
	<1225312189.21485.81.camel@rosebud>
Message-ID: <1225312444.23396.125.camel@nibbler.dlib.indiana.edu>

On Wed, 2008-10-29 at 16:29 -0400, seth vidal wrote:
> On Wed, 2008-10-29 at 16:23 -0400, Brian Wheeler wrote:
> > On Wed, 2008-10-29 at 15:16 -0500, Les Mikesell wrote:
> > > Matthew Woehlke wrote:
> > > > B
> > > >> Well, I'm a long time user and I don't see what the big deal is.  There
> > > >> are several people on this list which seem to announce that "<insert
> > > >> change here> is the one that's going to drive long time users away"
> > > >> and/or "time to look for a new distribution" semi-regularly... yet they
> > > >> (long time users) are still here.
> > > > 
> > > > Maybe they just haven't found anything better (yet)?
> > > 
> > > Or, speaking for myself, not actually running fedora anymore, just 
> > > watching to see how much damage is going to make its way into the next 
> > > RHEL and clones.
> > 
> > So, out of curiosity...Do you run X on your RHEL machines?  Are you
> > going to switch from RHEL when this change makes it into RHEL6 or
> > whatever?  
> 
> To be fair, one of the points of participating in the fedora community
> and discussion is to influence where rhel is going. We TELL people this
> upfront.
> 
> So his case isn't without merit. I may not agree with Les often but it's
> not like he's coming completely out of left field.

I wasn't trying to be unfair.  One of the main reasons I use fedora is
to find out what is coming in RHEL.  I just genuinely curious
considering that alot of his statements on this topic seem to imply that
people will leave due to this change (and possibly others).

*shrug*

I literally have a shed that needs painted next spring, perhaps I should
ask on here?

Brian



From mattdm at mattdm.org  Wed Oct 29 20:34:23 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 29 Oct 2008 16:34:23 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225311796.13184.90.camel@aglarond.local>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com> <20081029193426.GA24722@jadzia.bu.edu>
	<4908BD1C.6030501@gmail.com>
	<1225311796.13184.90.camel@aglarond.local>
Message-ID: <20081029203423.GA31571@jadzia.bu.edu>

On Wed, Oct 29, 2008 at 04:23:16PM -0400, Jeremy Katz wrote:
> > > Hit alt-F* until you find where X is?
> > Thanks, I would never have thought of that.  That will save lots of time.
> Given the non-determinism already X being able to grab a tty, I already
> play the "hit alt-F* until I find X" and have had to for a long time.

And speaking of Jeremy, Anaconda hasn't put X on F7 for a long time....


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From sgrubb at redhat.com  Wed Oct 29 20:39:59 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 29 Oct 2008 16:39:59 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <faa16b610810291225k4f77afc2o7d7dbb49f9948c63@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291513.11983.sgrubb@redhat.com>
	<faa16b610810291225k4f77afc2o7d7dbb49f9948c63@mail.gmail.com>
Message-ID: <200810291640.00051.sgrubb@redhat.com>

On Wednesday 29 October 2008 15:25:15 Colin Walters wrote:
> On Wed, Oct 29, 2008 at 3:13 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > 1) We've spent a lot of time on getting audit right. We can tell what
> > account was logged in under and find every single application that was
> > started as a result of that login. Message passing breaks this.
>
> True, though how interesting is the question of "what binaries were
> executed" as opposed to the system having enough intelligence to
> display security-relevant information?

Not sure I follow your question. I am talking about /proc/<pid>/loginuid and 
sessionid.


> > 2) There is no accountability for what actions are performed for each
> > user. The audit system cannot tell who something was done for.
>
> Should be easy to add such auditing; actually I think we do want to
> have dbus audit on system activation regardless of PolicyKit.

Again I'm talking about loginuid and sessionid.


> > 3) There is yet another MAC policy with no auditing of access decisions.
>
> Duplicate of 2)?

No this is about PolicyKit being another MAC system that needs configuring.


> As for the sysadmin impact, yes, there is a concern there but
> there is documentation: 
> http://hal.freedesktop.org/docs/PolicyKit/PolicyKit.conf.5.html 

Where's the GUI or commandline tool that lets me configure it? I may need to 
have auditing of who changed what entry in that file. When I chmod 4755 a 
program, I know who changed it, what the old and new values are, when they 
did it, and what the outcome was.


> Anyways, I don't want to completely derail this discussion on fcap
> into suid-vs-PolicyKit;

True...but this is a discussion that needs to be had so that it can be fixed. 
Auditing from user space is not trustworthy and that's why its done from the 
kernel. A user space daemon making access control decisions will not be 
something I want to see getting spread into things that are part of the next 
CC evaluation.

-Steve



From katzj at redhat.com  Wed Oct 29 20:46:08 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 29 Oct 2008 16:46:08 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029203423.GA31571@jadzia.bu.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com> <20081029193426.GA24722@jadzia.bu.edu>
	<4908BD1C.6030501@gmail.com> <1225311796.13184.90.camel@aglarond.local>
	<20081029203423.GA31571@jadzia.bu.edu>
Message-ID: <1225313168.13184.93.camel@aglarond.local>

On Wed, 2008-10-29 at 16:34 -0400, Matthew Miller wrote:
> On Wed, Oct 29, 2008 at 04:23:16PM -0400, Jeremy Katz wrote:
> > > > Hit alt-F* until you find where X is?
> > > Thanks, I would never have thought of that.  That will save lots of time.
> > Given the non-determinism already X being able to grab a tty, I already
> > play the "hit alt-F* until I find X" and have had to for a long time.
> 
> And speaking of Jeremy, Anaconda hasn't put X on F7 for a long time....

Ever actually.  I'm a bad person like that

Jeremy



From jspaleta at gmail.com  Wed Oct 29 20:48:35 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 12:48:35 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225312444.23396.125.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
	<geaflr$e29$1@ger.gmane.org> <4908C484.5040809@gmail.com>
	<1225311787.23396.121.camel@nibbler.dlib.indiana.edu>
	<1225312189.21485.81.camel@rosebud>
	<1225312444.23396.125.camel@nibbler.dlib.indiana.edu>
Message-ID: <604aa7910810291348m126eaad9m9796c154d0a597a5@mail.gmail.com>

On Wed, Oct 29, 2008 at 12:34 PM, Brian Wheeler <bdwheele at indiana.edu>
> I wasn't trying to be unfair.  One of the main reasons I use fedora is
> to find out what is coming in RHEL.  I just genuinely curious
> considering that alot of his statements on this topic seem to imply that
> people will leave due to this change (and possibly others).


There are some people who make a habit of threatening to leave as a
short-hand way of communicating in situations where other people would
prefer to use the sentence 'Hey how's it going, what's new today.'

Search through the discussion through multiple releases helps identify
those people if you don't know who they are already.

-jef



From notting at redhat.com  Wed Oct 29 20:48:55 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 16:48:55 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <ge9uvh$8qo$1@ger.gmane.org>
References: <1225141679.3523.48.camel@metroid.rdu.redhat.com>
	<4906FA43.4050902@odu.neva.ru>
	<91705d080810280627j73733c14x86e13cbb82fda36f@mail.gmail.com>
	<200810281509.40552.opensource@till.name>
	<20081028202624.GB8452@nostromo.devel.redhat.com>
	<49077869.9030706@redhat.com>
	<20081028204315.GF8452@nostromo.devel.redhat.com>
	<ge82t0$ql6$1@ger.gmane.org>
	<20081029005548.GA12270@nostromo.devel.redhat.com>
	<ge9uvh$8qo$1@ger.gmane.org>
Message-ID: <20081029204855.GB25197@nostromo.devel.redhat.com>

Matthew Woehlke (the-spambots-will-find-you at no.matter.what) said:
> Aside from the obvious question if this wouldn't start out as a  
> Fedora-specific kernel patch, why do you assume Fedora will be the only  
> distro with this problem? Or is plymouth (and similar technologies)  
> expected to remain Fedora-only forever?

I'd like to think it can be used other places, yes. But flopping ttys
based on command line arguments is just *WRONG*, for the reasons stated
already.

For example, right now, the user can customize their init system so that
tty7 is a continually updating 'top'. Or Star Wars piped through libcaca.
So, to do this reliably, you'd have to somehow get 'the specifics of how
the init system is configured' into the kernel, which is getting into
ridiculous levels of convolution.

Bill



From smooge at gmail.com  Wed Oct 29 18:50:03 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 29 Oct 2008 12:50:03 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810291145x393573f4g55d987080d7fc044@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300836.3846.49.camel@mentor.gurulabs.com>
	<20081029122251.80c75d94.zaitcev@redhat.com>
	<1225305765.3846.113.camel@mentor.gurulabs.com>
	<604aa7910810291145x393573f4g55d987080d7fc044@mail.gmail.com>
Message-ID: <80d7e4090810291150v244f2c26kcc780c18547608f6@mail.gmail.com>

On Wed, Oct 29, 2008 at 12:45 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Wed, Oct 29, 2008 at 10:42 AM, Dax Kelson
>> Is there a mailing list or infrastructure where the shepherds of various
>> distros can discuss a major changes for the sake of compatibility? If
>> not, there should be.
>
>
> I take exception to the idea that a line edit in a config file like
> inittab...to change default behavior..constitutes a major change.
>

I don't when it is something that every training manual etc has spoken
from 1994 onward... CONTROL-ALT-F1 to get to a non-X to fix a problem.
You are talking about a change that is rooted in a lot of system
administrators deep core from when they had to fix the CEO's laptop
before the IPO and its not working and we are all going to be fired...
Heck its something my Dad will checklist when he is saying he broke
mom's router and needs me to fix it. "Well its not completely broke, I
got to ALT-F1 and it says login: thats good right."





-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From cmadams at hiwaay.net  Wed Oct 29 20:49:50 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 29 Oct 2008 15:49:50 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
Message-ID: <20081029204950.GF1371252@hiwaay.net>

Once upon a time, Brian Wheeler <bdwheele at indiana.edu> said:
> People adapt, just like when I had to deal with Tru64, Solaris, and
> Linux.  "ps" is a harsh mistress when it comes to flags.

*#$@ it, I _still_ have to deal with Tru64 daily.  I turned off my last
Solaris box a few months ago though (thankfully!).

-- 
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  Wed Oct 29 20:52:44 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 16:52:44 -0400
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <49088E63.3020108@redhat.com>
References: <20081028152402.GA48208@dspnet.fr.eu.org>
	<1225208387.3897.88.camel@beck.corsepiu.local>
	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>
	<1225210747.3897.110.camel@beck.corsepiu.local>
	<490748B0.6060506@redhat.com>
	<1225215496.3897.158.camel@beck.corsepiu.local>
	<1225216493.2157.68.camel@luminos.localdomain>
	<4908337A.5030705@redhat.com>
	<1225296586.5409.78.camel@atropine.boston.devel.redhat.com>
	<49088E63.3020108@redhat.com>
Message-ID: <20081029205244.GC25197@nostromo.devel.redhat.com>

Gerd Hoffmann (kraxel at redhat.com) said: 
> Read the mail again.  All of it.  Last paragraph suggests to run
> plymouth on tty7 to keep the cross-fading effect.

Which either requires disgusting kernel convolutions (as stated
before), or doing it in plymouth userspace... which still gets you
a vt switch, as ttys have been initiated at that point.

Bill



From walters at verbum.org  Wed Oct 29 20:52:48 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 16:52:48 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291640.00051.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291513.11983.sgrubb@redhat.com>
	<faa16b610810291225k4f77afc2o7d7dbb49f9948c63@mail.gmail.com>
	<200810291640.00051.sgrubb@redhat.com>
Message-ID: <faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>

On Wed, Oct 29, 2008 at 4:39 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> On Wednesday 29 October 2008 15:25:15 Colin Walters wrote:
>> On Wed, Oct 29, 2008 at 3:13 PM, Steve Grubb <sgrubb at redhat.com> wrote:
>> > 1) We've spent a lot of time on getting audit right. We can tell what
>> > account was logged in under and find every single application that was
>> > started as a result of that login. Message passing breaks this.
>>
>> True, though how interesting is the question of "what binaries were
>> executed" as opposed to the system having enough intelligence to
>> display security-relevant information?
>
> Not sure I follow your question. I am talking about /proc/<pid>/loginuid and
> sessionid.

Oh.  Well, if your application uses PolicyKit there are *two*
programs; the privileged mechanism, and the unprivileged application.
The unprivileged application of course maintains the loginuid.

> No this is about PolicyKit being another MAC system that needs configuring.

Of course it would be ideal if there were One True MAC system, but
AFAIK the story on SELinux is still that the system must be secure
without it, and other vendors that we care about from the desktop
perspective (personally I just care about Ubuntu and OpenSolaris)
haven't yet finished integrating it.  Even when we do depend on
SELinux (and I would advocate that), PolicyKit fills a useful role as
"coarse grained" system on top of the far more fine grained SELinux
policy.  Also, by having application authors forced to split
applications into privileged mechanisms and unprivileged frontends,
the SELinux policy for the mechanism can be much stronger.

> Where's the GUI or commandline tool that lets me configure it? I may need to
> have auditing of who changed what entry in that file. When I chmod 4755 a
> program, I know who changed it, what the old and new values are, when they
> did it, and what the outcome was.

There's no real story on that other than "uid 0" and $EDITOR yet.
This is basically the same as all the other OS config files.

> True...but this is a discussion that needs to be had so that it can be fixed.
> Auditing from user space is not trustworthy and that's why its done from the
> kernel.

Hmm?  SELinux userspace enforcers (dbus and X.org) are using the audit
system; I don't think it's reasonable to say that the kernel is the
only component of the TCB.



From cmadams at hiwaay.net  Wed Oct 29 20:53:30 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 29 Oct 2008 15:53:30 -0500
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291521.32293.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<1225307614.3846.126.camel@mentor.gurulabs.com>
	<200810291521.32293.sgrubb@redhat.com>
Message-ID: <20081029205330.GG1371252@hiwaay.net>

Once upon a time, Steve Grubb <sgrubb at redhat.com> said:
> Its not a ping issue, its an installation issue. :)   I can either chmod 4755 
> or capset cap_net_raw=ep  during the installation. Upstream is not involved 
> in this.

How do these new bits get backed up?  I'm still working on getting
SELinux backed up correctly, and now this... <sigh> an admin's job is
never done.
-- 
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 michael at laptop.org  Wed Oct 29 20:57:22 2008
From: michael at laptop.org (Michael Stone)
Date: Wed, 29 Oct 2008 16:57:22 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <faa16b610810291233w600231a3ve6a6249ca73c7a8a@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
	<20081029192224.GD20573@didacte.laptop.org>
	<faa16b610810291233w600231a3ve6a6249ca73c7a8a@mail.gmail.com>
Message-ID: <20081029205722.GF20573@didacte.laptop.org>

On Wed, Oct 29, 2008 at 03:33:32PM -0400, Colin Walters wrote:
>On Wed, Oct 29, 2008 at 3:22 PM, Michael Stone <michael at laptop.org> wrote:
>
>> Could you please suggest some links to your favorite writeups of those
>> reasons?
>
>The PolicyKit docs have some:
>http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html

Thanks for the link; reading now.

>> Also, do you have data on what effect (if any) this trend has
>> on steady-state system memory consumption?
>
>That's a good question - I think with system activation by default
>activated mechanisms will stay around, though obviously the kernel can
>page them out. 

Do you have data which suggest that the pages are all or mostly clean?
(I work on a system with no swap other than, maybe, compcache.)

Michael



From notting at redhat.com  Wed Oct 29 20:57:26 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 16:57:26 -0400
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081029140356.GF1293@mokona.greysector.net>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
Message-ID: <20081029205726.GD25197@nostromo.devel.redhat.com>

Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > Not in the context of init.d/network, which is what I meant. (Well, not
> > outside of gross hacks.)
> 
> Yes, it works in that context. /etc/sysconfig/network-scripts/ifup-wireless
> needs a small patch which I posted in bugzilla and which has been ignored
> for years. The patch isn't actually mine, it was posted on one of fedora lists.
> I can't find that bugzilla report right now so I'm attaching the patch here
> instead.

Possibly because that particular patch wasn't ever in bugzilla (AFAICT.)

It's certainly a better one, but there's still the problem of entirely
disparate configuration (manually editing wpa_supplicant.conf, etc.)

Bill



From kraxel at redhat.com  Wed Oct 29 20:59:28 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Wed, 29 Oct 2008 21:59:28 +0100
Subject: X on tty1 in Rawhide/F10
In-Reply-To: <20081029205244.GC25197@nostromo.devel.redhat.com>
References: <20081028152402.GA48208@dspnet.fr.eu.org>	<1225208387.3897.88.camel@beck.corsepiu.local>	<d9c612bf0810280906m1b5c5536n934d31c4430eb33c@mail.gmail.com>	<1225210747.3897.110.camel@beck.corsepiu.local>	<490748B0.6060506@redhat.com>	<1225215496.3897.158.camel@beck.corsepiu.local>	<1225216493.2157.68.camel@luminos.localdomain>	<4908337A.5030705@redhat.com>	<1225296586.5409.78.camel@atropine.boston.devel.redhat.com>	<49088E63.3020108@redhat.com>
	<20081029205244.GC25197@nostromo.devel.redhat.com>
Message-ID: <4908CEB0.1010000@redhat.com>

Bill Nottingham wrote:
> Gerd Hoffmann (kraxel at redhat.com) said: 
>> Read the mail again.  All of it.  Last paragraph suggests to run
>> plymouth on tty7 to keep the cross-fading effect.
> 
> Which either requires disgusting kernel convolutions (as stated
> before), or doing it in plymouth userspace... which still gets you
> a vt switch, as ttys have been initiated at that point.

Do it in plymouth userspace of course (requiring a patched kernel would
be insane).  Before anything is displayed on the screen, so you switch
from black tty1 to black tty7.  No visible flicker, see?

cheers,
  Gerd



From notting at redhat.com  Wed Oct 29 21:02:50 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:02:50 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225282082.21485.33.camel@rosebud>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<1225282082.21485.33.camel@rosebud>
Message-ID: <20081029210250.GE25197@nostromo.devel.redhat.com>

seth vidal (skvidal at fedoraproject.org) said: 
> > Are we ready to start considering moving away from SUID bits to 
> > capabilities, in Fedora 11 maybe?
> 
> How does that mesh with networked file systems (nfs, samba)?

I don't have firsthand knowledge, but I would suspect 'badly'.

Bill



From sgrubb at redhat.com  Wed Oct 29 21:04:43 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 29 Oct 2008 17:04:43 -0400
Subject: PolicyKit auditing - was Re: Fedora 11: moving to posix file
	capabilities?
In-Reply-To: <faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291640.00051.sgrubb@redhat.com>
	<faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
Message-ID: <200810291704.43907.sgrubb@redhat.com>

On Wednesday 29 October 2008 16:52:48 Colin Walters wrote:
> > Not sure I follow your question. I am talking about /proc/<pid>/loginuid
> > and sessionid.
>
> Oh. ?Well, if your application uses PolicyKit there are *two*
> programs; the privileged mechanism, and the unprivileged application.
> The unprivileged application of course maintains the loginuid.

Which is a problem. We have no way to connect the session ID for the backend 
with the frontend. That means we can't make a killall mechanism that nails 
everything in a login session.


> > Where's the GUI or commandline tool that lets me configure it? I may need
> > to have auditing of who changed what entry in that file. When I chmod
> > 4755 a program, I know who changed it, what the old and new values are,
> > when they did it, and what the outcome was.
>
> There's no real story on that other than "uid 0" and $EDITOR yet.
> This is basically the same as all the other OS config files.

No...we have a handful of apps that audit changes to trusted databases. 
password and adduser are two examples.


> > True...but this is a discussion that needs to be had so that it can be
> > fixed. Auditing from user space is not trustworthy and that's why its
> > done from the kernel.
>
> Hmm? ?SELinux userspace enforcers (dbus and X.org) are using the audit
> system; I don't think it's reasonable to say that the kernel is the
> only component of the TCB.

I have to be able to tell the audit system to include or exclude events from 
certain users. That would mean a user space access control daemon would have 
to download and enforce audit policy. Nothing else does that because all the 
necessary process attributes are maintained across the exec model and the 
kernel can access it all.

-Steve



From sgrubb at redhat.com  Wed Oct 29 21:08:26 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 29 Oct 2008 17:08:26 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081029205330.GG1371252@hiwaay.net>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291521.32293.sgrubb@redhat.com>
	<20081029205330.GG1371252@hiwaay.net>
Message-ID: <200810291708.27051.sgrubb@redhat.com>

On Wednesday 29 October 2008 16:53:30 Chris Adams wrote:
> > Its not a ping issue, its an installation issue. :) ? I can either chmod
> > 4755 or capset cap_net_raw=ep ?during the installation. Upstream is not
> > involved in this.
>
> How do these new bits get backed up? ?I'm still working on getting
> SELinux backed up correctly, and now this... <sigh> an admin's job is
> never done.

Since they are stored as xattrs, tar and star should do it if you tell them to 
get the extended attributes. Also, aide supports looking for changes in 
xattrs if you need that, too.

-Steve



From cmadams at hiwaay.net  Wed Oct 29 21:11:50 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 29 Oct 2008 16:11:50 -0500
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291708.27051.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291521.32293.sgrubb@redhat.com>
	<20081029205330.GG1371252@hiwaay.net>
	<200810291708.27051.sgrubb@redhat.com>
Message-ID: <20081029211150.GH1371252@hiwaay.net>

Once upon a time, Steve Grubb <sgrubb at redhat.com> said:
> On Wednesday 29 October 2008 16:53:30 Chris Adams wrote:
> > > Its not a ping issue, its an installation issue. :) ? I can either chmod
> > > 4755 or capset cap_net_raw=ep ?during the installation. Upstream is not
> > > involved in this.
> >
> > How do these new bits get backed up? ?I'm still working on getting
> > SELinux backed up correctly, and now this... <sigh> an admin's job is
> > never done.
> 
> Since they are stored as xattrs, tar and star should do it if you tell them to 
> get the extended attributes. Also, aide supports looking for changes in 
> xattrs if you need that, too.

That's the same way SELinux contexts are stored, right (so anything that
handles extended attributes for SELinux should handle this as well)?

Thanks.
-- 
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  Wed Oct 29 21:15:03 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:15:03 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908A8E7.20604@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
	<4908A8E7.20604@gmail.com>
Message-ID: <20081029211503.GF25197@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
> As an admin you likely have the option of ssh'ing in from a different  
> machine in case the console hardware is broken.

And as a distro developer, we can do things like disable all
gettys by default, catch VT switch events with ConsoleKit, fire off events,
and start mingetty on demand.

(Well, not quite yet with upstart. But that really seems to be the
logical answer.)

Bill



From walters at verbum.org  Wed Oct 29 19:33:32 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 15:33:32 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081029192224.GD20573@didacte.laptop.org>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<faa16b610810290953y265a2db7h6a4b47c85719982d@mail.gmail.com>
	<20081029192224.GD20573@didacte.laptop.org>
Message-ID: <faa16b610810291233w600231a3ve6a6249ca73c7a8a@mail.gmail.com>

On Wed, Oct 29, 2008 at 3:22 PM, Michael Stone <michael at laptop.org> wrote:

> Could you please suggest some links to your favorite writeups of those
> reasons?

The PolicyKit docs have some:
http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html

> Also, do you have data on what effect (if any) this trend has
> on steady-state system memory consumption?

That's a good question - I think with system activation by default
activated mechanisms will stay around, though obviously the kernel can
page them out.  The clock applet mechanism
(http://svn.gnome.org/svn/gnome-panel/trunk/applets/clock/gnome-clock-applet-mechanism.c)
has its own 30-second timeout but it's kind of a hack.  It's something
we should look at addressing - unfortunately just calling exit() after
30 seconds I believe creates race conditions, and to fix it correctly
will need special DBus support.  There was a thread a while ago about
this on the DBus list IIRC.



From walters at verbum.org  Wed Oct 29 21:17:18 2008
From: walters at verbum.org (Colin Walters)
Date: Wed, 29 Oct 2008 17:17:18 -0400
Subject: PolicyKit auditing - was Re: Fedora 11: moving to posix file
	capabilities?
In-Reply-To: <200810291704.43907.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291640.00051.sgrubb@redhat.com>
	<faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
	<200810291704.43907.sgrubb@redhat.com>
Message-ID: <faa16b610810291417n7e9f73bavaf99d303fc840577@mail.gmail.com>

On Wed, Oct 29, 2008 at 5:04 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> On Wednesday 29 October 2008 16:52:48 Colin Walters wrote:
>> > Not sure I follow your question. I am talking about /proc/<pid>/loginuid
>> > and sessionid.
>>
>> Oh.  Well, if your application uses PolicyKit there are *two*
>> programs; the privileged mechanism, and the unprivileged application.
>> The unprivileged application of course maintains the loginuid.
>
> Which is a problem. We have no way to connect the session ID for the backend
> with the frontend. That means we can't make a killall mechanism that nails
> everything in a login session.

Conceptually the mechanism isn't part of the login session, it's OS
infrastructure that runs in userspace, just like libvirtd, iscsid[1]
or HAL.  In particular the same mechanism process can be reused by
multiple uids, just as multiple uids can share a page cache entry in
the kernel or enumerate devices from the HAL daemon.

> No...we have a handful of apps that audit changes to trusted databases.
> password and adduser are two examples.

Sure...but that's a tiny minority of files for the core OS; at least
looking at "ls /etc".  Don't get me wrong, I think it would make sense
to have a frontend tool but I can't see how the lack of one would be
considered a blocker.

> I have to be able to tell the audit system to include or exclude events from
> certain users. That would mean a user space access control daemon would have
> to download and enforce audit policy. Nothing else does that because all the
> necessary process attributes are maintained across the exec model and the
> kernel can access it all.

How Policykit should interact with auditing sounds like something to
bring up on the PolicyKit list; like I said before I think we do want
at least auditing of dbus system activation and that would be a use
case for userspace audit policy loading.

[1] Why the heck is my F9 desktop running iscsid?



From cdahlin at redhat.com  Wed Oct 29 21:19:43 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 17:19:43 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029211503.GF25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>	<49081A53.1050504@leemhuis.info>	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>	<1225300860.3897.398.camel@beck.corsepiu.local>	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>	<4908A8E7.20604@gmail.com>
	<20081029211503.GF25197@nostromo.devel.redhat.com>
Message-ID: <4908D36F.20908@redhat.com>

Bill Nottingham wrote:
> Les Mikesell (lesmikesell at gmail.com) said: 
>   
>> As an admin you likely have the option of ssh'ing in from a different  
>> machine in case the console hardware is broken.
>>     
>
> And as a distro developer, we can do things like disable all
> gettys by default, catch VT switch events with ConsoleKit, fire off events,
> and start mingetty on demand.
>
> (Well, not quite yet with upstart. But that really seems to be the
> logical answer.)
>
> Bill
>
>   
....y'know, we could...

I know we're kinda avoiding touching new upstart whizbang until the dust 
clears, but there's actually no reason that shouldn't work.

--CJD



From seg at haxxed.com  Wed Oct 29 21:19:49 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 29 Oct 2008 16:19:49 -0500
Subject: Don't hibernate, crashing is faster.
In-Reply-To: <49085FCD.9060707@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>  <49085FCD.9060707@gmail.com>
Message-ID: <1225315189.598.62.camel@localhost.localdomain>

On Wed, 2008-10-29 at 08:06 -0500, Les Mikesell wrote:
> I don't quite understand the obsession with making boot time faster 
> anyway.  Machines should only boot when they have a new kernel to 
> install.  If they aren't needed all the time they should sleep or 
> hibernate, waking up with everything still running.

Hibernate is the Wrong Thing.

http://lwn.net/Articles/191059/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/3617c9c4/attachment.sig>

From jspaleta at gmail.com  Wed Oct 29 21:24:21 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 13:24:21 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908D36F.20908@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
	<4908A8E7.20604@gmail.com>
	<20081029211503.GF25197@nostromo.devel.redhat.com>
	<4908D36F.20908@redhat.com>
Message-ID: <604aa7910810291424y65b6ff66pe1597c60ed4edc02@mail.gmail.com>

On Wed, Oct 29, 2008 at 1:19 PM, Casey Dahlin <cdahlin at redhat.com> wrote:
> I know we're kinda avoiding touching new upstart whizbang until the dust
> clears, but there's actually no reason that shouldn't work.


You mean ALT-CTRL-F1 might actually end up mapping to a console
interface that is NOT actually on tty1?

-jef"remappable keybindings... clever."spaleta



From notting at redhat.com  Wed Oct 29 21:25:36 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:25:36 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225258594.3742.73.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
Message-ID: <20081029212536.GG25197@nostromo.devel.redhat.com>

Dax Kelson (dkelson at gurulabs.com) said: 
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):

So, I'd like to take a different tack to this request. I don't want
to be combative, but I'm genuinely curious.

This change was documented as part of the BetterStartup feature on the
wiki page ever since existed. For those playing at home, that's roughly a
year and a half. No one complained on this list.

The feature was proposed to FESCo, and approved. No one complained
on this list.

The feature was implemented, and landed in rawhide. No one complained
on this list.

Will mentioned it on the list, as an adjunct to a release note (more
or less). Everybody showed up.

Are people not running rawhide and the test releases? Are they not
looking at features as they are proposed and being involved in the
process? Are they just sitting around waiting to be outraged?

Bill



From notting at redhat.com  Wed Oct 29 21:26:44 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:26:44 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908D36F.20908@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
	<4908A8E7.20604@gmail.com>
	<20081029211503.GF25197@nostromo.devel.redhat.com>
	<4908D36F.20908@redhat.com>
Message-ID: <20081029212644.GH25197@nostromo.devel.redhat.com>

Casey Dahlin (cdahlin at redhat.com) said: 
> ....y'know, we could...
>
> I know we're kinda avoiding touching new upstart whizbang until the dust  
> clears, but there's actually no reason that shouldn't work.

With 0.5, probably. But it's a tad late in the cycle for that for Fedora 10.
(And still leaves the 0.3.9 -> 0.5.0 -> next transition headaches.)

Bill



From notting at redhat.com  Wed Oct 29 21:29:45 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:29:45 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <49082E6B.7080304@hhs.nl>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
Message-ID: <20081029212945.GI25197@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> So the idea is to patch all the initscripts which currently only get 
> started by default for NFS, to as the first thing in their start method 
> grep for nfs in /etc/fstab and if that is not found exit quietly without 
> doing anything further.

Ow. But... maybe.

> Then to make manual mounting of nfs exports not in fstab work properly, 
> the suggested fix is to patch mount to check if the necessary daemons are 
> running and if not start them. Since this will probably turn out to be 
> distro specific I think it would be best to have a checknfsdaemons shell 
> script in some standard location provided by the distro and let mount 
> call that before each nfs mount. (Oh the horror an additional entire fork 
> and exec on each nfs mount, hello people this is going over the network, 
> forget about the fork and exec cost, thank you).

install nfs <do horrible, nasty dirty stuff here> in a modprobe.d file
might do the trick.

Bill



From dimi at lattica.com  Wed Oct 29 21:29:07 2008
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 29 Oct 2008 17:29:07 -0400
Subject: Don't hibernate, crashing is faster.
In-Reply-To: <1225315189.598.62.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>  <49085FCD.9060707@gmail.com>
	<1225315189.598.62.camel@localhost.localdomain>
Message-ID: <1225315747.32201.84.camel@dimi.lattica.com>


On Wed, 2008-10-29 at 16:19 -0500, Callum Lerwick wrote:
> Hibernate is the Wrong Thing.
> 
> http://lwn.net/Articles/191059/

Absolutely, if you want to shutdown, just crash the box.
Shutdown should be <3s. All the nonsense Fedora does now
with shutting down every daemon is just silly.

However, that has nothing to do with hibernate. This is because
a major reason a person doesn't want to reboot is that the state
of the desktops, apps, etc. is lost. And no crash-only software
can solve that problem.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From notting at redhat.com  Wed Oct 29 21:30:41 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:30:41 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <49085F0A.4010901@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
	<1225283507.5412.178.camel@vorpal.macdev.com>
	<49085F0A.4010901@gmail.com>
Message-ID: <20081029213041.GJ25197@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
> Not to mention POSIX and the LSB...

The LSB has standardized something useful that wasn't already a defacto
standard?

Bill



From cdahlin at redhat.com  Wed Oct 29 21:31:39 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 17:31:39 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212644.GH25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>	<49081A53.1050504@leemhuis.info>	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>	<1225300860.3897.398.camel@beck.corsepiu.local>	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>	<4908A8E7.20604@gmail.com>	<20081029211503.GF25197@nostromo.devel.redhat.com>	<4908D36F.20908@redhat.com>
	<20081029212644.GH25197@nostromo.devel.redhat.com>
Message-ID: <4908D63B.6080206@redhat.com>

Bill Nottingham wrote:
> Casey Dahlin (cdahlin at redhat.com) said: 
>   
>> ....y'know, we could...
>>
>> I know we're kinda avoiding touching new upstart whizbang until the dust  
>> clears, but there's actually no reason that shouldn't work.
>>     
>
> With 0.5, probably. But it's a tad late in the cycle for that for Fedora 10.
> (And still leaves the 0.3.9 -> 0.5.0 -> next transition headaches.)
>
> Bill
>
>   
True. Would have been interesting.


--CJD



From skvidal at fedoraproject.org  Wed Oct 29 21:32:22 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 29 Oct 2008 17:32:22 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212536.GG25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
Message-ID: <1225315942.21485.94.camel@rosebud>

On Wed, 2008-10-29 at 17:25 -0400, Bill Nottingham wrote:
> Dax Kelson (dkelson at gurulabs.com) said: 
> > I would argue strongly that this change should not be made for the
> > following reasons (in no particular order):

> Are people not running rawhide and the test releases?

Fairly obviously, they are not.


>  Are they not looking at features as they are proposed and being involved in the
> process? 

Also, no, or not as much

> Are they just sitting around waiting to be outraged?

No, but they will get upset when they're surprised by something.



I think the first two above  are more OUR problem than their problem,
though.

-sv






From notting at redhat.com  Wed Oct 29 21:33:22 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:33:22 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <alpine.LRH.2.00.0810291122590.954@arj.bjyevire.pbz>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <ge9bsl$2fp$1@ger.gmane.org>
	<4908360D.8060900@hhs.nl>
	<alpine.LRH.2.00.0810291122590.954@arj.bjyevire.pbz>
Message-ID: <20081029213322.GK25197@nostromo.devel.redhat.com>

R P Herrold (herrold at owlriver.com) said: 
> Source for '1%' please? -- I simply don't believe it, having deployed and 
> managed 'homes' for thousands of users of Linux in NFS environments.

Add together the number of Linksys routers sold, the number of T-Mobile G1
users, the number of Tivos, and the number of EEE PCs. Boom, whatever's left
for Fedora, Ubuntu, Novell, etc. are now almost certainly < 1%.

(Fun with statistics!)

Bill



From fenn at stanford.edu  Wed Oct 29 21:36:07 2008
From: fenn at stanford.edu (Tim Fenn)
Date: Wed, 29 Oct 2008 14:36:07 -0700
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <184a01e885d325a10895a8b90ce88207.squirrel@mail.jcomserv.net>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
	<184a01e885d325a10895a8b90ce88207.squirrel@mail.jcomserv.net>
Message-ID: <20081029143607.4e4c39ce@atbws1.stanford.edu>

On Wed, 29 Oct 2008 15:06:26 -0500 (CDT) "Jon Ciesla"
<limb at jcomserv.net> wrote:
> 
> Apply the attached patch and drop the trailing space from line 1 of
> pymol.desktop.
> 

Thanks, will do.

> But I can't install, no python-pmw available?
> 

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

which should also be available in EPEL testing.

-Tim

-- 
CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS



From sgrubb at redhat.com  Wed Oct 29 21:38:26 2008
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 29 Oct 2008 17:38:26 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081029211150.GH1371252@hiwaay.net>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291708.27051.sgrubb@redhat.com>
	<20081029211150.GH1371252@hiwaay.net>
Message-ID: <200810291738.26206.sgrubb@redhat.com>

On Wednesday 29 October 2008 17:11:50 Chris Adams wrote:
> > > How do these new bits get backed up? ?I'm still working on getting
> > > SELinux backed up correctly, and now this... <sigh> an admin's job is
> > > never done.
> >
> > Since they are stored as xattrs, tar and star should do it if you tell
> > them to get the extended attributes. Also, aide supports looking for
> > changes in xattrs if you need that, too.
>
> That's the same way SELinux contexts are stored, right (so anything that
> handles extended attributes for SELinux should handle this as well)?

Yes, that is the theory. I haven't personally done it, but if that doesn't 
work we need a bz filed.

-Steve



From alsadi at gmail.com  Wed Oct 29 21:39:29 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 30 Oct 2008 00:39:29 +0300
Subject: kde needs mysql-server ??
In-Reply-To: <ge5dn0$6tb$1@ger.gmane.org>
References: <48FF046A.3000501@nobugconsulting.ro>
	<200810241243.12892.Juha.Tuomala@iki.fi>
	<385866f0810240446j2ccd6cd8s749f39c9da60ccb0@mail.gmail.com>
	<ge5dn0$6tb$1@ger.gmane.org>
Message-ID: <385866f0810291439w1d22bac9sbbca1ed6f4ab7e74@mail.gmail.com>

> Ah, did you actually read http://techbase.kde.org/Projects/PIM/Akonadi?
> (Summary: they *did* consider sqlite, at least according to the FAQ)
>

yes I read it,


>Why not use sqlite?
> We tried. Really. It can't handle the concurrent access very well, in the best case this means very slow operations, but we've also seen deadlocks and failing transactions. Once that's fixed in sqlite, adjusting Akonadi to use it again instead of MySQL is no problem.

not convinced

I know that SQLite is not officiant for heavy concurrency
from http://www.sqlite.org/whentouse.html
Situations Where Another RDBMS May Work Better
High Concurrency

SQLite uses reader/writer locks on the entire database file. That
means if any process is reading from any part of the database, all
other processes are prevented from writing any other part of the
database. Similarly, if any one process is writing to the database,
all other processes are prevented from reading any other part of the
database. For many situations, this is not a problem. Each application
does its database work quickly and moves on, and no lock lasts for
more than a few dozen milliseconds. But there are some applications
that require more concurrency, and those applications may need to seek
a different solution.
EOQ

from http://www.sqlite.org/faq.html#q5

We are aware of no other embedded SQL database engine that supports as
much concurrency as SQLite. SQLite allows multiple processes to have
the database file open at once, and for multiple processes to read the
database at once. When any process wants to write, it must lock the
entire database file for the duration of its update. But that normally
only takes a few milliseconds.

EOQ

so I won't bother if it blocks for fraction of second when I'm doing
commits from more than one application

I bet that would be much faster than elephantine  RDBMS



From cmadams at hiwaay.net  Wed Oct 29 21:43:26 2008
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 29 Oct 2008 16:43:26 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212536.GG25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
Message-ID: <20081029214326.GI1371252@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> Are people not running rawhide and the test releases? Are they not
> looking at features as they are proposed and being involved in the
> process? Are they just sitting around waiting to be outraged?

Or have they not actually used a VT switch to a text console since this
was implemented?

</me ducks>
-- 
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 mw_triad at users.sourceforge.net  Wed Oct 29 21:49:03 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 16:49:03 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029213322.GK25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org>	<4908360D.8060900@hhs.nl>	<alpine.LRH.2.00.0810291122590.954@arj.bjyevire.pbz>
	<20081029213322.GK25197@nostromo.devel.redhat.com>
Message-ID: <gealof$4l0$1@ger.gmane.org>

Bill Nottingham wrote:
> R P Herrold (herrold at owlriver.com) said: 
>> Source for '1%' please? -- I simply don't believe it, having deployed and 
>> managed 'homes' for thousands of users of Linux in NFS environments.
> 
> Add together the number of Linksys routers sold, the number of T-Mobile G1
> users, the number of Tivos,

Those surely are running a customized distro with everything not in use 
disabled, so I don't think they count. What's the percent out of 
stock-Fedora-running machines?

> and the number of EEE PCs.

...but I might want NFS on my EEE :-). (Actually, given the abysmal size 
of the SSD, that's a pretty big "might"...)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From notting at redhat.com  Wed Oct 29 21:51:23 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:51:23 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
Message-ID: <20081029215123.GL25197@nostromo.devel.redhat.com>

Dan Nicholson (dbn.lists at gmail.com) said: 
> > * The default behavior of X on tty7 has been in place since the
> > beginning (almost a decade and a half).
> 
> This is actually convention, not any enforced behavior. There is
> nothing magic about tty7. It just so happens that the typical init
> configuration has been gettys on the first 6 ttys. When X starts, it
> simply chooses the next available VT. This has always been
> configurable - /etc/inittab with sysvinit and now
> /etc/event.d/tty[1-6] with upstart. Personally, I always thought that
> 6 consoles was more than I've ever wanted, so for me the "default" X
> was tty4.

The fact that it's just convention based on the number of ttys 
configured (that the admin can override) also means that any
change to unilaterally swtich to tty7 in plymouth means you're
potentially stomping on a local-use-for-something-else tty. I
don't think telling admins "if you want to run top on tty7, or
have already configured your system to do so, you need to edit some
plymouth thing and re-run mkinitrd for any kernel you want to boot"
is something that's necessarily going to fly.

Realistically, if you're going to start a boot process by default on a
particular *specific* tty, tty1 is the only sanely implementable answer,
as it's the one that's guaranteed to be available for use by the boot
process. (Unless you *really* mangle your init configuration... in
which case you probably broke the existing bootup before any of this
happened.)

Bill



From herrold at owlriver.com  Wed Oct 29 21:53:12 2008
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 29 Oct 2008 17:53:12 -0400 (EDT)
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908C716.2090906@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
Message-ID: <alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>

On Wed, 29 Oct 2008, Casey Dahlin wrote:

> I'd say I can count on one hand the number of distros that 
> aren't niche-only or effectively "living dead."

yeah - that Debian will never catch on

Rank  	Distribution  	H.P.D*
1 	Ubuntu 		2144
2 	openSUSE 	1870
3 	Mint 		1411
4 	Fedora 		1289
5 	PCLinuxOS 	1125

source: http://distrowatch.com/

nor the ones after that

7  	Mandriva  	986
8 	Dreamlinux 	621
9 	CentOS 		590

no-one uses RHEL so its community incarnation is irrelevant

-- Russ herrold



From notting at redhat.com  Wed Oct 29 21:54:16 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:54:16 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <gealof$4l0$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082E6B.7080304@hhs.nl> <ge9bsl$2fp$1@ger.gmane.org>
	<4908360D.8060900@hhs.nl>
	<alpine.LRH.2.00.0810291122590.954@arj.bjyevire.pbz>
	<20081029213322.GK25197@nostromo.devel.redhat.com>
	<gealof$4l0$1@ger.gmane.org>
Message-ID: <20081029215416.GM25197@nostromo.devel.redhat.com>

Matthew Woehlke (move_along at nothing_to_see_here) said: 
>>> Source for '1%' please? -- I simply don't believe it, having deployed 
>>> and managed 'homes' for thousands of users of Linux in NFS 
>>> environments.
>>
>> Add together the number of Linksys routers sold, the number of T-Mobile G1
>> users, the number of Tivos,
>
> Those surely are running a customized distro with everything not in use  
> disabled, so I don't think they count.

Well, it's "linux users". It does bring up the interesting side effect
that with the EEE, it's likely Xandros is the leading desktop Linux
distribution now, by an insanely wide margin.

(As for Fedora installs that use NFS, well, we can't have useful stats
without having machines report home as to what modules are loaded, what
filesystems are mounted, etc. Which brings up an entirely different flamewar.)

Bill



From notting at redhat.com  Wed Oct 29 21:57:49 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 17:57:49 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291738.26206.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291708.27051.sgrubb@redhat.com>
	<20081029211150.GH1371252@hiwaay.net>
	<200810291738.26206.sgrubb@redhat.com>
Message-ID: <20081029215749.GN25197@nostromo.devel.redhat.com>

Steve Grubb (sgrubb at redhat.com) said: 
> > That's the same way SELinux contexts are stored, right (so anything that
> > handles extended attributes for SELinux should handle this as well)?
> 
> Yes, that is the theory. I haven't personally done it, but if that doesn't 
> work we need a bz filed.

Which also implies that network FS support is the same pit of despair
that it is for SELinux labels?

Bill



From notting at redhat.com  Wed Oct 29 22:01:15 2008
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 29 Oct 2008 18:01:15 -0400
Subject: A suggestion regarding new features
In-Reply-To: <1225300511.3846.44.camel@mentor.gurulabs.com>
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
Message-ID: <20081029220115.GO25197@nostromo.devel.redhat.com>

Dax Kelson (dkelson at gurulabs.com) said: 
> Examples of "2c" include GRUB, udev/hal, ALSA, hda -> sda, LVM, FACLS
> on /dev files, CUPS, POSIX CAPs to replace SUID, etc. All distros moved
> these features in relative unison so I can toss that old knowledge out
> of my brain (and documentation).

Odddly enough, without any real cross-distro discussion about it. (In
fact, I'm fairly sure cups wasn't nearly in unison, SuSE shipped ALSA
before it was upstream, Fedora shipped libata for ATA at least a release
before anyone else, etc.)

In fact, most of these moves are because the kernel dropped things on userspace
and everyone had to scramble to catch up.

Bill



From mw_triad at users.sourceforge.net  Wed Oct 29 21:44:19 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 29 Oct 2008 16:44:19 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908C757.1000902@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
	<4908C757.1000902@gmail.com>
Message-ID: <gealfk$4td$1@ger.gmane.org>

Les Mikesell wrote:
> I'd expect most people who install fedora themselves to have at least a 
> couple of other OS's running concurrently.  Has anyone done a poll about 
> this recently?

Why would you expect that?

Granted, I may not be "most", but here's what I run:

Work:
- F9 (x64)
- Windows XP under KVM (and only for two apps that require either 
Windows or else bastardizing my Fedora install with IE + ActiveX, which 
I refuse to do ;-) )

Home:
- F6 (yeah, I know, I'll likely upgrade when I get a chance to bring the 
box down, now that I actually have available spare HD's)
- F9 (i686)
- Xandros (on my Asus EEE, and only because I haven't had time to find 
something better; how's Fedora on those?)

So, basically... I run Fedora. At home, certainly, my main desktop runs 
F9 and *only* F9.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
EPUN: program terminated due to egregious wordplay



From dpquigl at tycho.nsa.gov  Wed Oct 29 21:50:36 2008
From: dpquigl at tycho.nsa.gov (David P. Quigley)
Date: Wed, 29 Oct 2008 17:50:36 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081029210250.GE25197@nostromo.devel.redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<1225282082.21485.33.camel@rosebud>
	<20081029210250.GE25197@nostromo.devel.redhat.com>
Message-ID: <1225317036.31157.275.camel@moss-terrapins.epoch.ncsc.mil>

On Wed, 2008-10-29 at 17:02 -0400, Bill Nottingham wrote:
> seth vidal (skvidal at fedoraproject.org) said: 
> > > Are we ready to start considering moving away from SUID bits to 
> > > capabilities, in Fedora 11 maybe?
> > 
> > How does that mesh with networked file systems (nfs, samba)?
> 
> I don't have firsthand knowledge, but I would suspect 'badly'.
> 
> Bill
> 

Since the capabilities are stored in xattrs they will run into the same
problems that SELinux does. Labeled NFS is working to address this by
providing a per file attribute through NFSv4 for extra security
information. Additionally you could try NFSv4 named attributes for
capabilities but we have found that named attributes do not provide the
semantics needed for our purposes and would require changes to the NFSv4
xattr handler to use a hardcoded attribute name. The possibility of
multiple attributes being sent at the same time was initially raised by
BSD's MAC framework so we will have to look into separating the security
attribute into sections by some identifier (DOI maybe?).

Dave 



From randyn3lrx at gmail.com  Wed Oct 29 22:15:46 2008
From: randyn3lrx at gmail.com (Randall J. Berry)
Date: Wed, 29 Oct 2008 18:15:46 -0400
Subject: FC9: mock -r fedora-rawhide-i386 init fails
In-Reply-To: <1225179655.3897.38.camel@beck.corsepiu.local>
References: <1225179655.3897.38.camel@beck.corsepiu.local>
Message-ID: <4908E092.4010506@gmail.com>

Ralf Corsepius wrote:
> Hi,
> 
> Since this morning, initializing fedora-rawhide-i386 mock chroots fail
> for me on FC9:
> 
> # mock -r fedora-rawhide-i386 init
> INFO: mock.py version 0.9.9 starting...
> ...
> ERROR: Command failed: 
>  # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-i386/root/
> groupinstall buildsys-build
> ...
> /bin/sh: error while loading shared libraries: libtinfo.so.5: cannot
> open shared object file: No such file or directory
> error: %post(bash-3.2-28.fc10.i386) scriptlet failed, exit status 127
> ...
> 
> 
> I am able to reproduce this error on different fedora-9-i386 and
> fedora-9-x86_64 machines.
> 
> For whatever reason, so far, on fedora-9-x86_64, "mock -r
> fedora-rawhide-x86_64 init" doesn't fail, nor have I encountered this
> error on a fedora-rawhide-i386/fedora-9.92-i386 test-machine.
> 
> Ralf
> 
> 
I'm having the same issue trying to test build a package up for review.
F9-1386 mock builds just fine however this error stops the mock build in
rawhide-i386. Did I miss the solution to this or has one not yet been found?

Randy



From orion at cora.nwra.com  Wed Oct 29 22:20:15 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 29 Oct 2008 16:20:15 -0600
Subject: FC9: mock -r fedora-rawhide-i386 init fails
In-Reply-To: <4908E092.4010506@gmail.com>
References: <1225179655.3897.38.camel@beck.corsepiu.local>
	<4908E092.4010506@gmail.com>
Message-ID: <4908E19F.5060100@cora.nwra.com>

Randall J. Berry wrote:
> I'm having the same issue trying to test build a package up for review.
> F9-1386 mock builds just fine however this error stops the mock build in
> rawhide-i386. Did I miss the solution to this or has one not yet been found?

Should be fixed in the next rawhide build.

-- 
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 smooge at gmail.com  Wed Oct 29 22:24:57 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 29 Oct 2008 16:24:57 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212536.GG25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
Message-ID: <80d7e4090810291524w8892e6dgcacdab6026beac80@mail.gmail.com>

On Wed, Oct 29, 2008 at 3:25 PM, Bill Nottingham <notting at redhat.com> wrote:
> Dax Kelson (dkelson at gurulabs.com) said:
>> I would argue strongly that this change should not be made for the
>> following reasons (in no particular order):
>
> So, I'd like to take a different tack to this request. I don't want
> to be combative, but I'm genuinely curious.
>
> This change was documented as part of the BetterStartup feature on the
> wiki page ever since existed. For those playing at home, that's roughly a
> year and a half. No one complained on this list.
>
> The feature was proposed to FESCo, and approved. No one complained
> on this list.
>
> The feature was implemented, and landed in rawhide. No one complained
> on this list.
>
> Will mentioned it on the list, as an adjunct to a release note (more
> or less). Everybody showed up.
>

Well to be honest.. most of those places aren't in front of people's
faces. They are in front of your faces because you work in it 60+
hours a week every week. If I get 6 hours to play with Fedora on a
week I am ecstatic. If this was mentioned 1.5 years ago, 6 months ago,
etc.. it is gone from the brain of most of the people who may be
developing something completely different from this one feature. Thats
one of the issues with communication in a virtual environment.. you
must continuously do it because people join, leave, focus on their own
project, etc. Sadly putting it up on a web page is not enough because
there are too many webpages, too many twitters, etc for people to know
whats important until it smacks them in the face and says "Oh we
changed your XYZ, please redo all your docs for us."


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From dkelson at gurulabs.com  Wed Oct 29 22:25:15 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 16:25:15 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212536.GG25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
Message-ID: <1225319115.3846.143.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 17:25 -0400, Bill Nottingham wrote:
> Dax Kelson (dkelson at gurulabs.com) said: 
> > I would argue strongly that this change should not be made for the
> > following reasons (in no particular order):
> 
> So, I'd like to take a different tack to this request. I don't want
> to be combative, but I'm genuinely curious.
> 
> This change was documented as part of the BetterStartup feature on the
> wiki page ever since existed. For those playing at home, that's roughly a
> year and a half. No one complained on this list.

It is only subtlety documented. The page talks about gdm taking over the
existing VT (amongst a sea of other text on the page). I missed the
implication when I first read the page (several months ago).

Nowhere does it say, "the side effect of this is X will be on tty1 not
tty7".

> The feature was proposed to FESCo, and approved. No one complained
> on this list.
> 
> The feature was implemented, and landed in rawhide. No one complained
> on this list.
> 
> Will mentioned it on the list, as an adjunct to a release note (more
> or less). Everybody showed up.

I pulled down test 3 last week. I installed it yesterday and noticed the
change. This is the first rawhide I've been able to run, been too busy
with work. 

The timing of my email after Will's email is purely coincidence. My
email was being written anyway (then edited slightly after I saw Will's
email)

> Are people not running rawhide and the test releases? Are they not
> looking at features as they are proposed and being involved in the
> process? Are they just sitting around waiting to be outraged?

See above. I'd like to run rawhide more often and be involved more,
currently it is difficult juggling life (a common problem I'm sure).

Dax Kelson
Guru Labs



From randyn3lrx at gmail.com  Wed Oct 29 22:25:12 2008
From: randyn3lrx at gmail.com (Randall J. Berry)
Date: Wed, 29 Oct 2008 18:25:12 -0400
Subject: FC9: mock -r fedora-rawhide-i386 init fails
In-Reply-To: <4908E19F.5060100@cora.nwra.com>
References: <1225179655.3897.38.camel@beck.corsepiu.local>	<4908E092.4010506@gmail.com>
	<4908E19F.5060100@cora.nwra.com>
Message-ID: <4908E2C8.2090801@gmail.com>

Orion Poplawski wrote:
> Randall J. Berry wrote:
>> I'm having the same issue trying to test build a package up for review.
>> F9-1386 mock builds just fine however this error stops the mock build in
>> rawhide-i386. Did I miss the solution to this or has one not yet been
>> found?
> 
> Should be fixed in the next rawhide build.
> 
 Thanks Orion



From dbn.lists at gmail.com  Wed Oct 29 22:33:21 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Wed, 29 Oct 2008 15:33:21 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029215123.GL25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
Message-ID: <91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>

On Wed, Oct 29, 2008 at 2:51 PM, Bill Nottingham <notting at redhat.com> wrote:
> Dan Nicholson (dbn.lists at gmail.com) said:
>> > * The default behavior of X on tty7 has been in place since the
>> > beginning (almost a decade and a half).
>>
>> This is actually convention, not any enforced behavior. There is
>> nothing magic about tty7. It just so happens that the typical init
>> configuration has been gettys on the first 6 ttys. When X starts, it
>> simply chooses the next available VT. This has always been
>> configurable - /etc/inittab with sysvinit and now
>> /etc/event.d/tty[1-6] with upstart. Personally, I always thought that
>> 6 consoles was more than I've ever wanted, so for me the "default" X
>> was tty4.
>
> The fact that it's just convention based on the number of ttys
> configured (that the admin can override) also means that any
> change to unilaterally swtich to tty7 in plymouth means you're
> potentially stomping on a local-use-for-something-else tty. I
> don't think telling admins "if you want to run top on tty7, or
> have already configured your system to do so, you need to edit some
> plymouth thing and re-run mkinitrd for any kernel you want to boot"
> is something that's necessarily going to fly.

I didn't suggest having plymouth change to tty7. In fact, I posted a
patch so that it's all controlled from /etc/sysconfig/desktop instead
of having plymouth and gdm work behind the scenes.

https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02516.html

Does that seem reasonable at all?

--
Dan



From seg at haxxed.com  Wed Oct 29 22:32:34 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 29 Oct 2008 17:32:34 -0500
Subject: Don't hibernate, crashing is faster.
In-Reply-To: <1225315747.32201.84.camel@dimi.lattica.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>  <49085FCD.9060707@gmail.com>
	<1225315189.598.62.camel@localhost.localdomain>
	<1225315747.32201.84.camel@dimi.lattica.com>
Message-ID: <1225319554.598.69.camel@localhost.localdomain>

On Wed, 2008-10-29 at 17:29 -0400, Dimi Paun wrote:
> On Wed, 2008-10-29 at 16:19 -0500, Callum Lerwick wrote:
> > Hibernate is the Wrong Thing.
> > 
> > http://lwn.net/Articles/191059/
> 
> Absolutely, if you want to shutdown, just crash the box.
> Shutdown should be <3s. All the nonsense Fedora does now
> with shutting down every daemon is just silly.
> 
> However, that has nothing to do with hibernate. This is because
> a major reason a person doesn't want to reboot is that the state
> of the desktops, apps, etc. is lost. And no crash-only software
> can solve that problem.

Read closer, that's exactly the problem it solves. Crash only software
restarts in exactly the same state as when it crashed. Like firefox,
only without the dialog...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/f8014519/attachment.sig>

From dimi at lattica.com  Wed Oct 29 22:42:20 2008
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 29 Oct 2008 18:42:20 -0400
Subject: Don't hibernate, crashing is faster.
In-Reply-To: <1225319554.598.69.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>  <49085FCD.9060707@gmail.com>
	<1225315189.598.62.camel@localhost.localdomain>
	<1225315747.32201.84.camel@dimi.lattica.com>
	<1225319554.598.69.camel@localhost.localdomain>
Message-ID: <1225320140.32201.110.camel@dimi.lattica.com>


On Wed, 2008-10-29 at 17:32 -0500, Callum Lerwick wrote:
> Read closer, that's exactly the problem it solves. Crash only software
> restarts in exactly the same state as when it crashed. Like firefox,
> only without the dialog...

Yeah, yeah, but until you instrument every single app to do that
properly, hibernate has its use.

And even if you manage to do that, it's not clear that you want
to get rid of the two things, because starting from a clean slate
has its uses.

Fifefox has little state to save, and sometimes I _have_ to restart
clean 'cause it will be too slow anyway. But good luck to you getting
a complex app to save every freaking bit of crap.

When you're done in the year 2040, we'll look at getting rid of
hibernate. Meanwhile, *today* you need it to operate a laptop
properly.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From lsof at nodata.co.uk  Wed Oct 29 22:54:37 2008
From: lsof at nodata.co.uk (nodata)
Date: Wed, 29 Oct 2008 23:54:37 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212536.GG25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
Message-ID: <1225320877.2805.0.camel@sb-home>

Am Mittwoch, den 29.10.2008, 17:25 -0400 schrieb Bill Nottingham:
> Dax Kelson (dkelson at gurulabs.com) said: 
> > I would argue strongly that this change should not be made for the
> > following reasons (in no particular order):
> 
> So, I'd like to take a different tack to this request. I don't want
> to be combative, but I'm genuinely curious.
> 
> This change was documented as part of the BetterStartup feature on the
> wiki page ever since existed. For those playing at home, that's roughly a
> year and a half. No one complained on this list.
> 
> The feature was proposed to FESCo, and approved. No one complained
> on this list.
> 
> The feature was implemented, and landed in rawhide. No one complained
> on this list.
> 
> Will mentioned it on the list, as an adjunct to a release note (more
> or less). Everybody showed up.
> 
> Are people not running rawhide and the test releases? Are they not
> looking at features as they are proposed and being involved in the
> process? Are they just sitting around waiting to be outraged?

You've answered the question yourself.

The mailing list is in front of more eyes than the wiki.



From mattdm at mattdm.org  Wed Oct 29 23:31:22 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 29 Oct 2008 19:31:22 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029215123.GL25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
Message-ID: <20081029233122.GA14058@jadzia.bu.edu>

On Wed, Oct 29, 2008 at 05:51:23PM -0400, Bill Nottingham wrote:
> The fact that it's just convention based on the number of ttys 
> configured (that the admin can override) also means that any
> change to unilaterally swtich to tty7 in plymouth means you're
> potentially stomping on a local-use-for-something-else tty. I
> don't think telling admins "if you want to run top on tty7, or
> have already configured your system to do so, you need to edit some
> plymouth thing and re-run mkinitrd for any kernel you want to boot"
> is something that's necessarily going to fly.

For what it's worth?, I didn't notice this change because I've for years
configured my X sessions to be on F11 and F12 because the end of the row is
easier for my family members to remember than random keys in the middle.

Well, and also because KDM still defaults to vt7 in the current kdmrc in
rawhide, and I had to switch to KDM when GDM got all broken with multiple X
servers a few months ago. (There's a bug in bugzilla for that somewhere.)



1. Approximately nothing. I was just feeling left out what with having nothing
meaningful to contribute to this thrilling thread.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From bojan at rexursive.com  Wed Oct 29 23:31:29 2008
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 29 Oct 2008 23:31:29 +0000 (UTC)
Subject: Reasons to preseve X on tty7
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
Message-ID: <loom.20081029T233025-249@post.gmane.org>

Jeff Spaleta <jspaleta <at> gmail.com> writes:

> linuxconf!

+1.

Absolutely! Otherwise, people will never learn how to remove RPMs from the
system ;-)

--
Bojan



From lesmikesell at gmail.com  Wed Oct 29 23:39:33 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 18:39:33 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225312444.23396.125.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225281461.21057.0.camel@optimus>	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>	<1225301630.3846.66.camel@mentor.gurulabs.com>	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>	<4908BA6C.5030806@gmail.com>	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>	<geaflr$e29$1@ger.gmane.org>
	<4908C484.5040809@gmail.com>	<1225311787.23396.121.camel@nibbler.dlib.indiana.edu>	<1225312189.21485.81.camel@rosebud>
	<1225312444.23396.125.camel@nibbler.dlib.indiana.edu>
Message-ID: <4908F435.8080001@gmail.com>

Brian Wheeler wrote:
> On Wed, 2008-10-29 at 16:29 -0400, seth vidal wrote:
>> On Wed, 2008-10-29 at 16:23 -0400, Brian Wheeler wrote:
>>> On Wed, 2008-10-29 at 15:16 -0500, Les Mikesell wrote:
>>>> Matthew Woehlke wrote:
>>>>> B
>>>>>> Well, I'm a long time user and I don't see what the big deal is.  There
>>>>>> are several people on this list which seem to announce that "<insert
>>>>>> change here> is the one that's going to drive long time users away"
>>>>>> and/or "time to look for a new distribution" semi-regularly... yet they
>>>>>> (long time users) are still here.
>>>>> Maybe they just haven't found anything better (yet)?
>>>> Or, speaking for myself, not actually running fedora anymore, just 
>>>> watching to see how much damage is going to make its way into the next 
>>>> RHEL and clones.
>>> So, out of curiosity...Do you run X on your RHEL machines? 

They are mostly CentOS, but yes, I run X on the ones that aren't 
overloaded or overexposed, but I mostly interact via freenx and a more 
or less roving NX client.  For a long time I used an FC6 box as my main 
desktop machine but for reasons that aren't particularly interesting, 
have moved it to a less convenient location where it continues to run 
tape backups and now park an NX login on one screen of a dual-headed XP 
box and can barely tell the difference.  Which means I can just as 
easily work directly on boxes in remote data centers so I do a lot less 
locally - and I can pick up the desktops on a laptop or my home machine 
with everything still running.

>>> Are you
>>> going to switch from RHEL when this change makes it into RHEL6 or
>>> whatever?  

At least if a change like this happens it would stay for long enough to 
be worth remembering it.

> I wasn't trying to be unfair.  One of the main reasons I use fedora is
> to find out what is coming in RHEL.  I just genuinely curious
> considering that alot of his statements on this topic seem to imply that
> people will leave due to this change (and possibly others).

It's not so much about the impact of any single change that would make 
that would cause someone to switch distros, it is more about whether you 
trust it to be usable in the future, continuing to do as you've learned 
to expect and continuing to run the scripts you've written to it's 
conventions.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From sundaram at fedoraproject.org  Wed Oct 29 23:49:53 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Oct 2008 05:19:53 +0530
Subject: Reasons to preseve X on tty7
In-Reply-To: <alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
Message-ID: <4908F6A1.4020509@fedoraproject.org>

R P Herrold wrote:
> On Wed, 29 Oct 2008, Casey Dahlin wrote:
> 
>> I'd say I can count on one hand the number of distros that aren't 
>> niche-only or effectively "living dead."
> 
> yeah - that Debian will never catch on
> 
> Rank      Distribution      H.P.D*
> 1     Ubuntu         2144
> 2     openSUSE     1870
> 3     Mint         1411
> 4     Fedora         1289
> 5     PCLinuxOS     1125
> 
> source: http://distrowatch.com/

Try finding something more relevant than the number of people clicking a 
particular distrowatch page everyday. By this count, a lot of the very 
widely deployed distros are completely out. Xandros (via eeepc) for 
instance or RHEL which is by far the most popular enterprise Linux 
distribution. A number of customized distros are widely used by never 
reported there either.

Rahul





From cdahlin at redhat.com  Thu Oct 30 00:49:08 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 20:49:08 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
Message-ID: <49090484.5090704@redhat.com>

R P Herrold wrote:
> On Wed, 29 Oct 2008, Casey Dahlin wrote:
>
>> I'd say I can count on one hand the number of distros that aren't 
>> niche-only or effectively "living dead."
>
> yeah - that Debian will never catch on
>
> Rank      Distribution      H.P.D*
> 1     Ubuntu         2144
> 2     openSUSE     1870
> 3     Mint         1411
> 4     Fedora         1289
> 5     PCLinuxOS     1125
>
> source: http://distrowatch.com/
>
> nor the ones after that
>
> 7      Mandriva      986
> 8     Dreamlinux     621
> 9     CentOS         590
>
> no-one uses RHEL so its community incarnation is irrelevant
>
> -- Russ herrold
>
Unless you take "count on one hand" literally, you've handsomely proved 
my point.

--CJD



From cdahlin at redhat.com  Thu Oct 30 00:50:20 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 20:50:20 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225315942.21485.94.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<1225315942.21485.94.camel@rosebud>
Message-ID: <490904CC.6090606@redhat.com>

seth vidal wrote:
> On Wed, 2008-10-29 at 17:25 -0400, Bill Nottingham wrote:
>   
>> Dax Kelson (dkelson at gurulabs.com) said: 
>>     
>>> I would argue strongly that this change should not be made for the
>>> following reasons (in no particular order):
>>>       
>
>   
>> Are people not running rawhide and the test releases?
>>     
>
> Fairly obviously, they are not.
>
>
>   
>>  Are they not looking at features as they are proposed and being involved in the
>> process? 
>>     
>
> Also, no, or not as much
>
>   
>> Are they just sitting around waiting to be outraged?
>>     
>
> No, but they will get upset when they're surprised by something.
>
>
>
> I think the first two above  are more OUR problem than their problem,
> though.
>   
Beauty of a community run distro: We are They.

--CJD



From jspaleta at gmail.com  Thu Oct 30 00:57:20 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 16:57:20 -0800
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225315942.21485.94.camel@rosebud>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<1225315942.21485.94.camel@rosebud>
Message-ID: <604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>

On Wed, Oct 29, 2008 at 1:32 PM, seth vidal
> I think the first two above  are more OUR problem than their problem,
> though.

So no one notices the process communication now. I'm not seeing anyone
suggest a better way to communicate these sorts of things.

-jef"I guess I could start writing a weekly content column called the
Ye Ol' Curmudgeon as part of Fedora Mag where I discuss how new
features are going to impact people who pine for the featureset of rhl
6.2.  Though I don't know if I can muster enough sarcasm to keep it
fresh and entertaining on a regular basis."spaleta



From cdahlin at redhat.com  Thu Oct 30 01:04:09 2008
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 29 Oct 2008 21:04:09 -0400
Subject: A suggestion regarding new features
In-Reply-To: <1225300511.3846.44.camel@mentor.gurulabs.com>
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
Message-ID: <49090809.5050804@redhat.com>

Dax Kelson wrote:
> Progress is great, new shiny frobnicators are wonderful. What many
> people (myself included) object to is when old behaviors and
> compatibility is broken NEEDLESSLY.  Let's have our cake and eat it too!
>
> When implementing new features what about using a decision tree that
> looks like the following:
>
> ======================================================
>
> Step 1. Does $NEWFEATURE implementation change old behaviors or break
> compatibility? 
>
> a) NO -> Great go for it! Let's all eat cake!
> b) YES -> See step 2
>
> Step 2. Can $NEWFEATURE be implemented so that it doesn't change old
> behaviors or break compatibility?
>
> a) NO -> Uh oh, see step 3.
> b) YES preserve both -> Excellent. Let's all eat cake!
> c) YES preserve compatibility -> Great no "exceptions". Let's all eat
> cake!
>
> Examples of "2c" include GRUB, udev/hal, ALSA, hda -> sda, LVM, FACLS
> on /dev files, CUPS, POSIX CAPs to replace SUID, etc. All distros moved
> these features in relative unison so I can toss that old knowledge out
> of my brain (and documentation).
>
> Step 3. Does the benefit of $NEWFEATURE outweigh the cost of changing
> the old behavior or breaking compatibility? Obviously this can be
> subjective.
>
> a) NO -> Good effort. Have you considered picking one of the other many
> areas in Linux that need improving and working on that?
> b) YES -> OK, $NEWFEATURE must be really awesome. Please double check
> that you can't resolve this in Step 2. So Step 2 is a no go? OK, let's
> do it.
>
> ======================================================
>
>   

I reject your step 3, and substitute my own:

3) If you'd never seen linux before and knew nothing about it, and you 
were shown both the old and potential new behavior, how would the old 
behavior appear?
a) It'd be better -> Time to rethink things.
b) It'd be about the same -> Go to 4
c) It'd be worse -> Probably worth pushing for, but get a lot of 
opinions. You've been wrong before.
d) In the face of the new solution, it'd appear wrong/broken -> Do it.

4) Is this change really that significant?
a) Yes -> same as 3c
b) No -> Do it.

--CJD



From smooge at gmail.com  Thu Oct 30 01:37:51 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 29 Oct 2008 19:37:51 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<1225315942.21485.94.camel@rosebud>
	<604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>
Message-ID: <80d7e4090810291837m19b4064co7ecb1799db1d4e40@mail.gmail.com>

On Wed, Oct 29, 2008 at 6:57 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Wed, Oct 29, 2008 at 1:32 PM, seth vidal
>> I think the first two above  are more OUR problem than their problem,
>> though.
>
> So no one notices the process communication now. I'm not seeing anyone
> suggest a better way to communicate these sorts of things.
>
> -jef"I guess I could start writing a weekly content column called the
> Ye Ol' Curmudgeon as part of Fedora Mag where I discuss how new
> features are going to impact people who pine for the featureset of rhl
> 6.2.  Though I don't know if I can muster enough sarcasm to keep it
> fresh and entertaining on a regular basis."spaleta
>

Actually I was thinking about this on the way home. One of the issues
with communicating these things is that we do have to regularly spam
lists with whats going on... its part of being a big group.. you have
to communicate regularly, clearly, and precisely. You will still get
people who will say "What do you mean TTY1 is now a pink pony?" but it
also allows for more people who are only able to catch up on things
once a week or so to know whats going on.

1. Groups need to know where to give regular reports. fedora-devel,
fedora-list, fedora-pony-list?
2. People need to know where to discuss those reports.. if its
XYZ-list thats fine.. but it needs to be clear.
3. Groups need to be able to communicate what they are doing with
regular intervals in incremental steps:
  A. We implemented pony this week. Please see
http://wiki/PonyProject_Stage1 for what this looks like, and the
changes it has done.
  B. We implemented pink this week. We are looking for people to see
if this breaks any apps that are looking for old purple pony's.
Mockups at BLAH with instructions to test or you can use virt.img to
test for yourself.

I think those 3 things would help a lot.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From smooge at gmail.com  Thu Oct 30 02:13:54 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 29 Oct 2008 20:13:54 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212536.GG25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
Message-ID: <80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>

On Wed, Oct 29, 2008 at 3:25 PM, Bill Nottingham <notting at redhat.com> wrote:
> Dax Kelson (dkelson at gurulabs.com) said:
>> I would argue strongly that this change should not be made for the
>> following reasons (in no particular order):
>
> So, I'd like to take a different tack to this request. I don't want
> to be combative, but I'm genuinely curious.
>
> This change was documented as part of the BetterStartup feature on the
> wiki page ever since existed. For those playing at home, that's roughly a
> year and a half. No one complained on this list.
>
> The feature was proposed to FESCo, and approved. No one complained
> on this list.
>
> The feature was implemented, and landed in rawhide. No one complained
> on this list.
>
> Will mentioned it on the list, as an adjunct to a release note (more
> or less). Everybody showed up.
>
> Are people not running rawhide and the test releases? Are they not
> looking at features as they are proposed and being involved in the
> process? Are they just sitting around waiting to be outraged?
>

Hmmm on the way home from work, my old man brain cells kicked and I
realized where I saw this before:

A long time ago in a company in RDU, NC, USA there was a product
called Red Hat Linux. When Red Hat Linux 6.0 was about to come out, we
got new boxes to look at and they said something like: Red Hat Linux
6.. there was a hue and a cry from various developers and tech support
people that this was a change out of no-where. Management and
marketing reminded people that the lead developers had been to all the
meetings where it had been announced, and it had been on the various
people's white boards for months. After a bunch of arguing etc it was
decided that it would be called 6.0 and we would revisit it for 7.
Which it was but this time it was better communicated and while
various developers and support techs would talk over lunch that it was
marketing taking over the company... people were more aware and new it
was going to happen. By the time Red Hat Linux 8 and 9 came out all
that was left was dealing with the various customer culture that
expected a RHL 8.1 versus a 9.. and by the time the Fedora numberings
were in place.. there wasnt much talk about FC1.1... in fact the
developers seemed to be all for calling it 2.

And while this was just a naming change.. it was a big deal to the
cultures involved. Technical changes on the other hand have a bigger
issue especially when documentation may need to be reprinted, training
has to be updated and you always end up with the chance you are going
to relive the great egcs or similar changes where it looks great for
the small amount of beta testers but not everywhere.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From tgl at redhat.com  Thu Oct 30 02:57:06 2008
From: tgl at redhat.com (Tom Lane)
Date: Wed, 29 Oct 2008 22:57:06 -0400
Subject: kde needs mysql-server ?? 
In-Reply-To: <385866f0810291439w1d22bac9sbbca1ed6f4ab7e74@mail.gmail.com> 
References: <48FF046A.3000501@nobugconsulting.ro>
	<200810241243.12892.Juha.Tuomala@iki.fi>
	<385866f0810240446j2ccd6cd8s749f39c9da60ccb0@mail.gmail.com>
	<ge5dn0$6tb$1@ger.gmane.org>
	<385866f0810291439w1d22bac9sbbca1ed6f4ab7e74@mail.gmail.com>
Message-ID: <3363.1225335426@sss.pgh.pa.us>

"Muayyad AlSadi" <alsadi at gmail.com> writes:
>> Why not use sqlite?

> We tried. Really. It can't handle the concurrent access very well, in
> the best case this means very slow operations, but we've also seen
> deadlocks and failing transactions. Once that's fixed in sqlite,
> adjusting Akonadi to use it again instead of MySQL is no problem.

[ raised eyebrow... ]  mysql's reputation for concurrent performance
is not exactly stellar either.  I grant that table-wide locks are better
than database-wide locks, but unless you have a lot of independently
accessed tables in your DB design, it won't help much.

			regards, tom lane



From herrold at owlriver.com  Thu Oct 30 03:13:58 2008
From: herrold at owlriver.com (R P Herrold)
Date: Wed, 29 Oct 2008 23:13:58 -0400 (EDT)
Subject: Reasons to preseve X on tty7
In-Reply-To: <4908F6A1.4020509@fedoraproject.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<4908C716.2090906@redhat.com>
	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>
	<4908F6A1.4020509@fedoraproject.org>
Message-ID: <alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>

On Thu, 30 Oct 2008, Rahul Sundaram wrote:

>> source: http://distrowatch.com/
>
> Try finding something more relevant than the number of 
> people clicking a particular distrowatch page everyday.

Keep your venom -- I decline to ingest it.  It is easy to cast 
stones, but the point remains that there are tangible numbers, 
and that the 'one hand' argument is bunk.

I offered the best metric I know of, one which requires 
sustained effort to rig, and (having provided both the lead 
site's hosting for a while, and also a mirror), I know a bit 
about how such 'padding' is detectable with the code then 
used.

Find a better metric yourself, and tell us all.

-- Russ herrold



From dcbw at redhat.com  Thu Oct 30 03:39:25 2008
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 29 Oct 2008 23:39:25 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225302097.3846.74.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
	<gea202$mbt$1@ger.gmane.org>
	<604aa7910810290932m252c8a28pca37156ac252d5bb@mail.gmail.com>
	<1225302097.3846.74.camel@mentor.gurulabs.com>
Message-ID: <1225337965.32092.6.camel@localhost.localdomain>

On Wed, 2008-10-29 at 11:41 -0600, Dax Kelson wrote:
> On Wed, 2008-10-29 at 08:32 -0800, Jeff Spaleta wrote:
> > On Wed, Oct 29, 2008 at 8:11 AM, Matthew Woehlke
> > > it don't appear to care about the objections; they're not responding
> > > intelligently to them,
> > 
> > I don't have an intelligent response to any argument which essentially
> > comes down to "tradition."  Have the traditionalists pulled put forth
> > any consensus document like an RFC to support that at some point in
> > time a group of people actually talk through the need for doing gettys
> > a certain way?
> > 
> > Traditions which codify a collection of arbitrary decisions..are
> > traditions I will gladly help throw into the fire.
> 
> Jef,
> 
> Not you too. My arguments are NOT "essentially" tradition. One o my 9
> distinct arguments was Fedora becomes inconsistent with itself.
> 
> Another was that Fedora becomes incompatible with other Linux
> distributions. Do we really want to go down the path where we have to
> have "Fedora experts", "SUSE experts, "Ubuntu experts", etc and there is
> no such thing as a "Linux expert"? That were the path of frivolous
> incompatibilities leads.

It's not an incompatible change at all.  Your programs will all still
run exactly the same way they do now.  Your config files haven't
changed.  It still looks exactly the same when you boot up.

How is this _any_ different than, say, switching between a Dell and
Thinkpad where the Ctrl and Fn keys are swapped?  Annoying the first 5
minutes, but then you learn.  Or you remap them if you really care.
Same with vt1 vs. vt7.  Come on people...

Dan




From dcbw at redhat.com  Thu Oct 30 03:43:52 2008
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 29 Oct 2008 23:43:52 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225302097.3846.74.camel@mentor.gurulabs.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
	<gea202$mbt$1@ger.gmane.org>
	<604aa7910810290932m252c8a28pca37156ac252d5bb@mail.gmail.com>
	<1225302097.3846.74.camel@mentor.gurulabs.com>
Message-ID: <1225338232.32092.9.camel@localhost.localdomain>

On Wed, 2008-10-29 at 11:41 -0600, Dax Kelson wrote:
> On Wed, 2008-10-29 at 08:32 -0800, Jeff Spaleta wrote:
> > On Wed, Oct 29, 2008 at 8:11 AM, Matthew Woehlke
> > > it don't appear to care about the objections; they're not responding
> > > intelligently to them,
> > 
> > I don't have an intelligent response to any argument which essentially
> > comes down to "tradition."  Have the traditionalists pulled put forth
> > any consensus document like an RFC to support that at some point in
> > time a group of people actually talk through the need for doing gettys
> > a certain way?
> > 
> > Traditions which codify a collection of arbitrary decisions..are
> > traditions I will gladly help throw into the fire.
> 
> Jef,
> 
> Not you too. My arguments are NOT "essentially" tradition. One of my 9
> distinct arguments was Fedora becomes inconsistent with itself.
> 
> Another was that Fedora becomes incompatible with other Linux
> distributions. Do we really want to go down the path where we have to
> have "Fedora experts", "SUSE experts, "Ubuntu experts", etc and there is
> no such thing as a "Linux expert"? That were the path of frivolous
> incompatibilities leads.

Plus, distros are already incompatible.  Debian has a completely
different network config system than Fedora does, same with SUSE.  The
distros put their config files in different places.  There are two main
packaging formats.  Having a vt somewhere else is _soooo_ much less
incompatible than apt vs. rpm.

Dan




From kwhiskerz at gmail.com  Thu Oct 30 03:48:12 2008
From: kwhiskerz at gmail.com (Petrus de Calguarium)
Date: Wed, 29 Oct 2008 21:48:12 -0600
Subject: 2 ext4 queries
References: <geabnf$ugs$1@ger.gmane.org> <4908BD2F.5010907@redhat.com>
Message-ID: <gebaps$qaa$2@ger.gmane.org>

Eric Sandeen wrote:

> While ext4 is largely out of its development phase, it is still a
> relatively new filesystem so you would do well (as you would with any
> filesystem, to be honest) to test it in your environment before you
> deploy it for real data, and keep good backups.
> 
That's what common sense told me, but I didn't want to hear it, as I was eager to migrate. I think common sense must prevail; I have too much invested.

> ext4 filesystems formatted today should always be
> compatible with ext4 code in the future.
> 
That is good to hear. I formatted some non-critical partitions and hope not to need to do it over again (not that it is a HUGE hassle).




From zaitcev at redhat.com  Thu Oct 30 04:05:32 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 29 Oct 2008 22:05:32 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029212536.GG25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
Message-ID: <20081029220532.dcfc549e.zaitcev@redhat.com>

On Wed, 29 Oct 2008 17:25:36 -0400, Bill Nottingham <notting at redhat.com> wrote:

> Are people not running rawhide and the test releases? Are they not
> looking at features as they are proposed and being involved in the
> process? Are they just sitting around waiting to be outraged?

I encountered it in Rawhide some time ago, and my first thought was
that the X server was broken somehow. However, in a couple of
minutes I figured out what was happening. It wasn't a problem for me.
Maybe Dax paniced, hit <ctrl><alt><backspace>, and now nurses a grudge.

-- Pete



From lesmikesell at gmail.com  Thu Oct 30 04:09:32 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 23:09:32 -0500
Subject: Don't hibernate, crashing is faster.
In-Reply-To: <1225315189.598.62.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>
	<49085FCD.9060707@gmail.com>
	<1225315189.598.62.camel@localhost.localdomain>
Message-ID: <4909337C.3030302@gmail.com>

Callum Lerwick wrote:
> On Wed, 2008-10-29 at 08:06 -0500, Les Mikesell wrote:
>> I don't quite understand the obsession with making boot time faster 
>> anyway.  Machines should only boot when they have a new kernel to 
>> install.  If they aren't needed all the time they should sleep or 
>> hibernate, waking up with everything still running.
> 
> Hibernate is the Wrong Thing.
> 
> http://lwn.net/Articles/191059/


I'm really more interested in sleeping than hibernating.  Restart time 
should be 15-20 seconds including typing the password and bringing the 
network back up.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From zaitcev at redhat.com  Thu Oct 30 04:11:11 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 29 Oct 2008 22:11:11 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <80d7e4090810291837m19b4064co7ecb1799db1d4e40@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<1225315942.21485.94.camel@rosebud>
	<604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>
	<80d7e4090810291837m19b4064co7ecb1799db1d4e40@mail.gmail.com>
Message-ID: <20081029221111.a6a1e629.zaitcev@redhat.com>

On Wed, 29 Oct 2008 19:37:51 -0600, "Stephen John Smoogen" <smooge at gmail.com> wrote:

> Actually I was thinking about this on the way home. One of the issues
> with communicating these things is that we do have to regularly spam
> lists with whats going on... its part of being a big group.. you have
> to communicate regularly, clearly, and precisely. []

Look, the problem here is, it was inconceivable to everyone involved
that this little thing will get someone's panty in a wad. It's utter
non-problem, despite all the pages and pages and pages of rhethoric
about some manuals or whatnot. It's madness. Attempting to communicate
any such insignificant matter regularly, clearly, and precisely is
a recipy for people's eyes glazing over. I don't even read meeting
minutes these days. If things like X on tty1 start to appear in
regular communications, I'll have to filter out more.

-- Pete



From mattdm at mattdm.org  Thu Oct 30 04:45:36 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 30 Oct 2008 00:45:36 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
Message-ID: <20081030044536.GA10407@jadzia.bu.edu>

On Wed, Oct 29, 2008 at 08:13:54PM -0600, Stephen John Smoogen wrote:
> And while this was just a naming change.. it was a big deal to the
> cultures involved. Technical changes on the other hand have a bigger

It *was* a big deal, because at that point, Red Hat had built up a solid
tradition of making really questionable .0 releases, decent .1 releases, and
great .2 releases. 

Hmmm. If we consider 7.3 to _really_ be 8.0, 8 to really be 8.1, and 9 to be
8.2, this held true for that series too. Maybe even for FC1, FC2, and FC3.
:)


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From lesmikesell at gmail.com  Thu Oct 30 04:53:07 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 23:53:07 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <49086038.6060800@pingoured.fr>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>	<49085FCD.9060707@gmail.com>
	<49086038.6060800@pingoured.fr>
Message-ID: <49093DB3.3030907@gmail.com>

Pierre-Yves wrote:
> Les Mikesell wrote:
>> I don't quite understand the obsession with making boot time faster 
>> anyway.  Machines should only boot when they have a new kernel to 
>> install.  If they aren't needed all the time they should sleep or 
>> hibernate, waking up with everything still running.
>>
> 
> My problem here are your two last words *still running*...
> Maybe especially on my laptop.
> 

Why is that a problem? I don't have a fedora-loaded laptop handy but 
ubuntu seems to sleep and wake up OK.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Thu Oct 30 04:58:36 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 29 Oct 2008 23:58:36 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029135415.GA6665@wolff.to>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<555910.26860.qm@web32807.mail.mud.yahoo.com>
	<20081029135415.GA6665@wolff.to>
Message-ID: <49093EFC.1050603@gmail.com>

Bruno Wolff III wrote:
> I always thought it was odd it was on vt7 instead of vt1 or vt12. Why pick
> one in the middle to be special. (Note that when I used to use vts I
> had 12 configured.)

It just happens to be the first free one.  I remember having virtual 
terminals running Dell's version of SysV linux on a 486 box in the early 
90's.  Somebody probably copied their inittab file with 6 getty's...

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Thu Oct 30 05:06:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 00:06:14 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081030044536.GA10407@jadzia.bu.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<20081029212536.GG25197@nostromo.devel.redhat.com>	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
	<20081030044536.GA10407@jadzia.bu.edu>
Message-ID: <490940C6.3070701@gmail.com>

Matthew Miller wrote:
> On Wed, Oct 29, 2008 at 08:13:54PM -0600, Stephen John Smoogen wrote:
>> And while this was just a naming change.. it was a big deal to the
>> cultures involved. Technical changes on the other hand have a bigger
> 
> It *was* a big deal, because at that point, Red Hat had built up a solid
> tradition of making really questionable .0 releases, decent .1 releases, and
> great .2 releases. 
> 
> Hmmm. If we consider 7.3 to _really_ be 8.0, 8 to really be 8.1, and 9 to be
> 8.2, this held true for that series too. Maybe even for FC1, FC2, and FC3.
> :)

Doesn't fit with the code. 7.3 was the last in the 'increasingly 
reliable' series.  8 and 9 each introduced new breakage that was never 
fixed.  RHEL3.x would have been the logical successor to 7.3 in terms of 
being the next thing you would want to trust.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lesmikesell at gmail.com  Thu Oct 30 05:18:56 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 00:18:56 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <gealfk$4td$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>	<4908C757.1000902@gmail.com>
	<gealfk$4td$1@ger.gmane.org>
Message-ID: <490943C0.4070703@gmail.com>

Matthew Woehlke wrote:
> Les Mikesell wrote:
>> I'd expect most people who install fedora themselves to have at least 
>> a couple of other OS's running concurrently.  Has anyone done a poll 
>> about this recently?
> 
> Why would you expect that?

Because it is experimental and high maintenance to run.  I expect that 
people who choose it because it is 'new' will also be interested in 
several other new distos for comparison, and people who have work that 
needs to be done even if today's update crashes will have a more stable 
system around or they'll run under VMware.  Plus, much of the point of 
using unix-like systems is that they network well, so many users will 
probably be running client-server setups just on general principles - 
and they'll get tired of updating the server side at the rate needed to 
maintain fedora.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From smooge at gmail.com  Thu Oct 30 05:19:03 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 29 Oct 2008 23:19:03 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081030044536.GA10407@jadzia.bu.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
	<20081030044536.GA10407@jadzia.bu.edu>
Message-ID: <80d7e4090810292219o5ac553c5qbe4415b02af0be59@mail.gmail.com>

On Wed, Oct 29, 2008 at 10:45 PM, Matthew Miller <mattdm at mattdm.org> wrote:
> On Wed, Oct 29, 2008 at 08:13:54PM -0600, Stephen John Smoogen wrote:
>> And while this was just a naming change.. it was a big deal to the
>> cultures involved. Technical changes on the other hand have a bigger
>
> It *was* a big deal, because at that point, Red Hat had built up a solid
> tradition of making really questionable .0 releases, decent .1 releases, and
> great .2 releases.
>

Yes there is a tradition involved and people put a lot of trust into
tradition to keep the idea that the world is understandable somewhere.
ALT-F1 being a terminal is a tradition built up from somewhere around
MCC and SLS. What some people consider a simple configuration file
change is to someone else something important. And its going to get a
reaction.





-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From rawhide at fedoraproject.org  Thu Oct 30 05:48:02 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 30 Oct 2008 05:48:02 +0000 (UTC)
Subject: rawhide report: 20081029 changes
Message-ID: <20081030054802.DFF621F824B@releng2.fedora.phx.redhat.com>

Removed package atitvout
Updated Packages:

alienarena-7.20-5.fc10
----------------------
* Wed Oct 29 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 7.20-5
- use /bin/bash for the scripts due to the export LD_LIBRARY_PATH


anjuta-2.24.1-1.fc10
--------------------
* Tue Oct 28 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 1:2.24.1-1
- Version bump to 2.24.1.
- Makefile problems fixed by upstream.
- Added 'Requires: git' and 'BuildRequires: e2fsprogs-devel intltool'.
- libanjuta-egg.so has been dropped.


audit-1.7.8-6.fc10
------------------
* Tue Oct 28 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.8-6
- Update specfile requires to include dist


audit-viewer-0.4-1.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Miloslav Trma? <mitr at redhat.com> - 0.4-1
- Update to audit-viewer-0.4.


bash-3.2-29.fc10
----------------
* Tue Oct 28 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 3.2-29
- Add the Requires(post) back for ncurses-libs, so that rpm knows
  where to break the loop.  The post actually does require the curses
  libs for the sh calls.  Could consider doing this in LUA and not have
  any external deps.


bigboard-0.6.4-2.fc10
---------------------
* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.6.4-2
- Add missing Requires: python-twyt

* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.6.4-1
- Update to 0.6.4 (Fix Logout menu option not working)

* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.6.3-1
- Update to 0.6.3


chkconfig-1.3.38-1
------------------
* Wed Oct 29 18:00:00 2008 Bill Nottingham <notting at redhat.com> 1.3.38-1
- Fix runlevel list in man page (#466739)
- translation updates


createrepo-0.9.6-3.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 0.9.6-1
- 0.9.6-1
- add mergerepo


desktop-data-model-1.2.5-1.fc10
-------------------------------
* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 1.2.5-1
- Update to 1.2.5 (adds BuildRequires: empathy)


dovecot-1.1.5-1.fc10
--------------------
* Wed Oct 29 18:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.5-1
- update to upstream version 1.1.5 (Resolves: CVE-2008-4577, CVE-2008-4578)


fedora-release-notes-9.92-3
---------------------------
* Tue Oct 28 18:00:00 2008 Paul W. Frields <stickster at gmail.com> - 9.92-3
- Correct file names for Fedora 10 Preview Release

* Fri Oct 17 18:00:00 2008 Paul W. Frields <stickster at gmail.com> - 9.92-2
- Update version for Fedora 10 Preview Release

* Thu Oct  2 18:00:00 2008 Paul W. Frields <stickster at gmail.com> - 9.92-1
- Bump version and release to match for F10 Preview Release
- Fix description
- Fix missing README content


generic-logos-10.0.1-1.fc10
---------------------------
* Tue Oct 28 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 10.0.1-1
- incorporate KDE logo into upstream source distribution
- fix system-logo-white.png for compiz bleeding (#468258)


gnome-desktop-2.24.1-4.fc10
---------------------------
* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-4
- Take Requires: solar-backgrounds from libgnome so KDE
  spin doesn't pull it in (Requested by Rex).


gpgme-1.1.7-1.fc10
------------------
* Sat Oct 18 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.1.7-1
- gpgme-1.1.7


hal-0.5.12-9.20081027git.fc10
-----------------------------
* Tue Oct 28 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-9.20081027git
- Remove the newly added BDI devices to fix #468850


hamcrest-1.1-6.1.fc10
---------------------
* Tue Oct 28 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1-6.1
- Fedora-specific: enable GCJ support
- Fedora-specific: build with java 1.6.0
- Fedora-specific: disable integration and tests

* Tue Oct 28 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1-6
- make demo dependency on testng conditional


kde-settings-4.1-3.20081028svn.fc10
-----------------------------------
* Tue Oct 28 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1-3
- kdmrc: ServerVTs=1 , drop tty1 from ConsoleTTYs
- kde-settings-20081028
- Url: fedorahosted.org/kde-settings


kdepimlibs-4.1.2-3.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-3
- build against the system libical (F10+ only for now)


libgnome-2.24.1-7.fc10
----------------------
* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-7
- move Requires: solar-backgrounds to gnome-desktop so
  KDE spin doesn't pull it in (Requested by Rex).


mdadm-2.6.7.1-1.fc10
--------------------
* Fri Oct 24 18:00:00 2008 Doug Ledford <dledford at redhat.com> - 2.6.7.1-1
- Updated to latest upstream stable release (#466803)
- Change udev rule to not assemble degraded arrays (#453314)
- Fix metadata matching in config file (#466078)
- Fix assembly of raid10 devices (#444237)
- Fix incremental assembly of partitioned raid devices (#447818)


mtr-0.75-2.fc10
---------------
* Wed Oct 29 18:00:00 2008 Zdenek Prikryl <zprikryl at redhat.com> - 2:0.75-2
- Fixed setting socket flags in ipv4 only environment (#467964)


ntfs-3g-1.5012-3.fc10
---------------------
* Wed Oct 29 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2:1.5012-3
- fix hal file to cover all mount cases (thanks to Richard Hughes)


online-desktop-0.3.2-1.fc10
---------------------------
* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.3.2-1
- Update to 0.3.2
  - let gnome-keyring pick the right keyring instead of hardcoding "default"
  - fix unpacking error when adding new accounts
  - fix problem with locally saved accounts not properly updating
  - remove bigboard applet from default config (not useful any more)

* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.3.1-1
- Update to 0.3.1


pads-1.2-2.fc10
---------------
* Tue Oct 28 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.2-2
- Update CFLAGS for newer libprelude (#465964)


plymouth-0.6.0-0.2008.10.27.7.fc10
----------------------------------
* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.7
- Don't require /bin/plymouth before it's installed (bug 468925)

* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.6
- Force raw mode for keyboard input with solar and fade-in
  (bug 468880)
- make sure windows get closed on exit


rpm-4.6.0-0.rc1.6
-----------------
* Tue Oct 28 18:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- Florian's improved fingerprinting hash algorithm from upstream


spin-kickstarts-0.10.1-1.fc10
-----------------------------
* Tue Oct 28 18:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 0.10.1-1
- Second build for review #448072


system-config-boot-0.3.0-2.fc10
-------------------------------
* Tue Oct 28 18:00:00 2008 Harald Hoyer <harald at redhat.com> 0.3.0-2
- reapplied changes by spot

* Tue Oct 28 18:00:00 2008 Harald Hoyer <harald at redhat.com> 0.3.0-1
- version 0.3.0


system-config-firewall-1.2.13-2.fc10
------------------------------------
* Tue Oct 28 18:00:00 2008 Thomas Woerner <twoerner at redhat.com> 1.2.13-2
- fixed system-config-firewall-tui path (rhbz#457485)

* Tue Oct 28 18:00:00 2008 Thomas Woerner <twoerner at redhat.com> 1.2.13-1
- fixed two typos in fw_icmp (rhbz#467334)
- added ability to sort custom rules files (rhbz#467696)
- fixed modified test in sysctl writer: fixes rhbz#462325
  also removed quotes around values for new keys
- some build fixes
- updated translations for: as, de, fi, fr, he, hi, ko, hu, it, ja, ko, ml,
                            pl, pt_BR, ru, sk, sr, sr at latin, sv, ta, te, 
                            zh_CN, zh_TW


system-config-network-1.5.93-2.fc10
-----------------------------------
* Tue Oct 28 18:00:00 2008 Harald Hoyer <harald at redhat.com> 1.5.93-2
- version 1.5.93


system-switch-java-1.1.4-1.fc10
-------------------------------
* Tue Oct 28 18:00:00 2008 Deepak Bhole <dbhole at redhat.com> - 1.1.4-1
- Update to 1.1.4, which contains new translations

* Sat Sep  6 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.1.3-2
- fix license tag


usermode-1.98.1-1
-----------------
* Tue Oct 28 18:00:00 2008 Miloslav Trma? <mitr at redhat.com> - 1.98.1-1
- Update to usermode-1.98.1-1


xournal-0.4.2.1-2.fc10
----------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt? <ville.skytta at iki.fi> - 0.4.2.1-2
- Fix Patch0:/%patch mismatch (#463069)


yum-3.2.20-3.fc10
-----------------
* Wed Oct 29 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 3.2.20-3
- full patch against HEAD for skipbroken fixes (among others)


Summary:
Added Packages: 0
Removed Packages: 1
Modified Packages: 34
Broken deps for i386
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From rawhide at fedoraproject.org  Thu Oct 30 05:48:34 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 30 Oct 2008 05:48:34 +0000 (UTC)
Subject: rawhide report: 20081029 changes
Message-ID: <20081030054834.A3A411F824B@releng2.fedora.phx.redhat.com>

Removed package atitvout
Updated Packages:

alienarena-7.20-5.fc10
----------------------
* Wed Oct 29 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 7.20-5
- use /bin/bash for the scripts due to the export LD_LIBRARY_PATH


anjuta-2.24.1-1.fc10
--------------------
* Tue Oct 28 18:00:00 2008 Debarshi Ray <rishi at fedoraproject.org> - 1:2.24.1-1
- Version bump to 2.24.1.
- Makefile problems fixed by upstream.
- Added 'Requires: git' and 'BuildRequires: e2fsprogs-devel intltool'.
- libanjuta-egg.so has been dropped.


audit-1.7.8-6.fc10
------------------
* Tue Oct 28 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.7.8-6
- Update specfile requires to include dist


audit-viewer-0.4-1.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Miloslav Trma? <mitr at redhat.com> - 0.4-1
- Update to audit-viewer-0.4.


bash-3.2-29.fc10
----------------
* Tue Oct 28 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 3.2-29
- Add the Requires(post) back for ncurses-libs, so that rpm knows
  where to break the loop.  The post actually does require the curses
  libs for the sh calls.  Could consider doing this in LUA and not have
  any external deps.


bigboard-0.6.4-2.fc10
---------------------
* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.6.4-2
- Add missing Requires: python-twyt

* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.6.4-1
- Update to 0.6.4 (Fix Logout menu option not working)

* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.6.3-1
- Update to 0.6.3


chkconfig-1.3.38-1
------------------
* Wed Oct 29 18:00:00 2008 Bill Nottingham <notting at redhat.com> 1.3.38-1
- Fix runlevel list in man page (#466739)
- translation updates


createrepo-0.9.6-3.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 0.9.6-1
- 0.9.6-1
- add mergerepo


desktop-data-model-1.2.5-1.fc10
-------------------------------
* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 1.2.5-1
- Update to 1.2.5 (adds BuildRequires: empathy)


dovecot-1.1.5-1.fc10
--------------------
* Wed Oct 29 18:00:00 2008 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.5-1
- update to upstream version 1.1.5 (Resolves: CVE-2008-4577, CVE-2008-4578)


fedora-release-notes-9.92-3
---------------------------
* Tue Oct 28 18:00:00 2008 Paul W. Frields <stickster at gmail.com> - 9.92-3
- Correct file names for Fedora 10 Preview Release

* Fri Oct 17 18:00:00 2008 Paul W. Frields <stickster at gmail.com> - 9.92-2
- Update version for Fedora 10 Preview Release

* Thu Oct  2 18:00:00 2008 Paul W. Frields <stickster at gmail.com> - 9.92-1
- Bump version and release to match for F10 Preview Release
- Fix description
- Fix missing README content


generic-logos-10.0.1-1.fc10
---------------------------
* Tue Oct 28 18:00:00 2008 Bill Nottingham <notting at redhat.com> - 10.0.1-1
- incorporate KDE logo into upstream source distribution
- fix system-logo-white.png for compiz bleeding (#468258)


gnome-desktop-2.24.1-4.fc10
---------------------------
* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-4
- Take Requires: solar-backgrounds from libgnome so KDE
  spin doesn't pull it in (Requested by Rex).


gpgme-1.1.7-1.fc10
------------------
* Sat Oct 18 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 1.1.7-1
- gpgme-1.1.7


hal-0.5.12-9.20081027git.fc10
-----------------------------
* Tue Oct 28 18:00:00 2008 Richard Hughes <rhughes at redhat.com> - 0.5.12-9.20081027git
- Remove the newly added BDI devices to fix #468850


hamcrest-1.1-6.1.fc10
---------------------
* Tue Oct 28 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1-6.1
- Fedora-specific: enable GCJ support
- Fedora-specific: build with java 1.6.0
- Fedora-specific: disable integration and tests

* Tue Oct 28 18:00:00 2008 David Walluck <dwalluck at redhat.com> 0:1.1-6
- make demo dependency on testng conditional


kde-settings-4.1-3.20081028svn.fc10
-----------------------------------
* Tue Oct 28 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1-3
- kdmrc: ServerVTs=1 , drop tty1 from ConsoleTTYs
- kde-settings-20081028
- Url: fedorahosted.org/kde-settings


kdepimlibs-4.1.2-3.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.2-3
- build against the system libical (F10+ only for now)


libgnome-2.24.1-7.fc10
----------------------
* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> - 2.24.1-7
- move Requires: solar-backgrounds to gnome-desktop so
  KDE spin doesn't pull it in (Requested by Rex).


mdadm-2.6.7.1-1.fc10
--------------------
* Fri Oct 24 18:00:00 2008 Doug Ledford <dledford at redhat.com> - 2.6.7.1-1
- Updated to latest upstream stable release (#466803)
- Change udev rule to not assemble degraded arrays (#453314)
- Fix metadata matching in config file (#466078)
- Fix assembly of raid10 devices (#444237)
- Fix incremental assembly of partitioned raid devices (#447818)


mtr-0.75-2.fc10
---------------
* Wed Oct 29 18:00:00 2008 Zdenek Prikryl <zprikryl at redhat.com> - 2:0.75-2
- Fixed setting socket flags in ipv4 only environment (#467964)


ntfs-3g-1.5012-3.fc10
---------------------
* Wed Oct 29 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2:1.5012-3
- fix hal file to cover all mount cases (thanks to Richard Hughes)


online-desktop-0.3.2-1.fc10
---------------------------
* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.3.2-1
- Update to 0.3.2
  - let gnome-keyring pick the right keyring instead of hardcoding "default"
  - fix unpacking error when adding new accounts
  - fix problem with locally saved accounts not properly updating
  - remove bigboard applet from default config (not useful any more)

* Tue Oct 28 18:00:00 2008 Owen Taylor <otaylor at redhat.com> - 0.3.1-1
- Update to 0.3.1


pads-1.2-2.fc10
---------------
* Tue Oct 28 18:00:00 2008 Steve Grubb <sgrubb at redhat.com> 1.2-2
- Update CFLAGS for newer libprelude (#465964)


plymouth-0.6.0-0.2008.10.27.7.fc10
----------------------------------
* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.7
- Don't require /bin/plymouth before it's installed (bug 468925)

* Tue Oct 28 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.6
- Force raw mode for keyboard input with solar and fade-in
  (bug 468880)
- make sure windows get closed on exit


rpm-4.6.0-0.rc1.6
-----------------
* Tue Oct 28 18:00:00 2008 Panu Matilainen <pmatilai at redhat.com>
- Florian's improved fingerprinting hash algorithm from upstream


spin-kickstarts-0.10.1-1.fc10
-----------------------------
* Tue Oct 28 18:00:00 2008 Jeroen van Meeuwen <kanarip a fedoraunity.org> 0.10.1-1
- Second build for review #448072


system-config-boot-0.3.0-2.fc10
-------------------------------
* Tue Oct 28 18:00:00 2008 Harald Hoyer <harald at redhat.com> 0.3.0-2
- reapplied changes by spot

* Tue Oct 28 18:00:00 2008 Harald Hoyer <harald at redhat.com> 0.3.0-1
- version 0.3.0


system-config-firewall-1.2.13-2.fc10
------------------------------------
* Tue Oct 28 18:00:00 2008 Thomas Woerner <twoerner at redhat.com> 1.2.13-2
- fixed system-config-firewall-tui path (rhbz#457485)

* Tue Oct 28 18:00:00 2008 Thomas Woerner <twoerner at redhat.com> 1.2.13-1
- fixed two typos in fw_icmp (rhbz#467334)
- added ability to sort custom rules files (rhbz#467696)
- fixed modified test in sysctl writer: fixes rhbz#462325
  also removed quotes around values for new keys
- some build fixes
- updated translations for: as, de, fi, fr, he, hi, ko, hu, it, ja, ko, ml,
                            pl, pt_BR, ru, sk, sr, sr at latin, sv, ta, te, 
                            zh_CN, zh_TW


system-config-network-1.5.93-2.fc10
-----------------------------------
* Tue Oct 28 18:00:00 2008 Harald Hoyer <harald at redhat.com> 1.5.93-2
- version 1.5.93


system-switch-java-1.1.4-1.fc10
-------------------------------
* Tue Oct 28 18:00:00 2008 Deepak Bhole <dbhole at redhat.com> - 1.1.4-1
- Update to 1.1.4, which contains new translations

* Sat Sep  6 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.1.3-2
- fix license tag


usermode-1.98.1-1
-----------------
* Tue Oct 28 18:00:00 2008 Miloslav Trma? <mitr at redhat.com> - 1.98.1-1
- Update to usermode-1.98.1-1


xournal-0.4.2.1-2.fc10
----------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt? <ville.skytta at iki.fi> - 0.4.2.1-2
- Fix Patch0:/%patch mismatch (#463069)


yum-3.2.20-3.fc10
-----------------
* Wed Oct 29 18:00:00 2008 Seth Vidal <skvidal at fedoraproject.org> - 3.2.20-3
- full patch against HEAD for skipbroken fixes (among others)


Summary:
Added Packages: 0
Removed Packages: 1
Modified Packages: 34
Broken deps for i386
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From rc040203 at freenet.de  Thu Oct 30 05:48:19 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 30 Oct 2008 06:48:19 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
Message-ID: <1225345699.3897.451.camel@beck.corsepiu.local>

On Wed, 2008-10-29 at 09:50 -0800, Jeff Spaleta wrote:
> On Wed, Oct 29, 2008 at 9:21 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > You will likely comprehend the absurdity of this proposal when X server
> > races the next time.
> 
> As a user...wtf do I know about a race condition?

As a user, you watch your system becoming non-responsive. As a Win-User
you will switch the machine off and reboot.

As a Linux user with a bit of experience, you will want to check for
what is going wrong and will try to recover from the breakdown without
rebooting or reinstalling.

That said, Ctrl-F1 often is the first step to try (and sometimes the
only means) when "X11 becomes non-responsive".

> As a tester...im going to turn on a going to turn on gettys no matter
> what the defaults are.
> where the getty is..is arbitrary...for my needs to interact with it.

> As an admin....serial consoles are great.
I guess, you always have second machine around prepared for such
scenarios?

I guess, your laptop has a serial console you carry around all the time,
e.g. in hotels or in trains?

I guess, you have never had never been facing sporadic network
breakdowns (or more common on Fedora: NetworkManager misbehaving) ?




From dkelson at gurulabs.com  Thu Oct 30 05:49:01 2008
From: dkelson at gurulabs.com (Dax Kelson)
Date: Wed, 29 Oct 2008 23:49:01 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029220532.dcfc549e.zaitcev@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<20081029220532.dcfc549e.zaitcev@redhat.com>
Message-ID: <1225345741.3315.3.camel@mentor.gurulabs.com>

On Wed, 2008-10-29 at 22:05 -0600, Pete Zaitcev wrote:
> On Wed, 29 Oct 2008 17:25:36 -0400, Bill Nottingham <notting at redhat.com> wrote:
> 
> > Are people not running rawhide and the test releases? Are they not
> > looking at features as they are proposed and being involved in the
> > process? Are they just sitting around waiting to be outraged?
> 
> I encountered it in Rawhide some time ago, and my first thought was
> that the X server was broken somehow. However, in a couple of
> minutes I figured out what was happening. It wasn't a problem for me.
> Maybe Dax paniced, hit <ctrl><alt><backspace>, and now nurses a grudge.

Personal attacks are uncalled for.

Dax Kelson
Guru Labs



From mattdm at mattdm.org  Thu Oct 30 05:56:40 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 30 Oct 2008 01:56:40 -0400
Subject: breaking news: old-school is NO gettys with X Re: Reasons to
	preseve X on tty7]
In-Reply-To: <49093EFC.1050603@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<555910.26860.qm@web32807.mail.mud.yahoo.com>
	<20081029135415.GA6665@wolff.to> <49093EFC.1050603@gmail.com>
Message-ID: <20081030055640.GA12424@jadzia.bu.edu>

On Wed, Oct 29, 2008 at 11:58:36PM -0500, Les Mikesell wrote:
>> I always thought it was odd it was on vt7 instead of vt1 or vt12. Why pick
>> one in the middle to be special. (Note that when I used to use vts I
>> had 12 configured.)
> It just happens to be the first free one.  I remember having virtual 
> terminals running Dell's version of SysV linux on a 486 box in the early 
> 90's.  Somebody probably copied their inittab file with 6 getty's...


I went and looked at the oldest inittab I could find online in a half-hour
of searching.

<http://www.ibiblio.org/pub/historic-linux/distributions/redhat/3.0.3/i386/trees/liveram/etc/inittab>

It has:

# Run gettys in standard runlevels
1:1234:respawn:/sbin/getty tty1 VC linux
2:234:respawn:/sbin/getty tty2 VC linux
3:234:respawn:/sbin/getty tty3 VC linux
4:234:respawn:/sbin/getty tty4 VC linux
5:234:respawn:/sbin/getty tty5 VC linux
6:234:respawn:/sbin/getty tty6 VC linux

# Run xdm in runlevel 5
# x:5:respawn:/usr/bin/X11/xdm -nodaemon


That's right -- NO gettys configured in the X runlevel. None!

The new school *is* the old school!



And check out inittab from Slackware 1.1.2, dated 1994-01-27. It has the
following getty lines:


c1:12345:respawn:/sbin/agetty 38400 tty1
c2:12345:respawn:/sbin/agetty 38400 tty2
c3:45:respawn:/sbin/agetty 38400 tty3
c4:45:respawn:/sbin/agetty 38400 tty4
c5:45:respawn:/sbin/agetty 38400 tty5
c6:456:respawn:/sbin/agetty 38400 tty6


# Runlevel 6 used to be for an X-window only system, until we discovered
# that it throws init into a loop that keeps your load avg at least 1 all 
# the time. Thus, there is now one getty opened on tty6. Hopefully no one
# will notice. ;^)
# It might not be bad to have one text console anyway, in case something 
# happens to X.
x1:6:wait:/etc/rc.d/rc.6

So again, no text vts with X, except for due to a bug.


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From mattdm at mattdm.org  Thu Oct 30 06:00:38 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 30 Oct 2008 02:00:38 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225345699.3897.451.camel@beck.corsepiu.local>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
	<1225345699.3897.451.camel@beck.corsepiu.local>
Message-ID: <20081030060038.GA17282@jadzia.bu.edu>

On Thu, Oct 30, 2008 at 06:48:19AM +0100, Ralf Corsepius wrote:
> That said, Ctrl-F1 often is the first step to try (and sometimes the
> only means) when "X11 becomes non-responsive".

Yeah, but, realistically, if ctrl-alt-f1 doesn't work, isn't ctrl-alt-f2
automatically the next thing you do?


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From lmacken at redhat.com  Thu Oct 30 06:19:14 2008
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 30 Oct 2008 02:19:14 -0400
Subject: Fedora Security Tools spin
In-Reply-To: <abf6bee60809180804u425e9912w22d56081b40bbe34@mail.gmail.com>
References: <48BE023A.70703@redhat.com> <48BE1F95.2090509@redhat.com>
	<20080903210044.GF3726@x300>
	<200809050052.49444.Adi1981.2k5@gmail.com>
	<20080905002309.GN3726@x300>
	<abf6bee60809180804u425e9912w22d56081b40bbe34@mail.gmail.com>
Message-ID: <20081030061914.GP3313@x300>

On Thu, Sep 18, 2008 at 05:04:22PM +0200, Adrian P wrote:
> 2008/9/5 Luke Macken <lmacken at redhat.com>
> 
> > On Fri, Sep 05, 2008 at 12:52:49AM +0200, Adrian Pilchowiec wrote:
> > > On Wednesday 03 of September 2008 23:00:44 Luke Macken wrote:
> > > > On Wed, Sep 03, 2008 at 10:54:37AM +0530, Huzaifa Sidhpurwala wrote:
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA1
> > > > >
> > > > > Todd Zullinger wrote:
> > > > > > Huzaifa Sidhpurwala wrote:
> > > > > >> I just came across a knoppix security tool live CD and thought it
> > > > > >> would be a good idea for a security tool fedora spin too.
> > > > > >> The tools are freely available at:
> > > > > >>
> > > > > >> http://knoppix-std.org/index.html
> > > > > >> and are all GPLed?
> > > > > >>
> > > > > >> Do you guys think this is a good idea, I am sure such a spin does
> > > > > >> not exists in Fedora yet.
> > > > > >
> > > > > > Do you mean something like Luke Macken put together?
> > > > > >
> > > > > > http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD
> > > > >
> > > > > Yeah but more tools and more bare bones,
> > > > > Perhaps i can assist Luke in this?
> > > >
> > > > Absolutely!
> > > >
> > > > I'm in the process of rebasing the kickstart against the latest livecd
> > > > base, and I will be pushing it through the New Spin Process soon.
> > > >
> > > > More tools?  Yes.  I want it to ship with every security tool in
> > Fedora.
> > > > If you know of any that are missing from the list, please let me know.
> > > >
> > >
> > > Maybe it would be good to add OpenVAS [1] (free fork of nessus) to the
> > spin ?
> >
> > I added OpenVAS to the WishList, thanks!
> >
> >    https://fedoraproject.org/wiki/SecuritySpin#Wishlist
> >
> > luke
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> 
> Got few other tools to propose:
> Lynis [1] - Security and system auditing tool
> Nebula [2] Intrusion signature generator
> Unhide [3] tool for searching hidden processes
> SARA [4] Security Auditor's Research Assistant
> SiLK [5] Security analysis tool for network developed by CERT
> ArpON [6] Detects and blocks all ARP poisoning/spoofing attacks.
> Bh (Beholder) [7] IDS for wireless networks.
> Distack [8] Framework for attack detection which allows for an integration
> of various detection methods as lightweight modules.
> Ttyrpld [9] Multi-os kernel-level tty logger

Added to the wishlist.  Thanks!

luke



From rc040203 at freenet.de  Thu Oct 30 06:38:20 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 30 Oct 2008 07:38:20 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081030060038.GA17282@jadzia.bu.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
	<1225345699.3897.451.camel@beck.corsepiu.local>
	<20081030060038.GA17282@jadzia.bu.edu>
Message-ID: <1225348700.3897.455.camel@beck.corsepiu.local>

On Thu, 2008-10-30 at 02:00 -0400, Matthew Miller wrote:
> On Thu, Oct 30, 2008 at 06:48:19AM +0100, Ralf Corsepius wrote:
> > That said, Ctrl-F1 often is the first step to try (and sometimes the
> > only means) when "X11 becomes non-responsive".
> 
> Yeah, but, realistically, if ctrl-alt-f1 doesn't work, isn't ctrl-alt-f2
> automatically the next thing you do?
Yep, but what if there aren't any?

This is at least how I read Jeff's remark, my cynical comment was
referring to:
On Wed, 2008-10-29 at 08:11 -0800, Jeff Spaleta wrote:
> The flipside
> to all the arguments here is all gettys could be off by default unless
> local admins want them on.





From jspaleta at gmail.com  Thu Oct 30 06:51:00 2008
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Oct 2008 22:51:00 -0800
Subject: breaking news: old-school is NO gettys with X Re: Reasons to
	preseve X on tty7]
In-Reply-To: <20081030055640.GA12424@jadzia.bu.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<555910.26860.qm@web32807.mail.mud.yahoo.com>
	<20081029135415.GA6665@wolff.to> <49093EFC.1050603@gmail.com>
	<20081030055640.GA12424@jadzia.bu.edu>
Message-ID: <604aa7910810292351n5cd4d980n3f1e767de0fdc9cd@mail.gmail.com>

On Wed, Oct 29, 2008 at 9:56 PM, Matthew Miller
> The new school *is* the old school!

Fedora 10, the Retro-revolution

Thanks for the deep diving.

-jef



From peter at thecodergeek.com  Thu Oct 30 06:59:45 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 29 Oct 2008 23:59:45 -0700
Subject: Seeking New Maintainers: viaideinfo, pidgin-libnotify
Message-ID: <1225349985.5177.43.camel@tuxhugs>

Hi, all.

I am in need of new loving owners for both of these packages, which are
low-maintenance, having seen little to no recent upstream activity. 

I have not orphaned them in PkgDB yet as I feel it is very unfair to the
community to simply drop my maintainership of these packages on the
verge of a new GA release cycle. So, for the near future I will happily
continue caring for them as best I can; but due to lack of appropriate
hardware and interest, respectively, I will likely be unable to properly
resolve any bugs or issues that arise in them.

***

viaideinfo [1,2] is a small piece of software created by Gentoo/kernel
developer Daniel Drake, which supersedes the functionality provided
by /proc/ide/via in older VIA IDE driver code and keeps it in userspace.
However, with the recent failure and replacement of my mother's desktop
machine, I no longer have any hardware with VIA chipsets in it.

Even though it has seen only very minor up- and downstream activity
recently, I feel that as a hardware-specific tool, it would be best
served by a maintainer who actually has the hardware in question so that
it can properly be tested/debugged as necessary.

[1] http://reactivated.net/software/viaideinfo/
[2] https://admin.fedoraproject.org/pkgdb/packages/name/viaideinfo

***

pidgin-libnotify [3,4] is plugin for Pidgin (formerly Gaim) which shows
configurable notifications for various actions (such as buddies signing
on or off, someone saying your name in a chat, etc.). 

Since its initial packaging in December of 2006, its only major upstream
update has been for the Gaim --> Pidgin name change. Also, starting in
August of last year, I became the primary maintainer of Empathy and have
since been a strong proponent of the Telepathy stack, and a member of
the Fedora Telepathy SIG [5]. As someone who longer uses Pidgin (and
thus, this libnotify plugin), I feel it would be best served by a new
maintainer who actively uses it and is interested in its further
development.
	
[3] http://gaim-libnotify.sourceforge.net/
[4] https://admin.fedoraproject.org/pkgdb/packages/name/pidgin-libnotify
[5] http://fedoraproject.org/wiki/SIGs/Telepathy
***

Thanks, and Regards.
-- 
Peter Gordon (codergeek42)
???????????
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/8d09fcc6/attachment.sig>

From erik at vanpienbroek.nl  Thu Oct 30 07:26:41 2008
From: erik at vanpienbroek.nl (Erik van Pienbroek)
Date: Thu, 30 Oct 2008 08:26:41 +0100
Subject: Seeking New Maintainers: viaideinfo, pidgin-libnotify
In-Reply-To: <1225349985.5177.43.camel@tuxhugs>
References: <1225349985.5177.43.camel@tuxhugs>
Message-ID: <1225351601.3332.1.camel@erik>

Op woensdag 29-10-2008 om 23:59 uur [tijdzone -0700], schreef Peter
Gordon:
> I am in need of new loving owners for both of these packages, which are
> low-maintenance, having seen little to no recent upstream activity. 

I want to take pidgin-libnotify.

Regards,

Erik van Pienbroek




From fedora at shmuelhome.mine.nu  Thu Oct 30 07:32:36 2008
From: fedora at shmuelhome.mine.nu (shmuel siegel)
Date: Thu, 30 Oct 2008 07:32:36 -0000
Subject: A suggestion regarding new features
In-Reply-To: <1225300511.3846.44.camel@mentor.gurulabs.com>
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
Message-ID: <48E71C0B.7060302@shmuelhome.mine.nu>

Dax Kelson wrote:
> Step 3. Does the benefit of $NEWFEATURE outweigh the cost of changing
> the old behavior or breaking compatibility? Obviously this can be
> subjective.
>
> a) NO -> Good effort. Have you considered picking one of the other many
> areas in Linux that need improving and working on that?
> b) YES -> OK, $NEWFEATURE must be really awesome. Please double check
> that you can't resolve this in Step 2. So Step 2 is a no go? OK, let's
> do it.
>
>   
<semisarcasm>
Your step 3 should really be step 4. The real step 3 is

Step 3. Will suggesting this change cause more waste of time on useless 
discussions than any perceived gain that the change will achieve.
    a) YES-> Rethink step 2 or drop it. It will get in the way of more 
pressing issues. Winning is not worth the cost.
    b) NO -> go to step 4

</semisarcasm>



From pertusus at free.fr  Thu Oct 30 09:34:46 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 30 Oct 2008 10:34:46 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<1225301630.3846.66.camel@mentor.gurulabs.com>
	<1225303983.23396.82.camel@nibbler.dlib.indiana.edu>
	<4908BA6C.5030806@gmail.com>
	<1225310388.23396.99.camel@nibbler.dlib.indiana.edu>
Message-ID: <20081030093446.GA2640@free.fr>

On Wed, Oct 29, 2008 at 03:59:48PM -0400, Brian Wheeler wrote:
> 
> Well, I'm a long time user and I don't see what the big deal is.  There
> are several people on this list which seem to announce that "<insert
> change here> is the one that's going to drive long time users away"
> and/or "time to look for a new distribution" semi-regularly... yet they
> (long time users) are still here.

I think that many are not as present as before. Especially compared with
the time of extra+devel. And it also seems to me that many long time
users are still there but don't use fedora much anymore -- they still 
want to influence next RHEL. Also I don't think if there are others 
like me, but I thought that opening to the community would lead
to more work in common with (old-timers) technical users, with Red Hat
still taking the lead nevertheless as before. But even after some time
this didn't happened. I don't use any release anymore, but I still use
rawhide because I wanted to help with maintaining pieces of software
that I care about, but this is too difficult because upstream-fedora 
people don't care to a point that I fear that my actions are 
counter-productive in the end. Today the only motivation that keeps me 
lurking around fedora is EPEL.

--
Pat



From nicolas.mailhot at laposte.net  Thu Oct 30 09:38:07 2008
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 30 Oct 2008 10:38:07 +0100 (CET)
Subject: Reasons to preseve X on tty7
In-Reply-To: <80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
Message-ID: <f6b6eaf4ff607a70d21b06af648c7b50.squirrel@arekh.dyndns.org>



Le Jeu 30 octobre 2008 03:13, Stephen John Smoogen a ?crit :

Oh, well, so much for not wanting to participate to this thread

For the record I think this latest change is small and justified.

However I also believe this flamewar is due on no little part on how
previous changes were managed, and is more an "enough is enough"
thread than a "X on tty7" is sacred thread. It would be nice if
previous big changes were assimilated before adding more to the mix
(how many releases will it take before NetWorkManager is solid and
complete and on by default without needing the old framework for
backup, for example?).

Contrary to popular belief the supply of new unprejudiced users is not
inexhaustible, existing users are not a burden but an asset, and if we
piss off enough of them by changing stuff continuously and never
delivering stable complete replacements they'll make us such a
reputation we'll not find any replacements (there is such thing as the
Internet and Google, and they have long memories).

> Technical changes on the other hand have a bigger
> issue especially when documentation may need to be reprinted, training
> has to be updated and you always end up with the chance you are going
> to relive the great egcs or similar changes where it looks great for
> the small amount of beta testers but not everywhere.

Years after we merged decent fonts, and years after we added
metric-perfect Arial/TNR substitutes, the first Google hit on "Fedora
Fonts" is still a FAQ on how to install the crappy proprietary frozen
in time Microsoft fonts. And that's a simple self-contained example.

-- 
Nicolas Mailhot



From bruno at wolff.to  Thu Oct 30 09:40:36 2008
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 30 Oct 2008 04:40:36 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029214326.GI1371252@hiwaay.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<20081029214326.GI1371252@hiwaay.net>
Message-ID: <20081030094036.GA12691@wolff.to>

On Wed, Oct 29, 2008 at 16:43:26 -0500,
  Chris Adams <cmadams at hiwaay.net> wrote:
> Once upon a time, Bill Nottingham <notting at redhat.com> said:
> > Are people not running rawhide and the test releases? Are they not
> > looking at features as they are proposed and being involved in the
> > process? Are they just sitting around waiting to be outraged?
> 
> Or have they not actually used a VT switch to a text console since this
> was implemented?

As someone who was testing both Plymouth and KMS, I got plenty of chances
to switch to a VT and even filed some bug reports against both.
This is sort of like how recent Plymouth and mkinitrd changes regarding
encrypted file systems help me find a couple of issues with the f10 rescue
image.



From douglas at paradise.net.nz  Thu Oct 30 09:56:49 2008
From: douglas at paradise.net.nz (Douglas Bagnall)
Date: Thu, 30 Oct 2008 22:56:49 +1300
Subject: undefined symbol: __stack_chk_fail_local
Message-ID: <d24e24ab0810300256t232fd400s531fe07f5cd7e17f@mail.gmail.com>

I've been working on a package for OLPC that uses pam_sotp, which
Rahul Sundaram packaged for Fedora in order to help OLPC.

http://sundaram.fedorapeople.org/packages/pam_sotp-0.3.3-1.fc9.src.rpm

Unfortunately the installed pam module fails with errors like this:

 PAM unable to dlopen(/lib/security/pam_sotp.so): \
  /lib/security/pam_sotp.so: undefined symbol: __stack_chk_fail_local

This is related to gcc's fairly recently introduced stack smashing
protection; if it is compiled with CFLAGS="-fno-stack-protector", the
module works fine.  But that seems wrong.

How are these symbols ending up undefined?  Has anyone met this
problem before?  Some googling suggested linking with gcc rather than
ld, but I can't work out how to make the rpm do that.

(This is all Fedora 9, gcc-4.3.0-8.i386).


Douglas Bagnall



From forum at ru.bir.ru  Thu Oct 30 09:59:44 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Thu, 30 Oct 2008 12:59:44 +0300
Subject: Fedora 9 spins beta???
Message-ID: <gec0ih$fl9$1@ger.gmane.org>

On page http://spins.fedoraproject.org/ in section "Fedora 9 spins" all 
present torrent files has description with "- **Beta**" suffixes. But 
nor section name nor file names has not include "Beta"... Furthermore, 
Fedora 9 long time is stable... I assume this is only error in 
description? Or we have not stable Fedora 9 spins yet?

Please fix it, who can.



From kevin.kofler at chello.at  Thu Oct 30 10:35:51 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 30 Oct 2008 10:35:51 +0000 (UTC)
Subject: Fedora 9 spins beta???
References: <gec0ih$fl9$1@ger.gmane.org>
Message-ID: <loom.20081030T103319-30@post.gmane.org>

Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
> On page http://spins.fedoraproject.org/ in section "Fedora 9 spins" all 
> present torrent files has description with "- **Beta**" suffixes. But 
> nor section name nor file names has not include "Beta"... Furthermore, 
> Fedora 9 long time is stable... I assume this is only error in 
> description? Or we have not stable Fedora 9 spins yet?

Those are only the custom spins: Fedora Electronic Lab (lots of Electronics 
software on it) and XFCE (the "third desktop", aiming at being lighterweight 
than GNOME and KDE).

The official spins (installer DVD, "Desktop" (GNOME) and KDE) can be found at: 
http://torrent.fedoraproject.org/

        Kevin Kofler



From galibert at pobox.com  Thu Oct 30 10:50:34 2008
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 30 Oct 2008 11:50:34 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029221111.a6a1e629.zaitcev@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<1225315942.21485.94.camel@rosebud>
	<604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>
	<80d7e4090810291837m19b4064co7ecb1799db1d4e40@mail.gmail.com>
	<20081029221111.a6a1e629.zaitcev@redhat.com>
Message-ID: <20081030105034.GA29027@dspnet.fr.eu.org>

On Wed, Oct 29, 2008 at 10:11:11PM -0600, Pete Zaitcev wrote:
> Look, the problem here is, it was inconceivable to everyone involved
> that this little thing will get someone's panty in a wad. It's utter
> non-problem, despite all the pages and pages and pages of rhethoric
> about some manuals or whatnot.

And that's the problem in a nutshell, again.  "If it's not a problem
for me, it's not a problem, so shut up".

  OG.



From forum at ru.bir.ru  Thu Oct 30 10:59:50 2008
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Thu, 30 Oct 2008 13:59:50 +0300
Subject: Fedora 9 spins beta???
In-Reply-To: <loom.20081030T103319-30@post.gmane.org>
References: <gec0ih$fl9$1@ger.gmane.org>
	<loom.20081030T103319-30@post.gmane.org>
Message-ID: <gec437$r9p$1@ger.gmane.org>

Kevin Kofler ?????:
> Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
>> On page http://spins.fedoraproject.org/ in section "Fedora 9 spins" all 
>> present torrent files has description with "- **Beta**" suffixes. But 
>> nor section name nor file names has not include "Beta"... Furthermore, 
>> Fedora 9 long time is stable... I assume this is only error in 
>> description? Or we have not stable Fedora 9 spins yet?
> 
> Those are only the custom spins: Fedora Electronic Lab (lots of Electronics 
> software on it) and XFCE (the "third desktop", aiming at being lighterweight 
> than GNOME and KDE).

Off course. I do not known what is Electronic Lab, but I come here for 
XFCE spin, which is not in official spins.

So if it is wrong maillist for that question may you point me right?

> The official spins (installer DVD, "Desktop" (GNOME) and KDE) can be found at: 
> http://torrent.fedoraproject.org/
> 
>         Kevin Kofler
> 



From kevin.kofler at chello.at  Thu Oct 30 11:18:20 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 30 Oct 2008 11:18:20 +0000 (UTC)
Subject: Fedora 9 spins beta???
References: <gec0ih$fl9$1@ger.gmane.org>
	<loom.20081030T103319-30@post.gmane.org>
	<gec437$r9p$1@ger.gmane.org>
Message-ID: <loom.20081030T111628-898@post.gmane.org>

Pavel Alexeev (aka Pahan-Hubbitus <forum <at> ru.bir.ru> writes:
> Off course. I do not known what is Electronic Lab, but I come here for 
> XFCE spin, which is not in official spins.
> 
> So if it is wrong maillist for that question may you point me right?

Well, I think the custom spins are still considered "beta". But for a definite 
answer, you'll have to wait, it's the right mailing list, the people who know 
the answer just haven't seen your post yet.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 30 11:29:54 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 30 Oct 2008 11:29:54 +0000 (UTC)
Subject: looking for pymol tester/comaintainer for EL5
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
Message-ID: <loom.20081030T112907-207@post.gmane.org>

Tim Fenn <fenn <at> stanford.edu> writes:
> Right, I'd guess the build will be successful with a simple
> --vendor=fedora tag?

--vendor=fedora should not be used for new packages, use --vendor="" instead to 
get desktop-file-install to install the .desktop file without prepending a 
vendor prefix.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Oct 30 11:34:51 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 30 Oct 2008 11:34:51 +0000 (UTC)
Subject: looking for pymol tester/comaintainer for EL5
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
	<loom.20081030T112907-207@post.gmane.org>
Message-ID: <loom.20081030T113213-32@post.gmane.org>

I wrote:
> --vendor=fedora should not be used for new packages, use --vendor="" instead 
> to get desktop-file-install to install the .desktop file without prepending a 
> vendor prefix.

PS: See https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor for the 
relevant guideline change, it got approved by FPC on 2008-10-21 and by FESCo on 
2008-10-22, but the Packaging/Guidelines page hasn't been updated yet.

        Kevin Kofler






From aph at redhat.com  Thu Oct 30 11:45:46 2008
From: aph at redhat.com (Andrew Haley)
Date: Thu, 30 Oct 2008 11:45:46 +0000
Subject: undefined symbol: __stack_chk_fail_local
In-Reply-To: <d24e24ab0810300256t232fd400s531fe07f5cd7e17f@mail.gmail.com>
References: <d24e24ab0810300256t232fd400s531fe07f5cd7e17f@mail.gmail.com>
Message-ID: <49099E6A.8000208@redhat.com>

Douglas Bagnall wrote:
> I've been working on a package for OLPC that uses pam_sotp, which
> Rahul Sundaram packaged for Fedora in order to help OLPC.
> 
> http://sundaram.fedorapeople.org/packages/pam_sotp-0.3.3-1.fc9.src.rpm
> 
> Unfortunately the installed pam module fails with errors like this:
> 
>  PAM unable to dlopen(/lib/security/pam_sotp.so): \
>   /lib/security/pam_sotp.so: undefined symbol: __stack_chk_fail_local
> 
> This is related to gcc's fairly recently introduced stack smashing
> protection; if it is compiled with CFLAGS="-fno-stack-protector", the
> module works fine.  But that seems wrong.

That depends on whether the target system has runtime support for it.

> How are these symbols ending up undefined?  Has anyone met this
> problem before?  Some googling suggested linking with gcc rather than
> ld, but I can't work out how to make the rpm do that.

It seems to do that already.

> (This is all Fedora 9, gcc-4.3.0-8.i386).

This symbol hould be in /lib/libc.so.6.  Isn't it?

Andrew.



From mattdm at mattdm.org  Thu Oct 30 12:04:22 2008
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 30 Oct 2008 08:04:22 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225348700.3897.455.camel@beck.corsepiu.local>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<604aa7910810290040o1c504e5bhbae35069f5b39c5@mail.gmail.com>
	<49081A53.1050504@leemhuis.info>
	<604aa7910810290911j65f37865l2f9c64c3904dd702@mail.gmail.com>
	<1225300860.3897.398.camel@beck.corsepiu.local>
	<604aa7910810291050u2cf54235qe27e0e5d6eacc9fa@mail.gmail.com>
	<1225345699.3897.451.camel@beck.corsepiu.local>
	<20081030060038.GA17282@jadzia.bu.edu>
	<1225348700.3897.455.camel@beck.corsepiu.local>
Message-ID: <20081030120422.GA17591@jadzia.bu.edu>

On Thu, Oct 30, 2008 at 07:38:20AM +0100, Ralf Corsepius wrote:
> > > That said, Ctrl-F1 often is the first step to try (and sometimes the
> > > only means) when "X11 becomes non-responsive".
> > Yeah, but, realistically, if ctrl-alt-f1 doesn't work, isn't ctrl-alt-f2
> > automatically the next thing you do?
> Yep, but what if there aren't any?

Then I would be surprised and annoyed.

-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences



From jakub at redhat.com  Thu Oct 30 12:10:02 2008
From: jakub at redhat.com (Jakub Jelinek)
Date: Thu, 30 Oct 2008 13:10:02 +0100
Subject: undefined symbol: __stack_chk_fail_local
In-Reply-To: <d24e24ab0810300256t232fd400s531fe07f5cd7e17f@mail.gmail.com>
References: <d24e24ab0810300256t232fd400s531fe07f5cd7e17f@mail.gmail.com>
Message-ID: <20081030121002.GT14706@tyan-ft48-01.lab.bos.redhat.com>

On Thu, Oct 30, 2008 at 10:56:49PM +1300, Douglas Bagnall wrote:
> I've been working on a package for OLPC that uses pam_sotp, which
> Rahul Sundaram packaged for Fedora in order to help OLPC.
> 
> http://sundaram.fedorapeople.org/packages/pam_sotp-0.3.3-1.fc9.src.rpm
> 
> Unfortunately the installed pam module fails with errors like this:
> 
>  PAM unable to dlopen(/lib/security/pam_sotp.so): \
>   /lib/security/pam_sotp.so: undefined symbol: __stack_chk_fail_local
> 
> This is related to gcc's fairly recently introduced stack smashing
> protection; if it is compiled with CFLAGS="-fno-stack-protector", the
> module works fine.  But that seems wrong.
> 
> How are these symbols ending up undefined?  Has anyone met this
> problem before?  Some googling suggested linking with gcc rather than
> ld, but I can't work out how to make the rpm do that.

Yeah, that's very likely the case.  Linking with ld -shared as opposed
to gcc -shared is (almost always) a bug.
Guess you need to modify this package's Makefiles to do the right thing...

	Jakub



From limb at jcomserv.net  Thu Oct 30 12:11:26 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 30 Oct 2008 07:11:26 -0500 (CDT)
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <loom.20081030T113213-32@post.gmane.org>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
	<loom.20081030T112907-207@post.gmane.org>
	<loom.20081030T113213-32@post.gmane.org>
Message-ID: <19b551a07c6c5f17979df511aa99c5b0.squirrel@mail.jcomserv.net>


> I wrote:
>> --vendor=fedora should not be used for new packages, use --vendor=""
>> instead
>> to get desktop-file-install to install the .desktop file without
>> prepending a
>> vendor prefix.
>
> PS: See https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor for
> the
> relevant guideline change, it got approved by FPC on 2008-10-21 and by
> FESCo on
> 2008-10-22, but the Packaging/Guidelines page hasn't been updated yet.

Thanks, Kevin.  Tim, I've updated cvs for all branches, and bumped the
release.

>         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 jameshubbard at gmail.com  Thu Oct 30 12:23:21 2008
From: jameshubbard at gmail.com (James Hubbard)
Date: Thu, 30 Oct 2008 08:23:21 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <49093DB3.3030907@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud> <49085FCD.9060707@gmail.com>
	<49086038.6060800@pingoured.fr> <49093DB3.3030907@gmail.com>
Message-ID: <f3ddc6d30810300523p32c8fa77re87723d2292a500a@mail.gmail.com>

On Thu, Oct 30, 2008 at 12:53 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Pierre-Yves wrote:
>>
>> Les Mikesell wrote:
>>>
>>> I don't quite understand the obsession with making boot time faster
>>> anyway.  Machines should only boot when they have a new kernel to install.
>>>  If they aren't needed all the time they should sleep or hibernate, waking
>>> up with everything still running.
>>>
>>
>> My problem here are your two last words *still running*...
>> Maybe especially on my laptop.
>>
>
> Why is that a problem? I don't have a fedora-loaded laptop handy but ubuntu
> seems to sleep and wake up OK.

I still have problems with sleep.  It will periodically hang.  There's
an Nvidia chipset on the machine which is most of the problem.  Sleep
isn't as reliable as it should be.  A co-worker moved to Apple because
he got fed up with the sleep problems that he was having.

Under F9 when I resume from suspend it seems to take forever for it
the graphical interface to come back.  After X is back is seems to
take forever for the wireless connection to start.  It makes me wonder
if I shouldn't  shutdown the machine and reboot everytime.

The above doesn't include those that have dual boot setups either.
Boot times are important.



From rjones at redhat.com  Thu Oct 30 12:29:17 2008
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 30 Oct 2008 12:29:17 +0000
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081029140717.GA17393@jadzia.bu.edu>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<7863543B-361F-41B1-A559-796823CA5E26@nall.com>
	<20081029140717.GA17393@jadzia.bu.edu>
Message-ID: <20081030122917.GA8102@amd.home.annexia.org>

On Wed, Oct 29, 2008 at 10:07:17AM -0400, Matthew Miller wrote:
> On Wed, Oct 29, 2008 at 07:27:51AM -0500, Joe Nall wrote:
> > Not until this bug is fixed :)
> > prelink erases file-based capabilities
> > https://bugzilla.redhat.com/show_bug.cgi?id=456105
> 
> >From Jakub's 2004 paper on prelink, I see that it saves 1-2 seconds in
> startup time for openoffice swriter. Half a second or less on kword,
> konqueror, evolution, and epiphany. As computers get faster, prelink will
> still save relative time, but the absolute difference will become less and
> less perceptible. I know a second here and there adds up, but given the
> downsides, sooner or later prelink should be revisited.

Particularly since it corrupts binaries it doesn't understand :-(

http://www.redhat.com/archives/rhl-devel-list/2008-September/msg00045.html

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



From jdieter at gmail.com  Thu Oct 30 12:22:06 2008
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 30 Oct 2008 14:22:06 +0200
Subject: KDE i18n - l10n Arabic file conflict
Message-ID: <1225369326.3370.9.camel@jdlaptop>

There's a conflict between kde-i18n-Arabic and kde-l10n-Arabic:

Transaction Check Error:
  file /usr/share/locale/ar/LC_MESSAGES/kcmlilo.mo conflicts between
attempted installs of kde-l10n-Arabic-4.0.3-4.fc9.noarch and
kde-i18n-Arabic-3.5.10-1.fc9.noarch

Which component should I file the bug under?

Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/041f2a11/attachment.sig>

From limb at jcomserv.net  Thu Oct 30 12:31:23 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 30 Oct 2008 07:31:23 -0500 (CDT)
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <20081029143607.4e4c39ce@atbws1.stanford.edu>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
	<184a01e885d325a10895a8b90ce88207.squirrel@mail.jcomserv.net>
	<20081029143607.4e4c39ce@atbws1.stanford.edu>
Message-ID: <fbd50b9ba9b3757abd66fd6022579a4d.squirrel@mail.jcomserv.net>


> On Wed, 29 Oct 2008 15:06:26 -0500 (CDT) "Jon Ciesla"
> <limb at jcomserv.net> wrote:
>>
>> Apply the attached patch and drop the trailing space from line 1 of
>> pymol.desktop.
>>
>
> Thanks, will do.
>
>> But I can't install, no python-pmw available?
>>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=462250
>
> which should also be available in EPEL testing.

Got it, pymol works great, AFAICT.

> -Tim
>
> --
> CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS
>


-- 
novus ordo absurdum



From jameshubbard at gmail.com  Thu Oct 30 12:23:21 2008
From: jameshubbard at gmail.com (James Hubbard)
Date: Thu, 30 Oct 2008 08:23:21 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <49093DB3.3030907@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud> <49085FCD.9060707@gmail.com>
	<49086038.6060800@pingoured.fr> <49093DB3.3030907@gmail.com>
Message-ID: <f3ddc6d30810300523p32c8fa77re87723d2292a500a@mail.gmail.com>

On Thu, Oct 30, 2008 at 12:53 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Pierre-Yves wrote:
>>
>> Les Mikesell wrote:
>>>
>>> I don't quite understand the obsession with making boot time faster
>>> anyway.  Machines should only boot when they have a new kernel to install.
>>>  If they aren't needed all the time they should sleep or hibernate, waking
>>> up with everything still running.
>>>
>>
>> My problem here are your two last words *still running*...
>> Maybe especially on my laptop.
>>
>
> Why is that a problem? I don't have a fedora-loaded laptop handy but ubuntu
> seems to sleep and wake up OK.

I still have problems with sleep.  It will periodically hang.  There's
an Nvidia chipset on the machine which is most of the problem.  Sleep
isn't as reliable as it should be.  A co-worker moved to Apple because
he got fed up with the sleep problems that he was having.

Under F9 when I resume from suspend it seems to take forever for it
the graphical interface to come back.  After X is back is seems to
take forever for the wireless connection to start.  It makes me wonder
if I shouldn't  shutdown the machine and reboot everytime.

The above doesn't include those that have dual boot setups either.
Boot times are important.



From dominik at greysector.net  Thu Oct 30 12:34:45 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 30 Oct 2008 13:34:45 +0100
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081029205726.GD25197@nostromo.devel.redhat.com>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<20081029205726.GD25197@nostromo.devel.redhat.com>
Message-ID: <20081030123442.GB11708@mokona.greysector.net>

On Wednesday, 29 October 2008 at 21:57, Bill Nottingham wrote:
> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > > Not in the context of init.d/network, which is what I meant. (Well, not
> > > outside of gross hacks.)
> > 
> > Yes, it works in that context. /etc/sysconfig/network-scripts/ifup-wireless
> > needs a small patch which I posted in bugzilla and which has been ignored
> > for years. The patch isn't actually mine, it was posted on one of fedora lists.
> > I can't find that bugzilla report right now so I'm attaching the patch here
> > instead.
> 
> Possibly because that particular patch wasn't ever in bugzilla (AFAICT.)

It was, although it contained reindentation cosmetics. I only cleaned it up.

> It's certainly a better one, but there's still the problem of entirely
> disparate configuration (manually editing wpa_supplicant.conf, etc.)

What's wrong with manually editing wpa_supplicant.conf?

The patch doesn't break anything. I don't understand why, in the pursuit
of all-encompassing NM-based network configuration, some people don't want
to allow any alternative methods.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From kevin.kofler at chello.at  Thu Oct 30 12:37:00 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 30 Oct 2008 12:37:00 +0000 (UTC)
Subject: KDE i18n - l10n Arabic file conflict
References: <1225369326.3370.9.camel@jdlaptop>
Message-ID: <loom.20081030T123243-431@post.gmane.org>

Jonathan Dieter <jdieter <at> gmail.com> writes:
> There's a conflict between kde-i18n-Arabic and kde-l10n-Arabic:
> 
> Transaction Check Error:
>   file /usr/share/locale/ar/LC_MESSAGES/kcmlilo.mo conflicts between
> attempted installs of kde-l10n-Arabic-4.0.3-4.fc9.noarch and
> kde-i18n-Arabic-3.5.10-1.fc9.noarch
> 
> Which component should I file the bug under?

None, it's already filed:
https://bugzilla.redhat.com/show_bug.cgi?id=465715
but unfortunately we can't fix it for the reasons described in the bug report 
(upstream dropped the Arabic translation from KDE 4.1 because nobody updated 
it). :-( Somebody needs to work with upstream KDE to get the Arabic translation 
back into a shippable state. Fedora 10 does not include kde-l10n-Arabic at all 
at the moment. This is a pretty sad state of affairs. :-(

A few other languages are also affected by this issue (translations dropped 
from 4.1), but none as widely spoken as Arabic.

        Kevin Kofler



From sundaram at fedoraproject.org  Thu Oct 30 12:53:51 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Oct 2008 18:23:51 +0530
Subject: Reasons to preseve X on tty7
In-Reply-To: <alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>
	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>
	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
Message-ID: <4909AE5F.6070606@fedoraproject.org>

R P Herrold wrote:
> On Thu, 30 Oct 2008, Rahul Sundaram wrote:
> 
>>> source: http://distrowatch.com/
>>
>> Try finding something more relevant than the number of people clicking 
>> a particular distrowatch page everyday.
> 
> Keep your venom -- I decline to ingest it.  It is easy to cast stones, 
> but the point remains that there are tangible numbers, and that the 'one 
> hand' argument is bunk.

Distrowatch page hits are not useful at all to gather general metrics. 
Telling you that requires ingesting no venom. Just accepting facts.

> I offered the best metric I know of, one which requires sustained effort 
> to rig, and (having provided both the lead site's hosting for a while, 
> and also a mirror), I know a bit about how such 'padding' is detectable 
> with the code then used.
> 
> Find a better metric yourself, and tell us all.


Oh, we already did for Fedora.

http://fedoraproject.org/wiki/Infrastructure/Metrics
http://smolts.org/

OpenSUSE is adopting is. EPEL includes packages for EL. Ask your 
favourite distribution to include it as well.

Also

http://fedoraproject.org/wiki/Statistics

#1 thing to understand: There is no precise numbers anywhere and nothing 
even close to "good enough" as a universal solution to that problem yet.

Rahul






From lesmikesell at gmail.com  Thu Oct 30 12:56:31 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 07:56:31 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <f3ddc6d30810300523p32c8fa77re87723d2292a500a@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>
	<49085FCD.9060707@gmail.com>	<49086038.6060800@pingoured.fr>
	<49093DB3.3030907@gmail.com>
	<f3ddc6d30810300523p32c8fa77re87723d2292a500a@mail.gmail.com>
Message-ID: <4909AEFF.7090403@gmail.com>

James Hubbard wrote:
> On Thu, Oct 30, 2008 at 12:53 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
>> Pierre-Yves wrote:
>>> Les Mikesell wrote:
>>>> I don't quite understand the obsession with making boot time faster
>>>> anyway.  Machines should only boot when they have a new kernel to install.
>>>>  If they aren't needed all the time they should sleep or hibernate, waking
>>>> up with everything still running.
>>>>
>>> My problem here are your two last words *still running*...
>>> Maybe especially on my laptop.
>>>
>> Why is that a problem? I don't have a fedora-loaded laptop handy but ubuntu
>> seems to sleep and wake up OK.
> 
> I still have problems with sleep.  It will periodically hang.  There's
> an Nvidia chipset on the machine which is most of the problem.  Sleep
> isn't as reliable as it should be.  A co-worker moved to Apple because
> he got fed up with the sleep problems that he was having.
> 
> Under F9 when I resume from suspend it seems to take forever for it
> the graphical interface to come back.  After X is back is seems to
> take forever for the wireless connection to start.  It makes me wonder
> if I shouldn't  shutdown the machine and reboot everytime.
> 
> The above doesn't include those that have dual boot setups either.
> Boot times are important.

The one I tried was a windows dual-boot but set up to run the unbuntu 
partition under VMware as well (going the other way would have required 
relicensing windows on each switch from VM to native mode).   So it 
doesn't boot linux in native mode often, but it did seem to sleep and 
wake up only slightly slower than windows. It also has Nvidia video but 
I think it has the vendor drivers since it is easy under ubuntu. I've 
seen some problems mentioned with sleep using the nv driver. 
Reconnecting to wireless did seem slower than windows, but somewhat 
randomly and only by a few seconds.

Apple has had this right for years - you could close/open the old g4 
powerbooks and they'd be ready in seconds and you can just click 'sleep' 
on the others for the same effect.  It probably wastes a bit of power to 
keep the keyboard active to wake the machine up, but it is worth it to 
still have all your programs open where you left them almost instantly.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From roland.wolters at credativ.de  Thu Oct 30 13:19:07 2008
From: roland.wolters at credativ.de (Roland Wolters)
Date: Thu, 30 Oct 2008 14:19:07 +0100
Subject: Packaging Hobbit (network monitor) - anyone interested in helping
	out?
Message-ID: <200810301419.13994.roland.wolters@credativ.de>

Hi list,

currently I am trying to package hobbit (client + server) for EPEL and Fedora. 
I have to do that anyway, but it would be nice to have high quality packages 
upstream in the EPEL/Fedora repositories.

However, I'm only used to "light" packages where configure,make,make install is 
sufficient. Hobbit, in contrast, is a real beast, and needs quite some deep 
knowledge in init scripting and other stuff.

I started with the upstream provided RPMs and the ones I found at 
razorsedge.org and tried to come up with something. Currently I have packages 
which at least work - but which are pretty ugly, use quite some dark magic and 
are not at all compliant to rpmlint, Fedora's principles or even good taste.

So, is there anyone who wants to help out with the packages? I would agree to 
be the maintainer of the packages once they are in the repositories. 
Additionally, the Debian package maintainer already agreed to help with the 
packaging and together we would try to ask upstream for adjustments, fixes and 
other stuff to make life easier for packagers (and maybe admins/users) in the 
mid term.

The current version is here:
www.credativ.com/~rwo/hobbit-4.2.0-1.src.rpm
DON'T use that in production yet!

What is still missing:
- Making the init files pretty:
Currently the init files launch another script whcih behaves like just a nother 
init file. That can be made easier I think. Also/Maybe du to that, the init 
files do not properly react to start/stop in case of problems, and not all 
processes are shut down properly.

- pid files:
Currently pid files lie in /var/log/hobbit/, but should at least be in 
/var/run/hobbit. Due to the shell magic already done by upstream this might be 
more difficult than it sounds now.

- Licences:
The package seems to be GPL2, but some files are BSD and PD, this need to be 
addresed in the spec file.

- Installation:
Right now  the server requires the client due to some files included with teh 
client package. However, server and client must not run together, so the 
question is if this should be checked at runtime (current solution) or with 
package excludes (like razorsedge.org does, for example).

- General Cleaning:
As mentioned above, there is much too much dark magic in all the files around 
Hobbit, so it will be necessary in the long term to clean all the shell 
scripts to make them at least Fedora/EPEL compliant, or, even better, 
distribution agnostic.

- Upstream:
There is already a set of patches included since upstream still hasn't 
released a new version. Also, quite some shell magic really hurts the 
packagers (Debian as well as "us"), so it might be helpfull to talk to 
upstream together.

So, as I said, the package is ugly, and this task is for people who need a 
challenge. However, Hobbit is quite a nice program and it is worth it.

Best regards,

Roland
-- 
Roland Wolters
Tel.: +49 (0)21 61 / 46 43-181
pgp fingerprint: D2DE 4612 9C7D 7B7A 420D 84A8 E900 29F9 C16C 2283

credativ GmbH, HRB M?nchengladbach 12080 
Hohenzollernstr. 133, 41061 M?nchengladbach 
Gesch?ftsf?hrung: Dr. Michael Meskes, J?rg Folz
-------------- 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/20081030/aea26dfa/attachment.sig>

From skvidal at fedoraproject.org  Thu Oct 30 13:11:00 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 30 Oct 2008 09:11:00 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225338232.32092.9.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225281461.21057.0.camel@optimus>
	<1225283190.23396.10.camel@nibbler.dlib.indiana.edu>
	<49087249.8050905@ij.net>
	<1225290770.23396.32.camel@nibbler.dlib.indiana.edu>
	<gea202$mbt$1@ger.gmane.org>
	<604aa7910810290932m252c8a28pca37156ac252d5bb@mail.gmail.com>
	<1225302097.3846.74.camel@mentor.gurulabs.com>
	<1225338232.32092.9.camel@localhost.localdomain>
Message-ID: <1225372260.21485.102.camel@rosebud>

On Wed, 2008-10-29 at 23:43 -0400, Dan Williams wrote:
> On Wed, 2008-10-29 at 11:41 -0600, Dax Kelson wrote:
> > On Wed, 2008-10-29 at 08:32 -0800, Jeff Spaleta wrote:
> > > On Wed, Oct 29, 2008 at 8:11 AM, Matthew Woehlke
> > > > it don't appear to care about the objections; they're not responding
> > > > intelligently to them,
> > > 
> > > I don't have an intelligent response to any argument which essentially
> > > comes down to "tradition."  Have the traditionalists pulled put forth
> > > any consensus document like an RFC to support that at some point in
> > > time a group of people actually talk through the need for doing gettys
> > > a certain way?
> > > 
> > > Traditions which codify a collection of arbitrary decisions..are
> > > traditions I will gladly help throw into the fire.
> > 
> > Jef,
> > 
> > Not you too. My arguments are NOT "essentially" tradition. One of my 9
> > distinct arguments was Fedora becomes inconsistent with itself.
> > 
> > Another was that Fedora becomes incompatible with other Linux
> > distributions. Do we really want to go down the path where we have to
> > have "Fedora experts", "SUSE experts, "Ubuntu experts", etc and there is
> > no such thing as a "Linux expert"? That were the path of frivolous
> > incompatibilities leads.
> 
> Plus, distros are already incompatible.  Debian has a completely
> different network config system than Fedora does, same with SUSE.  The
> distros put their config files in different places.  There are two main
> packaging formats.  Having a vt somewhere else is _soooo_ much less
> incompatible than apt vs. rpm.
> 

deb vs rpm

apt != rpm
rpm != apt

-sv




From notting at redhat.com  Thu Oct 30 13:47:13 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 30 Oct 2008 09:47:13 -0400
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081030123442.GB11708@mokona.greysector.net>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<20081029205726.GD25197@nostromo.devel.redhat.com>
	<20081030123442.GB11708@mokona.greysector.net>
Message-ID: <20081030134713.GC7510@nostromo.devel.redhat.com>

Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > Possibly because that particular patch wasn't ever in bugzilla (AFAICT.)
> 
> It was, although it contained reindentation cosmetics. I only cleaned it up.

Not in either of the open bugs about wpa & initscripts. Perhaps it's
hiding somewhere else. (The ones in the open bugs were 'start WPA
supplicant and magically hope it associates in time'.)

> 
> > It's certainly a better one, but there's still the problem of entirely
> > disparate configuration (manually editing wpa_supplicant.conf, etc.)
> 
> What's wrong with manually editing wpa_supplicant.conf?

For WEP, you put keys <in one place>. For WPA you put keys and networks <this
entirely separate place and format>. It's a hack.

Bill



From mjg at redhat.com  Thu Oct 30 13:50:50 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Thu, 30 Oct 2008 13:50:50 +0000
Subject: Reasons to preseve X on tty7
In-Reply-To: <49093DB3.3030907@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
	<49085FCD.9060707@gmail.com> <49086038.6060800@pingoured.fr>
	<49093DB3.3030907@gmail.com>
Message-ID: <20081030135050.GA30892@srcf.ucam.org>

On Wed, Oct 29, 2008 at 11:53:07PM -0500, Les Mikesell wrote:

> Why is that a problem? I don't have a fedora-loaded laptop handy but 
> ubuntu seems to sleep and wake up OK.

Whether resume works or not is heavily dependent upon your BIOS, 
motherboard chipset and graphics hardware. Most systems should work in 
F10, but there's plenty that won't.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From smooge at gmail.com  Thu Oct 30 13:53:05 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Thu, 30 Oct 2008 07:53:05 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029221111.a6a1e629.zaitcev@redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<1225315942.21485.94.camel@rosebud>
	<604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>
	<80d7e4090810291837m19b4064co7ecb1799db1d4e40@mail.gmail.com>
	<20081029221111.a6a1e629.zaitcev@redhat.com>
Message-ID: <80d7e4090810300653l6a76e918nc113f707f08c7c13@mail.gmail.com>

On Wed, Oct 29, 2008 at 10:11 PM, Pete Zaitcev <zaitcev at redhat.com> wrote:
> On Wed, 29 Oct 2008 19:37:51 -0600, "Stephen John Smoogen" <smooge at gmail.com> wrote:
>
>> Actually I was thinking about this on the way home. One of the issues
>> with communicating these things is that we do have to regularly spam
>> lists with whats going on... its part of being a big group.. you have
>> to communicate regularly, clearly, and precisely. []
>
> Look, the problem here is, it was inconceivable to everyone involved
> that this little thing will get someone's panty in a wad. It's utter
> non-problem, despite all the pages and pages and pages of rhethoric
> about some manuals or whatnot. It's madness. Attempting to communicate
> any such insignificant matter regularly, clearly, and precisely is
> a recipy for people's eyes glazing over. I don't even read meeting
> minutes these days. If things like X on tty1 start to appear in
> regular communications, I'll have to filter out more.

Jeff asked for an approach to deal with this in the future, I gave a strawman.

What is the equivalent change in the Linux kernel? A userland API
change? While its more likely a 15+ year old side-effect, at what
point do those get treated like API's (my memory of LWN's Linux page
says that they have been treated as such before and needed to be dealt
with accordingly)? How are those dealt with?




-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From cra at WPI.EDU  Thu Oct 30 13:59:37 2008
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 30 Oct 2008 09:59:37 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <20081030122917.GA8102@amd.home.annexia.org>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<7863543B-361F-41B1-A559-796823CA5E26@nall.com>
	<20081029140717.GA17393@jadzia.bu.edu>
	<20081030122917.GA8102@amd.home.annexia.org>
Message-ID: <20081030135937.GN24297@angus.ind.WPI.EDU>

On Thu, Oct 30, 2008 at 12:29:17PM +0000, Richard W.M. Jones wrote:
> On Wed, Oct 29, 2008 at 10:07:17AM -0400, Matthew Miller wrote:
> > On Wed, Oct 29, 2008 at 07:27:51AM -0500, Joe Nall wrote:
> > > Not until this bug is fixed :)
> > > prelink erases file-based capabilities
> > > https://bugzilla.redhat.com/show_bug.cgi?id=456105
> > 
> > >From Jakub's 2004 paper on prelink, I see that it saves 1-2 seconds in
> > startup time for openoffice swriter. Half a second or less on kword,
> > konqueror, evolution, and epiphany. As computers get faster, prelink will
> > still save relative time, but the absolute difference will become less and
> > less perceptible. I know a second here and there adds up, but given the
> > downsides, sooner or later prelink should be revisited.
> 
> Particularly since it corrupts binaries it doesn't understand :-(
> 
> http://www.redhat.com/archives/rhl-devel-list/2008-September/msg00045.html
> 
> Rich.

And prelink still messes up "rpm -V" output.  rpm -Va has become 
pretty useless since prelink was added.  I know it is supposed to 
un-prelink on-the-fly to do the verify operation via prelink --verify, 
but this doesn't seem to work much of the time.  rpm -Va from an F9 
system:

prelink: /usr/lib/libnetembryo.so.0.5.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libnetembryo.so.0.5.0
prelink: /usr/lib/libdvbpsi.so.5.0.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libdvbpsi.so.5.0.0
prelink: /usr/lib/libwx_baseu-2.6.so.0.4.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libwx_baseu-2.6.so.0.4.0
prelink: /usr/lib/libwx_baseu_net-2.6.so.0.4.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libwx_baseu_net-2.6.so.0.4.0
prelink: /usr/lib/libwx_baseu_xml-2.6.so.0.4.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libwx_baseu_xml-2.6.so.0.4.0
prelink: /usr/lib/libwx_gtk2u_adv-2.6.so.0.4.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libwx_gtk2u_adv-2.6.so.0.4.0
prelink: /usr/lib/libwx_gtk2u_core-2.6.so.0.4.0: at least one of 
file's dependencies has changed since prelinking
S.?.....    /usr/lib/libwx_gtk2u_core-2.6.so.0.4.0
prelink: /usr/lib/libwx_gtk2u_html-2.6.so.0.4.0: at least one of 
file's dependencies has changed since prelinking
S.?.....    /usr/lib/libwx_gtk2u_html-2.6.so.0.4.0
prelink: /usr/lib/libwx_gtk2u_qa-2.6.so.0.4.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libwx_gtk2u_qa-2.6.so.0.4.0
prelink: /usr/lib/libwx_gtk2u_xrc-2.6.so.0.4.0: at least one of file's 
dependencies has changed since prelinking
prelink: /usr/lib/libnemesi.so.0.604.0: at least one of file's 
dependencies has changed since prelinking
S.?.....    /usr/lib/libnemesi.so.0.604.0

etc.



From dcbw at redhat.com  Thu Oct 30 14:04:41 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 30 Oct 2008 10:04:41 -0400
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081030123442.GB11708@mokona.greysector.net>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<20081029205726.GD25197@nostromo.devel.redhat.com>
	<20081030123442.GB11708@mokona.greysector.net>
Message-ID: <1225375481.19928.15.camel@unused>

On Thu, 2008-10-30 at 13:34 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 29 October 2008 at 21:57, Bill Nottingham wrote:
> > Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > > > Not in the context of init.d/network, which is what I meant. (Well, not
> > > > outside of gross hacks.)
> > > 
> > > Yes, it works in that context. /etc/sysconfig/network-scripts/ifup-wireless
> > > needs a small patch which I posted in bugzilla and which has been ignored
> > > for years. The patch isn't actually mine, it was posted on one of fedora lists.
> > > I can't find that bugzilla report right now so I'm attaching the patch here
> > > instead.
> > 
> > Possibly because that particular patch wasn't ever in bugzilla (AFAICT.)
> 
> It was, although it contained reindentation cosmetics. I only cleaned it up.
> 
> > It's certainly a better one, but there's still the problem of entirely
> > disparate configuration (manually editing wpa_supplicant.conf, etc.)
> 
> What's wrong with manually editing wpa_supplicant.conf?

Because it's not easily from anything but wpa_supplicant, and it's
completely different than the existing ifup/ifdown config system.
System-config-network would have to grow the ability to parse the
wpa_supplicant config file format.  You can't override the variables
from /etc/sysconfig/network if you want to.  There's no separation of
interfaces to allow for multiple connections with two or more wifi cards
with 'ifup number1' and 'ifup number2' independently.

A much better, more integrated and consistent implementation would have
each ifcfg file essentially be a network block in the supplicant config
file.  When you 'ifup my-wpa', the scripts write out a new supplicant
config file using key/value pairs
in /etc/sysconfig/network-scripts/ifcfg-my-wpa and execute a supplicant
based on that, then somehow wait for the supplicant to connect by
listening on the specific control socket for a connection, and if no
connection occurs, time out and fail just like DHCP fails.  When you
'ifdown my-wpa', it will terminate the supplicant based on the PID file
written to /var/run/wpa_supplicant-wlan0-my-wpa.pid and clean up the
routing and addresses.

That's what the patch _should_ do.  Just tossing a config file off to
the supplicant is a cop-out half solution.

> The patch doesn't break anything. I don't understand why, in the pursuit
> of all-encompassing NM-based network configuration, some people don't want
> to allow any alternative methods.

Look in bugzilla.  There have been wpa_supplicant bugs filed and many
mailing list posts where I and others have said "If somebody shows up to
add WPA support to initscripts in the right way that's great!"  We're
just not going to spend effort on it.

Dan




From hhoffman at ip-solutions.net  Thu Oct 30 14:43:56 2008
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Thu, 30 Oct 2008 10:43:56 -0400
Subject: A couple of install bugs...
Message-ID: <1225377837.6763.3.camel@n1-14-96.dhcp.drexel.edu>

Hi,

These are related to FC9 but might be in FC10 too (I haven't had a
chance to test).

In installation of FC9 (x86_64) if you select XFCE as a group the
installer doesn't actually install that group of packages.


If you are doing a re-install and have more then one encrypted LVM the
installer will prompt for each LVM password and unlock the volumes.

The problem is that only one of the two LVM names are there and you are
unable to manipulate the partitions inside of the lvm (or the lvms
themselves).

Cheers,
Harry





From jdieter at gmail.com  Thu Oct 30 14:53:46 2008
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 30 Oct 2008 16:53:46 +0200
Subject: KDE i18n - l10n Arabic file conflict
In-Reply-To: <loom.20081030T123243-431@post.gmane.org>
References: <1225369326.3370.9.camel@jdlaptop>
	<loom.20081030T123243-431@post.gmane.org>
Message-ID: <1225378426.3370.15.camel@jdlaptop>

On Thu, 2008-10-30 at 12:37 +0000, Kevin Kofler wrote:
> None, it's already filed:
> https://bugzilla.redhat.com/show_bug.cgi?id=465715
> but unfortunately we can't fix it for the reasons described in the bug report 
> (upstream dropped the Arabic translation from KDE 4.1 because nobody updated 
> it). :-( Somebody needs to work with upstream KDE to get the Arabic translation 
> back into a shippable state. Fedora 10 does not include kde-l10n-Arabic at all 
> at the moment. This is a pretty sad state of affairs. :-(
> 
> A few other languages are also affected by this issue (translations dropped 
> from 4.1), but none as widely spoken as Arabic.

Bummer.  What exactly does it take to become a translator?  I work at a
total-immersion English-speaking school for Lebanese kids (whose native
language is obviously Arabic).  There might be some potential for
getting some of them involved.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/872da12b/attachment.sig>

From mw_triad at users.sourceforge.net  Thu Oct 30 15:01:23 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 30 Oct 2008 10:01:23 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029215416.GM25197@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082E6B.7080304@hhs.nl>
	<ge9bsl$2fp$1@ger.gmane.org>	<4908360D.8060900@hhs.nl>	<alpine.LRH.2.00.0810291122590.954@arj.bjyevire.pbz>	<20081029213322.GK25197@nostromo.devel.redhat.com>	<gealof$4l0$1@ger.gmane.org>
	<20081029215416.GM25197@nostromo.devel.redhat.com>
Message-ID: <geci83$fnu$1@ger.gmane.org>

Bill Nottingham wrote:
> Matthew Woehlke (move_along at nothing_to_see_here) said: 

Thank you :-)

> Well, it's "linux users". It does bring up the interesting side effect
> that with the EEE, it's likely Xandros is the leading desktop Linux
> distribution now, by an insanely wide margin.

Possibly :-). Though from my experience with it, I might argue with 
calling it a "desktop" distro. The EEE with Xandros feels more like an 
appliance to me (which I'm sure is what they were going for).

> (As for Fedora installs that use NFS, well, we can't have useful stats
> without having machines report home as to what modules are loaded, what
> filesystems are mounted, etc. Which brings up an entirely different flamewar.)

Ah, the eternal problem collecting any sort of stats on Linux :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
This was, apparently, beyond her ken.  So far beyond her ken that she 
was well into barbie territory. -- J. D. Baldwin (from cluefire.net)



From dominik at greysector.net  Thu Oct 30 15:15:06 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 30 Oct 2008 16:15:06 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <gealfk$4td$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com> <4908C09B.6080609@gmail.com>
	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
	<4908C757.1000902@gmail.com> <gealfk$4td$1@ger.gmane.org>
Message-ID: <20081030151505.GA15721@mokona.greysector.net>

On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
[...]
> Granted, I may not be "most", but here's what I run:
[...]
> Home:
[...]
> - Xandros (on my Asus EEE, and only because I haven't had time to find 
> something better; how's Fedora on those?)

Fedora works great on those. I'm happily running F10 since snap2.
All I needed was an akmod from rpmfusion (rt2860sta driver) and
a pm quirk to re-enable screen after resume.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From wolfy at nobugconsulting.ro  Thu Oct 30 15:27:33 2008
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Thu, 30 Oct 2008 17:27:33 +0200
Subject: Packaging Hobbit (network monitor) - anyone interested in
 helping out?
In-Reply-To: <200810301419.13994.roland.wolters@credativ.de>
References: <200810301419.13994.roland.wolters@credativ.de>
Message-ID: <4909D265.4070802@nobugconsulting.ro>

Roland Wolters wrote:
> Hi list,
>
> currently I am trying to package hobbit (client + server) for EPEL and Fedora. 
> I have to do that anyway, but it would be nice to have high quality packages 
> upstream in the EPEL/Fedora repositories.
> [...]
> - Installation:
> Right now  the server requires the client due to some files included with teh 
> client package. However, server and client must not run together, so the 
> question is if this should be checked at runtime (current solution) or with 
> package excludes (like razorsedge.org does, for example).
>   
usually this can be handled by creating a hobbit-common package which 
includes the stuff needed by both client and server and two other 
packages, for client and for server.



From mw_triad at users.sourceforge.net  Thu Oct 30 15:30:37 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 30 Oct 2008 10:30:37 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <490943C0.4070703@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>	<4908C757.1000902@gmail.com>	<gealfk$4td$1@ger.gmane.org>
	<490943C0.4070703@gmail.com>
Message-ID: <gecjut$mlc$1@ger.gmane.org>

Les Mikesell wrote:
> Matthew Woehlke wrote:
>> Les Mikesell wrote:
>>> I'd expect most people who install fedora themselves to have at least 
>>> a couple of other OS's running concurrently.  Has anyone done a poll 
>>> about this recently?
>>
>> Why would you expect that?
> 
> Because it is experimental and high maintenance to run.

I beg to differ. Building KDE from trunk, now /that's/ "experimental and 
high maintenance", and even that not so much. The only problem I've had 
with Fedora 8/9 is the cr*p nvidia drivers don't work quite right on my 
setup, and that's hardly Fedora's fault.

Maintenance... sure, I run 'yum update' every few days, big deal :-). 
Most of the Fedora-related headaches I run into are from needing a newer 
package than what's in the official updates due to a requirement in 
KDE's trunk (like cmake 2.6.2, which I'm hoping will get pushed through 
before it becomes a hard requirement in a few weeks).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
This was, apparently, beyond her ken.  So far beyond her ken that she 
was well into barbie territory. -- J. D. Baldwin (from cluefire.net)



From nils at redhat.com  Thu Oct 30 15:31:25 2008
From: nils at redhat.com (Nils Philippsen)
Date: Thu, 30 Oct 2008 16:31:25 +0100
Subject: Firewalls and inter-team communication, was: Browser mode for
 nautilus
In-Reply-To: <20081027214856.GC1541@tango.0pointer.de>
References: <1225126695.14473.55.camel@x61.fubar.dk>
	<64b14b300810271104q7ef00b27hc21c46521827fe79@mail.gmail.com>
	<1225131238.14473.59.camel@x61.fubar.dk>
	<1225133403.8033.28.camel@rosebud>
	<1225134992.14473.74.camel@x61.fubar.dk>
	<1225135512.8033.31.camel@rosebud>
	<20081027204924.GA29373@tango.0pointer.de>
	<1225141454.8033.50.camel@rosebud>
	<20081027211919.GA1541@tango.0pointer.de>
	<80d7e4090810271429r1f58cc2cjda8538828e6ead9b@mail.gmail.com>
	<20081027214856.GC1541@tango.0pointer.de>
Message-ID: <1225380685.10115.2.camel@gibraltar.str.redhat.com>

Hi all,

I've added fedora-devel-list to Cc as this topic isn't really limited to
the desktop.

On Mon, 2008-10-27 at 22:48 +0100, Lennart Poettering wrote: 
> On Mon, 27.10.08 15:29, Stephen John Smoogen (smooge at gmail.com) wrote:
> 
> > > Having desktop firewalls is security theatre. Having 20 levels of
> > > false and inappropriate security is worse then having a single level
> > > of security that is appropriate for the task.
> > 
> > My guess is that having priv-sep, passwords, etc are all security
> > theatre for the desktop user in this case. I mean if application X
> > can't work without me being root then why not be root? If having a
> > password slows me down from getting stuff done, why not remove it. For
> > this level.. why are we doing anything beyond Windows 98 which seems
> > to be the perfect desktop platform.
> 
> You are making stupid generalizations here, and you know that.
> 
> Please don't talk to to me like I was a complete moron or
> something. In Avahi for example (which I wrote) I went into great
> lengths to run the code in an environment that is as confined as
> possible. We use stuff like chroot(), capabilities, we run as seperate
> user with minimal resource limits and stuff like that, so that even
> without SELinux an exploited Avahi does not allow attackers to exploit
> the entire system.
> 
> In fact, on my F10 system here that runs a lot of stuff in addition to
> the standard install, Avahi is still the *only* process which does
> all that security stuff. No other daemon employs chroot() or anything
> similar. So please, don't tell me I had no clue about how to secure
> daemons on Linux.

A bit off-topic for what's really my concern with this mail, but anyway:
that's probably because chroot() is seen by many as not being a security
tool(*), i.e. it's giving a false sense of security that should be
avoided, which would be consistent with comments made in this thread.

(*): In short: If the process can or is run as root, it can escape a
chroot "jail", if it's running as a normal user, it can't really do the
bad things a chroot environment would inhibit.

What I find a bit puzzling is that many people in this thread made
comments about the firewall being broken (or breaking something on the
desktop), but nobody thought about maybe inviting the iptables package
maintainer to this discussion. I happen to know him and if one --
depending on the POV -- might accuse him of not being exactly open
minded for all proposals coming out of the desktop corner, it's probably
because he'd rather err on the side of caution than be sorry later.

In general I'd very much suggest, when it comes to things that affect
areas other than one's own, to involve the affected persons or teams
early on in the discussion. If one discusses such matters only in one's
own "cabal" -- and I'm using that word with care, because that's exactly
how it's come across in a few instances -- and if one only after the
discussion is over presents something fait-accompli style to the rest of
the world, it very much begs for being shot down. Let me compare this to
casting concrete when parts of it have already begun setting, the result
surely won't be stable or homogenous.

The reason for that is quite simple, it basically boils down to that
nobody is super-human: We all make mistakes. To a certain degree, we
tend to concentrate on the stuff we're most experienced with and miss
things in other areas. Likewise, more often than not we put more
priority on issues that more visibly affect our own turf than on other
things and neglect how our own approach to a certain problem is
detrimental in other use cases. We all occasionally can't see the wood
for the trees.

> Use the appropriate tools for locking things down. Don't add
> protection that is bogus because it will be overriden by the user
> anyway. I am very sure that exactly 0% of all users deactivate all the
> security techniques that Avahi uses -- because they have no reason
> to. Because it doesn't limit the use of AVahi in any way -- it doesn't
> go against what users want to do.

Just as a side note, you've very carefully left out people disabling
avahi because it broke other things. Right on cue just this week, a
colleague disabled avahi on a server where its adding a route into the
169.something auto-IP network made it unreachable in the network, maybe
because that machine (for security reasons) didn't have a default
gateway. The machine in question is RHEL5, so any misbehavior on part of
avahi may be fixed by now, but this is still a good example for a
component unintentionally breaking basic functionality because its
possible impacts in "out of scope" use scenarios weren't fully assessed.
Needless to say that the colleague didn't ask for avahi to be installed
(it doesn't make much sense on a server), it got dragged in by
dependencies.

But I'm digressing: My plea for this week would be that we'd all begin
to look a bit more beyond our own noses and get to the point where
involving other people and teams right away becomes the norm, instead of
trying to circumvent the (perceived or not) shortcomings of components
or areas for which these others are really responsible.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From alsadi at gmail.com  Thu Oct 30 15:42:41 2008
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 30 Oct 2008 18:42:41 +0300
Subject: KDE i18n - l10n Arabic file conflict
In-Reply-To: <1225378426.3370.15.camel@jdlaptop>
References: <1225369326.3370.9.camel@jdlaptop>
	<loom.20081030T123243-431@post.gmane.org>
	<1225378426.3370.15.camel@jdlaptop>
Message-ID: <385866f0810300842v5af6a817vb5156d6ef2ce5e68@mail.gmail.com>

I'll try to get Arabeyes.org on this topic



From notting at redhat.com  Thu Oct 30 15:44:05 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 30 Oct 2008 11:44:05 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
Message-ID: <20081030154405.GA12240@nostromo.devel.redhat.com>

Dan Nicholson (dbn.lists at gmail.com) said: 
> I didn't suggest having plymouth change to tty7. In fact, I posted a
> patch so that it's all controlled from /etc/sysconfig/desktop instead
> of having plymouth and gdm work behind the scenes.
> 
> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02516.html
> 
> Does that seem reasonable at all?

Better, but still problematic, especially on runlevel 3->5 transitions:

- by moving the trigger to prefdm, you get gdm/X on whatever tty you run
  telinit from...
- which makes the logic w.r.t. tty1 in /etc/event.d/tty1 incorrect

Bill



From mackay_d at bellsouth.net  Thu Oct 30 15:51:49 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Thu, 30 Oct 2008 10:51:49 -0500
Subject: Reasons to preseve X on tty7
Message-ID: <1225381909.5412.188.camel@vorpal.macdev.com>

On Wed, 2008-10-29 at 11:28 -0400, seth vidal wrote:
        > On Wed, 2008-10-29 at 10:24 -0500, David G. Mackay wrote:
        > > On Wed, 2008-10-29 at 08:51 -0400, seth vidal wrote:
        > > > There's no one working in computing today ANYWHERE who is
        doing
        > > > revolutionary work. I'd argue there is no such thing as
        revolutionary
        > > > work AT ALL. Stop looking for it where it is not.
        > > 
        > > What about quantum computing?  A fundamental paradigm shift
        seems like
        > > it ought to count.
        > 
        > IBIWISI.
        
        If you expected to see it, then it wouldn't be revolutionary,
        would it?
        
        Dave

        



From mw_triad at users.sourceforge.net  Thu Oct 30 15:55:00 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 30 Oct 2008 10:55:00 -0500
Subject: Fedora on EEE?
Message-ID: <geclck$mlc$2@ger.gmane.org>

Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
>> - Xandros (on my Asus EEE, and only because I haven't had time to find 
>> something better; how's Fedora on those?)
> 
> Fedora works great on those. I'm happily running F10 since snap2.
> All I needed was an akmod from rpmfusion (rt2860sta driver) and
> a pm quirk to re-enable screen after resume.

Cool. Got any "how to" pages handy?

Anyway, a couple question about Fedora on EEE...

- Does Fedora know about multi-touch? (The default Xandros uses 
multi-touch for scrolling, not very reliable but still nice to have.)

- What FS is best? (Given that you're dealing with a SSD.) Also, does 
the lack of swap cause any "interesting" problems? Any other caveats 
related to the SSD?

- Does compiz run? ;-)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
This was, apparently, beyond her ken.  So far beyond her ken that she 
was well into barbie territory. -- J. D. Baldwin (from cluefire.net)



From lesmikesell at gmail.com  Thu Oct 30 15:57:23 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 10:57:23 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <gecjut$mlc$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>	<4908C757.1000902@gmail.com>	<gealfk$4td$1@ger.gmane.org>	<490943C0.4070703@gmail.com>
	<gecjut$mlc$1@ger.gmane.org>
Message-ID: <4909D963.8010301@gmail.com>

Matthew Woehlke wrote:
> 
>>>> I'd expect most people who install fedora themselves to have at 
>>>> least a couple of other OS's running concurrently.  Has anyone done 
>>>> a poll about this recently?
>>>
>>> Why would you expect that?
>>
>> Because it is experimental and high maintenance to run.
> 
> I beg to differ. Building KDE from trunk, now /that's/ "experimental and 
> high maintenance", and even that not so much. The only problem I've had 
> with Fedora 8/9 is the cr*p nvidia drivers don't work quite right on my 
> setup, and that's hardly Fedora's fault.

It is fedora's fault that their policy makes it difficult for you to run 
vendor drivers.  But I think you've been lucky with very common hardware 
or maybe there's been a lull in the serious breakage.  I gave up when an 
update late in the FC6 cycle which should have been stabilized by then 
and didn't need disruptive changes failed to boot from scsi on a fairly 
common dell box.

> Maintenance... sure, I run 'yum update' every few days, big deal :-). 

I don't mind running the update - it's when things don't work afterwards 
or a remote machine doesn't come back after a reboot that is the problem.

> Most of the Fedora-related headaches I run into are from needing a newer 
> package than what's in the official updates due to a requirement in 
> KDE's trunk (like cmake 2.6.2, which I'm hoping will get pushed through 
> before it becomes a hard requirement in a few weeks).

Throw in a few of the third party repositories that you need to deal 
with the policy and legal restrictions on what fedora provides and 
things get even more problematic.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From mackay_d at bellsouth.net  Thu Oct 30 16:02:42 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Thu, 30 Oct 2008 11:02:42 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029173101.GB3042@shell.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
	<1225283507.5412.178.camel@vorpal.macdev.com>
	<20081029173101.GB3042@shell.devel.redhat.com>
Message-ID: <1225382562.5412.198.camel@vorpal.macdev.com>


On Wed, 2008-10-29 at 13:31 -0400, Alan Cox wrote:
> On Wed, Oct 29, 2008 at 07:31:47AM -0500, David G. Mackay wrote:
> > > Design by committee just doesn't work.
> > 
> > So all of those ISO and IEEE standards are worthless?
> 
> Most of the good ones have a design list a few names long. Same with the
> good RFC stuff. May have had 100 people twiddle with the spec but only a tiny
> few wrote it. Compare IPv6 an OSI Level 4 ...

Sure, but the fact is that design by committee can work.  There's a book, "We Are Smarter Than Me"
by Barry Liebert, Jon Specter, and a cast of thousands.  It gives cases
where group input has been highly productive.  For that matter, how
about the linux kernel?  Group dynamics obviously forms a complex
system, which, often enough spirals off into chaos.  Every now and then,
however, it does work.

Dave




From mw_triad at users.sourceforge.net  Thu Oct 30 16:05:12 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 30 Oct 2008 11:05:12 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <4909D963.8010301@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>	<4908C757.1000902@gmail.com>	<gealfk$4td$1@ger.gmane.org>	<490943C0.4070703@gmail.com>	<gecjut$mlc$1@ger.gmane.org>
	<4909D963.8010301@gmail.com>
Message-ID: <geclvo$v87$1@ger.gmane.org>

Les Mikesell wrote:
> Matthew Woehlke wrote:
>>> [Fedora] is experimental and high maintenance to run.
>>
>> I beg to differ. Building KDE from trunk, now /that's/ "experimental 
>> and high maintenance", and even that not so much. The only problem 
>> I've had with Fedora 8/9 is the cr*p nvidia drivers don't work quite 
>> right on my setup, and that's hardly Fedora's fault.
> 
> It is fedora's fault that their policy makes it difficult for you to run 
> vendor drivers.

I'm sure this wasn't your intent anyway, but please don't put words in 
my mouth :-). I happen to *agree* with the policy. The problem, rather - 
at least as I see it - is simply that nvidia's drivers suck :-). Which 
is hardly Fedora's fault; if nvidia would get with the program and make 
Free and Open drivers, then maybe they could be fixed.

>> Maintenance... sure, I run 'yum update' every few days, big deal :-). 
> 
> I don't mind running the update - it's when things don't work afterwards 
> or a remote machine doesn't come back after a reboot that is the problem.

I'm sorry to hear about your bad experiences. I've never had such 
problems, though.

>> Most of the Fedora-related headaches I run into are from needing a 
>> newer package than what's in the official updates due to a requirement 
>> in KDE's trunk (like cmake 2.6.2, which I'm hoping will get pushed 
>> through before it becomes a hard requirement in a few weeks).
> 
> Throw in a few of the third party repositories that you need to deal 
> with the policy and legal restrictions on what fedora provides and 
> things get even more problematic.

Already have those. The only hiccup I've run into yet is waiting on new 
nvidia drivers when a kernel update hits. (Also, rpmfusion released the 
nonfree-release before the requisite free-release, but that merely 
caused a dependency failure until it was fixed...)

Given what it is, I'm sure some people have trouble with Fedora, and you 
have my sympathy if you're one of them. I'm not convinced, however, that 
such problems are the norm and not the exception.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
This was, apparently, beyond her ken.  So far beyond her ken that she 
was well into barbie territory. -- J. D. Baldwin (from cluefire.net)



From nicu_fedora at nicubunu.ro  Thu Oct 30 16:06:23 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 30 Oct 2008 18:06:23 +0200
Subject: Fedora on EEE?
In-Reply-To: <geclck$mlc$2@ger.gmane.org>
References: <geclck$mlc$2@ger.gmane.org>
Message-ID: <4909DB7F.9070509@nicubunu.ro>

Matthew Woehlke wrote:
> Dominik 'Rathann' Mierzejewski wrote:
>> On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
>>> - Xandros (on my Asus EEE, and only because I haven't had time to 
>>> find something better; how's Fedora on those?)
>>
>> Fedora works great on those. I'm happily running F10 since snap2.
>> All I needed was an akmod from rpmfusion (rt2860sta driver) and
>> a pm quirk to re-enable screen after resume.

Well, it chokes on my WPA.

> Cool. Got any "how to" pages handy?
> 
> Anyway, a couple question about Fedora on EEE...
> 
> - Does Fedora know about multi-touch? (The default Xandros uses 
> multi-touch for scrolling, not very reliable but still nice to have.)

Not sure, how can I try?

> - What FS is best? (Given that you're dealing with a SSD.) Also, does 
> the lack of swap cause any "interesting" problems? Any other caveats 
> related to the SSD?

Sorry, I have a HDD version.

> - Does compiz run? ;-)

Yes, out of the box.

-- 
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 vonbrand at inf.utfsm.cl  Thu Oct 30 13:47:54 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 30 Oct 2008 10:47:54 -0300
Subject: A suggestion regarding new features
In-Reply-To: <1225300511.3846.44.camel@mentor.gurulabs.com>
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
Message-ID: <200810301347.m9UDlswk004619@laptop14.inf.utfsm.cl>

Dax Kelson <dkelson at gurulabs.com> wrote:
> Progress is great, new shiny frobnicators are wonderful. What many
> people (myself included) object to is when old behaviors and
> compatibility is broken NEEDLESSLY.  Let's have our cake and eat it too!

To make omelette, you have to break some eggs...

> When implementing new features what about using a decision tree that
> looks like the following:
> 
> ======================================================
> 
> Step 1. Does $NEWFEATURE implementation change old behaviors or break
> compatibility? 
> 
> a) NO -> Great go for it! Let's all eat cake!
> b) YES -> See step 2

It is not really new, then.

> Step 2. Can $NEWFEATURE be implemented so that it doesn't change old
> behaviors or break compatibility?
> 
> a) NO -> Uh oh, see step 3.
> b) YES preserve both -> Excellent. Let's all eat cake!
> c) YES preserve compatibility -> Great no "exceptions". Let's all eat
> cake!

> Examples of "2c" include GRUB,

Completely different from lilo. Check.

>                                udev/hal,

Still trying to wrap my brain around that. Check.

>                                          ALSA,

Massive breakage, much gnashing of teeth, extensive flamewars. Check.

>                                                hda -> sda,

Even more massive breakage, gnashing of teeth, extensive flamewars. Check.

>                                                            LVM,

There are still people around claiming it breaks their setups so badly they
go to heroic ends to avoid it. Check.

>                                                                 FACLS
> on /dev files,

Had my own run ins with this, wan't really nice. Check.

>                CUPS,

Was a real mess until it got sorted out. Now it is great (if still a bit
misterious to me). Check.

>                      POSIX CAPs to replace SUID,

Massive change in sysadmining. Check.

>                                                  etc. All distros moved
> these features in relative unison so I can toss that old knowledge out
> of my brain (and documentation).

Old documentation has a penchant for hinding in all sorts of nooks and
crannies of the 'net, and comes to light only when $RELATIVE_NEWBIE looks
around for a fix for $MISTERY.

> Step 3. Does the benefit of $NEWFEATURE outweigh the cost of changing
> the old behavior or breaking compatibility? Obviously this can be
> subjective.
> 
> a) NO -> Good effort. Have you considered picking one of the other many
> areas in Linux that need improving and working on that?
> b) YES -> OK, $NEWFEATURE must be really awesome. Please double check
> that you can't resolve this in Step 2. So Step 2 is a no go? OK, let's
> do it.
> 
> ======================================================
> 
> Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST
> PLACE.

Not even your own "step 2" examples qualify... not by a long shot. The pain
is forgotten by now, that is all.
-- 
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 2340000       Fax:  +56 32 2797513



From seg at haxxed.com  Thu Oct 30 16:22:45 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 30 Oct 2008 11:22:45 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <4909AEFF.7090403@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud> <49085FCD.9060707@gmail.com>
	<49086038.6060800@pingoured.fr> <49093DB3.3030907@gmail.com>
	<f3ddc6d30810300523p32c8fa77re87723d2292a500a@mail.gmail.com>
	<4909AEFF.7090403@gmail.com>
Message-ID: <1225383765.4152.2.camel@localhost.localdomain>

On Thu, 2008-10-30 at 07:56 -0500, Les Mikesell wrote:
> Apple has had this right for years - you could close/open the old g4 
> powerbooks and they'd be ready in seconds and you can just click 'sleep' 
> on the others for the same effect.

Yes, it's very easy for Apple to get this right. Because they control
the hardware platform. We don't have that luxury. We're lucky if we even
get hardware documentation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/877d5a17/attachment.sig>

From rawhide at fedoraproject.org  Thu Oct 30 15:59:19 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 30 Oct 2008 15:59:19 +0000 (UTC)
Subject: rawhide report: 20081030 changes
Message-ID: <20081030155919.9A9F01F824B@releng2.fedora.phx.redhat.com>

Compose started at Thu Oct 30 06:01:10 UTC 2008

Removed package ruby-rpm
Updated Packages:

anaconda-11.4.1.53-1
--------------------
* Wed Oct 29 18:00:00 2008 David Cantrell <dcantrell at redhat.com> - 11.4.1.53-1
- Don't sleep(5) after xrandr (ajax)
- Force DPI to 96 even harder (#458738) (ajax)
- Don't try to switch VT to the one that X is on (ajax)
- Only copy /etc/resolv.conf if instPath != '/' (dcantrell)
- 'is not' -> '!=' (dcantrell)
- Write --dhcpclass instead of --class to the anaconda ks file. (jgranado)
- Fix 2 issues in pyparted found by pychecker (hdegoede)
- Add a bit of documentation to the top of runpychecker.sh (hdegoede)
- Add runpychecker.sh script and pychecker-false-positives file (hdegoede)
- Fix saving tracebacks via scp while in text mode. (clumens)
- Search for the hash in the whiteboard, not as the entire whiteboard.
  (clumens)
- Fix various syntax errors caught by PyChecker (hdegoede)
- Wouldn't it be nice to have some real documentation in filer.py? (clumens)
- Make sure the productVersion given by .treeinfo exists in bugzilla
  (#468657). (clumens)


ed-1.1-1.fc10
-------------
* Wed Oct 29 18:00:00 2008 Karsten Hopp <karsten at redhat.com> 1.1-1
- update to lastest version, fixes CVE-2008-3916


kdenetwork-4.1.2-3.fc10
-----------------------
* Mon Oct 20 18:00:00 2008 Luk?? Tinkl <ltinkl at redhat.com> 4.1.2-3
- fix kopete crashes on logout (kdebug:172011), in the account editor
  (kdebug:172985) and during login (kdebug:172997)


mash-0.4.2-2.fc10
-----------------
* Wed Oct 29 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 0.4.2-2
- Ignore the F10 key in favor of F10-beta key for now, until all builds are
  written out with the F10 key.  This prevents us from falling back to
  unsigned packages.


xorg-x11-drv-ati-6.9.0-37.fc10
------------------------------
* Thu Oct 30 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-37
- fix memory leak in -ati driver (#469024)

* Wed Oct 29 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-36
- radeon-6.9.0-add-hd3300.patch - add missing pciid (#466706)
- radeon-6.9.0-quirk-agp.patch - from Ubuntu.

* Wed Oct 29 18:00:00 2008 Dave Airlie <airlied at redhat.com> 6.9.0-35
- radeon-6.9.0-bgnr-enable.patch - enable bg none when kms enabled (#468879)


Summary:
Added Packages: 0
Removed Packages: 1
Modified Packages: 5









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From sundaram at fedoraproject.org  Thu Oct 30 16:33:17 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Oct 2008 22:03:17 +0530
Subject: Fedora on EEE?
In-Reply-To: <geclck$mlc$2@ger.gmane.org>
References: <geclck$mlc$2@ger.gmane.org>
Message-ID: <4909E1CD.2050208@fedoraproject.org>

Matthew Woehlke wrote:
> Dominik 'Rathann' Mierzejewski wrote:
>> On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
>>> - Xandros (on my Asus EEE, and only because I haven't had time to 
>>> find something better; how's Fedora on those?)
>>
>> Fedora works great on those. I'm happily running F10 since snap2.
>> All I needed was an akmod from rpmfusion (rt2860sta driver) and
>> a pm quirk to re-enable screen after resume.
> 
> Cool. Got any "how to" pages handy?

http://fedoraproject.org/wiki/EeePc
http://www.redhatmagazine.com/2008/02/14/fedora-eee-pc-eeedora/

Rahul



From vonbrand at inf.utfsm.cl  Thu Oct 30 16:34:10 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 30 Oct 2008 13:34:10 -0300
Subject: Reasons to preseve X on tty7
In-Reply-To: <604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<1225315942.21485.94.camel@rosebud>
	<604aa7910810291757p1fe32392sec108d0ef44272da@mail.gmail.com>
Message-ID: <200810301634.m9UGYAmB008061@laptop14.inf.utfsm.cl>

Jeff Spaleta <jspaleta at gmail.com> wrote:

[...]

> -jef"I guess I could start writing a weekly content column called the
> Ye Ol' Curmudgeon as part of Fedora Mag where I discuss how new
> features are going to impact people who pine for the featureset of rhl
> 6.2.  Though I don't know if I can muster enough sarcasm to keep it
> fresh and entertaining on a regular basis."spaleta

Please try. At least a couple of columns.
-- 
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 2340000       Fax:  +56 32 2797513



From vonbrand at inf.utfsm.cl  Thu Oct 30 16:37:32 2008
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 30 Oct 2008 13:37:32 -0300
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081029214326.GI1371252@hiwaay.net>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<20081029214326.GI1371252@hiwaay.net>
Message-ID: <200810301637.m9UGbW7C008088@laptop14.inf.utfsm.cl>

Chris Adams <cmadams at hiwaay.net> wrote:
> Once upon a time, Bill Nottingham <notting at redhat.com> said:
> > Are people not running rawhide and the test releases? Are they not
> > looking at features as they are proposed and being involved in the
> > process? Are they just sitting around waiting to be outraged?
> 
> Or have they not actually used a VT switch to a text console since this
> was implemented?

I noticed a month or so back, and thought it was weird (fingers know, brain
doesn't). Hunted around a bit, was no big deal; thought of reporting it,
but forgot (not a pressing issue).

> </me ducks>
</me too>
-- 
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 2340000       Fax:  +56 32 2797513



From mackay_d at bellsouth.net  Thu Oct 30 16:27:32 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Thu, 30 Oct 2008 11:27:32 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <80d7e4090810291129y148a4234y199a9da31c617817@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
	<1225293850.5412.181.camel@vorpal.macdev.com>
	<80d7e4090810291129y148a4234y199a9da31c617817@mail.gmail.com>
Message-ID: <1225384052.5412.214.camel@vorpal.macdev.com>


On Wed, 2008-10-29 at 12:29 -0600, Stephen John Smoogen wrote:
> On Wed, Oct 29, 2008 at 9:24 AM, David G. Mackay <mackay_d at bellsouth.net> wrote:
> >
> > On Wed, 2008-10-29 at 08:51 -0400, seth vidal wrote:
> >> There's no one working in computing today ANYWHERE who is doing
> >> revolutionary work. I'd argue there is no such thing as revolutionary
> >> work AT ALL. Stop looking for it where it is not.
> >
> > What about quantum computing?  A fundamental paradigm shift seems like
> > it ought to count.
> >
> 
> quantum computing is more like going back to analog computing from the
> 1940's. In the end, it will be masked by a lot of stuff that makes it
> seem like its digital because cultures are change averse... thats a

Just because we sugar coat the medicine doesn't mean it's the same
old-fashioned snake oil.

> reason why cultures exist.. to help preserve memory over a constantly
> changing universe. When you arbitrarily change something 'fundamental'
> to a culture you get a reaction in the opposite way.. the reaction is
> usually dis appropriately stronger than the original change because
> people are wired to maintain culture for survival.

Shades of Margarette Meade.  Cultures that won't adapt get swallowed by
those that can, usually.  China is an example of one that was able to
just absorb several sets of conquerors.  Most others in recent history,
Inuits, American Indians, etc., weren't so massively grounded in
tradition.

> The important thing is that individuals usually do not hold the same
> things to be fundamental as other individuals. Changing the TTY
> affects some people who work there a lot more than those who never use
> it.. but it might also affect someone who has it in the root of their
> soul: "If my computer is fucked-up, CNTRL-ALT-F1 to try and get it
> back." Changing a bed-rock principle that is pretty much in every
> chapter 1 linux book is a BIG deal and not something that can be
> washed over with a couple of emails. Most of the wars during the
> Reformation were started over smaller things.

I can see it now, a modern Martin Luther nailing his changelog to the
distro's door.  Ack!

> Does this mean the change can't happen? No it just means that you need
> to be aware that you need to build a cultural consensus.

Change is not only happening, it's accelerating.  Vernor Vinge coined
the term technological singularity to describe what we might be
experiencing soon.  It doesn't seem to be something that we're going to
be able to control all that much.

Dave




From pbrobinson at gmail.com  Thu Oct 30 16:27:10 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 30 Oct 2008 16:27:10 +0000
Subject: Fedora on EEE?
In-Reply-To: <4909DB7F.9070509@nicubunu.ro>
References: <geclck$mlc$2@ger.gmane.org> <4909DB7F.9070509@nicubunu.ro>
Message-ID: <5256d0b0810300927n764c4ad0t65207d6dd9c9341d@mail.gmail.com>

>
> On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
>>>
>>>> - Xandros (on my Asus EEE, and only because I haven't had time to find
>>>> something better; how's Fedora on those?)
>>>>
>>>
>>> Fedora works great on those. I'm happily running F10 since snap2.
>>> All I needed was an akmod from rpmfusion (rt2860sta driver) and
>>> a pm quirk to re-enable screen after resume.
>>>
>>
> Well, it chokes on my WPA.
>

Are you using WPA2 (or WPA+WPA2) on your AP? I have the same issue with mine
but it started working once I just set my AP to plain WPA. This driver is
being re-written for upstream inclusion so I suspect the problem will go
away once that is complete. It just seems to be taking ages.

Cool. Got any "how to" pages handy?
>>
>> Anyway, a couple question about Fedora on EEE...
>>
>> - Does Fedora know about multi-touch? (The default Xandros uses
>> multi-touch for scrolling, not very reliable but still nice to have.)
>>
>
> Not sure, how can I try?
>
>  - What FS is best? (Given that you're dealing with a SSD.) Also, does the
>> lack of swap cause any "interesting" problems? Any other caveats related to
>> the SSD?
>>
>
> Sorry, I have a HDD version.


I asked this question about ext4 and what options to use. I suspect that we
don't have a FS optimised for SSDs as yet. There's UBIFS but I'm not sure
whether that's for SSDs or just pure Flash devices.

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

From seg at haxxed.com  Thu Oct 30 16:48:10 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 30 Oct 2008 11:48:10 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <f6b6eaf4ff607a70d21b06af648c7b50.squirrel@arekh.dyndns.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
	<f6b6eaf4ff607a70d21b06af648c7b50.squirrel@arekh.dyndns.org>
Message-ID: <1225385290.4152.8.camel@localhost.localdomain>

On Thu, 2008-10-30 at 10:38 +0100, Nicolas Mailhot wrote:
> However I also believe this flamewar is due on no little part on how
> previous changes were managed, and is more an "enough is enough"
> thread than a "X on tty7" is sacred thread. It would be nice if
> previous big changes were assimilated before adding more to the mix
> (how many releases will it take before NetWorkManager is solid and
> complete and on by default without needing the old framework for
> backup, for example?).
> 
> Contrary to popular belief the supply of new unprejudiced users is not
> inexhaustible, existing users are not a burden but an asset, and if we
> piss off enough of them by changing stuff continuously and never
> delivering stable complete replacements they'll make us such a
> reputation we'll not find any replacements (there is such thing as the
> Internet and Google, and they have long memories).

The flip side of this is "The Boy Who Cried Wolf". The same handful of
people bitch and whine about any and every change and decision. After a
while they lose credibility and are doing nothing but filling the
mailing list with useless crap.

If I had the power I'd be banhammering people so hard...

...which is why I should never be in charge of a mailing list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/46f2d623/attachment.sig>

From smooge at gmail.com  Thu Oct 30 16:52:31 2008
From: smooge at gmail.com (Stephen John Smoogen)
Date: Thu, 30 Oct 2008 10:52:31 -0600
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225384052.5412.214.camel@vorpal.macdev.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
	<1225293850.5412.181.camel@vorpal.macdev.com>
	<80d7e4090810291129y148a4234y199a9da31c617817@mail.gmail.com>
	<1225384052.5412.214.camel@vorpal.macdev.com>
Message-ID: <80d7e4090810300952q52693157q4f84d196c5f6186@mail.gmail.com>

On Thu, Oct 30, 2008 at 10:27 AM, David G. Mackay
<mackay_d at bellsouth.net> wrote:
>
> On Wed, 2008-10-29 at 12:29 -0600, Stephen John Smoogen wrote:
>> On Wed, Oct 29, 2008 at 9:24 AM, David G. Mackay <mackay_d at bellsouth.net> wrote:

>> Does this mean the change can't happen? No it just means that you need
>> to be aware that you need to build a cultural consensus.
>
> Change is not only happening, it's accelerating.  Vernor Vinge coined
> the term technological singularity to describe what we might be
> experiencing soon.  It doesn't seem to be something that we're going to
> be able to control all that much.
>

Well we are going to have to.. because what usually happens in
societies where change goes on too fast,  people fall out of caring
about the current society and find 'easy' solutions to control it:
Fascism, Communism, or just modern Anti-Intellectualism. When people
start calling for Desktop Dictators to make the boot-times faster its
a sign that even the people addicted to the adrenaline of our ADHD
lifestyle want someone else to think for them. If I don't have to
think because others do it for me.. I am ok because the pack will take
care of me.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From ville.skytta at iki.fi  Thu Oct 30 16:52:37 2008
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 30 Oct 2008 18:52:37 +0200
Subject: Submitting new packages to F-10
Message-ID: <200810301852.39338.ville.skytta@iki.fi>

Hi,

I just built a freshly reviewed and accepted new package for F-10.  Now I'd 
like it to be included in F-10 with the first batch of updates shipped for 
it.  But "make update" does not work for me.  My "common" dir is up to date, 
and Koji shows that the build is tagged with dist-f10-updates-candidate.  Did 
I miss something?

$ make update
[snip clog]
Creating a new update for  vdr-remote-0.4.0-5.fc10
vdr-remote-0.4.0-5.fc10 not tagged as an update candidate

$ koji tag-pkg dist-f10-updates-candidate vdr-remote-0.4.0-5.fc10
[snip]
TagError: build vdr-remote-0.4.0-5.fc10 already tagged 
(dist-f10-updates-candidate)
  0 free  0 open  0 done  1 failed

$ make update
[snip clog]
Creating a new update for  vdr-remote-0.4.0-5.fc10
vdr-remote-0.4.0-5.fc10 not tagged as an update candidate

http://koji.fedoraproject.org/koji/buildinfo?buildID=68113



From dcbw at redhat.com  Thu Oct 30 17:01:42 2008
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 30 Oct 2008 13:01:42 -0400
Subject: Fedora on EEE?
In-Reply-To: <4909DB7F.9070509@nicubunu.ro>
References: <geclck$mlc$2@ger.gmane.org>  <4909DB7F.9070509@nicubunu.ro>
Message-ID: <1225386102.24806.5.camel@unused>

On Thu, 2008-10-30 at 18:06 +0200, Nicu Buculei wrote:
> Matthew Woehlke wrote:
> > Dominik 'Rathann' Mierzejewski wrote:
> >> On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
> >>> - Xandros (on my Asus EEE, and only because I haven't had time to 
> >>> find something better; how's Fedora on those?)
> >>
> >> Fedora works great on those. I'm happily running F10 since snap2.
> >> All I needed was an akmod from rpmfusion (rt2860sta driver) and
> >> a pm quirk to re-enable screen after resume.
> 
> Well, it chokes on my WPA.

Because the driver is the vendor driver, has not been cleaned up for the
quality standards of the kernel, does not properly implement wireless
extensions, and will _never_ go upstream because it includes its own
802.11 stack.

Effort should be directed towards the rt2x00 project which is writing
the correct upstreamable mac80211-based driver for these cards.

Dan

> 
> > Cool. Got any "how to" pages handy?
> > 
> > Anyway, a couple question about Fedora on EEE...
> > 
> > - Does Fedora know about multi-touch? (The default Xandros uses 
> > multi-touch for scrolling, not very reliable but still nice to have.)
> 
> Not sure, how can I try?
> 
> > - What FS is best? (Given that you're dealing with a SSD.) Also, does 
> > the lack of swap cause any "interesting" problems? Any other caveats 
> > related to the SSD?
> 
> Sorry, I have a HDD version.
> 
> > - Does compiz run? ;-)
> 
> Yes, out of the box.
> 
> -- 
> 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 fenn at stanford.edu  Thu Oct 30 17:04:05 2008
From: fenn at stanford.edu (Tim Fenn)
Date: Thu, 30 Oct 2008 10:04:05 -0700
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <19b551a07c6c5f17979df511aa99c5b0.squirrel@mail.jcomserv.net>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
	<loom.20081030T112907-207@post.gmane.org>
	<loom.20081030T113213-32@post.gmane.org>
	<19b551a07c6c5f17979df511aa99c5b0.squirrel@mail.jcomserv.net>
Message-ID: <20081030100405.0a19153c@atbws1.stanford.edu>

On Thu, 30 Oct 2008 07:11:26 -0500 (CDT) "Jon Ciesla"
<limb at jcomserv.net> wrote:

> 
> > I wrote:
> >> --vendor=fedora should not be used for new packages, use
> >> --vendor="" instead
> >> to get desktop-file-install to install the .desktop file without
> >> prepending a
> >> vendor prefix.
> >
> > PS: See
> > https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor for the
> > relevant guideline change, it got approved by FPC on 2008-10-21 and
> > by FESCo on
> > 2008-10-22, but the Packaging/Guidelines page hasn't been updated
> > yet.
> 
> Thanks, Kevin.  Tim, I've updated cvs for all branches, and bumped the
> release.
> 

Great - thanks for the help and testing!  (and thanks Kevin for the
info, I was looking for something along those lines)

-Tim

-- 
CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS



From roland.wolters at credativ.de  Thu Oct 30 17:06:15 2008
From: roland.wolters at credativ.de (Roland Wolters)
Date: Thu, 30 Oct 2008 18:06:15 +0100
Subject: Packaging Hobbit (network monitor) - anyone interested in
	helping out?
In-Reply-To: <4909D265.4070802@nobugconsulting.ro>
References: <200810301419.13994.roland.wolters@credativ.de>
	<4909D265.4070802@nobugconsulting.ro>
Message-ID: <200810301806.21739.roland.wolters@credativ.de>

Am Donnerstag 30 Oktober 2008 16:27:33 schrieb Manuel Wolfshant:
> > currently I am trying to package hobbit (client + server) for EPEL and
> > Fedora. I have to do that anyway, but it would be nice to have high
> > quality packages upstream in the EPEL/Fedora repositories.
> > [...]
> > - Installation:
> > Right now  the server requires the client due to some files included with
> > teh client package. However, server and client must not run together, so
> > the question is if this should be checked at runtime (current solution)
> > or with package excludes (like razorsedge.org does, for example).
>
> usually this can be handled by creating a hobbit-common package which
> includes the stuff needed by both client and server and two other
> packages, for client and for server.
> 
The problem is more that a decision must be made if it is worth the effrot - or 
needed at all - or if not. But thakns for the hint anyway :)

Regards,

Roland
-- 
Roland Wolters
Tel.: +49 (0)21 61 / 46 43-181
pgp fingerprint: D2DE 4612 9C7D 7B7A 420D 84A8 E900 29F9 C16C 2283

credativ GmbH, HRB M?nchengladbach 12080 
Hohenzollernstr. 133, 41061 M?nchengladbach 
Gesch?ftsf?hrung: Dr. Michael Meskes, J?rg Folz
-------------- 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/20081030/f03b9049/attachment.sig>

From pertusus at free.fr  Thu Oct 30 17:05:49 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 30 Oct 2008 18:05:49 +0100
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225385290.4152.8.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
	<f6b6eaf4ff607a70d21b06af648c7b50.squirrel@arekh.dyndns.org>
	<1225385290.4152.8.camel@localhost.localdomain>
Message-ID: <20081030170549.GD3086@free.fr>

On Thu, Oct 30, 2008 at 11:48:10AM -0500, Callum Lerwick wrote:
> 
> The flip side of this is "The Boy Who Cried Wolf". The same handful of
> people bitch and whine about any and every change and decision. After a
> while they lose credibility and are doing nothing but filling the
> mailing list with useless crap.

I don't know exactly who you are talking about, but if you think about the 
same people than me those bitching people (I consider being part of them, 
in case it wasn't clear) have diverging  points of view depending on the 
subject. That being said, I think that fedora has become so much one sided
that anything not in the direction of change is 'filling the mailing
list with useless crap' because decisions have already been irrevocably
taken. So, although those 'bitching people' in general try to be
constructive, in the end they are only adding noise (yes, it includes
me).

--
Pat



From Matt_Domsch at dell.com  Thu Oct 30 17:08:00 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Thu, 30 Oct 2008 12:08:00 -0500
Subject: Submitting new packages to F-10
In-Reply-To: <200810301852.39338.ville.skytta@iki.fi>
References: <200810301852.39338.ville.skytta@iki.fi>
Message-ID: <20081030170800.GB15222@auslistsprd01.us.dell.com>

On Thu, Oct 30, 2008 at 06:52:37PM +0200, Ville Skytt? wrote:
> Hi,
> 
> I just built a freshly reviewed and accepted new package for F-10.  Now I'd 
> like it to be included in F-10 with the first batch of updates shipped for 
> it.  But "make update" does not work for me.  My "common" dir is up to date, 
> and Koji shows that the build is tagged with dist-f10-updates-candidate.  Did 
> I miss something?
> 
> $ make update
> [snip clog]
> Creating a new update for  vdr-remote-0.4.0-5.fc10
> vdr-remote-0.4.0-5.fc10 not tagged as an update candidate
> 
> $ koji tag-pkg dist-f10-updates-candidate vdr-remote-0.4.0-5.fc10
> [snip]
> TagError: build vdr-remote-0.4.0-5.fc10 already tagged 
> (dist-f10-updates-candidate)
>   0 free  0 open  0 done  1 failed
> 
> $ make update
> [snip clog]
> Creating a new update for  vdr-remote-0.4.0-5.fc10
> vdr-remote-0.4.0-5.fc10 not tagged as an update candidate
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=68113


You need to request rel-eng to pull it in.
https://fedorahosted.org/rel-eng/newticket

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



From limb at jcomserv.net  Thu Oct 30 17:08:02 2008
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 30 Oct 2008 12:08:02 -0500 (CDT)
Subject: looking for pymol tester/comaintainer for EL5
In-Reply-To: <20081030100405.0a19153c@atbws1.stanford.edu>
References: <20081028160011.61d9b3ca@atbws1.stanford.edu>
	<c8188bb7a96221e7cf82ee85437489e4.squirrel@mail.jcomserv.net>
	<20081029113735.140c599c@atbws1.stanford.edu>
	<loom.20081030T112907-207@post.gmane.org>
	<loom.20081030T113213-32@post.gmane.org>
	<19b551a07c6c5f17979df511aa99c5b0.squirrel@mail.jcomserv.net>
	<20081030100405.0a19153c@atbws1.stanford.edu>
Message-ID: <87bee609bc5fde3203320c431388448c.squirrel@mail.jcomserv.net>


> On Thu, 30 Oct 2008 07:11:26 -0500 (CDT) "Jon Ciesla"
> <limb at jcomserv.net> wrote:
>
>>
>> > I wrote:
>> >> --vendor=fedora should not be used for new packages, use
>> >> --vendor="" instead
>> >> to get desktop-file-install to install the .desktop file without
>> >> prepending a
>> >> vendor prefix.
>> >
>> > PS: See
>> > https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor for the
>> > relevant guideline change, it got approved by FPC on 2008-10-21 and
>> > by FESCo on
>> > 2008-10-22, but the Packaging/Guidelines page hasn't been updated
>> > yet.
>>
>> Thanks, Kevin.  Tim, I've updated cvs for all branches, and bumped the
>> release.
>>
>
> Great - thanks for the help and testing!  (and thanks Kevin for the
> info, I was looking for something along those lines)

Anytime.  I will say, being an *packager helped, I didn't even have to
wait for you to approve my comaintainership in pkgdb!

*insert uber, super, mega, ultra, whatever.

> -Tim
>
> --
> CAPS LOCK IS THE CRUISE CONTROL OF AWESOMNESS
>


-- 
novus ordo absurdum



From katzj at redhat.com  Thu Oct 30 17:20:51 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 30 Oct 2008 13:20:51 -0400
Subject: Fedora on EEE?
In-Reply-To: <geclck$mlc$2@ger.gmane.org>
References: <geclck$mlc$2@ger.gmane.org>
Message-ID: <1225387251.25818.364.camel@aglarond.local>

Dominik 'Rathann' Mierzejewski wrote:
> a pm quirk to re-enable screen after resume.

Did you file a bug about the quirk needed so that it can be added to
hal-info?

Jeremy



From notting at redhat.com  Thu Oct 30 17:23:40 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 30 Oct 2008 13:23:40 -0400
Subject: Submitting new packages to F-10
In-Reply-To: <20081030170800.GB15222@auslistsprd01.us.dell.com>
References: <200810301852.39338.ville.skytta@iki.fi>
	<20081030170800.GB15222@auslistsprd01.us.dell.com>
Message-ID: <20081030172340.GA13764@nostromo.devel.redhat.com>

Matt Domsch (Matt_Domsch at dell.com) said: 
> > $ make update
> > [snip clog]
> > Creating a new update for  vdr-remote-0.4.0-5.fc10
> > vdr-remote-0.4.0-5.fc10 not tagged as an update candidate
> > 
> > $ koji tag-pkg dist-f10-updates-candidate vdr-remote-0.4.0-5.fc10
> > [snip]
> > TagError: build vdr-remote-0.4.0-5.fc10 already tagged 
> > (dist-f10-updates-candidate)
> >   0 free  0 open  0 done  1 failed
> > 
> > $ make update
> > [snip clog]
> > Creating a new update for  vdr-remote-0.4.0-5.fc10
> > vdr-remote-0.4.0-5.fc10 not tagged as an update candidate
> > 
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=68113
> 
> 
> You need to request rel-eng to pull it in.
> https://fedorahosted.org/rel-eng/newticket

Shouldn't be needed for updates. What I suspect is happening is that
the wrong branch is being passed to bodhi-client. If you do an early
branch for F10 and then do the update, the right thing will probably
happen, although that may not be what you want. (The web UI may also
work, if it's been set up.)

Bill



From lesmikesell at gmail.com  Thu Oct 30 17:23:42 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 12:23:42 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225383765.4152.2.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>
	<49085FCD.9060707@gmail.com>	<49086038.6060800@pingoured.fr>
	<49093DB3.3030907@gmail.com>	<f3ddc6d30810300523p32c8fa77re87723d2292a500a@mail.gmail.com>	<4909AEFF.7090403@gmail.com>
	<1225383765.4152.2.camel@localhost.localdomain>
Message-ID: <4909ED9E.2090109@gmail.com>

Callum Lerwick wrote:
> On Thu, 2008-10-30 at 07:56 -0500, Les Mikesell wrote:
>> Apple has had this right for years - you could close/open the old g4 
>> powerbooks and they'd be ready in seconds and you can just click 'sleep' 
>> on the others for the same effect.
> 
> Yes, it's very easy for Apple to get this right. Because they control
> the hardware platform. We don't have that luxury. We're lucky if we even
> get hardware documentation.

I haven't had any trouble with Windows either for the last few years but 
my experience is limited to Dell and Ibm laptops. I believe there is 
some vendor-supplied code that makes it work reliably.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From maillist at diffingo.com  Thu Oct 30 17:26:33 2008
From: maillist at diffingo.com (Stewart Adam)
Date: Thu, 30 Oct 2008 13:26:33 -0400
Subject: Fedora on EEE?
In-Reply-To: <geclck$mlc$2@ger.gmane.org>
References: <geclck$mlc$2@ger.gmane.org>
Message-ID: <4909EE49.3030604@diffingo.com>

On 10/30/08 11:55 AM, Matthew Woehlke wrote:
> Dominik 'Rathann' Mierzejewski wrote:
>> On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
>>> - Xandros (on my Asus EEE, and only because I haven't had time to
>>> find something better; how's Fedora on those?)
>>
>> Fedora works great on those. I'm happily running F10 since snap2.
>> All I needed was an akmod from rpmfusion (rt2860sta driver) and
>> a pm quirk to re-enable screen after resume.
>
> Cool. Got any "how to" pages handy?
>
> Anyway, a couple question about Fedora on EEE...
>
> - Does Fedora know about multi-touch? (The default Xandros uses
> multi-touch for scrolling, not very reliable but still nice to have.)
I'm not sure on this one - I read at some point that multitouch could be 
emulated with synaptics, but I'm not sure how far that's gone. The 
ClickFinger synaptics options may be of interest to you...

> - What FS is best? (Given that you're dealing with a SSD.) Also, does
> the lack of swap cause any "interesting" problems? Any other caveats
> related to the SSD?
ext2 or another FS without a journal is probably the best at the moment to 
avoid wearing down your SSD

> - Does compiz run? ;-)
Yup, works perfectly out of the box too!

Stewart



From itamar at ispbrasil.com.br  Thu Oct 30 17:34:47 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Thu, 30 Oct 2008 15:34:47 -0200
Subject: Submitting new packages to F-10
In-Reply-To: <20081030170800.GB15222@auslistsprd01.us.dell.com>
References: <200810301852.39338.ville.skytta@iki.fi>
	<20081030170800.GB15222@auslistsprd01.us.dell.com>
Message-ID: <4909F037.2040105@ispbrasil.com.br>

Domsch, thanks for fast answer, ticket open.

https://fedorahosted.org/rel-eng/ticket/917

also I have received another answer from my sponsor Mamoru Tasaka

"Currently bodhi does not accept F-10 updates request yet. I guess there 
will be an announce when bodhi starts to accept F-10 updates request. So 
please wait for now. For now you can submit push requests for F-9 
packages. "


---------------------


You need to request rel-eng to pull it in. 
https://fedorahosted.org/rel-eng/newticket
-- Matt Domsch




From lesmikesell at gmail.com  Thu Oct 30 17:58:20 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 12:58:20 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225385290.4152.8.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<20081029212536.GG25197@nostromo.devel.redhat.com>	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>	<f6b6eaf4ff607a70d21b06af648c7b50.squirrel@arekh.dyndns.org>
	<1225385290.4152.8.camel@localhost.localdomain>
Message-ID: <4909F5BC.2090804@gmail.com>

Callum Lerwick wrote:
> 
> The flip side of this is "The Boy Who Cried Wolf". The same handful of
> people bitch and whine about any and every change and decision.

As they should, when their experience says the change will break things 
and waste people's time.

> After a
> while they lose credibility and are doing nothing but filling the
> mailing list with useless crap.

Wait, now you are going to pretend that you ever listened in the first 
place???  I know I don't get much sympathy here because I disagree with 
policies, but find someone you trust that has kept large processes 
running for a long time with a lot of trained operators to ask how an 
unexpected change in an OS will affect things.  If you aren't building 
an OS that can be trusted for large and complex operations (and 
improving it at that), what's the point?  We can get toys anywhere.

-- 
   Les Mikesell
     lesmikesell at gmail.com




From seg at haxxed.com  Thu Oct 30 18:11:55 2008
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 30 Oct 2008 13:11:55 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225382562.5412.198.camel@vorpal.macdev.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
	<1225283507.5412.178.camel@vorpal.macdev.com>
	<20081029173101.GB3042@shell.devel.redhat.com>
	<1225382562.5412.198.camel@vorpal.macdev.com>
Message-ID: <1225390315.4152.14.camel@localhost.localdomain>

On Thu, 2008-10-30 at 11:02 -0500, David G. Mackay wrote:
> Sure, but the fact is that design by committee can work.  There's a book, "We Are Smarter Than Me"
> by Barry Liebert, Jon Specter, and a cast of thousands.  It gives cases
> where group input has been highly productive.  For that matter, how
> about the linux kernel?  Group dynamics obviously forms a complex
> system, which, often enough spirals off into chaos.  Every now and then,
> however, it does work.

It works if you have a competent "benevolent dictator" that will put
their foot down and make decisions that some may not like no matter how
long the mailing list threads get...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/89abad19/attachment.sig>

From Matt_Domsch at dell.com  Thu Oct 30 18:18:09 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Thu, 30 Oct 2008 13:18:09 -0500
Subject: Submitting new packages to F-10
In-Reply-To: <20081030172340.GA13764@nostromo.devel.redhat.com>
References: <200810301852.39338.ville.skytta@iki.fi>
	<20081030170800.GB15222@auslistsprd01.us.dell.com>
	<20081030172340.GA13764@nostromo.devel.redhat.com>
Message-ID: <20081030181809.GA1469@auslistsprd01.us.dell.com>

On Thu, Oct 30, 2008 at 01:23:40PM -0400, Bill Nottingham wrote:
> Matt Domsch (Matt_Domsch at dell.com) said: 
> > > $ make update
> > > [snip clog]
> > > Creating a new update for  vdr-remote-0.4.0-5.fc10
> > > vdr-remote-0.4.0-5.fc10 not tagged as an update candidate
> > > 
> > > $ koji tag-pkg dist-f10-updates-candidate vdr-remote-0.4.0-5.fc10
> > > [snip]
> > > TagError: build vdr-remote-0.4.0-5.fc10 already tagged 
> > > (dist-f10-updates-candidate)
> > >   0 free  0 open  0 done  1 failed
> > > 
> > > $ make update
> > > [snip clog]
> > > Creating a new update for  vdr-remote-0.4.0-5.fc10
> > > vdr-remote-0.4.0-5.fc10 not tagged as an update candidate
> > > 
> > > http://koji.fedoraproject.org/koji/buildinfo?buildID=68113
> > 
> > 
> > You need to request rel-eng to pull it in.
> > https://fedorahosted.org/rel-eng/newticket
> 
> Shouldn't be needed for updates. What I suspect is happening is that
> the wrong branch is being passed to bodhi-client. If you do an early
> branch for F10 and then do the update, the right thing will probably
> happen, although that may not be what you want. (The web UI may also
> work, if it's been set up.)

I snipped too much.  He wants it in dist-f10 and f10-final but 'make
tag' it tagging things into dist-f10-updates-candidate.


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



From pmatilai at laiskiainen.org  Thu Oct 30 18:25:51 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 30 Oct 2008 20:25:51 +0200 (EET)
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <200810291502.11358.sgrubb@redhat.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
Message-ID: <alpine.LFD.2.00.0810302016110.19576@turre.koti.laiskiainen.org>

On Wed, 29 Oct 2008, Steve Grubb wrote:

> On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
>> We have kernel support for storing capabilities on filesystem since 2.6.24
>> and recent libcap, both in F9 already.
>
> And we have also been busy updating everything else to support this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=449984

Ah, thanks for the pointer.

>
>> I just committed file capability support to rpm.org HEAD, filling in the
>> final(?) missing piece. Capability support is not going to be in rpm 4.6.0
>> but no reason they can't be pulled into 4.6.1 which is easily in F11
>> timeframe.
>
> We tried to support this in F-10 by having a test run with ping. We figured
> that is a simple well defined app that could be used as a test subject. We
> opened bz 455713 to document the change over. Turns out that people compile
> their own kernels and do not necessarily turn this on. So, what do we do in
> that case?

People compiling their own kernels can hose their systems more 
dramatically than this...

>
>> Are we ready to start considering moving away from SUID bits to
>> capabilities, in Fedora 11 maybe?
>
> We tried and got turned back. How does rpm work on kernels that do not support
> file capabilities? I'd like to see us get past the initial objections so that
> we can start removing some of the setuid bits.

Right now, installation of a package using capabilities will fail entirely 
if kernel/filesystem doesn't support setting capabilities. Packages with 
capabilities in them require rpmlib(FileCaps) feature, which rpm currently 
provides if built with libcap support. It could (and probably should, 
anyway) be made into a run-time tested feature, so that you'll get 
something like this if running on kernel with no capability support:

error: Failed dependencies:
 	rpmlib(FileCaps) <= 4.6.1-1 is needed by ...

 	- Panu -



From skvidal at fedoraproject.org  Thu Oct 30 18:29:53 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 30 Oct 2008 14:29:53 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.LFD.2.00.0810302016110.19576@turre.koti.laiskiainen.org>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<alpine.LFD.2.00.0810302016110.19576@turre.koti.laiskiainen.org>
Message-ID: <1225391393.21485.129.camel@rosebud>

On Thu, 2008-10-30 at 20:25 +0200, Panu Matilainen wrote:
> On Wed, 29 Oct 2008, Steve Grubb wrote:
> 
> > On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
> >> We have kernel support for storing capabilities on filesystem since 2.6.24
> >> and recent libcap, both in F9 already.
> >
> > And we have also been busy updating everything else to support this:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=449984
> 
> Ah, thanks for the pointer.
> 
> >
> >> I just committed file capability support to rpm.org HEAD, filling in the
> >> final(?) missing piece. Capability support is not going to be in rpm 4.6.0
> >> but no reason they can't be pulled into 4.6.1 which is easily in F11
> >> timeframe.
> >
> > We tried to support this in F-10 by having a test run with ping. We figured
> > that is a simple well defined app that could be used as a test subject. We
> > opened bz 455713 to document the change over. Turns out that people compile
> > their own kernels and do not necessarily turn this on. So, what do we do in
> > that case?
> 
> People compiling their own kernels can hose their systems more 
> dramatically than this...
> 
> >
> >> Are we ready to start considering moving away from SUID bits to
> >> capabilities, in Fedora 11 maybe?
> >
> > We tried and got turned back. How does rpm work on kernels that do not support
> > file capabilities? I'd like to see us get past the initial objections so that
> > we can start removing some of the setuid bits.
> 
> Right now, installation of a package using capabilities will fail entirely 
> if kernel/filesystem doesn't support setting capabilities. Packages with 
> capabilities in them require rpmlib(FileCaps) feature, which rpm currently 
> provides if built with libcap support. It could (and probably should, 
> anyway) be made into a run-time tested feature, so that you'll get 
> something like this if running on kernel with no capability support:
> 
> error: Failed dependencies:
>  	rpmlib(FileCaps) <= 4.6.1-1 is needed by ...

Except nothing really watches those rpmlib() deps much at all, does it?

-sv




From pmatilai at laiskiainen.org  Thu Oct 30 18:41:06 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 30 Oct 2008 20:41:06 +0200 (EET)
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225391393.21485.129.camel@rosebud>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<alpine.LFD.2.00.0810302016110.19576@turre.koti.laiskiainen.org>
	<1225391393.21485.129.camel@rosebud>
Message-ID: <alpine.LFD.2.00.0810302035060.19576@turre.koti.laiskiainen.org>

On Thu, 30 Oct 2008, seth vidal wrote:

> On Thu, 2008-10-30 at 20:25 +0200, Panu Matilainen wrote:
>> On Wed, 29 Oct 2008, Steve Grubb wrote:
>>
>>> On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
>>>> We have kernel support for storing capabilities on filesystem since 2.6.24
>>>> and recent libcap, both in F9 already.
>>>
>>> And we have also been busy updating everything else to support this:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=449984
>>
>> Ah, thanks for the pointer.
>>
>>>
>>>> I just committed file capability support to rpm.org HEAD, filling in the
>>>> final(?) missing piece. Capability support is not going to be in rpm 4.6.0
>>>> but no reason they can't be pulled into 4.6.1 which is easily in F11
>>>> timeframe.
>>>
>>> We tried to support this in F-10 by having a test run with ping. We figured
>>> that is a simple well defined app that could be used as a test subject. We
>>> opened bz 455713 to document the change over. Turns out that people compile
>>> their own kernels and do not necessarily turn this on. So, what do we do in
>>> that case?
>>
>> People compiling their own kernels can hose their systems more
>> dramatically than this...
>>
>>>
>>>> Are we ready to start considering moving away from SUID bits to
>>>> capabilities, in Fedora 11 maybe?
>>>
>>> We tried and got turned back. How does rpm work on kernels that do not support
>>> file capabilities? I'd like to see us get past the initial objections so that
>>> we can start removing some of the setuid bits.
>>
>> Right now, installation of a package using capabilities will fail entirely
>> if kernel/filesystem doesn't support setting capabilities. Packages with
>> capabilities in them require rpmlib(FileCaps) feature, which rpm currently
>> provides if built with libcap support. It could (and probably should,
>> anyway) be made into a run-time tested feature, so that you'll get
>> something like this if running on kernel with no capability support:
>>
>> error: Failed dependencies:
>>  	rpmlib(FileCaps) <= 4.6.1-1 is needed by ...
>
> Except nothing really watches those rpmlib() deps much at all, does it?

Rpm itself does, so unless you use --nodeps (or the API equivalent of 
that) it'll get caught before transaction starts.

 	- Panu -



From skvidal at fedoraproject.org  Thu Oct 30 18:44:01 2008
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 30 Oct 2008 14:44:01 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <alpine.LFD.2.00.0810302035060.19576@turre.koti.laiskiainen.org>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<alpine.LFD.2.00.0810302016110.19576@turre.koti.laiskiainen.org>
	<1225391393.21485.129.camel@rosebud>
	<alpine.LFD.2.00.0810302035060.19576@turre.koti.laiskiainen.org>
Message-ID: <1225392241.21485.132.camel@rosebud>

On Thu, 2008-10-30 at 20:41 +0200, Panu Matilainen wrote:
> On Thu, 30 Oct 2008, seth vidal wrote:
> 
> > On Thu, 2008-10-30 at 20:25 +0200, Panu Matilainen wrote:
> >> On Wed, 29 Oct 2008, Steve Grubb wrote:
> >>
> >>> On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
> >>>> We have kernel support for storing capabilities on filesystem since 2.6.24
> >>>> and recent libcap, both in F9 already.
> >>>
> >>> And we have also been busy updating everything else to support this:
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=449984
> >>
> >> Ah, thanks for the pointer.
> >>
> >>>
> >>>> I just committed file capability support to rpm.org HEAD, filling in the
> >>>> final(?) missing piece. Capability support is not going to be in rpm 4.6.0
> >>>> but no reason they can't be pulled into 4.6.1 which is easily in F11
> >>>> timeframe.
> >>>
> >>> We tried to support this in F-10 by having a test run with ping. We figured
> >>> that is a simple well defined app that could be used as a test subject. We
> >>> opened bz 455713 to document the change over. Turns out that people compile
> >>> their own kernels and do not necessarily turn this on. So, what do we do in
> >>> that case?
> >>
> >> People compiling their own kernels can hose their systems more
> >> dramatically than this...
> >>
> >>>
> >>>> Are we ready to start considering moving away from SUID bits to
> >>>> capabilities, in Fedora 11 maybe?
> >>>
> >>> We tried and got turned back. How does rpm work on kernels that do not support
> >>> file capabilities? I'd like to see us get past the initial objections so that
> >>> we can start removing some of the setuid bits.
> >>
> >> Right now, installation of a package using capabilities will fail entirely
> >> if kernel/filesystem doesn't support setting capabilities. Packages with
> >> capabilities in them require rpmlib(FileCaps) feature, which rpm currently
> >> provides if built with libcap support. It could (and probably should,
> >> anyway) be made into a run-time tested feature, so that you'll get
> >> something like this if running on kernel with no capability support:
> >>
> >> error: Failed dependencies:
> >>  	rpmlib(FileCaps) <= 4.6.1-1 is needed by ...
> >
> > Except nothing really watches those rpmlib() deps much at all, does it?
> 
> Rpm itself does, so unless you use --nodeps (or the API equivalent of 
> that) it'll get caught before transaction starts.

but after you've downloaded everything. And what provides those things
these days?

-sv





From lesmikesell at gmail.com  Thu Oct 30 18:52:00 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 13:52:00 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <4909AE5F.6070606@fedoraproject.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<4908C716.2090906@redhat.com>	<alpine.LRH.2.00.0810291750170.11173@arj.bjyevire.pbz>	<4908F6A1.4020509@fedoraproject.org>	<alpine.LRH.2.00.0810292308280.7694@arj.bjyevire.pbz>
	<4909AE5F.6070606@fedoraproject.org>
Message-ID: <490A0250.6010303@gmail.com>

Rahul Sundaram wrote:
> 
> Distrowatch page hits are not useful at all to gather general metrics. 
> Telling you that requires ingesting no venom. Just accepting facts.

And don't forget to put Linux in general into it's perspective as just 
above the iphone in visible numbers first...

http://marketshare.hitslink.com/report.aspx?qprid=8


-- 
   Les Mikesell
    lesmikesell at gmail.com




From dbn.lists at gmail.com  Thu Oct 30 18:55:48 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 30 Oct 2008 11:55:48 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081030154405.GA12240@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
Message-ID: <91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>

On Thu, Oct 30, 2008 at 8:44 AM, Bill Nottingham <notting at redhat.com> wrote:
> Dan Nicholson (dbn.lists at gmail.com) said:
>> I didn't suggest having plymouth change to tty7. In fact, I posted a
>> patch so that it's all controlled from /etc/sysconfig/desktop instead
>> of having plymouth and gdm work behind the scenes.
>>
>> https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02516.html
>>
>> Does that seem reasonable at all?
>
> Better, but still problematic, especially on runlevel 3->5 transitions:
>
> - by moving the trigger to prefdm, you get gdm/X on whatever tty you run
>  telinit from...
> - which makes the logic w.r.t. tty1 in /etc/event.d/tty1 incorrect

Yeah, I realized that later. The writing of /var/spool/gdm/whatever
should be done from /etc/event.d/tty1, since that's the only place you
really know it's appropriate. I changed it so that it only happens on
initial boot to runlevel 5 (`runlevel` = "N 5"). There is still the
problem where getty is not started on tty1 when the display manager is
not gdm. That would require some more smarts between /etc/event.d/tty1
and /etc/event.d/prefdm. But that's no different than the current
situation. I'm confident this can be done correctly, though. Patch
attached.

--
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initscripts-active-vt-2.patch
Type: text/x-diff
Size: 630 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/a6fbfc9d/attachment.bin>

From mackay_d at bellsouth.net  Thu Oct 30 18:57:03 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Thu, 30 Oct 2008 13:57:03 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225390315.4152.14.camel@localhost.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop> <49082E6B.7080304@hhs.nl>
	<20081029093818.GB2834@free.fr>
	<1225273515.3636.48.camel@hughsie-laptop>
	<1225283507.5412.178.camel@vorpal.macdev.com>
	<20081029173101.GB3042@shell.devel.redhat.com>
	<1225382562.5412.198.camel@vorpal.macdev.com>
	<1225390315.4152.14.camel@localhost.localdomain>
Message-ID: <1225393024.5412.234.camel@vorpal.macdev.com>


On Thu, 2008-10-30 at 13:11 -0500, Callum Lerwick wrote:
> On Thu, 2008-10-30 at 11:02 -0500, David G. Mackay wrote:
> > Sure, but the fact is that design by committee can work.  There's a book, "We Are Smarter Than Me"
> > by Barry Liebert, Jon Specter, and a cast of thousands.  It gives cases
> > where group input has been highly productive.  For that matter, how
> > about the linux kernel?  Group dynamics obviously forms a complex
> > system, which, often enough spirals off into chaos.  Every now and then,
> > however, it does work.
> 
> It works if you have a competent "benevolent dictator" that will put
> their foot down and make decisions that some may not like no matter how
> long the mailing list threads get...

The other trick is to avoid driving folks away in the process.  The
people who are dissenting may have valid viewpoints, and may have some
valuable input in other areas.

Dave




From katzj at redhat.com  Thu Oct 30 19:02:54 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 30 Oct 2008 15:02:54 -0400
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225392241.21485.132.camel@rosebud>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<alpine.LFD.2.00.0810302016110.19576@turre.koti.laiskiainen.org>
	<1225391393.21485.129.camel@rosebud>
	<alpine.LFD.2.00.0810302035060.19576@turre.koti.laiskiainen.org>
	<1225392241.21485.132.camel@rosebud>
Message-ID: <1225393374.25818.388.camel@aglarond.local>

On Thu, 2008-10-30 at 14:44 -0400, seth vidal wrote:
> On Thu, 2008-10-30 at 20:41 +0200, Panu Matilainen wrote:
> > On Thu, 30 Oct 2008, seth vidal wrote:
> > > On Thu, 2008-10-30 at 20:25 +0200, Panu Matilainen wrote:
> > >> error: Failed dependencies:
> > >>  	rpmlib(FileCaps) <= 4.6.1-1 is needed by ...
> > >
> > > Except nothing really watches those rpmlib() deps much at all, does it?
> > 
> > Rpm itself does, so unless you use --nodeps (or the API equivalent of 
> > that) it'll get caught before transaction starts.
> 
> but after you've downloaded everything. And what provides those things
> these days?

They're internally provided by rpm as they always have been.  And the
only place they can reasonably be checked is within rpmlib as is done
now.  Yeah, it means you download things and then get told "too bad!"
but there's really not a good way around that unless we were to
replicate all of the checks in yum

Jeremy



From pmatilai at laiskiainen.org  Thu Oct 30 19:09:23 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 30 Oct 2008 21:09:23 +0200 (EET)
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <1225392241.21485.132.camel@rosebud>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291502.11358.sgrubb@redhat.com>
	<alpine.LFD.2.00.0810302016110.19576@turre.koti.laiskiainen.org>
	<1225391393.21485.129.camel@rosebud>
	<alpine.LFD.2.00.0810302035060.19576@turre.koti.laiskiainen.org>
	<1225392241.21485.132.camel@rosebud>
Message-ID: <alpine.LFD.2.00.0810302101210.19576@turre.koti.laiskiainen.org>

On Thu, 30 Oct 2008, seth vidal wrote:

> On Thu, 2008-10-30 at 20:41 +0200, Panu Matilainen wrote:
>> On Thu, 30 Oct 2008, seth vidal wrote:
>>
>>> On Thu, 2008-10-30 at 20:25 +0200, Panu Matilainen wrote:
>>>> On Wed, 29 Oct 2008, Steve Grubb wrote:
>>>>
>>>>> On Wednesday 29 October 2008 06:37:32 Panu Matilainen wrote:
>>>>>> We have kernel support for storing capabilities on filesystem since 2.6.24
>>>>>> and recent libcap, both in F9 already.
>>>>>
>>>>> And we have also been busy updating everything else to support this:
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=449984
>>>>
>>>> Ah, thanks for the pointer.
>>>>
>>>>>
>>>>>> I just committed file capability support to rpm.org HEAD, filling in the
>>>>>> final(?) missing piece. Capability support is not going to be in rpm 4.6.0
>>>>>> but no reason they can't be pulled into 4.6.1 which is easily in F11
>>>>>> timeframe.
>>>>>
>>>>> We tried to support this in F-10 by having a test run with ping. We figured
>>>>> that is a simple well defined app that could be used as a test subject. We
>>>>> opened bz 455713 to document the change over. Turns out that people compile
>>>>> their own kernels and do not necessarily turn this on. So, what do we do in
>>>>> that case?
>>>>
>>>> People compiling their own kernels can hose their systems more
>>>> dramatically than this...
>>>>
>>>>>
>>>>>> Are we ready to start considering moving away from SUID bits to
>>>>>> capabilities, in Fedora 11 maybe?
>>>>>
>>>>> We tried and got turned back. How does rpm work on kernels that do not support
>>>>> file capabilities? I'd like to see us get past the initial objections so that
>>>>> we can start removing some of the setuid bits.
>>>>
>>>> Right now, installation of a package using capabilities will fail entirely
>>>> if kernel/filesystem doesn't support setting capabilities. Packages with
>>>> capabilities in them require rpmlib(FileCaps) feature, which rpm currently
>>>> provides if built with libcap support. It could (and probably should,
>>>> anyway) be made into a run-time tested feature, so that you'll get
>>>> something like this if running on kernel with no capability support:
>>>>
>>>> error: Failed dependencies:
>>>>  	rpmlib(FileCaps) <= 4.6.1-1 is needed by ...
>>>
>>> Except nothing really watches those rpmlib() deps much at all, does it?
>>
>> Rpm itself does, so unless you use --nodeps (or the API equivalent of
>> that) it'll get caught before transaction starts.
>
> but after you've downloaded everything.

Yes, if you filter them out of the repository metadata. Rather than filter 
all of them out, filter just the "well duh" things like 
rpmlib(CompressedFileNames) out? The rpmlib(foo) dependencies are an 
important mechanism for tracking support for new features, it's just that 
as there haven't been any in several years they've started looking 
completely moot.

> And what provides those things these days?

In rpm 4.6.0, you can get the rpmlib provides as a dependency set with 
rpm.ds.Rpmlib() in python. I don't remember off-hand how it worked for 
older versions.

 	- Panu -



From mackay_d at bellsouth.net  Thu Oct 30 18:53:24 2008
From: mackay_d at bellsouth.net (David G. Mackay)
Date: Thu, 30 Oct 2008 13:53:24 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <80d7e4090810300952q52693157q4f84d196c5f6186@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<1225271780.3636.27.camel@hughsie-laptop>
	<49082C1E.3030007@shmuelhome.mine.nu>
	<1225272707.3636.42.camel@hughsie-laptop>
	<20081029113735.GA1293@mokona.greysector.net>
	<20081029124254.GD3628@localhost.localdomain>
	<1225284662.21485.46.camel@rosebud>
	<1225293850.5412.181.camel@vorpal.macdev.com>
	<80d7e4090810291129y148a4234y199a9da31c617817@mail.gmail.com>
	<1225384052.5412.214.camel@vorpal.macdev.com>
	<80d7e4090810300952q52693157q4f84d196c5f6186@mail.gmail.com>
Message-ID: <1225392805.5412.230.camel@vorpal.macdev.com>


On Thu, 2008-10-30 at 10:52 -0600, Stephen John Smoogen wrote:
> On Thu, Oct 30, 2008 at 10:27 AM, David G. Mackay
> <mackay_d at bellsouth.net> wrote:
> >
> > On Wed, 2008-10-29 at 12:29 -0600, Stephen John Smoogen wrote:
> >> On Wed, Oct 29, 2008 at 9:24 AM, David G. Mackay <mackay_d at bellsouth.net> wrote:
> 
> >> Does this mean the change can't happen? No it just means that you need
> >> to be aware that you need to build a cultural consensus.
> >
> > Change is not only happening, it's accelerating.  Vernor Vinge coined
> > the term technological singularity to describe what we might be
> > experiencing soon.  It doesn't seem to be something that we're going to
> > be able to control all that much.
> >
> 
> Well we are going to have to.. because what usually happens in
> societies where change goes on too fast,  people fall out of caring
> about the current society and find 'easy' solutions to control it:
> Fascism, Communism, or just modern Anti-Intellectualism. When people

Yes, there are days when I think that taking up sheep ranching in the
Australian outback would be a great solution.  Most days, though, it's
utterly fascinating to see some of the new things that are happening
around us.  The choice that we face is to try to influence what we can,
or become irrelevant.  Control is far beyond us.  Look at stem cell
research, for example.  We tried to clamp on rigid controls in the U.
S., which had the effect of moving the cutting edge research to other
countries.  Not, that a lot of those countries wouldn't have become
involved in the research, but they wouldn't have gotten as much backing
if we hadn't banned a lot of things here in the U. S.

> start calling for Desktop Dictators to make the boot-times faster its
> a sign that even the people addicted to the adrenaline of our ADHD
> lifestyle want someone else to think for them. If I don't have to
> think because others do it for me.. I am ok because the pack will take
> care of me.

Or, you can stay in there and present your viewpoints.  After all,
changes CAN be reversed.  A lot of the younger folks here probably don't
remember the "New Coke" fiasco.  In 1985, or so, Coca-Cola announced
that they were introducing a new taste for their flagship product.  The
outcry from consumers forced them to re-introduce the old product.

Dave




From pbrobinson at gmail.com  Thu Oct 30 19:51:43 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 30 Oct 2008 19:51:43 +0000
Subject: rawhide netbook resume with xorg intel driver?
Message-ID: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>

Hi All,

Has anyone else seen issues with resume with the latest intel 2.5.0 driver
on netbooks. I'm seeing issues on my eeepc 901 which has the intel atom i945
chipset. It had worked previously and resumes OK but I get a black screen
with a cursor and around that a square of garbled bits. Just wondering if
anyone else has seen that of late on any of the random NetBooks with the
same chipset like the various newer eeePCs, Dell mini, Acer aspiron one etc.

Cheers,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/3b7c9078/attachment.htm>

From kevin.kofler at chello.at  Thu Oct 30 20:01:10 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 30 Oct 2008 20:01:10 +0000 (UTC)
Subject: Submitting new packages to F-10
References: <200810301852.39338.ville.skytta@iki.fi>
	<20081030170800.GB15222@auslistsprd01.us.dell.com>
	<4909F037.2040105@ispbrasil.com.br>
Message-ID: <loom.20081030T195912-204@post.gmane.org>

Itamar - IspBrasil <itamar <at> ispbrasil.com.br> writes:
> Domsch, thanks for fast answer, ticket open.
> 
> https://fedorahosted.org/rel-eng/ticket/917
> 
> also I have received another answer from my sponsor Mamoru Tasaka
> 
> "Currently bodhi does not accept F-10 updates request yet. I guess there 
> will be an announce when bodhi starts to accept F-10 updates request. So 
> please wait for now. For now you can submit push requests for F-9 
> packages. "

Well, in principle, getting the new packages tagged into f10-final should not 
hurt (assuming they don't have Obsoletes: tags for anything else), so you 
should be able to get rel-eng to do it through the rel-eng requests.

But indeed, if you just wait a few days, you'll be able to submit them as 
updates through Bodhi.

        Kevin Kofler



From jonrob at fedoraproject.org  Thu Oct 30 20:00:16 2008
From: jonrob at fedoraproject.org (Jonathan Roberts)
Date: Thu, 30 Oct 2008 20:00:16 +0000
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
Message-ID: <507738ef0810301300odeb166et6b7d8f1f7a8fb855@mail.gmail.com>

2008/10/30 Peter Robinson <pbrobinson at gmail.com>:
> Hi All,
>
> Has anyone else seen issues with resume with the latest intel 2.5.0 driver
> on netbooks. I'm seeing issues on my eeepc 901 which has the intel atom i945
> chipset. It had worked previously and resumes OK but I get a black screen
> with a cursor and around that a square of garbled bits. Just wondering if
> anyone else has seen that of late on any of the random NetBooks with the
> same chipset like the various newer eeePCs, Dell mini, Acer aspiron one etc.

Yeah - resume from suspend fails here. Get the blank screen with
cursor, nothing else.

(Dell Mini)

Jon



From dominik at greysector.net  Thu Oct 30 20:12:16 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 30 Oct 2008 21:12:16 +0100
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081030134713.GC7510@nostromo.devel.redhat.com>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<20081029205726.GD25197@nostromo.devel.redhat.com>
	<20081030123442.GB11708@mokona.greysector.net>
	<20081030134713.GC7510@nostromo.devel.redhat.com>
Message-ID: <20081030201215.GA18603@mokona.greysector.net>

On Thursday, 30 October 2008 at 14:47, Bill Nottingham wrote:
> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > > Possibly because that particular patch wasn't ever in bugzilla (AFAICT.)
> > 
> > It was, although it contained reindentation cosmetics. I only cleaned it up.
> 
> Not in either of the open bugs about wpa & initscripts. Perhaps it's
> hiding somewhere else. (The ones in the open bugs were 'start WPA
> supplicant and magically hope it associates in time'.)

I'll try to find it.

> > > It's certainly a better one, but there's still the problem of entirely
> > > disparate configuration (manually editing wpa_supplicant.conf, etc.)
> > 
> > What's wrong with manually editing wpa_supplicant.conf?
> 
> For WEP, you put keys <in one place>. For WPA you put keys and networks <this
> entirely separate place and format>. It's a hack.

You can use wpa_supplicant for WEP, too.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From luya at fedoraproject.org  Thu Oct 30 20:18:34 2008
From: luya at fedoraproject.org (Luya Tshimbalanga)
Date: Thu, 30 Oct 2008 13:18:34 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <4909AEFF.7090403@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<1225271780.3636.27.camel@hughsie-laptop>	<49082C1E.3030007@shmuelhome.mine.nu>	<1225272707.3636.42.camel@hughsie-laptop>	<20081029113735.GA1293@mokona.greysector.net>	<20081029124254.GD3628@localhost.localdomain>	<1225284662.21485.46.camel@rosebud>	<49085FCD.9060707@gmail.com>	<49086038.6060800@pingoured.fr>	<49093DB3.3030907@gmail.com>	<f3ddc6d30810300523p32c8fa77re87723d2292a500a@mail.gmail.com>
	<4909AEFF.7090403@gmail.com>
Message-ID: <490A169A.7040408@fedoraproject.org>

Les Mikesell a ?crit :
> Apple has had this right for years - you could close/open the old g4
> powerbooks and they'd be ready in seconds and you can just click
> 'sleep' on the others for the same effect.  It probably wastes a bit
> of power to keep the keyboard active to wake the machine up, but it is
> worth it to still have all your programs open where you left them
> almost instantly.
>
You forgot that Apple did with their own specific hardware. The
questioin is: will their method apply on heterogeneous environment that
is PC (Personal Computer)?

Luya

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

From dominik at greysector.net  Thu Oct 30 20:18:25 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 30 Oct 2008 21:18:25 +0100
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <1225375481.19928.15.camel@unused>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<20081029205726.GD25197@nostromo.devel.redhat.com>
	<20081030123442.GB11708@mokona.greysector.net>
	<1225375481.19928.15.camel@unused>
Message-ID: <20081030201825.GB18603@mokona.greysector.net>

On Thursday, 30 October 2008 at 15:04, Dan Williams wrote:
> On Thu, 2008-10-30 at 13:34 +0100, Dominik 'Rathann' Mierzejewski wrote:
[...]
> > What's wrong with manually editing wpa_supplicant.conf?
> 
> Because it's not easily from anything but wpa_supplicant, and it's
> completely different than the existing ifup/ifdown config system.
> System-config-network would have to grow the ability to parse the
> wpa_supplicant config file format.  You can't override the variables
> from /etc/sysconfig/network if you want to.  There's no separation of
> interfaces to allow for multiple connections with two or more wifi cards
> with 'ifup number1' and 'ifup number2' independently.

How often do you see machines with multiple wifi cards? I haven't seen
any. I could easily set one up by adding a usb stick with wifi or a pcmcia
card, but I haven't needed it yet.

> A much better, more integrated and consistent implementation would have
> each ifcfg file essentially be a network block in the supplicant config
> file.  When you 'ifup my-wpa', the scripts write out a new supplicant
> config file using key/value pairs
> in /etc/sysconfig/network-scripts/ifcfg-my-wpa and execute a supplicant
> based on that, then somehow wait for the supplicant to connect by
> listening on the specific control socket for a connection, and if no
> connection occurs, time out and fail just like DHCP fails.  When you
> 'ifdown my-wpa', it will terminate the supplicant based on the PID file
> written to /var/run/wpa_supplicant-wlan0-my-wpa.pid and clean up the
> routing and addresses.
> 
> That's what the patch _should_ do.  Just tossing a config file off to
> the supplicant is a cop-out half solution.

Alright, I'll see what I can come up with. I guess I can understand your
unwillingness to accept a half-assed solution that works only in one scenario.
After all, I don't like half-assed solutions myself.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From katzj at redhat.com  Thu Oct 30 20:19:50 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 30 Oct 2008 16:19:50 -0400
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <507738ef0810301300odeb166et6b7d8f1f7a8fb855@mail.gmail.com>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
	<507738ef0810301300odeb166et6b7d8f1f7a8fb855@mail.gmail.com>
Message-ID: <1225397990.25818.389.camel@aglarond.local>

On Thu, 2008-10-30 at 20:00 +0000, Jonathan Roberts wrote:
> 2008/10/30 Peter Robinson <pbrobinson at gmail.com>:
> > Has anyone else seen issues with resume with the latest intel 2.5.0 driver
> > on netbooks. I'm seeing issues on my eeepc 901 which has the intel atom i945
> > chipset. It had worked previously and resumes OK but I get a black screen
> > with a cursor and around that a square of garbled bits. Just wondering if
> > anyone else has seen that of late on any of the random NetBooks with the
> > same chipset like the various newer eeePCs, Dell mini, Acer aspiron one etc.
> 
> Yeah - resume from suspend fails here. Get the blank screen with
> cursor, nothing else.

Have you tried the various suspend quirks (most notably, vbepost)?

Jeremy



From dominik at greysector.net  Thu Oct 30 20:21:20 2008
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 30 Oct 2008 21:21:20 +0100
Subject: Fedora on EEE?
In-Reply-To: <1225387251.25818.364.camel@aglarond.local>
References: <geclck$mlc$2@ger.gmane.org>
	<1225387251.25818.364.camel@aglarond.local>
Message-ID: <20081030202120.GC18603@mokona.greysector.net>

On Thursday, 30 October 2008 at 18:20, Jeremy Katz wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> > a pm quirk to re-enable screen after resume.
> 
> Did you file a bug about the quirk needed so that it can be added to
> hal-info?

Yes.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jkeating at redhat.com  Thu Oct 30 20:23:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 30 Oct 2008 13:23:25 -0700
Subject: Submitting new packages to F-10
In-Reply-To: <loom.20081030T195912-204@post.gmane.org>
References: <200810301852.39338.ville.skytta@iki.fi>
	<20081030170800.GB15222@auslistsprd01.us.dell.com>
	<4909F037.2040105@ispbrasil.com.br>
	<loom.20081030T195912-204@post.gmane.org>
Message-ID: <1225398205.27779.3.camel@luminos.localdomain>

On Thu, 2008-10-30 at 20:01 +0000, Kevin Kofler wrote:
> 
> Well, in principle, getting the new packages tagged into f10-final should not 
> hurt (assuming they don't have Obsoletes: tags for anything else), so you 
> should be able to get rel-eng to do it through the rel-eng requests.
> 
> But indeed, if you just wait a few days, you'll be able to submit them as 
> updates through Bodhi.

At this point I want new packages to go  out as updates, unless there is
significant reason to pull them into F10 proper.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/74a0c2e1/attachment.sig>

From pbrobinson at gmail.com  Thu Oct 30 20:26:22 2008
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 30 Oct 2008 20:26:22 +0000
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <1225397990.25818.389.camel@aglarond.local>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
	<507738ef0810301300odeb166et6b7d8f1f7a8fb855@mail.gmail.com>
	<1225397990.25818.389.camel@aglarond.local>
Message-ID: <5256d0b0810301326p1ae11640g5b731c0dabae92bd@mail.gmail.com>

> On Thu, 2008-10-30 at 20:00 +0000, Jonathan Roberts wrote:
> > 2008/10/30 Peter Robinson <pbrobinson at gmail.com>:
> > > Has anyone else seen issues with resume with the latest intel 2.5.0
> driver
> > > on netbooks. I'm seeing issues on my eeepc 901 which has the intel atom
> i945
> > > chipset. It had worked previously and resumes OK but I get a black
> screen
> > > with a cursor and around that a square of garbled bits. Just wondering
> if
> > > anyone else has seen that of late on any of the random NetBooks with
> the
> > > same chipset like the various newer eeePCs, Dell mini, Acer aspiron one
> etc.
> >
> > Yeah - resume from suspend fails here. Get the blank screen with
> > cursor, nothing else.
>
> Have you tried the various suspend quirks (most notably, vbepost)?
>

No, I must say I haven't primarily because it was working quite nicely until
very recently so was initially wondering whether it was something I had
changed (not that I tend to change much on my eeePC). Is there a link
somewhere for these quirks?

Cheers,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/788c083d/attachment.htm>

From notting at redhat.com  Thu Oct 30 20:29:20 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 30 Oct 2008 16:29:20 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
Message-ID: <20081030202920.GB31153@nostromo.devel.redhat.com>

Dan Nicholson (dbn.lists at gmail.com) said: 
> Yeah, I realized that later. The writing of /var/spool/gdm/whatever
> should be done from /etc/event.d/tty1, since that's the only place you
> really know it's appropriate. I changed it so that it only happens on
> initial boot to runlevel 5 (`runlevel` = "N 5"). There is still the
> problem where getty is not started on tty1 when the display manager is
> not gdm. That would require some more smarts between /etc/event.d/tty1
> and /etc/event.d/prefdm. But that's no different than the current
> situation. I'm confident this can be done correctly, though. Patch
> attached.

Doesn't this just create a race between tty1 writing the file
and gdm trying to read it?

Bill



From dbn.lists at gmail.com  Thu Oct 30 21:10:01 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 30 Oct 2008 14:10:01 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081030202920.GB31153@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
Message-ID: <91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>

On Thu, Oct 30, 2008 at 1:29 PM, Bill Nottingham <notting at redhat.com> wrote:
> Dan Nicholson (dbn.lists at gmail.com) said:
>> Yeah, I realized that later. The writing of /var/spool/gdm/whatever
>> should be done from /etc/event.d/tty1, since that's the only place you
>> really know it's appropriate. I changed it so that it only happens on
>> initial boot to runlevel 5 (`runlevel` = "N 5"). There is still the
>> problem where getty is not started on tty1 when the display manager is
>> not gdm. That would require some more smarts between /etc/event.d/tty1
>> and /etc/event.d/prefdm. But that's no different than the current
>> situation. I'm confident this can be done correctly, though. Patch
>> attached.
>
> Doesn't this just create a race between tty1 writing the file
> and gdm trying to read it?

Oh, very good point. Let's try again. In the attached patch, all the
logic is handled in event.d/prefdm. In particular, when we want to
spawn a getty on tty1, we use initctl to emit a new event
"tty1-getty". This also includes some logic to try to make sure that
the display manager is gdm before assuming that it will be able to
start on tty1.

What do you think?

--
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initscripts-active-vt-3.patch
Type: text/x-diff
Size: 990 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/463e0d77/attachment.bin>

From lesmikesell at gmail.com  Thu Oct 30 21:19:53 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 16:19:53 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <geclvo$v87$1@ger.gmane.org>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>	<4908C757.1000902@gmail.com>	<gealfk$4td$1@ger.gmane.org>	<490943C0.4070703@gmail.com>	<gecjut$mlc$1@ger.gmane.org>	<4909D963.8010301@gmail.com>
	<geclvo$v87$1@ger.gmane.org>
Message-ID: <490A24F9.1030005@gmail.com>

Matthew Woehlke wrote:
> 
>>> I've had with Fedora 8/9 is the cr*p nvidia drivers don't work quite 
>>> right on my setup, and that's hardly Fedora's fault.
>>
>> It is fedora's fault that their policy makes it difficult for you to 
>> run vendor drivers.
> 
> I'm sure this wasn't your intent anyway, but please don't put words in 
> my mouth :-). I happen to *agree* with the policy. The problem, rather - 
> at least as I see it - is simply that nvidia's drivers suck :-).

Nobody can write code that always survives changes in non-standard 
interfaces.  Nvidia's drivers for OS's that provide stable interfaces 
work fine.

> Which 
> is hardly Fedora's fault; 

Well, it is a generic Linux problem, but fedora could make it easier for 
the users by not pushing out interface changes without coordinating with 
driver providers.

> if nvidia would get with the program and make 
> Free and Open drivers, then maybe they could be fixed.

Probably not - they would just be in the same shape as firewire and scsi 
drivers that go months/years with bugs that don't get fixed.

>>> Maintenance... sure, I run 'yum update' every few days, big deal :-). 
>>
>> I don't mind running the update - it's when things don't work 
>> afterwards or a remote machine doesn't come back after a reboot that 
>> is the problem.
> 
> I'm sorry to hear about your bad experiences. I've never had such 
> problems, though.

Maybe the person who builds the kernels has the same disk hardware as 
you and has some reason to care if it works.

> Given what it is, I'm sure some people have trouble with Fedora, and you 
> have my sympathy if you're one of them. I'm not convinced, however, that 
> such problems are the norm and not the exception.

And I'm not convinced that anyone even tries anything that matters with 
fedora - or runs it across a large variety of hardware.

-- 
   Les Mikesell
     lesmikesell at gmail.com




From jkeating at redhat.com  Thu Oct 30 22:18:25 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 30 Oct 2008 15:18:25 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <490A24F9.1030005@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>
	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>
	<4908C757.1000902@gmail.com>	<gealfk$4td$1@ger.gmane.org>
	<490943C0.4070703@gmail.com>	<gecjut$mlc$1@ger.gmane.org>
	<4909D963.8010301@gmail.com> <geclvo$v87$1@ger.gmane.org>
	<490A24F9.1030005@gmail.com>
Message-ID: <1225405105.27779.13.camel@luminos.localdomain>

On Thu, 2008-10-30 at 16:19 -0500, Les Mikesell wrote:
> Nobody can write code that always survives changes in non-standard 
> interfaces.  Nvidia's drivers for OS's that provide stable interfaces 
> work fine.

I think you mean os's that don't track upstream.

> 
> > Which 
> > is hardly Fedora's fault; 
> 
> Well, it is a generic Linux problem, 

If by "the changes are upstream" then yes.

> but fedora could make it easier for 
> the users by not pushing out interface changes without coordinating with 
> driver providers.

This "driver" provider has repeatedly in the past not cared one whit
what Fedora does or doesn't do.  Waiting for them to catch up would mean
never moving past a RHEL release.  If instead they worked with the
upstreams, this wouldn't be a problem.

> 
> > if nvidia would get with the program and make 
> > Free and Open drivers, then maybe they could be fixed.
> 
> Probably not - they would just be in the same shape as firewire and scsi 
> drivers that go months/years with bugs that don't get fixed.

Except now there would be more people that would have access and ability
to fix them.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/bed5e241/attachment.sig>

From lesmikesell at gmail.com  Thu Oct 30 22:58:14 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 30 Oct 2008 17:58:14 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <1225405105.27779.13.camel@luminos.localdomain>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<4908BA9F.6000301@redhat.com>	<4908C09B.6080609@gmail.com>	<1225311126.23396.113.camel@nibbler.dlib.indiana.edu>	<4908C757.1000902@gmail.com>	<gealfk$4td$1@ger.gmane.org>	<490943C0.4070703@gmail.com>	<gecjut$mlc$1@ger.gmane.org>	<4909D963.8010301@gmail.com>
	<geclvo$v87$1@ger.gmane.org>	<490A24F9.1030005@gmail.com>
	<1225405105.27779.13.camel@luminos.localdomain>
Message-ID: <490A3C06.1070103@gmail.com>

Jesse Keating wrote:
> 
>> Nobody can write code that always survives changes in non-standard 
>> interfaces.  Nvidia's drivers for OS's that provide stable interfaces 
>> work fine.
> 
> I think you mean os's that don't track upstream.

I mostly meant the "other" 95% of the market that doesn't have GPL 
constraints... But enterprise Linux versions solve the problem too, with 
a certain amount of extra effort.

> If by "the changes are upstream" then yes.
> 
>> but fedora could make it easier for 
>> the users by not pushing out interface changes without coordinating with 
>> driver providers.
> 
> This "driver" provider has repeatedly in the past not cared one whit
> what Fedora does or doesn't do.  Waiting for them to catch up would mean
> never moving past a RHEL release.  If instead they worked with the
> upstreams, this wouldn't be a problem.

I haven't used unbuntu enough to have a real feel for the difference in 
this regard but don't they do the updates automatically and together if 
you have installed the vendor driver?  That is, there is at least some 
coordination between the repository with the kernel and the one with the 
driver, whereas fedora seems to pretend such things don't exist.

>>> if nvidia would get with the program and make 
>>> Free and Open drivers, then maybe they could be fixed.
>> Probably not - they would just be in the same shape as firewire and scsi 
>> drivers that go months/years with bugs that don't get fixed.
> 
> Except now there would be more people that would have access and ability
> to fix them.

That doesn't mean anyone actually will - as firewire languished for 
years, and when they do change them it may not be an improvement, as the 
scsi drivers have periodically broken from changes that didn't seem 
necessary.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From jbarnes at virtuousgeek.org  Thu Oct 30 23:02:19 2008
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Thu, 30 Oct 2008 16:02:19 -0700
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <5256d0b0810301326p1ae11640g5b731c0dabae92bd@mail.gmail.com>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
	<1225397990.25818.389.camel@aglarond.local>
	<5256d0b0810301326p1ae11640g5b731c0dabae92bd@mail.gmail.com>
Message-ID: <200810301602.19324.jbarnes@virtuousgeek.org>

On Thursday, October 30, 2008 1:26 pm Peter Robinson wrote:
> > On Thu, 2008-10-30 at 20:00 +0000, Jonathan Roberts wrote:
> > > 2008/10/30 Peter Robinson <pbrobinson at gmail.com>:
> > > > Has anyone else seen issues with resume with the latest intel 2.5.0
> >
> > driver
> >
> > > > on netbooks. I'm seeing issues on my eeepc 901 which has the intel
> > > > atom
> >
> > i945
> >
> > > > chipset. It had worked previously and resumes OK but I get a black
> >
> > screen
> >
> > > > with a cursor and around that a square of garbled bits. Just
> > > > wondering
> >
> > if
> >
> > > > anyone else has seen that of late on any of the random NetBooks with
> >
> > the
> >
> > > > same chipset like the various newer eeePCs, Dell mini, Acer aspiron
> > > > one
> >
> > etc.
> >
> > > Yeah - resume from suspend fails here. Get the blank screen with
> > > cursor, nothing else.
> >
> > Have you tried the various suspend quirks (most notably, vbepost)?
>
> No, I must say I haven't primarily because it was working quite nicely
> until very recently so was initially wondering whether it was something I
> had changed (not that I tend to change much on my eeePC). Is there a link
> somewhere for these quirks?

Hm, it seems like it should still work, we definitely didn't *intend* to break 
it with 2.5.0. :)

Does it still work from the console (i.e. echo mem > /sys/power/state when 
booted to text mode)?  If so, then it's likely to be a regression we 
introduced in 2.5.0, otherwise it's probably a kernel bug.

-- 
Jesse Barnes, Intel Open Source Technology Center



From peter at thecodergeek.com  Thu Oct 30 23:35:34 2008
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 30 Oct 2008 16:35:34 -0700
Subject: Seeking New Maintainers: viaideinfo, pidgin-libnotify
In-Reply-To: <1225351601.3332.1.camel@erik>
References: <1225349985.5177.43.camel@tuxhugs> <1225351601.3332.1.camel@erik>
Message-ID: <1225409734.4264.0.camel@tuxhugs>

On Thu, 2008-10-30 at 08:26 +0100, Erik van Pienbroek wrote:
> I want to take pidgin-libnotify.

I've orphaned it in PkgDB now. Please feel free to take ownership of it
there. Thanks very much!
-- 
Peter Gordon (codergeek42)
???????????
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/98f094f2/attachment.sig>

From mjg at redhat.com  Thu Oct 30 23:42:45 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Thu, 30 Oct 2008 23:42:45 +0000
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <1225397990.25818.389.camel@aglarond.local>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
	<507738ef0810301300odeb166et6b7d8f1f7a8fb855@mail.gmail.com>
	<1225397990.25818.389.camel@aglarond.local>
Message-ID: <20081030234245.GA9077@srcf.ucam.org>

On Thu, Oct 30, 2008 at 04:19:50PM -0400, Jeremy Katz wrote:

> Have you tried the various suspend quirks (most notably, vbepost)?

i945 is perfectly capable of handling resume on its own in-kernel. The 
problem is more likely to be an excess of quirks interfering with that 
(or, alternatively, someone's broken the kernel).

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From mjg at redhat.com  Thu Oct 30 23:44:49 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Thu, 30 Oct 2008 23:44:49 +0000
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <200810301602.19324.jbarnes@virtuousgeek.org>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
	<1225397990.25818.389.camel@aglarond.local>
	<5256d0b0810301326p1ae11640g5b731c0dabae92bd@mail.gmail.com>
	<200810301602.19324.jbarnes@virtuousgeek.org>
Message-ID: <20081030234449.GB9077@srcf.ucam.org>

On Thu, Oct 30, 2008 at 04:02:19PM -0700, Jesse Barnes wrote:

> Does it still work from the console (i.e. echo mem > /sys/power/state when 
> booted to text mode)?  If so, then it's likely to be a regression we 
> introduced in 2.5.0, otherwise it's probably a kernel bug.

That doesn't test the same suspend pathway. A better option is:

dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From sundaram at fedoraproject.org  Thu Oct 30 23:47:10 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Oct 2008 05:17:10 +0530
Subject: Seeking comaintainers
Message-ID: <490A477E.4020204@fedoraproject.org>

Hi,

I am seeking additional maintainers for the following packages. I am 
working remotely for a while and on a connection with strict download 
limits so won't be able to pay much attention to these packages for 
sometime.

https://admin.fedoraproject.org/pkgdb/users/packages/sundaram

bcrypt -- File encryption utility
checkgmail -- System Tray Application that checks a Gmail Account for 
New Mail
dbench -- Filesystem load benchmarking tool
lxsplit -- File split / merge utility
ms-sys -- Create DOS/MS-compatible boot records
pdfmerge -- Command line utility program for merging PDF files
pyroom -- PyRoom is a full screen text editor and a clone of Writeroom
rssh -- Restricted shell for use with OpenSSH, allowing only scp and/or sftp
sarai-fonts -- Free Sarai Hindi Truetype Font

Issues:

https://bugzilla.redhat.com/show_bug.cgi?id=464325 - Pyroom needs to be 
updated to the latest upstream version

https://bugzilla.redhat.com/show_bug.cgi?id=456182#c17 - Adding rssh to 
the shell file using post scripts turned to be a bad idea and this needs 
  someone to just remove the script and do a rebuild.

Even if you are not interested enough to be a co-maintainer, if anyone 
wants to help out in fixing these simple issues, that would be great.

Rahul



From stlwrt at gmail.com  Fri Oct 31 00:02:13 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Fri, 31 Oct 2008 02:02:13 +0200
Subject: Fedora on EEE?
In-Reply-To: <geclck$mlc$2@ger.gmane.org>
References: <geclck$mlc$2@ger.gmane.org>
Message-ID: <d25f375f0810301702p2ab95cdfla61d6a552555090e@mail.gmail.com>

On Thu, Oct 30, 2008 at 5:55 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> - Does Fedora know about multi-touch? (The default Xandros uses multi-touch
> for scrolling, not very reliable but still nice to have.)

Synaptics driver has multitouch for years. I used macbook-style two
finger scroll 3 years ago on my acer laptop. Check "man synaptics"

Pinch, swipe and other multifinger gestures are also supported by
driver but not yet implemented in applications, mostly because GTK/Qt
lacks proper abstraction for gestures. Highest level of abstraction
available so far is array of finger coordinates, not even their
movement vectors. It would be cool to have some API to track vectors
and common gestures to bind pinch to zoom and swipe to back/forward
etc.


-- 
http://scwlab.com



From konrad at tylerc.org  Fri Oct 31 00:17:51 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 30 Oct 2008 17:17:51 -0700
Subject: Seeking comaintainers
In-Reply-To: <490A477E.4020204@fedoraproject.org>
References: <490A477E.4020204@fedoraproject.org>
Message-ID: <200810301717.51940.konrad@tylerc.org>

On Thursday 30 October 2008 04:47:10 pm Rahul Sundaram wrote:
> Hi,
>
> I am seeking additional maintainers for the following packages. I am
> working remotely for a while and on a connection with strict download
> limits so won't be able to pay much attention to these packages for
> sometime.
>
> https://admin.fedoraproject.org/pkgdb/users/packages/sundaram
>
> bcrypt -- File encryption utility
> checkgmail -- System Tray Application that checks a Gmail Account for
> New Mail
> dbench -- Filesystem load benchmarking tool
> lxsplit -- File split / merge utility
> ms-sys -- Create DOS/MS-compatible boot records
> pdfmerge -- Command line utility program for merging PDF files
> pyroom -- PyRoom is a full screen text editor and a clone of Writeroom
> rssh -- Restricted shell for use with OpenSSH, allowing only scp and/or
> sftp sarai-fonts -- Free Sarai Hindi Truetype Font
>
> Issues:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=464325 - Pyroom needs to be
> updated to the latest upstream version
>
> https://bugzilla.redhat.com/show_bug.cgi?id=456182#c17 - Adding rssh to
> the shell file using post scripts turned to be a bad idea and this needs
>   someone to just remove the script and do a rebuild.
>
> Even if you are not interested enough to be a co-maintainer, if anyone
> wants to help out in fixing these simple issues, that would be great.
>
> Rahul

What's the use of lxsplit over the coreutils 'split' command?

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From itamar at ispbrasil.com.br  Fri Oct 31 00:24:20 2008
From: itamar at ispbrasil.com.br (Itamar - IspBrasil)
Date: Thu, 30 Oct 2008 22:24:20 -0200
Subject: Seeking comaintainers
In-Reply-To: <490A477E.4020204@fedoraproject.org>
References: <490A477E.4020204@fedoraproject.org>
Message-ID: <490A5034.8040601@ispbrasil.com.br>

I can do this for you.

my nickname is itamarjp



--------------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599

On 10/30/2008 9:47 PM, Rahul Sundaram wrote:
> Hi,
>
> I am seeking additional maintainers for the following packages. I am 
> working remotely for a while and on a connection with strict download 
> limits so won't be able to pay much attention to these packages for 
> sometime.
>
> https://admin.fedoraproject.org/pkgdb/users/packages/sundaram
>
> bcrypt -- File encryption utility
> checkgmail -- System Tray Application that checks a Gmail Account for 
> New Mail
> dbench -- Filesystem load benchmarking tool
> lxsplit -- File split / merge utility
> ms-sys -- Create DOS/MS-compatible boot records
> pdfmerge -- Command line utility program for merging PDF files
> pyroom -- PyRoom is a full screen text editor and a clone of Writeroom
> rssh -- Restricted shell for use with OpenSSH, allowing only scp 
> and/or sftp
> sarai-fonts -- Free Sarai Hindi Truetype Font
>
> Issues:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=464325 - Pyroom needs to 
> be updated to the latest upstream version
>
> https://bugzilla.redhat.com/show_bug.cgi?id=456182#c17 - Adding rssh 
> to the shell file using post scripts turned to be a bad idea and this 
> needs  someone to just remove the script and do a rebuild.
>
> Even if you are not interested enough to be a co-maintainer, if anyone 
> wants to help out in fixing these simple issues, that would be great.
>
> Rahul
>




From sundaram at fedoraproject.org  Fri Oct 31 00:28:45 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Oct 2008 05:58:45 +0530
Subject: Seeking comaintainers
In-Reply-To: <200810301717.51940.konrad@tylerc.org>
References: <490A477E.4020204@fedoraproject.org>
	<200810301717.51940.konrad@tylerc.org>
Message-ID: <490A513D.5070907@fedoraproject.org>

Conrad Meyer wrote:

> What's the use of lxsplit over the coreutils 'split' command?

http://www.freebyte.com/hjsplit/ is a very popular Windows utility to 
split files. lxsplit provides a compatible implementation for Linux.

Rahul



From ianweller at gmail.com  Fri Oct 31 00:36:46 2008
From: ianweller at gmail.com (Ian Weller)
Date: Thu, 30 Oct 2008 19:36:46 -0500
Subject: Seeking comaintainers
In-Reply-To: <490A477E.4020204@fedoraproject.org>
References: <490A477E.4020204@fedoraproject.org>
Message-ID: <20081031003636.GA10253@gmail.com>

On Fri, Oct 31, 2008 at 05:17:10AM +0530, Rahul Sundaram wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=456182#c17 - Adding rssh to  
> the shell file using post scripts turned to be a bad idea and this needs  
>  someone to just remove the script and do a rebuild.
>
Will be done shortly.

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081030/91ca7cca/attachment.sig>

From konrad at tylerc.org  Fri Oct 31 00:39:06 2008
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 30 Oct 2008 17:39:06 -0700
Subject: Seeking comaintainers
In-Reply-To: <490A513D.5070907@fedoraproject.org>
References: <490A477E.4020204@fedoraproject.org>
	<200810301717.51940.konrad@tylerc.org>
	<490A513D.5070907@fedoraproject.org>
Message-ID: <200810301739.07156.konrad@tylerc.org>

On Thursday 30 October 2008 05:28:45 pm Rahul Sundaram wrote:
> Conrad Meyer wrote:
> > What's the use of lxsplit over the coreutils 'split' command?
>
> http://www.freebyte.com/hjsplit/ is a very popular Windows utility to
> split files. lxsplit provides a compatible implementation for Linux.
>
> Rahul

Oh, oops, I didn't intend to send this to the list.

-- 
Conrad Meyer <konrad at tylerc.org>




From sundaram at fedoraproject.org  Fri Oct 31 00:59:14 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Oct 2008 06:29:14 +0530
Subject: Seeking comaintainers
In-Reply-To: <490A5034.8040601@ispbrasil.com.br>
References: <490A477E.4020204@fedoraproject.org>
	<490A5034.8040601@ispbrasil.com.br>
Message-ID: <490A5862.4060407@fedoraproject.org>

Itamar - IspBrasil wrote:
> I can do this for you.
> 
> my nickname is itamarjp

Thanks but it is not clear to me what you did offer to help. I don't see 
you in freenode either.

pkgdb shows you at 
https://admin.fedoraproject.org/pkgdb/users/info/itamarjp but doesn't 
list any packages. Which ones do you want to co-maintain?


Rahul



From orcanbahri at yahoo.com  Fri Oct 31 01:06:42 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Thu, 30 Oct 2008 18:06:42 -0700 (PDT)
Subject: Seeking comaintainers
In-Reply-To: <490A477E.4020204@fedoraproject.org>
Message-ID: <538158.88753.qm@web32804.mail.mud.yahoo.com>

--- On Thu, 10/30/08, Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> From: Rahul Sundaram <sundaram at fedoraproject.org>
> Subject: Seeking comaintainers
> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>

> checkgmail -- System Tray Application that checks a Gmail
> lxsplit -- File split / merge utility
> pdfmerge -- Command line utility program for merging PDF

I sent my requests in pkgdb for the these three.
Orcan


      



From sundaram at fedoraproject.org  Fri Oct 31 01:29:30 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Oct 2008 06:59:30 +0530
Subject: Seeking comaintainers
In-Reply-To: <538158.88753.qm@web32804.mail.mud.yahoo.com>
References: <538158.88753.qm@web32804.mail.mud.yahoo.com>
Message-ID: <490A5F7A.8030907@fedoraproject.org>

Orcan Ogetbil wrote:
> --- On Thu, 10/30/08, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> 
>> From: Rahul Sundaram <sundaram at fedoraproject.org>
>> Subject: Seeking comaintainers
>> To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
> 
>> checkgmail -- System Tray Application that checks a Gmail
>> lxsplit -- File split / merge utility
>> pdfmerge -- Command line utility program for merging PDF
> 
> I sent my requests in pkgdb for the these three.

Already approved. Thanks.

Rahul



From rc040203 at freenet.de  Fri Oct 31 03:23:02 2008
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 31 Oct 2008 04:23:02 +0100
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081030201825.GB18603@mokona.greysector.net>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<20081029205726.GD25197@nostromo.devel.redhat.com>
	<20081030123442.GB11708@mokona.greysector.net>
	<1225375481.19928.15.camel@unused>
	<20081030201825.GB18603@mokona.greysector.net>
Message-ID: <1225423382.3897.533.camel@beck.corsepiu.local>

On Thu, 2008-10-30 at 21:18 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 30 October 2008 at 15:04, Dan Williams wrote:
> > On Thu, 2008-10-30 at 13:34 +0100, Dominik 'Rathann' Mierzejewski wrote:
> [...]
> > > What's wrong with manually editing wpa_supplicant.conf?
> > 
> > Because it's not easily from anything but wpa_supplicant, and it's
> > completely different than the existing ifup/ifdown config system.
> > System-config-network would have to grow the ability to parse the
> > wpa_supplicant config file format.  You can't override the variables
> > from /etc/sysconfig/network if you want to.  There's no separation of
> > interfaces to allow for multiple connections with two or more wifi cards
> > with 'ifup number1' and 'ifup number2' independently.
> 
> How often do you see machines with multiple wifi cards? I haven't seen
> any.
Until last week, I haven't see one, either, but I could not manage to
get the RealTek wifi working on my netbook, ...

>  I could easily set one up by adding a usb stick with wifi or a pcmcia
> card, but I haven't needed it yet.
..., which had caused me to try exactly what you describe.

Provided how cheap these usb-beasts have become, it doesn't need much
imagination to envision you'll soon see more of such systems.

Ralf






From tim.lauridsen at googlemail.com  Fri Oct 31 06:27:06 2008
From: tim.lauridsen at googlemail.com (Tim Lauridsen)
Date: Fri, 31 Oct 2008 07:27:06 +0100
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
Message-ID: <490AA53A.5040007@googlemail.com>

Peter Robinson wrote:
> Hi All,
>
> Has anyone else seen issues with resume with the latest intel 2.5.0 
> driver on netbooks. I'm seeing issues on my eeepc 901 which has the 
> intel atom i945 chipset. It had worked previously and resumes OK but I 
> get a black screen with a cursor and around that a square of garbled 
> bits. Just wondering if anyone else has seen that of late on any of 
> the random NetBooks with the same chipset like the various newer 
> eeePCs, Dell mini, Acer aspiron one etc.
>
> Cheers,
> Peter
Same problem on my ThinkPad T60, Disable compiz and it will work.
https://bugzilla.redhat.com/show_bug.cgi?id=467332

Tim



From pmatilai at laiskiainen.org  Fri Oct 31 06:37:11 2008
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 31 Oct 2008 08:37:11 +0200 (EET)
Subject: providing what they require
In-Reply-To: <20081029161452.GA19343@nostromo.devel.redhat.com>
References: <1224713033.3304.87.camel@rosebud>
	<20081023004149.8b90f588.mschwendt@gmail.com>
	<1224715741.3304.91.camel@rosebud>
	<200810230944.53271.ville.skytta@iki.fi>
	<alpine.DEB.1.10.0810240912370.27662@gotcha.dreamhost.com>
	<1224878261.29258.22.camel@rosebud>
	<alpine.DEB.1.10.0810290903480.17696@gotcha.dreamhost.com>
	<20081029161452.GA19343@nostromo.devel.redhat.com>
Message-ID: <alpine.DEB.1.10.0810310832470.17054@gotcha.dreamhost.com>

On Wed, 29 Oct 2008, Bill Nottingham wrote:

> Panu Matilainen (pmatilai at laiskiainen.org) said:
>> $ rpm -qa --qf "%{name}-%{version}\n[\t%{CLASSDICT}\n]\n"
>>
>> One of my favorites:
>>         PNG image data, 313 x 225, 8-bit/color RGBA, non-interlaced
>>         PNG image data, 339 x 210, 8-bit/color RGBA, non-interlaced
>>         PNG image data, 349 x 274, 8-bit/color RGBA, non-interlaced
>>         ...
>>
>> Rpm knows not only that it's image data, it even knows the picture
>> dimensions...
>
> Only in the sense that that's the raw output of file(1) - to rely

I guess you missed the sarcastic intent in the "knows" above :)

> on that, you have to hope that that never changes. Which is unlikely.
> (Ergo ... useless.)

Well, yes. That's largely the reason rpm used to bundle it's own copy of 
libmagic (to avoid strings changing) but that has it's own issues.

 	- Panu -



From nicu_fedora at nicubunu.ro  Fri Oct 31 07:23:11 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 31 Oct 2008 09:23:11 +0200
Subject: Fedora on EEE?
In-Reply-To: <5256d0b0810300927n764c4ad0t65207d6dd9c9341d@mail.gmail.com>
References: <geclck$mlc$2@ger.gmane.org> <4909DB7F.9070509@nicubunu.ro>
	<5256d0b0810300927n764c4ad0t65207d6dd9c9341d@mail.gmail.com>
Message-ID: <490AB25F.30408@nicubunu.ro>

Peter Robinson wrote:
> 
> 
>     Well, it chokes on my WPA.
> 
> 
> Are you using WPA2 (or WPA+WPA2) on your AP? I have the same issue with 
> mine but it started working once I just set my AP to plain WPA. This 
> driver is being re-written for upstream inclusion so I suspect the 
> problem will go away once that is complete. It just seems to be taking ages.

Indeed, I use WPA PSK + WPA2 PSK and changing the mode is not an option 
since I have some other equipments that work the best in this mode. I'll 
stay wired for the time being.

-- 
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 nicu_fedora at nicubunu.ro  Fri Oct 31 07:30:44 2008
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Fri, 31 Oct 2008 09:30:44 +0200
Subject: Fedora on EEE?
In-Reply-To: <1225386102.24806.5.camel@unused>
References: <geclck$mlc$2@ger.gmane.org> <4909DB7F.9070509@nicubunu.ro>
	<1225386102.24806.5.camel@unused>
Message-ID: <490AB424.1000909@nicubunu.ro>

Dan Williams wrote:
> On Thu, 2008-10-30 at 18:06 +0200, Nicu Buculei wrote:
>> Matthew Woehlke wrote:
>>> Dominik 'Rathann' Mierzejewski wrote:
>>>> On Wednesday, 29 October 2008 at 22:44, Matthew Woehlke wrote:
>>>>> - Xandros (on my Asus EEE, and only because I haven't had time to 
>>>>> find something better; how's Fedora on those?)
>>>> Fedora works great on those. I'm happily running F10 since snap2.
>>>> All I needed was an akmod from rpmfusion (rt2860sta driver) and
>>>> a pm quirk to re-enable screen after resume.
>> Well, it chokes on my WPA.
> 
> Because the driver is the vendor driver, has not been cleaned up for the
> quality standards of the kernel, does not properly implement wireless
> extensions, and will _never_ go upstream because it includes its own
> 802.11 stack.
> 
> Effort should be directed towards the rt2x00 project which is writing
> the correct upstreamable mac80211-based driver for these cards.

I am fully aware of this and from what I saw on the kernel list, even 
Linus is hit by this lack of this driver (he owns an Eee PC 901).
AFAIK, the estimation for a proper driver in the upstream kernel is for 
2.6.29, that should be Fedora 11, next spring.
Until then, the akmod from Rpmfusion seems like the best temporary option.

-- 
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 mcepl at redhat.com  Fri Oct 31 10:53:46 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 31 Oct 2008 11:53:46 +0100
Subject: A suggestion regarding new features
References: <1225300511.3846.44.camel@mentor.gurulabs.com>
	<200810301347.m9UDlswk004619@laptop14.inf.utfsm.cl>
Message-ID: <qm4rt5xmmo.ln2@ppp1053.in.ipex.cz>

On 2008-10-30, 13:47 GMT, Horst H. von Brand wrote:
> Old documentation has a penchant for hinding in all sorts of 
> nooks and crannies of the 'net, and comes to light only when 
> $RELATIVE_NEWBIE looks around for a fix for $MISTERY.

At least there is some -- HOWTOs etc., now we have every little 
petty project has its own website, which doesn'? link with the 
rest of the world.

Mat?j



From mcepl at redhat.com  Fri Oct 31 11:08:45 2008
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 31 Oct 2008 12:08:45 +0100
Subject: Reasons to preseve X on tty7
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<20081029212536.GG25197@nostromo.devel.redhat.com>
	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>
	<20081030044536.GA10407@jadzia.bu.edu> <490940C6.3070701@gmail.com>
Message-ID: <ti5rt5xmmo.ln2@ppp1053.in.ipex.cz>

On 2008-10-30, 05:06 GMT, Les Mikesell wrote:
> Doesn't fit with the code. 7.3 was the last in the 
> 'increasingly reliable' series.  8 and 9 each introduced new 
> breakage that was never fixed.

I was in the Debian-land then already, what were the problems?  
(you mean wonderful new gcc, which required kernel-only 
compiler?).

Mat?j



From rawhide at fedoraproject.org  Fri Oct 31 14:51:22 2008
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 31 Oct 2008 14:51:22 +0000 (UTC)
Subject: rawhide report: 20081031 changes
Message-ID: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>

Compose started at Fri Oct 31 06:01:18 UTC 2008

Updated Packages:

NetworkManager-pptp-0.7.0-0.12.svn4229.fc10
-------------------------------------------
* Wed Oct 29 18:00:00 2008 Dan Williams <dcbw at redhat.com> 1:0.7.0-12.svn4229
- Fix hang in auth dialog (rh #467007)


PackageKit-0.3.9-3.fc10
-----------------------
* Tue Oct 28 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-3
- Install the usr/share/cmake/Modules/FindQPackageKit.cmake file so we
  can build KPackageKit from svn head.
- Fix installing the preupgrade package when we check for distro upgrades
  on machines with 32 and 64 bit versions available. Fixes #469172

* Tue Oct 28 18:00:00 2008 Richard Hughes  <rhughes at redhat.com> - 0.3.9-2
- Apply a couple of patches from upstream to fix development filtering
  and installing the web plugin.


binutils-2.18.50.0.9-7.fc10
---------------------------
* Thu Oct 30 18:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> 2.18.50.0.9-7
- Fix %{_prefix}/include/bfd.h on 32-bit hosts due the 64-bit BFD target
  support from 2.18.50.0.8-2 (BZ 468495).

* Thu Oct 30 18:00:00 2008 Jan Kratochvil <jan.kratochvil at redhat.com> 2.18.50.0.9-6
- binutils-devel now requires zlib-devel (BZ 463101 comment 5).
- Fix complains on .gnu.linkonce.r relocations to their discarded
  .gnu.linkonce.t counterparts.


digikam-0.10.0-0.6.beta5.fc10
-----------------------------
* Mon Oct 27 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.10.0-0.6.beta5
- digikam-0.10.0-beta5


fedora-release-notes-9.92-4
---------------------------
* Thu Oct 30 18:00:00 2008 Paul W. Frields <stickster at gmail.com> - 9.92-4
- Fix URI in Release Notes OMF file (#469179)


gambas2-2.9.0-1.fc10
--------------------
* Thu Oct 30 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 2.9.0-1
- Update to 2.9.0


java-1.6.0-openjdk-1.6.0.0-2b12.fc10
------------------------------------
* Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-2b12
- Updated icedteasnapshot.
- Fixed post scriptlet to remove gcjwebplugin.so.
- Updated jvisualvm requirement.
- Added build option --with-pkgversion=6b12-Fedora-10
- Resolves: rhbz#428503
- Resolves: rhbz#251829
- Resolves: rhbz#415061
- Resolves: rhbz#452188

* Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.2.b12
- Added netbeans requirement for devel package.
- Fixed removal of gcjwebplugin.so link when installing plugin package.
- Updated Release.
- Resolves: rhbz#468635


kdegraphics-4.1.2-4.fc10
------------------------
* Wed Oct 29 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.1.2-4
- respin libkexiv2/libkdcraw backport patches


kernel-2.6.27.4-68.fc10
-----------------------
* Thu Oct 30 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.4-67
- radeon: try and workaround AGP badness with kms + enable VRAM mtrr

* Wed Oct 29 18:00:00 2008 Jarod Wilson <jarod at redhat.com> 2.6.27.4-66
- Update to latest firewire git code:
  * Resolve spb2/ohci module load race causing delayed sbp2 logins (#466679)
  * Prevent >256 bus resets from crashing the system (improves #244576)
  * Fix assorted memory leaks
  * Include timestamps in iso packet headers

* Wed Oct 29 18:00:00 2008 Dave Jones <davej at redhat.com>
- Reduce maximum supported CPUs on x86-64 to 64.

* Wed Oct 29 18:00:00 2008 Dave Airlie <airlied at redhat.com> 2.6.27.4-65
- radeon modesetting : misc fixes - rs690, agp unload, module unload warning


kipi-plugins-0.2.0-0.4.beta3.fc10
---------------------------------
* Mon Oct 27 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 0.2.0-0.4.beta3
- kipi-plugins-0.2.0-beta3


kphotoalbum-3.2-0.4.20081007svn.fc10
------------------------------------
* Wed Oct 29 18:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 3.2-0.4.20081007svn
- respin (kdegraphics)


ldm-2.0.15-1.fc10
-----------------
* Fri Oct 31 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.15-1
- ldminfod tells LDM client location of Xsession script
  fallback to client's known location if ldminfod failed to tell it
- ldminfod moved from ltsp-server to ldminfod package


ltsp-5.1.30-2.fc10
------------------
* Fri Oct 31 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.30-2
- ltsp-server requires ldminfod

* Thu Oct 30 18:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.30-1
- ldminfod tells LDM client location of Xsession script
  fallback to client's known location if ldminfod failed to tell it
- ldminfod moved from ltsp-server to ldminfod package
- Add alsa-plugins-pulseaudio to client chroot, should allow most
  localapps to output sound.
- Fix client boot with F10 iproute
- Debug shells on VT2-VT6 are now disabled by default
  edit /var/lib/tftpboot/i386/lts.conf to enable if you need it


mash-0.4.2-3.fc10
-----------------
* Thu Oct 30 18:00:00 2008 Jesse Keating <jkeating at redhat.com> - 0.4.2-3
- Add patch from upstream that hasn't been relased yet.
- Drop patch to ignore F10 key.


mkinitrd-6.0.69-1.fc10
----------------------
* Wed Oct 29 18:00:00 2008 Peter Jones <pjones at redhat.com> - 6.0.69-1
- Make it so we actually handle luks devs, cciss or otherwise. (dlehman)
  Resolves: rhbz#468856


perl-CGI-SpeedyCGI-2.22-4.fc10
------------------------------
* Thu Oct 30 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 2.22-4
- Fixed default configuration file reading loadmodule (#448320)


phpMyAdmin-3.0.1.1-1.fc10
-------------------------
* Thu Oct 30 18:00:00 2008 Robert Scheck <robert at fedoraproject.org> 3.0.1.1-1
- Upstream released 3.0.1.1 (#468974)


plymouth-0.6.0-0.2008.10.30.2.fc10
----------------------------------
* Thu Oct 30 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.30.2
- Update prompt text colors to be legible on new artwork

* Thu Oct 30 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.30.1
- Drop upstreamed patches
- Patch from Charlie to update artwork
- Patch from Charlie to make password screen match animation better
  (bug 468899)

* Thu Oct 30 18:00:00 2008 Ray Strode <rstrode at redhat.com> 0.6.0-0.2008.10.27.8
- Fix escape at password prompt (bug 467533)


policycoreutils-2.0.57-10.fc10
------------------------------
* Thu Oct 30 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-10
- Fix traceback in audit2why

* Wed Oct 29 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-9
- Make GUI use translations

* Wed Oct 29 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-8
- Fix typo in man page

* Tue Oct 28 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.57-7
- Handle selinux disabled correctly
- Handle manipulation of fcontext file correctly


pyxdg-0.16-1.fc10
-----------------
* Thu Oct 30 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.16-1
- update to 0.16
- fix indent bug in DesktopEntry.py (bz 469229)


rhythmbox-0.11.6-15.6005.fc10
-----------------------------
* Thu Oct 30 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-15.r6005
- Update to rev 6005
- Fixes typo in the LIRC config
- Force GConf library location to be a URI on startup


rssh-2.3.2-5.fc10
-----------------
* Thu Oct 30 18:00:00 2008 Ian Weller <ianweller at gmail.com> - 2.3.2-5
- Remove pre and post scripts
  - https://bugzilla.redhat.com/show_bug.cgi?id=456182#c17


selinux-policy-3.5.13-11.fc10
-----------------------------
* Wed Oct 29 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-11
- Fix confined users 
- Allow xguest to read/write xguest_dbusd_t

* Mon Oct 27 18:00:00 2008 Dan Walsh <dwalsh at redhat.com> 3.5.13-9
- Allow openoffice execstack/execmem privs


shared-mime-info-0.51-4.fc10
----------------------------
* Wed Oct 29 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 0.51-4
- Add patch to avoid picture CD being anything with a pictures directory
  (#459365)


solar-backgrounds-0.91.1-1.fc10
-------------------------------
* Thu Oct 30 18:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.91.0-2
- Bump Release for rebuild

* Thu Oct 30 18:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.91.0-1
- Split into basic wallpapers with standard resolution (for Live CD Spins) and
  -extras package with more resolutions

* Thu Oct 30 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.91.1-1
- Fix 5:4 to be really 1280x1024, not 1280x1014 (add top 10px from dual version)

* Tue Oct 28 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.90.0-2
- Split out a -common so we can symlink the wallpapers we need in the KDE theme
- without having to require all the ones we can't use.


solar-kde-theme-0.1.11-1.fc10
-----------------------------
* Thu Oct 30 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.10-3
- list 1200x900 (OLPC XO) for 4:3
- list 1280x768 (5:3) as widescreen (used by at least one netbook)

* Thu Oct 30 18:00:00 2008 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.1.10-2
- use backgrounds from solar-backgrounds-common (>= 0.91.0, with the new look)
- support aspect ratios in the KDM theme
- add some more 4:3 and 8:5 resolutions to the symlink lists (KDM, wallpapers)
- use solar_wide.png for 800x480 and 1024x600 in KDM and wallpapers

* Thu Oct 30 18:00:00 2008 Jaroslav Reznik <jreznik at redhat.com> 0.1.11-1
- fixes full qualified host name runs past the boundaries (bz#469048)
- removes backgrounds from source tarball


totem-pl-parser-2.24.2-1.fc10
-----------------------------
* Thu Oct 30 18:00:00 2008 - Bastien Nocera <bnocera at redhat.com> - 2.24.2-1
- Update to 2.24.2


xorg-x11-drv-ati-6.9.0-38.fc10
------------------------------

Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 28









Broken deps for ppc64
----------------------------------------------------------
	livecd-tools-019-1.fc10.ppc64 requires yaboot





From mw_triad at users.sourceforge.net  Fri Oct 31 15:17:47 2008
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 31 Oct 2008 10:17:47 -0500
Subject: Fedora on EEE?
In-Reply-To: <d25f375f0810301702p2ab95cdfla61d6a552555090e@mail.gmail.com>
References: <geclck$mlc$2@ger.gmane.org>
	<d25f375f0810301702p2ab95cdfla61d6a552555090e@mail.gmail.com>
Message-ID: <gef7ir$fm9$1@ger.gmane.org>

Pavel Shevchuk wrote:
> On Thu, Oct 30, 2008 at 5:55 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> Dominik 'Rathann' Mierzejewski wrote:
>> - Does Fedora know about multi-touch? (The default Xandros uses multi-touch
>> for scrolling, not very reliable but still nice to have.)
> 
> Synaptics driver has multitouch for years. I used macbook-style two
> finger scroll 3 years ago on my acer laptop. Check "man synaptics"
> 
> Pinch, swipe and other multifinger gestures are also supported by
> driver but not yet implemented in applications, mostly because GTK/Qt
> lacks proper abstraction for gestures. Highest level of abstraction
> available so far is array of finger coordinates, not even their
> movement vectors. It would be cool to have some API to track vectors
> and common gestures to bind pinch to zoom and swipe to back/forward
> etc.

Ok, so it's not new to Acer/Xandros, just that they're using the right 
driver? Nice to know.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Will your shell have salvation? Only if it's Bourne Again.



From orion at cora.nwra.com  Fri Oct 31 15:55:38 2008
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 31 Oct 2008 09:55:38 -0600
Subject: rawhide report: 20081031 changes
In-Reply-To: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
Message-ID: <490B2A7A.6040108@cora.nwra.com>

Rawhide Report wrote:
> Compose started at Fri Oct 31 06:01:18 UTC 2008

Does not appear to be on download.fedora.redhat.com yet....

-- 
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 lemenkov at gmail.com  Fri Oct 31 16:04:55 2008
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 31 Oct 2008 19:04:55 +0300
Subject: rawhide report: 20081031 changes
In-Reply-To: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
Message-ID: <adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>

2008/10/31 Rawhide Report <rawhide at fedoraproject.org>:
> Compose started at Fri Oct 31 06:01:18 UTC 2008
>
> Updated Packages:

> java-1.6.0-openjdk-1.6.0.0-2b12.fc10
> ------------------------------------
> * Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-2b12
> - Updated icedteasnapshot.
> - Fixed post scriptlet to remove gcjwebplugin.so.
> - Updated jvisualvm requirement.
> - Added build option --with-pkgversion=6b12-Fedora-10
> - Resolves: rhbz#428503
> - Resolves: rhbz#251829
> - Resolves: rhbz#415061
> - Resolves: rhbz#452188
>
> * Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.2.b12
> - Added netbeans requirement for devel package.
> - Fixed removal of gcjwebplugin.so link when installing plugin package.
> - Updated Release.
> - Resolves: rhbz#468635

So, since now I need to install netbeans-platform8 in order to be able
to compile helloworld.java? It looks for me like one more redunant BR.
Correct me if I wrong.


-- 
With best regards!



From jkeating at redhat.com  Fri Oct 31 16:04:36 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 31 Oct 2008 09:04:36 -0700
Subject: rawhide report: 20081031 changes
In-Reply-To: <490B2A7A.6040108@cora.nwra.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<490B2A7A.6040108@cora.nwra.com>
Message-ID: <1225469077.31015.1.camel@luminos.localdomain>

On Fri, 2008-10-31 at 09:55 -0600, Orion Poplawski wrote:
> Does not appear to be on download.fedora.redhat.com yet....

This tree switched out all the rpms with new rpms signed with the Fedora
10 key.  That's a lot of churn for mirrors to cope with.

download.fedora.redhat.com is a round robin of a few mirrors and not all
of them have the content yet.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081031/02bb2290/attachment.sig>

From dcbw at redhat.com  Fri Oct 31 16:05:28 2008
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 31 Oct 2008 12:05:28 -0400
Subject: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)
In-Reply-To: <20081030201825.GB18603@mokona.greysector.net>
References: <20081028213134.21EB661A0DA@hormel.redhat.com>
	<alpine.LRH.2.00.0810281736220.31333@hogwarts.egr.duke.edu>
	<20081029010142.GB12270@nostromo.devel.redhat.com>
	<20081029140356.GF1293@mokona.greysector.net>
	<20081029205726.GD25197@nostromo.devel.redhat.com>
	<20081030123442.GB11708@mokona.greysector.net>
	<1225375481.19928.15.camel@unused>
	<20081030201825.GB18603@mokona.greysector.net>
Message-ID: <1225469128.27440.8.camel@localhost.localdomain>

On Thu, 2008-10-30 at 21:18 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 30 October 2008 at 15:04, Dan Williams wrote:
> > On Thu, 2008-10-30 at 13:34 +0100, Dominik 'Rathann' Mierzejewski wrote:
> [...]
> > > What's wrong with manually editing wpa_supplicant.conf?
> > 
> > Because it's not easily from anything but wpa_supplicant, and it's
> > completely different than the existing ifup/ifdown config system.
> > System-config-network would have to grow the ability to parse the
> > wpa_supplicant config file format.  You can't override the variables
> > from /etc/sysconfig/network if you want to.  There's no separation of
> > interfaces to allow for multiple connections with two or more wifi cards
> > with 'ifup number1' and 'ifup number2' independently.
> 
> How often do you see machines with multiple wifi cards? I haven't seen
> any. I could easily set one up by adding a usb stick with wifi or a pcmcia
> card, but I haven't needed it yet.

Internal + USB?  If you want to do wireless -> wireless sharing (say, in
a hotel with $$$ wifi) then this is really your only option at the
moment.

Dan

> > A much better, more integrated and consistent implementation would have
> > each ifcfg file essentially be a network block in the supplicant config
> > file.  When you 'ifup my-wpa', the scripts write out a new supplicant
> > config file using key/value pairs
> > in /etc/sysconfig/network-scripts/ifcfg-my-wpa and execute a supplicant
> > based on that, then somehow wait for the supplicant to connect by
> > listening on the specific control socket for a connection, and if no
> > connection occurs, time out and fail just like DHCP fails.  When you
> > 'ifdown my-wpa', it will terminate the supplicant based on the PID file
> > written to /var/run/wpa_supplicant-wlan0-my-wpa.pid and clean up the
> > routing and addresses.
> > 
> > That's what the patch _should_ do.  Just tossing a config file off to
> > the supplicant is a cop-out half solution.
> 
> Alright, I'll see what I can come up with. I guess I can understand your
> unwillingness to accept a half-assed solution that works only in one scenario.
> After all, I don't like half-assed solutions myself.
> 
> Regards,
> R.
> 
> -- 
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
> "Faith manages."
>         -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> 



From jwboyer at gmail.com  Fri Oct 31 16:10:58 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 31 Oct 2008 12:10:58 -0400
Subject: rawhide report: 20081031 changes
In-Reply-To: <1225469077.31015.1.camel@luminos.localdomain>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<490B2A7A.6040108@cora.nwra.com>
	<1225469077.31015.1.camel@luminos.localdomain>
Message-ID: <20081031161058.GA10319@yoda.jdub.homelinux.org>

On Fri, Oct 31, 2008 at 09:04:36AM -0700, Jesse Keating wrote:
>On Fri, 2008-10-31 at 09:55 -0600, Orion Poplawski wrote:
>> Does not appear to be on download.fedora.redhat.com yet....
>
>This tree switched out all the rpms with new rpms signed with the Fedora
>10 key.  That's a lot of churn for mirrors to cope with.
>
>download.fedora.redhat.com is a round robin of a few mirrors and not all
>of them have the content yet.

Actually, I think download.fedoraproject.org is the round-robin.

josh



From jkeating at redhat.com  Fri Oct 31 16:22:29 2008
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 31 Oct 2008 09:22:29 -0700
Subject: rawhide report: 20081031 changes
In-Reply-To: <20081031161058.GA10319@yoda.jdub.homelinux.org>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<490B2A7A.6040108@cora.nwra.com>
	<1225469077.31015.1.camel@luminos.localdomain>
	<20081031161058.GA10319@yoda.jdub.homelinux.org>
Message-ID: <1225470151.31015.3.camel@luminos.localdomain>

On Fri, 2008-10-31 at 12:10 -0400, Josh Boyer wrote:
> Actually, I think download.fedoraproject.org is the round-robin.

Nope, that's mirrormanager (:

Although technically I think we round-robin the entry point to
mirror-manager, which then sends you out to a mirror from the list.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081031/85bf54d9/attachment.sig>

From langel at redhat.com  Fri Oct 31 17:08:43 2008
From: langel at redhat.com (Lillian Angel)
Date: Fri, 31 Oct 2008 13:08:43 -0400
Subject: rawhide report: 20081031 changes
In-Reply-To: <adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
Message-ID: <490B3B9B.5070805@redhat.com>

Peter Lemenkov wrote:
> 2008/10/31 Rawhide Report <rawhide at fedoraproject.org>:
>   
>> Compose started at Fri Oct 31 06:01:18 UTC 2008
>>
>> Updated Packages:
>>     
>
>   
>> java-1.6.0-openjdk-1.6.0.0-2b12.fc10
>> ------------------------------------
>> * Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-2b12
>> - Updated icedteasnapshot.
>> - Fixed post scriptlet to remove gcjwebplugin.so.
>> - Updated jvisualvm requirement.
>> - Added build option --with-pkgversion=6b12-Fedora-10
>> - Resolves: rhbz#428503
>> - Resolves: rhbz#251829
>> - Resolves: rhbz#415061
>> - Resolves: rhbz#452188
>>
>> * Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.2.b12
>> - Added netbeans requirement for devel package.
>> - Fixed removal of gcjwebplugin.so link when installing plugin package.
>> - Updated Release.
>> - Resolves: rhbz#468635
>>     
>
> So, since now I need to install netbeans-platform8 in order to be able
> to compile helloworld.java? It looks for me like one more redunant BR.
> Correct me if I wrong.

Correct. The -devel package now includes visualvm, which depends on 
netbeans-platform8. We can talk about moving this out to a separate 
package, and adding it as a "Suggests" for the java-1.6.0-openjdk-devel 
package. The netbeans-platform8 package adds about 6.0M (not including 
the small packages it requires. ~1M in total: javahelp2 jna 
jpackage-utils swing-layout).

What are everyone's thoughts on this?


Lillian



From aph at redhat.com  Fri Oct 31 17:23:14 2008
From: aph at redhat.com (Andrew Haley)
Date: Fri, 31 Oct 2008 17:23:14 +0000
Subject: rawhide report: 20081031 changes
In-Reply-To: <490B3B9B.5070805@redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
	<490B3B9B.5070805@redhat.com>
Message-ID: <490B3F02.7050305@redhat.com>

Lillian Angel wrote:

> 
> Correct. The -devel package now includes visualvm, which depends on
> netbeans-platform8. We can talk about moving this out to a separate
> package, and adding it as a "Suggests" for the java-1.6.0-openjdk-devel
> package. The netbeans-platform8 package adds about 6.0M (not including
> the small packages it requires. ~1M in total: javahelp2 jna
> jpackage-utils swing-layout).
> 
> What are everyone's thoughts on this?

I think making such a change would be beneficial.  Not crucial, but
nice.

Andrew.



From overholt at redhat.com  Fri Oct 31 17:38:53 2008
From: overholt at redhat.com (Andrew Overholt)
Date: Fri, 31 Oct 2008 13:38:53 -0400
Subject: rawhide report: 20081031 changes
In-Reply-To: <490B3B9B.5070805@redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
	<490B3B9B.5070805@redhat.com>
Message-ID: <20081031173852.GA3664@redhat.com>

* Lillian Angel <langel at redhat.com> [2008-10-31 13:08]:
> Peter Lemenkov wrote:
>> So, since now I need to install netbeans-platform8 in order to be able
>> to compile helloworld.java? It looks for me like one more redunant BR.
>> Correct me if I wrong.
>
> Correct. The -devel package now includes visualvm, which depends on  
> netbeans-platform8. We can talk about moving this out to a separate  
> package, and adding it as a "Suggests" for the java-1.6.0-openjdk-devel  
> package. The netbeans-platform8 package adds about 6.0M (not including  
> the small packages it requires. ~1M in total: javahelp2 jna  
> jpackage-utils swing-layout).

So we're adding ~7 MB of requirements to a package that's ~41 MB.  It's
a tough trade-off:  we want ease of installation ("just install this one
package"), full functionality ("look, you also get visualvm!"), and a
small disk footprint.  I tend towards ease of installation but that's
'cause I live where disks and bandwidth are relatively cheap.

Does Sun release the -devel bits of the JDK without NetBeans?  Without
visualvm?  Do most users expect visualvm to be there if they have a JDK?

Andrew



From langel at redhat.com  Fri Oct 31 17:45:06 2008
From: langel at redhat.com (Lillian Angel)
Date: Fri, 31 Oct 2008 13:45:06 -0400
Subject: rawhide report: 20081031 changes
In-Reply-To: <20081031173852.GA3664@redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>	<490B3B9B.5070805@redhat.com>
	<20081031173852.GA3664@redhat.com>
Message-ID: <490B4422.1070205@redhat.com>

Andrew Overholt wrote:
> * Lillian Angel <langel at redhat.com> [2008-10-31 13:08]:
>   
>> Peter Lemenkov wrote:
>>     
>>> So, since now I need to install netbeans-platform8 in order to be able
>>> to compile helloworld.java? It looks for me like one more redunant BR.
>>> Correct me if I wrong.
>>>       
>> Correct. The -devel package now includes visualvm, which depends on  
>> netbeans-platform8. We can talk about moving this out to a separate  
>> package, and adding it as a "Suggests" for the java-1.6.0-openjdk-devel  
>> package. The netbeans-platform8 package adds about 6.0M (not including  
>> the small packages it requires. ~1M in total: javahelp2 jna  
>> jpackage-utils swing-layout).
>>     
>
> So we're adding ~7 MB of requirements to a package that's ~41 MB.  It's
> a tough trade-off:  we want ease of installation ("just install this one
> package"), full functionality ("look, you also get visualvm!"), and a
> small disk footprint.  I tend towards ease of installation but that's
> 'cause I live where disks and bandwidth are relatively cheap.
>
> Does Sun release the -devel bits of the JDK without NetBeans?  
Visualvm is part of Sun's JDK (not the JRE).

> Without
> visualvm?  Do most users expect visualvm to be there if they have a JDK?
>   

AFAIK, yes.


Lillian



From overholt at redhat.com  Fri Oct 31 17:48:27 2008
From: overholt at redhat.com (Andrew Overholt)
Date: Fri, 31 Oct 2008 13:48:27 -0400
Subject: rawhide report: 20081031 changes
In-Reply-To: <490B4422.1070205@redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
	<490B3B9B.5070805@redhat.com> <20081031173852.GA3664@redhat.com>
	<490B4422.1070205@redhat.com>
Message-ID: <20081031174827.GD3664@redhat.com>

* Lillian Angel <langel at redhat.com> [2008-10-31 13:45]:
>> Andrew Overholt wrote:
>> 
>> Does Sun release the -devel bits of the JDK without NetBeans?  
> Visualvm is part of Sun's JDK (not the JRE).

Then I think it should be part of our -devel packages, no?

>> Do most users expect visualvm to be there if they have a JDK?
>
> AFAIK, yes.

Then adding ~17% to the package seems acceptable to me (going on the
assumption that upstream 'added' it, too).

Andrew



From hughsient at gmail.com  Fri Oct 31 18:06:18 2008
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 31 Oct 2008 18:06:18 +0000
Subject: PackageKit 0.3.10 into F9
Message-ID: <1225476378.15633.21.camel@hughsie-laptop>

I'm asking for your opinions as to whether PackageKit 0.3.10 should be
pushed into F9 as an update. 0.3.10 will be released on Monday, and is
much more feature complete and stable than the 0.2.x series. There have
been 10 releases on the 0.3.x codebase in the last three months. 0.3.x
is API and ABI incompatible with 0.2.x and 0.1.x versions, and has been
in rawhide for a few months now.

Uploading 0.3.10 also allows us to build KPackageKit for F9, which is
quite nice to use now. Something for all the KDE people.
gnome-packagekit is also much more user friendly and all the
transactions should be much faster.

If there are any early adopters keen to try a package (please!), can you
please download a automatically generated git-snapshots here
http://www.packagekit.org/packages/ and:

* yum remove PackageKit gnome-packagekit
* rebuild PackageKit-x.srpm
* install PackageKit-x-*.rpm
* rebuild gnome-packagekit-x.srpm
* install gnome-packagekit-x-*.rpm
* reboot

Please send error reports to me, or the PackageKit mailing list.

If there are no user regressions, I'll build this in f9-updates-testing,
and then push it out using bodhi.

Thanks,

Richard.




From dbhole at redhat.com  Fri Oct 31 18:10:24 2008
From: dbhole at redhat.com (Deepak Bhole)
Date: Fri, 31 Oct 2008 14:10:24 -0400
Subject: rawhide report: 20081031 changes
In-Reply-To: <adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
Message-ID: <20081031181024.GB22521@redhat.com>

* Peter Lemenkov <lemenkov at gmail.com> [2008-10-31 12:15]:
> 2008/10/31 Rawhide Report <rawhide at fedoraproject.org>:
> > Compose started at Fri Oct 31 06:01:18 UTC 2008
> >
> > Updated Packages:
> 
> > java-1.6.0-openjdk-1.6.0.0-2b12.fc10
> > ------------------------------------
> > * Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-2b12
> > - Updated icedteasnapshot.
> > - Fixed post scriptlet to remove gcjwebplugin.so.
> > - Updated jvisualvm requirement.
> > - Added build option --with-pkgversion=6b12-Fedora-10
> > - Resolves: rhbz#428503
> > - Resolves: rhbz#251829
> > - Resolves: rhbz#415061
> > - Resolves: rhbz#452188
> >
> > * Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.2.b12
> > - Added netbeans requirement for devel package.
> > - Fixed removal of gcjwebplugin.so link when installing plugin package.
> > - Updated Release.
> > - Resolves: rhbz#468635
> 
> So, since now I need to install netbeans-platform8 in order to be able
> to compile helloworld.java? It looks for me like one more redunant BR.
> Correct me if I wrong.
> 
> 

Since it brings in only the platform and not all of netbeans, I think
it is acceptable. 6MB is not _that_ much of a download IMO...

Additionally, since the upstream jdk provides VisualVN, I would normally
expect it to be there in the -devel package.

Deepak

> -- 
> With best regards!
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From debarshi.ray at gmail.com  Fri Oct 31 18:22:01 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 31 Oct 2008 23:52:01 +0530
Subject: PackageKit 0.3.10 into F9
In-Reply-To: <1225476378.15633.21.camel@hughsie-laptop>
References: <1225476378.15633.21.camel@hughsie-laptop>
Message-ID: <3170f42f0810311122l5317d775l5cb25b4b2c0ed3d@mail.gmail.com>

> If there are any early adopters keen to try a package (please!), can you
> please download a automatically generated git-snapshots here
> http://www.packagekit.org/packages/ and:
>
> * yum remove PackageKit gnome-packagekit
> * rebuild PackageKit-x.srpm
> * install PackageKit-x-*.rpm
> * rebuild gnome-packagekit-x.srpm
> * install gnome-packagekit-x-*.rpm
> * reboot
>
> Please send error reports to me, or the PackageKit mailing list.

I am already running yesterdays' (30th Oct) snapshot and I find that
the System -> Administration -> Add/Remove Software icon is missing.

These are the packages that I have installed:
PackageKit-yum-plugin-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-browser-plugin-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-yum-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-glib-devel-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-glib-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-cron-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-udev-helper-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-gstreamer-plugin-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-backend-devel-0.3.10-0.1062.20081030git.fc9.x86_64
PackageKit-docs-0.3.10-0.1062.20081030git.fc9.x86_64
gnome-packagekit-extra-0.3.10-0.904.20081030git.fc9.x86_64
gnome-packagekit-0.3.10-0.904.20081030git.fc9.x86_64

Cheerio,
Debarshi



From billcrawford1970 at gmail.com  Fri Oct 31 17:45:33 2008
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Fri, 31 Oct 2008 17:45:33 +0000
Subject: rawhide report: 20081031 changes
In-Reply-To: <490B4422.1070205@redhat.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<20081031173852.GA3664@redhat.com> <490B4422.1070205@redhat.com>
Message-ID: <200810311745.33433.billcrawford1970@gmail.com>

On Friday 31 October 2008 17:45:06 Lillian Angel wrote:
> Andrew Overholt wrote:
...
> > Does Sun release the -devel bits of the JDK without NetBeans?
                                            ^^^
>
> Visualvm is part of Sun's JDK (not the JRE).

Your point?



From Victor.Vasilyev at Sun.COM  Fri Oct 31 19:17:10 2008
From: Victor.Vasilyev at Sun.COM (Victor Vasilyev)
Date: Fri, 31 Oct 2008 22:17:10 +0300
Subject: rawhide report: 20081031 changes
In-Reply-To: <adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<adf480660810310904p7042ec95y4ea1901a70fa5fc9@mail.gmail.com>
Message-ID: <490B59B6.1080402@sun.com>

Peter,

Peter Lemenkov wrote:
> 2008/10/31 Rawhide Report <rawhide at fedoraproject.org>:
>   
>> java-1.6.0-openjdk-1.6.0.0-2b12.fc10
>> ------------------------------------
>> ...
>> * Mon Oct 27 18:00:00 2008 Lillian Angel <langel at redhat.com> - 1:1.6.0-1.2.b12
>> - Added netbeans requirement for devel package.
>> ...
> So, since now I need to install netbeans-platform8 in order to be able
> to compile helloworld.java? It looks for me like one more redunant BR.
> Correct me if I wrong
FYI Java VisualVM was first bundled with the the Java platform, Standard 
Edition (Java SE) in JDK version 6, update 7. [1]

IMHO
1) Java VisualVM will be very useful at the development time, e.g. if 
your helloworld is the multithread remote Java application or Web 
service :-)
2) The NetBeans platform [2] is not bad platform to support a tool for 
data visualization.
BTW, there is a big collection of tools [3] usually used by Java 
developers that are sharing this 6M byte-code of the NetBeans platform.
So, I think, it is not big overhead.

[1] http://java.sun.com/javase/6/docs/technotes/guides/visualvm/index.html
[2] http://www.netbeans.org/features/platform/index.html
[3] http://plugins.netbeans.org/PluginPortal/

WBR,
Victor Vasilyev



From overholt at redhat.com  Fri Oct 31 19:21:44 2008
From: overholt at redhat.com (Andrew Overholt)
Date: Fri, 31 Oct 2008 15:21:44 -0400
Subject: rawhide report: 20081031 changes
In-Reply-To: <200810311745.33433.billcrawford1970@gmail.com>
References: <20081031145123.2D23E1F824C@releng2.fedora.phx.redhat.com>
	<20081031173852.GA3664@redhat.com> <490B4422.1070205@redhat.com>
	<200810311745.33433.billcrawford1970@gmail.com>
Message-ID: <20081031192144.GA4966@redhat.com>

* Bill Crawford <billcrawford1970 at gmail.com> [2008-10-31 15:14]:
> On Friday 31 October 2008 17:45:06 Lillian Angel wrote:
> > Andrew Overholt wrote:
> ...
> > > Does Sun release the -devel bits of the JDK without NetBeans?
>                                             ^^^
> >
> > Visualvm is part of Sun's JDK (not the JRE).
> 
> Your point?

Our -devel tries to match the JDK so we should therefore have visualvm
in our -devel package (and its dependencies as dependencies of -devel).

Andrew



From lesmikesell at gmail.com  Fri Oct 31 19:44:08 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 31 Oct 2008 14:44:08 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <ti5rt5xmmo.ln2@ppp1053.in.ipex.cz>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<20081029212536.GG25197@nostromo.devel.redhat.com>	<80d7e4090810291913u14db67b2m74fbfcc9afcc2d32@mail.gmail.com>	<20081030044536.GA10407@jadzia.bu.edu>
	<490940C6.3070701@gmail.com> <ti5rt5xmmo.ln2@ppp1053.in.ipex.cz>
Message-ID: <490B6008.8060800@gmail.com>

Matej Cepl wrote:
> On 2008-10-30, 05:06 GMT, Les Mikesell wrote:
>> Doesn't fit with the code. 7.3 was the last in the 
>> 'increasingly reliable' series.  8 and 9 each introduced new 
>> breakage that was never fixed.
> 
> I was in the Debian-land then already, what were the problems?  
> (you mean wonderful new gcc, which required kernel-only 
> compiler?).

I've tried to block the most painful details from memory...  But aside 
from the gcc and gnome desktop stuff, the killer for me was that they 
had finally, finally gotten the compile options right for apache and 
mod_perl to work as shipped in a 7.3 update - and broke it again in 8 
and never fixed it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From debarshi.ray at gmail.com  Fri Oct 31 19:46:06 2008
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sat, 1 Nov 2008 01:16:06 +0530
Subject: Dia has .la files
Message-ID: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>

I noticed that the dia package has %{_libdir}/%{name}/*.la files. Any
particular reason for them to be there? Doesn't guidelines ask us to
remove them?

Cheerio,
Debarshi



From walters at verbum.org  Fri Oct 31 19:55:33 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 31 Oct 2008 15:55:33 -0400
Subject: Dia has .la files
In-Reply-To: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
Message-ID: <faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>

On Fri, Oct 31, 2008 at 3:46 PM, Debarshi Ray <debarshi.ray at gmail.com> wrote:
> I noticed that the dia package has %{_libdir}/%{name}/*.la files. Any
> particular reason for them to be there? Doesn't guidelines ask us to
> remove them?

Yes, please remove them.  We should not encourage the libtool agenda
to redefine how shared libraries work on our platform.



From choeger at cs.tu-berlin.de  Fri Oct 31 20:19:38 2008
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Fri, 31 Oct 2008 21:19:38 +0100
Subject: rawhide netbook resume with xorg intel driver?
In-Reply-To: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
References: <5256d0b0810301251t56a4e35xeaefb3437e6fc16c@mail.gmail.com>
Message-ID: <1225484378.4755.3.camel@choeger6>

I can confirm that behavior on my thinkpad R61 running f9.

from lscpi:
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev
0c)

kernel: kernel-2.6.26.6-79.fc9.i686
xorg-x11-server-Xorg-1.5.0-2.fc9.i386

please Note that this happens randomly.

regards

Christoph


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081031/8678fcf7/attachment.sig>

From notting at redhat.com  Fri Oct 31 20:20:54 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 31 Oct 2008 16:20:54 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
Message-ID: <20081031202054.GB8150@nostromo.devel.redhat.com>

Dan Nicholson (dbn.lists at gmail.com) said: 
> Oh, very good point. Let's try again. In the attached patch, all the
> logic is handled in event.d/prefdm. In particular, when we want to
> spawn a getty on tty1, we use initctl to emit a new event
> "tty1-getty". This also includes some logic to try to make sure that
> the display manager is gdm before assuming that it will be able to
> start on tty1.
> 
> What do you think?

It's still problematic in that whichever vt you run telinit from will
get gdm, which may not be tty1. (Also, it's just getting a little complex
overall.)

There's still the issue of what to do with respect to stopping sometihng
on a current tty that GDM is using, if there is something there.

Bill



From lesmikesell at gmail.com  Fri Oct 31 20:44:40 2008
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 31 Oct 2008 15:44:40 -0500
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081031202054.GB8150@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>	<20081029215123.GL25197@nostromo.devel.redhat.com>	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>	<20081030154405.GA12240@nostromo.devel.redhat.com>	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>	<20081030202920.GB31153@nostromo.devel.redhat.com>	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
Message-ID: <490B6E38.2000108@gmail.com>

Bill Nottingham wrote:
> Dan Nicholson (dbn.lists at gmail.com) said: 
>> Oh, very good point. Let's try again. In the attached patch, all the
>> logic is handled in event.d/prefdm. In particular, when we want to
>> spawn a getty on tty1, we use initctl to emit a new event
>> "tty1-getty". This also includes some logic to try to make sure that
>> the display manager is gdm before assuming that it will be able to
>> start on tty1.
>>
>> What do you think?
> 
> It's still problematic in that whichever vt you run telinit from will
> get gdm, which may not be tty1. (Also, it's just getting a little complex
> overall.)

What happens if you aren't on a vt at all (ssh, remote X, vncserver, 
freenx, etc.?).

-- 
   Les Mikesell
     lesmikesell at gmail.com



From notting at redhat.com  Fri Oct 31 20:46:50 2008
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 31 Oct 2008 16:46:50 -0400
Subject: Reasons to preseve X on tty7
In-Reply-To: <490B6E38.2000108@gmail.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
	<490B6E38.2000108@gmail.com>
Message-ID: <20081031204650.GC8150@nostromo.devel.redhat.com>

Les Mikesell (lesmikesell at gmail.com) said: 
>> It's still problematic in that whichever vt you run telinit from will
>> get gdm, which may not be tty1. (Also, it's just getting a little complex
>> overall.)
>
> What happens if you aren't on a vt at all (ssh, remote X, vncserver,  
> freenx, etc.?).

It's started by init, which is on /dev/console, which maps (more or less)
to tty0, 'the current tty'. So it will start on whichever VT happens
to be focused at the time.

Bill



From dbn.lists at gmail.com  Fri Oct 31 21:01:13 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 31 Oct 2008 14:01:13 -0700
Subject: Reasons to preseve X on tty7
In-Reply-To: <20081031202054.GB8150@nostromo.devel.redhat.com>
References: <1225258594.3742.73.camel@mentor.gurulabs.com>
	<91705d080810290706h3c7f2a33q5dfb37f7ce55a73e@mail.gmail.com>
	<20081029215123.GL25197@nostromo.devel.redhat.com>
	<91705d080810291533o7a7f3a5dl1cbcbef4fa3498c8@mail.gmail.com>
	<20081030154405.GA12240@nostromo.devel.redhat.com>
	<91705d080810301155q487a968qc91be14ecdc6909d@mail.gmail.com>
	<20081030202920.GB31153@nostromo.devel.redhat.com>
	<91705d080810301410h415f6e4fj6fbf881eada2f69d@mail.gmail.com>
	<20081031202054.GB8150@nostromo.devel.redhat.com>
Message-ID: <91705d080810311401gdc85e93i1bd182ce56976bb3@mail.gmail.com>

On Fri, Oct 31, 2008 at 1:20 PM, Bill Nottingham <notting at redhat.com> wrote:
> Dan Nicholson (dbn.lists at gmail.com) said:
>> Oh, very good point. Let's try again. In the attached patch, all the
>> logic is handled in event.d/prefdm. In particular, when we want to
>> spawn a getty on tty1, we use initctl to emit a new event
>> "tty1-getty". This also includes some logic to try to make sure that
>> the display manager is gdm before assuming that it will be able to
>> start on tty1.
>>
>> What do you think?
>
> It's still problematic in that whichever vt you run telinit from will
> get gdm, which may not be tty1. (Also, it's just getting a little complex
> overall.)

I think this case is handled. Once you run telinit, runlevel will not
return "N" as the first setting and the force-vt logic is skipped. gdm
will start X on a new vt. And `telinit 5' from runlevel 5 is a no-op,
I believe.

It is certainly getting complex, but the current setup is not robust.
Even if you take away the "I always want getty on tty1" pref, how do
you handle the case when the display manager is not gdm? Just have
nothing running on tty1? Because, init currently will not start a
getty on tty1 in runlevel 5 in any situation.

> There's still the issue of what to do with respect to stopping sometihng
> on a current tty that GDM is using, if there is something there.

You mean the `telinit 3' from runlevel 5 case? I'm not following exactly.

--
Dan



From loganjerry at gmail.com  Fri Oct 31 21:12:49 2008
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 31 Oct 2008 15:12:49 -0600
Subject: Dia has .la files
In-Reply-To: <faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
Message-ID: <870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>

On Fri, Oct 31, 2008 at 1:55 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, Oct 31, 2008 at 3:46 PM, Debarshi Ray <debarshi.ray at gmail.com> wrote:
>> I noticed that the dia package has %{_libdir}/%{name}/*.la files. Any
>> particular reason for them to be there? Doesn't guidelines ask us to
>> remove them?
>
> Yes, please remove them.  We should not encourage the libtool agenda
> to redefine how shared libraries work on our platform.

I've got quite a collection of .la files under /usr/lib64 on my Fedora
9 x86_64 machine.  All of the following packages contain at least one
.la file:

alsa-lib
apr-devel
apr-util-devel
arts
banshee
bluez-utils
brasero
db4-devel
db4-java
db4-tcl
directfb
gamin-python
gdesklets
ghostscript-devel
gnome-bluetooth-libs
GraphicsMagick
gtkglextmm-devel
gutenprint
hplip
ImageMagick
imlib2
imlib2-devel
libesmtp
libieee1284-devel
libstatgrab-devel
libtool-ltdl-devel
libxml2-python
nfs-utils-lib
opensp-devel
pinball
planner
subversion-devel
subversion-javahl

-- 
Jerry James
http://loganjerry.googlepages.com/



From walters at verbum.org  Fri Oct 31 21:21:55 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 31 Oct 2008 17:21:55 -0400
Subject: Dia has .la files
In-Reply-To: <870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
Message-ID: <faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>

On Fri, Oct 31, 2008 at 5:12 PM, Jerry James <loganjerry at gmail.com> wrote:
> On Fri, Oct 31, 2008 at 1:55 PM, Colin Walters <walters at verbum.org> wrote:
>> On Fri, Oct 31, 2008 at 3:46 PM, Debarshi Ray <debarshi.ray at gmail.com> wrote:
>>> I noticed that the dia package has %{_libdir}/%{name}/*.la files. Any
>>> particular reason for them to be there? Doesn't guidelines ask us to
>>> remove them?
>>
>> Yes, please remove them.  We should not encourage the libtool agenda
>> to redefine how shared libraries work on our platform.
>
> I've got quite a collection of .la files under /usr/lib64 on my Fedora
> 9 x86_64 machine.  All of the following packages contain at least one
> .la file:

Really we need a post-build (BRP) hook in RPM to nuke them instead of
copy&paste of rm into spec files.

The ideal of course would be to convince libtool upstream that trying
to change the entire world to use libtool makes a lot less sense than
having those few modules that interact with shared libraries have
platform-specific code.

-- Colin, who spent too much time this week battling libtool while
working on http://live.gnome.org/GObjectIntrospection/



From loganjerry at gmail.com  Fri Oct 31 21:12:49 2008
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 31 Oct 2008 15:12:49 -0600
Subject: Dia has .la files
In-Reply-To: <faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
Message-ID: <870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>

On Fri, Oct 31, 2008 at 1:55 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, Oct 31, 2008 at 3:46 PM, Debarshi Ray <debarshi.ray at gmail.com> wrote:
>> I noticed that the dia package has %{_libdir}/%{name}/*.la files. Any
>> particular reason for them to be there? Doesn't guidelines ask us to
>> remove them?
>
> Yes, please remove them.  We should not encourage the libtool agenda
> to redefine how shared libraries work on our platform.

I've got quite a collection of .la files under /usr/lib64 on my Fedora
9 x86_64 machine.  All of the following packages contain at least one
.la file:

alsa-lib
apr-devel
apr-util-devel
arts
banshee
bluez-utils
brasero
db4-devel
db4-java
db4-tcl
directfb
gamin-python
gdesklets
ghostscript-devel
gnome-bluetooth-libs
GraphicsMagick
gtkglextmm-devel
gutenprint
hplip
ImageMagick
imlib2
imlib2-devel
libesmtp
libieee1284-devel
libstatgrab-devel
libtool-ltdl-devel
libxml2-python
nfs-utils-lib
opensp-devel
pinball
planner
subversion-devel
subversion-javahl

-- 
Jerry James
http://loganjerry.googlepages.com/



From joshuacov at googlemail.com  Fri Oct 31 22:25:51 2008
From: joshuacov at googlemail.com (Joshua C.)
Date: Fri, 31 Oct 2008 23:25:51 +0100
Subject: Strange ext3 problem
Message-ID: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>

I put this for discussion here
http://forums.fedoraforum.org/showthread.php?t=202573 and got no
helpful comments, so i put it here on the devel list.

Short description:

When copying and moving files bigger than ~ 100 mb I get different
sha1 sums between the copy and the original file. Once I issued the
sha1 sommand 2 consequitive times on one and the same file and got 2
(!!!) different results. This is impossible!

I tested the hdd with smartmontools (short and long tests) and got no
errors of any kind. then used fsck and e2fsck on the partition and
they corrected something. I thought the problem was gone but here it
happens again.

Maybe I should file a bug report. but against what? ext3? Any ideas
what this can be?

--joshua



From orcanbahri at yahoo.com  Fri Oct 31 23:11:48 2008
From: orcanbahri at yahoo.com (Orcan Ogetbil)
Date: Fri, 31 Oct 2008 16:11:48 -0700 (PDT)
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <b399909d0810160539u6fd8a49u272f3ff5b1e1ca32@mail.gmail.com>
Message-ID: <528188.21827.qm@web32801.mail.mud.yahoo.com>

What is the status of this project? Did anyone started out writing some code? I want to contribute to this. Is there a webpage?

My opinion on this idea is, we should first write a script that displays 3 different kind of outputs:

1- Pure automatic checks: sha1sums, %files etc. -> Display results
2- Semi-automatic checks: For instance, the script will check for static libraries in the build. -> Display results (If there are static libraries then it will warn the reviewer so he can check for the necessity of them.)
3- Purely manual checks: Not everything in the guidelines is easy to implement. Hence after the script is done, it will tell the reviewer what else needs to be checked manually.

As time goes more features can be implemented and more items from 3 can be shifted into 1 or 2. We will need to build a powerful parser. I think some code can be borrowed from rpmlint.


-oget


      



From dbn.lists at gmail.com  Fri Oct 31 23:15:22 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 31 Oct 2008 16:15:22 -0700
Subject: Dia has .la files
In-Reply-To: <faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
Message-ID: <91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>

On Fri, Oct 31, 2008 at 2:21 PM, Colin Walters <walters at verbum.org> wrote:
>
> The ideal of course would be to convince libtool upstream that trying
> to change the entire world to use libtool makes a lot less sense than
> having those few modules that interact with shared libraries have
> platform-specific code.

The libtool developers understand that the .la files aren't needed in
normal operation. The reason that they insist on keeping them is so
that `make uninstall' works since the .la files are the only place
that store information about the actual libraries (.so + links vs. .a,
etc.).

--
Dan



From walters at verbum.org  Fri Oct 31 23:17:16 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 31 Oct 2008 19:17:16 -0400
Subject: Dia has .la files
In-Reply-To: <91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
Message-ID: <faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>

On Fri, Oct 31, 2008 at 7:15 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Fri, Oct 31, 2008 at 2:21 PM, Colin Walters <walters at verbum.org> wrote:
>>
>> The ideal of course would be to convince libtool upstream that trying
>> to change the entire world to use libtool makes a lot less sense than
>> having those few modules that interact with shared libraries have
>> platform-specific code.
>
> The libtool developers understand that the .la files aren't needed in
> normal operation. The reason that they insist on keeping them is so
> that `make uninstall' works since the .la files are the only place
> that store information about the actual libraries (.so + links vs. .a,
> etc.).

Right - we have a "make uninstall", it's called "rpm -e".



From sundaram at fedoraproject.org  Fri Oct 31 23:20:28 2008
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 01 Nov 2008 04:50:28 +0530
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <528188.21827.qm@web32801.mail.mud.yahoo.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
Message-ID: <490B92BC.6080804@fedoraproject.org>

Orcan Ogetbil wrote:
> What is the status of this project? Did anyone started out writing some code? I want to contribute to this. Is there a webpage?

Refer

https://fedorahosted.org/review-o-matic

Yes, there is some code.

Rahul



From jonathan at jonmasters.org  Fri Oct 31 23:21:42 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Sat, 01 Nov 2008 00:21:42 +0100
Subject: Fedora 11: moving to posix file capabilities?
In-Reply-To: <faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
References: <alpine.DEB.1.10.0810291223570.17696@gotcha.dreamhost.com>
	<200810291513.11983.sgrubb@redhat.com>
	<faa16b610810291225k4f77afc2o7d7dbb49f9948c63@mail.gmail.com>
	<200810291640.00051.sgrubb@redhat.com>
	<faa16b610810291352p5b5e9002n2af909ab1ffe1cd2@mail.gmail.com>
Message-ID: <1225495302.9931.21.camel@jcmlaptop.bos.redhat.com>

On Wed, 2008-10-29 at 16:52 -0400, Colin Walters wrote:
> On Wed, Oct 29, 2008 at 4:39 PM, Steve Grubb <sgrubb at redhat.com> wrote:

> > No this is about PolicyKit being another MAC system that needs configuring.
> 
> Of course it would be ideal if there were One True MAC system, but
> AFAIK the story on SELinux is still that the system must be secure
> without it, and other vendors that we care about from the desktop
> perspective (personally I just care about Ubuntu and OpenSolaris)
> haven't yet finished integrating it.

Of course just so it's been said...setting capabilities on binaries has
little to do (or should have *very* little to do) with SELinux. Ever :)

Personally I think switching to fully POSIX file caps is a wonderful
idea for sometime around 2010 or a bit later, but it's not practical for
regular system utilities that might be sitting on older filesystems to
do this today. Root NFS will break, many custom spins, just a lot of
stuff is going to be very unhappy if we start doing this.

Jon.




From benny+usenet at amorsen.dk  Fri Oct 31 23:23:17 2008
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sat, 01 Nov 2008 00:23:17 +0100
Subject: Strange ext3 problem
In-Reply-To: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
	(Joshua C.'s message of "Fri\, 31 Oct 2008 23\:25\:51 +0100")
References: <5f6f8c5f0810311525s4a1ddd31y49527359340190b6@mail.gmail.com>
Message-ID: <m31vxwqrh6.fsf@ursa.amorsen.dk>

"Joshua C." <joshuacov at googlemail.com> writes:

> I tested the hdd with smartmontools (short and long tests) and got no
> errors of any kind. then used fsck and e2fsck on the partition and
> they corrected something. I thought the problem was gone but here it
> happens again.

Memory error. Or CPU. Try booting into memtest86; I believe the Fedora
iso's offer that. memtest86 isn't perfect though, your PC could still
have a problem even if memtest86 says OK (after a few days of testing).


/Benny



From ivazqueznet at gmail.com  Fri Oct 31 23:24:06 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 31 Oct 2008 19:24:06 -0400
Subject: review-o-matic : Fedora package review helper
In-Reply-To: <528188.21827.qm@web32801.mail.mud.yahoo.com>
References: <528188.21827.qm@web32801.mail.mud.yahoo.com>
Message-ID: <1225495446.25414.377.camel@ignacio.lan>

On Fri, 2008-10-31 at 16:11 -0700, Orcan Ogetbil wrote:
> I think some code can be borrowed from rpmlint.

Borrowing code is a losing proposition. What we need is for the main
rpmlint script to be refactored so that we can call it with a filename.

-- 
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/20081031/e608e8d9/attachment.sig>

From dbn.lists at gmail.com  Fri Oct 31 23:24:32 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Fri, 31 Oct 2008 16:24:32 -0700
Subject: Dia has .la files
In-Reply-To: <faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
	<faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
Message-ID: <91705d080810311624tdfd2f91x2b0e8fc15edfd099@mail.gmail.com>

On Fri, Oct 31, 2008 at 4:17 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, Oct 31, 2008 at 7:15 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> On Fri, Oct 31, 2008 at 2:21 PM, Colin Walters <walters at verbum.org> wrote:
>>>
>>> The ideal of course would be to convince libtool upstream that trying
>>> to change the entire world to use libtool makes a lot less sense than
>>> having those few modules that interact with shared libraries have
>>> platform-specific code.
>>
>> The libtool developers understand that the .la files aren't needed in
>> normal operation. The reason that they insist on keeping them is so
>> that `make uninstall' works since the .la files are the only place
>> that store information about the actual libraries (.so + links vs. .a,
>> etc.).
>
> Right - we have a "make uninstall", it's called "rpm -e".

OK, now convince the libtool developers to break everyone's `make
distcheck'. Might be tough. But I certainly would support a way to opt
out of that situation at build time. Something like:

export LIBTOOLFLAGS="--no-installed-la-files"

--
Dan



From ivazqueznet at gmail.com  Fri Oct 31 23:28:40 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 31 Oct 2008 19:28:40 -0400
Subject: Fedora on EEE?
In-Reply-To: <gef7ir$fm9$1@ger.gmane.org>
References: <geclck$mlc$2@ger.gmane.org>
	<d25f375f0810301702p2ab95cdfla61d6a552555090e@mail.gmail.com>
	<gef7ir$fm9$1@ger.gmane.org>
Message-ID: <1225495720.25414.381.camel@ignacio.lan>

On Fri, 2008-10-31 at 10:17 -0500, Matthew Woehlke wrote:
> Pavel Shevchuk wrote:
> > Synaptics driver has multitouch for years. I used macbook-style two
> > finger scroll 3 years ago on my acer laptop. Check "man synaptics"

> Ok, so it's not new to Acer/Xandros, just that they're using the right 
> driver? Nice to know.

No, it's that they've configured it the right way. Look for
VertTwoFingerScroll, HorizTwoFingerScroll, TapButton2, and TapButton3 in
the synaptics man page.

-- 
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/20081031/82f72df3/attachment.sig>

From stlwrt at gmail.com  Fri Oct 31 23:31:05 2008
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Sat, 1 Nov 2008 01:31:05 +0200
Subject: Fedora on EEE?
In-Reply-To: <1225495720.25414.381.camel@ignacio.lan>
References: <geclck$mlc$2@ger.gmane.org>
	<d25f375f0810301702p2ab95cdfla61d6a552555090e@mail.gmail.com>
	<gef7ir$fm9$1@ger.gmane.org> <1225495720.25414.381.camel@ignacio.lan>
Message-ID: <d25f375f0810311631pebc4408p69555bc4767ea3d4@mail.gmail.com>

2008/11/1 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Fri, 2008-10-31 at 10:17 -0500, Matthew Woehlke wrote:
>> Pavel Shevchuk wrote:
>> > Synaptics driver has multitouch for years. I used macbook-style two
>> > finger scroll 3 years ago on my acer laptop. Check "man synaptics"
>
>> Ok, so it's not new to Acer/Xandros, just that they're using the right
>> driver? Nice to know.
>
> No, it's that they've configured it the right way. Look for
> VertTwoFingerScroll, HorizTwoFingerScroll, TapButton2, and TapButton3 in
> the synaptics man page.
>
They also implemented pinch zoom in image viewer, i guess in very
hackish way, just to show off


-- 
http://scwlab.com



From walters at verbum.org  Fri Oct 31 23:32:18 2008
From: walters at verbum.org (Colin Walters)
Date: Fri, 31 Oct 2008 19:32:18 -0400
Subject: Dia has .la files
In-Reply-To: <91705d080810311624tdfd2f91x2b0e8fc15edfd099@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
	<faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
	<91705d080810311624tdfd2f91x2b0e8fc15edfd099@mail.gmail.com>
Message-ID: <faa16b610810311632w71f4937evcc494ff88642005a@mail.gmail.com>

On Fri, Oct 31, 2008 at 7:24 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>
> OK, now convince the libtool developers to break everyone's `make
> distcheck'.

Or alternatively convince the automake people that it shouldn't be in
the business of software lifecycle management (make uninstall) any
more than people should be coding/overriding build systems (make;make
install) inside RPM spec files.  This seems possible; probably worth
trying to at least have an environment variable AUTOMAKE_OPTIONS =
i-dont-need-uninstall.



From denis at poolshark.org  Fri Oct 31 23:33:16 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 01 Nov 2008 00:33:16 +0100
Subject: Dia has .la files
In-Reply-To: <faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>	<91705d080810311615u7a00ddai936c78e4d6de0119@mail.gmail.com>
	<faa16b610810311617v5ae4d6e4ife8e5368073ad563@mail.gmail.com>
Message-ID: <490B95BC.9000404@poolshark.org>

Colin Walters wrote:
> On Fri, Oct 31, 2008 at 7:15 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> On Fri, Oct 31, 2008 at 2:21 PM, Colin Walters <walters at verbum.org> wrote:
>>> The ideal of course would be to convince libtool upstream that trying
>>> to change the entire world to use libtool makes a lot less sense than
>>> having those few modules that interact with shared libraries have
>>> platform-specific code.
>> The libtool developers understand that the .la files aren't needed in
>> normal operation. The reason that they insist on keeping them is so
>> that `make uninstall' works since the .la files are the only place
>> that store information about the actual libraries (.so + links vs. .a,
>> etc.).
> 
> Right - we have a "make uninstall", it's called "rpm -e".

Was a libtool fork ever attempted ?



From denis at poolshark.org  Fri Oct 31 23:34:11 2008
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 01 Nov 2008 00:34:11 +0100
Subject: Dia has .la files
In-Reply-To: <870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
Message-ID: <490B95F3.9080509@poolshark.org>

Jerry James wrote:
> On Fri, Oct 31, 2008 at 1:55 PM, Colin Walters <walters at verbum.org> wrote:
>> On Fri, Oct 31, 2008 at 3:46 PM, Debarshi Ray <debarshi.ray at gmail.com> wrote:
>>> I noticed that the dia package has %{_libdir}/%{name}/*.la files. Any
>>> particular reason for them to be there? Doesn't guidelines ask us to
>>> remove them?
>> Yes, please remove them.  We should not encourage the libtool agenda
>> to redefine how shared libraries work on our platform.
> 
> I've got quite a collection of .la files under /usr/lib64 on my Fedora
> 9 x86_64 machine.  All of the following packages contain at least one
> .la file:
>
[cut]
> brasero
[cut]

Just fixed it in CVS.



From pertusus at free.fr  Fri Oct 31 21:30:59 2008
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 31 Oct 2008 22:30:59 +0100
Subject: Dia has .la files
In-Reply-To: <faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
References: <3170f42f0810311246g8c2e8f8mff12286a1a71c171@mail.gmail.com>
	<faa16b610810311255h2d48d7cal302456dfda5e1c85@mail.gmail.com>
	<870180fe0810311412s327c80bcq12a0f2df726d3bd9@mail.gmail.com>
	<faa16b610810311421m56051690ia378ebde7ab693f8@mail.gmail.com>
Message-ID: <20081031213059.GA2669@free.fr>

On Fri, Oct 31, 2008 at 05:21:55PM -0400, Colin Walters wrote:
> 
> Really we need a post-build (BRP) hook in RPM to nuke them instead of
> copy&paste of rm into spec files.
> 
> The ideal of course would be to convince libtool upstream that trying
> to change the entire world to use libtool makes a lot less sense than
> having those few modules that interact with shared libraries have
> platform-specific code.

There are still some (rare) cases that need the .la files. Maybe not in
%_libdir, but I don't think this is right to do this change in rpm
%scripts, better fix libtool.

--
Pat