From wart at kobold.org  Wed Mar  1 00:31:06 2006
From: wart at kobold.org (Michael Thomas)
Date: Tue, 28 Feb 2006 16:31:06 -0800
Subject: games user and group
Message-ID: <4404EB4A.40304@kobold.org>

I've got a few questions regarding the use of the 'games' user and group
for game packages.  The resulting recommended practices will be posted
to the Extras/SIGs/Games wiki page.

Daemon processes
================
Some games such as wesnoth and xpilot-ng come with server daemons.  I
see three choices for the owner of these daemon processes:

1) root (ick!)
2) Allocate a separate '<gamename>' user for each package/daemon
3) Piggyback on the 'games' user

My preference would be #3.  Are there any drawbacks to reusing the
'games' user to run various game daemons?

Scoreboard files
================
Two packages that I recently submitted for review ('rogue' and 'ularn')
use the 'games' group and a setgid executable so that all users have
access to the shared scoreboard file.  Are there any security issues
that we need to be aware of when using setgid games?

File ownership
==============
Almost every package that I see in FE uses %defattr(-,root,root,-).  Is
there any reason why we shouldn't be using %defattr(-,games,games,-) for
game packages (including documentation, manpages and such)?

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

From louisg00 at bellsouth.net  Wed Mar  1 00:35:20 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Tue, 28 Feb 2006 19:35:20 -0500
Subject: glxgears
Message-ID: <1141173320.23703.2.camel@soncomputer>

Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
think it is actually slower.

-Thanks



From alan at clueserver.org  Wed Mar  1 00:52:03 2006
From: alan at clueserver.org (alan)
Date: Tue, 28 Feb 2006 16:52:03 -0800 (PST)
Subject: glxgears
In-Reply-To: <1141173320.23703.2.camel@soncomputer>
References: <1141173320.23703.2.camel@soncomputer>
Message-ID: <Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>

On Tue, 28 Feb 2006, Louis E Garcia II wrote:

> Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
> think it is actually slower.

glx-utils

I have stopped using ati due to support issues.  nVIDIA may have closed 
source drivers, but they have at least supported everything with them. 
(ATI's support with their closed source driver depends on picking the 
right card.)

-- 
"George W. Bush -- Bringing back the Sixties one Nixon at a time."



From hughsient at gmail.com  Wed Mar  1 00:57:37 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 01 Mar 2006 00:57:37 +0000
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
Message-ID: <1141174657.19512.3.camel@localhost.localdomain>

On Tue, 2006-02-28 at 16:52 -0800, alan wrote:
> On Tue, 28 Feb 2006, Louis E Garcia II wrote:
> 
> > Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
> > think it is actually slower.
> 
> glx-utils
> 
> I have stopped using ati due to support issues.  nVIDIA may have closed 
> source drivers, but they have at least supported everything with them. 
> (ATI's support with their closed source driver depends on picking the 
> right card.)

So if I was buying a new laptop sometime soonish, what chipset is best
for all this new accelerated X stuff?

ati seems to not care about Linux, and I've heard bad things about
nvidia. I don't do games, so 3D isn't that important.

Thanks for any help,

Richard.



From p-danlu at ssl.fujitsu.com  Wed Mar  1 01:07:14 2006
From: p-danlu at ssl.fujitsu.com (LU)
Date: Wed, 01 Mar 2006 10:07:14 +0900
Subject: dmraid and mkinitrd
In-Reply-To: <20060228140957.EFD6.P-DANLU@ssl.fujitsu.com>
References: <1141018018.3592.11.camel@mentorng.gurulabs.com>
	<20060228140957.EFD6.P-DANLU@ssl.fujitsu.com>
Message-ID: <20060301100400.1CFD.P-DANLU@ssl.fujitsu.com>


I'm thinking that the files under /usr/include is too old.
Today will try again.

Lu.


On Tue, 28 Feb 2006 14:44:41 +0900
LU <p-danlu at ssl.fujitsu.com> wrote:

?> Hi,
?> ?
?> I'm SORRY about it might be irrelevant to this thread,
?> I'm working on Momonga-linux (http://www.momonga-linux.org/index.html.en) 
?> and tried to import the mkinitrd from fedora-devel.
?> 
?> When I did make or rebuild the src of mkinitrd-5.0.28,
?> I got such error-messages:
?> 
?> ----------------------- from here ----------------------------------
?> 
?> # uname -a
?> Linux momo.local 2.6.10-36m #1 Fri Apr 22 18:38:29 JST 2005 i686 i686 i386 GNU/Linux
?> # LANG=C rpmbuild -bb mkinitrd.spec
?> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.55369
?> + umask 022
?> + cd /usr/src/momonga/BUILD
?> + set --
?> + '[' 0 -gt 0 ']'
?> + cd /usr/src/momonga/BUILD
?> + rm -rf mkinitrd-5.0.28
?> + /usr/bin/bzip2 -dc /usr/src/momonga/SOURCES/mkinitrd-5.0.28.tar.bz2
?> + tar -xf -
?> + STATUS=0
?> + '[' 0 -ne 0 ']'
?> + cd mkinitrd-5.0.28
?> + echo 'Patch #100 (mkinitrd-5.0.28-momonga.patch):'
?> Patch #100 (mkinitrd-5.0.28-momonga.patch):
?> + patch -p1 -b --suffix .momonga~ -s
?> + echo 'Patch #105 (mkinitrd-5.0.28-insmod.static.old.patch):'
?> Patch #105 (mkinitrd-5.0.28-insmod.static.old.patch):
?> + patch -p1 -b --suffix .insmod.static.old~ -s
?> + exit 0
?> Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.7114
?> + umask 022
?> + cd /usr/src/momonga/BUILD
?> + cd mkinitrd-5.0.28
?> + make
?> make -C nash all
?> make[1]: Entering directory `/usr/src/momonga/BUILD/mkinitrd-5.0.28/nash'
?> making /usr/src/momonga/BUILD/mkinitrd-5.0.28/nash/version.h
?> for n in ; do make -C $n all ; done
?> gcc -Wall -Werror -g -D_FORTIFY_SOURCE=2 -c -o lib.o lib.c
?> gcc -Wall -Werror -g -D_FORTIFY_SOURCE=2 -c -o dm.o dm.c
?> dm.c: In function `nashDmCreate':
?> dm.c:189: warning: implicit declaration of function `dm_task_update_nodes'
?> dm.c: In function `dm_submap_has_part':
?> dm.c:678: warning: implicit declaration of function `dm_tree_create'
?> dm.c:678: warning: assignment makes pointer from integer without a cast
?> dm.c:684: warning: implicit declaration of function `dm_tree_add_dev'
?> dm.c:686: warning: implicit declaration of function `dm_tree_find_node'
?> dm.c:686: warning: assignment makes pointer from integer without a cast
?> dm.c:688: warning: implicit declaration of function `dm_tree_next_child'
?> dm.c:688: warning: assignment makes pointer from integer without a cast
?> dm.c:694: warning: implicit declaration of function `dm_tree_node_get_name'
?> dm.c:695: warning: passing arg 2 of `nashDmTaskNew' makes pointer from integer without a cast
?> dm.c:716: warning: assignment makes pointer from integer without a cast
?> dm.c:742: warning: implicit declaration of function `dm_tree_free'
?> make[1]: *** [dm.o] Error 1
?> make[1]: Leaving directory `/usr/src/momonga/BUILD/mkinitrd-5.0.28/nash'
?> make: *** [nash] Error 2
?> error: Bad exit status from /var/tmp/rpm-tmp.7114 (%build)
?> 
?> 
?> RPM build errors:
?>     Bad exit status from /var/tmp/rpm-tmp.7114 (%build)
?> 
?> ----------------------- above  ----------------------------------
?> 
?> 
?> Could anyone pls give me some advice into find the solution about this?
?> *I got the same error when only "make" from the src tree.
?> 
?> 
?> ### PS.
?> The patch files for momonga-linux:
?> 
?> -------------------------------------------------------------------------------------
?> # cat mkinitrd-5.0.28-momonga.patch
?> --- mkinitrd-5.0.28/grubby/new-kernel-pkg.def   2006-02-28 13:17:52.751654680 +0900
?> +++ mkinitrd-5.0.28/grubby/new-kernel-pkg       2006-02-28 13:20:26.978208680 +0900
?> @@ -7,6 +7,7 @@
?>  # addition/removal of kernel images from grub/lilo configuration (via grubby)
?>  #
?>  # Copyright (C) 2002-2005 Red Hat, Inc.
?> +# Copyright (C) 2006 Momonga Project.
?>  #
?> 
?>  PATH=/sbin:/bin:$PATH
?> @@ -139,7 +140,7 @@
?>         elif [ -f /etc/redhat-release ]; then
?>             title="$(sed 's/ release.*$//' < /etc/redhat-release) ($version)"
?>         else
?> -           title="Red Hat Linux ($version)"
?> +           title="Momonga Linux ($version)"
?>         fi
?>         /sbin/grubby --add-kernel=$bootPrefix/$kernelName-$version \
?>             $INITRD --copy-default $makedefault --title "$title" \
?> 
?> -------------------------------------------------------------------------------------
?> # cat mkinitrd-5.0.28-insmod.static.old.patch
?> --- mkinitrd-5.0.28/mkinitrd.def        2006-02-28 13:24:34.523576064 +0900
?> +++ mkinitrd-5.0.28/mkinitrd    2006-02-28 13:24:39.938752832 +0900
?> @@ -797,7 +797,15 @@
?>      inst /etc/fstab.sys "$MNTIMAGE/etc/fstab.sys"
?>  fi
?>  inst /sbin/nash "$MNTIMAGE/bin/nash"
?> -inst /sbin/insmod.static "$MNTIMAGE/bin/insmod"
?> +if [ `echo "$kernel"|cut -d'.' -f1-2` = "2.4" ]; then
?> +  if [ -f /sbin/insmod.static.old ]; then
?> +    inst /sbin/insmod.static.old "$MNTIMAGE/bin/insmod"
?> +  else
?> +    inst /sbin/insmod.static "$MNTIMAGE/bin/insmod"
?> +  fi
?> +else
?> +  inst /sbin/insmod.static "$MNTIMAGE/bin/insmod"
?> +fi
?>  ln -s /sbin/nash $MNTIMAGE/sbin/modprobe
?> 
?>  for MODULE in $MODULES; do
?> -------------------------------------------------------------------------------------
?> 
?> 
?> 
?> On Sun, 26 Feb 2006 22:26:58 -0700
?> Dax Kelson <dax at gurulabs.com> wrote:
?> 
?> ?> In stock Fedora Core 5 test 3 with a mkinitrd-5.0.26 created initramfs
?> ?> the dmraid was not properly activated.
?> ?> 
?> ?> I did a fresh install of FC5 test and upgraded to mkinitrd-5.0.28 inside
?> ?> the rescue environment. I rebuilt the initial ram disk and I'm happy to
?> ?> report that it fixes the problem.
?> ?> 
?> ?> More details are available in the bug I filed.
?> ?> 
?> ?> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182446
?> ?> 
?> ?> Dax Kelson
?> ?> Guru Labs
?> ?> 
?> ?> -- 
?> ?> 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





From alan at redhat.com  Wed Mar  1 01:25:26 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Feb 2006 20:25:26 -0500
Subject: games user and group
In-Reply-To: <4404EB4A.40304@kobold.org>
References: <4404EB4A.40304@kobold.org>
Message-ID: <20060301012526.GA14476@devserv.devel.redhat.com>

On Tue, Feb 28, 2006 at 04:31:06PM -0800, Michael Thomas wrote:
> Two packages that I recently submitted for review ('rogue' and 'ularn')

I was always under the impression rogue (and rogue clone) didn't meet the
Fedora licensing requirements as it was non-commercial only



From wart at kobold.org  Wed Mar  1 01:30:11 2006
From: wart at kobold.org (Michael Thomas)
Date: Tue, 28 Feb 2006 17:30:11 -0800
Subject: games user and group
In-Reply-To: <20060301012526.GA14476@devserv.devel.redhat.com>
References: <4404EB4A.40304@kobold.org>
	<20060301012526.GA14476@devserv.devel.redhat.com>
Message-ID: <4404F923.5070807@kobold.org>

Alan Cox wrote:
> On Tue, Feb 28, 2006 at 04:31:06PM -0800, Michael Thomas wrote:
> 
>>Two packages that I recently submitted for review ('rogue' and 'ularn')
> 
> 
> I was always under the impression rogue (and rogue clone) didn't meet the
> Fedora licensing requirements as it was non-commercial only

That's true for Angband, but rogue 5.4.2 is very BSD-ish:

http://cvs.sourceforge.net/viewcvs.py/roguelike/rogue5.4/LICENSE.TXT?view=markup

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

From docs-list at fedoralinks.org  Wed Mar  1 01:32:07 2006
From: docs-list at fedoralinks.org (Robert 'Bob' Jensen)
Date: Tue, 28 Feb 2006 19:32:07 -0600
Subject: [ANN] Docs/Beats Open for edits - web release
Message-ID: <1141176728.3166.17.camel@cbcclt02.cbcchome.cbccgroup.com>

On March 1, 2006 about 01:00 UTC we tagged the release notes ready for
translation to be included in the ISO release of FC5. 

The Wiki at http://fedoraproject.org/wiki/Docs/Beats is now open for
edits, changes and additions for the Web only update version of the
release notes.

Thank you to everyone who helped with the release notes.

The Wiki will again be frozen for the Web-published notes on 08 March at
23:59 UTC.
-- 
Robert 'Bob' Jensen <docs-list at fedoralinks.org>
Fedora Documentation Projects
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060228/9a66d7f7/attachment.sig>

From lamont at gurulabs.com  Wed Mar  1 01:43:28 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 28 Feb 2006 18:43:28 -0700
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141174657.19512.3.camel@localhost.localdomain>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
Message-ID: <200602281843.33687.lamont@gurulabs.com>

On Tuesday 28 February 2006 05:57pm, Richard Hughes wrote:
> On Tue, 2006-02-28 at 16:52 -0800, alan wrote:
> > On Tue, 28 Feb 2006, Louis E Garcia II wrote:
> > > Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
> > > think it is actually slower.
> >
> > glx-utils
> >
> > I have stopped using ati due to support issues.  nVIDIA may have closed
> > source drivers, but they have at least supported everything with them.
> > (ATI's support with their closed source driver depends on picking the
> > right card.)
>
> So if I was buying a new laptop sometime soonish, what chipset is best
> for all this new accelerated X stuff?

Personally, I've never liked nVidia.  Partly, that's because of how horribly 
sucky and unstable the first 4 or 5 generations of each chip were (though, 
only the first one really has any serious issues anymore, if even that).  Too 
many of my friends who had nVidia based cards experienced lots of system 
lockups and crashes when running games (even/especially on Windows) and 
simply switching to some other video card they wouldn't have any of those 
problems at all.  Yes, I know nVidia is much better than they used to be, but 
something about them still just rubs me the wrong way a little.  What can I 
say, I don't really like them.

I like Matrox, but they really don't support Linux like they used to.  Still, 
their cards are rock solid and run quite well.  I have lots of success with 
3D acceleration of those (I don't have any Parhelia level stuff, for which 
there is no 3D acceleration support that I am aware of).

I like ATI for notebooks, especially.  Good performance, relatively low power 
consumption and they are pretty well supported, even by ATI even for Linux.

But, nVidia's closed source drivers do seem to have the most complete 
accelerated 3D support of all the manufacturers.  I am considering getting an 
nVidia card for a game system for my wife (we play WoW).

Oh, how I would love to see the video card makers build open source drivers.  
Sigh.  I'll keep dreaming.

> ati seems to not care about Linux, and I've heard bad things about
> nvidia. I don't do games, so 3D isn't that important.

Well, if you don't care about 3D, then take your pick.  It really doesn't 
matter.  :)

Almost all cards are very nicely & completely support 2D and pretty much every 
card made today has pretty much equal 2D performance.  Card makers 
distinguish themselves on 3D.

However, with FC5, there are some cool things that can be done for "normal" 
apps if you have 3D acceleration.  Some new "eye-candy" items and such.

> Thanks for any help,

HTH, even though it doesn't look that helpful to me.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060228/25779e2f/attachment.sig>

From dax at gurulabs.com  Wed Mar  1 06:19:25 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Tue, 28 Feb 2006 23:19:25 -0700
Subject: My Feb 28 2006 rawhide problem report.
Message-ID: <1141193965.3099.19.camel@dhcp50.dkwired.gurulabs.com>

Are these known, do they need bugzilla reports?

1. Firstboot won't launch. There is a python traceback (something about
gtk?) that flashes by on the screen.

2. system-config-display won't launch, gives error:

Traceback (most recent call last):
  File "/usr/share/system-config-display/xconf.py", line 22, in ?
    import gobject
ImportError: No module named gobject

3. Running "yum install kernel-devel" resulted in:

Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
development                                                          [1/2]
development               100% |=========================| 1.1 kB    00:00
extras-development                                                   [2/2]
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
primary.xml.gz            100% |=========================| 1.2 MB    00:04
developmen: ################################################## 4282/4282
Added 4282 new packages, deleted 0 old in 12.05 seconds
primary.xml.gz            100% |=========================| 1.3 MB    00:11
extras-dev: ################################################## 3643/3643
Added 3643 new packages, deleted 0 old in 12.15 seconds
python: Modules/gcmodule.c:240: update_refs: Assertion `gc->gc.gc_refs == (-3)' failed.
Aborted

4. Evolution. When defining a mail account with the initial wizard and
selecting that SMTP authentication is required, the SMTP auth setting
doesn't stick. Later trying to send email fails and checking the account
details show that SMTP auth is not selected.

5. Evolution broken icons. Inside Evolution launched from the Edit menu,
the Evolution Preferences window has vertical column of icons on the
left. The icons "Mail Accounts", "Autocompletion", and "Calendar and
Tasks" look like a sheet of paper with a big red X in the middle.



From louisg00 at bellsouth.net  Wed Mar  1 06:21:10 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Wed, 01 Mar 2006 01:21:10 -0500
Subject: gnome trash
Message-ID: <1141194070.4512.1.camel@soncomputer>

Where are the file I delete from nautilus going? Because it's not going
in Trash.

--Louis



From ivazquez at ivazquez.net  Wed Mar  1 06:31:42 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Wed, 01 Mar 2006 01:31:42 -0500
Subject: gnome trash
In-Reply-To: <1141194070.4512.1.camel@soncomputer>
References: <1141194070.4512.1.camel@soncomputer>
Message-ID: <1141194703.17833.0.camel@ignacio.lan>

On Wed, 2006-03-01 at 01:21 -0500, Louis E Garcia II wrote:
> Where are the file I delete from nautilus going? Because it's not going
> in Trash.

~/.Trash

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- 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/20060301/c39f1b31/attachment.sig>

From arjan at fenrus.demon.nl  Wed Mar  1 07:47:25 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Wed, 01 Mar 2006 08:47:25 +0100
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141174657.19512.3.camel@localhost.localdomain>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
Message-ID: <1141199246.3866.22.camel@laptopd505.fenrus.org>

On Wed, 2006-03-01 at 00:57 +0000, Richard Hughes wrote:
> On Tue, 2006-02-28 at 16:52 -0800, alan wrote:
> > On Tue, 28 Feb 2006, Louis E Garcia II wrote:
> > 
> > > Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
> > > think it is actually slower.
> > 
> > glx-utils
> > 
> > I have stopped using ati due to support issues.  nVIDIA may have closed 
> > source drivers, but they have at least supported everything with them. 
> > (ATI's support with their closed source driver depends on picking the 
> > right card.)
> 
> So if I was buying a new laptop sometime soonish, what chipset is best
> for all this new accelerated X stuff?
> 
> ati seems to not care about Linux, and I've heard bad things about
> nvidia. I don't do games, so 3D isn't that important.

go intel.. intel video is well supported and open
(David will now say that it uses the bios to do mode setting and that it
thus isn't fully open, but i'll ignore him for now :)



From green at redhat.com  Wed Mar  1 07:52:43 2006
From: green at redhat.com (Anthony Green)
Date: Tue, 28 Feb 2006 23:52:43 -0800
Subject: Java - Azureus memory usage
In-Reply-To: <20060228162228.0f1eb3ec@dhcp05.addix.net>
References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
	<17412.24885.59516.767056@zapata.pink>
	<20060228162228.0f1eb3ec@dhcp05.addix.net>
Message-ID: <1141199563.3520.70.camel@localhost.localdomain>

On Tue, 2006-02-28 at 16:22 +0100, Ralf Ertzinger wrote:
> Hi
> 
> On Tue, 28 Feb 2006 14:41:57 +0000, Andrew Haley wrote:
> 
> >  > Anyone else seeing this?
> > 
> > When you start azureus, use 'gij -verbose:class'.  See if any of the
> > classes are loaded 'bytecode'.
> 
> 2929 unique classes. I'm impressed. Some of these are bytecode, indeed.
> Complete list is attached.

Thanks.  I see we're using a slow interpreter for the crypto code.  This
is a bad idea.  I've filed two bugs...

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

AG




From green at redhat.com  Wed Mar  1 07:53:52 2006
From: green at redhat.com (Anthony Green)
Date: Tue, 28 Feb 2006 23:53:52 -0800
Subject: Java - Azureus memory usage
In-Reply-To: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
Message-ID: <1141199633.3520.72.camel@localhost.localdomain>

On Tue, 2006-02-28 at 14:30 +0000, Garry Harthill wrote:
> 213mb memory and 50% CPU seems a bit excessive.
> 
> azureus-2.4.0.0-0.20060209cvs_1.fc5
> glib-java-0.2.3-1.2
> cairo-java-1.0.2-0.2
> libgconf-java-2.12.1-2.2
> libgtk-java-2.8.3-1.2
> java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
> 
> Anyone else seeing this?

It's big for me, but not using so much CPU.  Please file a bug report @
http://bugzilla.redhat.com.

Thanks,

AG




From green at redhat.com  Wed Mar  1 07:54:30 2006
From: green at redhat.com (Anthony Green)
Date: Tue, 28 Feb 2006 23:54:30 -0800
Subject: Java - Azureus memory usage
In-Reply-To: <20060228174314.GC3383@rathann.pekin.waw.pl>
References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
	<20060228174314.GC3383@rathann.pekin.waw.pl>
Message-ID: <1141199670.3520.74.camel@localhost.localdomain>

On Tue, 2006-02-28 at 18:43 +0100, Dominik 'Rathann' Mierzejewski wrote:
> 
> What I'm seeing is deficient functionality. FE version seems to be
> able
> to handle only one download at a time and at far lower speed, i.e.
> only one of all active downloads actually shows any "Down speed",
> all others are at zero.

I'm not seeing this, but please file a bug report and we can try to
solve it.

Thanks,

AG




From buildsys at redhat.com  Wed Mar  1 08:24:01 2006
From: buildsys at redhat.com (Build System)
Date: Wed, 1 Mar 2006 03:24:01 -0500
Subject: rawhide report: 20060301 changes
Message-ID: <200603010824.k218O0P1032044@porkchop.devel.redhat.com>

 

 
Updated Packages:

NetworkManager-0.5.1-17.cvs20060227
-----------------------------------
* Tue Feb 28 2006 Christopher Aillon <caillon at redhat.com> 0.5.1-17.cvs20060228
- Tweak three-scan-prune.patch

* Mon Feb 27 2006 Christopher Aillon <caillon at redhat.com> 0.5.1-16.cvs20060227
- Don't prune networks until they've gone MIA for three scans, not one.

anaconda-10.92.14-1
-------------------
* Tue Feb 28 2006 Jeremy Katz <katzj at redhat.com> - 10.92.14-1
- fix traceback in pkgorder
- don't display xen 
- make partitioning type combo wider (dcantrel)
- handle Serbian locales properly (#182591)

binutils-2.16.91.0.6-2
----------------------
* Tue Feb 28 2006 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.6-2
- add MNI support on i?86/x86_64 (#183080)
- support S signal frame augmentation flag in .eh_frame,
  add .cfi_signal_frame support (#175951, PR other/26208, BZ#300)

bluez-hcidump-1.30-1
--------------------
* Thu Feb 23 2006 David Woodhouse <dwmw2 at redhat.co,> 1.30-1
- update to bluez-hcidump 1.30

bluez-utils-2.25-1
------------------
* Thu Feb 23 2006 David Woodhouse <dwmw2 at redhat.com> - 2.25-1
- Update to bluez-utils 2.25
- Add hidd init script (#182274)

device-mapper-multipath-0.4.5-12.2
----------------------------------
* Mon Feb 27 2006 Benjamin Marzinski <bmarzins at redhat.com> 0.4.5-12.2
- Prereq: chkconfig

* Mon Feb 20 2006 Karsten Hopp <karsten at redhat.de> 0.4.5-12.1
- BuildRequires: libselinux-devel

eel2-2.13.92-2
--------------
* Tue Feb 28 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-2
-Fix a nautilus crash  (#183368)

evolution-2.5.92-1
------------------
* Mon Feb 27 2006 Ray Strode <rstrode at redhat.com> - 2.5.92-1
- 2.5.92

* Tue Feb 14 2006 David Malcolm <dmalcolm at redhat.com> - 2.5.91-1
- 2.5.91
- updated patch 101 to track upstream changes to calendar printing code
- remove uptreamed patch 807 (NM multiple initialization assertion)
- readded the mail-to-task plugin XML UI file
- bump e-d-s req to 1.5.91

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 2.5.90-2.1
- bump again for double-long bug on ppc(64)

evolution-connector-2.5.92-1
----------------------------
* Tue Feb 28 2006 Ray Strode <rstrode at redhat.com> - 2.5.92-1
- 2.5.92

* Wed Feb 15 2006 David Malcolm <dmalcolm at redhat.com> - 2.5.91-1
- 2.5.91
- fix missing declarations (patch 301)

evolution-data-server-1.5.92-1
------------------------------
* Mon Feb 27 2006 Ray Strode <rstrode at redhat.com> - 1.5.92-1
- 1.5.92

fedora-logos-1.1.42-1
---------------------
* Tue Feb 28 2006 Matthias Clasen <mclasen at redhat.com> 1.1.42-1
- New artwork for gdm, kdm Bluecurve from Diana Fong

gcc-4.1.0-1
-----------
* Tue Feb 28 2006 Jakub Jelinek <jakub at redhat.com> 4.1.0-1
- update from gcc-4_1-branch (-r111466:111570)
  - GCC 4.1.0 release
  - PR other/26473

* Mon Feb 27 2006 Jakub Jelinek <jakub at redhat.com> 4.1.0-0.31
- add __floatuns[sdt]i[sdxt]f exports to libgcc_s.so.1 (Joseph S. Myers)
- fix unwinding through signal frames (#175951, PR other/26208, glibc BZ#300)

gdb-6.3.0.0-1.110
-----------------
* Thu Feb 23 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.110
- Bump up release number.

* Thu Feb 23 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.107
- Enable gdb to debug core files and executables with mismatched
prelink base addresses.  Fixes BZ 175075.

* Tue Feb 14 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.106
- Bump up release number.

gnome-session-2.13.92-1
-----------------------
* Tue Feb 28 2006 Ray Strode <rstrode at redhat.com> - 2.13.92-1
- Update to 2.13.92
- Add patch from CVS HEAD to maintain compatibility with
  version 2.13.91

* Thu Feb 23 2006 Ray Strode <rstrode at redhat.com> - 2.13.91-2
- take ownership of autostart dir (bug 182335)

gnome-vfs2-2.13.92-3
--------------------
* Tue Feb 28 2006 Alexander Larsson <alexl at redhat.com> - 2.13.92-3
- Fix smb browsing (#170922)

* Tue Feb 28 2006 Alexander Larsson <alexl at redhat.com> - 2.13.92-2
- Add patch (from cvs) that fixes permission reading

gtkhtml3-3.9.92-1
-----------------
* Mon Feb 27 2006 Ray Strode <rstrode at redhat.com> - 3.9.92-1
- Update to 3.9.92

guile-5:1.6.7-6
---------------
* Tue Feb 28 2006 Miroslav Lichvar <mlichvar at redhat.com> - 5:1.6.7-6
- move .la files for modules from devel to main package (#182242)

hicolor-icon-theme-0.9-2
------------------------
* Mon Feb 27 2006 Ray Strode <rstrode at redhat.com> 0.9-2
- Remove Prereq on gtk.  Prereq's complicate things,
  and the gtk-update-icon-cache is already protected by
  [ -x  ... ]

htmlview-3.0.0-14
-----------------
* Tue Feb 28 2006 Matthias Clasen <mclasen at redhat.com>> 3.0.0-14
- Create absolute symlinks to desktop files (#176104)

initscripts-8.30-1
------------------
* Tue Feb 28 2006 Bill Nottingham <notting at redhat.com> 8.30-1
- hotplug: don't cause modules to be reloaded on ifdown/rmmod (#179809)
- fix endless loops in ifup/ifdown (#177792, #182466)
- fix enabling of enforcing SELinux mode after relabel (#181893)
- remove debugging code from ifup-bnep
- add /proc, /sys mounting back to rc.sysinit
  Note: booting without an initrd is deprecated
- translation updates

jpilot-0.99.8-3
---------------
* Mon Feb 27 2006 Ivana Varekova <varekova at redhat.com> - 0.99.8-3
- fix b183014 - jpilot startup problem

kernel-2.6.15-1.1996_FC5
------------------------
* Tue Feb 28 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc5-git3

* Tue Feb 28 2006 David Woodhouse <dwmw2 at redhat.com>
- Fix gettimeofday() in the 64-bit PowerPC vDSO

kudzu-1.2.33-1
--------------
* Tue Feb 28 2006 Jeremy Katz <katzj at redhat.com> - 1.2.33-1
- fix i2o again (#182522)

librsvg2-2.14.1-1
-----------------
* Tue Feb 28 2006 Matthias Clasen <mclasen at redhat.com> 2.14.1-1
- Update to 2.14.1

libvirt-0.0.6-1
---------------
* Tue Feb 28 2006 Daniel Veillard <veillard at redhat.com> 0.0.6-1
- added error handling APIs
- small bug fixes
- improve python bindings
- augment documentation and regression tests

mc-1:4.6.1a-9
-------------
* Tue Feb 28 2006 Jindrich Novy <jnovy at redhat.com> 4.6.1a-9
- fix hotkey conflict in Layout options (#183282)
- move syntax configuration file from /usr/share/mc to /etc/mc
- save layout settings pernamently for showing free space, not
  only for current session (#182127)
- fix audio bindings, make firefox default html binding

mod_auth_mysql-1:3.0.0-3
------------------------
* Tue Feb 28 2006 Joe Orton <jorton at redhat.com> 1:3.0.0-3
- fix to disable auth by default again (regression since FC4)

mono-1.1.13.2-4
---------------
* Tue Feb 28 2006 Ray Strode <rstrode at redhat.com> - 1.1.13.2-4
- Updated patch from Paolo Molaro <lupus at ximian.com>

* Mon Feb 27 2006 Ray Strode <rstrode at redhat.com> - 1.1.13.2-3
- Patch from Jakub to make work with SELinux better

ncurses-5.5-19
--------------
* Mon Feb 27 2006 Miroslav Lichvar <mlichvar at redhat.com> - 5.5-19
- avoid comparing padding in cchar_t structure (#182024)

ntp-4.2.0.a.20050816-11
-----------------------
* Thu Feb 23 2006 Miroslav Lichvar <mlichvar at redhat.com> - 4.2.0.a.20050816-11
- update man pages (#153195, #162856)
- drop C-Frame-121, vsnprintf, minusTi and loconly patch
- prevent segfault when loopback interface is not configured (#159056)
- spec cleanup

openoffice.org-1:2.0.2-5.1.2
----------------------------
* Sat Feb 25 2006 Caolan McNamara <caolanm at redhat.com> - 1:2.0.2-5.1
- hunspell replaces myspell
- Catalan help documentation available
- add sestatus details to crash_reporter
- nl_NL dictionaries upstreamed
- hu_HU dictionaries upstreamed
- workspace.epspreview.patch integrated
- workspace.dbwizardpp1.patch integrated
- workspace.cmcfixes20.patch integrated
- workspace.cmcfixes21.patch integrated
- workspace.cmcfixes22.patch integrated
- workspace.cmcfixes23.patch integrated
- workspace.gcc41.patch integrated
- workspace.sb41.patch integrated
- workspace.systemagg.patch integrated
- workspace.hro02.patch integrated
- openoffice.org-1.9.96.ooo35641.noxfonts.vcl.patch integrated
- openoffice.org-2.0.1.ooo58618.sfx2.interactionhandler.patch integrated
- openoffice.org-2.0.1.ooo58798.parallel.patch integrated
- openoffice.org-2.0.1.ooo59537.config_office.nss.patch integrated
- openoffice.org-2.0.1.ooo59666.vcl.animatedtheme.patch integrated
- openoffice.org-1.9.125.ooo54040.savecrash.svtools.patch integrated
- openoffice.org-2.0.1.ooo61098.vcl.readonlyentry.patch integrated
- openoffice.org-2.0.2.ooo61178.ucb.neon25.patch integrated
- drop openoffice.org-1.9.125.ooo54586.nfslock.sal.patch
- drop openoffice.org-1.9.112.ooo50857.gtkslowunderkde.vcl.patch
- drop openoffice.org-1.9.88.NONE.gcc3gcj4.patch
- drop empty sandbox.jar
- deliver link flag syntax changed
- new workspace.jaxpapi.patch
- replace fasterhelpcontent2.patch with workspace.targetedaot.patch
- replace ooo52974.systemhsqldbbeanshell.patch and oooXXXXX.systemxalan.patch 
  with workspace.systemjava.patch
- rh#178670# drop PROT_EXEC
- add openoffice.org-2.0.2-ooo61841.vcl.honourfontconfigoverrides.patch for rh#179692#
- add openoffice.org-2.0.2.ooo62030.solenv._version.patch
- rh#181876# update workspace.atkbridge.patch
- update and split evo patches to match upstream segmentation
- ooo#62318# mozab not available with system mozilla

php-5.1.2-5
-----------
* Tue Feb 28 2006 Joe Orton <jorton at redhat.com> 5.1.2-5
- provide php-api (#183227)
- add provides for all builtin modules (Tim Jackson, #173804)
- own %{_libdir}/php/pear for PEAR packages (per #176733)
- add obsoletes to allow upgrade from FE4 PDO packages (#181863)

php-pear-1:1.4.6-2
------------------
* Tue Feb 28 2006 Joe Orton <jorton at redhat.com> 1:1.4.6-2
- set cache_dir directory, own /var/cache/php-pear

pirut-0.9.17-1
--------------
* Tue Feb 28 2006 Jeremy Katz <katzj at redhat.com> - 0.9.17-1
- Fix package selection traceback (#183310)
- Lock the yum pid file when pirut tools are running (#183311)
- Give feedback during group selection (#183307)
- Fix display of urllib2 encoded strings (#183111)

pm-utils-0.11-1
---------------
* Tue Feb 28 2006 Jeremy Katz <katzj at redhat.com> - 0.11-1
- fix display on resume with nvidia graphics
- add infrastructure to tell what pm-util is running; don't resume 
  video on return from hibernate as the BIOS has already re-initialized it

* Fri Feb 24 2006 Phil Knirsch <pknirsch at redhat.com> - 0.10-1
- Added missing pciutils-devel BuildRequires (#182566) 
- Fixed missing vbestata save/restore calls for video suspend/resume (#182167, 
  - Renamed hook scripts to allow local pre and post inserts (#179421)
- Added support for blinking led lights on Thinkpad Laptops during suspend
  (#179420)
- Added pm-powersave script for powersaving via HAL (#169054)
- Added symlinks for pm-shutdown and pm-restart (#165953)

redhat-artwork-0.241-1
----------------------
* Tue Feb 28 2006 Matthias Clasen <mclasen at redhat.com> - 0.241-1
- New artwork by Diana Fong

sound-juicer-2.13.6-1
---------------------
* Tue Feb 28 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.6-1
- Update to 2.13.6

system-config-language-1.1.11-1
-------------------------------
* Tue Feb 28 2006 Paul Nasrat <pnasrat at redhat.com> - 1.1.11-1
- Update translations
- Serbian locales (#172600)

system-config-securitylevel-1.6.16-1
------------------------------------
* Tue Feb 28 2006 Chris Lumens <clumens at redhat.com> 1.6.16-1
- Add requirement for scriptlets (#182876, #182877).
- Add glade UI strings to translations (#182181).
- Reorder service checkboxes to make the screen fit for Italian (#182447).

totem-1.3.92-1
--------------
* Tue Feb 28 2006 Matthias Clasen <mclasen at redhat.com> - 1.3.92-1
- Update to 1.3.92

wpa_supplicant-1:0.4.8-2
------------------------
* Mon Feb 27 2006 Dan Williams <dcbw at redhat.com> - 0.4.8-2
- Don't expose private data on the control interface unless requested

xorg-x11-xkbdata-1.0.1-5
------------------------
* Tue Feb 28 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-5
- Fixed rpm pre script upgrade/install testing
- Rebuild package as 1.0.1-5 in rawhide, completing the transition to
  xkeyboard-config.

* Tue Feb 28 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-4.0.7.xkbcfg.5
- Added rpm pre script, to pre-remove the symbols/pc during package upgrades,
  to avoid an rpm cpio error if the X11R7.0 modular xkbdata package is already
  installed, because rpm can not replace a directory with a file.

* Fri Feb 24 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-4.0.7.xkbcfg.1
- Package renamed to xorg-x11-xkbdata and version/release tweaked since it
  is too late to add new package names to Fedora Core 5 development.
- Added "Provides: xkeyboard-config" virtual provide.

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs
	vconfig - 1.9-1.1.ia64 requires libc.so.6
	vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0)






Broken deps for ppc64
----------------------------------------------------------
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	vconfig - 1.9-1.1.ppc64 requires libc.so.6
	vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0)



Broken deps for s390
----------------------------------------------------------
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1



Broken deps for s390x
----------------------------------------------------------
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From jfrieben at freesurf.fr  Wed Mar  1 09:05:25 2006
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Wed, 1 Mar 2006 10:05:25 +0100 (CET)
Subject: gnome trash
In-Reply-To: <1141194070.4512.1.camel@soncomputer>
References: <1141194070.4512.1.camel@soncomputer>
Message-ID: <64222.194.94.224.254.1141203925.squirrel@arlette.freesurf.fr>

This is not a general Linux support list. Please, post to "fedora-list" or
elsewhere.

Thanks.

> Where are the file I delete from nautilus going? Because it's not going
> in Trash.
>
> --Louis
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list





From mharris at mharris.ca  Wed Mar  1 09:19:41 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Wed, 01 Mar 2006 04:19:41 -0500
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
Message-ID: <4405672D.7080205@mharris.ca>

The xorg-x11-xkbdata package up until version 1.0.1-4 contained
xkb data from the upstream X.Org official "xkbdata" tarball which
was part of the X11R7.0 release.

Ever since X.Org reformed, the primary XFree86 xkbdata maintainers
split out xkbdata into a separate project on freedesktop.org, so
they could maintain the data in one location for all open source
X11 implementations (primarily X.Org X11, and XFree86).  The new
project was named "xkeyboard-config" and is in the "xkbdesc"
CVS module on freedesktop.org.

However, since then, both X.Org and XFree86 have shipped the
traditional xkbdata that they've always shipped, and have not
updated to using the new xkeyboard-config data.  As such, what
has happened, is that the xkbdata in both projects has rotted,
with not much maintenance happening, and when bugs get reported
for xkbdata, the problems get fixed in xkeyboard-config if they're
present there also, and the bugs get marked closed in bugzilla.

Unfortunately, the users never see the bugfixes because neither
X project ships the xkeyboard-config data, and most distributions
ship what X.Org or XFree86 has provided.

There is fairly broad concensus that xkeyboard-config data is
"the future", and also that xkbdata from X.Org is more or less
totally unmaintained and abandoned.  One might ask "why did they
ship abandoned unmaintained xkbdata instead of shipping
xkeyboard-config then?", and that's a good question.  I don't
know the 100% authoritative answer, but I believe it was because
it was too big of a change at the time, plus the fact that the 7.0
and 6.9 releases had to be the same codebase, and that it wouldn't
be easy to integrate everything into 6.9.

Anyway the long and the short of it is that the GNOME project,
and I believe the KDE project as well, have standardized upstream
on using/expecting xkeyboard-config data present on the system,
and a whole slew of nasty problems happen if you're using the
X.Org or XFree86 unmaintained data.

As such, since xkeyboard-config is the future, and is very
actively maintained right now, we have decided to switch to using
it in FC5, so long as there are no major unresolveable regressions
between now and the final package build date.  It is too late to
change package names, or to add new package names to the OS, so I
had to assimilate the xorg-x11-xkbdata package with the
xkeyboard-config tarball.  Other than that it should be a drop-in
replacement.

The new package (1.0.1-5) containing xkeyboard-config is now in
rawhide, so you're all going to be using it tomorrow.  Many thanks
to the people who tested the pre-rawhide packages.

Please note that since the new data files have not been part of
the Fedora development process until now, so there could be some
problems potentially.  Please be sure to reconfigure your keyboards
with the gnome keyboard applet, and generally pound on it.

If you experience bugs/problems with the new xkbdata, please report
them in the X.Org bugzilla at http://bugs.freedesktop.org, in the
"xkbdesc" component, and select version "0.7" if it is visible in
bugzilla.  Once you've filed your bug in X.Org bugzilla, feel free
to file a tracking bug in Red Hat bugzilla also if you wish, and
we'll track the problem for FC5 as well.  There will be a new
version released soon that we'll be updating too, hopefully before
FC5 final as well.

This should resolve various keyboard quirks that have been reported
in different components throughout FC5 testing, but may introduce
a few new bugs too.  Overall, since it is the only maintained
xkbdata however, even if there are a few bumps, they'll be ironed
out via modular package updates easily enough, unlike the situation
we'd have if we shipped the X.Org xkbdata and let it rot.

Hope your keyboards all do the happy dance now.

Enjoy.


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From hughsient at gmail.com  Wed Mar  1 10:19:39 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 01 Mar 2006 10:19:39 +0000
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141199246.3866.22.camel@laptopd505.fenrus.org>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
Message-ID: <1141208379.3080.3.camel@localhost.localdomain>

On Wed, 2006-03-01 at 08:47 +0100, Arjan van de Ven wrote:
> On Wed, 2006-03-01 at 00:57 +0000, Richard Hughes wrote:
> > On Tue, 2006-02-28 at 16:52 -0800, alan wrote:
> > > On Tue, 28 Feb 2006, Louis E Garcia II wrote:
> > > 
> > > > Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
> > > > think it is actually slower.
> > > 
> > > glx-utils
> > > 
> > > I have stopped using ati due to support issues.  nVIDIA may have closed 
> > > source drivers, but they have at least supported everything with them. 
> > > (ATI's support with their closed source driver depends on picking the 
> > > right card.)
> > 
> > So if I was buying a new laptop sometime soonish, what chipset is best
> > for all this new accelerated X stuff?
> > 
> > ati seems to not care about Linux, and I've heard bad things about
> > nvidia. I don't do games, so 3D isn't that important.
> 
> go intel.. intel video is well supported and open
> (David will now say that it uses the bios to do mode setting and that it
> thus isn't fully open, but i'll ignore him for now :)

Thanks, that sounds the most definitive.

I'll do some googling on specific chipsets to make sure.

Thanks.

Richard.



From gazzerh at gmail.com  Wed Mar  1 10:24:19 2006
From: gazzerh at gmail.com (Garry Harthill)
Date: Wed, 1 Mar 2006 10:24:19 +0000
Subject: Java - Azureus memory usage
In-Reply-To: <1141199633.3520.72.camel@localhost.localdomain>
References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
	<1141199633.3520.72.camel@localhost.localdomain>
Message-ID: <1fcc9e320603010224r280de4bdn@mail.gmail.com>

On 01/03/06, Anthony Green <green at redhat.com> wrote:
> On Tue, 2006-02-28 at 14:30 +0000, Garry Harthill wrote:
> > 213mb memory and 50% CPU seems a bit excessive.
> >
> > azureus-2.4.0.0-0.20060209cvs_1.fc5
> > glib-java-0.2.3-1.2
> > cairo-java-1.0.2-0.2
> > libgconf-java-2.12.1-2.2
> > libgtk-java-2.8.3-1.2
> > java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
> >
> > Anyone else seeing this?
>
> It's big for me, but not using so much CPU.  Please file a bug report @
> http://bugzilla.redhat.com.
>
CPU usage varies. This was maybe a particularly high example. Anyway, bugged:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183461



From dwmw2 at infradead.org  Wed Mar  1 10:33:13 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 01 Mar 2006 10:33:13 +0000
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141199246.3866.22.camel@laptopd505.fenrus.org>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
Message-ID: <1141209193.3732.63.camel@pmac.infradead.org>

On Wed, 2006-03-01 at 08:47 +0100, Arjan van de Ven wrote:
> go intel.. intel video is well supported and open
> (David will now say that it uses the bios to do mode setting and that
> it thus isn't fully open, but i'll ignore him for now :)

Binary-only code is binary-only code, whether it's shipped with the
system or whether you install it yourself. Have you been overdosing on
the Intel kool-aid since you joined them? :)

Seriously -- please don't refer to Intel video as 'open' because it
misleads people. That kind of misinformation led directly to me buying
the useless Intel hardware I now have in what's supposed to become my
MythTV box. You might just as well say that nVidia is 'well supported
and open' because you can use it with the VESA 'driver'. But we digress.

Personally, if I was buying a laptop and didn't care about games, it'd
still have to be a PowerBook. You even get reliable suspend/resume
without all that ACPI crap, and we have the built-in Broadcom wireless
working in the rawhide kernels too, now. The ATI r300 cards are
well-enough supported for 2D, and 3D is sort of on the way too.

-- 
dwmw2



From aph at redhat.com  Wed Mar  1 10:53:10 2006
From: aph at redhat.com (Andrew Haley)
Date: Wed, 1 Mar 2006 10:53:10 +0000
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141209193.3732.63.camel@pmac.infradead.org>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
	<1141209193.3732.63.camel@pmac.infradead.org>
Message-ID: <17413.32022.205359.158452@zapata.pink>

David Woodhouse writes:
 > 
 > The ATI r300 cards are
 > well-enough supported for 2D, and 3D is sort of on the way too.

Are they really supported?  On my PC I still get

drmOpenDevice: Open failed
(II) RADEON(0): [drm] drmOpen failed
(EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.
(II) RADEON(0): Depth moves disabled by default
(II) RADEON(0): Memory manager initialized to (0,0) (1920,8191)
(II) RADEON(0): Reserved area from (0,1200) to (1920,1202)
(II) RADEON(0): Largest offscreen area available: 1920 x 6989
(II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer.
(II) RADEON(0): Render acceleration disabled

Andrew.



From dwmw2 at infradead.org  Wed Mar  1 10:55:47 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 01 Mar 2006 10:55:47 +0000
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <17413.32022.205359.158452@zapata.pink>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
	<1141209193.3732.63.camel@pmac.infradead.org>
	<17413.32022.205359.158452@zapata.pink>
Message-ID: <1141210547.3732.67.camel@pmac.infradead.org>

On Wed, 2006-03-01 at 10:53 +0000, Andrew Haley wrote:
> David Woodhouse writes:
>  > 
>  > The ATI r300 cards are well-enough supported for 2D, and 3D is sort
> > of on the way too.
> 
> Are they really supported?  On my PC I still get

Yeah, 2D acceleration is OK if not perfect -- I'm slightly surprised by
the lack of RENDER accel.

3D isn't working yet and the experimental 3D support has recently been
disabled for FC5, but it's on the way.

-- 
dwmw2



From gianluca.cecchi at gmail.com  Wed Mar  1 11:34:22 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Wed, 1 Mar 2006 12:34:22 +0100
Subject: gconf multiple versions (was Re: rawhide report: 20060209
	changes (part 1/2))
Message-ID: <561c252c0603010334g32f845c2s@mail.gmail.com>

On Fri, 17 Feb 2006 10:49:40 +0100 Gianluca Cecchi <gianluca cecchi gmail com>
>I cannot do "rpm -e GConf-1.0.9-18" because I get the same error as below.
[snip]
>On Thu, 9 Feb 2006 07:58:28 -0800 Tom London <selinux gmail com> wrote:
>>I get this installing today:
>>
>>  Cleanup   : GConf                        ##################### [351/638]
>>/sbin/ldconfig: relative path `1' used to build cache
>>error: %postun(GConf-1.0.9-18.i386) scriptlet failed, exit status 1
>>  Cleanup   : hdparm                       ##################### [352/638]

Just for tracking, I solved the problem using command
rpm -e --noscripts
for
GConf-1.0.9-18 and GConf-1.0.9-18.1
so now I have only one GConf package in RPMDB.
Does exist analog switch for yum? I didn't find so.



From ndbecker2 at gmail.com  Wed Mar  1 13:10:17 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 01 Mar 2006 08:10:17 -0500
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
References: <4405672D.7080205@mharris.ca>
Message-ID: <du46fp$97d$1@sea.gmane.org>

Does this explain why kde control-center/Regional/keyboard layout now has no
options?  And my 'swap control <-> capslock' no longer works?

So, how exactly do I fix this?



From walovaton at yahoo.com.mx  Wed Mar  1 13:20:04 2006
From: walovaton at yahoo.com.mx (William Lovaton)
Date: Wed, 1 Mar 2006 07:20:04 -0600 (CST)
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141208379.3080.3.camel@localhost.localdomain>
Message-ID: <20060301132004.84844.qmail@web60724.mail.yahoo.com>

Curiously enough yesterday I was thinking about buying
a laptop myself and I got my eye on a Dell Inspiron
630m:
http://www1.us.dell.com/content/products/productdetails.aspx/inspn_630m?c=us&cs=04&l=en&s=bsd&~page=2&~tab=specstab#tabtop

It seems to ship an Intel Media Accelerator 900 with
128 MB of video memory and I think it uses the 915G
chipset family:
http://www.intel.com/design/graphics/gma900/

Is this video card well supported (as in open source
support) on the linux kernel and Xorg server?  Can
anyone provide some links where I could read more
information about this?  Anyone have some experience
with this laptop with Fedora or Ubuntu (mainly
Fedora)?

Richard, may be you are not interested about gaming
but if you want the latest X stuff we have been seeing
around you will need good 3D support any way.

Cheers,

-William


 --- Richard Hughes <hughsient at gmail.com> escribi?:
> 
> Thanks, that sounds the most definitive.
> 
> I'll do some googling on specific chipsets to make
> sure.
> 
> Thanks.
> 
> Richard.



	
	
		
___________________________________________________________ 
Do You Yahoo!? 
La mejor conexi?n a Internet y <b >2GB</b> extra a tu correo por $100 al mes. http://net.yahoo.com.mx 



From mclasen at redhat.com  Wed Mar  1 13:28:20 2006
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 01 Mar 2006 08:28:20 -0500
Subject: My Feb 28 2006 rawhide problem report.
In-Reply-To: <1141193965.3099.19.camel@dhcp50.dkwired.gurulabs.com>
References: <1141193965.3099.19.camel@dhcp50.dkwired.gurulabs.com>
Message-ID: <1141219700.2369.0.camel@localhost.localdomain>

On Tue, 2006-02-28 at 23:19 -0700, Dax Kelson wrote:

> 5. Evolution broken icons. Inside Evolution launched from the Edit menu,
> the Evolution Preferences window has vertical column of icons on the
> left. The icons "Mail Accounts", "Autocompletion", and "Calendar and
> Tasks" look like a sheet of paper with a big red X in the middle.

Which icon theme is this with ? 





From dax at gurulabs.com  Wed Mar  1 14:42:14 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Wed, 01 Mar 2006 7:42:14 -0700
Subject: My Feb 28 2006 rawhide problem report.
In-Reply-To: <1141219700.2369.0.camel@localhost.localdomain>
References: <1141193965.3099.19.camel@dhcp50.dkwired.gurulabs.com> 
	<1141219700.2369.0.camel@localhost.localdomain>
Message-ID: <1938-SnapperMsg827D11E1C02B6352@[70.7.195.126]>

...... Original Message .......
On Wed, 01 Mar 2006 08:28:20 -0500 "Matthias Clasen" <mclasen at redhat.com> 
wrote:
>On Tue, 2006-02-28 at 23:19 -0700, Dax Kelson wrote:
>
>> 5. Evolution broken icons. Inside Evolution launched from the Edit menu,
>> the Evolution Preferences window has vertical column of icons on the
>> left. The icons "Mail Accounts", "Autocompletion", and "Calendar and
>> Tasks" look like a sheet of paper with a big red X in the middle.
>
>Which icon theme is this with ? 

Whatever the default is. During install I did not customize the package 
selection.
___
Dax Kelson
Sent with my Treo



From jsk_priv at gmx.de  Wed Mar  1 14:47:14 2006
From: jsk_priv at gmx.de (Joerg Skottke)
Date: Wed, 01 Mar 2006 15:47:14 +0100
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
In-Reply-To: <du46fp$97d$1@sea.gmane.org>
References: <4405672D.7080205@mharris.ca> <du46fp$97d$1@sea.gmane.org>
Message-ID: <4405B3F2.6070103@gmx.de>

For my (german) keyboard the Alt Gr does not work anymore (no @ :( ) and 
a couple of shifted keys fail as well (e.g shift+7 = "/"). Reconfiguring 
the keyboard did not help. I will look through the bugs filed and write 
one later today, unless someone else volunteers who has more 
time/experience to file something qualified ;-)

Joerg

Neal Becker wrote:
> Does this explain why kde control-center/Regional/keyboard layout now has no
> options?  And my 'swap control <-> capslock' no longer works?
> 
> So, how exactly do I fix this?
> 



From jbarnes at virtuousgeek.org  Wed Mar  1 16:09:51 2006
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Wed, 1 Mar 2006 08:09:51 -0800
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141210547.3732.67.camel@pmac.infradead.org>
References: <1141173320.23703.2.camel@soncomputer>
	<17413.32022.205359.158452@zapata.pink>
	<1141210547.3732.67.camel@pmac.infradead.org>
Message-ID: <200603010809.51354.jbarnes@virtuousgeek.org>

On Wednesday, March 01, 2006 2:55 am, David Woodhouse wrote:
> On Wed, 2006-03-01 at 10:53 +0000, Andrew Haley wrote:
> > David Woodhouse writes:
> >  > The ATI r300 cards are well-enough supported for 2D, and 3D is
> >  > sort
> > >
> > > of on the way too.
> >
> > Are they really supported?  On my PC I still get
>
> Yeah, 2D acceleration is OK if not perfect -- I'm slightly surprised
> by the lack of RENDER accel.
>
> 3D isn't working yet and the experimental 3D support has recently
> been disabled for FC5, but it's on the way.

Pick your poison.  With ATI chips you get open mode setting code but 
very poor support for recent devices.  ATI doesn't release specs so 
most of the ATI driver support is reverse engineered, and support for 
very recent devices is pretty buggy as a result.

With Intel chips, at least you get open 2D and 3D code developed by 
people with specs.  The modesetting stuff is still VBE-only 
unfortunately (though Dave Airlie is working on changing that, as are 
others I think), and really it's beyond Intel's control in many (most?) 
cases since vendors are free to plugin whatever external interface chip 
they want to the basic i9xx graphics hub whey they design their boards.

Jesse



From ndbecker2 at gmail.com  Wed Mar  1 16:09:15 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 01 Mar 2006 11:09:15 -0500
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
References: <4405672D.7080205@mharris.ca> <du46fp$97d$1@sea.gmane.org>
	<4405B3F2.6070103@gmx.de>
Message-ID: <du4gvb$kld$1@sea.gmane.org>

So far I found that gnome-keyboard-properties will fix this, but it is _not
and acceptable solution_.  Running this also screws up various other kde
settings!

For example, non-kde apps are now colored by the kde scheme, even though I
chose not to.  e.g., xemacs now has it's colors overridden.

> Neal Becker wrote:
>> Does this explain why kde control-center/Regional/keyboard layout now has
>> no
>> options?  And my 'swap control <-> capslock' no longer works?
>> 
>> So, how exactly do I fix this?
>> 
> 




From jbarnes at virtuousgeek.org  Wed Mar  1 16:12:07 2006
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Wed, 1 Mar 2006 08:12:07 -0800
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <200603010809.51354.jbarnes@virtuousgeek.org>
References: <1141173320.23703.2.camel@soncomputer>
	<1141210547.3732.67.camel@pmac.infradead.org>
	<200603010809.51354.jbarnes@virtuousgeek.org>
Message-ID: <200603010812.07871.jbarnes@virtuousgeek.org>

On Wednesday, March 01, 2006 8:09 am, Jesse Barnes wrote:
> Pick your poison.  With ATI chips you get open mode setting code but
> very poor support for recent devices.  ATI doesn't release specs so
> most of the ATI driver support is reverse engineered, and support for
> very recent devices is pretty buggy as a result.
>
> With Intel chips, at least you get open 2D and 3D code developed by
> people with specs.  The modesetting stuff is still VBE-only
> unfortunately (though Dave Airlie is working on changing that, as are
> others I think), and really it's beyond Intel's control in many
> (most?) cases since vendors are free to plugin whatever external
> interface chip they want to the basic i9xx graphics hub whey they
> design their boards.

Oh, forgot to  mention the implications.  If you buy a recent ATI device 
you get to help debug the drivers.  If you buy an Intel based device 
you can only set modes that the board/BIOS vendor thought of (though in 
some cases you can use vbetool or somesuch to make your own modes), 
which means you might have trouble plugging in arbitrary flat panels, 
TVs, etc.  Your choice.

Jesse



From che666 at gmail.com  Wed Mar  1 16:12:55 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Wed, 1 Mar 2006 17:12:55 +0100
Subject: games user and group
In-Reply-To: <4404F923.5070807@kobold.org>
References: <4404EB4A.40304@kobold.org>
	<20060301012526.GA14476@devserv.devel.redhat.com>
	<4404F923.5070807@kobold.org>
Message-ID: <e99d27470603010812pb34b038o@mail.gmail.com>

2006/3/1, Michael Thomas <wart at kobold.org>:
> Alan Cox wrote:
> > On Tue, Feb 28, 2006 at 04:31:06PM -0800, Michael Thomas wrote:
> >
> >>Two packages that I recently submitted for review ('rogue' and 'ularn')
> >
> >
> > I was always under the impression rogue (and rogue clone) didn't meet the
> > Fedora licensing requirements as it was non-commercial only
>
> That's true for Angband, but rogue 5.4.2 is very BSD-ish:
>
> http://cvs.sourceforge.net/viewcvs.py/roguelike/rogue5.4/LICENSE.TXT?view=markup
>
> --Mike
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>

id personally suggest to treat gamedaemons like other daemons and
create seperate system users for the game server processes.
A server is a server. Functionality differs but is rather irrelevant
in my eyes regarding the system users for the services.

regards,
Rudolf Kastl



From wart at kobold.org  Wed Mar  1 17:20:59 2006
From: wart at kobold.org (Michael Thomas)
Date: Wed, 01 Mar 2006 09:20:59 -0800
Subject: games user and group
In-Reply-To: <e99d27470603010812pb34b038o@mail.gmail.com>
References: <4404EB4A.40304@kobold.org>	<20060301012526.GA14476@devserv.devel.redhat.com>	<4404F923.5070807@kobold.org>
	<e99d27470603010812pb34b038o@mail.gmail.com>
Message-ID: <4405D7FB.3080505@kobold.org>

Rudolf Kastl wrote:
> id personally suggest to treat gamedaemons like other daemons and
> create seperate system users for the game server processes.
> A server is a server. Functionality differs but is rather irrelevant
> in my eyes regarding the system users for the services.

I won't argue that it would be more secure, but couldn't security also
be accomplished with an appropriate set of selinux policies?

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

From dax at gurulabs.com  Wed Mar  1 17:36:29 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Wed, 01 Mar 2006 10:36:29 -0700
Subject: games user and group
In-Reply-To: <4405D7FB.3080505@kobold.org>
References: <4404EB4A.40304@kobold.org>
	<20060301012526.GA14476@devserv.devel.redhat.com>
	<4404F923.5070807@kobold.org>
	<e99d27470603010812pb34b038o@mail.gmail.com>
	<4405D7FB.3080505@kobold.org>
Message-ID: <1141234589.3477.10.camel@mentorng.gurulabs.com>

On Wed, 2006-03-01 at 09:20 -0800, Michael Thomas wrote:
> Rudolf Kastl wrote:
> > id personally suggest to treat gamedaemons like other daemons and
> > create seperate system users for the game server processes.
> > A server is a server. Functionality differs but is rather irrelevant
> > in my eyes regarding the system users for the services.
> 
> I won't argue that it would be more secure, but couldn't security also
> be accomplished with an appropriate set of selinux policies?

Given multiple possible solutions to a security problem, the simplest
solution is preferred.

Dax Kelson
Guru Labs



From mhw at WittsEnd.com  Wed Mar  1 18:53:40 2006
From: mhw at WittsEnd.com (Michael H. Warfield)
Date: Wed, 01 Mar 2006 13:53:40 -0500
Subject: games user and group
In-Reply-To: <4405D7FB.3080505@kobold.org>
References: <4404EB4A.40304@kobold.org>
	<20060301012526.GA14476@devserv.devel.redhat.com>
	<4404F923.5070807@kobold.org>
	<e99d27470603010812pb34b038o@mail.gmail.com>
	<4405D7FB.3080505@kobold.org>
Message-ID: <1141239220.4380.12.camel@canyon.wittsend.com>

On Wed, 2006-03-01 at 09:20 -0800, Michael Thomas wrote:
> Rudolf Kastl wrote:
> > id personally suggest to treat gamedaemons like other daemons and
> > create seperate system users for the game server processes.
> > A server is a server. Functionality differs but is rather irrelevant
> > in my eyes regarding the system users for the services.

> I won't argue that it would be more secure, but couldn't security also
> be accomplished with an appropriate set of selinux policies?

	Only if you have selinux enabled.

	Make it (more) secure FIRST.  Then add additional security from
selinux.  What you don't want is someone ending up insecure just because
they have selinux turned off.  That's a wrong answer.  That's then
depending on selinux for your security rather than using selinux to
enhance your security.  Too many eggs in one basket.

> --Mike
> -- 

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

From louisg00 at bellsouth.net  Wed Mar  1 19:06:44 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Wed, 01 Mar 2006 14:06:44 -0500
Subject: gnome trash
Message-ID: <1141240004.2283.3.camel@soncomputer>

This is why I posted here. I am having trouble with gnome trash. ~.Trash
has items but the trash bin is empty. This only happen with current
rawhide. Anyone else see this?

--Louis

> This is not a general Linux support list. Please, post to
> "fedora-list" or elsewhere.
> 
> Thanks.
>
> > Where are the file I delete from nautilus going? Because it's not going
> > in Trash.
> >
> > --Louis



From trondeg at gmail.com  Wed Mar  1 19:19:33 2006
From: trondeg at gmail.com (=?UTF-8?Q?Trond_Eivind_Glomsr=C3=B8d?=)
Date: Wed, 1 Mar 2006 20:19:33 +0100
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141199246.3866.22.camel@laptopd505.fenrus.org>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
Message-ID: <d8dc7cba0603011119s26ab8513s5a60fd37583bfbb@mail.gmail.com>

On 3/1/06, Arjan van de Ven <arjan at fenrus.demon.nl> wrote:
> On Wed, 2006-03-01 at 00:57 +0000, Richard Hughes wrote:
> > On Tue, 2006-02-28 at 16:52 -0800, alan wrote:
> > > On Tue, 28 Feb 2006, Louis E Garcia II wrote:
> > >
> > > > Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
> > > > think it is actually slower.
> > >
> > > glx-utils
> > >
> > > I have stopped using ati due to support issues.  nVIDIA may have closed
> > > source drivers, but they have at least supported everything with them.
> > > (ATI's support with their closed source driver depends on picking the
> > > right card.)
> >
> > So if I was buying a new laptop sometime soonish, what chipset is best
> > for all this new accelerated X stuff?
> >
> > ati seems to not care about Linux, and I've heard bad things about
> > nvidia. I don't do games, so 3D isn't that important.
>
> go intel.. intel video is well supported and open
> (David will now say that it uses the bios to do mode setting and that it
> thus isn't fully open, but i'll ignore him for now :)


My own experience is that  Intel should be avoided -  I have to run
magic little programs setting magic little parameters to get  anything
beyond  plain VESA in low colors.

I bought Intel that time because I thought it was open, but low
performing. Only the latter is true, however, and native ATI/Nvidia
work better out of the box.

3D is missing with the bundled drivers, of course, but if you wanted
3D, you wouldn't go Intel anyway.

My recommendation would be NVidia - best out of the box 2D, and if you
want, the best 3D (closed source)
--
Trond Eivind Glomsr?d
Oslo, Norway



From gilboad at gmail.com  Wed Mar  1 20:02:34 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 01 Mar 2006 22:02:34 +0200
Subject: [Semi-OT] GCC 4.1 is out.
Message-ID: <1141243354.17966.2.camel@gilboa-home-dev.localhost>

http://gcc.gnu.org/
http://gcc.gnu.org/gcc-4.1/changes.html

I assume 4.1 final will make its way into FC5-release?

Gilboa



From benjy.grogan at gmail.com  Wed Mar  1 20:36:25 2006
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Wed, 1 Mar 2006 15:36:25 -0500
Subject: [Semi-OT] GCC 4.1 is out.
In-Reply-To: <1141243354.17966.2.camel@gilboa-home-dev.localhost>
References: <1141243354.17966.2.camel@gilboa-home-dev.localhost>
Message-ID: <d82d6db50603011236k359c6a85md7884378d600bd5b@mail.gmail.com>

It's already in rawhide as of March 1st.

On 3/1/06, Gilboa Davara <gilboad at gmail.com> wrote:
>
> http://gcc.gnu.org/
> http://gcc.gnu.org/gcc-4.1/changes.html
>
> I assume 4.1 final will make its way into FC5-release?
>
> Gilboa
>
> --
> 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/20060301/2585f886/attachment.htm>

From thacker at math.cornell.edu  Wed Mar  1 20:36:27 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Wed, 1 Mar 2006 15:36:27 -0500
Subject: [Semi-OT] GCC 4.1 is out.
In-Reply-To: <1141243354.17966.2.camel@gilboa-home-dev.localhost>
References: <1141243354.17966.2.camel@gilboa-home-dev.localhost>
Message-ID: <20060301203627.GA32214@localhost.localdomain>

On Wed, Mar 01, 2006 at 10:02:34PM +0200, Gilboa Davara wrote:
> http://gcc.gnu.org/
> http://gcc.gnu.org/gcc-4.1/changes.html
> 
> I assume 4.1 final will make its way into FC5-release?

Did you look at today's Rawhide update?

* Tue Feb 28 2006 Jakub Jelinek <jakub at redhat.com> 4.1.0-1
- update from gcc-4_1-branch (-r111466:111570)
  - GCC 4.1.0 release
  - PR other/26473

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060301/5359d60e/attachment.sig>

From icon at fedoraproject.org  Wed Mar  1 20:37:42 2006
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Wed, 01 Mar 2006 15:37:42 -0500
Subject: gnome trash
In-Reply-To: <1141240004.2283.3.camel@soncomputer>
References: <1141240004.2283.3.camel@soncomputer>
Message-ID: <44060616.6070005@fedoraproject.org>

Louis E Garcia II wrote:
> This is why I posted here. I am having trouble with gnome trash. ~.Trash
> has items but the trash bin is empty. This only happen with current
> rawhide. Anyone else see this?

Yep. Just found 14G of of ISOs in there that I thought were long gone. 
Empty Trash seems to not actually delete stuff, apparently.

Regards,
-- 
Konstantin Ryabitsev
McGill University WSG

Mal: "Dear Buddha: please send me a pony, and a plastic rocket, and..."
				--"Serenity"



From jbarnes at virtuousgeek.org  Wed Mar  1 20:41:42 2006
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Wed, 1 Mar 2006 12:41:42 -0800
Subject: gphoto2 problem: usb access for non root users
In-Reply-To: <561c252c0602281320v7254d1dap@mail.gmail.com>
References: <561c252c0601311402s2dfa06d3s@mail.gmail.com>
	<561c252c0602272305j3ce08b12o@mail.gmail.com>
	<561c252c0602281320v7254d1dap@mail.gmail.com>
Message-ID: <200603011241.42728.jbarnes@virtuousgeek.org>

> so it seems to me a problem in konqueror plugin (which one?) to read
> digicamera contents.

Yeah, I see the same thing too if I use the system:/ kioslave.  camera:/ 
still seems to work fine though.  To summarize:
  o permissions are still set incorrectly as of my 'yum upgrade' today
  o system:/media/camera kioslave is broken and doesn't list camera
    contents correctly (folders show up as files)

I'll look around and see if the HAL callout bug has been filed and/or 
fixed.

Jesse



From sundaram at fedoraproject.org  Wed Mar  1 20:44:45 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 02 Mar 2006 02:14:45 +0530
Subject: gnome trash
In-Reply-To: <44060616.6070005@fedoraproject.org>
References: <1141240004.2283.3.camel@soncomputer>
	<44060616.6070005@fedoraproject.org>
Message-ID: <440607BD.2090906@fedoraproject.org>

Konstantin Ryabitsev wrote:

> Louis E Garcia II wrote:
>
>> This is why I posted here. I am having trouble with gnome trash. ~.Trash
>> has items but the trash bin is empty. This only happen with current
>> rawhide. Anyone else see this?
>
>
> Yep. Just found 14G of of ISOs in there that I thought were long gone. 
> Empty Trash seems to not actually delete stuff, apparently.

Hmm. works fine here.

-- 
Rahul 





From theaton at lanl.gov  Wed Mar  1 20:49:28 2006
From: theaton at lanl.gov (Tony Heaton)
Date: Wed, 01 Mar 2006 13:49:28 -0700
Subject: gnome trash
In-Reply-To: <440607BD.2090906@fedoraproject.org>
References: <1141240004.2283.3.camel@soncomputer>
	<44060616.6070005@fedoraproject.org>
	<440607BD.2090906@fedoraproject.org>
Message-ID: <1141246168.5492.10.camel@mlor.frop.net>

> > Louis E Garcia II wrote:
> >
> >> This is why I posted here. I am having trouble with gnome trash. ~.Trash
> >> has items but the trash bin is empty. This only happen with current
> >> rawhide. Anyone else see this?

It may be just a typo above, but .Trash is in ~/.Trash.


-- 
Tony Heaton
CCN-9
(505)667-9015
Pager (505)996-3184
theaton at lanl.gov

- "If you do nothing, they'll win"

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

From gilboad at gmail.com  Wed Mar  1 21:08:28 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 01 Mar 2006 23:08:28 +0200
Subject: [Semi-OT] GCC 4.1 is out.
In-Reply-To: <20060301203627.GA32214@localhost.localdomain>
References: <1141243354.17966.2.camel@gilboa-home-dev.localhost>
	<20060301203627.GA32214@localhost.localdomain>
Message-ID: <1141247308.17966.4.camel@gilboa-home-dev.localhost>

On Wed, 2006-03-01 at 15:36 -0500, John Thacker wrote:
> On Wed, Mar 01, 2006 at 10:02:34PM +0200, Gilboa Davara wrote:
> > http://gcc.gnu.org/
> > http://gcc.gnu.org/gcc-4.1/changes.html
> > 
> > I assume 4.1 final will make its way into FC5-release?
> 
> Did you look at today's Rawhide update?
> 
> * Tue Feb 28 2006 Jakub Jelinek <jakub at redhat.com> 4.1.0-1
> - update from gcc-4_1-branch (-r111466:111570)
>   - GCC 4.1.0 release
>   - PR other/26473
> 

Somehow I missed it.

Thanks.



From louisg00 at bellsouth.net  Wed Mar  1 21:28:45 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Wed, 01 Mar 2006 16:28:45 -0500
Subject: gnome trash
In-Reply-To: <1141240004.2283.3.camel@soncomputer>
References: <1141240004.2283.3.camel@soncomputer>
Message-ID: <1141248525.22829.7.camel@soncomputer>

Seems to occur with user accounts. root is ok.

--Louis 


On Wed, 2006-03-01 at 14:06 -0500, Louis E Garcia II wrote:
> This is why I posted here. I am having trouble with gnome trash. ~.Trash
> has items but the trash bin is empty. This only happen with current
> rawhide. Anyone else see this?
> 
> --Louis
> 
> > This is not a general Linux support list. Please, post to
> > "fedora-list" or elsewhere.
> > 
> > Thanks.
> >
> > > Where are the file I delete from nautilus going? Because it's not going
> > > in Trash.
> > >
> > > --Louis



From wesley at bu.edu  Wed Mar  1 21:53:18 2006
From: wesley at bu.edu (Wesley Harrell)
Date: Wed, 1 Mar 2006 16:53:18 -0500
Subject: Yum plugin installonlyn packaging
Message-ID: <20060301215318.GA22532@hogtown.bu.edu>

This question is specifically about the installonlyn plugin,
but is also a question regarding yum plugin packaging in general.

Currently I see the installonlyn plugin included in the fedora 
yum-2.5 srpm, but was expecting to see it in the extras yum-utils, 
since I have seen other plugins within the yum-utils including 
changelog and fastestmirror.

Is placing installonlyn within yum just a one off, or are certain 
plugins going to make it into yum, while others are in yum-utils?
Currently it is a bit confusing, since I am expecting to look 
for plugins in yum-utils and would be more inclined to add a 
plugin to yum-utils, rather than yum.

cheers,

-- 
wesley



From mharris at mharris.ca  Wed Mar  1 21:59:17 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Wed, 01 Mar 2006 16:59:17 -0500
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
In-Reply-To: <4405672D.7080205@mharris.ca>
References: <4405672D.7080205@mharris.ca>
Message-ID: <44061935.9060200@mharris.ca>

Mike A. Harris wrote:
> This should resolve various keyboard quirks that have been reported
> in different components throughout FC5 testing, but may introduce
> a few new bugs too.  Overall, since it is the only maintained
> xkbdata however, even if there are a few bumps, they'll be ironed
> out via modular package updates easily enough, unlike the situation
> we'd have if we shipped the X.Org xkbdata and let it rot.
> 
> Hope your keyboards all do the happy dance now.

Update:

Some backward compatible options were disabled in the
xorg-x11-xkbdata-1.0.1-5 build which contains xkeyboard-config.

This has caused some problems for various users, and has been
fixed in the 1.0.1-6 release.  If you are experiencing any problems
with the 1.0.1-5 release, before filing a bug report in bugzilla,
please update to the -6 release, which can be found at:

xorg-x11-xkbdata-1.0.1-6 is now available for download via ftp at the 
following URL:  ftp://people.redhat.com/mharris/testing/unstable

After updating to -6, and restarting X, if you still have problems,
please search bugzilla to see if it has been reported already or not
(we get a lot of dupes for things like this, please help to limit
them), and if nobody's reported it yet, please file a new bug and
we'll go from there.

Thanks again to all the people testing FC5 development!


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From sundaram at fedoraproject.org  Wed Mar  1 22:00:27 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 02 Mar 2006 03:30:27 +0530
Subject: Yum plugin installonlyn packaging
In-Reply-To: <20060301215318.GA22532@hogtown.bu.edu>
References: <20060301215318.GA22532@hogtown.bu.edu>
Message-ID: <4406197B.1040504@fedoraproject.org>

Wesley Harrell wrote:

>This question is specifically about the installonlyn plugin,
>but is also a question regarding yum plugin packaging in general.
>
>Currently I see the installonlyn plugin included in the fedora 
>yum-2.5 srpm, but was expecting to see it in the extras yum-utils, 
>since I have seen other plugins within the yum-utils including 
>changelog and fastestmirror.
>
>Is placing installonlyn within yum just a one off, or are certain 
>plugins going to make it into yum, while others are in yum-utils?
>Currently it is a bit confusing, since I am expecting to look 
>for plugins in yum-utils and would be more inclined to add a 
>plugin to yum-utils, rather than yum.
>
>  
>
Upstream yum package does not include any plugins by default. Placing 
installonlyn in the Yum package itself is a one off at this point since 
it was written by Jeremy Katz to provide this functionality by default 
since there are a large number of kernel updates in Fedora and removing 
older kernels is a FAQ in the Fedora lists and forums not to mention the 
space wastage and confusion with multiple kernels despite the GRUB menu 
hiding it but if there are other good plugins that are required by 
default, it might become part of Yum in Fedora Core rather than 
Yum-utils in Fedora Extras.

-- 
Rahul 





From vd at paradigma.pt  Wed Mar  1 00:49:12 2006
From: vd at paradigma.pt (Vitor Domingos)
Date: Wed, 01 Mar 2006 00:49:12 +0000
Subject: aiglx
Message-ID: <4404EF88.4080000@paradigma.pt>

Is AIGLX going to appear on FC5? I've test it with ATI RADEON 7000, with 
all the hacks that's on the wiki page, and it's too dam slow....

-- 
Vitor Domingos
Paradigma.pt



From nicolas.mailhot at laposte.net  Wed Mar  1 23:03:33 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 02 Mar 2006 00:03:33 +0100
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
In-Reply-To: <4405672D.7080205@mharris.ca>
References: <4405672D.7080205@mharris.ca>
Message-ID: <1141254213.11543.4.camel@rousalka.dyndns.org>

Hi Mike

I just wanted to report a direct result of the change here is the gnome
keyboard switcher started working again in Rawhide (after months of
misbehaviour)

Thanks for making the switch. I know it was a hard decision to make just
before a release. Even if the xkbdata core contributors made it pretty
clear they only cared about xkeyboard-config nowadays.

Regards,

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

From sundaram at fedoraproject.org  Wed Mar  1 23:09:10 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 02 Mar 2006 04:39:10 +0530
Subject: aiglx
In-Reply-To: <4404EF88.4080000@paradigma.pt>
References: <4404EF88.4080000@paradigma.pt>
Message-ID: <44062996.7000907@fedoraproject.org>

Vitor Domingos wrote:

> Is AIGLX going to appear on FC5? I've test it with ATI RADEON 7000, 
> with all the hacks that's on the wiki page, and it's too dam slow....
>
Some of the pieces are already integrated. See the section on technical 
details for the current status. 
http://fedoraproject.org/wiki/RenderingProject/aiglx.  Since the 
features are not enabled by default, yet performance shouldnt be much of 
a concern for FC5. Reports with hardware details and benchmarks would be 
quite useful to fine tune it I guess.


-- 
Rahul 





From mharris at mharris.ca  Wed Mar  1 23:12:56 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Wed, 01 Mar 2006 18:12:56 -0500
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
In-Reply-To: <1141254213.11543.4.camel@rousalka.dyndns.org>
References: <4405672D.7080205@mharris.ca>
	<1141254213.11543.4.camel@rousalka.dyndns.org>
Message-ID: <44062A78.8010500@mharris.ca>

Nicolas Mailhot wrote:
> Hi Mike
> 
> I just wanted to report a direct result of the change here is the gnome
> keyboard switcher started working again in Rawhide (after months of
> misbehaviour)
> 
> Thanks for making the switch. I know it was a hard decision to make just
> before a release. Even if the xkbdata core contributors made it pretty
> clear they only cared about xkeyboard-config nowadays.

Yeah, the long term goal has always been to switch to xkeyboard-config
ever since it split off from XFree86 when X.Org revitalized itself.

However, while Xorg was still monolithic it made sense to use what
X.Org shipped rather than trying to hack on the xkeyboard-config
bits.  Also some people had concerns about backward compatibility
and other stuff.

With X11R7, upstream wanted to keep using the unmaintained data for
some reason, which had to do with um...  ok, I don't know.  Silly
worries or something.  ;o)

There were a few other things I'm struggling to try and forget now,
so I wont bore you. ;)

Even if things break for people now, we are in the best position
going forward with xkeyboard-config IMHO.  Mainly because bugs
in xkbdata are more or less permanent "so sorry, deal with it"
in nature. ;o)

Hopefully xkeyboard-config transition is smooth for FC5 now.


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mharris at mharris.ca  Wed Mar  1 23:17:08 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Wed, 01 Mar 2006 18:17:08 -0500
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <d8dc7cba0603011119s26ab8513s5a60fd37583bfbb@mail.gmail.com>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
	<d8dc7cba0603011119s26ab8513s5a60fd37583bfbb@mail.gmail.com>
Message-ID: <44062B74.3060200@mharris.ca>

Trond Eivind Glomsr?d wrote:
>>>So if I was buying a new laptop sometime soonish, what chipset is best
>>>for all this new accelerated X stuff?
>>>
>>>ati seems to not care about Linux, and I've heard bad things about
>>>nvidia. I don't do games, so 3D isn't that important.
>>
>>go intel.. intel video is well supported and open
>>(David will now say that it uses the bios to do mode setting and that it
>>thus isn't fully open, but i'll ignore him for now :)
> 
> My own experience is that  Intel should be avoided -  I have to run
> magic little programs setting magic little parameters to get  anything
> beyond  plain VESA in low colors.
> 
> I bought Intel that time because I thought it was open, but low
> performing. Only the latter is true, however, and native ATI/Nvidia
> work better out of the box.
> 
> 3D is missing with the bundled drivers, of course, but if you wanted
> 3D, you wouldn't go Intel anyway.
> 
> My recommendation would be NVidia - best out of the box 2D, and if you
> want, the best 3D (closed source)

I disagree with everyone.  ;o)

My recommendation, is to use Xvfb or the text console.  Almost no
hardware/driver related bugs/problems, and no big concerns over
openness of the code/specs/etc. ;o)





-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From wart at kobold.org  Thu Mar  2 00:09:48 2006
From: wart at kobold.org (Michael Thomas)
Date: Wed, 01 Mar 2006 16:09:48 -0800
Subject: games user and group
In-Reply-To: <1141239220.4380.12.camel@canyon.wittsend.com>
References: <4404EB4A.40304@kobold.org>	<20060301012526.GA14476@devserv.devel.redhat.com>	<4404F923.5070807@kobold.org>	<e99d27470603010812pb34b038o@mail.gmail.com>	<4405D7FB.3080505@kobold.org>
	<1141239220.4380.12.camel@canyon.wittsend.com>
Message-ID: <440637CC.8070201@kobold.org>

Michael H. Warfield wrote:
> On Wed, 2006-03-01 at 09:20 -0800, Michael Thomas wrote:
> 
>>Rudolf Kastl wrote:
>>
>>>id personally suggest to treat gamedaemons like other daemons and
>>>create seperate system users for the game server processes.
>>>A server is a server. Functionality differs but is rather irrelevant
>>>in my eyes regarding the system users for the services.
> 
> 
>>I won't argue that it would be more secure, but couldn't security also
>>be accomplished with an appropriate set of selinux policies?
> 
> 
> 	Only if you have selinux enabled.
> 
> 	Make it (more) secure FIRST.  Then add additional security from
> selinux.  What you don't want is someone ending up insecure just because
> they have selinux turned off.  That's a wrong answer.  That's then
> depending on selinux for your security rather than using selinux to
> enhance your security.  Too many eggs in one basket.

Right.  It seems the concensus is to use different users, and selinux,
if used, would be layered on top of that.

So what is the use of the 'games' user on the system if it isn't used
for game servers?  I can't see how setuid games would be acceptible for
similar reasons.  Or is this user legacy cruft that should just be ignored?

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

From jspaar at users.sourceforge.net  Thu Mar  2 01:13:28 2006
From: jspaar at users.sourceforge.net (Jack Spaar)
Date: Wed, 01 Mar 2006 17:13:28 -0800
Subject: Announcement: update RPMs using delta compression for low
	bandwidth	users
References: <1cef3e950602281018l69a9eecdre17e4460a217361d@mail.gmail.com>
Message-ID: <pan.2006.03.02.01.13.25.74830@users.sourceforge.net>

On Tue, 28 Feb 2006 18:18:36 +0000, Joe Desbonnet wrote:

> This software is for individual Fedora users and sys-admins who need to
> update one or more Fedora systems that are connected to the internet
> with low to medium bandwidth link (eg dialup, ISDN, satellite).
> 

I couldn't get tomcat going on FC4 easily (first time messing with it). 
So I set up tomcat on a rawhide box and pointed it to your test repo of
deltas and a local copy of FC4 base RPMS.  Then I was able to update an
FC4 box by changing only the /etc/yum.repos.d/fedora-updates.repo to use
that rawhide box as a yum virtual repo.  It worked great.

A few notes:

A typo in the manual (http://www.wombat.ie/software/rpmdc/manual.html):
>In the 'updates-released' section
>of the file change the baseurl to
>
>baseurl=http://localhost:8080/RPMDC/repo/pub/fedora/linux/core/$releasever/$basearch/os/

Should be:
.../core/updates/$releasever/$basearch/

IMO it would also be handy to have a link to the RPMDC download in the
installation section of the RPMDC manual.

Rpm-devel is required to compile deltarpm (this will be obvious to
some from the compiler errors about missing includes).

RPMDC wouldn't compile on the rawhide box [(GCC) 4.1.0 20060219 (Red
Hat 4.1.0-0.29)] like it would on FC4, but the .war provided in the binary
tarball ran just fine.

Tomcat needed the xml-commons-apis package to keep it from complaining at
startup.

Neat project!

--Jack Spaar



From ndbecker2 at gmail.com  Thu Mar  2 01:25:30 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 01 Mar 2006 20:25:30 -0500
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
References: <4405672D.7080205@mharris.ca> <44061935.9060200@mharris.ca>
Message-ID: <du5hia$bp0$1@sea.gmane.org>

Mike A. Harris wrote:

> Mike A. Harris wrote:
>> This should resolve various keyboard quirks that have been reported
>> in different components throughout FC5 testing, but may introduce
>> a few new bugs too.  Overall, since it is the only maintained
>> xkbdata however, even if there are a few bumps, they'll be ironed
>> out via modular package updates easily enough, unlike the situation
>> we'd have if we shipped the X.Org xkbdata and let it rot.
>> 
>> Hope your keyboards all do the happy dance now.
> 
> Update:
> 
> Some backward compatible options were disabled in the
> xorg-x11-xkbdata-1.0.1-5 build which contains xkeyboard-config.
> 
> This has caused some problems for various users, and has been
> fixed in the 1.0.1-6 release.  If you are experiencing any problems
> with the 1.0.1-5 release, before filing a bug report in bugzilla,
> please update to the -6 release, which can be found at:
> 
> xorg-x11-xkbdata-1.0.1-6 is now available for download via ftp at the
> following URL:  ftp://people.redhat.com/mharris/testing/unstable
> 
> After updating to -6, and restarting X, if you still have problems,
> please search bugzilla to see if it has been reported already or not
> (we get a lot of dupes for things like this, please help to limit
> them), and if nobody's reported it yet, please file a new bug and
> we'll go from there.
> 
> Thanks again to all the people testing FC5 development!
> 
> 

Thanks!  That fixed no keyboard layouts showing up in kde control panel.



From jdesbonnet at gmail.com  Thu Mar  2 02:42:45 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Thu, 2 Mar 2006 02:42:45 +0000
Subject: Announcement: update RPMs using delta compression for low
	bandwidth users
In-Reply-To: <pan.2006.03.02.01.13.25.74830@users.sourceforge.net>
References: <1cef3e950602281018l69a9eecdre17e4460a217361d@mail.gmail.com>
	<pan.2006.03.02.01.13.25.74830@users.sourceforge.net>
Message-ID: <1cef3e950603011842t46746eaes4cadc72f0b39a01a@mail.gmail.com>

Jack,
Thanks for the feedback. Typos noted. I've just setup FC5test3 on a
VMWare virtual machine and looking into those issues now.
Regards,
Joe.


On 3/2/06, Jack Spaar <jspaar at users.sourceforge.net> wrote:
> On Tue, 28 Feb 2006 18:18:36 +0000, Joe Desbonnet wrote:
>
> > This software is for individual Fedora users and sys-admins who need to
> > update one or more Fedora systems that are connected to the internet
> > with low to medium bandwidth link (eg dialup, ISDN, satellite).
> >
>
> I couldn't get tomcat going on FC4 easily (first time messing with it).
> So I set up tomcat on a rawhide box and pointed it to your test repo of
> deltas and a local copy of FC4 base RPMS.  Then I was able to update an
> FC4 box by changing only the /etc/yum.repos.d/fedora-updates.repo to use
> that rawhide box as a yum virtual repo.  It worked great.
>
> A few notes:
>
> A typo in the manual (http://www.wombat.ie/software/rpmdc/manual.html):
> >In the 'updates-released' section
> >of the file change the baseurl to
> >
> >baseurl=http://localhost:8080/RPMDC/repo/pub/fedora/linux/core/$releasever/$basearch/os/
>
> Should be:
> .../core/updates/$releasever/$basearch/
>
> IMO it would also be handy to have a link to the RPMDC download in the
> installation section of the RPMDC manual.
>
> Rpm-devel is required to compile deltarpm (this will be obvious to
> some from the compiler errors about missing includes).
>
> RPMDC wouldn't compile on the rawhide box [(GCC) 4.1.0 20060219 (Red
> Hat 4.1.0-0.29)] like it would on FC4, but the .war provided in the binary
> tarball ran just fine.
>
> Tomcat needed the xml-commons-apis package to keep it from complaining at
> startup.
>
> Neat project!
>
> --Jack Spaar
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From casimiro.barreto at gmail.com  Thu Mar  2 03:40:47 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Thu, 02 Mar 2006 00:40:47 -0300
Subject: Brazilian ABNT-2 Keyboard wrong with the last update
Message-ID: <4406693F.7030308@gmail.com>

Hello,

Brazilian ABNT-2 Keyboard got messed in the last fedora update. 
Particularly quotation mark-stroke key got dead (so there are no ways to 
write pathnames). Number pad became really the number-pad (no home, 
arrows or other functions). Combination of control+alt+function-key 
don't switch to console ...

Best regards

Casimiro



From jkeating at redhat.com  Thu Mar  2 07:55:02 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 01 Mar 2006 23:55:02 -0800
Subject: Udev issues in today's coming rawhide
Message-ID: <1141286103.31231.104.camel@ender>

We're attempting to fix a problem in udev where /dev/cdrom creation is a
race between multiple optical devices in a system.  To work around this
we will enumerate the devices as /dev/cdrom-hdc or /dev/cdrom-hdb.
However for compatibility reasons, we'll still create a /dev/cdrom, and
the last device found wins the race.

However in the udev package found in today's rawhide, /dev/cdrom is not
being created at all.  This is fixed in a newer package, but did not
make the rawhide push.  If you have issues with udev and /dev/cdrom,
please update to the udev package found here:

http://people.redhat.com/jkeating/udev-hotfix/

If you notice an application you use that depends on a /dev/cdrom entry,
please let us know so that we can investigate fixes for this improper
behavior.

Cheers! 
-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060301/262613bf/attachment.sig>

From dax at gurulabs.com  Thu Mar  2 07:55:33 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Thu, 02 Mar 2006 00:55:33 -0700
Subject: username best practices and other conventions
Message-ID: <1141286133.4207.36.camel@mentorng.gurulabs.com>

I was wondering if Fedora had any guidelines for valid usernames.
Especially usernames that are part of base and extra packages?

Since, well forever, I've understood the UNIX and Linux username best
practices to be:

(a) all lowercase
(b) alphanumeric with exception that first char must not be a number
(c) 8 char max length

The origin of (a) I believe comes from the fact that historically there
was a one-to-one mapping between email addresses and usernames and since
email addresses are not case sensitive, usernames that only differ by
case cause email ambiguities.

I'm not sure the origin of (b).

The origin of (c) comes from the fact that's the way it has always been
and older tools and file formats make only have room for 8 characters
such as old tar or cpio. Additionally once a username exceeds 8
characters some tools such as /bin/ps and /bin/ls start behaving
differently. This can cause a cascade problem when sys admins write
elaborate scripts or even one-off temporary scripts that because
non-temporary and parse the output of /bin/ps or /bin/ls.

For example, a script that is expecting the first column of /bin/ps
output to be a username, might go bonkers if it encounters:

avahi     2250  0.0  0.0   2744   436 ?        Ss   Mar01   0:00 avahi-daemon: chroot helper process
root      2259  0.0  0.0   3084  1172 ?        Ss   Mar01   0:00 cups-config-daemon
68        2269  0.0  0.1   5072  3476 ?        Ss   Mar01   0:02 hald
root      2270  0.0  0.0   3084  1140 ?        S    Mar01   0:00 hald-runner
68        2276  0.0  0.0   2192   896 ?        S    Mar01   0:00 /usr/libexec/hald-addon-acpi
68        2285  0.0  0.0   2196   900 ?        S    Mar01   0:00 /usr/libexec/hald-addon-keyboard
root      2292  0.0  0.0   2152   840 ?        S    Mar01   0:00 /usr/libexec/hald-addon-storage
root      2305  0.0  0.0   1548   448 tty2     Ss+  Mar01   0:00 /sbin/mingetty tty2

IMHO, Fedora should respect the traditional best practices and
conventions (not speaking solely about usernames) and not violate them
without good reason. It seems there is maybe a carefree indifference or
possibly ignorant attitude about the "old ways". Breaking long standing
conventions in itself violates the principal of least surprise --
something sys admins do not care for.

In regards to the username violations on my FC4 box I see three
usernames exceeding the 8 characters in length and on my rawhide box I
see five. It is getting worse.

For the sake of conversation here is list from a fresh rawhide install
with a moderate amount of packages installed.

lp = 2
adm = 3
bin = 3
ftp = 3
gdm = 3
ntp = 3
rpc = 3
rpm = 3
xfs = 3
dbus = 4
halt = 4
mail = 4
news = 4
nscd = 4
pcap = 4
root = 4
sshd = 4
sync = 4
uucp = 4
vcsa = 4
avahi = 5
games = 5
named = 5
smmsp = 5
squid = 5
apache = 6
daemon = 6
gopher = 6
nobody = 6
netdump = 7
rpcuser = 7
torrent = 7
mailnull = 8
operator = 8
shutdown = 8
distcache = 9
haldaemon = 9
nfsnobody = 9
webalizer = 9
beagleindex = 11

It isn't a universal trend, but it seems that the newer the program the
longer the username.

Any comments from the powers that be on this topic? Personally I'd love
to see these 9+ usernames "fixed".

Dax (getting a grey goatee) Kelson




From buildsys at redhat.com  Thu Mar  2 08:17:07 2006
From: buildsys at redhat.com (Build System)
Date: Thu, 2 Mar 2006 03:17:07 -0500
Subject: rawhide report: 20060302 changes
Message-ID: <200603020817.k228H7AE001227@porkchop.devel.redhat.com>

 

Removed package bogl

Updated Packages:

Guppi-0.40.3-25
---------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 0.40.3-25
- BuildPreReq: libSM-devel

NetworkManager-0.5.1-18.cvs20060301
-----------------------------------
* Wed Mar 01 2006 Dan Williams <dcbw at redhat.com> 0.5.1-18.cvs20060301
- Fix VPN-related crash
- Fix issue where NM would refuse to activate a VPN connection once it had timed out
- Log wpa_supplicant output for better debugging

autoconf213-2.13-11
-------------------
* Mon Feb 27 2006 Karsten Hopp <karsten at redhat.de> 2.13-11
- BuildRequire m4 (#181959)

axis-0:1.2.1-2jpp_1fc
---------------------
* Wed Mar 01 2006 Archit Shah <ashah at redhat.com> 0:1.2.1-2jpp_1fc
- remove unnecessary build dependencies on jacorb and jonathan-rmi
- include fix to Axis bug 2142
- merge from upstream 2jpp

beagle-0.2.1-15
---------------
* Wed Mar 01 2006 Matthias Clasen <mclasen at redhat.com> 0.2.1-15
- Bump log level to "error" to avoid tons of
  pointless warnings. (#183162)

* Wed Mar 01 2006 Matthias Clasen <mclasen at redhat.com> 0.2.1-14
- Fix a typo in /etc/beagle/crawl-applications

* Wed Mar 01 2006 Ray Strode <rstrode at redhat.com> 0.2.1-13
- add patch from  Felipe Alfaro Solana <felipe_alfaro at linuxmail.org>
  to invote beagle indexing helper function with valid shell
  (bug 183360)

cairo-java-1.0.2.0.20060301.rh1-0
---------------------------------
* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 1.0.2.0.20060301.rh1-0
- Increased version of required glib-java to 0.2.3.0.20060301.rh1.
- Imported new tarball to address bg #183538.

cman-1.0.5-0.FC5.0
------------------
* Wed Mar 01 2006 Chris Feist <cfeist at redhat.com>
- Rebuilt w/ new upstream sources

dbus-0.61-3
-----------
* Fri Feb 24 2006 John (J5) Palmieri <johnp at redhat.com> 0.61-2
- ABI hasn't changed so add patch that makes dbus-sharp think
  it is still 0.60 (mono uses hard version names so any change
  means apps need to recompile)

* Fri Feb 24 2006 John (J5) Palmieri <johnp at redhat.com> 0.61-2
- Make sure chkconfig rests the priorities so we can start earlier

* Fri Feb 24 2006 John (J5) Palmieri <johnp at redhat.com> 0.61-1
- Upgrade to upstream version 0.61
- remove python callchain patch
- update avc patch

desktop-printing-0.19-6
-----------------------
* Mon Feb 20 2006 Karsten Hopp <karsten at redhat.de> 0.19-6
- BuildRequire libXScrnSaver-devel for libXss

diskdumputils-1.2.8-4
---------------------
* Mon Feb 20 2006 Karsten Hopp <karsten at redhat.de> 1.2.8-4
- BuildRequires: zlib-devel

ekiga-1.99.1-2
--------------
* Mon Feb 20 2006 Karsten Hopp <karsten at redhat.de> 1.99.1-2
- Buildrequires: gnome-doc-utils

emacs-21.4-13
-------------
* Mon Feb 27 2006 Jens Petersen <petersen at redhat.com> - 21.4-13
- buildrequire libXaw-devel for menus and scrollbar
- pass -R to setarch to disable address randomization during dumping
  (Sam Peterson, #174736)
- install cc-mode.info correctly (Sam Peterson, #182084)
- fix sort-columns not to use deprecated non-posix sort key syntax
  with sort-columns-posix-key-182282.patch (Richard Ryniker, #182282)
- use system-name function not variable when setting frame-title-format in
  /etc/skel/.emacs for XEmacs users hitting .emacs

evince-0.5.1-2
--------------
* Wed Mar 01 2006 Kristian H??gsberg <krh at redhat.com> - 0.5.1-2
- Rebuild to pick up new poppler soname.

evolution-sharp-0.10.2-9
------------------------
* Tue Feb 21 2006 Karsten Hopp <karsten at redhat.de> 0.10.2-9
- BuildRequire gtk-sharp2

firstboot-1.4.5-1
-----------------
* Wed Mar 01 2006 Chris Lumens <clumens at redhat.com> 1.4.5-1
- Run if RUN_FIRSTBOOT != "NO" (#180520).
- Don't let dialog windows hide behind the main window.
- Remove timeout waiting for server to start.

fonts-ISO8859-2-1.0-17
----------------------
* Tue Feb 21 2006 Karsten Hopp <karsten at redhat.de> 1.0-17
- BuildRequire xorg-x11-font-utils

frysk-0.0.1.2006.02.19.rh2-0.FC5.1
----------------------------------
* Wed Mar 01 2006 Andrew Cagney <cagney at redhat.de> 0.0.1.2006.02.19.rh2-0.FC5.1
- Add dependencies on latest Java-GNOME bindings.

* Wed Mar 01 2006 Andrew Cagney <cagney at redhat.de> 0.0.1.2006.02.19.rh2-0.FC5.0
- Import frysk 0.0.1.2006.02.19.rh2; works around bug #180637.
- Enable x86_64, update *-java BuildRequires; fix bug #183538.

* Tue Feb 21 2006 Karsten Hopp <karsten at redhat.de> 0.0.1.2006.02.19.rh1-0.FC5.1
- BuildRequires: xmlto

gdk-pixbuf-1:0.22.0-22
----------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 0.22.0-22
- BuildRequires: libXt-devel

gecko-sharp2-0.11-6
-------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 0.11-6
- BuildRequires: gtk2-devel

gedit-1:2.13.92-2
-----------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.13.92-2	
- BuildRequire: gnome-doc-utils

ghostscript-8.15.1-6
--------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 8.15.1-6
- BuildRequires: libXt-devel

gimp-print-4.2.7-16
-------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 4.2.7-16
- BuildRequires: libjpeg-devel

gkrellm-2.2.7-7
---------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.2.7-7
- BuildRequires: libSM-devel

glib-java-0.2.3.0.20060301.rh1-1
--------------------------------
* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 0.2.3.0.20060301.rh1-1
- Imported new tarball to address bg #183538.

gnome-applets-1:2.13.90-3
-------------------------
* Wed Mar 01 2006 Ray Strode <rstrode at redhat.com> - 2.13.90-3
- More stock ticker fun (bug 179528)

* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.13.90-2
- BuildRequires: which

gnome-desktop-2.13.92-2
-----------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.13.92-2
- BuildRequires: gnome-doc-utils

gnome-keyring-manager-2.12.0-3
------------------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.12.0-3
- BuildRequires: gnome-doc-utils

gnome-libs-1:1.4.1.2.90-49
--------------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 1.4.1.2.90-49
- Buildrequires: libXt-devel

gnome-mag-0.12.3-3
------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 0.12.3-3
- BuildRequires: libXt-devel

gnome-mount-0.4-3
-----------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 0.4-3
- add some buildrequires

gnome-nettool-2.13.90-2
-----------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 2.13.90-2
- BuildRequires: desktop-file-utils for desktop-file-install

gnome-panel-2.13.91-5
---------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.13.91-5
- Buildrequires: ORBit2-devel, which, libxml2-python, libX11-devel,
  libXt-devel, gnome-doc-utils, dbus-devel

gnome-power-manager-2.13.92-2
-----------------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.13.92-2
- Buildrequires: gnome-doc-utils

gnome-python2-extras-2.13.3-4
-----------------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.13.3-4
- Buildrequires: python-devel

gnome-screensaver-2.13.92-2
---------------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 2.13.92-2
- BuildRequires: libXmu-devel

gnome-session-2.13.92-2
-----------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 2.13.92-2
- BuildRequires: gnome-desktop-devel, libX11-devel, libXt-devel

gnome-user-share-0.9-3
----------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 0.9-3
- BuildRequires: gtk2-devel, libglade2-devel, libselinux-devel

gnome-utils-1:2.13.93-2
-----------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 2.13.93-2
- BuildRequires:  gnome-doc-utils

gnuplot-4.0.0-11
----------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 4.0.0-11
- BuildRequires: libXt-devel

gok-1.0.6-2
-----------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 1.0.6-2
- BuildRequires: libXt-devel

gsf-sharp-0.6-8
---------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 0.6-8
- Buildrequires: gtk-sharp2

gstreamer-plugins-base-0.10.3-3
-------------------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 0.10.3-3	
- really add BuildRequires: cdparanoia-devel (#179034)

* Mon Feb 20 2006 John (J5) Palmieri <johnp at redhat.com> - 0.10.3-2
- Obsolete gstreamer-plugins (Bug #182098)

gtk+-1:1.2.10-50
----------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 1.2.10-50
- BuildRequires: libXt-devel

gtk2-2.8.13-3
-------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 2.8.13-3
- Buildrequires: libXi-devel

* Mon Feb 27 2006 Ray Strode <rstrode at redhat.com> - 2.8.13-2
- s/Prereq/Requires/ for hicolor dep

* Sat Feb 25 2006 Matthias Clasen <mclasen at redhat.com> - 2.8.13-1
- Update to 2.8.13

gtkhtml-1.1.9-12
----------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 1.1.9-12
- Buildrequires: GConf-devel, freetype-devel, libSM-devel

hplip-0.9.8-6
-------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 0.9.8-6
- Buildrequires: desktop-file-utils

* Mon Feb 27 2006 Tim Waugh <twaugh at redhat.com> 0.9.8-5
- Patchlevel 4.

imake-1.0.1-2
-------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 1.0.1-2
- Buildrequires: xorg-x11-proto-devel

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> 1.0.1-1.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> 1.0.1-1.1
- rebuilt for new gcc4.1 snapshot and glibc changes

isdn4k-utils-3.2-40
-------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 3.2-40
- Buildrequires: libXp-devel

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_82rh
------------------------------------------
* Wed Mar 01 2006 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.4.2.0-40jpp_82rh
- Add chkconfig as a prerequisite.

* Wed Mar 01 2006 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.4.2.0-40jpp_81rh
- Natively compile BouncyCastle.
- Move bcprov in the build section so that it is found by bootstrap
  architectures in the install section.
- Only include BC library directory on non-boostrap architectures.

jessie-0:1.0.1-3
----------------
* Wed Mar 01 2006 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.0.1-3
- Bump release number.

* Wed Mar 01 2006 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.0.1-2
- Add : to end of CLASSPATH.
- Natively compile Jessie.

jfsutils-1.1.10-4
-----------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 1.1.10-4
- BuildRequires: e2fsprogs-devel

joe-3.3-2
---------
* Wed Mar 01 2006 Ivana Varekova <varekova at redhat.com> 3.3-2
- add forgotten header files - bug 183455

kdeaccessibility-1:3.5.1-2
--------------------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 3.5.1-2
- BuildRequires: libXtst-devel

ksh-20060124-3
--------------
* Mon Feb 27 2006 Karsten Hopp <karsten at redhat.de> 20060124-3
- PreReq grep, coreutils (#182835)

libgconf-java-2.12.1.0.20060301.rh1-0
-------------------------------------
* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 2.12.1.0.20060301.rh1-0
- Imported new tarball to address bg #183538, updated dependancies.

libglade-java-2.12.2.0.20060301.rh1-1
-------------------------------------
* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 2.12.2.0.20060301.rh1-1
- Bumped release, fixed typo in Requires.

* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 2.12.2.0.20060301.rh1-0
- Imported new tarball to address bg #183538, updated dependancies.

libgnome-java-2.12.1.0.20060301.rh1-0
-------------------------------------
* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 2.12.1.0.20060301.rh1-0
- Imported new tarball to address bug 183538, updated dependancies.

libgtk-java-2.8.3.0.20060301.rh1-0
----------------------------------
* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 2.8.3.0.20060301.rh1-0
- Imported new tarball to address bg #183538, updated dependancies.

libvte-java-0.11.11.0.20060301.rh1-1.2
--------------------------------------
* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 0.11.11.0.20060301.rh1-1.1
- Fixed typo in Requires.

* Wed Mar 01 2006 Adam Jocksch <ajocksch at redhat.com> - 0.11.11.0.20060301.rh1-1
- Imported new tarball to address bg #183538, updated dependancies.

m17n-db-1.3.3-1
---------------
* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com> - 1.3.3-1
- update to 1.3.3 bugfix release
- fixes to Bengali, Hindi, and Punjabi maps (runab, aalam)
- Tamil phonetic map now works
- new Tamil99 Government Standard map (I Felix)

m17n-lib-1.3.3-1
----------------
* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com> - 1.3.3-1
- update to 1.3.3 minor bugfix release

mesa-6.4.2-6
------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 6.4.2-6
- Buildrequires: libXt-devel (#183479)

perl-4:5.8.8-4
--------------
* Wed Mar 01 2006 Jason Vas Dias <jvdias at redhat.com> - 4:5.8.8-4
- Fix bug 183553 / upstream bug 38657: fix -d:Foo=bar processing
- rebuild with new gcc-4.1.0-1, released today

* Mon Feb 27 2006 Jason Vas Dias <jvdias at redhat.com>
- Apply upstream patch #28284

* Mon Feb 13 2006 Jason Vas Dias <jvdias at redhat.com> - 4:5.8.8-3
- Apply upstream bugfix patch 27170

poppler-0.5.1-2
---------------
* Wed Mar 01 2006 Kristian H??gsberg <krh at redhat.com> 0.5.1-2
- Rebuild the get rid of old soname dependency.

* Tue Feb 28 2006 Kristian H??gsberg <krh at redhat.com> 0.5.1-1
- Update to version 0.5.1.

qt-1:3.3.5-13
-------------
* Mon Feb 27 2006 Than Ngo <than at redhat.com> 1:3.3.5-13
- add set of fixes for the immodule patch, thanks to Dirk M?ller

rhpl-0.184-1
------------
* Wed Mar 01 2006 David Cantrell <dcantrell at redhat.com> 0.184-1
- Use ca(fr) without fr-legacy variant for Canadian French (#182007).

scim-1.4.4-8
------------
* Wed Mar 01 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-8
- add scim-system-default-config.patch
  - add Zenkaku_Hankaku as trigger hotkey for Japanese users
  - use static XIM event flow so deadkeys work under XIM in off state (#169975)
- add alternatives as prereq for %post and %postun (pknirsch, #182853)

* Fri Feb 24 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-6
- fix Punjabi spelling with scim-panjabi-punjabi.patch (aalam)

* Mon Feb 20 2006 Warren Togami <wtogami at redhat.com> - 1.4.4-5
- Add epoch to iiimf Obsoletes so it actually removes it (#173071)
  NOTE: The goal of these Obsoletes is for the official supported 
  upgrade path to work smoothly.  If users want to use iiimf, they
  are free to do so but their package must be compatible.

scim-m17n-0.2.0-2
-----------------
* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com> - 0.2.0-2
- obsolete iiimf-le-unitle for upgrades (#181479,#183305)

scim-tables-0.5.6-3
-------------------
* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com> - 0.5.6-3
- move iiimf-le-unit obsoletes to scim-m17n
- disable Indian script tables for now: they are now in m17n-db
  - added %indic_tables switch to allow them to be built

udev-084-9
----------
* Wed Mar 01 2006 Harald Hoyer <harald at redhat.com> - 084-9
- create non-enum device (cdrom, floppy, scanner, changer)
  for compatibility (random device wins)
	e.g. /dev/cdrom -> hdd
	     /dev/cdrom-hdc -> hdc
             /dev/cdrom-hdd -> hdd

* Wed Mar 01 2006 Harald Hoyer <harald at redhat.com> - 084-8
- fixed ZIP drive thrashing (bz #181041 #182601)
- fixed enumeration (%e does not work anymore) (bz #183288)

* Fri Feb 24 2006 Peter Jones <pjones at redhat.com> - 084-7
- Don't start udevd in %post unless it's already running
- Stop udevd before chkconfig --del in %preun

usbutils-0.71-2
---------------
* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 1.71-2
- add usbutils-0.71-VT.patch to fix warnings about unknown lines
  (#176903)

wpa_supplicant-1:0.4.8-3
------------------------
* Wed Mar 01 2006 Dan Williams <dcbw at redhat.com> - 0.4.8-3
- Install wpa_passphrase too #rh183480#

xorg-x11-drv-citron-2.1.5-1
---------------------------
* Wed Mar 01 2006 Mike A. Harris <mharris at redhat.com> 2.1.5-1
- Updated to new upstream citron 2.1.5 driver.

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> 2.1.1.5-1.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> 2.1.1.5-1.1
- rebuilt for new gcc4.1 snapshot and glibc changes

xorg-x11-drv-mouse-1.0.4-1
--------------------------
* Wed Mar 01 2006 Mike A. Harris <mharris at redhat.com> 1.0.4-1
- Updated to new upstream driver version mouse-1.0.4.

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> 1.0.3.1-1.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> 1.0.3.1-1.1
- rebuilt for new gcc4.1 snapshot and glibc changes

xorg-x11-proto-devel-7.0-6
--------------------------
* Wed Mar 01 2006 Mike A. Harris <mharris at redhat.com> 7.0-6
- Update to glproto-1.4.5
- Remove xorg-x11-proto-devel-7.0-buffer-values.patch which is in 1.4.5.

* Wed Feb 22 2006 Jeremy Katz <katzj at redhat.com> 7.0-5
- require mesa-libGL-devel since it's needed by some of the headers

* Sun Feb 19 2006 Ray Strode <rstrode at redhat.com> 7.0-4
- Add back part of glproto-texture-from-drawable patch that didn't
  get integrated for some reason

xorg-x11-xbitmaps-1.0.1-2
-------------------------
* Wed Mar 01 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-2
- Cleaned up file manifest.
- Made package noarch, as it is just header files.
- Disable debuginfo processing, as there are no ELF objects in package.

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> 1.0.1-1.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> 1.0.1-1.1
- rebuilt for new gcc4.1 snapshot and glibc changes

xorg-x11-xfs-1:1.0.1-4
----------------------
* Wed Mar 01 2006 Mike A. Harris <mharris at redhat.com> 1:1.0.1-4
- Fix all rpm scriptlets "upgrade" tests to only execute on upgrades.

xorg-x11-xkbdata-1.0.1-6
------------------------
* Wed Mar 01 2006 Ray Strode <rstrode at redhat.com> 1.0.1-6
- Turn on compat symlink (bug 183521)

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs
	vconfig - 1.9-1.1.ia64 requires libc.so.6
	vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0)






Broken deps for ppc64
----------------------------------------------------------
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	vconfig - 1.9-1.1.ppc64 requires libc.so.6
	vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0)



Broken deps for s390
----------------------------------------------------------
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1



Broken deps for s390x
----------------------------------------------------------
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From sundaram at fedoraproject.org  Thu Mar  2 08:30:07 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 02 Mar 2006 14:00:07 +0530
Subject: rawhide report: 20060302 changes
In-Reply-To: <200603020817.k228H7AE001227@porkchop.devel.redhat.com>
References: <200603020817.k228H7AE001227@porkchop.devel.redhat.com>
Message-ID: <4406AD0F.2000606@fedoraproject.org>

Build System wrote:

> 
>dbus-0.61-3
>-----------
>* Fri Feb 24 2006 John (J5) Palmieri <johnp at redhat.com> 0.61-2
>- ABI hasn't changed so add patch that makes dbus-sharp think
>  it is still 0.60 (mono uses hard version names so any change
>  means apps need to recompile)
>
>  
>
Isnt hard version numbers a bad idea for mono? Can we get upstream to 
fix that?

>gnome-keyring-manager-2.12.0-3
>------------------------------
>* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.12.0-3
>- BuildRequires: gnome-doc-utils
>  
>
Isnt there a 2.14 version of this?

>scim-tables-0.5.6-3
>-------------------
>* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com> - 0.5.6-3
>- move iiimf-le-unit obsoletes to scim-m17n
>- disable Indian script tables for now: they are now in m17n-db
>  - added %indic_tables switch to allow them to be built
>  
>
Are we renabling Indic script tables before FC5 release?

-- 
Rahul 





From fedora at camperquake.de  Thu Mar  2 08:55:41 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 2 Mar 2006 09:55:41 +0100
Subject: username best practices and other conventions
In-Reply-To: <1141286133.4207.36.camel@mentorng.gurulabs.com>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
Message-ID: <20060302095541.5b2f48a7@dhcp05.addix.net>

Hi.

On Thu, 02 Mar 2006 00:55:33 -0700, Dax Kelson wrote:

> The origin of (a) I believe comes from the fact that historically
> there was a one-to-one mapping between email addresses and usernames
> and since email addresses are not case sensitive, usernames that only
> differ by case cause email ambiguities.

The local part of mail addresses is, and has always been, case sensitive.
Many mail systems ignore this, though (or can be configured to ignore it).



From gianluca.cecchi at gmail.com  Thu Mar  2 09:18:52 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 2 Mar 2006 10:18:52 +0100
Subject: evolution and exchange slow fetching
Message-ID: <561c252c0603020118waea4196t@mail.gmail.com>

Hello,
I have latest evolution packages from rawhide and have configured an
exchange user.
evolution-sharp-0.10.2-8
evolution-webcal-2.4.1-3.2
evolution-2.5.92-1
evolution-connector-2.5.92-1
evolution-data-server-1.5.92-1

Fetching summary information for new messages seems quite slow.
For example, if I:
- open evolution and let synchronize inbox folder (3500 messages and
116MB in size)
- then I'm able to work well
- close evolution
- open evolution immediately after
- it takes quite much time (about 2 minutes) to redo fetch of summary
information (to fetch actually nothing) and in the mean time I have
the right screen for inbox contents that is empty, so that I'm not
able to see any past message and so on

I would like to have this fetch operation (that in my test btw should
be in some way instantaneous) done in background and start work with
my previous inbox e-mails at least.
Is there a setting I have to provide in configuration for exchange
account in evolution, or can I post as a bug? Where, upstream or
rawhide?

Gianluca



From pbrobinson at gmail.com  Thu Mar  2 10:20:50 2006
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 2 Mar 2006 10:20:50 +0000
Subject: evolution and exchange slow fetching
In-Reply-To: <561c252c0603020118waea4196t@mail.gmail.com>
References: <561c252c0603020118waea4196t@mail.gmail.com>
Message-ID: <5256d0b0603020220j724800b0jea71a69cd3bf64f3@mail.gmail.com>

Hi,

I'm seeing exactly the same issues. It use to be much faster with 2.4
and prior. Not sure if its the same issues that this imap user is
seeing (http://www.advogato.org/person/dwmw2/diary.html?start=125) but
before if it had already downloaded various emails from the last time
it was run they would be listed straight up and then the new messages
would come as they were downloaded but now its just hideously slow
(especially when accessing the server remotely across the net) and
seems to fdownload messages repeatedly.

Peter

On 3/2/06, Gianluca Cecchi <gianluca.cecchi at gmail.com> wrote:
> Hello,
> I have latest evolution packages from rawhide and have configured an
> exchange user.
> evolution-sharp-0.10.2-8
> evolution-webcal-2.4.1-3.2
> evolution-2.5.92-1
> evolution-connector-2.5.92-1
> evolution-data-server-1.5.92-1
>
> Fetching summary information for new messages seems quite slow.
> For example, if I:
> - open evolution and let synchronize inbox folder (3500 messages and
> 116MB in size)
> - then I'm able to work well
> - close evolution
> - open evolution immediately after
> - it takes quite much time (about 2 minutes) to redo fetch of summary
> information (to fetch actually nothing) and in the mean time I have
> the right screen for inbox contents that is empty, so that I'm not
> able to see any past message and so on
>
> I would like to have this fetch operation (that in my test btw should
> be in some way instantaneous) done in background and start work with
> my previous inbox e-mails at least.
> Is there a setting I have to provide in configuration for exchange
> account in evolution, or can I post as a bug? Where, upstream or
> rawhide?
>
> Gianluca
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From mitr at volny.cz  Thu Mar  2 10:54:40 2006
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 02 Mar 2006 11:54:40 +0100
Subject: username best practices and other conventions
In-Reply-To: <1141286133.4207.36.camel@mentorng.gurulabs.com>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
Message-ID: <4406CEF0.5050506@volny.cz>

Hello,
Dax Kelson napsal(a):
> Since, well forever, I've understood the UNIX and Linux username best
> practices to be:
I don't know about best practices, but FWIW these are the hard limits in
shadow-utils and libuser:

> (a) all lowercase
> (b) alphanumeric with exception that first char must not be a number
[a-zA-Z0-9.-_]*, first char must not be -.  First char can be a number,
in fact the user name can be completely numeric (which of course a
stupid thing to do).
> (c) 8 char max length
UT_NAMESIZE - 1 (31) bytes.

> The origin of (a) I believe comes from the fact that historically there
> was a one-to-one mapping between email addresses and usernames and since
> email addresses are not case sensitive, usernames that only differ by
> case cause email ambiguities.
One other possible reason is that traditional UNIX supported
uppercase-only terminals (by mapping all characters to uppercase on
output and to lowercase on input), and getty would switch to the
uppercase-only mode when the username was entered in all uppercase.  I
have seen this behavior on Debian about five years ago.
	Mirek



From gianluca.cecchi at gmail.com  Thu Mar  2 11:13:19 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 2 Mar 2006 12:13:19 +0100
Subject: evolution and exchange slow fetching
Message-ID: <561c252c0603020313y2318e647h@mail.gmail.com>

In the mean time I have opened a bug in gnome upstream:

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



From galibert at pobox.com  Thu Mar  2 11:23:11 2006
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 2 Mar 2006 12:23:11 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <1141286103.31231.104.camel@ender>
References: <1141286103.31231.104.camel@ender>
Message-ID: <20060302112310.GA4822@dspnet.fr.eu.org>

On Wed, Mar 01, 2006 at 11:55:02PM -0800, Jesse Keating wrote:
> We're attempting to fix a problem in udev where /dev/cdrom creation is a
> race between multiple optical devices in a system.  To work around this
> we will enumerate the devices as /dev/cdrom-hdc or /dev/cdrom-hdb.
> However for compatibility reasons, we'll still create a /dev/cdrom, and
> the last device found wins the race.

And no /dev/cdrom1, etc.  Compatibility is for the weak, I presume?

  OG.



From harald at redhat.com  Thu Mar  2 12:58:49 2006
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 02 Mar 2006 13:58:49 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <20060302112310.GA4822@dspnet.fr.eu.org>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
Message-ID: <4406EC09.8010605@redhat.com>

Olivier Galibert wrote:
> On Wed, Mar 01, 2006 at 11:55:02PM -0800, Jesse Keating wrote:
> 
>>We're attempting to fix a problem in udev where /dev/cdrom creation is a
>>race between multiple optical devices in a system.  To work around this
>>we will enumerate the devices as /dev/cdrom-hdc or /dev/cdrom-hdb.
>>However for compatibility reasons, we'll still create a /dev/cdrom, and
>>the last device found wins the race.
> 
> 
> And no /dev/cdrom1, etc.  Compatibility is for the weak, I presume?

enumeration is not possible anymore... we should now have /dev/cdrom-{devname}



From uraeus at gnome.org  Thu Mar  2 13:11:02 2006
From: uraeus at gnome.org (Christian Fredrik Kalager Schaller)
Date: Thu, 02 Mar 2006 14:11:02 +0100
Subject: xorg-x11-xkbdata, xkbdata, xkeyboard-config and you
In-Reply-To: <44062A78.8010500@mharris.ca>
References: <4405672D.7080205@mharris.ca>
	<1141254213.11543.4.camel@rousalka.dyndns.org>
	<44062A78.8010500@mharris.ca>
Message-ID: <1141305063.4279.12.camel@localhost.localdomain>

Hi Mike,
Thanks for doing this switch, having struggled with the old data package
overwriting my keysyms for my multimedia keys for a while I am happy to
see this go in.

Unfortunately there are a couple of problems atm. Both of them might
actually be something else than this switch though, but I did discover
them both just after this switch. The first is that it seems 'repeat
keys mode' are no longer the default. Not a big problem, I was able to
turn it on again quickly through the keyboard preferences applet, but
the behavior did change for me as part of some package update.

The second issue is that both Banshee and Rhythmbox seems unaware of the
multimedia keys suddenly. Totem still works though and 'xev' do reports
the keysyms being correct, so this might be an application problem of
some sort. Maybe they need the same legacy stuff as KDE was reported to
need, so that as soon as I get updated to the 1.0.1-6 package they start
working again.

Christian


On Wed, 2006-03-01 at 18:12 -0500, Mike A. Harris wrote:
> Nicolas Mailhot wrote:
> > Hi Mike
> > 
> > I just wanted to report a direct result of the change here is the gnome
> > keyboard switcher started working again in Rawhide (after months of
> > misbehaviour)
> > 
> > Thanks for making the switch. I know it was a hard decision to make just
> > before a release. Even if the xkbdata core contributors made it pretty
> > clear they only cared about xkeyboard-config nowadays.
> 
> Yeah, the long term goal has always been to switch to xkeyboard-config
> ever since it split off from XFree86 when X.Org revitalized itself.
> 
> However, while Xorg was still monolithic it made sense to use what
> X.Org shipped rather than trying to hack on the xkeyboard-config
> bits.  Also some people had concerns about backward compatibility
> and other stuff.
> 
> With X11R7, upstream wanted to keep using the unmaintained data for
> some reason, which had to do with um...  ok, I don't know.  Silly
> worries or something.  ;o)
> 
> There were a few other things I'm struggling to try and forget now,
> so I wont bore you. ;)
> 
> Even if things break for people now, we are in the best position
> going forward with xkeyboard-config IMHO.  Mainly because bugs
> in xkbdata are more or less permanent "so sorry, deal with it"
> in nature. ;o)
> 
> Hopefully xkeyboard-config transition is smooth for FC5 now.
> 
> 
> -- 
> Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
>                        Proud Canadian.
> 



From dedourek at unb.ca  Thu Mar  2 14:24:45 2006
From: dedourek at unb.ca (John DeDourek)
Date: Thu, 02 Mar 2006 10:24:45 -0400
Subject: Udev issues in today's coming rawhide
In-Reply-To: <4406EC09.8010605@redhat.com>
References: <1141286103.31231.104.camel@ender>	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com>
Message-ID: <4407002D.4090000@unb.ca>



Harald Hoyer wrote:
> Olivier Galibert wrote:
> 
>> On Wed, Mar 01, 2006 at 11:55:02PM -0800, Jesse Keating wrote:
>>
>>> We're attempting to fix a problem in udev where /dev/cdrom creation is a
>>> race between multiple optical devices in a system.  To work around this
>>> we will enumerate the devices as /dev/cdrom-hdc or /dev/cdrom-hdb.
>>> However for compatibility reasons, we'll still create a /dev/cdrom, and
>>> the last device found wins the race.
>>
>>
>>
>> And no /dev/cdrom1, etc.  Compatibility is for the weak, I presume?
> 
> 
> enumeration is not possible anymore... we should now have 
> /dev/cdrom-{devname}
> 
Hmmm.  To quote "Greg Kroah-Hartman", from the paper "udev -- A
Userspace Imlementation of devfs", Proceeedings of the Linux Symosium,
July 23th-26th, 2003, Ottawa, Ontario, Canada:
"This paper will discuss udev, a program ... allows for features
that were previously not able to be done through devfs alone, such
as:  Persistent naming for devices when they move around the
device tree."

I guess we can't have persistent naming when they don't move
around the tree (but we reboot).  :0(

Or perhaps this is just a configuration issue and we can have
persistent names (whether they be /dev/cdrom-a and /dev/cdrom-b,
or the more traditional /dev/cdrom1 and /dev/cdrom2, or whatever.
We just can't use "enumeration" to do it.

I will continue working through the available documentation
until I do understand how this stuff works.  But I am finding
it very difficult to understand from the documentation that
I have read to date.

I would appreciate any poitners to additional things that I
should read about sysfs, udev, hotbplug, and drivers.



From arjan at fenrus.demon.nl  Thu Mar  2 14:39:21 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Thu, 02 Mar 2006 15:39:21 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <4407002D.4090000@unb.ca>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org> <4406EC09.8010605@redhat.com>
	<4407002D.4090000@unb.ca>
Message-ID: <1141310361.3206.64.camel@laptopd505.fenrus.org>

On Thu, 2006-03-02 at 10:24 -0400, John DeDourek wrote:
> 
> Harald Hoyer wrote:
> > Olivier Galibert wrote:
> > 
> >> On Wed, Mar 01, 2006 at 11:55:02PM -0800, Jesse Keating wrote:
> >>
> >>> We're attempting to fix a problem in udev where /dev/cdrom creation is a
> >>> race between multiple optical devices in a system.  To work around this
> >>> we will enumerate the devices as /dev/cdrom-hdc or /dev/cdrom-hdb.
> >>> However for compatibility reasons, we'll still create a /dev/cdrom, and
> >>> the last device found wins the race.
> >>
> >>
> >>
> >> And no /dev/cdrom1, etc.  Compatibility is for the weak, I presume?
> > 
> > 
> > enumeration is not possible anymore... we should now have 
> > /dev/cdrom-{devname}
> > 
> Hmmm.  To quote "Greg Kroah-Hartman", from the paper "udev -- A
> Userspace Imlementation of devfs", Proceeedings of the Linux Symosium,
> July 23th-26th, 2003, Ottawa, Ontario, Canada:
> "This paper will discuss udev, a program ... allows for features
> that were previously not able to be done through devfs alone, such
> as:  Persistent naming for devices when they move around the
> device tree."


agreed. calling them "hda" is really really bad, it makes them bus
dependant again

better would be to use UUID's, or at least vendor identification strings
etc from the device. We need to NOT tie these device names to underlying
accidental device numbers. That is a major major step back.



From galibert at pobox.com  Thu Mar  2 14:50:21 2006
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 2 Mar 2006 15:50:21 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <4406EC09.8010605@redhat.com>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com>
Message-ID: <20060302145021.GA25671@dspnet.fr.eu.org>

On Thu, Mar 02, 2006 at 01:58:49PM +0100, Harald Hoyer wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 01, 2006 at 11:55:02PM -0800, Jesse Keating wrote:
> >
> >>We're attempting to fix a problem in udev where /dev/cdrom creation is a
> >>race between multiple optical devices in a system.  To work around this
> >>we will enumerate the devices as /dev/cdrom-hdc or /dev/cdrom-hdb.
> >>However for compatibility reasons, we'll still create a /dev/cdrom, and
> >>the last device found wins the race.
> >
> >
> >And no /dev/cdrom1, etc.  Compatibility is for the weak, I presume?
> 
> enumeration is not possible anymore... we should now have 
> /dev/cdrom-{devname}

I hadn't realized my processor wasn't able to count anymore.  I'm not
sure I want to upgrade to fc5 if it can't do basic arithmetic.  Or
testing whether symlink(2) returns -EEXIST in a loop.

Someone could explain me the point of /dev/cdrom-{devname} when you
can use /dev/{devname} directly?

  OG.



From dwmw2 at infradead.org  Thu Mar  2 15:01:08 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 02 Mar 2006 15:01:08 +0000
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <44062B74.3060200@mharris.ca>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
	<d8dc7cba0603011119s26ab8513s5a60fd37583bfbb@mail.gmail.com>
	<44062B74.3060200@mharris.ca>
Message-ID: <1141311668.3732.184.camel@pmac.infradead.org>

On Wed, 2006-03-01 at 18:17 -0500, Mike A. Harris wrote:
> I disagree with everyone.  ;o)
> 
> My recommendation, is to use Xvfb or the text console.  Almost no
> hardware/driver related bugs/problems, and no big concerns over
> openness of the code/specs/etc. ;o)

Heh. I'm hoping that www.opengraphics.org turns out to be more than just
a pipe-dream.

-- 
dwmw2



From thacker at math.cornell.edu  Thu Mar  2 15:01:15 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Thu, 2 Mar 2006 10:01:15 -0500
Subject: Udev issues in today's coming rawhide
In-Reply-To: <20060302145021.GA25671@dspnet.fr.eu.org>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com>
	<20060302145021.GA25671@dspnet.fr.eu.org>
Message-ID: <20060302150115.GA13317@localhost.localdomain>

On Thu, Mar 02, 2006 at 03:50:21PM +0100, Olivier Galibert wrote:
> I hadn't realized my processor wasn't able to count anymore.  I'm not
> sure I want to upgrade to fc5 if it can't do basic arithmetic.  Or
> testing whether symlink(2) returns -EEXIST in a loop.

udev upstream deprecated the %e functionality and removed it from the
manpage (claiming that it had never really worked properly).  I had
thought it was supposed to still work, but it doesn't.
 
> Someone could explain me the point of /dev/cdrom-{devname} when you
> can use /dev/{devname} directly?

PAM in /etc/security/console.perms sets the console user to own the 
CDROM devices on login. (Along with other devices, like the soundcard.)
We do not, in general, want to set the user who logs in as the owner
of all block devices, such as hard drives.  Thus we want some way to
distinguish which block devices are CD-ROMs that works for PAM on
login.

John Thacker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060302/9504dc33/attachment.sig>

From galibert at pobox.com  Thu Mar  2 15:11:26 2006
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 2 Mar 2006 16:11:26 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <20060302150115.GA13317@localhost.localdomain>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com>
	<20060302145021.GA25671@dspnet.fr.eu.org>
	<20060302150115.GA13317@localhost.localdomain>
Message-ID: <20060302151125.GA27854@dspnet.fr.eu.org>

On Thu, Mar 02, 2006 at 10:01:15AM -0500, John Thacker wrote:
> On Thu, Mar 02, 2006 at 03:50:21PM +0100, Olivier Galibert wrote:
> > I hadn't realized my processor wasn't able to count anymore.  I'm not
> > sure I want to upgrade to fc5 if it can't do basic arithmetic.  Or
> > testing whether symlink(2) returns -EEXIST in a loop.
> 
> udev upstream deprecated the %e functionality and removed it from the
> manpage (claiming that it had never really worked properly).  I had
> thought it was supposed to still work, but it doesn't.

I had noticed already that the udev maintainers clearly didn't care
about backwards compatibility, but I didn't think it was the case of
fedora.


> PAM in /etc/security/console.perms sets the console user to own the 
> CDROM devices on login. (Along with other devices, like the soundcard.)
> We do not, in general, want to set the user who logs in as the owner
> of all block devices, such as hard drives.  Thus we want some way to
> distinguish which block devices are CD-ROMs that works for PAM on
> login.

Reasonable indeed.  Of course the udev people would say you should use
hal to get the list of devices.

  OG.



From thacker at math.cornell.edu  Thu Mar  2 15:13:02 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Thu, 2 Mar 2006 10:13:02 -0500
Subject: Udev issues in today's coming rawhide
In-Reply-To: <1141310361.3206.64.camel@laptopd505.fenrus.org>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com> <4407002D.4090000@unb.ca>
	<1141310361.3206.64.camel@laptopd505.fenrus.org>
Message-ID: <20060302151302.GA13377@localhost.localdomain>

On Thu, Mar 02, 2006 at 03:39:21PM +0100, Arjan van de Ven wrote:
> better would be to use UUID's, or at least vendor identification strings
> etc from the device. We need to NOT tie these device names to underlying
> accidental device numbers. That is a major major step back.

Wouldn't vendor identification strings, at least by themselves, still 
cause problems when people have two identical model devices?  That's
fairly rare for CDROM devices but not unheard of.  From what I understand
of the output of udevinfo, it doesn't look like a UUID is exported
as an environment variable the way that the vendor id strings are.
I don't claim to understand everything, though, and of course it could
be changed as well.

My understanding anyway is that the old method still somewhat depended
the underlying accidental device numbers, at least when it came to
deciding which was /dev/cdrom and which was /dev/cdrom1.

John Thacker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060302/5757535e/attachment.sig>

From kaboom at oobleck.net  Thu Mar  2 15:17:27 2006
From: kaboom at oobleck.net (Chris Ricker)
Date: Thu, 2 Mar 2006 10:17:27 -0500 (EST)
Subject: username best practices and other conventions
In-Reply-To: <20060302095541.5b2f48a7@dhcp05.addix.net>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
	<20060302095541.5b2f48a7@dhcp05.addix.net>
Message-ID: <Pine.LNX.4.64.0603021016540.31832@urd.oobleck.net>

On Thu, 2 Mar 2006, Ralf Ertzinger wrote:

> The local part of mail addresses is, and has always been, case sensitive.
> Many mail systems ignore this, though (or can be configured to ignore it).

except for postmaster which has to be case insensitive

later,
chris



From thacker at math.cornell.edu  Thu Mar  2 15:23:09 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Thu, 2 Mar 2006 10:23:09 -0500
Subject: Udev issues in today's coming rawhide
In-Reply-To: <20060302151125.GA27854@dspnet.fr.eu.org>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com>
	<20060302145021.GA25671@dspnet.fr.eu.org>
	<20060302150115.GA13317@localhost.localdomain>
	<20060302151125.GA27854@dspnet.fr.eu.org>
Message-ID: <20060302152309.GB13377@localhost.localdomain>

On Thu, Mar 02, 2006 at 04:11:26PM +0100, Olivier Galibert wrote:
> On Thu, Mar 02, 2006 at 10:01:15AM -0500, John Thacker wrote:
> > udev upstream deprecated the %e functionality and removed it from the
> > manpage (claiming that it had never really worked properly).  I had
> > thought it was supposed to still work, but it doesn't.
> 
> I had noticed already that the udev maintainers clearly didn't care
> about backwards compatibility, but I didn't think it was the case of
> fedora.

Well, in fairness it was broken upstream and the Fedora maintainer
(Harald) didn't notice that it was broken until now (when I filed
bug 183288 after emailing the list and getting no "me too" responses),
and it's a little difficult to get backwards compatibility working
without the option.  I'd like backwards compatibility too, but I'll
admit that on my own system my initial hack to get it working was
exactly the same one (without the hyphen) as Harald's.  Others know
more about udev than I, though.

> Reasonable indeed.  Of course the udev people would say you should use
> hal to get the list of devices.

Right.  Which is why the problem was at least masked on hal-using programs,
and thus why Harald and others didn't notice the problem before now.

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060302/a3572cb8/attachment.sig>

From arjan at fenrus.demon.nl  Thu Mar  2 15:25:50 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Thu, 02 Mar 2006 16:25:50 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <20060302151302.GA13377@localhost.localdomain>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org> <4406EC09.8010605@redhat.com>
	<4407002D.4090000@unb.ca>
	<1141310361.3206.64.camel@laptopd505.fenrus.org>
	<20060302151302.GA13377@localhost.localdomain>
Message-ID: <1141313150.3206.72.camel@laptopd505.fenrus.org>

On Thu, 2006-03-02 at 10:13 -0500, John Thacker wrote:
> On Thu, Mar 02, 2006 at 03:39:21PM +0100, Arjan van de Ven wrote:
> > better would be to use UUID's, or at least vendor identification strings
> > etc from the device. We need to NOT tie these device names to underlying
> > accidental device numbers. That is a major major step back.
> 
> Wouldn't vendor identification strings, at least by themselves, still 
> cause problems when people have two identical model devices?  That's
> fairly rare for CDROM devices but not unheard of.  From what I understand
> of the output of udevinfo, it doesn't look like a UUID is exported
> as an environment variable the way that the vendor id strings are.
> I don't claim to understand everything, though, and of course it could
> be changed as well.
> 
> My understanding anyway is that the old method still somewhat depended
> the underlying accidental device numbers, at least when it came to
> deciding which was /dev/cdrom and which was /dev/cdrom1.

but so does the new one! For example on one of my test boxes, it depends
on if I have a USB stick inserted.. if it is at boot, sda is my usb
stick and sdb is my sata disk, and sdc my cd writer.
if it's not, sda is my disk and sdb my cd writer.
Now add USB cd writers to the mix and it's clear that such device names
are not persistent at all and utterly useless for identification.

(and since USB goes via my kvm, this device order is potentially
different each time I switch my kvm to this machine)

while you can have 2 of the same type, the problem is at least less than
before, not bigger than before as is the case with the proposed
"solution".




From mharris at mharris.ca  Thu Mar  2 15:26:16 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Thu, 02 Mar 2006 10:26:16 -0500
Subject: Brazilian ABNT-2 Keyboard wrong with the last update
In-Reply-To: <4406693F.7030308@gmail.com>
References: <4406693F.7030308@gmail.com>
Message-ID: <44070E98.7000107@mharris.ca>

Casimiro de Almeida Barreto wrote:
> Hello,
> 
> Brazilian ABNT-2 Keyboard got messed in the last fedora update. 
> Particularly quotation mark-stroke key got dead (so there are no ways to 
> write pathnames). Number pad became really the number-pad (no home, 
> arrows or other functions). Combination of control+alt+function-key 
> don't switch to console ...

Fedora development occurs quickly enough that saying "in the last fedora
update" has almost no meaning.  Only specific rpm package versions mean
anything really.

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mharris at mharris.ca  Thu Mar  2 15:28:27 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Thu, 02 Mar 2006 10:28:27 -0500
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141311668.3732.184.camel@pmac.infradead.org>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<1141199246.3866.22.camel@laptopd505.fenrus.org>
	<d8dc7cba0603011119s26ab8513s5a60fd37583bfbb@mail.gmail.com>
	<44062B74.3060200@mharris.ca>
	<1141311668.3732.184.camel@pmac.infradead.org>
Message-ID: <44070F1B.7030701@mharris.ca>

David Woodhouse wrote:
> On Wed, 2006-03-01 at 18:17 -0500, Mike A. Harris wrote:
> 
>>I disagree with everyone.  ;o)
>>
>>My recommendation, is to use Xvfb or the text console.  Almost no
>>hardware/driver related bugs/problems, and no big concerns over
>>openness of the code/specs/etc. ;o)
> 
> 
> Heh. I'm hoping that www.opengraphics.org turns out to be more than just
> a pipe-dream.

I think you're pipe dreaming.  ;o)


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mharris at mharris.ca  Thu Mar  2 15:39:32 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Thu, 02 Mar 2006 10:39:32 -0500
Subject: Solution: keyboard layout problems in Fedora devel
Message-ID: <440711B4.8080609@mharris.ca>

This is a daily reminder to everyone, but in particular people who
experience problems and report them before they read the mailing
list archives or query bugzilla for bug reports before filing a
new one:

We have switched from X.Org xkbdata to xkeyboard-config data, and
in the process the initial build that went into rawhide (1.0.1-5)
inadvertently had backward compatibility stuff disabled.  This
problem has been resolved in 1.0.1-6, which should now be visible
in rawhide today.

If you experience *any* keyboard related problems or regressions
after updating, make sure you have xorg-x11-xkbdata-1.0.1-6 or
later installed before filing a bug report or asking for help.
After you're sure you have that version or newer installed, restart
X or reboot your system to ensure the changes take effect.  You
may also need to reconfigure your keyboard with system-config-keyboard.

After verifying you're using 1.0.1-6 or later however, if you still
have problems, please do report them in bugzilla against the
"xorg-x11-xkbdata" component.  I'll be reviewing xkbdata problems
closely between now and final build, and incorporating any fixes
I can muster up.

Thanks to everyone for testing the new bits out!

TTYL

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From harald at redhat.com  Thu Mar  2 15:55:35 2006
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 02 Mar 2006 16:55:35 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <1141313150.3206.72.camel@laptopd505.fenrus.org>
References: <1141286103.31231.104.camel@ender>	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com>	<4407002D.4090000@unb.ca>	<1141310361.3206.64.camel@laptopd505.fenrus.org>	<20060302151302.GA13377@localhost.localdomain>
	<1141313150.3206.72.camel@laptopd505.fenrus.org>
Message-ID: <44071577.6070908@redhat.com>

Arjan van de Ven wrote:
> On Thu, 2006-03-02 at 10:13 -0500, John Thacker wrote:
> 
>>On Thu, Mar 02, 2006 at 03:39:21PM +0100, Arjan van de Ven wrote:
>>
>>>better would be to use UUID's, or at least vendor identification strings
>>>etc from the device. We need to NOT tie these device names to underlying
>>>accidental device numbers. That is a major major step back.
>>
>>Wouldn't vendor identification strings, at least by themselves, still 
>>cause problems when people have two identical model devices?  That's
>>fairly rare for CDROM devices but not unheard of.  From what I understand
>>of the output of udevinfo, it doesn't look like a UUID is exported
>>as an environment variable the way that the vendor id strings are.
>>I don't claim to understand everything, though, and of course it could
>>be changed as well.
>>
>>My understanding anyway is that the old method still somewhat depended
>>the underlying accidental device numbers, at least when it came to
>>deciding which was /dev/cdrom and which was /dev/cdrom1.
> 
> 
> but so does the new one! For example on one of my test boxes, it depends
> on if I have a USB stick inserted.. if it is at boot, sda is my usb
> stick and sdb is my sata disk, and sdc my cd writer.
> if it's not, sda is my disk and sdb my cd writer.
> Now add USB cd writers to the mix and it's clear that such device names
> are not persistent at all and utterly useless for identification.
> 
> (and since USB goes via my kvm, this device order is potentially
> different each time I switch my kvm to this machine)
> 
> while you can have 2 of the same type, the problem is at least less than
> before, not bigger than before as is the case with the proposed
> "solution".
> 
> 

Arjan, if you want to have IDs... use:
/dev/disk/by-id/



From thacker at math.cornell.edu  Thu Mar  2 16:01:38 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Thu, 2 Mar 2006 11:01:38 -0500
Subject: Udev issues in today's coming rawhide
In-Reply-To: <1141313150.3206.72.camel@laptopd505.fenrus.org>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com> <4407002D.4090000@unb.ca>
	<1141310361.3206.64.camel@laptopd505.fenrus.org>
	<20060302151302.GA13377@localhost.localdomain>
	<1141313150.3206.72.camel@laptopd505.fenrus.org>
Message-ID: <20060302160138.GA3241@localhost.localdomain>

On Thu, Mar 02, 2006 at 04:25:50PM +0100, Arjan van de Ven wrote:
> but so does the new one! For example on one of my test boxes, it depends
> on if I have a USB stick inserted.. if it is at boot, sda is my usb
> stick and sdb is my sata disk, and sdc my cd writer.
> if it's not, sda is my disk and sdb my cd writer.
> Now add USB cd writers to the mix and it's clear that such device names
> are not persistent at all and utterly useless for identification.

Certainly this increases the problem because now it matters if different
types of devices are initialized in a different order, not just the
same type.  But if you only have one device of the type attached, the
default "generic" device name independent /dev/cdrom, etc. devices are 
still created.  So it doesn't make anything any worse for people who
only have one device of a type attached, and it makes things better
for people who have two devices of the same type attached, since it
at least creates a unique symlink for each device, allowing the permissions
to be set correctly, while still creating at least one device name 
independent device.

But the problem was brought to his attention the day before yesterday,
and he whipped up a quick hack yesterday that at least sets the console
permissions correctly.  I'm not sure that anyone's suggesting that this
is really a solution, or even one that should be sufficient for FC5--
he left the bug open as MODIFIED rather than closing it, and it is
a FC5 blocker.

John Thacker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060302/18859305/attachment.sig>

From thacker at math.cornell.edu  Thu Mar  2 16:27:13 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Thu, 2 Mar 2006 11:27:13 -0500
Subject: Udev issues in today's coming rawhide
In-Reply-To: <44071577.6070908@redhat.com>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com> <4407002D.4090000@unb.ca>
	<1141310361.3206.64.camel@laptopd505.fenrus.org>
	<20060302151302.GA13377@localhost.localdomain>
	<1141313150.3206.72.camel@laptopd505.fenrus.org>
	<44071577.6070908@redhat.com>
Message-ID: <20060302162713.GA3700@localhost.localdomain>

On Thu, Mar 02, 2006 at 04:55:35PM +0100, Harald Hoyer wrote:
> Arjan, if you want to have IDs... use:
> /dev/disk/by-id/

Which of course doesn't work for CDROMs (and neither does /by-uuid of course),
leaving us back where we started looking for another hack (like the one
used right now) for them.

John Thacker



From jdesbonnet at gmail.com  Thu Mar  2 16:21:12 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Thu, 2 Mar 2006 16:21:12 +0000
Subject: username best practices and other conventions
In-Reply-To: <1141286133.4207.36.camel@mentorng.gurulabs.com>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
Message-ID: <1cef3e950603020821j24b659b6r38139a4ccd49ca54@mail.gmail.com>

I think it's time to move beyond those traditional limits. At some
point we got over the 14 char file name limits, and the world is a
better place for it.

I much prefer to spend a few more characters for clarity. Eg
'webalizer' -- I know exactly what that's about. It's for Webalizer. 
'wbalizer', or 'webalize' or 'wlzpf82' or whatever you would use to
make it fit in 8 characters is likely not going to be so obvious.

As long as we don't start putting silly characters like spaces and
umlauts in there :-)

Joe.

On 3/2/06, Dax Kelson <dax at gurulabs.com> wrote:
> I was wondering if Fedora had any guidelines for valid usernames.
> Especially usernames that are part of base and extra packages?
>
> Since, well forever, I've understood the UNIX and Linux username best
> practices to be:
>
> (a) all lowercase
> (b) alphanumeric with exception that first char must not be a number
> (c) 8 char max length
>
> The origin of (a) I believe comes from the fact that historically there
> was a one-to-one mapping between email addresses and usernames and since
> email addresses are not case sensitive, usernames that only differ by
> case cause email ambiguities.
>
> I'm not sure the origin of (b).
>
> The origin of (c) comes from the fact that's the way it has always been
> and older tools and file formats make only have room for 8 characters
> such as old tar or cpio. Additionally once a username exceeds 8
> characters some tools such as /bin/ps and /bin/ls start behaving
> differently. This can cause a cascade problem when sys admins write
> elaborate scripts or even one-off temporary scripts that because
> non-temporary and parse the output of /bin/ps or /bin/ls.
>
> For example, a script that is expecting the first column of /bin/ps
> output to be a username, might go bonkers if it encounters:
>
> avahi     2250  0.0  0.0   2744   436 ?        Ss   Mar01   0:00 avahi-daemon: chroot helper process
> root      2259  0.0  0.0   3084  1172 ?        Ss   Mar01   0:00 cups-config-daemon
> 68        2269  0.0  0.1   5072  3476 ?        Ss   Mar01   0:02 hald
> root      2270  0.0  0.0   3084  1140 ?        S    Mar01   0:00 hald-runner
> 68        2276  0.0  0.0   2192   896 ?        S    Mar01   0:00 /usr/libexec/hald-addon-acpi
> 68        2285  0.0  0.0   2196   900 ?        S    Mar01   0:00 /usr/libexec/hald-addon-keyboard
> root      2292  0.0  0.0   2152   840 ?        S    Mar01   0:00 /usr/libexec/hald-addon-storage
> root      2305  0.0  0.0   1548   448 tty2     Ss+  Mar01   0:00 /sbin/mingetty tty2
>
> IMHO, Fedora should respect the traditional best practices and
> conventions (not speaking solely about usernames) and not violate them
> without good reason. It seems there is maybe a carefree indifference or
> possibly ignorant attitude about the "old ways". Breaking long standing
> conventions in itself violates the principal of least surprise --
> something sys admins do not care for.
>
> In regards to the username violations on my FC4 box I see three
> usernames exceeding the 8 characters in length and on my rawhide box I
> see five. It is getting worse.
>
> For the sake of conversation here is list from a fresh rawhide install
> with a moderate amount of packages installed.
>
> lp = 2
> adm = 3
> bin = 3
> ftp = 3
> gdm = 3
> ntp = 3
> rpc = 3
> rpm = 3
> xfs = 3
> dbus = 4
> halt = 4
> mail = 4
> news = 4
> nscd = 4
> pcap = 4
> root = 4
> sshd = 4
> sync = 4
> uucp = 4
> vcsa = 4
> avahi = 5
> games = 5
> named = 5
> smmsp = 5
> squid = 5
> apache = 6
> daemon = 6
> gopher = 6
> nobody = 6
> netdump = 7
> rpcuser = 7
> torrent = 7
> mailnull = 8
> operator = 8
> shutdown = 8
> distcache = 9
> haldaemon = 9
> nfsnobody = 9
> webalizer = 9
> beagleindex = 11
>
> It isn't a universal trend, but it seems that the newer the program the
> longer the username.
>
> Any comments from the powers that be on this topic? Personally I'd love
> to see these 9+ usernames "fixed".
>
> Dax (getting a grey goatee) Kelson
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From d.jacobfeuerborn at conversis.de  Thu Mar  2 16:53:27 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Thu, 02 Mar 2006 17:53:27 +0100
Subject: aiglx
In-Reply-To: <44062996.7000907@fedoraproject.org>
References: <4404EF88.4080000@paradigma.pt>
	<44062996.7000907@fedoraproject.org>
Message-ID: <44072307.80803@conversis.de>

Rahul Sundaram wrote:
> Vitor Domingos wrote:
> 
>> Is AIGLX going to appear on FC5? I've test it with ATI RADEON 7000, 
>> with all the hacks that's on the wiki page, and it's too dam slow....
>>
> Some of the pieces are already integrated. See the section on technical 
> details for the current status. 
> http://fedoraproject.org/wiki/RenderingProject/aiglx.  Since the 
> features are not enabled by default, yet performance shouldnt be much of 
> a concern for FC5. Reports with hardware details and benchmarks would be 
> quite useful to fine tune it I guess.

Is the integrated compositing manager in metacity also supposed to work 
with the "regular" Xorg shipped with FC5 (ie as a replacement for xcompmgr) 
or only with the AIGLX enabled version?

Regards,
   Dennis



From benjy.grogan at gmail.com  Thu Mar  2 18:26:07 2006
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Thu, 2 Mar 2006 13:26:07 -0500
Subject: aiglx
In-Reply-To: <44062996.7000907@fedoraproject.org>
References: <4404EF88.4080000@paradigma.pt>
	<44062996.7000907@fedoraproject.org>
Message-ID: <d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>

Isn't Red Hat forking the accelerated GL community by working on AIGLX
instead of Xgl?  It seems like Xgl is to AIGLX as SELinux is to AppArmor.

It would be great if Red Hat and Novell could convene under a big tent and
agree to work on SELinux for security and Xgl for accelereated GL.

Benjy

On 3/1/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>
> Vitor Domingos wrote:
>
> > Is AIGLX going to appear on FC5? I've test it with ATI RADEON 7000,
> > with all the hacks that's on the wiki page, and it's too dam slow....
> >
> Some of the pieces are already integrated. See the section on technical
> details for the current status.
> http://fedoraproject.org/wiki/RenderingProject/aiglx.  Since the
> features are not enabled by default, yet performance shouldnt be much of
> a concern for FC5. Reports with hardware details and benchmarks would be
> quite useful to fine tune it I guess.
>
>
> --
> Rahul
>
>
>
> --
> 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/20060302/7e010aa6/attachment.htm>

From mailinglists at erwinrol.com  Thu Mar  2 18:42:48 2006
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Thu, 02 Mar 2006 19:42:48 +0100
Subject: aiglx
In-Reply-To: <d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
References: <4404EF88.4080000@paradigma.pt>
	<44062996.7000907@fedoraproject.org>
	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
Message-ID: <1141324968.11294.48.camel@xpc.home.erwinrol.com>

On Thu, 2006-03-02 at 13:26 -0500, Benjy Grogan wrote:
> Isn't Red Hat forking the accelerated GL community by working on AIGLX
> instead of Xgl?  It seems like Xgl is to AIGLX as SELinux is to
> AppArmor.

AFAIK the one "forking" things was Suse/Novel, because they did their
work in secret. 

> It would be great if Red Hat and Novell could convene under a big tent
> and agree to work on SELinux for security and Xgl for accelereated
> GL. 

Yeah and all VI users should use Emacs, all Evolution users Thunderbird,
all Firefox users Mozilla  and all KDE users should use Gnome. 

But I agree with you that everybody that works on software that I don't
use is wasting his time, and that they work on the wrong software also
is the cause I have to wait longer on the software I want to use.

- Erwin

PS: The person who finds sarcasm in this mail, is allowed to keep it ;-)




From sundaram at fedoraproject.org  Thu Mar  2 18:53:16 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 03 Mar 2006 00:23:16 +0530
Subject: aiglx
In-Reply-To: <44072307.80803@conversis.de>
References: <4404EF88.4080000@paradigma.pt>	<44062996.7000907@fedoraproject.org>
	<44072307.80803@conversis.de>
Message-ID: <44073F1C.4000906@fedoraproject.org>

Dennis Jacobfeuerborn wrote:

> Rahul Sundaram wrote:
>
>> Vitor Domingos wrote:
>>
>>> Is AIGLX going to appear on FC5? I've test it with ATI RADEON 7000, 
>>> with all the hacks that's on the wiki page, and it's too dam slow....
>>>
>> Some of the pieces are already integrated. See the section on 
>> technical details for the current status. 
>> http://fedoraproject.org/wiki/RenderingProject/aiglx.  Since the 
>> features are not enabled by default, yet performance shouldnt be much 
>> of a concern for FC5. Reports with hardware details and benchmarks 
>> would be quite useful to fine tune it I guess.
>
>
> Is the integrated compositing manager in metacity also supposed to 
> work with the "regular" Xorg shipped with FC5 (ie as a replacement for 
> xcompmgr) or only with the AIGLX enabled version?
>
The regular Xorg server is getting all the patches for AIGLX merged into 
it. Meanwhile the compositing manager is metacity can work in tandem or 
without it.


-- 
Rahul 





From sundaram at fedoraproject.org  Thu Mar  2 19:00:57 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 03 Mar 2006 00:30:57 +0530
Subject: aiglx
In-Reply-To: <d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
References: <4404EF88.4080000@paradigma.pt>	<44062996.7000907@fedoraproject.org>
	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
Message-ID: <440740E9.6020600@fedoraproject.org>

Benjy Grogan wrote:

>Isn't Red Hat forking the accelerated GL community by working on AIGLX
>instead of Xgl?  It seems like Xgl is to AIGLX as SELinux is to AppArmor.
>  
>
The analogy here seems to be off the mark since AIGLX and SELinux has 
been developed in the open right from the start unlike AppArmor and XGL 
and unlike security frameworks such as SELinux, there are different 
approaches you can experiment with in a budding development of 
accelerated interfaces without any fundamental forks. You might want to 
read the FAQ at http://fedoraproject.org/wiki/RenderingProject/aiglx on 
doing incremental updates in comparison to whole sale rewrites of a X 
server.

The media likes to paint black and white situations of X vs Y while 
there is also a code sharing between XGL and AIGLX going on.

http://www.0xdeadbeef.com/weblog/?p=178
http://lists.freedesktop.org/archives/xorg/2006-February/013326.html

-- 
Rahul 





From mharris at mharris.ca  Thu Mar  2 19:02:27 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Thu, 02 Mar 2006 14:02:27 -0500
Subject: aiglx
In-Reply-To: <d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
References: <4404EF88.4080000@paradigma.pt>
	<44062996.7000907@fedoraproject.org>
	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
Message-ID: <44074143.6070905@mharris.ca>

Benjy Grogan wrote:
> Isn't Red Hat forking the accelerated GL community by working on AIGLX 
> instead of Xgl?

No.  Aside from that though, Xgl benefits from the work being done on
aiglx.

> It seems like Xgl is to AIGLX as SELinux is to AppArmor.

That would be a giant misconception on your part.


> It would be great if Red Hat and Novell could convene under a big tent 
> and agree to work on SELinux for security and Xgl for accelereated GL.

You don't seem to understand the problem domain very well.  Might
be worth educating yourself on exactly what Xgl is, and exactly
what accelerated indirect rendering is before formulating grossly
ignorant opinions.



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From d.jacobfeuerborn at conversis.de  Thu Mar  2 19:18:14 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Thu, 02 Mar 2006 20:18:14 +0100
Subject: aiglx
In-Reply-To: <44073F1C.4000906@fedoraproject.org>
References: <4404EF88.4080000@paradigma.pt>	<44062996.7000907@fedoraproject.org>	<44072307.80803@conversis.de>
	<44073F1C.4000906@fedoraproject.org>
Message-ID: <440744F6.2030904@conversis.de>

Rahul Sundaram wrote:
> Dennis Jacobfeuerborn wrote:
> 
>> Rahul Sundaram wrote:
>>
>>> Vitor Domingos wrote:
>>>
>>>> Is AIGLX going to appear on FC5? I've test it with ATI RADEON 7000, 
>>>> with all the hacks that's on the wiki page, and it's too dam slow....
>>>>
>>> Some of the pieces are already integrated. See the section on 
>>> technical details for the current status. 
>>> http://fedoraproject.org/wiki/RenderingProject/aiglx.  Since the 
>>> features are not enabled by default, yet performance shouldnt be much 
>>> of a concern for FC5. Reports with hardware details and benchmarks 
>>> would be quite useful to fine tune it I guess.
>>
>>
>> Is the integrated compositing manager in metacity also supposed to 
>> work with the "regular" Xorg shipped with FC5 (ie as a replacement for 
>> xcompmgr) or only with the AIGLX enabled version?
>>
> The regular Xorg server is getting all the patches for AIGLX merged into 
> it. Meanwhile the compositing manager is metacity can work in tandem or 
> without it.

When I turn on the compositing manager using the gconf-editor my desktop 
goes completely ballistic. The moment click the checkbox metacity restarts 
itself over and over again and the only way to get things back to normal is 
to switch to a text console, wait a few seconds for metacity to give up and 
then switch back to X11, uncheck the compositing_manager key again. After 
that I'm left without window decorations which can be fixed by restarting 
metacity manually again. The xcompmgr I compiled from CVS works fine though.

Regards,
   Dennis



From david at fubar.dk  Thu Mar  2 19:37:50 2006
From: david at fubar.dk (David Zeuthen)
Date: Thu, 02 Mar 2006 14:37:50 -0500
Subject: Udev issues in today's coming rawhide
In-Reply-To: <1141310361.3206.64.camel@laptopd505.fenrus.org>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org> <4406EC09.8010605@redhat.com>
	<4407002D.4090000@unb.ca>
	<1141310361.3206.64.camel@laptopd505.fenrus.org>
Message-ID: <1141328270.6117.7.camel@daxter.boston.redhat.com>

On Thu, 2006-03-02 at 15:39 +0100, Arjan van de Ven wrote:
> better would be to use UUID's, or at least vendor identification strings
> etc from the device. We need to NOT tie these device names to underlying
> accidental device numbers. That is a major major step back.

Uhm.. try:

 $ tree /dev/disk

Of course, if you think that relying on device node names is crazy in
the first place... then this discussion is kinda useless :-)

    David




From benjy.grogan at gmail.com  Thu Mar  2 19:39:23 2006
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Thu, 2 Mar 2006 14:39:23 -0500
Subject: aiglx
In-Reply-To: <440740E9.6020600@fedoraproject.org>
References: <4404EF88.4080000@paradigma.pt>
	<44062996.7000907@fedoraproject.org>
	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
	<440740E9.6020600@fedoraproject.org>
Message-ID: <d82d6db50603021139o6a6ffe61w713abf6c29404534@mail.gmail.com>

On 3/2/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>
> Benjy Grogan wrote:
>
> >Isn't Red Hat forking the accelerated GL community by working on AIGLX
> >instead of Xgl?  It seems like Xgl is to AIGLX as SELinux is to AppArmor.
> >
> >
> The analogy here seems to be off the mark since AIGLX and SELinux has
> been developed in the open right from the start unlike AppArmor and XGL
> and unlike security frameworks such as SELinux, there are different
> approaches you can experiment with in a budding development of
> accelerated interfaces without any fundamental forks. You might want to
> read the FAQ at http://fedoraproject.org/wiki/RenderingProject/aiglx on
> doing incremental updates in comparison to whole sale rewrites of a X
> server.
>
> The media likes to paint black and white situations of X vs Y while
> there is also a code sharing between XGL and AIGLX going on.


You're referring to the GLX_EXT_texture_from_pixmap extension.  Of course
there will be sharing but ultimately they are two competing methods of
improving X.  AIGLX, AFAIK just appeared a few weeks ago.  Xgl has been in
the works for a few years, and there's alot of thought behind it.  There's
an architecture (much like SELinux...) and while I'm still not certain of
this, hopefully more than eye candy.

AIGLX appears to me to be all eye candy.  It's been put together last minute
as an answer to Xgl.  I wasn't impressed by the demos of AIGLX.  I was blown
away by the demos for Xgl.  I like how Miguel de Icaza characterized Xgl as
"a lot of work" and that's what's needed.  It would be cool if Red Hat got
behind Xgl to accelerate development on Xgl, just like Novell should've
stayed with SELinux and accelerated it's development.

But it is somewhat black and white to pit XGL versus AIGLX, nevertheless I
think it will prove true in the end.

Benji
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060302/2ff89424/attachment.htm>

From sundaram at fedoraproject.org  Thu Mar  2 19:45:20 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 03 Mar 2006 01:15:20 +0530
Subject: aiglx
In-Reply-To: <d82d6db50603021139o6a6ffe61w713abf6c29404534@mail.gmail.com>
References: <4404EF88.4080000@paradigma.pt>	<44062996.7000907@fedoraproject.org>	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>	<440740E9.6020600@fedoraproject.org>
	<d82d6db50603021139o6a6ffe61w713abf6c29404534@mail.gmail.com>
Message-ID: <44074B50.9030807@fedoraproject.org>

Benjy Grogan wrote:

>
>>The media likes to paint black and white situations of X vs Y while
>>there is also a code sharing between XGL and AIGLX going on.
>>    
>>
>
>
>You're referring to the GLX_EXT_texture_from_pixmap extension. 
>
Not solely. Kindly refer to *both* the links posted earlier that you 
have trimmed off.

> Of course
>there will be sharing but ultimately they are two competing methods of
>improving X. 
>
Ya. Thats good and we have other approaches like XeGL too. Eventually 
the best code wins out. Thats how it works.

> AIGLX, AFAIK just appeared a few weeks ago.  Xgl has been in
>the works for a few years, and there's alot of thought behind it.
>
Code needs to be out and peer reviewed. Thats what matters.

>AIGLX appears to me to be all eye candy.  It's been put together last minute
>as an answer to Xgl.  
>
Really?  You might want to refer to the project page at 
http://fedoraproject.org/wiki/RenderingProject/ for the ideas behind the 
project. Eye candy isnt specified as a goal at all. You might also want 
to look at Xorg development a bit more if you think these efforts are 
new by any means.


-- 
Rahul 





From shiva at sewingwitch.com  Thu Mar  2 21:08:42 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Thu, 02 Mar 2006 13:08:42 -0800
Subject: username best practices and other conventions
In-Reply-To: <1cef3e950603020821j24b659b6r38139a4ccd49ca54@mail.gmail.com>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
	<1cef3e950603020821j24b659b6r38139a4ccd49ca54@mail.gmail.com>
Message-ID: <FE679D2A2CDF2BCFD6DABC2B@[10.0.0.14]>

--On Thursday, March 02, 2006 4:21 PM +0000 Joe Desbonnet 
<jdesbonnet at gmail.com> wrote:

> I think it's time to move beyond those traditional limits. At some
> point we got over the 14 char file name limits, and the world is a
> better place for it.

I use a lot of real usernames longer than 8 characters and my biggest issue 
is ugly ls output. How do others deal with that? Can you get ls to widen 
columns to the width needed to accommodate the widest token? (A similar 
problem occurs when listing a very large file, since the size overflows 
that column.)



From rodd at clarkson.id.au  Thu Mar  2 21:12:59 2006
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 03 Mar 2006 08:12:59 +1100
Subject: SD/MMC Support (was Re: Hotplug: no more fstab entries)
In-Reply-To: <1140701508.3633.9.camel@daxter.boston.redhat.com>
References: <20060222153244.002ea18c@dhcp05.addix.net>
	<43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca>
	<604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com>
	<20060223103910.2d9874ae@dhcp05.addix.net>
	<1140698854.3633.1.camel@daxter.boston.redhat.com>
	<20060223141925.5a085d71@dhcp05.addix.net>
	<1140701508.3633.9.camel@daxter.boston.redhat.com>
Message-ID: <1141333979.2793.7.camel@localhost.localdomain>

On Thu, 2006-02-23 at 08:31 -0500, David Zeuthen wrote:
> see 
> 
>  http://freedesktop.org/~david/gnome-mount-properties-0.01.png
> 
> for some work in progress.

Okay, this screen shot is just plain teasing.

Would you like to explain to the masses (or maybe just me) how you got
SD/MMC support working in Fedora.

I notice that 'modprobe mmc_block' now installs the modules needed, but
beyond this it's not doing anything.

Doesn't notice the insertion of cards into the reader (which lspci
reports as a):

03:01.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)

Nothing shows up in /dev

Nothing mounts, that's for certain.

This isn't the plug N play I'm getting used to in Fedora, so what do I
need to do.  It would be great to have support for SD/MMC in FC5 and it
certainly looks like we're close.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From sundaram at fedoraproject.org  Thu Mar  2 21:16:41 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 03 Mar 2006 02:46:41 +0530
Subject: Hotplug: no more fstab entries
In-Reply-To: <20060223172858.GC13799@devserv.devel.redhat.com>
References: <20060222153244.002ea18c@dhcp05.addix.net>	<43FC978E.6040006@feuerpokemon.de>
	<43FCB30D.2020509@unb.ca>	<604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com>	<20060223103910.2d9874ae@dhcp05.addix.net>	<1140698854.3633.1.camel@daxter.boston.redhat.com>	<20060223141925.5a085d71@dhcp05.addix.net>	<1140701508.3633.9.camel@daxter.boston.redhat.com>	<20060223160518.GA13799@devserv.devel.redhat.com>	<1140711491.24114.18.camel@daxter.boston.redhat.com>
	<20060223172858.GC13799@devserv.devel.redhat.com>
Message-ID: <440760B9.9040005@fedoraproject.org>

Bill Nottingham wrote:

>>>This is all documented in the release notes, right?
>>>      
>>>
>>If you think it's necessary.. feel free to add it.
>>    
>>
>
>I really think we could use one.
>
>Bill
>  
>
Available at http://fedoraproject.org/wiki/Docs/Beats/OverView. Will be 
in the overview section in the FC5 release notes in the ISO images.


-- 
Rahul 





From zaitcev at redhat.com  Thu Mar  2 22:48:30 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 2 Mar 2006 14:48:30 -0800
Subject: Java - Azureus memory usage
In-Reply-To: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
Message-ID: <20060302144830.27560e95.zaitcev@redhat.com>

On Tue, 28 Feb 2006 14:30:35 +0000, "Garry Harthill" <gazzerh at gmail.com> wrote:

> 213mb memory and 50% CPU seems a bit excessive.

> Anyone else seeing this?

Nope, mine is at about 53MB with Fedora torrents. It eats a bit of CPU,
but I run a VIA C3. Heck, ssh eats CPU on that wimpy chip.

-- Pete



From zaitcev at redhat.com  Thu Mar  2 22:50:20 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 2 Mar 2006 14:50:20 -0800
Subject: glxgears
In-Reply-To: <1141173320.23703.2.camel@soncomputer>
References: <1141173320.23703.2.camel@soncomputer>
Message-ID: <20060302145020.7d622ee3.zaitcev@redhat.com>

On Tue, 28 Feb 2006 19:35:20 -0500, Louis E Garcia II <louisg00 at bellsouth.net> wrote:

> Where is glxgears in FC54T3? I just put my radeon 9250 in abgmode 8 and
> think it is actually slower.

Had the same question, "yum search" works fine to find it.

-- Pete



From zaitcev at redhat.com  Thu Mar  2 22:53:38 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 2 Mar 2006 14:53:38 -0800
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <1141174657.19512.3.camel@localhost.localdomain>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
Message-ID: <20060302145338.0f8f7aac.zaitcev@redhat.com>

On Wed, 01 Mar 2006 00:57:37 +0000, Richard Hughes <hughsient at gmail.com> wrote:

> So if I was buying a new laptop sometime soonish, what chipset is best
> for all this new accelerated X stuff?

Apropos this, what is the situation with VIA Unichrome? Mike?
IIRC, they had an open driver as a plug-in for old X, and it was
poorly written, so someone started a rewrite. Did anything come
out of it? You know, those Averatecs really look attractive...

-- Pete



From jon.nettleton at gmail.com  Thu Mar  2 23:32:27 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Thu, 02 Mar 2006 18:32:27 -0500
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <20060302145338.0f8f7aac.zaitcev@redhat.com>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<20060302145338.0f8f7aac.zaitcev@redhat.com>
Message-ID: <1141342347.2573.10.camel@averatec>

On Thu, 2006-03-02 at 14:53 -0800, Pete Zaitcev wrote:
> On Wed, 01 Mar 2006 00:57:37 +0000, Richard Hughes <hughsient at gmail.com> wrote:
> 
> > So if I was buying a new laptop sometime soonish, what chipset is best
> > for all this new accelerated X stuff?
> 
> Apropos this, what is the situation with VIA Unichrome? Mike?
> IIRC, they had an open driver as a plug-in for old X, and it was
> poorly written, so someone started a rewrite. Did anything come
> out of it? You know, those Averatecs really look attractive...
> 
> -- Pete
> 

I currently use an Averatec 3250, that I have had for a year and a half.
It is a nice little machine (4.4lbs) and completely suites my needs.  I
currently run the via driver from www.openchrome.org, and have no video
problems with it.  These drivers do have EXA support now thanks to some
excellent work by Thomas Hellstr?m.

I will warn you that suspend to ram does not work.  It is one of the VIA
chipsets that suspends properly then reboots when you hit the power
button to wake it up. There has been a kernel bugzilla open since 2.6.9.
Suspend to disk does work on and off, depending what has been done to
the kernel that night.  Since this is just my mobile machine I don't
have a huge need for suspend.

Hope this helps.

Jon



From vd at paradigma.pt  Thu Mar  2 22:57:14 2006
From: vd at paradigma.pt (Vitor Domingos)
Date: Thu, 02 Mar 2006 22:57:14 +0000
Subject: aiglx
In-Reply-To: <44074143.6070905@mharris.ca>
References: <4404EF88.4080000@paradigma.pt>	<44062996.7000907@fedoraproject.org>	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
	<44074143.6070905@mharris.ca>
Message-ID: <4407784A.1080508@paradigma.pt>

Mike A. Harris wrote on 03/02/2006 07:02 PM:
> Benjy Grogan wrote:
>> It would be great if Red Hat and Novell could convene under a big tent 
>> and agree to work on SELinux for security and Xgl for accelereated GL.
> 
> You don't seem to understand the problem domain very well.  Might
> be worth educating yourself on exactly what Xgl is, and exactly
> what accelerated indirect rendering is before formulating grossly
> ignorant opinions.

Maybe this could help:
http://www.freesoftwaremagazine.com/free_issues/newsletters/accelerated_x/index_p1.html

Regards,
-- 
Vitor Domingos
Paradigma.pt



From rodd at clarkson.id.au  Thu Mar  2 23:48:05 2006
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 03 Mar 2006 10:48:05 +1100
Subject: SD/MMC Support (was Re: Hotplug: no more fstab entries)
In-Reply-To: <1141333979.2793.7.camel@localhost.localdomain>
References: <20060222153244.002ea18c@dhcp05.addix.net>
	<43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca>
	<604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com>
	<20060223103910.2d9874ae@dhcp05.addix.net>
	<1140698854.3633.1.camel@daxter.boston.redhat.com>
	<20060223141925.5a085d71@dhcp05.addix.net>
	<1140701508.3633.9.camel@daxter.boston.redhat.com>
	<1141333979.2793.7.camel@localhost.localdomain>
Message-ID: <1141343285.17636.0.camel@localhost.localdomain>

On Fri, 2006-03-03 at 08:12 +1100, Rodd Clarkson wrote:
> On Thu, 2006-02-23 at 08:31 -0500, David Zeuthen wrote:
> > see 
> > 
> >  http://freedesktop.org/~david/gnome-mount-properties-0.01.png
> > 
> > for some work in progress.
> 
> Okay, this screen shot is just plain teasing.
> 
> Would you like to explain to the masses (or maybe just me) how you got
> SD/MMC support working in Fedora.
> 
> I notice that 'modprobe mmc_block' now installs the modules needed, but
> beyond this it's not doing anything.
> 
> Doesn't notice the insertion of cards into the reader (which lspci
> reports as a):
> 
> 03:01.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)
> 
> Nothing shows up in /dev
> 
> Nothing mounts, that's for certain.
> 
> This isn't the plug N play I'm getting used to in Fedora, so what do I
> need to do.  It would be great to have support for SD/MMC in FC5 and it
> certainly looks like we're close.

Hmmm, could this be because the kernel doesn't have sdhci support?


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From felipe.alfaro at gmail.com  Fri Mar  3 00:07:43 2006
From: felipe.alfaro at gmail.com (Felipe Alfaro Solana)
Date: Fri, 3 Mar 2006 01:07:43 +0100
Subject: Vino
Message-ID: <6f6293f10603021607s1ca409e3gd3e448ee1eebd9f4@mail.gmail.com>

Hello,

I have been playing with VINO on Fedora Core 5 Test 3 but I find it
pretty unusable. First, screen updates are painfully slow: sometimes
on the real desktop I launch a gnome-terminal, but it takes up to five
seconds for the window to appear on the remote VNC client (it appears
almost instantly on the real desktop). Other times, working on the
real desktop produces no updates on the remote VNC client.

At first, I thought VINO wasn't using XDamage, but it seems it is,
since "xpyinfo | grep -i damage" reveals the local X server supports
the XDamage extension, and also "ldd /usr/libexec/vino-server" reveals
it is linked against libXdamage.so.1.

Am I the only one experiencing these issues with VINO?
Thanks.



From mharris at mharris.ca  Fri Mar  3 00:27:28 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Thu, 02 Mar 2006 19:27:28 -0500
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <20060302145338.0f8f7aac.zaitcev@redhat.com>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<20060302145338.0f8f7aac.zaitcev@redhat.com>
Message-ID: <44078D70.8010906@mharris.ca>

Pete Zaitcev wrote:
> On Wed, 01 Mar 2006 00:57:37 +0000, Richard Hughes <hughsient at gmail.com> wrote:
> 
> 
>>So if I was buying a new laptop sometime soonish, what chipset is best
>>for all this new accelerated X stuff?
> 
> 
> Apropos this, what is the situation with VIA Unichrome? Mike?
> IIRC, they had an open driver as a plug-in for old X, and it was
> poorly written, so someone started a rewrite. Did anything come
> out of it? You know, those Averatecs really look attractive...

There are about 100 via driver forks nowadays.  The original via
code, which it seems via updates once a year or so with a huge
press release.  The differences in their code seem to get merged
into the X.Org via driver.

Then there is the unichrome project - a fork of that, and
openchrome, a fork of unichrome.  Why so many forks?  Certain
individuals don't play well with others essentially.

Which one to use?  We ship the X.Org one, and never see any
bug reports, so I assume it must work well enough for FC users,
but I've never ran it personally, so don't know how stable or
reliable it really is, or what the featureset is.

I guess people probably start out using the Xorg driver, and
if it doesn't work perhaps they hop ship to one of the other 2
drivers.  Hard to say because there is almost zero feedback. ;)

I'm often asked which laptop chipset one should buy, or which
laptop chipset is best supported.  Here are 2 answers I generally
give, and they're dead honest, albeit a bit blunt.  I say that
because sometimes people think I'm blowing them off, when I'm
really just giving the reality of things:

1) None of the video chipsets are supported "the best".  Roll
    a dice, you get a video chipset that has some supported
    features, along with various bugs/problems to work around.

or

2) Whichever video chip works best for one's purposes after
they manually test every laptop on the market with the current
drivers, and decide which one meets their needs.


Yes, these answers suck, but they reflect reality, which also
sucks.  My advice is don't buy a laptop unless you can get
by with the kernel console driver and 24 VCs. ;)



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From gianluca.cecchi at gmail.com  Fri Mar  3 00:53:59 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Fri, 3 Mar 2006 01:53:59 +0100
Subject: kexec and root filesystem question
Message-ID: <561c252c0603021653q7b267064v@mail.gmail.com>

After updating my test3 rawhide to today updates, and after reading
about kexec, I decided to try it: impressive!
My system is a dual amd mp with serial ata pci card, scsi pci card and
other cards/devices, so bios startup phase is quite annoying,
especially at 01:39 AM... ;-)
And also my main bootloader is grub on CentOS 4 on first disk, with
option to chainload grub of FC5, installed in its root partition on
second hd... so two grub splash screens are too many at this time...
So my runnning kernel was 1955smp and just installed updates and in
particular the 1996smp kernel.
I ran:
1) kexec -l /boot/vmlinuz-2.6.15-1.1996_FC5smp
--initrd=/boot/initrd-2.6.15-1.1996_FC5smp.img --append="ro
root=/dev/sdb2 rhgb quiet"
to load new kernel into memory
2) shutdown 0
to put system in single user mode and stop various services
3) kexec -e
to reboot to the new loaded kernel
All has gone well with immediate boot up of the kernel!
Only one doubt:
at boot obviously the root filesystem appears uncleanly closed and so
I get the messages:
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: sdb2: orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 1263797
ext3_orphan_cleanup: deleting unreferenced inode 819283
ext3_orphan_cleanup: deleting unreferenced inode 819224
EXT3-fs: sdb2: 3 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.

Of course, as I was in init 1, "bowls were quite slow", but the orphan
clean up was not the marvellous message I like...
DO I have means to avoid this situation? Furthermore with FC5 you
don't get the option to check filesystem on unclean shutdown and so
only replay of journal is executed (correct?)
Thanks for your time
Gianluca



From hellwolf at seu.edu.cn  Fri Mar  3 00:56:59 2006
From: hellwolf at seu.edu.cn (ZC Miao)
Date: Fri, 03 Mar 2006 08:56:59 +0800
Subject: post script of fonts-chinese-3.02-4.1 has a typo
Message-ID: <1141347419.2336.6.camel@cocteau.hellwolf-misty.org>

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

I'd submit it for a long time, but no response :(
-- 
ZC Miao<hellwolf at seu.edu.cn>
http://hellwolf.cublog.cn/

gpg --keyserver keyserver.veridis.com --recv-key  0x6B174C6F

From notting at redhat.com  Fri Mar  3 02:52:42 2006
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 2 Mar 2006 21:52:42 -0500
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <44078D70.8010906@mharris.ca>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<20060302145338.0f8f7aac.zaitcev@redhat.com>
	<44078D70.8010906@mharris.ca>
Message-ID: <20060303025242.GB26983@devserv.devel.redhat.com>

Mike A. Harris (mharris at mharris.ca) said: 
> Which one to use?  We ship the X.Org one, and never see any
> bug reports, so I assume it must work well enough for FC users,
> but I've never ran it personally, so don't know how stable or
> reliable it really is, or what the featureset is.

It works for me on x86_64, although switching to a VC occasionally
does odd things to the pallette. And DRI is well and truly
hosed (bug 179970).

Bill



From harald at redhat.com  Fri Mar  3 05:44:06 2006
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 03 Mar 2006 06:44:06 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <20060302162713.GA3700@localhost.localdomain>
References: <1141286103.31231.104.camel@ender>	<20060302112310.GA4822@dspnet.fr.eu.org>	<4406EC09.8010605@redhat.com>
	<4407002D.4090000@unb.ca>	<1141310361.3206.64.camel@laptopd505.fenrus.org>	<20060302151302.GA13377@localhost.localdomain>	<1141313150.3206.72.camel@laptopd505.fenrus.org>	<44071577.6070908@redhat.com>
	<20060302162713.GA3700@localhost.localdomain>
Message-ID: <4407D7A6.3050707@redhat.com>

John Thacker wrote:
> On Thu, Mar 02, 2006 at 04:55:35PM +0100, Harald Hoyer wrote:
> 
>>Arjan, if you want to have IDs... use:
>>/dev/disk/by-id/
> 
> 
> Which of course doesn't work for CDROMs (and neither does /by-uuid of course),
> leaving us back where we started looking for another hack (like the one
> used right now) for them.
> 
> John Thacker
> 

Huh?


$ tree /dev/disk/by-id/
/dev/disk/by-id/
|-- ata-PIONEER_DVD-RW_DVR-105_BKDL086471WL -> ../../hdd



From harald at redhat.com  Fri Mar  3 05:58:03 2006
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 03 Mar 2006 06:58:03 +0100
Subject: Udev issues in today's coming rawhide
In-Reply-To: <4407D7A6.3050707@redhat.com>
References: <1141286103.31231.104.camel@ender>	<20060302112310.GA4822@dspnet.fr.eu.org>	<4406EC09.8010605@redhat.com>	<4407002D.4090000@unb.ca>	<1141310361.3206.64.camel@laptopd505.fenrus.org>	<20060302151302.GA13377@localhost.localdomain>	<1141313150.3206.72.camel@laptopd505.fenrus.org>	<44071577.6070908@redhat.com>	<20060302162713.GA3700@localhost.localdomain>
	<4407D7A6.3050707@redhat.com>
Message-ID: <4407DAEB.9050204@redhat.com>

Harald Hoyer wrote:
> Huh?
> 
> 
> $ tree /dev/disk/by-id/
> /dev/disk/by-id/
> |-- ata-PIONEER_DVD-RW_DVR-105_BKDL086471WL -> ../../hdd
> 
ok, this one is lucky to have a serial id.

Nevertheless, /dev/cdrom* is only for pam_console and CLI use.
Real GUI apps should provide a reasonable selection list and maybe use HAL. Look at k3b, xcdroast, 
nautilus-cdburner...



From thacker at math.cornell.edu  Fri Mar  3 06:01:49 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Fri, 3 Mar 2006 01:01:49 -0500
Subject: Udev issues in today's coming rawhide
In-Reply-To: <4407D7A6.3050707@redhat.com>
References: <1141286103.31231.104.camel@ender>
	<20060302112310.GA4822@dspnet.fr.eu.org>
	<4406EC09.8010605@redhat.com> <4407002D.4090000@unb.ca>
	<1141310361.3206.64.camel@laptopd505.fenrus.org>
	<20060302151302.GA13377@localhost.localdomain>
	<1141313150.3206.72.camel@laptopd505.fenrus.org>
	<44071577.6070908@redhat.com>
	<20060302162713.GA3700@localhost.localdomain>
	<4407D7A6.3050707@redhat.com>
Message-ID: <20060303060149.GA14349@localhost.localdomain>

On Fri, Mar 03, 2006 at 06:44:06AM +0100, Harald Hoyer wrote:
> John Thacker wrote:
> >>/dev/disk/by-id/
> >
> >Which of course doesn't work for CDROMs 
> >
> Huh?
> 
> $ tree /dev/disk/by-id/
> /dev/disk/by-id/
> |-- ata-PIONEER_DVD-RW_DVR-105_BKDL086471WL -> ../../hdd

Well, it certainly doesn't work on mine.  From looking at the rules,
it has something to do with both optical drives having no ID_SERIAL 
environment variable, since /dev/disk/by-id/ doesn't get created in
that case.  I was wondering if that was just me.  I kind of assumed
it wasn't, since the drives have different badges and one is a DVD-RW
while one is a CDRW.

$ udevinfo -q all -n /dev/hdc
P: /block/hdc
N: hdc
S: cdrom
S: cdrom-hdc
S: dvd
S: dvd-hdc
S: cdwriter
S: cdwriter-hdc
S: cdrw
S: cdrw-hdc
S: dvdwriter
S: dvdwriter-hdc
S: dvdrw
S: dvdrw-hdc
S: disk/by-path/pci-0000:00:09.0-ide-1:0
E: ID_TYPE=cd
E: ID_MODEL=_NEC_DVD_RW_ND-3520A
E: ID_SERIAL=
E: ID_REVISION=1.04
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:09.0-ide-1:0

$ udevinfo -q all -n /dev/hdd
P: /block/hdd
N: hdd
S: cdrom
S: cdrom-hdd
S: cdwriter
S: cdwriter-hdd
S: cdrw
S: cdrw-hdd
S: disk/by-path/pci-0000:00:09.0-ide-1:1
E: ID_TYPE=cd
E: ID_MODEL=LITE-ON_LTR-24102B
E: ID_SERIAL=
E: ID_REVISION=5S5A
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:09.0-ide-1:1

compared to

$ udevinfo -q all -n /dev/hda
P: /block/hda
N: hda
S: disk/by-id/ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191
S: disk/by-path/pci-0000:00:09.0-ide-0:0
E: ID_TYPE=disk
E: ID_MODEL=WDC_WD1200JB-75CRA0
E: ID_SERIAL=WD-WMA8C4186191
E: ID_REVISION=16.06V16
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:09.0-ide-0:0

and
$ udevinfo -q all -n /dev/hdb
P: /block/hdb
N: hdb
S: disk/by-id/ata-MAXTOR_6L080J4_664131818222
S: disk/by-path/pci-0000:00:09.0-ide-0:1
E: ID_TYPE=disk
E: ID_MODEL=MAXTOR_6L080J4
E: ID_SERIAL=664131818222
E: ID_REVISION=A93.0500
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:09.0-ide-0:1

results in
$ tree /dev/disk/by-id/
/dev/disk/by-id/
|-- ata-MAXTOR_6L080J4_664131818222 -> ../../hdb
|-- ata-MAXTOR_6L080J4_664131818222-part1 -> ../../hdb1
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191 -> ../../hda
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part1 -> ../../hda1
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part10 -> ../../hda10
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part2 -> ../../hda2
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part5 -> ../../hda5
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part6 -> ../../hda6
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part7 -> ../../hda7
|-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part8 -> ../../hda8
`-- ata-WDC_WD1200JB-75CRA0_WD-WMA8C4186191-part9 -> ../../hda9

John Thacker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060303/17032255/attachment.sig>

From igorm5 at vip.hr  Fri Mar  3 07:42:25 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Fri, 03 Mar 2006 08:42:25 +0100
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <44078D70.8010906@mharris.ca>
References: <1141173320.23703.2.camel@soncomputer>	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>	<1141174657.19512.3.camel@localhost.localdomain>	<20060302145338.0f8f7aac.zaitcev@redhat.com>
	<44078D70.8010906@mharris.ca>
Message-ID: <4407F361.4010908@vip.hr>

Mike A. Harris wrote:

> I'm often asked which laptop chipset one should buy, or which
> laptop chipset is best supported.

It would be much easier for us if we could buy a laptop with Linux
preinstalled, which I haven't seen yet here in Croatia. I saw some
laptops with FreeDOS, but not with Linux.

BTW why Red Hat does not make some contract with some laptop
manufacturer in order to bring Red Hat or fedora to laptops? Is that
such a bad idea? I saw that Mandriva and Ubuntu made this with some
manufacturers (HP, I think) for some markets (South America, I think).

> Here are 2 answers I generally
> give, and they're dead honest, albeit a bit blunt.  I say that
> because sometimes people think I'm blowing them off, when I'm
> really just giving the reality of things:
> 1) None of the video chipsets are supported "the best".  Roll
>     a dice, you get a video chipset that has some supported
>     features, along with various bugs/problems to work around.
> or
> 2) Whichever video chip works best for one's purposes after
> they manually test every laptop on the market with the current
> drivers, and decide which one meets their needs.

I use nVidia (Xelo FX5200) with closed source drivers because TV out is
well supported.

> Yes, these answers suck, but they reflect reality, which also
> sucks.  My advice is don't buy a laptop unless you can get
> by with the kernel console driver and 24 VCs. ;)

I've got an impression that IBM's are well supported on Linux:
http://www-307.ibm.com/pc/support/site.wss/MIGR-48NT8D.html
There are probably some other manufacturers as well supported, but I
didn't quite make any further research.

-- 
Igor Jagec



From mike at miketc.com  Fri Mar  3 08:14:30 2006
From: mike at miketc.com (Mike Chambers)
Date: Fri, 03 Mar 2006 02:14:30 -0600
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <4407F361.4010908@vip.hr>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<20060302145338.0f8f7aac.zaitcev@redhat.com>
	<44078D70.8010906@mharris.ca> <4407F361.4010908@vip.hr>
Message-ID: <1141373670.2240.4.camel@scrappy.miketc.com>

On Fri, 2006-03-03 at 08:42 +0100, Igor Jagec wrote:

> It would be much easier for us if we could buy a laptop with Linux
> preinstalled, which I haven't seen yet here in Croatia. I saw some
> laptops with FreeDOS, but not with Linux.
> 
> BTW why Red Hat does not make some contract with some laptop
> manufacturer in order to bring Red Hat or fedora to laptops? Is that
> such a bad idea? I saw that Mandriva and Ubuntu made this with some
> manufacturers (HP, I think) for some markets (South America, I think).

Try http://www.dell.com/linux

See what that turns up.

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt, then it's hilarious!"



From buildsys at redhat.com  Fri Mar  3 08:21:31 2006
From: buildsys at redhat.com (Build System)
Date: Fri, 3 Mar 2006 03:21:31 -0500
Subject: rawhide report: 20060303 changes
Message-ID: <200603030821.k238LVlw002256@porkchop.devel.redhat.com>

 

Removed package up2date

Removed package rhn-applet

Updated Packages:

NetworkManager-0.5.1-18.cvs20060302
-----------------------------------
* Thu Mar 02 2006 Jeremy Katz <katzj at redhat.com> - 0.5.1-18.cvs20060302
- updated cvs snapshot.  seems to make airo much less spastic

* Thu Mar 02 2006 Christopher Aillon <caillon at redhat.com>
- Move the unversioned libnm_glib.so to the -devel package

anaconda-10.92.15-1
-------------------
* Fri Mar 03 2006 Jeremy Katz <katzj at redhat.com> - 10.92.15-1
- conditional code is now in yum (pnasrat)
- sort network devices smarter (clumens, #166842)
- select needed fs entries (#183271)
- more serbian fixes (#182591)

comps-extras-11.1-1
-------------------
* Thu Mar 02 2006 Bill Nottingham <notting at redhat.com> - 11.1-1
- new education icon from Diana Fong
- update XFCE icon

* Wed Mar 01 2006 Bill Nottingham <notting at redhat.com> - 11-1
- pirut/anaconda now use 24x24. update sizes
- various additions/removals
- python scripts aren't useful with current repositories, remove them

* Thu May 05 2005 Bill Nottingham <notting at redhat.com> - 10.3-1
- updated icons (<dfong at redhat.com>)

distcache-1.4.5-13
------------------
* Thu Mar 02 2006 Joe Orton <jorton at redhat.com> 1.4.5-13
- avoid uid collision with exim (#182091)

dovecot-1.0-0.beta2.5
---------------------
* Mon Feb 27 2006 Petr Rockai <prockai at redhat.com> - 1.0-0.beta2.5
- fix #182240 by looking in lib64 for libs first and then lib
- fix comment #1 in #182240 by copying over the example config files
  to documentation directory

epic-4:2.2-3
------------
* Tue Feb 21 2006 Peter Vrabec <pvrabec at redhat.com> 4:2.2-3
- fix fuzz test fail (#181036)

gdm-1:2.13.0.9-1
----------------
* Tue Feb 28 2006 Ray Strode <rstrode at redhat.com> - 1:2.13.0.9-1
- Update to 2.13.0.9
- Use new %post section, written by 
  Michal Jaegermann <michal at harddata.com> (bug 183082)

glibc-2.3.91-1
--------------
* Thu Mar 02 2006 Jakub Jelinek <jakub at redhat.com> 2.3.91-1
- update from CVS
  - fixes for various arches
- ensure malloc returns pointers aligned to at least
  MIN (2 * sizeof (size_t), __alignof__ (long double))
  (only on ppc32 this has not been the case lately with addition
   of 128-bit long double, #182742)

* Wed Mar 01 2006 Jakub Jelinek <jakub at redhat.com> 2.3.90-39
- update from CVS

gnome-power-manager-2.13.92-3
-----------------------------
* Thu Mar 02 2006 Ray Strode <rstrode at redhat.com> - 2.13.92-3
- Add patch from Richard Hughes to potentially fix a
  crasher bug (bug 183127)

gthumb-2.7.3-2
--------------
* Thu Mar 02 2006 Ray Strode <rstrode at redhat.com> - 2.7.3-2
- Make saving work again (bug 183141)

kernel-2.6.15-1.2008_FC5
------------------------
* Thu Mar 02 2006 Dave Jones <davej at redhat.com>
- Fix acpi_os_acquire_object() with IRQs disabled debug msgs.
- Mark unwind info for signal trampolines in vDSOs

* Wed Mar 01 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc5-git4
- Fix leak in RAID1
- Further fixing of selinuxfs link count. (#182001)
- Enable PATA ports on Promise SATA. (#179369)
- NFS: writes should not clobber utimes() calls. (#183208)

libnotify-0.3.0-5
-----------------
* Thu Mar 02 2006 Ray Strode <rstrode at redhat.com> - 0.3.0-5
- patch out config.h include from public header

mono-1.1.13.2-5
---------------
* Thu Mar 02 2006 Ray Strode <rstrode at redhat.com> - 1.1.13.2-5
- Updated patch from Jakub (1.1.13.2-3 to 1.1.13.2-5 are 
  for bug 182965)

pirut-1.0.0-1
-------------
* Fri Mar 03 2006 Jeremy Katz <katzj at redhat.com> - 1.0.0-1
- Fix formatting in reboot dialog (#183597)
- Show category pixbuf if there's not one for the group (#183545)
- Ensure groups are shown as selected
- Catch locking error (#183685)

redhat-menus-6.7.5-1
--------------------
* Thu Mar 02 2006 Bill Nottingham <notting at redhat.com> - 6.7.5-1
- add locales (#176139)

rhpl-0.185-1
------------
* Thu Mar 02 2006 Jeremy Katz <katzj at redhat.com> - 0.185-1
- fix serbian keyboard (#182591)

scim-1.4.4-9
------------
* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-9
- scim-libs prereqs gtk2 > 2.8 so that update-gtk-immodules in %post can
  read im-scim.so (#183636)

* Wed Mar 01 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-8
- add scim-system-default-config.patch
  - add Zenkaku_Hankaku as trigger hotkey for Japanese users
  - use static XIM event flow so deadkeys work under XIM in off state (#169975)
- add alternatives as prereq for %post and %postun (pknirsch, #182853)

* Fri Feb 24 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-6
- fix Punjabi spelling with scim-panjabi-punjabi.patch (aalam)

specspo-10-1
------------
* Thu Mar 02 2006 Bill Nottingham <notting at redhat.com> 10-1
- update

* Thu Jul 03 2003 Paul Gampe <pgampe at redhat.com> 9.0.92
- Update translations

* Tue Feb 25 2003 Paul Gampe <pgampe at redhat.com> 9.0-1
- Update translations

squirrelmail-1.4.6-1.fc5
------------------------
* Wed Mar 01 2006 David Woodhouse <dwmw2 at redhat.com> 1.4.6-1
- Upgrade to 1.4.6 proper for CVE-2006-0377 CVE-2006-0195 CVE-2006-0188
- Script the charset changes instead of using a patch
- Convert the ko_KR files to UTF-8, dropping invalid characters from
  what's theoretically supposed to be EUC-KR in the original.

tcl-8.4.12-4
------------
* Fri Feb 17 2006 David Cantrell <dcantrell at redhat.com> - 8.4.12-4
- Enable threads (#181871)

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 8.4.12-3.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 8.4.12-3.1
- rebuilt for new gcc4.1 snapshot and glibc changes

tomcat5-0:5.5.15-1jpp_4fc
-------------------------
* Wed Mar 01 2006 Rafael Schloming <rafaels at redhat.com> - 0:5.5.15-1jpp_4fc
- Disabled juli logging as a workaround for a number of classpath bugs
- in java.util.logging.*

udev-084-10
-----------
* Thu Mar 02 2006 Harald Hoyer <harald at redhat.com> - 084-10
- fixed cdrom rule

yelp-2.13.6-1
-------------
* Mon Feb 27 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.6-1
- Update to 2.13.6

yum-2.5.3-4
-----------
* Thu Mar 02 2006 Paul Nasrat <pnasrat at redhat.com> - 2.5.3-4
- Cover pkg then group selection in conditional group support (#181858)

* Thu Mar 02 2006 Paul Nasrat <pnasrat at redhat.com> - 2.5.3-3
- Conditional group support (#181858)

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs
	vconfig - 1.9-1.1.ia64 requires libc.so.6
	vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0)






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	vconfig - 1.9-1.1.ppc64 requires libc.so.6
	vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0)
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_4fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From alexl at redhat.com  Fri Mar  3 08:44:39 2006
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 03 Mar 2006 09:44:39 +0100
Subject: gnome trash
In-Reply-To: <1141248525.22829.7.camel@soncomputer>
References: <1141240004.2283.3.camel@soncomputer>
	<1141248525.22829.7.camel@soncomputer>
Message-ID: <1141375480.19573.167.camel@greebo>

On Wed, 2006-03-01 at 16:28 -0500, Louis E Garcia II wrote:
> Seems to occur with user accounts. root is ok.

Very strange. It works for me with user accounts. Can you try making a
new account and try that? Something must be different with the computers
or accounts where it doesn't work.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a maverick pirate firefighter who must take medication to keep him sane. 
She's a vivacious belly-dancing safe cracker from a family of eight older 
brothers. They fight crime! 



From aph at redhat.com  Fri Mar  3 09:58:58 2006
From: aph at redhat.com (Andrew Haley)
Date: Fri, 3 Mar 2006 09:58:58 +0000
Subject: Java - Azureus memory usage
In-Reply-To: <20060302144830.27560e95.zaitcev@redhat.com>
References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com>
	<20060302144830.27560e95.zaitcev@redhat.com>
Message-ID: <17416.4962.941023.377259@zapata.pink>

Pete Zaitcev writes:
 > On Tue, 28 Feb 2006 14:30:35 +0000, "Garry Harthill" <gazzerh at gmail.com> wrote:
 > 
 > > 213mb memory and 50% CPU seems a bit excessive.
 > 
 > > Anyone else seeing this?
 > 
 > Nope, mine is at about 53MB with Fedora torrents. It eats a bit of CPU,
 > but I run a VIA C3. Heck, ssh eats CPU on that wimpy chip.

OH, right.  Thanks for that.  I wonder what causes the difference.

Andrew.



From dwmw2 at infradead.org  Fri Mar  3 13:04:05 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 03 Mar 2006 13:04:05 +0000
Subject: username best practices and other conventions
In-Reply-To: <20060302095541.5b2f48a7@dhcp05.addix.net>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
	<20060302095541.5b2f48a7@dhcp05.addix.net>
Message-ID: <1141391045.3732.231.camel@pmac.infradead.org>

On Thu, 2006-03-02 at 09:55 +0100, Ralf Ertzinger wrote:
> The local part of mail addresses is, and has always been, case sensitive.
> Many mail systems ignore this, though (or can be configured to ignore it).

That's system-dependent. You can be case sensitive or not as you see
fit.

However, many systems out there are not case-preserving; you'll find
that addresses are sometimes converted to all-lowercase or
all-uppercase. So the norm nowadays is to be case-insensitive.

And as Chris correctly points out, it's mandatory to accept 'PoStmAster'
in any combination of upper/lower case.

-- 
dwmw2



From hughsient at gmail.com  Fri Mar  3 13:15:06 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 03 Mar 2006 13:15:06 +0000
Subject: rawhide report: 20060302 changes
In-Reply-To: <200603020817.k228H7AE001227@porkchop.devel.redhat.com>
References: <200603020817.k228H7AE001227@porkchop.devel.redhat.com>
Message-ID: <1141391706.5249.17.camel@localhost.localdomain>

On Thu, 2006-03-02 at 03:17 -0500, Build System wrote:
> dbus-0.61-3
> -----------
> * Fri Feb 24 2006 John (J5) Palmieri <johnp at redhat.com> 0.61-1
> - Upgrade to upstream version 0.61

This breaks gnome-power-manager in rawhide.

It's because with dbus >= 0.61, struct are now "typed" (from dbus-glib's
point of view), and gnome-power-manager needed to be more 'precise' with
PropertyModified signals then before.

The fix is in g-p-m CVS.

Richard.



From igorm5 at vip.hr  Fri Mar  3 14:31:05 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Fri, 03 Mar 2006 15:31:05 +0100
Subject: Gnomebaker, missing dependency - FC5T3
Message-ID: <44085329.4030808@vip.hr>

[root at localhost ~]# yum install gnomebaker
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
development                                                          [1/2]
extras-development                                                   [2/2]
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package gnomebaker.i386 0:0.5.1-2.fc5 set to be updated
--> Running transaction check
--> Processing Dependency: libgstreamer-0.8.so.1 for package: gnomebaker
--> Finished Dependency Resolution
Error: Missing Dependency: libgstreamer-0.8.so.1 is needed by package
gnomebaker

-- 
Igor Jagec



From pp at ee.oulu.fi  Fri Mar  3 15:09:28 2006
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Fri, 3 Mar 2006 17:09:28 +0200
Subject: kernel debuginfo size
Message-ID: <20060303150927.GA10690@ee.oulu.fi>

Err... would it be possible to get some solution for the "Help!
I just want to run oprofile and systemtap" scenario?

-rw-rw-r--    1 ftp      ftp      459625793 Mar 02 09:20 kernel-debuginfo-2.6.15-1.2008_FC5.i686.rpm

is just not fun. Especially when a (uncompressed) 40MB vmlinux is all I
usually want from there.



From fedora at leemhuis.info  Fri Mar  3 15:37:38 2006
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 03 Mar 2006 16:37:38 +0100
Subject: Gnomebaker, missing dependency - FC5T3
In-Reply-To: <44085329.4030808@vip.hr>
References: <44085329.4030808@vip.hr>
Message-ID: <1141400259.2308.22.camel@localhost.localdomain>

Am Freitag, den 03.03.2006, 15:31 +0100 schrieb Igor Jagec:
> [root at localhost ~]# yum install gnomebaker
> Loading "installonlyn" plugin
> Setting up Install Process
> Setting up repositories
> development                                                          [1/2]
> extras-development                                                   [2/2]
> Reading repository metadata in from local files
> Parsing package install arguments
> Resolving Dependencies
> --> Populating transaction set with selected packages. Please wait.
> ---> Package gnomebaker.i386 0:0.5.1-2.fc5 set to be updated
> --> Running transaction check
> --> Processing Dependency: libgstreamer-0.8.so.1 for package: gnomebaker
> --> Finished Dependency Resolution
> Error: Missing Dependency: libgstreamer-0.8.so.1 is needed by package
> gnomebaker

The problem is well known and Fedora Extras is working to fix it before
FC5 is final. Thanks for your patience.

CU
thl

P.S.:gnomebaker is from extras, so fedora-extras-list would be a little
bit better for reporting such issues. But a lot of people hang out on
both lists.
-- 
Thorsten Leemhuis <fedora at leemhuis.info>



From bdpepple at ameritech.net  Fri Mar  3 15:20:37 2006
From: bdpepple at ameritech.net (Brian Pepple)
Date: Fri, 03 Mar 2006 10:20:37 -0500
Subject: Gnomebaker, missing dependency - FC5T3
In-Reply-To: <44085329.4030808@vip.hr>
References: <44085329.4030808@vip.hr>
Message-ID: <1141399237.18367.5.camel@shuttle.273piedmont.org>

On Fri, 2006-03-03 at 15:31 +0100, Igor Jagec wrote:
> [root at localhost ~]# yum install gnomebaker
> Loading "installonlyn" plugin
> Setting up Install Process
> Setting up repositories
> development                                                          [1/2]
> extras-development                                                   [2/2]
> Reading repository metadata in from local files
> Parsing package install arguments
> Resolving Dependencies
> --> Populating transaction set with selected packages. Please wait.
> ---> Package gnomebaker.i386 0:0.5.1-2.fc5 set to be updated
> --> Running transaction check
> --> Processing Dependency: libgstreamer-0.8.so.1 for package: gnomebaker
> --> Finished Dependency Resolution
> Error: Missing Dependency: libgstreamer-0.8.so.1 is needed by package
> gnomebaker

This is a known problem.  gstreamer08 was removed from Core a little
while ago, and until it's imported into FE this dependency isn't
available.

Right now the only thing holding up getting this into FE, is a problem
with rpath for gstreamer08.  You can follow the progress for this, or
better yet help solve it here:

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

/B
-- 
Brian Pepple <bdpepple at ameritech.net>

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

From paul at permanentmail.com  Fri Mar  3 17:04:40 2006
From: paul at permanentmail.com (Paul Dickson)
Date: Fri, 3 Mar 2006 10:04:40 -0700
Subject: Radical Suggestion: Add TiddlyWiki FAQ Page to Fedora Core
Message-ID: <20060303100440.58cc735a.paul@permanentmail.com>

A major problem with wiki FAQs is that the user must be on-line to use
them, which can be a problem if getting on-line is the problem.

Perhaps something like TiddlyWiki (http://www.tiddlywiki.com/) can be
used to get around this problem and help with other general usage of
Fedora Core too.  The only requirement would be to have firefox be part
of the default session setup.

TiddlyWiki runs self contained within it's own web page using Javascript.
No other software is needed.  Only images are kept separately (in separate
files, as usual for web pages).

If something like this was added to FC, post-install help and FAQ's could
be easily found.

	-Paul



From gianluca.cecchi at gmail.com  Fri Mar  3 17:09:07 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Fri, 3 Mar 2006 18:09:07 +0100
Subject: printer addition not dinamically aquired by openoffice
Message-ID: <561c252c0603030909g7dff0263y8fe12ab6b07942a7@mail.gmail.com>

With latest updates, I configured a printer while evolution and
openoffice were both opened.
The printer was configured as jet direct through System -->
Administration --> Printing menu.
After configuring and apply changes, in evolution I dinamically see
the new configured printer inside the printers list, in openoffice it
is not so.
Closing and reopening openoffice solves the problem.



From wart at kobold.org  Fri Mar  3 18:25:49 2006
From: wart at kobold.org (Michael Thomas)
Date: Fri, 03 Mar 2006 10:25:49 -0800
Subject: games user and group
In-Reply-To: <4404EB4A.40304@kobold.org>
References: <4404EB4A.40304@kobold.org>
Message-ID: <44088A2D.2080208@kobold.org>

Michael Thomas wrote:
> I've got a few questions regarding the use of the 'games' user and group
> for game packages.  The resulting recommended practices will be posted
> to the Extras/SIGs/Games wiki page.
> 
> Daemon processes
> ================
> Some games such as wesnoth and xpilot-ng come with server daemons.  I
> see three choices for the owner of these daemon processes:
> 
> 1) root (ick!)
> 2) Allocate a separate '<gamename>' user for each package/daemon
> 3) Piggyback on the 'games' user
> 
> My preference would be #3.  Are there any drawbacks to reusing the
> 'games' user to run various game daemons?
> 
> Scoreboard files
> ================
> Two packages that I recently submitted for review ('rogue' and 'ularn')
> use the 'games' group and a setgid executable so that all users have
> access to the shared scoreboard file.  Are there any security issues
> that we need to be aware of when using setgid games?
> 
> File ownership
> ==============
> Almost every package that I see in FE uses %defattr(-,root,root,-).  Is
> there any reason why we shouldn't be using %defattr(-,games,games,-) for
> game packages (including documentation, manpages and such)?

The concensus from fedora-devel and fedora-extras is this:

* Use a unique user for each game daemon as a minimum.  Layer other 
security tools such as selinux on top of that.

* No comment on the use of setgid 'games' executables for writing to a 
shared scoreboard file.  I'll assume that this is acceptible.

* Files should be owned by root.root, with the exception of the shared 
writable files (scoreboard, etc.).

I'll update this on the Extras/SIGs/Games wiki page at some point today.

Thanks for the feedback,

--Mike



From sundaram at fedoraproject.org  Fri Mar  3 18:38:27 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 04 Mar 2006 00:08:27 +0530
Subject: Radical Suggestion: Add TiddlyWiki FAQ Page to Fedora Core
In-Reply-To: <20060303100440.58cc735a.paul@permanentmail.com>
References: <20060303100440.58cc735a.paul@permanentmail.com>
Message-ID: <44088D23.60704@fedoraproject.org>

Paul Dickson wrote:

>A major problem with wiki FAQs is that the user must be on-line to use
>them, which can be a problem if getting on-line is the problem.
>
>Perhaps something like TiddlyWiki (http://www.tiddlywiki.com/) can be
>used to get around this problem and help with other general usage of
>Fedora Core too.  The only requirement would be to have firefox be part
>of the default session setup.
>
>TiddlyWiki runs self contained within it's own web page using Javascript.
>No other software is needed.  Only images are kept separately (in separate
>files, as usual for web pages).
>
>If something like this was added to FC, post-install help and FAQ's could
>be easily found.
>
>  
>
In the short term there is a plan to start using a CMS system.  Refer to 
http://fedoraproject.org/wiki/Websites/Meetings. We are working on 
including the end user guides and FAQ's as packages within Fedora Core 
and Extras. Not sure migrating to a new wiki system is worth the effort. 
fedora-websites list might be a better place for this discussion 
especially if you want to get involved.

-- 
Rahul 





From jamatos at fc.up.pt  Fri Mar  3 20:10:33 2006
From: jamatos at fc.up.pt (Jose' Matos)
Date: Fri, 3 Mar 2006 20:10:33 +0000
Subject: rawhide report: 20060303 changes
In-Reply-To: <200603030821.k238LVlw002256@porkchop.devel.redhat.com>
References: <200603030821.k238LVlw002256@porkchop.devel.redhat.com>
Message-ID: <200603032010.34087.jamatos@fc.up.pt>

On Friday 03 March 2006 08:21, Build System wrote:
> Removed package up2date
>
> Removed package rhn-applet

 Is not it too soon for this? ;-)

http://fedoraproject.org/wiki/FC6Future

Notice the second goal. :-)

-- 
Jos? Ab?lio



From sundaram at fedoraproject.org  Fri Mar  3 20:17:38 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 04 Mar 2006 01:47:38 +0530
Subject: rawhide report: 20060303 changes
In-Reply-To: <200603032010.34087.jamatos@fc.up.pt>
References: <200603030821.k238LVlw002256@porkchop.devel.redhat.com>
	<200603032010.34087.jamatos@fc.up.pt>
Message-ID: <4408A462.9000101@fedoraproject.org>

Jose' Matos wrote:

>On Friday 03 March 2006 08:21, Build System wrote:
>  
>
>>Removed package up2date
>>
>>Removed package rhn-applet
>>    
>>
>
> Is not it too soon for this? ;-)
>
>  
>
Not really.  I filed the bug report 
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167770) and we had 
some discussion going to get rid of this since all the package 
management tools like Pirut, Pup and the installer is now using Yum and 
I am glad this finally happened.

>http://fedoraproject.org/wiki/FC6Future
>
>Notice the second goal. :-)
>
>  
>
Thats just a list of changes that I dropped into the wiki page to keep 
track of things that I wanted to see happen. Now that the development 
tree drops up2date and rhn-applet, I have closed the bug and removed the 
"goal" from the wiki. Thanks.

-- 
Rahul 





From jkeating at redhat.com  Fri Mar  3 20:18:44 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 03 Mar 2006 12:18:44 -0800
Subject: rawhide report: 20060303 changes
In-Reply-To: <200603032010.34087.jamatos@fc.up.pt>
References: <200603030821.k238LVlw002256@porkchop.devel.redhat.com>
	<200603032010.34087.jamatos@fc.up.pt>
Message-ID: <1141417124.17519.4.camel@ender>

On Fri, 2006-03-03 at 20:10 +0000, Jose' Matos wrote:
> 
>  Is not it too soon for this? ;-)
> 
> http://fedoraproject.org/wiki/FC6Future
> 
> Notice the second goal. :-) 

Must have already been updated, second goal doesn't apply to this.

rhn-applet and up2date are currently providing 0 value to Fedora Core
users.  Why keep them in?  Why indeed.  We removed them.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060303/09331807/attachment.sig>

From jamatos at fc.up.pt  Fri Mar  3 20:36:07 2006
From: jamatos at fc.up.pt (Jose' Matos)
Date: Fri, 3 Mar 2006 20:36:07 +0000
Subject: rawhide report: 20060303 changes
In-Reply-To: <1141417124.17519.4.camel@ender>
References: <200603030821.k238LVlw002256@porkchop.devel.redhat.com>
	<200603032010.34087.jamatos@fc.up.pt>
	<1141417124.17519.4.camel@ender>
Message-ID: <200603032036.07428.jamatos@fc.up.pt>

On Friday 03 March 2006 20:18, Jesse Keating wrote:
> > Notice the second goal. :-)
>
> Must have already been updated, second goal doesn't apply to this.
>
> rhn-applet and up2date are currently providing 0 value to Fedora Core
> users. ?Why keep them in? ?Why indeed. ?We removed them.

  Come on, I can understand that and I agree as well. Nevertheless it is 
always nice to achieve goals ahead of schedule. :-)

  And yes, it was a joke. :-) :-D

> --
> Jesse Keating
> Release Engineer: Fedora

-- 
Jos? Ab?lio



From davej at redhat.com  Fri Mar  3 21:38:53 2006
From: davej at redhat.com (Dave Jones)
Date: Fri, 3 Mar 2006 16:38:53 -0500
Subject: kernel debuginfo size
In-Reply-To: <20060303150927.GA10690@ee.oulu.fi>
References: <20060303150927.GA10690@ee.oulu.fi>
Message-ID: <20060303213853.GA14714@redhat.com>

On Fri, Mar 03, 2006 at 05:09:28PM +0200, Pekka Pietikainen wrote:
 > Err... would it be possible to get some solution for the "Help!
 > I just want to run oprofile and systemtap" scenario?
 > 
 > -rw-rw-r--    1 ftp      ftp      459625793 Mar 02 09:20 kernel-debuginfo-2.6.15-1.2008_FC5.i686.rpm
 > 
 > is just not fun. Especially when a (uncompressed) 40MB vmlinux is all I
 > usually want from there.

It's due to there being 3 different kernel builds in there
(up/smp/kdump)

Tomorrows is bigger again -- readdition of Xen adds another two kernels.

Eventually, I'm hopeful that the kdump image can go away, but we're kinda
stuck with the others right now.

		Dave



From nmiell at comcast.net  Fri Mar  3 21:53:43 2006
From: nmiell at comcast.net (Nicholas Miell)
Date: Fri, 03 Mar 2006 13:53:43 -0800
Subject: kernel debuginfo size
In-Reply-To: <20060303150927.GA10690@ee.oulu.fi>
References: <20060303150927.GA10690@ee.oulu.fi>
Message-ID: <1141422823.2996.6.camel@entropy>

On Fri, 2006-03-03 at 17:09 +0200, Pekka Pietikainen wrote:
> Err... would it be possible to get some solution for the "Help!
> I just want to run oprofile and systemtap" scenario?
> 
> -rw-rw-r--    1 ftp      ftp      459625793 Mar 02 09:20 kernel-debuginfo-2.6.15-1.2008_FC5.i686.rpm
> 
> is just not fun. Especially when a (uncompressed) 40MB vmlinux is all I
> usually want from there.


What the world really needs is a tool that'll remove redundant DWARF
data[1].

Ideally, such a tool could remove redundant data within an object, or
between multiple objects (by specifying that one object -- libc.so.6,
vmlinux -- is the authoritative DWARF source and removing copies from
everything else). Discarding data that isn't actually used would be
good, too, but gcc does that right now and manages to screw it up (re:
enums), so you'd have to be extra careful.


[1] If a.c and b.c both include z.h, a.o and b.o will both have DWARF
info for z.h, and if you link a.o and b.o together, you'll get two
copies of that DWARF data in the resulting object. Now consider that
sched.h is a) big and b) included by most everything in the kernel and
that there are other headers just like it...

-- 
Nicholas Miell <nmiell at comcast.net>



From seg at haxxed.com  Fri Mar  3 22:31:05 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 03 Mar 2006 16:31:05 -0600
Subject: Vino
In-Reply-To: <6f6293f10603021607s1ca409e3gd3e448ee1eebd9f4@mail.gmail.com>
References: <6f6293f10603021607s1ca409e3gd3e448ee1eebd9f4@mail.gmail.com>
Message-ID: <1141425066.2822.4.camel@localhost>

On Fri, 2006-03-03 at 01:07 +0100, Felipe Alfaro Solana wrote:
> Hello,
> 
> I have been playing with VINO on Fedora Core 5 Test 3 but I find it
> pretty unusable. First, screen updates are painfully slow: sometimes
> on the real desktop I launch a gnome-terminal, but it takes up to five
> seconds for the window to appear on the remote VNC client (it appears
> almost instantly on the real desktop). Other times, working on the
> real desktop produces no updates on the remote VNC client.

> Am I the only one experiencing these issues with VINO?

No, I find vino to be unusably slow and buggy as well. I use the vnc X
server extension instead. Which oddly enough, is even faster than using
a dedicated Xvnc server. The VNC extension seems to have broken in test3
however...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060303/8b89afcb/attachment.sig>

From louisg00 at bellsouth.net  Fri Mar  3 22:30:36 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Fri, 03 Mar 2006 17:30:36 -0500
Subject: gnome trash
Message-ID: <1141425036.4530.5.camel@soncomputer>

> > Seems to occur with user accounts. root is ok.
> 
> Very strange. It works for me with user accounts. Can you try making a
> new account and try that? Something must be different with the computers
> or accounts where it doesn't work.
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>                    alexl redhat com    alla lysator liu se 
> He's a maverick pirate firefighter who must take medication to keep him sane. 
> She's a vivacious belly-dancing safe cracker from a family of eight older 
> brothers. They fight crime! 

It's the same with new accounts also. The only thing I can think is /home is
on a separate partition but it shouldn't matter.

--Louis



From louisg00 at bellsouth.net  Fri Mar  3 22:41:39 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Fri, 03 Mar 2006 17:41:39 -0500
Subject: some gnome annoyances
Message-ID: <1141425699.4665.8.camel@soncomputer>

When login on to gnome the home folder is always below trash. Should be
in order from top down: computer, home folder, Trash.

Evolution does.t remember last position of window and always takes up
the whole desktop.

-Thanks



From sundaram at fedoraproject.org  Fri Mar  3 22:42:30 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 04 Mar 2006 04:12:30 +0530
Subject: Vino
In-Reply-To: <1141425066.2822.4.camel@localhost>
References: <6f6293f10603021607s1ca409e3gd3e448ee1eebd9f4@mail.gmail.com>
	<1141425066.2822.4.camel@localhost>
Message-ID: <4408C656.6090301@fedoraproject.org>

Callum Lerwick wrote:

>No, I find vino to be unusably slow and buggy as well. I use the vnc X
>server extension instead. Which oddly enough, is even faster than using
>a dedicated Xvnc server. The VNC extension seems to have broken in test3
>however...
>  
>
Have you filed a bug report on the VNC extension being broken?

-- 
Rahul 





From roland at redhat.com  Fri Mar  3 23:15:02 2006
From: roland at redhat.com (Roland McGrath)
Date: Fri,  3 Mar 2006 15:15:02 -0800 (PST)
Subject: kernel debuginfo size
In-Reply-To: Nicholas Miell's message of  Friday,
	3 March 2006 13:53:43 -0800 <1141422823.2996.6.camel@entropy>
Message-ID: <20060303231502.52DA8180B1E@magilla.sf.frob.com>

In the unspecified distant future we intend to do exactly that.
But there is a lot of work to make it happen.



From paul at permanentmail.com  Fri Mar  3 23:50:54 2006
From: paul at permanentmail.com (Paul Dickson)
Date: Fri, 3 Mar 2006 16:50:54 -0700
Subject: Radical Suggestion: Add TiddlyWiki FAQ Page to Fedora Core
In-Reply-To: <44088D23.60704@fedoraproject.org>
References: <20060303100440.58cc735a.paul@permanentmail.com>
	<44088D23.60704@fedoraproject.org>
Message-ID: <20060303165054.7d1332a6.paul@permanentmail.com>

On Sat, 04 Mar 2006 00:08:27 +0530, Rahul Sundaram wrote:

> Paul Dickson wrote:
> 
> >A major problem with wiki FAQs is that the user must be on-line to use
> >them, which can be a problem if getting on-line is the problem.
> >
> >Perhaps something like TiddlyWiki (http://www.tiddlywiki.com/) can be
> >used to get around this problem and help with other general usage of
> >Fedora Core too.  The only requirement would be to have firefox be part
> >of the default session setup.
> >
> >TiddlyWiki runs self contained within it's own web page using Javascript.
> >No other software is needed.  Only images are kept separately (in separate
> >files, as usual for web pages).
> >
> >If something like this was added to FC, post-install help and FAQ's could
> >be easily found.
> >

> In the short term there is a plan to start using a CMS system.  Refer to 
> http://fedoraproject.org/wiki/Websites/Meetings. We are working on 
> including the end user guides and FAQ's as packages within Fedora Core 
> and Extras. Not sure migrating to a new wiki system is worth the effort. 
> fedora-websites list might be a better place for this discussion 
> especially if you want to get involved.

Well, TiddlyWiki is mostly for local usage.  There is an addition that
adds Zope as the back-end called ZiddlyWiki (http://ziddlywiki.org/).

	-Paul



From felipe.alfaro at gmail.com  Sat Mar  4 00:09:48 2006
From: felipe.alfaro at gmail.com (Felipe Alfaro Solana)
Date: Sat, 4 Mar 2006 01:09:48 +0100
Subject: Vino
In-Reply-To: <1141425066.2822.4.camel@localhost>
References: <6f6293f10603021607s1ca409e3gd3e448ee1eebd9f4@mail.gmail.com>
	<1141425066.2822.4.camel@localhost>
Message-ID: <6f6293f10603031609o28af38dck95a28e1baa214651@mail.gmail.com>

> > Am I the only one experiencing these issues with VINO?
>
> No, I find vino to be unusably slow and buggy as well. I use the vnc X
> server extension instead. Which oddly enough, is even faster than using
> a dedicated Xvnc server. The VNC extension seems to have broken in test3
> however...

Are you sure? I'm using it right now with no apparent problems.



From nmiell at comcast.net  Sat Mar  4 00:09:59 2006
From: nmiell at comcast.net (Nicholas Miell)
Date: Fri, 03 Mar 2006 16:09:59 -0800
Subject: kernel debuginfo size
In-Reply-To: <20060303231502.52DA8180B1E@magilla.sf.frob.com>
References: <20060303231502.52DA8180B1E@magilla.sf.frob.com>
Message-ID: <1141430999.2996.11.camel@entropy>

On Fri, 2006-03-03 at 15:15 -0800, Roland McGrath wrote:
> In the unspecified distant future we intend to do exactly that.
> But there is a lot of work to make it happen.
> 

Nice!

As part of ld, or something else?

-- 
Nicholas Miell <nmiell at comcast.net>



From sundaram at fedoraproject.org  Sat Mar  4 00:56:57 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 04 Mar 2006 06:26:57 +0530
Subject: Wild cry for package documentation
Message-ID: <4408E5D9.1090204@fedoraproject.org>

Hi,


I send out a note to 
https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html 
to document packages in Fedora Extras is a better way when the 
installation or configuration procedures are non obvious and we are 
seeing changes such as the Games Special Interest Group 
(http://fedoraproject.org/wiki/Extras/SIGs/Games) tackling 
http://fedoraproject.org/wiki/Games . I would like to see that happen 
for Fedora Core packages too. Use the fedora wiki whenever you can. We 
can publish them formally in Fedora if required.

http://fedoraproject.org/wiki/DocsProject

On a related note all the RHEL documentation is being relicensed to OPL 
to match the new Fedora documentation licensing requirement and thereby 
pushing in tons of nice documentation available soon for Fedora not to 
mention less duplication of work.

http://www.redhat.com/archives/fedora-docs-list/2006-February/msg00110.html

-- 


-- 
Rahul 





From gianluca.cecchi at gmail.com  Sat Mar  4 07:46:39 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Sat, 4 Mar 2006 08:46:39 +0100
Subject: is system-config-keyboard still necessary?
Message-ID: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>

On my system with system-config-keyboard-1.2.7-1.1
If I run in Gnome the System --> Administration --> Keyboard tool, it
gives absolutely nothing: only an empty window with title "Keyboard" and
inside a keyboard-key icon with the text "select the appropriate
keyboard for the system".
Wouldn't be useful to bind this menu with the gnome-keyboard-properties
 command?
But the last one is inside gnome control-center rpm, so I don't know
impact for kde users.
It could be that System --> Administration --> Keyboard actually tests
for the running DE environment and depending on result it runs the
corresponding program (for gnome, kde, xfce, etc.).



From n0dalus+redhat at gmail.com  Sat Mar  4 07:56:39 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Sat, 4 Mar 2006 18:26:39 +1030
Subject: is system-config-keyboard still necessary?
In-Reply-To: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>
References: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>
Message-ID: <6280325c0603032356v7c23ec7epa799b93c308bfee3@mail.gmail.com>

On 3/4/06, Gianluca Cecchi <gianluca.cecchi at gmail.com> wrote:
> On my system with system-config-keyboard-1.2.7-1.1
> If I run in Gnome the System --> Administration --> Keyboard tool, it
> gives absolutely nothing: only an empty window with title "Keyboard" and
> inside a keyboard-key icon with the text "select the appropriate
> keyboard for the system".
> Wouldn't be useful to bind this menu with the gnome-keyboard-properties
>  command?

I think system-config-keyboard sets the keyboard type on a global
level while gnome-keyboard-properties sets it per user.

n0dalus.



From dragoran at feuerpokemon.de  Sat Mar  4 08:02:56 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Sat, 04 Mar 2006 09:02:56 +0100
Subject: aiglx
In-Reply-To: <4407784A.1080508@paradigma.pt>
References: <4404EF88.4080000@paradigma.pt>	<44062996.7000907@fedoraproject.org>	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>	<44074143.6070905@mharris.ca>
	<4407784A.1080508@paradigma.pt>
Message-ID: <440949B0.1040901@feuerpokemon.de>

Vitor Domingos wrote:

> Mike A. Harris wrote on 03/02/2006 07:02 PM:
>
>> Benjy Grogan wrote:
>>
>>> It would be great if Red Hat and Novell could convene under a big 
>>> tent and agree to work on SELinux for security and Xgl for 
>>> accelereated GL.
>>
>>
>> You don't seem to understand the problem domain very well.  Might
>> be worth educating yourself on exactly what Xgl is, and exactly
>> what accelerated indirect rendering is before formulating grossly
>> ignorant opinions.
>
>
> Maybe this could help:
> http://www.freesoftwaremagazine.com/free_issues/newsletters/accelerated_x/index_p1.html 
>
>
> Regards,

http://osnews.com/comment.php?news_id=13850



From buildsys at redhat.com  Sat Mar  4 08:19:13 2006
From: buildsys at redhat.com (Build System)
Date: Sat, 4 Mar 2006 03:19:13 -0500
Subject: rawhide report: 20060304 changes
Message-ID: <200603040819.k248JDps030282@porkchop.devel.redhat.com>

 

Removed package umb-scheme

Updated Packages:

acpid-1.0.4-2
-------------
* Wed Mar 01 2006 Phil Knirsch <pknirsch at redhat.com> - 1.0.4-2
- Added video.conf file to turn on DPMS when opening the laptop lid. Disabled
  by default.

agg-2.3-4
---------
* Fri Feb 17 2006 Karsten Hopp <karsten at redhat.de> 2.3-4
- add BuildRequires freetype-devel for ft2build.h

alsa-utils-1.0.11-3.rc2
-----------------------
* Mon Feb 20 2006 Martin Stransky <stransky at redhat.com> 1.0.11-3.rc2
- removed autoreconf

anaconda-10.92.16-1
-------------------
* Fri Mar 03 2006 Paul Nasrat <pnasrat at redhat.com> - 10.92.16-1
- Support Everything/globs in ks (pnasrat, clumens, #177621)
- Allow changes if not enough disk space (clumens, #183878)
- Set controlling tty in rescue mode (dcantrel,#182222)
- Sort list of languages (dcantrel)

aspell-12:0.60.3-5
------------------
* Thu Mar 02 2006 Ivana Varekova <varekova at redhat.com> - 12:0.60.3-5
- update aspell man page (bug 183205)

* Tue Feb 21 2006 Ivana Varekova <varekova at redhat.com> - 12:0.60.3-4
- fix multilib file conflict

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 12:0.60.3-3.2
- bump again for double-long bug on ppc(64)

aspell-en-50:6.0-2
------------------
* Fri Mar 03 2006 Ivana Varekova <varekova at redhat.com> - 50:6.0-2
- removed "offencive" (#154352), add "practice" (#62225)

avahi-0.6.8-1
-------------
* Thu Feb 23 2006 Jason Vas Dias <jvdias at redhat.com> - 0.6.8-1
- Upgrade to upstream version 0.6.8
- fix bug 182462: +Requires(post): initscripts, chkconfig, ldconfig

* Fri Feb 17 2006 Jason Vas Dias <jvdias at redhat.com> - 0.6.7-1
- Upgrade to upstream version 0.6.7

* Fri Feb 17 2006 Karsten Hopp <karsten at redhat.de> - 0.6.6-4
- BuildRequires pygtk2

beagle-0.2.1-17
---------------
* Fri Mar 03 2006 Alexander Larsson <alexl at redhat.com> 0.2.1-17
- Change beagle user to uid/gid 58 (registered), because
  nut was already using 57 (unregistred!)

binutils-2.16.91.0.6-3
----------------------
* Fri Mar 03 2006 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.6-3
- support DW_CFA_val_{offset,offset_sf,expression} in readelf/objdump

cairo-1.0.2-5
-------------
* Fri Mar 03 2006 Carl Worth <cworth at redhat.com> - 1.0.2-5
- add patch to chunk Xlib glyph compositing (bug 182416 and
  CVE-20060528)

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 1.0.2-4.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 1.0.2-4.1
- rebuilt for new gcc4.1 snapshot and glibc changes

cman-1.0.5-0.FC5.1
------------------
* Wed Mar 01 2006 Chris Feist <cfeist at redhat.com>
- Rebuilt w/ new upstream sources

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 1.0.4-0.FC5.1.1
- rebuilt for new gcc4.1 snapshot and glibc changes

* Fri Dec 16 2005 Chris Feist <cfeist at redhat.com>
- Rebuilt w/ new upstream sources

dhcp-11:3.0.3-26
----------------
* Thu Mar 02 2006 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-26
- fix bug 181908: enable dhclient to operate on IBM zSeries z/OS linux guests:
  o add -I <dhcp-client-identifier> dhclient command line option
  o add -B "always broadcast" dhclient command line option
  o add 'bootp-broadcast-always;' dhclient.conf statement

* Mon Feb 20 2006 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-24
- Apply upstream fix for bug 176615 / ISC RT#15811

* Tue Feb 14 2006 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-22
- fix bug 181482: resolv.conf not updated on RENEW :
  since dhcp-3.0.1rc12-RHScript.patch: "$new_domain_servers" should have
  been "$new_domain_name_servers" :-(

eog-2.13.92-1
-------------
* Sat Mar 04 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-1
- Update to 2.13.92
- Drop upstreamed patch

firstboot-1.4.6-1
-----------------
* Fri Mar 03 2006 Chris Lumens <clumens at redhat.com> 1.4.6-1
- Revert UI changes that broke s-c-keyboard (#183718).

flex-2.5.4a-37.3
----------------
* Fri Feb 10 2006 Petr Machata <pmachata at redhat.com> - 2.5.4a-37.3
- rebuilt, no changes inside. In hunt for #183098

frysk-0.0.1.2006.02.19.rh2-0.FC5.2
----------------------------------
* Fri Mar 03 2006 Andrew Cagney <cagney at redhat.de> 0.0.1.2006.02.19.rh2-0.FC5.2
- Add Hidden=true to frysk.desktop file; from halfline; with fixes.
- Disable xml check in frysk-gui/.

gdb-6.3.0.0-1.114
-----------------
* Fri Mar 03 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.114
- Bump up release number.

* Fri Mar 03 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.111
- Add support for "S" augmentation for signal stack frames.
- Add support for CFA value expressions and encodings.
- Various improvements to the prelink test.

* Thu Feb 23 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.110
- Bump up release number.

ghostscript-8.15.1-7
--------------------
* Thu Mar 02 2006 Tim Waugh <twaugh at redhat.com> 8.15.1-7
- BuildRequires: gnutls-devel
- Updated KRGB patch for gdevijs.

gimp-2:2.2.10-4
---------------
* Fri Mar 03 2006 Nils Philippsen <nphilipp at redhat.com> - 2:2.2.10-4
- use htmlview as default web browser (#183730, patch by Ben Levenson)
- require hicolor-icon-theme (#182784, #182785)

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 2:2.2.10-2.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 2:2.2.10-2.1
- rebuilt for new gcc4.1 snapshot and glibc changes

gnome-mount-0.4-5
-----------------
* Wed Mar 01 2006 David Zeuthen <davidz at redhat.com> - 0.4-5
- Update for new patch in #183191

* Wed Mar 01 2006 Matthias Clasen <mclasen at redhat.com> - 0.4-4
- Fix a crash without media (#183191)

gnome-power-manager-2.13.93-1
-----------------------------
* Fri Mar 03 2006 Ray Strode <rstrode at redhat.com> - 2.13.93-1
- Update to 2.13.93
- ignore d-bus timeout errors

gnome-terminal-2.13.92-1
------------------------
* Sat Mar 04 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-1
- Update to 2.13.92

gnome-utils-1:2.13.95-1
-----------------------
* Sat Mar 04 2006 Matthias Clasen <mclasen at redhat.com> 2.13.95-1
- Update to gnome-utils-2.13.95

gtk-sharp2-2.8.2-1
------------------
* Fri Mar 03 2006 Christopher Aillon <caillon at redhat.com> - 2.8.2-1
- Update to 2.8.2 to fix an issue with marshalling on x86-64

hal-0.5.7-3
-----------
* Fri Mar 03 2006 John (J5) Palmieri <johnp at redhat.com> - 0.5.7-3
- Fix fstab clearing script to not strip whitespace

* Thu Mar 02 2006 John (J5) Palmieri <johnp at redhat.com> - 0.5.7-2
- clear out fstab of all fstab-sync entries if previous hal < 0.5.7-2

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_83rh
------------------------------------------
* Fri Mar 03 2006 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.4.2.0-40jpp_83rh
- Make javadoc post scriplet pass unconditionally.
- Force symlinks in javadoc post scriptlet.

kernel-2.6.15-1.2009.4.2_FC5
----------------------------
* Thu Mar 02 2006 Stephen Tweedie <sct at redhat.com>
- Rebase to rawhide 1.2009
- Disable xen PAE build again

libgdiplus-1.1.13.4-1
---------------------
* Fri Mar 03 2006 Christopher Aillon <caillon at redhat.com> - 1.1.13.4-1
- Update to 1.1.13.4

libsoup-2.2.91-1
----------------
* Sat Mar 04 2006 Matthias Clasen <mclasen at redhat.com> - 2.2.91-1
- Update to 2.2.91

mono-1.1.13.4-1
---------------
* Fri Mar 03 2006 Christopher Aillon <caillon at redhat.com> - 1.1.13.4-1
- Update to 1.1.13.4
- Add patch so mono doesn't segfault on PPC SMP machines
- Minor spec cleanup

nautilus-cd-burner-2.13.92-2
----------------------------
* Mon Feb 27 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-2
- Add a Req for gnome-mount

openssh-4.3p2-4
---------------
* Thu Mar 02 2006 Tomas Mraz <tmraz at redhat.com> - 4.3p2-4
- allow access if audit is not compiled in kernel (#183243)

pirut-1.0.1-1
-------------
* Fri Mar 03 2006 Jeremy Katz <katzj at redhat.com> - 1.0.1-1
- Ensure we unlock things on exit (#183882)

pm-utils-0.13-1
---------------
* Fri Mar 03 2006 Phil Knirsch <pknirsch at redhat.com> - 0.13-1
- Revert last changes for ATI graphics chips as they seem to cause more
  problems than they solved.

* Wed Mar 01 2006 Phil Knirsch <pknirsch at redhat.com> - 0.12-1
- Use vbetool post instead of vbetool dpms on for ATI cards.

* Tue Feb 28 2006 Jeremy Katz <katzj at redhat.com>
- allow building on all x86 arches (#183175)

screen-4.0.2-12
---------------
* Fri Feb 24 2006 Petr Rockai <prockai at redhat.com> - 4.0.2-12
- detect libutil(s).a even if it is only present in lib64 (#182407)

squirrelmail-1.4.6-3.fc5
------------------------
* Fri Mar 03 2006 Warren Togami <wtogami at redhat.com> 1.4.6-3
- Fix regex in doc mangling (#183943 Michal Jaegermann)

* Fri Mar 03 2006 David Woodhouse <dwmw2 at redhat.com> 1.4.6-2
- Add a %build section, move the file mangling to it.
  (#162852 Nicolas Mailhot)

sysreport-1.4.3-3
-----------------
* Fri Mar 03 2006 Than Ngo <than at redhat.com> 1.4.3-3
- add dmidecode option
- write outputs in home instead tmp

system-config-display-1.0.36-3
------------------------------
* Fri Mar 03 2006 Martin Stransky <stransky at redhat.com> 1.0.36-3
- added pam fix (#170625)
- fix prereq (#182861, #182862)

vconfig-1.9-2
-------------
* Fri Feb 17 2006 Phil Knirsch <pknirsch at redhat.com> - 1.9-2
- Fix build problems and cleaned up files in archive properly

vnc-4.1.1-36
------------
* Tue Feb 28 2006 Jitka Kudrnacova <jkudrnac at redhat.com> 4.1.1-36
- with default cofiguration, /etc/init.d/vncserver start will say 
  "no displays configured" (bug #182161)

wpa_supplicant-1:0.4.8-4
------------------------
* Fri Mar 03 2006 Dan Williams <dcbw at redhat.com> - 0.4.8-4
- Add additional BuildRequires #rh181914#
- Add prereq on chkconfig #rh182905# #rh182906#
- Own /var/run/wpa_supplicant and /etc/wpa_supplicant #rh183696#

xen-3.0.1-0.20060301.fc5.3
--------------------------
* Thu Mar 02 2006 Stephen Tweedie <sct at redhat.com> - 3.0.1-0.20060301.fc5.3
- Remove unneeded CFLAGS spec file hack

* Thu Mar 02 2006 Rik van Riel <riel at redhat.com> - 3.0.1-0.20060301.fc5.2
- fix 64 bit CFLAGS issue with vmxloader and hvmloader

* Wed Mar 01 2006 Stephen Tweedie <sct at redhat.com> - 3.0.1-0.20060301.fc5.1
- Update to xen-unstable cset 9022

xorg-x11-xbitmaps-1.0.1-3
-------------------------
* Thu Mar 02 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
- Made package arch specific due to pkgconfig files being placed in lib64
  if the noarch packages manage to get built on x86_64/ppc64/s390x.

yum-2.5.3-5
-----------
* Fri Mar 03 2006 Paul Nasrat <pnasrat at redhat.com> - 2.5.3-5
- Add support for patterns in YumBase.install()

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	gnome-volume-manager - 1.5.13-3.ia64 requires kernel >= 0:2.6
	pcmciautils - 011-1.2.ia64 requires kernel >= 0:2.6.12-1.1411_FC5
	rgmanager - 1.9.31-3.ia64 requires ccs
	systemtap - 0.5.4-2.2.ia64 requires kernel >= 0:2.6.9-11






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_4fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From rc040203 at freenet.de  Sat Mar  4 08:39:38 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 04 Mar 2006 09:39:38 +0100
Subject: rawhide report: 20060304 changes
In-Reply-To: <200603040819.k248JDps030282@porkchop.devel.redhat.com>
References: <200603040819.k248JDps030282@porkchop.devel.redhat.com>
Message-ID: <1141461578.5203.49.camel@mccallum.corsepiu.local>

On Sat, 2006-03-04 at 03:19 -0500, Build System wrote:

> xorg-x11-xbitmaps-1.0.1-3
> -------------------------
> * Thu Mar 02 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
> - Made package arch specific due to pkgconfig files being placed in lib64
>   if the noarch packages manage to get built on x86_64/ppc64/s390x.

What?

Fix the toplevel Makefile.am to install the pkgconfig file to $datadir
instead of libdir:

-pkgconfigdir = $(libdir)/pkgconfig
+pkgconfigdir = $(datadir)/pkgconfig

That's what other noarch packages do.


Alternatively, fix your spec to use

%configure --libdir=%_datadir
...
%_datadir/share/pkgconfig/*.pc



Ralf




From mharris at mharris.ca  Sat Mar  4 09:20:27 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Sat, 04 Mar 2006 04:20:27 -0500
Subject: rawhide report: 20060304 changes
In-Reply-To: <1141461578.5203.49.camel@mccallum.corsepiu.local>
References: <200603040819.k248JDps030282@porkchop.devel.redhat.com>
	<1141461578.5203.49.camel@mccallum.corsepiu.local>
Message-ID: <44095BDB.6030700@mharris.ca>

Ralf Corsepius wrote:
> On Sat, 2006-03-04 at 03:19 -0500, Build System wrote:
> 
> 
>>xorg-x11-xbitmaps-1.0.1-3
>>-------------------------
>>* Thu Mar 02 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
>>- Made package arch specific due to pkgconfig files being placed in lib64
>>  if the noarch packages manage to get built on x86_64/ppc64/s390x.
> 
> 
> What?
> 
> Fix the toplevel Makefile.am to install the pkgconfig file to $datadir
> instead of libdir:
> 
> -pkgconfigdir = $(libdir)/pkgconfig
> +pkgconfigdir = $(datadir)/pkgconfig
> 
> That's what other noarch packages do.
> 
> 
> Alternatively, fix your spec to use
> 
> %configure --libdir=%_datadir
> ...
> %_datadir/share/pkgconfig/*.pc

For now, the important thing is that FC5 is in a state that everything
builds, and is ready for final release.  Minor trivia like this is not
mission critical to the release of the OS.

Feel free to submit a patch to X.Org to do this, so it is fixed in
the future.


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mharris at mharris.ca  Sat Mar  4 11:20:37 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Sat, 04 Mar 2006 06:20:37 -0500
Subject: aiglx
In-Reply-To: <440949B0.1040901@feuerpokemon.de>
References: <4404EF88.4080000@paradigma.pt>
	<44062996.7000907@fedoraproject.org>
	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
	<44074143.6070905@mharris.ca> <4407784A.1080508@paradigma.pt>
	<440949B0.1040901@feuerpokemon.de>
Message-ID: <44097805.4030902@mharris.ca>

dragoran wrote:
> Vitor Domingos wrote:
> 
>> Mike A. Harris wrote on 03/02/2006 07:02 PM:
>>
>>> Benjy Grogan wrote:
>>>
>>>> It would be great if Red Hat and Novell could convene under a big 
>>>> tent and agree to work on SELinux for security and Xgl for 
>>>> accelereated GL.
>>>
>>>
>>>
>>> You don't seem to understand the problem domain very well.  Might
>>> be worth educating yourself on exactly what Xgl is, and exactly
>>> what accelerated indirect rendering is before formulating grossly
>>> ignorant opinions.
>>
>>
>>
>> Maybe this could help:
>> http://www.freesoftwaremagazine.com/free_issues/newsletters/accelerated_x/index_p1.html 
>>
>>
>> Regards,
> 
> 
> http://osnews.com/comment.php?news_id=13850

Indeed.  In particular the last comment on the page says it all:


 >RE: web sites prefer flame wars
 > By FooBarWidget (1.71) on 2006-03-02 19:50:32 UTC in reply to "web 
 >sites prefer flame wars"
 >Exactly, I agree. OSNews and Slashdot are actively provoking the 
 >community. Recently Gnomedesktop.org published an article which 
 >explains X's background and how AIGLX and XGL actually share a lot of 
 >code with each other, and neither Slashdot nor OSnews publish the 
 >article. The community receives too much bad news, which makes people 
 >flame at Linux and OSS all the time.


How much banner ad revenue would Slashdot or any of the other
equally horrible news sites make if they published the truth, or
published honest and fair journalism?  Their revenue would plummet!

If people read that the developers at Red Hat, Novell, and other
companies actually work together and collaborate on things, and
contribute to a common pool upstream, and that the work being done
by one company is benefiting the work done by the other company,
it all sounds way to happy and friendly.  Nobody wants to read
true things like that!

People want to hear about negative things.  People want there to be
wars, fights, intense tooth and nail competition.  If those things
don't exist, they want people to make up bullshit stories and post
it as news.  That way they have something to argue/debate nonsense
with during their lunch breaks with other drones around the world.

People - negative articles, true or not - SELL!  Happy stories do
not sell.  They're boring and make people go to sleep.  Controversy
is King.

Sorry to disappoint everyone that the negativity and other nonsense
surrounding the articles doesn't hold much water in reality.

Just say no to Slashdot today.  (And all the other garbage sites
out there).



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From emeric.maschino at jouy.inra.fr  Sat Mar  4 11:23:45 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Sat,  4 Mar 2006 12:23:45 +0100
Subject: some gnome annoyances
In-Reply-To: <1141425699.4665.8.camel@soncomputer>
References: <1141425699.4665.8.camel@soncomputer>
Message-ID: <1141471425.440978c1abaed@www.jouy.inra.fr>

> When login on to gnome the home folder is always below trash. Should be
> in order from top down: computer, home folder, Trash.

Absolutely. Same situation here. Furthermore, the countdown when logging out a
session or rebooting the system aren't working for me.



From frank at scirocco-5v-turbo.de  Sat Mar  4 12:14:06 2006
From: frank at scirocco-5v-turbo.de (Frank Arnold)
Date: Sat, 04 Mar 2006 13:14:06 +0100
Subject: some gnome annoyances
In-Reply-To: <1141471425.440978c1abaed@www.jouy.inra.fr>
References: <1141425699.4665.8.camel@soncomputer>
	<1141471425.440978c1abaed@www.jouy.inra.fr>
Message-ID: <1141474446.25906.104.camel@localhost>

Am Samstag, den 04.03.2006, 12:23 +0100 schrieb ?meric Maschino:
> Absolutely. Same situation here. Furthermore, the countdown when logging out a
> session or rebooting the system aren't working for me.

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

Regards,
Frank



From caillon at redhat.com  Sat Mar  4 15:20:29 2006
From: caillon at redhat.com (Christopher Aillon)
Date: Sat, 04 Mar 2006 10:20:29 -0500
Subject: rawhide report: 20060304 changes
In-Reply-To: <44095BDB.6030700@mharris.ca>
References: <200603040819.k248JDps030282@porkchop.devel.redhat.com>	<1141461578.5203.49.camel@mccallum.corsepiu.local>
	<44095BDB.6030700@mharris.ca>
Message-ID: <4409B03D.2060507@redhat.com>

On 03/04/2006 04:20 AM, Mike A. Harris wrote:
> Ralf Corsepius wrote:
>> On Sat, 2006-03-04 at 03:19 -0500, Build System wrote:
>>
>>
>>> xorg-x11-xbitmaps-1.0.1-3
>>> -------------------------
>>> * Thu Mar 02 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
>>> - Made package arch specific due to pkgconfig files being placed in 
>>> lib64
>>>  if the noarch packages manage to get built on x86_64/ppc64/s390x.
>>
>>
>> What?
>>
>> Fix the toplevel Makefile.am to install the pkgconfig file to $datadir
>> instead of libdir:
>>
>> -pkgconfigdir = $(libdir)/pkgconfig
>> +pkgconfigdir = $(datadir)/pkgconfig
>>
>> That's what other noarch packages do.
>>
>>
>> Alternatively, fix your spec to use
>>
>> %configure --libdir=%_datadir
>> ...
>> %_datadir/share/pkgconfig/*.pc
> 
> For now, the important thing is that FC5 is in a state that everything
> builds, and is ready for final release.  Minor trivia like this is not
> mission critical to the release of the OS.
> 
> Feel free to submit a patch to X.Org to do this, so it is fixed in
> the future.
> 
> 

Actually, it's more important that things are in a state where upgrading 
works sanely.  Changing from noarch -> arch-specific -> noarch typically 
breaks upgrading.



From cmadams at hiwaay.net  Sat Mar  4 15:29:18 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 4 Mar 2006 09:29:18 -0600
Subject: Wild cry for package documentation
In-Reply-To: <4408E5D9.1090204@fedoraproject.org>
References: <4408E5D9.1090204@fedoraproject.org>
Message-ID: <20060304152918.GA757294@hiwaay.net>

Once upon a time, Rahul Sundaram <sundaram at fedoraproject.org> said:
> On a related note all the RHEL documentation is being relicensed to OPL 
> to match the new Fedora documentation licensing requirement and thereby 
> pushing in tons of nice documentation available soon for Fedora not to 
> mention less duplication of work.

Please pass on a big thanks to the Red Hat folks responsible for this.
Documentation is not glorious work (people only really notice when it
isn't there), but Red Hat has done a good job.
-- 
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 seandarcy2 at gmail.com  Sat Mar  4 17:20:26 2006
From: seandarcy2 at gmail.com (sean)
Date: Sat, 04 Mar 2006 12:20:26 -0500
Subject: other annoyances before fc5
Message-ID: <duci8r$9si$1@sea.gmane.org>

As fc5 is fast approaching, here are my two minor annoyances:

1. kernel messages about my dvd if there's a disk ( 
unmounted) in it. /var/log/messages is filled with:

hdc: media error (bad sector): status=0x51 { DriveReady 
SeekComplete Error }
hdc: media error (bad sector): error=0x30 { 
LastFailedSense=0x03 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 64
Buffer I/O error on device hdc, logical block 8

I can read and burn dvd's just fine, so there's does not 
appear to be any problem, just spurious error messages.

2. With the new xkeyboard, a dialog comes up each time X is 
started, asking if you want the X or gnome setting. There's 
also a checkbox to not show the dialog again. But it's not 
clear if you select the checkbox if your choice is 
persistent.  Also it's not clear that gnome is recommended. 
Is this only an issue on an upgrade, but not a new install??

FWIW, these are small potatoes in all the great work that's 
been done in a small amount of time on fc5.

sean



From jbarnes at virtuousgeek.org  Sat Mar  4 17:29:21 2006
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Sat, 4 Mar 2006 09:29:21 -0800
Subject: other annoyances before fc5
In-Reply-To: <duci8r$9si$1@sea.gmane.org>
References: <duci8r$9si$1@sea.gmane.org>
Message-ID: <200603040929.22397.jbarnes@virtuousgeek.org>

On Saturday, March 04, 2006 9:20 am, sean wrote:
> As fc5 is fast approaching, here are my two minor annoyances:
>
> 1. kernel messages about my dvd if there's a disk (
> unmounted) in it. /var/log/messages is filled with:
>
> hdc: media error (bad sector): status=0x51 { DriveReady
> SeekComplete Error }
> hdc: media error (bad sector): error=0x30 {
> LastFailedSense=0x03 }
> ide: failed opcode was: unknown
> end_request: I/O error, dev hdc, sector 64
> Buffer I/O error on device hdc, logical block 8
>
> I can read and burn dvd's just fine, so there's does not
> appear to be any problem, just spurious error messages.

I see these messages too, on my PowerBook.  I've been meaning to file a 
bug about it but keep forgetting.  Is it already being tracked?

The other issue on my PowerBook is that the Fedora wireless scripts 
don't seem to work with the bcm43xx driver.  I need to up the interface 
before I set its essid.  I've been meaning to look into it but haven't 
found time yet.

Jesse



From saddateh at gmail.com  Sat Mar  4 17:37:53 2006
From: saddateh at gmail.com (Sadda Teh)
Date: Sat, 4 Mar 2006 12:37:53 -0500
Subject: Xair for x86_64
Message-ID: <fc33c1550603040937v6bf32fa0ke1eed9f811e504e5@mail.gmail.com>

Any word on when the 64-bit bugs in Xair will be fixed? I have an old Voodoo
3 card (the only card I have that I could get DRI to work on with open
source drivers) that I'm dying to test with aiglx and my Athlon 64 box.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060304/f1e1cd74/attachment.htm>

From frank at scirocco-5v-turbo.de  Sat Mar  4 17:58:39 2006
From: frank at scirocco-5v-turbo.de (Frank Arnold)
Date: Sat, 04 Mar 2006 18:58:39 +0100
Subject: other annoyances before fc5
In-Reply-To: <200603040929.22397.jbarnes@virtuousgeek.org>
References: <duci8r$9si$1@sea.gmane.org>
	<200603040929.22397.jbarnes@virtuousgeek.org>
Message-ID: <1141495119.25906.112.camel@localhost>

Am Samstag, den 04.03.2006, 09:29 -0800 schrieb Jesse Barnes:
> I see these messages too, on my PowerBook.  I've been meaning to file a 
> bug about it but keep forgetting.  Is it already being tracked?

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

Regards,
Your bugzilla search interface



From jbarnes at virtuousgeek.org  Sat Mar  4 18:05:37 2006
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Sat, 4 Mar 2006 10:05:37 -0800
Subject: other annoyances before fc5
In-Reply-To: <1141495119.25906.112.camel@localhost>
References: <duci8r$9si$1@sea.gmane.org>
	<200603040929.22397.jbarnes@virtuousgeek.org>
	<1141495119.25906.112.camel@localhost>
Message-ID: <200603041005.37709.jbarnes@virtuousgeek.org>

On Saturday, March 04, 2006 9:58 am, Frank Arnold wrote:
> Am Samstag, den 04.03.2006, 09:29 -0800 schrieb Jesse Barnes:
> > I see these messages too, on my PowerBook.  I've been meaning to
> > file a bug about it but keep forgetting.  Is it already being
> > tracked?
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156709

Thanks (I absolutely detest bugzilla, searching bugzilla even moreso, if 
that's possible), looks like it hasn't been resolved yet...

Jesse



From jfrieben at freesurf.fr  Sat Mar  4 18:40:33 2006
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sat, 4 Mar 2006 19:40:33 +0100 (CET)
Subject: other annoyances before fc5
In-Reply-To: <duci8r$9si$1@sea.gmane.org>
References: <duci8r$9si$1@sea.gmane.org>
Message-ID: <43228.194.94.224.254.1141497633.squirrel@jose.freesurf.fr>

E.g. after removing you (GNOME) dot directories, the keyboard
settings will be regenerated correctly, and the dialog will be
gone.

>
> 2. With the new xkeyboard, a dialog comes up each time X is
> started, asking if you want the X or gnome setting. There's
> also a checkbox to not show the dialog again. But it's not
> clear if you select the checkbox if your choice is
> persistent.  Also it's not clear that gnome is recommended.
> Is this only an issue on an upgrade, but not a new install??
>




From chris at tylers.info  Sat Mar  4 19:14:58 2006
From: chris at tylers.info (Chris Tyler)
Date: Sat, 04 Mar 2006 14:14:58 -0500
Subject: bind-chroot obsolete due to SElinux?
Message-ID: <1141499698.3522.10.camel@concord2.proximity.on.ca>


I noticed that the bind-chroot package is no longer installed by default
(FC5t3 & rawhide), even through it's still present. Should we consider
bind-chroot obsolete, since SElinux should be able to provide similar
protection (preventing named from touching files it should not, even if
compromised)?

--
Chris Tyler



From jvdias at redhat.com  Sat Mar  4 19:18:01 2006
From: jvdias at redhat.com (Jason Vas Dias)
Date: Sat, 4 Mar 2006 14:18:01 -0500
Subject: bind-chroot obsolete due to SElinux?
In-Reply-To: <1141499698.3522.10.camel@concord2.proximity.on.ca>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
Message-ID: <200603041418.01375.jvdias@redhat.com>

On Saturday 04 March 2006 14:14, Chris Tyler <chris at tylers.info> wrote:
>  
>  I noticed that the bind-chroot package is no longer installed by default
>  (FC5t3 & rawhide), even through it's still present. Should we consider
>  bind-chroot obsolete, since SElinux should be able to provide similar
>  protection (preventing named from touching files it should not, even if
>  compromised)?
>  
>  --
>  Chris Tyler
>  
Yes

There's no protection provided by bind-chroot that is not provided by running
named with SELinux in Enforcing mode.

Regards,
Jason Vas Dias,
BIND package maintainer 



From ivg2 at cornell.edu  Sat Mar  4 19:49:20 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Sat, 04 Mar 2006 14:49:20 -0500
Subject: bind-chroot obsolete due to SElinux?
In-Reply-To: <200603041418.01375.jvdias@redhat.com>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<200603041418.01375.jvdias@redhat.com>
Message-ID: <4409EF40.2010808@cornell.edu>


> Yes
>
> There's no protection provided by bind-chroot that is not provided by running
> named with SELinux in Enforcing mode.
>   
I have my doubts about that.

A chroot jail allows you to easily see what bind can and cannot do.
SElinux requires analysis of policy to accomplish the same thing.
It likely does have a lot more privileges than when jailed.

For example,
files_read_etc_files(named_t) allows named to read all files marked 
etc_t. Those are usually configuration files, shouldn't be any secrets 
there.... What if it turns out there is a secret file mislabeled by 
mistake? Why is named interested in configuration of other programs anyway?

I also see named can interact with NetworkManager, mount(??), dbus 
domain over sockets and pipes.
Is this possible in a chroot jail?

To be sure the application does exactly what it should, it's necessary to:
1) look at the generated policy, and search for dangerous domain 
interactions.
2) ensure labeling is working properly

I would advise people working on bind-chroot to audit the selinux policy 
and make sure it does what it should, before assuming it provides the 
same level of confinement as a chroot jail. SElinux does aim for minimum 
privilege - but to what degree it accomplishes that is highly variable 
depending on which policy you're looking at. That's probably why SELinux 
runs after DAC, and not by itself.



From jvdias at redhat.com  Sat Mar  4 20:14:39 2006
From: jvdias at redhat.com (Jason Vas Dias)
Date: Sat, 4 Mar 2006 15:14:39 -0500
Subject: bind-chroot obsolete due to SElinux?
In-Reply-To: <4409EF40.2010808@cornell.edu>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<200603041418.01375.jvdias@redhat.com>
	<4409EF40.2010808@cornell.edu>
Message-ID: <200603041514.39648.jvdias@redhat.com>

On Saturday 04 March 2006 14:49, Ivan Gyurdiev <ivg2 at cornell.edu> wrote:
>  
>  > Yes
>  >
>  > There's no protection provided by bind-chroot that is not provided by running
>  > named with SELinux in Enforcing mode.
>  >   
>  I have my doubts about that.
>  
>  A chroot jail allows you to easily see what bind can and cannot do.
>  SElinux requires analysis of policy to accomplish the same thing.
Not so - any infractions by named are clearly logged, which would not
be the case if running in bind-chroot with SELinux disabled.
>  It likely does have a lot more privileges than when jailed.
>  
Not so - except in the etc_t case you mention.
>  For example,
>  files_read_etc_files(named_t) allows named to read all files marked 
>  etc_t. Those are usually configuration files, shouldn't be any secrets 
>  there.... What if it turns out there is a secret file mislabeled by 
>  mistake? Why is named interested in configuration of other programs anyway?
>
This is because named.conf can 'include "...";' other files, which are in $ROOTDIR/etc
and not labelled as named_conf_t by default - unless in the chroot, where 
/var/named/chroot/etc/* is labelled as named_conf_t. I think probably this should be
changed to label  /etc/named.* or /etc/bind/* as named_conf_t and disallow named etc_t 
read privilege. But this is mitigated by the fact that named runs as the 'named:named' user, 
and most /etc/* files should be -rw------- .
  
>  I also see named can interact with NetworkManager, mount(??), dbus 
>  domain over sockets and pipes.
>  Is this possible in a chroot jail?
>  
Yes - named by default is given the '-D' command line option to enable dbus
support for dynamic forwarder table management, which NetworkManager uses.
That means the init script needs to mount /var/run/dbus in the chroot.
This is easily disabled by removing the -D option from the /etc/sysconfig/named
'OPTIONS=-D' setting. 
Also, the named initscript still needs to mount /proc under the chroot to determine
the correct number of CPUs, and in order to respond to changes in the interface list.

named does not need to have mount privileges - only the initscript needs them.

>  To be sure the application does exactly what it should, it's necessary to:
>  1) look at the generated policy, and search for dangerous domain 
>  interactions.
>  2) ensure labeling is working properly
>  
>  I would advise people working on bind-chroot to audit the selinux policy 
>  and make sure it does what it should, before assuming it provides the 
>  same level of confinement as a chroot jail. SElinux does aim for minimum 
>  privilege - but to what degree it accomplishes that is highly variable 
>  depending on which policy you're looking at. That's probably why SELinux 
>  runs after DAC, and not by itself.
>  
The bind-chroot environment exists primarily to prevent named modifying 
files it should not be able to, if taken over or compromised. 

This is also accomplished sufficiently well by the SELinux policy.

Also ExecShield, -z noexecstack, and read-only relocation segments are
enabled for the named executable, making it extremely difficult if not
impossible to take over a running named process.

So I think SELinux protection is enough for named .

Regards,
Jason Vas Dias.



From denis at poolshark.org  Sat Mar  4 21:07:15 2006
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 04 Mar 2006 13:07:15 -0800
Subject: Kernel hangup fixed with last update
Message-ID: <440A0183.8030802@poolshark.org>

Great, i'm no longer having the kernel hang on boot withe the 2009.4.2
update (was reported here:
https://www.redhat.com/archives/fedora-devel-list/2006-February/msg01375.html

-denis



From paul at city-fan.org  Sat Mar  4 21:13:34 2006
From: paul at city-fan.org (Paul Howarth)
Date: Sat, 04 Mar 2006 21:13:34 +0000
Subject: bind-chroot obsolete due to SElinux?
In-Reply-To: <200603041514.39648.jvdias@redhat.com>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<200603041418.01375.jvdias@redhat.com> <4409EF40.2010808@cornell.edu>
	<200603041514.39648.jvdias@redhat.com>
Message-ID: <1141506814.27650.20.camel@laurel.intra.city-fan.org>

On Sat, 2006-03-04 at 15:14 -0500, Jason Vas Dias wrote:
> On Saturday 04 March 2006 14:49, Ivan Gyurdiev <ivg2 at cornell.edu> wrote:
> >  
> >  > Yes
> >  >
> >  > There's no protection provided by bind-chroot that is not provided by running
> >  > named with SELinux in Enforcing mode.
> >  >   
> >  I have my doubts about that.
> >  
> >  A chroot jail allows you to easily see what bind can and cannot do.
> >  SElinux requires analysis of policy to accomplish the same thing.
> Not so - any infractions by named are clearly logged, which would not
> be the case if running in bind-chroot with SELinux disabled.

Those of us brought up around having layers of security will no doubt
continue to use both SELinux and chroot.

However, I think deprecating chroot in favour of SELinux at this time is
a bit premature. There are large numbers of users that habitually turn
off SELinux at the first hint of problems because they just can't get
their heads around it to fix issues they have with it. Setting up bind
in a chroot is relatively straightforward and people can follow recipes
they find on advice sites. Getting a system working happily with SELinux
(particularly for those people that like to put files in unusual places)
is a much bigger task for them to accomplish and many give up easily.

Paul.



From seandarcy2 at gmail.com  Sat Mar  4 21:15:58 2006
From: seandarcy2 at gmail.com (sean)
Date: Sat, 04 Mar 2006 16:15:58 -0500
Subject: other annoyances before fc5
In-Reply-To: <43228.194.94.224.254.1141497633.squirrel@jose.freesurf.fr>
References: <duci8r$9si$1@sea.gmane.org>
	<43228.194.94.224.254.1141497633.squirrel@jose.freesurf.fr>
Message-ID: <dud02e$j2v$1@sea.gmane.org>

Joachim Frieben wrote:
> E.g. after removing you (GNOME) dot directories, the keyboard
> settings will be regenerated correctly, and the dialog will be
> gone.
> 
> 
>>2. With the new xkeyboard, a dialog comes up each time X is
>>started, asking if you want the X or gnome setting. There's
>>also a checkbox to not show the dialog again. But it's not
>>clear if you select the checkbox if your choice is
>>persistent.  Also it's not clear that gnome is recommended.
>>Is this only an issue on an upgrade, but not a new install??
>>

I'm not sure what my gnome dot dircectories are, but I 
assume this means the dialog won't appear with new installs 
( which is good, because we won't have everybody in the 
office stop work as they debate it).

In any event, my modest suggestion is that the dialog take 
care of ( or ask if it should take care of ) removing 
whatever directories it should.

sean




From overholt at redhat.com  Sat Mar  4 21:26:36 2006
From: overholt at redhat.com (Andrew Overholt)
Date: Sat, 4 Mar 2006 16:26:36 -0500
Subject: rawhide report: 20060304 changes
In-Reply-To: <4409B03D.2060507@redhat.com>
References: <200603040819.k248JDps030282@porkchop.devel.redhat.com>
	<1141461578.5203.49.camel@mccallum.corsepiu.local>
	<44095BDB.6030700@mharris.ca> <4409B03D.2060507@redhat.com>
Message-ID: <20060304212636.GA2213@redhat.com>

* Christopher Aillon <caillon at redhat.com> [2006-03-04 10:20]:
> 
> Changing from noarch -> arch-specific -> noarch typically breaks
> upgrading.

FWIW, I'm pretty sure these issues have all been dealt with during the move
from java bytecode to bytecode + native .sos.  Tom Fitzsimmons would have
more details but if issues persist, it'd be good to get them cleared up.

Andrew



From vd at paradigma.pt  Sat Mar  4 21:09:18 2006
From: vd at paradigma.pt (Vitor Domingos)
Date: Sat, 4 Mar 2006 21:09:18 +0000
Subject: other annoyances before fc5
In-Reply-To: <duci8r$9si$1@sea.gmane.org>
References: <duci8r$9si$1@sea.gmane.org>
Message-ID: <510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>

Btw, what's the status for suspend/hibernate on FC5, specially on ATI Radeon cards ?
I'm on rawhide (with tuesday updates) and it still doesnt resumes Xorg properlly.

//VD

On Sat, 04 Mar 2006 12:20:26 -0500, sean <seandarcy2 at gmail.com> wrote:
> As fc5 is fast approaching, here are my two minor annoyances:
> 
> 1. kernel messages about my dvd if there's a disk (
> unmounted) in it. /var/log/messages is filled with:
> 
> hdc: media error (bad sector): status=0x51 { DriveReady
> SeekComplete Error }
> hdc: media error (bad sector): error=0x30 {
> LastFailedSense=0x03 }
> ide: failed opcode was: unknown
> end_request: I/O error, dev hdc, sector 64
> Buffer I/O error on device hdc, logical block 8
> 
> I can read and burn dvd's just fine, so there's does not
> appear to be any problem, just spurious error messages.
> 
> 2. With the new xkeyboard, a dialog comes up each time X is
> started, asking if you want the X or gnome setting. There's
> also a checkbox to not show the dialog again. But it's not
> clear if you select the checkbox if your choice is
> persistent.  Also it's not clear that gnome is recommended.
> Is this only an issue on an upgrade, but not a new install??
> 
> FWIW, these are small potatoes in all the great work that's
> been done in a small amount of time on fc5.
> 
> sean
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
//VD



From jkeating at redhat.com  Sat Mar  4 22:13:18 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 04 Mar 2006 14:13:18 -0800
Subject: other annoyances before fc5
In-Reply-To: <510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
Message-ID: <1141510398.2730.1.camel@ender>

On Sat, 2006-03-04 at 21:09 +0000, Vitor Domingos wrote:
> Btw, what's the status for suspend/hibernate on FC5, specially on ATI Radeon cards ?
> I'm on rawhide (with tuesday updates) and it still doesnt resumes Xorg properlly. 

My T42 laptop works great with its radeon mobility chip.

Two things:  I have acpi_serialize as a kernel arg in grub, and I have
radeonfb uncommented in /etc/modprobe.d/blacklist.  Also I have options
radeonfb radeon_force_sleep=1 in /etc/modprob.conf.  Suspend and
hibernate work great.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060304/eefe9de3/attachment.sig>

From selinux at gmail.com  Sat Mar  4 22:37:17 2006
From: selinux at gmail.com (Tom London)
Date: Sat, 4 Mar 2006 14:37:17 -0800
Subject: other annoyances before fc5
In-Reply-To: <1141510398.2730.1.camel@ender>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
Message-ID: <4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>

No longer works for me: Thinkpad X41 (Intel 915 graphics).

I tried booting with acpi_serialize, but no joy.

I do see this in /var/log/messages, believe it is when it is trying to wakeup.

Mar  4 14:24:48 localhost kernel: Debug: sleeping function called from
invalid context at include/asm/semaphore.h:99
Mar  4 14:24:48 localhost kernel: in_atomic():0, irqs_disabled():1
Mar  4 14:24:48 localhost kernel:  [<c01e1af5>]
acpi_os_wait_semaphore+0x61/0xb9     [<c01f69b1>]
acpi_ut_acquire_mutex+0x2f/0x65
Mar  4 14:24:48 localhost kernel:  [<c01eef8c>]
acpi_ns_evaluate_relative+0x4e/0xca     [<c01f2a57>]
acpi_rs_set_srs_method_data+0x93/0xb7
Mar  4 14:24:48 localhost kernel:  [<c01f0042>]
acpi_get_next_object+0x6/0x84   [<c01f9df7>]
acpi_pci_link_set+0xf0/0x169
Mar  4 14:24:48 localhost kernel:  [<c01f9ea4>]
irqrouter_resume+0x34/0x52     [<c0226867>] __sysdev_resume+0x11/0x53
Mar  4 14:24:48 localhost NetworkManager: <information> Waking up from sleep.
Mar  4 14:24:48 localhost kernel:  [<c02269a7>]
sysdev_resume+0x16/0x47     [<c022a956>] device_power_up+0x5/0xa
Mar  4 14:24:48 localhost kernel:  [<c0132e86>]
enter_state+0x142/0x1ba     [<c0132f86>] state_store+0x88/0x94
Mar  4 14:24:48 localhost kernel:  [<c0132efe>] state_store+0x0/0x94  
  [<c018817a>] subsys_attr_store+0x1e/0x22
Mar  4 14:24:48 localhost kernel:  [<c0188289>]
sysfs_write_file+0xa9/0xd2     [<c01881e0>] sysfs_write_file+0x0/0xd2
Mar  4 14:24:48 localhost kernel:  [<c0154be3>] vfs_write+0xa1/0x140  
  [<c01550eb>] sys_write+0x3c/0x63
Mar  4 14:24:48 localhost kernel:  [<c0102bc1>] syscall_call+0x7/0xb  
 <7>PM: Finishing wakeup.



From davej at redhat.com  Sat Mar  4 22:42:40 2006
From: davej at redhat.com (Dave Jones)
Date: Sat, 4 Mar 2006 17:42:40 -0500
Subject: other annoyances before fc5
In-Reply-To: <4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
	<4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
Message-ID: <20060304224240.GG3968@redhat.com>

On Sat, Mar 04, 2006 at 02:37:17PM -0800, Tom London wrote:
 > No longer works for me: Thinkpad X41 (Intel 915 graphics).
 > 
 > I tried booting with acpi_serialize, but no joy.
 > 
 > I do see this in /var/log/messages, believe it is when it is trying to wakeup.

Is that with the latest kernel ? I thought I'd nailed the last of the
acpi "sleep in places you can't sleep" bugs.

		Dave



From selinux at gmail.com  Sat Mar  4 22:59:15 2006
From: selinux at gmail.com (Tom London)
Date: Sat, 4 Mar 2006 14:59:15 -0800
Subject: other annoyances before fc5
In-Reply-To: <20060304224240.GG3968@redhat.com>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
	<4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
	<20060304224240.GG3968@redhat.com>
Message-ID: <4c4ba1530603041459yd3a66flae2953056e00966a@mail.gmail.com>

On 3/4/06, Dave Jones <davej at redhat.com> wrote:
> On Sat, Mar 04, 2006 at 02:37:17PM -0800, Tom London wrote:
>  > No longer works for me: Thinkpad X41 (Intel 915 graphics).
>  >
>  > I tried booting with acpi_serialize, but no joy.
>  >
>  > I do see this in /var/log/messages, believe it is when it is trying to wakeup.
>
> Is that with the latest kernel ? I thought I'd nailed the last of the
> acpi "sleep in places you can't sleep" bugs.
>
>                 Dave
>
Yes, with 2.6.15-1.2009.4.2_FC5.

Also, I notice that there are some SELinux AVCs generated during
suspend. Seem to be affecting 'vbetool'.

I 'retried' suspending in Permissive mode, and seemed to get further:
my monitor now is indicating that it is getting a signal, but the
screen is still black.  Also, I think I can 'hear' more disk activity.

I'll log the SELinux messages to the selinux list.

More I can test?

tom
--
Tom London



From davej at redhat.com  Sat Mar  4 23:02:46 2006
From: davej at redhat.com (Dave Jones)
Date: Sat, 4 Mar 2006 18:02:46 -0500
Subject: other annoyances before fc5
In-Reply-To: <4c4ba1530603041459yd3a66flae2953056e00966a@mail.gmail.com>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
	<4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
	<20060304224240.GG3968@redhat.com>
	<4c4ba1530603041459yd3a66flae2953056e00966a@mail.gmail.com>
Message-ID: <20060304230246.GA25773@redhat.com>

On Sat, Mar 04, 2006 at 02:59:15PM -0800, Tom London wrote:
 > On 3/4/06, Dave Jones <davej at redhat.com> wrote:
 > > On Sat, Mar 04, 2006 at 02:37:17PM -0800, Tom London wrote:
 > >  > No longer works for me: Thinkpad X41 (Intel 915 graphics).
 > >  >
 > >  > I tried booting with acpi_serialize, but no joy.
 > >  >
 > >  > I do see this in /var/log/messages, believe it is when it is trying to wakeup.
 > >
 > > Is that with the latest kernel ? I thought I'd nailed the last of the
 > > acpi "sleep in places you can't sleep" bugs.
 > >
 > >                 Dave
 > >
 > Yes, with 2.6.15-1.2009.4.2_FC5.
 > 
 > Also, I notice that there are some SELinux AVCs generated during
 > suspend. Seem to be affecting 'vbetool'.

please bugzilla these against selinux-policy-targeted

 > I 'retried' suspending in Permissive mode, and seemed to get further:
 > my monitor now is indicating that it is getting a signal, but the
 > screen is still black.  Also, I think I can 'hear' more disk activity.

before suspending, log in as root on a tty, so that when you resume
you can ctrl-alt-f1, and type 'vbetool post' (you'll have to type this 'blind')
You may need to then flip back to X with alt-f7

Does that do anything different ?

		Dave



From tambet at ximian.com  Sat Mar  4 23:19:45 2006
From: tambet at ximian.com (Tambet Ingo)
Date: Sat, 04 Mar 2006 18:19:45 -0500
Subject: other annoyances before fc5
In-Reply-To: <4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
	<4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
Message-ID: <1141514386.2110.4.camel@localhost.localdomain>

On Sat, 2006-03-04 at 14:37 -0800, Tom London wrote:
> No longer works for me: Thinkpad X41 (Intel 915 graphics).

I have T40 and I get exactly the same message in /var/log/messages, but
my screen does resume correctly. At the beginning, everything seems to
work fine, and then (in about 10 seconds) everything hangs with

Mar  4 18:05:51 localhost kernel: hda: dma_intr: status=0x51
{ DriveReady SeekComplete Error }
Mar  4 18:05:51 localhost kernel: hda: dma_intr: error=0x10
{ SectorIdNotFound }, LBAsect=75563541, sector=75563541
Mar  4 18:05:51 localhost kernel: ide: failed opcode was: unknown
Mar  4 18:05:51 localhost kernel: hda: dma_intr: status=0x51
{ DriveReady SeekComplete Error }
Mar  4 18:05:51 localhost kernel: hda: dma_intr: error=0x10
{ SectorIdNotFound }, LBAsect=75563541, sector=75563541
Mar  4 18:05:51 localhost kernel: ide: failed opcode was: unknown
....

(kernel-2.6.15-1.2009.4.2_FC5)

Tambet

> 
> I tried booting with acpi_serialize, but no joy.
> 
> I do see this in /var/log/messages, believe it is when it is trying to wakeup.
> 
> Mar  4 14:24:48 localhost kernel: Debug: sleeping function called from
> invalid context at include/asm/semaphore.h:99
> Mar  4 14:24:48 localhost kernel: in_atomic():0, irqs_disabled():1
> Mar  4 14:24:48 localhost kernel:  [<c01e1af5>]
> acpi_os_wait_semaphore+0x61/0xb9     [<c01f69b1>]
> acpi_ut_acquire_mutex+0x2f/0x65
> Mar  4 14:24:48 localhost kernel:  [<c01eef8c>]
> acpi_ns_evaluate_relative+0x4e/0xca     [<c01f2a57>]
> acpi_rs_set_srs_method_data+0x93/0xb7
> Mar  4 14:24:48 localhost kernel:  [<c01f0042>]
> acpi_get_next_object+0x6/0x84   [<c01f9df7>]
> acpi_pci_link_set+0xf0/0x169
> Mar  4 14:24:48 localhost kernel:  [<c01f9ea4>]
> irqrouter_resume+0x34/0x52     [<c0226867>] __sysdev_resume+0x11/0x53
> Mar  4 14:24:48 localhost NetworkManager: <information> Waking up from sleep.
> Mar  4 14:24:48 localhost kernel:  [<c02269a7>]
> sysdev_resume+0x16/0x47     [<c022a956>] device_power_up+0x5/0xa
> Mar  4 14:24:48 localhost kernel:  [<c0132e86>]
> enter_state+0x142/0x1ba     [<c0132f86>] state_store+0x88/0x94
> Mar  4 14:24:48 localhost kernel:  [<c0132efe>] state_store+0x0/0x94  
>   [<c018817a>] subsys_attr_store+0x1e/0x22
> Mar  4 14:24:48 localhost kernel:  [<c0188289>]
> sysfs_write_file+0xa9/0xd2     [<c01881e0>] sysfs_write_file+0x0/0xd2
> Mar  4 14:24:48 localhost kernel:  [<c0154be3>] vfs_write+0xa1/0x140  
>   [<c01550eb>] sys_write+0x3c/0x63
> Mar  4 14:24:48 localhost kernel:  [<c0102bc1>] syscall_call+0x7/0xb  
>  <7>PM: Finishing wakeup.
> 



From selinux at gmail.com  Sat Mar  4 23:21:53 2006
From: selinux at gmail.com (Tom London)
Date: Sat, 4 Mar 2006 15:21:53 -0800
Subject: other annoyances before fc5
In-Reply-To: <20060304230246.GA25773@redhat.com>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
	<4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
	<20060304224240.GG3968@redhat.com>
	<4c4ba1530603041459yd3a66flae2953056e00966a@mail.gmail.com>
	<20060304230246.GA25773@redhat.com>
Message-ID: <4c4ba1530603041521l53c8a263gddd4b25ec2648a5f@mail.gmail.com>

On 3/4/06, Dave Jones <davej at redhat.com> wrote:
>
> before suspending, log in as root on a tty, so that when you resume
> you can ctrl-alt-f1, and type 'vbetool post' (you'll have to type this 'blind')
> You may need to then flip back to X with alt-f7
>
> Does that do anything different ?

Uhh, no. Its not clear that my 'blind typing' actually did anything. I
tried typing 'date >foo; vbetool post >foobar' while blind, and I can
find neither file after shutting down/restarting (CTL-ALT-DEL appears
to shutdown/reboot OK).

Anyway, after typing 'vbetool post', CTL-ALT-F7 had no effect.

I tried typing this on both X41 keyboard and USB keyboard.

tom
--
Tom London



From mailinglists at erwinrol.com  Sat Mar  4 23:37:54 2006
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Sun, 05 Mar 2006 00:37:54 +0100
Subject: dropdown menu's
Message-ID: <1141515474.5468.21.camel@xpc.home.erwinrol.com>

Hey all,

This is something that already bothers me a while, i think it never
really worked as expected, but i am not sure if it is a "my machine
only" kind of problem.

Dropdown menu's that don't fit on the screen are not displayed
correctly. For example take the gimp file-open dialog. When you move the
dialog to the bottom border of the screen, and press the "All Files"
dropdown menu, the menu will open, and the bottom of the menu will be
aligned with the bottom of the screen, the top of the menu will be
somewhere mid screen. But the first entry will be at the location of the
position of the dropdown box, and so everything above that position is
empty. I tried to make a screenshot, but that didn't work with the
dropdown box open, i suggest to just try it. Since it happens with every
GTK application, it smells like an GTK issue.

- Erwin



  



From n0dalus+redhat at gmail.com  Sat Mar  4 23:55:34 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Sun, 5 Mar 2006 10:25:34 +1030
Subject: dropdown menu's
In-Reply-To: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
Message-ID: <6280325c0603041555o692e90e3mda08ca359aea6f3a@mail.gmail.com>

On 3/5/06, Erwin Rol <mailinglists at erwinrol.com> wrote:
>
> Dropdown menu's that don't fit on the screen are not displayed
> correctly. For example take the gimp file-open dialog. When you move the
> dialog to the bottom border of the screen, and press the "All Files"
> dropdown menu, the menu will open, and the bottom of the menu will be
> aligned with the bottom of the screen, the top of the menu will be
> somewhere mid screen. But the first entry will be at the location of the
> position of the dropdown box, and so everything above that position is
> empty.

It doesn't look pretty, but I think this is intentional; the first
option in a drop down list is right next to where your mouse is when
you click on it. If you move the mouse down to the bottom of the list
it will start scrolling up so all the items are visible at once.

n0dalus.



From wrrhdev at riede.org  Sun Mar  5 00:03:47 2006
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 04 Mar 2006 19:03:47 -0500
Subject: dropdown menu's
In-Reply-To: <1141515474.5468.21.camel@xpc.home.erwinrol.com> (from
	mailinglists@erwinrol.com on Sat Mar  4 18:37:54 2006)
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
Message-ID: <1141517027l.19906l.3l@athena.riede.org>

On 03/04/2006 06:37:54 PM, Erwin Rol wrote:
> Hey all,
> 
> This is something that already bothers me a while, i think it never
> really worked as expected, but i am not sure if it is a "my machine
> only" kind of problem.

Happens here too - so it's not just you.

Regards, Willem Riede.




From Lam at Lam.pl  Sun Mar  5 00:15:52 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Sun, 05 Mar 2006 01:15:52 +0100
Subject: dropdown menu's
In-Reply-To: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
Message-ID: <1141517752.21493.8.camel@pensja.lam.pl>

Dnia 05-03-2006, nie o godzinie 00:37 +0100, Erwin Rol napisa?(a): 
> This is something that already bothers me a while, i think it never
> really worked as expected, but i am not sure if it is a "my machine
> only" kind of problem.
From http://www.gtk.org/api/2.6/gtk/GtkComboBox.html
"The style in which the selected value is displayed, and the style of
the popup is determined by the current theme. It may be similar to a
GtkOptionMenu, or similar to a Windows-style combo box."

So probably it can be changed in the theme (or only the look and color,
but not that behavior), but all themes I have here (Fedora 3) have it
the way you experience and dislike. The purpose is to have the currently
selected option right in the place where the option menu is, so you can
click it to see other options and click in the same place again not
changing anything (instead of clicking somewhere else in the window or
hitting Esc). Anyways, it's not Fedora-specific.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060305/08dbdeb1/attachment.sig>

From mharris at mharris.ca  Sun Mar  5 00:27:23 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Sat, 04 Mar 2006 19:27:23 -0500
Subject: rawhide report: 20060304 changes
In-Reply-To: <4409B03D.2060507@redhat.com>
References: <200603040819.k248JDps030282@porkchop.devel.redhat.com>
	<1141461578.5203.49.camel@mccallum.corsepiu.local>
	<44095BDB.6030700@mharris.ca> <4409B03D.2060507@redhat.com>
Message-ID: <440A306B.8020501@mharris.ca>

Christopher Aillon wrote:
> On 03/04/2006 04:20 AM, Mike A. Harris wrote:
> 
>> Ralf Corsepius wrote:
>>
>>> On Sat, 2006-03-04 at 03:19 -0500, Build System wrote:
>>>
>>>
>>>> xorg-x11-xbitmaps-1.0.1-3
>>>> -------------------------
>>>> * Thu Mar 02 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
>>>> - Made package arch specific due to pkgconfig files being placed in 
>>>> lib64
>>>>  if the noarch packages manage to get built on x86_64/ppc64/s390x.
>>>
>>>
>>>
>>> What?
>>>
>>> Fix the toplevel Makefile.am to install the pkgconfig file to $datadir
>>> instead of libdir:
>>>
>>> -pkgconfigdir = $(libdir)/pkgconfig
>>> +pkgconfigdir = $(datadir)/pkgconfig
>>>
>>> That's what other noarch packages do.
>>>
>>>
>>> Alternatively, fix your spec to use
>>>
>>> %configure --libdir=%_datadir
>>> ...
>>> %_datadir/share/pkgconfig/*.pc
>>
>>
>> For now, the important thing is that FC5 is in a state that everything
>> builds, and is ready for final release.  Minor trivia like this is not
>> mission critical to the release of the OS.
>>
>> Feel free to submit a patch to X.Org to do this, so it is fixed in
>> the future.
>>
>>
> 
> Actually, it's more important that things are in a state where upgrading 
> works sanely.  Changing from noarch -> arch-specific -> noarch typically 
> breaks upgrading.

That was the case in the past, when the tools did not support the
architecture changing with the package name staying the same.  My
understanding is that yum has supported this for a long time now,
and that up2date and other tools also support it.  I've certainly
had no upgrade problems while testing any arch -> noarch -> arch
updates anyway, and haven't had any bug reports.



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mailinglists at erwinrol.com  Sun Mar  5 00:34:21 2006
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Sun, 05 Mar 2006 01:34:21 +0100
Subject: dropdown menu's
In-Reply-To: <1141517752.21493.8.camel@pensja.lam.pl>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
	<1141517752.21493.8.camel@pensja.lam.pl>
Message-ID: <1141518861.5468.33.camel@xpc.home.erwinrol.com>

On Sun, 2006-03-05 at 01:15 +0100, Leszek Matok wrote:

> So probably it can be changed in the theme (or only the look and
> color, but not that behavior), but all themes I have here (Fedora 3)
> have it the way you experience and dislike. The purpose is to have the
> currently selected option right in the place where the option menu is,
> so you can click it to see other options 

Well that won't work, because you now have to scroll to see the other
options. 

> and click in the same place again not changing anything (instead of
> clicking somewhere else in the window or hitting Esc). Anyways, it's
> not Fedora-specific.

But anyway if it is a specially designed feature, i guess i just dislike
it because a large empty "menu" on the screen just looks weird. A better
way would probably be having an extra entry always at the top (or bottom
when the menu goes up, that holds the current selection, a bit like the
font selection in OOo.org. That way you can click twice to "check" and
you don#t have that strange empty menu.

- Erwin





From pedro.lamarao at mndfck.org  Sun Mar  5 00:50:11 2006
From: pedro.lamarao at mndfck.org (=?ISO-8859-1?Q?Pedro_Lamar=E3o?=)
Date: Sat, 04 Mar 2006 21:50:11 -0300
Subject: libstdc++-so7 info?
In-Reply-To: <1140642120.2983.14.camel@entropy>
References: <dthk4l$qo$1@sea.gmane.org>	<20060222120933.GZ24295@devserv.devel.redhat.com>	<1140637220.2983.4.camel@entropy>	<20060222201844.GF24295@devserv.devel.redhat.com>
	<1140642120.2983.14.camel@entropy>
Message-ID: <dudd3b$p11$1@sea.gmane.org>

Nicholas Miell wrote:

[SNIP]

> Nice to see that somebody is finally trying to solve the problem,
> instead of just letting the users suffer. Maybe C++ will actually be a
> viable language for library development one day soon.

C++ is excellent for library development.[1]

C++ libraries present difficulties to distributors of precompiled
systems in an environment where users need, for some random reason, to
use the latest.

g++ 3.3 is still available, and g++ 3.4 is still being maintained. You
don't want your system to break ABI? Don't break ABI in *your* system,
then.[2] This is the free software world.

[1] http://www.boost.org/

[2] I don't remember Red Hat / Fedora ever upgrading GCC like that for a
given system version. But maybe I just don't remember much.

--
 Pedro Lamar?o



From Lam at Lam.pl  Sun Mar  5 00:58:48 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Sun, 05 Mar 2006 01:58:48 +0100
Subject: dropdown menu's
In-Reply-To: <1141518861.5468.33.camel@xpc.home.erwinrol.com>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
	<1141517752.21493.8.camel@pensja.lam.pl>
	<1141518861.5468.33.camel@xpc.home.erwinrol.com>
Message-ID: <1141520328.21493.20.camel@pensja.lam.pl>

Dnia 05-03-2006, nie o godzinie 01:34 +0100, Erwin Rol napisa?(a):
> A better
> way would probably be having an extra entry always at the top (or bottom
> when the menu goes up, that holds the current selection, a bit like the
> font selection in OOo.org.
What you mean (I think) is making all GtkComboBoxes' popups (or
dropdowns) appear below/above the GtkComboBox (leaving it in place for
second click), not making this "empty space", instead only scrolling in
the area from the GtkComboBox to the start/end of the screen (depending
on where it appeared).

If it can be changed in theme, than it is a good idea to ask BlueCurve
authors to work on it. Otherwise, aren't we on a wrong list?

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060305/adf51130/attachment.sig>

From thuforuk at yahoo.co.uk  Sun Mar  5 01:04:10 2006
From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski)
Date: Sun, 05 Mar 2006 01:04:10 +0000
Subject: dropdown menu's
In-Reply-To: <1141517752.21493.8.camel@pensja.lam.pl>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
	<1141517752.21493.8.camel@pensja.lam.pl>
Message-ID: <440A390A.7030100@yahoo.co.uk>

On 03/05/2006 12:15 AM, Leszek Matok wrote:
> Dnia 05-03-2006, nie o godzinie 00:37 +0100, Erwin Rol napisa?(a): 
>> This is something that already bothers me a while, i think it never
>> really worked as expected, but i am not sure if it is a "my machine
>> only" kind of problem.
> From http://www.gtk.org/api/2.6/gtk/GtkComboBox.html
> "The style in which the selected value is displayed, and the style of
> the popup is determined by the current theme. It may be similar to a
> GtkOptionMenu, or similar to a Windows-style combo box."
> 
> So probably it can be changed in the theme (or only the look and color,
> but not that behavior), but all themes I have here (Fedora 3) have it
> the way you experience and dislike. The purpose is to have the currently
> selected option right in the place where the option menu is, so you can
> click it to see other options and click in the same place again not
> changing anything (instead of clicking somewhere else in the window or
> hitting Esc). Anyways, it's not Fedora-specific.

It's silly -- you click on the combobox to see what other options are 
and yet you don't see them! util of course you move the mouse to the 
bottom of the screen, wait for the whole list to scroll up (never mind 
that there was enough space on screen to display all option in the first 
place) and only then you can decide whether you actually want to change 
the option. Now how on Earth can you save any time or effort of moving 
cursor some place else in the window to click to cancel? Very smart...

I dislike this "design" too :(

Dariusz


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com



From nmiell at comcast.net  Sun Mar  5 02:10:12 2006
From: nmiell at comcast.net (Nicholas Miell)
Date: Sat, 04 Mar 2006 18:10:12 -0800
Subject: libstdc++-so7 info?
In-Reply-To: <dudd3b$p11$1@sea.gmane.org>
References: <dthk4l$qo$1@sea.gmane.org>
	<20060222120933.GZ24295@devserv.devel.redhat.com>
	<1140637220.2983.4.camel@entropy>
	<20060222201844.GF24295@devserv.devel.redhat.com>
	<1140642120.2983.14.camel@entropy>  <dudd3b$p11$1@sea.gmane.org>
Message-ID: <1141524612.2991.19.camel@entropy>

On Sat, 2006-03-04 at 21:50 -0300, Pedro Lamar?o wrote:
> Nicholas Miell wrote:
> 
> [SNIP]
> 
> > Nice to see that somebody is finally trying to solve the problem,
> > instead of just letting the users suffer. Maybe C++ will actually be a
> > viable language for library development one day soon.
> 
> C++ is excellent for library development.

You have failed to consider what happens when multiple objects link to
different ABI-incompatible versions of libstdc++.

In such a situation, ELF symbol resolution rules cause all the libstdc++
symbols to resolve to the first instance of the library loaded
(typically the version of libstdc++ used by the main application).

If vtable layout has changed, object size or layout has changed, or some
implementation detail assumed by inlined libstdc++ functions has
changed, things blow up messily.

This will happen even if the main application doesn't actually use the
STL, because it has to link to libstdc++ anyway to get the runtime
support necessary for C++ to function. (This runtime support is actually
part of libsupc++ -- which has had a stable ABI -- but you can't link to
libsupc++ separately in the dynamic case.)

ELF symbol versioning is supposed to help with this, but apparently it
doesn't (for reasons that were never really made clear). It certainly
won't help in the case where STL objects are involved in the public
library API.

As such, the only reliable way to use C++ on Linux is to never actually
use any of the STL. This isn't something you can guarantee and decreases
the benefits of using C++ in the first place.

(And if any of this happens to be wrong, please correct me!)

-- 
Nicholas Miell <nmiell at comcast.net>



From pedro.lamarao at mndfck.org  Sun Mar  5 03:20:06 2006
From: pedro.lamarao at mndfck.org (=?UTF-8?B?UGVkcm8gTGFtYXLDo28=?=)
Date: Sun, 05 Mar 2006 00:20:06 -0300
Subject: libstdc++-so7 info?
In-Reply-To: <1141524612.2991.19.camel@entropy>
References: <dthk4l$qo$1@sea.gmane.org>	<20060222120933.GZ24295@devserv.devel.redhat.com>	<1140637220.2983.4.camel@entropy>	<20060222201844.GF24295@devserv.devel.redhat.com>	<1140642120.2983.14.camel@entropy>
	<dudd3b$p11$1@sea.gmane.org> <1141524612.2991.19.camel@entropy>
Message-ID: <dudls9$afo$1@sea.gmane.org>

Nicholas Miell wrote:

>>C++ is excellent for library development.
> 
> 
> You have failed to consider what happens when multiple objects link to
> different ABI-incompatible versions of libstdc++.

I have not. Of course there are problems with linking together objects
which themselves are linked against incompatible versions of the same
library.

BUT, as I said, this is not a problem simply because libraries break
ABI, this is a problem because systems administrators and/or users, for
some random reason, decide to use the latest.

Why are you linking new objects against the latest when already present,
necessary, objects are linked against something older?

Are we talking about "absolute" requirements like some new software you
must have that is not compatible with your current system? Oops, not
compatible with your current system.

Are you upgrading your system compiler, together with your system
libraries, to a newer, ABI breaking, version? Oops, not compatible with
your current system.

Are you doing it just because newest is best? Whoa.

Are you doing it without even noticing? Whoa. Why are you compiling
stuff again?

This is the free software world. If you were being forced to upgrade to
ABI breaking versions, because, say, your commercial vendor says so, I'd
understand your woes. But you're not. The source for older free software
is available for as long as we're competent to keep the storage running.
I never heard of relevant free software being lost forever for any reason.



From nmiell at comcast.net  Sun Mar  5 04:36:13 2006
From: nmiell at comcast.net (Nicholas Miell)
Date: Sat, 04 Mar 2006 20:36:13 -0800
Subject: libstdc++-so7 info?
In-Reply-To: <dudls9$afo$1@sea.gmane.org>
References: <dthk4l$qo$1@sea.gmane.org>
	<20060222120933.GZ24295@devserv.devel.redhat.com>
	<1140637220.2983.4.camel@entropy>
	<20060222201844.GF24295@devserv.devel.redhat.com>
	<1140642120.2983.14.camel@entropy> <dudd3b$p11$1@sea.gmane.org>
	<1141524612.2991.19.camel@entropy>  <dudls9$afo$1@sea.gmane.org>
Message-ID: <1141533373.2991.37.camel@entropy>

On Sun, 2006-03-05 at 00:20 -0300, Pedro Lamar?o wrote:
> Nicholas Miell wrote:
> 
> >>C++ is excellent for library development.
> > 
> > 
> > You have failed to consider what happens when multiple objects link to
> > different ABI-incompatible versions of libstdc++.
> 
> I have not. Of course there are problems with linking together objects
> which themselves are linked against incompatible versions of the same
> library.

I shouldn't have to care, and incompatible versions of the same library
shouldn't exist.

> BUT, as I said, this is not a problem simply because libraries break
> ABI, this is a problem because systems administrators and/or users, for
> some random reason, decide to use the latest.

Or perhaps they upgraded their OS.

> Why are you linking new objects against the latest when already present,
> necessary, objects are linked against something older?

I'm not. I'm linking them against the system-supplied library chosen by
the compiler. Of course, I can't actually distribute this object,
because my end users might have other objects linked against newer or
older versions of libstdc++.

> Are we talking about "absolute" requirements like some new software you
> must have that is not compatible with your current system? Oops, not
> compatible with your current system.
> 
> Are you upgrading your system compiler, together with your system
> libraries, to a newer, ABI breaking, version? Oops, not compatible with
> your current system.
> 
> Are you doing it just because newest is best? Whoa.
> 
> Are you doing it without even noticing? Whoa. Why are you compiling
> stuff again?
> 
> This is the free software world. If you were being forced to upgrade to
> ABI breaking versions, because, say, your commercial vendor says so, I'd
> understand your woes. But you're not. The source for older free software
> is available for as long as we're competent to keep the storage running.
> I never heard of relevant free software being lost forever for any reason.
> 

Ah, so you think that N different versions of program compiled for FC 4,
FC 3, FC 2, FC 1, RHEL 4, RHEL 3, CentOS 4, CentOS 3, SLES 9, NLD 9,
SuSE Linux 10, Debian etch, Debian 3.1, Ubuntu 5.10, Ubuntu dapper
drake, Mandriva 2006, and Slackware 10.2 is a good thing? (And that's
just the big distros...)
-- 
Nicholas Miell <nmiell at comcast.net>



From seg at haxxed.com  Sun Mar  5 05:12:49 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 04 Mar 2006 23:12:49 -0600
Subject: Vino
In-Reply-To: <4408C656.6090301@fedoraproject.org>
References: <6f6293f10603021607s1ca409e3gd3e448ee1eebd9f4@mail.gmail.com>
	<1141425066.2822.4.camel@localhost>
	<4408C656.6090301@fedoraproject.org>
Message-ID: <1141535569.26432.3.camel@localhost>

On Sat, 2006-03-04 at 04:12 +0530, Rahul Sundaram wrote:
> Callum Lerwick wrote:
> 
> >No, I find vino to be unusably slow and buggy as well. I use the vnc X
> >server extension instead. Which oddly enough, is even faster than using
> >a dedicated Xvnc server. The VNC extension seems to have broken in test3
> >however...
> >  
> >
> Have you filed a bug report on the VNC extension being broken?

Nope. FC5t3 broke a bunch of stuff (Can't log in to Gnome either) on
this particular system, (Laptop upgraded just fine, go fig) and I don't
have a lot of time (School) to deal with it right now. Bleh.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060304/36d80fea/attachment.sig>

From seg at haxxed.com  Sun Mar  5 05:25:34 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 04 Mar 2006 23:25:34 -0600
Subject: dropdown menu's
In-Reply-To: <440A390A.7030100@yahoo.co.uk>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
	<1141517752.21493.8.camel@pensja.lam.pl> <440A390A.7030100@yahoo.co.uk>
Message-ID: <1141536335.26432.4.camel@localhost>

> I dislike this "design" too :(

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

From buildsys at redhat.com  Sun Mar  5 08:33:48 2006
From: buildsys at redhat.com (Build System)
Date: Sun, 5 Mar 2006 03:33:48 -0500
Subject: rawhide report: 20060305 changes
Message-ID: <200603050833.k258XmGC026238@porkchop.devel.redhat.com>

 

 
Updated Packages:

gnome-terminal-2.13.93-1
------------------------
* Sat Mar 04 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.93-1
- Update to 2.13.93

lam-2:7.1.1-11
--------------
* Tue Feb 21 2006 Jason Vas Dias<jvdias at redhat.com> - 2:7.1.1-11
- ld.so.conf.d/mpi.conf integration with openmpi

* Thu Feb 16 2006 Jason Vas Dias<jvdias at redhat.com> - 2:7.1.1-10.FC5
- Enable co-existence with OpenMPI

sysklogd-1.4.1-36
-----------------
* Thu Feb 23 2006 Jason Vas Dias <jvdias at redhat.com> - 1.4.1-36
- fix bug 182605: only chkconfig --add in %post if $1 -eq 1

system-config-bind-4.0.0-38_FC5
-------------------------------
* Wed Mar 01 2006 Jason Vas Dias <jvdias at redhat.com> - 4.0.0-38
- fix bug 182857: add Requires(post): hicolor-icon-them
- ship updated translations

system-config-netboot-0.1.38-1
------------------------------
* Tue Feb 14 2006 Jason Vas Dias <jvdias at redhat.com> - 0.1.38-1
- further fix for f1 at micromemory.com problem (now bug 181365)
  deal with required binaries that have been replaced by scripts
- fix bug 178395: allow setting of NISDOMAIN 
- fix bug 174629: fix initscript patches (prevent application!)
- fix bug 182869: should Requires(post): hicolor-icon-theme
- fix issues reported by brian at chpc.utah.edu (bugs to be raised):
  o mkdiskless must not wipe out client root customizations on re-run
  o give serial console checkbox a speed drop down list
    - add "Use tty0 console also" checkbox option
  o allow editing of extra boot options in the config file
  o do not create snapshot directory for network boot targets
  o remove /etc/ssh keys and make /etc/ssh a snapshot file
  o mount /var/cache, /var/lib/misc, /var/lib/mrtg on tmpfs / snapshot
  o fix network syslog : '*' -> '*.*'

udev-084-11
-----------
* Sun Mar 05 2006 Bill Nottingham <notting at redhat.com> - 084-11
- use $ENV{MODALIAS}, not $modalias (#181494)

xorg-x11-fonts-7.0-3
--------------------
* Sat Mar 04 2006 Mike A. Harris <mharris at redhat.com> 7.0-3
- Ensure upgrade-only section of fonts-base rpm post script only executes on
  upgrades using -gt instead of -ge.

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	gnome-volume-manager - 1.5.13-3.ia64 requires kernel >= 0:2.6
	pcmciautils - 011-1.2.ia64 requires kernel >= 0:2.6.12-1.1411_FC5
	rgmanager - 1.9.31-3.ia64 requires ccs
	systemtap - 0.5.4-2.2.ia64 requires kernel >= 0:2.6.9-11






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_4fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From fedora at adslpipe.co.uk  Sun Mar  5 08:54:09 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Sun, 05 Mar 2006 08:54:09 +0000
Subject: other annoyances before fc5
In-Reply-To: <510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
Message-ID: <440AA731.7020302@adslpipe.co.uk>

Vitor Domingos wrote:

> what's the status for suspend/hibernate on FC5, specially on ATI Radeon cards ?

If video isn't re-enabled after resume, I found that switching VTs 
revived it, i.e. press CTRL-ALT-F1 to force card to text console, then 
ALT-F7 to go back to X console, at which point my monitor comes out of 
DPMS sleep :-)



From nicolas.mailhot at laposte.net  Sun Mar  5 10:19:49 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 05 Mar 2006 11:19:49 +0100
Subject: other annoyances before fc5
In-Reply-To: <440AA731.7020302@adslpipe.co.uk>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
Message-ID: <1141553990.6034.1.camel@rousalka.dyndns.org>

The worst annoyance right now is the gnome panel not being closed on
logout, as a result gnome-session refuses to create a panel on login.

I don't know if a non-technical user will be able to cope with this,
unless he reboots on each logout.

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

From sundaram at fedoraproject.org  Sun Mar  5 10:42:53 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 05 Mar 2006 16:12:53 +0530
Subject: other annoyances before fc5
In-Reply-To: <1141553990.6034.1.camel@rousalka.dyndns.org>
References: <duci8r$9si$1@sea.gmane.org>	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>	<440AA731.7020302@adslpipe.co.uk>
	<1141553990.6034.1.camel@rousalka.dyndns.org>
Message-ID: <440AC0AD.8030300@fedoraproject.org>

Nicolas Mailhot wrote:

>The worst annoyance right now is the gnome panel not being closed on
>logout, as a result gnome-session refuses to create a panel on login.
>
>I don't know if a non-technical user will be able to cope with this,
>unless he reboots on each logout.
>  
>
Do you have a bug report on this? It works fine on my rawhide system 
with all the updates.


-- 
Rahul 





From nicolas.mailhot at laposte.net  Sun Mar  5 11:02:33 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 05 Mar 2006 12:02:33 +0100
Subject: other annoyances before fc5
In-Reply-To: <440AC0AD.8030300@fedoraproject.org>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<1141553990.6034.1.camel@rousalka.dyndns.org>
	<440AC0AD.8030300@fedoraproject.org>
Message-ID: <1141556553.6034.5.camel@rousalka.dyndns.org>

Le dimanche 05 mars 2006 ? 16:12 +0530, Rahul Sundaram a ?crit :
> Nicolas Mailhot wrote:
> 
> >The worst annoyance right now is the gnome panel not being closed on
> >logout, as a result gnome-session refuses to create a panel on login.
> >
> >I don't know if a non-technical user will be able to cope with this,
> >unless he reboots on each logout.
> >  
> >
> Do you have a bug report on this? It works fine on my rawhide system 
> with all the updates.

It's pretty erratic - I suppose at one point of my workflow something
happens that puts the panel in unkillable state. Pretty difficult to
pinpoint - I have long sessions

I don't have a bug number but this particular problem has been reported
by several people already on the lists so I suppose there is an entry in
bugzilla somewhere.

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

From sundaram at fedoraproject.org  Sun Mar  5 11:13:36 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 05 Mar 2006 16:43:36 +0530
Subject: other annoyances before fc5
In-Reply-To: <1141556553.6034.5.camel@rousalka.dyndns.org>
References: <duci8r$9si$1@sea.gmane.org>	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>	<440AA731.7020302@adslpipe.co.uk>	<1141553990.6034.1.camel@rousalka.dyndns.org>	<440AC0AD.8030300@fedoraproject.org>
	<1141556553.6034.5.camel@rousalka.dyndns.org>
Message-ID: <440AC7E0.7040504@fedoraproject.org>

Nicolas Mailhot wrote:

>It's pretty erratic - I suppose at one point of my workflow something
>happens that puts the panel in unkillable state. Pretty difficult to
>pinpoint - I have long sessions
>
>I don't have a bug number but this particular problem has been reported
>by several people already on the lists so I suppose there is an entry in
>bugzilla somewhere.
>  
>
There isnt any bug reports filed on this against fedora devel or any of 
the FC 5 test releases. If you come across this issue again, kindly file 
a bug reports with the details.


-- 
Rahul 





From gilboad at gmail.com  Sun Mar  5 11:11:25 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 05 Mar 2006 13:11:25 +0200
Subject: other annoyances before fc5
In-Reply-To: <440AC0AD.8030300@fedoraproject.org>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<1141553990.6034.1.camel@rousalka.dyndns.org>
	<440AC0AD.8030300@fedoraproject.org>
Message-ID: <1141557085.8109.9.camel@gilboa-work-dev>

On Sun, 2006-03-05 at 16:12 +0530, Rahul Sundaram wrote:
> Nicolas Mailhot wrote:
> 
> >The worst annoyance right now is the gnome panel not being closed on
> >logout, as a result gnome-session refuses to create a panel on login.
> >
> >I don't know if a non-technical user will be able to cope with this,
> >unless he reboots on each logout.
> >  
> >
> Do you have a bug report on this? It works fine on my rawhide system 
> with all the updates.
> 
> 
> -- 
> Rahul 
> 
> 
> 

Saw the same under FC5T3.
Log off, Log on, all panels crash; Check process list, all old panels
remain active.
I couldn't reproduce it, so I decided against BZ'ing it.

Gilboa



From emeric.maschino at jouy.inra.fr  Sun Mar  5 12:16:47 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Sun,  5 Mar 2006 13:16:47 +0100
Subject: other annoyances before fc5
In-Reply-To: <1141557085.8109.9.camel@gilboa-work-dev>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<1141553990.6034.1.camel@rousalka.dyndns.org>
	<440AC0AD.8030300@fedoraproject.org>
	<1141557085.8109.9.camel@gilboa-work-dev>
Message-ID: <1141561007.440ad6af746bd@www.jouy.inra.fr>

This problem appears for me only when a GNOME-related package update is
installed. This is on an Itanium workstation.

    ?meric

Selon Gilboa Davara <gilboad at gmail.com>:

> On Sun, 2006-03-05 at 16:12 +0530, Rahul Sundaram wrote:
> > Nicolas Mailhot wrote:
> >
> > >The worst annoyance right now is the gnome panel not being closed on
> > >logout, as a result gnome-session refuses to create a panel on login.
> > >
> > >I don't know if a non-technical user will be able to cope with this,
> > >unless he reboots on each logout.
> > >
> > >
> > Do you have a bug report on this? It works fine on my rawhide system
> > with all the updates.
> >
> >
> > --
> > Rahul
> >
> >
> >
>
> Saw the same under FC5T3.
> Log off, Log on, all panels crash; Check process list, all old panels
> remain active.
> I couldn't reproduce it, so I decided against BZ'ing it.
>
> Gilboa
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>




From emeric.maschino at jouy.inra.fr  Sun Mar  5 12:24:26 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Sun,  5 Mar 2006 13:24:26 +0100
Subject: 2GB swap partition limit?
Message-ID: <1141561466.440ad87ae2478@www.jouy.inra.fr>

Hi,

I didn't notice this earlier. On Feb. 11th, I completely reinstalled Fedora Core
on my Itanium workstation using the FTP method. All ran flawlessly and, by
contrast to my first attempt, the anaconda graphical screens were correctly
displayed.

My workstation has been upgraded to 6GB RAM. I let anaconda automatically manage
the partitions on the disk. It created a 4GB swap partition in a LVM volume.
But top, free and gnome-system-monitor all report that my swap space is 2GB
(more precisely, 1.9GB). IIRC, there was a 2GB limit partition for the swap
size in the past, but I thought this has been overcame.

Isn't it the case?

Cheers,

    ?meric



From gianluca.cecchi at gmail.com  Sun Mar  5 12:41:11 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Sun, 5 Mar 2006 13:41:11 +0100
Subject: 2009 kernel hangs on amd mp when uni processor kernel chosen
Message-ID: <561c252c0603050441x3e654556k96e5fda90616e343@mail.gmail.com>

For error I started the uniprocessor kernel on a dual MP 2200+ system
and I noticed that
the uniprocessor 2.6.15-1.2009.4.2_FC5 kernel hangs up. The smp one is
ok instead.
Tried two times with same result.
The message is:
BUG: soft lockup detected on cpu#0!
PID:0, comm: swapper
EIP: 0060 [<c01394fe>] CPU: 0
EIP is at handle_irq_event+0x17/0x4c



From gilboad at gmail.com  Sun Mar  5 12:54:42 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 05 Mar 2006 14:54:42 +0200
Subject: 2GB swap partition limit?
In-Reply-To: <1141561466.440ad87ae2478@www.jouy.inra.fr>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
Message-ID: <1141563282.8109.18.camel@gilboa-work-dev>

On Sun, 2006-03-05 at 13:24 +0100, ?meric Maschino wrote:
> Hi,
> 
> I didn't notice this earlier. On Feb. 11th, I completely reinstalled Fedora Core
> on my Itanium workstation using the FTP method. All ran flawlessly and, by
> contrast to my first attempt, the anaconda graphical screens were correctly
> displayed.
> 
> My workstation has been upgraded to 6GB RAM. I let anaconda automatically manage
> the partitions on the disk. It created a 4GB swap partition in a LVM volume.
> But top, free and gnome-system-monitor all report that my swap space is 2GB
> (more precisely, 1.9GB). IIRC, there was a 2GB limit partition for the swap
> size in the past, but I thought this has been overcame.
> 
> Isn't it the case?
> 
> Cheers,
> 
>     ?meric
> 

Weird,

The "new swap" type (mkswap -v1, default) which came in kernel v2.2 (?)
fixed the 2GB limit on swap space that came with the "old swap" type.
(mkswap -v0).

E.g. (my workstation; FC4/64)
[gilboa at gilboa-home-dev ~]$ cat /proc/meminfo
MemTotal:      2048624 kB
MemFree:         21516 kB
Buffers:        125596 kB
Cached:        1029680 kB
SwapCached:          0 kB
Active:        1397408 kB
Inactive:       301004 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      2048624 kB
LowFree:         21516 kB
SwapTotal:     4063224 kB
SwapFree:      4062868 kB
Dirty:            1360 kB
Writeback:           0 kB
Mapped:         721168 kB
Slab:           230228 kB
CommitLimit:   5087536 kB
Committed_AS:  1664788 kB
PageTables:      17560 kB
VmallocTotal: 34359738367 kB
VmallocUsed:     38064 kB
VmallocChunk: 34359696379 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB
[gilboa at gilboa-home-dev ~]$ cat /proc/swaps
Filename                                Type            Size    Used
Priority
/dev/mapper/VolMD-LogSwap               partition       4063224 356
-1




From emeric.maschino at jouy.inra.fr  Sun Mar  5 13:39:33 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Sun,  5 Mar 2006 14:39:33 +0100
Subject: 2GB swap partition limit?
In-Reply-To: <1141563282.8109.18.camel@gilboa-work-dev>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<1141563282.8109.18.camel@gilboa-work-dev>
Message-ID: <1141565973.440aea15c0199@www.jouy.inra.fr>

Thanks for your report.

I'm wondering if there's not something wrong with my LVM volume. anaconda
created a 4GB swap partition, but cat /proc/meminfo and cat /proc/swaps all
report it's in fact 2GB. Furthermore, I'm getting "Incorrect metadata area
header checksum" when my LV are mounted or when I enter lvdisplay at the lvm>
prompt.

   ?meric

> Weird,
>
> The "new swap" type (mkswap -v1, default) which came in kernel v2.2 (?)
> fixed the 2GB limit on swap space that came with the "old swap" type.
> (mkswap -v0).
>
> E.g. (my workstation; FC4/64)
> [gilboa at gilboa-home-dev ~]$ cat /proc/meminfo
> MemTotal:      2048624 kB
> MemFree:         21516 kB
> Buffers:        125596 kB
> Cached:        1029680 kB
> SwapCached:          0 kB
> Active:        1397408 kB
> Inactive:       301004 kB
> HighTotal:           0 kB
> HighFree:            0 kB
> LowTotal:      2048624 kB
> LowFree:         21516 kB
> SwapTotal:     4063224 kB
> SwapFree:      4062868 kB
> Dirty:            1360 kB
> Writeback:           0 kB
> Mapped:         721168 kB
> Slab:           230228 kB
> CommitLimit:   5087536 kB
> Committed_AS:  1664788 kB
> PageTables:      17560 kB
> VmallocTotal: 34359738367 kB
> VmallocUsed:     38064 kB
> VmallocChunk: 34359696379 kB
> HugePages_Total:     0
> HugePages_Free:      0
> Hugepagesize:     2048 kB
> [gilboa at gilboa-home-dev ~]$ cat /proc/swaps
> Filename                                Type            Size    Used
> Priority
> /dev/mapper/VolMD-LogSwap               partition       4063224 356
> -1



From sdl.web at gmail.com  Sun Mar  5 13:42:56 2006
From: sdl.web at gmail.com (leon)
Date: Sun, 05 Mar 2006 13:42:56 +0000
Subject: Sendmail won't send mails
Message-ID: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>

Hi all,

I just noticed that I have dozens of mails queuing in
/var/spool/mqueue. I use the default setting from fedora development.

Sendmail daemon is running. I only need to send outgoing mails in my
laptop. The following information might be related:

SElinux: permissive
Firewall: ssh enabled only

-- 
Leon
Fedora Core release 4 (Rawhide)



From arjan at fenrus.demon.nl  Sun Mar  5 13:45:53 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Sun, 05 Mar 2006 14:45:53 +0100
Subject: 2GB swap partition limit?
In-Reply-To: <1141561466.440ad87ae2478@www.jouy.inra.fr>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
Message-ID: <1141566353.16916.2.camel@laptopd505.fenrus.org>


> But top, free and gnome-system-monitor all report that my swap space is 2GB
> (more precisely, 1.9GB). IIRC, there was a 2GB limit partition for the swap
> size in the past, but I thought this has been overcame.

there is no principle 2Gb limit since the 2.4 kernels (RHL 7.1 for those
who still remember that one). So either the tools that report are broken
(eg using the wrong data types) or the tools that set things up are
somehow.. but it'd be odd if it was this later since it for sure used to
work.



From sdl.web at gmail.com  Sun Mar  5 13:51:41 2006
From: sdl.web at gmail.com (leon)
Date: Sun, 05 Mar 2006 13:51:41 +0000
Subject: Sendmail won't send mails
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>

leon <sdl.web at gmail.com> writes:

 | Hi all,
 | 
 | I just noticed that I have dozens of mails queuing in
 | /var/spool/mqueue. I use the default setting from fedora development.
 | 
 | Sendmail daemon is running. I only need to send outgoing mails in my
 | laptop. The following information might be related:
 | 
 | SElinux: permissive
 | Firewall: ssh enabled only
 | 
 | -- 
 | Leon
 | Fedora Core release 4 (Rawhide)

I can send mails to newgroup but not to external email accounts. Any
ideas?

-- 
Leon



From walovaton at yahoo.com.mx  Sun Mar  5 13:55:08 2006
From: walovaton at yahoo.com.mx (William Lovaton)
Date: Sun, 05 Mar 2006 08:55:08 -0500
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <4407F361.4010908@vip.hr>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<20060302145338.0f8f7aac.zaitcev@redhat.com>
	<44078D70.8010906@mharris.ca> <4407F361.4010908@vip.hr>
Message-ID: <1141566908.2198.8.camel@athlon2000>

El vie, 03-03-2006 a las 08:42 +0100, Igor Jagec escribi??:
> Mike A. Harris wrote:
> 
> > I'm often asked which laptop chipset one should buy, or which
> > laptop chipset is best supported.
> 
> It would be much easier for us if we could buy a laptop with Linux
> preinstalled

Talking about this... has anyone tested the LinuxCertified Laptops?
[] http://linuxcertified.com/linux_laptops.html

Any comments about them?


-William


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ?gratis! 
Reg?strate ya - http://correo.yahoo.com.mx/ 



From dwmw2 at infradead.org  Sun Mar  5 13:59:11 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 05 Mar 2006 13:59:11 +0000
Subject: Sendmail won't send mails
In-Reply-To: <m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <1141567151.4233.26.camel@pmac.infradead.org>

On Sun, 2006-03-05 at 13:51 +0000, leon wrote:
> I can send mails to newgroup but not to external email accounts. Any
> ideas?

Not unless you show the sendmail logs which recorded the reason why
those mails didn't go through, no.

-- 
dwmw2



From sdl.web at gmail.com  Sun Mar  5 14:17:34 2006
From: sdl.web at gmail.com (leon)
Date: Sun, 05 Mar 2006 14:17:34 +0000
Subject: Sendmail won't send mails
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141567151.4233.26.camel@pmac.infradead.org>
Message-ID: <m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>

David Woodhouse <dwmw2 at infradead.org> writes:

 | On Sun, 2006-03-05 at 13:51 +0000, leon wrote:
 | > I can send mails to newgroup but not to external email accounts. Any
 | > ideas?
 | 
 | Not unless you show the sendmail logs which recorded the reason why
 | those mails didn't go through, no.
 | 
 | -- 
 | dwmw2

Here is /var/log/maillog
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: maillog
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060305/392fbe81/attachment.ksh>
-------------- next part --------------

Thank you.
-- 
Leon

From dwmw2 at infradead.org  Sun Mar  5 14:28:05 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 05 Mar 2006 14:28:05 +0000
Subject: Sendmail won't send mails
In-Reply-To: <m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141567151.4233.26.camel@pmac.infradead.org>
	<m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <1141568885.4233.33.camel@pmac.infradead.org>

On Sun, 2006-03-05 at 14:17 +0000, leon wrote:
> Here is /var/log/maillog

Connection timed out when trying to contact any host outside cam.ac.uk.
That's hardly surprising; the UCS started filtering outgoing port 25
from undergrad machines (and indeed any machines not explictly
permitted) about a decade ago.

Use a smarthost -- probably smtp.hermes.

-- 
dwmw2



From sdl.web at gmail.com  Sun Mar  5 14:38:41 2006
From: sdl.web at gmail.com (leon)
Date: Sun, 05 Mar 2006 14:38:41 +0000
Subject: Sendmail won't send mails
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141567151.4233.26.camel@pmac.infradead.org>
	<m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141568885.4233.33.camel@pmac.infradead.org>
Message-ID: <m3y7zphs7i.fsf@sl392.st-edmunds.cam.ac.uk>

David Woodhouse <dwmw2 at infradead.org> writes:

 | On Sun, 2006-03-05 at 14:17 +0000, leon wrote:
 | > Here is /var/log/maillog
 | 
 | Connection timed out when trying to contact any host outside cam.ac.uk.
 | That's hardly surprising; the UCS started filtering outgoing port 25
 | from undergrad machines (and indeed any machines not explictly
 | permitted) about a decade ago.
 | 
 | Use a smarthost -- probably smtp.hermes.
 | 
 | -- 
 | dwmw2
Very informative. Thanks.

1. Can I choose another port to workaround?
2. How to delete queue mails in /var/spool/mqueue:
   ? rm -rf /var/spool/mqueue/*

Thanks again.
-- 
Leon



From kms at passback.co.uk  Sun Mar  5 14:49:10 2006
From: kms at passback.co.uk (Keith Sharp)
Date: Sun, 05 Mar 2006 14:49:10 +0000
Subject: Sendmail won't send mails
In-Reply-To: <m3y7zphs7i.fsf@sl392.st-edmunds.cam.ac.uk>
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141567151.4233.26.camel@pmac.infradead.org>
	<m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141568885.4233.33.camel@pmac.infradead.org>
	<m3y7zphs7i.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <1141570150.10699.7.camel@animal.passback.co.uk>

On Sun, 2006-03-05 at 14:38 +0000, leon wrote:
> David Woodhouse <dwmw2 at infradead.org> writes:
> 
>  | On Sun, 2006-03-05 at 14:17 +0000, leon wrote:
>  | > Here is /var/log/maillog
>  | 
>  | Connection timed out when trying to contact any host outside cam.ac.uk.
>  | That's hardly surprising; the UCS started filtering outgoing port 25
>  | from undergrad machines (and indeed any machines not explictly
>  | permitted) about a decade ago.
>  | 
>  | Use a smarthost -- probably smtp.hermes.
>  | 
>  | -- 
>  | dwmw2
> Very informative. Thanks.
> 
> 1. Can I choose another port to workaround?
> 2. How to delete queue mails in /var/spool/mqueue:
>    ? rm -rf /var/spool/mqueue/*

That probably won't work, somewhere a firewall is preventing OUTBOUND
connections to port 25, this is a common practice these days.

What you need to do is:

1) Edit /etc/mail/sendmail.mc and uncomment line 22:

dnl define(`SMART_HOST',`smtp.your.provider')

by deleting "dnl".  Replace smtp.your.provider with the correct
smarthost for your network.

2) Stop and restart sendmail (as root):

	/sbin/service sendmail restart

All the mail in the queue should now be sent, this might take several
minutes, and future emails should work as well.

Keith.



From mblancom at gmail.com  Sun Mar  5 15:51:17 2006
From: mblancom at gmail.com (Miguel Blanco)
Date: Sun, 5 Mar 2006 16:51:17 +0100
Subject: problem mounting a jffs2 filesystem
Message-ID: <8766c4ce0603050751kc5b331fo@mail.gmail.com>

Hello,

 Trying to mount a jffs2 file system in my desktop PC:
 ...
 $ modprobe mtdram total_size=6144 erase_size=128
 $ modprobe mtdblock
 ...
 $ dd if=fw.wsw of=data.jffs2 ibs=1 obs=1M count=5888K skip=6292872
 $ jffs2dump -b -c -e data-le.jffs2 data.jffs2
 $ dd if=data-le.jffs2 of=/dev/mtdblock0
 $ mkdir data
 $ mount -t jffs2 /dev/mtdblock0 data

 I get a mount error:
    "2942 Violaci?n de segmento" (in spanish and "segment violation"
in english :-) )

 and dmesg says (relevant part I think):

 divide error: 0000 [#1]
 last sysfs file: /block/mtdblock0/dev
 Modules linked in: jffs2 zlib_deflate mtdblock mtd_blkdevs mtdram
mtdpart mtdcor e parport_pc lp parport autofs4 dm_mod video button
battery ac ipv6 ohci1394 iee e1394 uhci_hcd ehci_hcd i2c_i801 i2c_core
snd_intel8x0 snd_ac97_codec snd_ac97_b us snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_o ss snd_mixer_oss
snd_pcm snd_timer snd soundcore snd_page_alloc 8139cp 8139too m ii
floppy sr_mod ext3 jbd aic7xxx scsi_transport_spi sd_mod scsi_mod
 CPU:    0
 EIP:    0060:[<e118deef>]    Not tainted VLI
 EFLAGS: 00210246   (2.6.15-1.1830_FC4)
 EIP is at jffs2_scan_medium+0xdf/0x55e [jffs2]
 eax: 0000fff4   ebx: d2c5fa00   ecx: dffef180   edx: 00000000
 esi: d07d24e0   edi: d07d28d0   ebp: d3c98a80   esp: d0995d80
 ds: 007b   es: 007b   ss: 0068
 Process mount (pid: 2942, threadinfo=d0995000 task=d311b030)
 Stack: 00000000 d3c98a80 d0995da4 00000080 00000030 00000002 00000000 00000000
       00600000 e0b58000 d2c5fa00 00000030 d2c5fa00 00000000 e119107a d2c5fa00
       d3c98338 fffffff4 c0152c19 ffffffff e119611d 000000d0 00000000 d2c5fa00
 Call Trace:
 [<e119107a>] jffs2_build_filesystem+0x1a
/0x306 [jffs2]     [<c0152c19>] __vmall oc+0xf/0x13
 [<e119611d>] jffs2_sum_init+0x3d/0xbf [jffs2]     [<e1191609>]
jffs2_do_mount_f s+0x1cc/0x233 [jffs2]
 [<e119300c>] jffs2_do_fill_super+0xa8/0x1cb [jffs2]     [<e1193647>]
jffs2_sb_s et+0x0/0x1d [jffs2]
 [<e119385f>] jffs2_get_sb_mtd+0x1fb/0x22c [jffs2]     [<e11939b5>]
jffs2_get_sb +0xe7/0x192 [jffs2]
 [<c017502b>] alloc_vfsmnt+0x9b/0xc2     [<c0174f79>] get_fs_type+0x8d/0xa4
 [<c0161d29>] do_kern_mount+0xaf/0x147     [<c0176437>] do_new_mount+0x6b/0x90
 [<c0176a37>] do_mount+0x1b1/0x1cc     [<c01422e0>] __alloc_pages+0x57/0x2ed
 [<c017683d>] copy_mount_options+0x4d/0x96     [<c0176db4>] sys_mount+0x72/0xa4
 [<c0102e75>] syscall_call+0x7/0xb
 Code: 8b 93 b0 00 00 00 8b 42 18 01 43 7c 8b 43 78 2b 42 18 89 43 78
c7 42 18 00  00 00 00 8b b3 b0 00 00 00 85 f6 74 24 8b 46 20 31 d2
<f7> b3 84 01 00 00 85 d2  74 15 01 56 1c 01 53 7c 8b 83 b0 00 00
 Continuing in 1 seconds.
 <6>loop: loaded (max 8 devices)


 this is with Fedora 4 kernel 2.6.15-1.1830 (and later kernels).
2.6.14.1.1656 is OK!

 I know is a vendor kernel, but the 2.6.15 ChangeLog contains a lot of
changes related
 to mtd devices and jffs2 filesystems, so I think it could be a mainline bug.

 Let me know if you need more information.

 Thank you,
 Miguel.



From sdl.web at gmail.com  Sun Mar  5 16:06:05 2006
From: sdl.web at gmail.com (leon)
Date: Sun, 05 Mar 2006 16:06:05 +0000
Subject: Sendmail won't send mails
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141567151.4233.26.camel@pmac.infradead.org>
	<m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141568885.4233.33.camel@pmac.infradead.org>
	<m3y7zphs7i.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141570150.10699.7.camel@animal.passback.co.uk>
Message-ID: <m3hd6cj2qa.fsf@sl392.st-edmunds.cam.ac.uk>

Keith Sharp <kms at passback.co.uk> writes:

 | On Sun, 2006-03-05 at 14:38 +0000, leon wrote:
 | > David Woodhouse <dwmw2 at infradead.org> writes:
 | > 
 | >  | On Sun, 2006-03-05 at 14:17 +0000, leon wrote:
 | >  | > Here is /var/log/maillog
 | >  | 
 | >  | Connection timed out when trying to contact any host outside cam.ac.uk.
 | >  | That's hardly surprising; the UCS started filtering outgoing port 25
 | >  | from undergrad machines (and indeed any machines not explictly
 | >  | permitted) about a decade ago.
 | >  | 
 | >  | Use a smarthost -- probably smtp.hermes.
 | >  | 
 | >  | -- 
 | >  | dwmw2
 | > Very informative. Thanks.
 | > 
 | > 1. Can I choose another port to workaround?
 | > 2. How to delete queue mails in /var/spool/mqueue:
 | >    ? rm -rf /var/spool/mqueue/*
 | 
 | That probably won't work, somewhere a firewall is preventing OUTBOUND
 | connections to port 25, this is a common practice these days.
 | 
 | What you need to do is:
 | 
 | 1) Edit /etc/mail/sendmail.mc and uncomment line 22:
 | 
 | dnl define(`SMART_HOST',`smtp.your.provider')
 | 
 | by deleting "dnl".  Replace smtp.your.provider with the correct
 | smarthost for your network.
 | 
 | 2) Stop and restart sendmail (as root):
 | 
 | 	/sbin/service sendmail restart
 | 
 | All the mail in the queue should now be sent, this might take several
 | minutes, and future emails should work as well.
 | 
 | Keith.
Problem solved.
Many thanks.
-- 
Leon



From sdl.web at gmail.com  Sun Mar  5 16:15:24 2006
From: sdl.web at gmail.com (leon)
Date: Sun, 05 Mar 2006 16:15:24 +0000
Subject: messy desktop icons when first log in
Message-ID: <m3d5h0j2ar.fsf@sl392.st-edmunds.cam.ac.uk>

Hi all,

I'm not sure if this happens in you box too. It happens in my laptop
all the way from test1. Since the release date is drawn near, I would
like this bug to be closed if it is a bug.

I have reported it here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183939

The problem is when I first log in gnome, the icons on the desktop are
not tidily arranged. Then I do a 'Clean Up by Name' from the right
click on the desktop. However, the icons get messed up in next
login. Any one has the same experience?

Thank you all! 
-- 
Leon



From emeric.maschino at jouy.inra.fr  Sun Mar  5 18:02:15 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Sun,  5 Mar 2006 19:02:15 +0100
Subject: Sluggish window moving with EXA acceleration
Message-ID: <1141581735.440b27a7300ef@www.jouy.inra.fr>

Hi,

Quickly moving windows on my GNOME desktop isn't fluent with the EXA
acceleration although the old XAA acceleration performs normally. Is there
anybody out there experiencing the same issue? This is on an Itanium
workstation sporting an AGP ATI FireGL X1 graphics adapter (R300 chipset). I
didn't add any tweaking option to my xorg.conf file except for AccelMethod when
using EXA.

Cheers,

    ?meric



From otaylor at redhat.com  Sun Mar  5 15:30:58 2006
From: otaylor at redhat.com (Owen Taylor)
Date: Sun, 05 Mar 2006 10:30:58 -0500
Subject: dropdown menu's
In-Reply-To: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
Message-ID: <1141572658.22406.0.camel@huygens.localdomain>

On Sun, 2006-03-05 at 00:37 +0100, Erwin Rol wrote:
> Hey all,
> 
> This is something that already bothers me a while, i think it never
> really worked as expected, but i am not sure if it is a "my machine
> only" kind of problem.
> 
> Dropdown menu's that don't fit on the screen are not displayed
> correctly. For example take the gimp file-open dialog. When you move the
> dialog to the bottom border of the screen, and press the "All Files"
> dropdown menu, the menu will open, and the bottom of the menu will be
> aligned with the bottom of the screen, the top of the menu will be
> somewhere mid screen. But the first entry will be at the location of the
> position of the dropdown box, and so everything above that position is
> empty. I tried to make a screenshot, but that didn't work with the
> dropdown box open, i suggest to just try it. Since it happens with every
> GTK application, it smells like an GTK issue.

Discussion, links, etc.:

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

Regards,
						Owen




From gtwilliams at gmail.com  Sun Mar  5 19:28:09 2006
From: gtwilliams at gmail.com (Garry Williams)
Date: Sun, 05 Mar 2006 14:28:09 -0500
Subject: Sendmail won't send mails
In-Reply-To: <1141570150.10699.7.camel@animal.passback.co.uk>
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>
	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141567151.4233.26.camel@pmac.infradead.org>
	<m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141568885.4233.33.camel@pmac.infradead.org>
	<m3y7zphs7i.fsf@sl392.st-edmunds.cam.ac.uk>
	<1141570150.10699.7.camel@animal.passback.co.uk>
Message-ID: <1141586889.25335.11.camel@localhost>

On Sun, 2006-03-05 at 14:49 +0000, Keith Sharp wrote:
> On Sun, 2006-03-05 at 14:38 +0000, leon wrote:
> > David Woodhouse <dwmw2 at infradead.org> writes:
> > 
> What you need to do is:
> 
> 1) Edit /etc/mail/sendmail.mc and uncomment line 22:
> 
> dnl define(`SMART_HOST',`smtp.your.provider')

Some providers require that host name to specified in square brackets.
(Bellsouth.net is an example.)

Sendmail will look up the MX for that host and relay to *that* MX host,
if the host name is not inside square brackets.  If the MX isn't the
host that they want you to relay through, the mail will be rejected, if
the recipient is outside the ISP.

-- 
Garry Williams -- +1 (678) 656-4579



From mailinglists at erwinrol.com  Sun Mar  5 20:20:48 2006
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Sun, 05 Mar 2006 21:20:48 +0100
Subject: kdevelop crash
Message-ID: <1141590049.5468.100.camel@xpc.home.erwinrol.com>

I just had (one of many) kdevelop crashes, below a stacktrace from the kcrash dialog. 

Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47959183098960 (LWP 19430)]
[New Thread 1084229968 (LWP 19454)]
[KCrash handler]
#5  0x000000327d93b744 in QListViewItem::takeItem ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#6  0x000000327e1037e9 in KListViewItem::takeItem ()
   from /usr/lib64/libkdeui.so.4
#7  0x000000327d9486a2 in QListViewItem::~QListViewItem$base ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#8  0x00002b9e653cdd3e in ~VariableDomBrowserItem (this=0x30a9700)
    at classviewwidget.h:109
#9  0x00002b9e653c3bdc in FolderBrowserItem::processVariable (this=0x3920350, 
    var=@0x7fffffc48490, remove=true) at classviewwidget.cpp:489
#10 0x00002b9e653c83e4 in FolderBrowserItem::processFile (this=0x3920350, 
    file=@0x7fffffc48680, path=) at classviewwidget.cpp:326
#11 0x00002b9e653c8b48 in ClassViewWidget::removeFile (this=0x23df1a0, 
    fileName=) at classviewwidget.cpp:245
#12 0x00002b9e653c95a4 in ClassViewWidget::qt_invoke (this=0x23df1a0, 
    _id=116, _o=0x7fffffc487c0) at classviewwidget.moc:138
#13 0x000000327d85d009 in QObject::activate_signal ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#14 0x000000327d85d639 in QObject::activate_signal ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#15 0x000000327f2363a8 in KDevLanguageSupport::aboutToRemoveSourceInfo (
    this=0x251e2f0, t0=) at kdevlanguagesupport.moc:140
#16 0x00002b9e641f448b in CppSupportPart::removeWithReferences (
    this=0x251e2f0, fileName=@0x7fffffc48940) at cppsupportpart.cpp:1562
#17 0x00002b9e641f4613 in CppSupportPart::recomputeCodeModel (this=0x251e2f0, 
    fileName=@0x7fffffc48940) at cppsupportpart.cpp:1767
#18 0x00002b9e641f6c06 in CppSupportPart::customEvent (this=0x251e2f0, ev=)
    at cppsupportpart.cpp:305
#19 0x000000327d85c5a6 in QObject::event ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#20 0x000000327d7fc935 in QApplication::internalNotify ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#21 0x000000327d7fde14 in QApplication::notify ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#22 0x000000327cde1e78 in KApplication::notify ()
   from /usr/lib64/libkdecore.so.4
#23 0x000000327d7fd949 in QApplication::sendPostedEvents ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#24 0x000000327d7aba4a in QEventLoop::processEvents ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#25 0x000000327d8141e1 in QEventLoop::enterLoop ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#26 0x000000327d8140ba in QEventLoop::exec ()
   from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#27 0x000000000040736e in main (argc=) at main.cpp:145
#28 0x000000327921d084 in __libc_start_main (main=0x406ba0 <main>, argc=3, 
    ubp_av=0x7fffffc49348, init=) at libc-start.c:231
#29 0x0000000000406b09 in _start ()
#30 0x00007fffffc49338 in ?? ()
#31 0x0000000000000000 in ?? ()
Current language:  auto; currently c




From sdl.web at gmail.com  Sun Mar  5 20:28:40 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 20:28:40 +0000
Subject: other annoyances before fc5
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<1141553990.6034.1.camel@rousalka.dyndns.org>
Message-ID: <m2hd6c1vrb.fsf@sl392.st-edmunds.cam.ac.uk>

Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:

> The worst annoyance right now is the gnome panel not being closed on
> logout, as a result gnome-session refuses to create a panel on login.
>
> I don't know if a non-technical user will be able to cope with this,
> unless he reboots on each logout.
>
> -- 
> Nicolas Mailhot

I have exact the same problem.

-- 
Leon



From sdl.web at gmail.com  Sun Mar  5 20:30:28 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 20:30:28 +0000
Subject: other annoyances before fc5
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
Message-ID: <m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>

Andy Burns <fedora at adslpipe.co.uk> writes:

> Vitor Domingos wrote:
>
>> what's the status for suspend/hibernate on FC5, specially on ATI Radeon cards ?
>
> If video isn't re-enabled after resume, I found that switching VTs
> revived it, i.e. press CTRL-ALT-F1 to force card to text console, then
> ALT-F7 to go back to X console, at which point my monitor comes out of
> DPMS sleep :-)

Doesn't work here:( I have to push the poweroff button.

-- 
Leon



From selinux at gmail.com  Sun Mar  5 20:44:23 2006
From: selinux at gmail.com (Tom London)
Date: Sun, 5 Mar 2006 12:44:23 -0800
Subject: other annoyances before fc5
In-Reply-To: <m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>

I 'made it work' on my Thinkpad X41 by patching /etc/pm/functions-intel.

I'm sure this is not really right, but it makes it work.

I'm tracking down a problem with 'vbetool post' now.....

tom

--- function-intel.save 2006-03-05 10:45:49.000000000 -0800
+++ functions-intel     2006-03-05 10:40:55.000000000 -0800
@@ -13,8 +13,9 @@
 resume_video()
 {
 (
-       /usr/sbin/vbetool post
-       /usr/sbin/vbetool vbestate restore < /var/run/vbestate
+#      /usr/sbin/vbetool post
+#      /usr/sbin/vbetool vbestate restore < /var/run/vbestate
+       /usr/sbin/vbetool dpms on
 ) >/dev/null 2>&1
 }



From sdl.web at gmail.com  Sun Mar  5 21:08:14 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 21:08:14 +0000
Subject: other annoyances before fc5
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>
Message-ID: <m2oe0kzjk1.fsf@sl392.st-edmunds.cam.ac.uk>

Thank you for this.

Why you think it is not right? Feel worried to adapt this change.

"Tom London" <selinux at gmail.com> writes:

> I 'made it work' on my Thinkpad X41 by patching /etc/pm/functions-intel.
>
> I'm sure this is not really right, but it makes it work.
>
> I'm tracking down a problem with 'vbetool post' now.....
>
> tom
>
> --- function-intel.save 2006-03-05 10:45:49.000000000 -0800
> +++ functions-intel     2006-03-05 10:40:55.000000000 -0800
> @@ -13,8 +13,9 @@
>  resume_video()
>  {
>  (
> -       /usr/sbin/vbetool post
> -       /usr/sbin/vbetool vbestate restore < /var/run/vbestate
> +#      /usr/sbin/vbetool post
> +#      /usr/sbin/vbetool vbestate restore < /var/run/vbestate
> +       /usr/sbin/vbetool dpms on
>  ) >/dev/null 2>&1
>  }

-- 
Leon



From vd at paradigma.pt  Sun Mar  5 21:20:04 2006
From: vd at paradigma.pt (Vitor Domingos)
Date: Sun, 05 Mar 2006 21:20:04 +0000
Subject: other annoyances before fc5
In-Reply-To: <4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>
References: <duci8r$9si$1@sea.gmane.org>	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>	<440AA731.7020302@adslpipe.co.uk>	<m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>
Message-ID: <440B5604.8000701@paradigma.pt>

BTW, the USB module never wakes up too...

//VD

Tom London wrote:
> I 'made it work' on my Thinkpad X41 by patching /etc/pm/functions-intel.
> 
> I'm sure this is not really right, but it makes it work.
> 
> I'm tracking down a problem with 'vbetool post' now.....
> 
> tom
> 
> --- function-intel.save 2006-03-05 10:45:49.000000000 -0800
> +++ functions-intel     2006-03-05 10:40:55.000000000 -0800
> @@ -13,8 +13,9 @@
>  resume_video()
>  {
>  (
> -       /usr/sbin/vbetool post
> -       /usr/sbin/vbetool vbestate restore < /var/run/vbestate
> +#      /usr/sbin/vbetool post
> +#      /usr/sbin/vbetool vbestate restore < /var/run/vbestate
> +       /usr/sbin/vbetool dpms on
>  ) >/dev/null 2>&1
>  }
> 



From sdl.web at gmail.com  Sun Mar  5 21:13:24 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 21:13:24 +0000
Subject: where is ~/.xsession-errors?
Message-ID: <m2k6b8zjbf.fsf@sl392.st-edmunds.cam.ac.uk>

Hi all,

There is no ~/.xsession-errors or the like in my home dir. Any ideas?

-- 
Leon



From selinux at gmail.com  Sun Mar  5 21:37:05 2006
From: selinux at gmail.com (Tom London)
Date: Sun, 5 Mar 2006 13:37:05 -0800
Subject: other annoyances before fc5
In-Reply-To: <m2oe0kzjk1.fsf@sl392.st-edmunds.cam.ac.uk>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>
	<m2oe0kzjk1.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <4c4ba1530603051337ra8b812ci236a46f5acde155c@mail.gmail.com>

On 3/5/06, Leon <sdl.web at gmail.com> wrote:
> Thank you for this.
>
> Why you think it is not right? Feel worried to adapt this change.
>
> Leon
I'm guessing that some Intel graphics chips may need more than this...

I've added to an existing bugzilla on this, and created one for the
issue with vbetool:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184033
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184066

tom
--
Tom London



From sdl.web at gmail.com  Sun Mar  5 22:11:10 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 22:11:10 +0000
Subject: other annoyances before fc5
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>
	<m2oe0kzjk1.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051337ra8b812ci236a46f5acde155c@mail.gmail.com>
Message-ID: <m2hd6cr18h.fsf@sl392.st-edmunds.cam.ac.uk>

Just noticed that /etc/sysconfig/pm has the following:
HIBERNATE_RESUME_POST_VIDEO="no"

Maybe set it to "yes" will help.

"Tom London" <selinux at gmail.com> writes:

> On 3/5/06, Leon <sdl.web at gmail.com> wrote:
>> Thank you for this.
>>
>> Why you think it is not right? Feel worried to adapt this change.
>>
>> Leon
> I'm guessing that some Intel graphics chips may need more than this...
>
> I've added to an existing bugzilla on this, and created one for the
> issue with vbetool:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184033
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184066
>
> tom
> --
> Tom London

-- 
Leon



From nutello at sweetness.com  Sun Mar  5 22:26:50 2006
From: nutello at sweetness.com (Rudi Chiarito)
Date: Sun, 5 Mar 2006 23:26:50 +0100
Subject: where is ~/.xsession-errors?
In-Reply-To: <m2k6b8zjbf.fsf@sl392.st-edmunds.cam.ac.uk>
References: <m2k6b8zjbf.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <20060305222650.GB28409@plain.rackshack.net>

On Sun, Mar 05, 2006 at 09:13:24PM +0000, Leon wrote:
> There is no ~/.xsession-errors or the like in my home dir. Any ideas?

Look for /tmp/xses-USERNAME.RANDOM

-- 
Rudi



From sdl.web at gmail.com  Sun Mar  5 22:37:05 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 22:37:05 +0000
Subject: where is ~/.xsession-errors?
References: <m2k6b8zjbf.fsf@sl392.st-edmunds.cam.ac.uk>
	<20060305222650.GB28409@plain.rackshack.net>
Message-ID: <m264msr01a.fsf@sl392.st-edmunds.cam.ac.uk>

Rudi Chiarito <nutello at sweetness.com> writes:

> On Sun, Mar 05, 2006 at 09:13:24PM +0000, Leon wrote:
>> There is no ~/.xsession-errors or the like in my home dir. Any ideas?
>
> Look for /tmp/xses-USERNAME.RANDOM
>
> -- 
> Rudi

Thank you. 

By the way, any clue why such a change?

-- 
Leon



From selinux at gmail.com  Sun Mar  5 22:39:14 2006
From: selinux at gmail.com (Tom London)
Date: Sun, 5 Mar 2006 14:39:14 -0800
Subject: other annoyances before fc5
In-Reply-To: <m2hd6cr18h.fsf@sl392.st-edmunds.cam.ac.uk>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>
	<m2oe0kzjk1.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051337ra8b812ci236a46f5acde155c@mail.gmail.com>
	<m2hd6cr18h.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <4c4ba1530603051439q45c1f6c5wa13211f9d1008477@mail.gmail.com>

On 3/5/06, Leon <sdl.web at gmail.com> wrote:
> Just noticed that /etc/sysconfig/pm has the following:
> HIBERNATE_RESUME_POST_VIDEO="no"
>
> Maybe set it to "yes" will help.
>
> Leon
>
Don't think so.  /etc/pm/hooks/20video has:

case "$1" in
        suspend)
                suspend_video
                ;;
        resume)
                if [ "x$PM_MODE" != "hibernate" -o \
                     "x$HIBERNATE_RESUME_POST_VIDEO" == "xyes" ]; then
                        resume_video
                fi

Since PM_MODE should not be "hibernate", there will be no check of
HIBERNATE_RESUME_POST_VIDEO. In any case, resume_video is being
called.

tom
--
Tom London



From sdl.web at gmail.com  Sun Mar  5 22:50:01 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 22:50:01 +0000
Subject: other annoyances before fc5
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<m2d5h01vob.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051244w6965b41tca3ec036f43e216a@mail.gmail.com>
	<m2oe0kzjk1.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051337ra8b812ci236a46f5acde155c@mail.gmail.com>
	<m2hd6cr18h.fsf@sl392.st-edmunds.cam.ac.uk>
	<4c4ba1530603051439q45c1f6c5wa13211f9d1008477@mail.gmail.com>
Message-ID: <m21wxgqzfq.fsf@sl392.st-edmunds.cam.ac.uk>

"Tom London" <selinux at gmail.com> writes:

> On 3/5/06, Leon <sdl.web at gmail.com> wrote:
>> Just noticed that /etc/sysconfig/pm has the following:
>> HIBERNATE_RESUME_POST_VIDEO="no"
>>
>> Maybe set it to "yes" will help.
>>
>> Leon
>>
> Don't think so.  /etc/pm/hooks/20video has:
>
> case "$1" in
>         suspend)
>                 suspend_video
>                 ;;
>         resume)
>                 if [ "x$PM_MODE" != "hibernate" -o \
>                      "x$HIBERNATE_RESUME_POST_VIDEO" == "xyes" ]; then
>                         resume_video
>                 fi
>
> Since PM_MODE should not be "hibernate", there will be no check of
> HIBERNATE_RESUME_POST_VIDEO. In any case, resume_video is being
> called.
>
> tom
> --
> Tom London

I think this is an important issue and should get fixed for the final
release. If only the packager of pm_utils could read this thread and
speed up the work on hibernation/suspension! Time's pressing.

-- 
Leon
Fedora core 5



From sdl.web at gmail.com  Sun Mar  5 23:02:55 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 05 Mar 2006 23:02:55 +0000
Subject: xdvi warning?
Message-ID: <m2oe0kpk9s.fsf@sl392.st-edmunds.cam.ac.uk>

Hi all,

When opening dvi files, xdvi keeps warning:

   Couldn't allocate enough colors - expect low display quality.

Is there something wrong with my X?

-- 
Leon



From nman64 at n-man.com  Sun Mar  5 23:37:42 2006
From: nman64 at n-man.com (Patrick Barnes)
Date: Sun, 5 Mar 2006 17:37:42 -0600
Subject: xdvi warning?
In-Reply-To: <m2oe0kpk9s.fsf@sl392.st-edmunds.cam.ac.uk>
References: <m2oe0kpk9s.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <200603051737.45777.nman64@n-man.com>

On Sunday 05 March 2006 17:02, Leon wrote:
> Hi all,
>
> When opening dvi files, xdvi keeps warning:
>
>    Couldn't allocate enough colors - expect low display quality.
>
> Is there something wrong with my X?
>
> --
> Leon

Your post is off-topic for this list.  Please see fedora-list at redhat.com 
instead.

https://www.redhat.com/mailman/listinfo/fedora-list
http://fedoraproject.org/wiki/PostIsOffTopic

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

http://www.n-man.com/

Have I been helpful?  Rate my assistance!
http://rate.affero.net/nman64/
-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060305/075dacef/attachment.sig>

From wtogami at redhat.com  Mon Mar  6 00:29:40 2006
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 05 Mar 2006 19:29:40 -0500
Subject: Sendmail won't send mails
In-Reply-To: <m3y7zphs7i.fsf@sl392.st-edmunds.cam.ac.uk>
References: <m3bqwlj9cv.fsf@sl392.st-edmunds.cam.ac.uk>	<m37j79j8ya.fsf@sl392.st-edmunds.cam.ac.uk>	<1141567151.4233.26.camel@pmac.infradead.org>	<m33bhxj7r5.fsf@sl392.st-edmunds.cam.ac.uk>	<1141568885.4233.33.camel@pmac.infradead.org>
	<m3y7zphs7i.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <440B8274.1060806@redhat.com>

leon wrote:
> David Woodhouse <dwmw2 at infradead.org> writes:
> 
>  | On Sun, 2006-03-05 at 14:17 +0000, leon wrote:
>  | > Here is /var/log/maillog
>  | 
>  | Connection timed out when trying to contact any host outside cam.ac.uk.
>  | That's hardly surprising; the UCS started filtering outgoing port 25
>  | from undergrad machines (and indeed any machines not explictly
>  | permitted) about a decade ago.
>  | 
>  | Use a smarthost -- probably smtp.hermes.
>  | 
>  | -- 
>  | dwmw2
> Very informative. Thanks.
> 
> 1. Can I choose another port to workaround?
> 2. How to delete queue mails in /var/spool/mqueue:
>    ? rm -rf /var/spool/mqueue/*
> 
> Thanks again.

Please be aware that Fedora-devel list is a development discussion list. 
Your issue here is a user configuration and network support issue that 
would be best discussed in a user community, and is off-topic for this 
list.  In the future, please bring your issue to communities like 
fedoraforum.org or fedora-list before escalating them to development 
groups like this or bugzilla.

Thank you,
Warren Togami
wtogami at redhat.com



From rc040203 at freenet.de  Mon Mar  6 05:02:05 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 06 Mar 2006 06:02:05 +0100
Subject: rawhide report: 20060304 changes
In-Reply-To: <44095BDB.6030700@mharris.ca>
References: <200603040819.k248JDps030282@porkchop.devel.redhat.com>
	<1141461578.5203.49.camel@mccallum.corsepiu.local>
	<44095BDB.6030700@mharris.ca>
Message-ID: <1141621326.5228.7.camel@mccallum.corsepiu.local>

On Sat, 2006-03-04 at 04:20 -0500, Mike A. Harris wrote:
> Ralf Corsepius wrote:
> > On Sat, 2006-03-04 at 03:19 -0500, Build System wrote:
> > 
> > 
> >>xorg-x11-xbitmaps-1.0.1-3
> >>-------------------------
> >>* Thu Mar 02 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
> >>- Made package arch specific due to pkgconfig files being placed in lib64
> >>  if the noarch packages manage to get built on x86_64/ppc64/s390x.
> > 
> > 
> > What?
> > 
> > Fix the toplevel Makefile.am to install the pkgconfig file to $datadir
> > instead of libdir:
> > 
> > -pkgconfigdir = $(libdir)/pkgconfig
> > +pkgconfigdir = $(datadir)/pkgconfig
> > 
> > That's what other noarch packages do.
> > 
> > 
> > Alternatively, fix your spec to use
> > 
> > %configure --libdir=%_datadir
> > ...
> > %_datadir/share/pkgconfig/*.pc
> 
> For now, the important thing is that FC5 is in a state that everything
> builds, and is ready for final release.  Minor trivia like this is not
> mission critical to the release of the OS.
>
> Feel free to submit a patch to X.Org to do this, so it is fixed in
> the future.

It's always great having to experience the "warm feeling" your responses
emit and having to experience your attempts on pushing people around,
instead of fixing bugs you are responsible for yourself.

Even the time you invested to reply my remark exceeds the time it would
have taken you to fix your spec-file. 

Ralf




From naoki at valuecommerce.com  Mon Mar  6 08:13:17 2006
From: naoki at valuecommerce.com (Naoki)
Date: Mon, 06 Mar 2006 17:13:17 +0900
Subject: 2.6.15-1.2009.4.2_FC5hypervisor + xen startup issue.
Message-ID: <1141632797.2519.4.camel@dragon.sys.intra>

Howdy,

Anybody else seeing this with the latest kernel?

# xm list
Error: Error connecting to xend: Connection refused.  Is xend running?
# ps -ef|grep xen
root        12    11  0 17:02 ?        00:00:00 [xenwatch]
root        13    11  0 17:02 ?        00:00:00 [xenbus]
root      1953     1  0 17:03 ?        00:00:00 python /usr/sbin/xend
start
root      1954  1953  0 17:03 ?        00:00:00 python /usr/sbin/xend
start
root      2685  2656  0 17:10 pts/3    00:00:00 grep xen

>From the log :
[2006-03-06 17:03:34 xend] INFO (SrvDaemon:278) Xend Daemon started
[2006-03-06 17:03:34 xend] INFO (SrvDaemon:282) Xend changeset:
unavailable .
[2006-03-06 17:03:34 xend] ERROR (SrvDaemon:292) Exception starting xend
((111, 'Connection refused'))
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line 286, in run
    servers = SrvServer.create()
  File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvServer.py",
line 106, in create
    root.putChild('xend', SrvRoot())
  File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvRoot.py",
line 40, in __init__
    self.get(name)
  File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 82, in
get
    val = val.getobj()
  File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 52, in
getobj
    self.obj = klassobj()
  File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line
39, in __init__
    self.xd = XendDomain.instance()
  File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
550, in instance
    inst.init()
  File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
70, in init
    xstransact.Mkdir(VMROOT)
  File
"/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
317, in Mkdir
    complete(path, lambda t: t.mkdir(*args))
  File
"/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
323, in complete
    t = xstransact(path)
  File
"/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
20, in __init__
    self.transaction = xshandle().transaction_start()
  File "/usr/lib/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
line 18, in xshandle
    xs_handle = xen.lowlevel.xs.xs()
RuntimeError: (111, 'Connection refused')



No doubt unrelated but with this kernel on boot S05kudzu throws a "line
23 segfault" error which does not occur with the normal SMP kernel. Line
23 in that script is simply a case statement though.



From buildsys at redhat.com  Mon Mar  6 08:17:14 2006
From: buildsys at redhat.com (Build System)
Date: Mon, 6 Mar 2006 03:17:14 -0500
Subject: rawhide report: 20060306 changes
Message-ID: <200603060817.k268HEmI032188@porkchop.devel.redhat.com>

 

 
Updated Packages:

gcc-4.1.0-2
-----------
* Sat Mar 04 2006 Jakub Jelinek <jakub at redhat.com> 4.1.0-2
- update from -gcc-4_1-branch (-r111570:111697)
  - PRs c++/26291, libgfortran/26136, libgfortran/26423, libgfortran/26464,
	libstdc++/26526, rtl-optimization/26345, target/19061, target/26453
- handle DW_CFA_val_{offset,offset_sf,expression} in the libgcc{,_s} unwinder

gphoto2-2.1.99-7
----------------
* Fri Mar 03 2006 Radek Vok??l <rvokal at redhat.com> 2.1.99-7
- remove .la files (#183367)

* Thu Mar 02 2006 Ray Strode <rstrode at redhat.com> 2.1.99-6
- potentially work around bug 183371 by looping/checking for
  5 seconds.

* Wed Mar 01 2006 Radek Vok??l <rvokal at redhat.com> 2.1.99-5.4
- spec file tweak, become self-building again

rhythmbox-0.9.3.1-2
-------------------
* Fri Mar 03 2006 Ray Strode <rstrode at redhat.com> - 0.9.3.1-2
- add patch from James "Doc" Livingston to stop a hang
  for new users (bug 183883)

wpa_supplicant-1:0.4.8-5
------------------------
* Fri Mar 03 2006 Dan Williams <dcbw at redhat.com> - 0.4.8-5
- Increase association timeout, mainly for drivers that don't
	fully support WPA ioctls yet

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	gnome-volume-manager - 1.5.13-3.ia64 requires kernel >= 0:2.6
	pcmciautils - 011-1.2.ia64 requires kernel >= 0:2.6.12-1.1411_FC5
	rgmanager - 1.9.31-3.ia64 requires ccs
	systemtap - 0.5.4-2.2.ia64 requires kernel >= 0:2.6.9-11






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_4fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_2fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_1fc.1.1.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_7fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_4fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_2fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_3fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_8fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From che666 at gmail.com  Mon Mar  6 09:04:50 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 6 Mar 2006 10:04:50 +0100
Subject: other annoyances before fc5
In-Reply-To: <1141510398.2730.1.camel@ender>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
Message-ID: <e99d27470603060104v1d4212dcv@mail.gmail.com>

2006/3/4, Jesse Keating <jkeating at redhat.com>:
> On Sat, 2006-03-04 at 21:09 +0000, Vitor Domingos wrote:
> > Btw, what's the status for suspend/hibernate on FC5, specially on ATI Radeon cards ?
> > I'm on rawhide (with tuesday updates) and it still doesnt resumes Xorg properlly.
>
> My T42 laptop works great with its radeon mobility chip.
>
> Two things:  I have acpi_serialize as a kernel arg in grub, and I have
> radeonfb uncommented in /etc/modprobe.d/blacklist.  Also I have options
> radeonfb radeon_force_sleep=1 in /etc/modprob.conf.  Suspend and
> hibernate work great.

i got a thinkpad r51 and suspend and hibernate also works great (with
acpitool -S and acpitool -s). ati mobility resumes without problems. i
have radeonfb turned on actually too.

regards,
rudolf kastl

>
> --
> Jesse Keating
> Release Engineer: Fedora
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (GNU/Linux)
>
> iD8DBQBEChD+4v2HLvE71NURAmcxAJwLv1jLkfuN9uRLU7UZ5wtopuMQKwCfb3qU
> c7Rl047lvGzl5RsKeFgbM/k=
> =hpcJ
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Mon Mar  6 10:00:55 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Mon, 6 Mar 2006 11:00:55 +0100
Subject: SD/MMC Support (was Re: Hotplug: no more fstab entries)
In-Reply-To: <1141333979.2793.7.camel@localhost.localdomain>
References: <20060222153244.002ea18c@dhcp05.addix.net>
	<43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca>
	<604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com>
	<20060223103910.2d9874ae@dhcp05.addix.net>
	<1140698854.3633.1.camel@daxter.boston.redhat.com>
	<20060223141925.5a085d71@dhcp05.addix.net>
	<1140701508.3633.9.camel@daxter.boston.redhat.com>
	<1141333979.2793.7.camel@localhost.localdomain>
Message-ID: <20060306110055.2d506a15@python2>

Rodd Clarkson wrote :

> Would you like to explain to the masses (or maybe just me) how you got
> SD/MMC support working in Fedora.
> 
> I notice that 'modprobe mmc_block' now installs the modules needed, but
> beyond this it's not doing anything.
> 
> Doesn't notice the insertion of cards into the reader (which lspci
> reports as a):
> 
> 03:01.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)
> 
> Nothing shows up in /dev
> 
> Nothing mounts, that's for certain.
> 
> This isn't the plug N play I'm getting used to in Fedora, so what do I
> need to do.  It would be great to have support for SD/MMC in FC5 and it
> certainly looks like we're close.

Well, these might be separate issues, as many USB connected SD/MMC readers
work by default (only with unencrypted media, I guess), whereas the device
you list reminds me a lot of the internal reader I have in my Dell X1
laptop, which simply doesn't work with Linux, from the lack of a device
driver... it's a quite different device (PCI connected, not USB).

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4
Load : 0.34 0.35 0.34



From pertusus at free.fr  Mon Mar  6 11:01:59 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 6 Mar 2006 12:01:59 +0100
Subject: acpi command line client in core?
Message-ID: <20060306110159.GC3002@free.fr>

Hello,

It seems to me that there is no command line acpi client in fedora core.
If I'm not wrong, maybe acpitool (that I packaged in extras) could be moved 
to core? It has more functionalities than the other client I found, acpi
(that I've just submitted to extras).

--
Pat



From vonbrand at inf.utfsm.cl  Sun Mar  5 22:26:48 2006
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Sun, 05 Mar 2006 19:26:48 -0300
Subject: other annoyances before fc5 
In-Reply-To: Your message of "Sun, 05 Mar 2006 13:11:25 +0200."
	<1141557085.8109.9.camel@gilboa-work-dev> 
Message-ID: <200603052226.k25MQmoD021080@laptop11.inf.utfsm.cl>

Gilboa Davara <gilboad at gmail.com> wrote:
> On Sun, 2006-03-05 at 16:12 +0530, Rahul Sundaram wrote:
> > Nicolas Mailhot wrote:
> > 
> > >The worst annoyance right now is the gnome panel not being closed on
> > >logout, as a result gnome-session refuses to create a panel on login.
> > >
> > >I don't know if a non-technical user will be able to cope with this,
> > >unless he reboots on each logout.

> > Do you have a bug report on this? It works fine on my rawhide system 
> > with all the updates.

> Saw the same under FC5T3.
> Log off, Log on, all panels crash; Check process list, all old panels
> remain active.
> I couldn't reproduce it, so I decided against BZ'ing it.

I've seen stuff like this if you update some pieces of Gnome from a Gnome
session, but not otherwise. Didn't think much about it, and didn't note any
details, sorry.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From alan at redhat.com  Mon Mar  6 13:09:16 2006
From: alan at redhat.com (Alan Cox)
Date: Mon, 6 Mar 2006 08:09:16 -0500
Subject: other annoyances before fc5
In-Reply-To: <1141514386.2110.4.camel@localhost.localdomain>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<1141510398.2730.1.camel@ender>
	<4c4ba1530603041437k3c1d3163h55dcc5030aca829@mail.gmail.com>
	<1141514386.2110.4.camel@localhost.localdomain>
Message-ID: <20060306130916.GB22313@devserv.devel.redhat.com>

On Sat, Mar 04, 2006 at 06:19:45PM -0500, Tambet Ingo wrote:
> Mar  4 18:05:51 localhost kernel: hda: dma_intr: status=0x51
> { DriveReady SeekComplete Error }
> Mar  4 18:05:51 localhost kernel: hda: dma_intr: error=0x10
> { SectorIdNotFound }, LBAsect=75563541, sector=75563541

This is a known problem with the suspend support. The Linux kernel removes
the HPA clipping, the resume code doesn't re-do this when the BIOS puts it
back on resume.

Upstream work is in progress on ACPI restore support for ata



From clumens at redhat.com  Mon Mar  6 14:54:12 2006
From: clumens at redhat.com (Chris Lumens)
Date: Mon, 6 Mar 2006 09:54:12 -0500
Subject: is system-config-keyboard still necessary?
In-Reply-To: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>
References: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>
Message-ID: <20060306145411.GE28157@exeter.boston.redhat.com>

> On my system with system-config-keyboard-1.2.7-1.1
> If I run in Gnome the System --> Administration --> Keyboard tool, it
> gives absolutely nothing: only an empty window with title "Keyboard" and
> inside a keyboard-key icon with the text "select the appropriate
> keyboard for the system".

This was a bug in firstboot (strangely enough) that's fixed in Rawhide
now.

- Chris



From david at fubar.dk  Mon Mar  6 15:42:38 2006
From: david at fubar.dk (David Zeuthen)
Date: Mon, 06 Mar 2006 10:42:38 -0500
Subject: acpi command line client in core?
In-Reply-To: <20060306110159.GC3002@free.fr>
References: <20060306110159.GC3002@free.fr>
Message-ID: <1141659758.2170.4.camel@daxter.boston.redhat.com>

On Mon, 2006-03-06 at 12:01 +0100, Patrice Dumas wrote:
> Hello,
> 
> It seems to me that there is no command line acpi client in fedora core.
> If I'm not wrong, maybe acpitool (that I packaged in extras) could be moved 
> to core? It has more functionalities than the other client I found, acpi
> (that I've just submitted to extras).

Things like hal / gnome-power-manager right now works well for the core
distribution (some day we'll even get rid of acpid) so I'm not sure why
acpitool (which admittedly may be useful for admins / expert users with
special needs) can't stay in Fedora Extras?

    David




From pertusus at free.fr  Mon Mar  6 16:05:53 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 6 Mar 2006 17:05:53 +0100
Subject: acpi command line client in core?
In-Reply-To: <1141659758.2170.4.camel@daxter.boston.redhat.com>
References: <20060306110159.GC3002@free.fr>
	<1141659758.2170.4.camel@daxter.boston.redhat.com>
Message-ID: <20060306160553.GB2894@free.fr>

> Things like hal / gnome-power-manager right now works well for the core
> distribution (some day we'll even get rid of acpid) so I'm not sure why
> acpitool (which admittedly may be useful for admins / expert users with
> special needs) can't stay in Fedora Extras?

It can stay in Extras, it is just a proposition. But it may be interesting 
to have a command line acpi client, even for non-experts, but for those 
who have a basic use of the command line. Using an abstraction layer with 
hal seems better, but is there a command line interface to that abstraction
layer?

--
Pat



From hughsient at gmail.com  Mon Mar  6 16:12:53 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 06 Mar 2006 16:12:53 +0000
Subject: acpi command line client in core?
In-Reply-To: <20060306160553.GB2894@free.fr>
References: <20060306110159.GC3002@free.fr>
	<1141659758.2170.4.camel@daxter.boston.redhat.com>
	<20060306160553.GB2894@free.fr>
Message-ID: <1141661573.7826.8.camel@localhost.localdomain>

On Mon, 2006-03-06 at 17:05 +0100, Patrice Dumas wrote:
> > Things like hal / gnome-power-manager right now works well for the core
> > distribution (some day we'll even get rid of acpid) so I'm not sure why
> > acpitool (which admittedly may be useful for admins / expert users with
> > special needs) can't stay in Fedora Extras?
> 
> It can stay in Extras, it is just a proposition. But it may be interesting 
> to have a command line acpi client, even for non-experts, but for those 
> who have a basic use of the command line. Using an abstraction layer with 
> hal seems better, but is there a command line interface to that abstraction
> layer?

Depends what you want to do. With a few lines of python you can listen
for events for the battery, and ac_adapter, as well as set the
brightness of your LCD panel.

Or you can install gnome power manager and have all this done for you,
so it "just works" -- or it it unsuitable for your needs?

Richard

(g-p-m author..)



From david at fubar.dk  Mon Mar  6 16:14:57 2006
From: david at fubar.dk (David Zeuthen)
Date: Mon, 06 Mar 2006 11:14:57 -0500
Subject: acpi command line client in core?
In-Reply-To: <20060306160553.GB2894@free.fr>
References: <20060306110159.GC3002@free.fr>
	<1141659758.2170.4.camel@daxter.boston.redhat.com>
	<20060306160553.GB2894@free.fr>
Message-ID: <1141661698.2170.7.camel@daxter.boston.redhat.com>

On Mon, 2006-03-06 at 17:05 +0100, Patrice Dumas wrote:
> It can stay in Extras, it is just a proposition. But it may be interesting 
> to have a command line acpi client, even for non-experts, but for those 
> who have a basic use of the command line. Using an abstraction layer with 
> hal seems better, but is there a command line interface to that abstraction
> layer?

Only dbus-send at the moment but that is hardly useful:

 dbus-send --system --print-reply --reply-timeout=2147483648 \
 --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer \
 org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0

Though it's a one-time only pain since this interface probably won't
change much until hal goes 1.0.

    David




From katzj at redhat.com  Mon Mar  6 16:19:26 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 06 Mar 2006 11:19:26 -0500
Subject: 2.6.15-1.2009.4.2_FC5hypervisor + xen startup issue.
In-Reply-To: <1141632797.2519.4.camel@dragon.sys.intra>
References: <1141632797.2519.4.camel@dragon.sys.intra>
Message-ID: <1141661966.2338.2.camel@orodruin.boston.redhat.com>

On Mon, 2006-03-06 at 17:13 +0900, Naoki wrote:
> Anybody else seeing this with the latest kernel?
[snip]
> RuntimeError: (111, 'Connection refused')

For now, the temporary workaround is to mknod /dev/kmem.  Hopefully that
should go away after today

> No doubt unrelated but with this kernel on boot S05kudzu throws a "line
> 23 segfault" error which does not occur with the normal SMP kernel. Line
> 23 in that script is simply a case statement though.

Completely unrelated

Jeremy



From dhollis at davehollis.com  Mon Mar  6 16:48:26 2006
From: dhollis at davehollis.com (David Hollis)
Date: Mon, 06 Mar 2006 11:48:26 -0500
Subject: Postfix+LDAP segfault issues anyone?
Message-ID: <1141663706.2343.12.camel@dhollis-lnx.sunera.com>

I updated my home server to FC5-test3/development over the weekend and
everything went fine except for Postfix.  I'm using Postfix to host my
virtual mail domains using LDAP (Phamm schemas).  After updating to
Postfix-2.2.8-1.2.x86_64, trivial-rewrite would bomb out upon every
message delivery.  Doing some straces on it, it looks like it queries
LDAP and gets a result, but suddenly segfaults for some reason, thus
preventing mail delivery from happening.  I tried rebuilding the postfix
SRPM on my system in case it was some odd-ball library dependency issue,
but I had the exact same issue.

After a lot of trial and error, I pulled the postfix SRPM from FC4
(2.2.2-2) and rebuilt it on my system and downgraded to it, and all is
well.  I'm just wondering if this is a problem specific to something in
my installation, or if other folks have seen this as well?

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

From alan at redhat.com  Mon Mar  6 17:21:49 2006
From: alan at redhat.com (Alan Cox)
Date: Mon, 6 Mar 2006 12:21:49 -0500
Subject: Recommended laptop for FC5, was: glxgears
In-Reply-To: <20060302145338.0f8f7aac.zaitcev@redhat.com>
References: <1141173320.23703.2.camel@soncomputer>
	<Pine.LNX.4.64.0602281650090.30958@blackbox.fnordora.org>
	<1141174657.19512.3.camel@localhost.localdomain>
	<20060302145338.0f8f7aac.zaitcev@redhat.com>
Message-ID: <20060306172149.GA13959@devserv.devel.redhat.com>

On Thu, Mar 02, 2006 at 02:53:38PM -0800, Pete Zaitcev wrote:
> Apropos this, what is the situation with VIA Unichrome? Mike?
> IIRC, they had an open driver as a plug-in for old X, and it was
> poorly written, so someone started a rewrite. Did anything come
> out of it? You know, those Averatecs really look attractive...

My VIA unichrome 3D seems to worry pretty well now. The never open sourced
their mpeg engine because of patent concerns but Ivor Hewitt figured that out
and fixed the problem 8)

The slice engine is a great help for TV and the 3D works but the 3D performance
is not stunning. Its fine for tuxracer/bzflag but isnt going to make a gamer
happy



From jbarnes at virtuousgeek.org  Mon Mar  6 17:39:35 2006
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Mon, 6 Mar 2006 09:39:35 -0800
Subject: Sluggish window moving with EXA acceleration
In-Reply-To: <1141581735.440b27a7300ef@www.jouy.inra.fr>
References: <1141581735.440b27a7300ef@www.jouy.inra.fr>
Message-ID: <200603060939.35812.jbarnes@virtuousgeek.org>

On Sunday, March 5, 2006 10:02 am, ?meric Maschino wrote:
> Hi,
>
> Quickly moving windows on my GNOME desktop isn't fluent with the EXA
> acceleration although the old XAA acceleration performs normally. Is
> there anybody out there experiencing the same issue? This is on an
> Itanium workstation sporting an AGP ATI FireGL X1 graphics adapter
> (R300 chipset). I didn't add any tweaking option to my xorg.conf file
> except for AccelMethod when using EXA.

Sounds like a problem with the ATI driver's EXA implementation.  I assume 
you're not using the ATI binary drivers?  If not, you should probably 
file a bug with X.Org bugzilla to track the problem.

Jesse



From emeric.maschino at jouy.inra.fr  Mon Mar  6 19:33:32 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Mon,  6 Mar 2006 20:33:32 +0100
Subject: Sluggish window moving with EXA acceleration
In-Reply-To: <200603060939.35812.jbarnes@virtuousgeek.org>
References: <1141581735.440b27a7300ef@www.jouy.inra.fr>
	<200603060939.35812.jbarnes@virtuousgeek.org>
Message-ID: <1141673612.440c8e8c8e5cb@www.jouy.inra.fr>

Hi,

> Sounds like a problem with the ATI driver's EXA implementation.  I assume
> you're not using the ATI binary drivers?  If not, you should probably
> file a bug with X.Org bugzilla to track the problem.

This is with the open source ati driver provided by the Fedora Core X.org
implementation. Before filing a bug, I first would like to know if other people
have noticed this, just in case there's something to tweak in the xorg.conf file
to solve this. Anyway, thank you for you suggestion.

    ?meric



From kzak at redhat.com  Mon Mar  6 20:51:18 2006
From: kzak at redhat.com (Karel Zak)
Date: Mon, 6 Mar 2006 21:51:18 +0100
Subject: username best practices and other conventions
In-Reply-To: <1cef3e950603020821j24b659b6r38139a4ccd49ca54@mail.gmail.com>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
	<1cef3e950603020821j24b659b6r38139a4ccd49ca54@mail.gmail.com>
Message-ID: <20060306205118.GA8743@petra.dvoda.cz>

On Thu, Mar 02, 2006 at 04:21:12PM +0000, Joe Desbonnet wrote:
> I think it's time to move beyond those traditional limits. At some
> point we got over the 14 char file name limits, and the world is a
> better place for it.
> 
> I much prefer to spend a few more characters for clarity. Eg

 Hmm.. spend for what? For example "ps aux" uses all terminal columns
 and on traditional terminal with 80 columns there will be less space
 for the command column. So we will lost a lot of useful information
 about all processes, because there is one process that running with
 obscure username. I think 8 chars is good compromise. BTW, if you
 want to see full usernames you can use:

 ps -eo user:14,pid,%cpu,%mem,vsz,rss,tty,stat,start_time,time,command
 
> > IMHO, Fedora should respect the traditional best practices and
> > conventions (not speaking solely about usernames) and not violate them
> > without good reason. It seems there is maybe a carefree indifference or
> > possibly ignorant attitude about the "old ways". Breaking long standing
> > conventions in itself violates the principal of least surprise --
> > something sys admins do not care for.

 Agree.

> > distcache = 9
> > haldaemon = 9
> > nfsnobody = 9
> > webalizer = 9
> > beagleindex = 11

 Please, fill bugzilla.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From dwmw2 at infradead.org  Mon Mar  6 22:20:23 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 06 Mar 2006 22:20:23 +0000
Subject: bind-chroot obsolete due to SElinux?
In-Reply-To: <1141499698.3522.10.camel@concord2.proximity.on.ca>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
Message-ID: <1141683624.29230.0.camel@localhost.localdomain>

On Sat, 2006-03-04 at 14:14 -0500, Chris Tyler wrote:
> Should we consider bind-chroot obsolete, since SElinux should be able
> to provide similar protection (preventing named from touching files it
> should not, even if compromised)?

Most definitely not. Chroot is simple and effective; I've still never
been able to install and use SElinux without it breaking things.

-- 
dwmw2



From kloczek at zie.pg.gda.pl  Mon Mar  6 22:28:18 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Mon, 06 Mar 2006 23:28:18 +0100
Subject: bind-chroot obsolete due to SElinux?
In-Reply-To: <1141683624.29230.0.camel@localhost.localdomain>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
Message-ID: <1141684098.4081.37.camel@kloczek01.pracownicy.zie>

Dnia 06-03-2006, pon o godzinie 22:20 +0000, David Woodhouse napisa?(a):
> On Sat, 2006-03-04 at 14:14 -0500, Chris Tyler wrote:
> > Should we consider bind-chroot obsolete, since SElinux should be able
> > to provide similar protection (preventing named from touching files it
> > should not, even if compromised)?
> 
> Most definitely not. Chroot is simple and effective; I've still never
> been able to install and use SElinux without it breaking things.
> 

BTW bind.
Anyone work on fix Fedora bind for make this package FHS compliant ?
Current base directory for bind files is /var/named and acording to FHS
specification it will be better use /var/lib/named.

kloczek




From dax at gurulabs.com  Mon Mar  6 22:45:00 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Mon, 06 Mar 2006 15:45:00 -0700
Subject: BIND and FHS
In-Reply-To: <1141684098.4081.37.camel@kloczek01.pracownicy.zie>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
Message-ID: <1141685100.3862.14.camel@mentorng.gurulabs.com>

On Mon, 2006-03-06 at 23:28 +0100, Tomasz K?oczko wrote:

> BTW bind.
> Anyone work on fix Fedora bind for make this package FHS compliant ?
> Current base directory for bind files is /var/named and acording to FHS
> specification it will be better use /var/lib/named.

That'd would be nice.

I write multi-distro "Linux" documentation I'm painfully aware of
unneeded and trivial differences between distributions.

The "other" big distro does stick bind in /var/lib/named.

I'm not faulting Red Hat for /var/named/ though, as it does have 10+
years of momentum behind it and when it was chosen most likely there was
no standard location defined.

Dax Kelson
Guru Labs



From kloczek at zie.pg.gda.pl  Mon Mar  6 23:31:56 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Tue, 07 Mar 2006 00:31:56 +0100
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <1141685100.3862.14.camel@mentorng.gurulabs.com>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
Message-ID: <1141687916.4081.58.camel@kloczek01.pracownicy.zie>

Dnia 06-03-2006, pon o godzinie 15:45 -0700, Dax Kelson napisa?(a):
> On Mon, 2006-03-06 at 23:28 +0100, Tomasz K?oczko wrote:
> 
> > BTW bind.
> > Anyone work on fix Fedora bind for make this package FHS compliant ?
> > Current base directory for bind files is /var/named and acording to FHS
> > specification it will be better use /var/lib/named.
> 
> That'd would be nice.
> 
> I write multi-distro "Linux" documentation I'm painfully aware of
> unneeded and trivial differences between distributions.
> 
> The "other" big distro does stick bind in /var/lib/named.
> 
> I'm not faulting Red Hat for /var/named/ though, as it does have 10+
> years of momentum behind it and when it was chosen most likely there was
> no standard location defined.

Current FC have much more FHS clashes with FHS.
More examples:

- many programs still uses /var/spool/mail,

# LANG= grep /var/spool/mail /usr/bin/* /usr/sbin/* /sbin/* /bin/*
Binary file /usr/bin/balsa matches
Binary file /usr/bin/balsa-ab matches
Binary file /usr/bin/epic matches
Binary file /usr/bin/epic-EPIC4-2.2 matches
Binary file /usr/bin/gkrellm matches
Binary file /usr/bin/incm matches
Binary file /usr/bin/korn matches
Binary file /usr/bin/mail.local matches
Binary file /usr/bin/omshell matches
/usr/sbin/ctl-hlfsd:elif [ -d /var/spool/mail/. ]; then
/usr/sbin/ctl-hlfsd:    maildir="/var/spool/mail"
Binary file /usr/sbin/dhcpd matches
Binary file /usr/sbin/dhcrelay matches
Binary file /sbin/dhclient matches

- many programs still uses /usr/sbin/sendmail
  instead /usr/lib/sendmail (acording to FHS on this path must be
  avaialible sendmail commandline compliant program and for save this
  complinace anly this path will be good use).

# LANG= grep /usr/sbin/sendmail /usr/bin/* /usr/sbin/* /sbin/* /bin/*
Binary file /bin/mail matches
/usr/bin/bashbug-64:elif [ -f /usr/sbin/sendmail ] ; then
/usr/bin/bashbug-64:    RMAIL="/usr/sbin/sendmail"
Binary file /usr/bin/bug-buddy matches
/usr/bin/cmail:    $MAILPROG    = "/usr/sbin/sendmail" if (   (-x
"/usr/sbin/sendmail")
/usr/bin/cvsbug:SENDMAIL="/usr/sbin/sendmail"
Binary file /usr/bin/emacs-21.4-nox matches
Binary file /usr/bin/emacs-21.4-x matches
Binary file /usr/bin/emacs-nox matches
Binary file /usr/bin/emacs-x matches
/usr/bin/flea:SENDMAIL=/usr/sbin/sendmail
Binary file /usr/bin/lynx matches
Binary file /usr/bin/Mail matches
Binary file /usr/bin/mailsettings matches
Binary file /usr/bin/mutt matches
Binary file /usr/bin/nex-nocanna matches
Binary file /usr/bin/nview-nocanna matches
Binary file /usr/bin/nvi-nocanna matches
Binary file /usr/bin/oldrdist matches
/usr/bin/perlbug:       for
(qw(/usr/lib/sendmail /usr/sbin/sendmail /usr/ucblib/sendmail)) {
Binary file /usr/bin/php matches
Binary file /usr/bin/php-cgi matches
Binary file /usr/bin/procmail matches
Binary file /usr/bin/rcs matches
Binary file /usr/bin/rdist matches
/usr/bin/rmail:SENDMAIL="/usr/sbin/sendmail"
/usr/bin/rmail.postfix:SENDMAIL="/usr/sbin/sendmail"
Binary file /usr/bin/slrn matches
Binary file /usr/bin/sudo matches
Binary file /usr/bin/sudoedit matches
Binary file /usr/bin/sylpheed matches
Binary file /usr/sbin/anacron matches
Binary file /usr/sbin/arpsnmp matches
Binary file /usr/sbin/arpwatch matches
Binary file /usr/sbin/atd matches
Binary file /usr/sbin/crond matches
Binary file /usr/sbin/postconf matches
Binary file /usr/sbin/postfix matches
Binary file /usr/sbin/visudo matches
Binary file /sbin/mdadm matches
Binary file /sbin/mdadm.static matches

Looks like there is no hardcoded /usr/sbin/sendmail and /var/spool/mail
paths in libraries (I'm not check DSO installed in %{_libdir}
subdirectories).

- now are used for example /var/{arpwatch,gdm,kerberos,racoon,tux} (this
  is probably not all).
  Acording to FHS all this directories must be /var/lib.

kloczek



From cmadams at hiwaay.net  Tue Mar  7 00:08:11 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 6 Mar 2006 18:08:11 -0600
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <1141687916.4081.58.camel@kloczek01.pracownicy.zie>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
Message-ID: <20060307000811.GA719216@hiwaay.net>

Once upon a time, Tomasz Koczko <kloczek at zie.pg.gda.pl> said:
> Current FC have much more FHS clashes with FHS.
> More examples:
> 
> - many programs still uses /var/spool/mail,

I haven't read FHS, but changing from /var/spool/mail would be a major
backwards compatibility problem.

Also, just because programs reference /var/spool/mail doesn't mean it is
incorrect.  Many programs simply fall back to /var/spool/mail if $MAIL
isn't set (I expect that at least some of them have other traditional
paths hard coded for compatibility).

> - many programs still uses /usr/sbin/sendmail
>   instead /usr/lib/sendmail (acording to FHS on this path must be
>   avaialible sendmail commandline compliant program and for save this
>   complinace anly this path will be good use).

That's just dumb.  Requiring a binary in /usr/lib is bad for many
reasons (multi-arch like x86_64 for example).  Having a compatibility
symlink from /usr/lib/sendmail to /usr/sbin/sendmail is not a bad idea
(but come on, it has been something like 10 years or more since
/usr/sbin was the recommended place for sendmail).  Things should
reference /usr/sbin/sendmail as the proper place (/usr/lib/sendmail
being just for broken programs).

Does FHS say /usr/lib/sendmail should just exist or that it should be
used _instead of_ /usr/sbin/sendmail?

Also, again, some of your matches are also compatibility matches for
traditional paths on different OSes.

-- 
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 wtogami at redhat.com  Tue Mar  7 00:42:04 2006
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 06 Mar 2006 19:42:04 -0500
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
Message-ID: <440CD6DC.6020903@redhat.com>

https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=150222&hide_resolved=1

We are now attempting to fix some last minute problems.  Your help would 
be greatly appreciated in finding solutions for the problems listed in 
the above FC5 Blocker list.

Your testing of rawhide nightly tree installs (while not guaranteed to 
work) is very valuable at this point.  We need to know if there are any 
critical installation issues that would effect FC5 install, like the 
nasty Bug #159026.  Please also test upgrades of FC3 or FC4 systems to 
the nightly rawhide tree and report any problems that you see to Bugzilla.

Bugzilla is the official and best way to get reports to the developers. 
  Complaints posted only to a mailing list are very likely to be lost in 
the bulk.  Bug reports have status, comments and resolution states so at 
least there is a chance of tracking your issue.

Thank you for using Fedora.

Warren Togami
wtogami at redhat.com



From seg at haxxed.com  Tue Mar  7 01:02:57 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 06 Mar 2006 19:02:57 -0600
Subject: rawhide of 20060223: KDE fails to start
In-Reply-To: <20060224233116.GA17915@joshua.mesa.nl>
References: <20060224180127.GA13869@joshua.mesa.nl>
	<20060224233116.GA17915@joshua.mesa.nl>
Message-ID: <1141693378.2599.10.camel@localhost>

On Sat, 2006-02-25 at 00:31 +0100, Marcel J.E. Mol wrote:
> Right, solved it. 
> I needed to remove the fontcache in ~/.rh-fontconfig

I ran into a similar problem updating to FC5t3. Couldn't log in to
gnome, tried logging in to the failsafe terminal, trying to start any
apps would just segfault.

I didn't have a ~/.rh-fontconfig, however I do have over a thousand
fonts in ~/.fonts, sorted into subdirectories. I deleted all the
fonts.cache-1 files, and it seems to work now. And now I do have a
~/.rh-fontconfig ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060306/f4ebf5dd/attachment.sig>

From z at canteiros.org  Tue Mar  7 01:01:26 2006
From: z at canteiros.org (Z)
Date: Mon, 06 Mar 2006 17:01:26 -0800
Subject: X keyboard compose key
In-Reply-To: <20060306145411.GE28157@exeter.boston.redhat.com>
References: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>
	<20060306145411.GE28157@exeter.boston.redhat.com>
Message-ID: <440CDB66.5070706@canteiros.org>

Where did the compose key selection went? Or is it fixed to right-alt?

Z



From thacker at math.cornell.edu  Tue Mar  7 02:37:13 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Mon, 6 Mar 2006 21:37:13 -0500
Subject: X keyboard compose key
In-Reply-To: <440CDB66.5070706@canteiros.org>
References: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>
	<20060306145411.GE28157@exeter.boston.redhat.com>
	<440CDB66.5070706@canteiros.org>
Message-ID: <20060307023713.GA18913@localhost.localdomain>

On Mon, Mar 06, 2006 at 05:01:26PM -0800, Z wrote:
> Where did the compose key selection went? Or is it fixed to right-alt?

System -> Preferences -> Keyboard -> Layout Options -> Compose key position

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060306/96fe0380/attachment.sig>

From wtogami at redhat.com  Tue Mar  7 03:10:11 2006
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 06 Mar 2006 22:10:11 -0500
Subject: X keyboard compose key
In-Reply-To: <20060307023713.GA18913@localhost.localdomain>
References: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>	<20060306145411.GE28157@exeter.boston.redhat.com>	<440CDB66.5070706@canteiros.org>
	<20060307023713.GA18913@localhost.localdomain>
Message-ID: <440CF993.4030901@redhat.com>

John Thacker wrote:
> On Mon, Mar 06, 2006 at 05:01:26PM -0800, Z wrote:
>> Where did the compose key selection went? Or is it fixed to right-alt?
> 
> System -> Preferences -> Keyboard -> Layout Options -> Compose key position
> 
> John
> 

Before you do this, could you please do this first.

gconftool-2 -R /desktop/gnome/peripherals/keyboard > keyboard-backup.txt

Then please attach that to your reply mail.

If you have already modified your settings using the Keyboard 
preferences tool, then it is too late.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183997
I suspect this complaint is from a similar cause of this problem, if you 
are referring to some behavior changing in rawhide.

Warren Togami
wtogami at redhat.com



From z at canteiros.org  Tue Mar  7 04:13:42 2006
From: z at canteiros.org (Z)
Date: Mon, 06 Mar 2006 20:13:42 -0800
Subject: X keyboard compose key
In-Reply-To: <440CF993.4030901@redhat.com>
References: <561c252c0603032346j34e8e13eg2375855ff42ee11f@mail.gmail.com>	<20060306145411.GE28157@exeter.boston.redhat.com>	<440CDB66.5070706@canteiros.org>	<20060307023713.GA18913@localhost.localdomain>
	<440CF993.4030901@redhat.com>
Message-ID: <440D0876.70009@canteiros.org>

Warren Togami wrote:
> John Thacker wrote:
> 
>> On Mon, Mar 06, 2006 at 05:01:26PM -0800, Z wrote:
>>
>>> Where did the compose key selection went? Or is it fixed to right-alt?
>>
>>
>> System -> Preferences -> Keyboard -> Layout Options -> Compose key 
>> position
>>
>> John

Thanks!

> Before you do this, could you please do this first.
> 
> gconftool-2 -R /desktop/gnome/peripherals/keyboard > keyboard-backup.txt
> 
> Then please attach that to your reply mail.

Done. Hope it helps.

Z

> If you have already modified your settings using the Keyboard 
> preferences tool, then it is too late.
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183997
> I suspect this complaint is from a similar cause of this problem, if you 
> are referring to some behavior changing in rawhide.
> 
> Warren Togami
> wtogami at redhat.com
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: keyboard-backup.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060306/22480360/attachment.txt>

From che666 at gmail.com  Tue Mar  7 09:13:49 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 7 Mar 2006 10:13:49 +0100
Subject: username best practices and other conventions
In-Reply-To: <20060306205118.GA8743@petra.dvoda.cz>
References: <1141286133.4207.36.camel@mentorng.gurulabs.com>
	<1cef3e950603020821j24b659b6r38139a4ccd49ca54@mail.gmail.com>
	<20060306205118.GA8743@petra.dvoda.cz>
Message-ID: <e99d27470603070113i4eabaa92h@mail.gmail.com>

2006/3/6, Karel Zak <kzak at redhat.com>:
> On Thu, Mar 02, 2006 at 04:21:12PM +0000, Joe Desbonnet wrote:
> > I think it's time to move beyond those traditional limits. At some
> > point we got over the 14 char file name limits, and the world is a
> > better place for it.
> >
> > I much prefer to spend a few more characters for clarity. Eg
>
>  Hmm.. spend for what? For example "ps aux" uses all terminal columns
>  and on traditional terminal with 80 columns there will be less space
>  for the command column. So we will lost a lot of useful information
>  about all processes, because there is one process that running with
>  obscure username. I think 8 chars is good compromise. BTW, if you
>  want to see full usernames you can use:
>
>  ps -eo user:14,pid,%cpu,%mem,vsz,rss,tty,stat,start_time,time,command
>
> > > IMHO, Fedora should respect the traditional best practices and
> > > conventions (not speaking solely about usernames) and not violate them
> > > without good reason. It seems there is maybe a carefree indifference or
> > > possibly ignorant attitude about the "old ways". Breaking long standing
> > > conventions in itself violates the principal of least surprise --
> > > something sys admins do not care for.
>
>  Agree.
>
> > > distcache = 9
> > > haldaemon = 9
> > > nfsnobody = 9
> > > webalizer = 9
> > > beagleindex = 11
>
>  Please, fill bugzilla.
>
>    Karel
>
> --
>  Karel Zak  <kzak at redhat.com>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

this sounds to me like going back to 8 char filenames again. best
practice with the limitations of the last decade ... i dont know if
thats the right approach...

if a console command has problems to deal with proper output id fix
the command. just my opinion.

Using cryptic names also makes stuff less obvious with no real gain in
my eyes besides working around some limitations of console commands
maybe as described above.

regards,
Rudolf Kastl



From buildsys at redhat.com  Tue Mar  7 09:24:06 2006
From: buildsys at redhat.com (Build System)
Date: Tue, 7 Mar 2006 04:24:06 -0500
Subject: rawhide report: 20060307 changes
Message-ID: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>

 

 
Updated Packages:

GConf2-2.13.5-5
---------------
* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> 2.13.5-5
- Only sync the database once when installing multiple
  schema files.  Patch by Josselin Mouette <joss at debian.org>.
  (upstream bug 333353)

NetworkManager-0.6.0-2
----------------------
* Mon Mar 06 2006 Dan Williams <dcbw at redhat.com> 0.6.0-2
- Don't let wpa_supplicant perform scanning with non-WPA drivers

* Mon Mar 06 2006 Dan Williams <dcbw at redhat.com> 0.6.0-1
- Update to 0.6.0 release
- Move autostart file to /usr/share/gnome/autostart

OpenIPMI-1.4.14-19
------------------
* Fri Feb 17 2006 Phil Knirsch <pknirsch at redhat.com> 1.4.14-19
- Added missing PreReq for chkconfig

adaptx-0:0.9.6-1jpp_3fc.1
-------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:0.9.6-1jpp_3fc.1
- stop scriptlet spew

anaconda-10.92.17-1
-------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 10.92.17-1
- fix traceback in size check
- disable size check on upgrade (clumens, #184112)
- try to catch more failures to read repo metadata (clumens)
- only do runlevel 5 if graphical install (dcantrel, #184013)
- adjust to new xen kernel package naming
- add 'vesa' flag to force the use of the vesa driver
- more meaningful error messages on conflicts (pnasrat)
- ensure some dirs are labelled correct (#182252)

ant-0:1.6.5-1jpp_7fc
--------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.6.5-1jpp_7fc
- stop scriptlet spew

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 0:1.6.5-1jpp_6fc
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 0:1.6.5-1jpp_5fc
- rebuilt for new gcc4.1 snapshot and glibc changes

antlr-0:2.7.4-2jpp_6fc
----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.7.4-2jpp_6fc
- stop scriptlet spew

audit-1.1.5-1
-------------
* Mon Mar 06 2006 Steve Grubb <sgrubb at redhat.com> 1.1.5-1
- Changed audit_log_semanage_message to take new params
- In aureport, add class between syscall and permission in avc report
- Fix bug where fsync is called in debug mode
- Add optional support for tty in SYSCALL records for ausearch/aureport
- Reinstate legacy rule operator support
- Add man pages
- Auditd ignore most signals

avalon-framework-0:4.1.4-2jpp_8fc
---------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:4.1.4-2jpp_8fc
- stop scriptlet spew

avalon-logkit-0:1.2-3jpp_3fc
----------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.2-3jpp_3fc
- stop scriptlet spew

axis-0:1.2.1-2jpp_2fc
---------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.2.1-2jpp_2fc
- stop scriptlet spew

bcel-0:5.1-1jpp_6fc
-------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:5.1-1jpp_6fc
- stop the scriptlet spew

bluez-utils-2.25-2
------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 2.25-2
- fix initscripts to be more resilient of files missing to clean up 
  scriptlet errors on install

booty-0.69-1
------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0.69-1
- adjust for changed xen kernel naming

bsf-0:2.3.0-6jpp_3fc
--------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.3.0-6jpp_3fc
- stop scriptlet spew

castor-0:0.9.5-1jpp_2fc
-----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:0.9.5-1jpp_2fc
- stop scriptlet spew

classpathx-jaf-0:1.0-2jpp_5fc
-----------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.0-2jpp_5fc
- stop scriptlet spew

classpathx-mail-0:1.0-4jpp_5fc
------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.0-4jpp_5fc
- stop the scriptlet spew

concurrent-0:1.3.2-2jpp_2fc
---------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.3.2-2jpp_2fc
- stop scriptlet spew

cyrus-sasl-2.1.21-10
--------------------
* Mon Feb 20 2006 Nalin Dahyabhai <nalin at redhat.com> 2.1.21-10
- add missing buildrequires on gdbm-devel (Karsten Hopp)

dovecot-1.0-0.beta2.6
---------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1.0-0.beta2.6
- fix scriptlet error (mitr, #184151)

evince-0.5.1-3
--------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0.5.1-3
- quiet scriptlet spew from gconfd killing

firefox-1.5.0.1-7
-----------------
* Mon Mar 06 2006 Warren Togami <wtogami at redhat.com> - 1.5.0.1-7
- make links point to the correct release

* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 1.5.0.1-6
- Add new bookmarks file from Warren (bug 182386)

* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de>
- add buildrequires libXt-devel for X11/Intrinsic.h, X11/Shell.h

gdm-1:2.13.0.9-2
----------------
* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 1:2.13.0.9-2
- disable sounds completely when disabled in configuration file
 (upstream bug 333435)

glibc-2.4-1
-----------
* Mon Mar 06 2006 Jakub Jelinek <jakub at redhat.com> 2.4-1
- update from CVS
  - glibc 2.4 release

* Mon Mar 06 2006 Jakub Jelinek <jakub at redhat.com> 2.3.91-2
- update from CVS
  - fix sYSMALLOc for MALLOC_ALIGNMENT > 2 * SIZE_SZ (#183895)
  - revert ppc32 malloc alignment patch, it breaks malloc_set_state
    and needs some further thoughts and time (#183894)
- provide accurate unwind info for lowlevellock.h stubs on x86_64

gnome-pilot-2.0.13-7.fc5.3
--------------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.0.13-7.fc5.3
- Buildrequires: gob2

gnome-power-manager-2.13.93-4
-----------------------------
* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 2.13.93-4
- fix the fix in -2 and -3

* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 2.13.93-3
- fix the fix in -2

* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 2.13.93-2
- fix icon in bubbles (bug 184192).

gnome-print-1:0.37-13
---------------------
* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 0.37-13
- BuildRequires: freetype-devel for freetype-config

gnome-python2-desktop-2.13.3-2
------------------------------

gnome-session-2.13.92-3
-----------------------
* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 2.13.92-3
- Patch from Vincent Untz to fix session editing (upstream bug 333641)
- Desensitize buttons for operations that the user isn't allowed
  to do (bug 179479).

gnu-crypto-0:2.1.0-1jpp_2fc
---------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.1.0-1jpp_2fc
- stop scriptlet spew

gnu.getopt-0:1.0.9-4jpp_4fc
---------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.0.9-4jpp_4fc
- stop scriptlet spew

hsqldb-0:1.80.1-1jpp_8fc
------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.80.1-1jpp_8fc
- stop scriptlet spew

imake-1.0.1-3
-------------
* Mon Mar 06 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
- Updated xorg-cf-files-1.0.1-redhat.patch with fix for (#178177)

initscripts-8.31-1
------------------
* Sun Mar 05 2006 Bill Nottingham <notting at redhat.com> 8.31-1
- fix kexec support (<jmoyer at redhat.com>)
- translation updates

iputils-20020927-35
-------------------
* Fri Feb 24 2006 Radek Vok??l <rvokal at redhat.com> - 20020927-35
- add PreReq: chkconfig (#182799,#182798)

jakarta-commons-beanutils-0:1.7.0-2jpp_6fc
------------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.7.0-2jpp_6fc
- stop scriptlet spew

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> 
- bump again for double-long bug on ppc(64)

* Wed Dec 21 2005 Jesse Keating <jkeating at redhat.com> - 0:1.7.0-2jpp_4fc
- rebuilt again

jakarta-commons-codec-0:1.3-2jpp_4fc
------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.3-2jpp_4fc
- BR java-javadoc

* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.3-2jpp_3fc
- stop the scriptlet spew

jakarta-commons-collections-0:3.1-2jpp_5fc
------------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:3.1-2jpp_5fc
- stop the scriptlet spew

jakarta-commons-daemon-1:1.0-2jpp_3fc
-------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1:1.0-2jpp_3fc
- stop scriptlet spew

jakarta-commons-digester-0:1.7-2jpp_10fc
----------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.7-2jpp_10fc
- stop scriptlet spew

jakarta-commons-el-0:1.0-4jpp_6fc
---------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.0-4jpp_6fc
- stop scriptlet spew

jakarta-commons-fileupload-1:1.0-3jpp_5fc
-----------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1:1.0-3jpp_5fc
- stop scriptlet spew

jakarta-commons-httpclient-1:3.0-0.rc2.0jpp_4fc
-----------------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1:3.0-0.rc2.0jpp_4fc
- stop scriptlet spew

jakarta-commons-lang-0:2.0-2jpp_4fc
-----------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.0-2jpp_4fc
- stop scriptlet spew

jakarta-commons-launcher-0:0.9-3jpp_3fc
---------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:0.9-3jpp_3fc
- stop scriptlet spew

jakarta-commons-logging-0:1.0.4-2jpp_10fc
-----------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.0.4-2jpp_10fc
- stop scriptlet spew

jakarta-commons-modeler-0:1.1-4jpp_6fc
--------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.1-4jpp_6fc
- stop scriptlet spew

jakarta-commons-pool-0:1.2-2jpp_4fc
-----------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.2-2jpp_4fc
- stop scriptlet spew

jakarta-taglibs-standard-0:1.1.1-4jpp_3fc
-----------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.1.1-4jpp_3fc
- stop scriptlet spew

java_cup-1:0.10-0.k.1jpp_9fc
----------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1:0.10-0.k.1jpp_9fc
- stop scriptlet spew

jdom-0:1.0-1jpp_3fc
-------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.0-1jpp_3fc
- stop scriptlet spew

jgroups-0:2.2.6-1jpp_4fc
------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.2.6-1jpp_4fc
- stop scriptlet spew

jsch-0:0.1.18-1jpp_7fc
----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:0.1.18-1jpp_7fc
- stop scriptlet spew

jzlib-0:1.0.5-2jpp_2fc
----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.0.5-2jpp_2fc
- stop the scriptlet spew

kernel-2.6.15-1.2025_FC5
------------------------
* Mon Mar 06 2006 Dave Jones <davej at redhat.com>
- Disable DRI on Radeon R300 and above, due to instability. (#174646,#182196)
- Don't do voluntary preempt until after bootup

* Mon Mar 06 2006 Stephen Tweedie <sct at redhat.com>
- Merge xen rebase with 1.2016 kernel
- Rename kernel-xen-(hypervisor|guest) to kernel-xen(0|U) for consistency
  with upstream and to make kernel subtype suffixes match the subpackage
  names.  (From Jeremy Katz.)
- Export mmap-able kva interface for xen to find the xenstore page 
  (xen-unstable cset 9130)
- Remove stale linux-2.6-xen-module-fault.patch file
- Add workaround for non-xen ia64 builds: temporarily back-out the ia64-
  specific portions of linux-2.6-xen.patch.

* Sun Mar 05 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc5-git8
- Add a safety net to softlockup so that it doesn't prevent installs.

kexec-tools-1.101-13
--------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1.101-13
- proper requires for scriptlets

* Mon Mar 06 2006 Thomas Graf <tgraf at redhat.com> - 1.101-12
- Move kexec and kdump binaries to /sbin

* Thu Mar 02 2006 Thomas Graf <tgraf at redhat.com> - 1.101-11
- Fix argument order when stopping kexec

kudzu-1.2.34-1
--------------
* Mon Mar 06 2006 Bill Nottingham <notting at redhat.com> - 1.2.34-1
- silence some error messages

log4j-0:1.2.8-7jpp_8fc
----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.2.8-7jpp_8fc
- fix scriptlet spew

metacity-2.13.144-1
-------------------
* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 2.13.144-1
- update to 2.13.144
- add bling patch from HEAD

nautilus-2.13.92-2
------------------
* Mon Mar 06 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-2
- Reinstate the format patch which was accidentally dropped

policycoreutils-1.29.26-5
-------------------------
* Mon Mar 06 2006 Dan Walsh <dwalsh at redhat.com> 1.29.26-5
- Fix audit2allow to generate all rules

* Fri Mar 03 2006 Dan Walsh <dwalsh at redhat.com> 1.29.26-4
- Minor fixes to chcat and semanage

* Fri Feb 24 2006 Dan Walsh <dwalsh at redhat.com> 1.29.26-3
- Add missing setsebool man page

puretls-0.9-0.b4.1jpp_4fc
-------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0.9-0.b4.1jpp_4fc
- stop scriptlet spew

pyxf86config-0.3.24-1
---------------------
* Wed Feb 22 2006 Chris Lumens <clumens at redhat.com> 0.3.24-1
- Add 1600x1024 and 800x512 to the list of supported resolutions (#115679)

* Tue Jan 17 2006 Christopher Aillon <caillon at redhat.com> 0.3.23-1
- Use the standard X headers instead of keeping a copy in-tree

* Wed Dec 21 2005 Jesse Keating <jkeating at redhat.com>
- changed BuildReq to new modular devel package
- Changed search path for X libraries

regexp-0:1.3-2jpp_7fc
---------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.3-2jpp_7fc
- stop scriptlet spew

rhpxl-0.18-1
------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0.18-1
- allow forcing vesa (#184015)

selinux-policy-2.2.23-4
-----------------------
* Mon Mar 06 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-4
- Fixes for cups
- Make cryptosetup work with hal

* Sun Mar 05 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-3
- Load Policy needs translock

* Sat Mar 04 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-2
- Fix cups html interface

setup-2.5.49-1
--------------
* Thu Feb 23 2006 Phil Knirsch <pknirsch at redhat.com> 2.4.49-1
- Really switch to new /etc/services file
- Added /etc/fstab and /etc/mtab to ownership of setup (#177061)

system-config-date-1.8.1-1
--------------------------
* Fri Mar 03 2006 Nils Philippsen <nphilipp at redhat.com> 1.8.1
- require hicolor-icon-theme (#182859, #182860)

system-config-nfs-1.3.19-1
--------------------------
* Fri Mar 03 2006 Nils Philippsen <nphilipp at redhat.com> 1.3.19
- require hicolor-icon-theme (#182870, #182871)

system-config-samba-1.2.34-1
----------------------------
* Fri Mar 03 2006 Nils Philippsen <nphilipp at redhat.com> - 1.2.34
- require hicolor-icon-theme (#182874, #182875)

system-config-services-0.9.0-1
------------------------------
* Fri Mar 03 2006 Nils Philippsen <nphilipp at redhat.com> - 0.9.0
- require hicolor-icon-theme (#182878, #182879)

* Tue Feb 28 2006 Florian Festi <ffesti at redhat.com> 
- rewrote large parts of servicemethods (OO design, better handling of old/new
  settings, read headers of init scripts completely)
- first implementation of widgets to control services (intended for tools
  configuring single services like nfs, samba, bind, ...), still missing: i18n,
  dependencies on other services (like portmap)

system-config-soundcard-1.2.16-2
--------------------------------
* Mon Feb 27 2006 Martin Stransky <stransky at redhat.com> 1.2.16-2
- added hicolor-icon-theme to PreReq, (#182880, #182881)

system-config-users-1.2.42-1
----------------------------
* Fri Mar 03 2006 Nils Philippsen <nphilipp at redhat.com> - 1.2.42
- require hicolor-icon-theme (#182882, #182883)

* Fri Oct 14 2005 Nils Philippsen <nphilipp at redhat.com>
- don't use pam_stack (#170649)

* Tue Oct 04 2005 Nils Philippsen <nphilipp at redhat.com> - 1.2.41
- fix variable names to prevent hangs when adding a group (#169730)

tanukiwrapper-0:3.1.1-4jpp_7fc
------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:3.1.1-4jpp_7fc
- stop scriptlet spew

tetex-3.0-17
------------
* Sat Feb 25 2006 Jindrich Novy <jnovy at redhat.com> 3.0-17
- PreReq: info (#182886, #182887)

texi2html-1.76-3
----------------
* Sat Feb 25 2006 Jindrich Novy <jnovy at redhat.com> 1.76-3
- PreReq info (#182888)

tomcat5-0:5.5.15-1jpp_6fc
-------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:5.5.15-1jpp_6fc
- stop scriptlet spew

* Fri Mar 03 2006 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:5.5.15-1jpp_5fc
- Require java-gcj-compat for post and postun sections of
  servlet-2.4-api, jsp-2.0-api-javadoc and
  server-lib sub-packages, since these three packages call
  /usr/bin/rebuild-gcj-db in their post and/or postun sections.

udev-084-12
-----------
* Mon Mar 06 2006 Harald Hoyer <harald at redhat.com> - 084-12
- fixed DRI permissions

velocity-0:1.4-3jpp_4fc
-----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.4-3jpp_4fc
- stop scriptlet spew

werken.xpath-0:0.9.4-0.beta.9jpp_3fc
------------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:0.9.4-0.beta.9jpp_3fc
- stop scriptlet spew

wsdl4j-0:1.5.1-1jpp_4fc
-----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.5.1-1jpp_4fc
- stop scriptlet spew

xalan-j2-0:2.6.0-3jpp_9fc
-------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.6.0-3jpp_9fc
- stop scriptlet spew

xdoclet-0:1.2.2-2jpp_5fc
------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.2.2-2jpp_5fc
- fix scriptlet spew

xen-3.0.1-2
-----------
* Mon Mar 06 2006 Stephen Tweedie <sct at redhat.com> - 3.0.1-2
- Use kva mmap to find the xenstore page (upstream xen-unstable cset 9130)

* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 3.0.1-1
- fix xenguest-install so that it uses phy: for block devices instead of 
  forcing them over loopback.  
- change package versioning to be a little more accurate

xerces-j2-0:2.7.1-6jpp_7fc
--------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.7.1-6jpp_7fc
- stop scriptlet spew

xjavadoc-0:1.1-1jpp_4fc
-----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.1-1jpp_4fc
- stop scriptlet spew

xml-commons-0:1.3.02-0.b2.7jpp_7fc
----------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.3.02-0.b2.7jpp_7fc
- stop scriptlet spew

xml-commons-resolver-0:1.1-1jpp_8fc
-----------------------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:1.1-1jpp_8fc
- stop scriptlet spew

xmlrpc-0:2.0.1-1jpp_6fc
-----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 0:2.0.1-1jpp_6fc
- stop scriptlet spew

* Fri Feb 24 2006 Igor Foox <ifoox at redhat.com> - 0:2.0.1-1jpp_5fc
- Added post/postun dependency on coreutils.

xorg-x11-server-1.0.1-8
-----------------------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1.0.1-8
- build libxf86config with -fPIC (#181292)
- fix sgi 1600sw extra mode (#182430)

* Wed Feb 22 2006 Jeremy Katz <katzj at redhat.com> 1.0.1-7
- install randrstr.h as part of sdk as required for building some drivers

* Tue Feb 21 2006 Mike A. Harris <mharris at redhat.com>
- Added xorg-server-1.0.1-backtrace.patch which enables the Xorg server's
  built in backtrace support by default, as it was inadvertently disabled in
  7.0.

xorg-x11-xkbdata-1.0.1-7
------------------------
* Sat Mar 04 2006 Ray Strode <rstrode at redhat.com> 1.0.1-7
- Update to 0.8.

yum-2.6.0-1
-----------
* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 2.6.0-1
- update to 2.6.0 final containing fix for #176257

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From che666 at gmail.com  Tue Mar  7 11:17:31 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 7 Mar 2006 12:17:31 +0100
Subject: nvidiafb
Message-ID: <e99d27470603070317m24f84fedx@mail.gmail.com>

Hello!

I am well aware that the nvidiafb/rivafb driver doesent work well
together with the nvidia binary driver... that said... id be happy if
nvidiafb would be built aswell. as far as i know and read it should be
in the mainline kernel but it seems that the module isnt built in
latest fedora development kernels, rivafb is.

I am not really aware about the details regarding this "issue" or
"feature request" but is there a sound reason why the nvidiafb driver
isnt beeing built so one could atleast test it?

regards,
Rudolf Kastl

p.s. radeonfb on my thinkpad works great ;)



From gianluca.cecchi at gmail.com  Tue Mar  7 11:34:07 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Tue, 7 Mar 2006 12:34:07 +0100
Subject: ordinary kernels install when choosing xen
Message-ID: <561c252c0603070334m500a71b5ybd55e29efafa0396@mail.gmail.com>

If you choose xen in installation, only kernel-xen-hypervisor is
installed, not the ordinary uni/smp kernels on i686.
Is this intentional? How could one install both xen and ordinary
kernels, without doing it manually after install?



From hk at isphuset.no  Tue Mar  7 14:28:19 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Tue, 07 Mar 2006 15:28:19 +0100
Subject: Evince claims pdf password protected
Message-ID: <1141741699.2993.5.camel@linux>

Opening
http://www.highpoint-tech.com/manuals/BIOS%20Update%20User%20Manual.pdf
in Document Viewer (Evince) fails and it clams it is password protected.
If I open it using Xpdf it works just fine.

File can be found at
http://www.highpoint-tech.com/USA/bios_rr1820a.htm
link is known as "BIOS User Manual". I used Firefox.

FC4
xpdf-3.01-0.FC4.8
evince-0.4.0-1.2
firefox-1.0.7-1.2.fc4

-HK



From sundaram at fedoraproject.org  Tue Mar  7 14:25:16 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 07 Mar 2006 19:55:16 +0530
Subject: Evince claims pdf password protected
In-Reply-To: <1141741699.2993.5.camel@linux>
References: <1141741699.2993.5.camel@linux>
Message-ID: <440D97CC.3000508@fedoraproject.org>

Hans Kristian Rosbach wrote:

>Opening
>http://www.highpoint-tech.com/manuals/BIOS%20Update%20User%20Manual.pdf
>in Document Viewer (Evince) fails and it clams it is password protected.
>If I open it using Xpdf it works just fine.
>
>File can be found at
>http://www.highpoint-tech.com/USA/bios_rr1820a.htm
>link is known as "BIOS User Manual". I used Firefox.
>
>  
>
Similar issue with http://www.acm.org/usacm/weblog/wp-content/DRM.pdf. 
Related article with comments at http://lwn.net/Articles/174448/.


-- 
Rahul 





From kloczek at zie.pg.gda.pl  Tue Mar  7 15:02:04 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Tue, 07 Mar 2006 16:02:04 +0100
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <20060307000811.GA719216@hiwaay.net>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<20060307000811.GA719216@hiwaay.net>
Message-ID: <1141743724.4081.121.camel@kloczek01.pracownicy.zie>

Dnia 06-03-2006, pon o godzinie 18:08 -0600, Chris Adams napisa?(a):
[..]
> I haven't read FHS,

So my answer is very short: be so kind/smart and please finish lecture
FHS specyfication before starting disscuss about this subjects. OK ?

I have not time for learning you and pointing where you are try say
something completly dumb (on ground this specyfication).

kloczek



From cmadams at hiwaay.net  Tue Mar  7 15:37:50 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 7 Mar 2006 09:37:50 -0600
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <604aa7910603070733x400ce168w66b8c7e3420bda6c@mail.gmail.com>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<20060307000811.GA719216@hiwaay.net>
	<604aa7910603070733x400ce168w66b8c7e3420bda6c@mail.gmail.com>
Message-ID: <20060307153750.GC1229196@hiwaay.net>

Once upon a time, Jeff Spaleta <jspaleta at gmail.com> said:
> On 3/6/06, Chris Adams <cmadams at hiwaay.net> wrote:
> > Does FHS say /usr/lib/sendmail should just exist or that it should be
> > used _instead of_ /usr/sbin/sendmail?
> Friendly advice.. it helps to read up on reference material before
> asking questions... or else you run the risk of having your questions
> summarily disregarded.

I asked the question because the original poster said that programs
calling /usr/sbin/sendmail were wrong.  I didn't think that was the
intent of the FHS, so I asked the OP to support the claim.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From jspaleta at gmail.com  Tue Mar  7 15:33:59 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 7 Mar 2006 10:33:59 -0500
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <20060307000811.GA719216@hiwaay.net>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<20060307000811.GA719216@hiwaay.net>
Message-ID: <604aa7910603070733x400ce168w66b8c7e3420bda6c@mail.gmail.com>

On 3/6/06, Chris Adams <cmadams at hiwaay.net> wrote:
> Does FHS say /usr/lib/sendmail should just exist or that it should be
> used _instead of_ /usr/sbin/sendmail?
Friendly advice.. it helps to read up on reference material before
asking questions... or else you run the risk of having your questions
summarily disregarded.

In this case... /usr/lib/sendmail is a symlink specifically required
for historical reasons but there is no requirement that any modern
application use it as the prefered location. In fact the fhs 2.3 goes
out of its way to explain that /usr/sbin/ is the current default and
there is an expectation that applications will be using the default
/usr/sbin/sendmail location if possible. I belive the referenced
footnote clarifies this.

Just so everyone in this discussion has a clear understanding of the
text in question, I will quote 
http://www.pathname.com/fhs/pub/fhs-2.3.html. It would have been
helpful if the original poster would have provided a quote and
citation of the fhs they felt was in conflict. I don't see an issue
according to the the 2.3 fhs and I believe the original poster in this
thread has misunderstood the fhs text.  /usr/lib/sendmail must be
provided for "historical reasons" and applications are encouraged to
use /usr/sbin/sendmail which is the current default.

-jef
<quote http://www.pathname.com/fhs/pub/fhs-2.3.html>
Chapter 4. The /usr Hierarchy
...
Specific Options
For historical reasons, /usr/lib/sendmail must be a symbolic link to
/usr/sbin/sendmail if the latter exists. [24]
	
.....
[24] Some executable commands such as makewhatis and sendmail have
also been traditionally placed in /usr/lib. makewhatis is an internal
binary and must be placed in a binary directory; users access only
catman. Newer sendmail binaries are now placed by default in
/usr/sbin. Additionally, systems using a sendmail-compatible mail
transfer agent must provide /usr/sbin/sendmail as a symbolic link to
the appropriate executable.
</quote>



From ndbecker2 at gmail.com  Tue Mar  7 15:59:48 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 07 Mar 2006 10:59:48 -0500
Subject: beagle backup (user_xattr)
Message-ID: <dukalf$qfo$1@sea.gmane.org>

How can we backup beagle data, including user_xattr?

What happens if we don't restore user_xattr correctly?  Will beagle re-create it?



From mclasen at redhat.com  Tue Mar  7 16:02:52 2006
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 07 Mar 2006 11:02:52 -0500
Subject: beagle backup (user_xattr)
In-Reply-To: <dukalf$qfo$1@sea.gmane.org>
References: <dukalf$qfo$1@sea.gmane.org>
Message-ID: <1141747372.20856.10.camel@golem.boston.redhat.com>

On Tue, 2006-03-07 at 10:59 -0500, Neal Becker wrote:
> How can we backup beagle data, including user_xattr?
> 
> What happens if we don't restore user_xattr correctly?  Will beagle re-create it?
> 

Beagle does not use extended attributes in FC5 (at least not by
default), it uses sqlite. So there should be no problem.


Matthias



From jspaleta at gmail.com  Tue Mar  7 15:57:55 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 7 Mar 2006 10:57:55 -0500
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <1141687916.4081.58.camel@kloczek01.pracownicy.zie>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
Message-ID: <604aa7910603070757j505b2c9qd0ca71df579b3dff@mail.gmail.com>

On 3/6/06, Tomasz K?oczko <kloczek at zie.pg.gda.pl> wrote:
> - many programs still uses /var/spool/mail,
>
> # LANG= grep /var/spool/mail /usr/bin/* /usr/sbin/* /sbin/* /bin/*

Did you run the equilalent grep for /var/mail  ?  I think you should,
and then do a diff against both lists to get a more accurate picture
of potential compliance problems.

balsa for example... matches for both /var/mail and /var/spool/mail
I don't see how you can make a judgement about uncompliant behavior
based on grep matches for binaries which match both /var/mail and
/var/spool/mail.  There is nothing in the fhs which says that an
application can't look for other directories as well as /var/mail.

And any case, if there are applications which are not looking for
/var/mail like they should, then they are most likely problems you
need to take to the upstream projects if possible and not something
Fedora should be fixing with distro specific packaging unless there is
no upstream developer to go to.

-jef



From kloczek at zie.pg.gda.pl  Tue Mar  7 16:11:18 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Tue, 07 Mar 2006 17:11:18 +0100
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <20060307153750.GC1229196@hiwaay.net>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<20060307000811.GA719216@hiwaay.net>
	<604aa7910603070733x400ce168w66b8c7e3420bda6c@mail.gmail.com>
	<20060307153750.GC1229196@hiwaay.net>
Message-ID: <1141747878.4081.146.camel@kloczek01.pracownicy.zie>

Dnia 07-03-2006, wto o godzinie 09:37 -0600, Chris Adams napisa?(a):
> Once upon a time, Jeff Spaleta <jspaleta at gmail.com> said:
> > On 3/6/06, Chris Adams <cmadams at hiwaay.net> wrote:
> > > Does FHS say /usr/lib/sendmail should just exist or that it should be
> > > used _instead of_ /usr/sbin/sendmail?
> > Friendly advice.. it helps to read up on reference material before
> > asking questions... or else you run the risk of having your questions
> > summarily disregarded.
> 
> I asked the question because the original poster said that programs
> calling /usr/sbin/sendmail were wrong.  I didn't think that was the
> intent of the FHS, so I asked the OP to support the claim.

Yes it IS wrong because it is location of installed sendmail binaries.
FHS says something like "do not use directly /usr/sbin/sendmail binary
but use sendmail command line compliant binary (or symlink to this
binary) which must be installed/avalaible in /usr/lib/sendmail".

If in future sendmail will be changed for handle in diffrent way some
command line switches recognize by sendmail binary using arg[0] runed
by /usr/lib/sendmail link/symlink will allow for this program be fully
*backward compatible*.

Sorry but do not try be so silly and try disscuss correctnes or not of
FHS on this list. Please move your doubts to FHS discussion list.
But first finish read with understaniding this specyfication.

FHS was prepared, disscusses and aproved also by RH people. Also be FHS
compliat it was (looks like still only on paper) one of the main RH
developers goal many years ago.
It will be good finish this process by make some neccessary adjustments
in RH/FC distributions .. nothing more.

Again: ANY kind doubts about FHS fist try clarify on FHS forum.

kloczek



From felipe.alfaro at gmail.com  Tue Mar  7 16:10:35 2006
From: felipe.alfaro at gmail.com (Felipe Alfaro Solana)
Date: Tue, 7 Mar 2006 17:10:35 +0100
Subject: beagle backup (user_xattr)
In-Reply-To: <1141747372.20856.10.camel@golem.boston.redhat.com>
References: <dukalf$qfo$1@sea.gmane.org>
	<1141747372.20856.10.camel@golem.boston.redhat.com>
Message-ID: <6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>

> Beagle does not use extended attributes in FC5 (at least not by
> default), it uses sqlite. So there should be no problem.

Then, why do my files show attributes created by beagle?

# getfattr Desktop
user.Beagle.AttrTime
user.Beagle.Fingerprint
user.Beagle.MTime
user.Beagle.Uid

(BTW, the filesystem is being mounted with -o user_xattr).



From ndbecker2 at gmail.com  Tue Mar  7 16:09:34 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 07 Mar 2006 11:09:34 -0500
Subject: beagle backup (user_xattr)
References: <dukalf$qfo$1@sea.gmane.org>
	<1141747372.20856.10.camel@golem.boston.redhat.com>
Message-ID: <dukb7q$td8$1@sea.gmane.org>

Matthias Clasen wrote:

> On Tue, 2006-03-07 at 10:59 -0500, Neal Becker wrote:
>> How can we backup beagle data, including user_xattr?
>> 
>> What happens if we don't restore user_xattr correctly?  Will beagle
>> re-create it?
>> 
> 
> Beagle does not use extended attributes in FC5 (at least not by
> default), it uses sqlite. So there should be no problem.
> 
> 

Is this documented?  How can I tell?

If I look at beagle docs on the web, it tells me I really should mount with
user_xattr, and that beagle will auto-detect this at runtime.



From dragoran at feuerpokemon.de  Tue Mar  7 16:12:26 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Tue, 07 Mar 2006 17:12:26 +0100
Subject: beagle backup (user_xattr)
In-Reply-To: <6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
References: <dukalf$qfo$1@sea.gmane.org>	<1141747372.20856.10.camel@golem.boston.redhat.com>
	<6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
Message-ID: <440DB0EA.3000105@feuerpokemon.de>

Felipe Alfaro Solana wrote:

>>Beagle does not use extended attributes in FC5 (at least not by
>>default), it uses sqlite. So there should be no problem.
>>    
>>
>
>Then, why do my files show attributes created by beagle?
>
># getfattr Desktop
>user.Beagle.AttrTime
>user.Beagle.Fingerprint
>user.Beagle.MTime
>user.Beagle.Uid
>
>(BTW, the filesystem is being mounted with -o user_xattr).
>  
>
thats the reason, by default filesystems are not mounted with user_xattr 
(why?)



From mclasen at redhat.com  Tue Mar  7 16:15:01 2006
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 07 Mar 2006 11:15:01 -0500
Subject: beagle backup (user_xattr)
In-Reply-To: <6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
References: <dukalf$qfo$1@sea.gmane.org>
	<1141747372.20856.10.camel@golem.boston.redhat.com>
	<6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
Message-ID: <1141748101.20856.12.camel@golem.boston.redhat.com>

On Tue, 2006-03-07 at 17:10 +0100, Felipe Alfaro Solana wrote:
> > Beagle does not use extended attributes in FC5 (at least not by
> > default), it uses sqlite. So there should be no problem.
> 
> Then, why do my files show attributes created by beagle?
> 
> # getfattr Desktop
> user.Beagle.AttrTime
> user.Beagle.Fingerprint
> user.Beagle.MTime
> user.Beagle.Uid
> 
> (BTW, the filesystem is being mounted with -o user_xattr).

Then you turned it on yourself. user_xattr is not on by default.



From felipe.alfaro at gmail.com  Tue Mar  7 16:15:08 2006
From: felipe.alfaro at gmail.com (Felipe Alfaro Solana)
Date: Tue, 7 Mar 2006 17:15:08 +0100
Subject: beagle backup (user_xattr)
In-Reply-To: <440DB0EA.3000105@feuerpokemon.de>
References: <dukalf$qfo$1@sea.gmane.org>
	<1141747372.20856.10.camel@golem.boston.redhat.com>
	<6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
	<440DB0EA.3000105@feuerpokemon.de>
Message-ID: <6f6293f10603070815v4e3db019g1899158444090be6@mail.gmail.com>

> >(BTW, the filesystem is being mounted with -o user_xattr).
> >
> thats the reason, by default filesystems are not mounted with user_xattr
> (why?)

Yes... Any good reason for not doing so?



From kloczek at zie.pg.gda.pl  Tue Mar  7 16:22:13 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Tue, 07 Mar 2006 17:22:13 +0100
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <604aa7910603070757j505b2c9qd0ca71df579b3dff@mail.gmail.com>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<604aa7910603070757j505b2c9qd0ca71df579b3dff@mail.gmail.com>
Message-ID: <1141748533.4081.154.camel@kloczek01.pracownicy.zie>

Dnia 07-03-2006, wto o godzinie 10:57 -0500, Jeff Spaleta napisa?(a):
> On 3/6/06, Tomasz K?oczko <kloczek at zie.pg.gda.pl> wrote:
> > - many programs still uses /var/spool/mail,
> >
> > # LANG= grep /var/spool/mail /usr/bin/* /usr/sbin/* /sbin/* /bin/*
> 
> Did you run the equilalent grep for /var/mail  ?  I think you should,
> and then do a diff against both lists to get a more accurate picture
> of potential compliance problems.

# ( LANG= ; grep /var/mail /bin/* /usr/bin/* /usr/sbin/* /sbin/*;
grep /var/spool/mail /bin/* /usr/bin/* /usr/sbin/* /sbin/* ) | sort |
uniq -d
Binary file /usr/bin/balsa-ab matches
Binary file /usr/bin/balsa matches
Binary file /usr/bin/epic-EPIC4-2.2 matches
Binary file /usr/bin/epic matches
Binary file /usr/bin/gkrellm matches
Binary file /usr/bin/incm matches

So in this kind buggy programs we have some additional subclass :>

> balsa for example... matches for both /var/mail and /var/spool/mail
> I don't see how you can make a judgement about uncompliant behavior
> based on grep matches for binaries which match both /var/mail and
> /var/spool/mail.  There is nothing in the fhs which says that an
> application can't look for other directories as well as /var/mail.

Don't try look on stupid examples ;>
Try answer on some very basig/elementar questio like: if some programs
uses only one location (with full success) why some other tries be "more
smarter" ? :)

kloczek



From mitr at volny.cz  Tue Mar  7 16:24:34 2006
From: mitr at volny.cz (Miloslav Trmac)
Date: Tue, 07 Mar 2006 17:24:34 +0100
Subject: FC more FHS clashes
In-Reply-To: <1141747878.4081.146.camel@kloczek01.pracownicy.zie>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>	<1141683624.29230.0.camel@localhost.localdomain>	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>	<1141685100.3862.14.camel@mentorng.gurulabs.com>	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>	<20060307000811.GA719216@hiwaay.net>	<604aa7910603070733x400ce168w66b8c7e3420bda6c@mail.gmail.com>	<20060307153750.GC1229196@hiwaay.net>
	<1141747878.4081.146.camel@kloczek01.pracownicy.zie>
Message-ID: <440DB3C2.4040508@volny.cz>

Tomasz K?oczko napsal(a):
> Dnia 07-03-2006, wto o godzinie 09:37 -0600, Chris Adams napisa?(a):
>> I asked the question because the original poster said that programs
>> calling /usr/sbin/sendmail were wrong.  I didn't think that was the
>> intent of the FHS, so I asked the OP to support the claim.
> 
> Yes it IS wrong because it is location of installed sendmail binaries.
> FHS says something like "do not use directly /usr/sbin/sendmail binary
> but use sendmail command line compliant binary (or symlink to this
> binary) which must be installed/avalaible in /usr/lib/sendmail".
Please provide an exact FHS quote, I really can't find any language to
that effect, and Jeff has already quoted a footnote with the opposite
requirement.

> If in future sendmail will be changed for handle in diffrent way some
> command line switches recognize by sendmail binary using arg[0] runed
> by /usr/lib/sendmail link/symlink will allow for this program be fully
> *backward compatible*.
First, that would be a very unreliable way to detect the execution path.
Second, sendmail breaking sendmail is just not likely, and can always be
handled by pointing the alternatives symlink Fedora has at
/usr/sbin/sendmail to a wrapper script.

> Sorry but do not try be so silly and try disscuss correctnes or not of
> FHS on this list. Please move your doubts to FHS discussion list.
> But first finish read with understaniding this specyfication.
Most posters in this thread seem to agree /usr/sbin/sendmail is the
correct place, thus it is your task to provide convincing arguments, if
not patches, if you want to change the Fedora behavior.
	Mirek



From nigel.metheringham at dev.intechnology.co.uk  Tue Mar  7 16:25:03 2006
From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham)
Date: Tue, 07 Mar 2006 16:25:03 +0000
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <1141747878.4081.146.camel@kloczek01.pracownicy.zie>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<20060307000811.GA719216@hiwaay.net>
	<604aa7910603070733x400ce168w66b8c7e3420bda6c@mail.gmail.com>
	<20060307153750.GC1229196@hiwaay.net>
	<1141747878.4081.146.camel@kloczek01.pracownicy.zie>
Message-ID: <1141748703.25615.29.camel@localhost.localdomain>

On Tue, 2006-03-07 at 17:11 +0100, Tomasz K?oczko wrote:
> Yes it IS wrong because it is location of installed sendmail binaries.
> FHS says something like "do not use directly /usr/sbin/sendmail binary
> but use sendmail command line compliant binary (or symlink to this
> binary) which must be installed/avalaible in /usr/lib/sendmail".

Does it bollocks!

http://www.pathname.com/fhs/pub/fhs-2.3.html#AEN1402
        For historical reasons, /usr/lib/sendmail must be a symbolic
        link to /usr/sbin/sendmail if the latter exists. [24]

http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1402
        Some executable commands such as makewhatis and sendmail have
        also been traditionally placed in /usr/lib. makewhatis is an
        internal binary and must be placed in a binary directory; users
        access only catman. Newer sendmail binaries are now placed by
        default in /usr/sbin. Additionally, systems using a
        sendmail-compatible mail transfer agent must
        provide /usr/sbin/sendmail as a symbolic link to the appropriate
        executable.

There are 2 other passing references to sendmail which are not relevant
to this.

There is no reference to not directly calling /usr/sbin/sendmail (or
even calling it at all)

	Nigel.
-- 
[ Nigel Metheringham           Nigel.Metheringham at InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]




From kloczek at zie.pg.gda.pl  Tue Mar  7 16:41:24 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Tue, 07 Mar 2006 17:41:24 +0100
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <1141748703.25615.29.camel@localhost.localdomain>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<20060307000811.GA719216@hiwaay.net>
	<604aa7910603070733x400ce168w66b8c7e3420bda6c@mail.gmail.com>
	<20060307153750.GC1229196@hiwaay.net>
	<1141747878.4081.146.camel@kloczek01.pracownicy.zie>
	<1141748703.25615.29.camel@localhost.localdomain>
Message-ID: <1141749684.4081.159.camel@kloczek01.pracownicy.zie>

Dnia 07-03-2006, wto o godzinie 16:25 +0000, Nigel Metheringham
napisa?(a):
[..]
> There is no reference to not directly calling /usr/sbin/sendmail (or
> even calling it at all)

OK you are right.
Case /usr/sbin/sendmail can be removed from list incompatibilities.

kloczek




From cmadams at hiwaay.net  Tue Mar  7 16:42:59 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 7 Mar 2006 10:42:59 -0600
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <1141748533.4081.154.camel@kloczek01.pracownicy.zie>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<604aa7910603070757j505b2c9qd0ca71df579b3dff@mail.gmail.com>
	<1141748533.4081.154.camel@kloczek01.pracownicy.zie>
Message-ID: <20060307164259.GE1229196@hiwaay.net>

Once upon a time, Tomasz Koczko <kloczek at zie.pg.gda.pl> said:
> # ( LANG= ; grep /var/mail /bin/* /usr/bin/* /usr/sbin/* /sbin/*;
> grep /var/spool/mail /bin/* /usr/bin/* /usr/sbin/* /sbin/* ) | sort |
> uniq -d
> Binary file /usr/bin/balsa-ab matches
> Binary file /usr/bin/balsa matches
> Binary file /usr/bin/epic-EPIC4-2.2 matches
> Binary file /usr/bin/epic matches
> Binary file /usr/bin/gkrellm matches
> Binary file /usr/bin/incm matches

Again, how many of those try $MAIL first?  That should always be set, so
falling back to /var/mail, /var/spool/mail, or /dev/null should not be
flagged as a bug.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From jspaleta at gmail.com  Tue Mar  7 17:02:29 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 7 Mar 2006 12:02:29 -0500
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <20060307164259.GE1229196@hiwaay.net>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<604aa7910603070757j505b2c9qd0ca71df579b3dff@mail.gmail.com>
	<1141748533.4081.154.camel@kloczek01.pracownicy.zie>
	<20060307164259.GE1229196@hiwaay.net>
Message-ID: <604aa7910603070902k2b06fcadr55018abe35fb41de@mail.gmail.com>

On 3/7/06, Chris Adams <cmadams at hiwaay.net> wrote:
> Again, how many of those try $MAIL first?  That should always be set, so
> falling back to /var/mail, /var/spool/mail, or /dev/null should not be
> flagged as a bug.

balsa is even smarter than that... first it checkes $MAIL and then it
iterates across a set of guesses starting with /var/mail.

I think I've learned a value lesson today. And that lesson is the
original poster is on crack.

Out of everything in his original /var/spool/mail hitlist which "may"
be a problem the only thing I can see so far is dhcp, which seems to
have a list of directories to try which doesn't include /var/mail  on
linux.   Needs to be addressed with upstream if possible.

<quote from linux.h in dhcp src code>
const char *dirs[] = {
        "/tmp",
        "/usr/tmp",
        ".",
        "/",
        "/var/spool",
        "/dev",
        "/var/spool/mail",
        "/home",
        "/usr/home",
        NULL
};
</quote>


<quote from libbalsa.c from balsa src code>
libbalsa_guess_mail_spool(void)
{
    int i;
    gchar *env;
    gchar *spool;
    static const gchar *guesses[] = {
        "/var/mail/",
        "/var/spool/mail/",
        "/usr/spool/mail/",
        "/usr/mail/",
        NULL
    };

    if ((env = getenv("MAIL")) != NULL)
        return g_strdup(env);

    if ((env = getenv("USER")) != NULL) {
        for (i = 0; guesses[i] != NULL; i++) {
            spool = g_strconcat(guesses[i], env, NULL);

            if (g_file_test(spool, G_FILE_TEST_EXISTS))
                return spool;

            g_free(spool);
        }
    }

    /* libmutt's configure.in indicates that this
     * ($HOME/mailbox) exists on
     * some systems, and it's a good enough default if we
     * can't guess it any other way. */
    return g_strconcat(g_get_home_dir(), "/mailbox", NULL);
}
</quote>


-jef



From jspaleta at gmail.com  Tue Mar  7 16:46:05 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 7 Mar 2006 11:46:05 -0500
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <1141748533.4081.154.camel@kloczek01.pracownicy.zie>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<604aa7910603070757j505b2c9qd0ca71df579b3dff@mail.gmail.com>
	<1141748533.4081.154.camel@kloczek01.pracownicy.zie>
Message-ID: <604aa7910603070846p8979adnf258ecea1e4fc35b@mail.gmail.com>

On 3/7/06, Tomasz K?oczko <kloczek at zie.pg.gda.pl> wrote:
> So in this kind buggy programs we have some additional subclass :>
That is a matter of opinion, and I happen to disagree. But if you
think these applications are buggy.. please by all means contact the
upstream developers and provide patches to remove all references to
/var/spool/mail. If balsa is checking both /var/mail and
/var/spool/mail locations then its probably not a fedora specific
issue and is something you should take to the upstream balsa
developers and have them strip the references to /var/spool/mail from
the upstream codebase if you feel balsa is buggy.

Similiarly with each and every application which you have found. Since
you took the time to hunt this sort of stuff down, I'd hate for the
upstream projects, and thus all the other distributors, to not benefit
from your extraordinary efforts.

> Don't try look on stupid examples ;>

My examples can be no better than your original short list. Perhaps
this whole issue is stupid and not worth discussing at all.  Either
way, I expect you to follow up with the upstream developers for each
of the applications you think are buggy and submit patches.

> Try answer on some very basig/elementar questio like: if some programs
> uses only one location (with full success) why some other tries be "more
> smarter" ? :)

These are questions you need to ask the upstream developers of each
affected program, not me nor the fedora maintainers of these packages.
If you need help figuring out how to contact each upstream project so
you can attempt to get these potential issues corrected, I'm sure that
could be arranged.

Have a nice day

-jef



From gianluca.cecchi at gmail.com  Tue Mar  7 17:32:56 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Tue, 7 Mar 2006 18:32:56 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
Message-ID: <561c252c0603070932t5669947w15b5b4cf6ad46b50@mail.gmail.com>

I could help for testing installations these latest days.
I have a Dell 6650 with 4x3GHz cpus (8 with HT enabled) and 4GB of ram.
 I can use it for 2-3 weeks.
I have configured the dell with pxe boot, picking up kickstart file
via http from one server and installing via nfs from another server
(this last is a FC5 X86_64 workstation).
It works with fc5 test3. I'm going to automate the process of updating
pxeboot fc 5 images and nfs repository, so that in about 25 minutes I
can have the machine installed from scratch.
and test on a daily basis or request basis (matching with my free
time, of course...)
Some questions:
- any particular %packages directive is suggested for better help?
can I use something like @all ? I have not seen in interactive
installation a way to install everything, like before...
If anyone has any test to be run on this machine, I'm available.

lspci of this server gives:
00:00.0 Host bridge: Broadcom CMIC-HE (rev 22)
00:00.1 Host bridge: Broadcom CMIC-HE
00:00.2 Host bridge: Broadcom CMIC-HE
00:00.3 Host bridge: Broadcom CMIC-HE
00:03.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02)
00:04.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00:0f.0 Host bridge: Broadcom CSB5 South Bridge (rev 93)
00:0f.1 IDE interface: Broadcom CSB5 IDE Controller (rev 93)
00:0f.2 USB Controller: Broadcom OSB4/CSB5 OHCI USB Controller (rev 05)
00:0f.3 ISA bridge: Broadcom CSB5 LPC bridge
00:10.0 Host bridge: Broadcom CIOB30 (rev 03)
00:10.2 Host bridge: Broadcom CIOB30 (rev 03)
00:11.0 Host bridge: Broadcom CIOB30 (rev 03)
00:11.2 Host bridge: Broadcom CIOB30 (rev 03)
00:12.0 Host bridge: Broadcom CIOB30 (rev 03)
00:12.2 Host bridge: Broadcom CIOB30 (rev 03)
03:01.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID (rev 01)
08:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5700
Gigabit Ethernet (rev 14)
08:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5700
Gigabit Ethernet (rev 14)
13:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit
Ethernet Controller (Copper) (rev 01)
13:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit
Ethernet Controller (Copper) (rev 01)



From kloczek at zie.pg.gda.pl  Tue Mar  7 17:45:00 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Tue, 07 Mar 2006 18:45:00 +0100
Subject: FC more FHS clashes (was: BIND and FHS)
In-Reply-To: <20060307164259.GE1229196@hiwaay.net>
References: <1141499698.3522.10.camel@concord2.proximity.on.ca>
	<1141683624.29230.0.camel@localhost.localdomain>
	<1141684098.4081.37.camel@kloczek01.pracownicy.zie>
	<1141685100.3862.14.camel@mentorng.gurulabs.com>
	<1141687916.4081.58.camel@kloczek01.pracownicy.zie>
	<604aa7910603070757j505b2c9qd0ca71df579b3dff@mail.gmail.com>
	<1141748533.4081.154.camel@kloczek01.pracownicy.zie>
	<20060307164259.GE1229196@hiwaay.net>
Message-ID: <1141753500.15466.25.camel@kloczek01.pracownicy.zie>

Dnia 07-03-2006, wto o godzinie 10:42 -0600, Chris Adams napisa?(a): 
> Once upon a time, Tomasz Koczko <kloczek at zie.pg.gda.pl> said:
> > # ( LANG= ; grep /var/mail /bin/* /usr/bin/* /usr/sbin/* /sbin/*;
> > grep /var/spool/mail /bin/* /usr/bin/* /usr/sbin/* /sbin/* ) | sort |
> > uniq -d
> > Binary file /usr/bin/balsa-ab matches
> > Binary file /usr/bin/balsa matches
> > Binary file /usr/bin/epic-EPIC4-2.2 matches
> > Binary file /usr/bin/epic matches
> > Binary file /usr/bin/gkrellm matches
> > Binary file /usr/bin/incm matches
> 
> Again, how many of those try $MAIL first?  That should always be set, so
> falling back to /var/mail, /var/spool/mail, or /dev/null should not be
> flagged as a bug.

But mainly I'm not talking about using first $MAIL and after this
fallback to /var/mail, /var/spool/mail, or /dev/null :)
It is good question for all MUA is current behavior :)

In fist email in this thread you can find some programs which uses
ONLY /var/spool/mail.
THIS breaks FHS.

Using additionaly /var/spool/mail path and any other paths in hardcoded
configuration still IS redundand and it is kind of bug .. yes
non-critical from point of view FHS compliance but still it is bug
because using first $MAIL and after this fallback to /var/mail allow
place in $MAIL also /var/spool/mail if it is neccessary.
It can be fixed during audit all programs dor use $MAIL -> /var/mail.
Why ? Because it allow prepare probably most simpler automated test for
FHS compliance.
Do you see this now ? :)

Simple: code for handle something other than $MAIL and /var/mail can be
removed without removing SINGLE neccessary functionality and it allow
also minimize size of binary programs.
Q: are you still look on balsa behavior as correct ? :)

Very simillar bug sits in for example /usr/bin/info:

$ strings /usr/bin/info | grep /usr
/usr/local/info:/usr/info:/usr/local/lib/info:/usr/lib/info:/usr/local/gnu/info:/usr/local/gnu/lib/info:/usr/gnu/info:/usr/gnu/lib/info:/opt/gnu/info:/usr/share/info:/usr/share/lib/info:/usr/local/share/info:/usr/local/share/lib/info:/usr/gnu/lib/emacs/info:/usr/local/gnu/lib/emacs/info:/usr/local/lib/emacs/info:/usr/local/emacs/info:.
/usr/share/locale
/usr/share/info

This program have hardcoded many paths which aren't used and using this
hardcoded DEFAULT_INFOPATH makes longer info run time.
But .. if any path from above list will be neccesary in some system it
still can be placed in $INFOPATH. Above can be fixed by apply patch
from:
http://cvs.pld.org.pl/SOURCES/texinfo-DEFAULT_INFOPATH.patch?rev=1.1

kloczek



From ihok at hotmail.com  Tue Mar  7 17:51:00 2006
From: ihok at hotmail.com (Jack Tanner)
Date: Tue, 07 Mar 2006 12:51:00 -0500
Subject: Evince claims pdf password protected
In-Reply-To: <440D97CC.3000508@fedoraproject.org>
References: <1141741699.2993.5.camel@linux>
	<440D97CC.3000508@fedoraproject.org>
Message-ID: <dukh64$km3$1@sea.gmane.org>

Rahul Sundaram wrote:
> Hans Kristian Rosbach wrote:
> 
>> Opening
>> http://www.highpoint-tech.com/manuals/BIOS%20Update%20User%20Manual.pdf
>> in Document Viewer (Evince) fails and it clams it is password protected.
>> If I open it using Xpdf it works just fine.
>>
>> File can be found at
>> http://www.highpoint-tech.com/USA/bios_rr1820a.htm
>> link is known as "BIOS User Manual". I used Firefox.
>>
>>  
>>
> Similar issue with http://www.acm.org/usacm/weblog/wp-content/DRM.pdf. 
> Related article with comments at http://lwn.net/Articles/174448/.

Interestingly enough, Acrobat 5 (not Acrobat Reader, even) on Windows 
chokes on the ACM DRM statement as well. This probably all belongs in 
Bugzilla, though, or at least on the Evince mailing list.



From dax at gurulabs.com  Tue Mar  7 17:55:49 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Tue, 07 Mar 2006 10:55:49 -0700
Subject: ordinary kernels install when choosing xen
In-Reply-To: <561c252c0603070334m500a71b5ybd55e29efafa0396@mail.gmail.com>
References: <561c252c0603070334m500a71b5ybd55e29efafa0396@mail.gmail.com>
Message-ID: <1141754149.3545.18.camel@mentorng.gurulabs.com>

On Tue, 2006-03-07 at 12:34 +0100, Gianluca Cecchi wrote:
> If you choose xen in installation, only kernel-xen-hypervisor is
> installed, not the ordinary uni/smp kernels on i686.
> Is this intentional? How could one install both xen and ordinary
> kernels, without doing it manually after install?

See:

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

Seem it was resolved with:

"We're taking Xen out as a user-visible option for FC5 based on the fact
that it's not ready."

Dax Kelson
Guru Labs



From aph at redhat.com  Tue Mar  7 18:01:39 2006
From: aph at redhat.com (Andrew Haley)
Date: Tue, 7 Mar 2006 18:01:39 +0000
Subject: ordinary kernels install when choosing xen
In-Reply-To: <1141754149.3545.18.camel@mentorng.gurulabs.com>
References: <561c252c0603070334m500a71b5ybd55e29efafa0396@mail.gmail.com>
	<1141754149.3545.18.camel@mentorng.gurulabs.com>
Message-ID: <17421.51843.304403.350462@zapata.pink>

Dax Kelson writes:
 > On Tue, 2006-03-07 at 12:34 +0100, Gianluca Cecchi wrote:
 > > If you choose xen in installation, only kernel-xen-hypervisor is
 > > installed, not the ordinary uni/smp kernels on i686.
 > > Is this intentional? How could one install both xen and ordinary
 > > kernels, without doing it manually after install?
 > 
 > See:
 > 
 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181618
 > 
 > Seem it was resolved with:
 > 
 > "We're taking Xen out as a user-visible option for FC5 based on the fact
 > that it's not ready."

I'm sure that's the right thing to do.  I'm very excited about Xen,
but the last thing we need is for it to get a reputation for
unreliability and difficulty in use.

Andrew.



From clydekunkel7734 at cox.net  Tue Mar  7 19:44:41 2006
From: clydekunkel7734 at cox.net (Clyde E. Kunkel)
Date: Tue, 07 Mar 2006 14:44:41 -0500
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <440CD6DC.6020903@redhat.com>
References: <440CD6DC.6020903@redhat.com>
Message-ID: <440DE2A9.5040302@cox.net>

Warren Togami wrote:
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=150222&hide_resolved=1 
> 
> 
> We are now attempting to fix some last minute problems.  Your help would 
> be greatly appreciated in finding solutions for the problems listed in 
> the above FC5 Blocker list.
> 
> Your testing of rawhide nightly tree installs (while not guaranteed to 
> work) is very valuable at this point.  We need to know if there are any 
> critical installation issues that would effect FC5 install, like the 
> nasty Bug #159026.  Please also test upgrades of FC3 or FC4 systems to 
> the nightly rawhide tree and report any problems that you see to Bugzilla.
> 
> Bugzilla is the official and best way to get reports to the developers. 
>  Complaints posted only to a mailing list are very likely to be lost in 
> the bulk.  Bug reports have status, comments and resolution states so at 
> least there is a chance of tracking your issue.
> 
> Thank you for using Fedora.
> 
> Warren Togami
> wtogami at redhat.com
> 

During install of todays development tree, could not mount the home LV 
during firstboot.  Had to use selinux=0 kernel parm in grub.conf.

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


-- 
Regards,

Old Fart
(my reply-to address is "munged" to defeat spambots)



From casimiro.barreto at gmail.com  Wed Mar  8 00:24:59 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 07 Mar 2006 21:24:59 -0300
Subject: PANIC on RPMDB... can't even get version numbers for installed
	packages...
Message-ID: <440E245B.6030505@gmail.com>

After update done 00:23 08/Mar/2006 the following  happened (so  I can't 
even get version for packages...):
 
[root at terra ~]# yum update
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from dbenv->open: DB_RUNRECOVERY: Fatal error, 
run database recovery
error: cannot open Packages index using db3 -  (-30977)
error: cannot open Packages database in /var/lib/rpm
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 80, in main
    base.getOptionsConfig(args)
  File "/usr/share/yum-cli/cli.py", line 177, in getOptionsConfig
    self.doConfigSetup(fn=opts.conffile, root=root)
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 102, in 
doConfigSetup
    self.conf = config.readMainConfig(fn, root)
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 573, in 
readMainConfig
    vars['releasever'] = _getsysver(earlyconf.installroot, 
earlyconf.distroverpkg)
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 673, in 
_getsysver
    idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed
[root at terra ~]# rpm -qa | grep rpm
rpmdb: *PANIC:* fatal region error detected; run recovery
erro: erro do db4 (-30977) do dbenv->open: DB_RUNRECOVERY: Fatal error, 
run database recovery
erro: n?o consigo abrir o ?ndice de Packages usando o db3 -  (-30977)
erro: n?o consigo abrir a base de dados Packages em /var/lib/rpm
[root at terra ~]#

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

From rstrode at redhat.com  Wed Mar  8 01:23:28 2006
From: rstrode at redhat.com (Ray Strode)
Date: Tue, 07 Mar 2006 20:23:28 -0500
Subject: where is ~/.xsession-errors?
In-Reply-To: <m264msr01a.fsf@sl392.st-edmunds.cam.ac.uk>
References: <m2k6b8zjbf.fsf@sl392.st-edmunds.cam.ac.uk>
	<20060305222650.GB28409@plain.rackshack.net>
	<m264msr01a.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <1141781008.2296.1.camel@halflap>

Hi,
> Rudi Chiarito <nutello at sweetness.com> writes:
> 
> > On Sun, Mar 05, 2006 at 09:13:24PM +0000, Leon wrote:
> >> There is no ~/.xsession-errors or the like in my home dir. Any ideas?
> >
> > Look for /tmp/xses-USERNAME.RANDOM
> >
> > -- 
> > Rudi
> 
> Thank you. 
> 
> By the way, any clue why such a change?
Files that are directly in the user's home directory are hard to lock
down with our selinux policy I guess.

--Ray



From dax at gurulabs.com  Wed Mar  8 04:06:05 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Tue, 07 Mar 2006 21:06:05 -0700
Subject: kernel panic during Mar 7th rawhide install
In-Reply-To: <440CD6DC.6020903@redhat.com>
References: <440CD6DC.6020903@redhat.com>
Message-ID: <1141790765.4222.3.camel@mentorng.gurulabs.com>

On Mon, 2006-03-06 at 19:42 -0500, Warren Togami wrote:
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=150222&hide_resolved=1
> 
> We are now attempting to fix some last minute problems.  Your help would 
> be greatly appreciated in finding solutions for the problems listed in 
> the above FC5 Blocker list.
> 
> Your testing of rawhide nightly tree installs (while not guaranteed to 
> work) is very valuable at this point.  We need to know if there are any 
> critical installation issues that would effect FC5 install, like the 
> nasty Bug #159026.  Please also test upgrades of FC3 or FC4 systems to 
> the nightly rawhide tree and report any problems that you see to Bugzilla.

I tried doing a fresh install of March 7th rawhide on a AMD64 (but using
i686). I got a kernel panic when the install was almost done.

filed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184350

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

From pnasrat at redhat.com  Wed Mar  8 05:02:26 2006
From: pnasrat at redhat.com (Paul Nasrat)
Date: Wed, 08 Mar 2006 00:02:26 -0500
Subject: PANIC on RPMDB... can't even get version numbers for installed
	packages...
In-Reply-To: <440E245B.6030505@gmail.com>
References: <440E245B.6030505@gmail.com>
Message-ID: <1141794146.2550.2.camel@enki.eridu>

On Tue, 2006-03-07 at 21:24 -0300, Casimiro de Almeida Barreto wrote:
> After update done 00:23 08/Mar/2006 the following  happened (so  I
> can't even get version for packages...):
>  
> [root at terra ~]# yum update
> rpmdb: PANIC: fatal region error detected; run recovery
> error: db4 error(-30977) from dbenv->open: DB_RUNRECOVERY: Fatal
> error, run database recovery
> error: cannot open Packages index using db3 -  (-30977)
> error: cannot open Packages database in /var/lib/rpm

rpm issue, what steps did you take up to that point? If you experienced
any failures what were they?

Please back up your rpmdb (/var/lib/rpm) and create a bugzilla,
preferably with the history above.

Paul



From perbj at sbcglobal.net  Wed Mar  8 05:55:58 2006
From: perbj at sbcglobal.net (Per Bjornsson)
Date: Tue, 07 Mar 2006 21:55:58 -0800
Subject: rawhide report: 20060307 changes
In-Reply-To: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>
References: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>
Message-ID: <1141797358.2294.2.camel@localhost.localdomain>

On Tue, 2006-03-07 at 04:24 -0500, Build System wrote:

> NetworkManager-0.6.0-2
> ----------------------
> * Mon Mar 06 2006 Dan Williams <dcbw at redhat.com> 0.6.0-2
> - Don't let wpa_supplicant perform scanning with non-WPA drivers

Awesome. Now NetworkManager works for me again, it was going completely
nuts earlier in the FC5 devel cycle (madwifi-old, no encryption). Thanks
a million!

Per




From saddateh at gmail.com  Wed Mar  8 06:29:06 2006
From: saddateh at gmail.com (Sadda Teh)
Date: Wed, 8 Mar 2006 01:29:06 -0500
Subject: FC5 Final Release
Message-ID: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>

Is FC5 still on schedule to be release March 15th? Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060308/ae46932a/attachment.htm>

From sundaram at fedoraproject.org  Wed Mar  8 06:38:41 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 12:08:41 +0530
Subject: FC5 Final Release
In-Reply-To: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
Message-ID: <440E7BF1.4070502@fedoraproject.org>

Sadda Teh wrote:

>Is FC5 still on schedule to be release March 15th? Thanks.
>
>  
>
Yes it is.

-- 
Rahul 





From ivg2 at cornell.edu  Wed Mar  8 08:04:32 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Wed, 08 Mar 2006 03:04:32 -0500
Subject: FC5 Final Release
In-Reply-To: <440E7BF1.4070502@fedoraproject.org>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
	<440E7BF1.4070502@fedoraproject.org>
Message-ID: <440E9010.9070202@cornell.edu>


> Yes it is.
Maybe it's a good time to make it bootable then?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182008

I also have heard nothing from the Xorg bugzilla regarding making the nv 
driver work:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182396

Then there's the minor inconvenience of gnome-netstatus being broken 
with my atheros chip:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861









From sundaram at fedoraproject.org  Wed Mar  8 08:10:44 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 13:40:44 +0530
Subject: FC5 Final Release
In-Reply-To: <440E9010.9070202@cornell.edu>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>
	<440E9010.9070202@cornell.edu>
Message-ID: <440E9184.8030009@fedoraproject.org>

Ivan Gyurdiev wrote:

>
>> Yes it is.
>
> Maybe it's a good time to make it bootable then?
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182008

It boots on my system so that wouldnt apply as a general question but 
all of these bugs are potential blockers. Would have been better to post 
to the list earlier though.

>
> I also have heard nothing from the Xorg bugzilla regarding making the 
> nv driver work:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182396
>
> Then there's the minor inconvenience of gnome-netstatus being broken 
> with my atheros chip:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861
>
https://www.redhat.com/archives/fedora-devel-list/2006-March/msg00261.html.  
Crashers, regressions and stuff not working should be blocking this bug.


-- 
Rahul 





From alexl at redhat.com  Wed Mar  8 08:19:12 2006
From: alexl at redhat.com (Alexander Larsson)
Date: Wed, 08 Mar 2006 09:19:12 +0100
Subject: beagle backup (user_xattr)
In-Reply-To: <dukalf$qfo$1@sea.gmane.org>
References: <dukalf$qfo$1@sea.gmane.org>
Message-ID: <1141805952.15569.127.camel@greebo>

On Tue, 2006-03-07 at 10:59 -0500, Neal Becker wrote:
> How can we backup beagle data, including user_xattr?
> 
> What happens if we don't restore user_xattr correctly?  Will beagle re-create it?

beagle uses the xattrs to store information about if/when/how the file
was indexed. I think its fine if this information gets lost, although it
will cause beagle to re-index the file.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a scrappy chivalrous boxer She's a wealthy belly-dancing opera singer 
from a secret island of warrior women. They fight crime! 



From sundaram at fedoraproject.org  Wed Mar  8 08:16:51 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 13:46:51 +0530
Subject: FC5 Final Release
In-Reply-To: <440E9010.9070202@cornell.edu>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>
	<440E9010.9070202@cornell.edu>
Message-ID: <440E92F3.60905@fedoraproject.org>

Ivan Gyurdiev wrote:

>
>> Yes it is.
>
> Maybe it's a good time to make it bootable then?
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182008
>
> I also have heard nothing from the Xorg bugzilla regarding making the 
> nv driver work:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182396

The information requested from you needs to be supplied on this report.

>
> Then there's the minor inconvenience of gnome-netstatus being broken 
> with my atheros chip:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861

madwifi drivers arent providing in Fedora so this one doesnt seem like a 
blocker to me.

-- 
Rahul 





From alexl at redhat.com  Wed Mar  8 08:21:19 2006
From: alexl at redhat.com (Alexander Larsson)
Date: Wed, 08 Mar 2006 09:21:19 +0100
Subject: beagle backup (user_xattr)
In-Reply-To: <6f6293f10603070815v4e3db019g1899158444090be6@mail.gmail.com>
References: <dukalf$qfo$1@sea.gmane.org>
	<1141747372.20856.10.camel@golem.boston.redhat.com>
	<6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
	<440DB0EA.3000105@feuerpokemon.de>
	<6f6293f10603070815v4e3db019g1899158444090be6@mail.gmail.com>
Message-ID: <1141806080.15569.131.camel@greebo>

On Tue, 2006-03-07 at 17:15 +0100, Felipe Alfaro Solana wrote:
> > >(BTW, the filesystem is being mounted with -o user_xattr).
> > >
> > thats the reason, by default filesystems are not mounted with user_xattr
> > (why?)
> 
> Yes... Any good reason for not doing so?

Beagle was added sort of late in the cycle, and changing the default
mount options needs changes in anaconda etc, so we (the desktop team)
really hasn't been pushing this. At some point we should sit down with
the installer people and the kernel filesystem people and figure out if
and when we should set user_xattr.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a deeply religious Republican filmmaker from the Mississippi delta. She's 
a time-travelling motormouth safe cracker married to the Mob. They fight 
crime! 



From ivg2 at cornell.edu  Wed Mar  8 08:22:00 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Wed, 08 Mar 2006 03:22:00 -0500
Subject: FC5 Final Release
In-Reply-To: <440E92F3.60905@fedoraproject.org>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>	<440E9010.9070202@cornell.edu>
	<440E92F3.60905@fedoraproject.org>
Message-ID: <440E9428.5090604@cornell.edu>


>> I also have heard nothing from the Xorg bugzilla regarding making the 
>> nv driver work:
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182396
>
> The information requested from you needs to be supplied on this report.
It was supplied... in the freedesktop bugzilla.
M. Harris said I should communicate directly with upstream
(though upstream doesn't seem to be communicating back).

>> Then there's the minor inconvenience of gnome-netstatus being broken 
>> with my atheros chip:
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861
>
> madwifi drivers arent providing in Fedora so this one doesnt seem like 
> a blocker to me.
I wouldn't call any bug in the netstatus applet a blocker, but it's not 
nice that there's no response from the maintainer.



From hk at isphuset.no  Wed Mar  8 08:31:50 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Wed, 08 Mar 2006 09:31:50 +0100
Subject: FC5 Final Release
In-Reply-To: <440E7BF1.4070502@fedoraproject.org>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
	<440E7BF1.4070502@fedoraproject.org>
Message-ID: <1141806710.2993.15.camel@linux>

On Wed, 2006-03-08 at 12:08 +0530, Rahul Sundaram wrote:
> Sadda Teh wrote:
> 
> >Is FC5 still on schedule to be release March 15th? Thanks.
> >
> Yes it is.

Just a general question.. 
Will anaconda not display estimated disk usage when
customizing package choices anymore? I have found the estimate
quite important sometimes when installing on machines
with little disk and a user that wants all the bling.

No biggie, I'll just miss it.

-HK



From buildsys at redhat.com  Wed Mar  8 08:26:05 2006
From: buildsys at redhat.com (Build System)
Date: Wed, 8 Mar 2006 03:26:05 -0500
Subject: rawhide report: 20060308 changes
Message-ID: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-11.0.1-1
-----------------
* Tue Mar 07 2006 Jeremy Katz <katzj at redhat.com> - 11.0.1-1
- Fix text display for rescue CD isolinux
- Fix usb-storage not showing up by default (#181739)

* Tue Mar 07 2006 Jeremy Katz <katzj at redhat.com> - 11.0.0-1
- Really fix the file contexts on the directories (#182252)
- More fixing for Xen kernel naming
- Branched, turn off betanag

autoconf213-2.13-12
-------------------
* Mon Feb 27 2006 Karsten Hopp <karsten at redhat.de> 2.13-12
- require m4 >= 1.1

beagle-0.2.2-2
--------------
* Tue Mar 07 2006 Alexander Larsson <alexl at redhat.com> - 0.2.2-2
- Fix beagle-craw-system NullPtrException

* Tue Mar 07 2006 Alexander Larsson <alexl at redhat.com> - 0.2.2-1
- update to 0.2.2

bluez-utils-2.25-3
------------------
* Tue Mar 07 2006 Jeremy Katz <katzj at redhat.com> - 2.25-3
- more initscript tweaking

control-center-1:2.13.92-2
--------------------------
* Wed Feb 15 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-2
- Add a missing BuildRequires

doxygen-1:1.4.6-2
-----------------
* Mon Mar 06 2006 Than Ngo <than at redhat.com> 1:1.4.6-2
- fix build problem #184042

e2fsprogs-1.38-11
-----------------
* Tue Mar 07 2006 David Cantrell <dcantrell at redhat.com> - 1.38-11
- BuildRequires pkgconfig

* Tue Mar 07 2006 David Cantrell <dcantrell at redhat.com> - 1.38-10
- Disable /etc/blkid.tab caching if time is set before epoch (#182188)

eclipse-1:3.1.2-1jpp_13fc
-------------------------
* Tue Mar 07 2006 Andrew Overholt <overholt at redhat.com> 3.1.2-1jpp_13fc
- One more small help fix (include tomcatwrapper.jar o.e.tomcat manifest).

* Fri Mar 03 2006 Andrew Overholt <overholt at redhat.com> 3.1.2-1jpp_12fc
- Only build with a native ecj on x86{,_64}

* Tue Feb 28 2006 Andrew Overholt <overholt at redhat.com> 3.1.2-1jpp_12fc
- Update to tomcat 5.5 (e.o#98371).
- Don't build on ppc64 until we get the tomcat situation straightened out.

eclipse-cdt-1:3.0.2-1jpp_2fc
----------------------------
* Tue Mar 07 2006 Andrew Overholt <overholt at redhat.com> 3.0.2-1jpp_2fc
- Bump release.

* Mon Feb 13 2006 Andrew Overholt <overholt at redhat.com> 3.0.2-1jpp_1fc
- 3.0.2.

glib2-2.10.1-1
--------------
* Tue Mar 07 2006 Matthias Clasen <mclasen at redhat.com> - 2.10.1-1
- Update to 2.10.1

glibc-2.4-4
-----------
* Tue Mar 07 2006 Roland McGrath <roland at redhat.com> 2.4-4
- back up %{ix86} gdb conflicts to < 6.3.0.0-1.111

* Tue Mar 07 2006 Jakub Jelinek <jakub at redhat.com> 2.4-3
- really fix rintl on ppc64

* Tue Mar 07 2006 Jakub Jelinek <jakub at redhat.com> 2.4-2
- accurate unwind info for lowlevellock.h stubs on %{ix86}
- fix ppc/ppc64 ceill, floorl, rintl, roundl and truncl (BZ#2423)

gnome-applets-1:2.13.90-4
-------------------------
* Tue Mar 07 2006 Ray Strode <rstrode at redhat.com> - 2.13.90-4
- ref some objects given to us by gstreamer

kernel-2.6.15-1.2032_FC5
------------------------
* Tue Mar 07 2006 John W. Linville <linville at redhat.com>
- Temporarily disable automatic load of bcm43xx driver (causes hangs on some systems)

* Tue Mar 07 2006 Stephen Tweedie <sct at redhat.com>
- Include xen header files in -devel packages if we're building xen.
  (bug 180198)
- Disable CONFIG_B44 for Xen builds for now: it results in
  "b44.ko needs unknown symbol dma_get_cache_alignment" errors.

* Tue Mar 07 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc5-git9
- Fix NMI watchdog on i386.

kexec-tools-1.101-14
--------------------
* Tue Mar 07 2006 Thomas Graf <tgraf at redhat.com> - 1.101-14
- Fix kdump.init to call kexec from its new location

kudzu-1.2.34.1-1
----------------
* Tue Mar 07 2006 Bill Nottingham <notting at redhat.com> - 1.2.35-1
- switch at runtime between vm86 and x86emu on i386. Fixes vbe/ddc on
  Xen and i386-on-x86_64

libbonobo-2.13.93-1
-------------------
* Tue Mar 07 2006 Matthias Clasen <mclasen at redhat.com>
- Update to 2.13.93

libdv-0:0.104-2.fc5
-------------------
* Tue Mar 07 2006 Warren Togami <wtogami at redhat.com> 0.104-2
- remove instead of exclude static libs

* Wed Feb 15 2006 Matthias Saou <http://freshrpms.net/> 0.104-1
- Update to 0.104 at last (#147311)
- Include no-exec-stack, pic-fix, amd64reloc and gtk2 patches from Gentoo
  and PLD (merge gcc4 fix to the pic-fix patch).
- Now build against gtk2 (thanks to the patch above).
- Exclude static library.

pykickstart-0.23-1
------------------
* Tue Mar 07 2006 Chris Lumens <clumens at redhat.com> 0.23-1
- Backwards compatibility support for options to zerombr.

rhythmbox-0.9.3.1-3
-------------------
* Wed Mar 08 2006 Ray Strode <rstrode at redhat.com> - 0.9.3.1-3
- fix icon on notification bubbles (bug 183720)
- patch from CVS to escape bubble markup, found by 
  Bill Nottingham

selinux-policy-2.2.23-6
-----------------------
* Tue Mar 07 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-5
- Add Xen support

system-config-date-1.8.2-1
--------------------------
* Mon Mar 06 2006 Nils Philippsen <nphilipp at redhat.com> 1.8.2
- don't write into /tmp
- make synchronizing with time servers configurable (#157485)

system-config-display-1.0.37-1
------------------------------
* Tue Mar 07 2006 Chris Lumens <clumens at redhat.com> 1.0.37-1
- Initialize monitor name label to something other than unknown if we
  really know what it is.

* Wed Feb 22 2006 Chris Lumens <clumens at redhat.com> 1.0.36-2
- Add rhpxl to requires

* Fri Jan 27 2006 Paul Nasrat <pnasrat at redhat.com> - 1.0.36-1
- Rebuild for translations
- Fix reconfig mode

system-switch-mail-0.5.25-8
---------------------------
* Tue Mar 07 2006 Than Ngo <than at redhat.com> 0.5.25-8
- fix deprecated functions in gtk #159155

tog-pegasus-2:2.5-9
-------------------
* Tue Mar 07 2006 Bill Nottingham <notting at redhat.com> - 2:2.5-9
- use an assigned uid/gid, do not loop over user ids looking for a free one

xen-3.0.1-3
-----------
* Tue Mar 07 2006 Jeremy Katz <katzj at redhat.com> - 3.0.1-3
- set /proc/xen/privcmd and /var/log/xend-debug.log as close on exec to avoid
  SELinux problems
- give better feedback on invalid urls (#184176)

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From igorm5 at vip.hr  Wed Mar  8 08:32:15 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Wed, 08 Mar 2006 09:32:15 +0100
Subject: rawhide report: 20060307 changes
In-Reply-To: <1141797358.2294.2.camel@localhost.localdomain>
References: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>
	<1141797358.2294.2.camel@localhost.localdomain>
Message-ID: <440E968F.8010302@vip.hr>

Per Bjornsson wrote:

>>NetworkManager-0.6.0-2
>>----------------------
>>* Mon Mar 06 2006 Dan Williams <dcbw at redhat.com> 0.6.0-2
>>- Don't let wpa_supplicant perform scanning with non-WPA drivers
> Awesome. Now NetworkManager works for me again, it was going completely
> nuts earlier in the FC5 devel cycle (madwifi-old, no encryption). Thanks
> a million!

Speaking about NM, are there any plans for supporting static IP addresses?

-- 
Igor Jagec



From sundaram at fedoraproject.org  Wed Mar  8 08:32:38 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 14:02:38 +0530
Subject: FC5 Final Release
In-Reply-To: <1141806710.2993.15.camel@linux>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>
	<1141806710.2993.15.camel@linux>
Message-ID: <440E96A6.1080305@fedoraproject.org>

Hans Kristian Rosbach wrote:

>On Wed, 2006-03-08 at 12:08 +0530, Rahul Sundaram wrote:
>  
>
>>Sadda Teh wrote:
>>
>>    
>>
>>>Is FC5 still on schedule to be release March 15th? Thanks.
>>>
>>>      
>>>
>>Yes it is.
>>    
>>
>
>Just a general question.. 
>Will anaconda not display estimated disk usage when
>customizing package choices anymore? I have found the estimate
>quite important sometimes when installing on machines
>with little disk and a user that wants all the bling.
>
>No biggie, I'll just miss it.
>  
>
I think this feature got dropped when Anaconda got revamped to use yum 
as a dependency resolver. Not sure if its being added back now.


-- 
Rahul 





From sundaram at fedoraproject.org  Wed Mar  8 08:35:21 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 14:05:21 +0530
Subject: FC5 Final Release
In-Reply-To: <440E9428.5090604@cornell.edu>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>	<440E9010.9070202@cornell.edu>	<440E92F3.60905@fedoraproject.org>
	<440E9428.5090604@cornell.edu>
Message-ID: <440E9749.9020509@fedoraproject.org>

Ivan Gyurdiev wrote:

>
>>> I also have heard nothing from the Xorg bugzilla regarding making 
>>> the nv driver work:
>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182396
>>
>>
>> The information requested from you needs to be supplied on this report.
>
> It was supplied... in the freedesktop bugzilla.
> M. Harris said I should communicate directly with upstream
> (though upstream doesn't seem to be communicating back).

Ok. Thanks for bringing this up. I have marked it as a blocker so that 
it doesnt get lost.

>
>>> Then there's the minor inconvenience of gnome-netstatus being broken 
>>> with my atheros chip:
>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861
>>
>>
>> madwifi drivers arent providing in Fedora so this one doesnt seem 
>> like a blocker to me.
>
> I wouldn't call any bug in the netstatus applet a blocker, but it's 
> not nice that there's no response from the maintainer.

Just a matter of priority when hundreds of reports flow through every 
day. Please be patient.


-- 
Rahul 





From ivg2 at cornell.edu  Wed Mar  8 08:37:11 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Wed, 08 Mar 2006 03:37:11 -0500
Subject: FC5 Final Release
In-Reply-To: <440E9010.9070202@cornell.edu>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
	<440E7BF1.4070502@fedoraproject.org> <440E9010.9070202@cornell.edu>
Message-ID: <440E97B7.8080001@cornell.edu>


>> Yes it is.
> Maybe it's a good time to make it bootable then?
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182008
>
> I also have heard nothing from the Xorg bugzilla regarding making the 
> nv driver work:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182396
>
> Then there's the minor inconvenience of gnome-netstatus being broken 
> with my atheros chip:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861
I also feel this bug needs to be investigated in more detail as a 
potential blocker:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183958

I am not positive that Beagle does leak memory at this point, but 
there's enough users reporting memory leaks on fedora-test-list, that 
the issue should be looked at before release time. Just rebooted to test 
if 2009 kernel boots (it does not), and now mono is up and running 
again, I will see if memory usage increases significantly over the next 
2-3 days.



From sundaram at fedoraproject.org  Wed Mar  8 08:38:21 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 14:08:21 +0530
Subject: rawhide report: 20060307 changes
In-Reply-To: <440E968F.8010302@vip.hr>
References: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>	<1141797358.2294.2.camel@localhost.localdomain>
	<440E968F.8010302@vip.hr>
Message-ID: <440E97FD.9090805@fedoraproject.org>

Igor Jagec wrote:

>Per Bjornsson wrote:
>
>  
>
>>>NetworkManager-0.6.0-2
>>>----------------------
>>>* Mon Mar 06 2006 Dan Williams <dcbw at redhat.com> 0.6.0-2
>>>- Don't let wpa_supplicant perform scanning with non-WPA drivers
>>>      
>>>
>>Awesome. Now NetworkManager works for me again, it was going completely
>>nuts earlier in the FC5 devel cycle (madwifi-old, no encryption). Thanks
>>a million!
>>    
>>
>
>Speaking about NM, are there any plans for supporting static IP addresses?
>
>  
>
NM is still not enabled by default precisely because it doesnt support 
things like static IP addresses yet.

https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00001.html

 http://fedoraproject.org/wiki/Docs/Beats/Networking

So I believe there are plans to support this in the future.


-- 
Rahul 





From david at lovesunix.net  Wed Mar  8 08:41:28 2006
From: david at lovesunix.net (David Nielsen)
Date: Wed, 08 Mar 2006 09:41:28 +0100
Subject: beagle backup (user_xattr)
In-Reply-To: <1141806080.15569.131.camel@greebo>
References: <dukalf$qfo$1@sea.gmane.org>
	<1141747372.20856.10.camel@golem.boston.redhat.com>
	<6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
	<440DB0EA.3000105@feuerpokemon.de>
	<6f6293f10603070815v4e3db019g1899158444090be6@mail.gmail.com>
	<1141806080.15569.131.camel@greebo>
Message-ID: <1141807289.2348.48.camel@price.stavtrup-st.dk>

ons, 08 03 2006 kl. 09:21 +0100, skrev Alexander Larsson:
> On Tue, 2006-03-07 at 17:15 +0100, Felipe Alfaro Solana wrote:
> > > >(BTW, the filesystem is being mounted with -o user_xattr).
> > > >
> > > thats the reason, by default filesystems are not mounted with user_xattr
> > > (why?)
> > 
> > Yes... Any good reason for not doing so?
> 
> Beagle was added sort of late in the cycle, and changing the default
> mount options needs changes in anaconda etc, so we (the desktop team)
> really hasn't been pushing this. At some point we should sit down with
> the installer people and the kernel filesystem people and figure out if
> and when we should set user_xattr.

For FC6 isn't one of the goals to get seperate partitions for /home -
then it would be a great time to add the user_xattr to that partition at
least.

- David



From sundaram at fedoraproject.org  Wed Mar  8 08:46:06 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 14:16:06 +0530
Subject: beagle backup (user_xattr)
In-Reply-To: <1141807289.2348.48.camel@price.stavtrup-st.dk>
References: <dukalf$qfo$1@sea.gmane.org>	<1141747372.20856.10.camel@golem.boston.redhat.com>	<6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>	<440DB0EA.3000105@feuerpokemon.de>	<6f6293f10603070815v4e3db019g1899158444090be6@mail.gmail.com>	<1141806080.15569.131.camel@greebo>
	<1141807289.2348.48.camel@price.stavtrup-st.dk>
Message-ID: <440E99CE.7@fedoraproject.org>

David Nielsen wrote:

>For FC6 isn't one of the goals to get seperate partitions for /home -
>then it would be a great time to add the user_xattr to that partition at
>least.
>
>  
>
/home by default  is requested  at  
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150670. Jeremy Katz 
had other ideas about doing this in a much better and flexible way 
though I dont remember the precise details now. Would you file a RFE 
against anaconda to add the user_xattr by default to track this?


-- 
Rahul 





From fedora at camperquake.de  Wed Mar  8 08:53:21 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 8 Mar 2006 09:53:21 +0100
Subject: rawhide report: 20060308 changes
In-Reply-To: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>
References: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>
Message-ID: <20060308095321.4b8ba99a@soran.addix.net>

Hi.

On Wed, 8 Mar 2006 03:26:05 -0500, Build System wrote:

> - use an assigned uid/gid, do not loop over user ids looking for a
> free one

I have often wondered why useradd does not have built in support for
stuff like this. From time to time I'd like to do something like
"add a user, I do not care about the UID, but it has to be larger than
X (and, optionally, less than Y)".



From sundaram at fedoraproject.org  Wed Mar  8 08:57:36 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 14:27:36 +0530
Subject: rawhide report: 20060308 changes
In-Reply-To: <20060308095321.4b8ba99a@soran.addix.net>
References: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>
	<20060308095321.4b8ba99a@soran.addix.net>
Message-ID: <440E9C80.9040408@fedoraproject.org>

Ralf Ertzinger wrote:

>Hi.
>
>On Wed, 8 Mar 2006 03:26:05 -0500, Build System wrote:
>
>  
>
>>- use an assigned uid/gid, do not loop over user ids looking for a
>>free one
>>    
>>
>
>I have often wondered why useradd does not have built in support for
>stuff like this. From time to time I'd like to do something like
>"add a user, I do not care about the UID, but it has to be larger than
>X (and, optionally, less than Y)".
>  
>
Useradd has -r and groupadd  has -r and -g options in Fedora/RHEL to do 
similar things. check the man page for them for additional details. Does 
that serve your purpose?


-- 
Rahul 





From fedora at camperquake.de  Wed Mar  8 09:01:00 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 8 Mar 2006 10:01:00 +0100
Subject: rawhide report: 20060308 changes
In-Reply-To: <440E9C80.9040408@fedoraproject.org>
References: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>
	<20060308095321.4b8ba99a@soran.addix.net>
	<440E9C80.9040408@fedoraproject.org>
Message-ID: <20060308100100.2d0c477b@soran.addix.net>

Hi.

On Wed, 08 Mar 2006 14:27:36 +0530, Rahul Sundaram wrote:

> Useradd has -r and groupadd  has -r and -g options in Fedora/RHEL to
> do similar things. check the man page for them for additional
> details. Does that serve your purpose?

This is not exactly about system accounts. Looking though the man
page (again) I found -K, which seems to do what I want (except that
-K UID_MIN=10,UID_MAX=499 is explicitly marked as "does not work yet").



From david at lovesunix.net  Wed Mar  8 09:10:48 2006
From: david at lovesunix.net (David Nielsen)
Date: Wed, 08 Mar 2006 10:10:48 +0100
Subject: rawhide report: 20060308 changes
In-Reply-To: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>
References: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>
Message-ID: <1141809049.2348.52.camel@price.stavtrup-st.dk>


> rhythmbox-0.9.3.1-3
> -------------------
> * Wed Mar 08 2006 Ray Strode <rstrode at redhat.com> - 0.9.3.1-3
> - fix icon on notification bubbles (bug 183720)
> - patch from CVS to escape bubble markup, found by 
>   Bill Nottingham

Well there goes the wasted effort of filing:

#184361 and #184360 5 mins before the rawhide messages of the day.

- David



From sundaram at fedoraproject.org  Wed Mar  8 09:32:07 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 15:02:07 +0530
Subject: rawhide report: 20060308 changes
In-Reply-To: <1141809049.2348.52.camel@price.stavtrup-st.dk>
References: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>
	<1141809049.2348.52.camel@price.stavtrup-st.dk>
Message-ID: <440EA497.5020601@fedoraproject.org>

David Nielsen wrote:

>>rhythmbox-0.9.3.1-3
>>-------------------
>>* Wed Mar 08 2006 Ray Strode <rstrode at redhat.com> - 0.9.3.1-3
>>- fix icon on notification bubbles (bug 183720)
>>- patch from CVS to escape bubble markup, found by 
>>  Bill Nottingham
>>    
>>
>
>Well there goes the wasted effort of filing:
>
>#184361 and #184360 5 mins before the rawhide messages of the day.
>
>  
>
Oh the joys of a rawhide rider. Thanks for reporting them anyway.


-- 
Rahul 





From gilboad at gmail.com  Wed Mar  8 09:47:25 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Wed, 08 Mar 2006 11:47:25 +0200
Subject: FC5 Final Release
In-Reply-To: <440E96A6.1080305@fedoraproject.org>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
	<440E7BF1.4070502@fedoraproject.org> <1141806710.2993.15.camel@linux>
	<440E96A6.1080305@fedoraproject.org>
Message-ID: <1141811245.23652.0.camel@gilboa-work-dev>

On Wed, 2006-03-08 at 14:02 +0530, Rahul Sundaram wrote:
> Hans Kristian Rosbach wrote:
> 
> >On Wed, 2006-03-08 at 12:08 +0530, Rahul Sundaram wrote:
> >  
> >
> >>Sadda Teh wrote:
> >>
> >>    
> >>
> >>>Is FC5 still on schedule to be release March 15th? Thanks.
> >>>
> >>>      
> >>>
> >>Yes it is.
> >>    
> >>
> >
> >Just a general question.. 
> >Will anaconda not display estimated disk usage when
> >customizing package choices anymore? I have found the estimate
> >quite important sometimes when installing on machines
> >with little disk and a user that wants all the bling.
> >
> >No biggie, I'll just miss it.
> >  
> >
> I think this feature got dropped when Anaconda got revamped to use yum 
> as a dependency resolver. Not sure if its being added back now.
> 
> 
> -- 
> Rahul 
> 
> 
> 

Already reported: (and closed)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183878


Gilboa




From sundaram at fedoraproject.org  Wed Mar  8 10:00:05 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 15:30:05 +0530
Subject: rawhide report: 20060308 changes
In-Reply-To: <20060308100100.2d0c477b@soran.addix.net>
References: <200603080826.k288Q5ZL008956@porkchop.devel.redhat.com>	<20060308095321.4b8ba99a@soran.addix.net>	<440E9C80.9040408@fedoraproject.org>
	<20060308100100.2d0c477b@soran.addix.net>
Message-ID: <440EAB25.6080109@fedoraproject.org>

Ralf Ertzinger wrote:

>Hi.
>
>On Wed, 08 Mar 2006 14:27:36 +0530, Rahul Sundaram wrote:
>
>  
>
>>Useradd has -r and groupadd  has -r and -g options in Fedora/RHEL to
>>do similar things. check the man page for them for additional
>>details. Does that serve your purpose?
>>    
>>
>
>This is not exactly about system accounts. Looking though the man
>page (again) I found -K, which seems to do what I want (except that
>-K UID_MIN=10,UID_MAX=499 is explicitly marked as "does not work yet").
>  
>
Interesting. Is there a open bug report for someone to look at other 
than a probably a long forgotten man page?


-- 
Rahul 





From dwmw2 at infradead.org  Wed Mar  8 11:25:04 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 08 Mar 2006 11:25:04 +0000
Subject: rawhide report: 20060307 changes
In-Reply-To: <440E968F.8010302@vip.hr>
References: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>
	<1141797358.2294.2.camel@localhost.localdomain>
	<440E968F.8010302@vip.hr>
Message-ID: <1141817104.5413.52.camel@pmac.infradead.org>

On Wed, 2006-03-08 at 09:32 +0100, Igor Jagec wrote:
> Speaking about NM, are there any plans for supporting static IP addresses?

Doesn't NM work with static IP addresses? It obeys static IP addresses
in /etc/sysconfig/network-scripts/ifcfg-eth1 for me -- it confused me by
doing so a couple of weeks ago.

-- 
dwmw2



From gianluca.cecchi at gmail.com  Wed Mar  8 11:58:06 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Wed, 8 Mar 2006 12:58:06 +0100
Subject: install error: unable to read package metadata
Message-ID: <561c252c0603080358v23dbe4b3y59f1dfaa0764294d@mail.gmail.com>

I'm trying to install via pxe+nfs from rsync of yesterday on x86 and I
get this error window during anaconda:
unable to read package metadata. this may be due
to a missing repodata. Please ensure that your
install tree has been correctly
generated. failure: repodata/comps.xml  from anaconda:
[errno 256] no more mirrors to try
switching to the shell with Ctrl+Alt+F2, I see inside anaconda.log in
/tmp I have
[snip]
10:42:24 INFO    : NFS install method detected, will use RHupdates/
10:42:24 INFO    : Running anaconda script /usr/bin/anaconda
10:42:27 INFO    : Display mode = g
10:42:27 INFO    : Method = nfs://mnt/source/.
10:42:44 INFO    : Started mini-wm
10:42:44 INFO    : Starting graphical installation...
10:42:45 INFO    : anaconda floppy device None
10:42:45 DEBUG   : self.driveList(): ['sda', 'sdb']
10:42:45 DEBUG   : DiskSet.skippedDisks: []
10:42:45 DEBUG   : DiskSet.skippedDisks: []
10:42:45 DEBUG   : starting all dmraids on drives ['sda', 'sdb']
10:42:45 DEBUG   : scanning for dmraid on drives ['sda', 'sdb']
10:42:45 WARNING : Couldnt lookup monitor type Smart Cable.
10:42:45 WARNING : step partitionmethod does not exist
10:42:45 WARNING : step partitionmethodsetup does not exist
10:42:45 WARNING : step autopartition does not exist
10:42:45 WARNING : step readcomps does not exist
10:42:45 WARNING : step selectlangpackages does not exist
10:42:45 WARNING : step handleX11pkgs does not exist
10:42:45 WARNING : step handlemiscpkgs does not exist
10:42:45 WARNING : step fixupconditionals does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:45 WARNING : step complete does not exist
10:42:46 INFO    : moving (1) to step partitionobjinit
10:42:46 DEBUG   : self.driveList(): ['sda', 'sdb']
10:42:46 DEBUG   : DiskSet.skippedDisks: []
10:42:46 DEBUG   : DiskSet.skippedDisks: []
10:42:46 INFO    : moving (1) to step autopartitionexecute
10:42:46 INFO    : moving (1) to step partitiondone
10:42:46 INFO    : moving (1) to step bootloadersetup
10:42:46 INFO    : moving (1) to step networkdevicecheck
10:42:46 INFO    : moving (1) to step reposetup
10:42:47 INFO    : anaconda
        [1/1]
10:42:47 ERROR   : reading package metadata: failure:
repodata/comps.xml from anaconda: [Errno 256] No more mirrors to try.

df -k gives:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev                   1948452         0   1948452   0% /dev
192.168.0.110:/fc5nfs
                      14200000   9822368   3644672  73% /mnt/source
/tmp/loop0               70720     70720         0 100% /mnt/runtime
 and I can edit /mnt/source/repodata/comps.xml ....

Is this a problem on my part about rsync or what?
How can I dig into this?



From sundaram at fedoraproject.org  Wed Mar  8 12:34:00 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 18:04:00 +0530
Subject: dropdown menu's
In-Reply-To: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
Message-ID: <440ECF38.8030908@fedoraproject.org>

Erwin Rol wrote:

>Hey all,
>
>This is something that already bothers me a while, i think it never
>really worked as expected, but i am not sure if it is a "my machine
>only" kind of problem.
>
>Dropdown menu's that don't fit on the screen are not displayed
>correctly. For example take the gimp file-open dialog. When you move the
>dialog to the bottom border of the screen, and press the "All Files"
>dropdown menu, the menu will open, and the bottom of the menu will be
>aligned with the bottom of the screen, the top of the menu will be
>somewhere mid screen. But the first entry will be at the location of the
>position of the dropdown box, and so everything above that position is
>empty. I tried to make a screenshot, but that didn't work with the
>dropdown box open, i suggest to just try it. Since it happens with every
>GTK application, it smells like an GTK issue.
>
>  
>
Being fixed in GTK 2.10 FYI

http://inverted-tree.livejournal.com/49201.html.


-- 
Rahul 





From mailinglists at erwinrol.com  Wed Mar  8 12:44:29 2006
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Wed, 08 Mar 2006 13:44:29 +0100
Subject: dropdown menu's
In-Reply-To: <440ECF38.8030908@fedoraproject.org>
References: <1141515474.5468.21.camel@xpc.home.erwinrol.com>
	<440ECF38.8030908@fedoraproject.org>
Message-ID: <1141821869.5468.173.camel@xpc.home.erwinrol.com>

On Wed, 2006-03-08 at 18:04 +0530, Rahul Sundaram wrote:
> Being fixed in GTK 2.10 FYI
> 
> http://inverted-tree.livejournal.com/49201.html.

>From the page; "A scroll menu patch went in, which gets rid of the blank
area which sometimes appeared in for example popup menus and
annoyed/confused a lot of people."

I am glad to see it says "a lot of people" :-)

- Erwin





From casimiro.barreto at gmail.com  Wed Mar  8 12:50:53 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Wed, 08 Mar 2006 09:50:53 -0300
Subject: PANIC on RPMDB... can't even get version numbers for installed
 packages...
In-Reply-To: <1141794146.2550.2.camel@enki.eridu>
References: <440E245B.6030505@gmail.com> <1141794146.2550.2.camel@enki.eridu>
Message-ID: <440ED32D.4090006@gmail.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060308/1120df39/attachment.htm>

From pnasrat at redhat.com  Wed Mar  8 13:00:03 2006
From: pnasrat at redhat.com (Paul Nasrat)
Date: Wed, 08 Mar 2006 08:00:03 -0500
Subject: PANIC on RPMDB... can't even get version numbers for installed
	packages...
In-Reply-To: <440ED32D.4090006@gmail.com>
References: <440E245B.6030505@gmail.com>
	<1141794146.2550.2.camel@enki.eridu>  <440ED32D.4090006@gmail.com>
Message-ID: <1141822804.2550.11.camel@enki.eridu>

On Wed, 2006-03-08 at 09:50 -0300, Casimiro de Almeida Barreto wrote:
> I did the same procedure as I'd do with M$...
> 
> 1) Reboot the system
> 2) ftp download.fedora.redhat.com
> 3) download glibc*
> 4) rpm -Uvh --force --nodeps glibc-comm* (yeah... after a reboot rpm
> works)
> 5) rm glibc-comm* && rpm -Uvh --force --nodeps glibc*
> 
> And everything comes back to life...

1) Use a depsolver eg: yum update glibc this will do the right thing.
Updating by hand is really not the way to do things. The fedora
documentation projejct explain how to use yum, I suggest you read that.

2) What do you expect from partial forced updates force/nodeps have no
use in a casual update.

3) rpm -Uvh glibc-...rpm glibc-common....rpm should work also

Basically don't do it like that....

Paul




From tarjei.knapstad at gmail.com  Wed Mar  8 13:02:44 2006
From: tarjei.knapstad at gmail.com (Tarjei Knapstad)
Date: Wed, 8 Mar 2006 14:02:44 +0100
Subject: Qt 4 RPM and pkg-config problem
Message-ID: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>

A while back I posted about Qt4 rpms for development work and got
pointed towards Than's rawhide SRPM at
ftp://people.redhat.com/than/rawhide/.

This works and I've just used the spec to build Qt 4.1.1, but it has
one minor flaw which I'm not sure how to fix. All the pkg-config
scripts which are installed in lib/ include the RPM build dir in the
Libs: section (I need the pkg-config stuff to properly detect Qt4
using autoconf). Here's an example from QtCore.pc:

Libs: -L${libdir} -lQtCore -L/usr/lib/mysql
-L/home/tarjeik/rpmbuild/BUILD/qt-x11-opensource-src-4.1.1/lib  -lz
-lm -lpthread -ldl

What is the proper way to fix this? Add a small sed line in the spec
to clean out the rpmbuild dir from the .pc files after the build is
complete and the files are packaged? I wouldn't be surprised if this
was a common problem with a common fix, I just need to know how :)

Oh, Paul F.J., did you get around to add this RPM to Extras? (can't
find the bugzilla entry in case you did)

Sincerely,
--
Tarjei



From paul at all-the-johnsons.co.uk  Wed Mar  8 13:26:08 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Wed, 08 Mar 2006 13:26:08 +0000
Subject: Qt 4 RPM and pkg-config problem
In-Reply-To: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>
References: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>
Message-ID: <1141824368.20537.53.camel@mrwibble.mrwobble>

Hi,

> Oh, Paul F.J., did you get around to add this RPM to Extras? (can't
> find the bugzilla entry in case you did)

Is it worth putting Qt4 into extras as it's sooner or later going to be
in core?

I have no problem submitting it, just don't want to duplicate effort.

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From caillon at redhat.com  Wed Mar  8 13:30:15 2006
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 08 Mar 2006 08:30:15 -0500
Subject: rawhide report: 20060307 changes
In-Reply-To: <440E968F.8010302@vip.hr>
References: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>	<1141797358.2294.2.camel@localhost.localdomain>
	<440E968F.8010302@vip.hr>
Message-ID: <440EDC67.9090005@redhat.com>

On 03/08/2006 03:32 AM, Igor Jagec wrote:
> Per Bjornsson wrote:
> 
>>> NetworkManager-0.6.0-2
>>> ----------------------
>>> * Mon Mar 06 2006 Dan Williams <dcbw at redhat.com> 0.6.0-2
>>> - Don't let wpa_supplicant perform scanning with non-WPA drivers
>> Awesome. Now NetworkManager works for me again, it was going completely
>> nuts earlier in the FC5 devel cycle (madwifi-old, no encryption). Thanks
>> a million!
> 
> Speaking about NM, are there any plans for supporting static IP addresses?
> 

Static IPs are supported, but there is no way to configure it with NM. 
Configure it with system-config-network, and NM will pick up the static 
IP fine.



From sundaram at fedoraproject.org  Wed Mar  8 13:30:44 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 19:00:44 +0530
Subject: Qt 4 RPM and pkg-config problem
In-Reply-To: <1141824368.20537.53.camel@mrwibble.mrwobble>
References: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>
	<1141824368.20537.53.camel@mrwibble.mrwobble>
Message-ID: <440EDC84.4060100@fedoraproject.org>

Paul F. Johnson wrote:

>Hi,
>
>  
>
>>Oh, Paul F.J., did you get around to add this RPM to Extras? (can't
>>find the bugzilla entry in case you did)
>>    
>>
>
>Is it worth putting Qt4 into extras as it's sooner or later going to be
>in core?
>
>I have no problem submitting it, just don't want to duplicate effort.
>  
>
Its quite good to get a package submitted and reviewed in Fedora Extras 
even when its destined to be in Fedora Core later. It increases the 
quality of the packages, helps get some early feedback and so on.

-- 
Rahul 





From paul at all-the-johnsons.co.uk  Wed Mar  8 13:32:40 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Wed, 08 Mar 2006 13:32:40 +0000
Subject: Qt 4 RPM and pkg-config problem
In-Reply-To: <440EDC84.4060100@fedoraproject.org>
References: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>
	<1141824368.20537.53.camel@mrwibble.mrwobble>
	<440EDC84.4060100@fedoraproject.org>
Message-ID: <1141824760.20537.58.camel@mrwibble.mrwobble>

Hi,

> >I have no problem submitting it, just don't want to duplicate effort.
> >  
> Its quite good to get a package submitted and reviewed in Fedora Extras 
> even when its destined to be in Fedora Core later. It increases the 
> quality of the packages, helps get some early feedback and so on.

I'll get onto it tonight - thought I'm porting z88dk to 64 bit currently
and that's not a happy task. 

Hmm, when am I going to get time to get the next C Vu out thought ;-p

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From vd at paradigma.pt  Wed Mar  8 13:35:06 2006
From: vd at paradigma.pt (Vitor Domingos)
Date: Wed, 8 Mar 2006 13:35:06 +0000
Subject: rawhide report: 20060307 changes
In-Reply-To: <440EDC67.9090005@redhat.com>
References: <440EDC67.9090005@redhat.com>
Message-ID: <a58a10e7e843fc918aa15349a8cc8d71@mail.paradigma.pt>

On Wed, 08 Mar 2006 08:30:15 -0500, Christopher Aillon <caillon at redhat.com> wrote:
> Static IPs are supported, but there is no way to configure it with NM.
> Configure it with system-config-network, and NM will pick up the static
> IP fine.

:) And if you have to static IPs for each network you're in ? I know that NM cannot detect that change of phisical networks, but can this static ip be asked upon network selection ?

-- 
//VD



From dragoran at feuerpokemon.de  Wed Mar  8 15:01:42 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 08 Mar 2006 16:01:42 +0100
Subject: FC5 Final Release
In-Reply-To: <440E96A6.1080305@fedoraproject.org>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>	<1141806710.2993.15.camel@linux>
	<440E96A6.1080305@fedoraproject.org>
Message-ID: <440EF1D6.6070407@feuerpokemon.de>

Rahul Sundaram wrote:

> Hans Kristian Rosbach wrote:
>
>> On Wed, 2006-03-08 at 12:08 +0530, Rahul Sundaram wrote:
>>  
>>
>>> Sadda Teh wrote:
>>>
>>>   
>>>
>>>> Is FC5 still on schedule to be release March 15th? Thanks.
>>>>
>>>>     
>>>
>>> Yes it is.
>>>   
>>
>>
>> Just a general question.. Will anaconda not display estimated disk 
>> usage when
>> customizing package choices anymore? I have found the estimate
>> quite important sometimes when installing on machines
>> with little disk and a user that wants all the bling.
>>
>> No biggie, I'll just miss it.
>>  
>>
> I think this feature got dropped when Anaconda got revamped to use yum 
> as a dependency resolver. Not sure if its being added back now.
>
>
it seems that it was remove from the gui for some reasons.
in text mode the size is shown.



From rdieter at math.unl.edu  Wed Mar  8 15:20:02 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 08 Mar 2006 09:20:02 -0600
Subject: Qt 4 RPM and pkg-config problem
In-Reply-To: <1141824368.20537.53.camel@mrwibble.mrwobble>
References: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>
	<1141824368.20537.53.camel@mrwibble.mrwobble>
Message-ID: <440EF622.6020808@math.unl.edu>

Paul F. Johnson wrote:

>>Oh, Paul F.J., did you get around to add this RPM to Extras? (can't
>>find the bugzilla entry in case you did)
> 
> 
> Is it worth putting Qt4 into extras as it's sooner or later going to be
> in core?
> 
> I have no problem submitting it, just don't want to duplicate effort.

I had been working on it, but got side-tracked with several other 
projects.  So, as it stands, I'd be willing to review anything 
submitted... (-:

-- Rex



From pertusus at free.fr  Wed Mar  8 15:33:07 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 8 Mar 2006 16:33:07 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <440CD6DC.6020903@redhat.com>
References: <440CD6DC.6020903@redhat.com>
Message-ID: <20060308153307.GF2238@free.fr>

Hello,

I don't know if it is the kind of input that is usefull, but here it is.
I tried a yum update from FC-4 to rawhide. I have general comments, packages
leftovers, and Xorg modularization leftovers.

1) General

Things went rather smoothly. Some scriptlet said somethings (but I didn't
kept what they said). There was a failure in hal post scriptlet (no other
error message than the message saying there was an error), so I ended with 
the old hal still present in the rpmdb. There is nothing in logs, so I 
guess reporting this failure isn't usefull. 

2) Leftovers

After the update, I had those packages from fc4 still installed:

gnome-kerberos system-config-mouse comps perl-XML-Encoding gimp-gap
iiimf-libs

I could remove them without any issue, and they didn't blocked any update.

I investigated a bit, gnome-kerberos system-config-mouse and gimp-gap
weren't needed by anything, comps was needed by an apt subpackage (from
extras if I'm not wrong),  perl-XML-Encoding was needed by foomatic and
perl-libxml-enno, and it seems that perl-libxml-enno has been obsoleted
by other perl modules. iiimf subsystem seems to have been obsoleted by 
scim.

Maybe anaconda knows how to deal with these packages? Otherwise they could
appear in the wiki as packaged dropped from core that could be imported
in extra (if it makes sense). Otherwise I don't have much idea on how
to get rid of them during the yum upgrade. I believe they may block
updates later...

3) X modularization

It is possible that anaconda knows how to deal with those issues.

Many unowned include files and directories are kept in /usr/X11R6/include/X11/
ls /usr/X11R6/include/X11/
ap_keysym.h   fonts         RectObjP.h    Xatom.h       Xfuncs.h   xpm.h
bitmaps       HPkeysym.h    Shell.h       Xauth.h       X.h        Xpoll.h
Composite.h   ICE           ShellP.h      Xaw           XKBlib.h   Xproto.h
CompositeP.h  Intrinsic.h   SM            Xaw3d         Xlib.h     Xprotostr.h
ConstrainP.h  IntrinsicP.h  StringDefs.h  Xcms.h        Xlibint.h  Xresource.h
Constraint.h  keysymdef.h   Sunkeysym.h   Xcursor       Xlocale.h  Xthreads.h
Core.h        keysym.h      Vendor.h      Xdefs.h       Xmd.h      Xutil.h
CoreP.h       Object.h      VendorP.h     Xdmcp.h       Xmu        XWDFile.h
cursorfont.h  ObjectP.h     X10.h         XF86keysym.h  Xosdefs.h
DECkeysym.h   PM            Xalloca.h     Xft           Xos.h
extensions    RectObj.h     Xarch.h       Xfuncproto.h  Xos_r.h

A dangling symlink to X was also kept.

There are also some empty directories unowned under /usr/X11R6/ (man, lib)
and directories within.

lib/modules/input
/usr/X11R6/lib/X11:
app-defaults  fonts  getconfig  locale  proxymngr  xdm
/usr/X11R6/lib/X11/fonts/75dpi/fonts.dir
/usr/X11R6/lib/X11/locale/pt_BR.UTF-8/

In /usr/X11R6/include there are also the following unowned directories that
should belong to openmotif:
Mrm  uil  Xm
The files within those directories belong to openmotif-devel-2.3.0-0.1.9.2.

In fact there is a link from /usr/include/Mrm to ../X11R6/include/Mrm
and similarly for Xm and uil.

There is a bug about openmotif,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170947
but it was closed.

Hope it helps.

--
Pat



From fedora at camperquake.de  Wed Mar  8 15:46:12 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 8 Mar 2006 16:46:12 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <20060308153307.GF2238@free.fr>
References: <440CD6DC.6020903@redhat.com>
	<20060308153307.GF2238@free.fr>
Message-ID: <20060308164612.1edb3f29@soran.addix.net>

Hi.

On Wed, 8 Mar 2006 16:33:07 +0100, Patrice Dumas wrote:


> In /usr/X11R6/include there are also the following unowned
> directories that should belong to openmotif:
> Mrm  uil  Xm
> The files within those directories belong to
> openmotif-devel-2.3.0-0.1.9.2.

Can you check something for me?
Does rpm -qf <file-in-usr-x11r6-include-xm> claim that the
file is owned by openmotif?
If yes, does rpm -ql openmotif show any files in /usr/X11R6?



From paul at city-fan.org  Wed Mar  8 16:03:41 2006
From: paul at city-fan.org (Paul Howarth)
Date: Wed, 08 Mar 2006 16:03:41 +0000
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <20060308153307.GF2238@free.fr>
References: <440CD6DC.6020903@redhat.com> <20060308153307.GF2238@free.fr>
Message-ID: <440F005D.3080901@city-fan.org>

Patrice Dumas wrote:
> 2) Leftovers
> 
> After the update, I had those packages from fc4 still installed:
> 
> gnome-kerberos system-config-mouse comps perl-XML-Encoding gimp-gap
> iiimf-libs
> 
> I could remove them without any issue, and they didn't blocked any update.
> 
> I investigated a bit, gnome-kerberos system-config-mouse and gimp-gap
> weren't needed by anything, comps was needed by an apt subpackage (from
> extras if I'm not wrong),  perl-XML-Encoding was needed by foomatic and
> perl-libxml-enno, and it seems that perl-libxml-enno has been obsoleted
> by other perl modules.

Regarding perl-XML-Encoding, perl-libxml-enno, and foomatic, see 
Bugzilla #128879

Basically, perl-libxml-enno has been split into (some of) its 
constituent modules (I believe perl-XML-DOM should obsolete it), and 
perl-XML-Encoding, which was a dep of perl-libxml-enno, is no longer 
needed in FC5 and so was dropped. foomatic has dropped the deps on these 
packages too.

Paul.



From pertusus at free.fr  Wed Mar  8 16:04:09 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 8 Mar 2006 17:04:09 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <20060308164612.1edb3f29@soran.addix.net>
References: <440CD6DC.6020903@redhat.com> <20060308153307.GF2238@free.fr>
	<20060308164612.1edb3f29@soran.addix.net>
Message-ID: <20060308160409.GI2238@free.fr>

> Can you check something for me?
> Does rpm -qf <file-in-usr-x11r6-include-xm> claim that the
> file is owned by openmotif?

Yes. But not for directory.

[dumas at nor75-15-82-67-190-22 include]$ rpm -qf /usr/X11R6/include/Mrm/MrmAppl.h 
openmotif-devel-2.3.0-0.1.9.2
[dumas at nor75-15-82-67-190-22 include]$ rpm -qf /usr/X11R6/include/Mrm/
file /usr/X11R6/include/Mrm is not owned by any package

> If yes, does rpm -ql openmotif show any files in /usr/X11R6?

No they appear to be in /usr/include 
[dumas at nor75-15-82-67-190-22 include]$ rpm -ql openmotif-devel | grep X11R6

echoes nothing, and there is:

[dumas at nor75-15-82-67-190-22 include]$ rpm -ql openmotif-devel | grep MrmAppl.h
/usr/include/Mrm/MrmAppl.h

--
Pat



From fedora at camperquake.de  Wed Mar  8 16:11:23 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 8 Mar 2006 17:11:23 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <20060308160409.GI2238@free.fr>
References: <440CD6DC.6020903@redhat.com> <20060308153307.GF2238@free.fr>
	<20060308164612.1edb3f29@soran.addix.net>
	<20060308160409.GI2238@free.fr>
Message-ID: <20060308171123.04f74390@soran.addix.net>

Hi.

On Wed, 8 Mar 2006 17:04:09 +0100, Patrice Dumas wrote:

> [dumas at nor75-15-82-67-190-22 include]$ rpm
> -qf /usr/X11R6/include/Mrm/MrmAppl.h openmotif-devel-2.3.0-0.1.9.2
> [dumas at nor75-15-82-67-190-22 include]$ rpm -qf /usr/X11R6/include/Mrm/
> file /usr/X11R6/include/Mrm is not owned by any package
> 
> > If yes, does rpm -ql openmotif show any files in /usr/X11R6?
> 
> No they appear to be in /usr/include 
> [dumas at nor75-15-82-67-190-22 include]$ rpm -ql openmotif-devel | grep
> X11R6
> 
> echoes nothing, and there is:
> 
> [dumas at nor75-15-82-67-190-22 include]$ rpm -ql openmotif-devel | grep
> MrmAppl.h /usr/include/Mrm/MrmAppl.h

I had the same effect while migrating to modular X. Maybe someone more
versed in RPM internals can tell why RPM thinks that oponmotif owns
files in /usr/X11R6 when rpm -ql show none of those files.



From billcrawford1970 at gmail.com  Wed Mar  8 16:37:21 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 08 Mar 2006 16:37:21 +0000
Subject: New /etc/services for testing available
In-Reply-To: <43D685EB.4090502@redhat.com>
References: <43D685EB.4090502@redhat.com>
Message-ID: <440F0841.5030605@gmail.com>

Phil Knirsch wrote:
> Hi folks.
>
> I'd like to get some feedback on a hugely updated /etc/services i've 
> done today.
>
> It basically merges the old /etc/services with almost all current 
> official IANA services.
>
> I've tried to make sure the file is sane and in order, but due to the 
> huge amount of new services i'd like to give it some selected exposure 
> and feedback before i think about putting it into our setup package.
>
> The file can be downloaded from here:
>
> http://people.redhat.com/pknirsch/services
>
> Just dump it as a replacement in /etc (maybe making a copy of the old 
> /etc/services first, but shouldn't be necessary as the first part of 
> the file is identical to our old one).
>
> I'd especially like to get some feedback from people using it on 
> network servers or monitoring machines where apps like nmap, tcpdump 
> and ethereral are run. My main interest is if any errors pop up and if 
> anyone gets performance problems (because for worst case scenarios it 
> can now take up to 15 times as long for getservbyname() to complete).
>
> Thanks in advance,
>
> Read ya, Phil
>

 I'd really suggest instead making a poll of what people would find useful.

 There are going to be a lot of things in there that will probably never 
be useful, e.g. 2545 "sis-emt" is one I registered, and I'm pretty sure 
is now unused, or certainly of only very limited use.

 Just a thought.




From sundaram at fedoraproject.org  Wed Mar  8 16:39:37 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 08 Mar 2006 22:09:37 +0530
Subject: New /etc/services for testing available
In-Reply-To: <440F0841.5030605@gmail.com>
References: <43D685EB.4090502@redhat.com> <440F0841.5030605@gmail.com>
Message-ID: <440F08C9.4010001@fedoraproject.org>

Bill Crawford wrote:

>
> I'd really suggest instead making a poll of what people would find 
> useful.
>
> There are going to be a lot of things in there that will probably 
> never be useful, e.g. 2545 "sis-emt" is one I registered, and I'm 
> pretty sure is now unused, or certainly of only very limited use.
>
> Just a thought.

Whats the harm in having them there though?

-- 
Rahul 





From gianluca.cecchi at gmail.com  Wed Mar  8 16:41:41 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Wed, 8 Mar 2006 17:41:41 +0100
Subject: install error: unable to read package metadata
In-Reply-To: <561c252c0603080358v23dbe4b3y59f1dfaa0764294d@mail.gmail.com>
References: <561c252c0603080358v23dbe4b3y59f1dfaa0764294d@mail.gmail.com>
Message-ID: <561c252c0603080841q1d2d4570yf4bbbaedafaf1655@mail.gmail.com>

same errors after rsynced today... with  kernel-2.6.15-1.2032_FC5 and
anaconda-11.0.1-1
do I have to recreate anything at my side? or pxe+nfs is broken for
daily snapshots?
I skip debug and SRPMS directory under tree but I think this doesn't matter...
Gianluca


On 3/8/06, Gianluca Cecchi <gianluca.cecchi at gmail.com> wrote:
> I'm trying to install via pxe+nfs from rsync of yesterday on x86 and I
> get this error window during anaconda:
> unable to read package metadata. this may be due
> to a missing repodata. Please ensure that your
> install tree has been correctly
> generated. failure: repodata/comps.xml  from anaconda:
> [errno 256] no more mirrors to try
> switching to the shell with Ctrl+Alt+F2, I see inside anaconda.log in
> /tmp I have
> [snip]
> 10:42:24 INFO    : NFS install method detected, will use RHupdates/
> 10:42:24 INFO    : Running anaconda script /usr/bin/anaconda
> 10:42:27 INFO    : Display mode = g
> 10:42:27 INFO    : Method = nfs://mnt/source/.
> 10:42:44 INFO    : Started mini-wm
> 10:42:44 INFO    : Starting graphical installation...
> 10:42:45 INFO    : anaconda floppy device None
> 10:42:45 DEBUG   : self.driveList(): ['sda', 'sdb']
> 10:42:45 DEBUG   : DiskSet.skippedDisks: []
> 10:42:45 DEBUG   : DiskSet.skippedDisks: []
> 10:42:45 DEBUG   : starting all dmraids on drives ['sda', 'sdb']
> 10:42:45 DEBUG   : scanning for dmraid on drives ['sda', 'sdb']
> 10:42:45 WARNING : Couldnt lookup monitor type Smart Cable.
> 10:42:45 WARNING : step partitionmethod does not exist
> 10:42:45 WARNING : step partitionmethodsetup does not exist
> 10:42:45 WARNING : step autopartition does not exist
> 10:42:45 WARNING : step readcomps does not exist
> 10:42:45 WARNING : step selectlangpackages does not exist
> 10:42:45 WARNING : step handleX11pkgs does not exist
> 10:42:45 WARNING : step handlemiscpkgs does not exist
> 10:42:45 WARNING : step fixupconditionals does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:45 WARNING : step complete does not exist
> 10:42:46 INFO    : moving (1) to step partitionobjinit
> 10:42:46 DEBUG   : self.driveList(): ['sda', 'sdb']
> 10:42:46 DEBUG   : DiskSet.skippedDisks: []
> 10:42:46 DEBUG   : DiskSet.skippedDisks: []
> 10:42:46 INFO    : moving (1) to step autopartitionexecute
> 10:42:46 INFO    : moving (1) to step partitiondone
> 10:42:46 INFO    : moving (1) to step bootloadersetup
> 10:42:46 INFO    : moving (1) to step networkdevicecheck
> 10:42:46 INFO    : moving (1) to step reposetup
> 10:42:47 INFO    : anaconda
>         [1/1]
> 10:42:47 ERROR   : reading package metadata: failure:
> repodata/comps.xml from anaconda: [Errno 256] No more mirrors to try.
>
> df -k gives:
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev                   1948452         0   1948452   0% /dev
> 192.168.0.110:/fc5nfs
>                       14200000   9822368   3644672  73% /mnt/source
> /tmp/loop0               70720     70720         0 100% /mnt/runtime
>  and I can edit /mnt/source/repodata/comps.xml ....
>
> Is this a problem on my part about rsync or what?
> How can I dig into this?
>



From wtogami at redhat.com  Wed Mar  8 16:44:31 2006
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 08 Mar 2006 11:44:31 -0500
Subject: Help Needed: TEST FC5 KERNELS!
Message-ID: <440F09EF.10009@redhat.com>

http://people.redhat.com/davej/kernels/Fedora/devel/

If you are running rawhide FC5 on any architecture, please update to the 
latest kernel here often, reboot and test.  We need your feedback very 
quickly if a new kernel here causes regressions, because we are rapidly 
approaching what will become the FC5 final kernel.

If your box is SMP or dual-core, please test booting the uniprocessor 
and multi-processor kernels if your architecture has both kernel builds. 
  In cases where we have separate uniprocessor and SMP kernels (x86 and 
ppc), we need both tested because the installer uses uniprocessor while 
your yum updated system might not by default.

Please keep in mind that we are only interested in regressions in things 
that would break installation and booting at this point.  If issue has 
always existed in past Fedora, then it would not be useful to push it 
again now.  PLEASE REPORT ONLY REGRESSIONS

Thank you,
Warren Togami
wtogami at redhat.com



From katzj at redhat.com  Wed Mar  8 16:50:33 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 08 Mar 2006 11:50:33 -0500
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <20060308153307.GF2238@free.fr>
References: <440CD6DC.6020903@redhat.com>  <20060308153307.GF2238@free.fr>
Message-ID: <1141836633.21278.2.camel@orodruin.boston.redhat.com>

On Wed, 2006-03-08 at 16:33 +0100, Patrice Dumas wrote:
> 2) Leftovers
> 
> After the update, I had those packages from fc4 still installed:
> 
> gnome-kerberos system-config-mouse comps perl-XML-Encoding gimp-gap
> iiimf-libs

Did you not have obsoletes enabled?  iiimf-libs at least should have
been removed by scim obsoleting old versions.  Some packages being left
isn't abnormal on an upgrade.

Jeremy



From katzj at redhat.com  Wed Mar  8 16:53:44 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 08 Mar 2006 11:53:44 -0500
Subject: beagle backup (user_xattr)
In-Reply-To: <440E99CE.7@fedoraproject.org>
References: <dukalf$qfo$1@sea.gmane.org>
	<1141747372.20856.10.camel@golem.boston.redhat.com>
	<6f6293f10603070810t308e1eees87ab4d5ac04b197f@mail.gmail.com>
	<440DB0EA.3000105@feuerpokemon.de>
	<6f6293f10603070815v4e3db019g1899158444090be6@mail.gmail.com>
	<1141806080.15569.131.camel@greebo>
	<1141807289.2348.48.camel@price.stavtrup-st.dk>
	<440E99CE.7@fedoraproject.org>
Message-ID: <1141836824.21278.4.camel@orodruin.boston.redhat.com>

On Wed, 2006-03-08 at 14:16 +0530, Rahul Sundaram wrote:
> David Nielsen wrote:
> >For FC6 isn't one of the goals to get seperate partitions for /home -
> >then it would be a great time to add the user_xattr to that partition at
> >least.
> >
> /home by default  is requested  at  
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150670. Jeremy Katz 
> had other ideas about doing this in a much better and flexible way 
> though I dont remember the precise details now. Would you file a RFE 
> against anaconda to add the user_xattr by default to track this?

The right way to get user_xattr by default is to change the default
mount options for the filesystem in the kernel, not installer hacks. 

Jeremy



From billcrawford1970 at gmail.com  Wed Mar  8 16:53:45 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 08 Mar 2006 16:53:45 +0000
Subject: New /etc/services for testing available
In-Reply-To: <440F08C9.4010001@fedoraproject.org>
References: <43D685EB.4090502@redhat.com> <440F0841.5030605@gmail.com>
	<440F08C9.4010001@fedoraproject.org>
Message-ID: <440F0C19.10501@gmail.com>

Rahul Sundaram wrote:
> Bill Crawford wrote:
>
>>
>> I'd really suggest instead making a poll of what people would find 
>> useful.
>>
>> There are going to be a lot of things in there that will probably 
>> never be useful, e.g. 2545 "sis-emt" is one I registered, and I'm 
>> pretty sure is now unused, or certainly of only very limited use.
>>
>> Just a thought.
>
> Whats the harm in having them there though?
>
Wasted time, mostly. I know we're talking about less than a second per, 
but it's still unnecessary.

Harm would mostly be e.g. confusion caused to people looking at netstat 
output, though I'm pleased to see things like the AOL port numbers 
listed there (which is certainly common enough that I see it primarily 
useful; however even then .. *shrug*).

Anyway, it's wasted time for an app to search. Granted I'm only 
referring to one particular entry, but I can guarantee that for the 
majority of people out there, if a connection happens to be on port 
2545, having it show up as "sis-emt" isn't helping them one bit :)

Same probably goes for a lot of the others, is the point I was making. 
If that ends up being a majority of them (which I suspect) it really is 
just wasted time. Trivial in many cases, yes, but still quite 
unnecessary, and again, probably confusing more than helpful anyway. In 
other words:-

Cost: time.
Benefit: loss of time figuring out why a connection shows up as "foo" in 
netstat output.

(i.e. the "benefit" side is negative too.)

FWIW I do agree that having a few more than the barest minimum is 
probably useful. But multiplying up the time taken to scan /etc/services 
significantly for no or possibly negative benefit is just (IMO) poor 
engineering choice.

Again, I'm explicitly talking about a subset of what's there, not saying 
"don't expand it, DANGER WILL ROBINSON DANGER" without thought. I *know* 
at least one entry in there is pretty useless. And I'm sure there will 
be others.

I'm asking for a positive input of what folk feel *should* be in there, 
and suggesting that all such be included. Hoping it'll be less than the 
full list :)



From notting at redhat.com  Wed Mar  8 17:03:52 2006
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 8 Mar 2006 12:03:52 -0500
Subject: rawhide report: 20060307 changes
In-Reply-To: <440EDC67.9090005@redhat.com>
References: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>
	<1141797358.2294.2.camel@localhost.localdomain>
	<440E968F.8010302@vip.hr> <440EDC67.9090005@redhat.com>
Message-ID: <20060308170352.GE3048@devserv.devel.redhat.com>

Christopher Aillon (caillon at redhat.com) said: 
> >Speaking about NM, are there any plans for supporting static IP addresses?
> 
> Static IPs are supported, but there is no way to configure it with NM. 
> Configure it with system-config-network, and NM will pick up the static 
> IP fine.

... assuming your devices end up loaded in the same order.

Bill



From pertusus at free.fr  Wed Mar  8 17:04:40 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 8 Mar 2006 18:04:40 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <1141836633.21278.2.camel@orodruin.boston.redhat.com>
References: <440CD6DC.6020903@redhat.com> <20060308153307.GF2238@free.fr>
	<1141836633.21278.2.camel@orodruin.boston.redhat.com>
Message-ID: <20060308170440.GK2238@free.fr>

> Did you not have obsoletes enabled?  iiimf-libs at least should have
> been removed by scim obsoleting old versions.  Some packages being left

Yep, that's strange, I have scim-libs installed, and that package obsoletes
iiimf-libs. Something went wrong. Unfortunately I haven't redirected the
yum errors :-(

I have obsoletes enabled (this is the default, if I'm not wrong).

> isn't abnormal on an upgrade.

Yep, but won't these block later updates? For example gnome-kerberos
requires a lot of libs. I understand that yum cannot deal with those
packages, but maybe anaconda should? After more thinking, it is not obvious.
Indeed it could be possible that I rebuild locally new versions of a 
package dropped from core and not obsoleted. So anaconda wouldn't be very
nice if it removed it. Maybe the only thing to do should be to explicitely
list such packages in the release notes. In the FC-4 release notes, there 
is a list of packages moved to extras, but no list of packages dropped from 
core and still not taken by extras.

--
Pat 



From pertusus at free.fr  Wed Mar  8 17:16:59 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 8 Mar 2006 18:16:59 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <440F005D.3080901@city-fan.org>
References: <440CD6DC.6020903@redhat.com> <20060308153307.GF2238@free.fr>
	<440F005D.3080901@city-fan.org>
Message-ID: <20060308171659.GL2238@free.fr>

> Regarding perl-XML-Encoding, perl-libxml-enno, and foomatic, see 
> Bugzilla #128879
> 
> Basically, perl-libxml-enno has been split into (some of) its 
> constituent modules (I believe perl-XML-DOM should obsolete it), and 
> perl-XML-Encoding, which was a dep of perl-libxml-enno, is no longer 
> needed in FC5 and so was dropped. foomatic has dropped the deps on these 
> packages too.

Ok. Everything is in order, so, except that I believe that at least 
perl-XML-Encoding should appear in 
http://fedoraproject.org/wiki/Extras/OrphanedPackages
or in
http://fedoraproject.org/wiki/Extras/OrphanedPackagesFC4
and it could be a good thing to also list the other modules that were
provided by perl-libxml-enno, even though they were never in fedora
core as such.

Maybe I could directly contact the person in charge of updating the list 
of Packages removed from Fedora Core 4 not yet imported into Fedora Extras?
Or am I too hasty?

--
Pat



From louisg00 at bellsouth.net  Wed Mar  8 19:05:46 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Wed, 08 Mar 2006 14:05:46 -0500
Subject: gnome trash (UGENT: found problem)
In-Reply-To: <1141248373.22829.3.camel@soncomputer>
References: <1141240004.2283.3.camel@soncomputer>
	<1141248373.22829.3.camel@soncomputer>
Message-ID: <1141844746.4580.8.camel@soncomputer>

> > Seems to occur with user accounts. root is ok.
> 
> Very strange. It works for me with user accounts. Can you try making a
> new account and try that? Something must be different with the computers
> or accounts where it doesn't work.

I did some investigating and found that this problem only occurs if /home
is a separate partition. I unmounted /home and created a new account, logged
in created a new text file and deleted it. All with nautilus. Trash showed
the file and was able to see it under the trash window.

Now I removed the new account and remounted /home. Did the same steps,
created a new account, logged in and create and deleted text file. Trash
did not show anything but ~.Trash had the file.

-Louis



From rdieter at math.unl.edu  Wed Mar  8 19:19:36 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 08 Mar 2006 13:19:36 -0600
Subject: gnome trash (UGENT: found problem)
In-Reply-To: <1141844746.4580.8.camel@soncomputer>
References: <1141240004.2283.3.camel@soncomputer>	<1141248373.22829.3.camel@soncomputer>
	<1141844746.4580.8.camel@soncomputer>
Message-ID: <440F2E48.3080001@math.unl.edu>

Louis E Garcia II wrote:
>>>Seems to occur with user accounts. root is ok.
>>
>>Very strange. It works for me with user accounts. Can you try making a
>>new account and try that? Something must be different with the computers
>>or accounts where it doesn't work.
> 
> 
> I did some investigating and found that this problem only occurs if /home
> is a separate partition. I unmounted /home and created a new account, logged
> in created a new text file and deleted it. All with nautilus. Trash showed
> the file and was able to see it under the trash window.
> 
> Now I removed the new account and remounted /home. Did the same steps,
> created a new account, logged in and create and deleted text file. Trash
> did not show anything but ~.Trash had the file.


http://bugzilla.redhat.com/ is your friend.

-- Rex



From gaptag at gmail.com  Wed Mar  8 23:45:23 2006
From: gaptag at gmail.com (Brian)
Date: Wed, 8 Mar 2006 23:45:23 +0000
Subject: Bluetooth missing from i586 kernel config?
Message-ID: <3dc4f1f50603081545t54ae2785l@mail.gmail.com>

Hi,

I've been struggling trying to get my USB bluetooth dongle to work on
my i586 based MiniITX since I started trying FC5 (Test 3).

The same BT dongle worked fine under the old FC4 installation.

>From what I can see, in the installed i586 kernel (2.6.15-1.2025_FC5)
the drivers and net modules are all missing. To prove this I just
installed the i686 kernel on another machine and bluetooth worked fine
and the relevant directories with modules were present:
i.e.
/lib/modules/2.6.15-1.2025_FC5/kernel/drivers/bluetooth
/lib/modules/2.6.15-1.2025_FC5/kernel/net/bluetooth

This seems to have been the case for all kernel builds I've tried in
the past few weeks.

Is this just an error in the config file used to compile the i586
kernel, or a concious decision to leave it out (in which case,
shouldn't the bluetooth service be removed too as it's throwing errors
on every boot?).

I'm hoping it's just an error, as I can't bear to think about having
to figure out how to manually compile every single new kernel from
source just to get bluetooth back on my mini-itx machine! :-(

Brian



From davej at redhat.com  Wed Mar  8 23:48:41 2006
From: davej at redhat.com (Dave Jones)
Date: Wed, 8 Mar 2006 18:48:41 -0500
Subject: Bluetooth missing from i586 kernel config?
In-Reply-To: <3dc4f1f50603081545t54ae2785l@mail.gmail.com>
References: <3dc4f1f50603081545t54ae2785l@mail.gmail.com>
Message-ID: <20060308234841.GA1730@redhat.com>

On Wed, Mar 08, 2006 at 11:45:23PM +0000, Brian wrote:
 > Hi,
 > 
 > I've been struggling trying to get my USB bluetooth dongle to work on
 > my i586 based MiniITX since I started trying FC5 (Test 3).
 > 
 > The same BT dongle worked fine under the old FC4 installation.
 > 
 > >From what I can see, in the installed i586 kernel (2.6.15-1.2025_FC5)
 > the drivers and net modules are all missing. To prove this I just
 > installed the i686 kernel on another machine and bluetooth worked fine
 > and the relevant directories with modules were present:
 > i.e.
 > /lib/modules/2.6.15-1.2025_FC5/kernel/drivers/bluetooth
 > /lib/modules/2.6.15-1.2025_FC5/kernel/net/bluetooth
 > 
 > This seems to have been the case for all kernel builds I've tried in
 > the past few weeks.
 > 
 > Is this just an error in the config file used to compile the i586
 > kernel, or a concious decision to leave it out (in which case,
 > shouldn't the bluetooth service be removed too as it's throwing errors
 > on every boot?).
 > 
 > I'm hoping it's just an error, as I can't bear to think about having
 > to figure out how to manually compile every single new kernel from
 > source just to get bluetooth back on my mini-itx machine! :-(

over-aggressive slimming down of the 586 kernel.
I had fixing that on my TODO, but it got bubbled down by
other things in the last few days.  I'll try and get to it tonight.

		Dave

-- 
http://www.codemonkey.org.uk



From tjb at unh.edu  Thu Mar  9 00:45:13 2006
From: tjb at unh.edu (Thomas J. Baker)
Date: Wed, 08 Mar 2006 19:45:13 -0500
Subject: other annoyances before fc5
In-Reply-To: <440AC7E0.7040504@fedoraproject.org>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<1141553990.6034.1.camel@rousalka.dyndns.org>
	<440AC0AD.8030300@fedoraproject.org>
	<1141556553.6034.5.camel@rousalka.dyndns.org>
	<440AC7E0.7040504@fedoraproject.org>
Message-ID: <1141865113.2690.9.camel@continuity>

On Sun, 2006-03-05 at 16:43 +0530, Rahul Sundaram wrote:
> Nicolas Mailhot wrote:
> 
> >It's pretty erratic - I suppose at one point of my workflow something
> >happens that puts the panel in unkillable state. Pretty difficult to
> >pinpoint - I have long sessions
> >
> >I don't have a bug number but this particular problem has been reported
> >by several people already on the lists so I suppose there is an entry in
> >bugzilla somewhere.
> >  
> >
> There isnt any bug reports filed on this against fedora devel or any of 
> the FC 5 test releases. If you come across this issue again, kindly file 
> a bug reports with the details.
> 
> 
> -- 
> Rahul 
> 
> 
> 

I filed this back on Feb 23rd....

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


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



From prigault at oricom.ca  Thu Mar  9 03:57:55 2006
From: prigault at oricom.ca (Philippe Rigault)
Date: Wed, 8 Mar 2006 22:57:55 -0500
Subject: Request: boot rescue environment from USB key
Message-ID: <200603082257.55895.prigault@oricom.ca>

If one wants to boot Fedora Core from a USB key (using diskboot.img from the 
images directory), it is currently only possible to run the installer, but 
not a rescue environment. 

It would be very helpful to be able to boot a rescue environment from an USB 
key.

Is that doable easily ?

Cheers,

Philippe



From jkeating at j2solutions.net  Thu Mar  9 04:19:08 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 08 Mar 2006 23:19:08 -0500
Subject: Request: boot rescue environment from USB key
In-Reply-To: <200603082257.55895.prigault@oricom.ca>
References: <200603082257.55895.prigault@oricom.ca>
Message-ID: <1141877948.20202.23.camel@ender>

On Wed, 2006-03-08 at 22:57 -0500, Philippe Rigault wrote:
> If one wants to boot Fedora Core from a USB key (using diskboot.img from the 
> images directory), it is currently only possible to run the installer, but 
> not a rescue environment. 
> 
> It would be very helpful to be able to boot a rescue environment from an USB 
> key.
> 
> Is that doable easily ? 

I'm reasonably certain that if you boot the diskboot.img with 'rescue'
as a boot option, you'll get a rescue environment.  In fact, I just
tested it and it does work.  You still have to point to a location of
Stage2 (IE an install location), but it does go into Rescue mode.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060308/633f5d72/attachment.sig>

From stanfinley at comcast.net  Thu Mar  9 05:26:17 2006
From: stanfinley at comcast.net (Stanton Finley)
Date: Wed, 08 Mar 2006 22:26:17 -0700
Subject: FC5 Final Release
Message-ID: <1141881977.5982.5.camel@stantonfinley.org>

> Ivan Gyurdiev wrote:
> 
> Maybe it's a good time to make it bootable then?
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182008
> 
> I also have heard nothing from the Xorg bugzilla regarding making the
> nv driver work:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182396
> 
> Then there's the minor inconvenience of gnome-netstatus being broken >
> with my atheros chip:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861

And these:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182147

Stanton Finley
http://stanton-finley.net/



From jkeating at redhat.com  Thu Mar  9 06:14:27 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 09 Mar 2006 01:14:27 -0500
Subject: FC5 Final Release
In-Reply-To: <1141881977.5982.5.camel@stantonfinley.org>
References: <1141881977.5982.5.camel@stantonfinley.org>
Message-ID: <1141884867.20202.25.camel@ender>

On Wed, 2006-03-08 at 22:26 -0700, Stanton Finley wrote:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182147
> 

These appear to be machine specific, and need a fix from the machine
provider.  Not sure if this is something we can fix in Fedora space.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060309/5475b5af/attachment.sig>

From stanfinley at comcast.net  Thu Mar  9 06:39:31 2006
From: stanfinley at comcast.net (Stanton Finley)
Date: Wed, 08 Mar 2006 23:39:31 -0700
Subject: FC5 Final Release
In-Reply-To: <1141884867.20202.25.camel@ender>
References: <1141881977.5982.5.camel@stantonfinley.org>
	<1141884867.20202.25.camel@ender>
Message-ID: <1141886371.5982.10.camel@stantonfinley.org>

On Thu, 2006-03-09 at 01:14 -0500, Jesse Keating wrote:
> On Wed, 2006-03-08 at 22:26 -0700, Stanton Finley wrote:
> > 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182147
> > 
> 
> These appear to be machine specific, and need a fix from the machine
> provider.  Not sure if this is something we can fix in Fedora space.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

This then begs the question why do the FC2, FC3, and FC4 installation
media boot and install on the same machine without incident? What's
different about the FC5 installation image kernel and can it be fixed?

Stanton Finley
http://stanton-finley.net/



From sundaram at fedoraproject.org  Thu Mar  9 06:45:13 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 09 Mar 2006 12:15:13 +0530
Subject: other annoyances before fc5
In-Reply-To: <1141865113.2690.9.camel@continuity>
References: <duci8r$9si$1@sea.gmane.org>	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>	<440AA731.7020302@adslpipe.co.uk>	<1141553990.6034.1.camel@rousalka.dyndns.org>	<440AC0AD.8030300@fedoraproject.org>	<1141556553.6034.5.camel@rousalka.dyndns.org>	<440AC7E0.7040504@fedoraproject.org>
	<1141865113.2690.9.camel@continuity>
Message-ID: <440FCEF9.2080807@fedoraproject.org>

Thomas J. Baker wrote:

>
>>I filed this back on Feb 23rd....
>>
>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182653
>>
>>    
>>
Thanks. Somehow missed it in my queries. Is this still reproducible for you?

-- 
Rahul 





From sundaram at fedoraproject.org  Thu Mar  9 06:52:09 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 09 Mar 2006 12:22:09 +0530
Subject: FC5 Final Release
In-Reply-To: <1141886371.5982.10.camel@stantonfinley.org>
References: <1141881977.5982.5.camel@stantonfinley.org>	<1141884867.20202.25.camel@ender>
	<1141886371.5982.10.camel@stantonfinley.org>
Message-ID: <440FD099.40802@fedoraproject.org>

Stanton Finley wrote:

>On Thu, 2006-03-09 at 01:14 -0500, Jesse Keating wrote:
>  
>
>>On Wed, 2006-03-08 at 22:26 -0700, Stanton Finley wrote:
>>    
>>
>>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143
>>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182147
>>>
>>>      
>>>
>>These appear to be machine specific, and need a fix from the machine
>>provider.  Not sure if this is something we can fix in Fedora space.
>>
>>-- 
>>    
>>
>
>This then begs the question why do the FC2, FC3, and FC4 installation
>media boot and install on the same machine without incident? What's
>different about the FC5 installation image kernel and can it be fixed?
>  
>
Syslinux changes seem to affect some specific hardware everytime. Its 
hard to figure out this without the relevant hardware which is not there 
internally. Changing syslinux late in the release cycle might create 
problems like the infamous one in which FC4 wouldnt bootup on some Intel 
chipsets, without feeding in garbage at the bootup prompt, which again  
wasnt there in our labs 
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159026).  Not sure 
there are easy resolutions to such issues.

-- 
Rahul 





From mharris at mharris.ca  Thu Mar  9 07:08:53 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Thu, 09 Mar 2006 02:08:53 -0500
Subject: Please "attach" files to bugzilla,
 instead of pasting into a massive comment
Message-ID: <440FD485.2080102@mharris.ca>

Warning: Frustration rant follows.

More and more over time, I am noticing a tendency of bug reporters
adding log files, config files and other large files to bug reports
by cutting and pasting these massive files into the comment box,
instead of attaching them as proper bugzilla file attachements.

As a developer, this is very irritating because it makes the bug
report incredibly long to view.  You have to scroll forever to
get from one comment to the next, with this massive file pasted
in the middle, making it very hard to follow, and thus making
it more difficult to provide help for the problem being reported.

It also causes bugzilla's word-wrap to affect the text being pasted,
which generally breaks patches, making them no longer apply cleanly,
until they're reattached properly as file attachment by the person
who has the original, or causing the developer more work manually
recreating the patch from scratch by hand editing the source and
regenerating it with diff/gendiff.  This also can cause config files
pasted into comments to be distorted and no longer machine parseable,
depending on the syntax of the file, and how the parser that reads
it handles things that have moved from one line to another due to
wordwrapping in bugzilla.

Bugzilla has a file attachment feature, labeled "Create a file
attachment".  If you can not find it, please use your web browser's
search feature to find the link on the bugzilla page, and _always_
attach these files directly as individual uncompressed text files,
so that developers such as myself can bring the file attachments
up in another web browser tab/window with a simple single mouse
click, while still following the bug report.

Bugzilla used to also have a "Create a file attachment" hyperlink
directly under the "Add a comment" window in red font, which the
majority of users seemed to find right away.  Back then, we got
very few 1Mb log files pasted into bug reports making them
unreadable, however nowadays bugzilla has reverted to the old
behaviour, and an ever mounting number of bugs are getting these
massive files pasted into them.

This is very very irritating.  Please help us (developers) to help
you (bug reporters/testers), by using bugzilla properly, and
thinking about what it is like to be on the receiving end of 500
bug reports and get 30 like this.
</rant>


Feature request filed:
     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184481



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From buildsys at redhat.com  Thu Mar  9 08:22:19 2006
From: buildsys at redhat.com (Build System)
Date: Thu, 9 Mar 2006 03:22:19 -0500
Subject: rawhide report: 20060309 changes
Message-ID: <200603090822.k298MJqf024023@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-11.0.2-1
-----------------
* Wed Mar 08 2006 Jeremy Katz <katzj at redhat.com> - 11.0.2-1
- error handling on fs label reading (#184412)
- add sis190 driver
- remove no-longer shipped lvm2-cluster on upgrade (pjones)

avahi-0.6.9-3
-------------
* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> - 0.6.9-2
- fix scriplet error during installer
- move service-types* to the tools package (avoids multilib conflicts)

* Tue Mar 07 2006 Jason Vas Dias <jvdias at redhat.com> - 0.6.9-1
- Upgrade to upstream version 0.6.9

beagle-0.2.2-3
--------------
* Wed Mar 08 2006 Ray Strode <rstrode at redhat.com> - 0.2.2-3
- turn off beagle by default to limit the severity of
  bug 183898
- fix trigger/post scriptlet (bug 184238)

booty-0.70-1
------------
* Wed Mar 08 2006 Peter Jones <pjones at redhat.com> - 0.70-1
- don't make fd0 entries in device.map, they screw up suspend/hibernate

caching-nameserver-7.3-5.FC5
----------------------------
* Wed Mar 08 2006 Jesse Keating <jkeating at redhat.com> 7.3-5.FC5
- update for version differences FC-3 -> 4 -> 5

dovecot-1.0-0.beta2.7
---------------------
* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> - 1.0-0.beta2.7
- fix scriplet noise some more

e2fsprogs-1.38-12
-----------------
* Wed Mar 08 2006 Peter Jones <pjones at redhat.com> - 1.38-12
- Move /etc/blkid.tab to /etc/blkid/blkid.tab

flex-2.5.4a-37.4
----------------
* Wed Mar 08 2006 Petr Machata <pmachata at redhat.com> - 2.5.4a-37.4
- adding test for #183098 into build process

* Thu Mar 02 2006 Petr Machata <pmachata at redhat.com> - 2.5.4a-37.3
- rebuilt, no changes inside. In hunt for #183098

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 2.5.4a-37.2
- bump again for double-long bug on ppc(64)

gdb-6.3.0.0-1.122
-----------------
* Wed Mar 08 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.122
- Bump up release number.

* Wed Mar 08 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.119
- Fix regression in PIE debugging (BZ 133944) (re?)introduced by
the prelink fix (BZ 175075).  Improve testcase for the prelink fix.
- Revert dwarf2 frame identifier change.

* Tue Mar 07 2006 Alexandre Oliva <aoliva at redhat.com> - 6.3.0.0-1.118
- Bump up release number.

gnome-applets-1:2.13.90-6
-------------------------
* Wed Mar 08 2006 Ray Strode <rstrode at redhat.com> - 2.13.90-6
- improve package installation time by running gconftool-2 only
  once in %post

* Wed Mar 08 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.90-5
- Fix a crash in the mixer applet (#184285, #182957)

gnome-user-docs-2.13.1.1-2
--------------------------
* Wed Mar 08 2006 Ray Strode <rstrode at redhat.com> 2.13.1.1-2
- PreReq instead of Requires scrollkeeper.  Reported by
  Bill Nottingham

gphoto2-2.1.99-8
----------------
* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> 2.1.99-8
- fix i386/x86_64 conflict on fdi files

gtk2-2.8.14-1
-------------
* Wed Mar 08 2006 Matthias Clasen <mclasen at redhat.com> - 2.8.14-1
- Update to 2.8.14 to fix a possible memory overrun
  in gtk_object_sink

* Sun Mar 05 2006 Matthias Clasen <mclasen at redhat.com> - 2.8.13-4
- Don't ship .la files for engines, either

* Wed Mar 01 2006 Karsten Hopp <karsten at redhat.de> 2.8.13-3
- Buildrequires: libXi-devel

hsqldb-0:1.80.1-1jpp_9fc
------------------------
* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> - 0:1.80.1-1jpp_9fc
- use an assigned user/group id
- don't do usermod
- add missing requirements (#182796, #182797)

jakarta-commons-daemon-1:1.0-2jpp_4fc
-------------------------------------
* Wed Mar 08 2006 Rafael Schloming <rafaels at redhat.com> - 1:1.0-2jpp_4fc
- added missing %post section for rebuild-gcj-db

kde-i18n-1:3.5.1-2
------------------
* Wed Mar 08 2006 Than Ngo <than at redhat.com> 1:3.5.1-2 
- add missing zh_TW

kexec-tools-1.101-16
--------------------
* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> - 1.101-16
- fix scriptlet - call chkconfig --add, change the default in the
  script itself (#183633)

* Wed Mar 08 2006 Thomas Graf <tgraf at redhat.com> - 1.101-15
- Don't add kdump service by default, let the user manually add it to
  avoid everyone seeing a warning.

mc-1:4.6.1a-10
--------------
* Wed Mar 08 2006 Jindrich Novy <jnovy at redhat.com> 4.6.1a-10
- fix typo in extensions patch so that C sources are
  highlighted correctly (#184228)

mdadm-2.3.1-3
-------------
* Wed Mar 08 2006 Peter Jones <pjones at redhat.com> - 2.3.1-3
- fix build on ppc64

* Wed Mar 08 2006 Jeremy Katz <katzj at redhat.com> - 2.3.1-2
- fix build on ppc

* Wed Mar 08 2006 Jeremy Katz <katzj at redhat.com> - 2.3.1-1
- update to 2.3.1 to fix raid5 (#184284)

mkinitrd-5.0.30-1
-----------------
* Wed Mar 08 2006 Peter Jones <pjones at redhat.com> - 5.0.30-1
- move blkid.tab* references to /etc/blkid/blkid.tab*
- don't do the selinux context stuff on blkid.tab*, as it now inherits from
  the directory.

notify-daemon-0.3.1-9
---------------------
* Wed Mar 08 2006 John (J5) Palmieri <johnp at redhat.com> - 0.3.1-9
- Add patch to fix struct handling in the dbus glib binding for dbus 0.61
  so image data works again

pam_krb5-2.2.6-2.2
------------------
* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> - 2.2.6-2.2
- don't use paths in man pages - avoids multilib conflicts

quagga-0:0.98.5-4
-----------------
* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> - 0:0.98.5-4
- use an assigned gid for quaggavt

selinux-policy-2.2.23-11
------------------------
* Thu Mar 09 2006 Jeremy Katz <katzj at redhat.com> - 2.2.23-11
- more xen policy fixups

* Wed Mar 08 2006 Jeremy Katz <katzj at redhat.com> - 2.2.23-10
- more xen fixage (#184393)

* Wed Mar 08 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-9
- Fix blkid specification
- Allow postfix to execute mailman_que

udev-084-13
-----------
* Wed Mar 08 2006 Harald Hoyer <harald at redhat.com> - 084-13
- fixed pam_console rules (#182600)

util-linux-2.13-0.17
--------------------
* Wed Mar 08 2006 Karel Zak <kzak at redhat.com> 2.13-0.17
- fix #181782 - mkswap selinux relabeling (fix util-linux-2.13-mkswap-selinux.patch)

xen-3.0.1-4
-----------
* Thu Mar 09 2006 Jeremy Katz <katzj at redhat.com> - 3.0.1-4
- add udev rule so that /dev/xen/evtchn gets created properly
- make pygrub not use /tmp for SELinux
- make xenguest-install actually unmount its nfs share.  also, don't use /tmp

xterm-209-4
-----------
* Tue Mar 07 2006 Jason Vas Dias <jvdias at redhat.com> - 209-4
- fix bug 183993: call set_cursor_gcs in ReverseVideo

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5
	gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5





From gaptag at gmail.com  Thu Mar  9 09:28:16 2006
From: gaptag at gmail.com (Brian)
Date: Thu, 9 Mar 2006 09:28:16 +0000
Subject: Bluetooth missing from i586 kernel config?
Message-ID: <3dc4f1f50603090128k3d5a6106j@mail.gmail.com>

>  > I've been struggling trying to get my USB bluetooth dongle to work on
>  > my i586 based MiniITX since I started trying FC5 (Test 3).
>  >
>  > The same BT dongle worked fine under the old FC4 installation.
>  >
>  > >From what I can see, in the installed i586 kernel (2.6.15-1.2025_FC5)
>  > the drivers and net modules are all missing. To prove this I just
>  > installed the i686 kernel on another machine and bluetooth worked fine
>  > and the relevant directories with modules were present:
>
> over-aggressive slimming down of the 586 kernel.
> I had fixing that on my TODO, but it got bubbled down by
> other things in the last few days.  I'll try and get to it tonight.
>
>                Dave

Thanks Dave! I'll stop hitting my head off the "it's a configuration
issue" brick wall and put bluetooth use on hold till it's fixed. :-)

Brian



From bela.pesics at gmail.com  Thu Mar  9 10:01:47 2006
From: bela.pesics at gmail.com (Bela Pesics)
Date: Thu, 9 Mar 2006 11:01:47 +0100
Subject: FC5 Final Release
In-Reply-To: <440FD099.40802@fedoraproject.org>
References: <1141881977.5982.5.camel@stantonfinley.org>
	<1141884867.20202.25.camel@ender>
	<1141886371.5982.10.camel@stantonfinley.org>
	<440FD099.40802@fedoraproject.org>
Message-ID: <f67c87220603090201n21685793ja8557dd4d36d5813@mail.gmail.com>

On 3/9/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Stanton Finley wrote:
>
> >On Thu, 2006-03-09 at 01:14 -0500, Jesse Keating wrote:
> >
> >
> >>On Wed, 2006-03-08 at 22:26 -0700, Stanton Finley wrote:
> >>
> >>
> >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143
> >>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182147
> >>>
> >>>
> >>>
> >>These appear to be machine specific, and need a fix from the machine
> >>provider.  Not sure if this is something we can fix in Fedora space.


Why from the machine provider? How can you imagine that?
If we can't fix it, at least I have to find a solution for my own poor
laptop... :-)


> >>
> >>--
> >>
> >>
> >
> >This then begs the question why do the FC2, FC3, and FC4 installation
> >media boot and install on the same machine without incident? What's
> >different about the FC5 installation image kernel and can it be fixed?
> >
> >
> Syslinux changes seem to affect some specific hardware everytime. Its
> hard to figure out this without the relevant hardware which is not there
> internally. Changing syslinux late in the release cycle might create
> problems like the infamous one in which FC4 wouldnt bootup on some Intel
> chipsets, without feeding in garbage at the bootup prompt, which again
> wasnt there in our labs
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159026).  Not sure
> there are easy resolutions to such issues.
>

Is "vmlinuz initrd=initrd.img" considered to be a garbage in this case?
If so, what is the way of making sure this is really an upstream bug?

Bela



From gianluca.cecchi at gmail.com  Thu Mar  9 10:37:05 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 9 Mar 2006 11:37:05 +0100
Subject: typos errors in /etc/rc.d/init.d/nfs
Message-ID: <561c252c0603090237r4ae56a0dkc90197b192e58c90@mail.gmail.com>

opened bug 184486



From rodd at clarkson.id.au  Thu Mar  9 11:07:34 2006
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Thu, 09 Mar 2006 22:07:34 +1100
Subject: rawhide report: 20060309 changes
In-Reply-To: <200603090822.k298MJqf024023@porkchop.devel.redhat.com>
References: <200603090822.k298MJqf024023@porkchop.devel.redhat.com>
Message-ID: <1141902454.3463.24.camel@localhost.localdomain>

> gnome-applets-1:2.13.90-6
> -------------------------
> * Wed Mar 08 2006 Ray Strode <rstrode at redhat.com> - 2.13.90-6
> - improve package installation time by running gconftool-2 only
>   once in %post
> 
> * Wed Mar 08 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.90-5
> - Fix a crash in the mixer applet (#184285, #182957)


Hmmm,

Lots of ...

Installed schema `/schemas/apps/cpufreq-applet/prefs/selector_mode' for locale `hi'
Installed schema `/schemas/apps/cpufreq-applet/prefs/selector_mode' for locale `pt'

and then ...

I/O warning : failed to load external entity "/etc/gconf/schemas/divemount.schemas"
Failed to open `/etc/gconf/schemas/divemount.schemas': No such file or directory
/var/tmp/rpm-tmp.87020: line 17: /etc/gconf/schemas/gtik.schemas: Permission denied
/var/tmp/rpm-tmp.87020: line 18: /etc/gconf/schemas/gweather.schemas: Permission denied
/var/tmp/rpm-tmp.87020: line 19: /etc/gconf/schemas/mini-commander-global.schemas: Permission denied
/var/tmp/rpm-tmp.87020: line 20: /etc/gconf/schemas/mini-commander.schemas: Permission denied
/var/tmp/rpm-tmp.87020: line 21: /etc/gconf/schemas/mixer.schemas: Permission denied/var/tmp/rpm-tmp.87020: line 22: /etc/gconf/schemas/modemlights.schemas: Permission denied
/var/tmp/rpm-tmp.87020: line 23: /etc/gconf/schemas/multiload.schemas: Permission denied
/var/tmp/rpm-tmp.87020: line 24: /etc/gconf/schemas/stickynotes.schemas: Permission denied


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jwboyer at jdub.homelinux.org  Thu Mar  9 10:51:00 2006
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Thu, 09 Mar 2006 05:51:00 -0500
Subject: typos errors in /etc/rc.d/init.d/nfs
In-Reply-To: <561c252c0603090237r4ae56a0dkc90197b192e58c90@mail.gmail.com>
References: <561c252c0603090237r4ae56a0dkc90197b192e58c90@mail.gmail.com>
Message-ID: <1141901460.17746.0.camel@yoda.jdub.homelinux.org>

On Thu, 2006-03-09 at 11:37 +0100, Gianluca Cecchi wrote:
> opened bug 184486

If you've opened a bug, you don't need to send an email to this list
about it.  Or if you do, at least add a proper URL so people can just
click on it to see the bug.

Otherwise, it's just noise.

thx,
josh



From ndbecker2 at gmail.com  Thu Mar  9 12:00:43 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 09 Mar 2006 07:00:43 -0500
Subject: rawhide report: 20060309 changes
References: <200603090822.k298MJqf024023@porkchop.devel.redhat.com>
	<1141902454.3463.24.camel@localhost.localdomain>
Message-ID: <dup5d3$sdt$1@sea.gmane.org>

same here



From clydekunkel7734 at cox.net  Thu Mar  9 13:03:25 2006
From: clydekunkel7734 at cox.net (Clyde E. Kunkel)
Date: Thu, 09 Mar 2006 08:03:25 -0500
Subject: rawhide report: 20060309 changes
In-Reply-To: <dup5d3$sdt$1@sea.gmane.org>
References: <200603090822.k298MJqf024023@porkchop.devel.redhat.com>	<1141902454.3463.24.camel@localhost.localdomain>
	<dup5d3$sdt$1@sea.gmane.org>
Message-ID: <4410279D.8020405@cox.net>

Neal Becker wrote:
> same here
> 

same here

-- 
Regards,

Old Fart
(my reply-to address is "munged" to defeat spambots)



From ndbecker2 at gmail.com  Thu Mar  9 13:04:02 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 09 Mar 2006 08:04:02 -0500
Subject: NM + caching-nameserver?
Message-ID: <dup93r$bhd$1@sea.gmane.org>

Is NM compatible with a local caching nameserver?  It looks like the default
NM setup is to set resolv.conf from dhcp.  If I want to cache results
locally, how can I do this?



From tarjei.knapstad at gmail.com  Thu Mar  9 13:00:58 2006
From: tarjei.knapstad at gmail.com (Tarjei Knapstad)
Date: Thu, 9 Mar 2006 14:00:58 +0100
Subject: Qt 4 RPM and pkg-config problem
In-Reply-To: <440EF622.6020808@math.unl.edu>
References: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>
	<1141824368.20537.53.camel@mrwibble.mrwobble>
	<440EF622.6020808@math.unl.edu>
Message-ID: <ff5e09cc0603090500m7e0d6592l4359a0c8e745f8f5@mail.gmail.com>

On 3/8/06, Rex Dieter <rdieter at math.unl.edu> wrote:
> Paul F. Johnson wrote:
>
> >>Oh, Paul F.J., did you get around to add this RPM to Extras? (can't
> >>find the bugzilla entry in case you did)
> >
> >
> > Is it worth putting Qt4 into extras as it's sooner or later going to be
> > in core?
> >
> > I have no problem submitting it, just don't want to duplicate effort.
>
> I had been working on it, but got side-tracked with several other
> projects.  So, as it stands, I'd be willing to review anything
> submitted... (-:
>

Sounds good, I'll offer my inputs as well once it is committed.

With the pkg-config bug though I'd say the package is slightly broken
as you can't use autotools to detect the library (well, I guess you
can, but pkg-config is much the preferred solution). No suggestions
for a fix?

Cheers,
--
Tarjei



From davej at redhat.com  Thu Mar  9 13:27:21 2006
From: davej at redhat.com (Dave Jones)
Date: Thu, 9 Mar 2006 08:27:21 -0500
Subject: Bluetooth missing from i586 kernel config?
In-Reply-To: <3dc4f1f50603090128k3d5a6106j@mail.gmail.com>
References: <3dc4f1f50603090128k3d5a6106j@mail.gmail.com>
Message-ID: <20060309132721.GB26354@redhat.com>

On Thu, Mar 09, 2006 at 09:28:16AM +0000, Brian wrote:
 > >  > I've been struggling trying to get my USB bluetooth dongle to work on
 > >  > my i586 based MiniITX since I started trying FC5 (Test 3).
 > >  >
 > >  > The same BT dongle worked fine under the old FC4 installation.
 > >  >
 > >  > >From what I can see, in the installed i586 kernel (2.6.15-1.2025_FC5)
 > >  > the drivers and net modules are all missing. To prove this I just
 > >  > installed the i686 kernel on another machine and bluetooth worked fine
 > >  > and the relevant directories with modules were present:
 > >
 > > over-aggressive slimming down of the 586 kernel.
 > > I had fixing that on my TODO, but it got bubbled down by
 > > other things in the last few days.  I'll try and get to it tonight.
 > >
 > >                Dave
 > 
 > Thanks Dave! I'll stop hitting my head off the "it's a configuration
 > issue" brick wall and put bluetooth use on hold till it's fixed. :-)

I fixed it in CVS, will be in the next build.

		Dave

-- 
http://www.codemonkey.org.uk



From tarjei.knapstad at gmail.com  Thu Mar  9 14:07:26 2006
From: tarjei.knapstad at gmail.com (Tarjei Knapstad)
Date: Thu, 9 Mar 2006 15:07:26 +0100
Subject: Qt 4 RPM and pkg-config problem
In-Reply-To: <ff5e09cc0603090500m7e0d6592l4359a0c8e745f8f5@mail.gmail.com>
References: <ff5e09cc0603080502j68a2d47fudc715013bf07d359@mail.gmail.com>
	<1141824368.20537.53.camel@mrwibble.mrwobble>
	<440EF622.6020808@math.unl.edu>
	<ff5e09cc0603090500m7e0d6592l4359a0c8e745f8f5@mail.gmail.com>
Message-ID: <ff5e09cc0603090607y4779a427n8f3f9bc90def4f15@mail.gmail.com>

> With the pkg-config bug though I'd say the package is slightly broken
> as you can't use autotools to detect the library (well, I guess you
> can, but pkg-config is much the preferred solution). No suggestions
> for a fix?
>

I'm currently adding some sed stuff to the spec to go over all the .pc
files and strip out the superfluous -L flag. I'll post an updated spec
here later today, just need to check that it works as intended first.

--
T



From gianluca.cecchi at gmail.com  Thu Mar  9 14:16:15 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 9 Mar 2006 15:16:15 +0100
Subject: typos errors in /etc/rc.d/init.d/nfs
Message-ID: <561c252c0603090616i5167529fg546e223198c22808@mail.gmail.com>

On Thu, 09 Mar 2006 05:51:00 -0500 Josh Boyer wrote:
> Otherwise, it's just noise.
You are right, in general, but due to the imminent release date I
thought I had better to post also here so that a trivial not blocking
bug could have more chance to be seen and eventually forwarded...
In bugzilla I posted the bug as "Normal", because we are talking about
a "cosmetic" bug (only a wrong echo command inside the script for
status option): these days I think mantainers are only targeted to
blocking problems.
Call this "efficiency through redundancy"?



From sundaram at fedoraproject.org  Thu Mar  9 14:21:32 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 09 Mar 2006 19:51:32 +0530
Subject: typos errors in /etc/rc.d/init.d/nfs
In-Reply-To: <561c252c0603090616i5167529fg546e223198c22808@mail.gmail.com>
References: <561c252c0603090616i5167529fg546e223198c22808@mail.gmail.com>
Message-ID: <441039EC.3030805@fedoraproject.org>

Gianluca Cecchi wrote:

>On Thu, 09 Mar 2006 05:51:00 -0500 Josh Boyer wrote:
>  
>
>>Otherwise, it's just noise.
>>    
>>
>You are right, in general, but due to the imminent release date I
>thought I had better to post also here so that a trivial not blocking
>bug could have more chance to be seen and eventually forwarded...
>  
>
In general these sort of bugs are probably going to be ignored till the 
release while we work on the major issues.

>In bugzilla I posted the bug as "Normal", because we are talking about
>a "cosmetic" bug (only a wrong echo command inside the script for
>status option): these days I think mantainers are only targeted to
>blocking problems.
>Call this "efficiency through redundancy"?
>  
>
It might be good to also post to the list when a bug is indeed major and 
needs to be highlighted and in that case, kindly provide a direct link. 
If its not a major bug, just filing a report in bugzilla is pretty much 
efficient. Thanks.


-- 
Rahul 





From jvdias at redhat.com  Thu Mar  9 18:13:33 2006
From: jvdias at redhat.com (Jason Vas Dias)
Date: Thu, 9 Mar 2006 13:13:33 -0500
Subject: NM + caching-nameserver?
In-Reply-To: <dup93r$bhd$1@sea.gmane.org>
References: <dup93r$bhd$1@sea.gmane.org>
Message-ID: <200603091313.34150.jvdias@redhat.com>

On Thursday 09 March 2006 08:04, Neal Becker <ndbecker2 at gmail.com> wrote:
>  Is NM compatible with a local caching nameserver?  It looks like the default
>  NM setup is to set resolv.conf from dhcp.  If I want to cache results
>  locally, how can I do this?
>  
You need to enable the named and dhcdbd services:
  # chkconfig --level=235 named on; chkconfig --level=0146 named off;
  # chkconfig --level=235 dhcdbd on; chkconfig --level=0146 dhcdb off;
NetworkManager depends on these services being started for caching-nameserver
use to be enabled.



From mharris at mharris.ca  Thu Mar  9 18:18:17 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Thu, 09 Mar 2006 13:18:17 -0500
Subject: typos errors in /etc/rc.d/init.d/nfs
In-Reply-To: <561c252c0603090616i5167529fg546e223198c22808@mail.gmail.com>
References: <561c252c0603090616i5167529fg546e223198c22808@mail.gmail.com>
Message-ID: <44107169.1040200@mharris.ca>

Gianluca Cecchi wrote:
> On Thu, 09 Mar 2006 05:51:00 -0500 Josh Boyer wrote:
> 
>>Otherwise, it's just noise.
> 
> You are right, in general, but due to the imminent release date I
> thought I had better to post also here so that a trivial not blocking
> bug could have more chance to be seen and eventually forwarded...
> In bugzilla I posted the bug as "Normal", because we are talking about

The bugzilla "Priority" field is almost completely and totally
universally ignored.

The reason for this, is that different users think very different
things about what "priority" means to them, which generally is
relative to _their_ circumstances.

A developer however, thinks of the priority of a given bug, based
on what all work is on their plate, including bug fixing, development,
Fedora work, RHEL work, other work projects, etc., and schedules their
time based on that.  Any given bug's priority is relative to the
developer's schedules, product schedules, etc.

Aside from that, users arbitrarily raise the priority field to
"high" almost randomly, in an attempt to try to raise their bug
to be more visible, or to get people to look at it sooner.

A developer must decide the priority based on various factors which
the reporter(s) are not aware of, and so the two viewpoints differ
very greatly.  Any developer can modify the priority field on a bug
to more closely reflect the bug's real priority from an engineering
viewpoint, however this does not really provide any useful value to
the developer, nor to the reporter(s).

Since the priority field is always end user modifyable, if the
reporter disagrees with the priority a developer has set, they often
will be upset at the developer, add flames to the bug, and set the
priority back to "high" as if to say "No, damnit you will treat this
bug as high priority right now or else!".

That type of logic is where the whole publically modifyable bugzilla
bug priority concept breaks down into uselessness.  It is pointless
for a developer to have a bugzilla priority field war with a reporter,
and pointless to waste manhours justifying or explaining to a
reporter why you've assigned a given bug a particular priority.  It's
also not worth upsetting someone over something which is really an
internal administrative engineering decision.

As such, the bugzilla priority field is useless and ignored almost
entirely by everyone.  Feel free to set it to something if it makes
you feel butterflies inside, but it is probably not going to have
any real-world effect.

This topic comes up from time to time, and generally people offer
suggestions as to changing bugzilla to allow the reporter to set
the priority only at submission time, then make it read-only after
that.  While that would prevent the silly back and forth priority
war problem, if a developer changes the priority, and a user sees
it and is upset about it, they'll still be angry in the bug report,
and maybe not even respond anymore.  That is not healthy for
anyone either.

Other suggestions include having a developer-only priority field
which is only visible internally, and is initially set from the
publically visible priority field.  That assumes that a priority
field is actually useful at all however.  ;o)

Nowadays, the way most of us work, is to review bugs in NEW state
as they come in, or in cycles such as once a day, once a week, once
every 2 weeks, etc. and then do an initial triage on them, and
assign the bug to various keywords or bug target trackers such
as "FC5Target".  As we work, we may be working on high-priority
work or something else.  Time gets allotted say for working on
"FC5Blocker" issues, or "FC5Target", etc. and bugs lists are
passed through.  Other developers may keep other sub-trackers, or
even keep track on paper to manage priorities.

So, from a task based workflow perspective as an engineer receiving
on order of 50-100 bug reports or more per month, the bugzilla
priority field is 200% useless.  Task based workflow schemes (such
as our internal MCP tool) and other per-project, per-package,
per-team, or per-developer schemes of prioritzing issues work much
better in practice, and vary as needed in different groups.

If we allowed external parties to have full control over our
priorities, then we'd never release an OS, and important things
that weren't reported by users as "high priority", but which were
very urgent or high priority nonetheless - would never get done.

And thus ends todays lecture. ;o)

Class dismissed!


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From kwade at redhat.com  Thu Mar  9 19:01:53 2006
From: kwade at redhat.com (Karsten Wade)
Date: Thu, 09 Mar 2006 11:01:53 -0800
Subject: [WIKI SNAP] FC 5 latest release notes >23:59 UTC today
Message-ID: <1141930913.3391.153.camel@erato.phig.org>

http://fedoraproject.org/wiki/Docs/Beats

Later today ... or tonight ... depending on flurries of activity from
ya'll, we are going to freeze the release notes beats for an edit pass
prior to putting out another round of XML.

Next week, with the FC 5 launch, we are going to be posting this latest
release notes.  The URL is prominently at the top of the release notes
on the installed system.

Once we unlock the Wiki, you can continue to put in changes for FC 5.
If they are crucial for launch, please note that in the the changelog
message, and consider filing a bug report against the release-notes
component of Fedora Documentation.  We have this Web launch precisely so
we can be flexible up to the last few days before release to get in
crucial, important, and timely information.  Just don't be abusive. :)

Thanks again to all of you for your support and contributions.  

Best.  
Release Notes.  
Ever.

- Karsten
Cc: os-devel-list and fedora-maintainers-list (separately)
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
Content Services                          Fedora Documentation Project
http://www.redhat.com/docs   http://fedoraproject.org/wiki/DocsProject
-------------- 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/20060309/20344d05/attachment.sig>

From louisg00 at bellsouth.net  Thu Mar  9 19:11:36 2006
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Thu, 09 Mar 2006 14:11:36 -0500
Subject: Stability of firefox
Message-ID: <1141931496.4234.2.camel@soncomputer>

Has anyone been encountering stability issues with firefox? Seems to
segfault randomly when trying to download. Also a few times loading
pages.

-Louis



From jspaleta at gmail.com  Thu Mar  9 19:51:37 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 9 Mar 2006 14:51:37 -0500
Subject: Stability of firefox
In-Reply-To: <1141931496.4234.2.camel@soncomputer>
References: <1141931496.4234.2.camel@soncomputer>
Message-ID: <604aa7910603091151g69bec8a8l36fccca7d8ed2079@mail.gmail.com>

On 3/9/06, Louis E Garcia II <louisg00 at bellsouth.net> wrote:
> Has anyone been encountering stability issues with firefox? Seems to
> segfault randomly when trying to download. Also a few times loading
> pages.

did you install any additional extentions or plugins?

-jef



From tjarls at iee.lu  Thu Mar  9 19:52:00 2006
From: tjarls at iee.lu (Charles Lopes)
Date: Thu, 09 Mar 2006 20:52:00 +0100
Subject: typos errors in /etc/rc.d/init.d/nfs
In-Reply-To: <441039EC.3030805@fedoraproject.org>
References: <561c252c0603090616i5167529fg546e223198c22808@mail.gmail.com>
	<441039EC.3030805@fedoraproject.org>
Message-ID: <44108760.2000401@iee.lu>

Rahul Sundaram wrote:
> Gianluca Cecchi wrote:
>
>> On Thu, 09 Mar 2006 05:51:00 -0500 Josh Boyer wrote:
>>  
>>
>>> Otherwise, it's just noise.
>>>   
>> You are right, in general, but due to the imminent release date I
>> thought I had better to post also here so that a trivial not blocking
>> bug could have more chance to be seen and eventually forwarded...
>>  
>>
> In general these sort of bugs are probably going to be ignored till 
> the release while we work on the major issues.
>
Although it's only a cosmetic issue, this particular bug has been 
reported before FC4:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158866
It's trivial to fix it. Could someone just go and fix in cvs?



From pjones at redhat.com  Thu Mar  9 21:09:58 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 09 Mar 2006 16:09:58 -0500
Subject: 2GB swap partition limit?
In-Reply-To: <1141561466.440ad87ae2478@www.jouy.inra.fr>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
Message-ID: <1141938598.4313.12.camel@vroomfondel.internal.datastacks.com>

On Sun, 2006-03-05 at 13:24 +0100, ?meric Maschino wrote:

> My workstation has been upgraded to 6GB RAM. I let anaconda automatically manage
> the partitions on the disk. It created a 4GB swap partition in a LVM volume.
> But top, free and gnome-system-monitor all report that my swap space is 2GB
> (more precisely, 1.9GB). IIRC, there was a 2GB limit partition for the swap
> size in the past, but I thought this has been overcame.

Hrm, that's a bit odd.  Anaconda by default won't create a swap device
larger than 2GB unless you specifically set the size higher.  You're
sure it's a 4GB LV it's on?

Can we see lvdisplay's output?

Also, what does /proc/swaps say?

-- 
  Peter



From gianluca.cecchi at gmail.com  Thu Mar  9 22:31:01 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 9 Mar 2006 23:31:01 +0100
Subject: typos errors in /etc/rc.d/init.d/nfs
Message-ID: <561c252c0603091431v2cc18a34sbfc473ce04f95d4a@mail.gmail.com>

On  Thu, 09 Mar 2006 13:18:17 -0500 Mike A. Harris wrote
> A developer however, thinks of the priority of a given bug, based
> on what all work is on their plate, including bug fixing, development,
> Fedora work, RHEL work, other work projects, etc., and schedules their
> time based on that.  Any given bug's priority is relative to the
> developer's schedules, product schedules, etc.

Thanks for your explanation Mike, that gives the members like me, who
are non developers, a better understanding of the heavy jobs of open
source sw developers.
I think threads like this are useful to establish a contact between
different minds and roles, and to keep clear that these lists are not
only for reporting pure software/technology related issues, that can
be otherwise somehow arid and dry...
For what bug reporting is related, I'm in the active part: for example in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184051
(ok the link Josh?) there was a very rapid committment from both sides...
It was worth leaving for some months slackware current and put the
nose inside fedora!
Anyway, I understood you Mike are on my side in this thread... (just a
joke, sorry ;-0

Please open the door!!! Who locked me in?!? Where are you guys: you
let me alone in the classroom!



From wieseltux23 at gmail.com  Thu Mar  9 22:27:04 2006
From: wieseltux23 at gmail.com (wieseltux23)
Date: Thu, 9 Mar 2006 23:27:04 +0100
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1141877948.20202.23.camel@ender>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
Message-ID: <20060309232704.7b003dbf.wieseltux23@gmail.com>

www.wolfspakt.de/spiel.php?id=7358


On Wed, 08 Mar 2006 23:19:08 -0500
Jesse Keating <jkeating at j2solutions.net> wrote:

> On Wed, 2006-03-08 at 22:57 -0500, Philippe Rigault wrote:
> > If one wants to boot Fedora Core from a USB key (using diskboot.img from the 
> > images directory), it is currently only possible to run the installer, but 
> > not a rescue environment. 
> > 
> > It would be very helpful to be able to boot a rescue environment from an USB 
> > key.
> > 
> > Is that doable easily ? 
> 
> I'm reasonably certain that if you boot the diskboot.img with 'rescue'
> as a boot option, you'll get a rescue environment.  In fact, I just
> tested it and it does work.  You still have to point to a location of
> Stage2 (IE an install location), but it does go into Rescue mode.
> 
> -- 
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
> 
-------------- 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/20060309/a119b074/attachment.sig>

From jkeating at j2solutions.net  Thu Mar  9 22:36:01 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 09 Mar 2006 17:36:01 -0500
Subject: Request: boot rescue environment from USB key
In-Reply-To: <20060309232704.7b003dbf.wieseltux23@gmail.com>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<20060309232704.7b003dbf.wieseltux23@gmail.com>
Message-ID: <1141943761.20202.77.camel@ender>

On Thu, 2006-03-09 at 23:27 +0100, wieseltux23 wrote:
> www.wolfspakt.de/spiel.php?id=7358
> 

um, wtf?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060309/0056365a/attachment.sig>

From igorm5 at vip.hr  Thu Mar  9 22:36:49 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Thu, 09 Mar 2006 23:36:49 +0100
Subject: rawhide report: 20060307 changes
In-Reply-To: <440EDC67.9090005@redhat.com>
References: <200603070924.k279O6g3000845@porkchop.devel.redhat.com>	<1141797358.2294.2.camel@localhost.localdomain>	<440E968F.8010302@vip.hr>
	<440EDC67.9090005@redhat.com>
Message-ID: <4410AE01.2050305@vip.hr>

Christopher Aillon ka?e:

> Static IPs are supported, but there is no way to configure it with NM. 
> Configure it with system-config-network, and NM will pick up the static 
> IP fine.

It erases my /etc/resolv.conf, which is also static in my case. Shortly,
it doesn't work for me, but I'm glad to here that there are more
features to be implemented.

-- 
Igor Jagec



From pjones at redhat.com  Thu Mar  9 23:13:35 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 09 Mar 2006 18:13:35 -0500
Subject: FC5 Final Release
In-Reply-To: <440E9010.9070202@cornell.edu>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
	<440E7BF1.4070502@fedoraproject.org>  <440E9010.9070202@cornell.edu>
Message-ID: <1141946015.4313.19.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-08 at 03:04 -0500, Ivan Gyurdiev wrote:

> Then there's the minor inconvenience of gnome-netstatus being broken 
> with my atheros chip:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861

We don't ship an Atheros driver.
-- 
  Peter



From pjones at redhat.com  Thu Mar  9 23:15:24 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 09 Mar 2006 18:15:24 -0500
Subject: FC5 Final Release
In-Reply-To: <1141881977.5982.5.camel@stantonfinley.org>
References: <1141881977.5982.5.camel@stantonfinley.org>
Message-ID: <1141946124.4313.21.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-08 at 22:26 -0700, Stanton Finley wrote:

> And these:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182147

Almost certainly a BIOS bug in both cases.
-- 
  Peter



From pjones at redhat.com  Thu Mar  9 23:19:01 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 09 Mar 2006 18:19:01 -0500
Subject: FC5 Final Release
In-Reply-To: <1141886371.5982.10.camel@stantonfinley.org>
References: <1141881977.5982.5.camel@stantonfinley.org>
	<1141884867.20202.25.camel@ender>
	<1141886371.5982.10.camel@stantonfinley.org>
Message-ID: <1141946341.4313.26.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-08 at 23:39 -0700, Stanton Finley wrote:

> This then begs the question why do the FC2, FC3, and FC4 installation
> media boot and install on the same machine without incident? What's
> different about the FC5 installation image kernel and can it be fixed?

Because the behavior of the int13h hook in your BIOS's CD reading code
depends not only on the inputs that it's supposed to depend on, but also
on some other factor, be it previous calls or some incorrect dependence
on another register's value.

If you really want this to work, you're either going to have to debug
it, or get a machine to somebody who can.  I can't really just guess
what your BIOS is doing.

-- 
  Peter



From pjones at redhat.com  Thu Mar  9 23:23:42 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 09 Mar 2006 18:23:42 -0500
Subject: FC5 Final Release
In-Reply-To: <f67c87220603090201n21685793ja8557dd4d36d5813@mail.gmail.com>
References: <1141881977.5982.5.camel@stantonfinley.org>
	<1141884867.20202.25.camel@ender>
	<1141886371.5982.10.camel@stantonfinley.org>
	<440FD099.40802@fedoraproject.org>
	<f67c87220603090201n21685793ja8557dd4d36d5813@mail.gmail.com>
Message-ID: <1141946622.4313.32.camel@vroomfondel.internal.datastacks.com>

On Thu, 2006-03-09 at 11:01 +0100, Bela Pesics wrote:

> > >>These appear to be machine specific, and need a fix from the machine
> > >>provider.  Not sure if this is something we can fix in Fedora space.
> 
> 
> Why from the machine provider? How can you imagine that?
> If we can't fix it, at least I have to find a solution for my own poor
> laptop... :-)

The workaround for this problem seems to be to type:

/isolinux/vmlinuz initrd=/isolinux/initrd.img

at the prompt.

> > Changing syslinux late in the release cycle might create
> > problems like the infamous one in which FC4 wouldnt bootup on some Intel
> > chipsets, without feeding in garbage at the bootup prompt, which again
> > wasnt there in our labs

To be fair, we had that machine, and that was a totally legitimate bug,
not some weird hardware bizarreness.  We certainly don't test every CD
on every machine in the building, as nice as that would be, it's just
too time consuming.

But you're right, we're *not* pushing syslinux changes this late in the
release cycle.

> Is "vmlinuz initrd=initrd.img" considered to be a garbage in this case?
> If so, what is the way of making sure this is really an upstream bug?

Well, considering we don't actually *recompile* the syslinux code from
upstream, you can be fairly certain that any handling of this would need
to be addressed there.  At the same time, it's really quite likely that
this *is* a hardware problem.

-- 
  Peter



From ivg2 at cornell.edu  Thu Mar  9 23:31:56 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Thu, 09 Mar 2006 18:31:56 -0500
Subject: FC5 Final Release
In-Reply-To: <1141946015.4313.19.camel@vroomfondel.internal.datastacks.com>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>
	<440E9010.9070202@cornell.edu>
	<1141946015.4313.19.camel@vroomfondel.internal.datastacks.com>
Message-ID: <4410BAEC.5070504@cornell.edu>

Peter Jones wrote:
> On Wed, 2006-03-08 at 03:04 -0500, Ivan Gyurdiev wrote:
>
>   
>> Then there's the minor inconvenience of gnome-netstatus being broken 
>> with my atheros chip:
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861
>>     
>
> We don't ship an Atheros driver.
>   
Now *that* should be a blocker bug....

Note that the Atheros driver from madwifi worked fine, and previously 
the gnome-netstatus applet was also functional with it. It was broken 
during the FC testing cycle.



From ivg2 at cornell.edu  Thu Mar  9 23:52:49 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Thu, 09 Mar 2006 18:52:49 -0500
Subject: FC5 Final Release
In-Reply-To: <4410BAEC.5070504@cornell.edu>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>	<440E7BF1.4070502@fedoraproject.org>	<440E9010.9070202@cornell.edu>	<1141946015.4313.19.camel@vroomfondel.internal.datastacks.com>
	<4410BAEC.5070504@cornell.edu>
Message-ID: <4410BFD1.4070108@cornell.edu>

Ivan Gyurdiev wrote:
> Peter Jones wrote:
>> On Wed, 2006-03-08 at 03:04 -0500, Ivan Gyurdiev wrote:
>>
>>  
>>> Then there's the minor inconvenience of gnome-netstatus being broken 
>>> with my atheros chip:
>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406
>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861
>>>     
>>
>> We don't ship an Atheros driver.
>>   
> Now *that* should be a blocker bug....
>
> Note that the Atheros driver from madwifi worked fine, and previously 
> the gnome-netstatus applet was also functional with it. It was broken 
> during the FC testing cycle.
I'm not even online with this card anymore - unlike Nvidia's drivers I 
find madwifi rather unreliable. There's 3 NICs on this machine, and the 
applet is still broken. Removing the Atheros modules from the kernel 
does not help at all.



From tjb at unh.edu  Fri Mar 10 00:04:56 2006
From: tjb at unh.edu (Thomas J. Baker)
Date: Thu, 09 Mar 2006 19:04:56 -0500
Subject: other annoyances before fc5
In-Reply-To: <440FCEF9.2080807@fedoraproject.org>
References: <duci8r$9si$1@sea.gmane.org>
	<510b8bb53ffa46e75bdc6aa704213a28@mail.paradigma.pt>
	<440AA731.7020302@adslpipe.co.uk>
	<1141553990.6034.1.camel@rousalka.dyndns.org>
	<440AC0AD.8030300@fedoraproject.org>
	<1141556553.6034.5.camel@rousalka.dyndns.org>
	<440AC7E0.7040504@fedoraproject.org>
	<1141865113.2690.9.camel@continuity>
	<440FCEF9.2080807@fedoraproject.org>
Message-ID: <1141949097.14783.3.camel@continuity>

On Thu, 2006-03-09 at 12:15 +0530, Rahul Sundaram wrote:
> Thomas J. Baker wrote:
> 
> >
> >>I filed this back on Feb 23rd....
> >>
> >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182653
> >>
> >>    
> >>
> Thanks. Somehow missed it in my queries. Is this still reproducible for you?
> 
> -- 
> Rahul 
> 
> 
> 

Seems fixed just today...

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



From seg at haxxed.com  Fri Mar 10 04:02:35 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 09 Mar 2006 22:02:35 -0600
Subject: FC5 Final Release
In-Reply-To: <4410BAEC.5070504@cornell.edu>
References: <fc33c1550603072229yf976d93i4b87b16b3447f012@mail.gmail.com>
	<440E7BF1.4070502@fedoraproject.org> <440E9010.9070202@cornell.edu>
	<1141946015.4313.19.camel@vroomfondel.internal.datastacks.com>
	<4410BAEC.5070504@cornell.edu>
Message-ID: <1141963356.6368.5.camel@localhost>

On Thu, 2006-03-09 at 18:31 -0500, Ivan Gyurdiev wrote:
> Note that the Atheros driver from madwifi worked fine, and previously 
> the gnome-netstatus applet was also functional with it. It was broken 
> during the FC testing cycle.

Yeah, NetworkManager worked fine for some time on madwifi-ng and
madwifi-old, then it broke maybe a month ago. Just recently it seems to
have been (partly) fixed for madwifi-old, but still doesn't work at all
with madwifi-ng. It has a tendency to disconnect randomly for no
apparent reason, and I have to click on my network in the applet to
reconnect, hence the partly fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060309/264962eb/attachment.sig>

From arjan at fenrus.demon.nl  Fri Mar 10 07:45:11 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Fri, 10 Mar 2006 08:45:11 +0100
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1141877948.20202.23.camel@ender>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
Message-ID: <1141976712.2876.12.camel@laptopd505.fenrus.org>

On Wed, 2006-03-08 at 23:19 -0500, Jesse Keating wrote:
> On Wed, 2006-03-08 at 22:57 -0500, Philippe Rigault wrote:
> > If one wants to boot Fedora Core from a USB key (using diskboot.img from the 
> > images directory), it is currently only possible to run the installer, but 
> > not a rescue environment. 
> > 
> > It would be very helpful to be able to boot a rescue environment from an USB 
> > key.
> > 
> > Is that doable easily ? 
> 
> I'm reasonably certain that if you boot the diskboot.img with 'rescue'
> as a boot option, you'll get a rescue environment.  In fact, I just
> tested it and it does work. 

it only works if your USB device uses a partition table. The USB devices
that don't use a partition table do not work in this way.
At least that's my experience from last week trying to rescue my
firewall from a dead disk



From buildsys at redhat.com  Fri Mar 10 08:14:29 2006
From: buildsys at redhat.com (Build System)
Date: Fri, 10 Mar 2006 03:14:29 -0500
Subject: rawhide report: 20060310 changes
Message-ID: <200603100814.k2A8ETTT016596@porkchop.devel.redhat.com>

 

 
Updated Packages:

GFS-kernel-2.6.15.1-5.FC5.13
----------------------------

at-spi-1.7.6-2
--------------
* Thu Mar 09 2006 Matthias Clasen <mclasen at redhat.com> - 1.7.6-2
- Fix a crash on x86_64

binutils-2.16.91.0.6-4
----------------------
* Thu Mar 09 2006 Alexandre Oliva <aoliva at redhat.com> 2.16.91.0.6-4
- fix relaxation of TLS GD to LE on PPC (#184590)

cdrdao-1.2.1-1
--------------
* Wed Mar 08 2006 Harald Hoyer <harald at redhat.com> - 1.2.1-1
- version 1.2.1 (1.2.0 was not functional)

cman-kernel-2.6.15.1-0.FC5.11
-----------------------------

dlm-kernel-2.6.15.1-0.FC5.9
---------------------------

doxygen-1:1.4.6-3
-----------------
* Wed Mar 08 2006 Than Ngo <than at redhat.com> 1:1.4.6-3
- fix typo bug #184400

emacs-21.4-14
-------------
* Tue Mar 07 2006 Jens Petersen <petersen at redhat.com> - 21.4-14
- bring back setarch for i386 with -R option in spec file and drop
  emacs-21-personality-linux32-101818.patch since it no longer seems
  sufficient with recent kernels (Sam Peterson, #174736)
- buildrequire giflib-devel instead of libungif-devel

* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com>
- avoid backup for fix-x-vs-no-x-diffs.dpatch (Ian Collier, #183503)
- remove the old ccmode info manual (#182084)

gcc-4.1.0-3
-----------
* Thu Mar 09 2006 Alexandre Oliva <aoliva at redhat.com> 4.1.0-3
- make ppc32 TLS PIC code sequences compatible with secure plt (#184446)
  (Richard Henderson and myself)

gnbd-kernel-2.6.15-5.FC5.14
---------------------------

gnome-applets-1:2.13.90-8
-------------------------
* Thu Mar 09 2006 Ray Strode <rstrode at redhat.com> - 2.13.90-8
- s/divemount/drivemount/

* Thu Mar 09 2006 Ray Strode <rstrode at redhat.com> - 2.13.90-7
- remove some bad trailing spaces introduced in 2.13.90-6

gnome-session-2.13.92-5
-----------------------
* Thu Mar 09 2006 Ray Strode <rstrode at redhat.com> - 2.13.92-5
- fix up path creation functions

* Thu Mar 09 2006 Ray Strode <rstrode at redhat.com> - 2.13.92-4
- create ~/.config/autostart before trying to migrate
  session-manual to it (bug 179602).

grub-0.97-4
-----------
* Thu Mar 09 2006 Peter Jones <pjones at redhat.com> - 0.97-4
- Fix running "install" multiple times on the same fs in the same invocation
  of grub.  (bz #158426 , patch from lxo at redhat.com)

kernel-2.6.15-1.2038_FC5
------------------------
* Thu Mar 09 2006 Stephen Tweedie <sct at redhat.com>
- Disable a bunch of hardware drivers in xenU that have no business
  being built in an unprivileged guest.
- Fix conflict between Xen and ati patch from latest git tree

* Thu Mar 09 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc5-git12/git13
- Make 'quiet' work again.
- Turn off some debugging stuff.
- Fix up some debug spew that could occur during resume.

* Wed Mar 08 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc5-git10/git11

kudzu-1.2.34.2-1
----------------
* Thu Mar 09 2006 Bill Nottingham <notting at redhat.com> - 1.2.34.2-1
- special-case xen to not use vm86 (works around #179013)

* Tue Mar 07 2006 Bill Nottingham <notting at redhat.com> - 1.2.34.1-1
- switch at runtime between vm86 and x86emu on i386. Fixes vbe/ddc on
  Xen and i386-on-x86_64

* Mon Mar 06 2006 Bill Nottingham <notting at redhat.com> - 1.2.34-1
- silence some error messages

lftp-3.4.2-5
------------
* Fri Mar 10 2006 Bill Nottingham <notting at redhat.com> - 3.4.2-5
- rebuild for ppc TLS issue (#184446)

libstdc++so7-4.2.0-0.3.20060203.2
---------------------------------
* Fri Mar 10 2006 Bill Nottingham <notting at redhat.com> - 4.2.0-0.3.20060203.2
- rebuild for ppc TLS issue (#184446)

libwvstreams-4.2.1-2
--------------------
* Fri Mar 10 2006 Bill Nottingham <notting at redhat.com> - 4.2.1-2
- rebuild for ppc TLS issue (#184446)

libxklavier-2.1.0.2006.02.23-2
------------------------------
* Thu Mar 09 2006 Ray Strode <rstrode at redhat.com> - 2.1.0.2006.02.23-2
- trap X error reply to limit the damage of bug 183569.

* Thu Feb 23 2006 Ray Strode <rstrode at redhat.com> - 2.1.0.2006.02.23-1
- upgrade to latest cvs to handle xml comments (bug 178163)

mono-1.1.13.4-2
---------------
* Fri Mar 10 2006 Bill Nottingham <notting at redhat.com> - 1.1.13.4-2
- rebuild for ppc TLS issue (#184446)

numactl-0.6.4-1.27
------------------
* Fri Mar 10 2006 Bill Nottingham <notting at redhat.com>
- rebuild for ppc TLS issue (#184446)

selinux-policy-2.2.23-15
------------------------
* Thu Mar 09 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-15
- Get rid of mount/fsdisk scan of /dev messages
- Additional fixes for suspend/resume

* Thu Mar 09 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-14
- Fake make to rebuild enableaudit.pp

* Thu Mar 09 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-13
- Get xen networking running.

switchdesk-4.0.8-4
------------------
* Thu Mar 09 2006 Than Ngo <than at redhat.com> 4.0.8-4
- fix deprecated functions in gtk

system-config-display-1.0.37-2
------------------------------
* Thu Mar 09 2006 Chris Lumens <clumens at redhat.com> 1.0.37-2
- Add back spec file parts that got lost on last rebuild.

util-linux-2.13-0.20
--------------------
* Thu Mar 09 2006 Jesse Keating <jkeating at redhat.com> 2.13-0.20
- Better calling of restorecon as suggested by Bill Nottingham
- prereq restorecon to avoid ordering issues

* Thu Mar 09 2006 Jesse Keating <jkeating at redhat.com> 2.13-0.19
- restorecon /var/log/lastlog

vim-1:6.4.007-4
---------------
* Thu Mar 09 2006 Karsten Hopp <karsten at redhat.de> 6.4.007-4
- fix configure check for python (#184478)

* Thu Mar 09 2006 Karsten Hopp <karsten at redhat.de> 6.4.007-3
- rebuild

Broken deps for i386
----------------------------------------------------------
	gnbd-kernel - 2.6.15-5.FC5.14.i686 requires kernel = 0:2.6.15-1.2032_FC5
	gnbd-kernel - 2.6.15-5.FC5.14.i686 requires /lib/modules/2.6.15-1.2032_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.14.i686 requires /lib/modules/2.6.15-1.2032_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2032_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel - 2.6.15-5.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2032_FC5
	gnbd-kernel - 2.6.15-5.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2032_FC5





From Axel.Thimm at ATrpms.net  Fri Mar 10 08:44:13 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 10 Mar 2006 09:44:13 +0100
Subject: kernel versioning
Message-ID: <20060310084413.GE1803@neu.nirvana>

Hi,

upstream kernels that are release candidates or git sub-rcs etc. are
versioned in FC/RHEL based on the previous stable kernel release,
e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15.

I generally think that's a good idea (e.g. it *is* 2.6.15 with patches
towards 2.6.16 and not yet 2.6.16, and the user is not confused that
he's already running 2.6.16).

But tons of kernel module projects check on the version of the kernel
and trigger different code bits. These projects depend on the
versioning to decide whether some features exist or not.

This results to funny external Fedora-patches to these projects that
only last a kernel release and are troublesome to maintain. The
typical user has to hunt down these issues, upstream needs a Fedora
system or someone willing to do the check on his system, and the
package maintainer needs to revise his packages upon any kernel
release.

So there is a wish to keep the versioning in the top level Makefile as
vanilla ships it. That way the checks will be more accurate and
users/upstream/packagers will have less to worry about, less
Fedora-only patching and so on.

The downside of this is that uname -r will give a different kernel
version than rpm's version, e.g. 2.6.16-xxx vs 2.6.15-yyy. If the
rpm's version is adapted to the kernel's then we have the issues on
epoching (which is solvable in ugly way) and that of the user's
thinking they already run 2.6.16 which they don't yet (at least not
the released version).

Any thoughts on how to make everyone happy? :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/b734d540/attachment.sig>

From emeric.maschino at jouy.inra.fr  Fri Mar 10 09:07:43 2006
From: emeric.maschino at jouy.inra.fr (Emeric Maschino)
Date: Fri, 10 Mar 2006 10:07:43 +0100
Subject: 2GB swap partition limit?
In-Reply-To: <1141938598.4313.12.camel@vroomfondel.internal.datastacks.com>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<1141938598.4313.12.camel@vroomfondel.internal.datastacks.com>
Message-ID: <1141981664.5103.6.camel@localhost.localdomain>

Hello,

I'm pretty sure that anaconda displayed 4GB for the swap when it created
the partitions. But it seems it was only a graphical artifact, since
cat /proc/swaps, cat /proc/meminfo and lvdisplay all report a 2GB swap
space, as well as top, free and the gnome-system-monitor. Thus, if
anaconda doesn't create swap partition bigger than 2GB, everything seems
to be fine.

	?meric


Le jeudi 09 mars 2006 ? 16:09 -0500, Peter Jones a ?crit :
> On Sun, 2006-03-05 at 13:24 +0100, ?meric Maschino wrote:
> 
> > My workstation has been upgraded to 6GB RAM. I let anaconda automatically manage
> > the partitions on the disk. It created a 4GB swap partition in a LVM volume.
> > But top, free and gnome-system-monitor all report that my swap space is 2GB
> > (more precisely, 1.9GB). IIRC, there was a 2GB limit partition for the swap
> > size in the past, but I thought this has been overcame.
> 
> Hrm, that's a bit odd.  Anaconda by default won't create a swap device
> larger than 2GB unless you specifically set the size higher.  You're
> sure it's a 4GB LV it's on?
> 
> Can we see lvdisplay's output?
> 
> Also, what does /proc/swaps say?
> 
> -- 
>   Peter
> 



From arjan at fenrus.demon.nl  Fri Mar 10 10:12:42 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Fri, 10 Mar 2006 11:12:42 +0100
Subject: kernel versioning
In-Reply-To: <20060310084413.GE1803@neu.nirvana>
References: <20060310084413.GE1803@neu.nirvana>
Message-ID: <1141985562.2876.40.camel@laptopd505.fenrus.org>

On Fri, 2006-03-10 at 09:44 +0100, Axel Thimm wrote:
> Hi,
> 
> upstream kernels that are release candidates or git sub-rcs etc. are
> versioned in FC/RHEL based on the previous stable kernel release,
> e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15.
> 
> I generally think that's a good idea (e.g. it *is* 2.6.15 with patches
> towards 2.6.16 and not yet 2.6.16, and the user is not confused that
> he's already running 2.6.16).
> 
> But tons of kernel module projects check on the version of the kernel
> and trigger different code bits. These projects depend on the
> versioning to decide whether some features exist or not.


there is no good solution ;(
because even if it said 2.6.16... that's not enough. the api is still
changing and you'd get patches like "fedora claims 2.6.16 but it's not,
so now we need to back down one level".

So your proposal would trade the issue from one side, for an issue from
the other side. Depending on where in the release cycle the exact cut
is, either can be worse (eg the earlier the cut the more accurate 2.6.15
would be, the later the cut the more accurate 2.6.16)

So all in all... I think this is just an evil that external modules need
to live with as price for being external; it's effectively just the same
price they pay for the non-stable kernel API in general.



From Axel.Thimm at ATrpms.net  Fri Mar 10 10:23:46 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 10 Mar 2006 11:23:46 +0100
Subject: kernel versioning
In-Reply-To: <1141985562.2876.40.camel@laptopd505.fenrus.org>
References: <20060310084413.GE1803@neu.nirvana>
	<1141985562.2876.40.camel@laptopd505.fenrus.org>
Message-ID: <20060310102346.GF1803@neu.nirvana>

On Fri, Mar 10, 2006 at 11:12:42AM +0100, Arjan van de Ven wrote:
> On Fri, 2006-03-10 at 09:44 +0100, Axel Thimm wrote:
> > Hi,
> > 
> > upstream kernels that are release candidates or git sub-rcs etc. are
> > versioned in FC/RHEL based on the previous stable kernel release,
> > e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15.
> > 
> > I generally think that's a good idea (e.g. it *is* 2.6.15 with patches
> > towards 2.6.16 and not yet 2.6.16, and the user is not confused that
> > he's already running 2.6.16).
> > 
> > But tons of kernel module projects check on the version of the kernel
> > and trigger different code bits. These projects depend on the
> > versioning to decide whether some features exist or not.
> 
> 
> there is no good solution ;(
> because even if it said 2.6.16... that's not enough. the api is still
> changing and you'd get patches like "fedora claims 2.6.16 but it's not,
> so now we need to back down one level".

But in practice most external kernel module projects will work, and if
it should break it breaks exactly like against upstream kernel
sources, so Fedora isn't the guilty part of this chain. You can toss
the ball back to the kernel project.

> So your proposal would trade the issue from one side, for an issue from
> the other side.

Well, for one I'm not making any proposal, I'm just presenting this
issue for discussion. But I do think that not changing the SUBLEVEL
would be better. It's upstream after all, and modern Fedora Core has
upstream written all over it.

> Depending on where in the release cycle the exact cut is, either can
> be worse (eg the earlier the cut the more accurate 2.6.15 would be,
> the later the cut the more accurate 2.6.16)
> 
> So all in all... I think this is just an evil that external modules need
> to live with as price for being external; it's effectively just the same
> price they pay for the non-stable kernel API in general.

From a marketing POV, a Fedora user tries to build kernel project
foo. He fails against the Fedora kernel and upstream advises to try
vanilla or some other distribution. He succeeds and the Fedora kernel
get's the blaim. That happens all the time.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/e85c9b8b/attachment.sig>

From Lam at Lam.pl  Fri Mar 10 11:45:06 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Fri, 10 Mar 2006 12:45:06 +0100
Subject: kernel versioning
In-Reply-To: <20060310084413.GE1803@neu.nirvana>
References: <20060310084413.GE1803@neu.nirvana>
Message-ID: <1141991106.5272.52.camel@pensja.lam.pl>

Dnia 10-03-2006, pi? o godzinie 09:44 +0100, Axel Thimm napisa?(a):
> But tons of kernel module projects check on the version of the kernel
> and trigger different code bits. These projects depend on the
> versioning to decide whether some features exist or not.
2.6.17-pre1 will have SUBLEVEL=17 and EXTRAVERSION=-pre1. It will have
LINUX_VERSION_CODE equal to KERNEL_VERION( 2, 6, 17 ). It won't have
most of the changes to come in "real" 2.6.17. Does every module maker
check for EXTRAVERSION in /lib/modules/`uname -r`/build/Makefile,
extracts "pre" or "rc" part in case there are some other suffixes (like
-git7-mm3-ac4) and knows that rc1 > pre100? My guess is no.

There are more problems if you consider the fact that any (vendor/user)
patched kernel may have an API change that won't make it into the next
(or any) official Linux version or it may have some official-kernel
change removed.

API/ABI/whatever changes should be marked using some specific #defines
which can be checked instead of depending on a non meaningful version
number. There are CONFIG_ defines that can break modules, but they can
be detected and made to work (for example, NVIDIA proprietary driver
recently learned to work with CONFIG_4KSTACKS). If some change
_requires_ testing for kernel version (which doesn't mean that much,
really), it's just wrong. It forces the module maker to trace every
change in the kernel and make code fragments compiled conditional under
different kernel version _ranges_ (and he has to continually check if
current range isn't about to end) instead of just depending on something
defined globally, upstream and changed when API changes occur.

Besides... who cares? USER shouldn't have to worry about compiling
kernel modules, he/she expects to get it with their system. Programmers
and rpm builders can deal with problem themselves so that I get working
module (in our case, from FC or FE). If a patch is required, it becomes
unnecessary upon next Fedora major kernel upgrade (if you're right).
Proprietary module vendors have their own programming forces that can
and should fix things if they're paid for it. Fedora is "big" enough
distro to afford changing the kernel (with good intentions :)) and
expecting others comply if they're not kind enough to give out sources.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/9254db49/attachment.sig>

From katzj at redhat.com  Fri Mar 10 15:53:52 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 10 Mar 2006 10:53:52 -0500
Subject: Fedora Core 5 Status
Message-ID: <1142006032.29247.10.camel@orodruin.boston.redhat.com>

Due to circumstances outside of our control, we're going to be unable to
keep to the scheduled date of March 15th for the release of FC5 and
instead are going to have to make the release date Monday, March 20th.
While unfortunate in some ways, this gives us the opportunity to pull in
the final GNOME 2.14 tarballs which should be available on Monday
assuming the changes are suitably minor.  

Jeremy



From jkeating at j2solutions.net  Fri Mar 10 16:11:41 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 10 Mar 2006 11:11:41 -0500
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1141976712.2876.12.camel@laptopd505.fenrus.org>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
Message-ID: <1142007102.2505.14.camel@ender>

On Fri, 2006-03-10 at 08:45 +0100, Arjan van de Ven wrote:
> it only works if your USB device uses a partition table. The USB devices
> that don't use a partition table do not work in this way.
> At least that's my experience from last week trying to rescue my
> firewall from a dead disk 

Hrm, how else would you use the diskboot.img?  I always just backup the
contents of my usb key, then dd if=diskboot.img of=/dev/sdX  where X is
my usb fob.  Works for me every time...

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/df46cc46/attachment.sig>

From jwboyer at jdub.homelinux.org  Fri Mar 10 15:12:25 2006
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Fri, 10 Mar 2006 09:12:25 -0600 (CST)
Subject: Fedora Core 5 Status
In-Reply-To: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
References: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
Message-ID: <45452.129.42.161.36.1142003545.squirrel@jdub.homelinux.org>

> Due to circumstances outside of our control, we're going to be unable to
> keep to the scheduled date of March 15th for the release of FC5 and
> instead are going to have to make the release date Monday, March 20th.
> While unfortunate in some ways, this gives us the opportunity to pull in
> the final GNOME 2.14 tarballs which should be available on Monday
> assuming the changes are suitably minor.

Before people start to bitch and moan about this, I'd like to take a
second and just thank the Core developers.  Your hard work is appreciated.
 Slips suck, but it's better to delay a release to fix the remaining
issues than to just stick to a schedule.

josh



From andy at warmcat.com  Fri Mar 10 16:28:04 2006
From: andy at warmcat.com (Andy Green)
Date: Fri, 10 Mar 2006 16:28:04 +0000
Subject: Fedora Core 5 Status
In-Reply-To: <45452.129.42.161.36.1142003545.squirrel@jdub.homelinux.org>
References: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
	<45452.129.42.161.36.1142003545.squirrel@jdub.homelinux.org>
Message-ID: <4411A914.3030401@warmcat.com>

Josh Boyer wrote:

>> Due to circumstances outside of our control, we're going to be unable to
>> keep to the scheduled date of March 15th for the release of FC5 and

> Before people start to bitch and moan about this, I'd like to take a

Let's hope the installer folks use the extra 5 days to fix up a way to
give each parent in the install hierarchy a way to check and uncheck all
children, allowing simple an intuitive emulation of the 'minimal' and
'everything' metaselections.  Because this seems to be a major issue -
with a simple fix - over in userworld.

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

From arjan at fenrus.demon.nl  Fri Mar 10 16:31:00 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Fri, 10 Mar 2006 17:31:00 +0100
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142007102.2505.14.camel@ender>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
Message-ID: <1142008260.2876.68.camel@laptopd505.fenrus.org>

On Fri, 2006-03-10 at 11:11 -0500, Jesse Keating wrote:
> On Fri, 2006-03-10 at 08:45 +0100, Arjan van de Ven wrote:
> > it only works if your USB device uses a partition table. The USB devices
> > that don't use a partition table do not work in this way.
> > At least that's my experience from last week trying to rescue my
> > firewall from a dead disk 
> 
> Hrm, how else would you use the diskboot.img?  I always just backup the
> contents of my usb key, then dd if=diskboot.img of=/dev/sdX  where X is
> my usb fob.  Works for me every time...

you can do better ;)

copy vmlinuz/initrd.img from the rescue image
syslinux that to the disk, with proper syslinux.cfg
then cp the rest of the iso to the usb stick as well
and .. voila. Ought to work.. except for the case where anaconda can't
deal with usb sticks without partition table



From jkeating at j2solutions.net  Fri Mar 10 16:37:30 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 10 Mar 2006 11:37:30 -0500
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142008260.2876.68.camel@laptopd505.fenrus.org>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
	<1142008260.2876.68.camel@laptopd505.fenrus.org>
Message-ID: <1142008650.2505.25.camel@ender>

On Fri, 2006-03-10 at 17:31 +0100, Arjan van de Ven wrote:
> 
> you can do better ;)
> 
> copy vmlinuz/initrd.img from the rescue image
> syslinux that to the disk, with proper syslinux.cfg
> then cp the rest of the iso to the usb stick as well
> and .. voila. Ought to work.. except for the case where anaconda can't
> deal with usb sticks without partition table 

Suppose that works.  It's almost as much work to do that than to
backup / restore the existing content.  I think we'd accept patches to
anaconda to handle this usage case.. (:

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/4931129c/attachment.sig>

From paul at cypherpunks.ca  Fri Mar 10 16:58:44 2006
From: paul at cypherpunks.ca (Paul Wouters)
Date: Fri, 10 Mar 2006 17:58:44 +0100 (CET)
Subject: =?iso-8859-1?q?=C2Re=3A_kernel_versioning?=
In-Reply-To: <20060310084413.GE1803@neu.nirvana>
References: <20060310084413.GE1803@neu.nirvana>
Message-ID: <Pine.LNX.4.63.0603101756050.28470@tla.xelerance.com>

On Fri, 10 Mar 2006, Axel Thimm wrote:

> upstream kernels that are release candidates or git sub-rcs etc. are
> versioned in FC/RHEL based on the previous stable kernel release,
> e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15.
>
> I generally think that's a good idea (e.g. it *is* 2.6.15 with patches
> towards 2.6.16 and not yet 2.6.16, and the user is not confused that
> he's already running 2.6.16).
>
> But tons of kernel module projects check on the version of the kernel
> and trigger different code bits. These projects depend on the
> versioning to decide whether some features exist or not.
>
> This results to funny external Fedora-patches to these projects that
> only last a kernel release and are troublesome to maintain.

Yes, this is a nightmare for openswan's KLIPS module.

> So there is a wish to keep the versioning in the top level Makefile as
> vanilla ships it. That way the checks will be more accurate and
> users/upstream/packagers will have less to worry about, less
> Fedora-only patching and so on.

That is going to be confusing too.

> Any thoughts on how to make everyone happy? :)

I have no idea :(

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155



From kwade at redhat.com  Fri Mar 10 17:08:56 2006
From: kwade at redhat.com (Karsten Wade)
Date: Fri, 10 Mar 2006 09:08:56 -0800
Subject: [WIKI SNAP] FC 5 latest release notes >23:59 UTC today
In-Reply-To: <1141930913.3391.153.camel@erato.phig.org>
References: <1141930913.3391.153.camel@erato.phig.org>
Message-ID: <1142010536.9552.83.camel@erato.phig.org>

On Thu, 2006-03-09 at 11:01 -0800, Karsten Wade wrote:
> http://fedoraproject.org/wiki/Docs/Beats
> 
> Later today ... or tonight ... depending on flurries of activity from
> ya'll, we are going to freeze the release notes beats for an edit pass
> prior to putting out another round of XML.

Considering that the FC5 launch is postponed until 20 March, we are
going to unfreeze the Docs/Beats pages in the Wiki until this coming
Monday or Tuesday.  We shall then do a final edit through and conversion
to XML for the Web launch.

- Karsten
100% carefully triple-posted content!
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
Content Services                          Fedora Documentation Project
http://www.redhat.com/docs   http://fedoraproject.org/wiki/DocsProject
-------------- 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/20060310/238816b7/attachment.sig>

From prigault at oricom.ca  Fri Mar 10 17:20:33 2006
From: prigault at oricom.ca (Philippe Rigault)
Date: Fri, 10 Mar 2006 12:20:33 -0500
Subject: Fedora Core 5 Status
Message-ID: <200603101220.33585.prigault@oricom.ca>

> Due to circumstances outside of our control, we're going to be unable to
> keep to the scheduled date of March 15th for the release of FC5 and
> instead are going to have to make the release date Monday, March 20th.
> While unfortunate in some ways, this gives us the opportunity to pull in
> the final GNOME 2.14 tarballs which should be available on Monday
> assuming the changes are suitably minor.  
> 
> Jeremy

I have two problems with this:

The first is that FC5 will be released essentially _untested_ after two of its 
main components were upgraded to a stable release after FC5test3:
 - gcc 4.1.0
 - glibc-2.4

It could be argued that FC5 will be _released_ with a stable release of its 
compiler and C library, but not that this had been tested.

The second goes the same way, arguing that if test3 is the latest test 
release, any new major component should _not_ be upgraded to a new release, 
which is particularly true for a big beast like GNOME.

Here are comments from Jesse and Alan made after I raised the very point of 
GNOME 2.14:
> On Sat, 2006-02-04 at 11:57 -0500, Philippe Rigault wrote:
> > 
> > I also very much hope that this will be an opportunity for re-assessing 
the 
> > relevance of March 15 as the release date for FC5-final, which I see a the 
> > worst possible choice in March, given the following release dates:
> > March 15        GNOME-2.14, koffice-1.5
> > March 17        KDE-3.5.2
> > 
>On  Sat, 04 Feb 2006 10:15:54 -0800, Jesse Keating wrote:
> Unfortunately large changes such as the ones above would generally
> require another test release before making it final.  We're trying to
> get all our major changes in before test3 so that the time between test3
> and final is spent fixing all the BUGS found in test3 rather than
> introducing more new software  and more new bugs.
>
>-- 
>Jesse Keating RHCE      (geek.j2solutions.net)
>Fedora Legacy Team      (www.fedoralegacy.org)
>GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
>
>On Mon, 6 Feb 2006 10:37:30 -0500, Alan Cox wrote:
>It would need to be a large delay because moving to major new versions means
>invalidating a lot of the testing work in T1/T2. If sliding test2 a bit to 
fit
>these would have worked then maybe there would be a practical way to do it, 
but
>test3 > final is about polishing critical final bugs.
>
>Alan

In conclusion, I think that:
 1. There should be a new test release, so that gcc/glibc are tested before 
FC5 final
 2. Since GNOME 2.14 may happen before this test release, it could be 
included.

Cheers,

Philippe



From katzj at redhat.com  Fri Mar 10 17:25:49 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 10 Mar 2006 12:25:49 -0500
Subject: Fedora Core 5 Status
In-Reply-To: <200603101220.33585.prigault@oricom.ca>
References: <200603101220.33585.prigault@oricom.ca>
Message-ID: <1142011549.3073.8.camel@aglarond.local>

On Fri, 2006-03-10 at 12:20 -0500, Philippe Rigault wrote:
> I have two problems with this:
> 
> The first is that FC5 will be released essentially _untested_ after two of its 
> main components were upgraded to a stable release after FC5test3:
>  - gcc 4.1.0
>  - glibc-2.4
> 
> It could be argued that FC5 will be _released_ with a stable release of its 
> compiler and C library, but not that this had been tested.

The changes between what we shipped in test3 and what we're going to be
shipping are extremely small.  And we _always_ have to fix bugs in
things between test3 and the final release, sometimes larger ones than
the diff present there.

> The second goes the same way, arguing that if test3 is the latest test 
> release, any new major component should _not_ be upgraded to a new release, 
> which is particularly true for a big beast like GNOME.

Again, the changes going in at this point are all small targeted bug
fixes as they wind down their release cycle.  

Trust me, we're looking at diffs of everything that's going in at this
point and if some component of GNOME goes off and rewrites a huge chunk
of how it works, we're not going to pull it in.

Jeremy



From arjan at fenrus.demon.nl  Fri Mar 10 17:25:42 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Fri, 10 Mar 2006 18:25:42 +0100
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142008650.2505.25.camel@ender>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
	<1142008260.2876.68.camel@laptopd505.fenrus.org>
	<1142008650.2505.25.camel@ender>
Message-ID: <1142011542.2876.79.camel@laptopd505.fenrus.org>

On Fri, 2006-03-10 at 11:37 -0500, Jesse Keating wrote:
> On Fri, 2006-03-10 at 17:31 +0100, Arjan van de Ven wrote:
> > 
> > you can do better ;)
> > 
> > copy vmlinuz/initrd.img from the rescue image
> > syslinux that to the disk, with proper syslinux.cfg
> > then cp the rest of the iso to the usb stick as well
> > and .. voila. Ought to work.. except for the case where anaconda can't
> > deal with usb sticks without partition table 
> 
> Suppose that works.  It's almost as much work to do that than to
> backup / restore the existing content.  I think we'd accept patches to
> anaconda to handle this usage case.. (:

as I said it already works.
Except that anaconda as whole didn't think usb sticks come in 2
varieties: partitioned and unpartitioned. It assumed only partitioned.
(fwiw gnome's HAL has the same defect)



From katzj at redhat.com  Fri Mar 10 17:29:48 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 10 Mar 2006 12:29:48 -0500
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142011542.2876.79.camel@laptopd505.fenrus.org>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
	<1142008260.2876.68.camel@laptopd505.fenrus.org>
	<1142008650.2505.25.camel@ender>
	<1142011542.2876.79.camel@laptopd505.fenrus.org>
Message-ID: <1142011788.3073.13.camel@aglarond.local>

On Fri, 2006-03-10 at 18:25 +0100, Arjan van de Ven wrote:
> as I said it already works.
> Except that anaconda as whole didn't think usb sticks come in 2
> varieties: partitioned and unpartitioned. It assumed only partitioned.

Which part of anaconda?  I know I wrote code at least once to handle
both cases.

Jeremy



From thacker at math.cornell.edu  Fri Mar 10 17:39:43 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Fri, 10 Mar 2006 12:39:43 -0500
Subject: System clock speedup with latest kernels
Message-ID: <20060310173943.GA3470@localhost.localdomain>


Anyone else seeing this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184593 ?

With the last two kernels, 2.6.15-1.2032_FC5 and 2.6.15-1.2038_FC5,
the system clock starts running too fast for me.  It gains about an
hour per day.  It runs so fast that NTP won't sync to any clock
servers because the jitter grows far too fast.  Rebooting to 
kernel-2.6.15-1.2009.4.2_FC5 works perfectly.  I can switch back and 
forth between the working kernel-2.6.15-1.2009.4.2_FC5 and the two 
broken kernels, and the behavior shifts between working and running 
too fast each time.  (The hardware clock runs perfectly fine too.)

Anyone else seeing it?  Any more information that would be useful?
I assume this is related to the "timer fixes" from git9 mentioned
in the 2028 update, although frankly I don't know enough to be sure.
Obviously, this is a blocker for me personally, but I haven't seen
any other complaints.

John Thacker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/453079db/attachment.sig>

From seg at haxxed.com  Fri Mar 10 17:51:26 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 10 Mar 2006 11:51:26 -0600
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142011542.2876.79.camel@laptopd505.fenrus.org>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
	<1142008260.2876.68.camel@laptopd505.fenrus.org>
	<1142008650.2505.25.camel@ender>
	<1142011542.2876.79.camel@laptopd505.fenrus.org>
Message-ID: <1142013087.2640.0.camel@localhost>

On Fri, 2006-03-10 at 18:25 +0100, Arjan van de Ven wrote:
> as I said it already works.
> Except that anaconda as whole didn't think usb sticks come in 2
> varieties: partitioned and unpartitioned. It assumed only partitioned.
> (fwiw gnome's HAL has the same defect)

Isn't this a property of whoever formatted the stick, rather than the
stick itself?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/278898ba/attachment.sig>

From fedora at camperquake.de  Fri Mar 10 17:49:10 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 10 Mar 2006 18:49:10 +0100
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142013087.2640.0.camel@localhost>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
	<1142008260.2876.68.camel@laptopd505.fenrus.org>
	<1142008650.2505.25.camel@ender>
	<1142011542.2876.79.camel@laptopd505.fenrus.org>
	<1142013087.2640.0.camel@localhost>
Message-ID: <20060310184910.5fae082a@soran.addix.net>

Hi.

On Fri, 10 Mar 2006 11:51:26 -0600, Callum Lerwick wrote:

> Isn't this a property of whoever formatted the stick, rather than the
> stick itself?

I have a (rather oldish) stick which can not be partitoned (the hardware
prevents it).

But it also has a sector size of 2048 bytes, so it is a little on the
unusual side.



From stanfinley at comcast.net  Fri Mar 10 17:53:00 2006
From: stanfinley at comcast.net (Stanton Finley)
Date: Fri, 10 Mar 2006 10:53:00 -0700
Subject: System clock speedup with latest kernels
In-Reply-To: <20060310173943.GA3470@localhost.localdomain>
References: <20060310173943.GA3470@localhost.localdomain>
Message-ID: <1142013181.3102.2.camel@stantonfinley.org>

On Fri, 2006-03-10 at 12:39 -0500, John Thacker wrote:
> Anyone else seeing this:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184593 ?
> 
> With the last two kernels, 2.6.15-1.2032_FC5 and 2.6.15-1.2038_FC5,
> the system clock starts running too fast for me.  It gains about an
> hour per day.  It runs so fast that NTP won't sync to any clock
> servers because the jitter grows far too fast.  Rebooting to 
> kernel-2.6.15-1.2009.4.2_FC5 works perfectly.  I can switch back and 
> forth between the working kernel-2.6.15-1.2009.4.2_FC5 and the two 
> broken kernels, and the behavior shifts between working and running 
> too fast each time.  (The hardware clock runs perfectly fine too.)
> 
> Anyone else seeing it?  Any more information that would be useful?
> I assume this is related to the "timer fixes" from git9 mentioned
> in the 2028 update, although frankly I don't know enough to be sure.
> Obviously, this is a blocker for me personally, but I haven't seen
> any other complaints.
> 
> John Thacker
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

I have the same issue. Try adding "noapic nolapic" to the end of the
"kernel" line in /boot/grub/grub.conf.

Stanton Finley
http://stanton-finley.net/



From arjan at fenrus.demon.nl  Fri Mar 10 18:01:48 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Fri, 10 Mar 2006 19:01:48 +0100
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142011788.3073.13.camel@aglarond.local>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
	<1142008260.2876.68.camel@laptopd505.fenrus.org>
	<1142008650.2505.25.camel@ender>
	<1142011542.2876.79.camel@laptopd505.fenrus.org>
	<1142011788.3073.13.camel@aglarond.local>
Message-ID: <1142013708.2876.91.camel@laptopd505.fenrus.org>

On Fri, 2006-03-10 at 12:29 -0500, Jeremy Katz wrote:
> On Fri, 2006-03-10 at 18:25 +0100, Arjan van de Ven wrote:
> > as I said it already works.
> > Except that anaconda as whole didn't think usb sticks come in 2
> > varieties: partitioned and unpartitioned. It assumed only partitioned.
> 
> Which part of anaconda?  I know I wrote code at least once to handle
> both cases.


the part that tries to find stage2.img; it refuses to look at the usb
stick if there's no partition table. (disclaimer: this was with the
fc5test3 images, it can be that you fixed it since)



From seg at haxxed.com  Fri Mar 10 18:45:37 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 10 Mar 2006 12:45:37 -0600
Subject: System clock speedup with latest kernels
In-Reply-To: <1142013181.3102.2.camel@stantonfinley.org>
References: <20060310173943.GA3470@localhost.localdomain>
	<1142013181.3102.2.camel@stantonfinley.org>
Message-ID: <1142016337.2640.4.camel@localhost>

On Fri, 2006-03-10 at 10:53 -0700, Stanton Finley wrote:
> I have the same issue. Try adding "noapic nolapic" to the end of the
> "kernel" line in /boot/grub/grub.conf.

For what its worth, I'm not seeing this with 2032 on my PIII laptop.
(which doesn't have an apic/lapic)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/453f12f1/attachment.sig>

From j.w.r.degoede at hhs.nl  Fri Mar 10 18:48:58 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 10 Mar 2006 19:48:58 +0100
Subject: System clock speedup with latest kernels
In-Reply-To: <20060310173943.GA3470@localhost.localdomain>
References: <20060310173943.GA3470@localhost.localdomain>
Message-ID: <4411CA1A.10700@hhs.nl>



John Thacker wrote:
> Anyone else seeing this:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184593 ?
> 
> With the last two kernels, 2.6.15-1.2032_FC5 and 2.6.15-1.2038_FC5,
> the system clock starts running too fast for me.  It gains about an
> hour per day.  It runs so fast that NTP won't sync to any clock
> servers because the jitter grows far too fast.  Rebooting to 
> kernel-2.6.15-1.2009.4.2_FC5 works perfectly.  I can switch back and 
> forth between the working kernel-2.6.15-1.2009.4.2_FC5 and the two 
> broken kernels, and the behavior shifts between working and running 
> too fast each time.  (The hardware clock runs perfectly fine too.)
> 
> Anyone else seeing it?  Any more information that would be useful?
> I assume this is related to the "timer fixes" from git9 mentioned
> in the 2028 update, although frankly I don't know enough to be sure.
> Obviously, this is a blocker for me personally, but I haven't seen
> any other complaints.
> 
> John Thacker
> 

I've the feeling it is doing the same over here too, I'll watch it more 
closely now to see if it really is.

Regards,

Hans



From katzj at redhat.com  Fri Mar 10 19:42:20 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 10 Mar 2006 14:42:20 -0500
Subject: Request: boot rescue environment from USB key
In-Reply-To: <1142013708.2876.91.camel@laptopd505.fenrus.org>
References: <200603082257.55895.prigault@oricom.ca>
	<1141877948.20202.23.camel@ender>
	<1141976712.2876.12.camel@laptopd505.fenrus.org>
	<1142007102.2505.14.camel@ender>
	<1142008260.2876.68.camel@laptopd505.fenrus.org>
	<1142008650.2505.25.camel@ender>
	<1142011542.2876.79.camel@laptopd505.fenrus.org>
	<1142011788.3073.13.camel@aglarond.local>
	<1142013708.2876.91.camel@laptopd505.fenrus.org>
Message-ID: <1142019740.3073.15.camel@aglarond.local>

On Fri, 2006-03-10 at 19:01 +0100, Arjan van de Ven wrote:
> On Fri, 2006-03-10 at 12:29 -0500, Jeremy Katz wrote:
> > On Fri, 2006-03-10 at 18:25 +0100, Arjan van de Ven wrote:
> > > as I said it already works.
> > > Except that anaconda as whole didn't think usb sticks come in 2
> > > varieties: partitioned and unpartitioned. It assumed only partitioned.
> > 
> > Which part of anaconda?  I know I wrote code at least once to handle
> > both cases.
> 
> the part that tries to find stage2.img; it refuses to look at the usb
> stick if there's no partition table. (disclaimer: this was with the
> fc5test3 images, it can be that you fixed it since)

Yeah, doesn't look like that code is as smart.  If you file something,
that should be easy to knock out for FC6

Jeremy



From pekkas at netcore.fi  Fri Mar 10 20:19:10 2006
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 10 Mar 2006 22:19:10 +0200 (EET)
Subject: Fedora Core 5 Status
In-Reply-To: <200603101220.33585.prigault@oricom.ca>
References: <200603101220.33585.prigault@oricom.ca>
Message-ID: <Pine.LNX.4.64.0603102213250.23722@netcore.fi>

On Fri, 10 Mar 2006, Philippe Rigault wrote:
...
> In conclusion, I think that:
> 1. There should be a new test release, so that gcc/glibc are tested before
> FC5 final
> 2. Since GNOME 2.14 may happen before this test release, it could be
> included.

Uhh, I'm not following the logic about testing.  It's not like you can 
just install FC5, disable yum, and forget about it for years.

FWIW, at present, FC4 has over 2 GB of updates.  If there are major 
bugs in any of the FC5 system components, I'm pretty confident that 
they'll be fixed; as a matter of fact, I'd be surprised if the gcc, 
glibc or gnome weren't updated within the next 3 months or so.

-- 
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 jfrieben at freesurf.fr  Fri Mar 10 21:18:25 2006
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Fri, 10 Mar 2006 22:18:25 +0100 (CET)
Subject: System clock speedup with latest kernels
In-Reply-To: <20060310173943.GA3470@localhost.localdomain>
References: <20060310173943.GA3470@localhost.localdomain>
Message-ID: <7389.194.94.224.254.1142025505.squirrel@jose.freesurf.fr>

For SMP systems, this kind of bug has been around for ages, see my almost
prehistoric bug report from 2001:

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

The kernel got finally fixed in November 2005 and is broken again since
January 2006. Curious to see, that UP systems are now hit, too. Adding the
"noapic" kernel option did the job for me.

>
> Anyone else seeing this:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184593 ?
>
> With the last two kernels, 2.6.15-1.2032_FC5 and 2.6.15-1.2038_FC5, the
> system clock starts running too fast for me. ...
>




From prigault at oricom.ca  Fri Mar 10 21:24:12 2006
From: prigault at oricom.ca (Philippe Rigault)
Date: Fri, 10 Mar 2006 16:24:12 -0500
Subject: Fedora Core 5 Status
In-Reply-To: <200603101358.16653.philippe.rigault@borabora.crchul.ulaval.ca>
References: <200603101358.16653.philippe.rigault@borabora.crchul.ulaval.ca>
Message-ID: <200603101624.12608.prigault@oricom.ca>

On Friday 10 March 2006 13:58, you wrote:
> On Fri, 2006-03-10 at 12:20 -0500, Philippe Rigault wrote:
> > I have two problems with this:
> >
> > The first is that FC5 will be released essentially _untested_ after two
> > of
>
> its
>
> > main components were upgraded to a stable release after FC5test3:
> >  - gcc 4.1.0
> >  - glibc-2.4
> >
> > It could be argued that FC5 will be _released_ with a stable release of
> > its compiler and C library, but not that this had been tested.
>
> The changes between what we shipped in test3 and what we're going to be
> shipping are extremely small.  

Sure, only 2442 RPM packages have been rebuilt out of 2442.

> And we _always_ have to fix bugs in 
> things between test3 and the final release, sometimes larger ones than
> the diff present there.

Understood, but there should be a rule that after the last release candidate, 
there can not be _any_ major change (such as one that triggers recompilation 
of all packages) and that only major regressions be fixed. And in case a 
major change must occur (to fix showstoppers only), then at least one more 
release candidate is warranted.
I find GCC to be an example to follow in the way they deal with releases, both 
in terms of policies and in terms of enforcing them. Release candidates 
(which test3 should be) are exactly that, an ideal release candidate is one 
that is not modified at all before release. A (good) consequence of that is 
that one never knows how many RC will be necessary, all they know is that 
quality and process is what drives releases.

> > The second goes the same way, arguing that if test3 is the latest test
> > release, any new major component should _not_ be upgraded to a new
> > release, which is particularly true for a big beast like GNOME.
>
> Again, the changes going in at this point are all small targeted bug
> fixes as they wind down their release cycle.
>
> Trust me, we're looking at diffs of everything that's going in at this
> point and if some component of GNOME goes off and rewrites a huge chunk
> of how it works, we're not going to pull it in.
This point already has 100% of packages different from what I last tested in 
core3.

I trust you and other Fedora developers  for the quality of your work, but it 
is entirely beside the point. 
The point of testing is that you avoid surprises, and you always apply the 
same simple rules consistently.
My machines trust neither you nor me. 

Respecting arbitrary timelines for final releases (especially by a few weeks), 
although desirable,  is of importance close to zero to me compared to 
quality.

Cheers,

Philippe.



From jkeating at redhat.com  Fri Mar 10 21:35:06 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 10 Mar 2006 16:35:06 -0500
Subject: Fedora Core 5 Status
In-Reply-To: <200603101624.12608.prigault@oricom.ca>
References: <200603101358.16653.philippe.rigault@borabora.crchul.ulaval.ca>
	<200603101624.12608.prigault@oricom.ca>
Message-ID: <1142026506.2505.52.camel@ender>

On Fri, 2006-03-10 at 16:24 -0500, Philippe Rigault wrote:
> Sure, only 2442 RPM packages have been rebuilt out of 2442.

Um, no.  These were rebuilt before Test3, and the reason why Test3 took
a while because we wanted to get these built FOR test3 so that they
would get TESTING.

> > And we _always_ have to fix bugs in 
> > things between test3 and the final release, sometimes larger ones than
> > the diff present there.
> 
> Understood, but there should be a rule that after the last release candidate, 
> there can not be _any_ major change (such as one that triggers recompilation 
> of all packages) and that only major regressions be fixed. And in case a 
> major change must occur (to fix showstoppers only), then at least one more 
> release candidate is warranted.
> I find GCC to be an example to follow in the way they deal with releases, both 
> in terms of policies and in terms of enforcing them. Release candidates 
> (which test3 should be) are exactly that, an ideal release candidate is one 
> that is not modified at all before release. A (good) consequence of that is 
> that one never knows how many RC will be necessary, all they know is that 
> quality and process is what drives releases.

The goal of FC5 was to get in gcc4.1.  We used pre-release snapshots
during the development leading up to the final release.  We used these
pre-releases as targets that would need the full rebuild so that when
the final landed it would NOT necessitate rebuilding the entire distro.
See, this was planned out and done with a purpose.  We didn't just wake
up one day and say "Hey, lets toss in a new compiler sometime in the
middle of the development cycle.", this was something we planned around
from the get go.  Same with gnome.  Pre-release snapshots DURING testing
to be tested, so that when the final tarballs land, they'll just be
fixing bugs and not introducing new features.  Funny that.  

> > > The second goes the same way, arguing that if test3 is the latest test
> > > release, any new major component should _not_ be upgraded to a new
> > > release, which is particularly true for a big beast like GNOME.
> >
> > Again, the changes going in at this point are all small targeted bug
> > fixes as they wind down their release cycle.
> >
> > Trust me, we're looking at diffs of everything that's going in at this
> > point and if some component of GNOME goes off and rewrites a huge chunk
> > of how it works, we're not going to pull it in.
> This point already has 100% of packages different from what I last tested in 
> core3.
> 
> I trust you and other Fedora developers  for the quality of your work, but it 
> is entirely beside the point. 
> The point of testing is that you avoid surprises, and you always apply the 
> same simple rules consistently.
> My machines trust neither you nor me. 
> 

We're avoiding surprises by using the prerelease snapshots on an, um,
prerelease snapshot of Fedora.  So that when the final releases come
out, we're not surprised by anything, we've been tracking it all along,
and we're doing just minor updates for the final release.

Does this make sense?


-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/46b9322c/attachment.sig>

From prigault at oricom.ca  Fri Mar 10 22:38:06 2006
From: prigault at oricom.ca (Philippe Rigault)
Date: Fri, 10 Mar 2006 17:38:06 -0500
Subject: Fedora Core 5 Status
Message-ID: <200603101738.07266.prigault@oricom.ca>

Thank you, Jesse, for the explaination.

On Fri, 10 Mar 2006 16:35:06 -0500, Jesse Keating wrote:
> On Fri, 2006-03-10 at 16:24 -0500, Philippe Rigault wrote:
> > Sure, only 2442 RPM packages have been rebuilt out of 2442.
> 
> Um, no.  These were rebuilt before Test3, and the reason why Test3 took
> a while because we wanted to get these built FOR test3 so that they
> would get TESTING.

I see, I misinterpreted the fact that all packages have a last modification 
date of March 6 or after, it is true that most carry the same name as in 
test3. Most of them have therefore been touch'ed and not rebuild, right ?

And since packages based on gcc-4.1.0 and glibc-2.4 stable were indeed rebuilt 
after test 3, it means that most packages on FC5 will have been built with an 
earlier gcc/glibc (pre-release), different from that distributed in the 
release.

As a consequence, if one takes an FC5 SRPM and does a 'rpmbuild -bb', the rpm 
may contain differences from the native RPM disributed with FC5.

Am I right on these points ?

Maybe this deserves a little note in the release notes (unless I am the only 
one who was confused).

Thanks.



From roland at redhat.com  Fri Mar 10 23:08:30 2006
From: roland at redhat.com (Roland McGrath)
Date: Fri, 10 Mar 2006 15:08:30 -0800 (PST)
Subject: Fedora Core 5 Status
In-Reply-To: Philippe Rigault's message of  Friday,
	10 March 2006 17:38:06 -0500
	<200603101738.07266.prigault@oricom.ca>
Message-ID: <20060310230830.43C66180AB4@magilla.sf.frob.com>

> I see, I misinterpreted the fact that all packages have a last modification 
> date of March 6 or after, it is true that most carry the same name as in 
> test3. Most of them have therefore been touch'ed and not rebuild, right ?

There is only one build ever done with the same N-V-R.ARCH.  The files may
have been signed later, or signed again with different keys at different
times; that is the only reason two copies N-V-R.ARCH.rpm should not be
identical.  They are copied around frequently to make up the install trees
and download areas and so forth, which might change the modtimes unrelated
to anything meaningful.

> And since packages based on gcc-4.1.0 and glibc-2.4 stable were indeed
> rebuilt after test 3, it means that most packages on FC5 will have been
> built with an earlier gcc/glibc (pre-release), different from that
> distributed in the release.
> 
> As a consequence, if one takes an FC5 SRPM and does a 'rpmbuild -bb', the
> rpm may contain differences from the native RPM disributed with FC5.

This is potentially true by definition (obviously), when any rpm predates
the prerequisites involved in building it.  (Note that there are always
byte-level differences in a package when you rebuild it even using exactly
identical prerequisites, because of dates and such.  Inside individual
compiled files, there may be byte-level differences inside for the same
reason, though off hand I would expect those to show up only in the
-debuginfo rpms.  You have to do somewhat savvy comparisons to avoid false
mismatches, using tools like eu-elfcmp.)

We honestly don't expect you to find such differences however.  During the
pre-release period, we endeavor to rebuild things when they are affected by
tools changes.  This is why we had those complete rebuilds during testing,
where every package's release number changed.  Just recently, we discovered
a last-minute compiler problem and updated the compiler to fix it; that
problem affected only a few packages (ones producing ppc32 binaries that
use TLS in a certain way), and so we rebuilt all those packages with the
fixed compiler.  We cannot be 110% sure that the new compiler doesn't
differ in some other way beyond our imaginings, or that we didn't overlook
some individual packages that should have been rebuilt--but we are 99% sure.
It's certainly undesireable to make any material change to the compiler so
late, and we would not have done it if it were avoidable.  

But you asked about the updates after the official GNU releases of
gcc-4.1.0 and glibc-2.4, in particular.  These are both much less eventful
updates than you might imagine.  It's not like we rebased to a new upstream
version of the code at the last minute.  For a long time we have been using
a gcc and a glibc based on the day to day upstream branches in preparation
for the 4.1 and 2.4 releases--every update during the testing period has
gotten our base as close as is physically possible to what those releases
would contain when finalized.  The gcc-4.1.0 and glibc-2.4 releases were
essentially blessings of the code we had built already, not new bases for
our builds.  The version numbers changed and very little else.


Thanks,
Roland



From notting at redhat.com  Sat Mar 11 01:32:58 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 10 Mar 2006 20:32:58 -0500
Subject: Fedora Core 5 Status
In-Reply-To: <200603101728.03241.prigault@oricom.ca>
References: <200603101728.03241.prigault@oricom.ca>
Message-ID: <20060311013258.GB10099@devserv.devel.redhat.com>

Philippe Rigault (prigault at oricom.ca) said: 
> Thank you, Jesse, for the explaination.
> 
> On Fri, 10 Mar 2006 16:35:06 -0500, Jesse Keating wrote:
> > On Fri, 2006-03-10 at 16:24 -0500, Philippe Rigault wrote:
> > > Sure, only 2442 RPM packages have been rebuilt out of 2442.
> > 
> > Um, no.  These were rebuilt before Test3, and the reason why Test3 took
> > a while because we wanted to get these built FOR test3 so that they
> > would get TESTING.
> 
> I see, I misinterpreted the fact that all packages have a last modification 
> date of March 6 or after, it is true that most carry the same name as in 
> test3. Most of them have therefore been touch'ed and not rebuild, right ?

They've been signed.

Bill



From admin at ramshacklestudios.com  Sat Mar 11 01:49:03 2006
From: admin at ramshacklestudios.com (Peter Gordon)
Date: Fri, 10 Mar 2006 17:49:03 -0800
Subject: Fedora Core 5 Status
In-Reply-To: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
References: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
Message-ID: <1142041744.3331.16.camel@tuxhugger>

On Fri, 2006-03-10 at 10:53 -0500, Jeremy Katz wrote:
> Due to circumstances outside of our control, we're going to be unable to
> keep to the scheduled date of March 15th for the release of FC5 and
> instead are going to have to make the release date Monday, March 20th.
> While unfortunate in some ways, this gives us the opportunity to pull in
> the final GNOME 2.14 tarballs which should be available on Monday
> assuming the changes are suitably minor.  
> 
> Jeremy

As others have probably similarly mentioned, I think the few extras days
for another excellent Fedora release is well worth the wait. Thank you,
Jeremy and Jesse and Rahul and Dave and others, for all your hard
work! :)
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xDA3634D7
Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060310/98bd7f14/attachment.sig>

From seg at haxxed.com  Sat Mar 11 06:42:10 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 11 Mar 2006 00:42:10 -0600
Subject: aiglx
In-Reply-To: <1141324968.11294.48.camel@xpc.home.erwinrol.com>
References: <4404EF88.4080000@paradigma.pt>
	<44062996.7000907@fedoraproject.org>
	<d82d6db50603021026s368de3f7udefd35344aa0a6de@mail.gmail.com>
	<1141324968.11294.48.camel@xpc.home.erwinrol.com>
Message-ID: <1142059331.2640.37.camel@localhost>

On Thu, 2006-03-02 at 19:42 +0100, Erwin Rol wrote:
> But I agree with you that everybody that works on software that I don't
> use is wasting his time, and that they work on the wrong software also
> is the cause I have to wait longer on the software I want to use.

Dunno how much sarcasm is in that, but on a serious note:

http://www.jadetower.org/muses/archives/000039.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060311/9e65b6b4/attachment.sig>

From buildsys at redhat.com  Sat Mar 11 09:41:17 2006
From: buildsys at redhat.com (Build System)
Date: Sat, 11 Mar 2006 04:41:17 -0500
Subject: rawhide report: 20060311 changes
Message-ID: <200603110941.k2B9fHRf022009@porkchop.devel.redhat.com>

 

 
Updated Packages:

gnupg-1.4.2.2-2
---------------
* Fri Mar 10 2006 Nalin Dahyabhai <nalin at redhat.com> - 1.4.2.2-2
- rebuild

* Fri Mar 10 2006 Nalin Dahyabhai <nalin at redhat.com> - 1.4.2.2-1
- update to 1.4.2.2 to fix detection of unsigned data (CVE-2006-0049, #185111)

kernel-2.6.15-1.2041_FC5
------------------------
* Fri Mar 10 2006 Dave Jones <davej at redhat.com>
- And back off.

* Fri Mar 10 2006 Dave Jones <davej at redhat.com>
- Turn slab debug back on for one more build

* Thu Mar 09 2006 Dave Jones <davej at redhat.com>
- Add viro's slab leak detector.

mkinitrd-5.0.31-1
-----------------
* Fri Mar 10 2006 Peter Jones <pjones at redhat.com> - 5.0.31-1
- add segv handler for nash

pm-utils-0.14-1
---------------
* Fri Mar 10 2006 Peter Jones <pjones at redhat.com> - 0.14-1
- fix hibernate check in /etc/pm/hooks/20video

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.13.i686 requires kernel = 0:2.6.15-1.2038_FC5
	GFS-kernel - 2.6.15.1-5.FC5.13.i686 requires /lib/modules/2.6.15-1.2038_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.13.i686 requires /lib/modules/2.6.15-1.2038_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.13.i686 requires kernel-smp = 0:2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.i686 requires kernel = 0:2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.i686 requires /lib/modules/2.6.15-1.2038_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.11.i686 requires /lib/modules/2.6.15-1.2038_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.11.i686 requires kernel-smp = 0:2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.i686 requires kernel = 0:2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.i686 requires /lib/modules/2.6.15-1.2038_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.9.i686 requires /lib/modules/2.6.15-1.2038_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.2038_FC5
	gnbd-kernel - 2.6.15-5.FC5.14.i686 requires kernel = 0:2.6.15-1.2032_FC5
	gnbd-kernel - 2.6.15-5.FC5.14.i686 requires /lib/modules/2.6.15-1.2032_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.14.i686 requires /lib/modules/2.6.15-1.2032_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2032_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.13.x86_64 requires kernel = 0:2.6.15-1.2038_FC5
	GFS-kernel - 2.6.15.1-5.FC5.13.x86_64 requires /lib/modules/2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.x86_64 requires kernel = 0:2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.x86_64 requires /lib/modules/2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.x86_64 requires kernel = 0:2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.x86_64 requires /lib/modules/2.6.15-1.2038_FC5
	gnbd-kernel - 2.6.15-5.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2032_FC5
	gnbd-kernel - 2.6.15-5.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2032_FC5





From dragoran at feuerpokemon.de  Sat Mar 11 17:43:55 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Sat, 11 Mar 2006 18:43:55 +0100
Subject: kernel versioning
In-Reply-To: <Pine.LNX.4.63.0603101756050.28470@tla.xelerance.com>
References: <20060310084413.GE1803@neu.nirvana>
	<Pine.LNX.4.63.0603101756050.28470@tla.xelerance.com>
Message-ID: <44130C5B.9090904@feuerpokemon.de>

Paul Wouters wrote:

>On Fri, 10 Mar 2006, Axel Thimm wrote:
>
>  
>
>>upstream kernels that are release candidates or git sub-rcs etc. are
>>versioned in FC/RHEL based on the previous stable kernel release,
>>e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15.
>>
>>I generally think that's a good idea (e.g. it *is* 2.6.15 with patches
>>towards 2.6.16 and not yet 2.6.16, and the user is not confused that
>>he's already running 2.6.16).
>>
>>But tons of kernel module projects check on the version of the kernel
>>and trigger different code bits. These projects depend on the
>>versioning to decide whether some features exist or not.
>>
>>This results to funny external Fedora-patches to these projects that
>>only last a kernel release and are troublesome to maintain.
>>    
>>
>
>Yes, this is a nightmare for openswan's KLIPS module.
>
>  
>
>>So there is a wish to keep the versioning in the top level Makefile as
>>vanilla ships it. That way the checks will be more accurate and
>>users/upstream/packagers will have less to worry about, less
>>Fedora-only patching and so on.
>>    
>>
>
>That is going to be confusing too.
>
>  
>
>>Any thoughts on how to make everyone happy? :)
>>    
>>
>
>I have no idea :(
>
>Paul
>  
>
A solution is not to check the kernel version but to check for 
features/apis they need.
the (closed) nvidia driver does this for the wrapper part and it seems 
to work fine.



From paul at cypherpunks.ca  Sat Mar 11 19:29:32 2006
From: paul at cypherpunks.ca (Paul Wouters)
Date: Sat, 11 Mar 2006 20:29:32 +0100 (CET)
Subject: kernel versioning
In-Reply-To: <44130C5B.9090904@feuerpokemon.de>
References: <20060310084413.GE1803@neu.nirvana>
	<Pine.LNX.4.63.0603101756050.28470@tla.xelerance.com>
	<44130C5B.9090904@feuerpokemon.de>
Message-ID: <Pine.LNX.4.63.0603112022270.26776@tla.xelerance.com>

On Sat, 11 Mar 2006, dragoran wrote:

> > > Any thoughts on how to make everyone happy? :)
> >
> > I have no idea :(
> >
> > Paul
> >
> A solution is not to check the kernel version but to check for features/apis
> they need.
> the (closed) nvidia driver does this for the wrapper part and it seems to work
> fine.

That does not work when cross compiling.

Tell me how to properly check for the changed skb structures without using
versions or compiling code. Perhaps these changed should set defines that
do not rely on kernel versions. We now had to make our own defines which we
then set in the spec file. They are also versioned, but for fedora we need
to override these in the spec file. So far we already have:

HAVE_SOCK_ZAPPED
NET_26_12_SKALLOC
HAVE_SOCK_SECURITY
HAVE_SKB_NF_DEBUG
SYSCTL_IPSEC_DEFAULT_TTL
HAVE_TSTAMP
HAVE_INET_SK_SPORT

Unfortunately, I really have no idea how to better do this, unless fedora
ships some kernel header so at least all software projects could just
re-use the same defines and all projects wouldn't have to re-invent the
wheel. Because so far, we usually find out only after a kernel api broke.

Better documentation about these would be appreciated.

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155



From bojan at rexursive.com  Sat Mar 11 22:12:21 2006
From: bojan at rexursive.com (Bojan Smojver)
Date: Sun, 12 Mar 2006 09:12:21 +1100
Subject: Recent kernels hang on resume
Message-ID: <1142115142.2001.10.camel@coyote.rexursive.com>

Just for the record, the recent kernels (2032 and above it would seem),
hang occasionally on resume on my notebook (this is after suspend to
disk with the vanilla kernel code). The last output is:

Stopping tasks: =

I'm attaching the lspci output for hardware reference. Full specs of the
notebook are here:

http://www.rexursive.com/articles/linuxonhpze4201.html

The suspend to disk/resume first started working with 2.6.15-1.1909_FC5,
when a fix for ATI graphics suspend code was committed to the vanilla
kernel. Things now appear to be broken again. I'm just not sure if
anyone else is seeing this on their hardware, or if it's specific to
this machine.

-- 
Bojan
-------------- next part --------------
00:00.0 Host bridge: ATI Technologies Inc RS200/RS200M AGP Bridge [IGP 340M] (rev 02)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 64
	Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Region 1: Memory at d4005000 (32-bit, prefetchable) [size=4K]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4

00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M] (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 99
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: d4300000-d43fffff
	Prefetchable memory behind bridge: dc000000-dfffffff
	Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (20000ns max), Cache Line Size 08
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR+
	Latency: 64 (500ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at 1000 [size=256]
	Region 1: Memory at d4001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: ALi Corporation M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+]
	Subsystem: ALi Corporation ALi M1533 Aladdin IV/V ISA Bridge
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [a0] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:08.0 Modem: ALi Corporation M5457 AC'97 Modem Controller (prog-if 00 [Generic])
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at d4002000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at 1400 [size=256]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 CardBus bridge: O2 Micro, Inc. OZ601/6912/711E0 CardBus/SmartCardBus Controller
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at d4003000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 40000000-41fff000 (prefetchable)
	Memory window 1: 42000000-43fff000
	I/O window 0: 00001800-000018ff
	I/O window 1: 00001c00-00001cff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) (prog-if fa)
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 1000ns max)
	Interrupt: pin A routed to IRQ 0
	Region 4: I/O ports at 2000 [size=16]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 90 (2750ns min, 13000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at 2400 [size=256]
	Region 1: Memory at d4004000 (32-bit, non-prefetchable) [size=4K]
	[virtual] Expansion ROM at 44000000 [disabled] [size=64K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=320mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M (prog-if 00 [VGA])
	Subsystem: Hewlett-Packard Company Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 66 (2000ns min), Cache Line Size 08
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at dc000000 (32-bit, prefetchable) [size=64M]
	Region 1: I/O ports at 9000 [size=256]
	Region 2: Memory at d4300000 (32-bit, non-prefetchable) [size=64K]
	[virtual] Expansion ROM at d4320000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
		Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
		Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-


From casimiro.barreto at gmail.com  Sun Mar 12 02:46:59 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Sat, 11 Mar 2006 23:46:59 -0300
Subject: Problems with kernel-2.6.15-1.2041_FC5
Message-ID: <44138BA3.2010700@gmail.com>

Dear sirs,

Kernel-2.6.15-1.2041_FC5 does not recognize USB devices and have 
problems in DNS. Also locks looking for bluetooth devices.

Computer box uses an ASUS P4S800-MX SE

In this board and with all the kernels up to the moment I've experienced 
enormous problems with linear and raid1 devices. Linux blocks (just like 
M$), all IRQs dead (flatline dead) and the only way is to power off the 
computer and restart. After that, when examining system log, not a 
single message indicates what can be the origin of the problem. It is 
really anoying and a major setback.

Both linear devices and raid1 devices were built using standard (or, in 
other words, that should work) procedures. Both disks are SATA, 
identical. Partitions used for raid1 are identical in both disks (same 
starting point, same ending point, etc). Locks happen, usually, when 
burst recording large files.

Best regards,

Casimiro



From buildsys at redhat.com  Sun Mar 12 08:35:42 2006
From: buildsys at redhat.com (Build System)
Date: Sun, 12 Mar 2006 03:35:42 -0500
Subject: rawhide report: 20060312 changes
Message-ID: <200603120835.k2C8Zg9f016356@porkchop.devel.redhat.com>

 

 
Updated Packages:

gnbd-kernel-2.6.15-5.FC5.18
---------------------------

gnome-pilot-2.0.13-7.fc5.4
--------------------------
* Sat Mar 11 2006 Bill Nottingham <notting at redhat.com> 2.0.13-7.fc5.4
- fix pilot-link-version vs pilot_link_version macro/dep confusion

* Tue Feb 28 2006 Karsten Hopp <karsten at redhat.de> 2.0.13-7.fc5.3
- Buildrequires: gob2

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 2.0.13-7.fc5.2.1
- bump again for double-long bug on ppc(64)

libnotify-0.3.0-6
-----------------
* Sat Mar 11 2006 Bill Nottingham <notting at redhat.com> - 0.3.0-6
- define %{glib2_version} if it's in a requirement

librsvg2-2.14.1-2
-----------------
* Sat Mar 11 2006 Bill Nottingham <notting at redhat.com> 2.14.1-2
- fix bad libart dep

openoffice.org-1:2.0.2-5.2.2
----------------------------
* Fri Mar 10 2006 Bill Nottingham <notting at redhat.com> - 1:2.0.2-5.2
- rebuild for PPC TLS issue (#184446)

pm-utils-0.15-1
---------------
* Sat Mar 11 2006 Peter Jones <pjones at redhat.com> - 0.15-1
- fix hibernate check in a way that doesn't break "sleep".

policycoreutils-1.29.26-6
-------------------------
* Fri Mar 10 2006 Dan Walsh <dwalsh at redhat.com> 1.29.26-6
- Remove prereq

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.13.i686 requires kernel = 0:2.6.15-1.2038_FC5
	GFS-kernel - 2.6.15.1-5.FC5.13.i686 requires /lib/modules/2.6.15-1.2038_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.13.i686 requires /lib/modules/2.6.15-1.2038_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.13.i686 requires kernel-smp = 0:2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.i686 requires kernel = 0:2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.i686 requires /lib/modules/2.6.15-1.2038_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.11.i686 requires /lib/modules/2.6.15-1.2038_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.11.i686 requires kernel-smp = 0:2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.i686 requires kernel = 0:2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.i686 requires /lib/modules/2.6.15-1.2038_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.9.i686 requires /lib/modules/2.6.15-1.2038_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.2038_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.13.x86_64 requires kernel = 0:2.6.15-1.2038_FC5
	GFS-kernel - 2.6.15.1-5.FC5.13.x86_64 requires /lib/modules/2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.x86_64 requires kernel = 0:2.6.15-1.2038_FC5
	cman-kernel - 2.6.15.1-0.FC5.11.x86_64 requires /lib/modules/2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.x86_64 requires kernel = 0:2.6.15-1.2038_FC5
	dlm-kernel - 2.6.15.1-0.FC5.9.x86_64 requires /lib/modules/2.6.15-1.2038_FC5





From arjan at fenrus.demon.nl  Sun Mar 12 08:52:41 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Sun, 12 Mar 2006 09:52:41 +0100
Subject: kernel versioning
In-Reply-To: <Pine.LNX.4.63.0603112022270.26776@tla.xelerance.com>
References: <20060310084413.GE1803@neu.nirvana>
	<Pine.LNX.4.63.0603101756050.28470@tla.xelerance.com>
	<44130C5B.9090904@feuerpokemon.de>
	<Pine.LNX.4.63.0603112022270.26776@tla.xelerance.com>
Message-ID: <1142153561.2882.7.camel@laptopd505.fenrus.org>


> HAVE_SOCK_ZAPPED
> NET_26_12_SKALLOC
> HAVE_SOCK_SECURITY
> HAVE_SKB_NF_DEBUG
> SYSCTL_IPSEC_DEFAULT_TTL
> HAVE_TSTAMP
> HAVE_INET_SK_SPORT
> 
> Unfortunately, I really have no idea how to better do this, unless fedora
> ships some kernel header so at least all software projects could just
> re-use the same defines and all projects wouldn't have to re-invent the
> wheel. Because so far, we usually find out only after a kernel api broke.

well API changes are one of the prices you pay for being an outside
module, and is not unique to Fedora.

The entire kernel development model is setup for having everything in
one repo, and everything outside that is just painful. See that as
incentive to get your code merged ;)



From gilboad at gmail.com  Sun Mar 12 09:35:24 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 12 Mar 2006 11:35:24 +0200
Subject: Rawhide 20061103 install report (x86_64).
Message-ID: <1142156124.18462.3.camel@gilboa-work-dev>

Hello all,

Problem list:
* During installation the grub configuration prompt did not appear.
* Installation finished successfully.

Reboot:
1. Kernel was not installed.
2. Grub was not configured.
3. coreutils rpm was not installed.
4. As a result, rawhide could not be rebooted.

Gilboa



From fedora at camperquake.de  Sun Mar 12 15:21:01 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 12 Mar 2006 16:21:01 +0100
Subject: The repository scoring problem - a proposal
Message-ID: <20060312162101.3a36a492@lain>

Hi.

Every one in a while the problem of repository scoring comes up (maybe
under a different name, but I chose this one): The wish of users to
give different RPM repositories different "rights" with respect to the
packages that can be installed from the various sources, mostly to prevent
third party repositories from replacing packages installed by the core
operating system.

This post is not about discussing whether this is a good idea or not.
I personally think this is a valid tool, but I can see that there may
be other views about it.

A core problem in this context is that while it is possible to determine
where a package comes from at installation time this information is lost
during installation, all packages installed on a system are "equal" in
that there is no way to tell where they originally came from, thus making
the scoring mentioned above hard to impossible.

It has been proposed to add a field to the RPM file headers that can
be set by the packager to indicate where the package came from. This requires
work on the behalf of all packagers/repositories, and is thus not likely
to work (in my opinion), or it will take a long time to actually show effect.

I hereby propose a diffenent path. Do not add repository information to
the RPM files (or do it anyway, it is useful information after all, just
not suited for the problem at hand) but change the RPM libraries to enable
programs installing packages (be it RPM itself, yum, smart or whatever)
to add metadata to the installed package. The installing program knows
best where it got the package it is just installing, after all, so
it can add the information itself.

This has the following pros and cons:

Pro:
* If implemented, it works right now (except for packages already installed,
  but other approaches have that problem, too)
* It requires no work on the behalf of the packagers
* It is stable against repositories changing their repository id (if
  such a field is added, see above)

Cons:
* It may not be stable against certain configuration changes in
  the package managing program (if, for example, yum uses it's internal
  repositoryid to tag packages a change to that id would create
  some problems)
* Using different programs to manage your packages at the same time will
  probably not work, since they will not recognize the tags written by
  each other.
* I do not know if such a change can be made while retaining backwards
  compatibility to older RPM versions (if this is desired, that is)


I'd like to hear your thoughts about this. And maybe there are other ideas
of what can be done with user addable metadata in the RPM package DB.



From walovaton at yahoo.com.mx  Sun Mar 12 15:36:02 2006
From: walovaton at yahoo.com.mx (William Lovaton)
Date: Sun, 12 Mar 2006 10:36:02 -0500
Subject: System clock speedup with latest kernels
In-Reply-To: <1142013181.3102.2.camel@stantonfinley.org>
References: <20060310173943.GA3470@localhost.localdomain>
	<1142013181.3102.2.camel@stantonfinley.org>
Message-ID: <1142177762.2197.5.camel@athlon2000>

Hi,

El vie, 10-03-2006 a las 10:53 -0700, Stanton Finley escribi??:
> On Fri, 2006-03-10 at 12:39 -0500, John Thacker wrote:
> > Anyone else seeing this:
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184593 ?
> > 
> > With the last two kernels, 2.6.15-1.2032_FC5 and 2.6.15-1.2038_FC5,
> > the system clock starts running too fast for me.  It gains about an
> > hour per day.  It runs so fast that NTP won't sync to any clock
> > servers because the jitter grows far too fast.  Rebooting to 
> > kernel-2.6.15-1.2009.4.2_FC5 works perfectly.  I can switch back and 
> > forth between the working kernel-2.6.15-1.2009.4.2_FC5 and the two 
> > broken kernels, and the behavior shifts between working and running 
> > too fast each time.  (The hardware clock runs perfectly fine too.)
> > 
> > Anyone else seeing it?  Any more information that would be useful?
> > I assume this is related to the "timer fixes" from git9 mentioned
> > in the 2028 update, although frankly I don't know enough to be sure.
> > Obviously, this is a blocker for me personally, but I haven't seen
> > any other complaints.
> > 
> > John Thacker
> > -- 
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> I have the same issue. Try adding "noapic nolapic" to the end of the
> "kernel" line in /boot/grub/grub.conf.

I have two IBM xSeries 445 servers running a web server and a database,
they are SPM 8X systems with hyperthreading.  And every 2 or 3 days they
get out of sync from each other and from the real world time.  Is there
any regression if I disable apic and lapic in the kernel parameters?
They are under heavy load usually.

What they are for (apic and lapic)?

-William


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ?gratis! 
Reg?strate ya - http://correo.yahoo.com.mx/ 



From fedora at camperquake.de  Sun Mar 12 15:46:43 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 12 Mar 2006 16:46:43 +0100
Subject: System clock speedup with latest kernels
In-Reply-To: <1142177762.2197.5.camel@athlon2000>
References: <20060310173943.GA3470@localhost.localdomain>
	<1142013181.3102.2.camel@stantonfinley.org>
	<1142177762.2197.5.camel@athlon2000>
Message-ID: <20060312164643.5fa2e390@lain>

Hi.

On Sun, 12 Mar 2006 10:36:02 -0500, William Lovaton wrote

> world time.  Is there any regression if I disable apic and lapic in
> the kernel parameters? They are under heavy load usually.
> 
> What they are for (apic and lapic)?

Interrupt handling. I think you can not disable them on SMP machines
(and retain SMP, that is).



From nicolas.mailhot at laposte.net  Sun Mar 12 17:34:13 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 12 Mar 2006 18:34:13 +0100
Subject: The repository scoring problem - a proposal
In-Reply-To: <20060312162101.3a36a492@lain>
References: <20060312162101.3a36a492@lain>
Message-ID: <1142184853.2606.5.camel@rousalka.dyndns.org>

Le dimanche 12 mars 2006 ? 16:21 +0100, Ralf Ertzinger a ?crit :

> It has been proposed to add a field to the RPM file headers that can
> be set by the packager to indicate where the package came from. This requires
> work on the behalf of all packagers/repositories, and is thus not likely
> to work (in my opinion), or it will take a long time to actually show effect.

Why do you need a separate header/field/whatever ?

You *already* have this field - that's the GPG signature.

Assign weights to signing keys and you're done (this solves rpm/yum,
manual rebuilds, p.r.c. repos, it's so natural that's not even funny
considering we're been ignoring it so long)

You'll note Fedora *already* recognizes keys are a discriminant -
different keys are used for different repos (Core, Security, etc)

(Of course that would require Fedora to implement the long-awaited
rawhide signing. Virtuous circle - you do something for one reason, and
it has good side effects on other problems)

Regards,

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

From michael.favia at insitesinc.com  Sun Mar 12 19:04:49 2006
From: michael.favia at insitesinc.com (Michael Favia)
Date: Sun, 12 Mar 2006 13:04:49 -0600
Subject: The repository scoring problem - a proposal
In-Reply-To: <1142184853.2606.5.camel@rousalka.dyndns.org>
References: <20060312162101.3a36a492@lain>
	<1142184853.2606.5.camel@rousalka.dyndns.org>
Message-ID: <441470D1.4060002@insitesinc.com>

Nicolas Mailhot wrote:
> (Of course that would require Fedora to implement the long-awaited
> rawhide signing. Virtuous circle - you do something for one reason, and
> it has good side effects on other problems)

Rawhide signing should be done anyway IMO. I have never heard a valid 
argument not to do so. It provides a piece of mind that you have 
authentic packages for very little cost. -mf

-- 
Michael Favia          michael.favia at insitesinc.com
Insites Incorporated  http://michael.insitesinc.com



From dwmw2 at infradead.org  Sun Mar 12 23:10:04 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 12 Mar 2006 23:10:04 +0000
Subject: The repository scoring problem - a proposal
In-Reply-To: <1142184853.2606.5.camel@rousalka.dyndns.org>
References: <20060312162101.3a36a492@lain>
	<1142184853.2606.5.camel@rousalka.dyndns.org>
Message-ID: <1142205004.29552.57.camel@localhost.localdomain>

On Sun, 2006-03-12 at 18:34 +0100, Nicolas Mailhot wrote:
> Why do you need a separate header/field/whatever ?
> You *already* have this field - that's the GPG signature.
> Assign weights to signing keys and you're done 

Not always sufficient. Most of the time I want yum to prioritise, it's
when it downloads a package from a remote repository which is actually
also available from a local one (with a file:// URL). I'd want to
priorities my local caches over the remote repositories, which can't be
done with the signature (although yum arguably ought to do that one for
itself anyway).

-- 
dwmw2



From nicolas.mailhot at laposte.net  Sun Mar 12 23:27:23 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 13 Mar 2006 00:27:23 +0100
Subject: The repository scoring problem - a proposal
In-Reply-To: <1142205004.29552.57.camel@localhost.localdomain>
References: <20060312162101.3a36a492@lain>
	<1142184853.2606.5.camel@rousalka.dyndns.org>
	<1142205004.29552.57.camel@localhost.localdomain>
Message-ID: <1142206043.2606.40.camel@rousalka.dyndns.org>

Le dimanche 12 mars 2006 ? 23:10 +0000, David Woodhouse a ?crit :
> On Sun, 2006-03-12 at 18:34 +0100, Nicolas Mailhot wrote:
> > Why do you need a separate header/field/whatever ?
> > You *already* have this field - that's the GPG signature.
> > Assign weights to signing keys and you're done 
> 
> Not always sufficient. Most of the time I want yum to prioritise, it's
> when it downloads a package from a remote repository which is actually
> also available from a local one (with a file:// URL). I'd want to
> priorities my local caches over the remote repositories, which can't be
> done with the signature (although yum arguably ought to do that one for
> itself anyway).

The local/remote problem is 100% inside yum - can not be solved at the
package level. One could even argue it should not be exposed at the user
at all.

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

From paul at cypherpunks.ca  Mon Mar 13 01:59:14 2006
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 13 Mar 2006 02:59:14 +0100 (CET)
Subject: kernel versioning
In-Reply-To: <1142153561.2882.7.camel@laptopd505.fenrus.org>
References: <20060310084413.GE1803@neu.nirvana>
	<Pine.LNX.4.63.0603101756050.28470@tla.xelerance.com>
	<44130C5B.9090904@feuerpokemon.de>
	<Pine.LNX.4.63.0603112022270.26776@tla.xelerance.com>
	<1142153561.2882.7.camel@laptopd505.fenrus.org>
Message-ID: <Pine.LNX.4.63.0603130249250.17642@tla.xelerance.com>

On Sun, 12 Mar 2006, Arjan van de Ven wrote:

> well API changes are one of the prices you pay for being an outside
> module, and is not unique to Fedora.
>
> The entire kernel development model is setup for having everything in
> one repo, and everything outside that is just painful. See that as
> incentive to get your code merged ;)

Well, in theory one would hope that API changes in "vendor kernels" would
not be needed. After all the linuS kernel is the "experimental" kernel,
and the "vendor" kernels are supposed to be stable ones. So ideally, the
Fedora kernel would only have bugfixes, not API changes.

But it is a price we'll pay. Networking code isn't always in flux as it
has been, so most of the time it is okay. We would like to get our UDP
encapsulation patch ("IPsec NAT-Traversal patch") code in Fedora, since
right now, the ESPinUDP code is located in the XFRM code, while the KLIPS
version of this code is more general and within the udp.c code, which
unfortunately requires a kernel recompile. This patch has been in use
for years, and is pretty small, but we haven't yet submitted it for
review to Fedora or upstream. Part of the reason was that lots of people
got (rightfully so) pissed off at the FreeS/WAN politics, and although
Openswan does not have these issues, that clear cut hasn't been clear to
everyone yet. Another reason was that we were hoping to perhaps change
the code to a netfilter module, which could then be a loadable kernel
module, which is perhaps a cleaner approach and more appropriate.

Though the NAT-T patch rock solid. It has been used for many years without
known issues, so if the kernel people for Fedora would want to apply the
nat-t patch, that would of course rock! :)
(Or even just add it and define it to be disabled per default so, we can
just tell them to rpmbuild the kernel with a --define 'natt-patch=1'.

ftp://ftp.openswan.org/openswan/openswan-2.4.5rc5.kernel-2.4-natt.patch.gz

Paul



From dax at gurulabs.com  Mon Mar 13 03:00:18 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Sun, 12 Mar 2006 20:00:18 -0700
Subject: Current rawhide Anaconda LVM crash
Message-ID: <1142218818.3501.4.camel@mentorng.gurulabs.com>

Just a FYI.

On my FC4, LVM using, laptop I created a LV to install rawhide on. I
tried installing a March 11th 2006 rawhide tree. But ananconda bombed
out when I tried to do a custom layout and tried to assign "/" to the
previously created LV. This is 100% reproducible.

Bug filed with full Anaconda traceback and debug info:

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

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

From buildsys at redhat.com  Mon Mar 13 08:07:25 2006
From: buildsys at redhat.com (Build System)
Date: Mon, 13 Mar 2006 03:07:25 -0500
Subject: rawhide report: 20060313 changes
Message-ID: <200603130807.k2D87PhT000396@porkchop.devel.redhat.com>

 

 
Updated Packages:

GFS-kernel-2.6.15.1-5.FC5.15
----------------------------

cman-kernel-2.6.15.1-0.FC5.13
-----------------------------

dlm-kernel-2.6.15.1-0.FC5.11
----------------------------




Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5








From giallu at gmail.com  Mon Mar 13 08:13:32 2006
From: giallu at gmail.com (Gianluca Sforna)
Date: Mon, 13 Mar 2006 09:13:32 +0100
Subject: FC5 test3 udev hang
Message-ID: <d5ad21470603130013v57ebe748g75ced763f7fb5073@mail.gmail.com>

Hi,
I just put my hands an a shiny Acer Travelmate 8202WLMi laptop so I
decided to give a try to FC5. The installation wen fine, but upon
first reboot I an stuck at:

Starting udev:_

Admittedly, I did _not_ expected FC to work fine on that, having a
bunch of fancy new hardware in there ( Centrino Core Duo, wifi
ipw3945ABG, SATA HD and so on ), so this is just for the records.

If someone also has an idea on how to get it booting, I could try to
upgrade the beast so I can see if newer packages fixes the problem.

Thanks a lot

Gianluca



From mike at miketc.com  Mon Mar 13 08:17:22 2006
From: mike at miketc.com (Mike Chambers)
Date: Mon, 13 Mar 2006 02:17:22 -0600
Subject: FC5 test3 udev hang
In-Reply-To: <d5ad21470603130013v57ebe748g75ced763f7fb5073@mail.gmail.com>
References: <d5ad21470603130013v57ebe748g75ced763f7fb5073@mail.gmail.com>
Message-ID: <1142237842.2558.2.camel@scrappy.miketc.com>

On Mon, 2006-03-13 at 09:13 +0100, Gianluca Sforna wrote:
> Hi,
> I just put my hands an a shiny Acer Travelmate 8202WLMi laptop so I
> decided to give a try to FC5. The installation wen fine, but upon
> first reboot I an stuck at:
> 
> Starting udev:_

I would try an install from rawhide and see if that works with the
latest kernel/packages.

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt, then it's hilarious!"



From jfrieben at freesurf.fr  Mon Mar 13 09:09:26 2006
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Mon, 13 Mar 2006 10:09:26 +0100 (CET)
Subject: System clock speedup with latest kernels
In-Reply-To: <20060312164643.5fa2e390@lain>
References: <20060312164643.5fa2e390@lain>
Message-ID: <25708.194.94.224.254.1142240966.squirrel@jose.freesurf.fr>

Sure you can. For 5 years, this has been the only workaround on my PR440FX
based SMP box to keep the RTC in sync - with enabled SMP of course! See:

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

>
> Interrupt handling. I think you can not disable them on SMP machines
> (and retain SMP, that is).
>




From tarjei.knapstad at gmail.com  Mon Mar 13 13:22:48 2006
From: tarjei.knapstad at gmail.com (Tarjei Knapstad)
Date: Mon, 13 Mar 2006 14:22:48 +0100
Subject: Updated Qt4 spec [was: Qt 4 RPM and pkg-config problem]
Message-ID: <ff5e09cc0603130522r1eae635fua254d9bfdb240809@mail.gmail.com>

On 3/9/06, Tarjei Knapstad <tarjei.knapstad at gmail.com> wrote:
> > With the pkg-config bug though I'd say the package is slightly broken
> > as you can't use autotools to detect the library (well, I guess you
> > can, but pkg-config is much the preferred solution). No suggestions
> > for a fix?
> >
>
> I'm currently adding some sed stuff to the spec to go over all the .pc
> files and strip out the superfluous -L flag. I'll post an updated spec
> here later today, just need to check that it works as intended first.
>

Got caught up with something else, but here it is. I've added a
changelog entry describing what I've altered. There is one very minor
problem left concerning package removal in that the directory
$prefix/qt-4.1/plugins/sqldrivers is left behind, but other than that
it should be ok and ready for Extras submittal and review.

--
Tarjei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qt4.spec
Type: application/octet-stream
Size: 44721 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060313/f4fcfa9f/attachment.obj>

From linux_4ever at yahoo.com  Mon Mar 13 13:33:52 2006
From: linux_4ever at yahoo.com (Steve G)
Date: Mon, 13 Mar 2006 05:33:52 -0800 (PST)
Subject: rawhide e2fsprogs & yum
Message-ID: <20060313133352.83245.qmail@web51507.mail.yahoo.com>

Hi,

I've noticed a problem in rawhide just doing yum update regarding e2fsprogs on
x86_64. The update fails like this:

>Running Transaction Test
>Finished Transaction Test
>
>Transaction Check Error:   file /usr/share/man/man8/blkid.8.gz from install of
>e2fsprogs-1.38-12 conflicts with file from package e2fsprogs-1.38-1

So, I check my rpm database and see this:

>[root at dhcp83-35 ~]# ./bin/rpmdb_sanity_check
>Version mismatches were found:
>e2fsprogs-1.38-1.i386
>e2fsprogs-1.38-11.x86_64

So, x86_64 & i386 have different versions. So, I check to see what yum has to say
about this:

>[root at dhcp83-35 ~]# yum list e2fsprogs*
>Reading repository metadata in from local files
>Installed Packages
>e2fsprogs.x86_64                         1.38-11                installed
>e2fsprogs.i386                           1.38-1                 installed
>e2fsprogs-devel.x86_64                   1.38-11                installed
>e2fsprogs-libs.x86_64                    1.38-11                installed
>Available Packages
>e2fsprogs.x86_64                         1.38-12                development
>e2fsprogs-debuginfo.i386                 1.38-12                development
>e2fsprogs-debuginfo.x86_64               1.38-12                development
>e2fsprogs-devel.x86_64                   1.38-12                development
>e2fsprogs-libs.i386                      1.38-12                development
>e2fsprogs-libs.x86_64                    1.38-12                development

So...this says there are no i386 -11 or -12 packages. So, the 32 bit version must
not be needed for x86_64 anymore, lets delete it:

>[root at dhcp83-35 ~]# rpm -e e2fsprogs-1.38-1.i386
>error: Failed dependencies:
>        libcom_err.so.2 is needed by (installed) curl-7.15.1-1.2.1.i386
>        libcom_err.so.2 is needed by (installed) krb5-libs-1.4.3-4.1.i386
>        libcom_err.so.2 is needed by (installed) libc-client-2004g-2.2.i386
>        libcom_err.so.2 is needed by (installed) neon-0.25.5-1.2.i386
>        libcom_err.so.2 is needed by (installed) openssl-0.9.8a-5.2.i686
>        libcom_err.so.2 is needed by (installed) samba-common-3.0.21b-2.i386
>        libcom_err.so.2 is needed by (installed) nss_ldap-249-1.i386
>        libcom_err.so.2 is needed by (installed) gnome-vfs2-2.13.92-3.i386
>        libcom_err.so.2 is needed by (installed) cyrus-sasl-2.1.21-10.i386
>        libcom_err.so.2 is needed by (installed)
cyrus-sasl-gssapi-2.1.21-10.i386
>        libcom_err.so.2 is needed by (installed) pam_krb5-2.2.6-2.2.i386
>        libuuid.so.1 is needed by (installed) apr-1.2.2-7.2.i386

Well, I guess it is needed...is the repo broken ?  Its been like this for a week
or so.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From walovaton at yahoo.com.mx  Mon Mar 13 13:49:26 2006
From: walovaton at yahoo.com.mx (William Lovaton)
Date: Mon, 13 Mar 2006 07:49:26 -0600 (CST)
Subject: System clock speedup with latest kernels
In-Reply-To: <25708.194.94.224.254.1142240966.squirrel@jose.freesurf.fr>
Message-ID: <20060313134926.49010.qmail@web60720.mail.yahoo.com>

I'm glad to know this... but I am really worried about
performance in this case, there is a lot of traffic
between the web server (Apache/PHP) and the database
server (Oracle 9.2.0.7) so "noapic" wouldn't be a
viable workaround if it degrades performance.  Any
advice about this?

Thanks for your comments,


-William


 --- Joachim Frieben <jfrieben at freesurf.fr> escribi?:

> Sure you can. For 5 years, this has been the only
> workaround on my PR440FX
> based SMP box to keep the RTC in sync - with enabled
> SMP of course! See:
> 
>  
>
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55223
> 
> >
> > Interrupt handling. I think you can not disable
> them on SMP machines
> > (and retain SMP, that is).
> >



	
	
		
___________________________________________________________ 
Do You Yahoo!? 
La mejor conexi?n a Internet y <b >2GB</b> extra a tu correo por $100 al mes. http://net.yahoo.com.mx 



From jspaleta at gmail.com  Mon Mar 13 13:50:04 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 13 Mar 2006 08:50:04 -0500
Subject: rawhide e2fsprogs & yum
In-Reply-To: <20060313133352.83245.qmail@web51507.mail.yahoo.com>
References: <20060313133352.83245.qmail@web51507.mail.yahoo.com>
Message-ID: <604aa7910603130550g6115557em7e08b8946e26a372@mail.gmail.com>

On 3/13/06, Steve G <linux_4ever at yahoo.com> wrote:
> Well, I guess it is needed...is the repo broken ?  Its been like this for a week
> or so.

the 32bit tree has e2fsprogs-libs-1.38-12 currently.

and the 32bit version is in the rawhide tree... so I don't understand
your problem...unless your yum is hitting a stale mirror.

http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/e2fsprogs-libs-1.38-12.i386.rpm

-jef



From gilboad at gmail.com  Mon Mar 13 13:45:30 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 13 Mar 2006 15:45:30 +0200
Subject: rawhide e2fsprogs & yum
In-Reply-To: <20060313133352.83245.qmail@web51507.mail.yahoo.com>
References: <20060313133352.83245.qmail@web51507.mail.yahoo.com>
Message-ID: <1142257530.17469.4.camel@gilboa-work-dev>

On Mon, 2006-03-13 at 05:33 -0800, Steve G wrote:
> Hi,
> 
> I've noticed a problem in rawhide just doing yum update regarding e2fsprogs on
> x86_64. The update fails like this:
> 
> >Running Transaction Test
> >Finished Transaction Test
> >
> >Transaction Check Error:   file /usr/share/man/man8/blkid.8.gz from install of
> >e2fsprogs-1.38-12 conflicts with file from package e2fsprogs-1.38-1
> 
> So, I check my rpm database and see this:
> 
> >[root at dhcp83-35 ~]# ./bin/rpmdb_sanity_check
> >Version mismatches were found:
> >e2fsprogs-1.38-1.i386
> >e2fsprogs-1.38-11.x86_64
> 
> So, x86_64 & i386 have different versions. So, I check to see what yum has to say
> about this:
> 
> >[root at dhcp83-35 ~]# yum list e2fsprogs*
> >Reading repository metadata in from local files
> >Installed Packages
> >e2fsprogs.x86_64                         1.38-11                installed
> >e2fsprogs.i386                           1.38-1                 installed
> >e2fsprogs-devel.x86_64                   1.38-11                installed
> >e2fsprogs-libs.x86_64                    1.38-11                installed
> >Available Packages
> >e2fsprogs.x86_64                         1.38-12                development
> >e2fsprogs-debuginfo.i386                 1.38-12                development
> >e2fsprogs-debuginfo.x86_64               1.38-12                development
> >e2fsprogs-devel.x86_64                   1.38-12                development
> >e2fsprogs-libs.i386                      1.38-12                development
> >e2fsprogs-libs.x86_64                    1.38-12                development
> 
> So...this says there are no i386 -11 or -12 packages. So, the 32 bit version must
> not be needed for x86_64 anymore, lets delete it:
> 
> >[root at dhcp83-35 ~]# rpm -e e2fsprogs-1.38-1.i386
> >error: Failed dependencies:
> >        libcom_err.so.2 is needed by (installed) curl-7.15.1-1.2.1.i386
> >        libcom_err.so.2 is needed by (installed) krb5-libs-1.4.3-4.1.i386
> >        libcom_err.so.2 is needed by (installed) libc-client-2004g-2.2.i386
> >        libcom_err.so.2 is needed by (installed) neon-0.25.5-1.2.i386
> >        libcom_err.so.2 is needed by (installed) openssl-0.9.8a-5.2.i686
> >        libcom_err.so.2 is needed by (installed) samba-common-3.0.21b-2.i386
> >        libcom_err.so.2 is needed by (installed) nss_ldap-249-1.i386
> >        libcom_err.so.2 is needed by (installed) gnome-vfs2-2.13.92-3.i386
> >        libcom_err.so.2 is needed by (installed) cyrus-sasl-2.1.21-10.i386
> >        libcom_err.so.2 is needed by (installed)
> cyrus-sasl-gssapi-2.1.21-10.i386
> >        libcom_err.so.2 is needed by (installed) pam_krb5-2.2.6-2.2.i386
> >        libuuid.so.1 is needed by (installed) apr-1.2.2-7.2.i386
> 
> Well, I guess it is needed...is the repo broken ?  Its been like this for a week
> or so.
> 
> -Steve

I encountered the same problem.
In order to solve this problem I:
A. Removed all the i386/i686 packages.
B. yum'ed to rawhide.
C. Reinstalled the OpenOffice i386 packages. (which installed most of
the original i386 packages.)

Gilboa



From kaspars at os.lv  Mon Mar 13 14:05:24 2006
From: kaspars at os.lv (Kaspars)
Date: Mon, 13 Mar 2006 16:05:24 +0200
Subject: My FC5 test3 problems...
Message-ID: <44157C24.3090603@os.lv>


Hi all,

My broken things:

* From panel, web is not opening. I copy command to command line:
$htmlview %u
Error: No running window found

* Thunderbird is lost icon, what can see, when you are switching with 
alt-tab, or when it is full screen in workspace windows...

* My compiled mplayer anymore not stoping XScreenSaver whyle playing... 
something changed? commpiled from source xmms can`t open his mpeg123 codec.

* My biggest concerns - fonts and Latvian typing... Gnome and KDE system 
fonts are not showing ok on system, and keyboard switcher did not swith 
Lva, but in command line:
[root at p ~]# setxkbmap lv apostrophe
worked ok!

  Sorry, if I did`t techical correctly explayn my problems in deep, if 
you need, I`d love to test more...

K.



From linux_4ever at yahoo.com  Mon Mar 13 14:16:37 2006
From: linux_4ever at yahoo.com (Steve G)
Date: Mon, 13 Mar 2006 06:16:37 -0800 (PST)
Subject: rawhide e2fsprogs & yum
In-Reply-To: <604aa7910603130550g6115557em7e08b8946e26a372@mail.gmail.com>
Message-ID: <20060313141637.1496.qmail@web51507.mail.yahoo.com>


>> Well, I guess it is needed...is the repo broken ?  Its been like this for a
>>week or so.
>
>the 32bit tree has e2fsprogs-libs-1.38-12 currently.

Its the main package...not the libs.

[root at dhcp83-35 ~]# rpm -e e2fsprogs-1.38-1.i386
error: Failed dependencies:

locate + rpm -qf does show that /lib/libcom_err.so.2 is owned by
e2fsprogs-1.38-1.i386.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From mailinglists at erwinrol.com  Mon Mar 13 14:16:16 2006
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Mon, 13 Mar 2006 15:16:16 +0100
Subject: rawhide e2fsprogs & yum
In-Reply-To: <604aa7910603130550g6115557em7e08b8946e26a372@mail.gmail.com>
References: <20060313133352.83245.qmail@web51507.mail.yahoo.com>
	<604aa7910603130550g6115557em7e08b8946e26a372@mail.gmail.com>
Message-ID: <1142259376.2612.17.camel@xpc.home.erwinrol.com>

On Mon, 2006-03-13 at 08:50 -0500, Jeff Spaleta wrote:
> On 3/13/06, Steve G <linux_4ever at yahoo.com> wrote:
> > Well, I guess it is needed...is the repo broken ?  Its been like this for a week
> > or so.
> 
> the 32bit tree has e2fsprogs-libs-1.38-12 currently.
> 
> and the 32bit version is in the rawhide tree... so I don't understand
> your problem...unless your yum is hitting a stale mirror.
> 

The problem seems (I had it too), that yum/rpm are not able to do the
update, because there is a collision between a man file from the two
versions. I used rpm -e --nodeps to remove the old version and than used
yum to install the new version. Without it yum wouldn't want to update
it. Since i didn't think much of it, i never bothered to report it.

But yes i have seen that error to, and i didn't use a mirror, so it is
very unlikely an stale mirror problem. 

- Erwin




From mailinglists at erwinrol.com  Mon Mar 13 14:29:14 2006
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Mon, 13 Mar 2006 15:29:14 +0100
Subject: rawhide e2fsprogs & yum
In-Reply-To: <20060313141637.1496.qmail@web51507.mail.yahoo.com>
References: <20060313141637.1496.qmail@web51507.mail.yahoo.com>
Message-ID: <1142260154.2612.21.camel@xpc.home.erwinrol.com>

On Mon, 2006-03-13 at 06:16 -0800, Steve G wrote:
> >> Well, I guess it is needed...is the repo broken ?  Its been like this for a
> >>week or so.
> >
> >the 32bit tree has e2fsprogs-libs-1.38-12 currently.
> 
> Its the main package...not the libs.

Maybe the manpage was moved from the main package in 1.38-1 to the lib
in 1.38-11. And 1.38-12 also has it in the lib so now the update
collides with the left over (how ever that happened) 1.38-1 package.

just a guess.

- Erwin

> [root at dhcp83-35 ~]# rpm -e e2fsprogs-1.38-1.i386
> error: Failed dependencies:

> locate + rpm -qf does show that /lib/libcom_err.so.2 is owned by
> e2fsprogs-1.38-1.i386.

--nodeps worked for me (of course you need to quickly install the new
version, cause else the programs that need the library will fail).

- Erwin




From jspaleta at gmail.com  Mon Mar 13 14:41:01 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 13 Mar 2006 09:41:01 -0500
Subject: rawhide e2fsprogs & yum
In-Reply-To: <20060313141637.1496.qmail@web51507.mail.yahoo.com>
References: <604aa7910603130550g6115557em7e08b8946e26a372@mail.gmail.com>
	<20060313141637.1496.qmail@web51507.mail.yahoo.com>
Message-ID: <604aa7910603130641q11c3b533p6fe2a3d78e918cd9@mail.gmail.com>

On 3/13/06, Steve G <linux_4ever at yahoo.com> wrote:
> locate + rpm -qf does show that /lib/libcom_err.so.2 is owned by
> e2fsprogs-1.38-1.i386.

then thats the problem... the most recent packages
/lib/libcom_err.so.2 is owned by the -libs.

So the problem you are seeing is the result of shifts inside the
development tree.  The current tree isn't broken, but you don't have a
clean update path.  I would imagine the only people seeing the problem
are testers. I expect anaconda upgrades from fc4 to work...but you
should probably test that scenario.

-jef



From vonbrand at inf.utfsm.cl  Sat Mar 11 00:24:24 2006
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Fri, 10 Mar 2006 21:24:24 -0300
Subject: Fedora Core 5 Status 
In-Reply-To: Message from Philippe Rigault <prigault@oricom.ca> of "Fri,
	10 Mar 2006 12:20:33 CDT." <200603101220.33585.prigault@oricom.ca> 
Message-ID: <200603110024.k2B0OOws004997@laptop11.inf.utfsm.cl>

Philippe Rigault <prigault at oricom.ca> wrote:

> > Due to circumstances outside of our control, we're going to be unable to
> > keep to the scheduled date of March 15th for the release of FC5 and
> > instead are going to have to make the release date Monday, March 20th.
> > While unfortunate in some ways, this gives us the opportunity to pull in
> > the final GNOME 2.14 tarballs which should be available on Monday
> > assuming the changes are suitably minor.  

> I have two problems with this:

> The first is that FC5 will be released essentially _untested_ after two
> of its main components were upgraded to a stable release after FC5test3:
>  - gcc 4.1.0
>  - glibc-2.4

And the kernel has been updated almost daily, but that doesn't count?

> It could be argued that FC5 will be _released_ with a stable release of its 
> compiler and C library, but not that this had been tested.

Can't have it both ways (fix bugs timely + ultra-tested software only)...

> The second goes the same way, arguing that if test3 is the latest test 
> release, any new major component should _not_ be upgraded to a new release, 
> which is particularly true for a big beast like GNOME.

There we could perhaps agree... but presumably the changes between the
current one and the final release are minor, bugfixes only?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From vonbrand at inf.utfsm.cl  Sun Mar 12 19:12:07 2006
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Sun, 12 Mar 2006 15:12:07 -0400
Subject: The repository scoring problem - a proposal 
In-Reply-To: Message from Ralf Ertzinger <fedora@camperquake.de> 
	of "Sun, 12 Mar 2006 16:21:01 +0100." <20060312162101.3a36a492@lain> 
Message-ID: <200603121912.k2CJC7kW007150@laptop11.inf.utfsm.cl>

Ralf Ertzinger <fedora at camperquake.de> wrote:
> Every one in a while the problem of repository scoring comes up (maybe
> under a different name, but I chose this one): The wish of users to
> give different RPM repositories different "rights" with respect to the
> packages that can be installed from the various sources, mostly to prevent
> third party repositories from replacing packages installed by the core
> operating system.

Then don't use 3rd party repositories...

A repository is not "just" a collection of packages that can be installed
on Foo, it is a system of packages built and tested for use together on
Foo. You /can't/ just mix-and-match at will.

[...]

> I hereby propose a diffenent path. Do not add repository information to
> the RPM files (or do it anyway, it is useful information after all, just
> not suited for the problem at hand) but change the RPM libraries to enable
> programs installing packages (be it RPM itself, yum, smart or whatever)
> to add metadata to the installed package. The installing program knows
> best where it got the package it is just installing, after all, so
> it can add the information itself.
> 
> This has the following pros and cons:
> 
> Pro:
> * If implemented, it works right now (except for packages already installed,
>   but other approaches have that problem, too)
> * It requires no work on the behalf of the packagers
> * It is stable against repositories changing their repository id (if
>   such a field is added, see above)

No, it isn't. Can't be, really.

* It handles packages moving among repositories (i.e., from Extras to Core)

> Cons:
> * It may not be stable against certain configuration changes in
>   the package managing program (if, for example, yum uses it's internal
>   repositoryid to tag packages a change to that id would create
>   some problems)
> * Using different programs to manage your packages at the same time will
>   probably not work, since they will not recognize the tags written by
>   each other.

Need a common format for that anyway,

> * I do not know if such a change can be made while retaining backwards
>   compatibility to older RPM versions (if this is desired, that is)

You are proposing a scheme that doesn't touch the RPM format itself, so I
don't see how this would enter here.

* What if a package exists with the same name in different repositories?
  Using one set of (coordinated) repositories prevents that today (and that
  is exactly the problem you are trying to solve...)
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From aph at redhat.com  Mon Mar 13 15:54:06 2006
From: aph at redhat.com (Andrew Haley)
Date: Mon, 13 Mar 2006 15:54:06 +0000
Subject: Fedora Core 5 Status 
In-Reply-To: <200603110024.k2B0OOws004997@laptop11.inf.utfsm.cl>
References: <prigault@oricom.ca> <200603101220.33585.prigault@oricom.ca>
	<200603110024.k2B0OOws004997@laptop11.inf.utfsm.cl>
Message-ID: <17429.38302.649821.559301@zapata.pink>

Horst von Brand writes:
 > Philippe Rigault <prigault at oricom.ca> wrote:
 > 
 > > > Due to circumstances outside of our control, we're going to be
 > > > unable to keep to the scheduled date of March 15th for the
 > > > release of FC5 and instead are going to have to make the
 > > > release date Monday, March 20th.  While unfortunate in some
 > > > ways, this gives us the opportunity to pull in the final GNOME
 > > > 2.14 tarballs which should be available on Monday assuming the
 > > > changes are suitably minor.
 > 
 > > I have two problems with this:
 > 
 > > The first is that FC5 will be released essentially _untested_ after two
 > > of its main components were upgraded to a stable release after FC5test3:
 > >  - gcc 4.1.0
 > >  - glibc-2.4
 > 
 > And the kernel has been updated almost daily, but that doesn't
 > count?
 > 
 > > It could be argued that FC5 will be _released_ with a stable
 > > release of its compiler and C library, but not that this had been
 > > tested.
 > 
 > Can't have it both ways (fix bugs timely + ultra-tested software only)...

Indeed.  The alternative is to re-start the test period whenever we
make a minor revision to critical packages.  I can't see anyone really
wanting that.

 > > The second goes the same way, arguing that if test3 is the latest
 > > test release, any new major component should _not_ be upgraded to
 > > a new release, which is particularly true for a big beast like
 > > GNOME.
 > 
 > There we could perhaps agree... but presumably the changes between
 > the current one and the final release are minor, bugfixes only?

Hopefully.

Andrew.



From fedora at camperquake.de  Mon Mar 13 17:21:28 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 13 Mar 2006 18:21:28 +0100
Subject: The repository scoring problem - a proposal
In-Reply-To: <200603121912.k2CJC7kW007150@laptop11.inf.utfsm.cl>
References: <20060312162101.3a36a492@lain>
	<200603121912.k2CJC7kW007150@laptop11.inf.utfsm.cl>
Message-ID: <20060313182128.4b50c242@nausicaa.camperquake.de>

Hi.

Horst von Brand <vonbrand at inf.utfsm.cl> wrote:

> > * I do not know if such a change can be made while retaining backwards
> >   compatibility to older RPM versions (if this is desired, that is)
> 
> You are proposing a scheme that doesn't touch the RPM format itself, so
> I don't see how this would enter here.

The information has to be stored somewhere on disk after all. I do not
know enough about how RPM splits the information into it's various databases
to decide where this new information would go (and if it would affect
older RPM versions)

> * What if a package exists with the same name in different repositories?
>   Using one set of (coordinated) repositories prevents that today (and
> that is exactly the problem you are trying to solve...)

Yes, if there were no overlaps between repositories all of this would be
a non-issue.

-- 
The Law of Motivation
        Creativity is great, but plagiarism is faster.



From gianluca.cecchi at gmail.com  Mon Mar 13 17:56:35 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Mon, 13 Mar 2006 18:56:35 +0100
Subject: match between gnome 2.14 "manifesto" and upcoming fc5 features
Message-ID: <561c252c0603130956o3f72bf51v18c4bd14400b764d@mail.gmail.com>

hello,
as one of the core features of fc5 will be final gnome 2.14, I tried
to match up what described at gnome.org  "A look at Gnome 2.14" (see 
http://www.gnome.org/%7Edavyd/gnome-2-14/), that seems to me a sort of
manifesto of the new functionalities a user will find in upcoming
gnome 2.14, with fc5 at this point.
Take it as a cue, to eventually refine release notes, so that users
that expect fc5 <--> gnome 2.14 are aware of fc5 components.
Gianluca

- speed king
   - gslice timings: unable to try: anyone is able to tell me how to bench this?
   - gnome terminal performance: it is stated 1 second, while I'm not
able to go under 6.5...

- locked out
description of pessulus (lock down editor for gnome)
I could not find it neither in core nor in extras at this moment. Will
fedora include a comparative component?

- Push it
Admin suite sabayon, to create profiles for user and groups
found in fc5 extras but unable to install it due to the fact that
[root at pevit00 RPMS]# yum install sabayon-admin
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
extras-development                                                   [1/2]
development                                                          [2/2]
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package sabayon-admin.x86_64 0:2.12.3-3 set to be updated
---> Package sabayon-admin.noarch 0:0.18-1 set to be updated
--> Running transaction check
--> Processing Dependency: xorg-x11-Xnest for package: sabayon-admin
--> Finished Dependency Resolution
Error: Missing Dependency: xorg-x11-Xnest is needed by package sabayon-admin

and in core the Xnest server is named now xorg-x11-server-Xnest

- Searching for love
it is ok, but recent decision is that beagled is disabled by default.
Running search in nautilus I get unable to contact beagle daemon.
manually starting beagled is ok....

- Help!
Ok for x86, while when using search in yelp for x86_64 I have it
crashed (I'm going to open a bugzilla number) with the messages:
(yelp:5244): GLib-GObject-WARNING **: invalid unclassed pointer in
cast to `BeagleRequest'

(yelp:5244): GLib-GObject-CRITICAL **: g_type_instance_get_private:
assertion `instance != NULL && instance->g_class != NULL' failed

Same version yelp-2.13.6-1 for both x86 and x86_64

- Message to my girl
ekiga is here. Not tested yet

- Look through any window
. windows edge resistance: It seems to me that is not in place
. multimonitor support optimizations: not tested
. remote X windows: it seems ok; I have at the end of the title of
remote  X windows the label "(on otherhost.otherdomain.com)"
. metacity composite manager:
work in progress with details at
http://fedoraproject.org/wiki/RenderingProject/aiglx
but it is stated as an initial feature disabled by default also in gnome itself

- You've Got The Whole World In Your Hand
deskbar-applet is at the moment in extras. Ok on x86; it doesn't work
for me on x86_64 (I'm going to open bugzilla point): the icon stays
grey and I'm not able to wwrite in it...

- Changes
fast user switching: I have not been able to activate it; anyone can
give help if the feature is here?

- Evolution
OK. I'm testing it against exchange 2003 and it seems quite more
stable and performant in respect with previous versions.

- Writing montage
it seems ok

- Sharp dressed man
OK

- daysleeper
ok

- It's only sound
ok for gstreamer 0.10 part

- Choices
OK

- Do You See What I See?
Upcoming.. notification framework seems already in place, for example
with low disk space and battery on laptops.



From janina at rednote.net  Mon Mar 13 18:14:22 2006
From: janina at rednote.net (Janina Sajka)
Date: Mon, 13 Mar 2006 13:14:22 -0500
Subject: 'everything' install option in FC5test1
Message-ID: <20060313181422.GA13846@rednote.net>

The grub documentation includes provides kernel failover provisions, but
these don't appear to work.

http://www.gnu.org/software/grub/manual/html_node/Making-your-system-robust.html#Making-your-system-robust

Should I expect this to work? Is there some other mechanism to boot a
different kernel just once--on the next boot?

Associated, the docs say there should be a grub-set-default command
which is also not present.

What's the story with these issues?

Sorry if I should be raising this elsewhere.

-- 

Janina Sajka				Phone: +1.240.715.1272
Partner, Capital Accessibility LLC	http://www.CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://www.ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org



From janina at rednote.net  Mon Mar 13 18:15:20 2006
From: janina at rednote.net (Janina Sajka)
Date: Mon, 13 Mar 2006 13:15:20 -0500
Subject: Grub Fallback -- Is it for real?
Message-ID: <20060313181520.GA13830@rednote.net>

The grub documentation includes provides kernel failover provisions, but
these don't appear to work.

http://www.gnu.org/software/grub/manual/html_node/Making-your-system-robust.html#Making-your-system-robust

Should I expect this to work? Is there some other mechanism to boot a
different kernel just once--on the next boot?

Associated, the docs say there should be a grub-set-default command
which is also not present.

What's the story with these issues?

Sorry if I should be raising this elsewhere.

-- 

Janina Sajka				Phone: +1.240.715.1272
Partner, Capital Accessibility LLC	http://www.CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://www.ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org



From jfrieben at freesurf.fr  Mon Mar 13 18:47:17 2006
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Mon, 13 Mar 2006 19:47:17 +0100 (CET)
Subject: System clock speedup with latest kernels
In-Reply-To: <20060313134926.49010.qmail@web60720.mail.yahoo.com>
References: <20060313134926.49010.qmail@web60720.mail.yahoo.com>
Message-ID: <60952.194.94.224.254.1142275637.squirrel@jose.freesurf.fr>

Right,

the main implication of running in "noapic" mode is a performance hit, as
interrupts are not handled as efficiently. For systems that are heavily
interrupt driven (includes those that have a lot of network traffic such as
web servers) this might be measurable. Nonetheless, the benefits of SMP
almost always outweigh this impact. You could try once with and once without
the "noapic" option to measure networking performance respectively.

Cheers,

-JF

> I'm glad to know this... but I am really worried about
> performance in this case, there is a lot of traffic
> between the web server (Apache/PHP) and the database
> server (Oracle 9.2.0.7) so "noapic" wouldn't be a
> viable workaround if it degrades performance.  Any
> advice about this?
>
> Thanks for your comments,
>
>
> -William
>




From jfrieben at freesurf.fr  Mon Mar 13 19:02:48 2006
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Mon, 13 Mar 2006 20:02:48 +0100 (CET)
Subject: match between gnome 2.14 &quot; manifesto&quot;
	and upcoming fc5 features
In-Reply-To: <561c252c0603130956o3f72bf51v18c4bd14400b764d@mail.gmail.com>
References: <561c252c0603130956o3f72bf51v18c4bd14400b764d@mail.gmail.com>
Message-ID: <62781.194.94.224.254.1142276568.squirrel@jose.freesurf.fr>

This test *must* depend on your actual hardware, so the value given has to
be taken with a grain of salt and is probably a lower bound. On my IBM
ThinkPad T23, the "gnome-terminal" benchmark takes more than a 1/2 a minute!
Of course, as indicated for 25x80 and fixed font.

>   bench this? - gnome terminal performance: it is stated 1 second,
>   while I'm not
> able to go under 6.5..




From paul at cypherpunks.ca  Mon Mar 13 18:37:31 2006
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 13 Mar 2006 19:37:31 +0100 (CET)
Subject: Grub Fallback -- Is it for real?
In-Reply-To: <20060313181520.GA13830@rednote.net>
References: <20060313181520.GA13830@rednote.net>
Message-ID: <Pine.LNX.4.63.0603131936020.21294@tla.xelerance.com>

On Mon, 13 Mar 2006, Janina Sajka wrote:

> The grub documentation includes provides kernel failover provisions, but
> these don't appear to work.
>
> http://www.gnu.org/software/grub/manual/html_node/Making-your-system-robust.html#Making-your-system-robust
>
> Should I expect this to work? Is there some other mechanism to boot a
> different kernel just once--on the next boot?
>
> Associated, the docs say there should be a grub-set-default command
> which is also not present.
>
> What's the story with these issues?

There is a mixup in grub versions and patches to the original grub. The
Fedora grub patches did not implement what teh grub docs on the website
describe. I ended up installing grub 0.9.7 from source nad then I do have
the grub-set-default and it all works fine.

Paul



From rdieter at math.unl.edu  Mon Mar 13 19:14:15 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 13 Mar 2006 13:14:15 -0600
Subject: Grub Fallback -- Is it for real?
In-Reply-To: <20060313181520.GA13830@rednote.net>
References: <20060313181520.GA13830@rednote.net>
Message-ID: <4415C487.7@math.unl.edu>

Janina Sajka wrote:
> The grub documentation includes provides kernel failover provisions, but
> these don't appear to work.
> 
> http://www.gnu.org/software/grub/manual/html_node/Making-your-system-robust.html#Making-your-system-robust
> 
> Should I expect this to work? 
...
> Is there some other mechanism to boot a
> different kernel just once--on the next boot?

http://www.gnu.org/software/grub/manual/html_node/Booting-once_002donly.html

(Haven't tried it myself yet)

-- Rex



From igorm5 at vip.hr  Mon Mar 13 19:19:47 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Mon, 13 Mar 2006 20:19:47 +0100
Subject: [OT] Happy Birthday Jesse Keating !!!
Message-ID: <4415C5D3.8010002@vip.hr>

Hapy Birthday To You
Hapy Birthday To You
Hapy Birthday Dear Jesse
Hapy Birthday To You

Cheers mate!	;-)

-- 
Igor Jagec



From nicolas.mailhot at laposte.net  Mon Mar 13 19:25:01 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 13 Mar 2006 20:25:01 +0100
Subject: Grub Fallback -- Is it for real?
In-Reply-To: <Pine.LNX.4.63.0603131936020.21294@tla.xelerance.com>
References: <20060313181520.GA13830@rednote.net>
	<Pine.LNX.4.63.0603131936020.21294@tla.xelerance.com>
Message-ID: <1142277902.10342.18.camel@rousalka.dyndns.org>

Le lundi 13 mars 2006 ? 19:37 +0100, Paul Wouters a ?crit :
> On Mon, 13 Mar 2006, Janina Sajka wrote:
> 
> > The grub documentation includes provides kernel failover provisions, but
> > these don't appear to work.
> >
> > http://www.gnu.org/software/grub/manual/html_node/Making-your-system-robust.html#Making-your-system-robust
> >
> > Should I expect this to work? Is there some other mechanism to boot a
> > different kernel just once--on the next boot?
> >
> > Associated, the docs say there should be a grub-set-default command
> > which is also not present.
> >
> > What's the story with these issues?
> 
> There is a mixup in grub versions and patches to the original grub. The
> Fedora grub patches did not implement what teh grub docs on the website
> describe. I ended up installing grub 0.9.7 from source nad then I do have
> the grub-set-default and it all works fine.

The fallback directive worked just fine last time I tested it.
The problem with Fedora is the grubby kernel scripts always remove it
from grub.conf.

Regards,

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

From gianluca.cecchi at gmail.com  Mon Mar 13 19:31:47 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Mon, 13 Mar 2006 20:31:47 +0100
Subject: match between gnome "manifesto" and upcoming fc5 features
Message-ID: <561c252c0603131131t70947148i698082a254ba8d65@mail.gmail.com>

On dual athlon MP 2200+ (1800): 5.6 secs
On PIV 2.8GHz: 6.5
On laptop Dell C640 (PIV Mob 1.8GHz): 10.2

It is strange nevertheless to say 1 sec... a typo or an overestimating..



From chitlesh at fedoraproject.org  Mon Mar 13 19:54:01 2006
From: chitlesh at fedoraproject.org (Chitlesh GOORAH)
Date: Mon, 13 Mar 2006 20:54:01 +0100
Subject: [OT] Happy Birthday Jesse Keating !!!
In-Reply-To: <4415C5D3.8010002@vip.hr>
References: <4415C5D3.8010002@vip.hr>
Message-ID: <13dbfe4f0603131154q1be2d592m8020f77164759c2d@mail.gmail.com>

Happy Birthday, Jesse

Chitlesh
--
http://clunixchit.blogspot.com



From dax at gurulabs.com  Mon Mar 13 20:51:10 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Mon, 13 Mar 2006 13:51:10 -0700
Subject: Current rawhide Anaconda LVM crash
In-Reply-To: <1142218818.3501.4.camel@mentorng.gurulabs.com>
References: <1142218818.3501.4.camel@mentorng.gurulabs.com>
Message-ID: <1142283070.3473.25.camel@mentorng.gurulabs.com>

On Sun, 2006-03-12 at 20:00 -0700, Dax Kelson wrote:
> Just a FYI.
> 
> On my FC4, LVM using, laptop I created a LV to install rawhide on. I
> tried installing a March 11th 2006 rawhide tree. But ananconda bombed
> out when I tried to do a custom layout and tried to assign "/" to the
> previously created LV. This is 100% reproducible.
> 
> Bug filed with full Anaconda traceback and debug info:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185272

This has now been fixed for FC5 final. Thanks Jeremy!

For any interested parties it was Anaconda not handling PEs 128MB in
size. The legal PE values are hard coded apparently.

For FC6 the plan is to fix Anaconda to dynamically handle arbitrary PE
sizes.

Dax Kelson
Guru Labs

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

From jkeating at redhat.com  Mon Mar 13 20:58:50 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Mar 2006 15:58:50 -0500
Subject: [OT] Happy Birthday Jesse Keating !!!
In-Reply-To: <4415C5D3.8010002@vip.hr>
References: <4415C5D3.8010002@vip.hr>
Message-ID: <1142283530.20338.32.camel@ender>

On Mon, 2006-03-13 at 20:19 +0100, Igor Jagec wrote:
> Cheers mate!    ;-)

Heh!  In light of the slip and all that, I needed this.  Cheers!

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060313/ba6b1d19/attachment.sig>

From wtogami at redhat.com  Mon Mar 13 21:23:35 2006
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 13 Mar 2006 16:23:35 -0500
Subject: Grub Fallback -- Is it for real?
In-Reply-To: <20060313181520.GA13830@rednote.net>
References: <20060313181520.GA13830@rednote.net>
Message-ID: <4415E2D7.2050606@redhat.com>

Janina Sajka wrote:
> 
> Should I expect this to work? Is there some other mechanism to boot a
> different kernel just once--on the next boot?

http://togami.com/~warren/guides/remoteraidcrazies/
My guide here has an example of using grub's savedefault --default X 
--once directives in order to specify a kernel to boot next.  It tries 
to boot that kernel.  If you reboot again, it falls back to the first 
listed kernel in grub.conf.

In order to use this type of fallback, you need to move your "known 
good" kernel to be in the first position.  Then change 
/boot/grub/grub.conf so "default=saved".  Then savedefault --default X 
--once chooses a kernel specified by X, which begins counting at zero.

I personally use savedefault --default X --once on my dedicated server 
where I have no physical access, but I do have remote power cycling 
capability.  This way I can reboot into an experimental kernel, and 
trigger a reboot into the original kernel if it got "stuck" during bootup.

Another option is to use "panic=X" where X is a number of seconds.  This 
triggers an automatic reboot if the kernel panics.  It doesn't always 
work, but might be useful in some cases where you don't have physical 
access to the box.  I personally don't use panic=X anymore after I 
gained remote power cycling capability.

Warren Togami
wtogami at redhat.com



From rodd at clarkson.id.au  Mon Mar 13 21:56:12 2006
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Tue, 14 Mar 2006 08:56:12 +1100
Subject: SD/MMC Support (was Re: Hotplug: no more fstab entries)
In-Reply-To: <20060306110055.2d506a15@python2>
References: <20060222153244.002ea18c@dhcp05.addix.net>
	<43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca>
	<604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com>
	<20060223103910.2d9874ae@dhcp05.addix.net>
	<1140698854.3633.1.camel@daxter.boston.redhat.com>
	<20060223141925.5a085d71@dhcp05.addix.net>
	<1140701508.3633.9.camel@daxter.boston.redhat.com>
	<1141333979.2793.7.camel@localhost.localdomain>
	<20060306110055.2d506a15@python2>
Message-ID: <1142286972.2667.19.camel@localhost.localdomain>

On Mon, 2006-03-06 at 11:00 +0100, Matthias Saou wrote:
> Rodd Clarkson wrote :
> 
> > Would you like to explain to the masses (or maybe just me) how you got
> > SD/MMC support working in Fedora.
> > 
> > I notice that 'modprobe mmc_block' now installs the modules needed, but
> > beyond this it's not doing anything.
> > 
> > Doesn't notice the insertion of cards into the reader (which lspci
> > reports as a):
> > 
> > 03:01.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)
> > 
> > Nothing shows up in /dev
> > 
> > Nothing mounts, that's for certain.
> > 
> > This isn't the plug N play I'm getting used to in Fedora, so what do I
> > need to do.  It would be great to have support for SD/MMC in FC5 and it
> > certainly looks like we're close.
> 
> Well, these might be separate issues, as many USB connected SD/MMC readers
> work by default (only with unencrypted media, I guess), whereas the device
> you list reminds me a lot of the internal reader I have in my Dell X1
> laptop, which simply doesn't work with Linux, from the lack of a device
> driver... it's a quite different device (PCI connected, not USB).

Yes, I've got one of these in my Dell Inspiron 9300 at the moment.

Fortunately for us, a driver has been developed and has been submitted
for inclusion in the kernel.  It's currently in -mm and should make it
into 2.6.16 or 2.6.17.

Personally, I'd love to see it included as a patch into the kernel, but
I know Dave's perspective on it and respect that position.  I also know
that occasionally Dave makes exceptions to the rule, so while I hoped
that this might be one of them, I'm also not going to start holding my
breath.


Rodd

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From dax at gurulabs.com  Mon Mar 13 21:55:25 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Mon, 13 Mar 2006 14:55:25 -0700
Subject: Warning - Maxtor SATA II and Nvidia nforce4
Message-ID: <1142286925.3473.58.camel@mentorng.gurulabs.com>

Short version
==============
Nvidia Nforce4 chipset with Maxtor SATA II drives with certain firmware
revisions cause data corruption and system instability.

This was acknowledged just in the last few weeks, see:

http://maxtor.custhelp.com/cgi-bin/maxtor.cfg/php/enduser/std_adp.php?p_faqid=2685


Long version
=============

About a year ago I got a new home uber system all decked out. I have
Fedora installed plus small Windows install for gaming.

AMDFX-55
Nforce4 SLI motherboard
2GB RAM
Nvidia 6800GT PCIe x2 in SLI mode
300GB Maxtor SATA II HDD x2 (model 6B300S with firmware BANC1B70)

Off and on I have experienced the following problems:

* kernel panics
* freezes
* insta-reboots
* on-board RAID (nforce fake raid) de-syncing
* LCD blinking on and off (most common symptom for me)
* segfaults and application crashes

The problems were not continuous and would seemingly erratically
appear. 

My memory tested fine with memtest86+ over repeated tests the past 12
months. I RMA'd my video cards and got a new motherboard. I was
contemplating swapping my CPU when I finally did a Google search on
"Maxtor nforce4" and my eyes were opened. Pages and pages of posts in
hundreds of different forums. Honestly, I had a sense of relief that my
culprit was identified.

I'm going to go review my bug reports and close any that could possibly
be related to this hardware problem.

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

From maccy at maccomms.co.uk  Mon Mar 13 21:59:58 2006
From: maccy at maccomms.co.uk (Maccy)
Date: Mon, 13 Mar 2006 21:59:58 +0000 (GMT)
Subject: simple script
Message-ID: <Pine.LNX.4.63.0603132156140.9552@titanic.qubiq.net>


Does anyone have a simple perl or shell script that will run a set of 
commands on a number of machines?

For example install a perl cpan module on 50 machines, listed in a file.

I've very much a beginner when it comes to shell scripting.

Many thanks in advance!

Mark



From michael.favia at insitesinc.com  Mon Mar 13 22:05:33 2006
From: michael.favia at insitesinc.com (Michael Favia)
Date: Mon, 13 Mar 2006 16:05:33 -0600
Subject: simple script
In-Reply-To: <Pine.LNX.4.63.0603132156140.9552@titanic.qubiq.net>
References: <Pine.LNX.4.63.0603132156140.9552@titanic.qubiq.net>
Message-ID: <4415ECAD.5050101@insitesinc.com>

Maccy wrote:
> 
> Does anyone have a simple perl or shell script that will run a set of 
> commands on a number of machines?

Sorry, but this is pretty off topic. Please find help elsewhere. -mf

-- 
Michael Favia          michael.favia at insitesinc.com
Insites Incorporated  http://michael.insitesinc.com



From orion at cora.nwra.com  Mon Mar 13 22:30:24 2006
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 13 Mar 2006 15:30:24 -0700
Subject: No more selinux-policy-*-sources
Message-ID: <dv4rq0$csu$1@sea.gmane.org>

I there some docs (FAQ/ReleaseNotes?) that describe how to make changes 
to policy in FC5?



From jkeating at redhat.com  Mon Mar 13 22:38:43 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 13 Mar 2006 17:38:43 -0500
Subject: rawhide report: 20060311 changes
In-Reply-To: <200603110941.k2B9fHRf022009@porkchop.devel.redhat.com>
References: <200603110941.k2B9fHRf022009@porkchop.devel.redhat.com>
Message-ID: <1142289523.20338.38.camel@ender>

On Sat, 2006-03-11 at 04:41 -0500, Build System wrote:
> 
> Updated Packages: 

So uh... yeah.  This seems to have gotten stuck in a mail queue
somewhere.  Don't panic (:

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060313/f0c337af/attachment.sig>

From janina at rednote.net  Mon Mar 13 23:36:17 2006
From: janina at rednote.net (Janina Sajka)
Date: Mon, 13 Mar 2006 18:36:17 -0500
Subject: Grub Fallback -- Is it for real?
In-Reply-To: <4415E2D7.2050606@redhat.com>
References: <20060313181520.GA13830@rednote.net> <4415E2D7.2050606@redhat.com>
Message-ID: <20060313233617.GB13846@rednote.net>

Warren Togami writes:
> Janina Sajka wrote:
> >
> >Should I expect this to work? Is there some other mechanism to boot a
> >different kernel just once--on the next boot?
> 
> http://togami.com/~warren/guides/remoteraidcrazies/
> My guide here has an example of using grub's savedefault --default X 
> --once directives in order to specify a kernel to boot next.  It tries 
> to boot that kernel.  If you reboot again, it falls back to the first 
> listed kernel in grub.conf.
> 
Hmmm, this syntax looks different from that in the grub docs on gnu.org.
Thanks for forwarding this. I will study and see what I can do with it.
I am precisely in the position of needing to manage a server which I
cannot get to physically.

Janina

> In order to use this type of fallback, you need to move your "known 
> good" kernel to be in the first position.  Then change 
> /boot/grub/grub.conf so "default=saved".  Then savedefault --default X 
> --once chooses a kernel specified by X, which begins counting at zero.
> 
> I personally use savedefault --default X --once on my dedicated server 
> where I have no physical access, but I do have remote power cycling 
> capability.  This way I can reboot into an experimental kernel, and 
> trigger a reboot into the original kernel if it got "stuck" during bootup.
> 
> Another option is to use "panic=X" where X is a number of seconds.  This 
> triggers an automatic reboot if the kernel panics.  It doesn't always 
> work, but might be useful in some cases where you don't have physical 
> access to the box.  I personally don't use panic=X anymore after I 
> gained remote power cycling capability.
> 
> 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

-- 

Janina Sajka				Phone: +1.240.715.1272
Partner, Capital Accessibility LLC	http://www.CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://www.ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org



From ivazquez at ivazquez.net  Tue Mar 14 00:48:39 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Mon, 13 Mar 2006 19:48:39 -0500
Subject: match between gnome 2.14 "manifesto" and upcoming fc5 features
In-Reply-To: <561c252c0603130956o3f72bf51v18c4bd14400b764d@mail.gmail.com>
References: <561c252c0603130956o3f72bf51v18c4bd14400b764d@mail.gmail.com>
Message-ID: <1142297319.22634.1.camel@ignacio.lan>

On Mon, 2006-03-13 at 18:56 +0100, Gianluca Cecchi wrote:
> - You've Got The Whole World In Your Hand
> deskbar-applet is at the moment in extras. Ok on x86; it doesn't work
> for me on x86_64 (I'm going to open bugzilla point): the icon stays
> grey and I'm not able to wwrite in it...

Is this with 2.14.0 or the previous build?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060313/55ec0de8/attachment.sig>

From pjones at redhat.com  Tue Mar 14 02:17:59 2006
From: pjones at redhat.com (Peter Jones)
Date: Mon, 13 Mar 2006 21:17:59 -0500
Subject: Grub Fallback -- Is it for real?
In-Reply-To: <20060313233617.GB13846@rednote.net>
References: <20060313181520.GA13830@rednote.net>
	<4415E2D7.2050606@redhat.com>  <20060313233617.GB13846@rednote.net>
Message-ID: <1142302680.7020.17.camel@vroomfondel.internal.datastacks.com>

On Mon, 2006-03-13 at 18:36 -0500, Janina Sajka wrote:
> Warren Togami writes:
> > Janina Sajka wrote:
> > >
> > >Should I expect this to work? Is there some other mechanism to boot a
> > >different kernel just once--on the next boot?
> > 
> > http://togami.com/~warren/guides/remoteraidcrazies/
> > My guide here has an example of using grub's savedefault --default X 
> > --once directives in order to specify a kernel to boot next.  It tries 
> > to boot that kernel.  If you reboot again, it falls back to the first 
> > listed kernel in grub.conf.
> > 
> Hmmm, this syntax looks different from that in the grub docs on gnu.org.
> Thanks for forwarding this. I will study and see what I can do with it.
> I am precisely in the position of needing to manage a server which I
> cannot get to physically.
> 
> Janina

It is -- we've got a patch that implements this functionality, and we've
had it since before upstream had the ability to do this.  Nobody's filed
any bugs requesting the "new" way, and there's code using it, so we just
haven't migrated to the new way yet.

-- 
  Peter



From gianluca.cecchi at gmail.com  Tue Mar 14 05:20:55 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Tue, 14 Mar 2006 06:20:55 +0100
Subject: deskbar-applet on x86_64(was: Re: match between gnome 2.14
	"manifesto" and upcoming fc5 features)
Message-ID: <561c252c0603132120g623c908ardc56dc8e5e54a565@mail.gmail.com>

On Mon, 13 Mar 2006 19:48:39 -0500 Ignacio Vazquez-Abrams wrote:
> Is this with 2.14.0 or the previous build?
It is with deskbar-applet-2.13.91-3.fc5 downloaded on 13th of March
but I'm seeing that 2.14 was released and now it is available also in
Fedora Extras: I'm going to update and feedback.
I suggest deskbar screencast (it is in ubuntu...) if one wants to see it at work:
http://browserbookapp.sourceforge.net/deskbar-2-14-screencast.html



From buildsys at redhat.com  Tue Mar 14 08:09:05 2006
From: buildsys at redhat.com (Build System)
Date: Tue, 14 Mar 2006 03:09:05 -0500
Subject: rawhide report: 20060314 changes
Message-ID: <200603140809.k2E895Gc023342@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-11.0.3-1
-----------------
* Mon Mar 13 2006 Jeremy Katz <katzj at redhat.com> - 11.0.3-1
- Check for none in size test (clumens, #185172)
- Fix hard drive install (clumens)
- Don't clobber network on upgrade (pnasrat, #183203)
- Fix some simple syntax errors (#185275)
- Allow 128M PE sizes (#185272)

* Thu Mar 09 2006 Jeremy Katz <katzj at redhat.com> - 11.0.2-1
- adjust blkid location
- don't try to download packages being erased (clumens, #184531)
- don't show group selection on upgrade (pnasrat, #184528)
- don't make file conflicts kill upgrades (pnasrat, #184461)

atk-1.11.3-1
------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 1.11.3-1
- Update to 1.11.3

bug-buddy-1:2.14.0-1
--------------------
* Sun Mar 12 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

control-center-1:2.14.0-1
-------------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

eel2-2.14.0-1
-------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0
- Drop upstreamed patch

eog-2.14.0-1
------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

file-roller-2.14.0-1
--------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

firefox-1.5.0.1-9
-----------------
* Sat Mar 11 2006 Christopher Aillon <caillon at redhat.com> - 1.5.0.1-9
- Add a notice to the about dialog denoting this is a pango enabled build.
- Tweak the user agent denoting this is a pango enabled build.

gail-1.8.11-1
-------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 1.8.11-1
- Update to 1.8.11

* Fri Mar 10 2006 Matthias Clasen <mclasen at redhat.com> - 1.8.10-2
- Fix a treeview crash

gconf-editor-2.14.0-1
---------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

gdm-1:2.14.0-1
--------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 1:2.14.0-1
- Update to 2.14.0

* Tue Mar 07 2006 Ray Strode <rstrode at redhat.com> - 1:2.13.0.9-4
- Follow Solaris's lead and default to AlwaysRestartServer=True
  (may work around bug 182957)

* Mon Mar 06 2006 Ray Strode <rstrode at redhat.com> - 1:2.13.0.9-3
- migrate users with baseXsession=/etc/X11/gdm/Xsession to
  /etc/X11/xinit/Xsession

gedit-1:2.14.0-1
----------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 2.14.0-1
- Update to 2.14.0

gnome-applets-1:2.14.0-1
------------------------
* Sun Mar 12 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- update to 2.14.0

gnome-doc-utils-0.6.0-1
-----------------------
* Sun Mar 12 2006 Ray Strode <rstrode at redhat.com> - 0.6.0-1
- Update to 0.6.0

gnome-games-1:2.14.0-1
----------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

gnome-keyring-0.4.9-1
---------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 0.4.9-1
- Update to 0.4.9

* Mon Feb 27 2006 Matthias Clasen <mclasen at redhat.com> - 0.4.8-1
- Update to 0.4.8

* Mon Feb 13 2006 Matthias Clasen <mclasen at redhat.com> - 0.4.7-1
- Update to 0.4.7

gnome-keyring-manager-2.14.0-1
------------------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 2.14.0-1
- Update to 2.14.0

gnome-mag-0.12.4-1
------------------
* Mon Mar 13 2006 Matthias Clasen  <mclasen at redhat.com> 0.12.4-1
- Update to 0.12.4

gnome-python2-2.12.4-1
----------------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.12.4-1
- Update to 2.12.4

gnome-python2-extras-2.14.0-1
-----------------------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.de> 2.14.0-1
- Update to 2.14.0

gnome-screensaver-2.14.0-1
--------------------------
* Mon Mar 13 2006 Matthias Clasen  <mclasen at redhat.com> 2.14.0-1
- Update to 2.14.0

gnome-session-2.14.0-1
----------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

gnome-system-monitor-2.14.0-1
-----------------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 2.14.0-1
- Update to 2.14.0

gnome-terminal-2.14.0-1
-----------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

gnome-user-docs-2.14.0-1
------------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 2.14.0-1
- Update to 2.14.0

gnome-utils-1:2.14.0-3
----------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 2.14.0-3
- Update to zenity 2.14.0

* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 2.14.0-2
- Update to gcalctool 5.7.32

* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 2.14.0-1
- Update to gnome-utils 2.14.0
- Update to gucharmap 1.6.0

gnome-vfs2-2.14.0-1
-------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0
- Drop upstreamed patches

gnome-volume-manager-1.5.15-1
-----------------------------
* Sun Mar 12 2006 Ray Strode <rstrode at redhat.com> - 1.5.15-1
- update to 1.5.15

grub-0.97-5
-----------
* Mon Mar 13 2006 Peter Jones <pjones at redhat.com> - 0.97-5
- Fix merge error for "bootonce" patch (broken in 0.95->0.97 update)
- Get rid of the 0.97 "default" stuff, since it conflicts with our working
  method.

gtk2-2.8.15-1
-------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.8.15-1
- Update to 2.8.15
- Drop upstreamed patch

* Fri Mar 10 2006 Matthias Clasen <mclasen at redhat.com> - 2.8.14-2
- Fix a crash when using accessible treeviews

* Wed Mar 08 2006 Matthias Clasen <mclasen at redhat.com> - 2.8.14-1
- Update to 2.8.14 to fix a possible memory overrun
  in gtk_object_sink

gtkhtml3-3.10.0-1
-----------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 3.10.0-1
- Update to 3.10.0

* Mon Feb 13 2006 Matthias Clasen <mclasen at redhat.com> - 3.9.91-1
- Update to 3.9.91

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 3.9.90-3.2
- bump again for double-long bug on ppc(64)

gtksourceview-1.6.0-1
---------------------
* Sun Mar 12 2006 Ray Strode <rstrode at redhat.com> - 1.6.0-1
- update to 1.6.0

libcroco-0.6.1-1
----------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 0.6.1-1
- Update to 0.6.1
- Drop upstreamed patches

libgnome-2.14.0-1
-----------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

* Mon Feb 27 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.90-1
- Update to 2.13.90
- Drop obsolete patch

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 2.13.7-5.1
- bump again for double-long bug on ppc(64)

libgnomecanvas-2.14.0-1
-----------------------
* Mon Mar 13 2006 Matthias Clasen  <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

libgnomeui-2.14.0-1
-------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

libgtop2-2.14.0-1
-----------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

librsvg2-2.14.2-1
-----------------
* Sun Mar 12 2006 Ray Strode <rstrode at redhat.com> 2.14.2-1
- Update to 2.14.2

metacity-2.14.0-1
-----------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- update to 2.14.0

mkinitrd-5.0.32-1
-----------------
* Mon Mar 13 2006 Peter Jones <pjones at redhat.com> - 5.0.32-1
- handle sd_mod on scsi_mod in findmodule, not in the scsi setup.  This
  fixes the "no scsi_hostadapter" alias problem better (#182008).

nautilus-2.14.0-1
-----------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

* Mon Mar 06 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-2
- Reinstate the format patch which was accidentally dropped

* Mon Feb 27 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-1
- Update to 2.13.92

nautilus-cd-burner-2.14.0-1
---------------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-11
- Update to 2.14.0

opal-2.2.0-2
------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> - 2.2.0-2
- rebuild

* Mon Mar 13 2006 Daniel Veillard <veillard at redhat.com> - 2.2.0-1
- final version for ekiga-2.0.0

pango-1.12.0-1
--------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 1.12.0-1
- Update to 1.12.0

pwlib-1.10.0-1
--------------
* Mon Mar 13 2006 Daniel Veillard <veillard at redhat.com> - 1.10.0-1
- final version for ekiga 2.0.0

sound-juicer-2.14.0-1
---------------------
* Sun Mar 12 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

thunderbird-0:1.5-6
-------------------
* Mon Mar 13 2006 Christopher Aillon <caillon at redhat.com> - 1.5.6
- Temporarily disable other arches that we don't ship FC5 with, for time

* Mon Mar 13 2006 Christopher Aillon <caillon at redhat.com> - 1.5-5
- Add a notice to the mail start page denoting this is a pango enabled build.

valgrind-1:3.1.0-2
------------------
* Mon Mar 13 2006 Jakub Jelinek <jakub at redhat.com> 3.1.0-2
- add support for DW_CFA_val_offset{,_sf}, DW_CFA_def_cfa_sf
  and skip over DW_CFA_val_expression quietly
- adjust libc/ld.so filenames in glibc-2.4.supp for glibc 2.4
  release

* Mon Jan 09 2006 Jakub Jelinek <jakub at redhat.com> 3.1.0-1
- upgrade to 3.1.0 (#174582)
  - many bugfixes, ppc32 support

* Thu Oct 13 2005 Jakub Jelinek <jakub at redhat.com> 3.0.1-2
- remove Obsoletes for valgrind-callgrind, as it has been
  ported to valgrind 3.0.x already

vte-0.12.0-1.fc5.1
------------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> 0.12.0-1
- Update to 0.12.0-1

* Fri Mar 10 2006 Matthias Clasen <mclasen at redhat.com> 0.11.21-1
- Update to 0.11.21

yelp-2.14.0-1
-------------
* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

Broken deps for i386
----------------------------------------------------------
	ekiga - 1.99.1-2.i386 requires libpt_linux_x86_r.so.1.9.3
	ekiga - 1.99.1-2.i386 requires libopal_linux_x86_r.so.2.1



Broken deps for ia64
----------------------------------------------------------
	ekiga - 1.99.1-2.ia64 requires libpt_linux_ia64_r.so.1.9.3()(64bit)
	ekiga - 1.99.1-2.ia64 requires libopal_linux_ia64_r.so.2.1()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	ekiga - 1.99.1-2.ppc requires libpt_linux_ppc_r.so.1.9.3
	ekiga - 1.99.1-2.ppc requires libopal_linux_ppc_r.so.2.1



Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	ekiga - 1.99.1-2.ppc64 requires libpt_linux_ppc64_r.so.1.9.3()(64bit)
	ekiga - 1.99.1-2.ppc64 requires libopal_linux_ppc64_r.so.2.1()(64bit)
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	ekiga - 1.99.1-2.s390 requires libpt_linux_s390_r.so.1.9.3
	ekiga - 1.99.1-2.s390 requires libopal_linux_s390_r.so.2.1
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	ekiga - 1.99.1-2.x86_64 requires libpt_linux_x86_64_r.so.1.9.3()(64bit)
	ekiga - 1.99.1-2.x86_64 requires libopal_linux_x86_64_r.so.2.1()(64bit)





From fedora at camperquake.de  Tue Mar 14 08:25:15 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 14 Mar 2006 09:25:15 +0100
Subject: rawhide report: 20060314 changes
In-Reply-To: <200603140809.k2E895Gc023342@porkchop.devel.redhat.com>
References: <200603140809.k2E895Gc023342@porkchop.devel.redhat.com>
Message-ID: <20060314092515.2bec7916@soran.addix.net>

Hi.

On Tue, 14 Mar 2006 03:09:05 -0500, Build System wrote:

> firefox-1.5.0.1-9
> -----------------
> * Sat Mar 11 2006 Christopher Aillon <caillon at redhat.com> - 1.5.0.1-9
> - Add a notice to the about dialog denoting this is a pango enabled
> build.
> - Tweak the user agent denoting this is a pango enabled build.

Why, exactly, would the HTTP server care about the way firefox renders it's
pages?



From paul at city-fan.org  Tue Mar 14 08:31:46 2006
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 14 Mar 2006 08:31:46 +0000
Subject: No more selinux-policy-*-sources
In-Reply-To: <dv4rq0$csu$1@sea.gmane.org>
References: <dv4rq0$csu$1@sea.gmane.org>
Message-ID: <1142325106.12438.13.camel@laurel.intra.city-fan.org>

On Mon, 2006-03-13 at 15:30 -0700, Orion Poplawski wrote:
> I there some docs (FAQ/ReleaseNotes?) that describe how to make changes 
> to policy in FC5?

Doing minor tweaks is described at:
http://fedoraproject.org/wiki/SELinux/LoadableModules/Audit2allow

As for wholesale policy changes, I don't know.

Paul.




From giallu at gmail.com  Tue Mar 14 09:18:07 2006
From: giallu at gmail.com (Gianluca Sforna)
Date: Tue, 14 Mar 2006 10:18:07 +0100
Subject: FC5 test3 udev hang
In-Reply-To: <1142237842.2558.2.camel@scrappy.miketc.com>
References: <d5ad21470603130013v57ebe748g75ced763f7fb5073@mail.gmail.com>
	<1142237842.2558.2.camel@scrappy.miketc.com>
Message-ID: <d5ad21470603140118v2afa9ecdj7d23e2ff79b5d99@mail.gmail.com>

On 3/13/06, Mike Chambers <mike at miketc.com> wrote:
>
> I would try an install from rawhide and see if that works with the
> latest kernel/packages.
>

Just installed RawHide. hangs at the very same place :(
I also have a bunch of messages like:

PCI: Cannot allocate resource region X of device Y

are there any smart kernel parameters I can try to use in order to
boot correctly ?

thanks in advance

Gianluca



From gianluca.cecchi at gmail.com  Tue Mar 14 09:22:43 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Tue, 14 Mar 2006 10:22:43 +0100
Subject: deskbar-applet on x86_64(was: Re: match between gnome 2.14
	"manifesto" and upcoming fc5 features)
Message-ID: <561c252c0603140122h53b19d09ve46eb80b47250794@mail.gmail.com>

it seems ok now also in x86_64 with deskbar-applet-2.14.0-1.fc5
Thanks Gianluca



From veillard at redhat.com  Tue Mar 14 09:57:12 2006
From: veillard at redhat.com (Daniel Veillard)
Date: Tue, 14 Mar 2006 04:57:12 -0500
Subject: rawhide report: 20060314 changes
In-Reply-To: <1142327894.24640.1.camel@iridium>
References: <200603140809.k2E895Gc023342@porkchop.devel.redhat.com>
	<1142327894.24640.1.camel@iridium>
Message-ID: <20060314095712.GC22401@redhat.com>

On Tue, Mar 14, 2006 at 01:18:14AM -0800, Nathanael D. Noblet wrote:
> On Tue, 2006-03-14 at 03:09 -0500, Build System wrote:
> > Broken deps for i386
> > ----------------------------------------------------------
> > 	ekiga - 1.99.1-2.i386 requires libpt_linux_x86_r.so.1.9.3
> > 	ekiga - 1.99.1-2.i386 requires libopal_linux_x86_r.so.2.1
> 
> I can confirm that the yum update failed to get ekiga because of failed
> deps above. They'll get fixed later I presume?

 yes, sorry about that.

Daniel

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



From harald at redhat.com  Tue Mar 14 10:39:26 2006
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 14 Mar 2006 11:39:26 +0100
Subject: wpa_supplicant support for ifup
Message-ID: <44169D5E.9090705@redhat.com>

What do you think about the attached patch to ifup-wireless? Works for me :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ifup-wireless.patch
Type: text/x-patch
Size: 4655 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060314/bf8cf9c0/attachment.bin>

From dstewart at atl.lmco.com  Tue Mar 14 13:04:05 2006
From: dstewart at atl.lmco.com (Doug Stewart)
Date: Tue, 14 Mar 2006 08:04:05 -0500
Subject: [OT] Happy Birthday Jesse Keating !!!
In-Reply-To: <4415C5D3.8010002@vip.hr>
References: <4415C5D3.8010002@vip.hr>
Message-ID: <4416BF45.2060703@atl.lmco.com>

Igor Jagec wrote:
> Hapy Birthday To You
> Hapy Birthday To You
> Hapy Birthday Dear Jesse
> Hapy Birthday To You
> 
> Cheers mate!	;-)
> 

You better not have sung that while typing, or you'll be facing a nasty 
copyright suit.  *grin*

(Ref. http://www.snopes.com/music/songs/birthday.asp for those who 
aren't aware of the situation...)

-- 
----------
Doug Stewart
Systems Administrator/Web Applications Developer
Lockheed Martin Advanced Technology Labs
dstewart at atl.lmco.com



From billcrawford1970 at gmail.com  Tue Mar 14 13:21:53 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Tue, 14 Mar 2006 13:21:53 +0000
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <20060308171123.04f74390@soran.addix.net>
References: <440CD6DC.6020903@redhat.com>
	<20060308153307.GF2238@free.fr>	<20060308164612.1edb3f29@soran.addix.net>	<20060308160409.GI2238@free.fr>
	<20060308171123.04f74390@soran.addix.net>
Message-ID: <4416C371.7000603@gmail.com>

Ralf Ertzinger wrote:
> Hi.
>
> On Wed, 8 Mar 2006 17:04:09 +0100, Patrice Dumas wrote:
>
>   
>> [dumas at nor75-15-82-67-190-22 include]$ rpm
>> -qf /usr/X11R6/include/Mrm/MrmAppl.h openmotif-devel-2.3.0-0.1.9.2
>> [dumas at nor75-15-82-67-190-22 include]$ rpm -qf /usr/X11R6/include/Mrm/
>> file /usr/X11R6/include/Mrm is not owned by any package
>>
>>     
>>> If yes, does rpm -ql openmotif show any files in /usr/X11R6?
>>>       
>> No they appear to be in /usr/include 
>> [dumas at nor75-15-82-67-190-22 include]$ rpm -ql openmotif-devel | grep
>> X11R6
>>
>> echoes nothing, and there is:
>>
>> [dumas at nor75-15-82-67-190-22 include]$ rpm -ql openmotif-devel | grep
>> MrmAppl.h /usr/include/Mrm/MrmAppl.h
>>     
>
> I had the same effect while migrating to modular X. Maybe someone more
> versed in RPM internals can tell why RPM thinks that oponmotif owns
> files in /usr/X11R6 when rpm -ql show none of those files.
>
>   
 The files in the -devel package install to /usr/include/X11 which was 
(and might still be, if rpm -qf is reporting ownership of those files) 
symlinked to /usr/X11R6/include/X11



From d.jacobfeuerborn at conversis.de  Tue Mar 14 13:49:58 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Tue, 14 Mar 2006 14:49:58 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142325106.12438.13.camel@laurel.intra.city-fan.org>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
Message-ID: <4416CA06.3040605@conversis.de>

Paul Howarth wrote:
> On Mon, 2006-03-13 at 15:30 -0700, Orion Poplawski wrote:
>> I there some docs (FAQ/ReleaseNotes?) that describe how to make changes 
>> to policy in FC5?
> 
> Doing minor tweaks is described at:
> http://fedoraproject.org/wiki/SELinux/LoadableModules/Audit2allow

I've taken a look at AppArmor and it looks like a much more incremental 
and easier to use solution than selinux. It's not as powerful but all this 
power doesn't help much if most people will turn off selinux anyway because 
it gets in the way. Has anyone heard of any efforts trying to port it over 
to Fedora?

Regards,
   Dennis



From paul at city-fan.org  Tue Mar 14 13:58:45 2006
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 14 Mar 2006 13:58:45 +0000
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416CA06.3040605@conversis.de>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>
Message-ID: <4416CC15.6040006@city-fan.org>

Dennis Jacobfeuerborn wrote:
> Paul Howarth wrote:
> 
>> On Mon, 2006-03-13 at 15:30 -0700, Orion Poplawski wrote:
>>
>>> I there some docs (FAQ/ReleaseNotes?) that describe how to make 
>>> changes to policy in FC5?
>>
>>
>> Doing minor tweaks is described at:
>> http://fedoraproject.org/wiki/SELinux/LoadableModules/Audit2allow
> 
> 
> I've taken a look at AppArmor and it looks like a much more incremental 
> and easier to use solution than selinux. It's not as powerful but all 
> this power doesn't help much if most people will turn off selinux anyway 
> because it gets in the way. Has anyone heard of any efforts trying to 
> port it over to Fedora?

Not an answer to your question but there's an interesting discussion on 
AppArmor and SELinux in Dan Walsh's blog:

http://danwalsh.livejournal.com/424.html

Paul.



From arjan at fenrus.demon.nl  Tue Mar 14 14:13:15 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Tue, 14 Mar 2006 15:13:15 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416CC15.6040006@city-fan.org>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>  <4416CC15.6040006@city-fan.org>
Message-ID: <1142345596.3027.38.camel@laptopd505.fenrus.org>


> Not an answer to your question but there's an interesting discussion on 
> AppArmor and SELinux in Dan Walsh's blog:
> 
> http://danwalsh.livejournal.com/424.html


maybe it's time to accept that SELinux as technology is doomed. Not
because the code is bad, but because it's Just Too Complex(tm).
Complexity kills, and I think the time it is taking to get to the point
where at least less than 99% of the people turns selinux off first thing
is waay too long already.

Maybe it's a matter of focus; sometimes I get the impression the focus
is to give more coverage rather than to get the existing coverage to the
point where people use it... but maybe the later is just so much work
and so time consuming that it takes more time to get it than it takes
the codebase to change again.



From jspaleta at gmail.com  Tue Mar 14 14:19:31 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 14 Mar 2006 09:19:31 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416CA06.3040605@conversis.de>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>
Message-ID: <604aa7910603140619va254ca5p930ff093185d777e@mail.gmail.com>

On 3/14/06, Dennis Jacobfeuerborn <d.jacobfeuerborn at conversis.de> wrote:
> I've taken a look at AppArmor and it looks like a much more incremental
> and easier to use solution than selinux. It's not as powerful but all this
> power doesn't help much if most people will turn off selinux anyway because
> it gets in the way. Has anyone heard of any efforts trying to port it over
> to Fedora?

My understanding is that it still requires kernel patches which are
not in the mainline kernel yet. If you want to use it.. you'll have to
use a patched kernel. Snowball's chance in hell the Fedora kernels are
going to include apparmor specific patches that should be going into
mainline kernel for everyone to use.  You want to see it ported and
see it available in Fedora Extras... then go chew the novell
developers ears off about getting the required kernel patches into the
mainline kernel.  Please go read up in the lkml archives about
Immunix's SubDomain (newly renamed as Novell AppArmor) to gain insight
on where in the process things are to get Immunix's..err i mean
Novell's kernel patches into the mainline kernel.


-jef"New name==new press release==old news"spaleta



From d.jacobfeuerborn at conversis.de  Tue Mar 14 14:24:45 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Tue, 14 Mar 2006 15:24:45 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142345596.3027.38.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
Message-ID: <4416D22D.30604@conversis.de>

Arjan van de Ven wrote:
>> Not an answer to your question but there's an interesting discussion on 
>> AppArmor and SELinux in Dan Walsh's blog:
>>
>> http://danwalsh.livejournal.com/424.html
> 
> 
> maybe it's time to accept that SELinux as technology is doomed. Not
> because the code is bad, but because it's Just Too Complex(tm).
> Complexity kills, and I think the time it is taking to get to the point
> where at least less than 99% of the people turns selinux off first thing
> is waay too long already.

I wouldn't say it's doomed I would just say that it seems focused on 
addressing needs most users don't have. It should be pitched as a solution 
to people who have extreme security needs and the resources to support such 
complex solutions. AppArmor looks more attractive to me because while it 
may not be perfect at least it's usable and easily understandable compared 
to selinuxes black wizardry.

Regards,
   Dennis



From hhoffman at ip-solutions.net  Tue Mar 14 14:25:06 2006
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Tue, 14 Mar 2006 09:25:06 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142345596.3027.38.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
Message-ID: <4416D242.8010000@ip-solutions.net>

I'm not sure I buy that SELinux is doomed.

While it may be complex we use it on all of our linux servers and
desktops. We've had a few problems but that caused us to read the docs
and learn how to write policy to deal with these things.

Just like any new technology there are going to be learning curves, but
that doesn't stop many from learning other really complex systems that
now seem simple.

I think that as more and more people begin "tinkering" with selinux
we'll begin to see more and more tools that allow most non-technical
people to deal with the issues interacting with selinux.



Cheers,
Harry


-- 
Harry Hoffman
Integrated Portable Solutions, LLC
877.846.5927 ext 1000
http://www.ip-solutions.net/


Arjan van de Ven wrote:

<snip>
> 
> maybe it's time to accept that SELinux as technology is doomed. Not
> because the code is bad, but because it's Just Too Complex(tm).
> Complexity kills, and I think the time it is taking to get to the point
> where at least less than 99% of the people turns selinux off first thing
> is waay too long already.
> 
> Maybe it's a matter of focus; sometimes I get the impression the focus
> is to give more coverage rather than to get the existing coverage to the
> point where people use it... but maybe the later is just so much work
> and so time consuming that it takes more time to get it than it takes
> the codebase to change again.
> 



From d.jacobfeuerborn at conversis.de  Tue Mar 14 14:33:41 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Tue, 14 Mar 2006 15:33:41 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <604aa7910603140619va254ca5p930ff093185d777e@mail.gmail.com>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<604aa7910603140619va254ca5p930ff093185d777e@mail.gmail.com>
Message-ID: <4416D445.5040507@conversis.de>

Jeff Spaleta wrote:
> On 3/14/06, Dennis Jacobfeuerborn <d.jacobfeuerborn at conversis.de> wrote:
>> I've taken a look at AppArmor and it looks like a much more incremental
>> and easier to use solution than selinux. It's not as powerful but all this
>> power doesn't help much if most people will turn off selinux anyway because
>> it gets in the way. Has anyone heard of any efforts trying to port it over
>> to Fedora?
> 
> My understanding is that it still requires kernel patches which are
> not in the mainline kernel yet. If you want to use it.. you'll have to
> use a patched kernel. Snowball's chance in hell the Fedora kernels are
> going to include apparmor specific patches that should be going into
> mainline kernel for everyone to use.  You want to see it ported and
> see it available in Fedora Extras... then go chew the novell
> developers ears off about getting the required kernel patches into the
> mainline kernel.  Please go read up in the lkml archives about
> Immunix's SubDomain (newly renamed as Novell AppArmor) to gain insight
> on where in the process things are to get Immunix's..err i mean
> Novell's kernel patches into the mainline kernel.

Maybe I should have chosen my wording more carefully. When I said "port it 
over to Fedora" I meant to ask if someone is providing the necessary 
packages to run AppArmor on Fedora. It looks like an interesting technology 
to me but to determine if it's really useful I'd first have to actually 
test it and such packages would help doing that. I'm very aware that any 
sort of official inclusion into Fedora is quite unlikely even in the 
midterm future.

Regards,
   Dennis



From caillon at redhat.com  Tue Mar 14 14:39:47 2006
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 14 Mar 2006 09:39:47 -0500
Subject: rawhide report: 20060314 changes
In-Reply-To: <20060314092515.2bec7916@soran.addix.net>
References: <200603140809.k2E895Gc023342@porkchop.devel.redhat.com>
	<20060314092515.2bec7916@soran.addix.net>
Message-ID: <4416D5B3.6070805@redhat.com>

On 03/14/2006 03:25 AM, Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 14 Mar 2006 03:09:05 -0500, Build System wrote:
> 
>> firefox-1.5.0.1-9
>> -----------------
>> * Sat Mar 11 2006 Christopher Aillon <caillon at redhat.com> - 1.5.0.1-9
>> - Add a notice to the about dialog denoting this is a pango enabled
>> build.
>> - Tweak the user agent denoting this is a pango enabled build.
> 
> Why, exactly, would the HTTP server care about the way firefox renders it's
> pages?
> 

It wouldn't.  Just like it doesn't care about what distribution people 
are using, or most of the other stuff in the user agent.  The Mozilla 
Corporation requested this change.  In theory, it could know whether to 
show you MathML or a PDF version of the MathML since enabling pango 
breaks MathML right now.



From dwalsh at redhat.com  Tue Mar 14 15:00:27 2006
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 14 Mar 2006 10:00:27 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <dv4rq0$csu$1@sea.gmane.org>
References: <dv4rq0$csu$1@sea.gmane.org>
Message-ID: <4416DA8B.4050601@redhat.com>

Orion Poplawski wrote:
> I there some docs (FAQ/ReleaseNotes?) that describe how to make 
> changes to policy in FC5?
>
http://fedoraproject.org/wiki/SELinux/FAQ/ProposedAdditions



From alan at redhat.com  Tue Mar 14 15:16:14 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Mar 2006 10:16:14 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416D22D.30604@conversis.de>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
Message-ID: <20060314151614.GA26289@devserv.devel.redhat.com>

On Tue, Mar 14, 2006 at 03:24:45PM +0100, Dennis Jacobfeuerborn wrote:
> complex solutions. AppArmor looks more attractive to me because while it 
> may not be perfect at least it's usable and easily understandable compared 
> to selinuxes black wizardry.

Lots of things can look pretty but it doesn't mean they actually solve the
fundamental problems. SELinux uses more complex ideas like roles because in
the 1960s people working on this stuff realised the simple model actually
doesn't work.



From sds at tycho.nsa.gov  Tue Mar 14 15:36:14 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 14 Mar 2006 10:36:14 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142345596.3027.38.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>  <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
Message-ID: <1142350574.3072.17.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 15:13 +0100, Arjan van de Ven wrote:
> > Not an answer to your question but there's an interesting discussion on 
> > AppArmor and SELinux in Dan Walsh's blog:
> > 
> > http://danwalsh.livejournal.com/424.html
> 
> 
> maybe it's time to accept that SELinux as technology is doomed. Not
> because the code is bad, but because it's Just Too Complex(tm).
> Complexity kills, and I think the time it is taking to get to the point
> where at least less than 99% of the people turns selinux off first thing
> is waay too long already.
> 
> Maybe it's a matter of focus; sometimes I get the impression the focus
> is to give more coverage rather than to get the existing coverage to the
> point where people use it... but maybe the later is just so much work
> and so time consuming that it takes more time to get it than it takes
> the codebase to change again.

No, there is quite a bit of ongoing work on improving useability for
SELinux, including several new higher level tools that have been
recently released.  But don't conflate the user interface with the
mechanism - if you limit the OS access control mechanism by what is
immediately useable by end users, then you end up with a solution that
can never be secure (to wit:  AppArmor and its path-based
configurations).  You need to get the mechanism right first, which is
what we've done in SELinux, and then you build the nice UI on top of
that.  You might find the Useability discussion from the SELinux summit
of interest, see the summit minutes at:
http://www.selinux-symposium.org/2006/summit.php
   
-- 
Stephen Smalley
National Security Agency



From shahms at shahms.com  Tue Mar 14 15:34:03 2006
From: shahms at shahms.com (Shahms King)
Date: Tue, 14 Mar 2006 07:34:03 -0800
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416DA8B.4050601@redhat.com>
References: <dv4rq0$csu$1@sea.gmane.org> <4416DA8B.4050601@redhat.com>
Message-ID: <4416E26B.7060502@shahms.com>

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

Daniel J Walsh wrote:
> Orion Poplawski wrote:
> 
>> I there some docs (FAQ/ReleaseNotes?) that describe how to make
>> changes to policy in FC5?
>>
> http://fedoraproject.org/wiki/SELinux/FAQ/ProposedAdditions
> 

This should be widely linked and become well known.  Some of the things
on that page (like semodule) look to be making headway towards solving
the one major SELinux obstacle of application-specific policy.  Yes,
writing policy is difficult, but with sufficient infrastructure (i.e.
macros or interfaces) it could become relatively straightforward for the
vast majority of cases.  SELinux is very exciting and seeing it mature
into something that's actually usable (or at least potentially so ;-P)
is even more so.  Keep up the good work!

- --
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEFuJr/qs2NkWy11sRAgxRAJ45PRQ5fDLavz0pmuaTn+OYfsnu3gCeL1GX
kS46QD1wz4aRi6P1yIdVdTs=
=VJGU
-----END PGP SIGNATURE-----



From d.jacobfeuerborn at conversis.de  Tue Mar 14 15:52:54 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Tue, 14 Mar 2006 16:52:54 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <20060314151614.GA26289@devserv.devel.redhat.com>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
Message-ID: <4416E6D6.7040109@conversis.de>

Alan Cox wrote:
> On Tue, Mar 14, 2006 at 03:24:45PM +0100, Dennis Jacobfeuerborn wrote:
>> complex solutions. AppArmor looks more attractive to me because while it 
>> may not be perfect at least it's usable and easily understandable compared 
>> to selinuxes black wizardry.
> 
> Lots of things can look pretty but it doesn't mean they actually solve the
> fundamental problems. SELinux uses more complex ideas like roles because in
> the 1960s people working on this stuff realised the simple model actually
> doesn't work.


I understand that but if this system that "solves the fundamental problems" 
is so complex that most people just turn it off then the gain in security 
you get is pretty much theoretical. Security isn't an all-or-nothing thing 
and right now there seems to be chasm between the very basic traditional 
Unix model and the very secure but extremely complex SELinux. It looks like 
AppArmor fits in quite well between these two extremes.

Regards,
   Dennis



From d.jacobfeuerborn at conversis.de  Tue Mar 14 15:55:13 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Tue, 14 Mar 2006 16:55:13 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142350574.3072.17.camel@moss-spartans.epoch.ncsc.mil>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<1142350574.3072.17.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <4416E761.1010907@conversis.de>

Stephen Smalley wrote:
> On Tue, 2006-03-14 at 15:13 +0100, Arjan van de Ven wrote:
>>> Not an answer to your question but there's an interesting discussion on 
>>> AppArmor and SELinux in Dan Walsh's blog:
>>>
>>> http://danwalsh.livejournal.com/424.html
>>
>> maybe it's time to accept that SELinux as technology is doomed. Not
>> because the code is bad, but because it's Just Too Complex(tm).
>> Complexity kills, and I think the time it is taking to get to the point
>> where at least less than 99% of the people turns selinux off first thing
>> is waay too long already.
>>
>> Maybe it's a matter of focus; sometimes I get the impression the focus
>> is to give more coverage rather than to get the existing coverage to the
>> point where people use it... but maybe the later is just so much work
>> and so time consuming that it takes more time to get it than it takes
>> the codebase to change again.
> 
> No, there is quite a bit of ongoing work on improving useability for
> SELinux, including several new higher level tools that have been
> recently released.
[snip]

Where can I get more information about these tools?

Regards,
   Dennis



From sds at tycho.nsa.gov  Tue Mar 14 16:08:41 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 14 Mar 2006 11:08:41 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416E761.1010907@conversis.de>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<1142350574.3072.17.camel@moss-spartans.epoch.ncsc.mil>
	<4416E761.1010907@conversis.de>
Message-ID: <1142352521.3072.29.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 16:55 +0100, Dennis Jacobfeuerborn wrote:
> Stephen Smalley wrote:
> > No, there is quite a bit of ongoing work on improving useability for
> > SELinux, including several new higher level tools that have been
> > recently released.
> [snip]
> 
> Where can I get more information about these tools?

http://tresys.com/selinux/index.shtml

http://selinux-ide.sourceforge.net/index.php

-- 
Stephen Smalley
National Security Agency



From bruno at wolff.to  Tue Mar 14 16:07:56 2006
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 14 Mar 2006 10:07:56 -0600
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142345596.3027.38.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
Message-ID: <20060314160756.GC2943@wolff.to>

On Tue, Mar 14, 2006 at 15:13:15 +0100,
  Arjan van de Ven <arjan at fenrus.demon.nl> wrote:
> 
> maybe it's time to accept that SELinux as technology is doomed. Not
> because the code is bad, but because it's Just Too Complex(tm).
> Complexity kills, and I think the time it is taking to get to the point
> where at least less than 99% of the people turns selinux off first thing
> is waay too long already.

I would expect that for FC4 very few people would have a problem with the
targetted policy. I had some issues on my web server, because I was doing
some nonstandard things. However the benefit of limiting the damage from
security bugs in services exposed to the internet makes this a very good
trade off.

I aggree that the documentation seems lacking. I have read through a fair
amount of what is available and am developing an understanding of the model,
but I am know where near being able to write policies from scratch.

Personally, I find SELinux interesting and I will be playing with MCS and MLS
in FC5. I will also try to get some practice writing policies for commercial
software that I don't trust not to phone home. (Currently I run such software
as a separate user and have my firewall block any nonlocal traffic. But this
is a pain.)



From dwalsh at redhat.com  Tue Mar 14 16:08:52 2006
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 14 Mar 2006 11:08:52 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142345596.3027.38.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
Message-ID: <4416EA94.9060904@redhat.com>

Arjan van de Ven wrote:
>> Not an answer to your question but there's an interesting discussion on 
>> AppArmor and SELinux in Dan Walsh's blog:
>>
>> http://danwalsh.livejournal.com/424.html
>>     
>
>
> maybe it's time to accept that SELinux as technology is doomed. Not
> because the code is bad, but because it's Just Too Complex(tm).
> Complexity kills, and I think the time it is taking to get to the point
> where at least less than 99% of the people turns selinux off first thing
> is waay too long already.
>
> Maybe it's a matter of focus; sometimes I get the impression the focus
> is to give more coverage rather than to get the existing coverage to the
> point where people use it... but maybe the later is just so much work
> and so time consuming that it takes more time to get it than it takes
> the codebase to change again.
>
>   
Arjan,

Nice to hear from you.   I think that SELinux is just getting to the 
point where it is ready for steady improvements
in usability.  I will admit that we are being pulled by multiple 
forces.  I feel as I stated in my Blog that there are three groups 
pulling at SELinux, System Administrators who just want to get the damn 
thing working.  Software Application Developers who are kicking the 
tires to see if SELinux could help them protect there applications and 
finally Security people who are focused on things like protecting 
information flow.   Perhaps in the past we have been focused too heavily 
on the last group.

With loadable modules we are at the point where we can start to address 
all three groups, and you see products emerging to handle all three.  
Are these products coming fast enough, I don't know.  Can we use help, yes.

Loadable modules are providing a framework for just getting the damn 
thing working, in RHEL 4 and FC4, you needed to install policy-sources 
in order to make small customizations to policy, in FC5 you can just 
create a small policy module to fix your problem. 

Loadable modules gives us the opportunity to allow third parties to ship 
there own policy, and for us to start to break up the policy from one 
big blob to the point where it is shipped with individual packages. 

I equate SELinux to the point when personal firewalls were first being 
introduced to each computer, everyone at that point just turned them 
off.  But eventually the technology got to the point where most people 
don't
realize they have a firewall running on there system.

Maybe we need a top ten list of things that I don't like about SELinux 
and then we can work to fix them.

Dan



From shahms at shahms.com  Tue Mar 14 16:19:51 2006
From: shahms at shahms.com (Shahms King)
Date: Tue, 14 Mar 2006 08:19:51 -0800
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416E6D6.7040109@conversis.de>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
Message-ID: <4416ED27.5060907@shahms.com>

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

Dennis Jacobfeuerborn wrote:
> Alan Cox wrote:
> 
>> On Tue, Mar 14, 2006 at 03:24:45PM +0100, Dennis Jacobfeuerborn wrote:
>>
>>> complex solutions. AppArmor looks more attractive to me because while
>>> it may not be perfect at least it's usable and easily understandable
>>> compared to selinuxes black wizardry.
>>
>>
>> Lots of things can look pretty but it doesn't mean they actually solve
>> the
>> fundamental problems. SELinux uses more complex ideas like roles
>> because in
>> the 1960s people working on this stuff realised the simple model actually
>> doesn't work.
> 
> 
> 
> I understand that but if this system that "solves the fundamental
> problems" is so complex that most people just turn it off then the gain
> in security you get is pretty much theoretical. Security isn't an
> all-or-nothing thing and right now there seems to be chasm between the
> very basic traditional Unix model and the very secure but extremely
> complex SELinux. It looks like AppArmor fits in quite well between these
> two extremes.
> 
> Regards,
>   Dennis
> 


I'm over-simplifying, but the main source of complexity in the current
SELinux environment is its comprehensive nature.  None of the security
models currently used in SELinux is particularly complex.  The MLS
security model is counter-intuitive, but it's also not currently used
;-P  As it stands, the confusing areas of SELinux itself mostly reside
at the intersection between the different models (i.e. how DAC identity
and SELinux identity interact, how roles and types relate, etc.) and
with the myriad of object classes and associated permissions.

The task of specifying a comprehensive policy using only the DAC model
would be as daunting a task as doing so for SELinux is currently.  The
only difference is that DAC is inherently modular.  Securing your
average daemon/application is mostly a matter of asking two questions:

1. Who should be able to run this application?
2. What should the application be able to do?

Obviously both questions are overly-simplistic, but both are readily
answerable and the answers to both questions translate pretty directly
into a reasonable policy.  Taking, for example, an anonymous-only ftp
daemon:

1. It should be run from the init scripts by the system or administrator
2. It should be able to:
 a. read it's configuration from /etc
 b. listen on port 21 and 20
 c. read files and directories under its root
 d. append to a log file

That's pretty much it (off the top of my head).  A number of those
translate to multiple permissions (specifically 2c).  Given a base
policy I could write an application specific policy using the above
information.  Admittedly, I know more about SELinux than most, but with
a little more work the above could be turned into a couple of macros or
interfaces that could be used easily by application packagers with
relatively little knowledge of the details.  Even enabling full
read-write support for authenticated users (and authenticating those
users) and an associated boolean for switching between the two should be
relatively easy to write and/or macro-ize.

This post turned out longer than I expected, but the point is that
SELinux's reputation for incomprehensible complexity is undeserved.
It's new, different, and relatively undocumented but with a little
refinement should be no more difficult to deal with than the current DAC
security model and provides real security unlike AppArmor.

- --
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEFu0n/qs2NkWy11sRAqiTAKCwgIKMTRepNQdbx5o/Zh7ayeomxgCfS8jh
frtZiRS9qL+32nuH/2tpNT0=
=hnhd
-----END PGP SIGNATURE-----



From smooge at gmail.com  Tue Mar 14 16:26:01 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Tue, 14 Mar 2006 09:26:01 -0700
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416E6D6.7040109@conversis.de>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
Message-ID: <80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>

On 3/14/06, Dennis Jacobfeuerborn <d.jacobfeuerborn at conversis.de> wrote:
> Alan Cox wrote:
> > On Tue, Mar 14, 2006 at 03:24:45PM +0100, Dennis Jacobfeuerborn wrote:
> >> complex solutions. AppArmor looks more attractive to me because while it
> >> may not be perfect at least it's usable and easily understandable compared
> >> to selinuxes black wizardry.
> >
> > Lots of things can look pretty but it doesn't mean they actually solve the
> > fundamental problems. SELinux uses more complex ideas like roles because in
> > the 1960s people working on this stuff realised the simple model actually
> > doesn't work.
>
>
> I understand that but if this system that "solves the fundamental problems"
> is so complex that most people just turn it off then the gain in security
> you get is pretty much theoretical. Security isn't an all-or-nothing thing
> and right now there seems to be chasm between the very basic traditional
> Unix model and the very secure but extremely complex SELinux. It looks like
> AppArmor fits in quite well between these two extremes.
>

To be honest, we have found that the following people turn off SeLinux
for the following reasons:

1) They were told that xyz would be fixed by turning off SeLinux. In
most cases, they the problem with xyz was really a config issue that
they then fix by hand, but will swear that turning off selinux somehow
fixed things. It is similar to problems back in the Red Hat Linux 5.0
days where any problem with the system was fixed with a static
compiled kernel or application.

2) They have installed some super nifty kernel module (panassas) or
application that selinux (and 90% of the rest of the kernel) does not
agree with.

3) They found a legitimate problem with selinux but did not have the
tools to debug it or had the training needed to fix it.

4) They turn it off because it is outside their experience or religous
(Unix) convictions.

I think that the issue is mainly tools and time to get people up to
speed on it. The Selinux module looks to me like a Policy Virtual
Machine, and most of the policy data is assembly code. Now thats all
fun for some people, but most system administrators these days don't
do assembly code work anymore. They need levels of abstraction to help
make it something they can understand since they have not one system
to look after but 300 or more. They need a "python/perl/ruby" level
tool that does all the assembly code deep down but just has commands
like "import confidential_policy; print system_users; for $user in
peter, john, robert, thomas, paul, lindy do add_user system_users,
$user; done"


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From alan at redhat.com  Tue Mar 14 16:29:53 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 14 Mar 2006 11:29:53 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416E6D6.7040109@conversis.de>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
Message-ID: <20060314162953.GA2769@devserv.devel.redhat.com>

On Tue, Mar 14, 2006 at 04:52:54PM +0100, Dennis Jacobfeuerborn wrote:
> I understand that but if this system that "solves the fundamental problems" 
> is so complex that most people just turn it off then the gain in security 
> you get is pretty much theoretical. Security isn't an all-or-nothing thing 
> and right now there seems to be chasm between the very basic traditional 

It becomes a packaging problem. For most users SELinux just works and they
take the defaults. The argument you are making is not new btw, the same was
said about firewalling by default years ago and today would be regarded as
deeply silly.

In part the risk model changed, in part the tools improved

> Unix model and the very secure but extremely complex SELinux. It looks like 
> AppArmor fits in quite well between these two extremes.

Looks pretty, does little ? Thats not a good combination. I agree entirely
about the lack of easy tool configuration for SELinux.

Anyway if AppArmor wats to become anything serious it needs to get upstream
and I see no evidence of them even trying to do that. If it gets upstream
dropping the tools for it into extras is easy



From laroche at redhat.com  Tue Mar 14 16:30:12 2006
From: laroche at redhat.com (Florian La Roche)
Date: Tue, 14 Mar 2006 17:30:12 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416EA94.9060904@redhat.com>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416EA94.9060904@redhat.com>
Message-ID: <20060314163012.GA8478@dudweiler.stuttgart.redhat.com>

> I equate SELinux to the point when personal firewalls were first being 
> introduced to each computer, everyone at that point just turned them 
> off.  But eventually the technology got to the point where most people 
> don't
> realize they have a firewall running on there system.

I start hearing from more and more people who now keep selinux
enabled on e.g. fc4 with all updates applied.
And getting developers who often change their system to have
selinux on is one of the bigger hurdles...

regards,

Florian La Roche



From jspaleta at gmail.com  Tue Mar 14 16:33:05 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 14 Mar 2006 11:33:05 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
Message-ID: <604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>

On 3/14/06, Stephen J. Smoogen <smooge at gmail.com> wrote:
> 3) They found a legitimate problem with selinux but did not have the
> tools to debug it or had the training needed to fix it.

I'm getting more comfortable with at least troubleshooting selinux
errors by looking for avc error messages in the logs. But sometimes i
run into head-scratching situations that people run into where there
are no avc error messages being generated but putting selinux into
permissive mode seems to help as a last resort.

Are there selinux interactions which will not generate avc messages as
a matter of selinux design?  If so how do i troubleshoot or even
confirm that selinux policy is what an application is tripping over in
those situations?

-jef



From sds at tycho.nsa.gov  Tue Mar 14 16:45:36 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 14 Mar 2006 11:45:36 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
Message-ID: <1142354736.3072.47.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 11:33 -0500, Jeff Spaleta wrote:
> On 3/14/06, Stephen J. Smoogen <smooge at gmail.com> wrote:
> > 3) They found a legitimate problem with selinux but did not have the
> > tools to debug it or had the training needed to fix it.
> 
> I'm getting more comfortable with at least troubleshooting selinux
> errors by looking for avc error messages in the logs. But sometimes i
> run into head-scratching situations that people run into where there
> are no avc error messages being generated but putting selinux into
> permissive mode seems to help as a last resort.
> 
> Are there selinux interactions which will not generate avc messages as
> a matter of selinux design?  If so how do i troubleshoot or even
> confirm that selinux policy is what an application is tripping over in
> those situations?

Under FC4 and earlier:
http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2827008

Under FC5, you install the enableaudit.pp package, see the end of:
http://fedoraproject.org/wiki/SELinux/Troubleshooting

The wiki could use some help...

-- 
Stephen Smalley
National Security Agency



From dwalsh at redhat.com  Tue Mar 14 16:40:44 2006
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 14 Mar 2006 11:40:44 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>	<20060314151614.GA26289@devserv.devel.redhat.com>	<4416E6D6.7040109@conversis.de>	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
Message-ID: <4416F20C.4060508@redhat.com>

Jeff Spaleta wrote:
> On 3/14/06, Stephen J. Smoogen <smooge at gmail.com> wrote:
>   
>> 3) They found a legitimate problem with selinux but did not have the
>> tools to debug it or had the training needed to fix it.
>>     
>
> I'm getting more comfortable with at least troubleshooting selinux
> errors by looking for avc error messages in the logs. But sometimes i
> run into head-scratching situations that people run into where there
> are no avc error messages being generated but putting selinux into
> permissive mode seems to help as a last resort.
>
> Are there selinux interactions which will not generate avc messages as
> a matter of selinux design?  If so how do i troubleshoot or even
> confirm that selinux policy is what an application is tripping over in
> those situations?
>
> -jef
>
>   
http://fedoraproject.org/wiki/SELinux/FAQ/ProposedAdditions#head-6dcc9a7f5f2d7e7ee033e777caacebb434713dd7



From arjan at fenrus.demon.nl  Tue Mar 14 16:45:42 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Tue, 14 Mar 2006 17:45:42 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416ED27.5060907@shahms.com>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>  <4416ED27.5060907@shahms.com>
Message-ID: <1142354743.3027.52.camel@laptopd505.fenrus.org>


> 
> I'm over-simplifying, but the main source of complexity in the current
> SELinux environment is its comprehensive nature.  None of the security
> models currently used in SELinux is particularly complex.  The MLS
> security model is counter-intuitive, but it's also not currently used
> ;-P  As it stands, the confusing areas of SELinux itself mostly reside
> at the intersection between the different models (i.e. how DAC identity
> and SELinux identity interact, how roles and types relate, etc.) and
> with the myriad of object classes and associated permissions.


which is because the policy design seems to keep starting from the wrong
place. That policy design is aimed for a "strict" policy. Even the so
called targeted policy tries to work in a strict way.

With this I mean it tries to be too fine grained. Far too fine grained.

But that is easy to say without having to say what it should look like
then... So maybe something like this:

Create several high level classes for binaries

* CanDoAll: no limitations at all
  (this already exists as unrestricted today)
* NormalBinary: "modern" normal but simple binary; 
  no executable stack, no dlopen allowed, no textrels, 
  no writable executable memory
* NoExec: like "NormalBinary" but doesn't do system/exec to launch 
  other applications
* NoNetworking: like NoExec but application is not doing anything
  network-ish (eg connect/bind/accept etc)

these last 2 classes I bet will cover 95% of /usr/bin already.
What is more, most of the requirements can be validated at build time
(just by looking at which glibc functions get called)

You can argue that this doesn't cover the hard cases, like ssh and
apache. And you know what, that would be right. Apache is just a really
really complex beast, given that it accepts 3rd party plugins and has a
near-turing-complete configurability. 

To me the later means that any attempt to in detail describe what the
application is allowed to do for the general population is doomed from
the start. That leaves 3 options
1) Have a policy generator that reads httpd.conf and based on that
creates the policy
2) Give apache very broad permissions
3) Work from the other angle, forbid it to do certain bad things. So
instead of enumerating all the possible things you can do, you enumerate
the things it cannot do. The traditional argument for MAC is "but you
can't enumerate all the bad things so lets say what it CAN do". My
counter argument is that you can't enumerate what it can do either, and
that telling it obvious things it can't do is at least a step forward. 

1) and 3) are not exclusive.

 



From jspaleta at gmail.com  Tue Mar 14 16:53:52 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 14 Mar 2006 11:53:52 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142354736.3072.47.camel@moss-spartans.epoch.ncsc.mil>
References: <dv4rq0$csu$1@sea.gmane.org> <4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
	<1142354736.3072.47.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <604aa7910603140853s2df750a9q4034620f09027a92@mail.gmail.com>

On 3/14/06, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> Under FC4 and earlier:
> http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2827008
>
> Under FC5, you install the enableaudit.pp package, see the end of:
> http://fedoraproject.org/wiki/SELinux/Troubleshooting
>
> The wiki could use some help...

excellent....

-jef



From aph at redhat.com  Tue Mar 14 16:54:07 2006
From: aph at redhat.com (Andrew Haley)
Date: Tue, 14 Mar 2006 16:54:07 +0000
Subject: No more selinux-policy-*-sources
In-Reply-To: <80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
Message-ID: <17430.62767.42318.610131@zapata.pink>

Stephen J. Smoogen writes:
 > 
 > To be honest, we have found that the following people turn off SeLinux
 > for the following reasons:
 > 
 > 1) They were told that xyz would be fixed by turning off SeLinux. In
 > most cases, they the problem with xyz was really a config issue that
 > they then fix by hand, but will swear that turning off selinux somehow
 > fixed things. It is similar to problems back in the Red Hat Linux 5.0
 > days where any problem with the system was fixed with a static
 > compiled kernel or application.
 > 
 > 2) They have installed some super nifty kernel module (panassas) or
 > application that selinux (and 90% of the rest of the kernel) does not
 > agree with.
 > 
 > 3) They found a legitimate problem with selinux but did not have the
 > tools to debug it or had the training needed to fix it.
 > 
 > 4) They turn it off because it is outside their experience or religous
 > (Unix) convictions.

5) They don't want enhanced security.  I suspect this is a sizable
   number of people.

Andrew.



From lfarkas at bppiac.hu  Tue Mar 14 16:55:42 2006
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Tue, 14 Mar 2006 17:55:42 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <20060314163012.GA8478@dudweiler.stuttgart.redhat.com>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416EA94.9060904@redhat.com>
	<20060314163012.GA8478@dudweiler.stuttgart.redhat.com>
Message-ID: <4416F58E.10701@bppiac.hu>

Florian La Roche wrote:
>>I equate SELinux to the point when personal firewalls were first being 
>>introduced to each computer, everyone at that point just turned them 
>>off.  But eventually the technology got to the point where most people 
>>don't
>>realize they have a firewall running on there system.
> 
> 
> I start hearing from more and more people who now keep selinux
> enabled on e.g. fc4 with all updates applied.
> And getting developers who often change their system to have
> selinux on is one of the bigger hurdles...

we try and really try to use selinux on all of servers. but after a
years we are think more and more it's un usable. although Daniel is one
of the fastest and most gentle developer at rh and his response time is
almost always in one day it's still not enough. even after about a year
when rhel4 comes out we still regulary run
audit2allow -l -i /var/log/audit/audit.log
and still find rules which should have to apply in order to avoid
problems. and these are not extra applications these are just those
included in the rh release. on fedore the situation worse so we trun off
selinux all on of our desktops.
i hope when binary compiled policies can be used and application
developer has to develop their own policies then the situation will be
better, but now it's like a toy. but even then i do not realy belive
such a rules like:
allow named_t winbind_var_run_t:dir getattr;
allow mysqld_t nscd_var_run_t:dir search;
will be easily categorized to any package...

these are just my experiences:-(

-- 
  Levente                               "Si vis pacem para bellum!"



From arjan at fenrus.demon.nl  Tue Mar 14 16:58:30 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Tue, 14 Mar 2006 17:58:30 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <17430.62767.42318.610131@zapata.pink>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<17430.62767.42318.610131@zapata.pink>
Message-ID: <1142355511.3027.54.camel@laptopd505.fenrus.org>


> 5) They don't want enhanced security.  I suspect this is a sizable
>    number of people.

or rather, they don't care as long as it doesn't get in the way at all.



From bruno at wolff.to  Tue Mar 14 17:19:58 2006
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 14 Mar 2006 11:19:58 -0600
Subject: No more selinux-policy-*-sources
In-Reply-To: <604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
Message-ID: <20060314171958.GA28087@wolff.to>

On Tue, Mar 14, 2006 at 11:33:05 -0500,
> 
> Are there selinux interactions which will not generate avc messages as
> a matter of selinux design?  If so how do i troubleshoot or even
> confirm that selinux policy is what an application is tripping over in
> those situations?

I believe there is a way to say not to log specific events. I wouldn't
expect there to be very much of that in the supplied policies.



From sds at tycho.nsa.gov  Tue Mar 14 17:30:08 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 14 Mar 2006 12:30:08 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142354743.3027.52.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>  <4416ED27.5060907@shahms.com>
	<1142354743.3027.52.camel@laptopd505.fenrus.org>
Message-ID: <1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 17:45 +0100, Arjan van de Ven wrote:
> which is because the policy design seems to keep starting from the wrong
> place. That policy design is aimed for a "strict" policy. Even the so
> called targeted policy tries to work in a strict way.
> 
> With this I mean it tries to be too fine grained. Far too fine grained.
> 
> But that is easy to say without having to say what it should look like
> then... So maybe something like this:
> 
> Create several high level classes for binaries
> 
> * CanDoAll: no limitations at all
>   (this already exists as unrestricted today)
> * NormalBinary: "modern" normal but simple binary; 
>   no executable stack, no dlopen allowed, no textrels, 
>   no writable executable memory
> * NoExec: like "NormalBinary" but doesn't do system/exec to launch 
>   other applications
> * NoNetworking: like NoExec but application is not doing anything
>   network-ish (eg connect/bind/accept etc)
> 
> these last 2 classes I bet will cover 95% of /usr/bin already.
> What is more, most of the requirements can be validated at build time
> (just by looking at which glibc functions get called)
> 
> You can argue that this doesn't cover the hard cases, like ssh and
> apache. And you know what, that would be right. Apache is just a really
> really complex beast, given that it accepts 3rd party plugins and has a
> near-turing-complete configurability. 
> 
> To me the later means that any attempt to in detail describe what the
> application is allowed to do for the general population is doomed from
> the start. That leaves 3 options
> 1) Have a policy generator that reads httpd.conf and based on that
> creates the policy
> 2) Give apache very broad permissions
> 3) Work from the other angle, forbid it to do certain bad things. So
> instead of enumerating all the possible things you can do, you enumerate
> the things it cannot do. The traditional argument for MAC is "but you
> can't enumerate all the bad things so lets say what it CAN do". My
> counter argument is that you can't enumerate what it can do either, and
> that telling it obvious things it can't do is at least a step forward. 
> 
> 1) and 3) are not exclusive.

Go read:
http://www.ranum.com/security/computer_security/editorials/dumb/

-- 
Stephen Smalley
National Security Agency



From notting at redhat.com  Tue Mar 14 17:26:22 2006
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 14 Mar 2006 12:26:22 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <44169D5E.9090705@redhat.com>
References: <44169D5E.9090705@redhat.com>
Message-ID: <20060314172622.GA22376@devserv.devel.redhat.com>

Harald Hoyer (harald at redhat.com) said: 
> What do you think about the attached patch to ifup-wireless? Works for me :)

This should really be done in NM.

Bill



From fedora at camperquake.de  Tue Mar 14 17:36:57 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 14 Mar 2006 18:36:57 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de> <4416ED27.5060907@shahms.com>
	<1142354743.3027.52.camel@laptopd505.fenrus.org>
	<1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <20060314183657.3009bdd8@soran.addix.net>

Hi.

On Tue, 14 Mar 2006 12:30:08 -0500, Stephen Smalley wrote:

> Go read:
> http://www.ranum.com/security/computer_security/editorials/dumb/

So shipping the targetted policy is a dumb idea. RH will be glad to hear that.



From arjan at fenrus.demon.nl  Tue Mar 14 17:44:27 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Tue, 14 Mar 2006 18:44:27 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>  <4416ED27.5060907@shahms.com>
	<1142354743.3027.52.camel@laptopd505.fenrus.org>
	<1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <1142358267.3027.68.camel@laptopd505.fenrus.org>

On Tue, 2006-03-14 at 12:30 -0500, Stephen Smalley wrote:
> On Tue, 2006-03-14 at 17:45 +0100, Arjan van de Ven wrote:
> > which is because the policy design seems to keep starting from the wrong
> > place. That policy design is aimed for a "strict" policy. Even the so
> > called targeted policy tries to work in a strict way.
> > 
> > With this I mean it tries to be too fine grained. Far too fine grained.
> > 
> > But that is easy to say without having to say what it should look like
> > then... So maybe something like this:
> > 
> > Create several high level classes for binaries
> > 
> > * CanDoAll: no limitations at all
> >   (this already exists as unrestricted today)
> > * NormalBinary: "modern" normal but simple binary; 
> >   no executable stack, no dlopen allowed, no textrels, 
> >   no writable executable memory
> > * NoExec: like "NormalBinary" but doesn't do system/exec to launch 
> >   other applications
> > * NoNetworking: like NoExec but application is not doing anything
> >   network-ish (eg connect/bind/accept etc)
> > 
> > these last 2 classes I bet will cover 95% of /usr/bin already.
> > What is more, most of the requirements can be validated at build time
> > (just by looking at which glibc functions get called)
> > 
> > You can argue that this doesn't cover the hard cases, like ssh and
> > apache. And you know what, that would be right. Apache is just a really
> > really complex beast, given that it accepts 3rd party plugins and has a
> > near-turing-complete configurability. 
> > 
> > To me the later means that any attempt to in detail describe what the
> > application is allowed to do for the general population is doomed from
> > the start. That leaves 3 options
> > 1) Have a policy generator that reads httpd.conf and based on that
> > creates the policy
> > 2) Give apache very broad permissions
> > 3) Work from the other angle, forbid it to do certain bad things. So
> > instead of enumerating all the possible things you can do, you enumerate
> > the things it cannot do. The traditional argument for MAC is "but you
> > can't enumerate all the bad things so lets say what it CAN do". My
> > counter argument is that you can't enumerate what it can do either, and
> > that telling it obvious things it can't do is at least a step forward. 
> > 
> > 1) and 3) are not exclusive.
> 
> Go read:
> http://www.ranum.com/security/computer_security/editorials/dumb/

So it seems we disagree some ;-) Lets gets some individual statements
out then:

1) It's not feasible to enumerate all the bad things that can happen.
   I think we both agree on this based on your reaction.

2) For something as complex as apache (extremely configurable and used
   that way in practice all the time, as well as full of plugins with an
   active 3rd party plugin ecosystem), it is equally impossible to
   enumerate all the things it needs to be able to do statically and
   upfront. At least without ending up with an effective "everything
   goes" policy which is useless.

   I'm guessing you don't agree with this. 

3) If you try anyway, and a situation you didn't think of happens
   because the admin configures it that way, the complexity of the
   policy that resulted is such that the admin no longer has a chance
   to fix it himself. Even when the admin might fix a simple 5 line
   policy situation (for example by relabling his new app as "does
   network" from "does no network"), expecting the admin to fix up
   a highly complex policy without creating wide open holes is 
   a losing battle. Best case is he disables the lot and realizes he
   needs to keep his apache highly uptodate. Worst case is he thinks
   he's safe and never updates.

   I'm guessing you also don't agree with this.

So that leaves a few options:
* dynamic policy that adjusts to the configuration
  this is going to be of the same order of complexity as the
  configuration options are in the first place.
* keep the policy simple but allow more than strictly needed, yet
  disallow things that are highly out of bound.

The parallel to firewalls has been made several times. But in fact the
linux firewall does exactly this; the "related" ruleset is a dynamic
behavior that allows more than strictly would be needed to be allowed,
yet it's an effective way to keep things tight when you know they can
be.




From sds at tycho.nsa.gov  Tue Mar 14 17:51:59 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 14 Mar 2006 12:51:59 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <20060314183657.3009bdd8@soran.addix.net>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de> <4416ED27.5060907@shahms.com>
	<1142354743.3027.52.camel@laptopd505.fenrus.org>
	<1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
	<20060314183657.3009bdd8@soran.addix.net>
Message-ID: <1142358719.3072.76.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 18:36 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 14 Mar 2006 12:30:08 -0500, Stephen Smalley wrote:
> 
> > Go read:
> > http://www.ranum.com/security/computer_security/editorials/dumb/
> 
> So shipping the targetted policy is a dumb idea. RH will be glad to hear that.

Targeted policy is just a policy configuration of the SELinux mechanism,
which remains default deny by nature.  Targeted policy just differs from
strict in what it allows to happen.  And targeted policy is a way of
gradually introducing people to real MAC, which does take time, as it is
a paradigm shift.  Note the evolution of targeted policy in Fedora - it
went from a handful of daemons in FC3 to a much larger set in FC4 to an
even larger set in FC5.  Meanwhile, with the ongoing work on policy
tools and management infrastructure, the feasibility of making strict
policy the default in the future is becoming more realistic (still not
there, but not unreasonable once the necessary infrastructure is in
place).

-- 
Stephen Smalley
National Security Agency



From giallu at gmail.com  Tue Mar 14 17:48:20 2006
From: giallu at gmail.com (Gianluca Sforna)
Date: Tue, 14 Mar 2006 18:48:20 +0100
Subject: mock question
Message-ID: <d5ad21470603140948g5886ce68hf41a84e7cd66516e@mail.gmail.com>

may I use mock to test compilation of the 64bit variant of a rpm using
my regular 32bit centrino laptop?

Thanks in advance

Gianluca



From ivazquez at ivazquez.net  Tue Mar 14 17:52:40 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 14 Mar 2006 12:52:40 -0500
Subject: mock question
In-Reply-To: <d5ad21470603140948g5886ce68hf41a84e7cd66516e@mail.gmail.com>
References: <d5ad21470603140948g5886ce68hf41a84e7cd66516e@mail.gmail.com>
Message-ID: <1142358760.3904.0.camel@ignacio.lan>

On Tue, 2006-03-14 at 18:48 +0100, Gianluca Sforna wrote:
> may I use mock to test compilation of the 64bit variant of a rpm using
> my regular 32bit centrino laptop?

Nope.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060314/b3d7e2e3/attachment.sig>

From rc040203 at freenet.de  Tue Mar 14 17:58:33 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 14 Mar 2006 18:58:33 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <17430.62767.42318.610131@zapata.pink>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<17430.62767.42318.610131@zapata.pink>
Message-ID: <1142359114.31760.12.camel@mccallum.corsepiu.local>

On Tue, 2006-03-14 at 16:54 +0000, Andrew Haley wrote:
> Stephen J. Smoogen writes:
>  > 
>  > To be honest, we have found that the following people turn off SeLinux
>  > for the following reasons:
>  > 
>  > 1) They were told that xyz would be fixed by turning off SeLinux. In
>  > most cases, they the problem with xyz was really a config issue that
>  > they then fix by hand, but will swear that turning off selinux somehow
>  > fixed things. It is similar to problems back in the Red Hat Linux 5.0
>  > days where any problem with the system was fixed with a static
>  > compiled kernel or application.
>  > 
>  > 2) They have installed some super nifty kernel module (panassas) or
>  > application that selinux (and 90% of the rest of the kernel) does not
>  > agree with.
>  > 
>  > 3) They found a legitimate problem with selinux but did not have the
>  > tools to debug it or had the training needed to fix it.
Cf. 7) below.

>  > 4) They turn it off because it is outside their experience or religous
>  > (Unix) convictions.
>
> 5) They don't want enhanced security.  I suspect this is a sizable
>    number of people.
Only very few people work for a bank ;)


6) They found SELinux (rsp. policy bugs) to prevent the OS from proper
function. 

Fundamental design problem: SELinux policies are centralized and
therefore not easy to customize.

7) They found the current SELinux tools to suffer from usability
deficits. For example: Why aren't all selinux tools using a common
program prefix?

Finally, one fundamental problem, probably most users ask them
themselves: Is coping with all the issues SELinux causes worth the
effort, and does it really help the user? 

I guess, all Fedora users have been fighting with SELinux at some point
in time, but probably nobody or at least very few have seen SELinux
preventing damage from a system in real world installations.

Ralf




From gianluca.cecchi at gmail.com  Tue Mar 14 18:28:50 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Tue, 14 Mar 2006 19:28:50 +0100
Subject: [OT] Happy Birthday Jesse Keating !!!
Message-ID: <561c252c0603141028o46c3333dyc6089f2ddea2c067@mail.gmail.com>

On Tue, 14 Mar 2006 08:04:05 -0500 Doug Stewart
>You better not have sung that while typing, or you'll be facing a
nasty copyright suit. *grin*
And casually he missed one of the p in the first word... ;-)
Something like in M$?



From kms at passback.co.uk  Tue Mar 14 18:29:31 2006
From: kms at passback.co.uk (Keith Sharp)
Date: Tue, 14 Mar 2006 18:29:31 +0000
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060314172622.GA22376@devserv.devel.redhat.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
Message-ID: <1142360971.31972.30.camel@animal.passback.co.uk>

On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> Harald Hoyer (harald at redhat.com) said: 
> > What do you think about the attached patch to ifup-wireless? Works for me :)
> 
> This should really be done in NM.

I may have the wrong end of the stick, but what about the increasingly
common situation where wired access to Ethernet switches is beings
controlled by 802.1x authentication?  I understand that NM will handle
the laptop/workstation with GUI case, but what about servers?  And how
does NM handle static IP addresses?

Keith.



From smooge at gmail.com  Tue Mar 14 18:30:58 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Tue, 14 Mar 2006 11:30:58 -0700
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142359114.31760.12.camel@mccallum.corsepiu.local>
References: <dv4rq0$csu$1@sea.gmane.org> <4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<17430.62767.42318.610131@zapata.pink>
	<1142359114.31760.12.camel@mccallum.corsepiu.local>
Message-ID: <80d7e4090603141030s4d42d1d0sf0861d2dea31a01d@mail.gmail.com>

On 3/14/06, Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Tue, 2006-03-14 at 16:54 +0000, Andrew Haley wrote:
> > Stephen J. Smoogen writes:

> Finally, one fundamental problem, probably most users ask them
> themselves: Is coping with all the issues SELinux causes worth the
> effort, and does it really help the user?
>
> I guess, all Fedora users have been fighting with SELinux at some point
> in time, but probably nobody or at least very few have seen SELinux
> preventing damage from a system in real world installations.
>

I can say that is  false. Yes, I had some problems, but instead of
turning it off I took the time to learn what it wanted. I have seen
several cases where the Selinux targeted rules in httpd stopped bad
stuff from happening where a hacker tried to dial home but couldnt. At
this point, I think turning off selinux is the equivalent of not using
shadow files and no firewall.

Yes Apache is complex and you can do tons of different things with
it... and you can not enumerate out of the box every type of thing you
can do with it.. However, just because you can do something doesnt
mean you should do it, and if you don't know what it is going to do..
then you are better off with the computer saying "sorry cant let that
happen" than "oh gee look my box has been a kiddie-porn repository for
the last 6 months"

--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From csellers at tresys.com  Tue Mar 14 18:32:03 2006
From: csellers at tresys.com (Chad Sellers)
Date: Tue, 14 Mar 2006 13:32:03 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142358267.3027.68.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>	<20060314151614.GA26289@devserv.devel.redhat.com>	<4416E6D6.7040109@conversis.de>
	<4416ED27.5060907@shahms.com>	<1142354743.3027.52.camel@laptopd505.fenrus.org>	<1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
	<1142358267.3027.68.camel@laptopd505.fenrus.org>
Message-ID: <44170C23.8070900@tresys.com>

Arjan van de Ven wrote:
> 
> The parallel to firewalls has been made several times. But in fact the
> linux firewall does exactly this; the "related" ruleset is a dynamic
> behavior that allows more than strictly would be needed to be allowed,
> yet it's an effective way to keep things tight when you know they can
> be.
> 

There have been a number of valid points about the current usability of
SELinux, and those are exactly what we're working on addressing right now.

> So that leaves a few options:
> * dynamic policy that adjusts to the configuration
>   this is going to be of the same order of complexity as the
>   configuration options are in the first place.

This is definitely possible, and we're currently working on something
very similar. Check out the Websphere case study slides from the SELinux
Symposium at http://selinux-symposium.org/2006/slides/05-websphere.pdf.
This could easily be applied to other applications such as a apache with
exceptionally rich configuration options.

> * keep the policy simple but allow more than strictly needed, yet
>   disallow things that are highly out of bound.

As Steve pointed out, you have to first build the right mechanism, then
build on top of that. We've spent a lot of time on the mechanism, and
we're now working on making things easier. There are several projects
currently working to make policy simpler. These range from the bottom-up
approach of Reference Policy (http://serefpolicy.sourceforge.net/) to
the top-down approach of adding higher-level languages on top of SELinux
policy (a couple of these were presented at the SELinux Symposium as well).

In working to make the mechanism right, perhaps we've ignored usability
a bit. This doesn't mean the technology is doomed. On the contrary, I'd
say that the only reason it has a chance is because the mechanism is so
complete. Please don't discount SELinux just because these usability
features are still in their infancy.

Thanks,
Chad Sellers
-- 

----------------------
Chad Sellers
Tresys Technology, LLC
csellers at tresys.com
http://www.tresys.com



From notting at redhat.com  Tue Mar 14 18:32:13 2006
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 14 Mar 2006 13:32:13 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <1142360971.31972.30.camel@animal.passback.co.uk>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142360971.31972.30.camel@animal.passback.co.uk>
Message-ID: <20060314183213.GF2808@devserv.devel.redhat.com>

Keith Sharp (kms at passback.co.uk) said: 
> On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> > Harald Hoyer (harald at redhat.com) said: 
> > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > 
> > This should really be done in NM.
> 
> I may have the wrong end of the stick, but what about the increasingly
> common situation where wired access to Ethernet switches is beings
> controlled by 802.1x authentication?  I understand that NM will handle
> the laptop/workstation with GUI case, but what about servers?  And how
> does NM handle static IP addresses?

NM needs to move to handle these sorts of things; shipping two infrastructures
is silly.

Bill



From dwalsh at redhat.com  Tue Mar 14 18:48:59 2006
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 14 Mar 2006 13:48:59 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <20060314183657.3009bdd8@soran.addix.net>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>	<20060314151614.GA26289@devserv.devel.redhat.com>	<4416E6D6.7040109@conversis.de>
	<4416ED27.5060907@shahms.com>	<1142354743.3027.52.camel@laptopd505.fenrus.org>	<1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
	<20060314183657.3009bdd8@soran.addix.net>
Message-ID: <4417101B.5080407@redhat.com>

Ralf Ertzinger wrote:
> Hi.
>
> On Tue, 14 Mar 2006 12:30:08 -0500, Stephen Smalley wrote:
>
>   
>> Go read:
>> http://www.ranum.com/security/computer_security/editorials/dumb/
>>     
>
> So shipping the targetted policy is a dumb idea. RH will be glad to hear that.
>
>   
No targeted policy is confining the selected domains by deny all.    We 
look at targeted policy as a way
of protecting user space from system space.   Or another way to look at 
it would be putting a firewall around
the users processes and preventing the system spaces from touching 
that.  So one of the goals is to prevent apache
processes from touching user files.  As a by product of this, we are 
actually "fire walling" most applications from
each other, so apache can not touch the name server files, and the name 
server can not touch the apache server.

Strict policy and targeted policy are pretty much the same in FC5 as far 
as system applications are concerned.  Strict policy also tries to limit 
the access of applications that users run like Firefox and evolution.  
There are several problems
here but we are beginning to address some of these by limiting the use 
of executable memory, even in userspace.  We hope to slowly bring 
additional selinux components out into User space.




From galibert at pobox.com  Tue Mar 14 18:56:35 2006
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 14 Mar 2006 19:56:35 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
Message-ID: <20060314185635.GA20490@dspnet.fr.eu.org>

On Tue, Mar 14, 2006 at 09:26:01AM -0700, Stephen J. Smoogen wrote:
> To be honest, we have found that the following people turn off SeLinux
> for the following reasons:
[1-4]

5. They copied their / through remounting and rsync to another
partition on another disk to be able to change the partitions on the
original disk and ended up trying to find out why they couldn't log in
even as root anymore.  Which is fun to debug without the web.  It will
be a large number of years before my GF's brother allows selinux
anywhere his computer.

The selinux cra^Wlabels should have been taken into account in
cp/tar/rsync and other applications that copy executables before
anybody thought about activating it.  Now its reputation is so bad
people will wait for several years before even thinking about trying
it again.  "Failing gracefully" is one of these basic concepts
security people like to ignore or even rant about, forgetting the real
world needs it.  Locking root out of login on the console with its
password typed on the keyboard if some magic, fs-layout-dependant
flags aren't perfectly set in some hidden corner is stupid beyond
belief.  I personally won't ever trust selinux until the mentality
changes.  I don't always have a rescue cd handy.

  OG.



From dcbw at redhat.com  Tue Mar 14 18:56:39 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 14 Mar 2006 13:56:39 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <1142360971.31972.30.camel@animal.passback.co.uk>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142360971.31972.30.camel@animal.passback.co.uk>
Message-ID: <1142362599.26696.5.camel@dhcp83-69.boston.redhat.com>

On Tue, 2006-03-14 at 18:29 +0000, Keith Sharp wrote:
> On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> > Harald Hoyer (harald at redhat.com) said: 
> > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > 
> > This should really be done in NM.
> 
> I may have the wrong end of the stick, but what about the increasingly
> common situation where wired access to Ethernet switches is beings
> controlled by 802.1x authentication?  I understand that NM will handle
> the laptop/workstation with GUI case, but what about servers?  And how
> does NM handle static IP addresses?

The next version is targetting better static IP support and almost
definitely will have wired 802.1x support as well.  (along with
networking-before-login and LEAP)

Dan




From ivg2 at cornell.edu  Tue Mar 14 19:14:23 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Tue, 14 Mar 2006 14:14:23 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416F20C.4060508@redhat.com>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>	<20060314151614.GA26289@devserv.devel.redhat.com>	<4416E6D6.7040109@conversis.de>	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>	<604aa7910603140833x68f2026ei61c415aff35d7ec@mail.gmail.com>
	<4416F20C.4060508@redhat.com>
Message-ID: <4417160F.7070907@cornell.edu>


> http://fedoraproject.org/wiki/SELinux/FAQ/ProposedAdditions#head-6dcc9a7f5f2d7e7ee033e777caacebb434713dd7 
>

> "The most common reason for a silent denial is when the policy 
> contains an explicit dontaudit rule to suppress audit messages. The 
> dontaudit rule is often used this way when a benign denial is filling 
> the audit logs."
..which imho should be considered a bug in 90% of the cases where it's 
used - either a bug in policy, or a bug in the app.

I've seen dontaudits where the app "seems" to work (non-fatal error), 
but a denial is generated, so the dontaudit was added to make it go 
away. This seems completely wrong to me - I disagree with the "benign" 
denial, that's just covering up functionality that doesn't work. There 
should be a comment above every dontaudit that explains why it's needed, 
and why this problem can't be solved otherwise. In fact... it would be 
nice if every sblock of rules had a comment in front of it explaining 
why it's needed in terms of application functionality.

Just my 2c.



From ivg2 at cornell.edu  Tue Mar 14 19:25:04 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Tue, 14 Mar 2006 14:25:04 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <20060314185635.GA20490@dspnet.fr.eu.org>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>	<20060314151614.GA26289@devserv.devel.redhat.com>	<4416E6D6.7040109@conversis.de>	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<20060314185635.GA20490@dspnet.fr.eu.org>
Message-ID: <44171890.5070000@cornell.edu>


> The selinux cra^Wlabels should have been taken into account in
> cp/tar/rsync and other applications that copy executables before
>   
cp has supported selinux for quite some time now.

As far as recovering from disaster is concerned... there's the option of 
turning selinux off, or enabling it in permissive mode via kernel 
parameters, therefore selinux issues are never fatal if you know the 
right options (enforcing=0, or selinux=0).



From enrico.scholz at informatik.tu-chemnitz.de  Tue Mar 14 20:35:06 2006
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 14 Mar 2006 21:35:06 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <80d7e4090603141030s4d42d1d0sf0861d2dea31a01d@mail.gmail.com>
	(Stephen J. Smoogen's message of "Tue,
	14 Mar 2006 11:30:58 -0700")
References: <dv4rq0$csu$1@sea.gmane.org> <4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<17430.62767.42318.610131@zapata.pink>
	<1142359114.31760.12.camel@mccallum.corsepiu.local>
	<80d7e4090603141030s4d42d1d0sf0861d2dea31a01d@mail.gmail.com>
Message-ID: <87u0a0u5mt.fsf@kosh.bigo.ensc.de>

smooge at gmail.com ("Stephen J. Smoogen") writes:

>> Finally, one fundamental problem, probably most users ask them
>> themselves: Is coping with all the issues SELinux causes worth the
>> effort, and does it really help the user?
>>
>> I guess, all Fedora users have been fighting with SELinux at some point
>> in time, but probably nobody or at least very few have seen SELinux
>> preventing damage from a system in real world installations.
>
> I can say that is false. Yes, I had some problems, but instead of
> turning it off I took the time to learn what it wanted.

I took the time to learn how to write SELinux rules and adopted a system
(e.g. chrooted ntpd, non-FC dhcp relay agent). But after each 'yum upgrade'
which installed a new kernel or a new policy I got lot of policy errors
(new/unknown roles, incompatible labels, time consuming relabels or even
reboots were needed for the policy userspace packages) so that I had to
spent a lot of time to fix SELinux issues.

Finally, I found that it is not worth the trouble and turned SELinux
off. Applications were and are protected by proper configuration,
traditional security measurements (non-root execution, chroots) and
easier to manage security models (Linux VServers).


SELinux is unsuitable for certain tasks (e.g. chroot operations) due to its
broken/non existent kernel API (requiring two filesystems and operating
with pathnames is not very efficient, difficultly/insecure and does not
work in chroots). SELinux seems to have a big performance impact too (I
remember numbers of 5-7% but did not measured them myself).

'cfengine' provides the largest attack vectors in my systems and I do
not see how SELinux can help to protect this program.




Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060314/d1c6f69b/attachment.sig>

From tjb at unh.edu  Tue Mar 14 21:01:00 2006
From: tjb at unh.edu (Thomas J. Baker)
Date: Tue, 14 Mar 2006 16:01:00 -0500
Subject: Lower Window Keybinding
Message-ID: <1142370060.31688.21.camel@zero.sr.unh.edu>


A while back my lower-window keybinding stopped working and I filed a
bug against metacity. Turns out it wasn't metacity because it started
working after an update and metacity hadn't changed. Well, it's back and
even though metacity has been updated, I don't believe it's metacity's
fault given past history.

So when I type my lower-window keybinding on a window I want lowered,
all that happens is the window becomes unfocused. It does not lower and
it's not clear where the focus goes.

Anyone else having this problem? Anyone care to guess which component
might be responsible if it's not metacity?

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



From kwade at redhat.com  Tue Mar 14 21:05:28 2006
From: kwade at redhat.com (Karsten Wade)
Date: Tue, 14 Mar 2006 13:05:28 -0800
Subject: No more selinux-policy-*-sources
In-Reply-To: <4416E26B.7060502@shahms.com>
References: <dv4rq0$csu$1@sea.gmane.org> <4416DA8B.4050601@redhat.com>
	<4416E26B.7060502@shahms.com>
Message-ID: <1142370329.3270.77.camel@erato.phig.org>

On Tue, 2006-03-14 at 07:34 -0800, Shahms King wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel J Walsh wrote:
> > Orion Poplawski wrote:
> > 
> >> I there some docs (FAQ/ReleaseNotes?) that describe how to make
> >> changes to policy in FC5?
> >>
> > http://fedoraproject.org/wiki/SELinux/FAQ/ProposedAdditions
> > 
> 
> This should be widely linked and become well known. 

Please do not link to that page.  As it says, it is proposed additions.

The new maintainer of the SELinux FAQ is intending to have an updated
FAQ for the FC 5 release.  I'm working with him to help make this
happen.

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
Content Services                          Fedora Documentation Project
http://www.redhat.com/docs   http://fedoraproject.org/wiki/DocsProject
-------------- 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/20060314/40f1ef75/attachment.sig>

From cmadams at hiwaay.net  Tue Mar 14 22:03:05 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 14 Mar 2006 16:03:05 -0600
Subject: No more selinux-policy-*-sources
In-Reply-To: <44171890.5070000@cornell.edu>
References: <1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<20060314185635.GA20490@dspnet.fr.eu.org>
	<44171890.5070000@cornell.edu>
Message-ID: <20060314220305.GD1305620@hiwaay.net>

Once upon a time, Ivan Gyurdiev <ivg2 at cornell.edu> said:
> cp has supported selinux for quite some time now.

The fact that it "supports" SELinux by adding a new option doesn't
really help.  People know "cp -p" to preserve ownership and permissions,
but you have to use (the annoyingly verbose) "cp --preserve=all" to get
SELinux attributes.
-- 
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  Tue Mar 14 22:04:54 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 14 Mar 2006 16:04:54 -0600
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060314172622.GA22376@devserv.devel.redhat.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
Message-ID: <20060314220454.GE1305620@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> Harald Hoyer (harald at redhat.com) said: 
> > What do you think about the attached patch to ifup-wireless? Works for me :)
> 
> This should really be done in NM.

NM doesn't support system network configuration; only when a user logs
in will NM work.  That is supposed to change eventually, but people are
trying to use WPA today.
-- 
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 bojan at rexursive.com  Tue Mar 14 22:58:01 2006
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 15 Mar 2006 09:58:01 +1100
Subject: Recent kernels hang on resume
In-Reply-To: <1142115142.2001.10.camel@coyote.rexursive.com>
References: <1142115142.2001.10.camel@coyote.rexursive.com>
Message-ID: <20060315095801.5eg8axz128ggs0ok@www.rexursive.com>

Quoting Bojan Smojver <bojan at rexursive.com>:

> Stopping tasks: =

Just before that, the keyboard/touchpad gets initialised, so maybe I'm 
hitting this:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bd0ee93fef9733c72fef1817330b3ee2b71cf9d

-- 
Bojan



From mhw at wittsend.com  Tue Mar 14 23:02:31 2006
From: mhw at wittsend.com (Michael H. Warfield)
Date: Tue, 14 Mar 2006 18:02:31 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060314172622.GA22376@devserv.devel.redhat.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
Message-ID: <1142377351.5070.5.camel@canyon.wittsend.com>

On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> Harald Hoyer (harald at redhat.com) said: 
> > What do you think about the attached patch to ifup-wireless? Works for me :)

> This should really be done in NM.

	Some of us would prefer to avoid being plagued by NM.  It
(wpa_supplicant) works just fine, independent of NM and I've just got it
hooked in the bottom of the ifup scripts as they describe doing on the
project site.  So far, I haven't found a problem that NM solves for me
and a few that it creates for me.  NM and wpa_supplicant should each be
optional and orthogonal to each other.

> Bill

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

From mharris at mharris.ca  Tue Mar 14 23:07:18 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Tue, 14 Mar 2006 18:07:18 -0500
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <4416C371.7000603@gmail.com>
References: <440CD6DC.6020903@redhat.com> <20060308153307.GF2238@free.fr>
	<20060308164612.1edb3f29@soran.addix.net>
	<20060308160409.GI2238@free.fr>
	<20060308171123.04f74390@soran.addix.net> <4416C371.7000603@gmail.com>
Message-ID: <44174CA6.7060008@mharris.ca>

Bill Crawford wrote:
> Ralf Ertzinger wrote:
> 
>> Hi.
>>
>> On Wed, 8 Mar 2006 17:04:09 +0100, Patrice Dumas wrote:
>>
>>  
>>
>>> [dumas at nor75-15-82-67-190-22 include]$ rpm
>>> -qf /usr/X11R6/include/Mrm/MrmAppl.h openmotif-devel-2.3.0-0.1.9.2
>>> [dumas at nor75-15-82-67-190-22 include]$ rpm -qf /usr/X11R6/include/Mrm/
>>> file /usr/X11R6/include/Mrm is not owned by any package
>>>
>>>    
>>>
>>>> If yes, does rpm -ql openmotif show any files in /usr/X11R6?
>>>>       
>>>
>>> No they appear to be in /usr/include [dumas at nor75-15-82-67-190-22 
>>> include]$ rpm -ql openmotif-devel | grep
>>> X11R6
>>>
>>> echoes nothing, and there is:
>>>
>>> [dumas at nor75-15-82-67-190-22 include]$ rpm -ql openmotif-devel | grep
>>> MrmAppl.h /usr/include/Mrm/MrmAppl.h
>>>     
>>
>>
>> I had the same effect while migrating to modular X. Maybe someone more
>> versed in RPM internals can tell why RPM thinks that oponmotif owns
>> files in /usr/X11R6 when rpm -ql show none of those files.

Rawhide developmental growing pains.  Clean OS installs will not have
this problem, and upgrades direct from FC3/FC4 or older to FC5 final
should either not have this problem, or should have very minimal
issues at best.

Any systems which have tracked rawhide from November or so in an ongoing
basis, may have random files in /usr/X11R6 which are not owned by any
rpm packages anymore.

This is due to longstanding (and aparently permanent) limitation in rpm,
which can not replace a directory with a symlink, nor a symlink with
a directory when upgrading packages.  (It also can't replace a dir with
a file I've since discovered with the xkbdata package.)

Since it was mandatorily required that the dir/symlink be replaced in
this case, due to this rpm bug a workaround was required which had these
negative (but temporary) side effects, which only affected rawhide
systems.

The xorg-x11-filesystem package was created as the workaround for this
issue, because it had to be worked around via rpm %post scripts which
were ran during upgrades and guaranteed to occur prior to other packages
getting installed.  The "filesystem" package would have been the first
choice to use, but that package can not have any rpm scripts present in
it, because it is one of the first packages installed on the system.


> The files in the -devel package install to /usr/include/X11 which was 
> (and might still be, if rpm -qf is reporting ownership of those files) 
> symlinked to /usr/X11R6/include/X11

All of the X library -devel subpackages contain:

Requires(pre): xorg-x11-filesystem >= 0.99.2-3

That enforces that xorg-x11-filesystem gets installed first, which fixes
the directory/symlink problem, ensuring that the -devel packages get
installed into the proper location and end up managed by rpm.

All of the modular X packages which install files into a directory which
used to be a symlink previously, now depend on xorg-x11-filesystem being
installed first, using the above hard coded dependency.



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From dominik at greysector.net  Wed Mar 15 01:02:07 2006
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 15 Mar 2006 02:02:07 +0100
Subject: wpa_supplicant support for ifup
In-Reply-To: <1142377351.5070.5.camel@canyon.wittsend.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142377351.5070.5.camel@canyon.wittsend.com>
Message-ID: <20060315010207.GD8792@rathann.pekin.waw.pl>

On Wednesday, 15 March 2006 at 00:02, Michael H. Warfield wrote:
> On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> > Harald Hoyer (harald at redhat.com) said: 
> > > What do you think about the attached patch to ifup-wireless? Works for me :)
> 
> > This should really be done in NM.
> 
> 	Some of us would prefer to avoid being plagued by NM.  It
> (wpa_supplicant) works just fine, independent of NM and I've just got it
> hooked in the bottom of the ifup scripts as they describe doing on the
> project site.  So far, I haven't found a problem that NM solves for me
> and a few that it creates for me.  NM and wpa_supplicant should each be
> optional and orthogonal to each other.

+1

Personally, I find NM quite troublesome and the named dependency puts me
off immensely. Why the hell do I need to install a domain name server(!)
on a laptop? I'm sticking with ifup/ifdown for the time being.

Regards,
R.

-- 
       RPM repository for Fedora Core http://rpm.greysector.net/
mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jon.nettleton at gmail.com  Wed Mar 15 01:23:25 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Tue, 14 Mar 2006 20:23:25 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060315010207.GD8792@rathann.pekin.waw.pl>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142377351.5070.5.camel@canyon.wittsend.com>
	<20060315010207.GD8792@rathann.pekin.waw.pl>
Message-ID: <1142385805.9438.4.camel@averatec>

On Wed, 2006-03-15 at 02:02 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 15 March 2006 at 00:02, Michael H. Warfield wrote:
> > On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> > > Harald Hoyer (harald at redhat.com) said: 
> > > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > 
> > > This should really be done in NM.
> > 
> > 	Some of us would prefer to avoid being plagued by NM.  It
> > (wpa_supplicant) works just fine, independent of NM and I've just got it
> > hooked in the bottom of the ifup scripts as they describe doing on the
> > project site.  So far, I haven't found a problem that NM solves for me
> > and a few that it creates for me.  NM and wpa_supplicant should each be
> > optional and orthogonal to each other.
> 
> +1
> 
> Personally, I find NM quite troublesome and the named dependency puts me
> off immensely. Why the hell do I need to install a domain name server(!)
> on a laptop? I'm sticking with ifup/ifdown for the time being.
> 
This is completely off topic, but if you want to stick with ifup ifdown,
check out my old patches here,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132661

They provide scanning ap's at boot and choosing the correct wireless
config if your configs are name called ifcfg-ethx_essidname .  I found
it useful when switching from location to location back in the day.  If
you need help tweaking it mail me off the list.

Jon





From admin at ramshacklestudios.com  Wed Mar 15 02:47:31 2006
From: admin at ramshacklestudios.com (Peter Gordon)
Date: Tue, 14 Mar 2006 18:47:31 -0800
Subject: mock question
In-Reply-To: <d5ad21470603140948g5886ce68hf41a84e7cd66516e@mail.gmail.com>
References: <d5ad21470603140948g5886ce68hf41a84e7cd66516e@mail.gmail.com>
Message-ID: <1142390851.3547.8.camel@tuxhugger>

On Tue, 2006-03-14 at 18:48 +0100, Gianluca Sforna wrote:
> may I use mock to test compilation of the 64bit variant of a rpm using
> my regular 32bit centrino laptop?
> 
No. Generally speaking, you can build and run 32-bit code on a 64-bit
systems, but not vice-versa.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xDA3634D7
Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060314/75855eac/attachment.sig>

From notting at redhat.com  Wed Mar 15 02:51:24 2006
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 14 Mar 2006 21:51:24 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060314220454.GE1305620@hiwaay.net>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
Message-ID: <20060315025124.GB4248@devserv.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > 
> > This should really be done in NM.
> 
> NM doesn't support system network configuration; only when a user logs
> in will NM work.  That is supposed to change eventually, but people are
> trying to use WPA today.

True. But the goal is to only have *one* source of network configuration;
hence, I'm leery to add features for something that we're going to be
deprecating. (It's obviously late for FC5 final.)

I'll look at it some more.

Bill



From notting at redhat.com  Wed Mar 15 02:52:17 2006
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 14 Mar 2006 21:52:17 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <1142377351.5070.5.camel@canyon.wittsend.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142377351.5070.5.camel@canyon.wittsend.com>
Message-ID: <20060315025216.GC4248@devserv.devel.redhat.com>

Michael H. Warfield (mhw at wittsend.com) said: 
> 	Some of us would prefer to avoid being plagued by NM.  It
> (wpa_supplicant) works just fine, independent of NM and I've just got it
> hooked in the bottom of the ifup scripts as they describe doing on the
> project site.  So far, I haven't found a problem that NM solves for me
> and a few that it creates for me.  NM and wpa_supplicant should each be
> optional and orthogonal to each other.

That's implying that there should always be two completely disparate
and conflicting sources of network configuration (NM and ifcfg-X); I
really don't think that's practical long-term.

Bill



From dcbw at redhat.com  Wed Mar 15 02:50:25 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 14 Mar 2006 21:50:25 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060315010207.GD8792@rathann.pekin.waw.pl>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142377351.5070.5.camel@canyon.wittsend.com>
	<20060315010207.GD8792@rathann.pekin.waw.pl>
Message-ID: <1142391025.2385.16.camel@localhost.localdomain>

On Wed, 2006-03-15 at 02:02 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 15 March 2006 at 00:02, Michael H. Warfield wrote:
> > On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> > > Harald Hoyer (harald at redhat.com) said: 
> > > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > 
> > > This should really be done in NM.
> > 
> > 	Some of us would prefer to avoid being plagued by NM.  It
> > (wpa_supplicant) works just fine, independent of NM and I've just got it
> > hooked in the bottom of the ifup scripts as they describe doing on the
> > project site.  So far, I haven't found a problem that NM solves for me
> > and a few that it creates for me.  NM and wpa_supplicant should each be
> > optional and orthogonal to each other.
> 
> +1
> 
> Personally, I find NM quite troublesome and the named dependency puts me
> off immensely. Why the hell do I need to install a domain name server(!)
> on a laptop? I'm sticking with ifup/ifdown for the time being.

For a few reasons:

1) because if at any point you change a network with your laptop, it
takes up to 30 seconds for Mozilla and most other apps to notice.
Ubuntu even patches glibc to stat /etc/resolv.conf fairly often, just so
this doesn't happen!  Which is something upstream glibc refused to do.  

2) You can't do split DNS with glibc.  When using a VPN, split DNS means
directing only requests for stuff on the VPN to the VPN's name servers.
while cnn.com goes to your local nameservers, not the VPN's.  We don't
do that quite yet, but we planned for it, will do it soon, and named
allows for that.  glibc doesn't, and upstream doesn't want to add that
capability.

3) If you don't like named, DON'T USE IT.  What you don't seem to
realize is that NM doesn't require named.  It doesn't launch named.  It
doesn't use named unless named is running, and named's dbus service is
enabled.  NM will happily write /etc/resolv.conf, just like you want, if
you don't run named.  The choice is, actually, up to you.

So running a local nameserver, and pointing everything to 127.0.0.1
works out quite nicely.  I'm not quite sure what your problem is here,
since you don't even have to use named at all.

Dan




From jon.nettleton at gmail.com  Wed Mar 15 03:01:17 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Tue, 14 Mar 2006 22:01:17 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060315025124.GB4248@devserv.devel.redhat.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
Message-ID: <1142391678.9438.11.camel@averatec>

On Tue, 2006-03-14 at 21:51 -0500, Bill Nottingham wrote:
> Chris Adams (cmadams at hiwaay.net) said: 
> > > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > > 
> > > This should really be done in NM.
> > 
> > NM doesn't support system network configuration; only when a user logs
> > in will NM work.  That is supposed to change eventually, but people are
> > trying to use WPA today.
> 
> True. But the goal is to only have *one* source of network configuration;
> hence, I'm leery to add features for something that we're going to be
> deprecating. (It's obviously late for FC5 final.)
> 
> I'll look at it some more.
> 
> Bill
> 

I am still not sure why people feel we need to run a networking daemon
and client to configure a single static ip address for a server, or a
wireless desktop that only connects to one network.  It seems like we
are starting to get as piggish of resources as other operating systems.
Not everyone has a laptop they drag around and connect to every network
under the sun, and then vpn back somewhere else.  Sure that is becoming
more common, but there are plenty of machines that just sit there with
an ipv4 dhcp given address and run.

Jon



From jon.nettleton at gmail.com  Wed Mar 15 03:01:17 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Tue, 14 Mar 2006 22:01:17 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060315025124.GB4248@devserv.devel.redhat.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
Message-ID: <1142391678.9438.11.camel@averatec>

On Tue, 2006-03-14 at 21:51 -0500, Bill Nottingham wrote:
> Chris Adams (cmadams at hiwaay.net) said: 
> > > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > > 
> > > This should really be done in NM.
> > 
> > NM doesn't support system network configuration; only when a user logs
> > in will NM work.  That is supposed to change eventually, but people are
> > trying to use WPA today.
> 
> True. But the goal is to only have *one* source of network configuration;
> hence, I'm leery to add features for something that we're going to be
> deprecating. (It's obviously late for FC5 final.)
> 
> I'll look at it some more.
> 
> Bill
> 

I am still not sure why people feel we need to run a networking daemon
and client to configure a single static ip address for a server, or a
wireless desktop that only connects to one network.  It seems like we
are starting to get as piggish of resources as other operating systems.
Not everyone has a laptop they drag around and connect to every network
under the sun, and then vpn back somewhere else.  Sure that is becoming
more common, but there are plenty of machines that just sit there with
an ipv4 dhcp given address and run.

Jon



From jon.nettleton at gmail.com  Wed Mar 15 03:54:58 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Tue, 14 Mar 2006 22:54:58 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060315025216.GC4248@devserv.devel.redhat.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142377351.5070.5.camel@canyon.wittsend.com>
	<20060315025216.GC4248@devserv.devel.redhat.com>
Message-ID: <1142394899.9438.36.camel@averatec>

On Tue, 2006-03-14 at 21:52 -0500, Bill Nottingham wrote:
> Michael H. Warfield (mhw at wittsend.com) said: 
> > 	Some of us would prefer to avoid being plagued by NM.  It
> > (wpa_supplicant) works just fine, independent of NM and I've just got it
> > hooked in the bottom of the ifup scripts as they describe doing on the
> > project site.  So far, I haven't found a problem that NM solves for me
> > and a few that it creates for me.  NM and wpa_supplicant should each be
> > optional and orthogonal to each other.
> 
> That's implying that there should always be two completely disparate
> and conflicting sources of network configuration (NM and ifcfg-X); I
> really don't think that's practical long-term.
> 
> Bill
> 
Why are these understood as conlicting and disparate?  The way I see it,
is in the system-config-network gui you ask "activate on boot", and
"allow user to control". Why not ask "controlled by NetworkManager" that
just turns off the other two options, and in the Redhat specific
NetworkManager code write functions that look for that setting to know
whether or not to configure that interface?

I like NetworkManager and use it, but only on the laptop that I connect
to a lot of networks on ( and until NetworkManager can map different
firewall settings to a connection it is still cumbersome).  I haven't
read a convincing reason to not use ifcfg scripts for basic, repetitive,
static network configuration.

Sorry about being so opinionated about this subject.  I just feel the
direction this distro is going in concerns to this subject is losing
touch with how people use it.  It is great to be excited about allowing
a laptop to connect to lots of networks easily, but that is completely
useless for a desktop, or a server.

Jon




From buildsys at redhat.com  Wed Mar 15 08:19:47 2006
From: buildsys at redhat.com (Build System)
Date: Wed, 15 Mar 2006 03:19:47 -0500
Subject: rawhide report: 20060315 changes
Message-ID: <200603150819.k2F8Jl0L019777@porkchop.devel.redhat.com>

New package gnome-backgrounds
	Desktop backgrounds packaged with the GNOME desktop


 
Updated Packages:

GFS-kernel-2.6.15.1-5.FC5.17
----------------------------
* Tue Mar 14 2006 Chris Feist <cfeist at Redhat.com>
- Removed 'ARCH=xen' for xen builds.

NetworkManager-0.6.0-3
----------------------
* Tue Mar 14 2006 Peter Jones <pjones at redhat.com> - 0.6.0-3
- Fix device bringup on resume

ORBit2-2.14.0-1
---------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> - 2.14.1-1
- Update to 2.14.1

anaconda-11.0.5-1
-----------------
* Tue Mar 14 2006 Paul Nasrat <pnasrat at redhat.com> 11.0.5-1
- Fix import for rescue mode

* Tue Mar 14 2006 Chris Lumens <clumens at redhat.com> 11.0.4-1
- Remove Amharic and Thai from lang-table

bluez-pin-0.30-2
----------------
* Tue Mar 14 2006 david Woodhouse <dwmw2 at redhat.com> - 0.30-2
- Don't abort when user cancels a PIN request

* Tue Mar 14 2006 david Woodhouse <dwmw2 at redhat.com> - 0.30-1
- Update to bluez-pin 0.27, patched to 0.30 to avoid autocrap breakage
- Fix dbus harder
- Run automatically in X session

bluez-utils-2.25-4
------------------
* Tue Mar 14 2006 David Woodhouse <dwmw2 at redhat.com> - 2.25-4
- Require bluez-pin, since we're configured to use it by default

booty-0.71-1
------------
* Tue Mar 14 2006 Peter Jones <pjones at redhat.com> - 0.71-1
- pass through pci= boot arguments

cman-kernel-2.6.15.1-0.FC5.16
-----------------------------
* Tue Mar 14 2006 Chris Feist <cfeist at redhat.com>
- Removed 'ARCH=xen' for xen builds.

dasher-4.0.0-1
--------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 4.0.0-1
- Update to 4.0.0

dlm-kernel-2.6.15.1-0.FC5.14
----------------------------
* Tue Mar 14 2006 Chris Feist <cfeist at redhat.com>
- Removed 'ARCH=xen' for xen builds.

ekiga-2.0.1-1
-------------
* Tue Mar 14 2006 Daniel Veillard <veillard at redhat.com> - 2.0.1
- last minute bug rerelease 2.0.1

* Mon Mar 13 2006 Daniel Veillard <veillard at redhat.com> - 2.0.0
- final release of 2.0.0

evolution-2.6.0-1
-----------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.6.0-1
- 2.6.0
- turn on the "error on missing prototypes" check thing

* Mon Feb 27 2006 Ray Strode <rstrode at redhat.com> - 2.5.92-1
- 2.5.92

* Tue Feb 14 2006 David Malcolm <dmalcolm at redhat.com> - 2.5.91-1
- 2.5.91
- updated patch 101 to track upstream changes to calendar printing code
- remove uptreamed patch 807 (NM multiple initialization assertion)
- readded the mail-to-task plugin XML UI file
- bump e-d-s req to 1.5.91

gnbd-kernel-2.6.15-5.FC5.23
---------------------------
* Tue Mar 14 2006 Chris Feist <cfeist at Redhat.com>
- Removed 'ARCH=xen' for xen builds.

gnome-desktop-2.14.0-1
----------------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- Update to 2.14.0

gnome-media-2.14.0-2
--------------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-2
- rebuild

* Sun Mar 12 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

gnome-panel-2.14.0-1
--------------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- update to 2.14.0

gnome-python2-desktop-2.14.0-1
------------------------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.de> 2.14.0-1
- Update to 2.14.0
gnome-themes-2.14.0-1
---------------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- Update to 2.14.0

initscripts-8.31.1-1
--------------------
* Tue Mar 14 2006 Bill Nottingham <notting at redhat.com> 8.31.1-1
- fix context of /dev/pts (#185436)
- translation updates

kernel-2.6.15-1.2054_FC5
------------------------
* Tue Mar 14 2006 Dave Jones <davej at redhat.com>
- 2.6.16-rc6-git3

* Tue Mar 14 2006 David Woodhouse <dwmw2 at redhat.com>
- Recognise 'IBM,CBEA' as Cell platform too.

* Mon Mar 13 2006 Rik van Riel <riel at redhat.com>
- fix "Time went backwards" Xen kernel bug. (#185317)

kudzu-1.2.34.3-1
----------------
* Tue Mar 14 2006 Bill Nottingham <notting at redhat.com> - 1.2.34.3-1
- fix scsi probe to not return devices of the wrong class

libbonobo-2.14.0-1
------------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> 2.14.0-1
- Update to 2.14.0

libbonoboui-2.14.0-1
--------------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> 2.14.0-1
- Update to 2.14.0

libwnck-2.14.0-1
----------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- Update to 2.14.0

nautilus-cd-burner-2.14.0.1-1
-----------------------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.14.0.1-1
- Update to 2.14.0.1

* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 2.14.0-1
- Update to 2.14.0

* Mon Feb 27 2006 Matthias Clasen <mclasen at redhat.com> - 2.13.92-2
- Add a Req for gnome-mount

opal-2.2.1-1
------------
* Tue Mar 14 2006 Daniel Veillard <veillard at redhat.com> - 2.2.1-1
- last minute break fix and new release

parted-1.6.25-8
---------------
* Tue Mar 14 2006 Jeremy Katz <katzj at redhat.com> - 1.6.25-8
- fix ppc swraid
- BR gettext-devel

python-urlgrabber-2.9.8-2
-------------------------
* Tue Mar 14 2006 Jeremy Katz <katzj at redhat.com> - 2.9.8-2
- catch read errors so they trigger the failure callback.  helps catch bad cds




Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5








From paul at city-fan.org  Wed Mar 15 09:52:29 2006
From: paul at city-fan.org (Paul Howarth)
Date: Wed, 15 Mar 2006 09:52:29 +0000
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142359114.31760.12.camel@mccallum.corsepiu.local>
References: <dv4rq0$csu$1@sea.gmane.org>	<1142325106.12438.13.camel@laurel.intra.city-fan.org>	<4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>	<1142345596.3027.38.camel@laptopd505.fenrus.org>	<4416D22D.30604@conversis.de>	<20060314151614.GA26289@devserv.devel.redhat.com>	<4416E6D6.7040109@conversis.de>	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>	<17430.62767.42318.610131@zapata.pink>
	<1142359114.31760.12.camel@mccallum.corsepiu.local>
Message-ID: <4417E3DD.8040201@city-fan.org>

Ralf Corsepius wrote:
> Fundamental design problem: SELinux policies are centralized and
> therefore not easy to customize.

As of FC5 this is no longer the case. Packages can bundle SELinux policy 
modules, which provides for relatively easy customisation.

Paul.



From nicolas.mailhot at laposte.net  Wed Mar 15 10:50:42 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 15 Mar 2006 11:50:42 +0100 (CET)
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060315025124.GB4248@devserv.devel.redhat.com>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
Message-ID: <34931.192.54.193.51.1142419842.squirrel@rousalka.dyndns.org>


Le Mer 15 mars 2006 03:51, Bill Nottingham a ?crit :
> Chris Adams (cmadams at hiwaay.net) said:
>> > > What do you think about the attached patch to ifup-wireless? Works
>> for me :)
>> >
>> > This should really be done in NM.
>>
>> NM doesn't support system network configuration; only when a user logs
>> in will NM work.  That is supposed to change eventually, but people are
>> trying to use WPA today.
>
> True. But the goal is to only have *one* source of network configuration;

If you want this NM, gnome-power-manager and other GFX tools need to grow
a CLI/daemon personality ASAP.

You can't complain no one wants to rely on them if they deliberately
ignore everything that's not an open Gnome session.

> hence, I'm leery to add features for something that we're going to be
> deprecating.

If the new utilities stick to the gui session ghetto they'll be the ones
deprecated eventually.

Red Hat/Fedora unfortunately has a long history of writing gui management
utilities (printing, package management...) that were never designed to
provide full needs coverage, couldn't be extended to do it and eventually
were axed because of this. I'd be delighted to learn this has changed but
for now I wouldn't bet on what will eventually be deprecated.

Please do feel free to correct me.

Regards,

-- 
Nicolas Mailhot



From hughsient at gmail.com  Wed Mar 15 11:08:33 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 15 Mar 2006 11:08:33 +0000
Subject: wpa_supplicant support for ifup
In-Reply-To: <34931.192.54.193.51.1142419842.squirrel@rousalka.dyndns.org>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
	<34931.192.54.193.51.1142419842.squirrel@rousalka.dyndns.org>
Message-ID: <1142420913.3567.3.camel@localhost.localdomain>

On Wed, 2006-03-15 at 11:50 +0100, Nicolas Mailhot wrote:
> Le Mer 15 mars 2006 03:51, Bill Nottingham a ?crit :
> > Chris Adams (cmadams at hiwaay.net) said:
> >> > > What do you think about the attached patch to ifup-wireless? Works
> >> for me :)
> >> >
> >> > This should really be done in NM.
> >>
> >> NM doesn't support system network configuration; only when a user logs
> >> in will NM work.  That is supposed to change eventually, but people are
> >> trying to use WPA today.
> >
> > True. But the goal is to only have *one* source of network configuration;
> 
> If you want this NM, gnome-power-manager and other GFX tools need to grow
> a CLI/daemon personality ASAP.

You can control DPMS and suspend features with dbus with
gnome-power-manager. See docs/dbus-interface.txt [1]

Richard.

[1]
http://cvs.gnome.org/viewcvs/gnome-power-manager/docs/dbus-interface.txt?rev=1.3&view=markup



From dominik at greysector.net  Wed Mar 15 11:25:20 2006
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 15 Mar 2006 12:25:20 +0100
Subject: wpa_supplicant support for ifup
In-Reply-To: <1142391025.2385.16.camel@localhost.localdomain>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142377351.5070.5.camel@canyon.wittsend.com>
	<20060315010207.GD8792@rathann.pekin.waw.pl>
	<1142391025.2385.16.camel@localhost.localdomain>
Message-ID: <20060315112520.GA3304@rathann.pekin.waw.pl>

On Wednesday, 15 March 2006 at 03:50, Dan Williams wrote:
> On Wed, 2006-03-15 at 02:02 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > On Wednesday, 15 March 2006 at 00:02, Michael H. Warfield wrote:
> > > On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> > > > Harald Hoyer (harald at redhat.com) said: 
> > > > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > > 
> > > > This should really be done in NM.
> > > 
> > > 	Some of us would prefer to avoid being plagued by NM.  It
> > > (wpa_supplicant) works just fine, independent of NM and I've just got it
> > > hooked in the bottom of the ifup scripts as they describe doing on the
> > > project site.  So far, I haven't found a problem that NM solves for me
> > > and a few that it creates for me.  NM and wpa_supplicant should each be
> > > optional and orthogonal to each other.
> > 
> > +1
> > 
> > Personally, I find NM quite troublesome and the named dependency puts me
> > off immensely. Why the hell do I need to install a domain name server(!)
> > on a laptop? I'm sticking with ifup/ifdown for the time being.
> 
> For a few reasons:

[snip reasons I don't really care about]

> 3) If you don't like named, DON'T USE IT.  What you don't seem to
> realize is that NM doesn't require named.  It doesn't launch named.  It
> doesn't use named unless named is running, and named's dbus service is
> enabled.  NM will happily write /etc/resolv.conf, just like you want, if
> you don't run named.  The choice is, actually, up to you.

Please check the facts before replying with such confidence. I suggest you
look at the spec again (version 0.6.0-3):

Requires: caching-nameserver
[...]
Requires: bind >= %{bind_version}

This pulls in named when installing NetworkManager via yum. Sure, I can
*disable* named, but it still sits on my HDD. I don't want it installed in
the first place.

Remove this (explicit) dependency, and I'll be happy to forget ifup.

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

Regards,
R.

-- 
       RPM repository for Fedora Core http://rpm.greysector.net/
mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From nicolas.mailhot at laposte.net  Wed Mar 15 10:54:54 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 15 Mar 2006 11:54:54 +0100 (CET)
Subject: wpa_supplicant support for ifup
In-Reply-To: <1142391678.9438.11.camel@averatec>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
	<1142391678.9438.11.camel@averatec>
Message-ID: <11891.192.54.193.53.1142420094.squirrel@rousalka.dyndns.org>


Le Mer 15 mars 2006 04:01, Jon Nettleton a ?crit :

> I am still not sure why people feel we need to run a networking daemon
> and client to configure a single static ip address for a server, or a
> wireless desktop that only connects to one network.

For server you don't use wireless but bonding/failover but either way your
networking system needs to be able to adapt gracefully to link changes
without requiring someone to change static config manually (you can
configure bonding statically but it's far from ideal)

A properly written network management daemon helps everyone, from the
tablet to the cluster farm.

-- 
Nicolas Mailhot



From dcbw at redhat.com  Wed Mar 15 12:58:04 2006
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 15 Mar 2006 07:58:04 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <34931.192.54.193.51.1142419842.squirrel@rousalka.dyndns.org>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
	<34931.192.54.193.51.1142419842.squirrel@rousalka.dyndns.org>
Message-ID: <1142427485.2401.2.camel@localhost.localdomain>

On Wed, 2006-03-15 at 11:50 +0100, Nicolas Mailhot wrote:
> Le Mer 15 mars 2006 03:51, Bill Nottingham a ?crit :
> > Chris Adams (cmadams at hiwaay.net) said:
> >> > > What do you think about the attached patch to ifup-wireless? Works
> >> for me :)
> >> >
> >> > This should really be done in NM.
> >>
> >> NM doesn't support system network configuration; only when a user logs
> >> in will NM work.  That is supposed to change eventually, but people are
> >> trying to use WPA today.
> >
> > True. But the goal is to only have *one* source of network configuration;
> 
> If you want this NM, gnome-power-manager and other GFX tools need to grow
> a CLI/daemon personality ASAP.

You can do this for any service that exposes a dbus interface.  Nothing
stops your from using dbus-send on the CLI, or whipping up your own
scripts, to do this Right Now.  What you imply is missing is either 1) a
set of tools like ifconfig/ip/ifup/ifdown/etc that all perform discrete
functions in isolation of each other, or 2) a CLI client with an
interface like mysql or pgsql.

Dan




From dcbw at redhat.com  Wed Mar 15 13:04:07 2006
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 15 Mar 2006 08:04:07 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <20060315112520.GA3304@rathann.pekin.waw.pl>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<1142377351.5070.5.camel@canyon.wittsend.com>
	<20060315010207.GD8792@rathann.pekin.waw.pl>
	<1142391025.2385.16.camel@localhost.localdomain>
	<20060315112520.GA3304@rathann.pekin.waw.pl>
Message-ID: <1142427848.2401.9.camel@localhost.localdomain>

On Wed, 2006-03-15 at 12:25 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 15 March 2006 at 03:50, Dan Williams wrote:
> > On Wed, 2006-03-15 at 02:02 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > > On Wednesday, 15 March 2006 at 00:02, Michael H. Warfield wrote:
> > > > On Tue, 2006-03-14 at 12:26 -0500, Bill Nottingham wrote:
> > > > > Harald Hoyer (harald at redhat.com) said: 
> > > > > > What do you think about the attached patch to ifup-wireless? Works for me :)
> > > > 
> > > > > This should really be done in NM.
> > > > 
> > > > 	Some of us would prefer to avoid being plagued by NM.  It
> > > > (wpa_supplicant) works just fine, independent of NM and I've just got it
> > > > hooked in the bottom of the ifup scripts as they describe doing on the
> > > > project site.  So far, I haven't found a problem that NM solves for me
> > > > and a few that it creates for me.  NM and wpa_supplicant should each be
> > > > optional and orthogonal to each other.
> > > 
> > > +1
> > > 
> > > Personally, I find NM quite troublesome and the named dependency puts me
> > > off immensely. Why the hell do I need to install a domain name server(!)
> > > on a laptop? I'm sticking with ifup/ifdown for the time being.
> > 
> > For a few reasons:
> 
> [snip reasons I don't really care about]
> 
> > 3) If you don't like named, DON'T USE IT.  What you don't seem to
> > realize is that NM doesn't require named.  It doesn't launch named.  It
> > doesn't use named unless named is running, and named's dbus service is
> > enabled.  NM will happily write /etc/resolv.conf, just like you want, if
> > you don't run named.  The choice is, actually, up to you.
> 
> Please check the facts before replying with such confidence. I suggest you
> look at the spec again (version 0.6.0-3):

I help work on NetworkManager, and I'm responsible for packaging it in
Fedora.  So I sure do know what's going on with it, thanks.

The point here is that upstream NetworkManager does _not_ require named.
SUSE doesn't ship with it on, neither does Ubuntu.  In Fedora we made
the decision to use named to get a better experience for laptop and
mobile users.  That includes requiring caching-nameserver in the
specfile.

What you're complaining about is that the current Fedora package doesn't
fit your exact use case.  That's fine.  When writing software you don't
try to please everyone right away, because then you fail.  And because
it doesn't meet your exact use case right now, it requires package that
you don't wish to install.  Right now the tradeoff is that it works for
a lot of other people, but it doesn't work for you.  That's acceptable
to me.

BUT, we want it to work for you in the near future.  As NetworkManager
is gradually expanded, in a maintainable and _responsible_ way, it's
going to cover more and more use-cases, including ones like yours.  This
will hopefully happen in the FC6 timeframe.

Dan




From tjb at unh.edu  Wed Mar 15 13:58:09 2006
From: tjb at unh.edu (Thomas J. Baker)
Date: Wed, 15 Mar 2006 08:58:09 -0500
Subject: Lower Window Keybinding
In-Reply-To: <1142370060.31688.21.camel@zero.sr.unh.edu>
References: <1142370060.31688.21.camel@zero.sr.unh.edu>
Message-ID: <1142431089.4598.0.camel@zero.sr.unh.edu>

On Tue, 2006-03-14 at 16:01 -0500, Thomas J. Baker wrote:
> A while back my lower-window keybinding stopped working and I filed a
> bug against metacity. Turns out it wasn't metacity because it started
> working after an update and metacity hadn't changed. Well, it's back and
> even though metacity has been updated, I don't believe it's metacity's
> fault given past history.
> 
> So when I type my lower-window keybinding on a window I want lowered,
> all that happens is the window becomes unfocused. It does not lower and
> it's not clear where the focus goes.
> 
> Anyone else having this problem? Anyone care to guess which component
> might be responsible if it's not metacity?
> 
> tjb

Nevermind...Seems to be fixed with todays updates.

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



From sds at tycho.nsa.gov  Wed Mar 15 14:08:49 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 15 Mar 2006 09:08:49 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <1142358267.3027.68.camel@laptopd505.fenrus.org>
References: <dv4rq0$csu$1@sea.gmane.org>
	<1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de>	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>  <4416ED27.5060907@shahms.com>
	<1142354743.3027.52.camel@laptopd505.fenrus.org>
	<1142357408.3072.66.camel@moss-spartans.epoch.ncsc.mil>
	<1142358267.3027.68.camel@laptopd505.fenrus.org>
Message-ID: <1142431729.29737.38.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 18:44 +0100, Arjan van de Ven wrote:
> So it seems we disagree some ;-) Lets gets some individual statements
> out then:
> 
> 1) It's not feasible to enumerate all the bad things that can happen.
>    I think we both agree on this based on your reaction.

Yes.

> 2) For something as complex as apache (extremely configurable and used
>    that way in practice all the time, as well as full of plugins with an
>    active 3rd party plugin ecosystem), it is equally impossible to
>    enumerate all the things it needs to be able to do statically and
>    upfront. At least without ending up with an effective "everything
>    goes" policy which is useless.
> 
>    I'm guessing you don't agree with this.

I agree that the vendor-shipped policy is going to have to be fairly
permissive by default, with optional settings (e.g. booleans) for
tightening it up in certain predefined ways.

> 3) If you try anyway, and a situation you didn't think of happens
>    because the admin configures it that way, the complexity of the
>    policy that resulted is such that the admin no longer has a chance
>    to fix it himself. Even when the admin might fix a simple 5 line
>    policy situation (for example by relabling his new app as "does
>    network" from "does no network"), expecting the admin to fix up
>    a highly complex policy without creating wide open holes is 
>    a losing battle. Best case is he disables the lot and realizes he
>    needs to keep his apache highly uptodate. Worst case is he thinks
>    he's safe and never updates.
> 
>    I'm guessing you also don't agree with this.

I agree that typical sysadmins shouldn't have to write/edit .te files.
This is noted in the useability discussion from the SELinux summit
minutes, along with some initial steps toward solutions.  Again, this
doesn't require changes to the mechanism, just better tools to give the
sysadmin options without requiring him to deal with the raw policy,
along with proper use of already existing tools that let us check
properties of the resulting policy against security goals.
  
> So that leaves a few options:
> * dynamic policy that adjusts to the configuration
>   this is going to be of the same order of complexity as the
>   configuration options are in the first place.

This was discussed at the summit; see the minutes, and is also already
being employed in some tools that are in an early state.

> * keep the policy simple but allow more than strictly needed, yet
>   disallow things that are highly out of bound.

This is certainly doable with existing SELinux mechanism, and note that
the first part ("allow more than strictly needed") is consistent with
SELinux's model because you are still applying an overall bound on what
is allowed.

In short, we understand the problem, and solutions are in progress, but
they are properly done as higher level tools on top of the existing
mechanism, not as a fundamental reworking of it.

> The parallel to firewalls has been made several times. But in fact the
> linux firewall does exactly this; the "related" ruleset is a dynamic
> behavior that allows more than strictly would be needed to be allowed,
> yet it's an effective way to keep things tight when you know they can
> be.

-- 
Stephen Smalley
National Security Agency



From sds at tycho.nsa.gov  Wed Mar 15 14:23:31 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 15 Mar 2006 09:23:31 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <87u0a0u5mt.fsf@kosh.bigo.ensc.de>
References: <dv4rq0$csu$1@sea.gmane.org> <4416CA06.3040605@conversis.de>
	<4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<17430.62767.42318.610131@zapata.pink>
	<1142359114.31760.12.camel@mccallum.corsepiu.local>
	<80d7e4090603141030s4d42d1d0sf0861d2dea31a01d@mail.gmail.com>
	<87u0a0u5mt.fsf@kosh.bigo.ensc.de>
Message-ID: <1142432611.29737.52.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 21:35 +0100, Enrico Scholz wrote:
> SELinux is unsuitable for certain tasks (e.g. chroot operations) due to its
> broken/non existent kernel API (requiring two filesystems and operating
> with pathnames is not very efficient, difficultly/insecure and does not
> work in chroots). SELinux seems to have a big performance impact too (I
> remember numbers of 5-7% but did not measured them myself).

To clarify:
- The use of /proc for process security attributes and selinuxfs for
SELinux-specific interfaces was mandated by the kernel developers, who
frown on the introduction of new system calls (which was the original
approach taken when SELinux was a kernel patch).  It does have certain
drawbacks, but also certain advantages, and these APIs are only required
for security-aware applications.
- The SELinux kernel access control mechanism is not path-based; only
the initial assignment of security contexts to files by userspace
components is path-based (using file_contexts); for the runtime security
checks, SELinux uses the inode attributes.  Parallel:  For Linux DAC,
you assign modes and ownerships via utilities like chown/chmod by
specifying the path, and the kernel then applies runtime checks based on
the attributes of the inode.  setfiles even has an option for alternate
roots for that very purpose, to deal with applying file_contexts to a
chroot'd environment.
- I think your actual complaint has more to do with rpm SELinux
integration, which does need improvement.  But that isn't fundamental to
the underlying SELinux mechanism.
- SELinux does have a performance impact, but be careful about mixing
apples and oranges - the numbers I've seen repeatedly cited for AppArmor
appeared to be a comparison of their WebStone results against our dbench
results, and against results published a couple years ago.  Note that
unlike AppArmor, which is doing pathname generation in kernel and regex
matching in kernel, SELinux is just grabbing an incore inode security
value and doing a hash lookup, and our problems in the past with
scalability have been addressed by the conversion of the SELinux AVC to
using RCU by NEC. 

> 'cfengine' provides the largest attack vectors in my systems and I do
> not see how SELinux can help to protect this program.

Perhaps you could clarify why you think that SELinux cannot help with
it?  I haven't looked at cfengine closely myself, so I'm not sure about
its architecture.

-- 
Stephen Smalley
National Security Agency



From sds at tycho.nsa.gov  Wed Mar 15 14:26:26 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 15 Mar 2006 09:26:26 -0500
Subject: No more selinux-policy-*-sources
In-Reply-To: <20060314220305.GD1305620@hiwaay.net>
References: <1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<20060314185635.GA20490@dspnet.fr.eu.org>
	<44171890.5070000@cornell.edu>
	<20060314220305.GD1305620@hiwaay.net>
Message-ID: <1142432786.29737.56.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2006-03-14 at 16:03 -0600, Chris Adams wrote:
> Once upon a time, Ivan Gyurdiev <ivg2 at cornell.edu> said:
> > cp has supported selinux for quite some time now.
> 
> The fact that it "supports" SELinux by adding a new option doesn't
> really help.  People know "cp -p" to preserve ownership and permissions,
> but you have to use (the annoyingly verbose) "cp --preserve=all" to get
> SELinux attributes.

cp -c is the short form for preserving security contexts.  It was kept
separate from the default behavior for -p because there are definitely
cases where an application is allowed to set owner/mode on a file but
_not_ necessarily allowed to set a given security label on that file.
Thus, pushing those semantics into the default behavior of -p would
ultimately lead to breaking existing users of cp -p.  Not saying that
the coreutils SELinux integration couldn't stand improvement, but there
was a reason why they were kept separate, and that was discussed on the
public lists I believe.

-- 
Stephen Smalley
National Security Agency



From galibert at pobox.com  Wed Mar 15 14:34:24 2006
From: galibert at pobox.com (Olivier Galibert)
Date: Wed, 15 Mar 2006 15:34:24 +0100
Subject: No more selinux-policy-*-sources
In-Reply-To: <44171890.5070000@cornell.edu>
References: <1142325106.12438.13.camel@laurel.intra.city-fan.org>
	<4416CA06.3040605@conversis.de> <4416CC15.6040006@city-fan.org>
	<1142345596.3027.38.camel@laptopd505.fenrus.org>
	<4416D22D.30604@conversis.de>
	<20060314151614.GA26289@devserv.devel.redhat.com>
	<4416E6D6.7040109@conversis.de>
	<80d7e4090603140826w733aa271rec4ed04993b301@mail.gmail.com>
	<20060314185635.GA20490@dspnet.fr.eu.org>
	<44171890.5070000@cornell.edu>
Message-ID: <20060315143424.GA49179@dspnet.fr.eu.org>

On Tue, Mar 14, 2006 at 02:25:04PM -0500, Ivan Gyurdiev wrote:
> 
> >The selinux cra^Wlabels should have been taken into account in
> >cp/tar/rsync and other applications that copy executables before
> >  
> cp has supported selinux for quite some time now.

What in my sentence made you think this was an "or"?


> As far as recovering from disaster is concerned... there's the option of 
> turning selinux off, or enabling it in permissive mode via kernel 
> parameters, therefore selinux issues are never fatal if you know the 
> right options (enforcing=0, or selinux=0).

And once a sysadmin has had to turn selinux off temporarily to be able
to use his computer again, what do you think are the odds for his next
action to be turning it off definitively?

Guys, as long as the failure mode for a simple and somewhat invisible
problem (lost labels) which isn't a hardware failure is to make a
system totally unusable, selinux is too dangerous to be used.

  OG.



From nicolas.mailhot at laposte.net  Wed Mar 15 15:11:14 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 15 Mar 2006 16:11:14 +0100 (CET)
Subject: wpa_supplicant support for ifup
In-Reply-To: <1142427485.2401.2.camel@localhost.localdomain>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
	<34931.192.54.193.51.1142419842.squirrel@rousalka.dyndns.org>
	<1142427485.2401.2.camel@localhost.localdomain>
Message-ID: <12735.192.54.193.53.1142435474.squirrel@rousalka.dyndns.org>

Le Mer 15 mars 2006 13:58, Dan Williams a ?crit :

>> If you want this NM, gnome-power-manager and other GFX tools need to
>> grow
>> a CLI/daemon personality ASAP.
>
> You can do this for any service that exposes a dbus interface.  Nothing
> stops your from using dbus-send on the CLI, or whipping up your own
> scripts, to do this Right Now.  What you imply is missing is either 1) a
> set of tools like ifconfig/ip/ifup/ifdown/etc that all perform discrete
> functions in isolation of each other, or 2) a CLI client with an
> interface like mysql or pgsql.

What I imply are missing are tools basic users can use (not APIs for CLI
tool developpers).

If the actual aim is to deprecate current systems which do include CLI
tools, well the proponents of the new systems have to provide some
replacements. The current plan seems to leave them without any tools to
force them to convert to the GUI (not always possible) or create the
missing CLI utilities (why should they bother in the first place).

That this plan is met with a definite lack of enthusiasm should be no
surprise. That's the same mistake the selinux people did - create a
beautiful system, and forget about the tools users need to interact with
it.

-- 
Nicolas Mailhot



From florin at andrei.myip.org  Wed Mar 15 17:21:21 2006
From: florin at andrei.myip.org (Florin Andrei)
Date: Wed, 15 Mar 2006 09:21:21 -0800
Subject: Fedora Core 5 Status
In-Reply-To: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
References: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
Message-ID: <1142443281.3161.0.camel@rivendell.home.local>

On Fri, 2006-03-10 at 10:53 -0500, Jeremy Katz wrote:
> Due to circumstances outside of our control, we're going to be unable to
> keep to the scheduled date of March 15th for the release of FC5 and
> instead are going to have to make the release date Monday, March 20th.
> While unfortunate in some ways, this gives us the opportunity to pull in
> the final GNOME 2.14 tarballs which should be available on Monday
> assuming the changes are suitably minor.

Cool.

Will Evolution-2.6.0 be included as well?

-- 
Florin Andrei

http://florin.myip.org/



From bdpepple at ameritech.net  Wed Mar 15 17:28:19 2006
From: bdpepple at ameritech.net (Brian Pepple)
Date: Wed, 15 Mar 2006 12:28:19 -0500
Subject: Fedora Core 5 Status
In-Reply-To: <1142443281.3161.0.camel@rivendell.home.local>
References: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
	<1142443281.3161.0.camel@rivendell.home.local>
Message-ID: <1142443699.5648.0.camel@shuttle.273piedmont.org>

On Wed, 2006-03-15 at 09:21 -0800, Florin Andrei wrote:
> On Fri, 2006-03-10 at 10:53 -0500, Jeremy Katz wrote:
> > Due to circumstances outside of our control, we're going to be unable to
> > keep to the scheduled date of March 15th for the release of FC5 and
> > instead are going to have to make the release date Monday, March 20th.
> > While unfortunate in some ways, this gives us the opportunity to pull in
> > the final GNOME 2.14 tarballs which should be available on Monday
> > assuming the changes are suitably minor.
> 
> Cool.
> 
> Will Evolution-2.6.0 be included as well?
> 

It's already in Rawhide.

/B
-- 
Brian Pepple <bdpepple at ameritech.net>

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

From sds at tycho.nsa.gov  Wed Mar 15 17:37:25 2006
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 15 Mar 2006 12:37:25 -0500
Subject: wpa_supplicant support for ifup
In-Reply-To: <12735.192.54.193.53.1142435474.squirrel@rousalka.dyndns.org>
References: <44169D5E.9090705@redhat.com>
	<20060314172622.GA22376@devserv.devel.redhat.com>
	<20060314220454.GE1305620@hiwaay.net>
	<20060315025124.GB4248@devserv.devel.redhat.com>
	<34931.192.54.193.51.1142419842.squirrel@rousalka.dyndns.org>
	<1142427485.2401.2.camel@localhost.localdomain>
	<12735.192.54.193.53.1142435474.squirrel@rousalka.dyndns.org>
Message-ID: <1142444245.4933.27.camel@moss-spartans.epoch.ncsc.mil>

On Wed, 2006-03-15 at 16:11 +0100, Nicolas Mailhot wrote:
> That this plan is met with a definite lack of enthusiasm should be no
> surprise. That's the same mistake the selinux people did - create a
> beautiful system, and forget about the tools users need to interact with
> it.

We didn't forget, but we had to get the base mechanism in place first.
There is a lot of work in progress for better tools, including several
recently released ones, as noted in the other thread.

-- 
Stephen Smalley
National Security Agency



From peter at thecodergeek.com  Wed Mar 15 17:33:25 2006
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 15 Mar 2006 09:33:25 -0800 (PST)
Subject: Fedora Core 5 Status
In-Reply-To: <1142443281.3161.0.camel@rivendell.home.local>
References: <1142006032.29247.10.camel@orodruin.boston.redhat.com>
	<1142443281.3161.0.camel@rivendell.home.local>
Message-ID: <48172.127.0.0.1.1142444005.squirrel@www.thecodergeek.com>

Florin Andrei said:
> Cool.
>
> Will Evolution-2.6.0 be included as well?

It already is, according to the 20060315 Rawhide report. :)
-- 
Peter Gordon (codergeek42)
This message was sent through a webmail
    interface, and thus not signed.



From bojan at rexursive.com  Wed Mar 15 18:09:54 2006
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 16 Mar 2006 05:09:54 +1100
Subject: Recent kernels hang on resume
In-Reply-To: <1142115142.2001.10.camel@coyote.rexursive.com>
References: <1142115142.2001.10.camel@coyote.rexursive.com>
Message-ID: <1142446195.1982.0.camel@coyote.rexursive.com>

On Sun, 2006-03-12 at 09:12 +1100, Bojan Smojver wrote:

> Stopping tasks: =

Kernel 2054 is the same, so I was wrong about that mouse patch. Probably
some other module...

-- 
Bojan



From tjb at unh.edu  Wed Mar 15 19:35:07 2006
From: tjb at unh.edu (Thomas J. Baker)
Date: Wed, 15 Mar 2006 14:35:07 -0500
Subject: Lower Window Keybinding
In-Reply-To: <1142370060.31688.21.camel@zero.sr.unh.edu>
References: <1142370060.31688.21.camel@zero.sr.unh.edu>
Message-ID: <1142451307.13967.19.camel@zero.sr.unh.edu>

On Tue, 2006-03-14 at 16:01 -0500, Thomas J. Baker wrote:
> A while back my lower-window keybinding stopped working and I filed a
> bug against metacity. Turns out it wasn't metacity because it started
> working after an update and metacity hadn't changed. Well, it's back and
> even though metacity has been updated, I don't believe it's metacity's
> fault given past history.
> 
> So when I type my lower-window keybinding on a window I want lowered,
> all that happens is the window becomes unfocused. It does not lower and
> it's not clear where the focus goes.
> 
> Anyone else having this problem? Anyone care to guess which component
> might be responsible if it's not metacity?
> 
> tjb

Actually, it turns out that deskbar-applet by default uses my window
lowering key alt-f3 to gain focus. Maybe it would be nice if keys
already defined in keyboard bindings couldn't be stolen by individual
applets...

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



From russell at coker.com.au  Wed Mar 15 22:20:54 2006
From: russell at coker.com.au (Russell Coker)
Date: Thu, 16 Mar 2006 09:20:54 +1100
Subject: 2GB swap partition limit?
In-Reply-To: <1141561466.440ad87ae2478@www.jouy.inra.fr>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
Message-ID: <200603160920.58342.russell@coker.com.au>

On Sunday 05 March 2006 23:24, ?meric Maschino <emeric.maschino at jouy.inra.fr> 
wrote:
> My workstation has been upgraded to 6GB RAM. I let anaconda automatically
> manage the partitions on the disk. It created a 4GB swap partition in a LVM
> volume. But top, free and gnome-system-monitor all report that my swap
> space is 2GB (more precisely, 1.9GB). IIRC, there was a 2GB limit partition
> for the swap size in the past, but I thought this has been overcame.

Incidentally such a large swap space will not do you any good in most usage 
scenarios.

In most cases your machine will become totally unusable long before the 4G 
space is used, and often it would be more desirable to have the OOM killer 
kill something before it gets to that stage.  When configuring machines with 
more than about 512M of RAM I never use 2*RAM for swap size for this reason.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page




From janina at rednote.net  Thu Mar 16 05:07:42 2006
From: janina at rednote.net (Janina Sajka)
Date: Thu, 16 Mar 2006 00:07:42 -0500
Subject: No Joy From Attempted Hard Disk Install With T3
Message-ID: <20060316050742.GC13846@rednote.net>

I just attempted to install FC5T3 via hard disk and got the complaint
about repo data. Just to be sure I tried both from the DVD iso and the 5
disc iso set.

Is it just me? Have others succeeded installing from iso files on
another hd partition? It would be nice for this to be working whith the
FC5 release, of course.

-- 

Janina Sajka				Phone: +1.240.715.1272
Partner, Capital Accessibility LLC	http://www.CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://www.ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org



From naoki at valuecommerce.com  Thu Mar 16 07:31:50 2006
From: naoki at valuecommerce.com (Naoki)
Date: Thu, 16 Mar 2006 16:31:50 +0900
Subject: xen failure - xenstrore with 2.6.15-1.2009.4.2_FC5hypervisor #1 SMP
Message-ID: <1142494310.2480.9.camel@dragon.sys.intra>

I can't get xend to start, have not been able to for a couple of weeks,
if not more actually. Using 2.6.15-1.2009.4.2_FC5hypervisor #1 SMP

Log says this :

[2006-03-16 16:15:47 xend] INFO (SrvDaemon:285) Xend Daemon started
[2006-03-16 16:15:47 xend] INFO (SrvDaemon:289) Xend changeset:
unavailable .
[2006-03-16 16:15:47 xend] ERROR (SrvDaemon:299) Exception starting xend
((111, 'Connection refused'))
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line 293, in run
    servers = SrvServer.create()
  File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvServer.py",
line 106, in create
    root.putChild('xend', SrvRoot())
  File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvRoot.py",
line 40, in __init__
    self.get(name)
  File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 82, in
get
    val = val.getobj()
  File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 52, in
getobj
    self.obj = klassobj()
  File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line
39, in __init__
    self.xd = XendDomain.instance()
  File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
550, in instance
    inst.init()
  File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
70, in init
    xstransact.Mkdir(VMROOT)
  File
"/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
317, in Mkdir
    complete(path, lambda t: t.mkdir(*args))
  File
"/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
323, in complete
    t = xstransact(path)
  File
"/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
20, in __init__
    self.transaction = xshandle().transaction_start()
  File "/usr/lib/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
line 18, in xshandle
    xs_handle = xen.lowlevel.xs.xs()
RuntimeError: (111, 'Connection refused')

I traced the binary and I see this :
[pid  2954] socket(PF_FILE, SOCK_STREAM, 0) = 4
[pid  2954] connect(4, {sa_family=AF_FILE,
path="/var/run/xenstored/socket"}, 110) = -1 ECONNREFUSED (Connection
refused)
[pid  2954] close(4)  
[pid  2943] socket(PF_FILE, SOCK_STREAM, 0 <unfinished ...>
[pid  2954] write(2, "Failed to contact xenstore (Conn"..., 65
<unfinished ...>

The socket exists but nothing has a handle on it though :

$ ls -l /var/run/xenstored/socket
srw------- 1 root root 0 Mar 16 16:18 /var/run/xenstored/socket

It suggests xenstore is my problem but in the same trace I see it
executing ok :

[pid  2946] execve("/usr/sbin/xenstored", ["xenstored",
"--pid-file=/var/run/xenstore.pid"...], [/* 20 vars */]) = 0

So I ran it manually and I get this :

# FATAL: Failed to initialize dom0 state: No such device
full talloc report on 'null_context' (total 56 bytes in 3 blocks)
    struct domain                  contains     56 bytes in   2 blocks
(ref 0)
        /local/domain/0                contains     16 bytes in   1
blocks (ref 0)

Another trace shows the failure probably being here :

open("/proc/xen/xsd_kva", O_RDWR)       = 10
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENODEV
(No such device)
close(10)    

# ls -l /proc/xen/xsd_kva
-r-------- 1 root root 0 Mar 16 16:31 /proc/xen/xsd_kva


That's about as far as my debugging skills can go, anybody seen/know
this?



From naoki at valuecommerce.com  Thu Mar 16 07:36:53 2006
From: naoki at valuecommerce.com (Naoki)
Date: Thu, 16 Mar 2006 16:36:53 +0900
Subject: xen failure - xenstrore with 2.6.15-1.2009.4.2_FC5hypervisor
	#1 SMP
In-Reply-To: <1142494310.2480.9.camel@dragon.sys.intra>
References: <1142494310.2480.9.camel@dragon.sys.intra>
Message-ID: <1142494614.2480.12.camel@dragon.sys.intra>

Should have added the xen version sorry : xen-3.0.1-4
It's all latest rawhide.

On Thu, 2006-03-16 at 16:31 +0900, Naoki wrote:
> I can't get xend to start, have not been able to for a couple of weeks,
> if not more actually. Using 2.6.15-1.2009.4.2_FC5hypervisor #1 SMP
> 
> Log says this :
> 
> [2006-03-16 16:15:47 xend] INFO (SrvDaemon:285) Xend Daemon started
> [2006-03-16 16:15:47 xend] INFO (SrvDaemon:289) Xend changeset:
> unavailable .
> [2006-03-16 16:15:47 xend] ERROR (SrvDaemon:299) Exception starting xend
> ((111, 'Connection refused'))
> Traceback (most recent call last):
>   File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
> line 293, in run
>     servers = SrvServer.create()
>   File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvServer.py",
> line 106, in create
>     root.putChild('xend', SrvRoot())
>   File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvRoot.py",
> line 40, in __init__
>     self.get(name)
>   File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 82, in
> get
>     val = val.getobj()
>   File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 52, in
> getobj
>     self.obj = klassobj()
>   File
> "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line
> 39, in __init__
>     self.xd = XendDomain.instance()
>   File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
> 550, in instance
>     inst.init()
>   File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
> 70, in init
>     xstransact.Mkdir(VMROOT)
>   File
> "/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
> 317, in Mkdir
>     complete(path, lambda t: t.mkdir(*args))
>   File
> "/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
> 323, in complete
>     t = xstransact(path)
>   File
> "/usr/lib/python2.4/site-packages/xen/xend/xenstore/xstransact.py", line
> 20, in __init__
>     self.transaction = xshandle().transaction_start()
>   File "/usr/lib/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
> line 18, in xshandle
>     xs_handle = xen.lowlevel.xs.xs()
> RuntimeError: (111, 'Connection refused')
> 
> I traced the binary and I see this :
> [pid  2954] socket(PF_FILE, SOCK_STREAM, 0) = 4
> [pid  2954] connect(4, {sa_family=AF_FILE,
> path="/var/run/xenstored/socket"}, 110) = -1 ECONNREFUSED (Connection
> refused)
> [pid  2954] close(4)  
> [pid  2943] socket(PF_FILE, SOCK_STREAM, 0 <unfinished ...>
> [pid  2954] write(2, "Failed to contact xenstore (Conn"..., 65
> <unfinished ...>
> 
> The socket exists but nothing has a handle on it though :
> 
> $ ls -l /var/run/xenstored/socket
> srw------- 1 root root 0 Mar 16 16:18 /var/run/xenstored/socket
> 
> It suggests xenstore is my problem but in the same trace I see it
> executing ok :
> 
> [pid  2946] execve("/usr/sbin/xenstored", ["xenstored",
> "--pid-file=/var/run/xenstore.pid"...], [/* 20 vars */]) = 0
> 
> So I ran it manually and I get this :
> 
> # FATAL: Failed to initialize dom0 state: No such device
> full talloc report on 'null_context' (total 56 bytes in 3 blocks)
>     struct domain                  contains     56 bytes in   2 blocks
> (ref 0)
>         /local/domain/0                contains     16 bytes in   1
> blocks (ref 0)
> 
> Another trace shows the failure probably being here :
> 
> open("/proc/xen/xsd_kva", O_RDWR)       = 10
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENODEV
> (No such device)
> close(10)    
> 
> # ls -l /proc/xen/xsd_kva
> -r-------- 1 root root 0 Mar 16 16:31 /proc/xen/xsd_kva
> 
> 
> That's about as far as my debugging skills can go, anybody seen/know
> this?




From buildsys at redhat.com  Thu Mar 16 08:07:20 2006
From: buildsys at redhat.com (Build System)
Date: Thu, 16 Mar 2006 03:07:20 -0500
Subject: rawhide report: 20060316 changes
Message-ID: <200603160807.k2G87KKc022376@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5








From galibert at pobox.com  Thu Mar 16 09:51:23 2006
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 16 Mar 2006 10:51:23 +0100
Subject: 2GB swap partition limit?
In-Reply-To: <200603160920.58342.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603160920.58342.russell@coker.com.au>
Message-ID: <20060316095123.GA74693@dspnet.fr.eu.org>

On Thu, Mar 16, 2006 at 09:20:54AM +1100, Russell Coker wrote:
> On Sunday 05 March 2006 23:24, ?meric Maschino <emeric.maschino at jouy.inra.fr> 
> wrote:
> > My workstation has been upgraded to 6GB RAM. I let anaconda automatically
> > manage the partitions on the disk. It created a 4GB swap partition in a LVM
> > volume. But top, free and gnome-system-monitor all report that my swap
> > space is 2GB (more precisely, 1.9GB). IIRC, there was a 2GB limit partition
> > for the swap size in the past, but I thought this has been overcame.
> 
> Incidentally such a large swap space will not do you any good in most usage 
> scenarios.

Three words: "suspend to disk".

  OG.



From mmkernel at ezplanet.net  Thu Mar 16 11:16:14 2006
From: mmkernel at ezplanet.net (Mauro Mozzarelli)
Date: Thu, 16 Mar 2006 11:16:14 -0000 (GMT)
Subject: Building openoffice 2.0.2-5.2.2 fails
Message-ID: <44862.217.33.199.76.1142507774.squirrel@mauro.ezplanet.net>

Hi All,

When I build openoffice after hours and hours, during the "install"
process I get the following:

==============================
+
/var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/program/configimport
-e
file:///var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/share/registry
/usr/src/ezplanet/SOURCES/RegisterAndLicence.xcu
configimport.bin - Unhandled exception caught in main:
"configmgr::backend::ImportHandler: Could not get output handler for
component org.openoffice.Setup due to a backend exception:
 MultiStratumBackend: No Backend supports Entity:
"file:///var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/share/registry"
error: Bad exit status from /var/tmp/rpm-tmp.19514 (%install)

===========================

The same was happening with 2.0.2-5.1.2

Anyone knows what could be wrong?

MM






From russell at coker.com.au  Thu Mar 16 11:18:11 2006
From: russell at coker.com.au (Russell Coker)
Date: Thu, 16 Mar 2006 22:18:11 +1100
Subject: 2GB swap partition limit?
In-Reply-To: <20060316095123.GA74693@dspnet.fr.eu.org>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603160920.58342.russell@coker.com.au>
	<20060316095123.GA74693@dspnet.fr.eu.org>
Message-ID: <200603162218.14119.russell@coker.com.au>

On Thursday 16 March 2006 20:51, Olivier Galibert <galibert at pobox.com> wrote:
> > Incidentally such a large swap space will not do you any good in most
> > usage scenarios.
>
> Three words: "suspend to disk".

Good point.  How well does suspend to disk work nowadays?  The reports I've 
heard in the past have suggested that certain types of hardware could cause 
the machine to be in an uncertain state on resume so I've avoided using it to 
keep my data safe.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From caolanm at redhat.com  Thu Mar 16 11:29:59 2006
From: caolanm at redhat.com (Caolan McNamara)
Date: Thu, 16 Mar 2006 11:29:59 +0000
Subject: Building openoffice 2.0.2-5.2.2 fails
In-Reply-To: <44862.217.33.199.76.1142507774.squirrel@mauro.ezplanet.net>
References: <44862.217.33.199.76.1142507774.squirrel@mauro.ezplanet.net>
Message-ID: <1142508600.8054.29.camel@localhost.localdomain>

On Thu, 2006-03-16 at 11:16 +0000, Mauro Mozzarelli wrote:
> Hi All,
> 
> When I build openoffice after hours and hours, during the "install"
> process I get the following:
> 
> ==============================
> +
> /var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/program/configimport
> -e
> file:///var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/share/registry
> /usr/src/ezplanet/SOURCES/RegisterAndLicence.xcu
> configimport.bin - Unhandled exception caught in main:
> "configmgr::backend::ImportHandler: Could not get output handler for
> component org.openoffice.Setup due to a backend exception:
>  MultiStratumBackend: No Backend supports Entity:
> "file:///var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/share/registry"
> error: Bad exit status from /var/tmp/rpm-tmp.19514 (%install)
> 
> ===========================
> 
> The same was happening with 2.0.2-5.1.2
> 
> Anyone knows what could be wrong?

Never seen anything like that in all the times I've built OOo, so have
you made any modifications at all ?

If not then perhaps it's something that happens differently for you
because of a different locale. So as a wild stab in the dark I'd try
adding a 

export LANG=en_US.UTF-8
to the %install section of the spec.


If you have the ruins of your build still around then you can try and
manually run something like...

/var/tmp/foo/.../openoffice.org/program/configimport -e
file://./var/tmp/foo..openoffice.org/share/registry /usr/src/ezplanet/SOURCES/RegisterAndLicence.xcu

and experiment around with that.

C.



From galibert at pobox.com  Thu Mar 16 11:59:36 2006
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 16 Mar 2006 12:59:36 +0100
Subject: 2GB swap partition limit?
In-Reply-To: <200603162218.14119.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603160920.58342.russell@coker.com.au>
	<20060316095123.GA74693@dspnet.fr.eu.org>
	<200603162218.14119.russell@coker.com.au>
Message-ID: <20060316115936.GB74693@dspnet.fr.eu.org>

On Thu, Mar 16, 2006 at 10:18:11PM +1100, Russell Coker wrote:
> Good point.  How well does suspend to disk work nowadays?

Not that good yet.


> The reports I've 
> heard in the past have suggested that certain types of hardware could cause 
> the machine to be in an uncertain state on resume so I've avoided using it to 
> keep my data safe.

You'd better stay that way for now.

  OG.



From karsten at redhat.de  Thu Mar 16 11:59:24 2006
From: karsten at redhat.de (Karsten Hopp)
Date: Thu, 16 Mar 2006 12:59:24 +0100
Subject: Vim-7 Preview
Message-ID: <4419531C.3070803@redhat.de>

Hello,

I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/

Most prominent new features are gvim with windows in multiple tab pages  (:help tabpage),
spell checking (:help spell) and omni-completion (:help new-omni-completion).

A description of the new features of vim-7 is available with :help version7

Please report any problems in bugzilla and make sure to mention the package version

Have fun...
   Karsten


-- 
Learn. Network. Experience open source.
Red Hat Summit Nashville  |  May 30 - June 2, 2006
Learn more: http://www.redhat.com/promo/summit/



From fedora at adslpipe.co.uk  Thu Mar 16 11:08:47 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Thu, 16 Mar 2006 11:08:47 +0000
Subject: xen failure - xenstrore with 2.6.15-1.2009.4.2_FC5hypervisor#1
 SMP
In-Reply-To: <1142494614.2480.12.camel@dragon.sys.intra>
References: <1142494310.2480.9.camel@dragon.sys.intra>
	<1142494614.2480.12.camel@dragon.sys.intra>
Message-ID: <4419473F.3090209@adslpipe.co.uk>

Naoki wrote:

> Should have added the xen version sorry : xen-3.0.1-4
> It's all latest rawhide.
> 
> On Thu, 2006-03-16 at 16:31 +0900, Naoki wrote:
>> I can't get xend to start, have not been able to for a couple of weeks,
>> if not more actually. Using 2.6.15-1.2009.4.2_FC5hypervisor #1 SMP

2.6.15-1.2009.4.2.FC5hypervisor isn't latest rawhide, you should use
2.6.15-1.2054_FC5xen0



From gilboad at gmail.com  Thu Mar 16 12:29:05 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Thu, 16 Mar 2006 14:29:05 +0200
Subject: Vim-7 Preview
In-Reply-To: <4419531C.3070803@redhat.de>
References: <4419531C.3070803@redhat.de>
Message-ID: <1142512145.14319.23.camel@gilboa-work-dev>

On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> Hello,
> 
> I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
> 
> Most prominent new features are gvim with windows in multiple tab pages  (:help tabpage),
> spell checking (:help spell) and omni-completion (:help new-omni-completion).
> 
> A description of the new features of vim-7 is available with :help version7
> 
> Please report any problems in bugzilla and make sure to mention the package version
> 
> Have fun...
>    Karsten
> 

Yey!
Can the .spec be modified to co-exist with 6?
E.g. /usr/bin/vim7XXX?

Gilboa



From nitsheno at in.ibm.com  Thu Mar 16 12:17:04 2006
From: nitsheno at in.ibm.com (Nithin Shenoy)
Date: Thu, 16 Mar 2006 17:47:04 +0530
Subject: Nithin Shenoy is out of the office.
Message-ID: <OFC581FCCC.15921E84-ON65257133.00437B5B-65257133.00437B5C@in.ibm.com>

I will be out of the office starting  03/16/2006 and will not return until
03/21/2006.

I will respond to your message when I return.



From gianluca.cecchi at gmail.com  Thu Mar 16 13:17:30 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 16 Mar 2006 14:17:30 +0100
Subject: which gstreamer versions in official fc5?
Message-ID: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>

ATM we have
gstreamer-0.10.3-3
gstreamer-plugins-base-0.10.3-3
gstreamer-plugins-good-0.10.2-1

It seems in final gnome 2.14 the optimum is:
gstreamer 0.10.4 and gst-plugins-base 0.10.5
(see thread
http://mail.gnome.org/archives/release-team/2006-March/msg00126.html
and for previous related messages:
http://mail.gnome.org/archives/gnome-multimedia/2006-March/msg00000.html
http://mail.gnome.org/archives/gnome-multimedia/2006-March/msg00002.html
)
and gst-plugins-good-0.10.2
What is the plan for final fc5 about core and base? Are they planned
to be aligned with gnome?
Thanks
Gianluca



From mmkernel at ezplanet.net  Thu Mar 16 13:35:27 2006
From: mmkernel at ezplanet.net (Mauro Mozzarelli)
Date: Thu, 16 Mar 2006 13:35:27 -0000 (GMT)
Subject: 2GB swap partition limit?
In-Reply-To: <200603162218.14119.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603160920.58342.russell@coker.com.au>
	<20060316095123.GA74693@dspnet.fr.eu.org>
	<200603162218.14119.russell@coker.com.au>
Message-ID: <31979.217.33.199.76.1142516127.squirrel@mauro.ezplanet.net>


On Thu, March 16, 2006 11:18, Russell Coker wrote:
> On Thursday 16 March 2006 20:51, Olivier Galibert <galibert at pobox.com>
> wrote:
>> > Incidentally such a large swap space will not do you any good in most
>> > usage scenarios.
>>
>> Three words: "suspend to disk".
>

I use it for "tmpfs"



From gilboad at gmail.com  Thu Mar 16 13:39:42 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Thu, 16 Mar 2006 15:39:42 +0200
Subject: Kernel 2054 breaks nvidia.ko loading
In-Reply-To: <1142512080.3041.30.camel@laptopd505.fenrus.org>
References: <000901c64850$0cd5ce80$0a01a8c0@jbsys>
	<8767947e0603151711k4dea1e8cy303c8faa6bfd22ff@mail.gmail.com>
	<20060316022048.GB8407@redhat.com>
	<9050516b0603151947g24402572s9c49bf24d0ea890@mail.gmail.com>
	<a36b7e2a0603152109i2717fd44tb3b6e9f054d3a527@mail.gmail.com>
	<9050516b0603152201r692024f4u45f2f1e705a9bdc3@mail.gmail.com>
	<a36b7e2a0603160408l5a8a07adx2c0307ed975d24d1@mail.gmail.com>
	<1142511888.14319.21.camel@gilboa-work-dev>
	<1142512080.3041.30.camel@laptopd505.fenrus.org>
Message-ID: <1142516382.14319.54.camel@gilboa-work-dev>

On Thu, 2006-03-16 at 13:28 +0100, Arjan van de Ven wrote:
> > 
> > In nVidia/ATI's defense, unlike previous FC/non-GPL problems (udev, 4K
> > stacks, etc) the problem is not with the closed source drivers failing
> > to follow the latest kernel trunk.
> > Beside releasing their code under GPL (Which is a good thing(tm))
> > there's nothing nVidia nor ATI can do to fix this problem.
> 
> 
> this claim is incorrect, the workaround is trivial.
> 

I assume you mean "fixing" their driver by adding a copy of
print_tainted function, right?
Am I missing any other solution?

Gilboa



From russell at coker.com.au  Thu Mar 16 14:00:47 2006
From: russell at coker.com.au (Russell Coker)
Date: Fri, 17 Mar 2006 01:00:47 +1100
Subject: 2GB swap partition limit?
In-Reply-To: <31979.217.33.199.76.1142516127.squirrel@mauro.ezplanet.net>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603162218.14119.russell@coker.com.au>
	<31979.217.33.199.76.1142516127.squirrel@mauro.ezplanet.net>
Message-ID: <200603170100.51395.russell@coker.com.au>

On Friday 17 March 2006 00:35, "Mauro Mozzarelli" <mmkernel at ezplanet.net> 
wrote:
> >> > Incidentally such a large swap space will not do you any good in most
> >> > usage scenarios.
> >>
> >> Three words: "suspend to disk".
>
> I use it for "tmpfs"

There are situations where machines can perform very well with a tmpfs that is 
significantly larger than RAM.  There was one time that one of my machines 
with 512M of RAM needed a 6G tmpfs and gave really good performance with 6G 
of swap.

There are also some applications that have a working set which is far smaller 
than the full allocated memory space and which perform well when they are 
mostly swapped out.

However I believe that neither is a common use of a machine.  The general 
advice which is given as "use twice RAM" is something that I believe to be 
wrong in most instances now that machines with 512M of RAM or more are 
common.

The issue of what size of swap space will be viable is really determined by 
the IO capacity of the storage device.  Get a bunch of 15,000rpm SATA or SCSI 
disks in a RAID-5 array with a write-back disk controller and a swap space of 
several gigs in size may be viable for a wide range of work loads.  Get a 
single IDE disk with a few gigs of swap and it's most likely that the 
performance of your machine will be unusable (to a degree that you have to 
press reset as logging in to run shutdown takes far too long) long before the 
swap space is fully used.

I'm not trying to convince people that everyone should use less than 2*RAM for 
their swap space!  Merely that the 2*RAM advice originated when 16M of RAM 
was a big machine and that things are different now.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From rstrode at redhat.com  Thu Mar 16 14:44:42 2006
From: rstrode at redhat.com (Ray Strode)
Date: Thu, 16 Mar 2006 09:44:42 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
Message-ID: <1142520282.10076.1.camel@halflap>

Hi,
> It seems in final gnome 2.14 the optimum is:
> gstreamer 0.10.4 and gst-plugins-base 0.10.5
I believe the plan is to upgrade in FC5 updates, within a few days of
the FC5 release.

--Ray



From Lam at Lam.pl  Thu Mar 16 15:23:21 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Thu, 16 Mar 2006 16:23:21 +0100
Subject: 2GB swap partition limit?
In-Reply-To: <200603170100.51395.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603162218.14119.russell@coker.com.au>
	<31979.217.33.199.76.1142516127.squirrel@mauro.ezplanet.net>
	<200603170100.51395.russell@coker.com.au>
Message-ID: <1142522601.4996.16.camel@pensja.lam.pl>

Dnia 17-03-2006, pi? o godzinie 01:00 +1100, Russell Coker napisa?(a):
> the 2*RAM advice originated when 16M of RAM 
> was a big machine and that things are different now.
Not really - iirc it appeared with Linux 2.4, which swaps more
aggressively than 2.2. When 2.4 came out, 256 MiB of system memory was
pretty common for small servers.

Swap space can be as large as you want it to be unless you go into
situation where more than physical memory amount is needed for running
programs (or rather for pages these programs need continously or how-
they're-called). If this happens and your system becomes unresponsive,
this is really an oom-killer issue (it should act faster and choose
victims more wisely), decreasing swap space to "help" oom-killer act
fast is really not a solution, but a dirty hack.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060316/2f8bf838/attachment.sig>

From hunter at userfriendly.net  Thu Mar 16 15:24:28 2006
From: hunter at userfriendly.net (Michael Weiner)
Date: Thu, 16 Mar 2006 10:24:28 -0500
Subject: Vim-7 Preview
In-Reply-To: <1142512145.14319.23.camel@gilboa-work-dev>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
Message-ID: <d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>

On 3/16/06, Gilboa Davara <gilboad at gmail.com> wrote:
>
> On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> > Hello,
> >
> > I've prepared vim-7 prerelease packages, they are available from
> http://people.redhat.com/karsten/
> >
> > Most prominent new features are gvim with windows in multiple tab
> pages  (:help tabpage),
> > spell checking (:help spell) and omni-completion (:help
> new-omni-completion).
> >
> > A description of the new features of vim-7 is available with :help
> version7
> >


Karsten -

any chance of posting the src.rpm and/or spec file?

Thanks in advance.
Michael Weiner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060316/dd6e9564/attachment.htm>

From bdpepple at ameritech.net  Thu Mar 16 15:26:44 2006
From: bdpepple at ameritech.net (Brian Pepple)
Date: Thu, 16 Mar 2006 10:26:44 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142520282.10076.1.camel@halflap>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
Message-ID: <1142522804.10508.3.camel@shuttle.273piedmont.org>

On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote:
> I believe the plan is to upgrade in FC5 updates, within a few days of
> the FC5 release.
> 

Do you know if there is any plan to update libnotify to 0.3.2 for FC5?
I've got a couple of packages (gossip, xchat-gnome) that don't work with
0.3.0 due to the api change.

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

/B
-- 
Brian Pepple <bdpepple at ameritech.net>

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

From giallu at gmail.com  Thu Mar 16 15:30:00 2006
From: giallu at gmail.com (Gianluca Sforna)
Date: Thu, 16 Mar 2006 16:30:00 +0100
Subject: Vim-7 Preview
In-Reply-To: <d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
Message-ID: <d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>

On 3/16/06, Michael Weiner <hunter at userfriendly.net> wrote:
>
> any chance of posting the src.rpm and/or spec file?

It seems to be there...
http://people.redhat.com/karsten/vim-7.0aa.000-1.src.rpm

Cheers

Gianluca



From karsten at redhat.de  Thu Mar 16 15:31:51 2006
From: karsten at redhat.de (Karsten Hopp)
Date: Thu, 16 Mar 2006 16:31:51 +0100
Subject: Vim-7 Preview
In-Reply-To: <d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>
References: <4419531C.3070803@redhat.de>	<1142512145.14319.23.camel@gilboa-work-dev>	<d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
	<d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>
Message-ID: <441984E7.9000603@redhat.de>

Gianluca Sforna wrote:
> On 3/16/06, Michael Weiner <hunter at userfriendly.net> wrote:
>> any chance of posting the src.rpm and/or spec file?
> 
> It seems to be there...
> http://people.redhat.com/karsten/vim-7.0aa.000-1.src.rpm
> 
> Cheers
> 
> Gianluca
> 

I've uploaded it one moment ago...

    Karsten

-- 
Learn. Network. Experience open source.
Red Hat Summit Nashville  |  May 30 - June 2, 2006
Learn more: http://www.redhat.com/promo/summit/



From giallu at gmail.com  Thu Mar 16 15:33:44 2006
From: giallu at gmail.com (Gianluca Sforna)
Date: Thu, 16 Mar 2006 16:33:44 +0100
Subject: Vim-7 Preview
In-Reply-To: <441984E7.9000603@redhat.de>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
	<d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>
	<441984E7.9000603@redhat.de>
Message-ID: <d5ad21470603160733m1c7b0ebey7dd4952f82eae11a@mail.gmail.com>

On 3/16/06, Karsten Hopp <karsten at redhat.de> wrote:
>
> I've uploaded it one moment ago...
>

wow. that was fast...



From hunter at userfriendly.net  Thu Mar 16 15:34:35 2006
From: hunter at userfriendly.net (Michael Weiner)
Date: Thu, 16 Mar 2006 10:34:35 -0500
Subject: Vim-7 Preview
In-Reply-To: <441984E7.9000603@redhat.de>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
	<d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>
	<441984E7.9000603@redhat.de>
Message-ID: <d71b98be0603160734w57b52f3dma5fd464fab1c7873@mail.gmail.com>

On 3/16/06, Karsten Hopp <karsten at redhat.de> wrote:
>
> Gianluca Sforna wrote:
> > On 3/16/06, Michael Weiner <hunter at userfriendly.net> wrote:
> >> any chance of posting the src.rpm and/or spec file?
> >
> > It seems to be there...
> > http://people.redhat.com/karsten/vim-7.0aa.000-1.src.rpm
> >
> > Cheers
> >
> > Gianluca
> >
>
> I've uploaded it one moment ago...



Thank you both!!!Michael Weiner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060316/d7e51fdd/attachment.htm>

From rstrode at redhat.com  Thu Mar 16 15:47:38 2006
From: rstrode at redhat.com (Ray Strode)
Date: Thu, 16 Mar 2006 10:47:38 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142522804.10508.3.camel@shuttle.273piedmont.org>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
	<1142522804.10508.3.camel@shuttle.273piedmont.org>
Message-ID: <1142524058.15964.2.camel@halflap>

Hi,
> On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote:
> > I believe the plan is to upgrade in FC5 updates, within a few days of
> > the FC5 release.
> > 
> 
> Do you know if there is any plan to update libnotify to 0.3.2 for FC5?
> I've got a couple of packages (gossip, xchat-gnome) that don't work with
> 0.3.0 due to the api change.
It was considered, but it requires the new notification daemon, and the
new notification daemon requires libsexy which we don't ship.  At the
time, it was a bit late in the development cycle to add a new package to
the distribution.

If you file a bug though, maybe we can do something.  For instance, make
libsexy configure time optional or something.  Hard to say at this
point.

--Ray





From pertusus at free.fr  Thu Mar 16 16:00:43 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 16 Mar 2006 17:00:43 +0100
Subject: Help Needed: FC5 Blocker List and Rawhide Install Testing
In-Reply-To: <44174CA6.7060008@mharris.ca>
References: <440CD6DC.6020903@redhat.com> <20060308153307.GF2238@free.fr>
	<20060308164612.1edb3f29@soran.addix.net>
	<20060308160409.GI2238@free.fr>
	<20060308171123.04f74390@soran.addix.net>
	<4416C371.7000603@gmail.com> <44174CA6.7060008@mharris.ca>
Message-ID: <20060316160043.GG2262@free.fr>

> Rawhide developmental growing pains.  Clean OS installs will not have
> this problem, and upgrades direct from FC3/FC4 or older to FC5 final
> should either not have this problem, or should have very minimal
> issues at best.

As I said in the mail at the origin of the thread, there are a lot of
include files in /usr/X11R6/include/X11, and some directories and symlinks
in other directories, all are unowned (the openmotif issue is more serious
but seems unrelated).

Not a big deal. Maybe this could be documented in the release notes?

All in all I think that this can be considered as a successfull update.

> >The files in the -devel package install to /usr/include/X11 which was 
> >(and might still be, if rpm -qf is reporting ownership of those files) 
> >symlinked to /usr/X11R6/include/X11

It is not, at least in my case (FC-4 to devel yum update, a few days ago).

--
Pat



From karsten at redhat.de  Thu Mar 16 16:29:09 2006
From: karsten at redhat.de (Karsten Hopp)
Date: Thu, 16 Mar 2006 17:29:09 +0100
Subject: Vim-7 Preview
In-Reply-To: <1142512145.14319.23.camel@gilboa-work-dev>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
Message-ID: <44199255.7020106@redhat.de>

Gilboa Davara wrote:
> On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
>> Hello,
>>
>> I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
>>
>> Most prominent new features are gvim with windows in multiple tab pages  (:help tabpage),
>> spell checking (:help spell) and omni-completion (:help new-omni-completion).
>>
>> A description of the new features of vim-7 is available with :help version7
>>
>> Please report any problems in bugzilla and make sure to mention the package version
>>
>> Have fun...
>>    Karsten
>>
> 
> Yey!
> Can the .spec be modified to co-exist with 6?
> E.g. /usr/bin/vim7XXX?
> 
> Gilboa

Done in vim7-7.0aa.000-2, available from the same place.

    Karsten

-- 
Learn. Network. Experience open source.
Red Hat Summit Nashville  |  May 30 - June 2, 2006
Learn more: http://www.redhat.com/promo/summit/



From bruno at wolff.to  Thu Mar 16 16:35:29 2006
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 16 Mar 2006 10:35:29 -0600
Subject: 2GB swap partition limit?
In-Reply-To: <200603160920.58342.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603160920.58342.russell@coker.com.au>
Message-ID: <20060316163529.GB11682@wolff.to>

On Thu, Mar 16, 2006 at 09:20:54 +1100,
  Russell Coker <russell at coker.com.au> wrote:
> 
> In most cases your machine will become totally unusable long before the 4G 
> space is used, and often it would be more desirable to have the OOM killer 
> kill something before it gets to that stage.  When configuring machines with 
> more than about 512M of RAM I never use 2*RAM for swap size for this reason.

If you want a reliable system you don't want to turn on the oom killer.
When you do this you need to have swap space available for all allocated
memory even if it isn't being used. In this case you can have swap space
much larger than will actually be used in practice. Note that there are
cases where processes don't have there own copy of memory they have allocated
to them. A common case is memory in use when a fork is done that hasn't been
modified.



From jkeating at j2solutions.net  Thu Mar 16 17:00:31 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 16 Mar 2006 09:00:31 -0800
Subject: 2GB swap partition limit?
In-Reply-To: <200603162218.14119.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>	<200603160920.58342.russell@coker.com.au>	<20060316095123.GA74693@dspnet.fr.eu.org>
	<200603162218.14119.russell@coker.com.au>
Message-ID: <441999AF.1030505@j2solutions.net>

On 03/16/2006 Russell Coker wrote:

> Good point.  How well does suspend to disk work nowadays?  The reports I've 
> heard in the past have suggested that certain types of hardware could cause 
> the machine to be in an uncertain state on resume so I've avoided using it to 
> keep my data safe.


It has been working very well on my laptop.  Some of the folks at RH
spent time testing w/ various laptops that people would bring in and
fixing bugs found.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)

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

From vonbrand at inf.utfsm.cl  Thu Mar 16 17:14:14 2006
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Thu, 16 Mar 2006 13:14:14 -0400
Subject: 2GB swap partition limit? 
In-Reply-To: Your message of "Fri, 17 Mar 2006 01:00:47 +1100."
	<200603170100.51395.russell@coker.com.au> 
Message-ID: <200603161714.k2GHEEd4006846@laptop11.inf.utfsm.cl>

Russell Coker <russell at coker.com.au> wrote:
> On Friday 17 March 2006 00:35, "Mauro Mozzarelli" <mmkernel at ezplanet.net> 
> wrote:
> > >> > Incidentally such a large swap space will not do you any good in most
> > >> > usage scenarios.
> > >>
> > >> Three words: "suspend to disk".
> >
> > I use it for "tmpfs"

> There are situations where machines can perform very well with a tmpfs
> that is significantly larger than RAM.  There was one time that one of my
> machines with 512M of RAM needed a 6G tmpfs and gave really good
> performance with 6G of swap.

> There are also some applications that have a working set which is far
> smaller than the full allocated memory space and which perform well when
> they are mostly swapped out.

Exactly. Plus disk (even expensive, high-end ones) are /s l o w/. You need
to put enough RAM into the machine for what it needs, in which case you use
swap mostly for whatever load spikes run over that, and you care enough not
to let OOM take over... and that is completely unpredictable, unless you
have a very detailed knowledge of the expected load, so any "swap is X
times RAM" advise is bogus. But then again, disk is cheap, and you have to
tell people /something/...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From bdpepple at ameritech.net  Thu Mar 16 16:55:06 2006
From: bdpepple at ameritech.net (Brian Pepple)
Date: Thu, 16 Mar 2006 11:55:06 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142524058.15964.2.camel@halflap>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
	<1142522804.10508.3.camel@shuttle.273piedmont.org>
	<1142524058.15964.2.camel@halflap>
Message-ID: <1142528106.12669.4.camel@shuttle.273piedmont.org>

On Thu, 2006-03-16 at 10:47 -0500, Ray Strode wrote:
> Hi,
> > On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote:
> > > I believe the plan is to upgrade in FC5 updates, within a few days of
> > > the FC5 release.
> > > 
> > 
> > Do you know if there is any plan to update libnotify to 0.3.2 for FC5?
> > I've got a couple of packages (gossip, xchat-gnome) that don't work with
> > 0.3.0 due to the api change.
> It was considered, but it requires the new notification daemon, and the
> new notification daemon requires libsexy which we don't ship.  At the
> time, it was a bit late in the development cycle to add a new package to
> the distribution.
> 
> If you file a bug though, maybe we can do something.  For instance, make
> libsexy configure time optional or something.  Hard to say at this
> point.

Ray, thanks for the update.  I glanced at the latest notification daemon
tarball, and it looks fairly straight forward to make the libsexy
dependency option.  The only use of libsexy is in the theme.c file, and
it involves sexy-url-label.  If I've got some time this weekend, I'll
work on a patch to make libsexy option.

/B
-- 
Brian Pepple <bdpepple at ameritech.net>

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

From gilboad at gmail.com  Thu Mar 16 17:27:16 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Thu, 16 Mar 2006 19:27:16 +0200
Subject: Vim-7 Preview
In-Reply-To: <44199255.7020106@redhat.de>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<44199255.7020106@redhat.de>
Message-ID: <1142530036.26525.11.camel@gilboa-work-dev>

On Thu, 2006-03-16 at 17:29 +0100, Karsten Hopp wrote:
> Gilboa Davara wrote:
> > On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> >> Hello,
> >>
> >> I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
> >>
> >> Most prominent new features are gvim with windows in multiple tab pages  (:help tabpage),
> >> spell checking (:help spell) and omni-completion (:help new-omni-completion).
> >>
> >> A description of the new features of vim-7 is available with :help version7
> >>
> >> Please report any problems in bugzilla and make sure to mention the package version
> >>
> >> Have fun...
> >>    Karsten
> >>
> > 
> > Yey!
> > Can the .spec be modified to co-exist with 6?
> > E.g. /usr/bin/vim7XXX?
> > 
> > Gilboa
> 
> Done in vim7-7.0aa.000-2, available from the same place.
> 
>     Karsten
> 

Thanks!

I'll install it on i386 and rebuild/install on x86_64 tomorrow.
BTW, which vim build is it?

Gilboa



From lamont at gurulabs.com  Thu Mar 16 18:00:07 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Thu, 16 Mar 2006 11:00:07 -0700
Subject: 2GB swap partition limit?
In-Reply-To: <200603161714.k2GHEEd4006846@laptop11.inf.utfsm.cl>
References: <200603161714.k2GHEEd4006846@laptop11.inf.utfsm.cl>
Message-ID: <200603161100.08004.lamont@gurulabs.com>

On Thursday 16 March 2006 10:14am, Horst von Brand wrote:
> Russell Coker <russell at coker.com.au> wrote:
> > On Friday 17 March 2006 00:35, "Mauro Mozzarelli" <mmkernel at ezplanet.net>
> >
> > wrote:
> > > >> > Incidentally such a large swap space will not do you any good in
> > > >> > most usage scenarios.
> > > >>
> > > >> Three words: "suspend to disk".
> > >
> > > I use it for "tmpfs"
> >
> > There are situations where machines can perform very well with a tmpfs
> > that is significantly larger than RAM.  There was one time that one of my
> > machines with 512M of RAM needed a 6G tmpfs and gave really good
> > performance with 6G of swap.
> >
> > There are also some applications that have a working set which is far
> > smaller than the full allocated memory space and which perform well when
> > they are mostly swapped out.
>
> Exactly. Plus disk (even expensive, high-end ones) are /s l o w/. You need
> to put enough RAM into the machine for what it needs, in which case you use
> swap mostly for whatever load spikes run over that, and you care enough not
> to let OOM take over... and that is completely unpredictable, unless you
> have a very detailed knowledge of the expected load, so any "swap is X
> times RAM" advise is bogus. But then again, disk is cheap, and you have to
> tell people /something/...

IMHO, the main reason that the common advice is something like "2x RAM" is 
that those in the know were not willing or able (for whatever reason(s)) to 
explain the real truth to newbies, and that led to people thinking that it 
was some magic number.  I've even heard otherwise intelligent, knowledgeable 
admins tell people that you *absolutely must* make swap 2x RAM or it won't 
work or "performance will be horrid at best."

But, it's understandable; not everyone can take the time required to properly 
educate.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060316/7120b31f/attachment.sig>

From pnasrat at redhat.com  Thu Mar 16 19:23:37 2006
From: pnasrat at redhat.com (Paul Nasrat)
Date: Thu, 16 Mar 2006 14:23:37 -0500
Subject: No Joy From Attempted Hard Disk Install With T3
In-Reply-To: <20060316050742.GC13846@rednote.net>
References: <20060316050742.GC13846@rednote.net>
Message-ID: <1142537018.2685.20.camel@enki.eridu>

On Thu, 2006-03-16 at 00:07 -0500, Janina Sajka wrote:
> I just attempted to install FC5T3 via hard disk and got the complaint
> about repo data. Just to be sure I tried both from the DVD iso and the 5
> disc iso set.
> 
> Is it just me? Have others succeeded installing from iso files on
> another hd partition? It would be nice for this to be working whith the
> FC5 release, of course.

We've definitely tested this post test3 and it should all be working for
FC5 final.

Paul



From pnasrat at redhat.com  Thu Mar 16 19:25:59 2006
From: pnasrat at redhat.com (Paul Nasrat)
Date: Thu, 16 Mar 2006 14:25:59 -0500
Subject: Vim-7 Preview
In-Reply-To: <4419531C.3070803@redhat.de>
References: <4419531C.3070803@redhat.de>
Message-ID: <1142537160.2685.22.camel@enki.eridu>

On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> Hello,
> 
> I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/

Running createrepo to make it a modern yum repo would be a good plan...

Paul



From thomas at apestaart.org  Thu Mar 16 21:22:13 2006
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Thu, 16 Mar 2006 22:22:13 +0100
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142520282.10076.1.camel@halflap>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
Message-ID: <1142544133.22487.0.camel@otto.amantes>

On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote:
> Hi,
> > It seems in final gnome 2.14 the optimum is:
> > gstreamer 0.10.4 and gst-plugins-base 0.10.5
> I believe the plan is to upgrade in FC5 updates, within a few days of
> the FC5 release.

I asked around and I didn't really get an answer on how come everything
that is in GNOME's release got upgraded to the actual released versions,
except GStreamer.  Any logic to that ? Can someone shed some light ?


Thanks
Thomas




From vonbrand at inf.utfsm.cl  Thu Mar 16 21:24:51 2006
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Thu, 16 Mar 2006 17:24:51 -0400
Subject: 2GB swap partition limit? 
In-Reply-To: Message from "Lamont R. Peterson" <lamont@gurulabs.com> of "Thu,
	16 Mar 2006 11:00:07 MST." <200603161100.08004.lamont@gurulabs.com> 
Message-ID: <200603162124.k2GLOpkQ009476@laptop11.inf.utfsm.cl>

Lamont R. Peterson <lamont at gurulabs.com> wrote:
> On Thursday 16 March 2006 10:14am, Horst von Brand wrote:
> > Russell Coker <russell at coker.com.au> wrote:

[...]

> > > There are situations where machines can perform very well with a tmpfs
> > > that is significantly larger than RAM.  There was one time that one of my
> > > machines with 512M of RAM needed a 6G tmpfs and gave really good
> > > performance with 6G of swap.
> > >
> > > There are also some applications that have a working set which is far
> > > smaller than the full allocated memory space and which perform well when
> > > they are mostly swapped out.

> > Exactly. Plus disk (even expensive, high-end ones) are /s l o w/. You need
> > to put enough RAM into the machine for what it needs, in which case you use
> > swap mostly for whatever load spikes run over that, and you care enough not
> > to let OOM take over... and that is completely unpredictable, unless you
> > have a very detailed knowledge of the expected load, so any "swap is X
> > times RAM" advise is bogus. But then again, disk is cheap, and you have to
> > tell people /something/...

> IMHO, the main reason that the common advice is something like "2x RAM" is 
> that those in the know were not willing or able (for whatever reason(s)) to 
> explain the real truth to newbies,

Try my above rant on the average newbie, and see eyes glazing over and feel
(more than see) the irresistible urge to run away from all such complexity,
fast...
 
>                                    and that led to people thinking that it 
> was some magic number.

;-)

>                         I've even heard otherwise intelligent, knowledgeable 
> admins tell people that you *absolutely must* make swap 2x RAM or it won't 
> work or "performance will be horrid at best."

Some Solaris boxen had to have swap > RAM, or it wouldn't be of any use, so
2x RAM was a reasonable compromise.

> But, it's understandable; not everyone can take the time required to
> properly educate.

Some of us try, but it is hard.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From katzj at redhat.com  Thu Mar 16 21:28:33 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 16 Mar 2006 16:28:33 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142544133.22487.0.camel@otto.amantes>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
	<1142544133.22487.0.camel@otto.amantes>
Message-ID: <1142544513.24422.6.camel@orodruin.boston.redhat.com>

On Thu, 2006-03-16 at 22:22 +0100, Thomas Vander Stichele wrote:
> On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote:
> > > It seems in final gnome 2.14 the optimum is:
> > > gstreamer 0.10.4 and gst-plugins-base 0.10.5
> > I believe the plan is to upgrade in FC5 updates, within a few days of
> > the FC5 release.
> 
> I asked around and I didn't really get an answer on how come everything
> that is in GNOME's release got upgraded to the actual released versions,
> except GStreamer.  Any logic to that ? Can someone shed some light ?

Not everything got upgraded.  It was basically a matter of looking at
diffs and trying to decide what was "safe".  I don't think that anyone
is 100% happy with how that process went.  

The plan is definitely to get the rest of the 2.14 final packages out as
an update ASAP after Monday and there's also going to be an effort to
actually track the stable releases as they're done this time around :-)

Jeremy



From mclasen at redhat.com  Thu Mar 16 21:31:21 2006
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 16 Mar 2006 16:31:21 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142544513.24422.6.camel@orodruin.boston.redhat.com>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
	<1142544133.22487.0.camel@otto.amantes>
	<1142544513.24422.6.camel@orodruin.boston.redhat.com>
Message-ID: <1142544681.19089.8.camel@golem.boston.redhat.com>

On Thu, 2006-03-16 at 16:28 -0500, Jeremy Katz wrote:
> On Thu, 2006-03-16 at 22:22 +0100, Thomas Vander Stichele wrote:
> > On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote:
> > > > It seems in final gnome 2.14 the optimum is:
> > > > gstreamer 0.10.4 and gst-plugins-base 0.10.5
> > > I believe the plan is to upgrade in FC5 updates, within a few days of
> > > the FC5 release.
> > 
> > I asked around and I didn't really get an answer on how come everything
> > that is in GNOME's release got upgraded to the actual released versions,
> > except GStreamer.  Any logic to that ? Can someone shed some light ?
> 
> Not everything got upgraded.  It was basically a matter of looking at
> diffs and trying to decide what was "safe".  I don't think that anyone
> is 100% happy with how that process went.  
> 
> The plan is definitely to get the rest of the 2.14 final packages out as
> an update ASAP after Monday and there's also going to be an effort to
> actually track the stable releases as they're done this time around :-)
> 

They (remaining 2.14 pieces) are already queued for updates.



From jspaleta at gmail.com  Thu Mar 16 21:34:55 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 16 Mar 2006 16:34:55 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142544513.24422.6.camel@orodruin.boston.redhat.com>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
	<1142544133.22487.0.camel@otto.amantes>
	<1142544513.24422.6.camel@orodruin.boston.redhat.com>
Message-ID: <604aa7910603161334i1b34e41y7c1f0ee87d95cdd3@mail.gmail.com>

On 3/16/06, Jeremy Katz <katzj at redhat.com> wrote:
> Not everything got upgraded.  It was basically a matter of looking at
> diffs and trying to decide what was "safe".  I don't think that anyone
> is 100% happy with how that process went.
>
> The plan is definitely to get the rest of the 2.14 final packages out as
> an update ASAP after Monday and there's also going to be an effort to
> actually track the stable releases as they're done this time around :-)

Thank you for giving me yet another excuse to sit on the patches to
make istanbul in Extras build on 64bit. Now that i know the new gst is
going to be updated asap... makes working on gst08 istanbul package
this weekend particularly pointless when I'll be able to finally roll
a gst 0.10 with the gst update.

-jef



From thacker at math.cornell.edu  Thu Mar 16 22:18:51 2006
From: thacker at math.cornell.edu (John Thacker)
Date: Thu, 16 Mar 2006 17:18:51 -0500
Subject: which gstreamer versions in official fc5?
In-Reply-To: <1142544133.22487.0.camel@otto.amantes>
References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com>
	<1142520282.10076.1.camel@halflap>
	<1142544133.22487.0.camel@otto.amantes>
Message-ID: <20060316221851.GA18534@localhost.localdomain>

On Thu, Mar 16, 2006 at 10:22:13PM +0100, Thomas Vander Stichele wrote:
> 
> I asked around and I didn't really get an answer on how come everything
> that is in GNOME's release got upgraded to the actual released versions,
> except GStreamer.  Any logic to that ? Can someone shed some light ?

Among other things, GStreamer was not subject to the rigorous freezes
that the rest of GNOME was.  It's developed in a more independent fashion.
Hence, the difference between the 2.13.9x GNOME releases and 2.14 was
much smaller and safer, compared to the difference in GStreamer.
You know that, of course, based on the fact that you started this
thread on GNOME's release-team mailing list:
http://mail.gnome.org/archives/release-team/2006-March/msg00126.html

John Thacker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060316/6c1bcaca/attachment.sig>

From mmkernel at ezplanet.net  Thu Mar 16 23:59:38 2006
From: mmkernel at ezplanet.net (Mauro Mozzarelli)
Date: Thu, 16 Mar 2006 23:59:38 -0000 (GMT)
Subject: Building openoffice 2.0.2-5.2.2 fails
In-Reply-To: <1142508600.8054.29.camel@localhost.localdomain>
References: <44862.217.33.199.76.1142507774.squirrel@mauro.ezplanet.net>
	<1142508600.8054.29.camel@localhost.localdomain>
Message-ID: <35257.195.137.28.94.1142553578.squirrel@mauro.ezplanet.net>


On Thu, March 16, 2006 11:29, Caolan McNamara wrote:
> On Thu, 2006-03-16 at 11:16 +0000, Mauro Mozzarelli wrote:
>> Hi All,
>>
>> When I build openoffice after hours and hours, during the "install"
>> process I get the following:
>>
>> ==============================
>> +
>> /var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/program/configimport
>> -e
>> file:///var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/share/registry
>> /usr/src/ezplanet/SOURCES/RegisterAndLicence.xcu
>> configimport.bin - Unhandled exception caught in main:
>> "configmgr::backend::ImportHandler: Could not get output handler for
>> component org.openoffice.Setup due to a backend exception:
>>  MultiStratumBackend: No Backend supports Entity:
>> "file:///var/tmp/openoffice.org-2.0.2-root//usr/lib/openoffice.org2.0/share/registry"
>> error: Bad exit status from /var/tmp/rpm-tmp.19514 (%install)
>>
>> ===========================
>>
>> The same was happening with 2.0.2-5.1.2
>>
>> Anyone knows what could be wrong?
>
> Never seen anything like that in all the times I've built OOo, so have
> you made any modifications at all ?
>
> If not then perhaps it's something that happens differently for you
> because of a different locale. So as a wild stab in the dark I'd try
> adding a
>
> export LANG=en_US.UTF-8
> to the %install section of the spec.
>
>
> If you have the ruins of your build still around then you can try and
> manually run something like...
>
> /var/tmp/foo/.../openoffice.org/program/configimport -e
> file://./var/tmp/foo..openoffice.org/share/registry
> /usr/src/ezplanet/SOURCES/RegisterAndLicence.xcu
>
> and experiment around with that.
>
> C.

Caolan,

Thank you for your reply I tried that, also exporting LANG as specified,
but I get still the same error:

/var/tmp/openoffice.org-2.0.2-root/usr/lib/openoffice.org2.0/program/configimport
-e
file:///var/tmp/openoffice.org-2.0.2-root/usr/lib/openoffice.org2.0/share/registry
/usr/src/ezplanet/SOURCES/RegisterAndLicence.xcu
configimport.bin - Unhandled exception caught in main:
"configmgr::backend::ImportHandler: Could not get output handler for
component org.openoffice.Setup due to a backend exception:
 MultiStratumBackend: No Backend supports Entity:
"file:///var/tmp/openoffice.org-2.0.2-root/usr/lib/openoffice.org2.0/share/registry"

I have tried the same specifying as entity the installed version in
/usr/lib/open.... with the same result.

If I change directory to:

/var/tmp/openoffice.org-2.0.2-root/usr/lib/openoffice.org2.0/share/registry

and than I execute configimport without specifying the entity, it does not
fail, but also it does not make the import (no changes to the files in the
directory tree)

M



From hellwolf at seu.edu.cn  Fri Mar 17 00:14:44 2006
From: hellwolf at seu.edu.cn (ZC Miao)
Date: Fri, 17 Mar 2006 08:14:44 +0800
Subject: ipw2200 net device's name issue
Message-ID: <1142554484.2173.6.camel@cocteau.freehell.org>

$uname -r
2.6.15-1.2054_FC5
$/sbin/ifconfig
dev20354  Link encap:Ethernet  HWaddr 00:0E:35:38:65:96
          UP 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:10 Base address:0xc000 Memory:d0100000-d0100fff
...

This happened for many times as I upgrade my kernel, sometimes it's
called eth1 as usual but somethimes it's called devxxxx as above. Is it
a but?
-- 
ZC Miao<hellwolf at seu.edu.cn>
http://hellwolf.cublog.cn/

gpg --keyserver keyserver.veridis.com --recv-key  0x6B174C6F

From naoki at valuecommerce.com  Fri Mar 17 00:40:27 2006
From: naoki at valuecommerce.com (Naoki)
Date: Fri, 17 Mar 2006 09:40:27 +0900
Subject: xen failure - xenstrore with 2.6.15-1.2009.4.2_FC5hypervisor#1
 SMP
In-Reply-To: <4419473F.3090209@adslpipe.co.uk>
References: <1142494310.2480.9.camel@dragon.sys.intra>	<1142494614.2480.12.camel@dragon.sys.intra>
	<4419473F.3090209@adslpipe.co.uk>
Message-ID: <441A057B.5040306@valuecommerce.com>


> 2.6.15-1.2009.4.2.FC5hypervisor isn't latest rawhide, you should use
> 2.6.15-1.2054_FC5xen0

Now I feel like a right pillock :)
Cheers Andy, will give it a go!
Don't know why yum hasn't noticed a newer kernel though...



From russell at coker.com.au  Fri Mar 17 00:52:18 2006
From: russell at coker.com.au (Russell Coker)
Date: Fri, 17 Mar 2006 11:52:18 +1100
Subject: 2GB swap partition limit?
In-Reply-To: <1142522601.4996.16.camel@pensja.lam.pl>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603170100.51395.russell@coker.com.au>
	<1142522601.4996.16.camel@pensja.lam.pl>
Message-ID: <200603171152.22242.russell@coker.com.au>

On Friday 17 March 2006 02:23, Leszek Matok <Lam at lam.pl> wrote:
> Dnia 17-03-2006, pi? o godzinie 01:00 +1100, Russell Coker napisa?(a):
> > the 2*RAM advice originated when 16M of RAM
> > was a big machine and that things are different now.
>
> Not really - iirc it appeared with Linux 2.4, which swaps more
> aggressively than 2.2. When 2.4 came out, 256 MiB of system memory was
> pretty common for small servers.

I used to run servers on Linux 1.2, 1.3, and 2.0 with amounts of RAM such as 
16M for which 2*RAM worked nicely.  The 2*RAM advice originated long before 
2.4.

http://www.coker.com.au/performance/linux-swap.html

I've written a brief web page to give some advice on this matter, see the 
above URL.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From smooge at gmail.com  Fri Mar 17 01:06:52 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Thu, 16 Mar 2006 18:06:52 -0700
Subject: 2GB swap partition limit?
In-Reply-To: <200603171152.22242.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603170100.51395.russell@coker.com.au>
	<1142522601.4996.16.camel@pensja.lam.pl>
	<200603171152.22242.russell@coker.com.au>
Message-ID: <80d7e4090603161706p7ac0b6d3i54be50fc8ebe2b70@mail.gmail.com>

On 3/16/06, Russell Coker <russell at coker.com.au> wrote:
> On Friday 17 March 2006 02:23, Leszek Matok <Lam at lam.pl> wrote:
> > Dnia 17-03-2006, pi? o godzinie 01:00 +1100, Russell Coker napisa?(a):
> > > the 2*RAM advice originated when 16M of RAM
> > > was a big machine and that things are different now.
> >
> > Not really - iirc it appeared with Linux 2.4, which swaps more
> > aggressively than 2.2. When 2.4 came out, 256 MiB of system memory was
> > pretty common for small servers.
>
> I used to run servers on Linux 1.2, 1.3, and 2.0 with amounts of RAM such as
> 16M for which 2*RAM worked nicely.  The 2*RAM advice originated long before
> 2.4.
>
> http://www.coker.com.au/performance/linux-swap.html
>
> I've written a brief web page to give some advice on this matter, see the
> above URL.
>

I am pretty sure that the recommendation is close to what the old
SunOS-4.1.x installation guide says. Set aside swap to be 2x your
actual memory for optimal performance. I am pretty sure I was pointed
to that a long time ago.


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From linville at redhat.com  Fri Mar 17 01:34:43 2006
From: linville at redhat.com (John W. Linville)
Date: Thu, 16 Mar 2006 20:34:43 -0500
Subject: ipw2200 net device's name issue
In-Reply-To: <1142554484.2173.6.camel@cocteau.freehell.org>
References: <1142554484.2173.6.camel@cocteau.freehell.org>
Message-ID: <20060317013440.GA19110@redhat.com>

On Fri, Mar 17, 2006 at 08:14:44AM +0800, ZC Miao wrote:
> $uname -r
> 2.6.15-1.2054_FC5
> $/sbin/ifconfig
> dev20354  Link encap:Ethernet  HWaddr 00:0E:35:38:65:96
>           UP 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:10 Base address:0xc000 Memory:d0100000-d0100fff

This is almost always a problem w/ your ifcfg-ethX scripts.
Please post their contents for analysis...thanks!

John
-- 
John W. Linville
linville at tuxdriver.com



From jreiser at BitWagon.com  Fri Mar 17 01:35:03 2006
From: jreiser at BitWagon.com (John Reiser)
Date: Thu, 16 Mar 2006 17:35:03 -0800
Subject: speed up Firefox start by a factor of 3 on x86
Message-ID: <441A1247.3050901@BitWagon.com>

The Firefox browser often takes 15 seconds to start because random placement
of the vDSO page disrupts the pre-linking of the 133 shared libraries involved.
(Fedora Core 5 Test 3, kernel-2.6.15-1.2054_FC5, updated by yum to today,
1.1GHz Athlon Plain, 768MB RAM, ext3 UDMA100 local disk.)  Similar delays
are encountered by any application that uses many or large shared libraries.

In contrast, Firefox always starts in 5 seconds or less on a kernel which places
the vDSO intelligently: just below the .text of ld-linux or the main executable.
This preserves the benefits of exec-shield (including randomization, when prelink
randomizes) without destroying performance.

Want to experience the difference for yourself?  These two kernels have
only my patch applied on top of what will be released Monday as Fedora Core 5:
  (14MB) http://bitwagon.com/ftp/kernel-2.6.15-1.2054_FC5.jreiser.i686.rpm
  (14MB) http://bitwagon.com/ftp/kernel-smp-2.6.15-1.2054_FC5.jreiser.i686.rpm
The source is
  (48MB) http://bitwagon.com/ftp/kernel-2.6.15-1.2054_FC5.jreiser.src.rpm
   (7KB) http://bitwagon.com/ftp/linux-2.6-x86-vdso-stacktop.patch
While running, you can revert to FC5 standard behavior by using
     echo 1  > /proc/sys/kernel/exec-shield
See the .patch for documentation.

This issue appears as part of
   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162797

-- 



From hellwolf at seu.edu.cn  Fri Mar 17 01:53:17 2006
From: hellwolf at seu.edu.cn (ZC Miao)
Date: Fri, 17 Mar 2006 09:53:17 +0800
Subject: ipw2200 net device's name issue
In-Reply-To: <1142554484.2173.6.camel@cocteau.freehell.org>
References: <1142554484.2173.6.camel@cocteau.freehell.org>
Message-ID: <1142560398.6135.0.camel@cocteau.freehell.org>

On Thu, 2006-03-16 at 20:34 -0500, John W. Linville wrote:
> This is almost always a problem w/ your ifcfg-ethX scripts.
> Please post their contents for analysis...thanks!
$cat /etc/sysconfig/network-scripts/ifcfg-eth1 # Please
read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
ONBOOT=no
USERCTL=no
IPV6INIT=no
PEERDNS=yes
TYPE=Wireless
DEVICE=eth1
HWADDR=00:0e:35:38:65:96
BOOTPROTO=none
NETMASK=255.255.255.0
DHCP_HOSTNAME=
IPADDR=192.168.128.3
DOMAIN=
ESSID=hellwolf
CHANNEL=11
MODE=Ad-Hoc
RATE=Auto


But I don't think it's relevant to my problem, because I could not ifup
my w-device just because the eth1 device didn't exist.
-- 
ZC Miao<hellwolf at seu.edu.cn>
http://hellwolf.cublog.cn/

gpg --keyserver keyserver.veridis.com --recv-key  0x6B174C6F

From gianluca.cecchi at gmail.com  Fri Mar 17 07:38:06 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Fri, 17 Mar 2006 08:38:06 +0100
Subject: speed up Firefox start by a factor of 3 on x86
Message-ID: <561c252c0603162338g4dc56dc4md55e7bd2d05c6a3b@mail.gmail.com>

On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote:
>In contrast, Firefox always starts in 5 seconds or less on a kernel
which places
>the vDSO intelligently:
I read the long list of your reports at the bugzilla page, with the
many details and test cases provided, but apart the beginning, you
pratically received no feedback at all (at least inside bugzilla
itself): only periodically that "having merged with upstream kernel,
more than thousands of changes, so please test again and let know..."
I think you had better to submit your considerations to upstream kernel list.
In this way if accepted, they would be naturally incorporated also in fedora.
I'm not a kernel expert so sorry if this doesn't fit for you.
Juest my 0.02 euros...



From buildsys at redhat.com  Fri Mar 17 08:04:09 2006
From: buildsys at redhat.com (Build System)
Date: Fri, 17 Mar 2006 03:04:09 -0500
Subject: rawhide report: 20060317 changes
Message-ID: <200603170804.k2H849qs022500@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5








From seg at haxxed.com  Fri Mar 17 08:12:01 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 17 Mar 2006 02:12:01 -0600
Subject: 2GB swap partition limit?
In-Reply-To: <200603162218.14119.russell@coker.com.au>
References: <1141561466.440ad87ae2478@www.jouy.inra.fr>
	<200603160920.58342.russell@coker.com.au>
	<20060316095123.GA74693@dspnet.fr.eu.org>
	<200603162218.14119.russell@coker.com.au>
Message-ID: <1142583121.9669.1.camel@localhost>

On Thu, 2006-03-16 at 22:18 +1100, Russell Coker wrote:
> Good point.  How well does suspend to disk work nowadays?  The reports I've 
> heard in the past have suggested that certain types of hardware could cause 
> the machine to be in an uncertain state on resume so I've avoided using it to 
> keep my data safe.

Been working just fine for some time on my fairly obscure Compal N38N2
laptop.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/f5240c98/attachment.sig>

From seg at haxxed.com  Fri Mar 17 08:19:06 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 17 Mar 2006 02:19:06 -0600
Subject: 2GB swap partition limit?
In-Reply-To: <200603161100.08004.lamont@gurulabs.com>
References: <200603161714.k2GHEEd4006846@laptop11.inf.utfsm.cl>
	<200603161100.08004.lamont@gurulabs.com>
Message-ID: <1142583547.9669.7.camel@localhost>

On Thu, 2006-03-16 at 11:00 -0700, Lamont R. Peterson wrote:
> IMHO, the main reason that the common advice is something like "2x RAM" is 
> that those in the know were not willing or able (for whatever reason(s)) to 
> explain the real truth to newbies, and that led to people thinking that it 
> was some magic number.  I've even heard otherwise intelligent, knowledgeable 
> admins tell people that you *absolutely must* make swap 2x RAM or it won't 
> work or "performance will be horrid at best."

Speaking from experience, the 2x RAM rule was quite real for some time.
2.4 was very swap happy, and early 2.6 had some rather nasty OOM killer
bugs...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/83f0a856/attachment.sig>

From laroche at redhat.com  Fri Mar 17 10:14:17 2006
From: laroche at redhat.com (Florian La Roche)
Date: Fri, 17 Mar 2006 11:14:17 +0100
Subject: ipw2200 net device's name issue
In-Reply-To: <1142560398.6135.0.camel@cocteau.freehell.org>
References: <1142554484.2173.6.camel@cocteau.freehell.org>
	<1142560398.6135.0.camel@cocteau.freehell.org>
Message-ID: <20060317101416.GA2425@dudweiler.stuttgart.redhat.com>

> ONBOOT=no
> DEVICE=eth1
> HWADDR=00:0e:35:38:65:96

I have ONBOOT=yes also for "eth0" (! That's probably also your
LAN.) and then things work fine for me.

I also got problems if the HWADDR is not specified. I think it might
be nice if the network drivers are only specified in /etc/modprobe.conf
and no HWADDR is needed at all.

regards,

Florian La Roche



From fedora at camperquake.de  Fri Mar 17 10:25:47 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 17 Mar 2006 11:25:47 +0100
Subject: ipw2200 net device's name issue
In-Reply-To: <20060317101416.GA2425@dudweiler.stuttgart.redhat.com>
References: <1142554484.2173.6.camel@cocteau.freehell.org>
	<1142560398.6135.0.camel@cocteau.freehell.org>
	<20060317101416.GA2425@dudweiler.stuttgart.redhat.com>
Message-ID: <20060317112547.61c53876@soran.addix.net>

Hi.

On Fri, 17 Mar 2006 11:14:17 +0100, Florian La Roche wrote:

> I also got problems if the HWADDR is not specified.

This is because the network scripts identify the card by HWADDR, and
then rename it to the "real" (ethX) network device name.



From russell at coker.com.au  Fri Mar 17 11:00:01 2006
From: russell at coker.com.au (Russell Coker)
Date: Fri, 17 Mar 2006 22:00:01 +1100
Subject: 2GB swap partition limit?
In-Reply-To: <1142583547.9669.7.camel@localhost>
References: <200603161714.k2GHEEd4006846@laptop11.inf.utfsm.cl>
	<200603161100.08004.lamont@gurulabs.com>
	<1142583547.9669.7.camel@localhost>
Message-ID: <200603172200.04985.russell@coker.com.au>

On Friday 17 March 2006 19:19, Callum Lerwick <seg at haxxed.com> wrote:
> On Thu, 2006-03-16 at 11:00 -0700, Lamont R. Peterson wrote:
> > IMHO, the main reason that the common advice is something like "2x RAM"
> > is that those in the know were not willing or able (for whatever
> > reason(s)) to explain the real truth to newbies, and that led to people
> > thinking that it was some magic number.  I've even heard otherwise
> > intelligent, knowledgeable admins tell people that you *absolutely must*
> > make swap 2x RAM or it won't work or "performance will be horrid at
> > best."
>
> Speaking from experience, the 2x RAM rule was quite real for some time.
> 2.4 was very swap happy, and early 2.6 had some rather nasty OOM killer
> bugs...

2.4 only swapped if it needed to.  I used to run some servers on 2.4 which had 
2G of RAM and only used about 20M of swap.  They ran a small number of 
programs (Qmail, and the Courier POP and IMAP servers) which generally had 
short lifetimes for processes and nothing got swapped.

It really depends on what you are doing.  Sometimes you can't even accurately 
determine what you need until you go live in production.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From veillard at redhat.com  Fri Mar 17 13:14:14 2006
From: veillard at redhat.com (Daniel Veillard)
Date: Fri, 17 Mar 2006 08:14:14 -0500
Subject: Vim-7 Preview
In-Reply-To: <441984E7.9000603@redhat.de>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
	<d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>
	<441984E7.9000603@redhat.de>
Message-ID: <20060317131414.GQ16792@redhat.com>

On Thu, Mar 16, 2006 at 04:31:51PM +0100, Karsten Hopp wrote:
> Gianluca Sforna wrote:
> >On 3/16/06, Michael Weiner <hunter at userfriendly.net> wrote:
> >>any chance of posting the src.rpm and/or spec file?
> >
> >It seems to be there...
> >http://people.redhat.com/karsten/vim-7.0aa.000-1.src.rpm
> >
> >Cheers
> >
> >Gianluca
> >
> 
> I've uploaded it one moment ago...

  Hum, doesn't seems to build on RHEL4:

        libSM-devel is needed by vim-7.0aa.000-1.i386
        libXt-devel is needed by vim-7.0aa.000-1.i386

that XFree86-devel renamed, normal

        libacl-devel is needed by vim-7.0aa.000-1.i386
        libselinux-devel is needed by vim-7.0aa.000-1.i386

that I don't understand, why should vim deal with ACL or SELinux ???

Daniel

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



From karsten at redhat.de  Fri Mar 17 13:54:27 2006
From: karsten at redhat.de (Karsten Hopp)
Date: Fri, 17 Mar 2006 14:54:27 +0100
Subject: Vim-7 Preview
In-Reply-To: <20060317131414.GQ16792@redhat.com>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
	<d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>
	<441984E7.9000603@redhat.de> <20060317131414.GQ16792@redhat.com>
Message-ID: <20060317135426.GA10650@redhat.de>

On Fri, Mar 17, 2006 at 08:14:14AM -0500, Daniel Veillard wrote:
> On Thu, Mar 16, 2006 at 04:31:51PM +0100, Karsten Hopp wrote:
> > Gianluca Sforna wrote:
> > >On 3/16/06, Michael Weiner <hunter at userfriendly.net> wrote:
> > >>any chance of posting the src.rpm and/or spec file?
> > >
> > >It seems to be there...
> > >http://people.redhat.com/karsten/vim-7.0aa.000-1.src.rpm
> > >
> > >Cheers
> > >
> > >Gianluca
> > >
> > 
> > I've uploaded it one moment ago...
> 
>   Hum, doesn't seems to build on RHEL4:
> 
>         libSM-devel is needed by vim-7.0aa.000-1.i386
>         libXt-devel is needed by vim-7.0aa.000-1.i386
> 
> that XFree86-devel renamed, normal
> 
>         libacl-devel is needed by vim-7.0aa.000-1.i386
>         libselinux-devel is needed by vim-7.0aa.000-1.i386
> 
> that I don't understand, why should vim deal with ACL or SELinux ???
> 
> Daniel
> 

vim needs to copy the security context / ACLs for backup files or when you
write back a file under a different name.

  Karsten


--
 Karsten Hopp <karsten at redhat.de>   GPG 1024D/70ABD02C
 Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C
 Red Hat Deutschland, Hauptstaetter Str.58
 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111



From hunter at userfriendly.net  Fri Mar 17 13:23:45 2006
From: hunter at userfriendly.net (=?ISO-8859-1?B?lSA=?=Michael Weiner)
Date: Fri, 17 Mar 2006 08:23:45 -0500
Subject: Vim-7 Preview
In-Reply-To: <20060317131414.GQ16792@redhat.com>
Message-ID: <C0402291.3C97C%hunter@userfriendly.net>

On 3/17/06 8:14 AM, "Daniel Veillard" <veillard at redhat.com> wrote:

> On Thu, Mar 16, 2006 at 04:31:51PM +0100, Karsten Hopp wrote:
>> Gianluca Sforna wrote:
>>> On 3/16/06, Michael Weiner <hunter at userfriendly.net> wrote:
>>>> any chance of posting the src.rpm and/or spec file?
>>> 
>>> It seems to be there...
>>> http://people.redhat.com/karsten/vim-7.0aa.000-1.src.rpm
>>> 
>>> Cheers
>>> 
>>> Gianluca
>>> 
>> 
>> I've uploaded it one moment ago...
> 
>   Hum, doesn't seems to build on RHEL4:
> 
>         libSM-devel is needed by vim-7.0aa.000-1.i386
>         libXt-devel is needed by vim-7.0aa.000-1.i386
> 
> that XFree86-devel renamed, normal
> 
>         libacl-devel is needed by vim-7.0aa.000-1.i386
>         libselinux-devel is needed by vim-7.0aa.000-1.i386
> 
> that I don't understand, why should vim deal with ACL or SELinux ???

Doesnt build nicely on an FC2 box either   :(  requirements include libSM,
libICE, and a few xorg devel packages - oh well.

Michael Weiner 




From karsten at redhat.de  Fri Mar 17 14:00:44 2006
From: karsten at redhat.de (Karsten Hopp)
Date: Fri, 17 Mar 2006 15:00:44 +0100
Subject: Vim-7 Preview
In-Reply-To: <C0402291.3C97C%hunter@userfriendly.net>
References: <20060317131414.GQ16792@redhat.com>
	<C0402291.3C97C%hunter@userfriendly.net>
Message-ID: <20060317140044.GB10650@redhat.de>

On Fri, Mar 17, 2006 at 08:23:45AM -0500, ? Michael Weiner wrote:
> On 3/17/06 8:14 AM, "Daniel Veillard" <veillard at redhat.com> wrote:
> 
> > On Thu, Mar 16, 2006 at 04:31:51PM +0100, Karsten Hopp wrote:
> >> Gianluca Sforna wrote:
> >>> On 3/16/06, Michael Weiner <hunter at userfriendly.net> wrote:
> >>>> any chance of posting the src.rpm and/or spec file?
> >>> 
> >>> It seems to be there...
> >>> http://people.redhat.com/karsten/vim-7.0aa.000-1.src.rpm
> >>> 
> >>> Cheers
> >>> 
> >>> Gianluca
> >>> 
> >> 
> >> I've uploaded it one moment ago...
> > 
> >   Hum, doesn't seems to build on RHEL4:
> > 
> >         libSM-devel is needed by vim-7.0aa.000-1.i386
> >         libXt-devel is needed by vim-7.0aa.000-1.i386
> > 
> > that XFree86-devel renamed, normal
> > 
> >         libacl-devel is needed by vim-7.0aa.000-1.i386
> >         libselinux-devel is needed by vim-7.0aa.000-1.i386
> > 
> > that I don't understand, why should vim deal with ACL or SELinux ???
> 
> Doesnt build nicely on an FC2 box either   :(  requirements include libSM,
> libICE, and a few xorg devel packages - oh well.
> 
> Michael Weiner 
> 

Well, it is a preview for the next Fedora Core and the build requirements are
for modular X.
Just delete all those build requirements, try to build it in a FC2 mock
buildroot and add build requirements again as needed.

   Karsten

--
 Karsten Hopp <karsten at redhat.de>   GPG 1024D/70ABD02C
 Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C
 Red Hat Deutschland, Hauptstaetter Str.58
 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111



From ivazquez at ivazquez.net  Fri Mar 17 14:15:54 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Fri, 17 Mar 2006 09:15:54 -0500
Subject: FC4 packages for vim7 (was: Re: Vim-7 Preview)
In-Reply-To: <4419531C.3070803@redhat.de>
References: <4419531C.3070803@redhat.de>
Message-ID: <1142604954.9064.21.camel@ignacio.lan>

On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
> 
> Most prominent new features are gvim with windows in multiple tab pages  (:help tabpage),
> spell checking (:help spell) and omni-completion (:help new-omni-completion).
> 
> A description of the new features of vim-7 is available with :help version7
> 
> Please report any problems in bugzilla and make sure to mention the package version

I've rebuilt the vim7 packages for FC4 and placed them in my repo.
They're exactly the same with the exception of the X-based
BuildRequires.

http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.i386.rpm
http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.i386.rpm
http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.i386.rpm
http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.i386.rpm
http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.i386.rpm
http://fedora.ivazquez.net/yum/4/i386/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.ppc.rpm
http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.ppc.rpm
http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.ppc.rpm
http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.ppc.rpm
http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.ppc.rpm
http://fedora.ivazquez.net/yum/4/ppc/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.x86_64.rpm
http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.x86_64.rpm
http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.x86_64.rpm
http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.x86_64.rpm
http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.x86_64.rpm
http://fedora.ivazquez.net/yum/4/x86_64/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/ff2e4808/attachment.sig>

From dax at gurulabs.com  Fri Mar 17 14:39:36 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Fri, 17 Mar 2006 7:39:36 -0700
Subject: Vim-7 Preview
In-Reply-To: <20060317131414.GQ16792@redhat.com>
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<d71b98be0603160724w4bd9bda8v73cc01995870f598@mail.gmail.com>
	<d5ad21470603160730v6b2f042ft105a407326dcd38a@mail.gmail.com>
	<441984E7.9000603@redhat.de> <20060317131414.GQ16792@redhat.com>
Message-ID: <3620-SnapperMsg827D11E1C0407AB4@[70.7.201.250]>

...... Original Message .......
On Fri, 17 Mar 2006 08:14:14 -0500 "Daniel Veillard" <veillard at redhat.com> 
wrote:
>that I don't understand, why should vim deal with ACL or SELinux ???
>

This feature was first introduced with the vim shipped with Red Hat Linux 9.

When you edit a file and save, behind the scenes, vim creates a new file 
and once that operation has completed it replaces the original with the new 
file. This is safer then doing a truncate and write to the original file as 
you will lose data if there is a crash after the truncate but before the 
write.

The safer technique requires extra work on vim's part to preserve metadata .

For file ACLs vim uses libacl. 
___
Dax Kelson
Sent with my Treo



From arjan at fenrus.demon.nl  Fri Mar 17 16:23:43 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Fri, 17 Mar 2006 17:23:43 +0100
Subject: speed up Firefox start by a factor of 3 on x86
In-Reply-To: <561c252c0603162338g4dc56dc4md55e7bd2d05c6a3b@mail.gmail.com>
References: <561c252c0603162338g4dc56dc4md55e7bd2d05c6a3b@mail.gmail.com>
Message-ID: <1142612623.3033.119.camel@laptopd505.fenrus.org>

On Fri, 2006-03-17 at 08:38 +0100, Gianluca Cecchi wrote:
> On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote:
> >In contrast, Firefox always starts in 5 seconds or less on a kernel
> which places
> >the vDSO intelligently:
> I read the long list of your reports at the bugzilla page, with the
> many details and test cases provided, but apart the beginning, you
> pratically received no feedback at all (at least inside bugzilla
> itself): only periodically that "having merged with upstream kernel,
> more than thousands of changes, so please test again and let know..."
> I think you had better to submit your considerations to upstream kernel list.
> In this way if accepted, they would be naturally incorporated also in fedora.
> I'm not a kernel expert so sorry if this doesn't fit for you.
> Juest my 0.02 euros...
> 

that's not going to fly since this is a fix to a fedora specific
patch ;)



From notting at redhat.com  Fri Mar 17 16:24:19 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 17 Mar 2006 11:24:19 -0500
Subject: ipw2200 net device's name issue
In-Reply-To: <1142554484.2173.6.camel@cocteau.freehell.org>
References: <1142554484.2173.6.camel@cocteau.freehell.org>
Message-ID: <20060317162419.GC7479@devserv.devel.redhat.com>

ZC Miao (hellwolf at seu.edu.cn) said: 
> $uname -r
> 2.6.15-1.2054_FC5
> $/sbin/ifconfig
> dev20354  Link encap:Ethernet  HWaddr 00:0E:35:38:65:96
>           UP 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:10 Base address:0xc000 Memory:d0100000-d0100fff
> ...
> 
> This happened for many times as I upgrade my kernel, sometimes it's
> called eth1 as usual but somethimes it's called devxxxx as above. Is it
> a but?

Say you have two devices configured in your ifcfg-XXX files:

eth0 - wired - hwaddr 00:11:22:33:44:55
eth1 - wireless - hwaddr 00:0E:35:38:65:96

What happens is that udev is loading the wireless module first, so it
becomes eth0, and your wired eth1. When you bring up your wired device,
we rename it to eth0 (as that's what's configured) - if your wireless
device is currently eth0, it will get moved out of the way to something
like what you see above; the wireless device will get renamed to eth1
when *it* is brought up.

We're working on code to do this all at module load time, but I wasn't
going to add that in the last week before release.

Bill



From gilboad at gmail.com  Fri Mar 17 16:35:59 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Fri, 17 Mar 2006 18:35:59 +0200
Subject: FC4 packages for vim7 (was: Re: Vim-7 Preview)
In-Reply-To: <1142604954.9064.21.camel@ignacio.lan>
References: <4419531C.3070803@redhat.de> <1142604954.9064.21.camel@ignacio.lan>
Message-ID: <1142613359.27041.57.camel@gilboa-home-dev.localhost>

On Fri, 2006-03-17 at 09:15 -0500, Ignacio Vazquez-Abrams wrote:
> On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> > I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
> > 
> > Most prominent new features are gvim with windows in multiple tab pages  (:help tabpage),
> > spell checking (:help spell) and omni-completion (:help new-omni-completion).
> > 
> > A description of the new features of vim-7 is available with :help version7
> > 
> > Please report any problems in bugzilla and make sure to mention the package version
> 
> I've rebuilt the vim7 packages for FC4 and placed them in my repo.
> They're exactly the same with the exception of the X-based
> BuildRequires.
> 
> http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.i386.rpm
> http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.i386.rpm
> http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.i386.rpm
> http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.i386.rpm
> http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.i386.rpm
> http://fedora.ivazquez.net/yum/4/i386/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
> http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.ppc.rpm
> http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.ppc.rpm
> http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.ppc.rpm
> http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.ppc.rpm
> http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.ppc.rpm
> http://fedora.ivazquez.net/yum/4/ppc/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
> http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.x86_64.rpm
> http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.x86_64.rpm
> http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.x86_64.rpm
> http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.x86_64.rpm
> http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.x86_64.rpm
> http://fedora.ivazquez.net/yum/4/x86_64/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
> 
> -- 

Thanks.
Save me a x86_64 build.

Gilboa



From Axel.Thimm at ATrpms.net  Fri Mar 17 18:56:55 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 17 Mar 2006 19:56:55 +0100
Subject: Reorganization of src.rpm: not arch agnostic
Message-ID: <20060317185655.GA3031@neu.nirvana>

Hi Jesse,

while putting together these src.rpms under one folder was a good
thing, it uncovers an issue with conditional and macro-dependent
BuildRequires, i.e. they become static and reveal the arch in nasty
ways.

For instance the current gcc src.rpm as it will be shipped with FC5
will only install (aka extract) on x86_64 systems. Other archs will
need to use --nodeps.

Not something one can really fix, not even really work around it in a
clean fashion, but I'd rather give a heads-up to such ugly beasts. :/
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/875918c7/attachment.sig>

From notting at redhat.com  Fri Mar 17 19:07:13 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 17 Mar 2006 14:07:13 -0500
Subject: Reorganization of src.rpm: not arch agnostic
In-Reply-To: <20060317185655.GA3031@neu.nirvana>
References: <20060317185655.GA3031@neu.nirvana>
Message-ID: <20060317190713.GA9046@devserv.devel.redhat.com>

Axel Thimm (Axel.Thimm at ATrpms.net) said: 
> while putting together these src.rpms under one folder was a good
> thing, it uncovers an issue with conditional and macro-dependent
> BuildRequires, i.e. they become static and reveal the arch in nasty
> ways.

Huh? These are the same SRPMS as always; there is no difference to
how they are generated with respect to previous releases, only in
how the ISOs were generated.

Bill



From jkeating at redhat.com  Fri Mar 17 19:08:16 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Mar 2006 11:08:16 -0800
Subject: Reorganization of src.rpm: not arch agnostic
In-Reply-To: <20060317185655.GA3031@neu.nirvana>
References: <20060317185655.GA3031@neu.nirvana>
Message-ID: <200603171108.27410.jkeating@redhat.com>

On Friday 17 March 2006 10:56, Axel Thimm wrote:
> while putting together these src.rpms under one folder was a good
> thing, it uncovers an issue with conditional and macro-dependent
> BuildRequires, i.e. they become static and reveal the arch in nasty
> ways.
>
> For instance the current gcc src.rpm as it will be shipped with FC5
> will only install (aka extract) on x86_64 systems. Other archs will
> need to use --nodeps.
>
> Not something one can really fix, not even really work around it in a
> clean fashion, but I'd rather give a heads-up to such ugly beasts. :/

Eww, indeed that is a side effect I was not aware of.  I'm going to have to 
think on this one for a bit and get some other folks to think about it as 
well.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/866ec0eb/attachment.sig>

From casimiro.barreto at gmail.com  Fri Mar 17 20:04:07 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 17 Mar 2006 17:04:07 -0300
Subject: Kernel have problems with several devices...
Message-ID: <441B1637.6050709@gmail.com>

Hello,

Latest kernel (kernel-2.6.15-1.2095_FC5) and others since 2009_FC5 have 
problems in identifying devices when box have ASUS P4S800-MX SE motherboard.

/var/log/messages read as follows:

Mar 17 16:30:29 terra syslogd 1.4.1: restart.
Mar 17 16:30:29 terra kernel: klogd 1.4.1, log source = /proc/kmsg started.
Mar 17 16:30:29 terra kernel: Linux version 2.6.15-1.2054_FC5 
(bhcompile at hs20-bc1-3.build.redhat.com) (gcc version 4.1.0 20060304 (Red 
Hat 4.1.0-3)) #1 Tue Mar 14 15:48:33 EST 2006
Mar 17 16:30:29 terra kernel: BIOS-provided physical RAM map:
Mar 17 16:30:29 terra kernel:  BIOS-e820: 0000000000000000 - 
000000000009fc00 (usable)
Mar 17 16:30:29 terra kernel:  BIOS-e820: 000000000009fc00 - 
00000000000a0000 (reserved)
Mar 17 16:30:29 terra kernel:  BIOS-e820: 00000000000e4000 - 
0000000000100000 (reserved)
Mar 17 16:30:29 terra kernel:  BIOS-e820: 0000000000100000 - 
000000001dfc0000 (usable)
Mar 17 16:30:29 terra kernel:  BIOS-e820: 000000001dfc0000 - 
000000001dfd0000 (ACPI data)
Mar 17 16:30:29 terra kernel:  BIOS-e820: 000000001dfd0000 - 
000000001e000000 (ACPI NVS)
Mar 17 16:30:29 terra kernel:  BIOS-e820: 00000000ff7c0000 - 
0000000100000000 (reserved)
Mar 17 16:30:29 terra kernel: 0MB HIGHMEM available.
Mar 17 16:30:29 terra kernel: 479MB LOWMEM available.
Mar 17 16:30:29 terra kernel: found SMP MP-table at 000ff780
Mar 17 16:30:29 terra kernel: Using x86 segment limits to approximate NX 
protection
Mar 17 16:30:29 terra rpc.statd[1463]: Version 1.0.8-rc2 Starting
Mar 17 16:30:29 terra kernel: DMI 2.3 present.
Mar 17 16:30:29 terra auditd[1478]: Init complete, auditd 1.1.5 
listening for events
Mar 17 16:30:30 terra kernel: ACPI: PM-Timer IO Port: 0x808
Mar 17 16:30:30 terra kernel: Intel MultiProcessor Specification v1.1
Mar 17 16:30:30 terra kernel:     Virtual Wire compatibility mode.
Mar 17 16:30:30 terra kernel: OEM ID: SiS      Product ID:  APIC at: 
0xFEE00000
Mar 17 16:30:30 terra kernel: Processor #0 15:3 APIC version 20
Mar 17 16:30:30 terra kernel: I/O APIC #2 Version 17 at 0xFEC00000.
Mar 17 16:30:30 terra kernel: Enabling APIC mode:  Flat.  Using 1 I/O APICs
Mar 17 16:30:30 terra kernel: Processors: 1
Mar 17 16:30:30 terra kernel: Allocating PCI resources starting at 
20000000 (gap: 1e000000:e17c0000)
Mar 17 16:30:30 terra kernel: Built 1 zonelists
Mar 17 16:30:30 terra kernel: Kernel command line: ro root=LABEL=/ rhgb 
quiet
Mar 17 16:30:30 terra kernel: Enabling fast FPU save and restore... done.
Mar 17 16:30:30 terra kernel: Enabling unmasked SIMD FPU exception 
support... done.
Mar 17 16:30:30 terra kernel: Initializing CPU#0
Mar 17 16:30:30 terra kernel: CPU 0 irqstacks, hard=c03d4000 soft=c03d3000
Mar 17 16:30:30 terra kernel: PID hash table entries: 2048 (order: 11, 
32768 bytes)
Mar 17 16:30:30 terra kernel: Detected 2794.059 MHz processor.
Mar 17 16:30:30 terra kernel: Using pmtmr for high-res timesource
Mar 17 16:30:30 terra kernel: Console: colour VGA+ 80x25
Mar 17 16:30:30 terra kernel: Dentry cache hash table entries: 65536 
(order: 6, 262144 bytes)
Mar 17 16:30:31 terra kernel: Inode-cache hash table entries: 32768 
(order: 5, 131072 bytes)
Mar 17 16:30:31 terra kernel: Memory: 482076k/491264k available (1914k 
kernel code, 8572k reserved, 774k data, 176k init, 0k highmem)
Mar 17 16:30:31 terra kernel: Checking if this processor honours the WP 
bit even in supervisor mode... Ok.
Mar 17 16:30:31 terra kernel: Calibrating delay using timer specific 
routine.. 5594.76 BogoMIPS (lpj=11189534)
Mar 17 16:30:31 terra kernel: Security Framework v1.0.0 initialized
Mar 17 16:30:31 terra kernel: SELinux:  Initializing.
Mar 17 16:30:31 terra kernel: SELinux:  Starting in permissive mode
Mar 17 16:30:31 terra kernel: selinux_register_security:  Registering 
secondary module capabilityMar 17 16:30:31 terra kernel: CPU: Trace 
cache: 12K uops, L1 D cache: 16K
Mar 17 16:30:31 terra kernel: CPU: L2 cache: 1024K
Mar 17 16:30:31 terra kernel: Intel machine check architecture supported.
Mar 17 16:30:31 terra hidd[1557]: Bluetooth HID daemon
Mar 17 16:30:31 terra kernel: Intel machine check reporting enabled on 
CPU#0.
Mar 17 16:30:31 terra kernel: CPU0: Intel P4/Xeon Extended MCE MSRs (12) 
available
Mar 17 16:30:31 terra kernel: CPU0: Thermal monitoring enabled
Mar 17 16:30:31 terra kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz 
stepping 03
Mar 17 16:30:31 terra kernel: Checking 'hlt' instruction... OK.
Mar 17 16:30:31 terra kernel: ACPI: setting ELCR to 0200 (from 0c28)
Mar 17 16:30:31 terra kernel: ExtINT not setup in hardware but reported 
by MP table
Mar 17 16:30:31 terra kernel: ENABLING IO-APIC IRQs
Mar 17 16:30:31 terra kernel: ..TIMER: vector=0x31 apic1=0 pin1=2 
apic2=0 pin2=0
Mar 17 16:30:31 terra kernel: checking if image is initramfs... it is
Mar 17 16:30:31 terra kernel: Freeing initrd memory: 995k freed
Mar 17 16:30:31 terra kernel: NET: Registered protocol family 16
Mar 17 16:30:31 terra kernel: ACPI: bus type pci registered
Mar 17 16:30:31 terra kernel: PCI: PCI BIOS revision 2.10 entry at 
0xf0031, last bus=1
Mar 17 16:30:31 terra kernel: PCI: Using configuration type 1
Mar 17 16:30:31 terra kernel: ACPI: Subsystem revision 20060127
Mar 17 16:30:31 terra kernel: ACPI: Interpreter enabled
Mar 17 16:30:31 terra kernel: ACPI: Using PIC for interrupt routing
Mar 17 16:30:31 terra kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Mar 17 16:30:31 terra kernel: PCI: Ignoring BAR0-3 of IDE controller 
0000:00:02.5
Mar 17 16:30:31 terra kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 
5 7 10 *11 12 14 15)
Mar 17 16:30:32 terra kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 
5 7 *10 11 12 14 15)
Mar 17 16:30:32 terra kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 
5 7 *10 11 12 14 15)
Mar 17 16:30:32 terra kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 
*5 7 10 11 12 14 15)
Mar 17 16:30:32 terra kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 
5 7 *10 11 12 14 15)
Mar 17 16:30:32 terra hpiod: 0.9.8 accepting connections at 50000...
Mar 17 16:30:32 terra kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 
*5 7 10 11 12 14 15)
Mar 17 16:30:32 terra kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 
5 7 10 11 12 14 15)
Mar 17 16:30:33 terra kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 
*5 7 10 11 12 14 15)
Mar 17 16:30:33 terra kernel: Linux Plug and Play Support v0.97 (c) Adam 
Belay
Mar 17 16:30:33 terra kernel: pnp: PnP ACPI init
Mar 17 16:30:33 terra kernel: pnp: PnP ACPI: found 14 devices
Mar 17 16:30:33 terra kernel: usbcore: registered new driver usbfs
Mar 17 16:30:33 terra kernel: usbcore: registered new driver hub
Mar 17 16:30:33 terra kernel: PCI: Using ACPI for IRQ routing
Mar 17 16:30:33 terra kernel: PCI: If a device doesn't work, try 
"pci=routeirq".  If it helps, post a report
Mar 17 16:30:33 terra kernel: pnp: 00:07: ioport range 0x290-0x297 has 
been reserved
Mar 17 16:30:33 terra kernel: PCI: Ignore bogus resource 6 [0:0] of 
0000:01:00.0
Mar 17 16:30:34 terra kernel: PCI: Bridge: 0000:00:01.0
Mar 17 16:30:34 terra kernel:   IO window: e000-efff
Mar 17 16:30:34 terra kernel:   MEM window: d7f00000-d7ffffff
Mar 17 16:30:34 terra kernel:   PREFETCH window: d8000000-dfffffff
Mar 17 16:30:34 terra kernel: apm: BIOS version 1.2 Flags 0x03 (Driver 
version 1.16ac)
Mar 17 16:30:34 terra kernel: apm: overridden by ACPI.
Mar 17 16:30:34 terra kernel: audit: initializing netlink socket 
(disabled)Mar 17 16:30:34 terra kernel: VFS: Disk quotas dquot_6.5.1
Mar 17 16:30:34 terra kernel: Dquot-cache hash table entries: 1024 
(order 0, 4096 bytes)
Mar 17 16:30:34 terra kernel: SELinux:  Registering netfilter hooks
Mar 17 16:30:35 terra kernel: Initializing Cryptographic API
Mar 17 16:30:35 terra kernel: ksign: Installing public key data
Mar 17 16:30:35 terra kernel: Loading keyring
Mar 17 16:30:35 terra kernel: - Added public key EE596B44DDA71123
Mar 17 16:30:35 terra kernel: - User ID: Red Hat, Inc. (Kernel Module 
GPG key)
Mar 17 16:30:35 terra kernel: io scheduler noop registered
Mar 17 16:30:35 terra kernel: io scheduler anticipatory registered
Mar 17 16:30:35 terra kernel: io scheduler deadline registered
Mar 17 16:30:35 terra kernel: io scheduler cfq registered (default)
Mar 17 16:30:35 terra hpiod: ParDevice::nibble_read failed: Input/output 
error
Mar 17 16:30:35 terra kernel: pci_hotplug: PCI Hot Plug PCI Core 
version: 0.5
Mar 17 16:30:35 terra kernel: ACPI: Processor [CPU1] (supports 8 
throttling states)
Mar 17 16:30:35 terra kernel: isapnp: Scanning for PnP cards...
Mar 17 16:30:35 terra kernel: isapnp: No Plug & Play device found
Mar 17 16:30:35 terra kernel: Real Time Clock Driver v1.12ac
Mar 17 16:30:35 terra kernel: Linux agpgart interface v0.101 (c) Dave Jones
Mar 17 16:30:35 terra kernel: agpgart: Detected SiS 661 chipset
Mar 17 16:30:35 terra kernel: agpgart: AGP aperture is 64M @ 0xe0000000
Mar 17 16:30:35 terra kernel: PNP: PS/2 Controller 
[PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
Mar 17 16:30:35 terra kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Mar 17 16:30:35 terra kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Mar 17 16:30:35 terra kernel: Serial: 8250/16550 driver $Revision: 1.90 
$ 4 ports, IRQ sharing enabled
Mar 17 16:30:36 terra kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) 
is a 16550A
Mar 17 16:30:36 terra kernel: 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 
16550A
Mar 17 16:30:36 terra kernel: RAMDISK driver initialized: 16 RAM disks 
of 16384K size 1024 blocksize
Mar 17 16:30:36 terra kernel: Uniform Multi-Platform E-IDE driver 
Revision: 7.00alpha2
Mar 17 16:30:36 terra kernel: ide: Assuming 33MHz system bus speed for 
PIO modes; override with idebus=xx
Mar 17 16:30:36 terra kernel: SIS5513: IDE controller at PCI slot 
0000:00:02.5
Mar 17 16:30:36 terra kernel: ACPI: PCI Interrupt Link [LNKA] enabled at 
IRQ 11
Mar 17 16:30:36 terra kernel: ACPI: PCI Interrupt 0000:00:02.5[A] -> 
Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Mar 17 16:30:36 terra kernel: SIS5513: chipset revision 1
Mar 17 16:30:36 terra kernel: SIS5513: not 100% native mode: will probe 
irqs later
Mar 17 16:30:36 terra kernel: SIS5513: SiS 962/963 MuTIOL IDE UDMA133 
controller
Mar 17 16:30:36 terra kernel:     ide0: BM-DMA at 0xffa0-0xffa7, BIOS 
settings: hda:DMA, hdb:DMA
Mar 17 16:30:36 terra kernel:     ide1: BM-DMA at 0xffa8-0xffaf, BIOS 
settings: hdc:DMA, hdd:DMA
Mar 17 16:30:37 terra kernel: hda: SAMSUNG SP0802N, ATA DISK drive
Mar 17 16:30:37 terra kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Mar 17 16:30:37 terra kernel: hdc: ST3120025A, ATA DISK drive
Mar 17 16:30:37 terra kernel: hdd: HL-DT-ST DVDRAM GSA-4163B, ATAPI 
CD/DVD-ROM drive
Mar 17 16:30:37 terra kernel: ide1 at 0x170-0x177,0x376 on irq 15
Mar 17 16:30:37 terra kernel: hda: max request size: 512KiB
Mar 17 16:30:37 terra kernel: hda: 156368016 sectors (80060 MB) 
w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
Mar 17 16:30:37 terra kernel: hda: cache flushes supported
Mar 17 16:30:37 terra kernel:  hda: hda1
Mar 17 16:30:37 terra kernel: hdc: max request size: 512KiB
Mar 17 16:30:37 terra kernel: hdc: 234441648 sectors (120034 MB) 
w/1024KiB Cache, CHS=16383/255/63, UDMA(100)
Mar 17 16:30:37 terra kernel: hdc: cache flushes supported
Mar 17 16:30:37 terra nfsd[1756]: nfssvc_versbits: +2 +3 +4ar 17 
16:30:37 terra kernel:  hdc: hdc1 hdc2 hdc3
Mar 17 16:30:37 terra kernel: hdd: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW 
drive, 2048kB Cache, UDMA(33)
Mar 17 16:30:38 terra kernel: Uniform CD-ROM driver Revision: 3.20
Mar 17 16:30:38 terra kernel: ide-floppy driver 0.99.newide
Mar 17 16:30:38 terra kernel: usbcore: registered new driver libusual
Mar 17 16:30:38 terra kernel: usbcore: registered new driver hiddev
Mar 17 16:30:38 terra kernel: usbcore: registered new driver usbhid
Mar 17 16:30:38 terra kernel: drivers/usb/input/hid-core.c: v2.6:USB HID 
core driver
Mar 17 16:30:38 terra kernel: mice: PS/2 mouse device common for all mice
Mar 17 16:30:39 terra kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, 
MD_SB_DISKS=27
Mar 17 16:30:39 terra kernel: md: bitmap version 4.39
Mar 17 16:30:39 terra kernel: NET: Registered protocol family 2
Mar 17 16:30:39 terra kernel: input: AT Translated Set 2 keyboard as 
/class/input/input0
Mar 17 16:30:39 terra kernel: IP route cache hash table entries: 4096 
(order: 2, 16384 bytes)
Mar 17 16:30:39 terra kernel: TCP established hash table entries: 16384 
(order: 6, 262144 bytes)
Mar 17 16:30:39 terra kernel: TCP bind hash table entries: 16384 (order: 
6, 327680 bytes)
Mar 17 16:30:39 terra kernel: TCP: Hash tables configured (established 
16384 bind 16384)
Mar 17 16:30:39 terra kernel: TCP reno registered
Mar 17 16:30:39 terra kernel: TCP bic registered
Mar 17 16:30:39 terra kernel: Initializing IPsec netlink socket
Mar 17 16:30:39 terra gpm[1816]: *** info [startup.c(95)]:
Mar 17 16:30:39 terra kernel: NET: Registered protocol family 1
Mar 17 16:30:39 terra gpm[1816]: Started gpm successfully. Entered 
daemon mode.
Mar 17 16:30:39 terra kernel: NET: Registered protocol family 17
Mar 17 16:30:39 terra gpm[1816]: *** info [mice.c(1766)]:
Mar 17 16:30:39 terra kernel: Using IPI Shortcut mode
Mar 17 16:30:39 terra gpm[1816]: imps2: Auto-detected intellimouse PS/2
Mar 17 16:30:39 terra kernel: ACPI wakeup devices:
Mar 17 16:30:40 terra kernel: UAR1 PS2K PS2M EUSB  USB USB2 USB3 AC97 
MC97 PCI1 PCI2 PCI3  MAC
Mar 17 16:30:40 terra kernel: ACPI: (supports S0 S1 S3 S4 S5)
Mar 17 16:30:40 terra kernel: Freeing unused kernel memory: 176k freed
Mar 17 16:30:40 terra kernel: Write protecting the kernel read-only 
data: 359k
Mar 17 16:30:40 terra kernel: SCSI subsystem initialized
Mar 17 16:30:40 terra kernel: sata_sis 0000:00:05.0: version 0.5
Mar 17 16:30:40 terra kernel: ACPI: PCI Interrupt Link [LNKB] enabled at 
IRQ 10
Mar 17 16:30:40 terra kernel: ACPI: PCI Interrupt 0000:00:05.0[A] -> 
Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
Mar 17 16:30:40 terra kernel: sata_sis 0000:00:05.0: Detected SiS 
180/181 chipset in SATA mode
Mar 17 16:30:40 terra kernel: ata1: SATA max UDMA/133 cmd 0xD080 ctl 
0xD002 bmdma 0xC800 irq 10
Mar 17 16:30:40 terra kernel: ata2: SATA max UDMA/133 cmd 0xCC00 ctl 
0xC882 bmdma 0xC808 irq 10
Mar 17 16:30:41 terra kernel: input: ImPS/2 Generic Wheel Mouse as 
/class/input/input1
Mar 17 16:30:41 terra kernel: ata1: SATA link down (SStatus 0)
Mar 17 16:30:41 terra kernel: scsi0 : sata_sis
Mar 17 16:30:41 terra kernel: ata2: SATA link down (SStatus 0)
Mar 17 16:30:41 terra kernel: scsi1 : sata_sis
Mar 17 16:30:41 terra kernel: EXT3-fs: INFO: recovery required on 
readonly filesystem.
Mar 17 16:30:41 terra kernel: EXT3-fs: write access will be enabled 
during recovery.
Mar 17 16:30:41 terra kernel: kjournald starting.  Commit interval 5 seconds
Mar 17 16:30:41 terra kernel: EXT3-fs: hda1: orphan cleanup on readonly 
fsar 17 16:30:42 terra kernel: SELinux:  Disabled at runtime.
Mar 17 16:30:42 terra kernel: SELinux:  Unregistering netfilter hooks
Mar 17 16:30:42 terra xinetd[1728]: xinetd Version 2.3.13 started with 
libwrap loadavg options compiled in.
Mar 17 16:30:42 terra xinetd[1728]: Started working: 0 available services
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt Link [LNKE] enabled at 
IRQ 10
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt 0000:00:03.0[A] -> 
Link [LNKE] -> GSI 10 (level, low) -> IRQ 10
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.0: OHCI Host Controller
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.0: new USB bus 
registered, assigned bus number 1
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.0: irq 10, io mem 
0xd7efc000
Mar 17 16:30:42 terra kernel: sis900.c: v1.08.09 Sep. 19 2005
Mar 17 16:30:42 terra kernel: usb usb1: configuration #1 chosen from 1 
choice
Mar 17 16:30:42 terra kernel: hub 1-0:1.0: USB hub found
Mar 17 16:30:42 terra kernel: hub 1-0:1.0: 3 ports detected
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt Link [LNKF] enabled at 
IRQ 5
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt 0000:00:03.1[B] -> 
Link [LNKF] -> GSI 5 (level, low) -> IRQ 5
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.1: OHCI Host Controller
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.1: new USB bus 
registered, assigned bus number 2
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.1: irq 5, io mem 
0xd7efd000
Mar 17 16:30:42 terra kernel: usb usb2: configuration #1 chosen from 1 
choice
Mar 17 16:30:42 terra kernel: hub 2-0:1.0: USB hub found
Mar 17 16:30:42 terra kernel: hub 2-0:1.0: 3 ports detected
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt Link [LNKG] enabled at 
IRQ 3
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt 0000:00:03.2[C] -> 
Link [LNKG] -> GSI 3 (level, low) -> IRQ 3
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.2: OHCI Host Controller
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.2: new USB bus 
registered, assigned bus number 3
Mar 17 16:30:42 terra kernel: ohci_hcd 0000:00:03.2: irq 3, io mem 
0xd7efe000
Mar 17 16:30:42 terra kernel: usb 1-1: new full speed USB device using 
ohci_hcd and address 2
Mar 17 16:30:42 terra kernel: usb usb3: configuration #1 chosen from 1 
choice
Mar 17 16:30:42 terra kernel: hub 3-0:1.0: USB hub found
Mar 17 16:30:42 terra kernel: hub 3-0:1.0: 2 ports detected
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt Link [LNKC] enabled at 
IRQ 10
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt 0000:00:02.7[C] -> 
Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
Mar 17 16:30:42 terra kernel: intel8x0_measure_ac97_clock: measured 
54781 usecs
Mar 17 16:30:42 terra kernel: intel8x0: clocking to 48000
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt Link [LNKD] enabled at 
IRQ 5
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> 
Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
Mar 17 16:30:42 terra kernel: 0000:00:04.0: Realtek RTL8201 PHY 
transceiver found at address 1.
Mar 17 16:30:42 terra kernel: 0000:00:04.0: Using transceiver found at 
address 1 as default
Mar 17 16:30:42 terra kernel: eth0: SiS 900 PCI Fast Ethernet at 0xd400, 
IRQ 5, 00:13:d4:3c:34:be.
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt Link [LNKH] enabled at 
IRQ 5
Mar 17 16:30:42 terra kernel: ACPI: PCI Interrupt 0000:00:03.3[D] -> 
Link [LNKH] -> GSI 5 (level, low) -> IRQ 5
Mar 17 16:30:42 terra kernel: ehci_hcd 0000:00:03.3: EHCI Host Controller
Mar 17 16:30:42 terra kernel: ehci_hcd 0000:00:03.3: new USB bus 
registered, assigned bus number 4
Mar 17 16:30:43 terra kernel: ehci_hcd 0000:00:03.3: irq 5, io mem 
0xd7eff000
Mar 17 16:30:43 terra kernel: ehci_hcd 0000:00:03.3: USB 2.0 started, 
EHCI 1.00, driver 10 Dec 2004
Mar 17 16:30:43 terra kernel: usb usb4: configuration #1 chosen from 1 
choice
Mar 17 16:30:43 terra kernel: hub 4-0:1.0: USB hub found
Mar 17 16:30:43 terra kernel: hub 4-0:1.0: 8 ports detected
Mar 17 16:30:43 terra kernel: Non-volatile memory driver v1.2Mar 17 
16:30:43 terra kernel: parport: PnPBIOS parport detected.
Mar 17 16:30:43 terra kernel: parport0: PC-style at 0x378 (0x778), irq 7 
[PCSPP,TRISTATE,EPP]
Mar 17 16:30:43 terra kernel: ohci_hcd 0000:00:03.0: Unlink after 
no-IRQ?  Controller is probably using the wrong IRQ.
Mar 17 16:30:43 terra kernel: lp0: using parport0 (interrupt-driven).
Mar 17 16:30:43 terra kernel: lp0: console ready
Mar 17 16:30:43 terra kernel: NET: Registered protocol family 10
Mar 17 16:30:43 terra kernel: lo: Disabled Privacy Extensions
Mar 17 16:30:43 terra kernel: IPv6 over IPv4 tunneling driver
Mar 17 16:30:43 terra kernel: ACPI: Power Button (FF) [PWRF]
Mar 17 16:30:43 terra kernel: ACPI: Power Button (CM) [PWRB]
Mar 17 16:30:43 terra kernel: ibm_acpi: ec object not found
Mar 17 16:30:43 terra kernel: md: Autodetecting RAID arrays.
Mar 17 16:30:43 terra kernel: md: autorun ...
Mar 17 16:30:43 terra kernel: md: ... autorun DONE.
Mar 17 16:30:43 terra kernel: device-mapper: 4.5.0-ioctl (2005-10-04) 
initialised: dm-devel at redhat.com
Mar 17 16:30:43 terra kernel: EXT3 FS on hda1, internal journal
Mar 17 16:30:43 terra kernel: kjournald starting.  Commit interval 5 seconds
Mar 17 16:30:43 terra kernel: EXT3 FS on hdc1, internal journal
Mar 17 16:30:43 terra kernel: EXT3-fs: mounted filesystem with ordered 
data mode.
Mar 17 16:30:43 terra kernel: kjournald starting.  Commit interval 5 seconds
Mar 17 16:30:43 terra kernel: EXT3 FS on hdc3, internal journal
Mar 17 16:30:43 terra kernel: EXT3-fs: mounted filesystem with ordered 
data mode.
Mar 17 16:30:43 terra kernel: Adding 779144k swap on /dev/hdc2.  
Priority:-1 extents:1 across:779144k
Mar 17 16:30:43 terra kernel: eth0: Media Link On 100mbps full-duplex
Mar 17 16:30:43 terra kernel: Bluetooth: Core ver 2.8
Mar 17 16:30:43 terra kernel: NET: Registered protocol family 31
Mar 17 16:30:43 terra kernel: Bluetooth: HCI device and connection 
manager initialized
Mar 17 16:30:43 terra kernel: Bluetooth: HCI socket layer initialized
Mar 17 16:30:43 terra kernel: Bluetooth: L2CAP ver 2.8
Mar 17 16:30:43 terra kernel: Bluetooth: L2CAP socket layer initialized
Mar 17 16:30:43 terra kernel: Bluetooth: HIDP (Human Interface 
Emulation) ver 1.1
Mar 17 16:30:43 terra kernel: i2c /dev entries driver
Mar 17 16:30:43 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:30:43 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:30:43 terra kernel: ppdev: user-space parallel port driver
Mar 17 16:30:43 terra kernel: Installing knfsd (copyright (C) 1996 
okir at monad.swb.de).
Mar 17 16:30:43 terra kernel: NFSD: Using /var/lib/nfs/v4recovery as the 
NFSv4 state recovery directory
Mar 17 16:30:43 terra kernel: NFSD: unable to find recovery directory 
/var/lib/nfs/v4recovery
Mar 17 16:30:43 terra kernel: NFSD: starting 90-second grace period
Mar 17 16:30:43 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:30:43 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:30:44 terra freshclam[1931]: Daemon started.
Mar 17 16:30:44 terra freshclam[1932]: freshclam daemon 0.88 (OS: 
linux-gnu, ARCH: i386, CPU: i686)
Mar 17 16:30:44 terra freshclam[1932]: ClamAV update process started at 
Fri Mar 17 16:30:44 2006
Mar 17 16:30:44 terra clamd[1933]: Daemon started.
Mar 17 16:30:44 terra clamd[1933]: clamd daemon 0.88 (OS: linux-gnu, 
ARCH: i386, CPU: i686)Mar 17 16:30:45 terra clamd[1934]: Unix socket 
file /tmp/clamd
Mar 17 16:30:45 terra clamd[1934]: Setting connection queue length to 15
Mar 17 16:30:45 terra clamd[1934]: Archive: Archived file size limit set 
to 10485760 bytes.
Mar 17 16:30:45 terra clamd[1934]: Archive: Recursion level limit set to 8.
Mar 17 16:30:45 terra clamd[1934]: Archive: Files limit set to 1000.
Mar 17 16:30:45 terra clamd[1934]: Archive: Compression ratio limit set 
to 250.
Mar 17 16:30:45 terra clamd[1934]: Archive support enabled.
Mar 17 16:30:45 terra clamd[1934]: Archive: RAR support disabled.
Mar 17 16:30:45 terra clamd[1934]: Portable Executable support enabled.
Mar 17 16:30:45 terra clamd[1934]: Detection of broken executables enabled.
Mar 17 16:30:45 terra clamd[1934]: Mail files support enabled.
Mar 17 16:30:45 terra clamd[1934]: OLE2 support enabled.
Mar 17 16:30:45 terra clamd[1934]: HTML support enabled.
Mar 17 16:30:45 terra clamd[1934]: Self checking every 1800 seconds.
*Mar 17 16:30:45 terra clamd[1934]: Clamuko: Can't register with Dazuko
Mar 17 16:30:49 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:30:49 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:30:57 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:30:57 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:31:04 terra freshclam[1932]: ERROR: Can't query 
current.cvd.clamav.net
Mar 17 16:31:04 terra freshclam[1932]: WARNING: Invalid DNS reply. 
Falling back to HTTP mode.
Mar 17 16:31:05 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:31:05 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:31:13 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:31:13 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:31:21 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:31:21 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:31:29 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:31:29 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:31:37 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:31:37 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:31:44 terra freshclam[1932]: ERROR: Can't get information 
about database.clamav.net: Temporary DNS error
Mar 17 16:31:44 terra freshclam[1932]: ERROR: No servers could be 
reached. Giving up
Mar 17 16:31:44 terra freshclam[1932]: Trying again in 5 secs...
Mar 17 16:31:45 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:31:45 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:31:49 terra freshclam[1932]: ClamAV update process started at 
Fri Mar 17 16:31:49 2006
Mar 17 16:31:53 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:31:53 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:32:01 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:32:01 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:32:09 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:32:09 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 17 16:32:09 terra freshclam[1932]: ERROR: Can't query 
current.cvd.clamav.net
Mar 17 16:32:09 terra freshclam[1932]: WARNING: Invalid DNS reply. 
Falling back to HTTP mode.
Mar 17 16:32:17 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:32:17 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 17 16:32:25 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:32:25 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 17 16:32:33 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 17 16:32:33 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
(...)*

Besides that, RAID1 is causing catastrophic faillure (system locks 
without even logging status) on these boards, when using 2 SATA HD 
configured with RAID1. The same happens with linear and RAID0 (ext3 
filesystem).

Perhaps it would be good to test boxes with the ASUS P4S800-MX SE.

Best regards,

Casimiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/7dcac0ac/attachment.htm>

From Axel.Thimm at ATrpms.net  Fri Mar 17 19:21:14 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 17 Mar 2006 20:21:14 +0100
Subject: Reorganization of src.rpm: not arch agnostic
In-Reply-To: <200603171108.27410.jkeating@redhat.com>
	<20060317190713.GA9046@devserv.devel.redhat.com>
References: <20060317185655.GA3031@neu.nirvana>
	<200603171108.27410.jkeating@redhat.com>
	<20060317185655.GA3031@neu.nirvana>
	<20060317190713.GA9046@devserv.devel.redhat.com>
Message-ID: <20060317192114.GC1621@neu.nirvana>

On Fri, Mar 17, 2006 at 02:07:13PM -0500, Bill Nottingham wrote:
> Axel Thimm (Axel.Thimm at ATrpms.net) said: 
> > while putting together these src.rpms under one folder was a good
> > thing, it uncovers an issue with conditional and macro-dependent
> > BuildRequires, i.e. they become static and reveal the arch in nasty
> > ways.
> 
> Huh? These are the same SRPMS as always; there is no difference to
> how they are generated with respect to previous releases, only in
> how the ISOs were generated.

either the issue wasn't present until now (no arch hardconding in
BuildRequires before FC5), or nobody noticed.

On Fri, Mar 17, 2006 at 11:08:16AM -0800, Jesse Keating wrote:
> On Friday 17 March 2006 10:56, Axel Thimm wrote:
> > while putting together these src.rpms under one folder was a good
> > thing, it uncovers an issue with conditional and macro-dependent
> > BuildRequires, i.e. they become static and reveal the arch in nasty
> > ways.
> >
> > For instance the current gcc src.rpm as it will be shipped with FC5
> > will only install (aka extract) on x86_64 systems. Other archs will
> > need to use --nodeps.
> >
> > Not something one can really fix, not even really work around it in a
> > clean fashion, but I'd rather give a heads-up to such ugly beasts. :/
> 
> Eww, indeed that is a side effect I was not aware of.  I'm going to have to 
> think on this one for a bit and get some other folks to think about it as 
> well.

I've been through this some time ago and had to give up. The cleanest
way would be for rpm to no hardcode these values but to always
evaluate them. E.g. have rpm -qRp ignore the require tags in the
header and reparse the specfile. But that's too invasive of a change
to fix something only nitpickers and buildsystems notice ... :/

I guess the only workaround is unpack-repack:

rpm -i --nodeps funny-1-2.src.rpm
rpmbuild -bs --target myarch funny.spec
</ugly>

The resulting src.rpm will be arch-specific for the target platform
containing the "real" BuildRequires.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/6ffe72c8/attachment.sig>

From notting at redhat.com  Fri Mar 17 20:16:56 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 17 Mar 2006 15:16:56 -0500
Subject: Reorganization of src.rpm: not arch agnostic
In-Reply-To: <20060317192114.GC1621@neu.nirvana>
References: <20060317185655.GA3031@neu.nirvana>
	<200603171108.27410.jkeating@redhat.com>
	<20060317185655.GA3031@neu.nirvana>
	<20060317190713.GA9046@devserv.devel.redhat.com>
	<20060317192114.GC1621@neu.nirvana>
Message-ID: <20060317201656.GD11123@devserv.devel.redhat.com>

Axel Thimm (Axel.Thimm at ATrpms.net) said: 
> On Fri, Mar 17, 2006 at 02:07:13PM -0500, Bill Nottingham wrote:
> > Axel Thimm (Axel.Thimm at ATrpms.net) said: 
> > > while putting together these src.rpms under one folder was a good
> > > thing, it uncovers an issue with conditional and macro-dependent
> > > BuildRequires, i.e. they become static and reveal the arch in nasty
> > > ways.
> > 
> > Huh? These are the same SRPMS as always; there is no difference to
> > how they are generated with respect to previous releases, only in
> > how the ISOs were generated.
> 
> either the issue wasn't present until now (no arch hardconding in
> BuildRequires before FC5), or nobody noticed.

Almost certainly the latter. The source RPMs shipped have always been
identical across architecture; if you want to process the buildreqs,
use the spec. Or have a package that Provides: anytihng not available
on that arch as a build req.

Bill



From florin at andrei.myip.org  Fri Mar 17 23:14:25 2006
From: florin at andrei.myip.org (Florin Andrei)
Date: Fri, 17 Mar 2006 15:14:25 -0800
Subject: ancient memtest86
Message-ID: <1142637265.3098.1.camel@rivendell.home.local>

The version of memtest86 included on the Fedora installer CDs as a boot
option is 1.55 while the newest memtest86 is now at version 3.2

Is there a non-obvious reason why FC would include such an old version?

-- 
Florin Andrei

http://florin.myip.org/



From jkeating at redhat.com  Fri Mar 17 23:19:20 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 17 Mar 2006 15:19:20 -0800
Subject: ancient memtest86
In-Reply-To: <1142637265.3098.1.camel@rivendell.home.local>
References: <1142637265.3098.1.camel@rivendell.home.local>
Message-ID: <200603171519.24243.jkeating@redhat.com>

On Friday 17 March 2006 15:14, Florin Andrei wrote:
> Is there a non-obvious reason why FC would include such an old version?

Probably because nobody files a bug and nobody really noticed it.  I even 
forgot it was there.  File a bug and we'll look at bumping it for FC6.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060317/0e313114/attachment.sig>

From wes.shull at gmail.com  Fri Mar 17 23:25:45 2006
From: wes.shull at gmail.com (Wes Shull)
Date: Fri, 17 Mar 2006 16:25:45 -0700
Subject: ancient memtest86
In-Reply-To: <1142637265.3098.1.camel@rivendell.home.local>
References: <1142637265.3098.1.camel@rivendell.home.local>
Message-ID: <d676b7a80603171525l3391d26aoffaaab1bd94619e8@mail.gmail.com>

On 3/17/06, Florin Andrei <florin at andrei.myip.org> wrote:
> The version of memtest86 included on the Fedora installer CDs as a boot
> option is 1.55 while the newest memtest86 is now at version 3.2
>
> Is there a non-obvious reason why FC would include such an old version?

There are two memtest86's, with different versioning:

The original:  http://www.memtest86.com/
Note 3.2 dates back to November 2004.

memtest86+, a fork:  http://www.memtest.org/
"The first version of Memtest86+ was released on early 2004, based on
memtest86 v3.0 that was not updated since mid-2002"

Fedora ships the latter.  Note that FC5 will include memtest86+ 1.65. 
Even + 1.55, from March 2005,  is newer than 3.2.

--wes



From rdieter at math.unl.edu  Fri Mar 17 23:37:03 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 17 Mar 2006 17:37:03 -0600
Subject: ancient memtest86
In-Reply-To: <1142637265.3098.1.camel@rivendell.home.local>
References: <1142637265.3098.1.camel@rivendell.home.local>
Message-ID: <441B481F.8040303@math.unl.edu>

Florin Andrei wrote:
> The version of memtest86 included on the Fedora installer CDs as a boot
> option is 1.55 while the newest memtest86 is now at version 3.2

Check your facts again (note memtest86 != memtest86+)  (-:

Now, keeping that in mind, per
http://www.memtest.org/
the latest memtest86+ seems to be 1.65

-- Rex



From ndbecker2 at gmail.com  Sat Mar 18 02:32:52 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 17 Mar 2006 21:32:52 -0500
Subject: python module loading broken on fedora?
Message-ID: <dvfrgk$3qs$1@sea.gmane.org>

I've been trying to track down a problem with python module loading for
multarch (x86_64).  I think we have a problem.  The discussion so far is
archived here:

http://mail.python.org/pipermail/python-dev/2006-March/062462.html

It seems that the system Fedora has setup here:

http://fedoraproject.org/wiki/Packaging/Python

is not really correct.



From jspaleta at gmail.com  Sat Mar 18 02:50:24 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 17 Mar 2006 21:50:24 -0500
Subject: python module loading broken on fedora?
In-Reply-To: <dvfrgk$3qs$1@sea.gmane.org>
References: <dvfrgk$3qs$1@sea.gmane.org>
Message-ID: <604aa7910603171850q32ab9ee9s6a6e95f82f654743@mail.gmail.com>

On 3/17/06, Neal Becker <ndbecker2 at gmail.com> wrote:
> I've been trying to track down a problem with python module loading for
> multarch (x86_64).  I think we have a problem.  The discussion so far is
> archived here:
>
> http://mail.python.org/pipermail/python-dev/2006-March/062462.html
>
> It seems that the system Fedora has setup here:
>
> http://fedoraproject.org/wiki/Packaging/Python
>
> is not really correct.

to clarify  for those wanting a quick summary of the referenced thread
the specific issue being the macros
python_sitelib and  python_sitearch
resolving to different paths on x86_64 and the upstream python
discussion seems to indicate this is bad mojo and not something python
is expected to handle gracefully..

-jef



From toshio at tiki-lounge.com  Sat Mar 18 06:23:44 2006
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Fri, 17 Mar 2006 22:23:44 -0800
Subject: python module loading broken on fedora?
In-Reply-To: <dvfrgk$3qs$1@sea.gmane.org>
References: <dvfrgk$3qs$1@sea.gmane.org>
Message-ID: <1142663024.5659.34.camel@localhost>

On Fri, 2006-03-17 at 21:32 -0500, Neal Becker wrote:
> I've been trying to track down a problem with python module loading for
> multarch (x86_64).  I think we have a problem.  The discussion so far is
> archived here:
> 
> http://mail.python.org/pipermail/python-dev/2006-March/062462.html
> 
> It seems that the system Fedora has setup here:
> 
> http://fedoraproject.org/wiki/Packaging/Python
> 
> is not really correct.
> 
Summary
=======
Actual failure case:
  One module being split into sitelib and sitearch directories (so on
  x86_64 you have /usr/lib/python2.4/site-packages/foomodule
  and /usr/lib64/python2.4/site-packages/foomodule

Martin v. L?wis says: separate site-arch/site-lib is unsupported and
probably shouldn't be done by Red Hat's python.

Thomas Wouters asks: where are the 32bit compiled modules on a 64-bit
install going to reside?  If they live in /usr/lib/python2.4 then the
64-bit python can't depend on that directory to be "noarch" anymore.  He
also questions whether byte-compiled (.pyc and .pyo) pure python modules
built on one architecture can be safely used on another.

Thoughts
========
We can address the actual failure simply by not splitting one module's
files into site-arch and site-lib.

Except for this corner case, it seems to work, so it's not something we
need to rush into changing.

There is a benefit to having separate site-arch and site-lib directories
*if* site-lib is actually in an architecture independent location (ie:
%{_datadir).  In addition to allowing 32 bit python to use /usr/lib for
compiled files and 64 bit python to use /usr/lib64 it also allows
network mounting the noarch modules between architectures as part
of /usr/share.

Unless it's changed recently, byte-compiled python (pyc and pyo) is arch
independent so concerns about using a python module byte compiled on a
different architecture are groundless.

In order for the actual failure to be resolved, someone would have to
teach the python interpreter to merge site-lib and site-arch before it
knows what symbols are available in a module instead of simply looking
for them in site-lib or site-arch.  What happens if there's conflicts?
What about other directories in the PYTHONPATH?  This step would not be
a minor change.

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

From kevinverma at gmail.com  Sat Mar 18 19:58:37 2006
From: kevinverma at gmail.com (Kevin Verma)
Date: Sun, 19 Mar 2006 01:28:37 +0530
Subject: Re-view FC5 hardware requirements for GNOME
Message-ID: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>

Hello,

Quoting on the subject, I had gone through a review article for Gnome
2.14 and I began wondering if FC5 release notes should mention a
reviewed hardware requirement for GNOME 2.14 based desktop
installations, as per the facts delivered in this review article (
http://www.linux.com/article.pl?sid=06/03/17/0350228 ).

"Still, even allowing for my unscientific timing, the increase in
speed is impressive. It should be especially welcome on older,
RAM-challenged machines."

For some reasons I am not using rawhide as of now, so some one else
would be in a better position to suggest and test further, Rahul ?

I will also like to mention couple of facts that member developers of
FC team from developed countries could learn during Linux Asia 06,
(since those are not qouted much anywhere else) that in developing
nations, power disruptions affected and low on resources machines ....
--> expect Linux installations self recoverable,
--> expects software suspend an important feature,
--> expects lower hardware requirements.

Rahul, Chris, Greg ?

Thanks & Cheers,
Kevin



From buildsys at redhat.com  Sun Mar 19 08:23:47 2006
From: buildsys at redhat.com (Build System)
Date: Sun, 19 Mar 2006 03:23:47 -0500
Subject: rawhide report: 20060319 changes
Message-ID: <200603190823.k2J8NkZ4010492@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5








From sundaram at fedoraproject.org  Sun Mar 19 09:37:11 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 19 Mar 2006 15:07:11 +0530
Subject: Re-view FC5 hardware requirements for GNOME
In-Reply-To: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>
References: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>
Message-ID: <441D2647.3090202@fedoraproject.org>

Kevin Verma wrote:

>Hello,
>
>Quoting on the subject, I had gone through a review article for Gnome
>2.14 and I began wondering if FC5 release notes should mention a
>reviewed hardware requirement for GNOME 2.14 based desktop
>installations, as per the facts delivered in this review article (
>http://www.linux.com/article.pl?sid=06/03/17/0350228 ).
>
>"Still, even allowing for my unscientific timing, the increase in
>speed is impressive. It should be especially welcome on older,
>RAM-challenged machines."
>
>For some reasons I am not using rawhide as of now, so some one else
>would be in a better position to suggest and test further, Rahul ?
>  
>
The requirements specified in the release notes can be still considered 
reasonable. I have been running it with reasonable performance on lower 
end systems though.

>I will also like to mention couple of facts that member developers of
>FC team from developed countries could learn during Linux Asia 06,
>(since those are not qouted much anywhere else) that in developing
>nations, power disruptions affected and low on resources machines ....
>--> expect Linux installations self recoverable,
>  
>
Should happen at some point. check out rescue mode automation at  
http://fedoraproject.org/wiki/AnacondaWorkItems.

>--> expects software suspend an important feature,
>  
>
There has been some integration work done earlier. It should work on 
many systems for Fedora Core 5. If it doesnt, kindly file bug reports 
with the hardware details.

>--> expects lower hardware requirements.
>  
>
The work that has been happening on the OLPC front - 
http://fedoraproject.org/wiki/OLPC should help clean up dependencies and 
yield some performance benefits for low end systems.

>Rahul, Chris, Greg ?
>
>Thanks & Cheers,
>Kevin
>
>  
>

-- 
Rahul 





From pertusus at free.fr  Sun Mar 19 09:49:23 2006
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 19 Mar 2006 10:49:23 +0100
Subject: Re-view FC5 hardware requirements for GNOME
In-Reply-To: <441D2647.3090202@fedoraproject.org>
References: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>
	<441D2647.3090202@fedoraproject.org>
Message-ID: <20060319094923.GA2308@free.fr>

> The work that has been happening on the OLPC front - 
> http://fedoraproject.org/wiki/OLPC should help clean up dependencies and 
> yield some performance benefits for low end systems.

Going off-topic, but I think that the olpc related softs should be in 
extras...

--
Pat



From sundaram at fedoraproject.org  Sun Mar 19 10:18:01 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 19 Mar 2006 15:48:01 +0530
Subject: Re-view FC5 hardware requirements for GNOME
In-Reply-To: <20060319094923.GA2308@free.fr>
References: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>	<441D2647.3090202@fedoraproject.org>
	<20060319094923.GA2308@free.fr>
Message-ID: <441D2FD9.6020305@fedoraproject.org>

Patrice Dumas wrote:

>>The work that has been happening on the OLPC front - 
>>http://fedoraproject.org/wiki/OLPC should help clean up dependencies and 
>>yield some performance benefits for low end systems.
>>    
>>
>
>Going off-topic, but I think that the olpc related softs should be in 
>extras...
>
>  
>
Most of the base operating system modifications would just be integrated 
into rawhide itself. For the rest, there is a plan to setup a repository 
for OLPC already. The above wiki page has several details, for 
participating and keep track of the discussions.


-- 
Rahul 





From bela.pesics at gmail.com  Sun Mar 19 14:05:46 2006
From: bela.pesics at gmail.com (Bela Pesics)
Date: Sun, 19 Mar 2006 15:05:46 +0100
Subject: Re-view FC5 hardware requirements for GNOME
In-Reply-To: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>
References: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>
Message-ID: <f67c87220603190605k2f095f8kbb3e3cc320b22bcd@mail.gmail.com>

On 3/18/06, Kevin Verma <kevinverma at gmail.com> wrote:

> I will also like to mention couple of facts that member developers of
> FC team from developed countries could learn during Linux Asia 06,
> (since those are not qouted much anywhere else) that in developing
> nations, power disruptions affected and low on resources machines ....
> --> expect Linux installations self recoverable,
> --> expects software suspend an important feature,
> --> expects lower hardware requirements.

<remark>

I am not sure that using the terms developed and developing countries
in the context of Fedora is very healthy even if the mentioned
requirements are valid. Those are just requirements of _people_ or
certain interest groups and that is a proper distinction in contrast
with economical, geographical, racial...

Bela



From gilboad at gmail.com  Sun Mar 19 14:59:47 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 19 Mar 2006 16:59:47 +0200
Subject: FC4 packages for vim7 (was: Re: Vim-7 Preview)
In-Reply-To: <1142613359.27041.57.camel@gilboa-home-dev.localhost>
References: <4419531C.3070803@redhat.de> <1142604954.9064.21.camel@ignacio.lan>
	<1142613359.27041.57.camel@gilboa-home-dev.localhost>
Message-ID: <1142780387.1601.6.camel@gilboa-work-dev>

On Fri, 2006-03-17 at 18:36 +0200, Gilboa Davara wrote:
> On Fri, 2006-03-17 at 09:15 -0500, Ignacio Vazquez-Abrams wrote:
> > On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> > > I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
> > > 
> > > Most prominent new features are gvim with windows in multiple tab pages  (:help tabpage),
> > > spell checking (:help spell) and omni-completion (:help new-omni-completion).
> > > 
> > > A description of the new features of vim-7 is available with :help version7
> > > 
> > > Please report any problems in bugzilla and make sure to mention the package version
> > 
> > I've rebuilt the vim7 packages for FC4 and placed them in my repo.
> > They're exactly the same with the exception of the X-based
> > BuildRequires.
> > 
> > http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.i386.rpm
> > http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.i386.rpm
> > http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.i386.rpm
> > http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.i386.rpm
> > http://fedora.ivazquez.net/yum/4/i386/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.i386.rpm
> > http://fedora.ivazquez.net/yum/4/i386/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
> > http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.ppc.rpm
> > http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.ppc.rpm
> > http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.ppc.rpm
> > http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.ppc.rpm
> > http://fedora.ivazquez.net/yum/4/ppc/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.ppc.rpm
> > http://fedora.ivazquez.net/yum/4/ppc/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
> > http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-common-7.0aa.000-0.iva.1.x86_64.rpm
> > http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-debuginfo-7.0aa.000-0.iva.1.x86_64.rpm
> > http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-enhanced-7.0aa.000-0.iva.1.x86_64.rpm
> > http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-minimal-7.0aa.000-0.iva.1.x86_64.rpm
> > http://fedora.ivazquez.net/yum/4/x86_64/RPMS.ivazquez/vim7-X11-7.0aa.000-0.iva.1.x86_64.rpm
> > http://fedora.ivazquez.net/yum/4/x86_64/SRPMS.ivazquez/vim7-7.0aa.000-0.iva.1.src.rpm
> > 
> > -- 
> 
> Thanks.
> Save me a x86_64 build.
> 
> Gilboa

FYI.
 
Seem to be working just fine here. i386 & x86_64.

Thanks again,
Gilboa



From wrrhdev at riede.org  Sun Mar 19 16:10:00 2006
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 19 Mar 2006 11:10:00 -0500
Subject: Vim-7 Preview
In-Reply-To: <44199255.7020106@redhat.de> (from karsten@redhat.de on Thu Mar
	16 11:29:09 2006)
References: <4419531C.3070803@redhat.de>
	<1142512145.14319.23.camel@gilboa-work-dev>
	<44199255.7020106@redhat.de>
Message-ID: <1142784600l.12118l.2l@athena.riede.org>

On 03/16/2006 11:29:09 AM, Karsten Hopp wrote:
> Gilboa Davara wrote:
> > On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote:
> >> Hello,
> >>
> >> I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
> >>
> > Can the .spec be modified to co-exist with 6?
> > E.g. /usr/bin/vim7XXX?
> > 
> > Gilboa
> 
> Done in vim7-7.0aa.000-2, available from the same place.

Built a x86_64 from that - works fine AFAICT.

Thanks, willem Riede.



From zaitcev at redhat.com  Sun Mar 19 19:00:37 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 19 Mar 2006 11:00:37 -0800
Subject: Unable to boot a Xen guest kernel
Message-ID: <20060319110037.39ba7bbf.zaitcev@redhat.com>

For some reason, I cannot boot a Xen guest kernel which I built.
"xm create" ends with:
Error: Error creating domain: (22, 'Invalid argument')

I downloaded a Rawhide kernel rpm (2.6.15-1.2054_FC5), ran rpmbuild -bp,
then took rpms/BUILD/kernel-2.6.15/linux-2.6.15, copied
configs/kernel-2.6.15-i686-xenU-PAE.config, built the kernel
with "make oldconfig && make". The result, apparently, is the
vmlinuz in the root directory.

Does anyone have an idea what I am missing here?

-- Pete



From avi at argo.co.il  Sun Mar 19 20:42:14 2006
From: avi at argo.co.il (Avi Kivity)
Date: Sun, 19 Mar 2006 22:42:14 +0200
Subject: Unable to boot a Xen guest kernel
In-Reply-To: <20060319110037.39ba7bbf.zaitcev@redhat.com>
References: <20060319110037.39ba7bbf.zaitcev@redhat.com>
Message-ID: <441DC226.8070100@argo.co.il>

Pete Zaitcev wrote:

>For some reason, I cannot boot a Xen guest kernel which I built.
>"xm create" ends with:
>Error: Error creating domain: (22, 'Invalid argument')
>
>I downloaded a Rawhide kernel rpm (2.6.15-1.2054_FC5), ran rpmbuild -bp,
>then took rpms/BUILD/kernel-2.6.15/linux-2.6.15, copied
>configs/kernel-2.6.15-i686-xenU-PAE.config, built the kernel
>with "make oldconfig && make". The result, apparently, is the
>vmlinuz in the root directory.
>
>  
>
Anything in /var/log/xend.log?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From katzj at redhat.com  Sun Mar 19 21:08:59 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 19 Mar 2006 16:08:59 -0500
Subject: Unable to boot a Xen guest kernel
In-Reply-To: <20060319110037.39ba7bbf.zaitcev@redhat.com>
References: <20060319110037.39ba7bbf.zaitcev@redhat.com>
Message-ID: <1142802539.2737.37.camel@aglarond.local>

On Sun, 2006-03-19 at 11:00 -0800, Pete Zaitcev wrote:
> For some reason, I cannot boot a Xen guest kernel which I built.
> "xm create" ends with:
> Error: Error creating domain: (22, 'Invalid argument')
> 
> I downloaded a Rawhide kernel rpm (2.6.15-1.2054_FC5), ran rpmbuild -bp,
> then took rpms/BUILD/kernel-2.6.15/linux-2.6.15, copied
> configs/kernel-2.6.15-i686-xenU-PAE.config, built the kernel
> with "make oldconfig && make". The result, apparently, is the
> vmlinuz in the root directory.
> 
> Does anyone have an idea what I am missing here?

You have to be using a PAE hypervisor if you're using a PAE kernel.

Yes, this sucks.

Jeremy



From zaitcev at redhat.com  Sun Mar 19 21:24:57 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 19 Mar 2006 13:24:57 -0800
Subject: Unable to boot a Xen guest kernel
In-Reply-To: <441DC226.8070100@argo.co.il>
References: <20060319110037.39ba7bbf.zaitcev@redhat.com>
	<441DC226.8070100@argo.co.il>
Message-ID: <20060319132457.14ab6ea5.zaitcev@redhat.com>

On Sun, 19 Mar 2006 22:42:14 +0200, Avi Kivity <avi at argo.co.il> wrote:

> >For some reason, I cannot boot a Xen guest kernel which I built.
> >"xm create" ends with:
> >Error: Error creating domain: (22, 'Invalid argument')

> Anything in /var/log/xend.log?

[2006-03-19 11:04:43 xend.XendDomainInfo] ERROR (XendDomainInfo:189) Domain construction failed

But I think I figured what it was. I was running a regular FC-5 Xen and
for some reason it does not like PAE on the guest. If I remove the PAE,
the guest boots (and crashes later, but at least there's no cryptic
"Invalid argument").

-- Pete



From buildsys at redhat.com  Mon Mar 20 08:04:23 2006
From: buildsys at redhat.com (Build System)
Date: Mon, 20 Mar 2006 03:04:23 -0500
Subject: rawhide report: 20060320 changes
Message-ID: <200603200804.k2K84NBT001931@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5








From che666 at gmail.com  Mon Mar 20 09:27:47 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 20 Mar 2006 10:27:47 +0100
Subject: speed up Firefox start by a factor of 3 on x86
In-Reply-To: <1142612623.3033.119.camel@laptopd505.fenrus.org>
References: <561c252c0603162338g4dc56dc4md55e7bd2d05c6a3b@mail.gmail.com>
	<1142612623.3033.119.camel@laptopd505.fenrus.org>
Message-ID: <e99d27470603200127l657f9328m@mail.gmail.com>

2006/3/17, Arjan van de Ven <arjan at fenrus.demon.nl>:
> On Fri, 2006-03-17 at 08:38 +0100, Gianluca Cecchi wrote:
> > On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote:
> > >In contrast, Firefox always starts in 5 seconds or less on a kernel
> > which places
> > >the vDSO intelligently:
> > I read the long list of your reports at the bugzilla page, with the
> > many details and test cases provided, but apart the beginning, you
> > pratically received no feedback at all (at least inside bugzilla
> > itself): only periodically that "having merged with upstream kernel,
> > more than thousands of changes, so please test again and let know..."
> > I think you had better to submit your considerations to upstream kernel list.
> > In this way if accepted, they would be naturally incorporated also in fedora.
> > I'm not a kernel expert so sorry if this doesn't fit for you.
> > Juest my 0.02 euros...
> >
>
> that's not going to fly since this is a fix to a fedora specific
> patch ;)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

more comments on the fix would be nice. will it be merged?

regards,
rudolf kastl



From mjc at redhat.com  Mon Mar 20 09:52:59 2006
From: mjc at redhat.com (Mark J Cox)
Date: Mon, 20 Mar 2006 09:52:59 +0000 (GMT)
Subject: Summary of FC5 vulnerabilities
Message-ID: <0603200943010.13667@dell1.moose.awe.com>

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

Quick Summary:

For 20030101-20060320 there are a potential 1361 CVE named vulnerabilities 
that could have affected FC5 packages.  90% of those are fixed because FC5 
includes an upstream version that includes a fix, 1% are still 
outstanding, and 9% are fixed with a backported patch.  Many of the 
outstanding and backported entries are for issues still not dealt with 
upstream.

For comparison FC4 had 88% by version, 1% outstanding, 11% backported.

Method:

Near the release time of each new distribution the Red Hat security
team go through the packages to ensure that everything is up to date
with security patches.  Full details of the method can be found
http://people.redhat.com/mjc/20050505-fc4

A full table of CVE name, the reason why FC5 isn't vulnerable and optional 
comments showing the package name, version it was fixed in, or method used
to verify the details is available:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/audit/fc5?root=fedora

This file will be kept up to date through the life of FC5 to track 
publically known vulnerabilities and how they affect FC5.

Corrections, comments to secalert at redhat.com.

Thanks, Mark
- -- 
Mark J Cox / Red Hat Security Response Team


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iQCVAwUBRB57f+6tTP1JpWPZAQIRAgQApmCQEUeH4vbMBJABLsFPXmyvkhlbfN+X
mRMcFOHjIc/bekCGb864f64rDxbs+piLE7uXZak4zio7xAKRdWT5z28X2TgprcS8
VT+XBIzix0+vGni8JzDKpEZEq6FTE6zPG22gDfxGAwt9K0qxHGxb1JkY/Syh7wjI
V7vi8XFlaag=
=dnuD
-----END PGP SIGNATURE-----



From mbneto at gmail.com  Mon Mar 20 15:58:32 2006
From: mbneto at gmail.com (mbneto)
Date: Mon, 20 Mar 2006 11:58:32 -0400
Subject: Where is it?
Message-ID: <5cf776b80603200758h6743493bq7d43e67ff5ed218b@mail.gmail.com>

Any torrent around?



From peter at thecodergeek.com  Mon Mar 20 16:01:24 2006
From: peter at thecodergeek.com (Peter Gordon)
Date: Mon, 20 Mar 2006 08:01:24 -0800 (PST)
Subject: Where is it?
In-Reply-To: <5cf776b80603200758h6743493bq7d43e67ff5ed218b@mail.gmail.com>
References: <5cf776b80603200758h6743493bq7d43e67ff5ed218b@mail.gmail.com>
Message-ID: <57537.127.0.0.1.1142870484.squirrel@www.thecodergeek.com>

mbneto said:
> Any torrent around?


You mean FC5 ("Bordeaux")? You can find that at the Fedora
Project's Torrent page: http://torrent.fedoraproject.org

Hope that helps.
-- 
Peter Gordon (codergeek42)
This message was sent through a webmail
    interface, and thus not signed.



From davej at redhat.com  Mon Mar 20 16:12:06 2006
From: davej at redhat.com (Dave Jones)
Date: Mon, 20 Mar 2006 11:12:06 -0500
Subject: speed up Firefox start by a factor of 3 on x86
In-Reply-To: <e99d27470603200127l657f9328m@mail.gmail.com>
References: <561c252c0603162338g4dc56dc4md55e7bd2d05c6a3b@mail.gmail.com>
	<1142612623.3033.119.camel@laptopd505.fenrus.org>
	<e99d27470603200127l657f9328m@mail.gmail.com>
Message-ID: <20060320161206.GF29589@redhat.com>

On Mon, Mar 20, 2006 at 10:27:47AM +0100, Rudolf Kastl wrote:
 > 2006/3/17, Arjan van de Ven <arjan at fenrus.demon.nl>:
 > > On Fri, 2006-03-17 at 08:38 +0100, Gianluca Cecchi wrote:
 > > > On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote:
 > > > >In contrast, Firefox always starts in 5 seconds or less on a kernel
 > > > which places
 > > > >the vDSO intelligently:
 > > > I read the long list of your reports at the bugzilla page, with the
 > > > many details and test cases provided, but apart the beginning, you
 > > > pratically received no feedback at all (at least inside bugzilla
 > > > itself): only periodically that "having merged with upstream kernel,
 > > > more than thousands of changes, so please test again and let know..."
 > > > I think you had better to submit your considerations to upstream kernel list.
 > > > In this way if accepted, they would be naturally incorporated also in fedora.
 > > > I'm not a kernel expert so sorry if this doesn't fit for you.
 > > > Juest my 0.02 euros...
 > > >
 > >
 > > that's not going to fly since this is a fix to a fedora specific
 > > patch ;)
 > >
 > > --
 > > fedora-devel-list mailing list
 > > fedora-devel-list at redhat.com
 > > https://www.redhat.com/mailman/listinfo/fedora-devel-list
 > >
 > 
 > more comments on the fix would be nice. will it be merged?

I'll throw it into rawhide soon, and if nothing breaks,
then I'll backport it to the other releases.

		Dave

-- 
http://www.codemonkey.org.uk



From katzj at redhat.com  Mon Mar 20 16:59:57 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Mar 2006 11:59:57 -0500
Subject: Wild and crazy times for the development tree
Message-ID: <1142873997.3002.15.camel@aglarond.local>

With the release of Fedora Core 5, the development tree is now open for
things to continue forward.  So if you've been following it purely to
get updates for the FC5 test releases, you'll probably want to grab the
fedora-release package from the FC5 release instead.  If you want to
keep testing and helping to develop things for Fedora Core 6, expect for
some fun to pop up as always.

Jeremy



From fedora at camperquake.de  Mon Mar 20 17:08:53 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 20 Mar 2006 18:08:53 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142873997.3002.15.camel@aglarond.local>
References: <1142873997.3002.15.camel@aglarond.local>
Message-ID: <20060320180853.2939eeac@soran.addix.net>

Hi.

On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:

> to grab the fedora-release package from the FC5 release instead.  If
> you want to keep testing and helping to develop things for Fedora
> Core 6, expect for some fun to pop up as always.

Sooo... what are we going to break first?



From sundaram at fedoraproject.org  Mon Mar 20 17:10:58 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 20 Mar 2006 22:40:58 +0530
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320180853.2939eeac@soran.addix.net>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
Message-ID: <441EE222.7070806@fedoraproject.org>

Ralf Ertzinger wrote:

>Hi.
>
>On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:
>
>  
>
>>to grab the fedora-release package from the FC5 release instead.  If
>>you want to keep testing and helping to develop things for Fedora
>>Core 6, expect for some fun to pop up as always.
>>    
>>
>
>Sooo... what are we going to break first?
>
>  
>
Try and see?

-- 
Rahul 





From pbrobinson at gmail.com  Mon Mar 20 17:11:06 2006
From: pbrobinson at gmail.com (Peter Robinson)
Date: Mon, 20 Mar 2006 17:11:06 +0000
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320180853.2939eeac@soran.addix.net>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
Message-ID: <5256d0b0603200911j2fab3d18h4bdcbaf3d4ebfa1d@mail.gmail.com>

> > to grab the fedora-release package from the FC5 release instead.  If
> > you want to keep testing and helping to develop things for Fedora
> > Core 6, expect for some fun to pop up as always.
>
> Sooo... what are we going to break first?

I'd vote on some X funnies at some stage as the 3D stuff that didn't
make FC5 comes in at some stage.... bring it on!!!

Pete



From arjan at fenrus.demon.nl  Mon Mar 20 17:18:04 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Mon, 20 Mar 2006 18:18:04 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320180853.2939eeac@soran.addix.net>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
Message-ID: <1142875085.3114.62.camel@laptopd505.fenrus.org>

On Mon, 2006-03-20 at 18:08 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:
> 
> > to grab the fedora-release package from the FC5 release instead.  If
> > you want to keep testing and helping to develop things for Fedora
> > Core 6, expect for some fun to pop up as always.
> 
> Sooo... what are we going to break first?
> 

I would love to see the -fstack-protector support for the kernel go in..



From paul at all-the-johnsons.co.uk  Mon Mar 20 17:41:54 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Mon, 20 Mar 2006 17:41:54 +0000
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320180853.2939eeac@soran.addix.net>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
Message-ID: <1142876514.2786.36.camel@mrwibble.mrwobble>

Hi,

> > to grab the fedora-release package from the FC5 release instead.  If
> > you want to keep testing and helping to develop things for Fedora
> > Core 6, expect for some fun to pop up as always.
> 
> Sooo... what are we going to break first?

X is always guaranteed to raise a laugh ;-p

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From rstrode at redhat.com  Mon Mar 20 17:44:47 2006
From: rstrode at redhat.com (Ray Strode)
Date: Mon, 20 Mar 2006 12:44:47 -0500
Subject: gnome 2.14 test updates
Message-ID: <1142876688.2403.5.camel@halflap>

Hi,

A number of gnome 2.14 packages didn't quite make the FC5 cut.  These
packages have been pushed into -updates-testing, now.  For those
interested in helping, please give the new packages a test run and
report any problems you find with them.

If all goes well we should be able to push the updates that don't cause
regressions into -updates in a few days.

Thanks,
Ray



From dimi at lattica.com  Mon Mar 20 17:47:42 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 12:47:42 -0500
Subject: firefox packaging bug
Message-ID: <09fa01c64c46$6602f790$b6491b31@td612671>

Hi folks,

This may have already been fixed, but I figured I should note it
anyhow. It seems the RPM for
    firefox-1.0.6-1.2.fc4.i386
gets rid of the file
    /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl
before it is invoked in the %postun script:

[root at dimi ~]# rpm -e firefox-1.0.6-1.2.fc4
/var/tmp/rpm-tmp.83719: line 5:
/usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl: No such file or
directory
error: %postun(firefox-1.0.6-1.2.fc4.i386) scriptlet failed, exit status 127

Of course, if you recreate it for fun:

[root at dimi ~]# mkdir /usr/lib/firefox-1.0.6
[root at dimi ~]# vim /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl
[root at dimi ~]# touch /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl
[root at dimi ~]# chmod +x /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl

The same thing will happen:

[root at dimi ~]# rpm -e firefox-1.0.6-1.2.fc4
/var/tmp/rpm-tmp.18065: line 5:
/usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl: No such file or
directory
error: %postun(firefox-1.0.6-1.2.fc4.i386) scriptlet failed, exit status 127

Sure enogh the file (and dir) is gone again:

[root at dimi ~]# ll /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl
ls: /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl: No such file or
directory

Only this gets rid of the package:

[root at dimi ~]# rpm -e --noscripts firefox-1.0.6-1.2.fc4

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From wtogami at redhat.com  Mon Mar 20 18:22:29 2006
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 20 Mar 2006 13:22:29 -0500
Subject: firefox packaging bug
In-Reply-To: <09fa01c64c46$6602f790$b6491b31@td612671>
References: <09fa01c64c46$6602f790$b6491b31@td612671>
Message-ID: <441EF2E5.9060800@redhat.com>

Dimi Paun wrote:
> Hi folks,
> 
> This may have already been fixed, but I figured I should note it
> anyhow. It seems the RPM for
>     firefox-1.0.6-1.2.fc4.i386
> gets rid of the file
>     /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl
> before it is invoked in the %postun script:

This is not a firefox bug.  firefox-1.5.x no longer needs 
firefox-rebuild-databases.pl.  I'm guessing you probably have an old 
version of flash-plugin installed.

http://macromedia.mplug.org/
You may want to download a newer version because some security holes 
have been fixed since then.  The newer flash-plugin package also 
properly handles firefox-1.5.x.

Warren Togami
wtogami at redhat.com



From rhally at mindspring.com  Mon Mar 20 18:00:19 2006
From: rhally at mindspring.com (Richard Hally)
Date: Mon, 20 Mar 2006 13:00:19 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142875085.3114.62.camel@laptopd505.fenrus.org>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
Message-ID: <441EEDB3.3030008@mindspring.com>

Arjan van de Ven wrote:
> On Mon, 2006-03-20 at 18:08 +0100, Ralf Ertzinger wrote:
>> Hi.
>>
>> On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:
>>
>>> to grab the fedora-release package from the FC5 release instead.  If
>>> you want to keep testing and helping to develop things for Fedora
>>> Core 6, expect for some fun to pop up as always.
>> Sooo... what are we going to break first?
>>
> 
> I would love to see the -fstack-protector support for the kernel go in..
> 
What does the schedule look like for FC6?
I would like to see a 5 month schedule:
March 20 - April 20 == development
then
3 weeks;
freeze for test1 May 12;
test1 out around May 19;
3 weeks;
freeze for test2 June 9;
test 2 out around June 16;
3 weeks;
freeze for test3 July 7;
test3 out around July 14;
4 weeks (bug fixes only);
freeze for final around Aug 11;
FC6 around Aug 20!

With a schedule like this, when there is the inevitable slippage we will 
still be around 6 months between releases.



From arjan at fenrus.demon.nl  Mon Mar 20 18:45:11 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Mon, 20 Mar 2006 19:45:11 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <441EEDB3.3030008@mindspring.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
Message-ID: <1142880311.3114.77.camel@laptopd505.fenrus.org>

On Mon, 2006-03-20 at 13:00 -0500, Richard Hally wrote:
> Arjan van de Ven wrote:
> > On Mon, 2006-03-20 at 18:08 +0100, Ralf Ertzinger wrote:
> >> Hi.
> >>
> >> On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:
> >>
> >>> to grab the fedora-release package from the FC5 release instead.  If
> >>> you want to keep testing and helping to develop things for Fedora
> >>> Core 6, expect for some fun to pop up as always.
> >> Sooo... what are we going to break first?
> >>
> > 
> > I would love to see the -fstack-protector support for the kernel go in..
> > 
> What does the schedule look like for FC6?
> I would like to see a 5 month schedule:

personally I think the current 9 month schedule wasn't too bad (ok the
end slipped too much but lets ignore that bit); it gives enough time to
do fundamental improvements. For fc6 it would be nice if boot speed was
further improved for example, and since initscripts are tricky and need
lots of testing... a bit of extra time would be neat



From dimi at lattica.com  Mon Mar 20 19:09:32 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 14:09:32 -0500
Subject: firefox packaging bug
References: <09fa01c64c46$6602f790$b6491b31@td612671>
	<441EF2E5.9060800@redhat.com>
Message-ID: <0a3201c64c51$d8e228c0$b6491b31@td612671>

From: "Warren Togami" <wtogami at redhat.com>
> Dimi Paun wrote:
> > This may have already been fixed, but I figured I should note it
> > anyhow. It seems the RPM for
> >     firefox-1.0.6-1.2.fc4.i386
> > gets rid of the file
> >     /usr/lib/firefox-1.0.6/firefox-rebuild-databases.pl
> > before it is invoked in the %postun script:
> 
> This is not a firefox bug.  firefox-1.5.x no longer needs 
> firefox-rebuild-databases.pl.  I'm guessing you probably have an old 
> version of flash-plugin installed.

I don't think I do:
[root at dimi ~]# rpm -qa | grep flash | wc -l
0

Regardless, the script is in the 1.0.6 directory, what does it has
to do with 1.5? It is the 1.0.6 rpm that fails to uninstall cleanly.
Something must be off, I hope this is not normal behaviour :)
 
-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From jeff at ocjtech.us  Mon Mar 20 19:17:26 2006
From: jeff at ocjtech.us (Jeffrey C. Ollie)
Date: Mon, 20 Mar 2006 13:17:26 -0600
Subject: gnome 2.14 test updates
In-Reply-To: <1142876688.2403.5.camel@halflap>
References: <1142876688.2403.5.camel@halflap>
Message-ID: <1142882246.2635.21.camel@lt16585.campus.dmacc.edu>

On Mon, 2006-03-20 at 12:44 -0500, Ray Strode wrote:
> 
> A number of gnome 2.14 packages didn't quite make the FC5 cut.  These
> packages have been pushed into -updates-testing, now.  For those
> interested in helping, please give the new packages a test run and
> report any problems you find with them.
> 
> If all goes well we should be able to push the updates that don't cause
> regressions into -updates in a few days.

Have these packages been pushed to development as well?

Jeff

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

From dimi at lattica.com  Mon Mar 20 19:18:38 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 14:18:38 -0500
Subject: java-1.4.2-gcj-compat package problem
Message-ID: <0a4a01c64c53$1e5596c0$b6491b31@td612671>

This package is giving me grief as well:

[root at dimi ~]# rpm -e java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1.i386
/var/tmp/rpm-tmp.84077: line 8: /usr/bin/rebuild-security-providers: No such
file or directory
error: %postun(java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1.i386)
scriptlet failed, exit status 127

I don't know where this
    /usr/bin/rebuild-security-providers
script is comming from:

[root at dimi ~]# rpm -qf /usr/bin/rebuild-security-providers
file /usr/bin/rebuild-security-providers is not owned by any package


Something is off here. Should I just pass --noscripts to rpm
and be done with it? I was hoping I could help flush out some
packaging bugs, if there are any...

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From rstrode at redhat.com  Mon Mar 20 19:31:03 2006
From: rstrode at redhat.com (Ray Strode)
Date: Mon, 20 Mar 2006 14:31:03 -0500
Subject: gnome 2.14 test updates
In-Reply-To: <1142882246.2635.21.camel@lt16585.campus.dmacc.edu>
References: <1142876688.2403.5.camel@halflap>
	<1142882246.2635.21.camel@lt16585.campus.dmacc.edu>
Message-ID: <1142883063.2403.7.camel@halflap>

Hi,

On Mon, 2006-03-20 at 13:17 -0600, Jeffrey C. Ollie wrote:
> On Mon, 2006-03-20 at 12:44 -0500, Ray Strode wrote:
> > 
> > A number of gnome 2.14 packages didn't quite make the FC5 cut.  These
> > packages have been pushed into -updates-testing, now.  For those
> > interested in helping, please give the new packages a test run and
> > report any problems you find with them.
> > 
> > If all goes well we should be able to push the updates that don't cause
> > regressions into -updates in a few days.
> 
> Have these packages been pushed to development as well?
Not yet.  Although it will happen soon.

--Ray



From zaitcev at redhat.com  Mon Mar 20 20:26:05 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Mon, 20 Mar 2006 12:26:05 -0800
Subject: Unable to boot a Xen guest kernel
In-Reply-To: <441DC226.8070100@argo.co.il>
References: <20060319110037.39ba7bbf.zaitcev@redhat.com>
	<441DC226.8070100@argo.co.il>
Message-ID: <20060320122605.2f76f691.zaitcev@redhat.com>

To follow up, I wasted Avi's time.

The "Error (22, Invalid argument)" was caused by an attempt to boot a PAE
enabled guest. Without PAE, xend loads and runs the domain, which promptly
crashes.

So I downloaded the actual Beehive-built binary for 2.6.15-1.2054_FC5xenU
and it doesn't boot either. The guest crashes in cpu_gdt_init, same place
where my own build does. It simply is a duff kernel and there was nothing
wrong with my build procedure. The last working kernel that I know is
2.6.15-1.1955_FC5guest. I'm going to bisect this and find out the problem,
or file a bug for DaveJ to look.

Greetings,
-- Pete



From zaitcev at redhat.com  Mon Mar 20 20:29:55 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Mon, 20 Mar 2006 12:29:55 -0800
Subject: Unable to boot a Xen guest kernel
In-Reply-To: <1142802539.2737.37.camel@aglarond.local>
References: <20060319110037.39ba7bbf.zaitcev@redhat.com>
	<1142802539.2737.37.camel@aglarond.local>
Message-ID: <20060320122955.02abcf14.zaitcev@redhat.com>

On Sun, 19 Mar 2006 16:08:59 -0500, Jeremy Katz <katzj at redhat.com> wrote:

> You have to be using a PAE hypervisor if you're using a PAE kernel.

Thanks, Jeremy. Do you happen to know if I can run a 32-bit guest (both
PAE and not) on a 64-bit host?

-- Pete



From david at lovesunix.net  Mon Mar 20 20:40:10 2006
From: david at lovesunix.net (David Nielsen)
Date: Mon, 20 Mar 2006 21:40:10 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142880311.3114.77.camel@laptopd505.fenrus.org>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
Message-ID: <1142887210.23128.18.camel@price.stavtrup-st.dk>

man, 20 03 2006 kl. 19:45 +0100, skrev Arjan van de Ven:

> personally I think the current 9 month schedule wasn't too bad (ok the
> end slipped too much but lets ignore that bit); it gives enough time to
> do fundamental improvements. For fc6 it would be nice if boot speed was
> further improved for example, and since initscripts are tricky and need
> lots of testing... a bit of extra time would be neat

I tend to agree, the 9 month cycle worked wonderfully, Fedora Core 5 is
by far the best release the Fedora Project has put out yet and as a
tester I enjoyed having that extra time to see new fundamental changes
take place and get bugs tracked down.

If the new init system can be delivered this cycle I would love to see
it, I don't see 9 month cycles being a price to pay, more likely it's a
benefit for most everybody (opinion taken from the most reliable source
in the world.. my backside).

But let's get a clear roadmap down this time, what features are
essential for the next cycle?

- David



From katzj at redhat.com  Mon Mar 20 20:41:15 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Mar 2006 15:41:15 -0500
Subject: Unable to boot a Xen guest kernel
In-Reply-To: <20060320122955.02abcf14.zaitcev@redhat.com>
References: <20060319110037.39ba7bbf.zaitcev@redhat.com>
	<1142802539.2737.37.camel@aglarond.local>
	<20060320122955.02abcf14.zaitcev@redhat.com>
Message-ID: <1142887275.3002.24.camel@aglarond.local>

On Mon, 2006-03-20 at 12:29 -0800, Pete Zaitcev wrote:
> On Sun, 19 Mar 2006 16:08:59 -0500, Jeremy Katz <katzj at redhat.com> wrote:
> > You have to be using a PAE hypervisor if you're using a PAE kernel.
> 
> Thanks, Jeremy. Do you happen to know if I can run a 32-bit guest (both
> PAE and not) on a 64-bit host?

Not right now (for paravirt guests)

Jeremy



From katzj at redhat.com  Mon Mar 20 21:14:47 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Mar 2006 16:14:47 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142887210.23128.18.camel@price.stavtrup-st.dk>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
Message-ID: <1142889287.3002.42.camel@aglarond.local>

On Mon, 2006-03-20 at 21:40 +0100, David Nielsen wrote:
> man, 20 03 2006 kl. 19:45 +0100, skrev Arjan van de Ven:
> > personally I think the current 9 month schedule wasn't too bad (ok the
> > end slipped too much but lets ignore that bit); it gives enough time to
> > do fundamental improvements. For fc6 it would be nice if boot speed was
> > further improved for example, and since initscripts are tricky and need
> > lots of testing... a bit of extra time would be neat
> 
> I tend to agree, the 9 month cycle worked wonderfully, Fedora Core 5 is
> by far the best release the Fedora Project has put out yet and as a
> tester I enjoyed having that extra time to see new fundamental changes
> take place and get bugs tracked down.

Realistically, I don't think the 9 month cycle really helped that much
except for one very specific case of the underlying installer changes.
And realistically, if it had been a six month cycle instead, those would
have been worked out then as well.  For everything else, if we had been
on a six month cycle, some of them would have made FC5 and some would
have made FC6.  But guess what, that's going to be true no matter _when_
you actually cut a release.  It's the price of doing releases more than
once every three years :-)

Jeremy



From paul at all-the-johnsons.co.uk  Mon Mar 20 21:15:03 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Mon, 20 Mar 2006 21:15:03 +0000
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142887210.23128.18.camel@price.stavtrup-st.dk>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
Message-ID: <1142889303.3604.10.camel@T7.Linux>

Hi,

> But let's get a clear roadmap down this time, what features are
> essential for the next cycle?

A *much* reduced core size (5 CDs + rescue is getting a bit much) and
large reduction in the overall memory overhead. I know FC is fantastic,
but given you need 128Mb for a text only version and 512Mb for a desktop
environment, it's becoming hard to justify to the powers that be that
using Linux over WinXP is that good an option.

Slack 10 can run (text only) in 18Mb with a desktop environment in 64Mb
- Debian (sorry for swearing on this list) is a whole lot smaller than
FC in terms of memory again.

I think it was suggested that ISOs are made of FE. It may be time to do
this, but with quite a lot from FC moved to it. For example, gcc-gnat,
gfortran, objc and anything *not* mono/mcs (in other words, beagle,
fspot etc) should, IMHO, be in extras - and yes, I do use gfortran and
gnat. The OOo language packs should also be moved out - just keep in
french, german, spanish and any big userbases.

The same applies to Qt and KDE - quite a lot of the material in there
should be in extras, Qt (standard + devel) and some of the kde system
should be in Core. We also have a number of different database systems
in Core. Could a case not be made for trimming it down to MySQL and
postgresql with the rest again going to FE?

9 months is a long time for a release. Perhaps an interim release at the
5 month stage would be an advantage.

Obviously, these are just ideas *but* they do answer a growing number of
criticisms of FC.

TTFN

Paul
-- 
"ein zu starker starker Anblick kann Sie toten. Sie gegen gerade uber
den Rand mit dem festen Wissen des Wege vor Ihnen" - Linus Tordvals



From aph at redhat.com  Mon Mar 20 21:24:34 2006
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Mar 2006 21:24:34 +0000
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
Message-ID: <17439.7570.458154.295107@zapata.pink>

Dimi Paun writes:
 > This package is giving me grief as well:
 > 
 > [root at dimi ~]# rpm -e java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1.i386
 > /var/tmp/rpm-tmp.84077: line 8: /usr/bin/rebuild-security-providers: No such
 > file or directory
 > error: %postun(java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1.i386)
 > scriptlet failed, exit status 127
 > 
 > I don't know where this
 >     /usr/bin/rebuild-security-providers
 > script is comming from:
 > 
 > [root at dimi ~]# rpm -qf /usr/bin/rebuild-security-providers
 > file /usr/bin/rebuild-security-providers is not owned by any package

It's in jpackage-utils.

Andrew.



From dimi at lattica.com  Mon Mar 20 21:26:24 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 16:26:24 -0500
Subject: java-1.4.2-gcj-compat package problem
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
Message-ID: <0af601c64c64$f5cab160$b6491b31@td612671>

From: "Andrew Haley" <aph at redhat.com>
>  > [root at dimi ~]# rpm -qf /usr/bin/rebuild-security-providers
>  > file /usr/bin/rebuild-security-providers is not owned by any package
>
> It's in jpackage-utils.

Not here:

[root at dimi ~]# rpm -q jpackage-utils
jpackage-utils-1.6.6-1jpp
[root at dimi ~]# rpm -ql jpackage-utils | grep rebuild-security-providers |
wc -l
0

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mattdm at mattdm.org  Mon Mar 20 21:28:56 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 20 Mar 2006 16:28:56 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142887210.23128.18.camel@price.stavtrup-st.dk>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
Message-ID: <20060320212856.GA10685@jadzia.bu.edu>

On Mon, Mar 20, 2006 at 09:40:10PM +0100, David Nielsen wrote:
> I tend to agree, the 9 month cycle worked wonderfully, Fedora Core 5 is
> by far the best release the Fedora Project has put out yet and as a
> tester I enjoyed having that extra time to see new fundamental changes
> take place and get bugs tracked down.

I was intrigued by your blog suggestion of alternating 9 month devel / 4
month stabilization cycles. <tp://lovesunix.net/blog/?p=62> But I also think
your own objection (people will not take the 9-month release seriously
enough) is pretty strong.

As someone crazy enough to try to use Fedora for real work, the 9 month
cycle is awesome.


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



From katzj at redhat.com  Mon Mar 20 21:32:19 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 20 Mar 2006 16:32:19 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142889303.3604.10.camel@T7.Linux>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
Message-ID: <1142890339.3002.53.camel@aglarond.local>

On Mon, 2006-03-20 at 21:15 +0000, Paul F. Johnson wrote:
> > But let's get a clear roadmap down this time, what features are
> > essential for the next cycle?
> 
> A *much* reduced core size (5 CDs + rescue is getting a bit much) and
> large reduction in the overall memory overhead. I know FC is fantastic,
> but given you need 128Mb for a text only version and 512Mb for a desktop
> environment, it's becoming hard to justify to the powers that be that
> using Linux over WinXP is that good an option.

We're actually probably significantly better than FC4 on memory overhead
for the most part.  Installation is a little higher overhead this time
around and most of the reason for bumping the recommendation.  

> Slack 10 can run (text only) in 18Mb with a desktop environment in 64Mb
> - Debian (sorry for swearing on this list) is a whole lot smaller than
> FC in terms of memory again.

It all depends on what you're defining as your desktop environment.  We
could do fvwm instead, but I really don't think that's what most people
want.

> I think it was suggested that ISOs are made of FE. It may be time to do
> this, but with quite a lot from FC moved to it. For example, gcc-gnat,
> gfortran, objc and anything *not* mono/mcs (in other words, beagle,
> fspot etc) should, IMHO, be in extras - and yes, I do use gfortran and
> gnat. The OOo language packs should also be moved out - just keep in
> french, german, spanish and any big userbases.

The problem is that a lot of this is split over src.rpms that *must* be
in Core.  And right now, there's no way to do that split.  Given where
some things stand, I think that we can start thinking about tools to
make it easier for building CD sets and shadow repositories in the FC6
timeframe and then start really rethinking a release after that.

> The same applies to Qt and KDE - quite a lot of the material in there
> should be in extras, Qt (standard + devel) and some of the kde system
> should be in Core. We also have a number of different database systems
> in Core. Could a case not be made for trimming it down to MySQL and
> postgresql with the rest again going to FE?

We don't really ship any substantial (ie, non-embedded) databases other
than mysql and postgresql that I know of.  And changing the embedded
database for a piece of software isn't a trivial thing.

Jeremy



From dwmw2 at infradead.org  Mon Mar 20 21:42:12 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 20 Mar 2006 21:42:12 +0000
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142890339.3002.53.camel@aglarond.local>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142890339.3002.53.camel@aglarond.local>
Message-ID: <1142890933.17167.142.camel@localhost.localdomain>

On Mon, 2006-03-20 at 16:32 -0500, Jeremy Katz wrote:
> The problem is that a lot of this is split over src.rpms that *must*
> be in Core.  And right now, there's no way to do that split.

That _really_ isn't a hard problem to solve. To have certain binary
packages built in the Core build system and then wind up in the Extras
repositories really isn't rocket science.

-- 
dwmw2



From aph at redhat.com  Mon Mar 20 21:41:35 2006
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Mar 2006 21:41:35 +0000
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0af601c64c64$f5cab160$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
	<0af601c64c64$f5cab160$b6491b31@td612671>
Message-ID: <17439.8591.948815.966657@zapata.pink>

Dimi Paun writes:
 > From: "Andrew Haley" <aph at redhat.com>
 > >  > [root at dimi ~]# rpm -qf /usr/bin/rebuild-security-providers
 > >  > file /usr/bin/rebuild-security-providers is not owned by any package
 > >
 > > It's in jpackage-utils.
 > 
 > Not here:
 > 
 > [root at dimi ~]# rpm -q jpackage-utils
 > jpackage-utils-1.6.6-1jpp
 > [root at dimi ~]# rpm -ql jpackage-utils | grep rebuild-security-providers |
 > wc -l
 > 0

You have a bad version of jpackage-utils; remove it and get one from
`yum install'.  You need version 1jpp_2rh.

Andrew.



From mharris at mharris.ca  Mon Mar 20 21:42:09 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 20 Mar 2006 16:42:09 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320180853.2939eeac@soran.addix.net>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
Message-ID: <441F21B1.5090902@mharris.ca>

Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:
> 
> 
>>to grab the fedora-release package from the FC5 release instead.  If
>>you want to keep testing and helping to develop things for Fedora
>>Core 6, expect for some fun to pop up as always.
> 
> 
> Sooo... what are we going to break first?

All proprietary drivers?  ;o)



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From davej at redhat.com  Mon Mar 20 21:44:05 2006
From: davej at redhat.com (Dave Jones)
Date: Mon, 20 Mar 2006 16:44:05 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F21B1.5090902@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<441F21B1.5090902@mharris.ca>
Message-ID: <20060320214405.GC28360@redhat.com>

On Mon, Mar 20, 2006 at 04:42:09PM -0500, Mike A. Harris wrote:

 > >>to grab the fedora-release package from the FC5 release instead.  If
 > >>you want to keep testing and helping to develop things for Fedora
 > >>Core 6, expect for some fun to pop up as always.
 > >
 > >Sooo... what are we going to break first?
 > 
 > All proprietary drivers?  ;o)

Yawn, been there, done that :-P

		Dave

-- 
http://www.codemonkey.org.uk



From mharris at mharris.ca  Mon Mar 20 21:49:42 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 20 Mar 2006 16:49:42 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <5256d0b0603200911j2fab3d18h4bdcbaf3d4ebfa1d@mail.gmail.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<5256d0b0603200911j2fab3d18h4bdcbaf3d4ebfa1d@mail.gmail.com>
Message-ID: <441F2376.5080905@mharris.ca>

Peter Robinson wrote:
>>>to grab the fedora-release package from the FC5 release instead.  If
>>>you want to keep testing and helping to develop things for Fedora
>>>Core 6, expect for some fun to pop up as always.
>>
>>Sooo... what are we going to break first?
> 
> 
> I'd vote on some X funnies at some stage as the 3D stuff that didn't
> make FC5 comes in at some stage.... bring it on!!!

Hehe.

There has been a fair bit of upstream X.Org stable branch commits
lately for the 2D ati driver, and X server - mostly benh's memory
map fixes and other various Radeon fixes.  There are some known
problems I believe, but once they're straightened out, I think there
is going to be a new upstream "ati" driver release from the stable
branch.

Adam Jackson is also working towards a new stable-branch Xorg server
release.

When each of these become available upstream as tarballed releases,
we'll merge them into rawhide to get the testing process going.  Down
the road once any regressions are worked out, we'll probably pull them
both into FC5-updates also.

R300 DRI support is quite unstable however, and will probably be held
back until it shows signs of greater stability.  When I say this, I
do so knowing that some people who have tried it have found it to be
fairly stable for their own hardware/situation.  My definition of
"stable" is "works stable for majority of people, with little to no
bug reports, and does not cause massive bugzilla influx of bugs when
the driver is provided".

So, R300 dri support will be something you need to compile for yourself
for the time being if desired.  Also, our kernel does not have the
R300+ PCI IDs in it anymore, so you may need to recompile your kernel
as well.  Not sure what davej's specific plans are for that, but I hope
he keeps the R300 PCI IDs out of the kernel at least until the r300
DRI driver is remotely useable large-scale.



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From dimi at lattica.com  Mon Mar 20 21:50:22 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 16:50:22 -0500
Subject: java-1.4.2-gcj-compat package problem
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671><17439.7570.458154.295107@zapata.pink><0af601c64c64$f5cab160$b6491b31@td612671>
	<17439.8591.948815.966657@zapata.pink>
Message-ID: <0b2601c64c68$4ab4caf0$b6491b31@td612671>

From: "Andrew Haley" <aph at redhat.com>
>  > [root at dimi ~]# rpm -q jpackage-utils
>  > jpackage-utils-1.6.6-1jpp
>
> You have a bad version of jpackage-utils; remove it and get one from
> `yum install'.  You need version 1jpp_2rh.

Heh, 1jpp_2rh > 1jpp, yum should update it, no?

But it can't find it anywhere:

[root at dimi ~]# yum update jpackage-utils-1.6.6-1jpp_2rh
Setting up Update Process
Setting up repositories
dries                     100% |=========================|  951 B    00:00
dag                       100% |=========================| 1.1 kB    00:00
jpackage16-fc             100% |=========================|  951 B    00:00
freshrpms                 100% |=========================|  951 B    00:00
katz                      100% |=========================|  951 B    00:00
macromedia                100% |=========================|  951 B    00:00
jpackage16-generic        100% |=========================|  951 B    00:00
extras                    100% |=========================| 1.1 kB    00:00
updates-released          100% |=========================|  951 B    00:00
lattica-development       100% |=========================|  951 B    00:00
base                      100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
primary.xml.gz            100% |=========================| 1.1 kB    00:00
Could not find update match for jpackage-utils-1.6.6-1jpp_2rh
No Packages marked for Update/Obsoletion

Am I missing something?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mharris at mharris.ca  Mon Mar 20 21:50:39 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 20 Mar 2006 16:50:39 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <441EEDB3.3030008@mindspring.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
Message-ID: <441F23AF.4000504@mharris.ca>

Richard Hally wrote:
> Arjan van de Ven wrote:
> 
>> On Mon, 2006-03-20 at 18:08 +0100, Ralf Ertzinger wrote:
>>
>>> Hi.
>>>
>>> On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:
>>>
>>>> to grab the fedora-release package from the FC5 release instead.  If
>>>> you want to keep testing and helping to develop things for Fedora
>>>> Core 6, expect for some fun to pop up as always.
>>>
>>> Sooo... what are we going to break first?
>>>
>>
>> I would love to see the -fstack-protector support for the kernel go in..
>>
> What does the schedule look like for FC6?
> I would like to see a 5 month schedule:
> March 20 - April 20 == development

One month of development?

Hahahahaahahaaaa!!!!!


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From davej at redhat.com  Mon Mar 20 21:57:38 2006
From: davej at redhat.com (Dave Jones)
Date: Mon, 20 Mar 2006 16:57:38 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F2376.5080905@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<5256d0b0603200911j2fab3d18h4bdcbaf3d4ebfa1d@mail.gmail.com>
	<441F2376.5080905@mharris.ca>
Message-ID: <20060320215738.GD28360@redhat.com>

On Mon, Mar 20, 2006 at 04:49:42PM -0500, Mike A. Harris wrote:
 > So, R300 dri support will be something you need to compile for yourself
 > for the time being if desired.  Also, our kernel does not have the
 > R300+ PCI IDs in it anymore, so you may need to recompile your kernel
 > as well.  Not sure what davej's specific plans are for that, but I hope
 > he keeps the R300 PCI IDs out of the kernel at least until the r300
 > DRI driver is remotely useable large-scale.

not that it seems to matter. X seems to be doing a 'modprobe radeon'
when it sees anything ATI.  Chopping the IDs out stops it being
initialised, but it appears that X does _something_ differently
just by having the module loaded even if its not using it.

I can keep them chopped out for the time being, but the downside is
we're not going to get a lot of coverage testing, so how will we know
when its 'good enough' ?

		Dave

-- 
http://www.codemonkey.org.uk



From aph at redhat.com  Mon Mar 20 22:00:51 2006
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Mar 2006 22:00:51 +0000
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0b2601c64c68$4ab4caf0$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
	<0af601c64c64$f5cab160$b6491b31@td612671>
	<17439.8591.948815.966657@zapata.pink>
	<0b2601c64c68$4ab4caf0$b6491b31@td612671>
Message-ID: <17439.9747.977716.606497@zapata.pink>

Dimi Paun writes:
 > From: "Andrew Haley" <aph at redhat.com>
 > >  > [root at dimi ~]# rpm -q jpackage-utils
 > >  > jpackage-utils-1.6.6-1jpp
 > >
 > > You have a bad version of jpackage-utils; remove it and get one from
 > > `yum install'.  You need version 1jpp_2rh.
 > 
 > Heh, 1jpp_2rh > 1jpp, yum should update it, no?

No.

 > But it can't find it anywhere:
 > 
 > [root at dimi ~]# yum update jpackage-utils-1.6.6-1jpp_2rh
 > Setting up Update Process
 > Setting up repositories
 > dries                     100% |=========================|  951 B    00:00
 > dag                       100% |=========================| 1.1 kB    00:00
 > jpackage16-fc             100% |=========================|  951 B    00:00
 > freshrpms                 100% |=========================|  951 B    00:00
 > katz                      100% |=========================|  951 B    00:00
 > macromedia                100% |=========================|  951 B    00:00
 > jpackage16-generic        100% |=========================|  951 B    00:00
 > extras                    100% |=========================| 1.1 kB    00:00
 > updates-released          100% |=========================|  951 B    00:00
 > lattica-development       100% |=========================|  951 B    00:00
 > base                      100% |=========================| 1.1 kB    00:00
 > Reading repository metadata in from local files
 > primary.xml.gz            100% |=========================| 1.1 kB    00:00
 > Could not find update match for jpackage-utils-1.6.6-1jpp_2rh
 > No Packages marked for Update/Obsoletion
 > 
 > Am I missing something?

Yes.  Remove it with `rpm -e'.  Install it with `yum install'.

Andrew.



From dimi at lattica.com  Mon Mar 20 22:04:21 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 17:04:21 -0500
Subject: java-1.4.2-gcj-compat package problem
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671><17439.7570.458154.295107@zapata.pink><0af601c64c64$f5cab160$b6491b31@td612671><17439.8591.948815.966657@zapata.pink><0b2601c64c68$4ab4caf0$b6491b31@td612671>
	<17439.9747.977716.606497@zapata.pink>
Message-ID: <0b4901c64c6a$3eb93f90$b6491b31@td612671>

From: "Andrew Haley" <aph at redhat.com>
>  > Heh, 1jpp_2rh > 1jpp, yum should update it, no?
>
> No.

Why? Something is broken: my system got into this state
without me doing anything wrong.

> Yes.  Remove it with `rpm -e'.  Install it with `yum install'.

Still couldn't be found:

[root at dimi ~]# rpm -e jpackage-utils
error: Failed dependencies:
        jpackage-utils >= 0:1.5.26 is needed by (installed)
java-1.4.2-sun-1.4.2.08-1jpp.i586
        jpackage-utils >= 0:1.6.2-1jpp_5rh is needed by (installed)
gnu-crypto-2.0.1-1jpp_5fc.noarch
        jpackage-utils >= 0:1.6.3-1jpp_1rh is needed by (installed)
java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.i386
        jpackage-utils >= 0:1.6.3-1jpp_1rh is needed by (installed)
jessie-1.0.0-8.noarch
        jpackage-utils >= 0:1.6.3-1jpp_1rh is needed by (installed)
java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.1.i386
        jpackage-utils >= 0:1.6.3-1jpp_1rh is needed by (installed)
java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh.FC4.2.i386
        jpackage-utils >= 0:1.5 is needed by (installed)
log4j-1.2.12-1jpp.noarch
        jpackage-utils >= 0:1.5 is needed by (installed)
xml-commons-1.3.02-2jpp.noarch
        jpackage-utils >= 0:1.5 is needed by (installed)
ant-1.6.2-3jpp_8fc.i386
        jpackage-utils is needed by (installed) antlr-2.7.6-1jpp.noarch
        jpackage-utils >= 0:1.5.32 is needed by (installed)
tomcat5-jasper-5.0.30-11jpp.noarch
        jpackage-utils >= 0:1.6.0 is needed by (installed)
tomcat5-5.0.30-11jpp.noarch
[root at dimi ~]# rpm -e --nodeps jpackage-utils
[root at dimi ~]# yum install jpackage-utils-1.6.6-1jpp_2rh
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
No Match for argument: jpackage-utils-1.6.6-1jpp_2rh
Nothing to do

It finds the same package again:

[root at dimi ~]# yum install jpackage-utils
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for jpackage-utils to pack into transaction set.
jpackage-utils-1.6.6-1jpp 100% |=========================|  19 kB    00:00
---> Package jpackage-utils.noarch 0:1.6.6-1jpp set to be updated
--> Running transaction check

Dependencies Resolved

============================================================================
=
 Package                 Arch       Version          Repository        Size
============================================================================
=
Installing:
 jpackage-utils          noarch     1.6.6-1jpp       jpackage16-generic   49
k

Transaction Summary
============================================================================
=
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 49 k
Is this ok [y/N]: y
Downloading Packages:
(1/1): jpackage-utils-1.6 100% |=========================|  49 kB    00:00
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: jpackage-utils               ######################### [1/1]

Installed: jpackage-utils.noarch 0:1.6.6-1jpp
Complete!

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From fitzsim at redhat.com  Mon Mar 20 22:11:08 2006
From: fitzsim at redhat.com (Thomas Fitzsimmons)
Date: Mon, 20 Mar 2006 17:11:08 -0500
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0b4901c64c6a$3eb93f90$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
	<0af601c64c64$f5cab160$b6491b31@td612671>
	<17439.8591.948815.966657@zapata.pink>
	<0b2601c64c68$4ab4caf0$b6491b31@td612671>
	<17439.9747.977716.606497@zapata.pink>
	<0b4901c64c6a$3eb93f90$b6491b31@td612671>
Message-ID: <1142892668.3844.6.camel@tortoise.toronto.redhat.com>

Hi,

On Mon, 2006-03-20 at 17:04 -0500, Dimi Paun wrote:

>  Package                 Arch       Version          Repository        Size
> ============================================================================
> =
> Installing:
>  jpackage-utils          noarch     1.6.6-1jpp       jpackage16-generic   49
> k

Try disabling the jpackage16-generic repository before "yum install
jpackage-utils".

I've proposed rebuild-security-providers for inclusion in the next
upstream release of jpackage-utils.  If it is accepted then this
incompatibility will be resolved.

Tom




From aph at redhat.com  Mon Mar 20 22:11:33 2006
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Mar 2006 22:11:33 +0000
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0b4901c64c6a$3eb93f90$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
	<0af601c64c64$f5cab160$b6491b31@td612671>
	<17439.8591.948815.966657@zapata.pink>
	<0b2601c64c68$4ab4caf0$b6491b31@td612671>
	<17439.9747.977716.606497@zapata.pink>
	<0b4901c64c6a$3eb93f90$b6491b31@td612671>
Message-ID: <17439.10389.847505.591174@zapata.pink>

Dimi Paun writes:
 > From: "Andrew Haley" <aph at redhat.com>
 > >  > Heh, 1jpp_2rh > 1jpp, yum should update it, no?
 > >
 > > No.
 > 
 > Why? Something is broken: my system got into this state
 > without me doing anything wrong.
 > 
 > > Yes.  Remove it with `rpm -e'.  Install it with `yum install'.
 > 
 > Still couldn't be found:

I think you've got yum pointing at jpackage.org, not fedora.

Get rid of whatever yum config you have pointing at jpackage.org, and
you'll see this:

Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for jpackage-utils to pack into transaction set.
jpackage-utils-1.6.6-1jpp 100% |=========================|  20 kB    00:00
---> Package jpackage-utils.noarch 0:1.6.6-1jpp_2rh set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 jpackage-utils          noarch     1.6.6-1jpp_2rh   development        50 k

Transaction Summary
=============================================================================
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 50 k
Downloading Packages:
(1/1): jpackage-utils-1.6 100% |=========================|  50 kB    00:01
Running Transaction Test
warning: jpackage-utils-1.6.6-1jpp_2rh: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: jpackage-utils               ######################### [1/1]

Installed: jpackage-utils.noarch 0:1.6.6-1jpp_2rh
Complete!

Andrew.



From dimi at lattica.com  Mon Mar 20 22:15:40 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 17:15:40 -0500
Subject: java-1.4.2-gcj-compat package problem
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671><17439.7570.458154.295107@zapata.pink><0af601c64c64$f5cab160$b6491b31@td612671><17439.8591.948815.966657@zapata.pink><0b2601c64c68$4ab4caf0$b6491b31@td612671><17439.9747.977716.606497@zapata.pink><0b4901c64c6a$3eb93f90$b6491b31@td612671>
	<17439.10389.847505.591174@zapata.pink>
Message-ID: <0b5f01c64c6b$d34a4770$b6491b31@td612671>

From: "Andrew Haley" <aph at redhat.com>
> I think you've got yum pointing at jpackage.org, not fedora.

Yes.

> Get rid of whatever yum config you have pointing at jpackage.org, and
> you'll see this:

Do we really need this sort of incompatibilities?

>
============================================================================
=
>  Package                 Arch       Version          Repository
Size
>
============================================================================
=
> Installing:
>  jpackage-utils          noarch     1.6.6-1jpp_2rh   development        50
k
>
> Transaction Summary
>
============================================================================
=

I don't have development enabled! I get this instead:

[root at dimi ~]# rpm -e --nodeps jpackage-utils
[root at dimi ~]# yum install jpackage-utils
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for jpackage-utils to pack into transaction set.
jpackage-utils-1.6.3-1jpp 100% |=========================|  17 kB    00:00
---> Package jpackage-utils.noarch 0:1.6.3-1jpp_1rh set to be updated
--> Running transaction check

Dependencies Resolved

============================================================================
=
 Package                 Arch       Version          Repository        Size
============================================================================
=
Installing:
 jpackage-utils          noarch     1.6.3-1jpp_1rh   base               46 k

Transaction Summary
============================================================================
=
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 46 k
Is this ok [y/N]: y
Downloading Packages:
(1/1): jpackage-utils-1.6 100% |=========================|  46 kB    00:00
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: jpackage-utils               ######################### [1/1]

Installed: jpackage-utils.noarch 0:1.6.3-1jpp_1rh
Complete!

Much older jpackage-utils, it will get updated from jpackage
as soon as I enable it again :( Something is foobared...

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From smooge at gmail.com  Mon Mar 20 22:23:39 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Mon, 20 Mar 2006 15:23:39 -0700
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142889287.3002.42.camel@aglarond.local>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889287.3002.42.camel@aglarond.local>
Message-ID: <80d7e4090603201423me54ba3q74086be1bda8b109@mail.gmail.com>

On 3/20/06, Jeremy Katz <katzj at redhat.com> wrote:
> On Mon, 2006-03-20 at 21:40 +0100, David Nielsen wrote:
> > man, 20 03 2006 kl. 19:45 +0100, skrev Arjan van de Ven:
> > > personally I think the current 9 month schedule wasn't too bad (ok the
> > > end slipped too much but lets ignore that bit); it gives enough time to
> > > do fundamental improvements. For fc6 it would be nice if boot speed was
> > > further improved for example, and since initscripts are tricky and need
> > > lots of testing... a bit of extra time would be neat
> >
> > I tend to agree, the 9 month cycle worked wonderfully, Fedora Core 5 is
> > by far the best release the Fedora Project has put out yet and as a
> > tester I enjoyed having that extra time to see new fundamental changes
> > take place and get bugs tracked down.
>
> Realistically, I don't think the 9 month cycle really helped that much
> except for one very specific case of the underlying installer changes.
> And realistically, if it had been a six month cycle instead, those would

The problem with 6 month release cycles is developer burn-out. You had
3 extra months of fluff time that I saw lots of developers come in and
out and up-to-speed, and time for some developers to hand other stuff
off. In the previous release cycles.. I saw more people just bail out
after their 2nd release because they just didnt have any energy left
to devote and there was no time to do so. You can only push people
along a marathon schedule for so long before they break..

If you go back to a 6 month schedule, you will need to pair back how
many CD's are in the core set by at least 2 or 3 cd's. That would give
developers 6 weeks of fluff time to regain their energy after a
release and then be able to come back and say "you know this brick
wall we keep hitting on this project? Did you know there was a door 2
feet down?"

> have been worked out then as well.  For everything else, if we had been
> on a six month cycle, some of them would have made FC5 and some would
> have made FC6.  But guess what, that's going to be true no matter _when_
> you actually cut a release.  It's the price of doing releases more than
> once every three years :-)
>
> Jeremy
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From mharris at mharris.ca  Mon Mar 20 22:29:16 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 20 Mar 2006 17:29:16 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142889303.3604.10.camel@T7.Linux>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
Message-ID: <441F2CBC.9060204@mharris.ca>

Paul F. Johnson wrote:
> Hi,
> 
> 
>>But let's get a clear roadmap down this time, what features are
>>essential for the next cycle?
> 
> 
> A *much* reduced core size (5 CDs + rescue is getting a bit much) and
> large reduction in the overall memory overhead. I know FC is fantastic,
> but given you need 128Mb for a text only version and 512Mb for a desktop
> environment, it's becoming hard to justify to the powers that be that
> using Linux over WinXP is that good an option.

Are you implying that the only reason one would choose Linux over
Windows XP, is because it has lower memory and system requirements?

That is one particular usage case scenario that might tilt the scales
of a given rollout to a Linux based solution over an XP based one, but
there are far far more other reasons for using Linux over XP than just
"lower memory/disk footprint".

Having expressed this though, I also agree with you completely, in that
it would be nice to see the overall memory footprint reduced in a sane
manner without tossing out desired functionality, etc.


> Slack 10 can run (text only) in 18Mb with a desktop environment in 64Mb
> - Debian (sorry for swearing on this list) is a whole lot smaller than
> FC in terms of memory again.

Sure, different distributions focus on different areas, with some
levels of overlapping.  I don't think it is even possible at all
to make a complete one-size-fits all distribution however, because
different people have different and often conflicting
goals/requirements.


> I think it was suggested that ISOs are made of FE. It may be time to do
> this, but with quite a lot from FC moved to it. For example, gcc-gnat,
> gfortran, objc and anything *not* mono/mcs (in other words, beagle,
> fspot etc) should, IMHO, be in extras - and yes, I do use gfortran and
> gnat. The OOo language packs should also be moved out - just keep in
> french, german, spanish and any big userbases.

IMHO, moving more and more stuff out of Core and into Extras is an
overall good idea, so long as the infrastructure is present in
_advance_ to make it easy to install the stuff that has moved to
Extras, both at OS install time and later, and without requiring
mandatory network access.  ie:  Fedora Extras on CD, kindof like
powertools was before, but with anaconda support for that.

Anaconda support for additional arbitrary CDs would be nice.


> The same applies to Qt and KDE - quite a lot of the material in there
> should be in extras, Qt (standard + devel) and some of the kde system
> should be in Core. We also have a number of different database systems
> in Core. Could a case not be made for trimming it down to MySQL and
> postgresql with the rest again going to FE?

I use KDE mainly, but with mostly GTK apps.  Moving KDE to Extras would
be ok I guess, so long as I can still choose to install it at install
time, and not have to mess around a lot post install.

> 9 months is a long time for a release. Perhaps an interim release at the
> 5 month stage would be an advantage.
> 
> Obviously, these are just ideas *but* they do answer a growing number of
> criticisms of FC.

The only reason there might be growing numbers of criticisms of FC,
is that the userbase is expanding, so it makes sense that as the
number of users increase in volume that the number of both praises
and criticisms will increase in volume proportionately.

If we had a tug of war contest, in which 6 month cycle was the centre
of the tug of war starting point, and the team pulling to pull it
towards 4-5 months was on one side, and the team pulling on the
7-12 months was on the other side, I think we would clearly see the
"6 month flag" start out at the center, move a bit to the left, then
back to center and a bit to the right, and keep doing that more or
less indefinitely, until everyone passed out from exhaustion, or the
rope broke in half.

It makes more sense to base the release date off the features planned
for that release and an estimate of how much time is required to
obtain those features.  That includes in-house developed features,
and accounting for upstream release dates of various software that
are desired in the release.

That's much more important IMHO than arbitrary dates picked because
some people want a faster release cycle or longer release cycle for
their own individual preferences/desires.



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From aph at redhat.com  Mon Mar 20 22:47:29 2006
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Mar 2006 22:47:29 +0000
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0b5f01c64c6b$d34a4770$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
	<0af601c64c64$f5cab160$b6491b31@td612671>
	<17439.8591.948815.966657@zapata.pink>
	<0b2601c64c68$4ab4caf0$b6491b31@td612671>
	<17439.9747.977716.606497@zapata.pink>
	<0b4901c64c6a$3eb93f90$b6491b31@td612671>
	<17439.10389.847505.591174@zapata.pink>
	<0b5f01c64c6b$d34a4770$b6491b31@td612671>
Message-ID: <17439.12546.187028.628745@zapata.pink>

Dimi Paun writes:
 > From: "Andrew Haley" <aph at redhat.com>
 > > I think you've got yum pointing at jpackage.org, not fedora.
 > 
 > Yes.
 > 
 > > Get rid of whatever yum config you have pointing at jpackage.org, and
 > > you'll see this:
 > 
 > Do we really need this sort of incompatibilities?
 > 
 > >
 > ============================================================================
 > =
 > >  Package                 Arch       Version          Repository
 > Size
 > >
 > ============================================================================
 > =
 > > Installing:
 > >  jpackage-utils          noarch     1.6.6-1jpp_2rh   development        50
 > k
 > >
 > > Transaction Summary
 > >
 > ============================================================================
 > =
 > 
 > I don't have development enabled! I get this instead:
 > 
 > [root at dimi ~]# rpm -e --nodeps jpackage-utils
 > [root at dimi ~]# yum install jpackage-utils
 > Setting up Install Process
 > Setting up repositories
 > Reading repository metadata in from local files
 > Parsing package install arguments
 > Resolving Dependencies
 > --> Populating transaction set with selected packages. Please wait.
 > ---> Downloading header for jpackage-utils to pack into transaction set.
 > jpackage-utils-1.6.3-1jpp 100% |=========================|  17 kB    00:00
 > ---> Package jpackage-utils.noarch 0:1.6.3-1jpp_1rh set to be updated
 > --> Running transaction check
 > 
 > Dependencies Resolved
 > 
 > ============================================================================
 > =
 >  Package                 Arch       Version          Repository        Size
 > ============================================================================
 > =
 > Installing:
 >  jpackage-utils          noarch     1.6.3-1jpp_1rh   base               46 k
 > 
 > Transaction Summary
 > ============================================================================
 > =
 > Install      1 Package(s)
 > Update       0 Package(s)
 > Remove       0 Package(s)
 > Total download size: 46 k
 > Is this ok [y/N]: y
 > Downloading Packages:
 > (1/1): jpackage-utils-1.6 100% |=========================|  46 kB    00:00
 > Running Transaction Test
 > Finished Transaction Test
 > Transaction Test Succeeded
 > Running Transaction
 >   Installing: jpackage-utils               ######################### [1/1]
 > 
 > Installed: jpackage-utils.noarch 0:1.6.3-1jpp_1rh
 > Complete!
 > 
 > Much older jpackage-utils, it will get updated from jpackage
 > as soon as I enable it again :( Something is foobared...

My guess is your yum is pointed at FC4.

Andrew.



From dimi at lattica.com  Mon Mar 20 22:57:28 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 17:57:28 -0500
Subject: java-1.4.2-gcj-compat package problem
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671><17439.7570.458154.295107@zapata.pink><0af601c64c64$f5cab160$b6491b31@td612671><17439.8591.948815.966657@zapata.pink><0b2601c64c68$4ab4caf0$b6491b31@td612671><17439.9747.977716.606497@zapata.pink><0b4901c64c6a$3eb93f90$b6491b31@td612671><17439.10389.847505.591174@zapata.pink><0b5f01c64c6b$d34a4770$b6491b31@td612671>
	<17439.12546.187028.628745@zapata.pink>
Message-ID: <0b9b01c64c71$aa01d4e0$b6491b31@td612671>

From: "Andrew Haley" <aph at redhat.com>
> My guess is your yum is pointed at FC4.

Sorry I didn't mention it, it is indeed. It's just
broken for FC4 :) People still use it, no?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From Lam at Lam.pl  Mon Mar 20 23:12:10 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Tue, 21 Mar 2006 00:12:10 +0100
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0b9b01c64c71$aa01d4e0$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
	<0af601c64c64$f5cab160$b6491b31@td612671>
	<17439.8591.948815.966657@zapata.pink>
	<0b2601c64c68$4ab4caf0$b6491b31@td612671>
	<17439.9747.977716.606497@zapata.pink>
	<0b4901c64c6a$3eb93f90$b6491b31@td612671>
	<17439.10389.847505.591174@zapata.pink>
	<0b5f01c64c6b$d34a4770$b6491b31@td612671>
	<17439.12546.187028.628745@zapata.pink>
	<0b9b01c64c71$aa01d4e0$b6491b31@td612671>
Message-ID: <1142896330.5818.0.camel@pensja.lam.pl>

Dnia 20-03-2006, pon o godzinie 17:57 -0500, Dimi Paun napisa?(a):
> Sorry I didn't mention it, it is indeed. It's just
> broken for FC4 :) People still use it, no?
This is fedora-devel, not old-fedora-support ;)

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/7c2eb8e4/attachment.sig>

From Axel.Thimm at ATrpms.net  Mon Mar 20 23:12:09 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 21 Mar 2006 00:12:09 +0100
Subject: FC6: reducing size, moving packages out to fedora extras, security?
In-Reply-To: <441F2CBC.9060204@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux> <441F2CBC.9060204@mharris.ca>
Message-ID: <20060320231209.GV7825@neu.nirvana>

On Mon, Mar 20, 2006 at 05:29:16PM -0500, Mike A. Harris wrote:
> IMHO, moving more and more stuff out of Core and into Extras is an
> overall good idea, so long as the infrastructure is present in
> _advance_ to make it easy to install the stuff that has moved to
> Extras, both at OS install time and later, and without requiring
> mandatory network access.  ie:  Fedora Extras on CD, kindof like
> powertools was before, but with anaconda support for that.

I think this is already the plan for FC6 and the timeframe looks right
to get these parts done.

But I hope one thing doesn't get lost in this transition: Mark Cox and
his team have been checking RHEL and FC only until now (or has this
changed?). So currently I know the software on the 5 CDs has been
checked against CVEs rigorously and the security team has taken
appropriate measures.

I think this kind of security infrastructure is needed for moving
these targeted 2/3 of Fedora Core to Fedora Extras. I'm afraid that
simply assigning all of Fedora Extras to be checked as good as Fedora
Core has been means more human resources which may not be
available. So I see three scenarios:

o packages moved to Fedora Extras are not being checked by Mark Cox
  and friends anymore

o Mark Cox get a lot more coworkers to be able to deal with all
  packages in Fedora Core and Fedora Extras

o Fedora Extras is split security-wise into 1st class and 2nd class
  citizens.

From a user's POV I'd wish the second scenario would happen.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/005aa957/attachment.sig>

From aph at redhat.com  Mon Mar 20 23:17:31 2006
From: aph at redhat.com (Andrew Haley)
Date: Mon, 20 Mar 2006 23:17:31 +0000
Subject: java-1.4.2-gcj-compat package problem
In-Reply-To: <0b9b01c64c71$aa01d4e0$b6491b31@td612671>
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671>
	<17439.7570.458154.295107@zapata.pink>
	<0af601c64c64$f5cab160$b6491b31@td612671>
	<17439.8591.948815.966657@zapata.pink>
	<0b2601c64c68$4ab4caf0$b6491b31@td612671>
	<17439.9747.977716.606497@zapata.pink>
	<0b4901c64c6a$3eb93f90$b6491b31@td612671>
	<17439.10389.847505.591174@zapata.pink>
	<0b5f01c64c6b$d34a4770$b6491b31@td612671>
	<17439.12546.187028.628745@zapata.pink>
	<0b9b01c64c71$aa01d4e0$b6491b31@td612671>
Message-ID: <17439.14347.169619.941397@zapata.pink>

Dimi Paun writes:
 > From: "Andrew Haley" <aph at redhat.com>
 > > My guess is your yum is pointed at FC4.
 > 
 > Sorry I didn't mention it, it is indeed. It's just
 > broken for FC4 :) People still use it, no?

Well, this is fedora-devel-list.

OK, so you've got a configuration problem, with a bleeding-edge
jpackage overriding the stable FC4 release.

Andrew.



From dimi at lattica.com  Mon Mar 20 23:24:24 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 18:24:24 -0500
Subject: java-1.4.2-gcj-compat package problem
References: <0a4a01c64c53$1e5596c0$b6491b31@td612671><17439.7570.458154.295107@zapata.pink><0af601c64c64$f5cab160$b6491b31@td612671><17439.8591.948815.966657@zapata.pink><0b2601c64c68$4ab4caf0$b6491b31@td612671><17439.9747.977716.606497@zapata.pink><0b4901c64c6a$3eb93f90$b6491b31@td612671><17439.10389.847505.591174@zapata.pink><0b5f01c64c6b$d34a4770$b6491b31@td612671><17439.12546.187028.628745@zapata.pink><0b9b01c64c71$aa01d4e0$b6491b31@td612671>
	<17439.14347.169619.941397@zapata.pink>
Message-ID: <0c1901c64c75$6d3a4de0$b6491b31@td612671>

From: "Andrew Haley" <aph at redhat.com>
> OK, so you've got a configuration problem, with a bleeding-edge
> jpackage overriding the stable FC4 release.

No, it is not a configuration problem. My system is
configured properly, and the upstream packages are
broken. And unless FC4 was EOLed on the very same
day FC5 was released, I fail to see how this is off
topic here.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From i.pilcher at comcast.net  Mon Mar 20 23:27:26 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Mon, 20 Mar 2006 17:27:26 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F21B1.5090902@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>
	<441F21B1.5090902@mharris.ca>
Message-ID: <dvndou$llf$1@sea.gmane.org>

Mike A. Harris wrote:
> 
> All proprietary drivers?  ;o)
> 

I can't help wondering...

What do you guys do when you want decent 3D performance?

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From paul at all-the-johnsons.co.uk  Mon Mar 20 23:27:43 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Mon, 20 Mar 2006 23:27:43 +0000
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F2CBC.9060204@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>  <441F2CBC.9060204@mharris.ca>
Message-ID: <1142897263.3604.33.camel@T7.Linux>

> Hi,

>  
> > A *much* reduced core size (5 CDs + rescue is getting a bit much) and
> > large reduction in the overall memory overhead. I know FC is fantastic,
> > but given you need 128Mb for a text only version and 512Mb for a desktop
> > environment, it's becoming hard to justify to the powers that be that
> > using Linux over WinXP is that good an option.
> 
> Are you implying that the only reason one would choose Linux over
> Windows XP, is because it has lower memory and system requirements?

In part, yes. On a voluntary basis, I work for a local charity with some
pretty low end boxes (I think the highest spec machine is P3-366 or
thereabouts), all with 256Mb of memory. Linux runs fine on them.
However, due to the pointy haired boss (and he actually has pointy
hair!) reading distrowatch and seeing that 512Mb is recommended and has
said that given that, why can't he have his XP box and because of that,
we should have XP boxes. I know there is a massive problem with the
logic in that...

> That is one particular usage case scenario that might tilt the scales
> of a given rollout to a Linux based solution over an XP based one, but
> there are far far more other reasons for using Linux over XP than just
> "lower memory/disk footprint".

Yep. I completely agree. Memory is dirt cheap and if wasn't for me
giving my time free, the cost of Linux support would probably mean it is
more economical to go with the Borg and OOo.

> Having expressed this though, I also agree with you completely, in that
> it would be nice to see the overall memory footprint reduced in a sane
> manner without tossing out desired functionality, etc.

It would be interesting to see if the biggest of the hogs is the desktop
environment. I have noticed that while gnome is far better than previous
incarnations, it has somewhat become, well, bloated.

> > Slack 10 can run (text only) in 18Mb with a desktop environment in 64Mb
> > - Debian (sorry for swearing on this list) is a whole lot smaller than
> > FC in terms of memory again.
> 
> Sure, different distributions focus on different areas, with some
> levels of overlapping.  I don't think it is even possible at all
> to make a complete one-size-fits all distribution however, because
> different people have different and often conflicting
> goals/requirements.

True. If we leave aside Slack and concentrate on Debian, SuSE and
Mandriva (in otherwords, the closest thing to competition of the big
distros), Mandriva looks to have the same sort of memory requirements to
functionality ratio as FC, yet SuSE and Debian have smaller footprints
and arguably, greater functionality.

I'm not going to get into the argument over if Debian should be included
(as stable), I'm using it as not only is it one of the most revered, but
is the basis for the likes of Umbunto and Knoppix.

> > I think it was suggested that ISOs are made of FE. It may be time to do
> > this, but with quite a lot from FC moved to it. For example, gcc-gnat,
> > gfortran, objc and anything *not* mono/mcs (in other words, beagle,
> > fspot etc) should, IMHO, be in extras - and yes, I do use gfortran and
> > gnat. The OOo language packs should also be moved out - just keep in
> > french, german, spanish and any big userbases.
> 
> IMHO, moving more and more stuff out of Core and into Extras is an
> overall good idea, so long as the infrastructure is present in
> _advance_ to make it easy to install the stuff that has moved to
> Extras, both at OS install time and later, and without requiring
> mandatory network access.  ie:  Fedora Extras on CD, kindof like
> powertools was before, but with anaconda support for that.

That would be a perfect solution and with another 9 months between FC5
and 6, is probably doable. 

I've noted the comments about the src.rpms and the "not rocket science"
to move them over to Extras once they've been built. I can see both
points of view there. I would say it would probably be easier for the
likes of gnat and gfortran as well as non-core mono pieces to have them
built in Extras than build in core and shift across.

> Anaconda support for additional arbitrary CDs would be nice.

Well, firstboot does have that sort of support, sort of...

> > The same applies to Qt and KDE - quite a lot of the material in there
> > should be in extras, Qt (standard + devel) and some of the kde system
> > should be in Core. We also have a number of different database systems
> > in Core. Could a case not be made for trimming it down to MySQL and
> > postgresql with the rest again going to FE?
> 
> I use KDE mainly, but with mostly GTK apps.  Moving KDE to Extras would
> be ok I guess, so long as I can still choose to install it at install
> time, and not have to mess around a lot post install.

I'm not suggesting a whole sale shift of KDE to FE, that would be silly
and very counter productive (just look what happened when it was
suggested that RH would be gnome only and how that was blown out of
proportion!). I'm saying the likes of kedu, kgames and quite a good
chunk of the kde-internet stuff being shifted out. Keep knode, kopete,
kwifi and akregator and possibly kirc. When koffice was shifted out, it
hardly caused a riot...

> > 9 months is a long time for a release. Perhaps an interim release at the
> > 5 month stage would be an advantage.
> > 
> > Obviously, these are just ideas *but* they do answer a growing number of
> > criticisms of FC.
> 
> The only reason there might be growing numbers of criticisms of FC,
> is that the userbase is expanding, so it makes sense that as the
> number of users increase in volume that the number of both praises
> and criticisms will increase in volume proportionately.

True. It would be interesting to see the proportions of people using
what distro would be. Okay, that's probably a who can pee higher sort of
thing, but it would be interesting.

> It makes more sense to base the release date off the features planned
> for that release and an estimate of how much time is required to
> obtain those features.  That includes in-house developed features,
> and accounting for upstream release dates of various software that
> are desired in the release.

True. Given the improvements in FC5 and all the hard work, bug reports
and the late inclusion of mono, I was happy with 9 months. If the
changes to reduce the footprint without costing the functionality took 9
months, I doubt you'd hear that many moans as well. What you don't want
is the rush job which FC2 and FC4 felt like (I'm not saying they were
either!)

> That's much more important IMHO than arbitrary dates picked because
> some people want a faster release cycle or longer release cycle for
> their own individual preferences/desires.

Couldn't agree more. I want FC to succeed and it will only do that as
part of a wider balancing act.

TTFN

Paul
-- 
"ein zu starker starker Anblick kann Sie toten. Sie gegen gerade uber
den Rand mit dem festen Wissen des Wege vor Ihnen" - Linus Tordvals



From paul at all-the-johnsons.co.uk  Mon Mar 20 23:29:41 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Mon, 20 Mar 2006 23:29:41 +0000
Subject: Wild and crazy times for the development tree
In-Reply-To: <dvndou$llf$1@sea.gmane.org>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net> <441F21B1.5090902@mharris.ca>
	<dvndou$llf$1@sea.gmane.org>
Message-ID: <1142897381.3604.36.camel@T7.Linux>

Hi,

> > All proprietary drivers?  ;o)

> What do you guys do when you want decent 3D performance?

Take viagra! ;-p

Seriously, this box I'm on now has a monster nVidia card. However, it's
my development box, so I'm not that worried. My son uses ATI, my other
half is on SiS and my laptop in Intel. All three are fine with 3D.

TTFN

Paul
-- 
"ein zu starker starker Anblick kann Sie toten. Sie gegen gerade uber
den Rand mit dem festen Wissen des Wege vor Ihnen" - Linus Tordvals



From mharris at mharris.ca  Tue Mar 21 00:17:20 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 20 Mar 2006 19:17:20 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320215738.GD28360@redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<5256d0b0603200911j2fab3d18h4bdcbaf3d4ebfa1d@mail.gmail.com>
	<441F2376.5080905@mharris.ca> <20060320215738.GD28360@redhat.com>
Message-ID: <441F4610.5070108@mharris.ca>

Dave Jones wrote:
> On Mon, Mar 20, 2006 at 04:49:42PM -0500, Mike A. Harris wrote:
>  > So, R300 dri support will be something you need to compile for yourself
>  > for the time being if desired.  Also, our kernel does not have the
>  > R300+ PCI IDs in it anymore, so you may need to recompile your kernel
>  > as well.  Not sure what davej's specific plans are for that, but I hope
>  > he keeps the R300 PCI IDs out of the kernel at least until the r300
>  > DRI driver is remotely useable large-scale.
> 
> not that it seems to matter. X seems to be doing a 'modprobe radeon'
> when it sees anything ATI.

Yeah.  Not sure when exactly that changed, but it's probably because
there is now OSS support for Mach64/R128/Radeon for 3D I'm guessing.
We don't ship the mach64 DRI driver, or the R300+ one, but the X
server still seems to have static lists of stuff which is a bit brain
dead if you ask me.  ;o)


> Chopping the IDs out stops it being
> initialised, but it appears that X does _something_ differently
> just by having the module loaded even if its not using it.

Indeed, it is looking that way.  We'll likely figure that out during
FC6 and hopefully get it fixed in Xorg 7.1

> I can keep them chopped out for the time being, but the downside is
> we're not going to get a lot of coverage testing, so how will we know
> when its 'good enough' ?

I'd say at a minimum - when there's a new upstream release which
contains CVS checkins to the code in question as a minimum.  If
no fixes have went into the code that didn't work before, it's
most likely still broken.  ;o)

For the 2D-only side of things, I'd want to wait at least until
the new 2D radeon driver comes out (stable branch) and let it
get tested for a while in rawhide.  Then hopefully get any new
regressions resolved.  After that, enabling the kernel side
again to see if it breaks anything would be following scientific
method.  I'd prefer to avoid re-enabling 2-3 things simultaneously,
and then trying to guess which one caused breakage to occur though.

By the time a new stable 2D driver has come out and had a reasonable
shakedown period, then have a kernel DRM update which re-enables the
kernel bits, and another shakedown period - a new Mesa is likely
to be out, if not for the 6.4.x track, then the 6.5.x/6.6 track
heading towards Xorg 7.1.  I think it'd be good to wait until then
before considering re-enabling R300 DRI driver support in Mesa, as
we'd just be enabling known-broken code to do it before then, and
getting nothing useful other than an increase in bug reports
hitting Red Hat bugzilla, which should go to X.Org bugzilla instead.
;o)




-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mharris at mharris.ca  Tue Mar 21 00:43:41 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 20 Mar 2006 19:43:41 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <dvndou$llf$1@sea.gmane.org>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net> <441F21B1.5090902@mharris.ca>
	<dvndou$llf$1@sea.gmane.org>
Message-ID: <441F4C3D.6040605@mharris.ca>

Ian Pilcher wrote:
> Mike A. Harris wrote:
> 
>>All proprietary drivers?  ;o)
>>
> 
> 
> I can't help wondering...
> 
> What do you guys do when you want decent 3D performance?

That'll likely vary greatly from person to person, rather than there
being one single unified answer.

To be honest, for my own personal needs, I generally don't need
mandatory OpenGL 3D acceleration support in Linux for 99.99999%
of what I use Linux for day to day.  In fact, my primary desktop
system usually has DRI disabled, as this machine is used almost
entirely for 2D only usage, and having DRI enabled just leaves
another potential source of instability for me.

Whenever I do need/want 3D enabled support for something in Linux,
I fire up another machine and use it instead, leaving my primary
desktop in a stable DRI-disabled state.

To answer the "when do I want decent 3D performance" question,
I must first answer "When do I want accelerated 3D at all?".

99.99999% of the time I never need 3D acceleration in Linux
personally.  I disable the screensaver completely, or else pick
the "Matrix" saver, or some other boring simple screensaver, and
I don't use any 3D software in Linux generally.  The only real
use of OpenGL/3D software that I have would be for video games,
or for fun eye-candy stuff.  I generally turn eye-candy type of
stuff completely off on my computers that are intended for
productive work use, and I don't install video games on them
either, for the same reason.  ;o)

So, what do I use OpenGL for?  More or less for video games,
in the rare occurances that I actually have time to play games.
However, and I hate to admit this but I'm being totally honest
here - when I do actually have some spare time to play computer
games, I want to spend _all_ of that time actually playing the
games themselves and enjoying myself doing so, and spend zero of
my time trying to get the games to actually work.  As such, I
personally just play games in Windows XP and be done with it.

Please do not take that as a suggestion for what everyone else
should do however.  I admire the people out there who have the
dedication and spare time to install 3rd party emulators such
as winex or whatever is the coolest thing nowadays, and then
fiddle with whatever settings are needed, fiddle with drivers
and whatnot to get the stuff working under Linux.  I know many
people out there have tonnes of cool games and other software
running in Linux using one or more emulation layers, and I have
done so myself in the past as well.  But I just got tired of
spending 4-8 hours of downloading and compiling various things
and tweaking them to "maybe" get something to work in Linux,
and not actually have any time to _use_ the game or whatever it
was after that.  Since "fun spare time" is a limited resource
to me, I've decided to just play the games I bolted out $60
for in the OS they were designed for - at least for the time
being, than to fight the fight.

Having said that, I do look forward to some time in the future,
hopefully this year, in which I'll have some extra spare cycles
to tackle the various emulators and whatnot out there and maybe
get some stuff running in Linux again.  ;o)  I do very much hate
using Windows for anything, but I bite my tongue and use it on
occasion just to make better use of my time.

Now...  if I _was_ actually trying to get a game or some other
accelerated OpenGL software to work in Linux, I would use
whatever the best card I have on hand with OSS driver support
was at the given point in time.  The FireGL 8800 is what I
generally use for that purpose when I do enable DRI, and it
generally works quite well.  It generally meets _my_ needs,
however being a few generations old, and not having all the
latest bells and whistles, it is almost definitely not going
to meet everyone else out there's needs.  If I found it too
slow for something, I'd perhaps drop in a 9800Pro and roll
myself a custom rebuild of Mesa with the r300 dri driver
enabled and fiddle a bit.  Again, I don't expect that this
type of situation would be an acceptable or desired solution
for many other people out there, but it is something I can
personally live with for the time being, without having to
resort to proprietary drivers.

If I did have applications that I wanted to run mandatorily,
which required accelerated 3D performance, if running them
in Linux on the FireGL 8800 didn't cut it for me, I'd run them
in XP, or probably not run them at all, and find a new hobby.

That's my take on things for _my_ situation only.  Again though,
each person's situation is different, and each person has different
wants and needs, and are willing to compromise in different areas.
Some people compromise with proprietary drivers, others use OSS
drivers and compromise features or stability, others, like me
sometimes compromise by using a different OS that does what I
need/want for the given task.  To each his own.

There simply isn't a good general one-size-fits-all solution that
makes everyone happy right now.  If there was, these type of
discussions wouldn't come up 10 times a week on various mailing
lists and start heated debates that prove nothing other than the
fact that different people have different needs and different
viewpoints. ;o)

Take care,
TTYL




-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mharris at mharris.ca  Tue Mar 21 01:23:29 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 20 Mar 2006 20:23:29 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142897263.3604.33.camel@T7.Linux>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux> <441F2CBC.9060204@mharris.ca>
	<1142897263.3604.33.camel@T7.Linux>
Message-ID: <441F5591.3090205@mharris.ca>

Paul F. Johnson wrote:

>>>A *much* reduced core size (5 CDs + rescue is getting a bit much) and
>>>large reduction in the overall memory overhead. I know FC is fantastic,
>>>but given you need 128Mb for a text only version and 512Mb for a desktop
>>>environment, it's becoming hard to justify to the powers that be that
>>>using Linux over WinXP is that good an option.
>>
>>Are you implying that the only reason one would choose Linux over
>>Windows XP, is because it has lower memory and system requirements?
> 
> In part, yes. On a voluntary basis, I work for a local charity with some
> pretty low end boxes (I think the highest spec machine is P3-366 or
> thereabouts), all with 256Mb of memory. Linux runs fine on them.
> However, due to the pointy haired boss (and he actually has pointy
> hair!) reading distrowatch and seeing that 512Mb is recommended and has
> said that given that, why can't he have his XP box and because of that,
> we should have XP boxes. I know there is a massive problem with the
> logic in that...

Well actually, I wouldn't completely disagree with his logic.  In
that particular case, if hardware requirements are the greatest
concern, and Fedora has high requirements in the area, it is entirely
possible that Fedora really isn't a good choice for the particular
problem case.  As much as many of us would _like_ to see Fedora be
the end all be all general purpose solution to everything ...  it
sometimes is not.  ;o)

No harm in trying other Linux distributions to see if you can find one
with lower system requirements that allow you to avoid using XP though.


>>That is one particular usage case scenario that might tilt the scales
>>of a given rollout to a Linux based solution over an XP based one, but
>>there are far far more other reasons for using Linux over XP than just
>>"lower memory/disk footprint".
> 
> Yep. I completely agree. Memory is dirt cheap and if wasn't for me
> giving my time free, the cost of Linux support would probably mean it is
> more economical to go with the Borg and OOo.

A few years ago I set up a Linux solution for a small business, which
was very happy with it for a few years.  I provided support for a
reasonable fee for several years and they didn't need to contact me
very often, so they were happy.  However, the OS eventually went EOL,
and I informed them they really needed to do an upgrade to something
more modern.  They didn't want to take the risk of destabilizing what
worked so well for so long, and so delayed acting on that.  When they
finally contacted me to see if I could update them, was around the
time Fedora came out.  Previously they were using Red Hat Linux, and
I told them I could no longer support their EOL'd RHL box, and that
it would cost them far less to go with RHEL than to be paying me to
update the box every 6 months or so.

They didn't want to pay the subscription for RHEL, even though they
were paying me more than that anyway, and I pointed out that it would
be cheaper for them to do this, and for Red Hat to provide them
support directly.

In similar failed-logic, they considered switching to a Windows based
solution instead, and I told them it'd cost them a lot more to do that,
and it'd cost them a lot more to have someone coming over daily/weekly
to fix the problems they'd have for their particular usage.  They
agreed it could potentially be more costly, but still didn't make the
logic connection that RHEL would be cheaper TCO to them.  They wanted
to keep me on their emergency dialer.  ;o)

In the end, I left the decision up to them to decide to go with RHEL
or Windows, and I passed the administration of the EOL'd box (which was
quite minimal at the time) on to a friend instead, so I wouldn't have
to deal with any eventual security breach or other headache which was
inevitably likely to happen.

In the end, they decided to not make any decision, and I believe they
may still be using the ancient 6.2 based solution.  ;o)

So there's logic, illogic, and an entire new thing which defies
comprehension..  irrational illogic perhaps we could call it.  ;o)

Eventually, the system will likely fall over, and my phone will ring
off the hook.  Thank technology for caller ID!  ;o)


>>Having expressed this though, I also agree with you completely, in that
>>it would be nice to see the overall memory footprint reduced in a sane
>>manner without tossing out desired functionality, etc.
> 
> It would be interesting to see if the biggest of the hogs is the desktop
> environment. I have noticed that while gnome is far better than previous
> incarnations, it has somewhat become, well, bloated.

Indeed.  There is a tendency in OSS overall it seems for apps/libs/etc.
to sprout more and more dependencies over time just in general.  It is
very observable on the desktop, and in desktopish applications, but it
is also observable at the commandline and underlying OS level too.

Tough problem to solve I think.


>>>I think it was suggested that ISOs are made of FE. It may be time to do
>>>this, but with quite a lot from FC moved to it. For example, gcc-gnat,
>>>gfortran, objc and anything *not* mono/mcs (in other words, beagle,
>>>fspot etc) should, IMHO, be in extras - and yes, I do use gfortran and
>>>gnat. The OOo language packs should also be moved out - just keep in
>>>french, german, spanish and any big userbases.
>>
>>IMHO, moving more and more stuff out of Core and into Extras is an
>>overall good idea, so long as the infrastructure is present in
>>_advance_ to make it easy to install the stuff that has moved to
>>Extras, both at OS install time and later, and without requiring
>>mandatory network access.  ie:  Fedora Extras on CD, kindof like
>>powertools was before, but with anaconda support for that.
> 
> That would be a perfect solution and with another 9 months between FC5
> and 6, is probably doable. 
> 
> I've noted the comments about the src.rpms and the "not rocket science"
> to move them over to Extras once they've been built. I can see both
> points of view there. I would say it would probably be easier for the
> likes of gnat and gfortran as well as non-core mono pieces to have them
> built in Extras than build in core and shift across.

Personally, I think it would be confusing as hell to have a single
src.rpm generate binary rpms of which some are in Fedora Core and
others are in Fedora Extras.  That would be made more confusing
since Fedora has separate bugzilla product/etc. for Core and for
Extras (and for Legacy).  Since bugzilla components themselves are
based from the name of the src.rpm, one would have to file a bug
report from a binary package from extras against Fedora Core for the
src.rpm it was built from.

I can think of other complications and confusion that would ensue
as well.  I'm not sure what to suggest to solve those issues however.


>>Anaconda support for additional arbitrary CDs would be nice.
> 
> Well, firstboot does have that sort of support, sort of...

I'm talking about _before_ firstboot though, otherwise it is an
additional step you have to do after the OS is already installed.
That's going to be multiplied times the number of machines you
might have to install on.

I'd very much like to have the ability to install things from Core
and Extras _during_ install, both from the network, and from CD or
DVD.  Additionally, it'd be nice to be able to have Core and Extras
co-reside on a single DVD image (assuming it fits).

Wether this is planned or not, or wether it is feasible or not is
another question entirely.  I have given up on CD based installs
ever since we started producing DVD images, simply because I like
to have one disk installs possible.  Wether it is 1 CD or 1 DVD
I don't really care, but 1 DVD obviously holds more software than
1 CD, so I prefer that. ;o)  If Extras can cram in there too,
fantastic!  If not, a second DVD would be ok I guess.


>>>The same applies to Qt and KDE - quite a lot of the material in there
>>>should be in extras, Qt (standard + devel) and some of the kde system
>>>should be in Core. We also have a number of different database systems
>>>in Core. Could a case not be made for trimming it down to MySQL and
>>>postgresql with the rest again going to FE?
>>
>>I use KDE mainly, but with mostly GTK apps.  Moving KDE to Extras would
>>be ok I guess, so long as I can still choose to install it at install
>>time, and not have to mess around a lot post install. 
> 
> I'm not suggesting a whole sale shift of KDE to FE,

No, but others have suggested that we move KDE to FE, and provided
some good arguments for how it could be done in a good way that
benefits KDE users a lot, as well as benefiting the distribution by
reducing disk size, and benefitting KDE itself by scaling the number
of external people who could more actively contribute to an Extras
based KDE.

I think that it's worthy of further constructive discussion, but
that it should only be considered for the right reasons.  Some people
would view it in a negative light of KDE being "pushed out", but I
don't think that would really be the case at all.  I mostly use KDE
myself, and if it can be put in Extras in a sane manner, and still
be available at OS install time, and certain other factors sorted out,
then I think it is something worthy of continuing discussion to figure
out all the details without any hasty decisions or actions being made.


> that would be silly
> and very counter productive (just look what happened when it was
> suggested that RH would be gnome only and how that was blown out of
> proportion!).

I wouldn't say it is counter-productive.  I would however say that there
are a lot of people with strong religious preferences towards GNOME or
towards KDE who would invariably try to provide conspiracy theory spin
on such a consideration.

If there is any serious consideration made for putting KDE in extras
however, then in my opinion at least, the _goals_ would have to be
clearly defined.  ie: "Why?"  or rather "What are the benefits that
we are hoping to achieve by doing this?"

I think there are some worthy benefits to putting KDE in extras, but
I also think that if it is not considered right, not discussed
properly, and not implemented right, then it could be a disaster.

I'd definitely love to see more Fedora contributors actively
contributing directly to KDE in Fedora though, and it seems that
that would be much easier to see happen, if it was in Extras than
it being in Core.

Maybe someone would fix all the bugs in konsole that I've encountered
in the last 5 years then.  ;o)

> I'm saying the likes of kedu, kgames and quite a good
> chunk of the kde-internet stuff being shifted out. Keep knode, kopete,
> kwifi and akregator and possibly kirc. When koffice was shifted out, it
> hardly caused a riot...

That's an approach I hadn't considered.  If we could move individual
KDE/Qt applications into Extras, that might be a good way to allow
much more active KDE community in the Fedora project.  We do after
all have various GNOME/GTK stuff in extras already too, so why not
have more KDE/Qt stuff there as well?  Heck, there's probably various
stuff that is part of official GNOME that should be pushed to extras
as well, to encourage and enable additional community involvement in
the packages, and also to help reduce Core down in size to help
reduce the number of CDs, etc.


>>>9 months is a long time for a release. Perhaps an interim release at the
>>>5 month stage would be an advantage.
>>>
>>>Obviously, these are just ideas *but* they do answer a growing number of
>>>criticisms of FC.
>>
>>The only reason there might be growing numbers of criticisms of FC,
>>is that the userbase is expanding, so it makes sense that as the
>>number of users increase in volume that the number of both praises
>>and criticisms will increase in volume proportionately.
> 
> True. It would be interesting to see the proportions of people using
> what distro would be. Okay, that's probably a who can pee higher sort of
> thing, but it would be interesting.

Difficult if not impossible to measure though.  The most likely
suggestion to do such measurements is often web based surveys
or voting galleries, but unfortunately the measurement tools are
almost always inaccurate due to multiple people coming from behind
a single IP address (NAT), and individual people stuffing the polls
from multiple IPs, or even from a single IP.  Additionally, such
polls don't really measure actual usage out there very reliably,
but rather they measure the usage of people who have been made
aware of the survey and actually care enough to vote.  Many people
simply don't ever find out about such surveys, and many people
just don't care enough to vote in popularity contests of that
nature.

As such, you can never really get accurate measurements of usage
IMHO.

Reminds me of a cute paradoxical quote:

"Statistics have shown that 93.8% of all statistical studies are
innaccurate and flawed."


Or something like that... ;o)


>>It makes more sense to base the release date off the features planned
>>for that release and an estimate of how much time is required to
>>obtain those features.  That includes in-house developed features,
>>and accounting for upstream release dates of various software that
>>are desired in the release.
> 
> True. Given the improvements in FC5 and all the hard work, bug reports
> and the late inclusion of mono, I was happy with 9 months. If the
> changes to reduce the footprint without costing the functionality took 9
> months, I doubt you'd hear that many moans as well. What you don't want
> is the rush job which FC2 and FC4 felt like (I'm not saying they were
> either!)

One thing that will be nice now, regardless of the length of FC's
schedule, will be modular X.  There's going to be soooooooo much
less work to do updating each component over time, than the huge
mega monolith. ;o)

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From i.pilcher at comcast.net  Tue Mar 21 02:58:34 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Mon, 20 Mar 2006 20:58:34 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F5591.3090205@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<1142889303.3604.10.camel@T7.Linux>
	<441F2CBC.9060204@mharris.ca>	<1142897263.3604.33.camel@T7.Linux>
	<441F5591.3090205@mharris.ca>
Message-ID: <dvnq4r$m44$1@sea.gmane.org>

Mike A. Harris wrote:
> 
> Indeed.  There is a tendency in OSS overall it seems for apps/libs/etc.
> to sprout more and more dependencies over time just in general.  It is
> very observable on the desktop, and in desktopish applications, but it
> is also observable at the commandline and underlying OS level too.
> 
> Tough problem to solve I think.
> 

Partly due to the UNIX philosophy of compile-time feature selection.
It's solvable via dlopen, etc.; it would be nice to see the toolchains
help out here.

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From seg at haxxed.com  Tue Mar 21 04:04:46 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Mar 2006 22:04:46 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142889303.3604.10.camel@T7.Linux>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
Message-ID: <1142913886.5442.18.camel@localhost>

On Mon, 2006-03-20 at 21:15 +0000, Paul F. Johnson wrote:
> A *much* reduced core size (5 CDs + rescue is getting a bit much)

IMHO its getting time to just forget CDs. Put out DVD isos only. (At the
very least, stop worrying about how many CDs core fills and worry about
fitting on one DVDR...)

Especially with yum backed network installs becoming available. If you
don't want to download and burn an entire DVD iso, just download a
10-50mb network install iso. This is what I do with debian on the rare
occasion I install a system from scratch. Since I only install a system
once every few years, its a huge waste to me to download and burn 5+
disks that I'm only going to use once.

Someone on IRC was arguing that in many parts of the world, bandwidth is
very expensive. I don't see how 5 CDs to download vs a DVD make a
difference here. The real question is, how common are DVD burners, and
most importantly, DVD readers in various parts of the world.

I suppose the thing to do is keep an eye on CD downloads vs DVD. Let the
community decide.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060320/9b6486bd/attachment.sig>

From seg at haxxed.com  Tue Mar 21 04:08:34 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Mar 2006 22:08:34 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F5591.3090205@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux> <441F2CBC.9060204@mharris.ca>
	<1142897263.3604.33.camel@T7.Linux>  <441F5591.3090205@mharris.ca>
Message-ID: <1142914115.5442.19.camel@localhost>

On Mon, 2006-03-20 at 20:23 -0500, Mike A. Harris wrote:
> Personally, I think it would be confusing as hell to have a single
> src.rpm generate binary rpms of which some are in Fedora Core and
> others are in Fedora Extras.  That would be made more confusing
> since Fedora has separate bugzilla product/etc. for Core and for
> Extras (and for Legacy).  Since bugzilla components themselves are
> based from the name of the src.rpm, one would have to file a bug
> report from a binary package from extras against Fedora Core for the
> src.rpm it was built from.
> 
> I can think of other complications and confusion that would ensue
> as well.  I'm not sure what to suggest to solve those issues however.

Less separation between core and extras. Like maybe none. (cough Debian
cough)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060320/d970240b/attachment.sig>

From davej at redhat.com  Tue Mar 21 04:11:57 2006
From: davej at redhat.com (Dave Jones)
Date: Mon, 20 Mar 2006 23:11:57 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142913886.5442.18.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
Message-ID: <20060321041157.GA28237@redhat.com>

On Mon, Mar 20, 2006 at 10:04:46PM -0600, Callum Lerwick wrote:

 > Especially with yum backed network installs becoming available. If you
 > don't want to download and burn an entire DVD iso, just download a
 > 10-50mb network install iso. This is what I do with debian on the rare
 > occasion I install a system from scratch. Since I only install a system
 > once every few years, its a huge waste to me to download and burn 5+
 > disks that I'm only going to use once.
 > 
 > Someone on IRC was arguing that in many parts of the world, bandwidth is
 > very expensive. I don't see how 5 CDs to download vs a DVD make a
 > difference here. The real question is, how common are DVD burners, and
 > most importantly, DVD readers in various parts of the world.

DVD writers aren't anywhere near as commonplace as CD writers yet.
Looking around right now, I have 7 computers near me. CD writers outnumber
DVD writers 6:1.  (And the majority of the computers with CD writers are
less than 2 years old (two of them are <6 months old))

(ironically, the dvd writer is my 3 month old laptop)

I'm not claiming to be representative of the majority of Fedora users,
but given there are a lot of Fedora users less fortunate than myself,
I believe that discontinuing CD iso's would severely impact a huge portion
of our userbase.  It'd be interesting to see the download stats to see
if they agree with this.

		Dave
-- 
http://www.codemonkey.org.uk



From rc040203 at freenet.de  Tue Mar 21 04:19:49 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 21 Mar 2006 05:19:49 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F4C3D.6040605@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net> <441F21B1.5090902@mharris.ca>
	<dvndou$llf$1@sea.gmane.org>  <441F4C3D.6040605@mharris.ca>
Message-ID: <1142914789.26492.67.camel@mccallum.corsepiu.local>

On Mon, 2006-03-20 at 19:43 -0500, Mike A. Harris wrote:
> Ian Pilcher wrote:
> > Mike A. Harris wrote:
> > 
> >>All proprietary drivers?  ;o)
> >>
> > 
> > 
> > I can't help wondering...
> > 
> > What do you guys do when you want decent 3D performance?

Use the proprietary drivers ... :-)

> That'll likely vary greatly from person to person, rather than there
> being one single unified answer.

> Whenever I do need/want 3D enabled support for something in Linux,
> I fire up another machine and use it instead, leaving my primary
> desktop in a stable DRI-disabled state.
> 
> To answer the "when do I want decent 3D performance" question,
> I must first answer "When do I want accelerated 3D at all?".

> So, what do I use OpenGL for?  More or less for video games,

You are ignoring the fact, Linux has a strong user base in people with a
scientific/engineering/technical background ...

> Now...  if I _was_ actually trying to get a game or some other
> accelerated OpenGL software to work in Linux, I would use
> whatever the best card I have on hand with OSS driver support
> was at the given point in time. 

Whether you like it or not ... reality is different.

People are pragmatically using what they have/can get/are supplied with,
and will ditch the distro or even the OS if it doesn't suite to their
demands. Fortunately for Fedora, the proprietary drivers have worked
sufficiently well.

Ralf




From rc040203 at freenet.de  Tue Mar 21 04:27:58 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 21 Mar 2006 05:27:58 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F2CBC.9060204@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>  <441F2CBC.9060204@mharris.ca>
Message-ID: <1142915278.26492.75.camel@mccallum.corsepiu.local>

On Mon, 2006-03-20 at 17:29 -0500, Mike A. Harris wrote:
> Paul F. Johnson wrote:
> > Hi,
> > 
> > 
> >>But let's get a clear roadmap down this time, what features are
> >>essential for the next cycle?
> > 
> > 
> > A *much* reduced core size (5 CDs + rescue is getting a bit much) and
> > large reduction in the overall memory overhead. I know FC is fantastic,
> > but given you need 128Mb for a text only version and 512Mb for a desktop
> > environment, it's becoming hard to justify to the powers that be that
> > using Linux over WinXP is that good an option.
> 
> Are you implying that the only reason one would choose Linux over
> Windows XP, is because it has lower memory and system requirements?
No, not "the only reason", but one essential reason:

Linux's small memory footprint and it's free licensing had enabled
people to use Linux on "recycled HW".

Ralf




From notting at redhat.com  Tue Mar 21 04:35:47 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 20 Mar 2006 23:35:47 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321041157.GA28237@redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
Message-ID: <20060321043547.GA15330@devserv.devel.redhat.com>

Dave Jones (davej at redhat.com) said: 
> I'm not claiming to be representative of the majority of Fedora users,
> but given there are a lot of Fedora users less fortunate than myself,
> I believe that discontinuing CD iso's would severely impact a huge portion
> of our userbase.  It'd be interesting to see the download stats to see
> if they agree with this.

DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
and 6:1 on ppc.

Bill



From davej at redhat.com  Tue Mar 21 04:39:38 2006
From: davej at redhat.com (Dave Jones)
Date: Mon, 20 Mar 2006 23:39:38 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321043547.GA15330@devserv.devel.redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
Message-ID: <20060321043938.GD28237@redhat.com>

On Mon, Mar 20, 2006 at 11:35:47PM -0500, Bill Nottingham wrote:
 > Dave Jones (davej at redhat.com) said: 
 > > I'm not claiming to be representative of the majority of Fedora users,
 > > but given there are a lot of Fedora users less fortunate than myself,
 > > I believe that discontinuing CD iso's would severely impact a huge portion
 > > of our userbase.  It'd be interesting to see the download stats to see
 > > if they agree with this.
 > 
 > DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
 > and 6:1 on ppc.

Wow. I'm stunned.
I guess I should stop living in the past and get some DVD writables ;)

		Dave

-- 
http://www.codemonkey.org.uk



From dimi at lattica.com  Tue Mar 21 04:50:01 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 20 Mar 2006 23:50:01 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321043938.GD28237@redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
	<20060321043938.GD28237@redhat.com>
Message-ID: <1142916601.3511.82.camel@dimi>

On Mon, 2006-03-20 at 23:39 -0500, Dave Jones wrote:
> Wow. I'm stunned.

Same here. I am in the same position as Dave, and I *thought*
this is rather typical. I would have been willing to put money
that CDs are way more popular than DVDs...

Good thing I didn't! :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From rhally at mindspring.com  Tue Mar 21 05:01:30 2006
From: rhally at mindspring.com (Richard Hally)
Date: Tue, 21 Mar 2006 00:01:30 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321043547.GA15330@devserv.devel.redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<1142889303.3604.10.camel@T7.Linux>	<1142913886.5442.18.camel@localhost>	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
Message-ID: <441F88AA.20509@mindspring.com>

Bill Nottingham wrote:
> Dave Jones (davej at redhat.com) said: 
>> I'm not claiming to be representative of the majority of Fedora users,
>> but given there are a lot of Fedora users less fortunate than myself,
>> I believe that discontinuing CD iso's would severely impact a huge portion
>> of our userbase.  It'd be interesting to see the download stats to see
>> if they agree with this.
> 
> DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
> and 6:1 on ppc.
> 
> Bill
> 
Hi Bill,
	How or where did you get those number?

Thanks.



From mharris at mharris.ca  Tue Mar 21 05:00:18 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Tue, 21 Mar 2006 00:00:18 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142913886.5442.18.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
Message-ID: <441F8862.1030903@mharris.ca>

Callum Lerwick wrote:
> On Mon, 2006-03-20 at 21:15 +0000, Paul F. Johnson wrote:
> 
>>A *much* reduced core size (5 CDs + rescue is getting a bit much)
> 
> 
> IMHO its getting time to just forget CDs. Put out DVD isos only. (At the
> very least, stop worrying about how many CDs core fills and worry about
> fitting on one DVDR...)
> 
> Especially with yum backed network installs becoming available. If you
> don't want to download and burn an entire DVD iso, just download a
> 10-50mb network install iso. This is what I do with debian on the rare
> occasion I install a system from scratch. Since I only install a system
> once every few years, its a huge waste to me to download and burn 5+
> disks that I'm only going to use once.
> 
> Someone on IRC was arguing that in many parts of the world, bandwidth is
> very expensive. I don't see how 5 CDs to download vs a DVD make a
> difference here. The real question is, how common are DVD burners, and
> most importantly, DVD readers in various parts of the world.

I had an IRC discussion with a nice fellow from Jakarta a number of
months back, who explained how expensive it was to be on the internet.
He had a 56k connection, which cost him the equivalent of $20 USD for
the month.

My first thought was probably quite similar to what many of you are
currently thinking:  "Um, well that's very close to what it costs in
the US for access too, so is not really more expensive."

Except for the fact that this person was a full time computer
programmer, and told me that his monthly salary was the equivalent
of $200 US dollars.  Think about that.  His monthly internet connection
cost him 1/10th of his entire income for the month, just to get a
crappy 56k connection which ties up the phoneline as long as it is
connected.  I don't know if there were per-minute telephone fees
on top of that or not.

For each employed person reading this, take 1/10th of your income.
Would you pay that much money to have a 56k phone line based internet
connection each month?  Even if you did do so, would you want to
download the entire DVD ISO image which takes anywhere from 2-3 weeks
to download?  All this through a phone line which gets very frequently
disconnected?

I told him perhaps he should just purchase Fedora Core on CD instead,
and indicated there were many places online which you could order CDs.
He said it would be about $10, which again is like 5% of his monthly
income.  And that's a twice a year cost.  He said that buying Fedora
CDs locally was more expensive for "free software" than buying bootleg
copies of Windows XP down the street for $2-5 a pop.

That's only one single city in one country in the world.  There are
a great many of places in the world in which costs similar or higher
to this exist, and downloading large images is very prohibitive.

Another consideration worth mentioning is the OLPC project.


> I suppose the thing to do is keep an eye on CD downloads vs DVD. Let the
> community decide.

Living in North America, and having the pleasure of owning a DVD burner,
and having a huge stack of blank media, and a high speed Internet
connection (cablemodem) which costs me a very small fraction of my
income each month - I, like many North Americans do prefer to download
the DVD ISO images, and have no personal interest in the CD ISO images.
If the CD ISOs were to be dropped completely, it would bear practically
no consequence to me, as I have no use for them at all personally.

However, not having CD ISOs available would create a huge barrier for
many people in the world who are much less fortunate than you or I, who
either do not have high speed Internet, or who simply can't afford it,
or like the fellow I spoke to from Jakarta - who spend a massive
portion of their monthly income just to have the priveledge of using
open source software, because they believe it is the right thing to do.

Open source software (free software if you prefer) should be accessible
to all people, regardless of what country they live in, or their
personal financial circumstances.  Wherever possible it should not only
be free as in liberty, but also be available free of cost, or as close
to free of cost as possible.

So, as long as Fedora can be provided via CD ISO images for a reasonable
manpower cost in doing the work necessary to allow it to continue to
be viable, then it _should_ continue to be available in this manner
IMHO.  I think there are some creative ideas to allow this to be viable
for quite some time, and it seems that the Fedora Project is heading
in the right direction WRT this.

There is no really easy way to gauge how many people download the
CD images versus the DVD images, and equally no easy way to gauge
how many people install the OS from either based off how many
downloads there were.  Add bittorrent to the mix, and various other
download methods, other peer-to-peer networks, etc. and it's just
not possible to gauge.  It is quite clear to me however, that there
is a very significant number of people using CD based installs still,
and as long as that is evident enough in the community, I would be
quite surprised to see us seriously entertain the idea of dropping
CD based installation.  In fact, I would very strongly and vocally
oppose such an idea.



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From notting at redhat.com  Tue Mar 21 05:02:03 2006
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 21 Mar 2006 00:02:03 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F88AA.20509@mindspring.com>
References: <20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
	<441F88AA.20509@mindspring.com>
Message-ID: <20060321050203.GB15330@devserv.devel.redhat.com>

Richard Hally (rhally at mindspring.com) said: 
> Bill Nottingham wrote:
> >Dave Jones (davej at redhat.com) said: 
> >>I'm not claiming to be representative of the majority of Fedora users,
> >>but given there are a lot of Fedora users less fortunate than myself,
> >>I believe that discontinuing CD iso's would severely impact a huge portion
> >>of our userbase.  It'd be interesting to see the download stats to see
> >>if they agree with this.
> >
> >DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
> >and 6:1 on ppc.
> >
> >Bill
> >
> Hi Bill,
> 	How or where did you get those number?

http://torrent.fedoraproject.org:6969/

Bill



From kevinverma at gmail.com  Tue Mar 21 05:06:07 2006
From: kevinverma at gmail.com (Kevin Verma)
Date: Tue, 21 Mar 2006 10:36:07 +0530
Subject: Re-view FC5 hardware requirements for GNOME
In-Reply-To: <f67c87220603190605k2f095f8kbb3e3cc320b22bcd@mail.gmail.com>
References: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>
	<f67c87220603190605k2f095f8kbb3e3cc320b22bcd@mail.gmail.com>
Message-ID: <baf307070603202106p7dcb21ffu4da9e37e7edb2505@mail.gmail.com>

I've just been reading the final release notes of FC5 and the hardware
requirements seems reasonable enough, cheers folks.

Bela,
> I am not sure that using the terms developed and developing countries
> in the context of Fedora is very healthy even if the mentioned
> requirements are valid. Those are just requirements of _people_ or
> certain interest groups and that is a proper distinction in contrast
> with economical, geographical, racial...

You have a valid point that I guess I'll try to take care about but if
you can please kindly keep the racism out of our decent community,
cheers



From rc040203 at freenet.de  Tue Mar 21 05:07:28 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 21 Mar 2006 06:07:28 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321043938.GD28237@redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
	<20060321043938.GD28237@redhat.com>
Message-ID: <1142917649.26492.102.camel@mccallum.corsepiu.local>

On Mon, 2006-03-20 at 23:39 -0500, Dave Jones wrote:
> On Mon, Mar 20, 2006 at 11:35:47PM -0500, Bill Nottingham wrote:
>  > Dave Jones (davej at redhat.com) said: 
>  > > I'm not claiming to be representative of the majority of Fedora users,
>  > > but given there are a lot of Fedora users less fortunate than myself,
>  > > I believe that discontinuing CD iso's would severely impact a huge portion
>  > > of our userbase.  It'd be interesting to see the download stats to see
>  > > if they agree with this.
>  > 
>  > DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
>  > and 6:1 on ppc.

Don't trust any statistics you didn't forge yourself ;)

What did you count? Successful complete downloads or accesses?

The DVD image is the first a recursive download would access, so if you
counted accesses you'd erroniously count retries (which are likely to
happen due to the size of the image).

> I guess I should stop living in the past and get some DVD writables ;)
Don't forget about people with 
* low bandwidth/limited download contingents. To many of them, DVD
images aren't a real alternative, because downloading them would block
internet-access for a considerable amount of time.
* machines without DVD-ROMs still require CDs.

Ralf




From kevinverma at gmail.com  Tue Mar 21 05:08:44 2006
From: kevinverma at gmail.com (Kevin Verma)
Date: Tue, 21 Mar 2006 10:38:44 +0530
Subject: Re-view FC5 hardware requirements for GNOME
In-Reply-To: <baf307070603202106p7dcb21ffu4da9e37e7edb2505@mail.gmail.com>
References: <baf307070603181158r4a3e477dra593288d0d105916@mail.gmail.com>
	<f67c87220603190605k2f095f8kbb3e3cc320b22bcd@mail.gmail.com>
	<baf307070603202106p7dcb21ffu4da9e37e7edb2505@mail.gmail.com>
Message-ID: <baf307070603202108s7b8a3ce0t8f5830edd3c0b3e3@mail.gmail.com>

Oh by the way if some one can please hit me with light, for what did
serial mouse did wrong ?

On 3/21/06, Kevin Verma <kevinverma at gmail.com> wrote:
> I've just been reading the final release notes of FC5 and the hardware
> requirements seems reasonable enough, cheers folks.
>
> Bela,
> > I am not sure that using the terms developed and developing countries
> > in the context of Fedora is very healthy even if the mentioned
> > requirements are valid. Those are just requirements of _people_ or
> > certain interest groups and that is a proper distinction in contrast
> > with economical, geographical, racial...
>
> You have a valid point that I guess I'll try to take care about but if
> you can please kindly keep the racism out of our decent community,
> cheers
>



From mharris at mharris.ca  Tue Mar 21 05:10:19 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Tue, 21 Mar 2006 00:10:19 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142914115.5442.19.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux> <441F2CBC.9060204@mharris.ca>
	<1142897263.3604.33.camel@T7.Linux> <441F5591.3090205@mharris.ca>
	<1142914115.5442.19.camel@localhost>
Message-ID: <441F8ABB.50703@mharris.ca>

Callum Lerwick wrote:
> On Mon, 2006-03-20 at 20:23 -0500, Mike A. Harris wrote:
> 
>>Personally, I think it would be confusing as hell to have a single
>>src.rpm generate binary rpms of which some are in Fedora Core and
>>others are in Fedora Extras.  That would be made more confusing
>>since Fedora has separate bugzilla product/etc. for Core and for
>>Extras (and for Legacy).  Since bugzilla components themselves are
>>based from the name of the src.rpm, one would have to file a bug
>>report from a binary package from extras against Fedora Core for the
>>src.rpm it was built from.
>>
>>I can think of other complications and confusion that would ensue
>>as well.  I'm not sure what to suggest to solve those issues however.
> 
> Less separation between core and extras. Like maybe none. (cough Debian
> cough)

Hmm, that's actually an interesting point.  ;o)  Perhaps in the
future we could move away from the current model of repository
level separation, to a more responsibility oriented level of
separation or somesuch.  In other words, there are reasons why
things are the way they are now, which led to the solution of
having Core and Extras seprate.  However, that doesn't mean it
is the only way for us to achieve whatever goals are needed.

Perhaps the separation could be rethought out.  I guess the first
step would be to clearly define what the specific reasons are for
Fedora Core being separate from Extras right now.  If we can
define those reasons completely and clearly, they could be
"MUST-HAVE" features used as a basis for a new concept of
putting things together perhaps..

Just open brainstorming...  ;o)

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From seg at haxxed.com  Tue Mar 21 05:29:20 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Mar 2006 23:29:20 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321041157.GA28237@redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
Message-ID: <1142918960.5442.31.camel@localhost>

On Mon, 2006-03-20 at 23:11 -0500, Dave Jones wrote:
> DVD writers aren't anywhere near as commonplace as CD writers yet.
> Looking around right now, I have 7 computers near me. CD writers outnumber
> DVD writers 6:1.  (And the majority of the computers with CD writers are
> less than 2 years old (two of them are <6 months old))
> 
> (ironically, the dvd writer is my 3 month old laptop)

Yeah, but you own at least one, and that's the point. Extend this to
"friends with DVD writers". How many people don't have one?

Was Red Hat *ever* available on floppies? Yet we all still used it long
before CD writers became common... (Although RH was being sold for
profit on CD at the time...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060320/de9e4667/attachment.sig>

From mharris at mharris.ca  Tue Mar 21 05:25:52 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Tue, 21 Mar 2006 00:25:52 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142914789.26492.67.camel@mccallum.corsepiu.local>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net> <441F21B1.5090902@mharris.ca>
	<dvndou$llf$1@sea.gmane.org> <441F4C3D.6040605@mharris.ca>
	<1142914789.26492.67.camel@mccallum.corsepiu.local>
Message-ID: <441F8E60.6090706@mharris.ca>

Ralf Corsepius wrote:
> On Mon, 2006-03-20 at 19:43 -0500, Mike A. Harris wrote:
>>Whenever I do need/want 3D enabled support for something in Linux,
>>I fire up another machine and use it instead, leaving my primary
>>desktop in a stable DRI-disabled state.
>>
>>To answer the "when do I want decent 3D performance" question,
>>I must first answer "When do I want accelerated 3D at all?".
> 
>>So, what do I use OpenGL for?  More or less for video games,
> 
> You are ignoring the fact, Linux has a strong user base in people with a
> scientific/engineering/technical background ...

No, I'm not ignoring any facts at all.  My email clearly stated what
_I_ am using, and why, for my _own_ reasons.  I also clearly stated
that other people's situations are likely very different, and that
different people have different needs.  People with a scientific/
engineering/technical background are no exception.  _EVERY_ person's
needs is likely to be different in some way from the next guy.

My comments were not intended to recommend to people they should do what
_I_ decide have decided to do for me.  I clearly stated that also.

I was merely answering the question asked, which was "what do _I_
use OpenGL for".  And yes, I am a scientific/engineering/technical
person.


>>Now...  if I _was_ actually trying to get a game or some other
>>accelerated OpenGL software to work in Linux, I would use
>>whatever the best card I have on hand with OSS driver support
>>was at the given point in time. 
> 
> Whether you like it or not ... reality is different.

The email was about _MY_ chosen reality, not about your reality.
You can not change my own reality, nor my personal requirements or
preferences.  As stated, other people have different needs and
requirements which may be very different from what my own needs
and requirements are.  I did not in any way imply that everyone
should do what _I_ decide to do.  Don't put words in my mouth, or
read more into what I am saying, than what I am actually saying.


> People are pragmatically using what they have/can get/are supplied with,
> and will ditch the distro or even the OS if it doesn't suite to their
> demands.

Yes, some people will indeed do that.  As I said, everyone has their
own individual perogatives.  Mine is different from yours, and yours
is different from the next guy.  There are likely to be "groups" of
people in the same boat, other groups of people in boat #2, boat #3,
and even likely to be overlaps between some of the different boats,
but in no way whatsoever is there a one-size-fits-all solution for
everyone.

I myself have not ditched the distro or even the OS.  I do however
utilize "that other OS" when I feel the need to do so, because Linux
currently does not suit my personal demands.


> Fortunately for Fedora, the proprietary drivers have worked
> sufficiently well.

That's not even completely true.  It depends on which proprietary driver
it is you are talking about, what specific hardware you have, what
type of displays you have attached, and what the support is like for
your specific desired configuration, what driver features you need/want,
and wether they're supported or not.  The proprietary drivers work well
for some people, and other people can't get them to work at all.
Sometimes they can't get them to work due to their own incompetence, or
simple human error in not following instructions.  Other times it is due
to incompatibilities between the proprietary software and the specific
kernel they're using, specific X server they're using, or the particular
motherboard they have, the BIOS they have, or some other combination
of factors.  I can completely guarantee that there is a whole host of
people out there who have had nothing but endless problems with
proprietary drivers out there from _any_ vendor, many of whom have
sworn to never use proprietary drivers again.  I know, I get to hear
about it all week long every week.

As I said before, there is no one-size-fits-all solution.  Some people
simply refuse to use proprietary Linux drivers for ideological reasons,
or on some other principle.  Others may have tried to use them and been
unable to get them to work, or found their specific hardware isn't
supported.

To each his own.


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From mharris at mharris.ca  Tue Mar 21 05:29:21 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Tue, 21 Mar 2006 00:29:21 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142915278.26492.75.camel@mccallum.corsepiu.local>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux> <441F2CBC.9060204@mharris.ca>
	<1142915278.26492.75.camel@mccallum.corsepiu.local>
Message-ID: <441F8F31.3040506@mharris.ca>

Ralf Corsepius wrote:
> On Mon, 2006-03-20 at 17:29 -0500, Mike A. Harris wrote:
> 
>>Paul F. Johnson wrote:
>>
>>>Hi,
>>>
>>>
>>>
>>>>But let's get a clear roadmap down this time, what features are
>>>>essential for the next cycle?
>>>
>>>
>>>A *much* reduced core size (5 CDs + rescue is getting a bit much) and
>>>large reduction in the overall memory overhead. I know FC is fantastic,
>>>but given you need 128Mb for a text only version and 512Mb for a desktop
>>>environment, it's becoming hard to justify to the powers that be that
>>>using Linux over WinXP is that good an option.
>>
>>Are you implying that the only reason one would choose Linux over
>>Windows XP, is because it has lower memory and system requirements?
> 
> No, not "the only reason", but one essential reason:
> 
> Linux's small memory footprint and it's free licensing had enabled
> people to use Linux on "recycled HW".

Absolutely.  A fraction of the entire userbase out there does indeed
choose linux due to it having generally lower hardware requirements than
other OS choices within their consideration.

And to various other users, hardware requirements are meaningless,
they choose their OS based on other factors, such as specific features
unique to the OS, or for ideolological reasons, or lower TCO, or any
of a number of other factors.

Generally lower hardware requirements is not on every single person's
radar when choosing an OS.  If everyone valued lower hardware
requirements higher than anything else, nobody out there would
be running any Microsoft product for years now.



-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From david at lovesunix.net  Tue Mar 21 05:34:14 2006
From: david at lovesunix.net (David Nielsen)
Date: Tue, 21 Mar 2006 06:34:14 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F8862.1030903@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost> <441F8862.1030903@mharris.ca>
Message-ID: <1142919254.23128.29.camel@price.stavtrup-st.dk>

tir, 21 03 2006 kl. 00:00 -0500, skrev Mike A. Harris:

> I told him perhaps he should just purchase Fedora Core on CD instead,
> and indicated there were many places online which you could order CDs.
> He said it would be about $10, which again is like 5% of his monthly
> income.  And that's a twice a year cost.  He said that buying Fedora
> CDs locally was more expensive for "free software" than buying bootleg
> copies of Windows XP down the street for $2-5 a pop.

Please note that in the spirit of the community and all that, a lot of
us "wealthy" westerners do spend a considerable amount of money shipping
totally free copies of Fedora around the world. If he or anyone wants a
copy but cannot download it, #fedora on irc.freenode.net is a good place
to find friendly people to help and every Linux forum I've ever been to
has had a sticky thread offering free copies of Linux mailed anywhere in
the world.

Getting Linux is not a problem if you utilise the community. It's one of
the reasons Linux is such a great thing to be part of.

- David



From i.pilcher at comcast.net  Tue Mar 21 05:33:31 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Mon, 20 Mar 2006 23:33:31 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321043938.GD28237@redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<1142889303.3604.10.camel@T7.Linux>	<1142913886.5442.18.camel@localhost>	<20060321041157.GA28237@redhat.com>	<20060321043547.GA15330@devserv.devel.redhat.com>
	<20060321043938.GD28237@redhat.com>
Message-ID: <dvo37d$fbv$1@sea.gmane.org>

Dave Jones wrote:
> I guess I should stop living in the past and get some DVD writables ;)

Or forget about burning discs altogether.  Assuming that one is
upgrading (or parallel installing) a system that already has Linux
installed, there's no need.

I suppose that the one requirement that some people may not have is a
spare partition that can hold the ISO for a hard disk install.

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From seg at haxxed.com  Tue Mar 21 05:42:09 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Mar 2006 23:42:09 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F8ABB.50703@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux> <441F2CBC.9060204@mharris.ca>
	<1142897263.3604.33.camel@T7.Linux> <441F5591.3090205@mharris.ca>
	<1142914115.5442.19.camel@localhost>  <441F8ABB.50703@mharris.ca>
Message-ID: <1142919729.5442.41.camel@localhost>

On Tue, 2006-03-21 at 00:10 -0500, Mike A. Harris wrote:
> > Less separation between core and extras. Like maybe none. (cough Debian
> > cough)
> 
> Hmm, that's actually an interesting point.  ;o)  Perhaps in the
> future we could move away from the current model of repository
> level separation, to a more responsibility oriented level of
> separation or somesuch.  In other words, there are reasons why
> things are the way they are now, which led to the solution of
> having Core and Extras seprate.  However, that doesn't mean it
> is the only way for us to achieve whatever goals are needed.
> 
> Perhaps the separation could be rethought out.  I guess the first
> step would be to clearly define what the specific reasons are for
> Fedora Core being separate from Extras right now.  If we can
> define those reasons completely and clearly, they could be
> "MUST-HAVE" features used as a basis for a new concept of
> putting things together perhaps..

Well, what makes Fedora different is its a fast moving, cutting edge
distribution. Fedora is more than happy to make drastic changes in a
short amount of time, stomping over numerous core packages. This is what
makes it different. (especially from Debian...)

Perhaps the core/extras separation is the price we pay to accomplish
this development style. Perhaps eliminating the separation will just
turn Fedora into slow moving Debian.

Or maybe it won't. I really don't know.

> Just open brainstorming...  ;o)

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

From mharris at mharris.ca  Tue Mar 21 05:39:12 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Tue, 21 Mar 2006 00:39:12 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142919254.23128.29.camel@price.stavtrup-st.dk>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost> <441F8862.1030903@mharris.ca>
	<1142919254.23128.29.camel@price.stavtrup-st.dk>
Message-ID: <441F9180.6020709@mharris.ca>

David Nielsen wrote:
> tir, 21 03 2006 kl. 00:00 -0500, skrev Mike A. Harris:
> 
> 
>>I told him perhaps he should just purchase Fedora Core on CD instead,
>>and indicated there were many places online which you could order CDs.
>>He said it would be about $10, which again is like 5% of his monthly
>>income.  And that's a twice a year cost.  He said that buying Fedora
>>CDs locally was more expensive for "free software" than buying bootleg
>>copies of Windows XP down the street for $2-5 a pop.
> 
> 
> Please note that in the spirit of the community and all that, a lot of
> us "wealthy" westerners do spend a considerable amount of money shipping
> totally free copies of Fedora around the world. If he or anyone wants a
> copy but cannot download it, #fedora on irc.freenode.net is a good place
> to find friendly people to help and every Linux forum I've ever been to
> has had a sticky thread offering free copies of Linux mailed anywhere in
> the world.
> 
> Getting Linux is not a problem if you utilise the community. It's one of
> the reasons Linux is such a great thing to be part of.

That's a wonderful idea!  I never even thought of that.  The cost of one
of us Westerners shipping a CD/DVD anywhere in the world is probably
about the same cost or close to it of someone buying it online give or
take a few bucks, but the bigger difference is that to me or you it is
the price of a few cups of coffee, whereas it's like making a car or
house payment to people in some parts of the world.

<brainstorming>
Perhaps a http://www.fedora-for-free.org or
http://www.fedora-philanthropy.org could be set up, in which people in
various parts of the world who can't afford to buy CD/DVDs or to easily
download them to go to get them sent to them for free, and other people
such as ourselves could contribute a few bucks each release to fund the
distribution.
</brainstorming>

Just an idea.

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From i.pilcher at comcast.net  Tue Mar 21 05:37:51 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Mon, 20 Mar 2006 23:37:51 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142914789.26492.67.camel@mccallum.corsepiu.local>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>
	<441F21B1.5090902@mharris.ca>	<dvndou$llf$1@sea.gmane.org>
	<441F4C3D.6040605@mharris.ca>
	<1142914789.26492.67.camel@mccallum.corsepiu.local>
Message-ID: <dvo3ff$fbv$2@sea.gmane.org>

Ralf Corsepius wrote:
> People are pragmatically using what they have/can get/are supplied with,
> and will ditch the distro or even the OS if it doesn't suite to their
> demands. Fortunately for Fedora, the proprietary drivers have worked
> sufficiently well.

I have this gnawing feeling that ATI and nVIDIA are the twin rocks on
which desktop Linux is going to founder.

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From seg at haxxed.com  Tue Mar 21 05:55:11 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 20 Mar 2006 23:55:11 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F8862.1030903@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost> <441F8862.1030903@mharris.ca>
Message-ID: <1142920511.5442.51.camel@localhost>

On Tue, 2006-03-21 at 00:00 -0500, Mike A. Harris wrote:
> I had an IRC discussion with a nice fellow from Jakarta a number of
> months back, who explained how expensive it was to be on the internet.
> He had a 56k connection, which cost him the equivalent of $20 USD for
> the month.
> 
> My first thought was probably quite similar to what many of you are
> currently thinking:  "Um, well that's very close to what it costs in
> the US for access too, so is not really more expensive."
> 
> Except for the fact that this person was a full time computer
> programmer, and told me that his monthly salary was the equivalent
> of $200 US dollars.  Think about that.  His monthly internet connection
> cost him 1/10th of his entire income for the month, just to get a
> crappy 56k connection which ties up the phoneline as long as it is
> connected.  I don't know if there were per-minute telephone fees
> on top of that or not.
> 
> For each employed person reading this, take 1/10th of your income.
> Would you pay that much money to have a 56k phone line based internet
> connection each month?  Even if you did do so, would you want to
> download the entire DVD ISO image which takes anywhere from 2-3 weeks
> to download?  All this through a phone line which gets very frequently
> disconnected?

Its roughly the same amount of data to download a DVD vs 5 CDs. I fail
to see how the "bandwidth is expensive" argument applies.

Download cost is meaningless in the CDs vs DVDs argument. Its the same.

The question is, what does one do with the images once downloaded.

> I told him perhaps he should just purchase Fedora Core on CD instead,
> and indicated there were many places online which you could order CDs.
> He said it would be about $10, which again is like 5% of his monthly
> income.  And that's a twice a year cost.  He said that buying Fedora
> CDs locally was more expensive for "free software" than buying bootleg
> copies of Windows XP down the street for $2-5 a pop.

This is all a great example of what even a poor broke college student
like me takes for granted in the US, and is completely missing the
really useful bits of information:

1) So how *does* this person get Fedora, and keep it updated? Do they
download it at 56k? Do they buy CDs? What?

2) Do they have a DVD reader?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060320/f277f014/attachment.sig>

From seg at haxxed.com  Tue Mar 21 07:40:19 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 21 Mar 2006 01:40:19 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <dvo3ff$fbv$2@sea.gmane.org>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net> <441F21B1.5090902@mharris.ca>
	<dvndou$llf$1@sea.gmane.org> <441F4C3D.6040605@mharris.ca>
	<1142914789.26492.67.camel@mccallum.corsepiu.local>
	<dvo3ff$fbv$2@sea.gmane.org>
Message-ID: <1142926819.5442.67.camel@localhost>

On Mon, 2006-03-20 at 23:37 -0600, Ian Pilcher wrote:
> I have this gnawing feeling that ATI and nVIDIA are the twin rocks on
> which desktop Linux is going to founder.

We're back in the early days of XFree86 all over again.

It'll get better.

So when is someone going to start reverse engineering nVidia hardware?
There's support in Utah-GLX that no one's yet bothered to port over to
DRI, and some guy has written drivers for BeOS, though I've been unable
to find the actual source for the driver. Just an unmodified copy of
Mesa...

http://dri.freedesktop.org/wiki/nVidia?action=highlight&value=CategoryHardware
http://www.haikunews.org/1050
http://web.inter.nl.net/users/be-hold/BeOS/NVdriver/download.html

It seems having well maintained binary drivers is a great deterrent to
the community reverse engineering its own. ATI hardware is actively
being reverse engineered, the Aureal Vortex cards got reverse
engineered, Broadcom and TI ACX1xx wireless has been reverse engineered.
But no nVidia support is being maintained that I know of...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/fa832380/attachment.sig>

From nman64 at n-man.com  Tue Mar 21 07:56:36 2006
From: nman64 at n-man.com (Patrick Barnes)
Date: Tue, 21 Mar 2006 01:56:36 -0600
Subject: The Morning After
Message-ID: <200603210156.40386.nman64@n-man.com>

To start off, congratulations are in order for everyone who was involved in 
bringing Fedora Core 5 to fruition.  Fedora Core 5 is the most outstanding 
Fedora Core release to date, and we've seen a lot of progress since Fedora 
Core 4.  Thank you and congratulations to everyone!

Overall, I think the Fedora Core 5 release was a great success.  We had a few 
minor glitches, as will always happen on release day, but things really came 
together to deliver this awesome release in an awesome way.

While the excitement is still strong, let's look back over the events leading 
up to and immediately following the release, and see what we can do to make 
things better both for the lifetime of this release and for future releases.

Over the weekend, we saw quite a few leaked ISOs flying around.  This is to be 
expected, but we need to try to minimize this to avoid potential problems.  
We also saw a large number of users take advantage of BitTorrent, which 
greatly reduced demand on the main servers, but, as always, people are always 
looking for more bandwidth.  We've got plans in the works that will help, but 
there's always room for more improvement.  It is great that there is so much 
interest, so how can we best support that interest without failing our 
release goals?

A lot of switches and buttons had to be operated manually for this release.  
We could almost certainly add automation and scheduling, and we could 
streamline processes to make life easier on ourselves.

We had to update a lot of information on both fedora.redhat.com and 
fedoraproject.org.  We have some unnecessary duplication, and there are 
places where we can get things working a little more smoothly.  Jesse, and 
anyone else working on these things, what did you notice?  How can we improve 
the process?

It took a fair chunk of the day to get the latest release notes up on the 
website and working properly.  Surely, we can automate some of this.  I know 
a lot of work is going into getting the build tools working better, but what 
else can we do to simplify this for a prompt release reaction?

There were a few other technical errors or delays, such as those that prompted 
symlinking torrent URLs and the update to the release announcement, the lack 
of the planned instructions for CD-burning in the distribution directories, 
and a few known flaws in the final release.  These kinds of things are bound 
to happen, especially when internal issues arise just before the release, but 
that's no reason to ignore them.  What did we miss, and how can we make sure 
we get it right next time?

Finally, there has been a lot of buzz leading up to and following the release.  
We saw a refreshing surge even before the release hit.  That's great, but the 
buzz could still be bigger.  We saw a few reviews of the test releases, and 
many sites have published new information in the last 24 hours, but how can 
we generate more of this?  Did anybody notice particular areas that were 
undersold?

Now is the time for radical thoughts and ideas that can shape what we do to 
support Fedora Core 5 and prepare for Fedora Core 6.  Let's hear them!

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

http://www.n-man.com/

Have I been helpful?  Rate my assistance!
http://rate.affero.net/nman64/
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/99c77d1e/attachment.sig>

From nman64 at n-man.com  Tue Mar 21 08:03:43 2006
From: nman64 at n-man.com (Patrick Barnes)
Date: Tue, 21 Mar 2006 02:03:43 -0600
Subject: Wild and crazy times for the development tree
In-Reply-To: <441F9180.6020709@mharris.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<1142919254.23128.29.camel@price.stavtrup-st.dk>
	<441F9180.6020709@mharris.ca>
Message-ID: <200603210203.45532.nman64@n-man.com>

On Monday 20 March 2006 23:39, "Mike A. Harris" <mharris at mharris.ca> wrote:
> David Nielsen wrote:
> > tir, 21 03 2006 kl. 00:00 -0500, skrev Mike A. Harris:
> >>I told him perhaps he should just purchase Fedora Core on CD instead,
> >>and indicated there were many places online which you could order CDs.
> >>He said it would be about $10, which again is like 5% of his monthly
> >>income.  And that's a twice a year cost.  He said that buying Fedora
> >>CDs locally was more expensive for "free software" than buying bootleg
> >>copies of Windows XP down the street for $2-5 a pop.
> >
> > Please note that in the spirit of the community and all that, a lot of
> > us "wealthy" westerners do spend a considerable amount of money shipping
> > totally free copies of Fedora around the world. If he or anyone wants a
> > copy but cannot download it, #fedora on irc.freenode.net is a good place
> > to find friendly people to help and every Linux forum I've ever been to
> > has had a sticky thread offering free copies of Linux mailed anywhere in
> > the world.
> >
> > Getting Linux is not a problem if you utilise the community. It's one of
> > the reasons Linux is such a great thing to be part of.
>
> That's a wonderful idea!  I never even thought of that.  The cost of one
> of us Westerners shipping a CD/DVD anywhere in the world is probably
> about the same cost or close to it of someone buying it online give or
> take a few bucks, but the bigger difference is that to me or you it is
> the price of a few cups of coffee, whereas it's like making a car or
> house payment to people in some parts of the world.
>
> <brainstorming>
> Perhaps a http://www.fedora-for-free.org or
> http://www.fedora-philanthropy.org could be set up, in which people in
> various parts of the world who can't afford to buy CD/DVDs or to easily
> download them to go to get them sent to them for free, and other people
> such as ourselves could contribute a few bucks each release to fund the
> distribution.
> </brainstorming>
>
> Just an idea.
>

http://fedoraproject.org/wiki/FreeMedia

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

http://www.n-man.com/

Have I been helpful?  Rate my assistance!
http://rate.affero.net/nman64/
-- 

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

From i at stingr.net  Tue Mar 21 08:05:58 2006
From: i at stingr.net (Paul P Komkoff Jr)
Date: Tue, 21 Mar 2006 11:05:58 +0300
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320180853.2939eeac@soran.addix.net>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
Message-ID: <20060321080558.GX1339@stingr.net>

Replying to Ralf Ertzinger:
> Hi.
> 
> On Mon, 20 Mar 2006 11:59:57 -0500, Jeremy Katz wrote:
> 
> > to grab the fedora-release package from the FC5 release instead.  If
> > you want to keep testing and helping to develop things for Fedora
> > Core 6, expect for some fun to pop up as always.
> 
> Sooo... what are we going to break first?

I vote for init.

-- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
 This message represents the official view of the voices in my head



From david at lovesunix.net  Tue Mar 21 08:14:56 2006
From: david at lovesunix.net (David Nielsen)
Date: Tue, 21 Mar 2006 09:14:56 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320212856.GA10685@jadzia.bu.edu>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<20060320212856.GA10685@jadzia.bu.edu>
Message-ID: <1142928897.23128.75.camel@price.stavtrup-st.dk>

man, 20 03 2006 kl. 16:28 -0500, skrev Matthew Miller:
> On Mon, Mar 20, 2006 at 09:40:10PM +0100, David Nielsen wrote:
> > I tend to agree, the 9 month cycle worked wonderfully, Fedora Core 5 is
> > by far the best release the Fedora Project has put out yet and as a
> > tester I enjoyed having that extra time to see new fundamental changes
> > take place and get bugs tracked down.
> 
> I was intrigued by your blog suggestion of alternating 9 month devel / 4
> month stabilization cycles. <tp://lovesunix.net/blog/?p=62> But I also think
> your own objection (people will not take the 9-month release seriously
> enough) is pretty strong.
> 
> As someone crazy enough to try to use Fedora for real work, the 9 month
> cycle is awesome.

I'd wager that the technology preview releases would actually get a fair
bit of attention if we continued the current agenda where large parts of
software is backported to the stable releases.

To sum up the point, we'd have 6 months of development time followed by
3 months of API stable bugfixing and updating (e.g. like what was done
with GNOME 2.14 in FC5) then we release that as the technology preview
Fedora, it would be considered stable. Then we follow that up with a 4
month API stable polish cycle.

Pros and cons of such an out of balance approach to releasing are many
but when I thought it up I had just had a lenghty conversation with one
of the FC developers who was telling me that with the 9 month cycle he
was fighting fatigue and burnout. It struck me as a user that the 9
month cycle was completely awesome but for developers it might be hard -
thus the need for faster paced releases and periods of light pressure.

We can all agree that major surgery like replacing the Init system,
reworking the installer, switching to modular X, switching GCC versions,
etc. requires more time than a 6 month cycle would allow for in terms of
testing (implementation I'm sure could be done in the 6 month cycle but
would it be well tested?). So we will need more cycles of this length,
depending on the amount of surgery that is planned in the near future. 

We also need to consider that Red Hat needs to make money, they do this
selling RHEL and services related to that product, this means they need
a stable product to base their work off. The polish cycle would, I hope,
serve well as a platform for this kind of work. I'm all for making Red
Hat' life easier, they kindly sponsor a lot of Fedora development that I
get with no strings attached - the least I can do for them is help
hammer Fedora as best I can.

I truly think that the 9/4 cycle could work well for us provided we
could build up an active testing community, it all depends on appealing
to people with QA experience or the will to learn these skills. If we
fail to do this having a polish cycle will not result in a massively
better product in the end - but then again if we don't have proper
testing of any cycle, Fedora will be shit regardless.

Is it time for me to lay down the crackpipe?

- David



From buildsys at redhat.com  Tue Mar 21 08:18:01 2006
From: buildsys at redhat.com (Build System)
Date: Tue, 21 Mar 2006 03:18:01 -0500
Subject: rawhide report: 20060321 changes
Message-ID: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>

 

 
Updated Packages:

ORBit-1:0.5.17-16
-----------------
* Mon Mar 20 2006 Matthias Clasen <mclasen at redhat.com> - 1:0.5.17-16
- Fix source URL
- Don't ship static libraries

SysVinit-2.86-3
---------------
* Fri Mar 17 2006 Bill Nottingham <notting at redhat.com> - 2.86-3
- document that the kernel may sync even if reboot is called with -n (#180967)

anthy-7500-1
------------
* Fri Mar 17 2006 Akira TAGOH <tagoh at redhat.com> 7500-1
- New upstream release.
  - larning words works now. (#178764)
- anthy-2832.patch: patch from upstream that fixes wrong order of candidate list.
- anthy-2834.patch: patch from upstream that fixes unexpected word segment.
- anthy-gcanna-nakaguro.patch: added a word to dictionary to convert nakaguro to slash.

avahi-0.6.9-8.FC5
-----------------
* Mon Mar 20 2006 Jason Vas Dias <jvdias at redhat.com> - 0.6.9-8.FC6
- fix bug 185972: remove ellipses in initscript
- fix bug 185965: make chkconfigs unconditional

* Thu Mar 16 2006 Jason Vas Dias <jvdias at redhat.com> - 0.6.9-6
- Fix bug 185692: install avahi-sharp into /usr/lib, not /usr/lib64

* Thu Mar 09 2006 Jason Vas Dias <jvdias at redhat.com> - 0.6.9-4
- fix scriptlet error introduced by last fix: 
  if user has disabled avahi-daemon, do not enable it during %post

bind-30:9.3.2-10.FC6
--------------------
* Mon Mar 20 2006 Jason Vas Dias <jvdias at redhat.com> - 30.9.3.2-10
- fix bug 185969: more .spec file cleanup

* Wed Mar 08 2006 Jason Vas Dias <jvdias at redhat.com> - 30.9.3.2-8
- Do not allow package to be installed if named:25 userid creation fails
- Give libbind a pkg-config file
- remove restorecon from bind-chroot-admin (not required).
- fix named.caching-nameserver.conf (listen-on-v6 port 53 { ::1 };)

* Tue Mar 07 2006 Jason Vas Dias <jvdias at redhat.com> - 30:9.3.2-7
- fix issues with bind-chroot-admin

checkpolicy-1.30-1
------------------
* Fri Mar 17 2006 Dan Walsh <dwalsh at redhat.com> - 1.30-1
- Latest upgrade from NSA
	* Updated version for release.
	* Fixed bug in role dominance (define_role_dom).

* Fri Feb 17 2006 Dan Walsh <dwalsh at redhat.com> - 1.29.4-1
- Latest upgrade from NSA
	* Added a check for failure to declare each sensitivity in
	  a level definition.
	* Changed to clone level data for aliased sensitivities to
	  avoid double free upon sens_destroy.  Bug reported by Kevin
	  Carr of Tresys Technology.

* Mon Feb 13 2006 Dan Walsh <dwalsh at redhat.com> - 1.29.2-1
- Latest upgrade from NSA
	* Merged optionals in base patch from Joshua Brindle.

cups-1:1.2-0.1.b2.2
-------------------
* Fri Mar 17 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.1.b2.2
- Rebuilt.

* Tue Mar 14 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.1.b2.1
- Build requires gnutls-devel.
- Fixed default policy name.
- Fixed 'set-allowed-users' in web UI.

* Mon Mar 13 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.1.b2.0
- 1.2b2.
- Use new CUPS_SERVERBIN location (/usr/lib/cups even on 64-bit hosts).

db4-4.3.29-3
------------
* Mon Mar 13 2006 Jindrich Novy <jnovy at redhat.com> 4.3.29-3
- apply x86_64 fix from Henrik Nordstrom (#184588)
- don't nuke non-versioned archives twice

f-spot-0.1.11-1
---------------
* Fri Mar 17 2006 Christopher Aillon <caillon at redhat.com> 0.1.11-1
- Update to 0.1.11

fedora-release-5-rawhide
------------------------

file-4.17-2
-----------
* Tue Mar 14 2006 Radek Vok??l <rvokal at redhat.com> 4.17-2
- fix segfault when compiling magic
- add check for wctype.h
- fix for flac and mp3 files

* Mon Mar 13 2006 Radek Vok??l <rvokal at redhat.com> 4.17-1
- upgrade to file-4.17, patch clean-up

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 4.16-6.2
- bump again for double-long bug on ppc(64)

firstboot-1.4.7-1
-----------------
* Mon Mar 20 2006 Martin Stransky <stransky at redhat.com> 1.4.7-1
- replaced "Play test button" by "Play" button for s-c-s (#185931)

gsl-1.7-2
---------
* Fri Mar 03 2006 Ivana Varekova <varekova at redhat.com> - 1.7-2
- fix multilib problem

iproute-2.6.15-2
----------------
* Wed Feb 22 2006 Radek Vok??l <rvokal at redhat.com> - 2.6.15-2
- own /usr/lib/tc (#181953)
- obsoletes shapecfg (#182284)

ipv6calc-0.51-1
---------------
* Wed Feb 22 2006 Radek Vok??l <rvokal at redhat.com> 0.51-1
- upgrade to 0.51

kernel-2.6.15-1.2064_FC6
------------------------
* Sun Mar 19 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc6-git12
- Enable EFI on x86.

* Sat Mar 18 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc6-git10 & git11

* Fri Mar 17 2006 Dave Jones <davej at redhat.com>
- 2.6.16rc6-git8 & git9

lftp-3.4.3-1
------------
* Thu Mar 16 2006 Jason Vas Dias <jvdias at redhat.com> - 3.4.3-1
- Upgrade to upstream version 3.4.3

libgsf-1.14.0-1
---------------
* Mon Mar 20 2006 Caolan McNamara <caolanm at redhat.com> 1.14.0-1
- next version

libmng-1.0.9-4
--------------
* Mon Mar 20 2006 Matthias Clasen <mclasen at redhat.com> - 1.0.9-4
- enable lcms support (#184526)
- no longer build a libmng-static package

libselinux-1.30-1
-----------------
* Fri Mar 10 2006 Dan Walsh <dwalsh at redhat.com> 1.30-1
- Make some fixes so it will build on RHEL4
- Upgrade to latest from NSA
	* Updated version for release.
	* Altered rpm_execcon fallback logic for permissive mode to also
	  handle case where /selinux/enforce is not available.

libsemanage-1.6-1
-----------------
* Fri Mar 17 2006 Dan Walsh <dwalsh at redhat.com> - 1.6
- Make work on RHEL4
- Upgrade to latest from NSA
	* Merged abort early on merge errors patch from Ivan Gyurdiev.
	* Cleaned up error handling in semanage_split_fc based on a patch
	  by Serge Hallyn (IBM) and suggestions by Ivan Gyurdiev.
	* Merged MLS handling fixes from Ivan Gyurdiev.

libsepol-1.12.1-1
-----------------
* Fri Mar 10 2006 Dan Walsh <dwalsh at redhat.com> 1.12.1-1
- Upgrade to latest from NSA
	* Fixed sepol_module_package_write buffer overflow bug.

* Fri Mar 10 2006 Dan Walsh <dwalsh at redhat.com> 1.12-2
- Upgrade to latest from NSA
	* Updated version for release.
	* Merged cond_evaluate_expr fix from Serge Hallyn (IBM).
	* Fixed bug in copy_avrule_list reported by Ivan Gyurdiev.
	* Merged sepol_policydb_mls_enabled interface and error handling
	  changes from Ivan Gyurdiev.

libsetrans-0.1.20-1
-------------------
* Mon Mar 13 2006 Dan Walsh <dwalsh at redhat.com> 0.1.20-1
- Fix handling of untranslated sensitivities

* Mon Mar 13 2006 Dan Walsh <dwalsh at redhat.com> 0.1.19-1
- Fix segfault error on badly formated setrans file

libxkbfile-1.0.2-1
------------------
* Tue Feb 28 2006 Adam Jackson <ajackson at redhat.com> - 1.0.2-1
- Updated libxkbfile to version 1.0.2

man-1.6c-2
----------
* Mon Feb 27 2006 Ivana Varekova <varekova at redhat.com> - 1.6c-2
- fix the encoding of the Bulgarian translation

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 1.6c-1.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 1.6c-1.1
- rebuilt for new gcc4.1 snapshot and glibc changes

man-pages-2.25-2
----------------
* Thu Mar 16 2006 Ivana Varekova <varekova at redhat.com> 2.25-2
- fix MALLOC_CHECK_ description (#185502)

* Tue Mar 14 2006 Ivana Varekova <varekova at redhat.com> 2.25-1
- update to 2.25
- remove mbind and set_mempolicy files
- fix dbopen man page (#185310)

mc-1:4.6.1a-11
--------------
* Thu Mar 16 2006 Jindrich Novy <jnovy at redhat.com> 4.6.1a-11
- display the Layout dialog correctly on console (#185189)

mlocate-0.14-2
--------------
* Sat Mar 18 2006 Miloslav Trmac <mitr at redhat.com> - 0.14-2
- Ship NEWS

* Sat Mar 18 2006 Miloslav Trmac <mitr at redhat.com> - 0.14-1
- Update to mlocate-0.14

mrtg-2.13.2-1
-------------
* Sat Mar 18 2006 Miloslav Trmac <mitr at redhat.com> - 2.13.2-1
- Update to mrtg-2.13.2

nc-1.84-4
---------
* Mon Mar 06 2006 Radek Vok??l <rvokal at redhat.com> 1.84-4
- timeout works also for connect (#182736)

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 1.84-3.2
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 1.84-3.1
- rebuilt for new gcc4.1 snapshot and glibc changes

net-tools-1.60-64
-----------------
* Thu Mar 16 2006 Radek Vok??l <rvokal at redhat.com> - 1.60-54
- remove duplicate arp entries (#185604)

* Thu Feb 23 2006 Radek Vok??l <rvokal at redhat.com> - 1.60-63
- show inodes in netstat (#180974)

netpbm-10.32-1
--------------
* Tue Feb 28 2006 Jindrich Novy <jnovy at redhat.com> 10.32-1
- update to 10.32
- drop .msbmp patch, applied upstream
- sync the rest of the patches
- regenerate man pages

* Mon Feb 20 2006 Jindrich Novy <jnovy at redhat.com> 10.31-5
- add missing flex BuildRequires
- fix anytopnm to recognize ms-bmp files (#182060)

pam_krb5-2.2.7-1
----------------
* Tue Feb 21 2006 Nalin Dahyabhai <nalin at redhat.com> - 2.2.7-1
- add v4 credential conversion for "use_shmem" and "external" cases (though
  it should be redundant with "use_shmem") (#182239)

* Mon Feb 13 2006 Nalin Dahyabhai <nalin at redhat.com> - 2.2.6-2
- rebuild

* Mon Feb 06 2006 Nalin Dahyabhai <nalin at redhat.com> - 2.2.6-1
- add a "krb4_use_as_req" option so that obtaining v4 creds kinit-style can
  be disabled completely (Hugo Meiland)

perl-Archive-Tar-1.29-1
-----------------------
* Wed Mar 08 2006 Jason Vas Dias <jvdias at redhat.com> - 1.29-1
- Upgrade to upstream version 1.29

perl-Convert-ASN1-0.20-1
------------------------
* Thu Mar 09 2006 Jason Vas Dias <jvdias at redhat.com> - 1.20-1
- upgrade to upstream version 1.20-1

perl-DBD-Pg-1.45-1
------------------
* Wed Mar 08 2006 Jason Vas Dias <jvdias at redhat.com> - 1.45-1
- Upgrade to upstream version 1.45

perl-PDL-2.4.2-4.fc5
--------------------
* Fri Mar 10 2006 Jason Vas Dias <jvdias at redhat.com> - 2.4.2-4
- Further code cleanup & CFLAGS settings required to enable tests 
  to succeed on all platforms

* Thu Mar 09 2006 Jason Vas Dias <jvdias at redhat.com> - 2.4.2-4
- Enable tests to succeed on ia64 (remove casts from int to * !)

policycoreutils-1.30-4
----------------------
* Mon Mar 20 2006 Dan Walsh <dwalsh at redhat.com> 1.30-4
- Open file descriptor to make sure file does not change from underneath.

* Fri Mar 17 2006 Dan Walsh <dwalsh at redhat.com> 1.30-3
- Fixes for restorecond attack via symlinks
- Fixes for fixfiles

* Fri Mar 17 2006 Dan Walsh <dwalsh at redhat.com> 1.30-2
- Restorecon has to handle suspend/resume

samba-0:3.0.21c-2
-----------------
* Fri Mar 17 2006 Jay Fenlason <fenlason at redhat.com> 2.0.21c-2
- New upstream version.

scim-anthy-0.9.0-3.fc6
----------------------
* Fri Mar 17 2006 Akira TAGOH <tagoh at redhat.com> - 0.9.0-3.fc6
* scim-anthy-symbol-style.patch: applied a backport patch from upstream CVS to
  add an UI for the symbol style. (#178400)

selinux-policy-2.2.24-1
-----------------------
* Fri Mar 17 2006 Dan Walsh <dwalsh at redhat.com> 2.2.24-1
- Update to upstream

* Wed Mar 15 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-19
- Get transition rules to create policy.20 at SystemHigh

* Tue Mar 14 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-18
- Allow secadmin to shutdown system
- Allow sendmail to exec newalias

setarch-1.9-1
-------------
* Tue Feb 21 2006 Jindrich Novy <jnovy at redhat.com> 1.9-1
- applied some features proposed by Mike Frysinger (#182219)
- add mips arch support, add sparc32
- Obsoletes sparc32
- add '-h' option to display more comprehensive help
- add linux64 helper

stunnel-4.15-1
--------------
* Sat Mar 18 2006 Miloslav Trmac <mitr at redhat.com> - 4.15-1
- Update to stunnel-4.15

system-config-bind-4.0.0-40_FC5
-------------------------------
* Wed Mar 08 2006 Jason Vas Dias <jvdias at redhat.com> - 4.0.0-40
- fix bug 184065: prompts to place slave / DDNS updateable zone
                  files in slaves/ 
- ship updated translations

tcsh-6.14-7
-----------
* Sat Mar 18 2006 Miloslav Trmac <mitr at redhat.com> - 6.14-7
- Fix a crash when reading scripts with multibyte characters (#183267)
- Block SIGINT while waiting for children (#177366)

texinfo-4.8-10
--------------
* Sun Mar 19 2006 Miloslav Trmac <mitr at redhat.com> - 4.8-10
- Remove incorrect Prefix:
- Drop info/README
- Convert change log to UTF-8

xorg-x11-apps-1.0.2-1
---------------------
* Thu Mar 02 2006 Adam Jackson <ajackson at redhat.com> 1.0.2-1
- Bump x11perf to 1.4.1 from upstream.

xorg-x11-proto-devel-7.0-8
--------------------------
* Mon Mar 20 2006 Adam Jackson <ajackson at redhat.com> 7.0-8
- Fix the base URL.

* Wed Mar 15 2006 Adam Jackson <ajackson at redhat.com> 7.0-7
- Update to fixesproto-4.0, compositeproto-0.3, and glproto-1.4.6

xorg-x11-server-1.0.1-9
-----------------------
* Wed Mar 15 2006 Ray Strode <rstrode at redhat.com> - 1.0.1-9
- CVE-2006-0745 (bug 185084)

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gsf-sharp - 0.6-8.i386 requires libgsf-1.so.113
	gsf-sharp - 0.6-8.i386 requires libgsf-gnome-1.so.113
	librsvg2 - 2.14.2-1.i386 requires libgsf-1.so.113
	libwpd - 0.8.4-1.2.1.i386 requires libgsf-1.so.113
	libwpd-tools - 0.8.4-1.2.1.i386 requires libgsf-1.so.113



Broken deps for ia64
----------------------------------------------------------
	gsf-sharp - 0.6-8.ia64 requires libgsf-1.so.113()(64bit)
	gsf-sharp - 0.6-8.ia64 requires libgsf-gnome-1.so.113()(64bit)
	librsvg2 - 2.14.2-1.ia64 requires libgsf-1.so.113()(64bit)
	libwpd - 0.8.4-1.2.1.ia64 requires libgsf-1.so.113()(64bit)
	libwpd-tools - 0.8.4-1.2.1.ia64 requires libgsf-1.so.113()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	gsf-sharp - 0.6-8.ppc requires libgsf-1.so.113
	gsf-sharp - 0.6-8.ppc requires libgsf-gnome-1.so.113
	librsvg2 - 2.14.2-1.ppc requires libgsf-1.so.113
	libwpd - 0.8.4-1.2.1.ppc requires libgsf-1.so.113
	libwpd-tools - 0.8.4-1.2.1.ppc requires libgsf-1.so.113



Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	librsvg2 - 2.14.2-1.ppc64 requires libgsf-1.so.113()(64bit)
	libwpd - 0.8.4-1.2.1.ppc64 requires libgsf-1.so.113()(64bit)
	libwpd-tools - 0.8.4-1.2.1.ppc64 requires libgsf-1.so.113()(64bit)
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	gsf-sharp - 0.6-8.s390 requires libgsf-1.so.113
	gsf-sharp - 0.6-8.s390 requires libgsf-gnome-1.so.113
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	librsvg2 - 2.14.2-1.s390 requires libgsf-1.so.113
	libwpd - 0.8.4-1.2.1.s390 requires libgsf-1.so.113
	libwpd-tools - 0.8.4-1.2.1.s390 requires libgsf-1.so.113
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	gsf-sharp - 0.6-8.s390x requires libgsf-1.so.113()(64bit)
	gsf-sharp - 0.6-8.s390x requires libgsf-gnome-1.so.113()(64bit)
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	librsvg2 - 2.14.2-1.s390x requires libgsf-1.so.113()(64bit)
	libwpd - 0.8.4-1.2.1.s390x requires libgsf-1.so.113()(64bit)
	libwpd-tools - 0.8.4-1.2.1.s390x requires libgsf-1.so.113()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gsf-sharp - 0.6-8.x86_64 requires libgsf-1.so.113()(64bit)
	gsf-sharp - 0.6-8.x86_64 requires libgsf-gnome-1.so.113()(64bit)
	librsvg2 - 2.14.2-1.x86_64 requires libgsf-1.so.113()(64bit)
	libwpd - 0.8.4-1.2.1.x86_64 requires libgsf-1.so.113()(64bit)
	libwpd - 0.8.4-1.2.1.i386 requires libgsf-1.so.113
	libwpd-tools - 0.8.4-1.2.1.x86_64 requires libgsf-1.so.113()(64bit)





From emmanuel.seyman at club-internet.fr  Tue Mar 21 08:27:35 2006
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Tue, 21 Mar 2006 09:27:35 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142926819.5442.67.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<441F21B1.5090902@mharris.ca> <dvndou$llf$1@sea.gmane.org>
	<441F4C3D.6040605@mharris.ca>
	<1142914789.26492.67.camel@mccallum.corsepiu.local>
	<dvo3ff$fbv$2@sea.gmane.org> <1142926819.5442.67.camel@localhost>
Message-ID: <20060321082735.GB16674@orient.maison.moi>

On Tue, Mar 21, 2006 at 01:40:19AM -0600, Callum Lerwick wrote:
> 
> So when is someone going to start reverse engineering nVidia hardware?

St?phane Marchesin has started doing this :
  <URL:http://nouveau.sourceforge.net/>

Emmanuel



From mharris at mharris.ca  Tue Mar 21 08:45:33 2006
From: mharris at mharris.ca (Mike A. Harris)
Date: Tue, 21 Mar 2006 03:45:33 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142920511.5442.51.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<441F8862.1030903@mharris.ca> <1142920511.5442.51.camel@localhost>
Message-ID: <441FBD2D.1080707@mharris.ca>

Callum Lerwick wrote:

>>For each employed person reading this, take 1/10th of your income.
>>Would you pay that much money to have a 56k phone line based internet
>>connection each month?  Even if you did do so, would you want to
>>download the entire DVD ISO image which takes anywhere from 2-3 weeks
>>to download?  All this through a phone line which gets very frequently
>>disconnected?
> 
> 
> Its roughly the same amount of data to download a DVD vs 5 CDs. I fail
> to see how the "bandwidth is expensive" argument applies.

Because you don't actually have to download all 5 CDs to do an install,
unless we have recently made it mandatory that all of them are present
or something.  And downloads do not always succeed, resulting in having
to potentially redownload failed download in progress, or a corrupted
download.  Re-downloading one CD takes less time than redownloading
a DVD.

> Download cost is meaningless in the CDs vs DVDs argument. Its the same.

Only if you download everything always, and have flawless downloads,
which I'm told is not the case.

> The question is, what does one do with the images once downloaded.

Orthagonal issue to actually getting the images downloaded that one
wants in the first place.  It's easier and faster to do an absolute
minimal install, and then perhaps download individual packages
afterward with yum which you'd like to add on top of what you
installed already, than to download the whole DVD or 5 CDs, and then
install it.

Before you suggest doing a network install, think how well that would
work over a 56k or even slower - unreliable dialup line.  I did an
internet install over cable modem twice last week, and I get 200+Kb/s
and it took forever (and then failed due to install time bugs/problems.)


>>I told him perhaps he should just purchase Fedora Core on CD instead,
>>and indicated there were many places online which you could order CDs.
>>He said it would be about $10, which again is like 5% of his monthly
>>income.  And that's a twice a year cost.  He said that buying Fedora
>>CDs locally was more expensive for "free software" than buying bootleg
>>copies of Windows XP down the street for $2-5 a pop.
> 
> This is all a great example of what even a poor broke college student
> like me takes for granted in the US, and is completely missing the
> really useful bits of information:
> 
> 1) So how *does* this person get Fedora, and keep it updated? Do they
> download it at 56k? Do they buy CDs? What?
> 
> 2) Do they have a DVD reader?

The person in question has downloaded some releases and described it
as a very horrible process.  Having myself previously downloaded Red
Hat Linux 4.2 through 6.2 via modem, the older releases at 14.4k and
RHL 6.0 and higher at around 33.6k, I can say that it took about 1-2
weeks to get everything, with very frequent disconnections and other
hassles, all while completely consuming my single telephone line and
thus preventing me from making or receiving phonecalls.  That really
sucked, so I feel the pain of those who do not have high speed.

Mind you, I was able to at least set up my downloading to be able to
resume from where it left off, but even I have ended up having a
downloaded ISO not match MD5sum and not work properly, to have to
redownload it.

(After that, I joined Red Hat, and was sent 7.0 on CDROM, and 6
  months later we got cable modem Internet access in town so I never
  had to feel the pain again since...  although waiting all day for
  a DVD ISO to download is still painful.  ;o)




-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.



From naoki at valuecommerce.com  Tue Mar 21 09:02:41 2006
From: naoki at valuecommerce.com (Naoki)
Date: Tue, 21 Mar 2006 18:02:41 +0900
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142913886.5442.18.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
Message-ID: <441FC131.9040608@valuecommerce.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/a58b91e0/attachment.htm>

From aportal at univ-montp2.fr  Tue Mar 21 10:50:19 2006
From: aportal at univ-montp2.fr (Alain PORTAL)
Date: Tue, 21 Mar 2006 11:50:19 +0100
Subject: rawhide report: 20060204 changes
In-Reply-To: <200602040923.k149Njh2004185@porkchop.devel.redhat.com>
References: <200602040923.k149Njh2004185@porkchop.devel.redhat.com>
Message-ID: <200603211150.21726.aportal@univ-montp2.fr>

Le Samedi 4 F?vrier 2006 10:23, Build System a ?crit :
> Updated Packages:
>
> man-pages-fr-0.9.7-13
> ---------------------
> * Fri Feb 03 2006 Peter Vrabec <pvrabec at redhat.com>
> - rebuilt
>
> * Tue Jan 10 2006 Bernd Groh <bgroh at redhat.com>
> - remove pages that conflict with shadow-utils

Please, update.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139695

-- 
Les pages de manuel Linux en fran?ais :
http://manpagesfr.free.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/ce6d23e8/attachment.sig>

From russell at coker.com.au  Tue Mar 21 11:05:38 2006
From: russell at coker.com.au (Russell Coker)
Date: Tue, 21 Mar 2006 22:05:38 +1100
Subject: CD verify on FC5 disc 5.
Message-ID: <200603212205.41086.russell@coker.com.au>

I've been burning some sets of FC5 CDs for friends and verifying them.  I have 
observed that CD 5 takes an unreasonably large amount of time to verify.  
After the "Media Check" window disappears the system hands while virtual 
console 4 is giving IDE errors corresponding to logical blocks 189413 and 
189414.  After doing this for some time  it returns and says that the test 
has passed.

When burning CD-ROMs I put 80 sectors of blank padding to deal with crappy 
CD-ROM drives.  In the past I found that some of my CD-ROM drives would cause 
the Media Check to fail if I used a mere 30 sectors of padding and so I chose 
80 as an arbitrary large number to avoid that.  The number 80 has done well 
in terms of preventing check failures and install errors.  Should I consider 
the above failure to just be a symptom of an interaction between Linux and 
crappy hardware and ignore it?  Or is the fact that Linux is trying to seek 
so far past the end of the disk due to a bug in either the kernel or 
anaconda?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From hk at isphuset.no  Tue Mar 21 11:16:25 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Tue, 21 Mar 2006 12:16:25 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142918960.5442.31.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142918960.5442.31.camel@localhost>
Message-ID: <1142939785.2853.31.camel@linux>

On Mon, 2006-03-20 at 23:29 -0600, Callum Lerwick wrote:
> On Mon, 2006-03-20 at 23:11 -0500, Dave Jones wrote:
> > DVD writers aren't anywhere near as commonplace as CD writers yet.
> > Looking around right now, I have 7 computers near me. CD writers outnumber
> > DVD writers 6:1.  (And the majority of the computers with CD writers are
> > less than 2 years old (two of them are <6 months old))
> > 
> > (ironically, the dvd writer is my 3 month old laptop)
> 
> Yeah, but you own at least one, and that's the point. Extend this to
> "friends with DVD writers". How many people don't have one?

This does not hold in all cases.

For example take any server hosting company, at least here the cd-roms
outnumber the dvd-roms approx 15:1 at the moment. All new servers gets
dvd-roms, but we don't want to exchange several hundred cd-roms into
dvd-roms. Besides I hardly ever need more than cd1 on those servers
due to the post-install script fetching most useful packages so I only
need to do a minimal install on all servers no matter what purpose they
will have.

And then at home, I have dvd-roms in all my workstations but my mother
(and many others that I help out at times) does not. So i would still
need to carry the cd version as that is universally usable. For that
reason I have never even downloaded a single FC dvd image yet.

My firewall and all development boxes have only cd-roms as most of them
are P2/P3/Xeon 700Mhz, and even my dual Xeon 2.8Ghz has a cd-rom.

-HK



From russell at coker.com.au  Tue Mar 21 11:35:39 2006
From: russell at coker.com.au (Russell Coker)
Date: Tue, 21 Mar 2006 22:35:39 +1100
Subject: CD verify on FC5 disc 5.
In-Reply-To: <200603212205.41086.russell@coker.com.au>
References: <200603212205.41086.russell@coker.com.au>
Message-ID: <200603212235.42252.russell@coker.com.au>

On Tuesday 21 March 2006 22:05, Russell Coker <russell at coker.com.au> wrote:
> When burning CD-ROMs I put 80 sectors of blank padding to deal with crappy
> CD-ROM drives.  In the past I found that some of my CD-ROM drives would
> cause the Media Check to fail if I used a mere 30 sectors of padding and so
> I chose 80 as an arbitrary large number to avoid that.  The number 80 has
> done well in terms of preventing check failures and install errors.  Should
> I consider the above failure to just be a symptom of an interaction between
> Linux and crappy hardware and ignore it?  Or is the fact that Linux is
> trying to seek so far past the end of the disk due to a bug in either the
> kernel or anaconda?

I burned a copy of CD 5 with 800 blank sectors at the end and it worked 
perfectly.  I also noticed that CD 2 has the problem (although I hadn't 
noticed it before), CDs 3 and 4 don't have a problem (I still have to repeat 
tests on CD 1).

I guess that I can work around this problem by specifying a padsize of 
something between 81 and 800 sectors (if some more friends want copies of FC5 
then I'll find out soon).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From che666 at gmail.com  Tue Mar 21 11:50:17 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 21 Mar 2006 12:50:17 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142939785.2853.31.camel@linux>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142918960.5442.31.camel@localhost> <1142939785.2853.31.camel@linux>
Message-ID: <e99d27470603210350s72a18b2cq@mail.gmail.com>

2006/3/21, Hans Kristian Rosbach <hk at isphuset.no>:
> On Mon, 2006-03-20 at 23:29 -0600, Callum Lerwick wrote:
> > On Mon, 2006-03-20 at 23:11 -0500, Dave Jones wrote:
> > > DVD writers aren't anywhere near as commonplace as CD writers yet.
> > > Looking around right now, I have 7 computers near me. CD writers outnumber
> > > DVD writers 6:1.  (And the majority of the computers with CD writers are
> > > less than 2 years old (two of them are <6 months old))
> > >
> > > (ironically, the dvd writer is my 3 month old laptop)
> >
> > Yeah, but you own at least one, and that's the point. Extend this to
> > "friends with DVD writers". How many people don't have one?
>
> This does not hold in all cases.
>
> For example take any server hosting company, at least here the cd-roms
> outnumber the dvd-roms approx 15:1 at the moment. All new servers gets
> dvd-roms, but we don't want to exchange several hundred cd-roms into
> dvd-roms. Besides I hardly ever need more than cd1 on those servers
> due to the post-install script fetching most useful packages so I only
> need to do a minimal install on all servers no matter what purpose they
> will have.
>
> And then at home, I have dvd-roms in all my workstations but my mother
> (and many others that I help out at times) does not. So i would still
> need to carry the cd version as that is universally usable. For that
> reason I have never even downloaded a single FC dvd image yet.
>
> My firewall and all development boxes have only cd-roms as most of them
> are P2/P3/Xeon 700Mhz, and even my dual Xeon 2.8Ghz has a cd-rom.
>
> -HK
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

do you go to every server in your rack and pop in an install cd/dvd? :)

you serious?

regards,
rudolf kastl



From seanlkml at sympatico.ca  Tue Mar 21 12:06:07 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 21 Mar 2006 07:06:07 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142914789.26492.67.camel@mccallum.corsepiu.local>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<441F21B1.5090902@mharris.ca> <dvndou$llf$1@sea.gmane.org>
	<441F4C3D.6040605@mharris.ca>
	<1142914789.26492.67.camel@mccallum.corsepiu.local>
Message-ID: <BAYC1-PASMTP10D9FE03C55059269BCCF0AED80@CEZ.ICE>

On Tue, 21 Mar 2006 05:19:49 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> > > What do you guys do when you want decent 3D performance?
> 
> Use the proprietary drivers ... :-)

There are few cases where resorting to proprietary drivers is required.
There are open source drivers that provide good-enough 3d for the needs 
of many Linux users.

> You are ignoring the fact, Linux has a strong user base in people with a
> scientific/engineering/technical background ...

Engineers may have needs which can't be met by open source 3d drivers 
today.   Not sure who you're grouping into the scientific and technical 
categories though, i have a technical background and my needs are met 
perfectly well by open source 3d drivers.

> Whether you like it or not ... reality is different.

You should speak for yourself instead of imagining you have 
a better grasp of reality than everyone else :oP

> People are pragmatically using what they have/can get/are supplied with,
> and will ditch the distro or even the OS if it doesn't suite to their
> demands. Fortunately for Fedora, the proprietary drivers have worked
> sufficiently well.

Many people have been misinformed on this matter by others who are fixated 
on the latest-and-greatest graphics speed.  Personally I think it's time for 
a more rational discussion about the capabilities and performance levels 
actually needed by most people.

Anyone who values the flexibility and power offered by open source solutions
would do well to consider closely whether their 3d graphics needs honestly
require the use of proprietary drivers.

Cheers,
Sean



From che666 at gmail.com  Tue Mar 21 12:22:44 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 21 Mar 2006 13:22:44 +0100
Subject: gnome 2.14 test updates
In-Reply-To: <1142883063.2403.7.camel@halflap>
References: <1142876688.2403.5.camel@halflap>
	<1142882246.2635.21.camel@lt16585.campus.dmacc.edu>
	<1142883063.2403.7.camel@halflap>
Message-ID: <e99d27470603210422o395fa35bk@mail.gmail.com>

2006/3/20, Ray Strode <rstrode at redhat.com>:
> Hi,
>
> On Mon, 2006-03-20 at 13:17 -0600, Jeffrey C. Ollie wrote:
> > On Mon, 2006-03-20 at 12:44 -0500, Ray Strode wrote:
> > >
> > > A number of gnome 2.14 packages didn't quite make the FC5 cut.  These
> > > packages have been pushed into -updates-testing, now.  For those
> > > interested in helping, please give the new packages a test run and
> > > report any problems you find with them.
> > >
> > > If all goes well we should be able to push the updates that don't cause
> > > regressions into -updates in a few days.
> >
> > Have these packages been pushed to development as well?
> Not yet.  Although it will happen soon.
>
> --Ray
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Thats one thing i dont really understand. Actually all your hardcore
testers are on rawhide. If things should be tested properly id
personally expect that things hit rawhide and then the testing repos
not vice versa.

regards,
Rudolf Kastl



From hk at isphuset.no  Tue Mar 21 12:25:22 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Tue, 21 Mar 2006 13:25:22 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <e99d27470603210350s72a18b2cq@mail.gmail.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<e99d27470603210350s72a18b2cq@mail.gmail.com>
Message-ID: <1142943922.2853.53.camel@linux>

On Tue, 2006-03-21 at 12:50 +0100, Rudolf Kastl wrote:

> do you go to every server in your rack and pop in an install cd/dvd? :)
> 
> you serious?

Since we install about 1-3 servers per week, yes.
(And I don't have to do any of the carrying)

1. Server arrives at workshop desk
2. Hardware is installed/upgraded/dusted off
3. Bioses/firmwares updates
4. Memtest86+ overnight
5. OS Install (type depending on customers or our needs)
6. Server placed into rack

This lets us spot failing hardware such as capacitors or
hear noisy disks/fans. And with the KVM extender to my
office I can administrate the install remotely when I come
into my office after the overnight memtest anyways.

It might possibly be a bit more work than booting off PXE
but then we would have the added administration of PXE image
servers on each physical net. And just generally a cdrom is
a whole lot easier to debug if something fails. 

Installing minimal images over PXE would of course save
more time, but I would still have to make and maintain
all of them.

(Another benefit is that the firewall in that room is set
 up such that windows servers don't get viruses on them
 before windows update has run.)

-HK



From rc040203 at freenet.de  Tue Mar 21 12:34:43 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 21 Mar 2006 13:34:43 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321070607.732a890f.seanlkml@sympatico.ca>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net> <441F21B1.5090902@mharris.ca>
	<dvndou$llf$1@sea.gmane.org> <441F4C3D.6040605@mharris.ca>
	<1142914789.26492.67.camel@mccallum.corsepiu.local>
	<20060321070607.732a890f.seanlkml@sympatico.ca>
Message-ID: <1142944484.3149.94.camel@mccallum.corsepiu.local>

On Tue, 2006-03-21 at 07:06 -0500, sean wrote:
> On Tue, 21 Mar 2006 05:19:49 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > > > What do you guys do when you want decent 3D performance?
> > 
> > Use the proprietary drivers ... :-)
> 
> There are few cases where resorting to proprietary drivers is required.
> There are open source drivers that provide good-enough 3d for the needs 
> of many Linux users.
Wishful thinking - Try finding a notebook without an ATI or Nvidia
graphics card ...

> > You are ignoring the fact, Linux has a strong user base in people with a
> > scientific/engineering/technical background ...
> 
> Engineers may have needs which can't be met by open source 3d drivers 
> today.   Not sure who you're grouping into the scientific and technical 
> categories though, i have a technical background and my needs are met 
> perfectly well by open source 3d drivers.
Mine are not - I am working on 3d simulations/animations/visualizations.
For my applications, the nvidia driver outperforms the nv driver by ca.
factor 10. On top of that, for the hardware I have available, the nv
driver had been non-functional on one machine before FC4.

> > Whether you like it or not ... reality is different.
> 
> You should speak for yourself instead of imagining you have 
> a better grasp of reality than everyone else :oP
ROTFL ... 

> > People are pragmatically using what they have/can get/are supplied with,
> > and will ditch the distro or even the OS if it doesn't suite to their
> > demands. Fortunately for Fedora, the proprietary drivers have worked
> > sufficiently well.
> 
> Many people have been misinformed on this matter by others who are fixated 
> on the latest-and-greatest graphics speed. 
I am not talking about squeezing the "max" out of the latest and
greatest graphics HW, I am talking about:
- Getting 3D/GL functional at all.
- Getting a reasonable 3D/GL performance.
- Getting access to advanced GL features.
all on moderate to old graphic NVidia cards.

>  Personally I think it's time for 
> a more rational discussion about the capabilities and performance levels 
> actually needed by most people.
If you want to get a feeling about what I am talking about, try
SceneViewer (From Inventor, in FE) with one of the models from the Large
Geometry Repository, or try the Coin Examples from sim.no (Not in FE).

Ralf




From tla-ml at rasmil.dk  Tue Mar 21 12:40:05 2006
From: tla-ml at rasmil.dk (Tim Lauridsen)
Date: Tue, 21 Mar 2006 13:40:05 +0100
Subject: Weird yumex & selinux.
Message-ID: <441FF425.5060900@rasmil.dk>

On a newly installed FC5, with selinux set to "Enforcing"
I have some problem when updating some packages with yumex.

I get some scriptlet error:

error: %pre(avahi-0.6.9-8.FC5.i386) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping avahi-0.6.9-8.FC5
error: %pre(xorg-x11-server-Xorg-1.0.1-9.i386) scriptlet failed, exit
status 255
error:   install: %pre scriptlet failed (2), skipping
xorg-x11-server-Xorg-1.0.1-9
error: %post(tcsh-6.14-6.fc5.1.i386) scriptlet failed, exit status 255
error: %preun(avahi-0.6.9-3.i386) scriptlet failed, exit status 255

The result is some packages have multiple versions install, other is no
longer installed.:

$ rpm -q xorg-x11-server-Xorg
package xorg-x11-server-Xorg is not installed

$ rpm -q tcsh
tcsh-6.14-5.2.1
tcsh-6.14-6.fc5.1

It is only in yumex the problem exists, i yum i get no errors. (yumex
uses the Yum API to do the real action).
I another FC5 installation with selinux disabled i dont have these errors.

Anybody got any ideas to fix there problems ???.

Tim Lauridsen
Yumex Developer.





From che666 at gmail.com  Tue Mar 21 12:43:58 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 21 Mar 2006 13:43:58 +0100
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142943922.2853.53.camel@linux>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<e99d27470603210350s72a18b2cq@mail.gmail.com>
	<1142943922.2853.53.camel@linux>
Message-ID: <e99d27470603210443i4887e18eo@mail.gmail.com>

2006/3/21, Hans Kristian Rosbach <hk at isphuset.no>:
> On Tue, 2006-03-21 at 12:50 +0100, Rudolf Kastl wrote:
>
> > do you go to every server in your rack and pop in an install cd/dvd? :)
> >
> > you serious?
>
> Since we install about 1-3 servers per week, yes.
> (And I don't have to do any of the carrying)
>
> 1. Server arrives at workshop desk
> 2. Hardware is installed/upgraded/dusted off
> 3. Bioses/firmwares updates
> 4. Memtest86+ overnight
> 5. OS Install (type depending on customers or our needs)
> 6. Server placed into rack
>
> This lets us spot failing hardware such as capacitors or
> hear noisy disks/fans. And with the KVM extender to my
> office I can administrate the install remotely when I come
> into my office after the overnight memtest anyways.
>
> It might possibly be a bit more work than booting off PXE
> but then we would have the added administration of PXE image
> servers on each physical net. And just generally a cdrom is
> a whole lot easier to debug if something fails.
>
> Installing minimal images over PXE would of course save
> more time, but I would still have to make and maintain
> all of them.
>
> (Another benefit is that the firewall in that room is set
>  up such that windows servers don't get viruses on them
>  before windows update has run.)
>
> -HK
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

yup i was thinking of an install server. there are various approaches
as to how to do deal with it of course. well actually if you think
your present approach is best regarding your use case i wont hold you
back.

personally id go for the above mentioned pxe solution and push a hd
install then.

regards,
Rudolf Kastl



From mbneto at gmail.com  Tue Mar 21 13:06:46 2006
From: mbneto at gmail.com (mbneto)
Date: Tue, 21 Mar 2006 09:06:46 -0400
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060320180853.2939eeac@soran.addix.net>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
Message-ID: <5cf776b80603210506o369969c7rb2c84fb040817418@mail.gmail.com>

My wish list:
- break the packages in order to reduce dependencies so we can have a
lower footprint for a minimum install (and have a more granular
control of what is installed - security issues)
- optimize the memory usage so we can continue to use FC6,7 with
todays specs (even if reduced functionality).

>
> Sooo... what are we going to break first?
>



From jspaleta at gmail.com  Tue Mar 21 13:12:40 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 08:12:40 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321043547.GA15330@devserv.devel.redhat.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
Message-ID: <604aa7910603210512s5233b492qef33f8fda457314c@mail.gmail.com>

On 3/20/06, Bill Nottingham <notting at redhat.com> wrote:
> DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
> and 6:1 on ppc.

Is that for fc5?

I'd think the same statistic over the lifetime of a release would be
more interesting.  I'd argue the people who participate during the
release surge are a skewed sample of the overall population.

-jef



From avi at argo.co.il  Tue Mar 21 13:47:15 2006
From: avi at argo.co.il (Avi Kivity)
Date: Tue, 21 Mar 2006 15:47:15 +0200
Subject: Mirrorlist missing mirrors?
Message-ID: <442003E3.7080801@argo.co.il>

[avi at firebolt ~]$ wget -q -O - 
http://fedora.redhat.com/download/mirrors/fedora-core-5
http://download.fedoraproject.org/pub/fedora/linux/core/5/$ARCH/os/

A few more mirrors would help reduce the load...

-- 
error compiling committee.c: too many arguments to function



From jdesbonnet at gmail.com  Tue Mar 21 13:47:42 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 21 Mar 2006 13:47:42 +0000
Subject: delrarpm in core or extras
Message-ID: <1cef3e950603210547s5b807042nd36e074fb458003b@mail.gmail.com>

I have just tried the 'makedeltaiso' utility in the SuSE deltarpm 3.3
package . I was able to produce a FC5 i386 DVD ISO, Test3 -> Final
delta in only 300MB (10% of the size of the ISO).  xdelta didn't
produce any savings.

I think these deltarpm utilities are well worth making available in
extras or core (I estimate a RPM of 200KB). I'd volunteer myself, but
I have no experience with making RPMs (yet). It also seems to be quite
stable right now. Source at: ftp://ftp.suse.com/pub/projects/deltarpm/

Joe.

PS: if anyone is interested in that delta I mentioned above, I can
make it available via FTP/HTTP.



From tla-ml at rasmil.dk  Tue Mar 21 13:48:40 2006
From: tla-ml at rasmil.dk (Tim Lauridsen)
Date: Tue, 21 Mar 2006 14:48:40 +0100
Subject: Weird yumex & selinux.
In-Reply-To: <441FF425.5060900@rasmil.dk>
References: <441FF425.5060900@rasmil.dk>
Message-ID: <44200438.3080402@rasmil.dk>

Tim Lauridsen wrote:
> On a newly installed FC5, with selinux set to "Enforcing"
> I have some problem when updating some packages with yumex.
>
> I get some scriptlet error:
>
> error: %pre(avahi-0.6.9-8.FC5.i386) scriptlet failed, exit status 255
> error:   install: %pre scriptlet failed (2), skipping avahi-0.6.9-8.FC5
> error: %pre(xorg-x11-server-Xorg-1.0.1-9.i386) scriptlet failed, exit
> status 255
> error:   install: %pre scriptlet failed (2), skipping
> xorg-x11-server-Xorg-1.0.1-9
> error: %post(tcsh-6.14-6.fc5.1.i386) scriptlet failed, exit status 255
> error: %preun(avahi-0.6.9-3.i386) scriptlet failed, exit status 255
>
> The result is some packages have multiple versions install, other is no
> longer installed.:
>
> $ rpm -q xorg-x11-server-Xorg
> package xorg-x11-server-Xorg is not installed
>
> $ rpm -q tcsh
> tcsh-6.14-5.2.1
> tcsh-6.14-6.fc5.1
>
> It is only in yumex the problem exists, i yum i get no errors. (yumex
> uses the Yum API to do the real action).
> I another FC5 installation with selinux disabled i dont have these 
> errors.
>
> Anybody got any ideas to fix there problems ???.
>
> Tim Lauridsen
> Yumex Developer.
>
>
>
[tim at localhost ~]$ ls -Z /usr/bin/yum
-rwxr-xr-x  root     root     system_u:object_r:rpm_exec_t     /usr/bin/yum
[tim at localhost ~]$ ls -Z /usr/bin/yumex
lrwxrwxrwx  root     root     system_u:object_r:bin_t          
/usr/bin/yumex -> consolehelper
[tim at localhost ~]$ ls -Z /usr/share/yumex/yumex
-rwxr-xr-x  root     root     system_u:object_r:usr_t          
/usr/share/yumex/yumex
[tim at localhost ~]$ ls -Z /usr/sbin/pup
-rwxr-xr-x  root     root     system_u:object_r:rpm_exec_t     /usr/sbin/pup
[tim at localhost ~]$ ls -Z /usr/sbin/pup

It look like it have something to do with the 
'system_u:object_r:rpm_exec_t' attribute, yumex  dont have that attribute.
How do i get this attribute ????

Tim Lauridsen
Yumex Developer.



From nicu_fedora at nicubunu.ro  Tue Mar 21 13:58:14 2006
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Tue, 21 Mar 2006 15:58:14 +0200
Subject: Wild and crazy times for the development tree
In-Reply-To: <604aa7910603210512s5233b492qef33f8fda457314c@mail.gmail.com>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<1142889303.3604.10.camel@T7.Linux>	<1142913886.5442.18.camel@localhost>	<20060321041157.GA28237@redhat.com>	<20060321043547.GA15330@devserv.devel.redhat.com>
	<604aa7910603210512s5233b492qef33f8fda457314c@mail.gmail.com>
Message-ID: <44200676.9070303@nicubunu.ro>

Jeff Spaleta wrote:
> On 3/20/06, Bill Nottingham <notting at redhat.com> wrote:
>> DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
>> and 6:1 on ppc.
> 
> Is that for fc5?
> 
> I'd think the same statistic over the lifetime of a release would be
> more interesting.  I'd argue the people who participate during the
> release surge are a skewed sample of the overall population.

Not only that, people who download at any time are a skewed sample of 
the overall population. A lot of people obtain their install media from 
other sources: the CD-Writer of a friend, a magazine, etc.

Also, the 2:1 ratio can be interpreted the other way: at least 33% users 
prefer CDs for installation, going DVD only would leave them in the cold.

-- 
nicu
my hats collection: http://fedora.nicubunu.ro/hats/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro



From alan at redhat.com  Tue Mar 21 14:42:28 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Mar 2006 09:42:28 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <dvndou$llf$1@sea.gmane.org>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<441F21B1.5090902@mharris.ca> <dvndou$llf$1@sea.gmane.org>
Message-ID: <20060321144228.GC12823@devserv.devel.redhat.com>

On Mon, Mar 20, 2006 at 05:27:26PM -0600, Ian Pilcher wrote:
> Mike A. Harris wrote:
> > All proprietary drivers?  ;o)
> 
> I can't help wondering...
> What do you guys do when you want decent 3D performance?

I walk out of the front door, the resolution is excellent, the shadows are
superbly computed and you get exercise too 8)

On the more serious side there is a lack of DRI capability for very high
end gaming. R2xx will do all that I need however because highly detailed
simulations of killing people really don't appeal.

Alan





From ivazquez at ivazquez.net  Tue Mar 21 14:42:31 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 21 Mar 2006 09:42:31 -0500
Subject: Weird yumex & selinux.
In-Reply-To: <44200438.3080402@rasmil.dk>
References: <441FF425.5060900@rasmil.dk>  <44200438.3080402@rasmil.dk>
Message-ID: <1142952151.6177.2.camel@ignacio.lan>

On Tue, 2006-03-21 at 14:48 +0100, Tim Lauridsen wrote:
> It look like it have something to do with the 
> 'system_u:object_r:rpm_exec_t' attribute, yumex  dont have that attribute.
> How do i get this attribute ????

FC5+:
http://sepolicy-server.sourceforge.net/index.php?page=module-overview

FC4-:
https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core
Component: selinux-policy-targeted

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/77be030b/attachment.sig>

From alan at redhat.com  Tue Mar 21 14:48:51 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 21 Mar 2006 09:48:51 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321050203.GB15330@devserv.devel.redhat.com>
References: <1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
	<441F88AA.20509@mindspring.com>
	<20060321050203.GB15330@devserv.devel.redhat.com>
Message-ID: <20060321144851.GE12823@devserv.devel.redhat.com>

On Tue, Mar 21, 2006 at 12:02:03AM -0500, Bill Nottingham wrote:
> > Hi Bill,
> > 	How or where did you get those number?
> 
> http://torrent.fedoraproject.org:6969/

So its torrent stats only - thats fairly biased if so



From jspaleta at gmail.com  Tue Mar 21 15:00:09 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 10:00:09 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <442003E3.7080801@argo.co.il>
References: <442003E3.7080801@argo.co.il>
Message-ID: <604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>

On 3/21/06, Avi Kivity <avi at argo.co.il> wrote:
> [avi at firebolt ~]$ wget -q -O -
> http://fedora.redhat.com/download/mirrors/fedora-core-5
> http://download.fedoraproject.org/pub/fedora/linux/core/5/$ARCH/os/
>
> A few more mirrors would help reduce the load...

the file fedora-core-5-redirect is an actual mirrorlist file. 
Appearently there is suppose to be some serverside redirect magic
going on which is non-obvious from the client side yum configuration.

I've turned on verbose mode on the fastestmirror plugin I'm using to
see the list of mirrors which fastestmirror plugin is suppose to be
"timing" to make its judgement. And I'm not seeing the mirrors as
listed in the -redirect file in the fastestmirror output.  So from my
pov whatever magic on the server which is suppose to be redirecting
clients to use fedora-core-5-redirect mirrorlist isn't working afaict.

I'm not sure whom to address this problem to exactly. The redirect
issue affects both core and updates in the fc5 configs.

-jef



From ajackson at redhat.com  Tue Mar 21 15:08:10 2006
From: ajackson at redhat.com (Adam Jackson)
Date: Tue, 21 Mar 2006 10:08:10 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <dvndou$llf$1@sea.gmane.org>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>
	<441F21B1.5090902@mharris.ca> <dvndou$llf$1@sea.gmane.org>
Message-ID: <38734add04703fcd6124d3c1c58750b4@redhat.com>

On Mar 20, 2006, at 6:27 PM, Ian Pilcher wrote:

> Mike A. Harris wrote:
>>
>> All proprietary drivers?  ;o)
>>
>
> I can't help wondering...
>
> What do you guys do when you want decent 3D performance?

I write a working 3D driver.

- ajax



From tla-ml at rasmil.dk  Tue Mar 21 15:20:22 2006
From: tla-ml at rasmil.dk (Tim Lauridsen)
Date: Tue, 21 Mar 2006 16:20:22 +0100
Subject: Weird yumex & selinux.
In-Reply-To: <1142952151.6177.2.camel@ignacio.lan>
References: <441FF425.5060900@rasmil.dk> <44200438.3080402@rasmil.dk>
	<1142952151.6177.2.camel@ignacio.lan>
Message-ID: <442019B6.4030407@rasmil.dk>

Ignacio Vazquez-Abrams wrote:
> On Tue, 2006-03-21 at 14:48 +0100, Tim Lauridsen wrote:
>   
>> It look like it have something to do with the 
>> 'system_u:object_r:rpm_exec_t' attribute, yumex  dont have that attribute.
>> How do i get this attribute ????
>>     
>
> FC5+:
> http://sepolicy-server.sourceforge.net/index.php?page=module-overview
>
> FC4-:
> https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core
> Component: selinux-policy-targeted
>
>   
I have created a bugzilla record.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186076
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/7bb197f8/attachment.htm>

From jspaleta at gmail.com  Tue Mar 21 15:23:09 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 10:23:09 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
Message-ID: <604aa7910603210723y38caaf52r1e38c9cd01529e1d@mail.gmail.com>

On 3/21/06, Jeff Spaleta <jspaleta at gmail.com> wrote:
> I'm not sure whom to address this problem to exactly. The redirect
> issue affects both core and updates in the fc5 configs.


Of course I could be completely mis-interpreting how the redirect
magic works. The redirect stuff might be completely opaque to
clientside and we call all be redirected to other mirrors without
having to much in the way of clientside information that its
happening.

I'd personally love an explanation as to how the new mirror
redirection works with an eye on how to troubleshoot if there is a
problem or not without special access .... from the clientside of
things.

-jef



From jwboyer at jdub.homelinux.org  Tue Mar 21 14:11:52 2006
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Tue, 21 Mar 2006 08:11:52 -0600 (CST)
Subject: Wild and crazy times for the development tree
In-Reply-To: <604aa7910603210512s5233b492qef33f8fda457314c@mail.gmail.com>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
	<604aa7910603210512s5233b492qef33f8fda457314c@mail.gmail.com>
Message-ID: <14606.129.42.161.36.1142950312.squirrel@jdub.homelinux.org>

Jeff Spaleta wrote:
> On 3/20/06, Bill Nottingham <notting at redhat.com> wrote:
>> DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64,
>> and 6:1 on ppc.
>
> Is that for fc5?
>
> I'd think the same statistic over the lifetime of a release would be
> more interesting.  I'd argue the people who participate during the
> release surge are a skewed sample of the overall population.

That, and the numbers quoted are only for the torrent downloads.  Not
everyone uses the torrent.  However, it's probably the easiest to collect
sample set.  Tracking it on the mirrors would suck ;)

josh



From ralph+fedora at strg-alt-entf.org  Tue Mar 21 15:34:23 2006
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Tue, 21 Mar 2006 16:34:23 +0100
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603210723y38caaf52r1e38c9cd01529e1d@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
	<604aa7910603210723y38caaf52r1e38c9cd01529e1d@mail.gmail.com>
Message-ID: <20060321153423.GM4809@br-online.de>

Jeff Spaleta wrote:
> On 3/21/06, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > I'm not sure whom to address this problem to exactly. The redirect
> > issue affects both core and updates in the fc5 configs.
> 
> Of course I could be completely mis-interpreting how the redirect
> magic works. The redirect stuff might be completely opaque to
> clientside and we call all be redirected to other mirrors without
> having to much in the way of clientside information that its
> happening.

I don't think so. 

fastestmirror chooses download.fedora.redhat.com for me also, which
doesn't seem to be some round robin dns box. And there are mirrors in my
vicinity (Germany, Europe) which should supposedly be faster than
anything at *.redhat.com for me. 

And: If something times out while downloading, yum directly comes back
to me telling me, that it has run out of mirrors to try.

Regards,

Ralph
-- 
Ralph Angenendt......ra at br-online.de | .."Text processing has made it possible
Bayerischer Rundfunk...80300 M?nchen | ....to right-justify any idea, even one
Programmbereich.Bayern 3, Jugend und | .which cannot be justified on any other
Multimedia.........Tl:089.5900.16023 | ..........grounds." -- J. Finnegan, USC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/aa26875d/attachment.sig>

From katzj at redhat.com  Tue Mar 21 15:45:01 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 21 Mar 2006 10:45:01 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142928897.23128.75.camel@price.stavtrup-st.dk>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<20060320212856.GA10685@jadzia.bu.edu>
	<1142928897.23128.75.camel@price.stavtrup-st.dk>
Message-ID: <1142955901.2750.7.camel@aglarond.local>

On Tue, 2006-03-21 at 09:14 +0100, David Nielsen wrote:
> To sum up the point, we'd have 6 months of development time followed by
> 3 months of API stable bugfixing and updating (e.g. like what was done
> with GNOME 2.14 in FC5) then we release that as the technology preview
> Fedora, it would be considered stable. Then we follow that up with a 4
> month API stable polish cycle.

And then we have a release with basically extremely out of date software
for the next 9 months.  This ends up being pretty difficult to maintain
over the longer term.

> Pros and cons of such an out of balance approach to releasing are many
> but when I thought it up I had just had a lenghty conversation with one
> of the FC developers who was telling me that with the 9 month cycle he
> was fighting fatigue and burnout. It struck me as a user that the 9
> month cycle was completely awesome but for developers it might be hard -
> thus the need for faster paced releases and periods of light pressure.

Yep.  For all of the pressure that the 6 month cycle entails (and it
does), it definitely seemed less so than 9.  Mostly because the end is
more clearly in sight the entire time :)

> We can all agree that major surgery like replacing the Init system,
> reworking the installer, switching to modular X, switching GCC versions,
> etc. requires more time than a 6 month cycle would allow for in terms of
> testing (implementation I'm sure could be done in the 6 month cycle but
> would it be well tested?). So we will need more cycles of this length,
> depending on the amount of surgery that is planned in the near future. 

Like I've said, I don't think that a nine month cycle actually does
anything to significantly help here.  The problem is that then, if I
have something else pop up, it's easier to have it interrupt working on
whatever big new thing.  And it still ends up getting done at the last
minute.  I'm convinced this is a fundamental law of software
development :-)

Jeremy



From jspaleta at gmail.com  Tue Mar 21 15:51:17 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 10:51:17 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <20060321153423.GM4809@br-online.de>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
	<604aa7910603210723y38caaf52r1e38c9cd01529e1d@mail.gmail.com>
	<20060321153423.GM4809@br-online.de>
Message-ID: <604aa7910603210751q31ab6147s1a3f6ec44ed76f58@mail.gmail.com>

On 3/21/06, Ralph Angenendt <ralph+fedora at strg-alt-entf.org> wrote:
> I don't think so.

Or perhaps...the single mirror listed in the mirrorlist is acting as a
redirect at the http server level... redirecting you to some other
http mirror based on http server logic which we can't easily evaluate
via normal client interaction... essentially short-circuiting the
normal mirrorlist behavior we've grown used to in previous versions. 
I don't have a clear understanding as to expected behavior now and I
need an explanation from the mirror infrastructure developers as where
things stand. Something has certaintly appeared to have changed, but
without understanding the change it will be difficult to troubleshoot.

-jef



From prarit at sgi.com  Tue Mar 21 15:52:24 2006
From: prarit at sgi.com (Prarit Bhargava)
Date: Tue, 21 Mar 2006 10:52:24 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142955901.2750.7.camel@aglarond.local>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<20060320212856.GA10685@jadzia.bu.edu>	<1142928897.23128.75.camel@price.stavtrup-st.dk>
	<1142955901.2750.7.camel@aglarond.local>
Message-ID: <44202138.4080302@sgi.com>

   And it still ends up getting done at the last
> minute.  I'm convinced this is a fundamental law of software
> development :-)


Parkinson's Law

http://www.wildenforcers.com/Images/boogaard/Boogard-Skate.jpg

P.



From prarit at sgi.com  Tue Mar 21 15:54:38 2006
From: prarit at sgi.com (Prarit Bhargava)
Date: Tue, 21 Mar 2006 10:54:38 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <44202138.4080302@sgi.com>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<20060320212856.GA10685@jadzia.bu.edu>	<1142928897.23128.75.camel@price.stavtrup-st.dk>	<1142955901.2750.7.camel@aglarond.local>
	<44202138.4080302@sgi.com>
Message-ID: <442021BE.7060006@sgi.com>

Prarit Bhargava wrote:
>   And it still ends up getting done at the last
> 
>> minute.  I'm convinced this is a fundamental law of software
>> development :-)
> 
> 
> 
> Parkinson's Law
> 
> http://www.wildenforcers.com/Images/boogaard/Boogard-Skate.jpg
> 

Oops.  Wrong link

http://www.bartleby.com/59/3/workexpandst.html

P.

> P.
> 



From avi at argo.co.il  Tue Mar 21 16:07:51 2006
From: avi at argo.co.il (Avi Kivity)
Date: Tue, 21 Mar 2006 18:07:51 +0200
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603210751q31ab6147s1a3f6ec44ed76f58@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>	<604aa7910603210723y38caaf52r1e38c9cd01529e1d@mail.gmail.com>	<20060321153423.GM4809@br-online.de>
	<604aa7910603210751q31ab6147s1a3f6ec44ed76f58@mail.gmail.com>
Message-ID: <442024D7.1070401@argo.co.il>

Jeff Spaleta wrote:
> On 3/21/06, Ralph Angenendt <ralph+fedora at strg-alt-entf.org> wrote:
>   
>> I don't think so.
>>     
>
> Or perhaps...the single mirror listed in the mirrorlist is acting as a
> redirect at the http server level... redirecting you to some other
> http mirror based on http server logic which we can't easily evaluate
> via normal client interaction... essentially short-circuiting the
> normal mirrorlist behavior we've grown used to in previous versions. 
> I don't have a clear understanding as to expected behavior now and I
> need an explanation from the mirror infrastructure developers as where
> things stand. Something has certaintly appeared to have changed, but
> without understanding the change it will be difficult to troubleshoot.
>
>   
no. we have a single mirror active, and doing a 'yum upgrade' is an 
exercise in futility as after 4-5 headers the mirror will reject the 
connection due to overload and yum will exit saying no more mirrors are 
available.

the corresponding file for FC4 has all the mirrors listed, someone just 
needs to go and update it.

-- 
error compiling committee.c: too many arguments to function



From smooge at gmail.com  Tue Mar 21 16:32:50 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Tue, 21 Mar 2006 09:32:50 -0700
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142955901.2750.7.camel@aglarond.local>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<20060320212856.GA10685@jadzia.bu.edu>
	<1142928897.23128.75.camel@price.stavtrup-st.dk>
	<1142955901.2750.7.camel@aglarond.local>
Message-ID: <80d7e4090603210832p286ce71fr9704209be3641dc0@mail.gmail.com>

On 3/21/06, Jeremy Katz <katzj at redhat.com> wrote:

> Like I've said, I don't think that a nine month cycle actually does
> anything to significantly help here.  The problem is that then, if I
> have something else pop up, it's easier to have it interrupt working on
> whatever big new thing.  And it still ends up getting done at the last
> minute.  I'm convinced this is a fundamental law of software
> development :-)
>

Well it is a fundamental law of life. The gain in 9 months here was
that I as a tester could let real life deal me its usual blows and I
could still do some testing and finding of stuff before we crashed.  I
did not have that luxury with FC2 and basically dropped doing anything
with it.. and only was able to pick up FC3 at around its release time.
I didnt look at FC4 until it came out. I will probably have to blow
off FC6 on a sixth month schedule and do some work with FC7.  I might
be a statistical outlayer.. but it seems to be a constant
question/reply from other people using Fedora here in Government land
(or  us guys over 35 land with kids land.)


> Jeremy
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From notting at redhat.com  Tue Mar 21 16:44:52 2006
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 21 Mar 2006 11:44:52 -0500
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321144851.GE12823@devserv.devel.redhat.com>
References: <441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
	<20060321041157.GA28237@redhat.com>
	<20060321043547.GA15330@devserv.devel.redhat.com>
	<441F88AA.20509@mindspring.com>
	<20060321050203.GB15330@devserv.devel.redhat.com>
	<20060321144851.GE12823@devserv.devel.redhat.com>
Message-ID: <20060321164452.GD16972@devserv.devel.redhat.com>

Alan Cox (alan at redhat.com) said: 
> On Tue, Mar 21, 2006 at 12:02:03AM -0500, Bill Nottingham wrote:
> > > Hi Bill,
> > > 	How or where did you get those number?
> > 
> > http://torrent.fedoraproject.org:6969/
> 
> So its torrent stats only - thats fairly biased if so

Yes, but it's what's immediately available. 5:1 for x86_64 is still
fairly significant.

Bill



From ossman at cendio.se  Tue Mar 21 16:45:05 2006
From: ossman at cendio.se (Pierre Ossman)
Date: Tue, 21 Mar 2006 17:45:05 +0100
Subject: Polypaudio as sound server
Message-ID: <44202D91.60508@cendio.se>

Before the rumor gets started here as well, I though I'd just like to 
point out that the polypaudio project is very much alive. Lennart has 
just been a bit lazy about updating the front web page.

So to whomever is working on the sound server point in the future list, 
please don't skip polypaudio just because our web page is old. :)

If there are any concerns about required functionality, we're always 
open to suggestions. The synchronized streams point that is mentioned on 
http://fedoraproject.org/wiki/FC6Future might be solved with our next 
release (where multiple streams can be synchronized to each other).

-- 
Rgds
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com



From jkeating at redhat.com  Tue Mar 21 17:21:07 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 21 Mar 2006 09:21:07 -0800
Subject: gnome 2.14 test updates
In-Reply-To: <e99d27470603210422o395fa35bk@mail.gmail.com>
References: <1142876688.2403.5.camel@halflap> <1142883063.2403.7.camel@halflap>
	<e99d27470603210422o395fa35bk@mail.gmail.com>
Message-ID: <200603210921.07906.jkeating@redhat.com>

On Tuesday 21 March 2006 04:22, Rudolf Kastl wrote:
> Thats one thing i dont really understand. Actually all your hardcore
> testers are on rawhide. If things should be tested properly id
> personally expect that things hit rawhide and then the testing repos
> not vice versa.

Rawhide is the path to FC6, not the path to FC5 Updates.  There are things 
that may land in rawhide that make the package noncompatible with FC5, like a 
compiler update, or a new version of GTK or something like that.  This is why 
updates-testing exists, packages built in the FC5+updates environment 
designed to install in said environment, while rawhide can roll forward in 
its path to FC6.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/4cb28038/attachment.sig>

From jkeating at redhat.com  Tue Mar 21 17:26:25 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 21 Mar 2006 09:26:25 -0800
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
Message-ID: <200603210926.25367.jkeating@redhat.com>

On Tuesday 21 March 2006 07:00, Jeff Spaleta wrote:
> I'm not sure whom to address this problem to exactly. The redirect
> issue affects both core and updates in the fc5 configs.

download.fedoraproject.org is a redirector.  It uses the mirrors found in the 
-redirect version of the file (not sure if this is done automatically or 
somebody reads the -redirect file and updates some other list for 
redirection).  Elliot Lee is the person who is managing the redirector, 
perhaps he can chime in (I've cc'd him).  Theoretically each time you load a 
valid url from download.fedoraproject.org it would use a new mirror.  Firefox 
won't work for testing this, but using links again and again will show that 
it does indeed to go different hosts.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/e844d48a/attachment.sig>

From rspanton at gmail.com  Tue Mar 21 17:30:10 2006
From: rspanton at gmail.com (Robert Spanton)
Date: Tue, 21 Mar 2006 17:30:10 +0000
Subject: Mirrorlist missing mirrors?
In-Reply-To: <442024D7.1070401@argo.co.il>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
	<604aa7910603210723y38caaf52r1e38c9cd01529e1d@mail.gmail.com>
	<20060321153423.GM4809@br-online.de>
	<604aa7910603210751q31ab6147s1a3f6ec44ed76f58@mail.gmail.com>
	<442024D7.1070401@argo.co.il>
Message-ID: <ab6786480603210930k1b9ec0b1lcbb9238fee84bcef@mail.gmail.com>

I think some of the fedora mirrors haven't caught up yet. Maybe someone's
waiting for them to catch up a little.

Rob Spanton

On 3/21/06, Avi Kivity <avi at argo.co.il> wrote:
>
> Jeff Spaleta wrote:
> > On 3/21/06, Ralph Angenendt <ralph+fedora at strg-alt-entf.org> wrote:
> >
> >> I don't think so.
> >>
> >
> > Or perhaps...the single mirror listed in the mirrorlist is acting as a
> > redirect at the http server level... redirecting you to some other
> > http mirror based on http server logic which we can't easily evaluate
> > via normal client interaction... essentially short-circuiting the
> > normal mirrorlist behavior we've grown used to in previous versions.
> > I don't have a clear understanding as to expected behavior now and I
> > need an explanation from the mirror infrastructure developers as where
> > things stand. Something has certaintly appeared to have changed, but
> > without understanding the change it will be difficult to troubleshoot.
> >
> >
> no. we have a single mirror active, and doing a 'yum upgrade' is an
> exercise in futility as after 4-5 headers the mirror will reject the
> connection due to overload and yum will exit saying no more mirrors are
> available.
>
> the corresponding file for FC4 has all the mirrors listed, someone just
> needs to go and update it.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> 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/20060321/42b75088/attachment.htm>

From jspaleta at gmail.com  Tue Mar 21 18:02:42 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 13:02:42 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <200603210926.25367.jkeating@redhat.com>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
	<200603210926.25367.jkeating@redhat.com>
Message-ID: <604aa7910603211002y15e47dcdnc9362452c2e4ce9f@mail.gmail.com>

On 3/21/06, Jesse Keating <jkeating at redhat.com> wrote:
> Theoretically each time you load a
> valid url from download.fedoraproject.org it would use a new mirror.  Firefox
> won't work for testing this, but using links again and again will show that
> it does indeed to go different hosts.

I'd love an example of a client that I can use to troubleshoot this
behavior without resorting to low level packet inspection. The
verbosity on fastestmirror plugin doesn't indicate that a redirect is
occuring.  And yum clean metadata    yum -d6 list updates  does not
give me any information with regard to which mirror I'm being
redirected to when pulling primary.xml.gz or repomd.xml.gz
the yum -d6 output just lists the redirector url.  And now with the
change to the mirrorlist file... lists the same url repeatedly :->

What is the best procedure that I should be performing when following
up on complaints with regard to mirrorlist not redirecting as it
should?

-jef



From jdieter99 at gmx.net  Tue Mar 21 18:16:43 2006
From: jdieter99 at gmx.net (Jonathan Dieter)
Date: Tue, 21 Mar 2006 20:16:43 +0200
Subject: Wild and crazy times for the development tree
In-Reply-To: <20060321170003.C9B2672F67@hormel.redhat.com>
References: <20060321170003.C9B2672F67@hormel.redhat.com>
Message-ID: <4420430B.2080707@gmx.net>

I'm currently living in a country where broadband is expensive, and, 
even if you have the money to pay for broadband, upload speeds are below 
64kbps.  Because bittorrent rewards uploading, I've found that 
downloading through bittorrent takes roughly double the time it takes me 
to download directly from the mirrors (and when my maximum download 
speed is 256kbps, it means the difference between a little over a day 
for FC5 and a little over two days).

I would suspect most people with slow upload links have this problem 
(though I could be completely wrong).  If that is the case, then the 
torrent statistics will be heavily biased towards users with reasonably 
fast upload links, and the users with slower links (who, like myself, 
are probably downloading the CD isos for reasons mentioned by Mike 
Harris in another posting) aren't accurately represented.

Bear in mind that this is all based on assumptions made on my 
experiences which may be completely incorrect.

Jonathan

Bill Nottingham said:
> Alan Cox (alan at redhat.com) said:
> > > On Tue, Mar 21, 2006 at 12:02:03AM -0500, Bill Nottingham wrote:
> >>> > > > Hi Bill,
> >>> > > > How or where did you get those number?
> >> > >
> >> > > http://torrent.fedoraproject.org:6969/
> > >
> > > So its torrent stats only - thats fairly biased if so
>
> Yes, but it's what's immediately available. 5:1 for x86_64 is still
> fairly significant.
>
> Bill



From jkeating at j2solutions.net  Tue Mar 21 18:21:08 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 21 Mar 2006 10:21:08 -0800
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603211002y15e47dcdnc9362452c2e4ce9f@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>
	<200603210926.25367.jkeating@redhat.com>
	<604aa7910603211002y15e47dcdnc9362452c2e4ce9f@mail.gmail.com>
Message-ID: <200603211021.08997.jkeating@j2solutions.net>

On Tuesday 21 March 2006 10:02, Jeff Spaleta wrote:
> I'd love an example of a client that I can use to troubleshoot this
> behavior without resorting to low level packet inspection. The
> verbosity on fastestmirror plugin doesn't indicate that a redirect is
> occuring. ?And yum clean metadata ? ?yum -d6 list updates ?does not
> give me any information with regard to which mirror I'm being
> redirected to when pulling primary.xml.gz or repomd.xml.gz
> the yum -d6 output just lists the redirector url. ?And now with the
> change to the mirrorlist file... lists the same url repeatedly :->
>
> What is the best procedure that I should be performing when following
> up on complaints with regard to mirrorlist not redirecting as it
> should?

Currently I think Elliot Lee is the pointman for this 'feature'.  I was asked 
to try this.  If it continues to fail, I will copy over the existing list of 
mirrors in -redirect to the actual mirror file that yum points to and avoid 
the redirector on download.fedoraproject.org.

I think a bug to fedora infrastructure?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/35808bf1/attachment.sig>

From jspaleta at gmail.com  Tue Mar 21 18:27:26 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 13:27:26 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <200603211021.08997.jkeating@j2solutions.net>
References: <442003E3.7080801@argo.co.il>
	<200603210926.25367.jkeating@redhat.com>
	<604aa7910603211002y15e47dcdnc9362452c2e4ce9f@mail.gmail.com>
	<200603211021.08997.jkeating@j2solutions.net>
Message-ID: <604aa7910603211027m1f304ff1u9b9a7921f5906839@mail.gmail.com>

On 3/21/06, Jesse Keating <jkeating at j2solutions.net> wrote:
> Currently I think Elliot Lee is the pointman for this 'feature'.  I was asked
> to try this.  If it continues to fail,

Is it failing? Its very difficult to make a claim as to what is
failing and how, if competent troubleshouters can't reproduce behavior
with enough detail to pinpoint a problem. And right now the available
debugging information in yum isn't verbose enough to see the redirects
as they happen and tell the users about which mirror is being used.
This makes reproducibility and documentation of a problem...
difficult.

-jef



From saddateh at gmail.com  Tue Mar 21 18:57:13 2006
From: saddateh at gmail.com (Sadda Teh)
Date: Tue, 21 Mar 2006 13:57:13 -0500
Subject: Alsa patch for nvidia onboard sound
Message-ID: <fc33c1550603211057m7e812ba8mc45469a67e77780d@mail.gmail.com>

Might anyone be willing to apply the patch mentioned here:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1895 (You have to
click the Guest Login link to view)

I, and probably many others have a motherboard affected by this bug. It
would be much appreciated if the fix would make it into FC5. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/56506881/attachment.htm>

From jkeating at j2solutions.net  Tue Mar 21 19:00:49 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 21 Mar 2006 11:00:49 -0800
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603211027m1f304ff1u9b9a7921f5906839@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>
	<200603211021.08997.jkeating@j2solutions.net>
	<604aa7910603211027m1f304ff1u9b9a7921f5906839@mail.gmail.com>
Message-ID: <200603211100.49965.jkeating@j2solutions.net>

On Tuesday 21 March 2006 10:27, Jeff Spaleta wrote:
> Is it failing? Its very difficult to make a claim as to what is
> failing and how, if competent troubleshouters can't reproduce behavior
> with enough detail to pinpoint a problem. And right now the available
> debugging information in yum isn't verbose enough to see the redirects
> as they happen and tell the users about which mirror is being used.
> This makes reproducibility and documentation of a problem...
> difficult.

What exactly do you want from me here?  This in itself could be considered a 
failure.  File a bug as such.  If you're getting repeated failures running 
yum, but pointing yum to the -redirect version of the mirrorlist file 
consistently works, this would indicate a failure in the way the redirect is 
working for yum.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/7c67c604/attachment.sig>

From jspaleta at gmail.com  Tue Mar 21 19:15:42 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 14:15:42 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <200603211100.49965.jkeating@j2solutions.net>
References: <442003E3.7080801@argo.co.il>
	<200603211021.08997.jkeating@j2solutions.net>
	<604aa7910603211027m1f304ff1u9b9a7921f5906839@mail.gmail.com>
	<200603211100.49965.jkeating@j2solutions.net>
Message-ID: <604aa7910603211115y5294432w7b8e64c35a6dacb7@mail.gmail.com>

On 3/21/06, Jesse Keating <jkeating at j2solutions.net> wrote:
> What exactly do you want from me here?

>From you in particular? That's a difficult question to answer because
I'm not sure in a position to provide me with what I'm seeking...
since you have already pointed out that I need to schedule a meeting
between Mr. Lee and the magic lasso of truth that I have on loan from
wonder woman.

> This in itself could be considered a
> failure.  File a bug as such.

I'm attempting to do my best to ensure than whatever bugs are filed
are not closed as worksforme because of lack of reproducibility or
consistency of behavior. I would like to be able to find a way to
produce an auditable trail of clientside output which unsuspecting
users can be directed to generate as needed per incident in an effort
to document what could very well be a sporadic symptoms in order to
pinpoint the if there is an underlying problem with the new redirect
service. People are already confused by the changes in the mirrorlist
file.

> If you're getting repeated failures running
> yum, but pointing yum to the -redirect version of the mirrorlist file
> consistently works, this would indicate a failure in the way the redirect is
> working for yum.

And if using -redirect directly also produces sporadic failures for
some people with similiar clientside symptoms?  There are other,
pre-existing issues which some users can run into.. things like
timeout settings which could be mis-diagnosed as problems associated
with the new redirect layer simply because the redirect process is new
and opaque from the client pov.

-jef



From michel.salim at gmail.com  Tue Mar 21 20:42:43 2006
From: michel.salim at gmail.com (Michel Salim)
Date: Tue, 21 Mar 2006 15:42:43 -0500
Subject: delrarpm in core or extras
In-Reply-To: <1cef3e950603210547s5b807042nd36e074fb458003b@mail.gmail.com>
References: <1cef3e950603210547s5b807042nd36e074fb458003b@mail.gmail.com>
Message-ID: <883cfe6d0603211242g2b474db1i48225b127fa4617b@mail.gmail.com>

On 3/21/06, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
> I have just tried the 'makedeltaiso' utility in the SuSE deltarpm 3.3
> package . I was able to produce a FC5 i386 DVD ISO, Test3 -> Final
> delta in only 300MB (10% of the size of the ISO).  xdelta didn't
> produce any savings.
>

Sounds quite useful to create smaller "Service Packs" - if I were to
install FC5 in a few months' time, say.

How well does deltarpm handle pre- and post- (un)install scripts?

--
Michel Salim
http://www.cs.indiana.edu/~msalim
http://the-dubois-papers.blogspot.com/



From cmadams at hiwaay.net  Tue Mar 21 20:50:41 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 21 Mar 2006 14:50:41 -0600
Subject: Mirrorlist missing mirrors?
In-Reply-To: <200603210926.25367.jkeating@redhat.com>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
	<200603210926.25367.jkeating@redhat.com>
Message-ID: <20060321205041.GF710737@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> download.fedoraproject.org is a redirector.  It uses the mirrors found in the 
> -redirect version of the file (not sure if this is done automatically or 
> somebody reads the -redirect file and updates some other list for 
> redirection).  Elliot Lee is the person who is managing the redirector, 
> perhaps he can chime in (I've cc'd him).  Theoretically each time you load a 
> valid url from download.fedoraproject.org it would use a new mirror.  Firefox 
> won't work for testing this, but using links again and again will show that 
> it does indeed to go different hosts.

Using a server-side redirector seems like a bad idea.  It completely
defeats the purpose of things like fastestmirror or even giving a user a
list of mirrors to choose from.
-- 
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  Tue Mar 21 21:36:13 2006
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 21 Mar 2006 16:36:13 -0500
Subject: Alsa patch for nvidia onboard sound
In-Reply-To: <fc33c1550603211057m7e812ba8mc45469a67e77780d@mail.gmail.com>
References: <fc33c1550603211057m7e812ba8mc45469a67e77780d@mail.gmail.com>
Message-ID: <1142976974.3146.1.camel@localhost.localdomain>

On Tue, 2006-03-21 at 13:57 -0500, Sadda Teh wrote:
> Might anyone be willing to apply the patch mentioned here:
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1895 (You have
> to click the Guest Login link to view) 
> 
> I, and probably many others have a motherboard affected by this bug.
> It would be much appreciated if the fix would make it into FC5.
> Thanks!

Unless patches are crashers, they likely won't make it into FC5 without
being in the upstream kernel.  Work with the ALSA project to make sure
that patch gets into the upstream kernel ASAP, and it will show up in
Fedora quite soon after that.

Part of this is for quality reasons; if the patch makes it into the
kernel, then it's likely it's good enough.  It's also for API reasons
and maintainability.  The less different Fedora kernels are from
upstream "vanilla" kernels, the less work it is to update Fedora kernels
every time a new upstream kernel is released.

Dan




From jspaleta at gmail.com  Tue Mar 21 21:42:35 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 16:42:35 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603211115y5294432w7b8e64c35a6dacb7@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>
	<200603211021.08997.jkeating@j2solutions.net>
	<604aa7910603211027m1f304ff1u9b9a7921f5906839@mail.gmail.com>
	<200603211100.49965.jkeating@j2solutions.net>
	<604aa7910603211115y5294432w7b8e64c35a6dacb7@mail.gmail.com>
Message-ID: <604aa7910603211342x2ed88ba5j837652bb410d5f6e@mail.gmail.com>

On 3/21/06, Jeff Spaleta <jspaleta at gmail.com> wrote:
> And if using -redirect directly also produces sporadic failures for
> some people with similiar clientside symptoms?  There are other,
> pre-existing issues which some users can run into.. things like
> timeout settings which could be mis-diagnosed as problems associated
> with the new redirect layer simply because the redirect process is new
> and opaque from the client pov.


Very frustrating... how do I help users who are complaining about errors like..
http://download.fedoraproject.org/pub/fedora/linux/core/updates/5/i386/repodata/primary.xml.gz:
[Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from updates: [Errno 256] No
more mirrors to try.

now that there is a serverside redirector in place.. how do I help
track down which mirror is out of sync so it can be reported
appropriate?

And appearantly even though there are multiple instances of the same
url in the mirrorlist, yum doesn't fail over to the next listing like
they are different mirrors like it use to when the mirrorlist was a
set of distinct mirrors. Instead the error occurs and yum bails like
there was only a single mirror in the list. The single repeated
redirecting URL appears to shortcircuit "mirrorlist" functionality.

-jef



From jkeating at redhat.com  Tue Mar 21 21:55:31 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 21 Mar 2006 13:55:31 -0800
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603211342x2ed88ba5j837652bb410d5f6e@mail.gmail.com>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603211115y5294432w7b8e64c35a6dacb7@mail.gmail.com>
	<604aa7910603211342x2ed88ba5j837652bb410d5f6e@mail.gmail.com>
Message-ID: <200603211355.35150.jkeating@redhat.com>

On Tuesday 21 March 2006 13:42, Jeff Spaleta wrote:
> Instead the error occurs and yum bails like
> there was only a single mirror in the list. The single repeated
> redirecting URL appears to shortcircuit "mirrorlist" functionality.

I am reverting to the old style of the complete mirror list.  The single 
redirector URL is not working as planned.  Please wait for the new mirror 
list files to make it to the live webserver.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/9531b664/attachment.sig>

From emeric.maschino at jouy.inra.fr  Tue Mar 21 21:55:43 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Tue, 21 Mar 2006 22:55:43 +0100
Subject: Re-enable r300 dri support
Message-ID: <1142978143.4420765f2426c@www.jouy.inra.fr>

Hi,

IIRC, the device IDs of the r300-based graphics adapters were removed from the
kernel just before the FC5 release, thus preventing to enable DRI on systems
sporting ATI Radeon 9500 and above graphics adapters. When will these device
IDs go back into the kernel so that we can test r300 dri support again?

Cheers,

   ?meric



From kanarip at pczone-clan.nl  Tue Mar 21 22:05:46 2006
From: kanarip at pczone-clan.nl (Jeroen van Meeuwen)
Date: Tue, 21 Mar 2006 23:05:46 +0100
Subject: Mirrorlist missing mirrors?
In-Reply-To: <200603211355.35150.jkeating@redhat.com>
Message-ID: <200603212205.k2LM5R0L028348@pinky.kanarip.com>


> I am reverting to the old style of the complete mirror list.  The single
> redirector URL is not working as planned.  Please wait for the new mirror
> list files to make it to the live webserver.

It seems to be yum that cannot cope with the redirects. Elliot Lee
recommended the fedora-users mailing list subscribers earlier today to leave
things as they are, but there's no estimated time for a solution.

Jef Spaleta:

> yum -d6 list updates  does not
> give me any information with regard to which mirror I'm being
> redirected to when pulling primary.xml.gz or repomd.xml.gz

>From my point of view yum treats the 'Baseurl(s) for repo:' as the mirror
(and does not take any redirection from that point).

Kind regards,
 
Jeroen van Meeuwen
 
--
kanarip



From sopwith at redhat.com  Tue Mar 21 22:25:42 2006
From: sopwith at redhat.com (Elliot Lee)
Date: Tue, 21 Mar 2006 17:25:42 -0500 (EST)
Subject: Mirrorlist missing mirrors?
In-Reply-To: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
Message-ID: <Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>

On Tue, 21 Mar 2006, Jeroen van Meeuwen wrote:

> It seems to be yum that cannot cope with the redirects.

The yum I have installed (yum-2.6.0-1) seems to handle the redirects fine.

I am all in favor of fixing what is broken, but so far the only specific
complaint has been from Jef about the difficulty of seeing what's going on
with things. Other than that, I guess I really need to understand the 
specifics of the problem so I can do my part to help fix them...

Best,
-- Elliot



From saddateh at gmail.com  Tue Mar 21 22:28:25 2006
From: saddateh at gmail.com (Sadda Teh)
Date: Tue, 21 Mar 2006 17:28:25 -0500
Subject: Alsa patch for nvidia onboard sound
In-Reply-To: <1142976974.3146.1.camel@localhost.localdomain>
References: <fc33c1550603211057m7e812ba8mc45469a67e77780d@mail.gmail.com>
	<1142976974.3146.1.camel@localhost.localdomain>
Message-ID: <fc33c1550603211428w50d0bd9fy9d0cf1c3af81e582@mail.gmail.com>

Understood, I'm assuming that the changes will go into the kernel once they
release their next RC (I hope). In the meantime I'll try to compile in the
patch myself and see if it actually makes a difference. BTW, great kernel
compilation instructions in the release notes. Thanks to whoever wrote
those. Now, I'll go pester the folks at Alsa to get that patch upstream.

On 3/21/06, Dan Williams <dcbw at redhat.com> wrote:
>
> On Tue, 2006-03-21 at 13:57 -0500, Sadda Teh wrote:
> > Might anyone be willing to apply the patch mentioned here:
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1895 (You have
> > to click the Guest Login link to view)
> >
> > I, and probably many others have a motherboard affected by this bug.
> > It would be much appreciated if the fix would make it into FC5.
> > Thanks!
>
> Unless patches are crashers, they likely won't make it into FC5 without
> being in the upstream kernel.  Work with the ALSA project to make sure
> that patch gets into the upstream kernel ASAP, and it will show up in
> Fedora quite soon after that.
>
> Part of this is for quality reasons; if the patch makes it into the
> kernel, then it's likely it's good enough.  It's also for API reasons
> and maintainability.  The less different Fedora kernels are from
> upstream "vanilla" kernels, the less work it is to update Fedora kernels
> every time a new upstream kernel is released.
>
> Dan
>
>
> --
> 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/20060321/4490ad83/attachment.htm>

From fedora at adslpipe.co.uk  Tue Mar 21 22:31:40 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Tue, 21 Mar 2006 22:31:40 +0000
Subject: Re-enable r300 dri support
In-Reply-To: <1142978143.4420765f2426c@www.jouy.inra.fr>
References: <1142978143.4420765f2426c@www.jouy.inra.fr>
Message-ID: <44207ECC.90309@adslpipe.co.uk>

?meric Maschino wrote:

> When will these device
> IDs go back into the kernel so that we can test r300 dri support again?

Sounds like it could be a while before it is sufficiently improved to 
make a re-appearance
https://www.redhat.com/archives/fedora-devel-list/2006-March/msg00737.html



From jspaleta at gmail.com  Tue Mar 21 22:32:40 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 17:32:40 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
Message-ID: <604aa7910603211432l41c9dd34k5b0ed48aaf1ddae9@mail.gmail.com>

On 3/21/06, Elliot Lee <sopwith at redhat.com> wrote:
> On Tue, 21 Mar 2006, Jeroen van Meeuwen wrote:
>
> > It seems to be yum that cannot cope with the redirects.
>
> The yum I have installed (yum-2.6.0-1) seems to handle the redirects fine.

It's difficult for me to make such a claim based on yum-2.6.0-1 output
that I have available. Things may very well be redirected as expected
but there's not information being provided which I can use to confirm
that.

On top of that.. the mirrorlist approach fails to failover to a 2nd
mirror if there is a sync problem.. when only the redirector is used
as the only mirror in the list..even if its repeated in the list. That
has to be counted as regression in functionality... even if the
redirecting is working. Again very difficult to know whats going on
here from the clientside. I'd really appreciate it if you could define
a reasonably useful recipe for generating auditable content that I can
direct users to use so we can track which mirrors are causing
problems.. or if the redirection itself is causing a problem.  Is the
only way to audit this going to be having users fire up packet
sniffers and logging individual packages for review? I'd really like
to avoid that.

-jef



From kanarip at pczone-clan.nl  Tue Mar 21 22:47:44 2006
From: kanarip at pczone-clan.nl (Jeroen van Meeuwen)
Date: Tue, 21 Mar 2006 23:47:44 +0100
Subject: Mirrorlist missing mirrors?
In-Reply-To: <Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
Message-ID: <200603212247.k2LMlGPP031554@pinky.kanarip.com>

> I am all in favor of fixing what is broken, but so far the only specific
> complaint has been from Jef about the difficulty of seeing what's going on
> with things. Other than that, I guess I really need to understand the
> specifics of the problem so I can do my part to help fix them...

It's just now that I receive from
http://fedora.redhat.com/download/mirrors/fedora-core-$releasever a proper
list of mirrors.

The problem seems to be solved by not providing a mirrorlist directed to
download.fedoraproject.org, which then again redirects, but instead provide
the mirrorlist at fedora.redhat.com.

Kind regards,
 
Jeroen van Meeuwen
 
--
kanarip



From sopwith at redhat.com  Tue Mar 21 22:57:54 2006
From: sopwith at redhat.com (Elliot Lee)
Date: Tue, 21 Mar 2006 17:57:54 -0500 (EST)
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603211432l41c9dd34k5b0ed48aaf1ddae9@mail.gmail.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
	<604aa7910603211432l41c9dd34k5b0ed48aaf1ddae9@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0603211736390.8498@devserv.devel.redhat.com>

On Tue, 21 Mar 2006, Jeff Spaleta wrote:

> It's difficult for me to make such a claim based on yum-2.6.0-1 output
> that I have available. Things may very well be redirected as expected
> but there's not information being provided which I can use to confirm
> that.

I agree that the lack of debug info is sucky. Is this something that can
be fixed with a yum update, or is the fastestmirror plugin distributed
separately?

> On top of that.. the mirrorlist approach fails to failover to a 2nd
> mirror if there is a sync problem..

Hmm, do you know if yum does the mirror selection on a per-file basis or
once for all the downloads for a particular repo during a particular
session?

Out of syncedness should only really be an issue for rawhide... Maybe
Updates as well to some extent, but updates doesn't churn nearly as much
and is more likely to be in sync between mirrors.

Best,
-- Elliot



From ralph+fedora at strg-alt-entf.org  Tue Mar 21 22:57:42 2006
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Tue, 21 Mar 2006 23:57:42 +0100
Subject: Mirrorlist missing mirrors?
In-Reply-To: <Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
Message-ID: <20060321225742.GA29804@br-online.de>

Elliot Lee wrote:
> I am all in favor of fixing what is broken, but so far the only specific
> complaint has been from Jef about the difficulty of seeing what's going on
> with things. Other than that, I guess I really need to understand the 
> specifics of the problem so I can do my part to help fix them...

I had yum bailing out on my when timeouts occured. It printed out
"Trying other mirror." and then complained about having run out of
available mirrors. 

At the moment (with the mirrorlist available), using different mirrors
works again:

| Downloading Packages:
| http://fedora.inode.at/updates/5/i386/bind-config-9.3.2-10.FC5.i386.rpm:
| [Errno 14] HTTP Error 404: Content-Type: text/html
| Content-Length: 345
| Date: Tue, 21 Mar 2006 22:51:14 GMT
| Server: lighttpd/1.4.11
| Trying other mirror.
| (1/4): bind-config-9.3.2- 100% |=========================|  50 kB 00:00

Second: Having the redirector on the serverside makes plugins like
fastestmirror completely useless, as only one mirror will be found and
tested. What happens if the server running the redirector goes down? 

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/20060321/74d2fb4e/attachment.sig>

From ajneil at gmail.com  Tue Mar 21 23:08:09 2006
From: ajneil at gmail.com (Alastair Neil)
Date: Tue, 21 Mar 2006 18:08:09 -0500
Subject: xenguest install problem
Message-ID: <85ac2ef40603211508h2ab0a5f8y7390be00d36c11ea@mail.gmail.com>

I am attempting to install a FC5 xen guest on a FC5  xen0 host via http from
a server with a file tree copied from the DVD-iso I downloaded via the
torrent.  The sha sum of the iso was correct.  The host was installed also
via http from the same server with no problems.  during the installation
anaconda bombs out with the following exception:

"GroupsError:  No Groups Available in any repository"

I wanted to check here to see if there is a chance I am doing something
stupid before filing a bug report.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/94c6e42b/attachment.htm>

From ajneil at gmail.com  Tue Mar 21 23:14:57 2006
From: ajneil at gmail.com (Alastair Neil)
Date: Tue, 21 Mar 2006 18:14:57 -0500
Subject: xenguest install problem
In-Reply-To: <85ac2ef40603211508h2ab0a5f8y7390be00d36c11ea@mail.gmail.com>
References: <85ac2ef40603211508h2ab0a5f8y7390be00d36c11ea@mail.gmail.com>
Message-ID: <85ac2ef40603211514q1d5144b7y516f0cff43a10859@mail.gmail.com>

never mind I believe I overwrote the repodata directory, sorry to bother
yall

On 3/21/06, Alastair Neil <ajneil at gmail.com> wrote:
>
> I am attempting to install a FC5 xen guest on a FC5  xen0 host via http
> from a server with a file tree copied from the DVD-iso I downloaded via the
> torrent.  The sha sum of the iso was correct.  The host was installed also
> via http from the same server with no problems.  during the installation
> anaconda bombs out with the following exception:
>
> "GroupsError:  No Groups Available in any repository"
>
> I wanted to check here to see if there is a chance I am doing something
> stupid before filing a bug report.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060321/b4f75084/attachment.htm>

From sopwith at redhat.com  Tue Mar 21 23:19:45 2006
From: sopwith at redhat.com (Elliot Lee)
Date: Tue, 21 Mar 2006 18:19:45 -0500 (EST)
Subject: Mirrorlist missing mirrors?
In-Reply-To: <20060321225742.GA29804@br-online.de>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
	<20060321225742.GA29804@br-online.de>
Message-ID: <Pine.LNX.4.58.0603211758450.8498@devserv.devel.redhat.com>

On Tue, 21 Mar 2006, Ralph Angenendt wrote:

> Elliot Lee wrote:
> > I am all in favor of fixing what is broken, but so far the only specific
> > complaint has been from Jef about the difficulty of seeing what's going on
> > with things. Other than that, I guess I really need to understand the 
> > specifics of the problem so I can do my part to help fix them...
> 
> I had yum bailing out on my when timeouts occured. It printed out
> "Trying other mirror." and then complained about having run out of
> available mirrors. 

That particular problem should have been fixed a little while ago...

> At the moment (with the mirrorlist available), using different mirrors
> works again:
>
> | Downloading Packages:
> | http://fedora.inode.at/updates/5/i386/bind-config-9.3.2-10.FC5.i386.rpm:
> | [Errno 14] HTTP Error 404: Content-Type: text/html
> | Content-Length: 345
> | Date: Tue, 21 Mar 2006 22:51:14 GMT
> | Server: lighttpd/1.4.11
> | Trying other mirror.
> | (1/4): bind-config-9.3.2- 100% |=========================|  50 kB 00:00
> 
> Second: Having the redirector on the serverside makes plugins like
> fastestmirror completely useless, as only one mirror will be found and
> tested. What happens if the server running the redirector goes down?

And what will happen if the server hosting the mirrorlist goes down? :)

I can't help with the fastestmirror thing per se, and I know there are
people who are on the same backbone as a fast mirror and would rather make
use of that mirror by default. Some people will be helped by GeoIP (slated
to happen sometime). And perhaps there can be a way for clients to report
back to the server which mirrors they find fastest, while still allowing
the server to have a voice in the redirect decision. Let's try to figure
out the best of both worlds...

We do have a redundant setup that should be able to handle a reasonable 
amount of problems, but nothing is foolproof.
-- Elliot



From ralph+fedora at strg-alt-entf.org  Tue Mar 21 23:31:24 2006
From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt)
Date: Wed, 22 Mar 2006 00:31:24 +0100
Subject: Mirrorlist missing mirrors?
In-Reply-To: <Pine.LNX.4.58.0603211758450.8498@devserv.devel.redhat.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
	<20060321225742.GA29804@br-online.de>
	<Pine.LNX.4.58.0603211758450.8498@devserv.devel.redhat.com>
Message-ID: <20060321233124.GB29804@br-online.de>

Elliot Lee wrote:
> On Tue, 21 Mar 2006, Ralph Angenendt wrote:
> > I had yum bailing out on my when timeouts occured. It printed out
> > "Trying other mirror." and then complained about having run out of
> > available mirrors. 
> 
> That particular problem should have been fixed a little while ago...

Depends on the "little while" :)

Happened to me around 4pm (GMT+0100).

> > Second: Having the redirector on the serverside makes plugins like
> > fastestmirror completely useless, as only one mirror will be found and
> > tested. What happens if the server running the redirector goes down?
> 
> And what will happen if the server hosting the mirrorlist goes down? :)

True. Fastestmirror only caches the hostname. 

> I can't help with the fastestmirror thing per se, and I know there are
> people who are on the same backbone as a fast mirror and would rather make
> use of that mirror by default. Some people will be helped by GeoIP (slated
> to happen sometime). And perhaps there can be a way for clients to report
> back to the server which mirrors they find fastest, while still allowing
> the server to have a voice in the redirect decision. Let's try to figure
> out the best of both worlds...

Well, I'd try to be "netfriendly", so GeoIP probably would be the best
solution. No need for my packets to travel across the pond :)

> We do have a redundant setup that should be able to handle a reasonable 
> amount of problems, but nothing is foolproof.

Yeah. But I hadn't seen problems like this afternoon before, as I had to
start the update process about 15 times to get all headers and packages
...

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/20060322/72ca6501/attachment.sig>

From jspaleta at gmail.com  Wed Mar 22 00:07:15 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 21 Mar 2006 19:07:15 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <Pine.LNX.4.58.0603211736390.8498@devserv.devel.redhat.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
	<604aa7910603211432l41c9dd34k5b0ed48aaf1ddae9@mail.gmail.com>
	<Pine.LNX.4.58.0603211736390.8498@devserv.devel.redhat.com>
Message-ID: <604aa7910603211607i58a39c86ka952bad8f24e3161@mail.gmail.com>

On 3/21/06, Elliot Lee <sopwith at redhat.com> wrote:
> I agree that the lack of debug info is sucky. Is this something that can
> be fixed with a yum update, or is the fastestmirror plugin distributed
> separately?

I can't answer that.. i haven't started my patent-pending process of
putting in random print statements into either the yum code, the
urlgrabber code or the fastestmirror plugin yet to see how much
information i can actually sneak out about where the redirect is
actually redirecting me.  And now that the rediector has been reverted
back to a list, I don't have a url to use my patent-pending print
statement insertion method with.

Let's be clear here... i only turned on the fastestmirror verbositing
because at the moment its the most verbose information I have without
putting random print statements in. This is also something in trying
to avoid because I want to be able to give instructions to users as
they experience problems so that the specifics of each incident can be
recorded. I'm really not prepared to tell people to patch their update
client willy-nilly, even if it is just python scripts. I don't want to
cause more errors with my patent-pending print statement insertion
method.

> Hmm, do you know if yum does the mirror selection on a per-file basis or
> once for all the downloads for a particular repo during a particular
> session?
>
> Out of syncedness should only really be an issue for rawhide...

Uhm... while i respect the "should only" point of view.. it was
definitely happening with the redirector for core and updates.

> Maybe
> Updates as well to some extent, but updates doesn't churn nearly as much
> and is more likely to be in sync between mirrors.

Again i cannot stress how difficult is to argue either way as to the
extent of mirror sync is going to be a problem if the redirector is
opaque with regard to which mirrors end up resulting in sync issues. 
If I can't track symptoms for reproducibility per mirror I'm just
going to advise people to open bug reports to try to accumulate stats
as to general occurance of the problem. But I know how that will end,
the bugs will be closed because there wont be enough information to do
anything about it.. per report.

-jef



From gemi at bluewin.ch  Wed Mar 22 00:50:17 2006
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Wed, 22 Mar 2006 01:50:17 +0100
Subject: Long wait after FC4 install
Message-ID: <1142988617.18449.2.camel@scriabin.tannenrauch.ch>

After the last package has been installed, the time left indicator
shows 2 minutes. However, I presume the installer enters the seconds
phase of yum install (Cleanup). This takes more than 2 minutes to say
the least. Even if there is harddisk activity, it would be better to
provide some feedback, just the same as with yum.
-- 
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich



From rspanton at gmail.com  Wed Mar 22 01:01:03 2006
From: rspanton at gmail.com (Robert Spanton)
Date: Wed, 22 Mar 2006 01:01:03 +0000
Subject: Mirrorlist missing mirrors?
In-Reply-To: <20060321205041.GF710737@hiwaay.net>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603210700p6958202dy9aff62b61a4d2b8d@mail.gmail.com>
	<200603210926.25367.jkeating@redhat.com>
	<20060321205041.GF710737@hiwaay.net>
Message-ID: <ab6786480603211701o40f03fdch8d462c90486acd22@mail.gmail.com>

Chris Adams <cmadams at hiwaay.net> wrote:
>
> Using a server-side redirector seems like a bad idea.  It completely
> defeats the purpose of things like fastestmirror or even giving a user a
> list of mirrors to choose from.
>

Rather than having the server side redirect done on requests for
http://download.fedoraproject.org/pub/fedora/linux/core/5/i386/os, perhaps
it would be better to shuffle the mirror list itself. Would the problems
that we're all encountering be avoided that way?

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

From jwboyer at jdub.homelinux.org  Wed Mar 22 01:12:22 2006
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Tue, 21 Mar 2006 19:12:22 -0600
Subject: Mirrorlist missing mirrors?
In-Reply-To: <604aa7910603211607i58a39c86ka952bad8f24e3161@mail.gmail.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
	<604aa7910603211432l41c9dd34k5b0ed48aaf1ddae9@mail.gmail.com>
	<Pine.LNX.4.58.0603211736390.8498@devserv.devel.redhat.com>
	<604aa7910603211607i58a39c86ka952bad8f24e3161@mail.gmail.com>
Message-ID: <1142989943.2693.3.camel@yoda.jdub.homelinux.org>

On Tue, 2006-03-21 at 19:07 -0500, Jeff Spaleta wrote:
> On 3/21/06, Elliot Lee <sopwith at redhat.com> wrote:
> 
> > Hmm, do you know if yum does the mirror selection on a per-file basis or
> > once for all the downloads for a particular repo during a particular
> > session?
> >
> > Out of syncedness should only really be an issue for rawhide...
> 
> Uhm... while i respect the "should only" point of view.. it was
> definitely happening with the redirector for core and updates.

I was seeing this last night as well.  Repeatedly retrying the yum
update make it finally succeed.  Presumably because it picked a new
mirror finally.

I have to agree with Jef here in that it does look like a regression to
the everyday user.

josh



From webmaster at margo.bijoux.nom.br  Wed Mar 22 01:39:18 2006
From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo)
Date: Tue, 21 Mar 2006 22:39:18 -0300
Subject: Wild and crazy times for the development tree
In-Reply-To: <1142913886.5442.18.camel@localhost>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<1142875085.3114.62.camel@laptopd505.fenrus.org>	<441EEDB3.3030008@mindspring.com>	<1142880311.3114.77.camel@laptopd505.fenrus.org>	<1142887210.23128.18.camel@price.stavtrup-st.dk>	<1142889303.3604.10.camel@T7.Linux>
	<1142913886.5442.18.camel@localhost>
Message-ID: <4420AAC6.5040709@margo.bijoux.nom.br>

Callum Lerwick wrote:
> Someone on IRC was arguing that in many parts of the world, bandwidth is
> very expensive. I don't see how 5 CDs to download vs a DVD make a
> difference here. The real question is, how common are DVD burners, and
> most importantly, DVD readers in various parts of the world.
>
>   
Please ignore that comment about bandwith.. I was a bit sleepy at the 
time and my brain was working in a weird way.
The issue really is DVD reader/burner availability as mentioned several 
times on this thread. Checking just two places directly connected to 
internet and technology that I have/had access to, I'd have to say that 
the number of DVD readers and burners is still very small, even in a 
major city here in Brazil (I live in the 3rd biggest city of the 
country). In my workplace (a company that specializes in tech support 
for other companies), we dont have a single DVD burner, we have two DVD 
readers that and all the other machines have CDs. In the university 
where I just finished my CS course, I know for sure of the existence of 
about 10 DVD burners in desktop computers/servers owned by the 
department, while most computers have a CD reader.

Another big issue is the availability of reliable DVD-/+R discs and 
their price. While in the US you can get a 50 pack for a relatively 
small price, here a 50 pack from a good brand is about 50 reais (about 
US$25,00. Just as a reference, the minimum wage here is R$300,00 or 
US$150,00) and you only can find those on ebay. You can also find some 
cheap discs for R$2,00 each, but then you better pray that it lasts 
enough time for you to remove the disk from the burner and put in the 
reader of the machine you want to install

As for the statistics cited by Bill Nottingham, I'm certain they're very 
favorable to DVD isos, specially if you consider that in the release 
notes and in the release announcement it's strongly suggested that 
bittorrent be used to download the DVD images since a few broken 
ftp/http clients and servers may not be able to handle such big files, 
while bittorrent works perfectly.

--
Pedro Macedo



From mike at miketc.com  Wed Mar 22 02:35:45 2006
From: mike at miketc.com (Mike Chambers)
Date: Tue, 21 Mar 2006 20:35:45 -0600
Subject: Announcing the release of Fedora Core 5
In-Reply-To: <Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>
References: <20060320161816.GB6976@nostromo.devel.redhat.com>
	<Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>
Message-ID: <1142994945.13027.6.camel@scrappy.miketc.com>

On Mon, 2006-03-20 at 15:56 -0500, Max Spevack wrote:

> For those of you who don't yet know me, let me introduce myself.  I've 
> been with Red Hat for about a year and a half, and over the course of the 
> last month I've transitioned from an engineering and quality assurance job 
> into a new role as Red Hat's Fedora Project Leader.
> 
> My job is to represent the Fedora Project within Red Hat, to work with all 
> of the leaders within the Fedora Project (the leaders within the community 
> as well as inside of the Red Hat fenceline), and to set priorities and 
> direction at the level of engineering, budget, testing, branding, 
> marketing, and community building.

How does this affect Rahul Sundaram and his position?  Not that I am
trying to butt into Red Hat's business or whatever, just that he seems
to be the voice of Red Hat/Reason since this beta cycle began and just
seeing who we will be talking to, and who will be making decisions on
things and such.

Maybe an explanation/diagram of who reports to who, and who says what
type thing? (as in , developers to Rahul, Rahul to you, you to a
committee, etc..? something like that).  Might let us all understand how
this works as far as names and stuff *shrug*.

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt, then it's hilarious!"



From cmadams at hiwaay.net  Wed Mar 22 03:40:08 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 21 Mar 2006 21:40:08 -0600
Subject: Mirrorlist missing mirrors?
In-Reply-To: <Pine.LNX.4.58.0603211758450.8498@devserv.devel.redhat.com>
References: <200603212205.k2LM5R0L028348@pinky.kanarip.com>
	<Pine.LNX.4.58.0603211721160.8498@devserv.devel.redhat.com>
	<20060321225742.GA29804@br-online.de>
	<Pine.LNX.4.58.0603211758450.8498@devserv.devel.redhat.com>
Message-ID: <20060322034008.GA1402349@hiwaay.net>

Once upon a time, Elliot Lee <sopwith at redhat.com> said:
> And what will happen if the server hosting the mirrorlist goes down? :)

It would probably be easy enough for yum (or a plugin) to cache the last
known mirrorlist.

> I can't help with the fastestmirror thing per se, and I know there are
> people who are on the same backbone as a fast mirror and would rather make
> use of that mirror by default. Some people will be helped by GeoIP (slated
> to happen sometime). And perhaps there can be a way for clients to report
> back to the server which mirrors they find fastest, while still allowing
> the server to have a voice in the redirect decision. Let's try to figure
> out the best of both worlds...

Well, what problem was the server-side redirection try to solve?  What
are the cons to having the client choose a mirror instead of the server?

-- 
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 dedourek at unb.ca  Wed Mar 22 04:28:27 2006
From: dedourek at unb.ca (John DeDourek)
Date: Wed, 22 Mar 2006 00:28:27 -0400
Subject: Wild and crazy times for the development tree
In-Reply-To: <dvo3ff$fbv$2@sea.gmane.org>
References: <1142873997.3002.15.camel@aglarond.local>	<20060320180853.2939eeac@soran.addix.net>	<441F21B1.5090902@mharris.ca>	<dvndou$llf$1@sea.gmane.org>	<441F4C3D.6040605@mharris.ca>	<1142914789.26492.67.camel@mccallum.corsepiu.local>
	<dvo3ff$fbv$2@sea.gmane.org>
Message-ID: <4420D26B.4050106@unb.ca>

Ian Pilcher wrote:

>Ralf Corsepius wrote:
>  
>
>>People are pragmatically using what they have/can get/are supplied with,
>>and will ditch the distro or even the OS if it doesn't suite to their
>>demands. Fortunately for Fedora, the proprietary drivers have worked
>>sufficiently well.
>>    
>>
>
>I have this gnawing feeling that ATI and nVIDIA are the twin rocks on
>which desktop Linux is going to founder.
>
>  
>
Or maybe low cost wireless cards that don't use firmware.



From laroche at redhat.com  Wed Mar 22 06:19:43 2006
From: laroche at redhat.com (Florian La Roche)
Date: Wed, 22 Mar 2006 07:19:43 +0100
Subject: delrarpm in core or extras
In-Reply-To: <883cfe6d0603211242g2b474db1i48225b127fa4617b@mail.gmail.com>
References: <1cef3e950603210547s5b807042nd36e074fb458003b@mail.gmail.com>
	<883cfe6d0603211242g2b474db1i48225b127fa4617b@mail.gmail.com>
Message-ID: <20060322061943.GA3913@dudweiler.stuttgart.redhat.com>

On Tue, Mar 21, 2006 at 03:42:43PM -0500, Michel Salim wrote:
> On 3/21/06, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
> > I have just tried the 'makedeltaiso' utility in the SuSE deltarpm 3.3
> > package . I was able to produce a FC5 i386 DVD ISO, Test3 -> Final
> > delta in only 300MB (10% of the size of the ISO).  xdelta didn't
> > produce any savings.
> >
> 
> Sounds quite useful to create smaller "Service Packs" - if I were to
> install FC5 in a few months' time, say.
> 
> How well does deltarpm handle pre- and post- (un)install scripts?

The deltas are used to re-create the full rpm packages, so no
information is lost if you use them.

regards,

Florian La Roche



From buildsys at redhat.com  Wed Mar 22 08:14:27 2006
From: buildsys at redhat.com (Build System)
Date: Wed, 22 Mar 2006 03:14:27 -0500
Subject: rawhide report: 20060322 changes
Message-ID: <200603220814.k2M8ERGu015967@porkchop.devel.redhat.com>

 

 
Updated Packages:

GConf2-2.14.0-1
---------------
* Sun Mar 19 2006 Ray Strode <rstrode at redhat.com> 2.14.0-1
- Update to 2.14.0

anaconda-11.1.0.0-1
-------------------
* Tue Mar 21 2006 Jeremy Katz <katzj at redhat.com> - 11.1.0.0-1
- Fix text for rescue images
- Fix some file contexts (#182252)
- Update for new xen kernel names
- Don't try to download package being erased (clumens, #184531)
- Don't show group selection on ks upgrade (pnasrat, #184528)
- Ignore conflicts on upgrade (pnasrat, #184461)
- Don't traceback trying to mount auto fs's (clumens, #182730)
- String fixes (clumens, #181916)
- rootpath fix (clumens, #185172) 
- Prompt for missing images on hd installs (clumens, #185274)
- Don't clobber network on upgrades (pnasrat, (#183203)
- Fix some syntax errors (#185275)
- Cap pe size at 128M (#185272)
- Conditionalize selinux (msw)
- Remove some obsolete code (msw, katzj)
- Ensure we don't ask for no longer needed cds if packages are 
  deselected (pnasrat, #185437) 
- Remove amharic and thai since we don't have fonts (clumens)
- Let's try not doing traceonly and see the size difference for minstg2.img
- Fix i5 (pnasrat, #186070)
- Misc cleanups to iutil (clumens)
- Use system-config-date for text-mode timezone too (clumens)

* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 10.92.17-1
- fix traceback in size check
- disable size check on upgrade (clumens, #184112)
- try to catch more failures to read repo metadata (clumens)
- only do runlevel 5 if graphical install (dcantrel, #184013)
- adjust to new xen kernel package naming
- add 'vesa' flag to force the use of the vesa driver
- more meaningful error messages on conflicts (pnasrat)
- ensure some dirs are labelled correct (#182252)

* Fri Mar 03 2006 Paul Nasrat <pnasrat at redhat.com> - 10.92.16-1
- Support Everything/globs in ks (pnasrat, clumens, #177621)
- Allow changes if not enough disk space (clumens, #183878)
- Set controlling tty in rescue mode (dcantrel,#182222)
- Sort list of languages (dcantrel)

authconfig-5.2.3-2
------------------
* Tue Mar 21 2006 Tomas Mraz <tmraz at redhat.com> - 5.2.3-2
- rebuilt

* Tue Mar 21 2006 Tomas Mraz <tmraz at redhat.com> - 5.2.3-1
- make smb.conf and krb5.conf loading more robust (#185766)

beagle-0.2.3-4
--------------
* Tue Mar 21 2006 Alexander Larsson <alexl at redhat.com> - 0.2.3-4
- Remove more instances of wrapper scripts starting apps in cwd.
  Fixes bug #185981, and CVE-2006-1296

* Fri Mar 17 2006 Ray Strode <rstrode at redhat.com> - 0.2.3-3
- use /sbin/nologin instead of /bin/nologin for beagle user
  shell

* Fri Mar 17 2006 Ray Strode <rstrode at redhat.com> - 0.2.3-2
- use /bin/nologin instead of /bin/false for beagle user
  shell

cairo-1.0.4-1
-------------
* Wed Mar 15 2006 Matthias Clasen <mclasen at redhat.com> - 1.0.4-1
- Update to 1.0.4
- Drop upstreamed patches

* Fri Mar 03 2006 Carl Worth <cworth at redhat.com> - 1.0.2-5
- add patch to chunk Xlib glyph compositing (bug 182416 and
  CVE-20060528)

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 1.0.2-4.2
- bump again for double-long bug on ppc(64)

curl-7.15.3-1
-------------
* Mon Mar 20 2006 Ivana Varekova <varekova at redhat.com> - 7.15.3-1
- fix multilib problem using pkg-config
- update to 7.15.3

* Thu Feb 23 2006 Ivana Varekova <varekova at redhat.com> - 7.15.1-2
- fix multilib problem - #181290 - 
  curl-devel.i386 not installable together with curl-devel.x86-64

evolution-connector-2.6.0-1
---------------------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.6.0-1
- 2.6.0

evolution-data-server-1.6.0-1
-----------------------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 1.6.0-1
- 1.6.0

gnome-power-manager-2.14.0-1
----------------------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- Update to 2.14.0

gnome-vfs2-2.14.0-2
-------------------
* Wed Mar 15 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-2
- don't try to install a schema we don't ship anymore (bug 185549)

gok-1.0.7-1
-----------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.de> 1.0.7-1
- Update to 1.0.7

gsf-sharp-0.6-9
---------------
* Tue Mar 21 2006 Caolan McNamara <caolanm at redhat.com> 0.6-9
- rebuild against new libgsf

gstreamer-0.10.4-1
------------------
* Thu Mar 16 2006 Ray Strode <rstrode at redhat.com> - 0.10.4-1
- Update to 0.10.4

* Tue Feb 14 2006 Rik van Riel <riel at redhat.com> - 0.10.3-3
- Obsolete gstreamer-plugins (#181296)

* Mon Feb 13 2006 Christopher Aillon <caillon at redhat.com> - 0.10.3-2
- Rebuild

gstreamer-plugins-base-0.10.5-1
-------------------------------
* Thu Mar 16 2006 Ray Strode <rstrode at redhat.de> 0.10.5-1	
- Update to 0.10.5

gthumb-2.7.5-1
--------------
* Mon Mar 20 2006 Matthias Clasen <mclasen at redhat.com> - 2.7.5-1
- Update to 2.7.5

initscripts-8.31.2-1
--------------------
* Fri Mar 17 2006 Bill Nottingham <notting at redhat.com> 8.31.2-1
- add udev helper to rename network devices on device creation

kernel-2.6.16-1.2074_FC6
------------------------
* Mon Mar 20 2006 Dave Jones <davej at redhat.com>
- 2.6.16 & 2.6.16-git1
- Tux 2.6.16-A0 (Just rediffing)
- Update Ingo's latency tracer patch.
- Update exec-shield to Ingo's latest.
  (Incorporates John Reiser's "map the vDSO intelligently" patch
   which increases the efficiency of prelinking - #162797).
- ACPI ecdt uid hack. (#185947)

librsvg2-2.14.2-2
-----------------
* Tue Mar 21 2006 Caolan McNamara <caolanm at redhat.com> 2.14.2-2
- rebuild against new libgsf

libsemanage-1.6.2-1
-------------------
* Tue Mar 21 2006 Dan Walsh <dwalsh at redhat.com> - 1.6.2
- Upgrade to latest from NSA
	* Merged Makefile PYLIBVER definition patch from Dan Walsh.
	* Merged man page reorganization from Ivan Gyurdiev.

libwpd-0.8.4-2
--------------
* Tue Mar 21 2006 Caolan McNamara <caolanm at redhat.com> 0.8.4-2
- rebuild for libgsf

libxklavier-2.2-1
-----------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.2-1
- Update to 2.2

logwatch-7.2.1-1
----------------
* Fri Mar 17 2006 Ivana Varekova <varekova at redhat.com> 7.2.1-1
- update to 7.2.1
- update nosegfault, pam_unix, http patches
- added sshd, smart, named, audit, secure and mountd services
  patches

net-snmp-5.3-5
--------------
* Mon Mar 20 2006 Radek Vokal <rvokal at redhat.com> 5.3-5
- allow disman/event-mib

policycoreutils-1.30.1-2
------------------------
* Tue Mar 21 2006 Dan Walsh <dwalsh at redhat.com> 1.30.1-2
- make restorecond only ignore non directories with lnk > 1

* Tue Mar 21 2006 Dan Walsh <dwalsh at redhat.com> 1.30.1-1
- Make audit2allow translate dontaudit as well as allow rules
- Update from upstream
	* Merged semanage labeling prefix patch from Ivan Gyurdiev.

* Tue Mar 21 2006 Dan Walsh <dwalsh at redhat.com> 1.30-5
- Fix audit2allow to retrieve dontaudit rules

pyorbit-2.14.0-1
----------------
* Mon Mar 13 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- Update to 2.14.0

rusers-0.17-46
--------------
* Tue Mar 21 2006 Phil Knirsch <pknirsch at redhat.com> - 0.17-46
- Included fix for correct return values for rup (#177419)

selinux-policy-2.2.25-1
-----------------------

setools-2.3-2
-------------
* Tue Mar 21 2006 Dan Walsh <dwalsh at redhat.com> 2.3-2
- Remove console apps for sediff, sediffx and apol

setup-2.5.50-1
--------------
* Tue Mar 21 2006 Florian La Roche <laroche at redhat.com> 2.5.50-1
- use stricter umask of 022 for all logins

* Thu Feb 23 2006 Phil Knirsch <pknirsch at redhat.com> 2.5.49-1
- Really switch to new /etc/services file
- Added /etc/fstab and /etc/mtab to ownership of setup (#177061)

* Tue Jan 31 2006 Phil Knirsch <pknirsch at redhat.com> 2.5.48-1
- Switched to the new large /etc/services file which fixes #112298, #133683,
  - Fixed pathmunge problem with bashrc (#123621)
- Removed /usr/X11R6/bin from default PATH (#173856)

shared-mime-info-0.17-1
-----------------------
* Thu Mar 16 2006 Matthiass Clasen <mclasen at redhat.com> - 0.17-1
- Update to 0.17

squid-7:2.5.STABLE13-1.FC5
--------------------------
* Tue Mar 21 2006 Martin Stransky <stransky at redhat.com> - 7:2.5.STABLE13-1.FC5
- update to new upstream

totem-1.4.0-2
-------------
* Tue Mar 14 2006 Ray Strode <rstrode at redhat.com> - 1.4.0-2
- Update to 1.4.0

* Mon Mar 13 2006 Matthias Clasen <mclasen at redhat.com> - 1.4.0-1
- Update to 1.4.0

xorg-x11-server-1.0.99.1-1
--------------------------
* Tue Mar 21 2006 Kristian H??gsberg <krh at redhat.com> 1.0.99.1-1
- Update to 1.0.99.1 snapshot.

* Mon Mar 06 2006 Jeremy Katz <katzj at redhat.com> - 1.0.1-8
- build libxf86config with -fPIC (#181292)
- fix sgi 1600sw extra mode (#182430)

* Wed Feb 22 2006 Jeremy Katz <katzj at redhat.com> 1.0.1-7
- install randrstr.h as part of sdk as required for building some drivers

xterm-211-1.FC6
---------------
* Tue Mar 21 2006 Jason Vas Dias <jvdias at redhat.com> - 211-1
- Upgrade to upstream version 211 (fixes bug 186094).
- Enable new 'utf8Title' resource by default

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From jamatos at fc.up.pt  Wed Mar 22 08:17:04 2006
From: jamatos at fc.up.pt (Jose' Matos)
Date: Wed, 22 Mar 2006 08:17:04 +0000
Subject: Long wait after FC4 install
In-Reply-To: <1142988617.18449.2.camel@scriabin.tannenrauch.ch>
References: <1142988617.18449.2.camel@scriabin.tannenrauch.ch>
Message-ID: <200603220817.04822.jamatos@fc.up.pt>

On Wednesday 22 March 2006 00:50, G?rard Milmeister wrote:
I guess that you made a mistake in title, it should be FC5. :-)

> After the last package has been installed, the time left indicator
> shows 2 minutes. However, I presume the installer enters the seconds
> phase of yum install (Cleanup). This takes more than 2 minutes to say
> the least. Even if there is harddisk activity, it would be better to
> provide some feedback, just the same as with yum.

  For me the ETA disappeared. I suspected also that the cleaning stage was 
occurring, as for large minutes the screen was the same.

  Using top I noticed that other than anaconda sometimes ld-config or 
gnome-*-icons were running that confirms my suspicion about the cleaning 
stage.

  Some sort of feedback would be nice. :-)
> --
> G?rard Milmeister
> Langackerstrasse 49
> CH-8057 Z?rich

-- 
Jos? Ab?lio



From stransky at redhat.com  Wed Mar 22 08:58:15 2006
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 22 Mar 2006 09:58:15 +0100
Subject: Alsa patch for nvidia onboard sound
In-Reply-To: <fc33c1550603211428w50d0bd9fy9d0cf1c3af81e582@mail.gmail.com>
References: <fc33c1550603211057m7e812ba8mc45469a67e77780d@mail.gmail.com>	<1142976974.3146.1.camel@localhost.localdomain>
	<fc33c1550603211428w50d0bd9fy9d0cf1c3af81e582@mail.gmail.com>
Message-ID: <442111A7.9080002@redhat.com>

The patch was merged to ALSA CVS so you may check the new alsa-driver 
(when it comes) or download the affected file from ALSA CVS and merge it 
to the latest driver package.
how-to is here - http://people.redhat.com/stransky/alsa
Ma.


Sadda Teh wrote:
> Understood, I'm assuming that the changes will go into the kernel once 
> they release their next RC (I hope). In the meantime I'll try to compile 
> in the patch myself and see if it actually makes a difference. BTW, 
> great kernel compilation instructions in the release notes. Thanks to 
> whoever wrote those. Now, I'll go pester the folks at Alsa to get that 
> patch upstream.
> 
> On 3/21/06, *Dan Williams* <dcbw at redhat.com <mailto:dcbw at redhat.com>> wrote:
> 
>     On Tue, 2006-03-21 at 13:57 -0500, Sadda Teh wrote:
>      > Might anyone be willing to apply the patch mentioned here:
>      > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1895
>     <https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1895> (You have
>      > to click the Guest Login link to view)
>      >
>      > I, and probably many others have a motherboard affected by this bug.
>      > It would be much appreciated if the fix would make it into FC5.
>      > Thanks!
> 
>     Unless patches are crashers, they likely won't make it into FC5 without
>     being in the upstream kernel.  Work with the ALSA project to make sure
>     that patch gets into the upstream kernel ASAP, and it will show up in
>     Fedora quite soon after that.
> 
>     Part of this is for quality reasons; if the patch makes it into the
>     kernel, then it's likely it's good enough.  It's also for API reasons
>     and maintainability.  The less different Fedora kernels are from
>     upstream "vanilla" kernels, the less work it is to update Fedora kernels
>     every time a new upstream kernel is released.
> 
>     Dan
> 
> 
>     --
>     fedora-devel-list mailing list
>     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> 



From gianluca.cecchi at gmail.com  Wed Mar 22 10:24:00 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Wed, 22 Mar 2006 11:24:00 +0100
Subject: weird characters installing netscape 7
Message-ID: <561c252c0603220224n606f8f6ft94f9bd37a8132f1a@mail.gmail.com>

I have some Dell 5324 network switches.
To manage them via web, with firefox or epiphany I get the message
"The following browsers are supported :
Microsoft Internet explorer 5.5 and above
Netscape Version 7.1 and above
"
I  downloaded netscape 7.2 full installer and tried to install it, but
I get weird characters in the first window and other ones....
Instead of characters in text and buttons, I get only small rectangles...
This is on fc5 x86_64, while the installer is an x86 binary; I don't
know if it can make any  difference
in README file there is for requirements:
      * glibc - 2.2.4
      * gtk+ - 1.2.0 (1.2.5 or later preferred)
      * XFree86-3.3.6
      * Glib 1.2.x
so it is quite old (infact netscape 8 is available only for Windows)
doing ldd of the installer bin I get:
[gcecchi at pevit00 netscape-installer]$ ldd ./netscape-installer-bin
         (0xffffe000)
        libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0xf7e33000)
        libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0xf7df6000)
        libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0xf7df3000)
        libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0xf7dc9000)
        libdl.so.2 => /lib/libdl.so.2 (0x00b99000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x0336b000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00101000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00cee000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00bc6000)
        libm.so.6 => /lib/libm.so.6 (0x00b9f000)
        libc.so.6 => /lib/libc.so.6 (0x00a64000)
        /lib/ld-linux.so.2 (0x00a47000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00ded000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00df2000)
while
file ./netscape-installer-bin
./netscape-installer-bin: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared
libs), for GNU/Linux 2.2.5, stripped

Any hint how to work around with installation or to trick the dell
switch to let it think I have netscape...?
Any hint on how to use wine eventually in a x86_64 fc5 system?
Thanks in advance
Gianluca



From gianluca.cecchi at gmail.com  Wed Mar 22 10:28:32 2006
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Wed, 22 Mar 2006 11:28:32 +0100
Subject: First Impressions
Message-ID: <561c252c0603220228x28895b19ide049a06cdf44e40@mail.gmail.com>

On Tue, 21 Mar 2006 19:11:21 -0800 (PST) Leslie Satenstein wrote:
>Screeen resolution is fine but movement actions are choppy
any information at least on your video card and your resolution and
some messages catched up from log file /var/log/Xorg.0.log????
otherwise it is not possible neither to guess.
Gianluca



From arjan at fenrus.demon.nl  Wed Mar 22 10:45:12 2006
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Wed, 22 Mar 2006 11:45:12 +0100
Subject: weird characters installing netscape 7
In-Reply-To: <561c252c0603220224n606f8f6ft94f9bd37a8132f1a@mail.gmail.com>
References: <561c252c0603220224n606f8f6ft94f9bd37a8132f1a@mail.gmail.com>
Message-ID: <1143024312.2955.56.camel@laptopd505.fenrus.org>

On Wed, 2006-03-22 at 11:24 +0100, Gianluca Cecchi wrote:
> I have some Dell 5324 network switches.
> To manage them via web, with firefox or epiphany I get the message
> "The following browsers are supported :
> Microsoft Internet explorer 5.5 and above
> Netscape Version 7.1 and above
> "
it's probably easiest to get one of those plugins that allow you to
override the browser ident string and fake to be IE :)



From kloczek at zie.pg.gda.pl  Wed Mar 22 11:51:59 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Wed, 22 Mar 2006 12:51:59 +0100
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
Message-ID: <1143028319.32736.2.camel@kloczek01.pracownicy.zie>

Dnia 21-03-2006, wto o godzinie 03:18 -0500, Build System napisa?(a):
[..] 
> bind-30:9.3.2-10.FC6
> --------------------
> * Mon Mar 20 2006 Jason Vas Dias <jvdias at redhat.com> - 30.9.3.2-10
> - fix bug 185969: more .spec file cleanup
> 
> * Wed Mar 08 2006 Jason Vas Dias <jvdias at redhat.com> - 30.9.3.2-8
> - Do not allow package to be installed if named:25 userid creation fails
> - Give libbind a pkg-config file
> - remove restorecon from bind-chroot-admin (not required).
> - fix named.caching-nameserver.conf (listen-on-v6 port 53 { ::1 };)

Last change breaks bind. After upgrade to this named is started
with /etc/named.caching-nameserver.conf as default config. 
Anyone performs some minimal testing after this kind changes ?

# ps aux | grep named
named    29968  0.1  0.1  64872  4720 ?        Ssl  11:55
0:00 /usr/sbin/named -u named -n 2 -c /etc/named.caching-nameserver.conf
-t /var/named/chroot

So after upgrade if someone was using non caching configuration this
upgrade f* named :>

IMO last revision (1.41) from /cvs/dist/devel/bind/named.init from CVS
repo can be reverted because using custom/non-default config file can be
used
by /etc/sysconfig/named::OPTIONS="-c /etc/named.caching-nameserver.conf".

Also ..

# rpm -qf /var/named/chroot/etc/named.conf
bind-chroot-9.3.2-10.FC6
bind-config-9.3.2-10.FC6

and ..

# rpm -e bind-config
error: Failed dependencies:
        caching-nameserver is needed by (installed)
NetworkManager-0.6.0-3.x86_64
# rpm -e NetworkManager
error: Failed dependencies:
        NetworkManager = 0.6.0-3 is needed by (installed)
NetworkManager-glib-0.6.0-3.x86_64
# rpm -e NetworkManager NetworkManager-glib bind-config
error: Failed dependencies:
        libnm_glib.so.0()(64bit) is needed by (installed)
evolution-2.6.0-1.x86_64

So .. now if someone uses evolution it is not possible use on the same
system use named with custom configuration.

First: IMO it will be good remove depedencies beetween named and
NetworkManager (now using NetworkManager determines using only localy
installed DNS).

Second: instead provide package with only configuration better will be
put template for aching nameserver configuration as commented part in by
default installed named.conf.

kloczek



From kloczek at zie.pg.gda.pl  Wed Mar 22 12:00:42 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Wed, 22 Mar 2006 13:00:42 +0100
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <1143028319.32736.2.camel@kloczek01.pracownicy.zie>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<1143028319.32736.2.camel@kloczek01.pracownicy.zie>
Message-ID: <1143028842.32736.6.camel@kloczek01.pracownicy.zie>

Dnia 22-03-2006, ?ro o godzinie 12:51 +0100, Tomasz K?oczko napisa?(a):
> # rpm -e NetworkManager
> error: Failed dependencies:
>         NetworkManager = 0.6.0-3 is needed by (installed)
> NetworkManager-glib-0.6.0-3.x86_64

This can be fixed by:

Index: NetworkManager.spec
===================================================================
RCS file: /cvs/dist/devel/NetworkManager/NetworkManager.spec,v
retrieving revision 1.98
diff -u -r1.98 NetworkManager.spec
--- NetworkManager.spec 3 Mar 2006 05:16:50 -0000       1.98
+++ NetworkManager.spec 22 Mar 2006 11:56:26 -0000
@@ -93,7 +93,6 @@
 %package glib
 Summary: Libraries for adding NetworkManager support to applications that use glib.
 Group: Development/Libraries
-Requires: %{name} = %{version}-%{release}
 Requires: dbus >= %{dbus_version}
 Requires: dbus-glib >= %{dbus_version}

kloczek



From david at lovesunix.net  Wed Mar 22 12:00:52 2006
From: david at lovesunix.net (David Nielsen)
Date: Wed, 22 Mar 2006 13:00:52 +0100
Subject: RFE: use -Os instead of -O2 for Fedora Core 6
Message-ID: <1143028852.2266.10.camel@price.stavtrup-st.dk>

Hi List

We talked briefly about this cirka mid-FC5 cycle and there seemed to be
a general agreement that it was an area of optimization that was worth
looking into. 

I've taken the liberty of backing up the research paper that grants us a
bit of hard data on this and putting it on my webserver:
http://lovesunix.net/spaceoptimization.pdf

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060322/dbce9914/attachment.sig>

From hughsient at gmail.com  Wed Mar 22 12:30:29 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 22 Mar 2006 12:30:29 +0000
Subject: Bootsplash?
Message-ID: <1143030630.2327.10.camel@localhost.localdomain>

Now that FC5 has hibernate working for lots of people, how about we do
something about the delay which currently is displayed as a black
screen?

I click the hibernate button, and am presented with the black screen for
about 30 seconds as my ram is swapped out to disk. At resume, I'm
presented with a black screen until the desktop re-appears.

I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think
that requires a patch to the kernel away from vanilla, so that might not
be an option for fedora. Maybe rhgb could be used instead?

Has any work been done, or ideas discussed on this for fedora? Thanks.

Richard.




From radekvokal at gmail.com  Wed Mar 22 13:32:07 2006
From: radekvokal at gmail.com (Radek =?ISO-8859-1?Q?Vok=E1l?=)
Date: Wed, 22 Mar 2006 14:32:07 +0100
Subject: FC5 and early-login
Message-ID: <1143034327.31932.9.camel@localhost.localdomain>

Where did early login go? I don't see gdm-early-login in initscripts .. 
-- 
Radek Vok?l <radekvokal at gmail.com>



From casimiro.barreto at gmail.com  Wed Mar 22 13:48:42 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Wed, 22 Mar 2006 10:48:42 -0300
Subject: Still having problems with kernel-2.6.15-1.2064_FC6
Message-ID: <442155BA.6060205@gmail.com>

Kernel kernel-2.6.15-1.2064_FC6 still have the most anoying problems 
when working with ASUS P4S800-MX SE:

It identifies de network device. But eth0 does not work and in the 
/var/messages we have really lots of:

Mar 22 10:23:22 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:23:22 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 22 10:23:30 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:23:30 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 22 10:23:38 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:23:38 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 22 10:23:39 terra freshclam[1895]: ERROR: Can't get information 
about database.clamav.net: Temporary DNS error
Mar 22 10:23:39 terra freshclam[1895]: ERROR: No servers could be 
reached. Giving up
Mar 22 10:23:39 terra freshclam[1895]: Trying again in 5 secs...
Mar 22 10:23:44 terra freshclam[1895]: ClamAV update process started at 
Wed Mar 22 10:23:44 2006
Mar 22 10:23:46 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:23:46 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 22 10:23:54 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:23:54 terra kernel: eth0: Transmit timeout, status 00000004 
00000240
Mar 22 10:24:02 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:02 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:24:04 terra freshclam[1895]: ERROR: Can't query 
current.cvd.clamav.net
Mar 22 10:24:04 terra freshclam[1895]: WARNING: Invalid DNS reply. 
Falling back to HTTP mode.
Mar 22 10:24:10 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:10 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:24:18 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:18 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:24:26 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:26 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:24:34 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:34 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:24:42 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:42 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:24:44 terra freshclam[1895]: ERROR: Can't get information 
about database.clamav.net: Temporary DNS error
Mar 22 10:24:44 terra freshclam[1895]: ERROR: No servers could be 
reached. Giving up
Mar 22 10:24:44 terra freshclam[1895]: Trying again in 5 secs...
Mar 22 10:24:49 terra freshclam[1895]: ClamAV update process started at 
Wed Mar 22 10:24:49 2006
Mar 22 10:24:50 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:50 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:24:58 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:24:58 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:25:06 terra kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 22 10:25:06 terra kernel: eth0: Transmit timeout, status 00000004 
00000241
Mar 22 10:25:09 terra freshclam[1895]: ERROR: Can't query 
current.cvd.clamav.net
Mar 22 10:25:09 terra freshclam[1895]: WARNING: Invalid DNS reply. 
Falling back to HTTP mode.

Aparently system identifies the f-ck-g ethernet port:

Mar 22 10:22:37 terra xinetd[1691]: xinetd Version 2.3.13 started with 
libwrap loadavg options compiled in.
Mar 22 10:22:37 terra kernel: sis900.c: v1.08.09 Sep. 19 2005
Mar 22 10:22:37 terra xinetd[1691]: Started working: 0 available services
*Mar 22 10:22:37 terra kernel: ACPI: PCI Interrupt Link [LNKD] enabled 
at IRQ 5
Mar 22 10:22:37 terra kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> 
Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
Mar 22 10:22:37 terra kernel: 0000:00:04.0: Realtek RTL8201 PHY 
transceiver found at address 1.
Mar 22 10:22:37 terra kernel: 0000:00:04.0: Using transceiver found at 
address 1 as default
Mar 22 10:22:37 terra kernel: eth0: SiS 900 PCI Fast Ethernet at 0xd400, 
IRQ 5, 00:13:d4:3c:34:be.*
Mar 22 10:22:37 terra kernel: ACPI: PCI Interrupt Link [LNKC] enabled at 
IRQ 10
Mar 22 10:22:37 terra kernel: ACPI: PCI Interrupt 0000:00:02.7[C] -> 
Link [LNKC] -> GSI 10 (level, low) -> IRQ 10

Not being able to test kernels newer than Linux terra.intramundi 
2.6.15-1.2009.4.2_FC5 #1 Thu Mar 2 18:10:16 EST 2006 i686 i686 i386 
GNU/Linux seems to be a real major setback...

By the other side, ASUS motherboards are common enough to attract 
atention from kernel developers... So, what is going so wrong with it 
that we have almost two months of uncompliance????

By the way.. there are also other setbacks: videodev does not work, so 
OV511 devices (like webcams) stay stoned deeeaaad.

Bye...

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

From clydekunkel7734 at cox.net  Wed Mar 22 13:56:41 2006
From: clydekunkel7734 at cox.net (Clyde E. Kunkel)
Date: Wed, 22 Mar 2006 08:56:41 -0500
Subject: Announcing the release of Fedora Core 5
In-Reply-To: <1142994945.13027.6.camel@scrappy.miketc.com>
References: <20060320161816.GB6976@nostromo.devel.redhat.com>	<Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>
	<1142994945.13027.6.camel@scrappy.miketc.com>
Message-ID: <44215799.3010101@cox.net>

Mike Chambers wrote:
> On Mon, 2006-03-20 at 15:56 -0500, Max Spevack wrote:
> 
>> For those of you who don't yet know me, let me introduce myself.  I've 
>> been with Red Hat for about a year and a half, and over the course of the 
>> last month I've transitioned from an engineering and quality assurance job 
>> into a new role as Red Hat's Fedora Project Leader.
>>
>> My job is to represent the Fedora Project within Red Hat, to work with all 
>> of the leaders within the Fedora Project (the leaders within the community 
>> as well as inside of the Red Hat fenceline), and to set priorities and 
>> direction at the level of engineering, budget, testing, branding, 
>> marketing, and community building.
> 
> How does this affect Rahul Sundaram and his position?  Not that I am
> trying to butt into Red Hat's business or whatever, just that he seems
> to be the voice of Red Hat/Reason since this beta cycle began and just
> seeing who we will be talking to, and who will be making decisions on
> things and such.
> 
> Maybe an explanation/diagram of who reports to who, and who says what
> type thing? (as in , developers to Rahul, Rahul to you, you to a
> committee, etc..? something like that).  Might let us all understand how
> this works as far as names and stuff *shrug*.
> 

I can't find the original msg in my mail folder nor in the archives. 
Was this a spoof?

-- 
Regards,

Old Fart



From jwboyer at jdub.homelinux.org  Wed Mar 22 14:00:34 2006
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Wed, 22 Mar 2006 08:00:34 -0600 (CST)
Subject: Announcing the release of Fedora Core 5
In-Reply-To: <44215799.3010101@cox.net>
References: <20060320161816.GB6976@nostromo.devel.redhat.com>	<Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>
	<1142994945.13027.6.camel@scrappy.miketc.com>
	<44215799.3010101@cox.net>
Message-ID: <6579.129.42.161.36.1143036034.squirrel@jdub.homelinux.org>

Clyde E. Kunkel wrote:
>
> I can't find the original msg in my mail folder nor in the archives.
> Was this a spoof?

No.  The original email went to fedora-announce and fedora-list.

josh



From jspaleta at gmail.com  Wed Mar 22 14:51:23 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 22 Mar 2006 09:51:23 -0500
Subject: Mirrorlist missing mirrors?
In-Reply-To: <200603211355.35150.jkeating@redhat.com>
References: <442003E3.7080801@argo.co.il>
	<604aa7910603211115y5294432w7b8e64c35a6dacb7@mail.gmail.com>
	<604aa7910603211342x2ed88ba5j837652bb410d5f6e@mail.gmail.com>
	<200603211355.35150.jkeating@redhat.com>
Message-ID: <604aa7910603220651j2508d7p159db73e99028c4a@mail.gmail.com>

On 3/21/06, Jesse Keating <jkeating at redhat.com> wrote:
> I am reverting to the old style of the complete mirror list.  The single
> redirector URL is not working as planned.  Please wait for the new mirror
> list files to make it to the live webserver.

I just want to clarify..I take it the behavior has been reverted again
back to the redirector approach?

I'm seeing the same behavior as was seen ealier in the day yesterday
with regard to catching an out of sync mirror and not being able to
failover to another mirror.  Should I start direct people to file bugs
about this behavior per occurance? And which component do I have them
file against?

I continue to see a failure to failover to a second mirror with the
redirector mirrorlist in place.  Even after running yum clean all and
confirming by visual inspection that the cache directory is clear of
cached metadata.
Errors like:
http://download.fedoraproject.org/pub/fedora/linux/core/5/i386/os/repodata/primary.xml.gz:
[Errno 12] Timeout: <urlopen error timed out>
Trying other mirror.
Error: failure: repodata/primary.xml.gz from core: [Errno 256] No more
mirrors to try.

or

http://download.fedoraproject.org/pub/fedora/linux/core/updates/testing/5/i386/repodata/primary.xml.gz:
[Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from updates-testing: [Errno
256] No more mirrors to try.

When I use the -redirect mirrorlist instead.. IF there is a checksum
mismatch because of an out of sync mirror then the failover to the
second mirror in the lis occurs as expected. Also I can't seem to
cause a checksum mismatch right after do a yum clean all when using
the -redirect list, whereas the default mirrorlist is failing with the
above errors multiple times right after a yum clean all. Not 100% of
the time, because I'm sure it depends on which mirror I'm redirected
to when i pull the repomd from and then which mirror i am redirected
to for the primary pull.

With the server-side redirector active, I'm assuming that every
communication to the server means a potentially different mirror. As
in the pull to get repomd.xml can be a different mirror than the
primary.xml? If thats true.. thats russian rulette when there is a
single out of sync mirror in the pool for redirection. I really wish I
knew more about how the redirect works, or I could probe the redirect
so I could understand the potential failure modes. This is really
frustrating. I'm really considering telling people to edit their
configs so they are using a flat list instead.

This is vastly different than the logic I'm use to with yum. Normally
when you have a flat list of potential mirrors yum will start with a
mirror in the list and if there is a failure situation, yum will
failover to the next mirror and continue with that mirror unless there
is another error. Yum will continue to do this until it runs out of
mirrors never going back to a previous mirror.  With the server-side
redirect is there any garuntee that the server-side redirect won't
redirect me to a problematic out-of-sync mirror a second time during
the transaction?

-jef



From rc040203 at freenet.de  Wed Mar 22 15:01:13 2006
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 22 Mar 2006 16:01:13 +0100
Subject: Announcing the release of Fedora Core 5
In-Reply-To: <6579.129.42.161.36.1143036034.squirrel@jdub.homelinux.org>
References: <20060320161816.GB6976@nostromo.devel.redhat.com>
	<Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>
	<1142994945.13027.6.camel@scrappy.miketc.com>
	<44215799.3010101@cox.net>
	<6579.129.42.161.36.1143036034.squirrel@jdub.homelinux.org>
Message-ID: <1143039673.3149.166.camel@mccallum.corsepiu.local>

On Wed, 2006-03-22 at 08:00 -0600, Josh Boyer wrote:
> Clyde E. Kunkel wrote:
> >
> > I can't find the original msg in my mail folder nor in the archives.
> > Was this a spoof?
> 
> No.  The original email went to fedora-announce and fedora-list.
So it didn't go to those who'd be affected most and got lost in the
fedora-list noise - Tumanilists ;)

Ralf




From dimi at lattica.com  Wed Mar 22 15:12:09 2006
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 22 Mar 2006 10:12:09 -0500
Subject: Anaconda: good work!
Message-ID: <131501c64dc2$fe1522b0$b6491b31@td612671>

Hi Jeremy,

Just wanted to share a few thoughts about anaconda,
while fresh in my mind (I've managed to install FC5
last night).

First impression: anaconda really rocks! This is a
very solid, pleasant installer.

I do have a few _minor_ points that I think would
make it a bit nicer to use:
  * PASS/FAIL color coding
    When testing disks, there's nothing in the way
    of visual feedback between the PASS/FAIL screens
    (I haven't actually seen the FAIL screen :), but
    I assume it hasn't changed since FC4)
    This is a screen that I tend to dismiss quickly,
    and I'm left with that nagging feeling that I didn't
    read the text right. A green/red background just for
    the word PASS/FAIL will help immensely.

  * The text based boot is ugly
    Rather minor point, but a graphical initial boot 
    would make for a less intimidating experience in
    this otherwise flawless graphical installer.

  * Disk change indicators
    Not sure it's worth the trouble, but it would be
    really nice if we got some ticks along the progress
    bar on when we can expect we will need to change
    the CDs. This would also tell someone which CDs are
    needed. It would help people a lot to manage their
    time during installs.

  * Links don't work in Release Notes
    Rather frustrating, considering the size of the doc.
    Links within the document should work, if they
    look like regular links (color, cursor)

  * External links in Release Notes are confusing
    These can't possibly work, it would be nice if we
    can disable them to avoid confusion.

  * Space does not page down in Release Notes
    I am so used to use space to page down in viewers,
    I really miss it when I can not do so.

  * Release Notes too big?
    I found them to be too big/verbose, especially for
    a light read during install. But maybe it's just me.

Hope this helps, and thank you again for the excellent installer.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From katzj at redhat.com  Wed Mar 22 15:44:29 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 22 Mar 2006 10:44:29 -0500
Subject: Bootsplash?
In-Reply-To: <1143030630.2327.10.camel@localhost.localdomain>
References: <1143030630.2327.10.camel@localhost.localdomain>
Message-ID: <1143042269.23468.6.camel@orodruin.boston.redhat.com>

On Wed, 2006-03-22 at 12:30 +0000, Richard Hughes wrote:
> Now that FC5 has hibernate working for lots of people, how about we do
> something about the delay which currently is displayed as a black
> screen?

Agreed that this isn't really ideal as it currently stands.

> I click the hibernate button, and am presented with the black screen for
> about 30 seconds as my ram is swapped out to disk. At resume, I'm
> presented with a black screen until the desktop re-appears.
> 
> I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think
> that requires a patch to the kernel away from vanilla, so that might not
> be an option for fedora. Maybe rhgb could be used instead?

With the swsusp code currently in the kernel, there isn't really a way
to do any sort of useful userspace stuff.  Also, rhgb has the downside
of being X based which tends to hit "interesting" corner cases and bugs.
All the options here kind of suck :-/

> Has any work been done, or ideas discussed on this for fedora? Thanks.

Nothing of any substance.  But this is a good way to start the
discussion :-)

Jeremy



From mattdm at mattdm.org  Wed Mar 22 15:47:06 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 22 Mar 2006 10:47:06 -0500
Subject: Anaconda: good work!
In-Reply-To: <131501c64dc2$fe1522b0$b6491b31@td612671>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
Message-ID: <20060322154706.GA16944@jadzia.bu.edu>

On Wed, Mar 22, 2006 at 10:12:09AM -0500, Dimi Paun wrote:
>   * The text based boot is ugly
>     Rather minor point, but a graphical initial boot 
>     would make for a less intimidating experience in
>     this otherwise flawless graphical installer.

That part has to remain small and failsafe....


>   * External links in Release Notes are confusing
>     These can't possibly work, it would be nice if we
>     can disable them to avoid confusion.

Why can't they possibly work?


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



From paul at city-fan.org  Wed Mar 22 15:51:03 2006
From: paul at city-fan.org (Paul Howarth)
Date: Wed, 22 Mar 2006 15:51:03 +0000
Subject: Anaconda: good work!
In-Reply-To: <131501c64dc2$fe1522b0$b6491b31@td612671>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
Message-ID: <44217267.3070002@city-fan.org>

Dimi Paun wrote:
    * Release Notes too big?
>     I found them to be too big/verbose, especially for
>     a light read during install. But maybe it's just me.

I upgraded a desktop box from FC4->FC5 yesterday, and my perception was 
that the process was significantly slower (perhaps taking twice as 
long?) as previous upgrades, e.g. FC3->FC4 on the same box. Can't 
explain why that should be, unless of course it was to give me plenty of 
time to read the release notes (which I was able to do in full during 
the process) :-)

Paul.



From dimi at lattica.com  Wed Mar 22 15:51:37 2006
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 22 Mar 2006 10:51:37 -0500
Subject: Anaconda: good work!
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<20060322154706.GA16944@jadzia.bu.edu>
Message-ID: <136b01c64dc8$81add950$b6491b31@td612671>

From: "Matthew Miller" <mattdm at mattdm.org>
> >   * The text based boot is ugly
> That part has to remain small and failsafe....

I realize why it's done this way, my comment
was from a user's perspective. We do have the
graphical splash at bootloader time, would it
be so risky to have it at boot time as well?

> >   * External links in Release Notes are confusing
> >     These can't possibly work, it would be nice if we
> >     can disable them to avoid confusion.
> 
> Why can't they possibly work?

Sorry, I did not realize anaconda does DHCP and such.
Even so, when upgrading does it configure the interfaces
according to the settings in the upgraded system?

Regardless, they didn't work for me :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From jvdias at redhat.com  Wed Mar 22 16:06:05 2006
From: jvdias at redhat.com (Jason Vas Dias)
Date: Wed, 22 Mar 2006 11:06:05 -0500
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <1143028319.32736.2.camel@kloczek01.pracownicy.zie>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<1143028319.32736.2.camel@kloczek01.pracownicy.zie>
Message-ID: <200603221106.06212.jvdias@redhat.com>

On Wednesday 22 March 2006 06:51, Tomasz K?oczko <kloczek at zie.pg.gda.pl> wrote:
>  Dnia 21-03-2006, wto o godzinie 03:18 -0500, Build System napisa?(a):
>>  
>  Last change breaks bind. After upgrade to this named is started
>  with /etc/named.caching-nameserver.conf as default config. 
>  Anyone performs some minimal testing after this kind changes ?
>  
Yes, I've been performing "maximal" testing with this configuration over
the past few weeks - no problems have been discovered.

The $ROOTDIR/etc/named.caching-nameserver.conf is ONLY used if no
$ROOTDIR/etc/named.conf file exists.
 
>  
>  So after upgrade if someone was using non caching configuration this
>  upgrade f* named :>
>  
Your point is ? 

>  IMO last revision (1.41) from /cvs/dist/devel/bind/named.init from CVS
>  repo can be reverted because using custom/non-default config file can be
>  used
>  by /etc/sysconfig/named::OPTIONS="-c /etc/named.caching-nameserver.conf".
>  
That would defeat the point, which is to allow a caching-only nameserver
configuration to be the default to be used only if no custom configuration exists.
  
>  # rpm -qf /var/named/chroot/etc/named.conf
>  bind-chroot-9.3.2-10.FC6
>  bind-config-9.3.2-10.FC6
>  
named.conf is a '%ghost' file in both these packages, to prevent removal of previous
versions of these packages from removing named.conf - there are no conflicts created
by two packages owning %ghost files.
 
>  and ..
>  
>  # rpm -e bind-config
>  error: Failed dependencies:
>          caching-nameserver is needed by (installed)
>  NetworkManager-0.6.0-3.x86_64

Right - bind-config Obsoletes: caching-nameserver, which is required by NetworkManager. 
>  
>  So .. now if someone uses evolution it is not possible use on the same
>  system use named with custom configuration.
>  
Wrong: simply create a $ROOTDIR/etc/named.conf with your custom configuration, and it
will be used instead of $ROOTDIR/etc/named.caching-nameserver.conf.

>  First: IMO it will be good remove depedencies beetween named and
>  NetworkManager (now using NetworkManager determines using only localy
>  installed DNS).
>  
NetworkManager works by configuring the local caching-nameserver named with D-BUS;
hence, it must depend on the 'caching-nameserver' functionality provided by the bind-config 
package.

>  Second: instead provide package with only configuration better will be
>  put template for aching nameserver configuration as commented part in by
>  default installed named.conf.
>  
That is in effect what has occurred: named.caching-nameserver.conf is ONLY used if no
named.conf exists. This has the bonus of not requiring ANY user intervention to obtain
a caching-nameserver.

I fail to see any "problems" with the new bind packages from the above description -
if you find any, please raise a bind bugzilla about them.

Thanks & Regards,
Jason Vas Dias<jvdias at redhat.com>
bind package maintainer



From jkeating at j2solutions.net  Wed Mar 22 16:11:37 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 22 Mar 2006 08:11:37 -0800
Subject: Anaconda: good work!
In-Reply-To: <44217267.3070002@city-fan.org>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
Message-ID: <200603220811.41062.jkeating@j2solutions.net>

On Wednesday 22 March 2006 07:51, Paul Howarth wrote:
> I upgraded a desktop box from FC4->FC5 yesterday, and my perception was
> that the process was significantly slower (perhaps taking twice as
> long?) as previous upgrades, e.g. FC3->FC4 on the same box. Can't
> explain why that should be, unless of course it was to give me plenty of
> time to read the release notes (which I was able to do in full during
> the process)

The use of yum in the installer makes it take a bit longer.  But it is far 
better than previous tools used.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060322/23cbeada/attachment.sig>

From jkeating at redhat.com  Wed Mar 22 16:16:02 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 22 Mar 2006 08:16:02 -0800
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <1143028319.32736.2.camel@kloczek01.pracownicy.zie>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<1143028319.32736.2.camel@kloczek01.pracownicy.zie>
Message-ID: <200603220816.02750.jkeating@redhat.com>

On Wednesday 22 March 2006 03:51, Tomasz K?oczko wrote:
> Last change breaks bind. After upgrade to this named is started
> with /etc/named.caching-nameserver.conf as default config.
> Anyone performs some minimal testing after this kind changes ?

Did you have a custom /etc/named.conf prior to the upgrade?   Did the upgrade 
remove this file?  Do you still have /etc/named.conf on your system and bind 
is refusing to use that and uses the /etc/named.caching-nameserver.conf ?

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060322/ce43889a/attachment.sig>

From mhuhtala at abo.fi  Wed Mar 22 16:25:21 2006
From: mhuhtala at abo.fi (Mikko Huhtala)
Date: Wed, 22 Mar 2006 18:25:21 +0200
Subject: FC5: Suspend and wireless success
Message-ID: <17441.31345.18633.309916@urquell.abo.fi>


Installed FC5 on a ThinkPad R50. 

Hibernation worked out of the box.

Got a firmware rpm for ipw2100 from freshrpms. Did not touch the
kernel, the modules or do any kind of config. Wireless networking and
the brilliant new NetworkManager just work.

I am deeply impressed.

Mikko




From jvdias at redhat.com  Wed Mar 22 16:31:23 2006
From: jvdias at redhat.com (Jason Vas Dias)
Date: Wed, 22 Mar 2006 11:31:23 -0500
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <200603220816.02750.jkeating@redhat.com>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<1143028319.32736.2.camel@kloczek01.pracownicy.zie>
	<200603220816.02750.jkeating@redhat.com>
Message-ID: <200603221131.23528.jvdias@redhat.com>

On Wednesday 22 March 2006 11:16, Jesse Keating <jkeating at redhat.com> wrote:
>  On Wednesday 22 March 2006 03:51, Tomasz K?oczko wrote:
>  > Last change breaks bind. After upgrade to this named is started
>  > with /etc/named.caching-nameserver.conf as default config.
>  > Anyone performs some minimal testing after this kind changes ?
>  
>  Did you have a custom /etc/named.conf prior to the upgrade?   Did the upgrade 
>  remove this file?  Do you still have /etc/named.conf on your system and bind 
>  is refusing to use that and uses the /etc/named.caching-nameserver.conf ?
>  

This is simply not possible. Any existing named.conf is preserved, 
and if any /etc/named.conf exists, /etc/named.caching-nameserver.conf 
is never used.
I've tested and retested this.

Unfortunately, even the default unmodified named.conf from the old 
caching-nameserver package would be preserved also, owing to recent
changes to caching nameserver to mark named.conf as "%config(noreplace)".

Anyone wanting only the caching-nameserver functionality, without a
customized nameserver, should remove any existing /etc/named.conf 
left over after upgrade to bind-config.

Regards,
Jason.



From pjones at redhat.com  Wed Mar 22 16:38:59 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 22 Mar 2006 11:38:59 -0500
Subject: CD verify on FC5 disc 5.
In-Reply-To: <200603212235.42252.russell@coker.com.au>
References: <200603212205.41086.russell@coker.com.au>
	<200603212235.42252.russell@coker.com.au>
Message-ID: <1143045539.24732.23.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-21 at 22:35 +1100, Russell Coker wrote:

> I burned a copy of CD 5 with 800 blank sectors at the end and it worked 
> perfectly.  I also noticed that CD 2 has the problem (although I hadn't 
> noticed it before), CDs 3 and 4 don't have a problem (I still have to repeat 
> tests on CD 1).
> 
> I guess that I can work around this problem by specifying a padsize of 
> something between 81 and 800 sectors (if some more friends want copies of FC5 
> then I'll find out soon).

Ok, so... what CD drive do you have, what type of bus is it on, and what
controller is in use?

-- 
  Peter



From katzj at redhat.com  Wed Mar 22 16:45:25 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 22 Mar 2006 11:45:25 -0500
Subject: Anaconda: good work!
In-Reply-To: <131501c64dc2$fe1522b0$b6491b31@td612671>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
Message-ID: <1143045925.24028.12.camel@orodruin.boston.redhat.com>

On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:
> First impression: anaconda really rocks! This is a
> very solid, pleasant installer.

Thanks -- always nice to see people not just flaming us :-P

> I do have a few _minor_ points that I think would
> make it a bit nicer to use:
>   * PASS/FAIL color coding
>     When testing disks, there's nothing in the way
>     of visual feedback between the PASS/FAIL screens
>     (I haven't actually seen the FAIL screen :), but
>     I assume it hasn't changed since FC4)
>     This is a screen that I tend to dismiss quickly,
>     and I'm left with that nagging feeling that I didn't
>     read the text right. A green/red background just for
>     the word PASS/FAIL will help immensely.

I think there's actually a bug about this.  Doing it in newt isn't as
easy as one would hope, though :-/  I do agree that making the
difference between pass and fail more obvious is probably a good idea.

>   * The text based boot is ugly
>     Rather minor point, but a graphical initial boot 
>     would make for a less intimidating experience in
>     this otherwise flawless graphical installer.

As others have said, the problem is that we're relatively space
constrained here.  rhgb ends up requiring X at which point we're using
way more space than we currently do.  Any other solution ends up
basically being the realm of kernel patches that aren't upstream

>   * Disk change indicators
>     Not sure it's worth the trouble, but it would be
>     really nice if we got some ticks along the progress
>     bar on when we can expect we will need to change
>     the CDs. This would also tell someone which CDs are
>     needed. It would help people a lot to manage their
>     time during installs.

This comes up from time to time, I'm just not fully convinced of how
useful it is.  One thing that we really probably need to look at for FC6
is revisiting the time remaining algorithm.  It seems that every few
releases we need to go in and really prod at it to make it more
accurate.  One of the not measurable things which has a pretty big
impact ends up being the various cache generators run as %post
scriptlets of packages.

>   * Links don't work in Release Notes
>     Rather frustrating, considering the size of the doc.
>     Links within the document should work, if they
>     look like regular links (color, cursor)

Yeah.  We didn't have HTML release notes until late in the game.  At
that point, I noticed but it was a bit risky to be going and making the
necessary changes to have them work.

>   * External links in Release Notes are confusing
>     These can't possibly work, it would be nice if we
>     can disable them to avoid confusion.

Hrm.  Not sure how to handle this.  They could conceivably work in
network installs, but are almost certainly a bad idea.  Maybe the way to
do this is to do some processing on the release notes file before we
feed it to the viewer

>   * Space does not page down in Release Notes
>     I am so used to use space to page down in viewers,
>     I really miss it when I can not do so.

This seems like it should be easy enough to implement

>   * Release Notes too big?
>     I found them to be too big/verbose, especially for
>     a light read during install. But maybe it's just me.

Yep, the Docs project has rocked at getting lots of content.  This has
the downside of there being lots of content.  Double-edged sword...

Jeremy



From katzj at redhat.com  Wed Mar 22 16:46:21 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 22 Mar 2006 11:46:21 -0500
Subject: Anaconda: good work!
In-Reply-To: <44217267.3070002@city-fan.org>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
Message-ID: <1143045982.24028.14.camel@orodruin.boston.redhat.com>

On Wed, 2006-03-22 at 15:51 +0000, Paul Howarth wrote:
> I upgraded a desktop box from FC4->FC5 yesterday, and my perception was 
> that the process was significantly slower (perhaps taking twice as 
> long?) as previous upgrades, e.g. FC3->FC4 on the same box. Can't 
> explain why that should be, unless of course it was to give me plenty of 
> time to read the release notes (which I was able to do in full during 
> the process) :-)

Yeah, we're aware that upgrades are slower.  This is partially due to
there being more scriplets doing more.  But I'm pretty sure there's
something else going on differently as well, just haven't had a chance
to track it down

Jeremy



From sundaram at fedoraproject.org  Wed Mar 22 17:01:54 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 22 Mar 2006 22:31:54 +0530
Subject: FC5 and early-login
In-Reply-To: <1143034327.31932.9.camel@localhost.localdomain>
References: <1143034327.31932.9.camel@localhost.localdomain>
Message-ID: <44218302.6070005@fedoraproject.org>

Radek Vok?l wrote:

>Where did early login go? I don't see gdm-early-login in initscripts .. 
>  
>
Stalled for a while. 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952

-- 
Rahul 





From rstrode at redhat.com  Wed Mar 22 17:27:34 2006
From: rstrode at redhat.com (Ray Strode)
Date: Wed, 22 Mar 2006 12:27:34 -0500
Subject: FC5 and early-login
In-Reply-To: <1143034327.31932.9.camel@localhost.localdomain>
References: <1143034327.31932.9.camel@localhost.localdomain>
Message-ID: <1143048455.2383.3.camel@halflap>

On Wed, 2006-03-22 at 14:32 +0100, Radek Vok?l wrote:
> Where did early login go? I don't see gdm-early-login in initscripts .. 
Work for it was shelved for the time being.

--Ray



From vd at paradigma.pt  Wed Mar 22 16:33:01 2006
From: vd at paradigma.pt (Vitor Domingos)
Date: Wed, 22 Mar 2006 16:33:01 +0000
Subject: FC5: Suspend and wireless success
In-Reply-To: <17441.31345.18633.309916@urquell.abo.fi>
References: <17441.31345.18633.309916@urquell.abo.fi>
Message-ID: <065964bf9f3e74cc8b3dc4b207aee30b@mail.paradigma.pt>

Hear, Hear!

I've got one strange problem[1] during install, but suspend and wireless worked out of the box.
With windows XP I need to install the network, video and sound drivers. With Fedora, it's as much as 1-2-3.

Good work guys!

[1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143

//VD

On Wed, 22 Mar 2006 18:25:21 +0200, Mikko Huhtala <mhuhtala at abo.fi> wrote:
> 
> Installed FC5 on a ThinkPad R50.
> 
> Hibernation worked out of the box.
> 
> Got a firmware rpm for ipw2100 from freshrpms. Did not touch the
> kernel, the modules or do any kind of config. Wireless networking and
> the brilliant new NetworkManager just work.
> 
> I am deeply impressed.
> 
> Mikko
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
//VD



From kloczek at zie.pg.gda.pl  Wed Mar 22 17:34:46 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Wed, 22 Mar 2006 18:34:46 +0100
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <200603220816.02750.jkeating@redhat.com>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<1143028319.32736.2.camel@kloczek01.pracownicy.zie>
	<200603220816.02750.jkeating@redhat.com>
Message-ID: <1143048886.32736.26.camel@kloczek01.pracownicy.zie>

Dnia 22-03-2006, ?ro o godzinie 08:16 -0800, Jesse Keating napisa?(a):
> On Wednesday 22 March 2006 03:51, Tomasz K?oczko wrote:
> > Last change breaks bind. After upgrade to this named is started
> > with /etc/named.caching-nameserver.conf as default config.
> > Anyone performs some minimal testing after this kind changes ?
> 
> Did you have a custom /etc/named.conf prior to the upgrade? 

Yes.

>   Did the upgrade remove this file?

No. It will be biggest bug than currently existing.

>   Do you still have /etc/named.conf on your system and bind 
> is refusing to use that and uses the /etc/named.caching-nameserver.conf ?


> # ls  /var/named/chroot/etc/ -1; ps aux | grep named
localtime
named.caching-nameserver.conf.
named.conf
named.conf~
named.conf.old
named.conf~.org
named.conf.rpmnew
named.custom
named.rfc1912.zones
rndc.conf
rndc.key
rndc.key.rpmnew
named     1514  0.2  0.2  72464 12152 ?        Ssl  12:11
0:56 /usr/sbin/named -u named -n 2 -t /var/named/chroot
kloczek  27335  0.0  0.0  58076   800 pts/13   S+   18:28   0:00 less
named.init

named.caching-nameserver.conf is not used only because now it dos not
exist (just renamed as you see).

kloczek




From rstrode at redhat.com  Wed Mar 22 17:36:33 2006
From: rstrode at redhat.com (Ray Strode)
Date: Wed, 22 Mar 2006 12:36:33 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143045982.24028.14.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
Message-ID: <1143048993.2383.9.camel@halflap>

On Wed, 2006-03-22 at 11:46 -0500, Jeremy Katz wrote:
> On Wed, 2006-03-22 at 15:51 +0000, Paul Howarth wrote:
> > I upgraded a desktop box from FC4->FC5 yesterday, and my perception was 
> > that the process was significantly slower (perhaps taking twice as 
> > long?) as previous upgrades, e.g. FC3->FC4 on the same box. Can't 
> > explain why that should be, unless of course it was to give me plenty of 
> > time to read the release notes (which I was able to do in full during 
> > the process) :-)
> 
> Yeah, we're aware that upgrades are slower.  This is partially due to
> there being more scriplets doing more.  But I'm pretty sure there's
> something else going on differently as well, just haven't had a chance
> to track it down
I think installing gconf schemas got slower with the gconf backend
changes.  This may have something to do with things, not sure.

If that is a significant cause of the slowdowns, we can partially
alleviate the problem, by changing all %post snippets from

for S in "<list of schemas here>"; do
  gconftool-2 --make-install-rule $S
done

to

gconftool-2 --make-install-rule <list of schemas here>



--Ray



From dimi at lattica.com  Wed Mar 22 17:38:28 2006
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 22 Mar 2006 12:38:28 -0500
Subject: Anaconda: good work!
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
Message-ID: <13fb01c64dd7$6ec8ab30$b6491b31@td612671>

From: "Jeremy Katz" <katzj at redhat.com>
> 
> Thanks -- always nice to see people not just flaming us :-P
> 

Hey, don't get fooled by the flames, there's a lot of love here.
We just get passionate about our views, that all :)

> >   * Disk change indicators
> 
> This comes up from time to time, I'm just not fully convinced of how
> useful it is.  

Coupled with a better time estimate, it would be useful, no doubt.
Also copying the contents of the CDs to the HD before hand would be
a very good idea too. But when that's not possible (due to free
space constraints), the ticks would be nice :)

> One thing that we really probably need to look at for FC6
> is revisiting the time remaining algorithm.

Ideed -- I think the algorihm takes into account stuff that
it should't: at end of disk 3 (I think) it said 15min left,
after putting in disk 4, it jumped to 75min (no good).

> >   * External links in Release Notes are confusing
> 
> Hrm.  Not sure how to handle this.  They could conceivably work in
> network installs, but are almost certainly a bad idea.  Maybe the way to
> do this is to do some processing on the release notes file before we
> feed it to the viewer

Disabling the external links would be a good idea. And that can
happen even before you put them on CD (use a special Release Notes
file just for showing during install).
 
> >   * Space does not page down in Release Notes
> 
> This seems like it should be easy enough to implement

Cool!
 
> >   * Release Notes too big?
> >     I found them to be too big/verbose, especially for
> >     a light read during install. But maybe it's just me.
> 
> Yep, the Docs project has rocked at getting lots of content.  This has
> the downside of there being lots of content.  Double-edged sword...

It seems like a classical case of "I didn't have time to write you a
small letter, so I wrote you a long one instead". :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From saddateh at gmail.com  Wed Mar 22 17:50:35 2006
From: saddateh at gmail.com (Sadda Teh)
Date: Wed, 22 Mar 2006 12:50:35 -0500
Subject: Alsa patch for nvidia onboard sound
In-Reply-To: <442111A7.9080002@redhat.com>
References: <fc33c1550603211057m7e812ba8mc45469a67e77780d@mail.gmail.com>
	<1142976974.3146.1.camel@localhost.localdomain>
	<fc33c1550603211428w50d0bd9fy9d0cf1c3af81e582@mail.gmail.com>
	<442111A7.9080002@redhat.com>
Message-ID: <fc33c1550603220950pb2ab23al209232d1ec252cdd@mail.gmail.com>

Sweet! I thought I was going to have to recompile the whole kernel to test
this out. So you're saying I can follow steps 1-5 with the drivers from CVS
and then reboot and I should be running the latest hda module? Or do I also
have to do step 6 as well? Thanks very much.

On 3/22/06, Martin Stransky <stransky at redhat.com> wrote:
>
> The patch was merged to ALSA CVS so you may check the new alsa-driver
> (when it comes) or download the affected file from ALSA CVS and merge it
> to the latest driver package.
> how-to is here - http://people.redhat.com/stransky/alsa
> Ma.
>
>
> Sadda Teh wrote:
> > Understood, I'm assuming that the changes will go into the kernel once
> > they release their next RC (I hope). In the meantime I'll try to compile
> > in the patch myself and see if it actually makes a difference. BTW,
> > great kernel compilation instructions in the release notes. Thanks to
> > whoever wrote those. Now, I'll go pester the folks at Alsa to get that
> > patch upstream.
> >
> > On 3/21/06, *Dan Williams* <dcbw at redhat.com <mailto:dcbw at redhat.com>>
> wrote:
> >
> >     On Tue, 2006-03-21 at 13:57 -0500, Sadda Teh wrote:
> >      > Might anyone be willing to apply the patch mentioned here:
> >      > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1895
> >     <https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1895> (You
> have
> >      > to click the Guest Login link to view)
> >      >
> >      > I, and probably many others have a motherboard affected by this
> bug.
> >      > It would be much appreciated if the fix would make it into FC5.
> >      > Thanks!
> >
> >     Unless patches are crashers, they likely won't make it into FC5
> without
> >     being in the upstream kernel.  Work with the ALSA project to make
> sure
> >     that patch gets into the upstream kernel ASAP, and it will show up
> in
> >     Fedora quite soon after that.
> >
> >     Part of this is for quality reasons; if the patch makes it into the
> >     kernel, then it's likely it's good enough.  It's also for API
> reasons
> >     and maintainability.  The less different Fedora kernels are from
> >     upstream "vanilla" kernels, the less work it is to update Fedora
> kernels
> >     every time a new upstream kernel is released.
> >
> >     Dan
> >
> >
> >     --
> >     fedora-devel-list mailing list
> >     fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
> >     https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060322/0ca4635d/attachment.htm>

From dragoran at feuerpokemon.de  Wed Mar 22 17:51:07 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 22 Mar 2006 18:51:07 +0100
Subject: Anaconda: good work!
In-Reply-To: <1143045982.24028.14.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
Message-ID: <44218E8B.2080503@feuerpokemon.de>

I don't know if this is a feature or a bug but it seems like a bug:
I tryed a harddisk install (the image was on /dev/md0 ) but I could'nt 
select it it only showed all /dev/sd(a|b)X but not /dev/md0
any reason for that or is this a bug?



From theaton at lanl.gov  Wed Mar 22 17:54:16 2006
From: theaton at lanl.gov (Tony Heaton)
Date: Wed, 22 Mar 2006 10:54:16 -0700
Subject: FC5 kickstart  i386 and x86_64
Message-ID: <1143050056.9830.16.camel@mlor.frop.net>

Hello,

I've downloaded FC5 for i386 and x86_64.  I do netboot kickstart
installs.  With FC3 and FC4, and previous I think, If I didn't have a
network stanza in the kickstart config file it would just bypass
configuring the interfaces and just use the one that was selected during
the boot process.  With FC5 it asks to configure all the interfaces.  If
I add a single network line to the config file it bypasses the interface
configuration again and configures on the interface in the config file.
My machines don't all use the same interface for network connectivity,
and I liked the way it worked before.  Any suggestions would be
appreciated.  Yes I have RTMF.

Thanks

-- 
Tony Heaton
CCN-9
(505) 667-9015
theaton at lanl.gov



From darrellpf at gmail.com  Wed Mar 22 17:54:24 2006
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 22 Mar 2006 09:54:24 -0800
Subject: The joys of rawhide returning to form
Message-ID: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>

For the last couple of weeks as rawhide settled into FC5 I had a
completely working system. Now that the freeze has been lifted for a
couple of days I yum updated this morning.

Printing broke.

There was a cups update. I think I saw a scriptlet fail. There appears
to be no default printer. Using the control panel to remove the
current (USB) printer and remake a new one doesn't help. Test printing
fails.

X broke

There was an X server update. I have an ATI Radeon R300 so am involved
in the DRI fray. In previous versions commenting out the load of the
DRI module worked but in the new version DRI looks like it is still
attempted and I get the black screen of death. Reverted to the X
server rpm off the FC5 cd.

ipw2200 broke

There was a kernel upgrade (2074) and now the driver won't load.
Booted the 2064 kernel which continues to work.

So that was no X, no wireless and no printing. Eeeks.

I'll try to file some bug reports when I get a chance.

darrell



From igorm5 at vip.hr  Wed Mar 22 18:11:06 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Wed, 22 Mar 2006 19:11:06 +0100
Subject: Unable to mount cd & dvd after upgrading to FC5
Message-ID: <4421933A.5060005@vip.hr>

Hi there!

I've just upgraded to FC5 (from FC4) and there is a problem. I can't
mount CD or DVD any more. I've never experienced that problem while I
was playing with Rawhide on my test system upgrading it to FC5, or on
clean FC5 install on my second test partition, but now on my main system
I have :-/ I know that "Fedora Core 5 now uses gnome-mount, a more
efficient mechanism that replaces fstab-sync, and uses HAL to handle
mounting", but it does not work after the upgrade via install media
(which went ok BTW). I even tried to run hal deamon manually, to play
with gnome-mount and so on, but all of that didn't help. I tried to 'rpm
-V hal', but I got no output. Is there any way to solve that problem
manually? To make hal to detect my hdc and hdd devices? Any help would
be highly appreciated.

Thanks. Cheers!

-- 
Igor Jagec



From jvdias at redhat.com  Wed Mar 22 18:16:37 2006
From: jvdias at redhat.com (Jason Vas Dias)
Date: Wed, 22 Mar 2006 13:16:37 -0500
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <1143048692.32736.22.camel@kloczek01.pracownicy.zie>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<200603221106.06212.jvdias@redhat.com>
	<1143048692.32736.22.camel@kloczek01.pracownicy.zie>
Message-ID: <200603221316.37356.jvdias@redhat.com>

I am very sorry about this.
It appears a typo in the /etc/rc.d/init.d/named initscript that
could cause /etc/named.caching-nameserver to be used when /etc/named.conf 
exists was mistakenly checked into CVS, and was not the version I was testing
with :-(
A new bind-9.3.2-12.{FC5,FC6} is now being built and pushed to updates ASAP.
Regards,
Jason Vas Dias.



From sundaram at fedoraproject.org  Wed Mar 22 19:26:08 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 23 Mar 2006 00:56:08 +0530
Subject: Anaconda: good work!
In-Reply-To: <131501c64dc2$fe1522b0$b6491b31@td612671>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
Message-ID: <4421A4D0.8010406@fedoraproject.org>

Dimi Paun wrote:

>
>  * Release Notes too big?
>    I found them to be too big/verbose, especially for
>    a light read during install. But maybe it's just me.
>
>  
>
Pretty much all of the information supplied in the release notes are 
just things that users have asked for in the previous releases. We have 
tried adding references where required to help avoid too much verbosity 
but it's unlikely that we will be able to drop off the information 
without alienating a portion of the end users.  I am looking at 
providing a better simple overview by default with links to more 
detailed technical notes.


-- 
Rahul 





From zuirdj at gmail.com  Wed Mar 22 19:35:53 2006
From: zuirdj at gmail.com (Zuir DJ)
Date: Wed, 22 Mar 2006 15:35:53 -0400
Subject: FC5 and early-login
In-Reply-To: <44218302.6070005@fedoraproject.org>
References: <1143034327.31932.9.camel@localhost.localdomain>
	<44218302.6070005@fedoraproject.org>
Message-ID: <cc692e9b0603221135m320ff9b7r5d0b7f8fe6cb8eb9@mail.gmail.com>

On 3/22/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Radek Vok?l wrote:
>
> >Where did early login go? I don't see gdm-early-login in initscripts ..
> >
> >
> Stalled for a while.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952

The most CC'ed bugzilla entry... :-)

--
Zuirdj



From cmadams at hiwaay.net  Wed Mar 22 19:32:39 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 22 Mar 2006 13:32:39 -0600
Subject: Anaconda: good work!
In-Reply-To: <1143045925.24028.12.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
Message-ID: <20060322193239.GC1115919@hiwaay.net>

Once upon a time, Jeremy Katz <katzj at redhat.com> said:
> On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:
> >     A green/red background just for
> >     the word PASS/FAIL will help immensely.
> 
> I think there's actually a bug about this.  Doing it in newt isn't as
> easy as one would hope, though :-/  I do agree that making the
> difference between pass and fail more obvious is probably a good idea.

Don't use a green/red background as the difference; color blind people
can't tell the difference.

In text mode, extra line drawing characters (e.g. "---> FAIL <---") or
blinking text (does the Linux console support that attribute?) would be
preferable.

Another option would be to make the default selection box on the FAIL
screen do nothing, so just hitting ENTER won't continue (you'd have to
TAB to the "Continue" box).

-- 
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 rhally at mindspring.com  Wed Mar 22 19:44:36 2006
From: rhally at mindspring.com (Richard Hally)
Date: Wed, 22 Mar 2006 14:44:36 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143045925.24028.12.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
Message-ID: <4421A924.9090501@mindspring.com>

Jeremy Katz wrote:
> On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:
>> First impression: anaconda really rocks! This is a
>> very solid, pleasant installer.
> 
> Thanks -- always nice to see people not just flaming us :-P
> 

Very nice!!

> 
>>   * Disk change indicators
>>     Not sure it's worth the trouble, but it would be
>>     really nice if we got some ticks along the progress
>>     bar on when we can expect we will need to change
>>     the CDs. This would also tell someone which CDs are
>>     needed. It would help people a lot to manage their
>>     time during installs.
> 
> This comes up from time to time, I'm just not fully convinced of how
> useful it is.  One thing that we really probably need to look at for FC6
> is revisiting the time remaining algorithm.  It seems that every few
> releases we need to go in and really prod at it to make it more
> accurate.  One of the not measurable things which has a pretty big
> impact ends up being the various cache generators run as %post
> scriptlets of packages.
>> 
Just an idea, instead of/in addition would it be possible to show the 
number of packages and update that? e.g. [19/725] or what ever RPM has 
available.




From sundaram at fedoraproject.org  Wed Mar 22 20:15:38 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 23 Mar 2006 01:45:38 +0530
Subject: The Morning After
In-Reply-To: <200603210156.40386.nman64@n-man.com>
References: <200603210156.40386.nman64@n-man.com>
Message-ID: <4421B06A.8030809@fedoraproject.org>

Patrick Barnes wrote:

>To start off, congratulations are in order for everyone who was involved in 
>bringing Fedora Core 5 to fruition.  Fedora Core 5 is the most outstanding 
>Fedora Core release to date, and we've seen a lot of progress since Fedora 
>Core 4.  Thank you and congratulations to everyone!
>
>Overall, I think the Fedora Core 5 release was a great success.  We had a few 
>minor glitches, as will always happen on release day, but things really came 
>together to deliver this awesome release in an awesome way.
>
>While the excitement is still strong, let's look back over the events leading 
>up to and immediately following the release, and see what we can do to make 
>things better both for the lifetime of this release and for future releases.
>
>Over the weekend, we saw quite a few leaked ISOs flying around.  This is to be 
>expected, but we need to try to minimize this to avoid potential problems.  
>We also saw a large number of users take advantage of BitTorrent, which 
>greatly reduced demand on the main servers, but, as always, people are always 
>looking for more bandwidth. 
>
Documentation on downloads, checking ISO images and using Bittorrent 
should be better. The fact that we can do a minimal installation with a 
single CD,  a desktop class installation in 2 CD's or a network 
installation with boot.iso image is far from clear to everyone involved. 
It has been offered for years and people continue to request it as a new 
feature not being aware that it exists already in just about every 
release. Kickstart should be much better advertised.

> We've got plans in the works that will help, but 
>there's always room for more improvement.  It is great that there is so much 
>interest, so how can we best support that interest without failing our 
>release goals?
>
>A lot of switches and buttons had to be operated manually for this release.  
>We could almost certainly add automation and scheduling, and we could 
>streamline processes to make life easier on ourselves.
>
>  
>
The build system needs to be exploited to provide more information. The 
bugs closed and new features implemented  between every release 
including the test releases with bugzilla references. Refer to 
http://www.squarefree.com/burningedge/ for what I have in mind. The 
documentation specified in the RPM specs on every package should be 
available in the documentation page in revisions. This will make it 
easier to point to a particular man page or refer to it.

>We had to update a lot of information on both fedora.redhat.com and 
>fedoraproject.org.  We have some unnecessary duplication, and there are 
>places where we can get things working a little more smoothly.  Jesse, and 
>anyone else working on these things, what did you notice?  How can we improve 
>the process?
>  
>
High time we got rid of fedora.redhat.com and launch fedoraproject.org 
with a new design.

>It took a fair chunk of the day to get the latest release notes up on the 
>website and working properly. 
>
The release announcement should have had a link to the known issues page 
- http://fedoraproject.org/wiki/Bugs/FC5Common and publishing the 
release notes has always been in the last minute. We should do this 
earlier when we start pushing ISO images to the mirror. The release 
process and tasks being done should be  publicly documentation to make 
the information more transparent and possibly delegate tasks within the 
community as much as possible. Other development processes such as 
release targets, blockers and other tasks within the development process 
of Fedora should be available to everyone interested.

> Surely, we can automate some of this.  I know 
>a lot of work is going into getting the build tools working better, but what 
>else can we do to simplify this for a prompt release reaction?
>
>There were a few other technical errors or delays, such as those that prompted 
>symlinking torrent URLs and the update to the release announcement, the lack 
>of the planned instructions for CD-burning in the distribution directories, 
>and a few known flaws in the final release.  These kinds of things are bound 
>to happen, especially when internal issues arise just before the release, but 
>that's no reason to ignore them.  What did we miss, and how can we make sure 
>we get it right next time?
>
>Finally, there has been a lot of buzz leading up to and following the release.  
>We saw a refreshing surge even before the release hit.  That's great, but the 
>buzz could still be bigger.  We saw a few reviews of the test releases, and 
>many sites have published new information in the last 24 hours, but how can 
>we generate more of this?  Did anybody notice particular areas that were 
>undersold?
>  
>
I should have done the tour better - 
http://fedoraproject.org/wiki/Tours/FedoraCore5. Next time we should do 
this starting from the first test releases. Hopefully we get more 
testers and feedback that way too. The front page of fedora.redhat.com 
was too boring and pretty much no changes while we should have been 
shouting about the new release from the roof top.

>Now is the time for radical thoughts and ideas that can shape what we do to 
>support Fedora Core 5 and prepare for Fedora Core 6.  Let's hear them!
>
>  
>
Thats pretty much it for now. We have a roadmap page at 
http://fedoraproject.org/wiki/RoadMap.


-- 
Rahul 





From hughsient at gmail.com  Wed Mar 22 20:26:25 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 22 Mar 2006 20:26:25 +0000
Subject: Bootsplash?
In-Reply-To: <1143042269.23468.6.camel@orodruin.boston.redhat.com>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
Message-ID: <1143059186.28627.6.camel@localhost.localdomain>

On Wed, 2006-03-22 at 10:44 -0500, Jeremy Katz wrote:
> On Wed, 2006-03-22 at 12:30 +0000, Richard Hughes wrote:
> > I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think
> > that requires a patch to the kernel away from vanilla, so that might not
> > be an option for fedora. Maybe rhgb could be used instead?
> 
> With the swsusp code currently in the kernel, there isn't really a way
> to do any sort of useful userspace stuff.  Also, rhgb has the downside
> of being X based which tends to hit "interesting" corner cases and bugs.
> All the options here kind of suck :-/

Even displaying a static bitmap (a-la-windows 98) would be better than
the black we have now. Not sure if that makes it simpler.

Richard.



From sundaram at fedoraproject.org  Wed Mar 22 20:27:41 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 23 Mar 2006 01:57:41 +0530
Subject: Announcing the release of Fedora Core 5
In-Reply-To: <44215799.3010101@cox.net>
References: <20060320161816.GB6976@nostromo.devel.redhat.com>
	<Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>
	<1142994945.13027.6.camel@scrappy.miketc.com>
	<44215799.3010101@cox.net>
Message-ID: <1143059261.3802.1.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-22 at 08:56 -0500, Clyde E. Kunkel wrote:
> Mike Chambers wrote:

> > How does this affect Rahul Sundaram and his position? 

It doesnt. My day job doesnt have anything to do with Fedora so far. 

Rahul



From thomas.canniot at laposte.net  Wed Mar 22 20:29:26 2006
From: thomas.canniot at laposte.net (Thomas Canniot)
Date: Wed, 22 Mar 2006 21:29:26 +0100
Subject: Anaconda: good work!
In-Reply-To: <131501c64dc2$fe1522b0$b6491b31@td612671>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
Message-ID: <1143059367.5126.9.camel@MrTomLinux.workstation>

As Dimi Paun just shared his thoughts about anaconda, here is what i'm
dreaming of for anaconda.

What I found sad in anaconda during the installation process is the
permanent showing of our brand new logo for about 20 min, while anaconda
is copying files. We had in previous version of FC, texts talking about
the distribution itself. These have disappeared, too bad really.

Maybe we could do something here that really helps people, newbies who
are just installing their first linux distribution. I dreamt of an
anaconda that helps newbies make their first steps in Fedora Core.

Here is a mockup i made showing anaconda copying files and delivering
some help at the same time!

http://mrtomlinux.org/Up2date&anaconda-en.png

Of course, many topics could be reached this way, and that would make
Fedorz Core an even more user-friendly distribution.

Of course, many geeks won't like the idea because it is not a brand new
feature, or because they may feel bored reading through this kind of
newbies' help.

Tell me what you think about it!

Regards,

Thomas Canniot

Le mercredi 22 mars 2006 ? 10:12 -0500, Dimi Paun a ?crit :
> Hi Jeremy,
> 
> Just wanted to share a few thoughts about anaconda,
> while fresh in my mind (I've managed to install FC5
> last night).
> 
> First impression: anaconda really rocks! This is a
> very solid, pleasant installer.
> 
> I do have a few _minor_ points that I think would
> make it a bit nicer to use:
>   * PASS/FAIL color coding
>     When testing disks, there's nothing in the way
>     of visual feedback between the PASS/FAIL screens
>     (I haven't actually seen the FAIL screen :), but
>     I assume it hasn't changed since FC4)
>     This is a screen that I tend to dismiss quickly,
>     and I'm left with that nagging feeling that I didn't
>     read the text right. A green/red background just for
>     the word PASS/FAIL will help immensely.
> 
>   * The text based boot is ugly
>     Rather minor point, but a graphical initial boot 
>     would make for a less intimidating experience in
>     this otherwise flawless graphical installer.
> 
>   * Disk change indicators
>     Not sure it's worth the trouble, but it would be
>     really nice if we got some ticks along the progress
>     bar on when we can expect we will need to change
>     the CDs. This would also tell someone which CDs are
>     needed. It would help people a lot to manage their
>     time during installs.
> 
>   * Links don't work in Release Notes
>     Rather frustrating, considering the size of the doc.
>     Links within the document should work, if they
>     look like regular links (color, cursor)
> 
>   * External links in Release Notes are confusing
>     These can't possibly work, it would be nice if we
>     can disable them to avoid confusion.
> 
>   * Space does not page down in Release Notes
>     I am so used to use space to page down in viewers,
>     I really miss it when I can not do so.
> 
>   * Release Notes too big?
>     I found them to be too big/verbose, especially for
>     a light read during install. But maybe it's just me.
> 
> Hope this helps, and thank you again for the excellent installer.
> 
> -- 
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
> 



From codeshepherd at gmail.com  Thu Mar 23 07:21:22 2006
From: codeshepherd at gmail.com (Deepan Chakravarthy)
Date: Thu, 23 Mar 2006 02:21:22 -0500
Subject: help with comps.xml
Message-ID: <44224C72.3050404@gmail.com>

Hello everyone out there..
 We am developing a customized distro for biotech people. It will use 
Fedora as the base. so basically I edited comps.xml file .. that we pass 
as argument to createrepo.. added more rpms to Fedora/RPMS/ and a new 
category in comps.xml.. then executed createrepo, pkgorder, buildinstall 
, splittree.py.. finally the new CDs produced by splittree does not have 
my edited comps.xml.. and additional packages..



From jaboutboul at speakeasy.net  Wed Mar 22 21:16:57 2006
From: jaboutboul at speakeasy.net (Jack Aboutboul)
Date: Wed, 22 Mar 2006 16:16:57 -0500
Subject: [Fwd: Announcing FUDCon Boston 2006]
Message-ID: <1143062217.13204.188.camel@deepfort>

This failed to get through yesterday.
-------------- next part --------------
An embedded message was scrubbed...
From: Jack Aboutboul <jaboutboul at fedoraproject.org>
Subject: Announcing FUDCon Boston 2006
Date: Tue, 21 Mar 2006 10:31:10 -0500
Size: 2910
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060322/0db2464d/attachment.eml>

From sundaram at fedoraproject.org  Wed Mar 22 21:24:05 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 23 Mar 2006 02:54:05 +0530
Subject: Announcing the release of Fedora Core 5
In-Reply-To: <44215799.3010101@cox.net>
References: <20060320161816.GB6976@nostromo.devel.redhat.com>
	<Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>
	<1142994945.13027.6.camel@scrappy.miketc.com>
	<44215799.3010101@cox.net>
Message-ID: <1143062645.3802.10.camel@sundaram.pnq.redhat.com>


> Mike Chambers wrote:
> > On Mon, 2006-03-20 at 15:56 -0500, Max Spevack wrote:
> > 
> >> For those of you who don't yet know me, let me introduce myself.  I've 
> >> been with Red Hat for about a year and a half, and over the course of the 
> >> last month I've transitioned from an engineering and quality assurance job 
> >> into a new role as Red Hat's Fedora Project Leader.
> >>
> >> My job is to represent the Fedora Project within Red Hat, to work with all 
> >> of the leaders within the Fedora Project (the leaders within the community 
> >> as well as inside of the Red Hat fenceline), and to set priorities and 
> >> direction at the level of engineering, budget, testing, branding, 
> >> marketing, and community building.
> > 
> > How does this affect Rahul Sundaram and his position? 

It doesnt. My day job has nothing to do with Fedora.

Rahul



From billcrawford1970 at gmail.com  Wed Mar 22 21:31:59 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 22 Mar 2006 21:31:59 +0000
Subject: Anaconda: good work!
In-Reply-To: <20060322193239.GC1115919@hiwaay.net>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<20060322193239.GC1115919@hiwaay.net>
Message-ID: <200603222132.00267.billcrawford1970@googlemail.com>

On Wednesday 22 March 2006 19:32, Chris Adams wrote:

> Don't use a green/red background as the difference; color blind people
> can't tell the difference.

 Not entirely true. Most "colourblind" people have partial but slightly weak 
receptivity to certain wavelengths (the most common forms being that they are 
less sensitive to either red or green).  In the majority of cases a solid 
colour is distinguishable, I have no trouble telling red from green on the 
linux console; there are shades of pale green and bright oranges that are 
hard to distinguish.

 That said, a blinking text for failure *would* make it stand out; in 
particular the whole red/green thing only works well when it's one of those 
standing out in contrast to the other. In cases where there's only a small 
amount of coloured text, it's not all that helpful anyway.

 I would suggest using both: red, blinking text for failure. Or yellow, which 
stands out better for people with or without poor colour vision in most cases
(hence the choice of sodium lamps for street lighting in the UK).



From jkeating at j2solutions.net  Wed Mar 22 21:42:03 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 22 Mar 2006 13:42:03 -0800
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <1143048886.32736.26.camel@kloczek01.pracownicy.zie>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<200603220816.02750.jkeating@redhat.com>
	<1143048886.32736.26.camel@kloczek01.pracownicy.zie>
Message-ID: <200603221342.04177.jkeating@j2solutions.net>

On Wednesday 22 March 2006 09:34, Tomasz K?oczko wrote:
> > Did you have a custom /etc/named.conf prior to the upgrade?
>
> Yes.
>
> > ? Did the upgrade remove this file?
>
> No. It will be biggest bug than currently existing.
>
> > ? Do you still have /etc/named.conf on your system and bind
> > is refusing to use that and uses the /etc/named.caching-nameserver.conf ?
> >
> >
> > # ls ?/var/named/chroot/etc/ -1; ps aux | grep named
>
> localtime
> named.caching-nameserver.conf.
> named.conf
> named.conf~
> named.conf.old
> named.conf~.org
> named.conf.rpmnew
> named.custom
> named.rfc1912.zones
> rndc.conf
> rndc.key
> rndc.key.rpmnew
> named ? ? 1514 ?0.2 ?0.2 ?72464 12152 ? ? ? ? ?Ssl ?12:11
> 0:56 /usr/sbin/named -u named -n 2 -t /var/named/chroot
> kloczek ?27335 ?0.0 ?0.0 ?58076 ? 800 pts/13 ? S+ ? 18:28 ? 0:00 less
> named.init
>
> named.caching-nameserver.conf is not used only because now it dos not
> exist (just renamed as you see).

Wait, you're talking about the files in the chroot.

Jason, did you test this?

Tomasz, before (or if) you renamed the named.caching-nameserver.conf, did 
named prefer this file over your modified named.conf ?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060322/ff277593/attachment.sig>

From cmadams at hiwaay.net  Wed Mar 22 21:43:26 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 22 Mar 2006 15:43:26 -0600
Subject: Anaconda: good work!
In-Reply-To: <200603222132.00267.billcrawford1970@googlemail.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<20060322193239.GC1115919@hiwaay.net>
	<200603222132.00267.billcrawford1970@googlemail.com>
Message-ID: <20060322214325.GE1115919@hiwaay.net>

Once upon a time, Bill Crawford <billcrawford1970 at gmail.com> said:
>  Not entirely true. Most "colourblind" people have partial but slightly weak 
> receptivity to certain wavelengths (the most common forms being that they are 
> less sensitive to either red or green).  In the majority of cases a solid 
> colour is distinguishable, I have no trouble telling red from green on the 
> linux console; there are shades of pale green and bright oranges that are 
> hard to distinguish.

A cow-orker in the next cube is red/green colorblind and most often
cannot tell between the two (even with solid colors).  With some things,
if both are side by side, he can tell, but if you just present one or
the other, he usually cannot.

>  I would suggest using both: red, blinking text for failure. Or yellow, which 
> stands out better for people with or without poor colour vision in most cases
> (hence the choice of sodium lamps for street lighting in the UK).

There's also blue/yellow colorblind (more rare). :-)

-- 
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 esr at thyrsus.com  Wed Mar 22 21:52:12 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 22 Mar 2006 16:52:12 -0500
Subject: CD verify on FC5 disc 5.
In-Reply-To: <1143045539.24732.23.camel@vroomfondel.internal.datastacks.com>
References: <200603212205.41086.russell@coker.com.au>
	<200603212235.42252.russell@coker.com.au>
	<1143045539.24732.23.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060322215212.GC3904@thyrsus.com>

Peter Jones <pjones at redhat.com>:
> On Tue, 2006-03-21 at 22:35 +1100, Russell Coker wrote:
> 
> > I burned a copy of CD 5 with 800 blank sectors at the end and it worked 
> > perfectly.  I also noticed that CD 2 has the problem (although I hadn't 
> > noticed it before), CDs 3 and 4 don't have a problem (I still have to repeat 
> > tests on CD 1).
> > 
> > I guess that I can work around this problem by specifying a padsize of 
> > something between 81 and 800 sectors (if some more friends want copies of FC5 
> > then I'll find out soon).
> 
> Ok, so... what CD drive do you have, what type of bus is it on, and what
> controller is in use?

I can't answer that question, but I can tell you that the -pad 800 solved
this same problem for the exceedingly generic ATAPI CD-ROM drive on my Opteron
box.  This workaround is probably generally applicable, and I'm going to
put it in my Fedora Core customization FAQ.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From dominik at greysector.net  Wed Mar 22 22:33:37 2006
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 22 Mar 2006 23:33:37 +0100
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <1143028319.32736.2.camel@kloczek01.pracownicy.zie>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<1143028319.32736.2.camel@kloczek01.pracownicy.zie>
Message-ID: <20060322223337.GB7001@rathann.pekin.waw.pl>

On Wednesday, 22 March 2006 at 12:51, Tomasz K?oczko wrote:
[...]
> First: IMO it will be good remove depedencies beetween named and
> NetworkManager (now using NetworkManager determines using only localy
> installed DNS).

I've already proposed it.
See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185505

R.

-- 
       RPM repository for Fedora Core http://rpm.greysector.net/
mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From notting at redhat.com  Wed Mar 22 22:36:01 2006
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 22 Mar 2006 17:36:01 -0500
Subject: Anaconda: good work!
In-Reply-To: <44218E8B.2080503@feuerpokemon.de>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
	<44218E8B.2080503@feuerpokemon.de>
Message-ID: <20060322223601.GA15354@devserv.devel.redhat.com>

dragoran (dragoran at feuerpokemon.de) said: 
> I don't know if this is a feature or a bug but it seems like a bug:
> I tryed a harddisk install (the image was on /dev/md0 ) but I could'nt 
> select it it only showed all /dev/sd(a|b)X but not /dev/md0
> any reason for that or is this a bug?

Well, depending on your point of view, I believe that's either
a bug that's always existed, or a request for a feature enhancement. :)

Bill



From jspaleta at gmail.com  Wed Mar 22 22:38:45 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 22 Mar 2006 17:38:45 -0500
Subject: Unable to mount cd & dvd after upgrading to FC5
In-Reply-To: <4421933A.5060005@vip.hr>
References: <4421933A.5060005@vip.hr>
Message-ID: <604aa7910603221438n1e9246ct86181d481bbb9189@mail.gmail.com>

On 3/22/06, Igor Jagec <igorm5 at vip.hr> wrote:
>I even tried to run hal deamon manually, to play
> with gnome-mount and so on, but all of that didn't help. I tried to 'rpm
> -V hal', but I got no output. Is there any way to solve that problem
> manually? To make hal to detect my hdc and hdd devices? Any help would
> be highly appreciated.

1) if you tried to run it manually... does that mean it wasn't running already?
2)is the dbus stuff running correctly?  /sbin/service messagebus status

3) does the outout of lshal  show your hdc and hdd devices?
there should be a block of output starting with  udi = something
and ending with linux.sysfs_path = something
for both the hdc and hdd device

for example look for block.device = '/dev/hdc' near the end of the
block of information that defines the hdc device

4) I'm still not sure what you attempted exactly, so its pretty
difficult to provide any feedback.

-jef



From selinux at gmail.com  Wed Mar 22 22:46:05 2006
From: selinux at gmail.com (Tom London)
Date: Wed, 22 Mar 2006 14:46:05 -0800
Subject: The joys of rawhide returning to form
In-Reply-To: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
References: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
Message-ID: <4c4ba1530603221446i701e6adbsde60f14a6f082e1d@mail.gmail.com>

On 3/22/06, darrell pfeifer <darrellpf at gmail.com> wrote:
> For the last couple of weeks as rawhide settled into FC5 I had a
> completely working system. Now that the freeze has been lifted for a
> couple of days I yum updated this morning.
>
> Printing broke.
>
> There was a cups update. I think I saw a scriptlet fail. There appears
> to be no default printer. Using the control panel to remove the
> current (USB) printer and remake a new one doesn't help. Test printing
> fails.
>
> X broke
>
> There was an X server update. I have an ATI Radeon R300 so am involved
> in the DRI fray. In previous versions commenting out the load of the
> DRI module worked but in the new version DRI looks like it is still
> attempted and I get the black screen of death. Reverted to the X
> server rpm off the FC5 cd.
>
> ipw2200 broke
>
> There was a kernel upgrade (2074) and now the driver won't load.
> Booted the 2064 kernel which continues to work.

Wahoo!!! New ipw2200 driver in kernel:
Mar 22 14:40:33 localhost kernel: ipw2200: Intel(R) PRO/Wireless
2200/2915 Network Driver, git-1.1.1

You need the new firmware (3.0 or newer). You can get this from the
usual places, e.g.,:
http://atrpms.net/dist/common/ipw2200-firmware-testing/

>
> So that was no X, no wireless and no printing. Eeeks.
>
> I'll try to file some bug reports when I get a chance.
>
> darrell

--
Tom London



From cmadams at hiwaay.net  Wed Mar 22 23:05:23 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 22 Mar 2006 17:05:23 -0600
Subject: Anaconda: good work!
In-Reply-To: <44218E8B.2080503@feuerpokemon.de>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
	<44218E8B.2080503@feuerpokemon.de>
Message-ID: <20060322230523.GA1381356@hiwaay.net>

Once upon a time, dragoran <dragoran at feuerpokemon.de> said:
> I don't know if this is a feature or a bug but it seems like a bug:
> I tryed a harddisk install (the image was on /dev/md0 ) but I could'nt 
> select it it only showed all /dev/sd(a|b)X but not /dev/md0
> any reason for that or is this a bug?

Currently, hard disk installs are only supported from native ext2, ext3,
or VFAT partitions; no software RAID and no LVM.
-- 
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 kewley at gps.caltech.edu  Wed Mar 22 23:40:36 2006
From: kewley at gps.caltech.edu (David Kewley)
Date: Wed, 22 Mar 2006 15:40:36 -0800
Subject: Anaconda: good work!
In-Reply-To: <13fb01c64dd7$6ec8ab30$b6491b31@td612671>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<13fb01c64dd7$6ec8ab30$b6491b31@td612671>
Message-ID: <200603221540.36625.kewley@gps.caltech.edu>

On Wednesday 22 March 2006 09:38, Dimi Paun wrote:
> From: "Jeremy Katz" <katzj at redhat.com>
> > >   * Disk change indicators
> >
> > This comes up from time to time, I'm just not fully convinced of how
> > useful it is.
>
> Coupled with a better time estimate, it would be useful, no doubt.
> Also copying the contents of the CDs to the HD before hand would be
> a very good idea too. But when that's not possible (due to free
> space constraints), the ticks would be nice :)

A suggestion if this gets considered: dd the CD to a .iso file on disk, and 
mount it loopback.  That way you avoid slow CD seeks.

David



From clydekunkel7734 at cox.net  Wed Mar 22 23:44:43 2006
From: clydekunkel7734 at cox.net (Clyde E. Kunkel)
Date: Wed, 22 Mar 2006 18:44:43 -0500
Subject: Announcing the release of Fedora Core 5
In-Reply-To: <1143059261.3802.1.camel@sundaram.pnq.redhat.com>
References: <20060320161816.GB6976@nostromo.devel.redhat.com>	
	<Pine.LNX.4.64.0603201555510.9815@mspevack.rdu.redhat.com>	
	<1142994945.13027.6.camel@scrappy.miketc.com>
	<44215799.3010101@cox.net>
	<1143059261.3802.1.camel@sundaram.pnq.redhat.com>
Message-ID: <4421E16B.5070506@cox.net>

Rahul Sundaram wrote:
> On Wed, 2006-03-22 at 08:56 -0500, Clyde E. Kunkel wrote:
>> Mike Chambers wrote:
> 
>>> How does this affect Rahul Sundaram and his position? 
> 
> It doesnt. My day job doesnt have anything to do with Fedora so far. 
> 
> Rahul
> 
> 

Good.  You are a never sleeping voice of reason and common sense on 
these lists.

-- 
Regards,

Old Fart
(my reply-to address is "munged" to defeat spambots)



From russell at coker.com.au  Thu Mar 23 00:19:43 2006
From: russell at coker.com.au (Russell Coker)
Date: Thu, 23 Mar 2006 11:19:43 +1100
Subject: CD verify on FC5 disc 5.
In-Reply-To: <20060322215212.GC3904@thyrsus.com>
References: <200603212205.41086.russell@coker.com.au>
	<1143045539.24732.23.camel@vroomfondel.internal.datastacks.com>
	<20060322215212.GC3904@thyrsus.com>
Message-ID: <200603231119.47897.russell@coker.com.au>

On Thursday 23 March 2006 08:52, "Eric S. Raymond" <esr at thyrsus.com> wrote:
> Peter Jones <pjones at redhat.com>:
> > On Tue, 2006-03-21 at 22:35 +1100, Russell Coker wrote:
> > > I burned a copy of CD 5 with 800 blank sectors at the end and it worked
> > > perfectly.  I also noticed that CD 2 has the problem (although I hadn't
> > > noticed it before), CDs 3 and 4 don't have a problem (I still have to
> > > repeat tests on CD 1).
> > >
> > > I guess that I can work around this problem by specifying a padsize of
> > > something between 81 and 800 sectors (if some more friends want copies
> > > of FC5 then I'll find out soon).
> >
> > Ok, so... what CD drive do you have, what type of bus is it on, and what
> > controller is in use?

I've repeated this problem on three Compaq Evo 1.5GHz P4 machines.  They have 
an Intel 82845 845 (Brookdale) chipsets with a Compaq CRD-8484B CD/DVD-ROM 
drive.

Incidentally they make great test machines and are going really cheap on the 
second-hand market.  Apart from this CD-ROM issue they have no problems with 
any version of Fedora or RHEL that I've tried.

> I can't answer that question, but I can tell you that the -pad 800 solved
> this same problem for the exceedingly generic ATAPI CD-ROM drive on my
> Opteron box.  This workaround is probably generally applicable, and I'm
> going to put it in my Fedora Core customization FAQ.

The number required is probably a lot smaller than 800, I will do more tests 
next time I burn CDs.  But OTOH 800 sectors is 1.6M and there's enough space 
to spare.

For reference I had discovered in that past that 50 spare sectors was the 
minimum to guarantee that no CD-ROM drives in my test network would fail the 
media verification (disks with less than 50 spare sectors failed verification 
and would sometimes fail on an install), so I chose 80 sectors to be on the 
safe side.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From d.jacobfeuerborn at conversis.de  Thu Mar 23 00:50:35 2006
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Thu, 23 Mar 2006 01:50:35 +0100
Subject: The joys of rawhide returning to form
In-Reply-To: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
References: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
Message-ID: <4421F0DB.6030706@conversis.de>

darrell pfeifer wrote:
> X broke
> 
> There was an X server update. I have an ATI Radeon R300 so am involved
> in the DRI fray. In previous versions commenting out the load of the
> DRI module worked but in the new version DRI looks like it is still
> attempted and I get the black screen of death. Reverted to the X
> server rpm off the FC5 cd.

X has worked fine on my r300 based card (9500pro) before the last update 
even with 'Load "dri"' present in xorg.conf. Now EXA support seems to be 
broken though:

...
(**) RADEON(0): Using EXA acceleration architecture
(II) Loading sub module "exa"
(II) LoadModule: "exa"
(II) Loading /usr/lib/xorg/modules/libexa.so
(II) Module exa: vendor="X.Org Foundation"
         compiled for 7.0.0, module version = 2.0.0
         ABI class: X.Org Video Driver, version 0.8
(WW) module major version (2) doesn't match required major version (1)
(II) UnloadModule: "exa"
(II) Unloading /usr/lib/xorg/modules/libexa.so
(EE) Failed to load module "exa" (module requirement mismatch, 0)
...


Regards,
   Dennis



From igorm5 at vip.hr  Thu Mar 23 00:52:28 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Thu, 23 Mar 2006 01:52:28 +0100
Subject: Anaconda: good work!
In-Reply-To: <44217267.3070002@city-fan.org>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
Message-ID: <4421F14C.4000607@vip.hr>

Paul Howarth wrote:

> I upgraded a desktop box from FC4->FC5 yesterday, and my perception was 

<cut>

Can you mount CD or DVD medias? I've upgrade FC4 via install media.
Everything works fine on FC5 clean install, but not on upgrade from FC4.

-- 
Igor Jagec



From jeff at ocjtech.us  Thu Mar 23 05:34:31 2006
From: jeff at ocjtech.us (Jeffrey C. Ollie)
Date: Wed, 22 Mar 2006 23:34:31 -0600
Subject: The joys of rawhide returning to form
In-Reply-To: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
References: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
Message-ID: <1143092072.2481.6.camel@lt16585.campus.dmacc.edu>

On Wed, 2006-03-22 at 09:54 -0800, darrell pfeifer wrote:
> For the last couple of weeks as rawhide settled into FC5 I had a
> completely working system. Now that the freeze has been lifted for a
> couple of days I yum updated this morning.

I'm seeing all of the same things.

> Printing broke.
> 
> There was a cups update. I think I saw a scriptlet fail. There appears
> to be no default printer. Using the control panel to remove the
> current (USB) printer and remake a new one doesn't help. Test printing
> fails.
> 
> X broke
> 
> There was an X server update. I have an ATI Radeon R300 so am involved
> in the DRI fray. In previous versions commenting out the load of the
> DRI module worked but in the new version DRI looks like it is still
> attempted and I get the black screen of death. Reverted to the X
> server rpm off the FC5 cd.

In my case I had the EXA acceleration enabled on X, and that appeared
not to be loading.  I was able to get X working again by reconfiguring.

> ipw2200 broke
> 
> There was a kernel upgrade (2074) and now the driver won't load.
> Booted the 2064 kernel which continues to work.
> 
> So that was no X, no wireless and no printing. Eeeks.

Thank goodness I have a wired jack near to where I use my laptop at
home...

Jeff

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

From hk at isphuset.no  Thu Mar 23 08:32:02 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Thu, 23 Mar 2006 09:32:02 +0100
Subject: Anaconda: good work!
In-Reply-To: <1143045925.24028.12.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
Message-ID: <1143102722.2853.83.camel@linux>

On Wed, 2006-03-22 at 11:45 -0500, Jeremy Katz wrote:
> On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:
> > First impression: anaconda really rocks! This is a
> > very solid, pleasant installer.
> 
> Thanks -- always nice to see people not just flaming us :-P

*snip*

I have to agree that the new installer is very nice.
But despite this I really wish you will apply some bugfixes
to anaconda and release it in updates. This of course does
not help with FC5, but it will help those who use anaconda
to make new distros or respins such as I plan to do (either
official or unofficial).

The complete lack of updates to anaconda in FC4 bugged me,
but I was too late in the cycle to make you reconsider.
This time around I hope you will atleast take obvious
bugfixes and maintain the FC5 anaconda atleast for a
little while. I'm not asking for new features, only fixes.

-HK



From hk at isphuset.no  Thu Mar 23 08:48:51 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Thu, 23 Mar 2006 09:48:51 +0100
Subject: Intelligent Anaconda (was: Re: The Morning After)
In-Reply-To: <4421B06A.8030809@fedoraproject.org>
References: <200603210156.40386.nman64@n-man.com>
	<4421B06A.8030809@fedoraproject.org>
Message-ID: <1143103731.2853.92.camel@linux>

On Thu, 2006-03-23 at 01:45 +0530, Rahul Sundaram wrote:
> The fact that we can do a minimal installation with a 
> single CD,  a desktop class installation in 2 CD's or a network 
> installation with boot.iso image is far from clear to everyone involved. 
> It has been offered for years and people continue to request it as a new 
> feature not being aware that it exists already in just about every 
> release. Kickstart should be much better advertised.

In my opinion when you boot anaconda from CD1, it should ask you what
cds you have available. So if I only downloaded CD1 & 2 it would not
allow me to select packages that are not available on those two cds,
possibly asking me whether I want yum to download what I don't have.

This selection dialog could also be extended to let you chose that you
have indeed downloaded extras CD1, CD2 and CD3 (or somesuch).
Or let you select "Other CD" and let anaconda scan the disk and find
the prepared-by-anaconda list of rpms and deps on the disk.

This would allow me to make my own addons cd that would just be
installed from just like the other cds.

Yes, yum has solved this problem partially but not everyone has
24/7 highspeed Internet access. And some just don't want to have to
install from the internet every time.

-HK



From igorm5 at vip.hr  Thu Mar 23 09:57:55 2006
From: igorm5 at vip.hr (Igor Jagec)
Date: Thu, 23 Mar 2006 10:57:55 +0100
Subject: Unable to mount cd & dvd after upgrading to FC5
In-Reply-To: <604aa7910603221438n1e9246ct86181d481bbb9189@mail.gmail.com>
References: <4421933A.5060005@vip.hr>
	<604aa7910603221438n1e9246ct86181d481bbb9189@mail.gmail.com>
Message-ID: <44227123.8040503@vip.hr>

Jeff Spaleta wrote:

<cut>

I solved the problem, I guess. Here's what I've done: I've installed
hal-gnome package, turned on hal service on runlevel 5, commended out
some fstab lines and rebooted machine. Well, gnome-mount crashes often,
and I got some growfs error message after I successfully burned
multisession DVD (?), which was ok thoe, but at least I can say that it
works for now. After these unpleasent experiences, I can't say I'm gonna
recommend upgrading from FC4 to FC5 instead of clean install.

And here's my fstab, so you can see what lines I commented out, and what
lines I took from my test system and manually added:

[ijagec at munja ~]$ cat /etc/fstab
LABEL=/1            /                       ext3    defaults        1 1
LABEL=/boot1        /boot                   ext2    defaults        1 2
#none                /dev/pts                devpts  gid=5,mode=620  0 0
#none                /dev/shm                tmpfs   defaults        0 0
LABEL=/home         /home                   xfs     defaults        1 2
#none                /proc                   proc    defaults        0 0
#none                /sys                    sysfs   defaults        0 0
#LABEL=SWAP-hda5     swap                    swap    defaults        0 0


devpts              /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs               /dev/shm                tmpfs   defaults        0 0
proc                /proc                   proc    defaults        0 0
sysfs               /sys                    sysfs   defaults        0 0
/dev/hda5           swap                    swap    defaults        0 0

> On 3/22/06, Igor Jagec <igorm5 at vip.hr> wrote:
>> I even tried to run hal deamon manually, to play
>> with gnome-mount and so on, but all of that didn't help. I tried to 'rpm
>> -V hal', but I got no output. Is there any way to solve that problem
>> manually? To make hal to detect my hdc and hdd devices? Any help would
>> be highly appreciated.
> 1) if you tried to run it manually... does that mean it wasn't running already?

Most likely it wasn't.

> 2)is the dbus stuff running correctly?  /sbin/service messagebus status

[root at munja ~]# /sbin/service messagebus status
dbus-daemon (pid 4147 1558) se izvr?ava...

Which means it runs properly. BTW I tried to get english output with
'export LANG=en_EN.ISO8859-1', and it didn't help for that command, and
for some it did (?). Never mind.

> 3) does the outout of lshal  show your hdc and hdd devices?

[root at munja ~]# lshal|grep hdc
  block.device = '/dev/hdc'  (string)
  linux.sysfs_path_device = '/sys/block/hdc'  (string)
  linux.sysfs_path = '/sys/block/hdc'  (string)
[root at munja ~]# lshal|grep hdd
  storage.cdrom.hddvdrw = false  (bool)
  storage.cdrom.hddvdr = false  (bool)
  storage.cdrom.hddvd = false  (bool)
  storage.cdrom.hddvdrw = false  (bool)
  storage.cdrom.hddvdr = false  (bool)
  storage.cdrom.hddvd = false  (bool)
  block.device = '/dev/hdd'  (string)
  linux.sysfs_path_device = '/sys/block/hdd'  (string)
  linux.sysfs_path = '/sys/block/hdd'  (string)
  block.device = '/dev/hdd'  (string)
  linux.sysfs_path_device = '/sys/block/hdd/fakevolume'  (string)
  linux.sysfs_path = '/sys/block/hdd/fakevolume'  (string)

> there should be a block of output starting with  udi = something
> and ending with linux.sysfs_path = something
> for both the hdc and hdd device

That above is an output after I solved the problem. Since gnome-mount
crashes often, I'm not quite sure I solved the problem completely, but
at least it works now.

> 4) I'm still not sure what you attempted exactly, so its pretty
> difficult to provide any feedback.

I didn't know how to provide you more information, but I hope that above
will help a bit. I saw on the redhat's news group that I'm not the only
one who experienced that problem.

-- 
Igor Jagec



From fedora at camperquake.de  Thu Mar 23 10:07:17 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 23 Mar 2006 11:07:17 +0100
Subject: Anaconda: good work!
In-Reply-To: <1143048993.2383.9.camel@halflap>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
	<1143048993.2383.9.camel@halflap>
Message-ID: <20060323110717.2eb08b12@soran.addix.net>

Hi.

On Wed, 22 Mar 2006 12:36:33 -0500, Ray Strode wrote:

> I think installing gconf schemas got slower with the gconf backend
> changes.  This may have something to do with things, not sure.
> 
> If that is a significant cause of the slowdowns, we can partially
> alleviate the problem, by changing all %post snippets from
> 
> for S in "<list of schemas here>"; do
>   gconftool-2 --make-install-rule $S
> done
> 
> to
> 
> gconftool-2 --make-install-rule <list of schemas here>

This step (what does that do, anyway?) is _slow_. 30 seconds per
schema on my 500MHz iBook. Updating gnome-games takes ages.



From j.rink at freenet.de  Thu Mar 23 09:27:46 2006
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Thu, 23 Mar 2006 10:27:46 +0100
Subject: strange X11 Problems with cisco vpn client under Fedora 4 or 5
Message-ID: <20060323102746.d7bff2ff.j.rink@freenet.de>

Hi,
first of all, sry when this is not the right mailing list.

I have problems with the cisco vpnclient 4.xxx under Fedora 4 or 5.

The client works perfectly, but when it is started and i login with a
user into X11, after a while the mouse pointer stacks at the left side.
This happens ONLY when the cisco vpn client is connected with my
office.

So my question is, how can this happen, where can i look or debug
to get more info? I have to reboot the computer, deleting modules
restarting X do not work.

Anyone here with the same Problem? On my notebook with Fedora Core 3 i
do not have this problem.

Thanks for reading,

 Joern Rink



From paul at city-fan.org  Thu Mar 23 11:35:52 2006
From: paul at city-fan.org (Paul Howarth)
Date: Thu, 23 Mar 2006 11:35:52 +0000
Subject: Anaconda: good work!
In-Reply-To: <4421F14C.4000607@vip.hr>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>	<44217267.3070002@city-fan.org>
	<4421F14C.4000607@vip.hr>
Message-ID: <44228818.4050107@city-fan.org>

Igor Jagec wrote:
> Paul Howarth wrote:
> 
>> I upgraded a desktop box from FC4->FC5 yesterday, and my perception was 
> 
> <cut>
> 
> Can you mount CD or DVD medias? I've upgrade FC4 via install media.
> Everything works fine on FC5 clean install, but not on upgrade from FC4.

Didn't try; I always do NFS installs as they're so much faster than DVD/CD.

Paul.



From gtwilliams at gmail.com  Thu Mar 23 12:10:51 2006
From: gtwilliams at gmail.com (Garry Williams)
Date: Thu, 23 Mar 2006 07:10:51 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143045925.24028.12.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
Message-ID: <1143115851.12702.7.camel@localhost>

On Wed, 2006-03-22 at 11:45 -0500, Jeremy Katz wrote:
> On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:

[snip]

> One thing that we really probably need to look at for FC6
> is revisiting the time remaining algorithm.

Yeah, it took about fifteen minutes after all packages were installed to
finish doing an update.  That was long "1 minute remaining".  :-)

-- 
Garry Williams -- +1 (678) 656-4579



From jspaleta at gmail.com  Thu Mar 23 13:56:23 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 23 Mar 2006 08:56:23 -0500
Subject: The joys of rawhide returning to form
In-Reply-To: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
References: <f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com>
Message-ID: <604aa7910603230556w1617ff4bmf96cccc1b10478a9@mail.gmail.com>

On 3/22/06, darrell pfeifer <darrellpf at gmail.com> wrote:
> So that was no X, no wireless and no printing. Eeeks.


-jef"
Breaking News!!!!!!!!!
Rawhide eats babies!!!!!!!
Film at 11
"spaleta



From jspaleta at gmail.com  Thu Mar 23 14:30:37 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 23 Mar 2006 09:30:37 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143059367.5126.9.camel@MrTomLinux.workstation>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
Message-ID: <604aa7910603230630v3d10e098x9327a5689865e59b@mail.gmail.com>

On 3/22/06, Thomas Canniot <thomas.canniot at laposte.net> wrote:
> Maybe we could do something here that really helps people, newbies who
> are just installing their first linux distribution. I dreamt of an
> anaconda that helps newbies make their first steps in Fedora Core.

Screw that... embedded game of nexuiz would be much better.

As for the mock up... perhaps an embedded ogg video of desktop
interactions with localized closed caption text ala annodex.

-jef"so what if anaconda would require a minimum of 2 gig of ram for
the video to play while anaconda does packaging actions."spaleta



From clumens at redhat.com  Thu Mar 23 14:44:34 2006
From: clumens at redhat.com (Chris Lumens)
Date: Thu, 23 Mar 2006 09:44:34 -0500
Subject: FC5 kickstart  i386 and x86_64
In-Reply-To: <1143050056.9830.16.camel@mlor.frop.net>
References: <1143050056.9830.16.camel@mlor.frop.net>
Message-ID: <20060323144433.GF3137@exeter.boston.redhat.com>

> I've downloaded FC5 for i386 and x86_64.  I do netboot kickstart
> installs.  With FC3 and FC4, and previous I think, If I didn't have a
> network stanza in the kickstart config file it would just bypass
> configuring the interfaces and just use the one that was selected during
> the boot process.  With FC5 it asks to configure all the interfaces.  If
> I add a single network line to the config file it bypasses the interface
> configuration again and configures on the interface in the config file.
> My machines don't all use the same interface for network connectivity,
> and I liked the way it worked before.  Any suggestions would be
> appreciated.  Yes I have RTMF.

Kickstart got a major overhaul for FC5, so it's likely I have
accidentally dropped some behavior that was present in earlier versions.
In general, the way we do things is that kickstart asks for any missing
information so in this case, asking for the networking is consistent
with that policy.  However if it's a regression from earlier versions,
file a bug against anaconda and I'll take a look at it.

- Chris



From tjb at unh.edu  Thu Mar 23 14:50:29 2006
From: tjb at unh.edu (Thomas J. Baker)
Date: Thu, 23 Mar 2006 09:50:29 -0500
Subject: gnome-screen-saver unlock artwork
Message-ID: <1143125429.5133.6.camel@zero.sr.unh.edu>

I have some inconsistencies across several machines with the artwork for
the gnome screen saver unlock window that I thought was due to different
initial fc5 test installs. Now that I've done clean installs of fc5
proper on the same systems the inconsistencies remain. On some systems I
have the themed fedora core 5 unlock window and on others I have a
simple grey box. I can't really do a screen shot because the screen is
locked. It doesn't appear to be user related because a new user on an
affected system still has just the grey box unlock dialog.

Has anyone else seen this? 

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



From buildsys at redhat.com  Thu Mar 23 14:56:34 2006
From: buildsys at redhat.com (Build System)
Date: Thu, 23 Mar 2006 09:56:34 -0500
Subject: rawhide report: 20060323 changes
Message-ID: <200603231456.k2NEuYt3027315@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From dimi at lattica.com  Thu Mar 23 15:11:17 2006
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 23 Mar 2006 10:11:17 -0500
Subject: Anaconda: good work!
References: <131501c64dc2$fe1522b0$b6491b31@td612671><1143045925.24028.12.camel@orodruin.boston.redhat.com><20060322193239.GC1115919@hiwaay.net>
	<200603222132.00267.billcrawford1970@googlemail.com>
Message-ID: <169d01c64e8c$092a8f90$b6491b31@td612671>

From: "Bill Crawford" <billcrawford1970 at gmail.com>
>  That said, a blinking text for failure *would* make it stand out; in
> particular the whole red/green thing only works well when it's one of
those
> standing out in contrast to the other. In cases where there's only a small
> amount of coloured text, it's not all that helpful anyway.

Tha's why I suggested that the background be green/red, since
it provides a lot more color. Having other elements (like blinking)
to differentiate the two would also be good, but I think they should
be in addition, rather than replacing, the color background.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sundaram at fedoraproject.org  Thu Mar 23 15:22:15 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 23 Mar 2006 20:52:15 +0530
Subject: Anaconda: good work!
In-Reply-To: <1143102722.2853.83.camel@linux>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
Message-ID: <1143127335.3802.79.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-23 at 09:32 +0100, Hans Kristian Rosbach wrote:
> On Wed, 2006-03-22 at 11:45 -0500, Jeremy Katz wrote:
> > On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:
> > > First impression: anaconda really rocks! This is a
> > > very solid, pleasant installer.
> > 
> > Thanks -- always nice to see people not just flaming us :-P
> 
> *snip*
> 
> I have to agree that the new installer is very nice.
> But despite this I really wish you will apply some bugfixes
> to anaconda and release it in updates. This of course does
> not help with FC5, but it will help those who use anaconda
> to make new distros or respins such as I plan to do (either
> official or unofficial).
> 
> The complete lack of updates to anaconda in FC4 bugged me,
> but I was too late in the cycle to make you reconsider.
> This time around I hope you will atleast take obvious
> bugfixes and maintain the FC5 anaconda atleast for a
> little while. I'm not asking for new features, only fixes.
> 
> -HK

Are you asking this as a general idea or do you have specific bugs that
you want to see fixed sooner? . Bugzilla links would be nice.

Rahul



From hk at isphuset.no  Thu Mar 23 15:31:28 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Thu, 23 Mar 2006 16:31:28 +0100
Subject: Anaconda: good work!
In-Reply-To: <1143102722.2853.83.camel@linux>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
Message-ID: <1143127888.2853.96.camel@linux>

On Thu, 2006-03-23 at 09:32 +0100, Hans Kristian Rosbach wrote:
>> This time around I hope you will atleast take obvious
>> bugfixes and maintain the FC5 anaconda atleast for a
>> little while. I'm not asking for new features, only fixes.
>
>Are you asking this as a general idea or do you have specific bugs that
>you want to see fixed sooner? . Bugzilla links would be nice.

Yes, the general idea. I have no bugreports so far.

Just thought I'd voice this before the maintainers just let go
and completely focus on the one for FC6. I bet obvious fixes
will be detected in the starting phase of developing for FC6
and those might be backported to FC5 aswell.

-HK



From dcantrell at redhat.com  Thu Mar 23 15:46:48 2006
From: dcantrell at redhat.com (David Cantrell)
Date: Thu, 23 Mar 2006 10:46:48 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143102722.2853.83.camel@linux>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
Message-ID: <20060323154648.GA2595@mortise.boston.redhat.com>

Hans Kristian Rosbach wrote:
> On Wed, 2006-03-22 at 11:45 -0500, Jeremy Katz wrote:
> > On Wed, 2006-03-22 at 10:12 -0500, Dimi Paun wrote:
> > > First impression: anaconda really rocks! This is a
> > > very solid, pleasant installer.
> > 
> > Thanks -- always nice to see people not just flaming us :-P
> 
> *snip*
> 
> I have to agree that the new installer is very nice.
> But despite this I really wish you will apply some bugfixes
> to anaconda and release it in updates. This of course does
> not help with FC5, but it will help those who use anaconda
> to make new distros or respins such as I plan to do (either
> official or unofficial).
> 
> The complete lack of updates to anaconda in FC4 bugged me,
> but I was too late in the cycle to make you reconsider.
> This time around I hope you will atleast take obvious
> bugfixes and maintain the FC5 anaconda atleast for a
> little while. I'm not asking for new features, only fixes.

If you're using anaconda in projects, it's probably worth following what
happens in rawhide.  New anaconda packages make it there all the time.

-- 
David Cantrell
Red Hat / Westford, MA



From jspaleta at gmail.com  Thu Mar 23 16:02:34 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 23 Mar 2006 11:02:34 -0500
Subject: Unable to mount cd & dvd after upgrading to FC5
In-Reply-To: <44227123.8040503@vip.hr>
References: <4421933A.5060005@vip.hr>
	<604aa7910603221438n1e9246ct86181d481bbb9189@mail.gmail.com>
	<44227123.8040503@vip.hr>
Message-ID: <604aa7910603230802y102fe799g627ceaff891ee0d2@mail.gmail.com>

On 3/23/06, Igor Jagec <igorm5 at vip.hr> wrote:
> > 1) if you tried to run it manually... does that mean it wasn't running already?
>
> Most likely it wasn't.

hald not running..even in fc4.. is a problem that will result in a
number of weird symptoms. Unfortunately "most likely" doesn't help
narrow the underlying problem down, i was hoping for confirmation
while you were experiencing the problem.

>
> > 2)is the dbus stuff running correctly?  /sbin/service messagebus status
>
> [root at munja ~]# /sbin/service messagebus status
> dbus-daemon (pid 4147 1558) se izvr?ava...
>
> Which means it runs properly. BTW I tried to get english output with
> 'export LANG=en_EN.ISO8859-1', and it didn't help for that command, and
> for some it did (?). Never mind.
>
> > 3) does the outout of lshal  show your hdc and hdd devices?
>
> [root at munja ~]# lshal|grep hdc

I wasn't asking for a grep.. because the grep won't extract all the
information in the "block" of output that covers all the properties. I
specifically ask for a "block" oufput and I tried to define what the
beginning and end of the block looks like. Unfortunately you didn't
seem to understand what I was asking for.

> I didn't know how to provide you more information, but I hope that above
> will help a bit. I saw on the redhat's news group that I'm not the only
> one who experienced that problem.

gnome-mount isnt crashing for me... and I don't see any bugreports
about gnome-mount crashing so far reported in bugzilla by anyone.  If
this is a common occurance, and its a real bug, someone from those
"news groups" needs to actually file a bug report if they want the
crashing fixed.  People can discuss crasher issues in forums and
newsgroups and mailinglists forever.. but if its not filed in
bugzilla..you can never be sure the developers who need to be aware of
it will know about it.

-jef



From jspaleta at gmail.com  Thu Mar 23 16:04:31 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 23 Mar 2006 11:04:31 -0500
Subject: Anaconda: good work!
In-Reply-To: <20060323110717.2eb08b12@soran.addix.net>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
	<1143048993.2383.9.camel@halflap>
	<20060323110717.2eb08b12@soran.addix.net>
Message-ID: <604aa7910603230804i6693a5fbg6525268bdc709dce@mail.gmail.com>

On 3/23/06, Ralf Ertzinger <fedora at camperquake.de> wrote:
> This step (what does that do, anyway?) is _slow_. 30 seconds per
> schema on my 500MHz iBook. Updating gnome-games takes ages.

I'd have to agree, I've seen the schema updates take quite a bit of
time. So long in fact that I actually flip over and start a top to see
if the rpm trasaction is stalled or not.

-jef



From i.pilcher at comcast.net  Thu Mar 23 16:23:23 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Thu, 23 Mar 2006 10:23:23 -0600
Subject: Anaconda: good work!
In-Reply-To: <44217267.3070002@city-fan.org>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
Message-ID: <dvui1s$sl1$1@sea.gmane.org>

Paul Howarth wrote:
> I upgraded a desktop box from FC4->FC5 yesterday, and my perception was
> that the process was significantly slower (perhaps taking twice as
> long?) as previous upgrades, e.g. FC3->FC4 on the same box. Can't
> explain why that should be, unless of course it was to give me plenty of
> time to read the release notes (which I was able to do in full during
> the process) :-)

I had the same experience.  In a number of cases it took an
uncomfortably long time (15 seconds?) for the installer to respond to
a button click.

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From clumens at redhat.com  Thu Mar 23 16:47:02 2006
From: clumens at redhat.com (Chris Lumens)
Date: Thu, 23 Mar 2006 11:47:02 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143102722.2853.83.camel@linux>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
Message-ID: <20060323164702.GG3137@exeter.boston.redhat.com>

> I have to agree that the new installer is very nice.
> But despite this I really wish you will apply some bugfixes
> to anaconda and release it in updates. This of course does
> not help with FC5, but it will help those who use anaconda
> to make new distros or respins such as I plan to do (either
> official or unofficial).
> 
> The complete lack of updates to anaconda in FC4 bugged me,
> but I was too late in the cycle to make you reconsider.
> This time around I hope you will atleast take obvious
> bugfixes and maintain the FC5 anaconda atleast for a
> little while. I'm not asking for new features, only fixes.

We can't really do this easily.  Making a new anaconda means making new
first and second stage images, which means making new CD and DVD images,
which means a huge headache for mirrors and for keeping track of all
these versions of images floating around.

One thing we can look into is the possibility of providing an
updates.img from time to time that rolls up fixes, but this has its own
set of problems.  Doing something like that will make debugging in the
future much harder because we'll have to ask people what updates they
might be using in their installation when they report bugs.  I can just
see all sorts of problems resulting from that.

The installer is special.

- Chris



From katzj at redhat.com  Thu Mar 23 17:00:05 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 23 Mar 2006 12:00:05 -0500
Subject: Anaconda: good work!
In-Reply-To: <200603221540.36625.kewley@gps.caltech.edu>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<13fb01c64dd7$6ec8ab30$b6491b31@td612671>
	<200603221540.36625.kewley@gps.caltech.edu>
Message-ID: <1143133205.23486.14.camel@orodruin.boston.redhat.com>

On Wed, 2006-03-22 at 15:40 -0800, David Kewley wrote:
> On Wednesday 22 March 2006 09:38, Dimi Paun wrote:
> > From: "Jeremy Katz" <katzj at redhat.com>
> > > >   * Disk change indicators
> > >
> > > This comes up from time to time, I'm just not fully convinced of how
> > > useful it is.
> >
> > Coupled with a better time estimate, it would be useful, no doubt.
> > Also copying the contents of the CDs to the HD before hand would be
> > a very good idea too. But when that's not possible (due to free
> > space constraints), the ticks would be nice :)
> 
> A suggestion if this gets considered: dd the CD to a .iso file on disk, and 
> mount it loopback.  That way you avoid slow CD seeks.

The cost is that you then have to read every bit off the CD as opposed
to just the ones for the packages you're installing as well as then
needing to seek more on the disk when installing packages (since you're
reading and writing from the same device).  There's also a non-trivial
disk space overhead 

Jeremy



From katzj at redhat.com  Thu Mar 23 17:02:34 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 23 Mar 2006 12:02:34 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143059367.5126.9.camel@MrTomLinux.workstation>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
Message-ID: <1143133354.23486.17.camel@orodruin.boston.redhat.com>

On Wed, 2006-03-22 at 21:29 +0100, Thomas Canniot wrote:
> What I found sad in anaconda during the installation process is the
> permanent showing of our brand new logo for about 20 min, while anaconda
> is copying files. We had in previous version of FC, texts talking about
> the distribution itself. These have disappeared, too bad really.

The main thing needed here is having a group step up to create the
content.  fedora-marketing-love project maybe? :-)

Jeremy



From brunson at brunson.com  Thu Mar 23 17:17:53 2006
From: brunson at brunson.com (Eric Brunson)
Date: Thu, 23 Mar 2006 10:17:53 -0700
Subject: Core 5 and Samba issues
Message-ID: <4422D841.7040409@brunson.com>

 From a fresh install of FC5 I was joining my box to the office domain 
and came across a few issues.

Let me start by saying, system-config-samba is a very good tool.  It has 
some holes in functionality, but samba has always been a thorn in my 
side and this tool made it a whole lot easier.  However, if I go to 
Server Settings and select "ADS" for authentication, when I enter my 
Realm it joins the realm line with the line that follows it in the 
smb.conf which causes problems even when the following line is a comment.

Second, there seems to be an issue with SELinux policies and 
kerberos/samba.  When I've properly configured /etc/krb5.conf and samba, 
then try to do a "net join", the action fails with the error "end point 
not connected".  Even selecting "Disable SELinux" for smbd, nmbd, 
winbind and kerberos, the action fails.  After "setenforce 0" the action 
succeeds.  After the "net join" is complete, selinux can (apparently) be 
reset to enforcing.

Finally, SWAT is evil.  I used it to add a printer and it obliterated my 
config from system-config-samba.  Is there somewhere to make a 
recommendation to the user to use one or the other, but not both?

e.







From dragoran at feuerpokemon.de  Thu Mar 23 17:35:46 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Thu, 23 Mar 2006 18:35:46 +0100
Subject: Anaconda: good work!
In-Reply-To: <20060322223601.GA15354@devserv.devel.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>	<44217267.3070002@city-fan.org>	<1143045982.24028.14.camel@orodruin.boston.redhat.com>	<44218E8B.2080503@feuerpokemon.de>
	<20060322223601.GA15354@devserv.devel.redhat.com>
Message-ID: <4422DC72.2000109@feuerpokemon.de>

Bill Nottingham wrote:

>dragoran (dragoran at feuerpokemon.de) said: 
>  
>
>>I don't know if this is a feature or a bug but it seems like a bug:
>>I tryed a harddisk install (the image was on /dev/md0 ) but I could'nt 
>>select it it only showed all /dev/sd(a|b)X but not /dev/md0
>>any reason for that or is this a bug?
>>    
>>
>
>Well, depending on your point of view, I believe that's either
>a bug that's always existed, or a request for a feature enhancement. :)
>
>Bill
>
>  
>
no it seems that raid0 is broken in anaconda and/or fc5 kernel see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312



From david at lovesunix.net  Thu Mar 23 17:40:40 2006
From: david at lovesunix.net (David Nielsen)
Date: Thu, 23 Mar 2006 18:40:40 +0100
Subject: Today' rawhide update
Message-ID: <1143135640.767.2.camel@price.stavtrup-st.dk>

Is it just me or did we not get a rawhide update today?

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/14c25e89/attachment.sig>

From notting at redhat.com  Thu Mar 23 18:03:05 2006
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 23 Mar 2006 13:03:05 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143115851.12702.7.camel@localhost>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143115851.12702.7.camel@localhost>
Message-ID: <20060323180305.GA31517@devserv.devel.redhat.com>

Garry Williams (gtwilliams at gmail.com) said: 
> > One thing that we really probably need to look at for FC6
> > is revisiting the time remaining algorithm.
> 
> Yeah, it took about fifteen minutes after all packages were installed to
> finish doing an update.  That was long "1 minute remaining".  :-)

In prior releases, the upgrade procedure was:

upgrade A
remove old A
upgrade B
remove old C
...
upgrade Z
***
remove old Z

With the switch to yum, it's now:

upgrade A
upgrade B
upgrade C
...
upgrade Z
***
remove old A
remove old B
remove old C
...
remove old Z

The time algorithm and the progress bar were adopted for the first method -
when you get to 'where all the packages are installed', you're at the point
makred by '***' above.

This obviously doesn't fit the new model very well.

Bill



From kloczek at zie.pg.gda.pl  Thu Mar 23 18:26:13 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Thu, 23 Mar 2006 19:26:13 +0100
Subject: Broken bind (Re: rawhide report: 20060321 changes)
In-Reply-To: <200603221342.04177.jkeating@j2solutions.net>
References: <200603210818.k2L8I12p002317@porkchop.devel.redhat.com>
	<200603220816.02750.jkeating@redhat.com>
	<1143048886.32736.26.camel@kloczek01.pracownicy.zie>
	<200603221342.04177.jkeating@j2solutions.net>
Message-ID: <1143138373.10888.20.camel@kloczek01.pracownicy.zie>

Dnia 22-03-2006, ?ro o godzinie 13:42 -0800, Jesse Keating napisa?(a):
[..] 
> Tomasz, before (or if) you renamed the named.caching-nameserver.conf, did 
> named prefer this file over your modified named.conf ?

No, named.caching-nameserver.conf was preffered but this doesn't metter
now because inti script from today bind-9.3.2-12.FC6 seems works
correctly.
Still IMO adding special handling for named.caching-nameserver.conf in
separated bind-config package is IMO wrong way (IMO best will be put
caching only configuration as default configura example .

BTW I found next bug in current bind. Iin libbind.pc in Libs: is
specyfied -L/usr/lib - this will break 64bit archs
Patch in attachment.

I second atachemnt is patch for init scrips (use tabs instead spaces,
removed trailing spaces and tabs, removed ";" on EOF; rolled in multipe
rm commands to single run with more than one file for remove).

In next attachment are bind.spec cleanups:
- removed trailig spaces and tabs,
- use tabs instead spaces,
- remove gcc and tar from BuildRequires (this is esential BR so specify
  this directly isn't neccessary),
- simplified BuildRequires rules,
- s/textutils, fileutils/coreutils/ in Requires rules,
- removed not neccessatry specs conditions (%if in packages descriptions
  and %post/%postun scripts can be ommited),
- simplifications in %build,
- s/\${RPM_BUILD_ROOT}/$RPM_BUILD_ROOT/
- %clean moved after %install and before all %post/%pre/%post/%postun
  scripts,
- s,/usr/share,%{_datadir},
- cleanups in %prep,
- move unpack RFC docs to %prep (fixes for --short-circuit build),
- remove nit neccessary ";" in scripts and 
- rewrited sdb %postun for use only sed (this allow minimize number of
  Requires it will be also good rewrite %post script in sed because
  using this allow remove from sdb Requires(post) mktemp and SELinux
  utils because sed preserves SElinux context on files).

kloczek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libbind.pc.patch
Type: text/x-patch
Size: 482 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/3f97ce19/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: named.init.patch
Type: text/x-patch
Size: 11137 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/3f97ce19/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bind.spec.patch
Type: text/x-patch
Size: 25113 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/3f97ce19/attachment-0002.bin>

From hughsient at gmail.com  Thu Mar 23 19:08:28 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 23 Mar 2006 19:08:28 +0000
Subject: Anaconda: good work!
In-Reply-To: <604aa7910603230630v3d10e098x9327a5689865e59b@mail.gmail.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
	<604aa7910603230630v3d10e098x9327a5689865e59b@mail.gmail.com>
Message-ID: <1143140908.7301.19.camel@localhost.localdomain>

On Thu, 2006-03-23 at 09:30 -0500, Jeff Spaleta wrote:
> On 3/22/06, Thomas Canniot <thomas.canniot at laposte.net> wrote:
> > Maybe we could do something here that really helps people, newbies who
> > are just installing their first linux distribution. I dreamt of an
> > anaconda that helps newbies make their first steps in Fedora Core.
> 
> Screw that... embedded game of nexuiz would be much better.
> 
> As for the mock up... perhaps an embedded ogg video of desktop
> interactions with localized closed caption text ala annodex.
> 
> -jef"so what if anaconda would require a minimum of 2 gig of ram for
> the video to play while anaconda does packaging actions."spaleta

What about just slides like powerpoint (images)?

Richard.



From jspaleta at gmail.com  Thu Mar 23 19:15:45 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 23 Mar 2006 14:15:45 -0500
Subject: gnome-screen-saver unlock artwork
In-Reply-To: <1143125429.5133.6.camel@zero.sr.unh.edu>
References: <1143125429.5133.6.camel@zero.sr.unh.edu>
Message-ID: <604aa7910603231115x40c0d2ffp74536dd846e3e6ea@mail.gmail.com>

On 3/23/06, Thomas J. Baker <tjb at unh.edu> wrote:
> Has anyone else seen this?

that's awesome!!!!!!  how to diagnose that....
lets see first guess would be some sort of gdm/gtk/gnome theming which
could be related
per user? Like the gnome splash theme.. isnt that per user
configurable now.. and thus have some sort of systme default as well.

anything in /var/log/message that seems to be associated with
screensaver turning on or the lock dialog showing up?

-jef



From fedora-devel at stefan-neufeind.de  Thu Mar 23 19:16:23 2006
From: fedora-devel at stefan-neufeind.de (Stefan Neufeind)
Date: Thu, 23 Mar 2006 20:16:23 +0100
Subject: Removing dep for httpd from php?
Message-ID: <4422F407.2040209@stefan-neufeind.de>

Hi,

I was wondering if removing the dep for httpd inside package php might
be justified? Seen that in FC4 - and I guess it's in FC5 as well.

When running a server without a webserver installed, you can perfectly
install/use php anyhow. So why is that dep needed? Is there a chance to
get it removed on the next release? :-)


Regards,
 Stefan



From rstrode at redhat.com  Thu Mar 23 19:19:49 2006
From: rstrode at redhat.com (Ray Strode)
Date: Thu, 23 Mar 2006 14:19:49 -0500
Subject: gnome-screen-saver unlock artwork
In-Reply-To: <1143125429.5133.6.camel@zero.sr.unh.edu>
References: <1143125429.5133.6.camel@zero.sr.unh.edu>
Message-ID: <1143141590.10208.0.camel@halflap>

On Thu, 2006-03-23 at 09:50 -0500, Thomas J. Baker wrote:
> I have some inconsistencies across several machines with the artwork for
> the gnome screen saver unlock window that I thought was due to different
> initial fc5 test installs. Now that I've done clean installs of fc5
> proper on the same systems the inconsistencies remain. On some systems I
> have the themed fedora core 5 unlock window and on others I have a
> simple grey box. I can't really do a screen shot because the screen is
> locked. It doesn't appear to be user related because a new user on an
> affected system still has just the grey box unlock dialog.
The themed lock dialogs are per-screensaver.  Only one screensaver
currently provides a themed lock dialog.  It was probably a bad idea to
do it this way.  It causes a lot of confusion.

--Ray



From tjb at unh.edu  Thu Mar 23 19:39:43 2006
From: tjb at unh.edu (Thomas J. Baker)
Date: Thu, 23 Mar 2006 14:39:43 -0500
Subject: gnome-screen-saver unlock artwork
In-Reply-To: <1143141590.10208.0.camel@halflap>
References: <1143125429.5133.6.camel@zero.sr.unh.edu>
	<1143141590.10208.0.camel@halflap>
Message-ID: <1143142783.5133.37.camel@zero.sr.unh.edu>

On Thu, 2006-03-23 at 14:19 -0500, Ray Strode wrote:
> On Thu, 2006-03-23 at 09:50 -0500, Thomas J. Baker wrote:
> > I have some inconsistencies across several machines with the artwork for
> > the gnome screen saver unlock window that I thought was due to different
> > initial fc5 test installs. Now that I've done clean installs of fc5
> > proper on the same systems the inconsistencies remain. On some systems I
> > have the themed fedora core 5 unlock window and on others I have a
> > simple grey box. I can't really do a screen shot because the screen is
> > locked. It doesn't appear to be user related because a new user on an
> > affected system still has just the grey box unlock dialog.
> The themed lock dialogs are per-screensaver.  Only one screensaver
> currently provides a themed lock dialog.  It was probably a bad idea to
> do it this way.  It causes a lot of confusion.
> 
> --Ray
> 

Thanks for the explanation. The Floating Fedora Bubbles is the one with
the themed unlock dialog. At least there's a logical explanation and no
gremlins!

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



From dgregor at redhat.com  Thu Mar 23 19:45:07 2006
From: dgregor at redhat.com (Dennis Gregorovic)
Date: Thu, 23 Mar 2006 14:45:07 -0500
Subject: rawhide report: 20060323 changes
In-Reply-To: <200603231456.k2NEuYt3027315@porkchop.devel.redhat.com>
References: <200603231456.k2NEuYt3027315@porkchop.devel.redhat.com>
Message-ID: <1143143107.2199.1.camel@localhost.localdomain>

On Thu, 2006-03-23 at 09:56 -0500, Build System wrote:
>  
> 
> Updated Packages:
> 
> (none)

There were some issues with today's rawhide tree spin.  A correct
rawhide report email will be coming out in a minute.

-- Dennis



From buildsys at redhat.com  Thu Mar 23 19:46:05 2006
From: buildsys at redhat.com (Build System)
Date: Thu, 23 Mar 2006 14:46:05 -0500
Subject: rawhide report: 20060323 changes
Message-ID: <200603231946.k2NJk5p4014734@porkchop.devel.redhat.com>

 

 
Updated Packages:

aspell-12:0.60.3-6
------------------
* Wed Mar 22 2006 Ivana Varekova <varekova at redhat.com> - 12:0.60.3-6
- remove .la files (bug 184184)

* Thu Mar 02 2006 Ivana Varekova <varekova at redhat.com> - 12:0.60.3-5
- update aspell man page (bug 183205)

* Tue Feb 21 2006 Ivana Varekova <varekova at redhat.com> - 12:0.60.3-4
- fix multilib file conflict

bash-3.1-10
-----------
* Thu Mar 23 2006 Tim Waugh <twaugh at redhat.com> 3.1-10
- Patchlevel 14.

* Thu Mar 02 2006 Tim Waugh <twaugh at redhat.com> 3.1-9
- Fixed duplicate documentation of ulimit '-x' option introduced by
  ulimit patch (bug #183596).

* Tue Feb 21 2006 Tim Waugh <twaugh at redhat.com> 3.1-8
- Patchlevel 10.

beagle-0.2.3-5
--------------
* Tue Mar 21 2006 Alexander Larsson <alexl at redhat.com> 0.2.3-5
- Rebuild fc5 update in rawhide

bind-30:9.3.2-12.FC6
--------------------
* Wed Mar 22 2006 Jason Vas Dias <jvdias at redhat.com> - 30:9.3.2-12
- fix typo in initscript
- fix Requires(post): policycoreutils in sub-packages

cpio-2.6-14.FC5
---------------
* Wed Mar 22 2006 Peter Vrabec <pvrabec at redhat.com> 2.6-14.FC5
- FC5 update

* Wed Mar 15 2006 Peter Vrabec <pvrabec at redhat.com> 2.6-13
- merge toAsciiError.patch with writeOutHeaderBufferOverflow.patch
- merge largeFileGrew.patch with lfs.patch
- fix large file support, cpio is able to store files<8GB 
  in 'old ascii' format (-H odc option)
- adjust warnings.patch

* Tue Mar 14 2006 Peter Vrabec <pvrabec at redhat.com> 2.6-12
- fix warn_if_file_changed() and set exit code to #1 when 
  cpio fails to store file > 4GB (#183224)

cups-1:1.2-0.1.b2.3
-------------------
* Thu Mar 23 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.1.b2.3
- Update to svn snapshot.  No longer need users or policy patches.

expect-5.43.0-4
---------------
* Fri Feb 24 2006 David Cantrell <dcantrell at redhat.com> - 5.43.0-4
- Patch expLogChannelOpen() to create files with 0666 permissions (#182724)

gnome-icon-theme-2.14.2-2
-------------------------
* Wed Mar 22 2006 Matthias Clasen <mclasen at redhat.com> 2.14.2-2
- Update to 2.14.2
- Add symlinks to make application/xml work

kernel-2.6.16-1.2083_FC6
------------------------
* Wed Mar 22 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git5

* Wed Mar 22 2006 David Woodhouse <dwmw2 at redhat.com>
- Update the bcm43xx driver to make it work nicely with initscripts
  and NetworkManager without user intervention.

* Tue Mar 21 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git3
- Improve spinlock scalability on big machines.

m17n-db-1.3.3-2
---------------
* Thu Mar 09 2006 Jens Petersen <petersen at redhat.com> - 1.3.3-2
- Bengali input maps fixes (runab)
  - map Probhat '*' key to an alternate sequence since glyph missing (#179821)
  - more itrans cleanup (#182227)
- add icon for Tamil99 (aalam)

man-pages-fr-0.9.7-14
---------------------
* Thu Mar 23 2006 Karsten Hopp <karsten at redhat.de> 0.9.7-14
- remove pages that conflict with vim

man-pages-it-0.3.0-17
---------------------
* Thu Mar 23 2006 Karsten Hopp <karsten at redhat.de> 0.3.0-17
- remove vim.1, provided by the vim-common package

openoffice.org-1:2.0.2-5.4.3
----------------------------
* Mon Mar 13 2006 Caolan McNamara <caolanm at redhat.com> - 1:2.0.2-5.4
- ooo#59997# replacement opens___.ttf updated
- drop integrated openoffice.org-2.0.0.ooo56651.sw.rtfcrash.patch
- drop integrated openoffice.org-1.9.114.ooo51718.rpath.patch
- add openoffice.org-2.0.2.ooo63155.sfx2.badscript.patch for rh#185390#
- rh#181900# rename Bengali langpack
- drop pagein swappiness foo
- drop nearly 9 megs of afms and ppds

perl-DBD-Pg-1.47-1
------------------
* Wed Mar 22 2006 Jason Vas Dias <jvdias at redhat.com> - 1.47-1
- Upgrade to upstream version 1.47

perl-HTML-Parser-3.51-1.FC6
---------------------------
* Wed Mar 22 2006 Jason Vas Dias <jvdias at redhat.com> - 3.51-1
- upgrade to 3.51

perl-Net-DNS-0.57-1
-------------------
* Wed Mar 08 2006 Jason Vas Dias <jvdias at redhat.com> - 0.57-1
- Upgrade to upstream version 0.57

php-pear-1:1.4.6-2.1
--------------------
* Wed Mar 22 2006 Joe Orton <jorton at redhat.com> 1:1.4.6-2.1
- update to XML_RPC 1.4.5 (#186140)

postgresql-odbc-08.01.0200-2
----------------------------
* Wed Mar 22 2006 Tom Lane <tgl at redhat.com> 08.01.0200-2
- Change library name back to psqlodbc.so, because it appears that upstream
  will revert to that name in next release; no point in thrashing the name.
- Include documentation files unaccountably omitted before (bug #184158)

qt-1:3.3.6-1
------------
* Mon Mar 20 2006 Than Ngo <than at redhat.com> 1:3.3.6-1
- update to 3.3.6
- adapt qt-x11-immodule-unified-qt3.3.5-20060318 to qt-3.3.6
- remove set of fixes for the immodule patch, included in qt-x11-immodule-unified-qt3.3.5-20060318
- remove 0051-qtoolbar_77047.patch, qt-x11-free-3.3.4-assistant_de.patch,
  qt-x11-free-3.3.5-warning.patch, included in new upstream

selinux-policy-2.2.25-2
-----------------------
* Wed Mar 22 2006 Dan Walsh <dwalsh at redhat.com> 2.2.25-2
- Fix pam_console handling of usb_device
- dontaudit logwatch reading /mnt dir

sendmail-8.13.6-1
-----------------
* Wed Mar 22 2006 Thomas Woerner <twoerner at redhat.com> 8.13.6-1
- new version 8.13.6 (fixes VU#834865)
- dropped libmilter-sigwait patch (fixed in 8.13.6)

shadow-utils-2:4.0.14-5.FC5
---------------------------
* Wed Mar 22 2006 Peter Vrabec <pvrabec at redhat.com> 2:4.0.14-5.FC5
* FC5 update

* Fri Mar 10 2006 Peter Vrabec <pvrabec at redhat.com> 2:4.0.14-4
- fix lrename() function to handle relative symlinks too

* Tue Mar 07 2006 Peter Vrabec <pvrabec at redhat.com> 2:4.0.14-3
- set default umask to 077 in login.defs

shared-mime-info-0.17-2
-----------------------
* Wed Mar 22 2006 Matthias Clasen <mclasen at redhat.com> - 0.17-2
- Backport upstream change to fix postscript vs. matlab confusion

* Thu Mar 16 2006 Matthias Clasen <mclasen at redhat.com> - 0.17-1
- Update to 0.17

* Mon Feb 13 2006 Ray Strode <rstrode at redhat.com> - 0.16.cvs20060212-3
- add gthumb as fallback

smartmontools-1:5.33-6
----------------------
* Wed Mar 22 2006 Tomas Mraz <tmraz at redhat.com> - 1:5.33-6
- test SATA drives correctly

* Wed Mar 22 2006 Tomas Mraz <tmraz at redhat.com> - 1:5.33-5
- add default /etc/sysconfig/smartmontools file
- ignore errors on startup (#186130)
- test drive for SMART support before adding it to smartd.conf

star-1.5a73-1
-------------
* Wed Mar 22 2006 Peter Vrabec <pvrabec at redhat.com> 1.5a73-1
- upgrade

* Wed Mar 01 2006 Peter Vrabec <pvrabec at redhat.com> 1.5a72-1
- upgrade

* Wed Feb 22 2006 Peter Vrabec <pvrabec at redhat.com> 1.5a71-1
- upgrade

tar-1.15.1-14
-------------
* Wed Mar 22 2006 Peter Vrabec <pvrabec at redhat.com> 1.15.1-14
- fix problems with extracting large sparse archive members (#185460)

* Fri Feb 17 2006 Peter Vrabec <pvrabec at redhat.com> 1.15.1-13
- fix heap overlfow bug CVE-2006-0300 (#181773)

tcsh-6.14-8
-----------
* Thu Mar 23 2006 Miloslav Trmac <mitr at redhat.com> - 6.14-8
- Backport a patch to ignore LS_COLOR codes introduced in newer coreutils
  (#186037)

tftp-0.42-2
-----------
* Wed Mar 22 2006 Radek Vok??l <rvokal at redhat.com> 0.42-2
- fix double free error when hitting ^C (#186201)

* Wed Feb 22 2006 Radek Vok??l <rvokal at redhat.com> 0.42-1
- upgrade to 0.42

xorg-x11-drv-ati-6.5.7.3-4.cvs20060322
--------------------------------------
* Wed Mar 22 2006 Kristian H??gsberg <krh at redhat.com> 6.5.7.3-4.cvs20060322
- Update to CVS snapshot of 20060322.
- Drop xorg-x11-drv-ati-6.5.7.3-radeon-metamodes-SEGV-fix.patch.

xorg-x11-drv-i810-1.4.1.3-4.cvs20060322
---------------------------------------
* Wed Mar 22 2006 Kristian H??gsberg <krh at redhat.com> 1.4.1.3-4.cvs20060322
- Update to CVS snapshot of 20060322.

xorg-x11-server-1.0.99.1-2
--------------------------
* Wed Mar 22 2006 Soren Sandmann <sandmann at redhat.com> 1.0.99.1-2
- Add xorg-server-1.0.99-composite-visibility.patch to get rid of flashing
  titlebars in compositing metacity.

Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5



From tibbs at math.uh.edu  Thu Mar 23 19:46:21 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Thu, 23 Mar 2006 13:46:21 -0600
Subject: Kernel for SMP VIA C3 machines
Message-ID: <ufafyl92bci.fsf@epithumia.math.uh.edu>

I have a couple of VT310-DP boards (together in a little 1U case,
nice) and found that FC-5 won't do SMP on them.  (The i686 kernels
won't run on this chip.)

What's the cleanest way to add an i586-smp (or better yet, MVIAC3_2-smp)
build target to the existing kernel SRPM?  Currently I'm working from
Fedora CVS (FC-5 branch) which looks like it has reorganized the
config generation a bit.

 - J<



From jspaleta at gmail.com  Thu Mar 23 19:58:09 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 23 Mar 2006 14:58:09 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143127888.2853.96.camel@linux>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux> <1143127888.2853.96.camel@linux>
Message-ID: <604aa7910603231158n4f544409uf2cd289f40039449@mail.gmail.com>

On 3/23/06, Hans Kristian Rosbach <hk at isphuset.no> wrote:
> Just thought I'd voice this before the maintainers just let go
> and completely focus on the one for FC6. I bet obvious fixes
> will be detected in the starting phase of developing for FC6
> and those might be backported to FC5 aswell.

Installer bugs happen with pretty much each release. fixed boot.isos
are usually made available as links in bugzilla tickets as issues are
addressed and I believe there is a mechanism which is applied to
incorporate fixes into the mirrors so people doing network installs
can avoid some problems.

But at no point have I ever seen any discussion at any time which
suggests the release team is interested in spinning up replacement
isos and distributing them.  And quite frankly I don't think this is
the most appropriate time to suggest a change in the release model
used. This is the sort of thing that should be debated during the
testing phase, so plans can be in place to support respins if you are
able to convince the people who have to do them that its a good idea.
I don't think your request for fc5 anaconda updates post release day
is going to change any minds as to the support tradeoffs associated
with official respins that incorporate installer changes.

-jef"too little too late"spaleta



From Curtis at GreenKey.net  Thu Mar 23 20:30:54 2006
From: Curtis at GreenKey.net (Curtis Doty)
Date: Thu, 23 Mar 2006 12:30:54 -0800
Subject: boot images gone?
Message-ID: <4423057E.9090304@GreenKey.net>

What happened to images/* and isolinux/ on rawhide? They seem to have 
vanished last night. Or is it just my mirror.

../C



From tibbs at math.uh.edu  Thu Mar 23 21:14:05 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Thu, 23 Mar 2006 15:14:05 -0600
Subject: Anaconda: good work!
In-Reply-To: <20060323164702.GG3137@exeter.boston.redhat.com> (Chris
	Lumens's message of "Thu, 23 Mar 2006 11:47:02 -0500")
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<20060323164702.GG3137@exeter.boston.redhat.com>
Message-ID: <ufabqvw3luq.fsf@epithumia.math.uh.edu>

>>>>> "CL" == Chris Lumens <clumens at redhat.com> writes:

CL> Making a new anaconda means making new first and second stage
CL> images, which means making new CD and DVD images, which means a
CL> huge headache for mirrors and for keeping track of all these
CL> versions of images floating around.

The thing is, if you're spinning your own distro then you should be
able to figure out how to rebuild the anaconda RPM out of current CVS.
The last time I had to do it it took only a few additional minutes to
build an anaconda with fixes, along with other packages (kudzu in this
case) that needed updates.

The problems crop up when the current development version becomes
unsuitable for installing a current tree (as happened with the switch
to yum).  At that point it might be nice if the anaconda developers
would consider checking any critical fixes into the release branch for
those of us who regularly respin our distros, but I don't see the
point in actually doing releases.

 - J<



From billcrawford1970 at gmail.com  Thu Mar 23 21:42:37 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 23 Mar 2006 21:42:37 +0000
Subject: Anaconda: good work!
In-Reply-To: <20060322214325.GE1115919@hiwaay.net>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<200603222132.00267.billcrawford1970@googlemail.com>
	<20060322214325.GE1115919@hiwaay.net>
Message-ID: <200603232142.37600.billcrawford1970@googlemail.com>

On Wednesday 22 March 2006 21:43, Chris Adams wrote:

> A cow-orker in the next cube is red/green colorblind and most often
> cannot tell between the two (even with solid colors).  With some things,
> if both are side by side, he can tell, but if you just present one or
> the other, he usually cannot.

 Yeah, that kinds makes sense. I do have that problem with some colours (just 
luckily not at the console, usually ... it helps that it's a nice big monitor 
so there's plenty of colour to see, I think).

> There's also blue/yellow colorblind (more rare). :-)

 It is, indeed, much rarer, but yes, all should be catered for in some way. 
There are, though, limits to what one can do (alas); at some point it all 
degenerates to "have to read the text". Blinking for example is only a single 
attribute, after all, and "bold" or "underlined" still only gives you eight 
combinations. Also by that point even normally sighted people are becoming 
confused, anyway.



From cmadams at hiwaay.net  Thu Mar 23 22:21:54 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 23 Mar 2006 16:21:54 -0600
Subject: Anaconda: good work!
In-Reply-To: <200603232142.37600.billcrawford1970@googlemail.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<200603222132.00267.billcrawford1970@googlemail.com>
	<20060322214325.GE1115919@hiwaay.net>
	<200603232142.37600.billcrawford1970@googlemail.com>
Message-ID: <20060323222153.GE747608@hiwaay.net>

Once upon a time, Bill Crawford <billcrawford1970 at gmail.com> said:
>  It is, indeed, much rarer, but yes, all should be catered for in some way. 
> There are, though, limits to what one can do (alas); at some point it all 
> degenerates to "have to read the text". Blinking for example is only a single 
> attribute, after all, and "bold" or "underlined" still only gives you eight 
> combinations. Also by that point even normally sighted people are becoming 
> confused, anyway.

That's why I suggested that the default (pre-selected) button do
nothing.  That is probably the easiest way to distinguish "succeed" from
"fail"; if you hit ENTER on the "succeed" page, you'll move to the next
step, while if you hit ENTER on the "fail" page, you go nowhere (so you
have to read some more to find out what is happening).
-- 
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 bjohnson-dated-1143311757.2c9aa1 at symetrix.com  Thu Mar 23 22:17:41 2006
From: bjohnson-dated-1143311757.2c9aa1 at symetrix.com (Bernard Johnson)
Date: Thu, 23 Mar 2006 15:17:41 -0700
Subject: gnome-screen-saver unlock artwork
In-Reply-To: <1143125429.5133.6.camel@zero.sr.unh.edu>
References: <1143125429.5133.6.camel@zero.sr.unh.edu>
Message-ID: <dvv6q5$ch4$1@sea.gmane.org>

Yes, I was seeing it on my laptop computer, but a clean install of FC5
seems to have fixed it.

Thomas J. Baker wrote:
> I have some inconsistencies across several machines with the artwork for
> the gnome screen saver unlock window that I thought was due to different
> initial fc5 test installs. Now that I've done clean installs of fc5
> proper on the same systems the inconsistencies remain. On some systems I
> have the themed fedora core 5 unlock window and on others I have a
> simple grey box. I can't really do a screen shot because the screen is
> locked. It doesn't appear to be user related because a new user on an
> affected system still has just the grey box unlock dialog.
> 
> Has anyone else seen this? 
> 
> tjb



From fedora-devel at stefan-neufeind.de  Thu Mar 23 22:45:52 2006
From: fedora-devel at stefan-neufeind.de (Stefan Neufeind)
Date: Thu, 23 Mar 2006 23:45:52 +0100
Subject: FC5: Incorrect rndc.key from bind-package?
Message-ID: <44232520.1020404@stefan-neufeind.de>

Hi,

upon upgrading from a working FC4 to FC5 I encountered that named
wouldn't start up anymore because of an incorrect /etc/rndc.key.

It contained:

# cat /etc/rndc.key
key "rndckey" {
        algorithm       hmac-md5;
        secret "@KEY@";
};

which belonged to

# rpm -qf /etc/rndc.key
bind-9.3.2-12.FC5

Has somebody else seen something like this? Does somebody know if the
install-scripts should replace @KEY@ with a random-key?


Regards,
 Stefan



From maxer1 at xmission.com  Thu Mar 23 22:57:52 2006
From: maxer1 at xmission.com (maxer1 at xmission.com)
Date: Thu, 23 Mar 2006 15:57:52 -0700
Subject: Very bizarre upgrade with FC5
Message-ID: <20060323155752.h6kks5euxhws4swo@webmail.xmission.com>

I've seen some weird behavior for an upgrade, but this takes the cake.

Using DVD upgrade install of FC5 from a current FC4 test box exhibted the
following weirdness:

FC5 initially started loading the perfunctory drivers, then stated that the
media couldn't be found in the CDROM drive (which was running up to a point).

Prompted me with a pop up selection of the various media choices: CDROM,
floppy etc.

Then in an attempt to resolve the issue, I switched the media from the CDROM
to the firewire external Sony DVD RW drive. The install again proceeded until
we came to the Fedora Core bubbles splash screen which asks whether to do a
new install or upgrade the existing/found FC4.

When I proceeded with that upgrade, immediately an error message appeared
stating that the swap partition was missing in action and prompted reboot.

Any ideas?

I have been running FC4 test picking up all the updates along the way with yum
update.

Frank Jacobberger



From jspaleta at gmail.com  Fri Mar 24 00:11:02 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 23 Mar 2006 19:11:02 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143133354.23486.17.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
	<1143133354.23486.17.camel@orodruin.boston.redhat.com>
Message-ID: <604aa7910603231611u4ae3499hf532a08e450a2712@mail.gmail.com>

On 3/23/06, Jeremy Katz <katzj at redhat.com> wrote:
> The main thing needed here is having a group step up to create the
> content.  fedora-marketing-love project maybe? :-)

what? you mean a simple application of gtkshots  during my normal
desktop usage isn't enough?

-jef



From ndbecker2 at gmail.com  Fri Mar 24 00:21:36 2006
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 23 Mar 2006 19:21:36 -0500
Subject: fyi: vlc
Message-ID: <dvve2e$2r9$1@sea.gmane.org>

I tried FC5 vlc from livna, but it just gave a bunch of errors when started. 
Then I tried videolan-client from freshrpms.   Better, but gave an error
when trying to open my dvd.

I grabbed the srpm from freshrpms, and (after d/l all the builddeps) it is
rebuilt and working great.



From vonbrand at inf.utfsm.cl  Fri Mar 24 00:23:15 2006
From: vonbrand at inf.utfsm.cl (Horst von Brand)
Date: Thu, 23 Mar 2006 20:23:15 -0400
Subject: The joys of rawhide returning to form 
In-Reply-To: Your message of "Wed, 22 Mar 2006 09:54:24 PST."
	<f6e5806f0603220954v7fca4d5am83a169856b86af8d@mail.gmail.com> 
Message-ID: <200603240023.k2O0NGPb007286@laptop11.inf.utfsm.cl>

darrell pfeifer <darrellpf at gmail.com> wrote:
> For the last couple of weeks as rawhide settled into FC5 I had a
> completely working system. Now that the freeze has been lifted for a
> couple of days I yum updated this morning.

;-)

[...]

> ipw2200 broke
> 
> There was a kernel upgrade (2074) and now the driver won't load.
> Booted the 2064 kernel which continues to work.

The new driver needs new firmware.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513



From andreas.bierfert at lowlatency.de  Fri Mar 24 00:25:15 2006
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Fri, 24 Mar 2006 01:25:15 +0100
Subject: Bootsplash?
In-Reply-To: <1143059186.28627.6.camel@localhost.localdomain>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
Message-ID: <20060324012515.66d801f4@alkaid.a.lan>

On Wed, 22 Mar 2006 20:26:25 +0000
Richard Hughes <hughsient at gmail.com> wrote:
> Even displaying a static bitmap (a-la-windows 98) would be better than
> the black we have now. Not sure if that makes it simpler.

I did some work on splashy a while back because I don't like rhgb and it is
way faster. I wanted to submit it to extras but never found the time to
actually submit it... if this is actually something people want and would like
to have I am more then willing to wipe my spec into shape :)

- Andreas
-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/235602e2/attachment.sig>

From lamont at gurulabs.com  Fri Mar 24 00:47:25 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Thu, 23 Mar 2006 17:47:25 -0700
Subject: Anaconda: good work!
In-Reply-To: <200603221540.36625.kewley@gps.caltech.edu>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<13fb01c64dd7$6ec8ab30$b6491b31@td612671>
	<200603221540.36625.kewley@gps.caltech.edu>
Message-ID: <200603231747.25385.lamont@gurulabs.com>

On Wednesday 22 March 2006 04:40pm, David Kewley wrote:
> On Wednesday 22 March 2006 09:38, Dimi Paun wrote:
> > From: "Jeremy Katz" <katzj at redhat.com>
> >
> > > >   * Disk change indicators
> > >
> > > This comes up from time to time, I'm just not fully convinced of how
> > > useful it is.
> >
> > Coupled with a better time estimate, it would be useful, no doubt.
> > Also copying the contents of the CDs to the HD before hand would be
> > a very good idea too. But when that's not possible (due to free
> > space constraints), the ticks would be nice :)
>
> A suggestion if this gets considered: dd the CD to a .iso file on disk, and
> mount it loopback.  That way you avoid slow CD seeks.

In almost all cases, it will be much faster to do installs via NFS over 
100Mbps than via CD/DVD.

It's probably sixes on "average" hardware to do NFS vs same hard drive, 
speed-wise.  However, it's much more convenient and easier to set up the 
network install once and use it whenever you need it than it is to set up for 
hard drive installs each time.  Also, don't forget to count the time to copy 
the disc image(s) from CD/DVD to hard drive.

Putting the ISO(s) on a USB2.0 hard drive and doing the installs from that is 
quite fast.  To do that, I usually use a boot.iso CD to launch the install 
and get everything else from /dev/sda1 or /dev/sdb1 as the case may be.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/d29499f8/attachment.sig>

From shishz at hotpop.com  Fri Mar 24 00:19:46 2006
From: shishz at hotpop.com (Zing)
Date: Thu, 23 Mar 2006 19:19:46 -0500
Subject: strange X11 Problems with cisco vpn client under Fedora 4 or 5
References: <20060323102746.d7bff2ff.j.rink@freenet.de>
Message-ID: <pan.2006.03.24.00.19.45.916618@hotpop.com>

On Thu, 23 Mar 2006 10:27:46 +0100, J?rn Rink wrote:

> happens ONLY when the cisco vpn client is connected with my office.
> 
> So my question is, how can this happen, where can i look or debug to get
> more info? I have to reboot the computer, deleting modules restarting X do
> not work.
> 
> Anyone here with the same Problem? On my notebook with Fedora Core 3 i do
> not have this problem.

J?rn, I've been dealing with this problem for awhile.  See these bugzilla
reports and help out if you can.  I don't have enough knowledge of X to
know what's going on, but if I revert xf86Xinput.c (see links) to an older
version everything works ok...

Duplicate of #3113, but under Linux FC4 fully updated as of 2006-01-30
https://bugs.freedesktop.org/show_bug.cgi?id=5769

Mouse pointer sticks to left side of screen
https://bugs.freedesktop.org/show_bug.cgi?id=3113

zing



From bojan at rexursive.com  Fri Mar 24 02:31:57 2006
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 24 Mar 2006 13:31:57 +1100
Subject: FC5 updates in testing
Message-ID: <20060324133157.xotlxtzf8ckg0goc@www.rexursive.com>

Just a quick note about all the updates for FC5 in testing (especially  
the kernel). All looks very good on HP xw9300 workstation (dual  
Opteron, running x86_64 FC5). Nvidia drivers from Livna work fine too  
(dual head).

-- 
Bojan



From pjones at redhat.com  Fri Mar 24 04:58:23 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 23 Mar 2006 23:58:23 -0500
Subject: Bootsplash?
In-Reply-To: <1143059186.28627.6.camel@localhost.localdomain>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
Message-ID: <1143176306.10866.5.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-22 at 20:26 +0000, Richard Hughes wrote:
> On Wed, 2006-03-22 at 10:44 -0500, Jeremy Katz wrote:
> > On Wed, 2006-03-22 at 12:30 +0000, Richard Hughes wrote:
> > > I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think
> > > that requires a patch to the kernel away from vanilla, so that might not
> > > be an option for fedora. Maybe rhgb could be used instead?
> > 
> > With the swsusp code currently in the kernel, there isn't really a way
> > to do any sort of useful userspace stuff.  Also, rhgb has the downside
> > of being X based which tends to hit "interesting" corner cases and bugs.
> > All the options here kind of suck :-/
> 
> Even displaying a static bitmap (a-la-windows 98) would be better than
> the black we have now. Not sure if that makes it simpler.

But _much_ more risky.  We switch away from X because being in graphical
mode tends to make suspend/resume break horribly.  This would likely
cause the same failures.

-- 
  Peter



From pjones at redhat.com  Fri Mar 24 05:00:52 2006
From: pjones at redhat.com (Peter Jones)
Date: Fri, 24 Mar 2006 00:00:52 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143048993.2383.9.camel@halflap>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
	<1143048993.2383.9.camel@halflap>
Message-ID: <1143176455.10866.8.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-22 at 12:36 -0500, Ray Strode wrote:

> for S in "<list of schemas here>"; do
>   gconftool-2 --make-install-rule $S
> done
> 
> to
> 
> gconftool-2 --make-install-rule <list of schemas here>

Please,

for x in $schemas ; do echo \'$x\' ; done \
  | xargs gconftool-2 --make-install-rule 

(But we should probably work on actually making gconftool-2 faster at
this, as well)
-- 
  Peter



From pjones at redhat.com  Fri Mar 24 05:15:41 2006
From: pjones at redhat.com (Peter Jones)
Date: Fri, 24 Mar 2006 00:15:41 -0500
Subject: Anaconda: good work!
In-Reply-To: <4422DC72.2000109@feuerpokemon.de>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<44217267.3070002@city-fan.org>
	<1143045982.24028.14.camel@orodruin.boston.redhat.com>
	<44218E8B.2080503@feuerpokemon.de>
	<20060322223601.GA15354@devserv.devel.redhat.com>
	<4422DC72.2000109@feuerpokemon.de>
Message-ID: <1143177344.10866.10.camel@vroomfondel.internal.datastacks.com>

On Thu, 2006-03-23 at 18:35 +0100, dragoran wrote:

> >Well, depending on your point of view, I believe that's either
> >a bug that's always existed, or a request for a feature enhancement. :)
>
> no it seems that raid0 is broken in anaconda and/or fc5 kernel see:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312

No, we just haven't ever supported a raid array as the media for a
"harddisk install".

-- 
  Peter



From rodd at clarkson.id.au  Fri Mar 24 05:25:42 2006
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 24 Mar 2006 16:25:42 +1100
Subject: Today' rawhide update
In-Reply-To: <1143135640.767.2.camel@price.stavtrup-st.dk>
References: <1143135640.767.2.camel@price.stavtrup-st.dk>
Message-ID: <1143177942.2916.14.camel@localhost.localdomain>

Just you!

I got the 20060323 changes, but there weren't any changes so you didn't
in fact miss anything.


R.

On Thu, 2006-03-23 at 18:40 +0100, David Nielsen wrote:
> Is it just me or did we not get a rawhide update today?
> 
> - David
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From dgregor at redhat.com  Fri Mar 24 05:36:42 2006
From: dgregor at redhat.com (Dennis Gregorovic)
Date: Fri, 24 Mar 2006 00:36:42 -0500
Subject: Today' rawhide update
In-Reply-To: <1143135640.767.2.camel@price.stavtrup-st.dk>
References: <1143135640.767.2.camel@price.stavtrup-st.dk>
Message-ID: <1143178603.5939.2.camel@localhost.localdomain>

On Thu, 2006-03-23 at 18:40 +0100, David Nielsen wrote:
> Is it just me or did we not get a rawhide update today?
> 
> - David

The normal cron job was busted last night.  After some investigation, I
fixed the problem and then ran it by hand.  So, the packages and
metadata on d.f.r.c should have the latest stuff.  However, I didn't see
the rawhide-report email come through.  Maybe it's stuck in mailman?

Also, last night's rawhide issue caused install images to not get
created, but they *should* be there tomorrow.  (Well, about two hours
from now at this point)

-- Dennis



From n0dalus+redhat at gmail.com  Fri Mar 24 05:42:20 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Fri, 24 Mar 2006 16:12:20 +1030
Subject: Intelligent Anaconda (was: Re: The Morning After)
In-Reply-To: <1143103731.2853.92.camel@linux>
References: <200603210156.40386.nman64@n-man.com>
	<4421B06A.8030809@fedoraproject.org> <1143103731.2853.92.camel@linux>
Message-ID: <6280325c0603232142j3f99cfa5r3d1a20f2b0bf7a88@mail.gmail.com>

On 3/23/06, Hans Kristian Rosbach <hk at isphuset.no> wrote:
>
> In my opinion when you boot anaconda from CD1, it should ask you what
> cds you have available. So if I only downloaded CD1 & 2 it would not
> allow me to select packages that are not available on those two cds,
> possibly asking me whether I want yum to download what I don't have.
>

I have suggested this before, and thought it would best be combined
with a web interface on the Fedora website which would clone the
install interface. Apart from allowing an easy way to generate
kickstart files, it could also tell you which CDs you would need for
your installation.

Perhaps the most useful thing that a site like this would do is help
work out which packages should be on what CDs to have the lowest
average number of CDs needed per installation. It would also allow
developers to see which installation options are the most used in
practice.

Just some ideas,
n0dalus.



From peter at thecodergeek.com  Fri Mar 24 05:57:43 2006
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 23 Mar 2006 21:57:43 -0800
Subject: Today' rawhide update
In-Reply-To: <1143135640.767.2.camel@price.stavtrup-st.dk>
References: <1143135640.767.2.camel@price.stavtrup-st.dk>
Message-ID: <1143179863.19606.9.camel@tuxhugger>

On Thu, 2006-03-23 at 18:40 +0100, David Nielsen wrote:
> Is it just me or did we not get a rawhide update today?

The 20060323 rawhide report showed no updated packages.
-- 
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: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/f87df43e/attachment.sig>

From elprodigio at gmail.com  Fri Mar 24 07:05:50 2006
From: elprodigio at gmail.com (Didier Casse)
Date: Fri, 24 Mar 2006 15:05:50 +0800
Subject: Where is libtool-ltdl-devel in FC5?
Message-ID: <513a3b30603232305hf0c469bo7161cf16dac21d3c@mail.gmail.com>

Hi,
    I've a simple question: Where is libtool-ltdl-devel in FC5?

Please don't tell me that the libltdl.h and libltdl.so.xxx has been
merged in libtool and libtool-ltdl and that there's no DEVEL package!

--
Cheers,
Didier.

------------
Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe

Didier F.B Casse
PhD candidate, Singapore Synchrotron Light Source (SSLS)
National University of Singapore.



From hk at isphuset.no  Fri Mar 24 07:11:04 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Fri, 24 Mar 2006 08:11:04 +0100
Subject: Anaconda: good work!
In-Reply-To: <604aa7910603231158n4f544409uf2cd289f40039449@mail.gmail.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux> <1143127888.2853.96.camel@linux>
	<604aa7910603231158n4f544409uf2cd289f40039449@mail.gmail.com>
Message-ID: <1143184264.2853.108.camel@linux>

On Thu, 2006-03-23 at 14:58 -0500, Jeff Spaleta wrote:
> On 3/23/06, Hans Kristian Rosbach <hk at isphuset.no> wrote:
> > Just thought I'd voice this before the maintainers just let go
> > and completely focus on the one for FC6. I bet obvious fixes
> > will be detected in the starting phase of developing for FC6
> > and those might be backported to FC5 aswell.
> 
> Installer bugs happen with pretty much each release. fixed boot.isos
> are usually made available as links in bugzilla tickets as issues are
> addressed and I believe there is a mechanism which is applied to
> incorporate fixes into the mirrors so people doing network installs
> can avoid some problems.
> 
> But at no point have I ever seen any discussion at any time which
> suggests the release team is interested in spinning up replacement
> isos and distributing them.  And quite frankly I don't think this is
> the most appropriate time to suggest a change in the release model
> used. 
> I don't think your request for fc5 anaconda updates post release day
> is going to change any minds as to the support tradeoffs associated
> with official respins that incorporate installer changes.

This is not at all what I mean. I mean the anaconda.rpm that I can
download and install on my already installed FC5 computer.

There is bound to be some amount of bugs biting that could be
fixed very easily. I just ask that you sit down in a few weeks time
and take a look over what went wrong with FC5 and backport the
obvious bugfixes from rawhide. After that you probably wouldn't
have to do anything more with it.

I made unofficial FC4 respins (FC4.1 and FC4.2), these ONLY use
the official rpms from the fedora project. None of them rebuilt by me.
Because of this I was stuck with the known buggy anaconda.rpm that
never ever got a single update to fix even the most obvious bugs after
the FC4 release.

Tracking rawhide is going to prove very difficult since I have no
intimate knowledge about anaconda and what parts are sensitive to
changes. Also this would defeat my purpose of using only the official
rpms (base/updates only) from current release.

Dont know what more to say, but I'm a bit disappointed.

> This is the sort of thing that should be debated during the
> testing phase, so plans can be in place to support respins if you are
> able to convince the people who have to do them that its a good idea.

We had a fairly long discussion on this list about this during devel.

-HK



From jkeating at redhat.com  Fri Mar 24 07:20:40 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 23 Mar 2006 23:20:40 -0800
Subject: Anaconda: good work!
In-Reply-To: <604aa7910603231158n4f544409uf2cd289f40039449@mail.gmail.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143127888.2853.96.camel@linux>
	<604aa7910603231158n4f544409uf2cd289f40039449@mail.gmail.com>
Message-ID: <200603232320.44461.jkeating@redhat.com>

On Thursday 23 March 2006 11:58, Jeff Spaleta wrote:
> But at no point have I ever seen any discussion at any time which
> suggests the release team is interested in spinning up replacement
> isos and distributing them. ?And quite frankly I don't think this is
> the most appropriate time to suggest a change in the release model
> used. This is the sort of thing that should be debated during the
> testing phase, so plans can be in place to support respins if you are
> able to convince the people who have to do them that its a good idea.
> I don't think your request for fc5 anaconda updates post release day
> is going to change any minds as to the support tradeoffs associated
> with official respins that incorporate installer changes.

I don't think the OP wanted new isos, rather instead provide updated builds of 
the anaconda package.  Not entirely unreasonable.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/5fb6c3a1/attachment.sig>

From elprodigio at gmail.com  Fri Mar 24 07:23:24 2006
From: elprodigio at gmail.com (Didier Casse)
Date: Fri, 24 Mar 2006 15:23:24 +0800
Subject: Where is libtool-ltdl-devel in FC5?
In-Reply-To: <513a3b30603232305hf0c469bo7161cf16dac21d3c@mail.gmail.com>
References: <513a3b30603232305hf0c469bo7161cf16dac21d3c@mail.gmail.com>
Message-ID: <513a3b30603232323r3c88d43bt6936ba4c25cfb3f6@mail.gmail.com>

On 3/24/06, Didier Casse <elprodigio at gmail.com> wrote:
> Hi,
>     I've a simple question: Where is libtool-ltdl-devel in FC5?
>
> Please don't tell me that the libltdl.h and libltdl.so.xxx has been
> merged in libtool and libtool-ltdl and that there's no DEVEL package!

FORGET THIS EMAIL!

My yum failed to see the libtool-ltdl-devel package in the core for
some unknown reasons. After trying a few times, it finally got it.


--
Cheers,
Didier.

------------
Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe

Didier F.B Casse
PhD candidate, Singapore Synchrotron Light Source (SSLS)
National University of Singapore.



From hk at isphuset.no  Fri Mar 24 07:29:31 2006
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Fri, 24 Mar 2006 08:29:31 +0100
Subject: Anaconda: good work!
In-Reply-To: <20060323164702.GG3137@exeter.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<20060323164702.GG3137@exeter.boston.redhat.com>
Message-ID: <1143185371.2853.118.camel@linux>

On Thu, 2006-03-23 at 11:47 -0500, Chris Lumens wrote:
> > The complete lack of updates to anaconda in FC4 bugged me,
> > but I was too late in the cycle to make you reconsider.
> > This time around I hope you will atleast take obvious
> > bugfixes and maintain the FC5 anaconda atleast for a
> > little while. I'm not asking for new features, only fixes.
> 
> We can't really do this easily.  Making a new anaconda means making new
> first and second stage images, which means making new CD and DVD images,
> which means a huge headache for mirrors and for keeping track of all
> these versions of images floating around.
> 
> One thing we can look into is the possibility of providing an
> updates.img from time to time that rolls up fixes, but this has its own
> set of problems.  Doing something like that will make debugging in the
> future much harder because we'll have to ask people what updates they
> might be using in their installation when they report bugs.  I can just
> see all sorts of problems resulting from that.
> 
> The installer is special.

I'm not talking about a respin of the FC5 installer per se. I'm talking
about updating the anaconda.rpm file available for install via yum after
install. (More details in the mail I just sent in answer to jeff)

Having anaconda.rpm bugfixed just a little after release of FC5 will
make it so much better for use in respins, forks and new community
distros that just want to use a ready anaconda.

In bugzilla I can see several bugs that are showstoppers on some
machines and others that have workarounds. Most of these will probably
be fixed in rawhide during the next week or two (I hope). If just these
bugfixes were to be backported then respins/forks and new distros would
not have to deal with the same issues.

PS: Is the listserver really overloaded now? Both today and yesterday
my mail delivery from fedora lists seems to be 6-12 hours delayed.
I can see my own mails show up in the archives instantaneously and
nobody seems to answer my mails before they get through either so..


-HK



From mk at crc.dk  Fri Mar 24 07:32:30 2006
From: mk at crc.dk (Mogens Kjaer)
Date: Fri, 24 Mar 2006 08:32:30 +0100
Subject: FC5 kickstart  i386 and x86_64
In-Reply-To: <20060323144433.GF3137@exeter.boston.redhat.com>
References: <1143050056.9830.16.camel@mlor.frop.net>
	<20060323144433.GF3137@exeter.boston.redhat.com>
Message-ID: <4423A08E.30309@crc.dk>

Chris Lumens wrote:
...
> Kickstart got a major overhaul for FC5, so it's likely I have
> accidentally dropped some behavior that was present in earlier versions.
> In general, the way we do things is that kickstart asks for any missing
> information so in this case, asking for the networking is consistent
> with that policy.  However if it's a regression from earlier versions,
> file a bug against anaconda and I'll take a look at it.

I like the new kickstart. I've always missed that the installer
didn't ask for the network information in previous versions.

Mogens

-- 
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk at crc.dk Homepage: http://www.crc.dk



From j.w.r.degoede at hhs.nl  Fri Mar 24 07:47:55 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 24 Mar 2006 08:47:55 +0100
Subject: Debuginfo broken in rawhide
Message-ID: <4423A42B.1000008@hhs.nl>

Hi all,

The debug directory of the devel directory does not contain a repodata 
dir, breaking install of -debuginfo packages through yum.

Regards,

Hans




From jkeating at redhat.com  Fri Mar 24 07:57:42 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 23 Mar 2006 23:57:42 -0800
Subject: boot images gone?
In-Reply-To: <4423057E.9090304@GreenKey.net>
References: <4423057E.9090304@GreenKey.net>
Message-ID: <1143187062.3939.2.camel@ender>

On Thu, 2006-03-23 at 12:30 -0800, Curtis Doty wrote:
> What happened to images/* and isolinux/ on rawhide? They seem to have 
> vanished last night. Or is it just my mirror. 

Small breakage, will be fixed soon.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060323/2043e997/attachment.sig>

From buildsys at redhat.com  Fri Mar 24 08:10:02 2006
From: buildsys at redhat.com (Build System)
Date: Fri, 24 Mar 2006 03:10:02 -0500
Subject: rawhide report: 20060324 changes
Message-ID: <200603240810.k2O8A2lI005149@porkchop.devel.redhat.com>

 

 
Updated Packages:

bluez-utils-2.25-5
------------------
* Thu Mar 23 2006 Peter Jones <pjones at redhat.com> - 2.25-5
- Don't poll every 200ms when nothing happens unless there's poll event
  in hidd.

checkpolicy-1.30.1-1
--------------------
* Thu Mar 23 2006 Dan Walsh <dwalsh at redhat.com> - 1.30.1-1
- Latest upgrade from NSA
	* Moved processing of role and user require statements to 2nd pass.

cpio-2.6-15.FC5
---------------
* Thu Mar 23 2006 Peter Vrabec <pvrabec at redhat.com> 2.6-15.FC5
- init struct file_hdr (#186339)

gnome-applet-vm-0.0.7-2
-----------------------
* Thu Mar 23 2006 Karel Zak <kzak at redhat.com> 0.0.7-2
- add dependence on usermode

* Mon Mar 20 2006 Karel Zak <kzak at redhat.com> 0.0.7-1
- new upstream version

hplip-0.9.9-6
-------------
* Thu Mar 23 2006 Tim Waugh <twaugh at redhat.com> 0.9.9-6
- CUPS backend directory is always in /usr/lib.

* Mon Mar 13 2006 Tim Waugh <twaugh at redhat.com> 0.9.9-4
- Quieten hpssd on startup.

* Sat Mar 11 2006 Tim Waugh <twaugh at redhat.com> 0.9.9-3
- Patchlevel 1.

libglade2-2.5.1-5
-----------------
* Thu Mar 23 2006 Matthias Clasen <mclasen at redhat.com> - 2.5.1-5
- Make non-ASCII invisible characters work

mtr-2:0.70-1
------------
* Thu Mar 23 2006 Miroslav Lichvar <mlichvar at redhat.com> - 2:0.70-1
- update to mtr-0.70
- replace s390x patch, drop automake dependency

readahead-1:1.2-2
-----------------
* Mon Mar 20 2006 Karel Zak <kzak at redhat.com> 1.2-2
- cleanup release number
- cleanup spec file

* Thu Mar 16 2006 Karel Zak <kzak at redhat.com>
- update versions in *.in lists

rhpl-0.186-1
------------
* Thu Mar 23 2006 Chris Lumens <clumens at redhat.com> 0.186-1 
- Remove deprecated files now in rhpl or firstboot.

squid-7:2.5.STABLE13-2
----------------------
* Thu Mar 23 2006 Martin Stransky <stransky at redhat.com> - 7:2.5.STABLE13-2
- removed "--with-large-files" on 64bit arches

* Mon Mar 13 2006 Martin Stransky <stransky at redhat.com> - 7:2.5.STABLE13-1
- update to new upstream

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 7:2.5.STABLE12-5.1
- bump again for double-long bug on ppc(64)

tetex-3.0-19
------------
* Thu Mar 23 2006 Jindrich Novy <jnovy at redhat.com> 3.0-19
- install missing OMSrsfs.fd from CTAN to make \mathcal work
  with rsfs fonts (#186373)

* Wed Mar 08 2006 Jindrich Novy <jnovy at redhat.com> 3.0-18
- update vfontmap to attempt to fix #178411

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From seg at haxxed.com  Fri Mar 24 09:31:39 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 24 Mar 2006 03:31:39 -0600
Subject: Anaconda: good work!
In-Reply-To: <1143127335.3802.79.camel@sundaram.pnq.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<1143127335.3802.79.camel@sundaram.pnq.redhat.com>
Message-ID: <1143192699.28002.6.camel@localhost>

Would a respin of at least the rescue ISO be (theoretically) possible?

Personally I'm thinking of the rather annoying X11 bug that was in the
FC4 installer *and* the installed version that caused graphical install
to be unusable, and X to be unusable until you installed the updated
X11. Apparently that wasn't even bad enough for a respin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/a184ef01/attachment.sig>

From jfontain at free.fr  Fri Mar 24 09:30:33 2006
From: jfontain at free.fr (jfontain at free.fr)
Date: Fri, 24 Mar 2006 10:30:33 +0100
Subject: Core 5 and Samba issues
Message-ID: <1143192633.4423bc396d994@imp2-g19.free.fr>

I tried to make a FC4 then a FC5-test machine join an AD domain a while back and
failed.
I am not sure samba can do that reliably yet, but some standard FC procedure or
documentation would certainly be nice.

--
Jean-Luc



From fedora at camperquake.de  Fri Mar 24 09:47:35 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 24 Mar 2006 10:47:35 +0100
Subject: Removing dep for httpd from php?
In-Reply-To: <4422F407.2040209@stefan-neufeind.de>
References: <4422F407.2040209@stefan-neufeind.de>
Message-ID: <20060324104735.148acdc0@soran.addix.net>

Hi.

On Thu, 23 Mar 2006 20:16:23 +0100, Stefan Neufeind wrote:

> When running a server without a webserver installed, you can perfectly
> install/use php anyhow. So why is that dep needed? Is there a chance
> to get it removed on the next release? :-)

This is because mod_php is contained in the package as well, I think.



From fedora-devel-list at thebc.ch  Fri Mar 24 10:22:40 2006
From: fedora-devel-list at thebc.ch (Steven F. Christ)
Date: Fri, 24 Mar 2006 11:22:40 +0100
Subject: x won't start anymore
In-Reply-To: <4423057E.9090304@GreenKey.net>
References: <4423057E.9090304@GreenKey.net>
Message-ID: <20060324112240.3ade8be9@artchaos>

since yesterday x won't start anymore, the error message is:

symbol lookup error: /usr/lib/xorg/modules/drivers/i810_d



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Fri Mar 24 10:25:16 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Fri, 24 Mar 2006 11:25:16 +0100
Subject: Removing dep for httpd from php?
In-Reply-To: <4422F407.2040209@stefan-neufeind.de>
References: <4422F407.2040209@stefan-neufeind.de>
Message-ID: <20060324112516.2118b46e@python2>

Stefan Neufeind wrote :

> I was wondering if removing the dep for httpd inside package php might
> be justified? Seen that in FC4 - and I guess it's in FC5 as well.
> 
> When running a server without a webserver installed, you can perfectly
> install/use php anyhow. So why is that dep needed? Is there a chance to
> get it removed on the next release? :-)

I'd also like to see that happen, but it has already been filed in
bugzilla as a RFE, but got closed as WONTFIX "for the time being".

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

Time to start discussing it again?

In my case, I'm using php through fastcgi with lighttpd more and more,
with stunning performance where scripts output very big web pages or for
websites with lots of static content. On servers configured that way, I'd
like to avoid having httpd installed entirely in order to avoid any
possible confusion (like doing "service httpd restart" by habit instead of
"service lighttpd restart"). Not a strong point, definitely, but still,
having apache being mandatory when using php doesn't make that much sense
originally.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.15-1.2054_FC5
Load : 0.60 0.63 0.48



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Fri Mar 24 10:33:16 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Fri, 24 Mar 2006 11:33:16 +0100
Subject: rawhide report: 20060323 changes
In-Reply-To: <200603231946.k2NJk5p4014734@porkchop.devel.redhat.com>
References: <200603231946.k2NJk5p4014734@porkchop.devel.redhat.com>
Message-ID: <20060324113316.6990a87e@python2>

Build System wrote :

> man-pages-fr-0.9.7-14
> ---------------------
> * Thu Mar 23 2006 Karsten Hopp <karsten at redhat.de> 0.9.7-14
> - remove pages that conflict with vim

This package is in SERIOUS need of more attention than just that :-(

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

Is there any way to maybe poke the docs team about this?

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.15-1.2054_FC5
Load : 0.23 0.47 0.46



From andreas.bierfert at lowlatency.de  Fri Mar 24 11:46:41 2006
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Fri, 24 Mar 2006 12:46:41 +0100
Subject: Bootsplash?
In-Reply-To: <1143059186.28627.6.camel@localhost.localdomain>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
Message-ID: <20060324124641.2d75a27f@alkaid.a.lan>

On Wed, 22 Mar 2006 20:26:25 +0000
Richard Hughes <hughsient at gmail.com> wrote:
> Even displaying a static bitmap (a-la-windows 98) would be better than
> the black we have now. Not sure if that makes it simpler.

Seems my mail from yesterday did not make it to the list:

I worked on splashy a while back which is really nice and a lot faster then
rhgb... I wanted to submit it to extras but never found the time. Reading your
post inspired me to work on it again so I will publish something not long from
now :)

- Andreas
-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/83c94c35/attachment.sig>

From dhollis at davehollis.com  Fri Mar 24 13:00:05 2006
From: dhollis at davehollis.com (David Hollis)
Date: Fri, 24 Mar 2006 08:00:05 -0500
Subject: Removing dep for httpd from php?
In-Reply-To: <4422F407.2040209@stefan-neufeind.de>
References: <4422F407.2040209@stefan-neufeind.de>
Message-ID: <1143205205.6073.8.camel@dhollis-lnx.sunera.com>

On Thu, 2006-03-23 at 20:16 +0100, Stefan Neufeind wrote:
> Hi,
> 
> I was wondering if removing the dep for httpd inside package php might
> be justified? Seen that in FC4 - and I guess it's in FC5 as well.
> 
> When running a server without a webserver installed, you can perfectly
> install/use php anyhow. So why is that dep needed? Is there a chance to
> get it removed on the next release? :-)
> 

I think that it would be do-able if the Apache module part (libphp5.so)
was split off into a separate package - mod_php5 or the like.
Technically, removing the httpd-mmn requirement on the package does
allow you to install it cleanly on a system that doesn't have httpd, but
the package is 'broken' in that the Apache module doesn't work.  I can
see benefit in being able to install PHP without having to pull in
Apache.  It can be useful at times for writing little CLI type apps,
especially in the case where it is for performing
maintenance/administrative type tasks for the webserver and it's easier
to use PHP since you can re-use some of the code/libraries from the web
app itself.

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

From jdesbonnet at gmail.com  Fri Mar 24 13:07:46 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Fri, 24 Mar 2006 13:07:46 +0000
Subject: Anaconda: good work!
In-Reply-To: <20060323222153.GE747608@hiwaay.net>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<200603222132.00267.billcrawford1970@googlemail.com>
	<20060322214325.GE1115919@hiwaay.net>
	<200603232142.37600.billcrawford1970@googlemail.com>
	<20060323222153.GE747608@hiwaay.net>
Message-ID: <1cef3e950603240507v20f132f9od480d854698a1d20@mail.gmail.com>

BTW: is it a bug or feature that you can only do a HTTP install on
port 80? (ie you are asked only for a host and path, but not a port).
joe.



From sundaram at fedoraproject.org  Fri Mar 24 13:31:05 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 24 Mar 2006 19:01:05 +0530
Subject: Anaconda: good work!
In-Reply-To: <1143133354.23486.17.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
	<1143133354.23486.17.camel@orodruin.boston.redhat.com>
Message-ID: <1143207065.3802.99.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-23 at 12:02 -0500, Jeremy Katz wrote:
> On Wed, 2006-03-22 at 21:29 +0100, Thomas Canniot wrote:
> > What I found sad in anaconda during the installation process is the
> > permanent showing of our brand new logo for about 20 min, while anaconda
> > is copying files. We had in previous version of FC, texts talking about
> > the distribution itself. These have disappeared, too bad really.
> 
> The main thing needed here is having a group step up to create the
> content.  fedora-marketing-love project maybe? :-)
> 
> Jeremy
> 

Heh. fedora-marketing would very well work for this purpose. In fact I
asked explicitly for something like this earlier with no takers. Maybe
for FC6 someone will step up.

Rahul



From j.rink at freenet.de  Fri Mar 24 13:44:20 2006
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Fri, 24 Mar 2006 14:44:20 +0100
Subject: Anaconda: good work!
In-Reply-To: <131501c64dc2$fe1522b0$b6491b31@td612671>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
Message-ID: <20060324144420.57d89213.j.rink@freenet.de>

Am Wed, 22 Mar 2006 10:12:09 -0500
hat "Dimi Paun" <dimi at lattica.com> (Dimi Paun) folgendes geschrieben:

> Hi Jeremy,
> 
> Just wanted to share a few thoughts about anaconda,
> while fresh in my mind (I've managed to install FC5
> last night).
> 
> First impression: anaconda really rocks! This is a
> very solid, pleasant installer.

Yes, but since Redhat mkkickstart i missed something which let
me take SUSE for automatic installation in our firm.

You have no choice to get some individual input into the installation.

What i mean:
we have to install nearly 500 computer automatically in the office of
our customers (banks). Each computer has its own, predefined name, and
we are using logical (virtuell, self generated) MAC Adresses for
these PC's. So, tell me how to get the MAC Adress into the
installation via menu? The customer has to input it. For the
suse Installation we hav solved this with dialog tricks over the
autoyast console text menu to get the input.

And the network interface is configured AFTER the input.

I have no idea how to implement this in an anaconda kickstart
installation. Thats my wish, a point in the installation where i can,
if i want, ask for individual settings which override the ks.cfg
settings.

When anyone has an idea for this, i am the first who changed the
auto install from SuSE to fedora ;-)

CU
 Joern Rink   



From stickster at gmail.com  Fri Mar 24 13:49:36 2006
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 24 Mar 2006 08:49:36 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143045925.24028.12.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
Message-ID: <1143208176.2929.10.camel@localhost.localdomain>

On Wed, 2006-03-22 at 11:45 -0500, Jeremy Katz wrote:
>>   * Links don't work in Release Notes
>>     Rather frustrating, considering the size of the doc.
>>     Links within the document should work, if they
>>     look like regular links (color, cursor)
>
> Yeah.  We didn't have HTML release notes until late in the game.  At
> that point, I noticed but it was a bit risky to be going and making
> the necessary changes to have them work.
>
>>   * External links in Release Notes are confusing
>>     These can't possibly work, it would be nice if we
>>     can disable them to avoid confusion.
> 
> Hrm.  Not sure how to handle this.  They could conceivably work in
> network installs, but are almost certainly a bad idea.  Maybe the way
> to do this is to do some processing on the release notes file before
> we feed it to the viewer

This was my thought too.  A small XSL snippet and a specialized Makefile
target for the Anaconda-destined build should take care of this.  I
don't think anyone would reasonably argue against the fact that you guys
are using GtkHtml3 (right?) to render the notes in Anaconda now.  But it
would best not to mislead readers also.  I am cc'ing the Docs list on
this so we can capture the discussion, but a bug would be appreciated,
filed against Fedora Documentation -> toolchain-devel.

>>   * Release Notes too big?
>>     I found them to be too big/verbose, especially for
>>     a light read during install. But maybe it's just me.
>
> Yep, the Docs project has rocked at getting lots of content.  This has
> the downside of there being lots of content.  Double-edged sword...

Hey, are you trolling for compliments?  OK, OK, Anaconda ROCKS.  ;-D
(No, seriously.)

In any case, I agree, the release notes are a little TOO sizable.  I
think the general tenor with having community-provided "beats" with a
different author for each one means that everyone is under the
impression their content is of paramount importance.  With a very
decentralized process the first time through, we erred on the side of
inclusion, so as not to cheese anyone off by leaving out the one
surprise that hit their particular edge case. :-)

As we develop this process, which was new for FC5, I'm certain there
should and will be a strong guiding personality to "wield the red pen"
judiciously.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/7e689c14/attachment.sig>

From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Fri Mar 24 14:02:00 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Fri, 24 Mar 2006 15:02:00 +0100
Subject: fyi: vlc
In-Reply-To: <dvve2e$2r9$1@sea.gmane.org>
References: <dvve2e$2r9$1@sea.gmane.org>
Message-ID: <20060324150200.636182cb@python2>

Neal Becker wrote :

> I tried FC5 vlc from livna, but it just gave a bunch of errors when started. 
> Then I tried videolan-client from freshrpms.   Better, but gave an error
> when trying to open my dvd.
> 
> I grabbed the srpm from freshrpms, and (after d/l all the builddeps) it is
> rebuilt and working great.

Interesting :-/
Could you please have a look at the build log from the freshrpms.net
package and check the relevant differences with what you've got that could
explain the DVD playback problem?

http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/5/videolan-client/

Matthias

BTW: I appreciate this kind of feedback on the freshrpms-list or in
private email, so that known problems can get fixed ;-)

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.15-1.2054_FC5
Load : 0.30 0.65 0.57



From stickster at gmail.com  Fri Mar 24 14:00:48 2006
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 24 Mar 2006 09:00:48 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143133354.23486.17.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
	<1143133354.23486.17.camel@orodruin.boston.redhat.com>
Message-ID: <1143208849.2929.12.camel@localhost.localdomain>

On Thu, 2006-03-23 at 12:02 -0500, Jeremy Katz wrote:
> On Wed, 2006-03-22 at 21:29 +0100, Thomas Canniot wrote:
> > What I found sad in anaconda during the installation process is the
> > permanent showing of our brand new logo for about 20 min, while anaconda
> > is copying files. We had in previous version of FC, texts talking about
> > the distribution itself. These have disappeared, too bad really.
> 
> The main thing needed here is having a group step up to create the
> content.  fedora-marketing-love project maybe? :-)

Certainly the Docs Project would be happy to get involved, at a minimum
to provide proofreading and editing for the text.  Most of our members
are subscribed to marketing, IIRC.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/bd67114e/attachment.sig>

From dhollis at davehollis.com  Fri Mar 24 14:26:33 2006
From: dhollis at davehollis.com (David Hollis)
Date: Fri, 24 Mar 2006 09:26:33 -0500
Subject: FC5: Incorrect rndc.key from bind-package?
In-Reply-To: <44232520.1020404@stefan-neufeind.de>
References: <44232520.1020404@stefan-neufeind.de>
Message-ID: <1143210393.2539.0.camel@dhollis-lnx.sunera.com>

On Thu, 2006-03-23 at 23:45 +0100, Stefan Neufeind wrote:
> Hi,
> 
> upon upgrading from a working FC4 to FC5 I encountered that named
> wouldn't start up anymore because of an incorrect /etc/rndc.key.
> 
> It contained:
> 
> # cat /etc/rndc.key
> key "rndckey" {
>         algorithm       hmac-md5;
>         secret "@KEY@";
> };
> 
> which belonged to
> 
> # rpm -qf /etc/rndc.key
> bind-9.3.2-12.FC5
> 
> Has somebody else seen something like this? Does somebody know if the
> install-scripts should replace @KEY@ with a random-key?

This snippet from the bind %postinstall should take care of it:

        if /bin/egrep -q '@KEY@' /etc/rndc.key; then
           /bin/sed -i -e
"s^@KEY@^`/usr/sbin/dns-keygen`^" /etc/rndc.key ;
           chmod 0640  /etc/rndc.key
           chown root:named /etc/rndc.key
        fi

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

From sundaram at fedoraproject.org  Fri Mar 24 14:39:52 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 24 Mar 2006 20:09:52 +0530
Subject: Bootsplash?
In-Reply-To: <20060324012515.66d801f4@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
Message-ID: <1143211193.3802.120.camel@sundaram.pnq.redhat.com>

On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
> On Wed, 22 Mar 2006 20:26:25 +0000
> Richard Hughes <hughsient at gmail.com> wrote:
> > Even displaying a static bitmap (a-la-windows 98) would be better than
> > the black we have now. Not sure if that makes it simpler.
> 
> I did some work on splashy a while back because I don't like rhgb and it is
> way faster. I wanted to submit it to extras but never found the time to
> actually submit it... if this is actually something people want and would like
> to have I am more then willing to wipe my spec into shape :)

Might be a good alternative path to try out.

Rahul



From harald at redhat.com  Fri Mar 24 14:41:21 2006
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 24 Mar 2006 15:41:21 +0100
Subject: FC5 test3 udev hang
In-Reply-To: <d5ad21470603130013v57ebe748g75ced763f7fb5073@mail.gmail.com>
References: <d5ad21470603130013v57ebe748g75ced763f7fb5073@mail.gmail.com>
Message-ID: <44240511.1010404@redhat.com>

you may look at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186164
and test
http://www.redhat.com/archives/fedora-test-list/2006-March/msg01542.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3621 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/bb5dd2a9/attachment.bin>

From jburgess at uklinux.net  Fri Mar 24 15:05:02 2006
From: jburgess at uklinux.net (Jon Burgess)
Date: Fri, 24 Mar 2006 15:05:02 +0000
Subject: Anaconda: good work!
In-Reply-To: <20060323164702.GG3137@exeter.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>	<1143045925.24028.12.camel@orodruin.boston.redhat.com>	<1143102722.2853.83.camel@linux>
	<20060323164702.GG3137@exeter.boston.redhat.com>
Message-ID: <44240A9E.4000602@uklinux.net>

Chris Lumens wrote:
> We can't really do this easily.  Making a new anaconda means making new
> first and second stage images, which means making new CD and DVD images,
> which means a huge headache for mirrors and for keeping track of all
> these versions of images floating around.

Using Jigdo http://atterer.net/jigdo/ could help reduce the amount of 
data needed to be stored by the mirrors for a re-spun CD/DVD ISOs. It 
reduces the amount of data to be downloaded if the user already has the 
original ISOs.

It also allows enables other things like making a set of CD ISOs from 
the RPMS on a DVD ISO (or the reverse).

I see it has just been added to extras-devel if anyone wants to try it out.

	Jon



From katzj at redhat.com  Fri Mar 24 15:41:26 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 24 Mar 2006 10:41:26 -0500
Subject: Bootsplash?
In-Reply-To: <20060324012515.66d801f4@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
Message-ID: <1143214886.7224.0.camel@orodruin.boston.redhat.com>

On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
> On Wed, 22 Mar 2006 20:26:25 +0000
> Richard Hughes <hughsient at gmail.com> wrote:
> > Even displaying a static bitmap (a-la-windows 98) would be better than
> > the black we have now. Not sure if that makes it simpler.
> 
> I did some work on splashy a while back because I don't like rhgb and it is
> way faster. I wanted to submit it to extras but never found the time to
> actually submit it... if this is actually something people want and would like
> to have I am more then willing to wipe my spec into shape :)

It looks like splashy uses directfb which then requires fbdev.  fbdev +
accelerated X servers often ends up being a recipe for things to break
in odd and "exciting" ways :-/

Jeremy



From katzj at redhat.com  Fri Mar 24 15:44:55 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 24 Mar 2006 10:44:55 -0500
Subject: boot images gone?
In-Reply-To: <4423057E.9090304@GreenKey.net>
References: <4423057E.9090304@GreenKey.net>
Message-ID: <1143215095.7224.2.camel@orodruin.boston.redhat.com>

On Thu, 2006-03-23 at 12:30 -0800, Curtis Doty wrote:
> What happened to images/* and isolinux/ on rawhide? They seem to have 
> vanished last night. Or is it just my mirror.

The newer version of cpio was causing problems for tree builds

Jeremy



From casimiro.barreto at gmail.com  Fri Mar 24 16:02:53 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 24 Mar 2006 13:02:53 -0300
Subject: PHP-5 seems to be screwed on FC-5
Message-ID: <4424182D.9040202@gmail.com>

Hello,

Yesterday I updated one of my servers to FC-5. The primary effect sensed 
was that PHP-5 seems to be broken. Oh... yeah... it works up to a 
certain point but, after that, it miserably fails.

For instance, I have a ridiculous program that count hits. It stopped 
working. Not only a single f_ck_g error message or warning in the 
logs... I have an schedule program that works with MySQL and now it is 
simply unable to deal with ISO-8859-1 encoding... Oh... by the way... 
also refuses to work properly in UTF-8 (not that suported by MySQL 
itself) and other oddities... But as ALL UNIVERSE speaks English, why to 
bother with those who don't...

In both cases I have very little evidence of what is going on (really 
very little)... For instance... $_SEVER['ALL_HTTP'] (quite standard in 
PHP-5) issues error messages and little nasty things like that.

[root at sol httpd]# cat error_log
(...)
PHP Warning:  PHP Startup: ,L\x8c: Unable to initialize module\nModule 
compiled with module API=20041030, debug=0, thread-safety=0\nPHP    
compiled with module API=20050922, debug=0, thread-safety=0\nThese 
options need to match\n in Unknown on line 0
[Fri Mar 24 13:24:39 2006] [notice] mod_python: Creating 4 session 
mutexes based on 256 max processes and 0 max threads.
[Fri Mar 24 13:24:40 2006] [notice] Apache/2.2.0 (Fedora) configured -- 
resuming normal operations
[Fri Mar 24 13:41:07 2006] [error] [client 192.168.1.1] PHP Notice:  
Undefined index:  ALL_HTTP in 
/var/www/html/.../streaming/src/core/web_server/SLISAPI.php on line 40
(...)

Since pre-compiled versions of PHP are not to be found on Zend (I guess 
they got tired of things workin in one hour and not workin the next), I 
think it is a good thing that Fedora developers take care about what was 
working and will stop to work on next release... Including explicit 
mechanisms for downgrading...

Besides, I fixed the problems with device drivers (USB and SOUND) on 
FC5. Just rebuilding all the kernel (about a 2 hour work)... after all, 
ASUS being so minor motherboard manufacturer, who in the Universe would 
give a heck if Linux don't work in boxes that use ASUS, Pentium 4 and 
SIS chipsets.

Besides, RAID1 is still crashing. The same with RAID0 and linear. With 
SATA HDDs. Perhaps better thing to do is to spend some thousand US$ 
purchasing an external raid... since it is almost impossible to fix 
something that simply locks the sistem (much like M$) without leaving a 
single trace of what the hell happened.

Regards,

Casimiro

PS: I am not one of those ass-kisses that keeps congratulating for next 
versions... Next versions MUST work all right to deserve congratulation. 
Otherwise it will wind up just like other technological toys that 
enjoyed college students.



From Curtis at GreenKey.net  Fri Mar 24 16:22:07 2006
From: Curtis at GreenKey.net (Curtis Doty)
Date: Fri, 24 Mar 2006 08:22:07 -0800
Subject: FC5: Incorrect rndc.key from bind-package?
In-Reply-To: <44232520.1020404@stefan-neufeind.de>
References: <44232520.1020404@stefan-neufeind.de>
Message-ID: <44241CAF.3040505@GreenKey.net>

Stefan Neufeind wrote:
> upon upgrading from a working FC4 to FC5 I encountered that named
> wouldn't start up anymore because of an incorrect /etc/rndc.key.
>
> It contained:
>
> # cat /etc/rndc.key
> key "rndckey" {
>         algorithm       hmac-md5;
>         secret "@KEY@";
> };
>
> which belonged to
>
> # rpm -qf /etc/rndc.key
> bind-9.3.2-12.FC5
>
> Has somebody else seen something like this? Does somebody know if the
> install-scripts should replace @KEY@ with a random-key?
>   

$ rpm -q --scripts bind

-- 
These are not the droids you're looking for. - Obi-Wan Kenobi




From emeric.maschino at jouy.inra.fr  Thu Mar 23 22:11:17 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Thu, 23 Mar 2006 23:11:17 +0100
Subject: Today's (or maybe yersterday's) AVCs
Message-ID: <1143151877.44231d05e9406@www.jouy.inra.fr>

Hi,

The following AVCs are recorded in my audit.log file:

type=AVC msg=audit(1143153619.028:6): avc:  denied  { create } for  pid=2016
comm="cupsd" name="cups.sock" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file

type=AVC msg=audit(1143150069.342:14): avc:  denied  { use } for  pid=2478
comm="bluez-pin" name="[9973]" dev=pipefs ino=9973
scontext=user_u:system_r:bluetooth_helper_t:s0
tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd

Cheers,

   ?meric



From notting at redhat.com  Fri Mar 24 16:47:59 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 24 Mar 2006 11:47:59 -0500
Subject: Anaconda: good work!
In-Reply-To: <1143133354.23486.17.camel@orodruin.boston.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
	<1143133354.23486.17.camel@orodruin.boston.redhat.com>
Message-ID: <20060324164759.GA30366@devserv.devel.redhat.com>

Jeremy Katz (katzj at redhat.com) said: 
> On Wed, 2006-03-22 at 21:29 +0100, Thomas Canniot wrote:
> > What I found sad in anaconda during the installation process is the
> > permanent showing of our brand new logo for about 20 min, while anaconda
> > is copying files. We had in previous version of FC, texts talking about
> > the distribution itself. These have disappeared, too bad really.
> 
> The main thing needed here is having a group step up to create the
> content.  fedora-marketing-love project maybe? :-)

And, of course, getting the content translated. (It does 'bloat'
the stage2 image by some as well, especially if you have translated
images.)

Bill



From icon at fedoraproject.org  Fri Mar 24 16:52:19 2006
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Fri, 24 Mar 2006 11:52:19 -0500
Subject: Removing dep for httpd from php?
In-Reply-To: <4422F407.2040209@stefan-neufeind.de>
References: <4422F407.2040209@stefan-neufeind.de>
Message-ID: <442423C3.7040709@fedoraproject.org>

Stefan Neufeind wrote:
> Hi,
> 
> I was wondering if removing the dep for httpd inside package php might
> be justified? Seen that in FC4 - and I guess it's in FC5 as well.
> 
> When running a server without a webserver installed, you can perfectly
> install/use php anyhow. So why is that dep needed? Is there a chance to
> get it removed on the next release? :-)

Feel free to reopen and harp upon this some more. :)

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

Regards,
-- 
Konstantin Ryabitsev
McGill University WSG

Wash: "Oh my god, it's grotesque! Oh, and there's something in a jar."
				--Episode #12, "The Message"



From dragoran at feuerpokemon.de  Fri Mar 24 16:53:11 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Fri, 24 Mar 2006 17:53:11 +0100
Subject: FC5 weird raid issues
Message-ID: <442423F7.7060100@feuerpokemon.de>

I have tryed to upgrade from FC4 -> FC5 using anaconda but it did not 
detect my FC4 installation which is installed on /dev/md0.
It tryes to add a non raid partition to the array and ignores the raid 
partition. This causes the initalisation of md0 to fail.
Is this a kernel or anaconda bug?
Bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312
(no reply ...)
So I backuped my data dan tryed a reinstall and it detected the md0 
array in diskdruid but showed "foreign" as filesystem..
did edit and set mount point to / and filesystem ext3
but it failed formating it with a messages saying that it failed and 
that I should press enter to reboot the system.
What happend? How could such things happen with a *final* release? Raid 
support seems broken and nobody has noticed.
I always updated my system from RH9->FC1->FC2->FC3->FC4 (then 
reinstalled FC4 because of i386->x86_64) but it seems that upgrade is no 
more possible to FC5 :(





From hughsient at gmail.com  Fri Mar 24 17:02:08 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 24 Mar 2006 17:02:08 +0000
Subject: Bootsplash?
In-Reply-To: <20060324012515.66d801f4@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
Message-ID: <1143219728.22815.1.camel@localhost.localdomain>

On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
> On Wed, 22 Mar 2006 20:26:25 +0000
> Richard Hughes <hughsient at gmail.com> wrote:
> > Even displaying a static bitmap (a-la-windows 98) would be better than
> > the black we have now. Not sure if that makes it simpler.
> 
> I did some work on splashy a while back because I don't like rhgb and it is
> way faster. I wanted to submit it to extras but never found the time to
> actually submit it... if this is actually something people want and would like
> to have I am more then willing to wipe my spec into shape :)

I can't comment on rhgb, as I spend most of my time waiting for a
suspend or resume, and so I only see rhbg once a week or so.

If you've got a spec already, or a src.rpm post the link and we can give
it a try.

Thanks,

Richard.



From toshio at tiki-lounge.com  Fri Mar 24 17:17:42 2006
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Fri, 24 Mar 2006 09:17:42 -0800
Subject: Bootsplash?
In-Reply-To: <20060324012515.66d801f4@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
Message-ID: <1143220662.3500.1.camel@localhost>

On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
> On Wed, 22 Mar 2006 20:26:25 +0000
> Richard Hughes <hughsient at gmail.com> wrote:
> > Even displaying a static bitmap (a-la-windows 98) would be better than
> > the black we have now. Not sure if that makes it simpler.
> 
> I did some work on splashy a while back because I don't like rhgb and it is
> way faster. I wanted to submit it to extras but never found the time to
> actually submit it... if this is actually something people want and would like
> to have I am more then willing to wipe my spec into shape :)

http://splashy.alioth.debian.org/wiki/doku.php

Hmm..  No kernel patches and no X...  If you submit it you'll get
interest from me at least :-)

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

From j.rink at freenet.de  Fri Mar 24 17:17:34 2006
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Fri, 24 Mar 2006 18:17:34 +0100
Subject: strange X11 Problems with cisco vpn client under Fedora 4 or 5
In-Reply-To: <pan.2006.03.24.00.19.45.916618@hotpop.com>
References: <20060323102746.d7bff2ff.j.rink@freenet.de>
	<pan.2006.03.24.00.19.45.916618@hotpop.com>
Message-ID: <20060324181734.aca61fc6.j.rink@freenet.de>

Am Thu, 23 Mar 2006 19:19:46 -0500
hat Zing <shishz at hotpop.com> (Zing) folgendes geschrieben:

> On Thu, 23 Mar 2006 10:27:46 +0100, J?rn Rink wrote:
> 

> J?rn, I've been dealing with this problem for awhile.  See these
> bugzilla reports and help out if you can.  I don't have enough
> knowledge of X to know what's going on, but if I revert xf86Xinput.c
> (see links) to an older version everything works ok...
>

wow, cool, you understand my problem described with broken english
and you have the same problem. Thank good, i thought i was an idiot in
installing a fedora installation, because this problem was the reason
not to install FC 4 on my notebook.

Thanks for your help.




From dragoran at feuerpokemon.de  Fri Mar 24 17:47:08 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Fri, 24 Mar 2006 18:47:08 +0100
Subject: Anaconda: good work!
In-Reply-To: <1143177344.10866.10.camel@vroomfondel.internal.datastacks.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>	<44217267.3070002@city-fan.org>	<1143045982.24028.14.camel@orodruin.boston.redhat.com>	<44218E8B.2080503@feuerpokemon.de>	<20060322223601.GA15354@devserv.devel.redhat.com>	<4422DC72.2000109@feuerpokemon.de>
	<1143177344.10866.10.camel@vroomfondel.internal.datastacks.com>
Message-ID: <4424309C.2090000@feuerpokemon.de>

Peter Jones wrote:

>On Thu, 2006-03-23 at 18:35 +0100, dragoran wrote:
>
>  
>
>>>Well, depending on your point of view, I believe that's either
>>>a bug that's always existed, or a request for a feature enhancement. :)
>>>      
>>>
>>no it seems that raid0 is broken in anaconda and/or fc5 kernel see:
>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312
>>    
>>
>
>No, we just haven't ever supported a raid array as the media for a
>"harddisk install".
>
>  
>
but what about upgrades from a system that is installed on a raid array? 
(see bugreport)



From cmadams at hiwaay.net  Fri Mar 24 17:56:03 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 24 Mar 2006 11:56:03 -0600
Subject: Crashes with via_velocity?
Message-ID: <20060324175603.GA1325128@hiwaay.net>

Okay, I finally got around to loading FC5 on my Athlon 64 system here.
I first tried the 32 bit install.  The install (from local hard drive)
worked fine, but during boot, it got into a cycle of oopses during or
right after network setup.  I booted it single user mode and managed to
reproduce the oops.

I then tried a 64 bit install.  Again, install worked fine, but it
oopses during network config during boot.

This is an Abit AV8 motherboard with built-in Via gigabit ethernet
(via_velocity).  I've also added a Compaq dual 10/100 NIC (two e100
chips behind a DEC PCI bridge).  The e100s are eth0 and eth1 and the
via_velocity is eth2.  It oopses before configuring eth2 I think, but
the common thing in both 32 and 64 bit oopses is the message "last sysfs
file: /class/net/eth2/address".

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

-- 
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 jason.connor at gmail.com  Fri Mar 24 17:59:57 2006
From: jason.connor at gmail.com (Jason Connor)
Date: Fri, 24 Mar 2006 10:59:57 -0700
Subject: Fedora core for the Itanium
Message-ID: <c15751d30603240959l1f3e1261sbc75f01dfb856abb@mail.gmail.com>

Are there any plans for doing stable releases of fedora core for ia64?

I've seen the rawhide tree for the platform, but with the recent
pledges from intel, hp, and others to put more money into the
platform, I think it might be time to release fedora for end users on
it.
--
Jason Connor

"Don't worry about what anybody else is going to do.
The best way to predict the future is to invent it."
-- Alan Kay



From sundaram at fedoraproject.org  Fri Mar 24 18:00:32 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 24 Mar 2006 23:30:32 +0530
Subject: Intelligent Anaconda (was: Re: The Morning After)
In-Reply-To: <6280325c0603232142j3f99cfa5r3d1a20f2b0bf7a88@mail.gmail.com>
References: <200603210156.40386.nman64@n-man.com>
	<4421B06A.8030809@fedoraproject.org> <1143103731.2853.92.camel@linux>
	<6280325c0603232142j3f99cfa5r3d1a20f2b0bf7a88@mail.gmail.com>
Message-ID: <1143223232.3802.134.camel@sundaram.pnq.redhat.com>

On Fri, 2006-03-24 at 16:12 +1030, n0dalus wrote:
> On 3/23/06, Hans Kristian Rosbach <hk at isphuset.no> wrote:
> >
> > In my opinion when you boot anaconda from CD1, it should ask you what
> > cds you have available. So if I only downloaded CD1 & 2 it would not
> > allow me to select packages that are not available on those two cds,
> > possibly asking me whether I want yum to download what I don't have.
> >
> 
> I have suggested this before, and thought it would best be combined
> with a web interface on the Fedora website which would clone the
> install interface. Apart from allowing an easy way to generate
> kickstart files, it could also tell you which CDs you would need for
> your installation.
> 
> Perhaps the most useful thing that a site like this would do is help
> work out which packages should be on what CDs to have the lowest
> average number of CDs needed per installation. It would also allow
> developers to see which installation options are the most used in
> practice.
> 
> Just some ideas,
> n0dalus.

Want to give this idea a try on your own? We could get you some cvs and
web space setup to stage.

Rahul




From fedora at adslpipe.co.uk  Fri Mar 24 18:06:30 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Fri, 24 Mar 2006 18:06:30 +0000
Subject: fyi: vlc
In-Reply-To: <dvve2e$2r9$1@sea.gmane.org>
References: <dvve2e$2r9$1@sea.gmane.org>
Message-ID: <44243526.1030803@adslpipe.co.uk>

Neal Becker wrote:

> I tried FC5 vlc from livna, but it just gave a bunch of errors when started. 

Are you on x86_64? If so you might find this is the cause
http://bugzilla.livna.org/show_bug.cgi?id=775
certainly fixed it for me ...







From rdieter at math.unl.edu  Fri Mar 24 18:39:54 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 24 Mar 2006 12:39:54 -0600
Subject: Where is libtool-ltdl-devel in FC5?
In-Reply-To: <513a3b30603232305hf0c469bo7161cf16dac21d3c@mail.gmail.com>
References: <513a3b30603232305hf0c469bo7161cf16dac21d3c@mail.gmail.com>
Message-ID: <44243CFA.8000907@math.unl.edu>

Didier Casse wrote:
>     I've a simple question: Where is libtool-ltdl-devel in FC5?

It's there on my FC5 box/dvd.

-- Rex



From jspaleta at gmail.com  Fri Mar 24 18:44:53 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 24 Mar 2006 13:44:53 -0500
Subject: Anaconda: good work!
In-Reply-To: <200603232320.44461.jkeating@redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143127888.2853.96.camel@linux>
	<604aa7910603231158n4f544409uf2cd289f40039449@mail.gmail.com>
	<200603232320.44461.jkeating@redhat.com>
Message-ID: <604aa7910603241044s6f5397ecue2a98f0ccf072e04@mail.gmail.com>

On 3/24/06, Jesse Keating <jkeating at redhat.com> wrote:
> I don't think the OP wanted new isos, rather instead provide updated builds of
> the anaconda package.  Not entirely unreasonable.

Should I take this statement to mean that you are volunteering to
spend the time tracking bugs and integrating the requested backports
into FC-5 updates?  I'll agree with you that its reasonable as soon as
someone raises their hand and admits to having enough time, experience
and access to the Core cvs system to do it.

-jef



From sundaram at fedoraproject.org  Fri Mar 24 18:48:56 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 25 Mar 2006 00:18:56 +0530
Subject: Anaconda: good work!
In-Reply-To: <1143185371.2853.118.camel@linux>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<20060323164702.GG3137@exeter.boston.redhat.com>
	<1143185371.2853.118.camel@linux>
Message-ID: <1143226137.3802.157.camel@sundaram.pnq.redhat.com>


> PS: Is the listserver really overloaded now? Both today and yesterday
> my mail delivery from fedora lists seems to be 6-12 hours delayed.
> I can see my own mails show up in the archives instantaneously and
> nobody seems to answer my mails before they get through either so..
> 
> 
> -HK

Known issue. I have a report filed on this internally to track this.


Rahul



From florin at andrei.myip.org  Fri Mar 24 19:00:21 2006
From: florin at andrei.myip.org (Florin Andrei)
Date: Fri, 24 Mar 2006 11:00:21 -0800
Subject: firstboot system maintenance task
Message-ID: <1143226822.2415.23.camel@dhcp-198.home.local>

After installing Fedora on any system, when the system boots up for the
first time I always log in as root immediately, in a text-mode console
(not via X), then run this sequence:

killall anacron
yum -y update
yum clean packages
anacron -nd
sync
reboot

I just type everything in then I walk away and let the system do it
since there should be no user interaction. Perhaps a better idea would
be to run everything inside a typescript session, just to catch all the
output for further analysis - hmmm, that actually does sound good, I
should add that to my first boot ritual from now on. :-)

Anyway, even before Fedora, I was pretty much doing the same thing, but
translated in Red Hat Linux terms.
Even before that, 10 years ago when I was using Slackware Linux :-) I
was doing things that were functionally equivalent, albeit a lot more
manual and hugely more cumbersome.

I just think it's a good idea and it's the best and shortest way to
build a clean and up to date system out of a fresh install.

So I was thinking - perhaps it, or something equivalent - could be added
as the last step to firstboot. Perhaps as a popup, informing the user
that the system will apply all available updates, perform some
maintenance tasks then reboot, and asking the user to either accept or
reject it.

The only snag that I can think of is Internet access - firstboot should
test HTTP access and perhaps ask the user to configure proxy settings
first (and skip this whole thing if there seems to be no way to enable
Internet access at this point).
Also, perhaps anacron should not even be started the very first time the
system comes up after install, but instead wait for this maintenance
task to be either accepted by the user (then the system will reboot and
anacron will launch normally next time) or rejected (then perhaps
anacron should be launched by firstboot).

This might also help a lot of newbies since I noticed that some people
running Linux for the first time are not aware of the necessity to apply
updates and patches and do not even know how to do it.
For the advanced users it would be just a convenient way to bring a
fresh install up to date before actually pounding on it with real
workload.

Thoughts?

-- 
Florin Andrei

http://florin.myip.org/



From fedora-devel-list at thebc.ch  Fri Mar 24 19:07:27 2006
From: fedora-devel-list at thebc.ch (Steven F. Christ)
Date: Fri, 24 Mar 2006 20:07:27 +0100
Subject: xorg-x11-drv-i810.i386 1.4.1.3-4.cvs20060322
Message-ID: <20060324200727.5f8c4f92@artchaos>

The X Server won't start anymore!



From jkeating at j2solutions.net  Fri Mar 24 19:56:35 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 24 Mar 2006 11:56:35 -0800
Subject: Anaconda: good work!
In-Reply-To: <1143192699.28002.6.camel@localhost>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<1143127335.3802.79.camel@sundaram.pnq.redhat.com>
	<1143192699.28002.6.camel@localhost>
Message-ID: <1143230196.23491.110.camel@yoda.loki.me>

On Fri, 2006-03-24 at 03:31 -0600, Callum Lerwick wrote:
> Would a respin of at least the rescue ISO be (theoretically) possible?
> 
> Personally I'm thinking of the rather annoying X11 bug that was in the
> FC4 installer *and* the installed version that caused graphical install
> to be unusable, and X to be unusable until you installed the updated
> X11. Apparently that wasn't even bad enough for a respin.

That still needs an updated stage2, and an updated payload, so it is
basically a full respin.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/2e523f1b/attachment.sig>

From davej at redhat.com  Fri Mar 24 20:26:27 2006
From: davej at redhat.com (Dave Jones)
Date: Fri, 24 Mar 2006 15:26:27 -0500
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <ufafyl92bci.fsf@epithumia.math.uh.edu>
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
Message-ID: <20060324202627.GD2725@redhat.com>

On Thu, Mar 23, 2006 at 01:46:21PM -0600, Jason L Tibbitts III wrote:
 > I have a couple of VT310-DP boards (together in a little 1U case,
 > nice) and found that FC-5 won't do SMP on them.  (The i686 kernels
 > won't run on this chip.)

really ? I was under the impression that all the SMP capable C3's
were Nehemiah cores, which are 686 capable.

 > What's the cleanest way to add an i586-smp (or better yet, MVIAC3_2-smp)
 > build target to the existing kernel SRPM?  Currently I'm working from
 > Fedora CVS (FC-5 branch) which looks like it has reorganized the
 > config generation a bit.

cp configs/config-i586 configs/config-i586-smp
echo CONFIG_SMP=y >> configs/config-i586-smp
edit Makefile.config and add a stanza for your new i586-smp (mostly cut-n-pasting the 586 one
 but change the filename)
add the 586-smp config to the kernel-2.6.spec sources: list

that should be it, unless I've forgotten something.

		Dave

-- 
http://www.codemonkey.org.uk



From patmans at us.ibm.com  Fri Mar 24 20:36:20 2006
From: patmans at us.ibm.com (Patrick Mansfield)
Date: Fri, 24 Mar 2006 12:36:20 -0800
Subject: Today' rawhide update
In-Reply-To: <1143178603.5939.2.camel@localhost.localdomain>
References: <1143135640.767.2.camel@price.stavtrup-st.dk>
	<1143178603.5939.2.camel@localhost.localdomain>
Message-ID: <20060324203620.GA17657@us.ibm.com>

On Fri, Mar 24, 2006 at 12:36:42AM -0500, Dennis Gregorovic wrote:

> The normal cron job was busted last night.  After some investigation, I
> fixed the problem and then ran it by hand.  So, the packages and
> metadata on d.f.r.c should have the latest stuff.  However, I didn't see
> the rawhide-report email come through.  Maybe it's stuck in mailman?
> 
> Also, last night's rawhide issue caused install images to not get
> created, but they *should* be there tomorrow.  (Well, about two hours
> from now at this point)

Hi ... I see i386 images, but no ppc. Any status on those?

ncftp ...linux/core/development > pwd
ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/
ncftp ...linux/core/development > ls -l i386/images
-rw-r--r--    1 ftp      ftp      7022592   Mar 24 07:20   boot.iso
-rw-r--r--    1 ftp      ftp      8388608   Mar 24 07:20   diskboot.img
drwxrwsr-x    2 ftp      ftp         4096   Mar 24 07:24   pxeboot
-rw-r--r--    1 ftp      ftp          655   Mar 24 07:20   README
ncftp ...linux/core/development > ls -l ppc/images
[nothing]

Thanks ...

-- Patrick Mansfield



From dimi at lattica.com  Fri Mar 24 21:01:40 2006
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 24 Mar 2006 16:01:40 -0500
Subject: FC5: first impressions
Message-ID: <1a2301c64f86$283ce810$b6491b31@td612671>

Now that I past the installation of FC5, I can share some of
my impressions. BTW, I've been running Red Hat since 4.0, so
I'm a long time user of everything Red Hat.

I'd like to start by saying that this is a nice step forward
from FC4. There's a lot to be happy about: new versions, nicer
eye-candy, much faster in places. Good job!

I'd like to stress the "faster" part. This is a very important
criteria for a good desktop experience, and I'm really glad
we finally see some much needed improvements. It took _seconds_
in FC4 to start a simple app like gedit, now it's around a second.
Also, Firefox really shines, and for the first time it's actually
a better browser than IE for reading LKML [0].

I can go on and on about the number of improvements, but that
would be boring, so I'll start with the complaints :). BTW, I
run GNOME, and try to keep things as standard as possible.

So here are my complaints, in order of importance:

0. Missing terminal on desktop menu... just kidding! :)
   You guys were right, I can live without it. Mea culpa.

[seriously now]

1. Metacity's new window in the background
   I can not stress how big of a problem this is for me.
   I have used it since it was introduced, in the hope that
   I'll get used to it. I didn't. Not only it does the wrong
   thing for me in 90% of the cases, it also forces me to
   use the mouse a lot more, which is painful for me.
   A few google searches and browsing through GConf did not
   reveal a way of disabling it.

2. Evolution can't print
   Nowadays I get quite a few invoices via email, and not being
   able to print them is a big problem. Evo will just print the
   headers, but not the content. Even the Print Preview shows
   just the headers with an empty content. What gives?!?
   BTW, same behavior was present in FC4, I was hoping FC5 will
   fix it.

3. Gedit's tab
   Not only I find these tabs simply the wrong interface, but
   unconditionally having one even if I have only on file
   open is irritating me to the point that I avoid that app
   even when I need it. It's ugly, it takes vertical space, etc.
   Again, I found no way of disabling this silly behavior.

These are my top 3 problems. There are others, but they pale in
comparison. If I missed a simple way of fixing them, I'd appreciate
any pointers.

Thanks for an otherwise fantastic distro guys! All the pain, blood, 
and tears that you guys put into it is very much appreciated.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.

[0] Go to the LKML archive, say here
    http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/author.html
    scroll to the middle of the list, click on a message, and then
    click the Back button to go back to the list. 
    See how fast it renders the list again. 
    Until now, IE was way faster, but not anymore!



From lamont at gurulabs.com  Fri Mar 24 21:27:02 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Fri, 24 Mar 2006 14:27:02 -0700
Subject: Removing dep for httpd from php?
In-Reply-To: <20060324104735.148acdc0@soran.addix.net>
References: <4422F407.2040209@stefan-neufeind.de>
	<20060324104735.148acdc0@soran.addix.net>
Message-ID: <200603241427.08518.lamont@gurulabs.com>

On Friday 24 March 2006 02:47am, Ralf Ertzinger wrote:
> Hi.
>
> On Thu, 23 Mar 2006 20:16:23 +0100, Stefan Neufeind wrote:
> > When running a server without a webserver installed, you can perfectly
> > install/use php anyhow. So why is that dep needed? Is there a chance
> > to get it removed on the next release? :-)
>
> This is because mod_php is contained in the package as well, I think.

Correct.

I think that mod_php should be in it's own package and not in php.  A mod_php 
(or php-mod_php or php-mod or ...) package could still be built from the 
existing SPEC fine without changing the build process.  We just want the 
sub-package to depend on php & httpd.
--
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/72575426/attachment.sig>

From zaitcev at redhat.com  Fri Mar 24 21:28:36 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 24 Mar 2006 13:28:36 -0800
Subject: fyi: vlc
In-Reply-To: <dvve2e$2r9$1@sea.gmane.org>
References: <dvve2e$2r9$1@sea.gmane.org>
Message-ID: <20060324132836.65b28413.zaitcev@redhat.com>

On Thu, 23 Mar 2006 19:21:36 -0500, Neal Becker <ndbecker2 at gmail.com> wrote:

> I tried FC5 vlc from livna, but it just gave a bunch of errors when started. 
> Then I tried videolan-client from freshrpms.   Better, but gave an error
> when trying to open my dvd.

Oh, hmm... I knew that Livna was horked for a while, but you're right,
videolan-client does not work either:

[zaitcev at lembas ~]$ vlc dvd://
VLC media player 0.8.4a Janus
libdvdnav: Using dvdnav version 0.1.10 from http://dvd.sf.net
libdvdread: Using libdvdcss version 1.2.9 for DVD access
libdvdread: Can't stat
No such file or directory
libdvdnav: vm: faild to open/read the DVD
libdvdread: Can't stat
No such file or directory
[00000278] dvdread demuxer error: DVDRead cannot open source:
[00000277] main input error: no suitable access module for `dvd://'
[00000268] main playlist: nothing to play

The strace looks like this:

6263  open("/usr/lib/libdvdcss.so.2", O_RDONLY) = 10
6263  read(10, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\21\0\000"..., 512) = 512
6263  fstat64(10, {st_mode=S_IFREG|0755, st_size=31376, ...}) = 0
6263  mmap2(NULL, 36352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 10, 0) = 0xb0da1000
6263  mmap2(0xb0da8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 10, 0x6) = 0xb0da8000
6263  close(10)                         = 0
6263  munmap(0xb0dd6000, 78291)         = 0
6263  write(2, "libdvdread: Using libdvdcss vers"..., 57) = 57
6263  stat64("", 0xb15f5f6c)            = -1 ENOENT (No such file or directory)
6263  write(2, "libdvdread: Can\'t stat \n", 24) = 24 6263  write(2, "No such file or directory\n", 26) = 26
6263  write(1, "libdvdnav: vm: faild to open/rea"..., 42) = 42

> I grabbed the srpm from freshrpms, and (after d/l all the builddeps) it is
> rebuilt and working great.

Yeah, it seems like a rebuild time.

-- Pete



From katzj at redhat.com  Fri Mar 24 21:30:52 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 24 Mar 2006 16:30:52 -0500
Subject: Anaconda: good work!
In-Reply-To: <1cef3e950603240507v20f132f9od480d854698a1d20@mail.gmail.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<200603222132.00267.billcrawford1970@googlemail.com>
	<20060322214325.GE1115919@hiwaay.net>
	<200603232142.37600.billcrawford1970@googlemail.com>
	<20060323222153.GE747608@hiwaay.net>
	<1cef3e950603240507v20f132f9od480d854698a1d20@mail.gmail.com>
Message-ID: <1143235853.7616.0.camel@orodruin.boston.redhat.com>

On Fri, 2006-03-24 at 13:07 +0000, Joe Desbonnet wrote:
> BTW: is it a bug or feature that you can only do a HTTP install on
> port 80? (ie you are asked only for a host and path, but not a port).

I think you can do host:port and have it work

At least, that's the intent :)

Jeremy



From ofeeley at sbcglobal.net  Fri Mar 24 21:44:12 2006
From: ofeeley at sbcglobal.net (Oisin C. Feeley)
Date: Fri, 24 Mar 2006 13:44:12 -0800
Subject: strange X11 Problems with cisco vpn client under Fedora 4 or 5
In-Reply-To: <20060323102746.d7bff2ff.j.rink@freenet.de>
References: <20060323102746.d7bff2ff.j.rink@freenet.de>
Message-ID: <20060324214412.GA8673@tirnanog.dyndns.tv>

On Thu, Mar 23, 2006 at 10:27:46AM +0100, J?rn Rink wrote:
> I have problems with the cisco vpnclient 4.xxx under Fedora 4 or 5.

Are you referring to the vpnc client or to Cisco's own one?

If you're using Cisco's own one then you might like to try "yum install vpnc"?

Oisin Feeley



From katzj at redhat.com  Fri Mar 24 21:41:33 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 24 Mar 2006 16:41:33 -0500
Subject: Anaconda: good work!
In-Reply-To: <44240A9E.4000602@uklinux.net>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<20060323164702.GG3137@exeter.boston.redhat.com>
	<44240A9E.4000602@uklinux.net>
Message-ID: <1143236494.7616.3.camel@orodruin.boston.redhat.com>

On Fri, 2006-03-24 at 15:05 +0000, Jon Burgess wrote:
> Chris Lumens wrote:
> > We can't really do this easily.  Making a new anaconda means making new
> > first and second stage images, which means making new CD and DVD images,
> > which means a huge headache for mirrors and for keeping track of all
> > these versions of images floating around.
> 
> Using Jigdo http://atterer.net/jigdo/ could help reduce the amount of 
> data needed to be stored by the mirrors for a re-spun CD/DVD ISOs. It 
> reduces the amount of data to be downloaded if the user already has the 
> original ISOs.

Do you realize how many bugs get filed a week due to people with bad CDs
even when they download the _exact_ bits and just have to burn them?
Even when mediacheck is prominently present and will tell them their
media is bad?

Now, let's multiple that by some factor due to the images having to be
constructed.  Personally, I'd rather not. :(

Jeremy



From lamont at gurulabs.com  Fri Mar 24 21:44:55 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Fri, 24 Mar 2006 14:44:55 -0700
Subject: Anaconda: good work!
In-Reply-To: <20060324144420.57d89213.j.rink@freenet.de>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<20060324144420.57d89213.j.rink@freenet.de>
Message-ID: <200603241444.56067.lamont@gurulabs.com>

On Friday 24 March 2006 06:44am, J?rn Rink wrote:
> Am Wed, 22 Mar 2006 10:12:09 -0500
>
> hat "Dimi Paun" <dimi at lattica.com> (Dimi Paun) folgendes geschrieben:
> > Hi Jeremy,
> >
> > Just wanted to share a few thoughts about anaconda,
> > while fresh in my mind (I've managed to install FC5
> > last night).
> >
> > First impression: anaconda really rocks! This is a
> > very solid, pleasant installer.
>
> Yes, but since Redhat mkkickstart i missed something which let
> me take SUSE for automatic installation in our firm.
>
> You have no choice to get some individual input into the installation.
>
> What i mean:
> we have to install nearly 500 computer automatically in the office of
> our customers (banks). Each computer has its own, predefined name, and
> we are using logical (virtuell, self generated) MAC Adresses for
> these PC's. So, tell me how to get the MAC Adress into the
> installation via menu? The customer has to input it. For the
> suse Installation we hav solved this with dialog tricks over the
> autoyast console text menu to get the input.
>
> And the network interface is configured AFTER the input.
>
> I have no idea how to implement this in an anaconda kickstart
> installation. Thats my wish, a point in the installation where i can,
> if i want, ask for individual settings which override the ks.cfg
> settings.
>
> When anyone has an idea for this, i am the first who changed the
> auto install from SuSE to fedora ;-)

Get the kickstart file from a web server and make the file that is being 
pointed to a perl or PHP (or ruby or whatever you prefer) script that 
generates the "proper" kickstart file content as output.

With that in place, you can get the MAC address from a look-up table in your 
app, based on the IP address of the client connecting.  Of course, I'm 
assuming that you have such a map if you are setting the MAC addresses on all 
those machines.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/1e1cc9d5/attachment.sig>

From ivazquez at ivazquez.net  Fri Mar 24 21:50:31 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Fri, 24 Mar 2006 16:50:31 -0500
Subject: PHP-5 seems to be screwed on FC-5
In-Reply-To: <4424182D.9040202@gmail.com>
References: <4424182D.9040202@gmail.com>
Message-ID: <1143237032.31404.0.camel@ignacio.lan>

On Fri, 2006-03-24 at 13:02 -0300, Casimiro de Almeida Barreto wrote:
> PHP Warning:  PHP Startup: ,L\x8c: Unable to initialize module\nModule 
> compiled with module API=20041030, debug=0, thread-safety=0\nPHP    
> compiled with module API=20050922, debug=0, thread-safety=0\nThese 
> options need to match\n in Unknown on line 0

Have you tried to diagnose which module it is?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/fce2913d/attachment.sig>

From sundaram at fedoraproject.org  Fri Mar 24 21:46:38 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 25 Mar 2006 03:16:38 +0530
Subject: PHP-5 seems to be screwed on FC-5
In-Reply-To: <4424182D.9040202@gmail.com>
References: <4424182D.9040202@gmail.com>
Message-ID: <1143236798.3802.210.camel@sundaram.pnq.redhat.com>

On Fri, 2006-03-24 at 13:02 -0300, Casimiro de Almeida Barreto wrote:
> Hello,
> 
> Yesterday I updated one of my servers to FC-5. The primary effect sensed 
> was that PHP-5 seems to be broken. Oh... yeah... it works up to a 
> certain point but, after that, it miserably fails.
> 
> For instance, I have a ridiculous program that count hits. It stopped 
> working. Not only a single f_ck_g error message or warning in the 
> logs...

What program is this? Maybe its not compatible with PHP5?. Did you check
for the presence of any AVC denied messages in /var/log/messages
or /var/log/audit from SELinux?


>  I have an schedule program that works with MySQL and now it is 
> simply unable to deal with ISO-8859-1 encoding... Oh... by the way... 
> also refuses to work properly in UTF-8 (not that suported by MySQL 
> itself) and other oddities... But as ALL UNIVERSE speaks English, why to 
> bother with those who don't...

Poor claim. All the universe does not speak English and yes we do have
to care about users who don't speak English. 

> 
> Besides, I fixed the problems with device drivers (USB and SOUND) on 
> FC5.

Can you be more specific? What device driver and sound issues were
these? Has any bug reports been filed about them?


>  Just rebuilding all the kernel (about a 2 hour work)... after all, 
> ASUS being so minor motherboard manufacturer, who in the Universe would 
> give a heck if Linux don't work in boxes that use ASUS, Pentium 4 and 
> SIS chipsets.
> 
> Besides, RAID1 is still crashing. The same with RAID0 and linear. With 
> SATA HDDs. 

Device model and chipset numbers? When does it crash? Any error
messages?

Rahul



From jspaleta at gmail.com  Fri Mar 24 21:46:36 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 24 Mar 2006 16:46:36 -0500
Subject: Anaconda: good work!
In-Reply-To: <1cef3e950603240507v20f132f9od480d854698a1d20@mail.gmail.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<200603222132.00267.billcrawford1970@googlemail.com>
	<20060322214325.GE1115919@hiwaay.net>
	<200603232142.37600.billcrawford1970@googlemail.com>
	<20060323222153.GE747608@hiwaay.net>
	<1cef3e950603240507v20f132f9od480d854698a1d20@mail.gmail.com>
Message-ID: <604aa7910603241346s4445c9e1x1f4e24fd307827a8@mail.gmail.com>

On 3/24/06, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
> BTW: is it a bug or feature that you can only do a HTTP install on
> port 80? (ie you are asked only for a host and path, but not a port).
> joe.

you can't hang a :port on the end of the servername?

-jef



From notting at redhat.com  Fri Mar 24 21:47:13 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 24 Mar 2006 16:47:13 -0500
Subject: Anaconda: good work!
In-Reply-To: <44240A9E.4000602@uklinux.net>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<20060323164702.GG3137@exeter.boston.redhat.com>
	<44240A9E.4000602@uklinux.net>
Message-ID: <20060324214712.GD8721@devserv.devel.redhat.com>

Jon Burgess (jburgess at uklinux.net) said: 
> Chris Lumens wrote:
> >We can't really do this easily.  Making a new anaconda means making new
> >first and second stage images, which means making new CD and DVD images,
> >which means a huge headache for mirrors and for keeping track of all
> >these versions of images floating around.
> 
> Using Jigdo http://atterer.net/jigdo/ could help reduce the amount of 
> data needed to be stored by the mirrors for a re-spun CD/DVD ISOs. It 
> reduces the amount of data to be downloaded if the user already has the 
> original ISOs.
> 
> It also allows enables other things like making a set of CD ISOs from 
> the RPMS on a DVD ISO (or the reverse).
> 
> I see it has just been added to extras-devel if anyone wants to try it out.

If someone wants to post example jigdo stuff we could put on the
mirror master, that would be great. Not sure it's practical for rawhide,
though, as we really don't even want to go to the effort of spinning
isos for that.

Bill



From notting at redhat.com  Fri Mar 24 21:53:21 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 24 Mar 2006 16:53:21 -0500
Subject: Anaconda: good work!
In-Reply-To: <44240A9E.4000602@uklinux.net>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143045925.24028.12.camel@orodruin.boston.redhat.com>
	<1143102722.2853.83.camel@linux>
	<20060323164702.GG3137@exeter.boston.redhat.com>
	<44240A9E.4000602@uklinux.net>
Message-ID: <20060324215321.GE8721@devserv.devel.redhat.com>

Jon Burgess (jburgess at uklinux.net) said: 
> Chris Lumens wrote:
> >We can't really do this easily.  Making a new anaconda means making new
> >first and second stage images, which means making new CD and DVD images,
> >which means a huge headache for mirrors and for keeping track of all
> >these versions of images floating around.

Well, what sort-of-works now and could be done is to merge this
into rescuecd; ship a combined stage1+stage2 that can be pointed
at an installation tree, thereby separating the package repository
from the installer entirely. But it doesn't really work quite right
yet.

Bill



From jspaleta at gmail.com  Fri Mar 24 21:53:23 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 24 Mar 2006 16:53:23 -0500
Subject: Anaconda: good work!
In-Reply-To: <20060324164759.GA30366@devserv.devel.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<1143059367.5126.9.camel@MrTomLinux.workstation>
	<1143133354.23486.17.camel@orodruin.boston.redhat.com>
	<20060324164759.GA30366@devserv.devel.redhat.com>
Message-ID: <604aa7910603241353o6b8adb4dsa95f79716d553b55@mail.gmail.com>

On 3/24/06, Bill Nottingham <notting at redhat.com> wrote:
> And, of course, getting the content translated. (It does 'bloat'
> the stage2 image by some as well, especially if you have translated
> images.)

that's why i like the idea of annodex'd closed captions instead of
bitmap images with text

-jef



From notting at redhat.com  Fri Mar 24 22:08:02 2006
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 24 Mar 2006 17:08:02 -0500
Subject: Fedora core for the Itanium
In-Reply-To: <c15751d30603240959l1f3e1261sbc75f01dfb856abb@mail.gmail.com>
References: <c15751d30603240959l1f3e1261sbc75f01dfb856abb@mail.gmail.com>
Message-ID: <20060324220802.GG8721@devserv.devel.redhat.com>

Jason Connor (jason.connor at gmail.com) said: 
> Are there any plans for doing stable releases of fedora core for ia64?

No.

> I've seen the rawhide tree for the platform, but with the recent
> pledges from intel, hp, and others to put more money into the
> platform, I think it might be time to release fedora for end users on
> it.

There has not been sufficient community interest to warrant it; there
isn't even anything on the scale of CentOS for Alpha, or Aurora Linux.

Bill



From katzj at redhat.com  Fri Mar 24 22:17:06 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 24 Mar 2006 17:17:06 -0500
Subject: Fedora core for the Itanium
In-Reply-To: <c15751d30603240959l1f3e1261sbc75f01dfb856abb@mail.gmail.com>
References: <c15751d30603240959l1f3e1261sbc75f01dfb856abb@mail.gmail.com>
Message-ID: <1143238626.7616.24.camel@orodruin.boston.redhat.com>

On Fri, 2006-03-24 at 10:59 -0700, Jason Connor wrote:
> Are there any plans for doing stable releases of fedora core for ia64?

There are some interested people on fedora-ia64-list

> I've seen the rawhide tree for the platform, but with the recent
> pledges from intel, hp, and others to put more money into the
> platform, I think it might be time to release fedora for end users on
> it.

Realistically, for this to happen, there needs to be the following
a) A community of users working to get an initial unofficial release
ready and out (cf the original x86_64 and ppc releases in FC1 and FC3,
respectively)
b) See what sort of uptake there is.  There's going to have to be a
community to support the effort, especially as one requirement is going
to be active testing and helping with problems in Extras
c) Figure out a plan to get build support in Extras -- this involves
getting a box(es) that is suitable for the colo facility

Jeremy



From smooge at gmail.com  Fri Mar 24 22:24:05 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Fri, 24 Mar 2006 15:24:05 -0700
Subject: PHP-5 seems to be screwed on FC-5
In-Reply-To: <4424182D.9040202@gmail.com>
References: <4424182D.9040202@gmail.com>
Message-ID: <80d7e4090603241424x580d384if486129c3f0a8cc8@mail.gmail.com>

On 3/24/06, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> wrote:
> Hello,
>
> Yesterday I updated one of my servers to FC-5. The primary effect sensed
> was that PHP-5 seems to be broken. Oh... yeah... it works up to a
> certain point but, after that, it miserably fails.
>
> For instance, I have a ridiculous program that count hits. It stopped
> working. Not only a single f_ck_g error message or warning in the
> logs... I have an schedule program that works with MySQL and now it is
> simply unable to deal with ISO-8859-1 encoding... Oh... by the way...
> also refuses to work properly in UTF-8 (not that suported by MySQL
> itself) and other oddities... But as ALL UNIVERSE speaks English, why to
> bother with those who don't...
>

Dear Casmiro, please provide more information for this problem. I
realize you are tired and cranky because your system is broken.. but
some help please. Deep breath and try again.

1) What is the hardware of the affected system?
      CPU
      Motherboard
      Memory
      SATA disk drive controller
      Software raid/hardware raid
      USB controller
      Sound controller
      Network controller

2) What are the settings of the system
     LANG
     Swap space

3) Some changes seem to reorder the count order on some disk drives
controllers (but not all). I don't know the full info on this.. but it
seems to cause RAID-1 to not boot on some system because the sdb drive
gets grub and sda does not.

4) What PHP modules do you have loaded on the system?


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From sundaram at fedoraproject.org  Fri Mar 24 22:30:18 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 25 Mar 2006 04:00:18 +0530
Subject: FC5: first impressions
In-Reply-To: <1a2301c64f86$283ce810$b6491b31@td612671>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
Message-ID: <1143239418.3802.233.camel@sundaram.pnq.redhat.com>

On Fri, 2006-03-24 at 16:01 -0500, Dimi Paun wrote:
> Now that I past the installation of FC5, I can share some of
> my impressions. BTW, I've been running Red Hat since 4.0, so
> I'm a long time user of everything Red Hat.
> 
> I'd like to start by saying that this is a nice step forward
> from FC4. There's a lot to be happy about: new versions, nicer
> eye-candy, much faster in places. Good job!
> 
> I'd like to stress the "faster" part. This is a very important
> criteria for a good desktop experience, and I'm really glad
> we finally see some much needed improvements. It took _seconds_
> in FC4 to start a simple app like gedit, now it's around a second.
> Also, Firefox really shines, and for the first time it's actually
> a better browser than IE for reading LKML [0].
> 
> I can go on and on about the number of improvements, but that
> would be boring, so I'll start with the complaints :). BTW, I
> run GNOME, and try to keep things as standard as possible.
> 
> So here are my complaints, in order of importance:
> 
> 0. Missing terminal on desktop menu... just kidding! :)
>    You guys were right, I can live without it. Mea culpa.

Good to see the hundreds of mails on the thread we had earlier wasn't
entirely a waste. The release notes has information on bringing it back
if you need it btw (yum install nautilus-open-terminal).



> 
> [seriously now]
> 
> 1. Metacity's new window in the background
>    I can not stress how big of a problem this is for me.
>    I have used it since it was introduced, in the hope that
>    I'll get used to it. I didn't. Not only it does the wrong
>    thing for me in 90% of the cases, it also forces me to
>    use the mouse a lot more, which is painful for me.
>    A few google searches and browsing through GConf did not
>    reveal a way of disabling it.

We have a bug report open it. Upstream has tentatively agreed to make it
a option disabled by default


> 
> 2. Evolution can't print
>    Nowadays I get quite a few invoices via email, and not being
>    able to print them is a big problem. Evo will just print the
>    headers, but not the content. Even the Print Preview shows
>    just the headers with an empty content. What gives?!?
>    BTW, same behavior was present in FC4, I was hoping FC5 will
>    fix it.
> 

Do you have a bug report open on this?


> 3. Gedit's tab
>    Not only I find these tabs simply the wrong interface, but
>    unconditionally having one even if I have only on file
>    open is irritating me to the point that I avoid that app
>    even when I need it. It's ugly, it takes vertical space, etc.
>    Again, I found no way of disabling this silly behavior.


Might request a option to turn this off in bugzilla.gnome.org or post to
http://mail.gnome.org/archives/usability/index.html

> 
> These are my top 3 problems. There are others, but they pale in
> comparison. If I missed a simple way of fixing them, I'd appreciate
> any pointers.
> 
> Thanks for an otherwise fantastic distro guys! All the pain, blood, 
> and tears that you guys put into it is very much appreciated.
> 
> -- 
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
> 
> [0] Go to the LKML archive, say here
>     http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/author.html
>     scroll to the middle of the list, click on a message, and then
>     click the Back button to go back to the list. 
>     See how fast it renders the list again. 
>     Until now, IE was way faster, but not anymore!

You are talking about Firefox 1.5's fast back feature that stores a
rendered copy of the history in it's cache. It might gobble up some RAM
if you browse a large number of sites with huge images in it but it's
good otherwise. Thanks for the feedback. 


Rahul



From fedora at leemhuis.info  Fri Mar 24 22:34:05 2006
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 24 Mar 2006 23:34:05 +0100
Subject: fyi: vlc
In-Reply-To: <20060324132836.65b28413.zaitcev@redhat.com>
References: <dvve2e$2r9$1@sea.gmane.org>
	<20060324132836.65b28413.zaitcev@redhat.com>
Message-ID: <1143239645.2475.4.camel@localhost.localdomain>

Am Freitag, den 24.03.2006, 13:28 -0800 schrieb Pete Zaitcev:
> > I grabbed the srpm from freshrpms, and (after d/l all the builddeps)
> it is
> > rebuilt and working great.
> 
> Yeah, it seems like a rebuild time.

The rebuild already is done -- will probably be on the public servers in
round about half hour ;-)

Cu
thl
-- 
Thorsten Leemhuis <fedora at leemhuis.info>



From casimiro.barreto at gmail.com  Sat Mar 25 22:36:23 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Sat, 25 Mar 2006 19:36:23 -0300
Subject: PHP-5 seems to be screwed on FC-5
In-Reply-To: <80d7e4090603241424x580d384if486129c3f0a8cc8@mail.gmail.com>
References: <4424182D.9040202@gmail.com>
	<80d7e4090603241424x580d384if486129c3f0a8cc8@mail.gmail.com>
Message-ID: <395CDE33-D94D-4167-A3A0-DA6DD36428CA@gmail.com>


Em 24/03/2006, ?s 19:24, Stephen J. Smoogen escreveu:

> On 3/24/06, Casimiro de Almeida Barreto  
> <casimiro.barreto at gmail.com> wrote:
>> Hello,
>>
>> Yesterday I updated one of my servers to FC-5. The primary effect  
>> sensed
>> was that PHP-5 seems to be broken. Oh... yeah... it works up to a
>> certain point but, after that, it miserably fails.
>>
>> For instance, I have a ridiculous program that count hits. It stopped
>> working. Not only a single f_ck_g error message or warning in the
>> logs... I have an schedule program that works with MySQL and now  
>> it is
>> simply unable to deal with ISO-8859-1 encoding... Oh... by the way...
>> also refuses to work properly in UTF-8 (not that suported by MySQL
>> itself) and other oddities... But as ALL UNIVERSE speaks English,  
>> why to
>> bother with those who don't...
>>
>
> Dear Casmiro, please provide more information for this problem. I
> realize you are tired and cranky because your system is broken.. but
> some help please. Deep breath and try again.
>
> 1) What is the hardware of the affected system?
>       CPU
>       Motherboard
>       Memory
>       SATA disk drive controller
>       Software raid/hardware raid
>       USB controller
>       Sound controller
>       Network controller

Motherboard ASUS P4800-MX SE
CPU Pentium-4 at 2.8GHz
Memory: 960MBytes
Chipset: Sis661FX + Sis964
VGA:: SiS Real256E integrated
Audio: Realtek ALC655 6 Channel Audio Codec
Network: internal chipset + realtek chip
All the rest (USB, SATA, etc) controlled by SiS chipset


>
> 2) What are the settings of the system
>      LANG
pt_BR:UTF-8

Oh, yeah !!! MySQL does not like it that much... that' s make me goin  
from UTF-8 to ISO-8859-1 lots of times...

>      Swap space
2GBytes
>
> 3) Some changes seem to reorder the count order on some disk drives
> controllers (but not all). I don't know the full info on this.. but it
> seems to cause RAID-1 to not boot on some system because the sdb drive
> gets grub and sda does not.
>
Yeah... and some synchronization also... sometimes a "Degraded Array  
Event" is reported, but later it seems to be all right. BTW, Degraded  
Array Events are not related to "sudden death" of the system, for  
only /var/media and /var/www are on the /dev/md0
> 4) What PHP modules do you have loaded on the system?
>
All provided in Fedora repositories and some other from as asked by  
application. Latter I send you a complete listing...

>
> --
> Stephen J Smoogen.
> CSIRT/Linux System Administrator
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list




From dimi at lattica.com  Fri Mar 24 22:45:57 2006
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 24 Mar 2006 17:45:57 -0500
Subject: FC5: first impressions
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
Message-ID: <1b2301c64f94$b7a473c0$b6491b31@td612671>

From: "Rahul Sundaram" <sundaram at fedoraproject.org>
> > 1. Metacity's new window in the background
> 
> We have a bug report open it. Upstream has tentatively agreed to make it
> a option disabled by default

What means "disabled by default"? I hope we get the old behaviour
by default :)

<offtopic flamewar="false" excuse="friday">
Anyway, I think these are the kind of changes that irk people a 
lot as far as GNOME approach to usability goes: experimental 
behavior that is highly subjective, which is being forced onto 
the masses with no way of opting out.

I know, I know, this is not the list for this sort of complaints,
but these are things that people perceive as being "the disto",
and I think that Fedora should use its clout to fight these kind
of changes upstream. Especially when they originate from Red Hat :)
(BTW, I dread posting to the GNOME lists about this, I can almost
hear the your-are-not-our-target-customer-eveybody-is-happy-with-it
kind of response...)
</offtopic>

> > 2. Evolution can't print
> 
> Do you have a bug report open on this?

No, I'll file one when I get home.
 
> > 3. Gedit's tab
> 
> Might request a option to turn this off in bugzilla.gnome.org or post to
> http://mail.gnome.org/archives/usability/index.html
> 

For curiosity's sake, am I the only one that hates this?

> You are talking about Firefox 1.5's fast back feature that stores a
> rendered copy of the history in it's cache. It might gobble up some RAM
> if you browse a large number of sites with huge images in it but it's
> good otherwise. Thanks for the feedback. 

Yes, it works brilliantly! It's really really good for reading LKML :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From sundaram at fedoraproject.org  Fri Mar 24 23:21:39 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 25 Mar 2006 04:51:39 +0530
Subject: FC5: first impressions
In-Reply-To: <1b2301c64f94$b7a473c0$b6491b31@td612671>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
Message-ID: <1143242499.3802.260.camel@sundaram.pnq.redhat.com>

On Fri, 2006-03-24 at 17:45 -0500, Dimi Paun wrote:
> From: "Rahul Sundaram" <sundaram at fedoraproject.org>
> > > 1. Metacity's new window in the background
> > 
> > We have a bug report open it. Upstream has tentatively agreed to make it
> > a option disabled by default
> 
> What means "disabled by default"? I hope we get the old behaviour
> by default :)

Right. Thats what I meant. The RH bugzilla on this issue is
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186308


> 
> <offtopic flamewar="false" excuse="friday">
> Anyway, I think these are the kind of changes that irk people a 
> lot as far as GNOME approach to usability goes: experimental 
> behavior that is highly subjective, which is being forced onto 
> the masses with no way of opting out.

There was a fairly detailed analysis here
http://bugzilla.gnome.org/show_bug.cgi?id=326159 which even called the
behavior experimental. Might have been good to have a option till they
get it right atleast.


> 
> I know, I know, this is not the list for this sort of complaints,
> but these are things that people perceive as being "the disto",
> and I think that Fedora should use its clout to fight these kind
> of changes upstream. Especially when they originate from Red Hat :)
> (BTW, I dread posting to the GNOME lists about this, I can almost
> hear the your-are-not-our-target-customer-eveybody-is-happy-with-it
> kind of response...)
> </offtopic>

Can't say I love this option but it works for me. There are people who
do actually prefer the new option like LWN's editor Jonathan Corbet (
https://www.redhat.com/archives/fedora-test-list/2006-
February/msg00086.html) for example. Not a surprise since the original
motivation for this new behavior seems to a article on that website. I
can't find it now. 


Rahul





From Lam at Lam.pl  Fri Mar 24 23:50:50 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Sat, 25 Mar 2006 00:50:50 +0100
Subject: FC5: first impressions
In-Reply-To: <1143242499.3802.260.camel@sundaram.pnq.redhat.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<1143242499.3802.260.camel@sundaram.pnq.redhat.com>
Message-ID: <1143244250.2660.8.camel@pensja.lam.pl>

Dnia 25-03-2006, sob o godzinie 04:51 +0530, Rahul Sundaram napisa?(a):
> Right. Thats what I meant. The RH bugzilla on this issue is
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186308

which is a duplicate of
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178389

Hasn't anyone noticed it happens with gnome-terminal, which isn't worth
using anyhow? :) My multi-gnome-terminal works just as I want it to work
(programs started from it get focus). I use liferea with popping up
notifications, sometimes every minute or two, and I would go nuts if I'd
have to regain focus while typing in the terminal every single time. For
me it's perfect, just don't use stinking gnome-terminal 2.x and you'll
love it too! :)

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060325/fff4e742/attachment.sig>

From dimi at lattica.com  Sat Mar 25 00:10:10 2006
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 24 Mar 2006 19:10:10 -0500
Subject: FC5: first impressions
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<1143242499.3802.260.camel@sundaram.pnq.redhat.com>
Message-ID: <1b7901c64fa0$7bab8dc0$b6491b31@td612671>

From: "Rahul Sundaram" <sundaram at fedoraproject.org>
> > What means "disabled by default"? I hope we get the old behaviour
> > by default :)
> 
> Right. Thats what I meant. The RH bugzilla on this issue is
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186308

Great. This makes me very happy. Even using Eclipse is a pain
with this "feature". Every time you check stuff in, Eclipse
opens a dialog for the changelog. Well, this dialog doesn't
have the focus, requiring me to do yet another action to bring
in focus before I can type! Nothing to do with terminals BTW.
 
> Can't say I love this option but it works for me. There are people who
> do actually prefer the new option like LWN's editor Jonathan Corbet (
> https://www.redhat.com/archives/fedora-test-list/2006-
> February/msg00086.html) for example. Not a surprise since the original
> motivation for this new behavior seems to a article on that website. I
> can't find it now. 

Well, yeah. But his motivation is mainly that apps are slow to load.
The fix is to make them faster, not allow people to do something for
6 more secs until they start. It's just the wrong fix. And besides,
what can you do meaningfully in a few secs? This actually _extends_
the time significantly as it will take you a few seconds to manually
regain focus.

Anyway, thanks for the info. Help is on the way! :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From seg at haxxed.com  Sat Mar 25 00:57:19 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 24 Mar 2006 18:57:19 -0600
Subject: Bootsplash?
In-Reply-To: <1143059186.28627.6.camel@localhost.localdomain>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
Message-ID: <1143248242.28002.21.camel@localhost>

I would just like to say, after extensively using both suspend2 and
whatever the current stock suspend is, suspend2 is vastly superior. Its
much faster, it provides better feedback (userui), its more interactive.
You can cancel a suspend. (which would have been great with the suspend
loop bug I hit...) If you boot with a mismatching kernel, suspend2 will
warn you and ask you before it blows away your suspend image, giving you
a chance to restart with the right kernel.

Of course, Fedora shouldn't merge suspend2. Upstream should. And
apparently the answer to that is "Pavel says no". :P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/c4c104ca/attachment.sig>

From dimi at lattica.com  Sat Mar 25 00:58:56 2006
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 24 Mar 2006 19:58:56 -0500
Subject: FC5: first impressions
In-Reply-To: <1b2301c64f94$b7a473c0$b6491b31@td612671>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
Message-ID: <1143248336.2605.36.camel@dimi>

On Fri, 2006-03-24 at 17:45 -0500, Dimi Paun wrote:
> > > 2. Evolution can't print
> > 
> > Do you have a bug report open on this?
> 
> No, I'll file one when I get home.

As promised, here it is:
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186653

HTH.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From jcliburn at gmail.com  Sat Mar 25 01:31:41 2006
From: jcliburn at gmail.com (J. K. Cliburn)
Date: Fri, 24 Mar 2006 19:31:41 -0600
Subject: Crashes with via_velocity?
In-Reply-To: <20060324175603.GA1325128@hiwaay.net>
References: <20060324175603.GA1325128@hiwaay.net>
Message-ID: <3400f2f60603241731i67ceeca9naca366997815518a@mail.gmail.com>

On 3/24/06, Chris Adams <cmadams at hiwaay.net> wrote:
> This is an Abit AV8 motherboard with built-in Via gigabit ethernet
> (via_velocity).

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

I have the same motherboard.  Thanks for the heads-up.  I think I'll
try the install on a spare hdd and see if I run into the same problem.

Jay



From n0dalus+redhat at gmail.com  Sat Mar 25 02:05:12 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Sat, 25 Mar 2006 12:35:12 +1030
Subject: Intelligent Anaconda (was: Re: The Morning After)
In-Reply-To: <1143223232.3802.134.camel@sundaram.pnq.redhat.com>
References: <200603210156.40386.nman64@n-man.com>
	<4421B06A.8030809@fedoraproject.org> <1143103731.2853.92.camel@linux>
	<6280325c0603232142j3f99cfa5r3d1a20f2b0bf7a88@mail.gmail.com>
	<1143223232.3802.134.camel@sundaram.pnq.redhat.com>
Message-ID: <6280325c0603241805i5c671db5k4664eac6402c4797@mail.gmail.com>

On 3/25/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>
> Want to give this idea a try on your own? We could get you some cvs and
> web space setup to stage.
>

If I get time I will try make a quick prototype locally, then I can
move it over if I think it will work.

n0dalus.



From cmadams at hiwaay.net  Sat Mar 25 02:34:04 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 24 Mar 2006 20:34:04 -0600
Subject: Crashes with via_velocity?
In-Reply-To: <3400f2f60603241731i67ceeca9naca366997815518a@mail.gmail.com>
References: <20060324175603.GA1325128@hiwaay.net>
	<3400f2f60603241731i67ceeca9naca366997815518a@mail.gmail.com>
Message-ID: <20060325023404.GB1059455@hiwaay.net>

Once upon a time, J. K. Cliburn <jcliburn at gmail.com> said:
> On 3/24/06, Chris Adams <cmadams at hiwaay.net> wrote:
> > This is an Abit AV8 motherboard with built-in Via gigabit ethernet
> > (via_velocity).
> 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186584
> 
> I have the same motherboard.  Thanks for the heads-up.  I think I'll
> try the install on a spare hdd and see if I run into the same problem.

Let me know what you see.  I've had my system running memtest86+ for
almost 3 hours now (7 passes), and that hasn't found anything.

I'm wondering if it is related to the via_velocity or the e100 driver
(although I expect that use of the e100 driver is more widespread) or
even some oddity from using both.  It all works happy with FC3 though.

-- 
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 shiva at sewingwitch.com  Sat Mar 25 02:37:40 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Fri, 24 Mar 2006 18:37:40 -0800
Subject: GUI controls for instrumentation
Message-ID: <132A9F5E12B8828DA6ED8E85@[10.169.6.226]>

I'm tasked to write a front end for an instrumentation application for 
"that other operating system" ;) and I'd like to use GUI controls that are 
cross-platform portable for an eventual Linux port. What would the list 
recommend? I essentially need something that resembles the front panel of 
an oscilloscope, along with some dial indicators and knobs. I've also been 
thinking about making it web-accessible, so perhaps a Java-based solution 
would be suitable.



From jcliburn at gmail.com  Sat Mar 25 02:45:17 2006
From: jcliburn at gmail.com (J. K. Cliburn)
Date: Fri, 24 Mar 2006 20:45:17 -0600
Subject: Crashes with via_velocity?
In-Reply-To: <20060325023404.GB1059455@hiwaay.net>
References: <20060324175603.GA1325128@hiwaay.net>
	<3400f2f60603241731i67ceeca9naca366997815518a@mail.gmail.com>
	<20060325023404.GB1059455@hiwaay.net>
Message-ID: <3400f2f60603241845h56e331c7g6f180c78fcae329c@mail.gmail.com>

On 3/24/06, Chris Adams <cmadams at hiwaay.net> wrote:

> Let me know what you see.  I've had my system running memtest86+ for
> almost 3 hours now (7 passes), and that hasn't found anything.
>
> I'm wondering if it is related to the via_velocity or the e100 driver
> (although I expect that use of the e100 driver is more widespread) or
> even some oddity from using both.  It all works happy with FC3 though.

Seems to work fine.  I'm writing this message from the system right
now, using the via-velocity onboard nic.

system-config-network doesn't work, but that's another matter. 
(Perhaps I didn't install something critical; I did a pretty minimal
install on a spare hdd just to see if the nic would work.)



From shiva at sewingwitch.com  Sat Mar 25 02:39:10 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Fri, 24 Mar 2006 18:39:10 -0800
Subject: GUI controls for instrumentation
Message-ID: <3FF1210358CDF253AF08BCA1@[10.169.6.226]>

I'm tasked to write a front end for an instrumentation application for 
"that other operating system" ;) and I'd like to use GUI controls that are 
cross-platform portable for an eventual Linux port. What would the list 
recommend? I essentially need something that resembles the front panel of 
an oscilloscope, along with some dial indicators and knobs. I've also been 
thinking about making it web-accessible, so perhaps a Java-based solution 
would be suitable.



From dimi at lattica.com  Sat Mar 25 03:30:44 2006
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 24 Mar 2006 22:30:44 -0500
Subject: GUI controls for instrumentation
In-Reply-To: <3FF1210358CDF253AF08BCA1@[10.169.6.226]>
References: <3FF1210358CDF253AF08BCA1@[10.169.6.226]>
Message-ID: <1143257444.2605.39.camel@dimi>

On Fri, 2006-03-24 at 18:39 -0800, Kenneth Porter wrote:
> I've also been thinking about making it web-accessible, so perhaps a
> Java-based solution would be suitable. 

Native L&F:
  * Java SWT
  * wxWindows

Non-native:
  * Java Swing

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From lamont at gurulabs.com  Sat Mar 25 03:33:00 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Fri, 24 Mar 2006 20:33:00 -0700
Subject: GUI controls for instrumentation
In-Reply-To: <132A9F5E12B8828DA6ED8E85@[10.169.6.226]>
References: <132A9F5E12B8828DA6ED8E85@[10.169.6.226]>
Message-ID: <200603242033.03945.lamont@gurulabs.com>

On Friday 24 March 2006 07:37pm, Kenneth Porter wrote:
> I'm tasked to write a front end for an instrumentation application for
> "that other operating system" ;) and I'd like to use GUI controls that are
> cross-platform portable for an eventual Linux port. What would the list
> recommend? I essentially need something that resembles the front panel of
> an oscilloscope, along with some dial indicators and knobs. I've also been
> thinking about making it web-accessible, so perhaps a Java-based solution
> would be suitable.

Qt.

Trust me, I've written enough code in various languages and using various 
frameworks and toolkits to know that when you want stable, simple, reliable 
cross-platform code, Qt is excellent.

But, on this list in particular, I know there will be many who will think me 
an idiot for making that recommendation.  I'm not saying that Qt is the 
end-all, be-all of code.

I know that several people will want to point out how C++ is a "bad" language.  
Some will try to tell you how Qt's licensing is "not free".  Others will tell 
you that performance will be horrible if you go with Qt.

Well, I will let them have their opinions.

In the end, you have to make your choice.  So I recommend that to take an 
*objective* look at all the options suggested.  Don't let the fact that this 
solution or that is in a language you are less familiar with (or do not know) 
sway you, either.  Sure, it's a normal metric to include, but it should never 
be an absolute blocker, IMHO.

Qt is free and you can get a commercial license, as well.

C++ with Qt is a very easy to read, write and use language.  The flexibility 
and simplicity of your code will amaze you.

C++ can outperm C for the same task.  Mind you, I'm not saying that it will 
without work, but it has been shown to do so in many instances.

Qt performance is excellent.  In fact, it's very hard to beat.

Qt is small.  Including the libraries for Windows deployments is very easy.

Let the flames begin. :)

P.S.  Please, don't flame on this list.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060324/87dbf867/attachment.sig>

From jcliburn at gmail.com  Sat Mar 25 03:46:33 2006
From: jcliburn at gmail.com (J. K. Cliburn)
Date: Fri, 24 Mar 2006 21:46:33 -0600
Subject: Crashes with via_velocity?
In-Reply-To: <3400f2f60603241845h56e331c7g6f180c78fcae329c@mail.gmail.com>
References: <20060324175603.GA1325128@hiwaay.net>
	<3400f2f60603241731i67ceeca9naca366997815518a@mail.gmail.com>
	<20060325023404.GB1059455@hiwaay.net>
	<3400f2f60603241845h56e331c7g6f180c78fcae329c@mail.gmail.com>
Message-ID: <3400f2f60603241946g4db8baa5o286661b70435648e@mail.gmail.com>

On 3/24/06, J. K. Cliburn <jcliburn at gmail.com> wrote:
> Seems to work fine.  I'm writing this message from the system right
> now, using the via-velocity onboard nic.
>
> system-config-network doesn't work, but that's another matter.
> (Perhaps I didn't install something critical; I did a pretty minimal
> install on a spare hdd just to see if the nic would work.)

Well, there's something else way out of whack.  Firstboot didn't run
on, well, first boot, and it won't run on subsequent reboots. 
Attempting to run system-config-network produces

[root at osprey ~]# system-config-network
/usr/share/system-config-network/netconfpkg/NC_functions.py:30:
DeprecationWarning: rhpl.log is deprecated and will be removed; use
python's logging instead
  import rhpl.log
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/sbin/system-config-network-gui", line 67, in <lambda>
    PROGNAME, PRG_VERSION)
  File "/usr/lib64/python2.4/site-packages/rhpl/exception.py", line
337, in handleException
    import gtk
ImportError: No module named gtk

Original exception was:
Traceback (most recent call last):
  File "/usr/sbin/system-config-network-gui", line 70, in ?
    import gtk
ImportError: No module named gtk

I believe the gtk module problem explains why firstboot won't run.

This thread probably belongs on fedora-list, so I'll bow out.  Chris,
the nic works.  Hit me off list if you have specific questions.

Cheers,
Jay



From jdesbonnet at gmail.com  Sat Mar 25 03:59:40 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sat, 25 Mar 2006 03:59:40 +0000
Subject: GUI controls for instrumentation
In-Reply-To: <200603242033.03945.lamont@gurulabs.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
Message-ID: <1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>

For full portability you have many options. Personally I would go the
Java route. With excellent free IDEs like Eclipse you can get very
productive in that environment.

But there are several approaches:

1. Use applets which communicate via socket to server side (could be
in Java or other language)
2. Use stand alone application (in SWT or Swing or ...)
3. Use web based GUI using 'AJAX' like techniques. See
http://developer.yahoo.com/yui/index.html for some examples of what is
possible. This approach will probably not work for fast moving  data
eg an oscillascope display.
4. Use SVG: I've seen some excellent demos of SVG in action:
see http://www.adobe.com/svg/demos/
5. Use Flash (there are some dynamic flash generation frameworks, but
I know nothing about them).
6. Run the application on the server and use a light weight VNC client.



From jdesbonnet at gmail.com  Sat Mar 25 04:09:44 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sat, 25 Mar 2006 04:09:44 +0000
Subject: Support for 3Com 3CRWE737A dissapeared
Message-ID: <1cef3e950603242009y27f400ect12acf5a183d75be3@mail.gmail.com>

My 3Com 3CRWE737A Airconnect Wireless LAN PC Card (an old card, but
worked fine with every Redhat/Fedora release to date) is not
recognized by FC5 (on a Thinkpad T41p). It has worked with FC4,3,2,1
and Redhat Linux releases. I believe this card is handled by the
orinoco_cs module. I'd appreciate a pointer to some doc on how this
can be fixed: I assume this is a configuration issue rather than
support for the card being dropped from the kernel (?)

On plugging the card I get two lines in /var/log/messages:
Mar 25 04:06:12 localhost kernel: pccard: PCMCIA card inserted into slot 0
Mar 25 04:06:12 localhost kernel: pcmcia: registering new device pcmcia0.0

On unplug:
Mar 25 04:06:41 localhost kernel: pccard: card ejected from slot 0

Should I file this in bugzilla? Thanks,
Joe.



From dgregor at redhat.com  Sat Mar 25 04:17:00 2006
From: dgregor at redhat.com (Dennis Gregorovic)
Date: Fri, 24 Mar 2006 23:17:00 -0500
Subject: Today' rawhide update
In-Reply-To: <20060324203620.GA17657@us.ibm.com>
References: <1143135640.767.2.camel@price.stavtrup-st.dk>
	<1143178603.5939.2.camel@localhost.localdomain>
	<20060324203620.GA17657@us.ibm.com>
Message-ID: <1143260220.5939.123.camel@localhost.localdomain>

On Fri, 2006-03-24 at 12:36 -0800, Patrick Mansfield wrote:
> On Fri, Mar 24, 2006 at 12:36:42AM -0500, Dennis Gregorovic wrote:
> 
> > The normal cron job was busted last night.  After some investigation, I
> > fixed the problem and then ran it by hand.  So, the packages and
> > metadata on d.f.r.c should have the latest stuff.  However, I didn't see
> > the rawhide-report email come through.  Maybe it's stuck in mailman?
> > 
> > Also, last night's rawhide issue caused install images to not get
> > created, but they *should* be there tomorrow.  (Well, about two hours
> > from now at this point)
> 
> Hi ... I see i386 images, but no ppc. Any status on those?

It appears to still be busted.  I'll ping some folks and try to get an
update.

-- Dennis



From david at lovesunix.net  Sat Mar 25 06:26:08 2006
From: david at lovesunix.net (David Nielsen)
Date: Sat, 25 Mar 2006 07:26:08 +0100
Subject: Bootsplash?
In-Reply-To: <1143211193.3802.120.camel@sundaram.pnq.redhat.com>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143211193.3802.120.camel@sundaram.pnq.redhat.com>
Message-ID: <1143267968.2247.3.camel@price.stavtrup-st.dk>

fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
> On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
> > On Wed, 22 Mar 2006 20:26:25 +0000
> > Richard Hughes <hughsient at gmail.com> wrote:
> > > Even displaying a static bitmap (a-la-windows 98) would be better than
> > > the black we have now. Not sure if that makes it simpler.
> > 
> > I did some work on splashy a while back because I don't like rhgb and it is
> > way faster. I wanted to submit it to extras but never found the time to
> > actually submit it... if this is actually something people want and would like
> > to have I am more then willing to wipe my spec into shape :)
> 
> Might be a good alternative path to try out.

If you are looking at alternatives, the tool set Gentoo uses works
really well and has a really nice featureset - we might be able to adapt
that to our needs.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060325/abc97d32/attachment.sig>

From buildsys at redhat.com  Sat Mar 25 08:08:21 2006
From: buildsys at redhat.com (Build System)
Date: Sat, 25 Mar 2006 03:08:21 -0500
Subject: rawhide report: 20060325 changes
Message-ID: <200603250808.k2P88LkJ004679@porkchop.devel.redhat.com>

 

 
Updated Packages:

audiofile-1:0.2.6-3
-------------------
* Fri Mar 24 2006 Matthias Clasen <mclasen at redhat.com> - 1:0.2.6-3
- Reduce memory consumption by making data tables const

coreutils-5.94-2
----------------
* Fri Mar 24 2006 Tim Waugh <twaugh at redhat.com> 5.94-2
- 5.94.

cups-1:1.2-0.1.b2.6
-------------------
* Fri Mar 24 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.1.b2.6
- Add KDE compatibility symbols _ipp_add_attr/_ipp_free_attr to ipp.h, with
  a comment saying why they shouldn't be used.

* Fri Mar 24 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.1.b2.5
- Fix KDE compatibility symbols _ipp_add_attr/_ipp_free_attr.

* Fri Mar 24 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.1.b2.4
- Update to svn snapshot.

db4-4.3.29-4
------------
* Fri Mar 24 2006 Jindrich Novy <jnovy at redhat.com> 4.3.29-4
- drop useless java, lfs patches

epiphany-2.14.0-1
-----------------
* Sun Mar 12 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-1
- Update to 2.14.0

foomatic-3.0.2-34
-----------------
* Fri Mar 24 2006 Tim Waugh <twaugh at redhat.com> 3.0.2-34
- Always use /usr/lib/cups/{backend,filter}.

gedit-1:2.14.1-1
----------------
* Thu Mar 16 2006 Matthias Clasen <mclasen at redhat.com> 2.14.1-1
- Update to 2.14.1

gthumb-2.7.5.1-2
----------------
* Fri Mar 24 2006 Matthias Clasen <mclasen at redhat.com> - 2.7.5.1-2
- Update to 2.7.5.1

hplip-0.9.9-7
-------------
* Fri Mar 24 2006 Tim Waugh <twaugh at redhat.com> 0.9.9-7
- Include hpfax.
- Build requires libusb-devel.

kernel-2.6.16-1.2088_FC6
------------------------
* Fri Mar 24 2006 David Woodhouse <dwmw2 at redhat.com>
- Fix lockup when someone takes the bcm43xx device down while it's
  scanning (#180953)

* Thu Mar 23 2006 Juan Quintela <quintela at redhat.com>
- disable sky2 (as it is broken upstream)

* Thu Mar 23 2006 Juan Quintela <quintela at redhat.com>
- fix xen to compile with 2.6.16-git6.

libsepol-1.12.2-1
-----------------
* Fri Mar 24 2006 Dan Walsh <dwalsh at redhat.com> 1.12.2-1
- Upgrade to latest from NSA
	* Fixed avrule_block_write num_decls endian bug.

* Fri Mar 17 2006 Dan Walsh <dwalsh at redhat.com> 1.12.1-1
- Upgrade to latest from NSA
	* Fixed sepol_module_package_write buffer overflow bug.

* Fri Mar 10 2006 Dan Walsh <dwalsh at redhat.com> 1.12-2
- Upgrade to latest from NSA
	* Updated version for release.
	* Merged cond_evaluate_expr fix from Serge Hallyn (IBM).
	* Fixed bug in copy_avrule_list reported by Ivan Gyurdiev.
	* Merged sepol_policydb_mls_enabled interface and error handling
	  changes from Ivan Gyurdiev.

mtr-2:0.71-1
------------
* Fri Mar 24 2006 Miroslav Lichvar <mlichvar at redhat.com> - 2:0.71-1
- update to mtr-0.71

selinux-policy-2.2.26-1
-----------------------
* Wed Mar 22 2006 Dan Walsh <dwalsh at redhat.com> 2.2.25-3
- Fix policyhelp

smartmontools-1:5.33-7
----------------------
* Fri Mar 24 2006 Tomas Mraz <tmraz at redhat.com> - 1:5.33-7
- add missing quotes to /etc/sysconfig/smartmontools

squirrelmail-1.4.6-4.fc6
------------------------
* Fri Mar 24 2006 Warren Togami <wtogami at redhat.com> 1.4.6-4
- Fix outgoing Japanese mail to iso-2022-jp for now (#185767)

xinetd-2:2.3.14-2
-----------------
* Fri Mar 24 2006 Jay Fenlason <fenlason at redhat.com> 2:2.3.14-2
- Upgrade to new upstream version.  This obsoletes the -libwrap,
  -rpc, -banner, -bug140084 and -gcc4 patches.

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From fedora-devel-list at thebc.ch  Sat Mar 25 08:17:01 2006
From: fedora-devel-list at thebc.ch (Steven F. Christ)
Date: Sat, 25 Mar 2006 09:17:01 +0100
Subject: xorg-x11-drv-i810.i386 1.4.1.3-4.cvs20060322
In-Reply-To: <20060324200727.5f8c4f92@artchaos>
References: <20060324200727.5f8c4f92@artchaos>
Message-ID: <20060325091701.1dafe0d8@artchaos>

On Fri, 24 Mar 2006 20:07:27 +0100
"Steven F. Christ" <fedora-devel-list at thebc.ch> wrote:

> The X Server won't start anymore!
> 

just made a downgrade to "xorg-x11-drv-i810-1.4.1.3-3.1" and it's
working again.



From pemboa at gmail.com  Sat Mar 25 08:24:52 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sat, 25 Mar 2006 02:24:52 -0600
Subject: FC6: reducing size, moving packages out to fedora extras,
	security?
In-Reply-To: <20060320231209.GV7825@neu.nirvana>
References: <1142873997.3002.15.camel@aglarond.local>
	<20060320180853.2939eeac@soran.addix.net>
	<1142875085.3114.62.camel@laptopd505.fenrus.org>
	<441EEDB3.3030008@mindspring.com>
	<1142880311.3114.77.camel@laptopd505.fenrus.org>
	<1142887210.23128.18.camel@price.stavtrup-st.dk>
	<1142889303.3604.10.camel@T7.Linux> <441F2CBC.9060204@mharris.ca>
	<20060320231209.GV7825@neu.nirvana>
Message-ID: <16de708d0603250024u1380e8d1od1b2677f6cc105f7@mail.gmail.com>

I think the installation process (from Extras) could do with some polishing,
maybe enough to make users never have to use the command line for yum ( I
think I still would use the command line personally)

Presently, I do not consider FC to be too large, but apperently this may not
be the overall perception.

On 3/20/06, Axel Thimm <Axel.Thimm at atrpms.net> wrote:
>
> On Mon, Mar 20, 2006 at 05:29:16PM -0500, Mike A. Harris wrote:
> > IMHO, moving more and more stuff out of Core and into Extras is an
> > overall good idea, so long as the infrastructure is present in
> > _advance_ to make it easy to install the stuff that has moved to
> > Extras, both at OS install time and later, and without requiring
> > mandatory network access.  ie:  Fedora Extras on CD, kindof like
> > powertools was before, but with anaconda support for that.
>
> I think this is already the plan for FC6 and the timeframe looks right
> to get these parts done.
>
> But I hope one thing doesn't get lost in this transition: Mark Cox and
> his team have been checking RHEL and FC only until now (or has this
> changed?). So currently I know the software on the 5 CDs has been
> checked against CVEs rigorously and the security team has taken
> appropriate measures.
>
> I think this kind of security infrastructure is needed for moving
> these targeted 2/3 of Fedora Core to Fedora Extras. I'm afraid that
> simply assigning all of Fedora Extras to be checked as good as Fedora
> Core has been means more human resources which may not be
> available. So I see three scenarios:
>
> o packages moved to Fedora Extras are not being checked by Mark Cox
>   and friends anymore
>
> o Mark Cox get a lot more coworkers to be able to deal with all
>   packages in Fedora Core and Fedora Extras
>
> o Fedora Extras is split security-wise into 1st class and 2nd class
>   citizens.
>
> From a user's POV I'd wish the second scenario would happen.
> --
> Axel.Thimm at ATrpms.net
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>


--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060325/c0fa5002/attachment.htm>

From dgregor at redhat.com  Sat Mar 25 08:54:04 2006
From: dgregor at redhat.com (Dennis Gregorovic)
Date: Sat, 25 Mar 2006 03:54:04 -0500
Subject: Debuginfo broken in rawhide
In-Reply-To: <4423A42B.1000008@hhs.nl>
References: <4423A42B.1000008@hhs.nl>
Message-ID: <1143276845.17452.0.camel@localhost.localdomain>

On Fri, 2006-03-24 at 08:47 +0100, Hans de Goede wrote:
> Hi all,
> 
> The debug directory of the devel directory does not contain a repodata 
> dir, breaking install of -debuginfo packages through yum.
> 
> Regards,
> 
> Hans

The repodata dir should start appearing in tomorrow's (3/26/06) rawhide
tree.

-- Dennis



From j.rink at freenet.de  Sat Mar 25 10:02:07 2006
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Sat, 25 Mar 2006 11:02:07 +0100
Subject: Anaconda: good work!
In-Reply-To: <200603241444.56067.lamont@gurulabs.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<20060324144420.57d89213.j.rink@freenet.de>
	<200603241444.56067.lamont@gurulabs.com>
Message-ID: <20060325110207.8b1142d0.j.rink@freenet.de>

Am Fri, 24 Mar 2006 14:44:55 -0700
hat "Lamont R. Peterson" <lamont at gurulabs.com> (Lamont R. Peterson)
folgendes geschrieben:

> Get the kickstart file from a web server and make the file that is
> being pointed to a perl or PHP (or ruby or whatever you prefer)
> script that generates the "proper" kickstart file content as output.
> 
> With that in place, you can get the MAC address from a look-up table
> in your app, based on the IP address of the client connecting.  Of
> course, I'm assuming that you have such a map if you are setting the
> MAC addresses on all those machines.

Hi,
first of all, thanks for your answer.
I read about this method while googling around. The Problem is, that we
make DHCP and in the DHCP server, there we do not have a table of all
the MAC Adresses we are using or we want to use at this moment.

Because of this we send the hostname to the
dhcp server. So the client have to come up with the right hostname.

In the SuSE installation at this moment, all our customers has to input
2 things in the installation process, the hostname and the MAC Adress.

When we have the tables integrated in the DHCP Server, we can reduce
the input to one.

One solution can be the post or after installation scripts, but i have
to show the custumer an inputbox where he can input the hostname.



Another solution can be an anaconda hack, that while the installation
all is automatic exept the network configuration, but there is no
chance to input a mac adress.



From nicolas.mailhot at laposte.net  Sat Mar 25 10:11:37 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Mar 2006 11:11:37 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
Message-ID: <1143281498.4018.6.camel@rousalka.dyndns.org>

Le samedi 25 mars 2006 ? 03:59 +0000, Joe Desbonnet a ?crit :
> For full portability you have many options. Personally I would go the
> Java route. With excellent free IDEs like Eclipse you can get very
> productive in that environment.

Java server-side is a good idea.
On the client part it's a shockingly bad idea (and I include applets
there). Googling will find you boatloads of apps that choose java for
portability and still can not run on anything else than windows, because
just deploying the right JVM on all the systems you may target is a
major problem (and I'm not even counting the free stacks there).

If it where that easy, we'd have the latest eclipse version in Fedora
with all the major plugins instead of the current situation.

As a rule, if you can go thin-client just do it. Fat client in any
language will always be a deployment nightmare

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

From thuforuk at yahoo.co.uk  Sat Mar 25 10:47:32 2006
From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski)
Date: Sat, 25 Mar 2006 10:47:32 +0000
Subject: GUI controls for instrumentation
In-Reply-To: <1143281498.4018.6.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>	<200603242033.03945.lamont@gurulabs.com>	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
Message-ID: <44251FC4.3070207@yahoo.co.uk>

On 03/25/2006 10:11 AM, Nicolas Mailhot wrote:
> Le samedi 25 mars 2006 ?? 03:59 +0000, Joe Desbonnet a ??crit :
>> For full portability you have many options. Personally I would go the
>> Java route. With excellent free IDEs like Eclipse you can get very
>> productive in that environment.
> 
> Java server-side is a good idea.
> On the client part it's a shockingly bad idea (and I include applets
> there). Googling will find you boatloads of apps that choose java for
> portability and still can not run on anything else than windows, because
> just deploying the right JVM on all the systems you may target is a
> major problem (and I'm not even counting the free stacks there).

I tend to disagree -- get Java from Sun and you should have no problem 
unless your application is especially written to *not* run on anything 
else than some particular platform. And I'm speaking from experience: 
running lots of Java desktop applications on both Linux (at home) and 
Windows (at work). Few examples:

- Druid (druid.sf.net),
- JMeter,
- NetBeans (all versions, starting from 3.5 up to 5.0) with a few plugins,
- Azureus,
- IntelliJ IDEA,
- few NASA applications (e.g. Mars24j),
- Eclipse (since 2.1 up to all sorts of development releases 3.2) with 
*lots* of plugins (MyEclipseIDE, Subclipse, BIRT, Mylar, WebTools 
Platform, QuantumDB, GEF, VisualEditor, Jigloo, EMF...)
- RawView (http://www.through-the-lens.net)

and more... Successfully with no special treatment to make it work on 
either OS. And these are only some GUI applications I use/used. There's 
more non-GUI software too.


> If it where that easy, we'd have the latest eclipse version in Fedora
> with all the major plugins instead of the current situation.

Heh, it *is* that easy -- get Sun's Java stack, install, download your 
app of choice, install and run!

Regards,
Dariusz


		
___________________________________________________________ 
Yahoo! Photos ? NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com



From nicolas.mailhot at laposte.net  Sat Mar 25 10:59:22 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Mar 2006 11:59:22 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <44251FC4.3070207@yahoo.co.uk>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<44251FC4.3070207@yahoo.co.uk>
Message-ID: <1143284362.4018.14.camel@rousalka.dyndns.org>

Le samedi 25 mars 2006 ? 10:47 +0000, Dariusz J. Garbowski a ?crit :

> > If it where that easy, we'd have the latest eclipse version in Fedora
> > with all the major plugins instead of the current situation.
> 
> Heh, it *is* that easy -- get Sun's Java stack, install, download your 
> app of choice, install and run!

It's not, I'm sorry. You require lots of end-user work to make it
anything like work. That's why a stupid app like the logitech remote
controler (which has very simple fontionnality) is still not available
for linux even if it was written in java to be cross-platform.

For a developper java is easy. As soon as you need an average end-user
to make it work and are paying the support costs it suddenly is no
longer anywhere near a good choice.

And I'm not even talking about the differences between jvm behaviour (if
you think you can go sun-only just compare the arches sun, ibm and bea
support)

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

From jfontain at free.fr  Sat Mar 25 11:05:02 2006
From: jfontain at free.fr (Jean-Luc Fontaine)
Date: Sat, 25 Mar 2006 12:05:02 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <132A9F5E12B8828DA6ED8E85@[10.169.6.226]>
References: <132A9F5E12B8828DA6ED8E85@[10.169.6.226]>
Message-ID: <442523DE.3050703@free.fr>

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

Kenneth Porter wrote:

> I'm tasked to write a front end for an instrumentation application
> for "that other operating system" ;) and I'd like to use GUI
> controls that are cross-platform portable for an eventual Linux
> port. What would the list recommend? I essentially need something
> that resembles the front panel of an oscilloscope, along with some
> dial indicators and knobs. I've also been thinking about making it
> web-accessible, so perhaps a Java-based solution would be suitable.
>
>
Tcl/Tk (in FC), with BLT/Tktable (in FE) for graphs/spreadsheet
tables, Vu extension for dials, tcllib (in FE) for HTTP, ....
These are completely cross-platform and free software. See moodss in
FE to get an idea about a GUI built with those.

- --
Jean-Luc Fontaine  http://jfontain.free.fr/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEJSPdkG/MMvcT1qQRAj88AJ9njivNG4AF8jVKZpE2by2hYK8H2gCgvdO8
k9em7sSTDkbw9FYa0RYnAuM=
=tB9D
-----END PGP SIGNATURE-----



From thuforuk at yahoo.co.uk  Sat Mar 25 11:30:51 2006
From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski)
Date: Sat, 25 Mar 2006 11:30:51 +0000
Subject: GUI controls for instrumentation
In-Reply-To: <1143284362.4018.14.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>	<200603242033.03945.lamont@gurulabs.com>	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>	<1143281498.4018.6.camel@rousalka.dyndns.org>	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
Message-ID: <442529EB.2040004@yahoo.co.uk>

On 03/25/2006 10:59 AM, Nicolas Mailhot wrote:
> Le samedi 25 mars 2006 ? 10:47 +0000, Dariusz J. Garbowski a ?crit :
> 
>>> If it where that easy, we'd have the latest eclipse version in Fedora
>>> with all the major plugins instead of the current situation.
>> Heh, it *is* that easy -- get Sun's Java stack, install, download your 
>> app of choice, install and run!
> 
> It's not, I'm sorry. You require lots of end-user work to make it
> anything like work. That's why a stupid app like the logitech remote
> controler (which has very simple fontionnality) is still not available
> for linux even if it was written in java to be cross-platform.

There's nothing in the applications themselves to stop working on Linux. 
Work user has to put comes from the fact that distributions tend to make 
user's life more difficult by not making it trivial to have e.g. Sun's 
JRE installed (I don't want to blame distro developers here, Sun is 
probably the most guilty by not allowing to repackage and redistribute 
JRE). Yet situation is IMHO similar to proprietary NVidia drivers: users 
just have it easier thanks to the work of Livna developers (at least on 
Fedora). And, hey!, users still manage to install proprietary nvidia 
drivers from NVidia rather than Livna, with all the hassle it makes! 
Users are not stupid, they are ready and able to do quite a few things 
when they have clear instructions.

Let's say we have "Livna JRE" to install using yum. What's missing to 
make running Java apps trivial is making sure that there is at least a 
simple shell script to run it from command line. Say, user opens up "Run 
Command" dialog and types "jmeter" and it just starts. Of course the 
script would need to line on $PATH. Other "use case" is user opens up 
application's directory and double clicks the script. Application 
starts. Many applications already do provide it: NetBeans, Eclipse, 
JMeter...

Then a step further is packaging applications for distro, like each 
other native application.


> For a developper java is easy. As soon as you need an average end-user
> to make it work and are paying the support costs it suddenly is no
> longer anywhere near a good choice.

Nothing to do with Java applications, it's all about packaging. If your 
application is packaged for Linux, it will be easy to run! Vice versa it 
can be difficult for Windows if it's not packaged for Windows. Where's 
Java fault here?


> And I'm not even talking about the differences between jvm behaviour (if
> you think you can go sun-only just compare the arches sun, ibm and bea
> support)

You asked about *easy* way -- the easiest, least troublesome is to use 
Sun's JRE. You are free to try other solutions too. You have this 
freedom. It's good. Don't want problems? Try Sun first. If you really 
need to run on more exotic hardware, you are likely to hit other issues, 
yet it's a particular JRE's issue. Bug IBM/Sun/BEA to fix it :-)

Same with free stack. Everybody knows it's not quite there yet to run 
all Java software. And yes there's a few Java apps out there using sun.* 
packages -- not a Java issue either. Bug application developer to fix it 
so it's ready for free stack.

Want to avoid as much issues as you can? Get Sun's JRE and make sure 
it's on your PATH before free stack is.

Regards,
Dariusz

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com



From nicolas.mailhot at laposte.net  Sat Mar 25 11:51:26 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Mar 2006 12:51:26 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <442529EB.2040004@yahoo.co.uk>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
	<442529EB.2040004@yahoo.co.uk>
Message-ID: <1143287487.8838.4.camel@rousalka.dyndns.org>

Le samedi 25 mars 2006 ? 11:30 +0000, Dariusz J. Garbowski a ?crit :
>  Yet situation is IMHO similar to proprietary NVidia drivers: users 
> just have it easier thanks to the work of Livna developers (at least on 
> Fedora). And, hey!, users still manage to install proprietary nvidia 
> drivers from NVidia rather than Livna, with all the hassle it makes! 

Again that's all fine and dandy with hobbyists/gamers/whatever which are
ready to make all kinds of stupid sacrifices gratis pro deo. In a work
context (and I think oscilloscope qualifies) that's a direct helpdesk
redirection which *will* cost lots of money to someone.

java GUI is not realistic unless you're not fronting the support calls
nor are paying for them one way or another.

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

From thuforuk at yahoo.co.uk  Sat Mar 25 12:06:39 2006
From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski)
Date: Sat, 25 Mar 2006 12:06:39 +0000
Subject: GUI controls for instrumentation
In-Reply-To: <1143287487.8838.4.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>	<200603242033.03945.lamont@gurulabs.com>	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>	<1143281498.4018.6.camel@rousalka.dyndns.org>	<44251FC4.3070207@yahoo.co.uk>	<1143284362.4018.14.camel@rousalka.dyndns.org>	<442529EB.2040004@yahoo.co.uk>
	<1143287487.8838.4.camel@rousalka.dyndns.org>
Message-ID: <4425324F.9070903@yahoo.co.uk>

On 03/25/2006 11:51 AM, Nicolas Mailhot wrote:
> Le samedi 25 mars 2006 ? 11:30 +0000, Dariusz J. Garbowski a ?crit :
>>  Yet situation is IMHO similar to proprietary NVidia drivers: users 
>> just have it easier thanks to the work of Livna developers (at least on 
>> Fedora). And, hey!, users still manage to install proprietary nvidia 
>> drivers from NVidia rather than Livna, with all the hassle it makes! 
> 
> Again that's all fine and dandy with hobbyists/gamers/whatever which are
> ready to make all kinds of stupid sacrifices gratis pro deo. In a work
> context (and I think oscilloscope qualifies) that's a direct helpdesk
> redirection which *will* cost lots of money to someone.
> 
> java GUI is not realistic unless you're not fronting the support calls
> nor are paying for them one way or another.

I see where you're coming from. And I can see this may be a problem. I 
work in a big company on a web application that serves Java applet. 
Occasionally we used to have JRE/plugin issues however since company 
standardizes and pushes (via update mechanism) JRE on each user's 
machine we do not see that anymore. In fact we have more issues with 
Acrobat Reader...
But I can see that in some environments Java on the desktop may be a 
support issue.

Regards,
Dariusz


		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com



From hughsient at gmail.com  Sat Mar 25 12:30:10 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 25 Mar 2006 12:30:10 +0000
Subject: Bootsplash?
In-Reply-To: <1143267968.2247.3.camel@price.stavtrup-st.dk>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143211193.3802.120.camel@sundaram.pnq.redhat.com>
	<1143267968.2247.3.camel@price.stavtrup-st.dk>
Message-ID: <1143289811.2261.10.camel@localhost.localdomain>

On Sat, 2006-03-25 at 07:26 +0100, David Nielsen wrote:
> fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
> > Might be a good alternative path to try out.
> 
> If you are looking at alternatives, the tool set Gentoo uses works
> really well and has a really nice featureset - we might be able to adapt
> that to our needs.

What do they use?

Richard.



From j.rink at freenet.de  Sat Mar 25 12:44:55 2006
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Sat, 25 Mar 2006 13:44:55 +0100
Subject: smbfs not in the FC5 kernel?
Message-ID: <20060325134455.7167e6e7.j.rink@freenet.de>

Hi,
my old method to mount a smbfs filesystem does not work, further
investigation shows, that the smbfs kernel module does not exist in the
actual FC5 kernel.

Has the method changed? In fedora core 3 there was such a kernel module.



From jburgess at uklinux.net  Sat Mar 25 12:47:35 2006
From: jburgess at uklinux.net (Jon Burgess)
Date: Sat, 25 Mar 2006 12:47:35 +0000
Subject: Anaconda: good work!
In-Reply-To: <20060324214712.GD8721@devserv.devel.redhat.com>
References: <131501c64dc2$fe1522b0$b6491b31@td612671>	<1143045925.24028.12.camel@orodruin.boston.redhat.com>	<1143102722.2853.83.camel@linux>	<20060323164702.GG3137@exeter.boston.redhat.com>	<44240A9E.4000602@uklinux.net>
	<20060324214712.GD8721@devserv.devel.redhat.com>
Message-ID: <44253BE7.8010308@uklinux.net>

Bill Nottingham wrote:
> Jon Burgess (jburgess at uklinux.net) said: 
>> Chris Lumens wrote:
>>> We can't really do this easily.  Making a new anaconda means making new
>>> first and second stage images, which means making new CD and DVD images,
>>> which means a huge headache for mirrors and for keeping track of all
>>> these versions of images floating around.
>> Using Jigdo http://atterer.net/jigdo/ could help reduce the amount of 
>> data needed to be stored by the mirrors for a re-spun CD/DVD ISOs. It 
>> reduces the amount of data to be downloaded if the user already has the 
>> original ISOs.
>>
>> It also allows enables other things like making a set of CD ISOs from 
>> the RPMS on a DVD ISO (or the reverse).
>>
>> I see it has just been added to extras-devel if anyone wants to try it out.
> 
> If someone wants to post example jigdo stuff we could put on the
> mirror master, that would be great. Not sure it's practical for rawhide,
> though, as we really don't even want to go to the effort of spinning
> isos for that.
> 
> Bill
> 

I've just created jigdo and template files for the FC5 i386 and x86-64 
CD and DVD ISOs. See http://www.jburgess.uklinux.net/jigdo/

To install Jigdo on FC5:

# yum --enablerepo=extras-development install jigdo

To get it to build the i386 disc1 ISO:

# jigdo-lite http://www.jburgess.uklinux.net/jigdo/FC-5-i386-disc1.jigdo

Jigdo has already come in useful for me. I've been able to convert the 
DVD ISOs which I downloaded via Bittorrent into the CD ISOs and rescue 
CD without having to download any extra fies.

The jigdo and template files are tiny. Less than 2MB per architecture. I 
think that they would make a useful addition to a future Fedora release.

The Debian ISO process appears to use a patched mkisofs which generates 
the jigdo meta files at the same time that the ISOs are created. See 
http://www.einval.com/~steve/software/JTE/

I'm sure the download options could do with a little work. The jigdo 
file currently specifies http://download.fedoraproject.org as the 
download location so it gets redirected off to a new mirror for every 
file that it tries to download. It looks like Jigdo has some hard coded 
behaviour for selecting Debian mirrors, I guess we could do something 
similar for Fedora and perhaps utilise the yum mirrorlist file.

	Jon



From seanlkml at sympatico.ca  Sat Mar 25 12:47:57 2006
From: seanlkml at sympatico.ca (sean)
Date: Sat, 25 Mar 2006 07:47:57 -0500
Subject: smbfs not in the FC5 kernel?
In-Reply-To: <20060325134455.7167e6e7.j.rink@freenet.de>
References: <20060325134455.7167e6e7.j.rink@freenet.de>
Message-ID: <BAYC1-PASMTP10722F58C7B0DDF46BE57BAEDC0@CEZ.ICE>

On Sat, 25 Mar 2006 13:44:55 +0100
J?rn Rink <j.rink at freenet.de> wrote:

> my old method to mount a smbfs filesystem does not work, further
> investigation shows, that the smbfs kernel module does not exist in the
> actual FC5 kernel.
> 
> Has the method changed? In fedora core 3 there was such a kernel module.
 
Hi J?rn,

Use CIFS instead of smbfs.   By the way, this question would be more 
appropriately asked on the fedora-list not here on the developers list.

Sean



From sundaram at fedoraproject.org  Sat Mar 25 12:54:01 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 25 Mar 2006 18:24:01 +0530
Subject: smbfs not in the FC5 kernel?
In-Reply-To: <20060325134455.7167e6e7.j.rink@freenet.de>
References: <20060325134455.7167e6e7.j.rink@freenet.de>
Message-ID: <1143291241.3802.297.camel@sundaram.pnq.redhat.com>

On Sat, 2006-03-25 at 13:44 +0100, J?rn Rink wrote:
> Hi,
> my old method to mount a smbfs filesystem does not work, further
> investigation shows, that the smbfs kernel module does not exist in the
> actual FC5 kernel.
> 
> Has the method changed? In fedora core 3 there was such a kernel module.
> 
smbfs has been deprecated by CIFS. Try using that. Added this
information to the release notes
(http://fedoraproject.org/wiki/Docs/Beats/PackageNotes) which will be
published as an errata. 



Rahul



From j.rink at freenet.de  Sat Mar 25 12:57:29 2006
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Sat, 25 Mar 2006 13:57:29 +0100
Subject: strange X11 Problems with cisco vpn client under Fedora 4 or 5
In-Reply-To: <pan.2006.03.24.00.19.45.916618@hotpop.com>
References: <20060323102746.d7bff2ff.j.rink@freenet.de>
	<pan.2006.03.24.00.19.45.916618@hotpop.com>
Message-ID: <20060325135729.3511e6b3.j.rink@freenet.de>

Am Thu, 23 Mar 2006 19:19:46 -0500
hat Zing <shishz at hotpop.com> (Zing) folgendes geschrieben:


> Mouse pointer sticks to left side of screen
> https://bugs.freedesktop.org/show_bug.cgi?id=3113

That means, i have to recompile X11?
omg
cu 



From j.rink at freenet.de  Sat Mar 25 13:21:29 2006
From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink)
Date: Sat, 25 Mar 2006 14:21:29 +0100
Subject: smbfs not in the FC5 kernel?
In-Reply-To: <BAYC1-PASMTP10722F58C7B0DDF46BE57BAEDC0@CEZ.ICE>
References: <20060325134455.7167e6e7.j.rink@freenet.de>
	<BAYC1-PASMTP10722F58C7B0DDF46BE57BAEDC0@CEZ.ICE>
Message-ID: <20060325142129.b26d9488.j.rink@freenet.de>

Am Sat, 25 Mar 2006 07:47:57 -0500
hat sean <seanlkml at sympatico.ca> (sean) folgendes geschrieben:

Hi,

>  
> Hi J?rn,
> 
> Use CIFS instead of smbfs.   By the way, this question would be more 
> appropriately asked on the fedora-list not here on the developers
> list.

yes, sry you are right, shame on me, because i found it out myself 20
seconds after i trashed the mailing list with my fully unnecessary
comment.

It will not happen anymore in the future.

 CU
  J?rn Rink



From fedora at leemhuis.info  Sat Mar 25 13:23:58 2006
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 25 Mar 2006 14:23:58 +0100
Subject: smbfs not in the FC5 kernel?
In-Reply-To: <1143291241.3802.297.camel@sundaram.pnq.redhat.com>
References: <20060325134455.7167e6e7.j.rink@freenet.de>
	<1143291241.3802.297.camel@sundaram.pnq.redhat.com>
Message-ID: <1143293039.5197.15.camel@localhost.localdomain>

Am Samstag, den 25.03.2006, 18:24 +0530 schrieb Rahul Sundaram:
> On Sat, 2006-03-25 at 13:44 +0100, J?rn Rink wrote:
> > my old method to mount a smbfs filesystem does not work, further
> > investigation shows, that the smbfs kernel module does not exist in the
> > actual FC5 kernel.
> > 
> > Has the method changed? In fedora core 3 there was such a kernel module.
> smbfs has been deprecated by CIFS. Try using that. 

Exactly.

<criticism mode> But why the heck are the Core developers simply closing
#179451, #185363 and #186427 instead of reassigning the bug to
util-linux? I suppose the maintainers of mount should be able to patch
it somehow so it uses cifs automatically instead of the old smbmnt
(which will fail due to missing smbfs support in the kernel). That would
avoid a lot of confusion.</criticism mode>

I couldn't find a bug that requests such a change. I'll file one later
today.

CU
thl
-- 
Thorsten Leemhuis <fedora at leemhuis.info>



From david at lovesunix.net  Sat Mar 25 13:49:55 2006
From: david at lovesunix.net (David Nielsen)
Date: Sat, 25 Mar 2006 14:49:55 +0100
Subject: Bootsplash?
In-Reply-To: <1143289811.2261.10.camel@localhost.localdomain>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143211193.3802.120.camel@sundaram.pnq.redhat.com>
	<1143267968.2247.3.camel@price.stavtrup-st.dk>
	<1143289811.2261.10.camel@localhost.localdomain>
Message-ID: <1143294595.2428.4.camel@price.stavtrup-st.dk>

l?r, 25 03 2006 kl. 12:30 +0000, skrev Richard Hughes:
> On Sat, 2006-03-25 at 07:26 +0100, David Nielsen wrote:
> > fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
> > > Might be a good alternative path to try out.
> > 
> > If you are looking at alternatives, the tool set Gentoo uses works
> > really well and has a really nice featureset - we might be able to adapt
> > that to our needs.
> 
> What do they use?

http://dev.gentoo.org/~spock/projects/gensplash/

I think the developer aims to fix one of my top hated things about rhgb,
the fact that it displays ugly kernel messages between grub and loading
the splash - I dunno doing that seems very unpolished to me.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060325/7c19c73d/attachment.sig>

From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Sat Mar 25 13:52:12 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Sat, 25 Mar 2006 14:52:12 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
Message-ID: <20060325145212.2325eed4@python2>

Hi,

I've just tried to update the hardware I had in a machine, updating at the
same time the system from FC3 to FC5/dev. What I did was prepare an FC5
installation on the final hard drive, but in a temporary machine, then
planned on simply fixing up the initrd for the final one and putting the
disk in. But it wasn't that easy...

Once I got the final machine ready, a Sempron 2800+ on an Asus K8N4-E
Deluxe motherboard (pretty neat and not too expensive), which is based on
an nForce4-4x chipset, I could boot fine off the old parallel ata drive
with FC3 in single user mode, then even mount the new serial ata drive
which was recognized fine.

I thought it would be a piece of cake from here, since I just added the
sata_nv to the initrd and rebooted...

But it turns out, after fighting for a long while thinking it was an
initrd problem, that even the FC5 installation booted from DVD doesn't see
the serial ata drive, although it loads the sata_nv module. After loading
the module, nothing special in dmesg apart from some selinux related
stuff.

After hours of fiddling, trying to add a sleep delay after the sata_nv
modprobe in the inirtd (I saw a post somewhere about a race condition at
some point), I simply gave up. I brought a newer parallel ata to put into
the machine, and booting for the even older one where FC3 is installed, I
managed to copy over the install from the serial ata drive to the new
parallel ata one. BUT...

To my great surprise, I got into a very similar situation, where the
kernel wouldn't boot. Hmmm. So I tried once more simply starting an FC5
installation from the DVD, and same thing, when the kernel displays "hda:"
and seems to be trying to read the partition layout to display "hda1
hda2", I get messages about DMA timeouts.

Note that at that point, simply switching the boot device in the BIOS to
the old parallel ata drive and booting FC3, I can mount all three drives
and they work perfectly. So it doesn't seem to be a cabling problem or a
BIOS problem.

The only explanation I currently have is that 2.6.15 and 2.6.16 kernels
have a problem with this motherboard, as I've tried both the original FC5
kernel and the latest one from FC5 testing updates.

I've also tried the "noprobe" install option, booting with "noapic", but
I've run out of ideas....

Does anyone know about any issues with nForce4-4x chipsets currently? I've
been searching google for hours and found nothing at all.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2069_FC5
Load : 0.87 0.66 0.36



From nicolas.mailhot at laposte.net  Sat Mar 25 14:14:33 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Mar 2006 15:14:33 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <20060325145212.2325eed4@python2>
References: <20060325145212.2325eed4@python2>
Message-ID: <1143296074.8838.8.camel@rousalka.dyndns.org>

Hi,

I installed a rawhide (FC4->rawhide) system on a nforce4 mobo a few
months ago. The tricks I used were :

1. sata disks on sii controller (not the nforce one)
2. pata cd drive (sata dvd would fail once anaconda tried to reload it)
3. no winraid, but linux software raid on lvm

I'd have expected the situation to get better with FC5 :(

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

From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Sat Mar 25 14:39:37 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Sat, 25 Mar 2006 15:39:37 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <1143296074.8838.8.camel@rousalka.dyndns.org>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
Message-ID: <20060325153937.0e91fd98@python2>

Nicolas Mailhot wrote :

> I installed a rawhide (FC4->rawhide) system on a nforce4 mobo a few
> months ago. The tricks I used were :
> 
> 1. sata disks on sii controller (not the nforce one)
> 2. pata cd drive (sata dvd would fail once anaconda tried to reload it)
> 3. no winraid, but linux software raid on lvm
> 
> I'd have expected the situation to get better with FC5 :(

Thanks for the tip, but I just tried putting the sata drive on the
sata_sil controller (as a single drive, "JBOD") and the FC5 installer
still doesn't find any drive after having loaded the sata_sil module.

I can boot from the sata drive on that controller too, but again, even
after loading sata_sil from the initrd, it doesn't find the drive,
complains about /dev/root not found etc. and panics.

Seems like I'm really stuck as none of sata_nv, sata_sil or the normal ata
seem to work with recent kernels.

Any other pointers to stuff to test (even kernel patches, updated modules
etc.) would be very welcome.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2069_FC5
Load : 0.12 0.03 0.05



From hughsient at gmail.com  Sat Mar 25 14:54:50 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Sat, 25 Mar 2006 14:54:50 +0000
Subject: Bootsplash?
In-Reply-To: <1143294595.2428.4.camel@price.stavtrup-st.dk>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143211193.3802.120.camel@sundaram.pnq.redhat.com>
	<1143267968.2247.3.camel@price.stavtrup-st.dk>
	<1143289811.2261.10.camel@localhost.localdomain>
	<1143294595.2428.4.camel@price.stavtrup-st.dk>
Message-ID: <1143298491.2297.2.camel@localhost.localdomain>

On Sat, 2006-03-25 at 14:49 +0100, David Nielsen wrote:
> l?r, 25 03 2006 kl. 12:30 +0000, skrev Richard Hughes:
> > On Sat, 2006-03-25 at 07:26 +0100, David Nielsen wrote:
> > > fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
> > > > Might be a good alternative path to try out.
> > > 
> > > If you are looking at alternatives, the tool set Gentoo uses works
> > > really well and has a really nice featureset - we might be able to adapt
> > > that to our needs.
> > 
> > What do they use?
> 
> http://dev.gentoo.org/~spock/projects/gensplash/
> 
> I think the developer aims to fix one of my top hated things about rhgb,
> the fact that it displays ugly kernel messages between grub and loading
> the splash - I dunno doing that seems very unpolished to me.

Whats wrong with doing something with the framebuffer (like this) before
we do the hibernate:

fbi -a -1 --noedit -d /dev/fb0 -vt
7 /usr/share/backgrounds/images/default.png --noverbose

in pm-hibernate or something. Doing this makes my X not come back after
suspending, but I may be being a moron.

Richard.



From nicolas.mailhot at laposte.net  Sat Mar 25 15:19:04 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Mar 2006 16:19:04 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <20060325153937.0e91fd98@python2>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
Message-ID: <1143299944.8838.11.camel@rousalka.dyndns.org>

Le samedi 25 mars 2006 ? 15:39 +0100, Matthias Saou a ?crit :

> I can boot from the sata drive on that controller too, but again, even
> after loading sata_sil from the initrd, it doesn't find the drive,
> complains about /dev/root not found etc. and panics.

Another boog I hit was FUA doing crazy things with my disks, but I think
the sata people wanted to disable it in 2.6.16 final

Apart from this I don't remember any particular problem. Sorry

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

From wrrhdev at riede.org  Sat Mar 25 15:46:21 2006
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 25 Mar 2006 10:46:21 -0500
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <20060325153937.0e91fd98@python2> (from
	thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net on
	Sat Mar 25 09:39:37 2006)
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
Message-ID: <1143301581l.15265l.1l@athena.riede.org>

On 03/25/2006 09:39:37 AM, Matthias Saou wrote:
> 
> I can boot from the sata drive on that controller too, but again, even
> after loading sata_sil from the initrd, it doesn't find the drive,
> complains about /dev/root not found etc. and panics.
> 
> Seems like I'm really stuck as none of sata_nv, sata_sil or the normal ata
> seem to work with recent kernels.

Are you sure you have all the right modules in your initrd?
I don't have the same motherboard as you do, but am able to boot with / on sata_nv (raid).

My initrd modules:

lib/dm-zero.ko
lib/raid1.ko
lib/dm-mirror.ko
lib/ext3.ko
lib/dm-mod.ko
lib/dc395x.ko
lib/libata.ko
lib/sata_nv.ko
lib/dm-snapshot.ko
lib/scsi_mod.ko
lib/sd_mod.ko
lib/jbd.ko

Regards, Willem Riede.



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Sat Mar 25 15:50:14 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Sat, 25 Mar 2006 16:50:14 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <1143299944.8838.11.camel@rousalka.dyndns.org>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
	<1143299944.8838.11.camel@rousalka.dyndns.org>
Message-ID: <20060325165014.4edb1809@python2>

Nicolas Mailhot wrote :

> Le samedi 25 mars 2006 ? 15:39 +0100, Matthias Saou a ?crit :
> 
> > I can boot from the sata drive on that controller too, but again, even
> > after loading sata_sil from the initrd, it doesn't find the drive,
> > complains about /dev/root not found etc. and panics.
> 
> Another boog I hit was FUA doing crazy things with my disks, but I think
> the sata people wanted to disable it in 2.6.16 final
> 
> Apart from this I don't remember any particular problem. Sorry

FUA?
Right now, I'm running the latest FC3 errata kernel (2.6.12-1.1381_FC3) on
this FC5 system. Needless to say that things aren't smooth, especially
since udev really doesn't like that kernel.

I've tried the FC5 kernel, the latest FC4 update kernel the latest FC5
testing update kernel and the FC development kernel, and none have sata_nv
nor sata_sil output anything in the kernel messages, as if the devices
weren't there! OTOH, the FC3 kernel sees all of the 8 (in total) sata
ports, and the drive works great.

Something seems to have happened between 2.6.12 and 2.6.15 regarding
nForce4 chipsets, since even the parallel ata doesn't work properly *sigh*.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2069_FC5
Load : 0.21 0.11 0.03



From saddateh at gmail.com  Sat Mar 25 15:50:27 2006
From: saddateh at gmail.com (Sadda Teh)
Date: Sat, 25 Mar 2006 10:50:27 -0500
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <1143299944.8838.11.camel@rousalka.dyndns.org>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
	<1143299944.8838.11.camel@rousalka.dyndns.org>
Message-ID: <fc33c1550603250750n28a3c804x8698ebdcc1135354@mail.gmail.com>

Try booting with acpi=off

The Asus nforce 4 boards (at least the one I have, A8N-VM) have a broken
ACPI implementation, and when booted with acpi enabled (the default), causes
problems with other hardware in the system. Though I'm not sure it would
affect the problem you're having with sata. Worth a try though I guess...

On 3/25/06, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le samedi 25 mars 2006 ? 15:39 +0100, Matthias Saou a ?crit :
>
> > I can boot from the sata drive on that controller too, but again, even
> > after loading sata_sil from the initrd, it doesn't find the drive,
> > complains about /dev/root not found etc. and panics.
>
> Another boog I hit was FUA doing crazy things with my disks, but I think
> the sata people wanted to disable it in 2.6.16 final
>
> Apart from this I don't remember any particular problem. Sorry
>
> --
> Nicolas Mailhot
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iEYEABECAAYFAkQlX2gACgkQI2bVKDsp8g3w3QCfSglyeMVOL3nD/mFliZ8YLwUn
> ahUAoIhrhFyxI/9ulQCVYHhsS37rvoLm
> =DDo7
> -----END PGP SIGNATURE-----
>
>
> --
> 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/20060325/1fdf691b/attachment.htm>

From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Sat Mar 25 15:52:43 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Sat, 25 Mar 2006 16:52:43 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <1143301581l.15265l.1l@athena.riede.org>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
	<1143301581l.15265l.1l@athena.riede.org>
Message-ID: <20060325165243.4964c718@python2>

Willem Riede wrote :

> On 03/25/2006 09:39:37 AM, Matthias Saou wrote:
> > 
> > I can boot from the sata drive on that controller too, but again, even
> > after loading sata_sil from the initrd, it doesn't find the drive,
> > complains about /dev/root not found etc. and panics.
> > 
> > Seems like I'm really stuck as none of sata_nv, sata_sil or the normal ata
> > seem to work with recent kernels.
> 
> Are you sure you have all the right modules in your initrd?
> I don't have the same motherboard as you do, but am able to boot with / on sata_nv (raid).

I'm pretty sure I do and that it's not the problem, because :
- The FC5 installation loads sata_nv and sata_sil but doesn't "see"
anything even once they're loaded.
- Adding the same modules to the FC3 kernel's initrd makes things work.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2069_FC5
Load : 0.28 0.15 0.05



From dimi at lattica.com  Sat Mar 25 16:06:15 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 25 Mar 2006 11:06:15 -0500
Subject: Bootsplash?
In-Reply-To: <1143220662.3500.1.camel@localhost>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost>
Message-ID: <1143302775.2605.41.camel@dimi>

On Fri, 2006-03-24 at 09:17 -0800, Toshio Kuratomi wrote:
> http://splashy.alioth.debian.org/wiki/doku.php
> 
> Hmm..  No kernel patches and no X...  If you submit it you'll get
> interest from me at least :-)

Same here, I'd be really interested in a packaged version.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Sat Mar 25 16:10:17 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Sat, 25 Mar 2006 17:10:17 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <fc33c1550603250750n28a3c804x8698ebdcc1135354@mail.gmail.com>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
	<1143299944.8838.11.camel@rousalka.dyndns.org>
	<fc33c1550603250750n28a3c804x8698ebdcc1135354@mail.gmail.com>
Message-ID: <20060325171017.093a1cd1@python2>

ARGH!!!!

I can't believe I've waisted two days on this one... I think I tried
"noacpi", but maybe it doesn't work and "acpi=off" does?

Anyway, that was it. I suppose the FC3 kernels don't have ACPI enabled by
default, which would then explain.

Don't you just hate it when these kind of things happen... and I thought
only laptops had broken ACPI implementations :-(

Matthias

Sadda Teh wrote :

> Try booting with acpi=off
> 
> The Asus nforce 4 boards (at least the one I have, A8N-VM) have a broken
> ACPI implementation, and when booted with acpi enabled (the default), causes
> problems with other hardware in the system. Though I'm not sure it would
> affect the problem you're having with sata. Worth a try though I guess...
> 
> On 3/25/06, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> >
> > Le samedi 25 mars 2006 ? 15:39 +0100, Matthias Saou a ?crit :
> >
> > > I can boot from the sata drive on that controller too, but again, even
> > > after loading sata_sil from the initrd, it doesn't find the drive,
> > > complains about /dev/root not found etc. and panics.
> >
> > Another boog I hit was FUA doing crazy things with my disks, but I think
> > the sata people wanted to disable it in 2.6.16 final
> >
> > Apart from this I don't remember any particular problem. Sorry
> >
> > --
> > Nicolas Mailhot
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2.2 (GNU/Linux)
> >
> > iEYEABECAAYFAkQlX2gACgkQI2bVKDsp8g3w3QCfSglyeMVOL3nD/mFliZ8YLwUn
> > ahUAoIhrhFyxI/9ulQCVYHhsS37rvoLm
> > =DDo7
> > -----END PGP SIGNATURE-----
> >
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> >


-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2069_FC5
Load : 0.00 0.01 0.02



From nicolas.mailhot at laposte.net  Sat Mar 25 17:35:59 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 25 Mar 2006 18:35:59 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <20060325165014.4edb1809@python2>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
	<1143299944.8838.11.camel@rousalka.dyndns.org>
	<20060325165014.4edb1809@python2>
Message-ID: <1143308160.3375.2.camel@rousalka.dyndns.org>

Le samedi 25 mars 2006 ? 16:50 +0100, Matthias Saou a ?crit :
> Nicolas Mailhot wrote :
> 
> > Le samedi 25 mars 2006 ? 15:39 +0100, Matthias Saou a ?crit :
> > 
> > > I can boot from the sata drive on that controller too, but again, even
> > > after loading sata_sil from the initrd, it doesn't find the drive,
> > > complains about /dev/root not found etc. and panics.
> > 
> > Another boog I hit was FUA doing crazy things with my disks, but I think
> > the sata people wanted to disable it in 2.6.16 final
> > 
> > Apart from this I don't remember any particular problem. Sorry
> 
> FUA?

The new SATA-level barrier stuff.
When it fails, it fails spectacularly

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

From i.pilcher at comcast.net  Sat Mar 25 17:51:07 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Sat, 25 Mar 2006 11:51:07 -0600
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <20060325171017.093a1cd1@python2>
References: <20060325145212.2325eed4@python2>	<1143296074.8838.8.camel@rousalka.dyndns.org>	<20060325153937.0e91fd98@python2>	<1143299944.8838.11.camel@rousalka.dyndns.org>	<fc33c1550603250750n28a3c804x8698ebdcc1135354@mail.gmail.com>
	<20060325171017.093a1cd1@python2>
Message-ID: <e03vub$cm1$1@sea.gmane.org>

Matthias Saou wrote:
> 
> Don't you just hate it when these kind of things happen... and I thought
> only laptops had broken ACPI implementations :-(
> 

Oh, you poor, na?ve child.

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From emeric.maschino at jouy.inra.fr  Sat Mar 25 20:02:31 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Sat, 25 Mar 2006 21:02:31 +0100
Subject: selinux-policy-targeted-2.2.26-1 update failed
Message-ID: <1143316951.4425a1d750bff@www.jouy.inra.fr>

Hi,

I'm getting the following error with today Rawhide during the update of
selinux-policy-targeted-2.2.26-1

  Updating  : selinux-policy-targeted      ####################### [ 8/32]
libsemanage.semanage_install_active: setfiles returned error code 1.
libsemanage.semanage_install_active: Could not copy
/etc/selinux/targeted/modules/active/policy.kern to
/etc/selinux/targeted/policy/policy.20.
semodule:  Failed!
/sbin/restorecon: error while loading shared libraries: libselinux.so.1: cannot
open shared object file: No such file or directory

Is there something I must correct or will this issue be adressed in an
forthcoming update?

Cheers,

   ?meric



From ericsbinaryworld at gmail.com  Sat Mar 25 20:16:02 2006
From: ericsbinaryworld at gmail.com (Eric Mesa)
Date: Sat, 25 Mar 2006 15:16:02 -0500
Subject: pup uncheck all
Message-ID: <4425A502.2090903@gmail.com>

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

Pup sorely needs an uncheck-all button.  Right now I have a few
packages that keep messing the whole process up since they depend on
Xorg6 (since the packagers haven't updated the specs yet) so it's
quite tedious to uncheck every single box that won't work.

Thanks,

- --
Eric Mesa
ericsbinaryworld at gmail.com
http://www.ericsbinaryworld.com
Note:  All emails from this address should have a GPG signature.  If
you have the proper setup you can use this to confirm my identity and
that the email was not changed in transit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD4DBQFEJaUBPvU+8ApmWXIRAn4JAJ9L24Z+O4wvfK4C4fSuZY3hIDxwUQCYjLHs
uC++RLpQXzGflJVSi5cgOw==
=pdCe
-----END PGP SIGNATURE-----



From rhally at mindspring.com  Sat Mar 25 20:07:42 2006
From: rhally at mindspring.com (Richard Hally)
Date: Sat, 25 Mar 2006 15:07:42 -0500
Subject: selinux-policy-targeted-2.2.26-1 update failed
In-Reply-To: <1143316951.4425a1d750bff@www.jouy.inra.fr>
References: <1143316951.4425a1d750bff@www.jouy.inra.fr>
Message-ID: <4425A30E.4020300@mindspring.com>

?meric Maschino wrote:
> Hi,
> 
> I'm getting the following error with today Rawhide during the update of
> selinux-policy-targeted-2.2.26-1
> 
>   Updating  : selinux-policy-targeted      ####################### [ 8/32]
> libsemanage.semanage_install_active: setfiles returned error code 1.
> libsemanage.semanage_install_active: Could not copy
> /etc/selinux/targeted/modules/active/policy.kern to
> /etc/selinux/targeted/policy/policy.20.
> semodule:  Failed!
> /sbin/restorecon: error while loading shared libraries: libselinux.so.1: cannot
> open shared object file: No such file or directory
> 
> Is there something I must correct or will this issue be adressed in an
> forthcoming update?
> 
> Cheers,
> 
>    ?meric
> 
check to make sure you have libselinux installed.
After todays update from rawhide, I have libselinux-1.30-1.
HTH



From fedora at camperquake.de  Sat Mar 25 20:24:14 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 25 Mar 2006 21:24:14 +0100
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <20060325171017.093a1cd1@python2>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
	<1143299944.8838.11.camel@rousalka.dyndns.org>
	<fc33c1550603250750n28a3c804x8698ebdcc1135354@mail.gmail.com>
	<20060325171017.093a1cd1@python2>
Message-ID: <20060325212414.5b87ca55@nausicaa.camperquake.de>

Hi.

Matthias Saou <thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net> wrote:

> Don't you just hate it when these kind of things happen... and I thought
> only laptops had broken ACPI implementations :-(

Is there a single nonbroken ACPI implentation out there?


-- 
End users are just test loads for verifying that the system works, kind
of like resistors in an electrical circuit.  -- Kaz Kylheku in c.o.l.d.s



From emeric.maschino at jouy.inra.fr  Sat Mar 25 20:49:09 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Sat, 25 Mar 2006 21:49:09 +0100
Subject: selinux-policy-targeted-2.2.26-1 update failed
In-Reply-To: <4425A30E.4020300@mindspring.com>
References: <1143316951.4425a1d750bff@www.jouy.inra.fr>
	<4425A30E.4020300@mindspring.com>
Message-ID: <1143319749.4425acc59c729@www.jouy.inra.fr>

Hi Richard,

> check to make sure you have libselinux installed.
> After todays update from rawhide, I have libselinux-1.30-1.
> HTH

Where did you get this package? After today update, I have libselinux-1.12.2-1
and selinux-policy-*-2.2.26-1. This is on an Itanium workstation (Fedora ia64
flavour).

Thanks for your advice anyway.

   ?meric

PS: As a workaround, I ran in permissive mode, so that all the packages are
updated correctly. But now, there are a lot of AVCs in /var/log/messages and
/var/log/audit/audit.log



From david at lovesunix.net  Sat Mar 25 21:16:06 2006
From: david at lovesunix.net (David Nielsen)
Date: Sat, 25 Mar 2006 22:16:06 +0100
Subject: selinux-policy-targeted-2.2.26-1 update failed
In-Reply-To: <1143319749.4425acc59c729@www.jouy.inra.fr>
References: <1143316951.4425a1d750bff@www.jouy.inra.fr>
	<4425A30E.4020300@mindspring.com>
	<1143319749.4425acc59c729@www.jouy.inra.fr>
Message-ID: <1143321367.14370.3.camel@localhost.localdomain>

l?r, 25 03 2006 kl. 21:49 +0100, skrev ?meric Maschino:
> Hi Richard,
> 
> > check to make sure you have libselinux installed.
> > After todays update from rawhide, I have libselinux-1.30-1.
> > HTH
> 
> Where did you get this package? After today update, I have libselinux-1.12.2-1
> and selinux-policy-*-2.2.26-1. This is on an Itanium workstation (Fedora ia64
> flavour).
> 
> Thanks for your advice anyway.
> 
>    ?meric
> 
> PS: As a workaround, I ran in permissive mode, so that all the packages are
> updated correctly. But now, there are a lot of AVCs in /var/log/messages and
> /var/log/audit/audit.log

Yep, something about todays SELinux update seems to have made
Development live up to it's baby eating reputation.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060325/072b7b33/attachment.sig>

From seg at haxxed.com  Sat Mar 25 22:42:40 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Sat, 25 Mar 2006 16:42:40 -0600
Subject: Bootsplash?
In-Reply-To: <1143298491.2297.2.camel@localhost.localdomain>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143211193.3802.120.camel@sundaram.pnq.redhat.com>
	<1143267968.2247.3.camel@price.stavtrup-st.dk>
	<1143289811.2261.10.camel@localhost.localdomain>
	<1143294595.2428.4.camel@price.stavtrup-st.dk>
	<1143298491.2297.2.camel@localhost.localdomain>
Message-ID: <1143326561.10632.5.camel@localhost>

On Sat, 2006-03-25 at 14:54 +0000, Richard Hughes wrote:
> Whats wrong with doing something with the framebuffer (like this) before
> we do the hibernate:

Well, one major problem is the fact that fbcon and X do not get along on
some hardware. In particular, using rivafb and native X nv together is a
guaranteed system lockup on all nVidia hardware I've ever tried it on.

Can't really use framebuffer for anything until this is worked out.

Seems to me you could just stick to good old VGA though. (svgalib...) Or
maybe just do graphics in textmode... (hint: change the font...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060325/9dd75049/attachment.sig>

From alan at redhat.com  Sat Mar 25 22:48:23 2006
From: alan at redhat.com (Alan Cox)
Date: Sat, 25 Mar 2006 17:48:23 -0500
Subject: Known issues with nForce4-4x chipset and recent kernels?
In-Reply-To: <1143299944.8838.11.camel@rousalka.dyndns.org>
References: <20060325145212.2325eed4@python2>
	<1143296074.8838.8.camel@rousalka.dyndns.org>
	<20060325153937.0e91fd98@python2>
	<1143299944.8838.11.camel@rousalka.dyndns.org>
Message-ID: <20060325224823.GB9188@devserv.devel.redhat.com>

On Sat, Mar 25, 2006 at 04:19:04PM +0100, Nicolas Mailhot wrote:
> Another boog I hit was FUA doing crazy things with my disks, but I think
> the sata people wanted to disable it in 2.6.16 final

It was disabled yes



From shane at geeklords.org  Sat Mar 25 23:37:47 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Sat, 25 Mar 2006 15:37:47 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
Message-ID: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>

Greetings,

This message to the Fedora Development Community is an attempt to start a 
useful discussion on where Fedora/RHEL is today and where it is going in 
the future, on the subject of OS management. My apologies in advance for 
the long message.

OS management is a very broad topic, in specific I will focus on the 
elements that I consider foundational weaknesses (compared to what it 
could be).  This is not to imply these perceived "weaknesses" out weigh 
its strengths or that other OS's are overall superior in this regard.

A bit of background to put my technical comments in perspective:

I remember when I was first introduced to Unix (1992) and then later 
Linux (1993) compared to what I was used to at the time they combined a 
flexibility, functionality and a form of simplicity (in design) that when 
combined made all other operating systems seem hallow.  For the most part 
I still feel this way today, but over the years having worked in 
enterprise environments where Linux is the up and coming challenger to 
entrenched non-unix platforms (VMS, Windows, zOS, etc...) I have come to 
better appreciate some of the elements involved in limiting Linux's 
adoption.

I was recently tasked with standardizing/documenting our Linux server 
build/configuration process and as part of this process began training 
some of our Windows/Novell administrators to be able to carry out some of 
these basic tasks.  It was this second part of helping train people that 
caused me to examine and re-examine the processes I used for this 
standardization.

My goal was simple in theory, I would use pxe+kickstart and enforce 
standard configurations and policies via a series of post scripts while 
attempting to keep readability, simplicity and supportability from a 
"non-unix guru" perspective as my guiding light (A wise man once said: 
Make it as simple as possible but no simpler).  For those interested an 
example of what I came up with it can be obtained here: 
http://geeklords.org/~shane/kickstart

The process turned out to be not quite as simple as the theory but very 
educational none the less.  To start with I had a number of ways I could 
manipulate my fresh Linux install.

1) I could create a custom RPM that had all of the changes imbedded in 
config files and rpm scripts that merely overwrote the pre-existing ones. 
Problem being this approach hides the complexity of what all was being 
changed and why.

2) Use cfengine after the kickstart install.  This of course has some 
advantages over the rpm method but it also hides the same complexity and 
adds some of its own.

3) Document on paper all of the steps required and how to perform them 
from the console, taking advantage of the guis when available or command 
line when required.  I felt that was not only a big waste of time but left 
far too much to human error.


4) Create a series of simple scripts using basic OS applications/tools 
(sed, echo, cp, mv, authtool, postconf etc...) to perform all of the 
required modifications, documenting what and why along the way.


I choose method 4.

My conclusion having completed this process is that the number of 
variables, complexity and dependencies that must be understood and taken 
into account when modifying configuration files is much higher than it 
needs to be. I think this should be clear when reading the example scripts 
mentioned above.

Some things I learned:

Sed is a wonderful tool, but it is highly limited by the fact its user 
must take into account whole file(s) for each expression, this is further 
complicated when one must consider the file may change over time.  The 
complexity and readability of regular expression tools is much higher than 
should be required to change OS/application variables.

Creating new files or appending to the end of existing files with "echo" 
only takes one so far.  This also tends to have the cost of hurting 
readability as it is often the case you would prefer putting data 
somewhere else in the file (i.e. sed).

The nature of flat configuration files where each application has its own 
format is such where recovery and/or applying changes only if they have 
not been already applied is too complex and hurts readability far to much 
to be attempted in a simple shell script.

Many applications have their own command line driven configuration 
utilities.  However each has their own oddities and complexities 
(authtool, gconftool-2, postconf etc...) Oddly enough out of all of the 
command line configuration tools I have used, I find gconftool-2 to be 
closest to The Right Way (TM), which is odd as it is by far one of the 
most complex syntax's to use (God help anyone who tries to make major 
edits to gnome xml files using sed) example:

"gconftool-2 --direct --config-source 
xml:readwrite:/etc/gconf/gconf.xml.mandator
y --type float --set /desktop/gnome/peripherals/mouse/motion_acceleration 1"

Even a complex (yet powerful) tool can meet the golden rule of "Make it as 
simple as possible but no simpler" when compared against a bunch of tools 
that are less powerful (and perhaps less complex when viewed in 
isolation).

It is my opinion that we as a community need to find a Better Way (tm) to 
manage configuration changes for Linux subsystems and applications. 
Everything should be a file, but that does not mean every configuration 
file needs to be formatted and managed differently.

In closing, a change this fundamental must be designed by the best minds 
and must have a strong champion for it to have a chance to succeed.  The 
Fedora community is likely the only Linux entity with the brain power and 
influence to address this issue.

Cheers,
Shane



From smooge at gmail.com  Sun Mar 26 04:32:30 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Sat, 25 Mar 2006 21:32:30 -0700
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
Message-ID: <80d7e4090603252032y5c90809asfbab97e52502edd3@mail.gmail.com>

On 3/25/06, Shane Stixrud <shane at geeklords.org> wrote:
> Greetings,
>

....

> I was recently tasked with standardizing/documenting our Linux server
> build/configuration process and as part of this process began training
> some of our Windows/Novell administrators to be able to carry out some of
> these basic tasks.  It was this second part of helping train people that
> caused me to examine and re-examine the processes I used for this
> standardization.
>
> My goal was simple in theory, I would use pxe+kickstart and enforce
> standard configurations and policies via a series of post scripts while
> attempting to keep readability, simplicity and supportability from a
> "non-unix guru" perspective as my guiding light (A wise man once said:
> Make it as simple as possible but no simpler).  For those interested an
> example of what I came up with it can be obtained here:
> http://geeklords.org/~shane/kickstart
>
> The process turned out to be not quite as simple as the theory but very
> educational none the less.  To start with I had a number of ways I could
> manipulate my fresh Linux install.
>
> 1) I could create a custom RPM that had all of the changes imbedded in
> config files and rpm scripts that merely overwrote the pre-existing ones.
> Problem being this approach hides the complexity of what all was being
> changed and why.
>
> 2) Use cfengine after the kickstart install.  This of course has some
> advantages over the rpm method but it also hides the same complexity and
> adds some of its own.
>

I am completely missing the point of this letter I realize.. but
doesnt your "The Right Way" also hide all the complex things too. It
either does that or removes a lot of functionality that some admin
needs to complete a job in a slightly different environment... which
means enforcing that everyone's enviromental needs matches what you
are laying out. I have to cover 8 different field environments and
tasks that require that the same tools do something slightly different
each time. Now I can build 8 versions of the same tool that reuses 90%
of the same code or I can increase the complexity of the each tool to
cover all cases.


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From shane at geeklords.org  Sun Mar 26 05:25:28 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Sat, 25 Mar 2006 21:25:28 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <80d7e4090603252032y5c90809asfbab97e52502edd3@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<80d7e4090603252032y5c90809asfbab97e52502edd3@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603252110460.8740@master.geeklords.org>

>
> I am completely missing the point of this letter I realize.. but
> doesnt your "The Right Way" also hide all the complex things too. It
> either does that or removes a lot of functionality that some admin
> needs to complete a job in a slightly different environment... which
> means enforcing that everyone's enviromental needs matches what you
> are laying out. I have to cover 8 different field environments and
> tasks that require that the same tools do something slightly different
> each time. Now I can build 8 versions of the same tool that reuses 90%
> of the same code or I can increase the complexity of the each tool to
> cover all cases.

I did not say gconftool-2 should be the the solution, only that it 
shows how a single tool can be very powerful when it has a standard file 
configuration file format to work with.  I am by no means 
advocating using xml as the standard configuration format, it is way over 
kill in my opinion.

Nothing is hidden by standardizing config files, I am not implying they 
should be hidden in a binary file.... nor am I implying they couldn't be 
edited with sed or vi although that would likely be inefficient when 
compared to using a tool designed to manage configuration data.

Please provide an example of how this would harm your ability to:
"cover 8 different field environments and tasks that require that the 
same tools do something slightly different each time"

Perhaps you are just confusing my story of what lead to my conclusions 
with my actual suggestion?


Cheers,
Shane



From buildsys at redhat.com  Sun Mar 26 08:51:02 2006
From: buildsys at redhat.com (Build System)
Date: Sun, 26 Mar 2006 03:51:02 -0500
Subject: rawhide report: 20060326 changes
Message-ID: <200603260851.k2Q8p2IF028447@porkchop.devel.redhat.com>

 

 
Updated Packages:

gnome-screensaver-2.14.0-2
--------------------------
* Sat Mar 25 2006 Ray Strode <rstrode at redhat.com> 2.14.0-2
- Add missing "c" to the word "Screensaver" in summary
  (bug 186711).

net-snmp-5.3-6
--------------
* Sat Mar 25 2006 Radek Vokal <rvokal at redhat.com> 5.3-6
- use net.ipv6.neigh.lo.retrans_time_ms (#186546)

openoffice.org-1:2.0.2-5.5.3
----------------------------
* Fri Mar 24 2006 Caolan McNamara <caolanm at redhat.com> - 1:2.0.2-5.5
- rh#186515# Keep draw and math launchers for mimetypes
- rh#186215#/ooo#63583# accessibility crasher in impress

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From paul at all-the-johnsons.co.uk  Sun Mar 26 09:57:48 2006
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 26 Mar 2006 10:57:48 +0100
Subject: OOo x86_64
Message-ID: <1143367068.3583.107.camel@T7.Linux>

Hi,

Any chance of a repo being set up for the very early testing version of
OOo x86_64?

TTFN

Paul
-- 
"ein zu starker starker Anblick kann Sie toten. Sie gegen gerade uber
den Rand mit dem festen Wissen des Wege vor Ihnen" - Linus Tordvals
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060326/922b6f16/attachment.sig>

From giallu at gmail.com  Sun Mar 26 10:04:20 2006
From: giallu at gmail.com (Gianluca Sforna)
Date: Sun, 26 Mar 2006 11:04:20 +0100
Subject: FC5 test3 udev hang
In-Reply-To: <44240511.1010404@redhat.com>
References: <d5ad21470603130013v57ebe748g75ced763f7fb5073@mail.gmail.com>
	<44240511.1010404@redhat.com>
Message-ID: <d5ad21470603260204t6bdd3eccqbb5320ae2d69cf1a@mail.gmail.com>

On 3/24/06, Harald Hoyer <harald at redhat.com> wrote:
> you may look at
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186164
> and test
> http://www.redhat.com/archives/fedora-test-list/2006-March/msg01542.html
>
oops... missed this reply until now :(

I will test again tomorrow (Monday): I left the laptop at office.

Thanks a lot for looking into this.



From giallu at gmail.com  Sun Mar 26 10:24:07 2006
From: giallu at gmail.com (Gianluca Sforna)
Date: Sun, 26 Mar 2006 11:24:07 +0100
Subject: FC5: first impressions
In-Reply-To: <1143239418.3802.233.camel@sundaram.pnq.redhat.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
Message-ID: <d5ad21470603260224h599e6d39sabea7d1b8836564f@mail.gmail.com>

On 3/24/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> > 0. Missing terminal on desktop menu... just kidding! :)
> >    You guys were right, I can live without it. Mea culpa.
>
> Good to see the hundreds of mails on the thread we had earlier wasn't
> entirely a waste. The release notes has information on bringing it back
> if you need it btw (yum install nautilus-open-terminal).

Not meant to be so picky... but I bringing it back this way it's not
_exactly_ back (i.e. 3rd instead of 1st).
Now, since who install the n-o-t package has probably a "need" for a
fast way of launching the terminal, do you think it is possible to
change the package so when I install it the menu item is the first?

For me, I will be adding a keyboard shortcut to terminal ASAP...


> > 1. Metacity's new window in the background
> >    I can not stress how big of a problem this is for me.
> >    I have used it since it was introduced, in the hope that
> >    I'll get used to it. I didn't. Not only it does the wrong
> >    thing for me in 90% of the cases, it also forces me to
> >    use the mouse a lot more, which is painful for me.
> >    A few google searches and browsing through GConf did not
> >    reveal a way of disabling it.
>
> We have a bug report open it. Upstream has tentatively agreed to make it
> a option disabled by default

Glad to know that :)

That is seriously impacting my work speed (which is already not so high..)

Cheers

Gianluca



From gilboad at gmail.com  Sun Mar 26 10:48:51 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 26 Mar 2006 12:48:51 +0200
Subject: FC5 weird raid issues
In-Reply-To: <442423F7.7060100@feuerpokemon.de>
References: <442423F7.7060100@feuerpokemon.de>
Message-ID: <1143370131.5480.0.camel@gilboa-work-dev>

On Fri, 2006-03-24 at 17:53 +0100, dragoran wrote:
> I have tryed to upgrade from FC4 -> FC5 using anaconda but it did not 
> detect my FC4 installation which is installed on /dev/md0.
> It tryes to add a non raid partition to the array and ignores the raid 
> partition. This causes the initalisation of md0 to fail.
> Is this a kernel or anaconda bug?
> Bug report:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312
> (no reply ...)
> So I backuped my data dan tryed a reinstall and it detected the md0 
> array in diskdruid but showed "foreign" as filesystem..
> did edit and set mount point to / and filesystem ext3
> but it failed formating it with a messages saying that it failed and 
> that I should press enter to reboot the system.
> What happend? How could such things happen with a *final* release? Raid 
> support seems broken and nobody has noticed.
> I always updated my system from RH9->FC1->FC2->FC3->FC4 (then 
> reinstalled FC4 because of i386->x86_64) but it seems that upgrade is no 
> more possible to FC5 :(
> 
> 
> 

I'd suggest you switch to console once Anaconda loads and mount the MD0
by hand.
It should give you a way to circumvent the bug. 

Gilboa



From dragoran at feuerpokemon.de  Sun Mar 26 09:51:58 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Sun, 26 Mar 2006 11:51:58 +0200
Subject: FC5 weird raid issues
In-Reply-To: <1143370131.5480.0.camel@gilboa-work-dev>
References: <442423F7.7060100@feuerpokemon.de>
	<1143370131.5480.0.camel@gilboa-work-dev>
Message-ID: <4426643E.10405@feuerpokemon.de>

Gilboa Davara wrote:
> On Fri, 2006-03-24 at 17:53 +0100, dragoran wrote:
>   
>> I have tryed to upgrade from FC4 -> FC5 using anaconda but it did not 
>> detect my FC4 installation which is installed on /dev/md0.
>> It tryes to add a non raid partition to the array and ignores the raid 
>> partition. This causes the initalisation of md0 to fail.
>> Is this a kernel or anaconda bug?
>> Bug report:
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312
>> (no reply ...)
>> So I backuped my data dan tryed a reinstall and it detected the md0 
>> array in diskdruid but showed "foreign" as filesystem..
>> did edit and set mount point to / and filesystem ext3
>> but it failed formating it with a messages saying that it failed and 
>> that I should press enter to reboot the system.
>> What happend? How could such things happen with a *final* release? Raid 
>> support seems broken and nobody has noticed.
>> I always updated my system from RH9->FC1->FC2->FC3->FC4 (then 
>> reinstalled FC4 because of i386->x86_64) but it seems that upgrade is no 
>> more possible to FC5 :(
>>
>>
>>
>>     
>
> I'd suggest you switch to console once Anaconda loads and mount the MD0
> by hand.
> It should give you a way to circumvent the bug. 
>
> Gilboa
>
>   
I just deleted the raid and recreated it and now it seems to work fine.
(running FC5 with md raid now).
But the bug still needs to be fixed.
But I don't like to reinstall FC6 when its out upgrade from raid should 
work as it did before FC5.



From rmy at tigress.co.uk  Sun Mar 26 11:18:44 2006
From: rmy at tigress.co.uk (Ron Yorston)
Date: Sun, 26 Mar 2006 12:18:44 +0100 (BST)
Subject: FC5: first impressions
Message-ID: <200603261118.k2QBIiJc018557@tiffany.internal.tigress.co.uk>

Gianluca Sforna wrote:
>On 3/24/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>> > 1. Metacity's new window in the background
>> >    I can not stress how big of a problem this is for me.
>> >    I have used it since it was introduced, in the hope that
>> >    I'll get used to it. I didn't. Not only it does the wrong
>> >    thing for me in 90% of the cases, it also forces me to
>> >    use the mouse a lot more, which is painful for me.
>> >    A few google searches and browsing through GConf did not
>> >    reveal a way of disabling it.
>>
>> We have a bug report open it. Upstream has tentatively agreed to make it
>> a option disabled by default
>
>Glad to know that :)
>
>That is seriously impacting my work speed (which is already not so high..)

If anyone needs a pre-release version of metacity with configurable new
window focus I have it here:

   http://intgat.tigress.co.uk/rmy/metacity/fc5.html

Ron



From dragoran at feuerpokemon.de  Sun Mar 26 10:31:38 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Sun, 26 Mar 2006 12:31:38 +0200
Subject: FC5: first impressions
In-Reply-To: <200603261118.k2QBIiJc018557@tiffany.internal.tigress.co.uk>
References: <200603261118.k2QBIiJc018557@tiffany.internal.tigress.co.uk>
Message-ID: <44266D8A.7090201@feuerpokemon.de>

Ron Yorston wrote:
> Gianluca Sforna wrote:
>   
>> On 3/24/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>>     
>>>> 1. Metacity's new window in the background
>>>>    I can not stress how big of a problem this is for me.
>>>>    I have used it since it was introduced, in the hope that
>>>>    I'll get used to it. I didn't. Not only it does the wrong
>>>>    thing for me in 90% of the cases, it also forces me to
>>>>    use the mouse a lot more, which is painful for me.
>>>>    A few google searches and browsing through GConf did not
>>>>    reveal a way of disabling it.
>>>>         
>>> We have a bug report open it. Upstream has tentatively agreed to make it
>>> a option disabled by default
>>>       
>> Glad to know that :)
>>
>> That is seriously impacting my work speed (which is already not so high..)
>>     
>
> If anyone needs a pre-release version of metacity with configurable new
> window focus I have it here:
>
>    http://intgat.tigress.co.uk/rmy/metacity/fc5.html
>
> Ron
>
>   

also the new mount stuff is a anoying...
mounted fat harddiks are not shown in computer:// and in the gtk file 
selector; those worked fine in FC4. Is this because fstab is no longer 
used by gnome? If it does not want to use fstab its fine but why only 
show removeable media but not harddisks?



From n0dalus+redhat at gmail.com  Sun Mar 26 11:47:54 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Sun, 26 Mar 2006 22:17:54 +1030
Subject: FC5: first impressions
In-Reply-To: <200603261118.k2QBIiJc018557@tiffany.internal.tigress.co.uk>
References: <200603261118.k2QBIiJc018557@tiffany.internal.tigress.co.uk>
Message-ID: <6280325c0603260347l6780af9bt1bdf320be2bf743a@mail.gmail.com>

On 3/26/06, Ron Yorston <rmy at tigress.co.uk> wrote:
>
> If anyone needs a pre-release version of metacity with configurable new
> window focus I have it here:
>
>    http://intgat.tigress.co.uk/rmy/metacity/fc5.html
>

I'd be curious to see a description of how each behaviour acts. I know
some of the behaviours are listed on the Gnome bugzilla but there's a
lot to read there.

I think other people would also be curious about what different
focusing styles exist in Gnome or will exist.

Any information appreciated,
n0dalus.



From rmy at tigress.co.uk  Sun Mar 26 12:14:01 2006
From: rmy at tigress.co.uk (Ron Yorston)
Date: Sun, 26 Mar 2006 13:14:01 +0100 (BST)
Subject: FC5: first impressions
Message-ID: <200603261214.k2QCE1ON018688@tiffany.internal.tigress.co.uk>

n0dalus wrote:
>On 3/26/06, Ron Yorston <rmy at tigress.co.uk> wrote:
>>
>> If anyone needs a pre-release version of metacity with configurable new
>> window focus I have it here:
>>
>>    http://intgat.tigress.co.uk/rmy/metacity/fc5.html
>>
>
>I'd be curious to see a description of how each behaviour acts. I know
>some of the behaviours are listed on the Gnome bugzilla but there's a
>lot to read there.
>
>I think other people would also be curious about what different
>focusing styles exist in Gnome or will exist.

My patch currently has two settings:  "smart" which is the pre-2.14
behaviour and "strict" which enables the experimental strict focus
approximation mode.  (Neither of these is a particularly good name,
as the smart mode isn't really smart and the strict mode isn't really
strict.)

The smart mode simply applies the user's current focus policy to new
windows.  So if you're using focus follows mouse and the new window
appears at your mouse position it gets focus.  Some people don't like
this and claim it can be dangerous.

The experimental strict focus approximation mode tries to prevent
windows started from a hardcoded list of terminals from getting focus.
In part it does this by putting the new window underneath the terminal,
which lots of people find objectionable.

In the GNOME Bugzilla Elijah Newren has suggested additional modes
which might be called "always" and "never", though these haven't been
implemented yet.  I guess that "always" would force the new window always
to have focus while "never" would never give focus to new windows.  This
latter is what some people would call "strict".

All of these modes apply an additional layer of behaviour beyond what you
currently get with the click/mouse/sloppy focus modes (and are independent
of those modes).

Ron



From sundaram at fedoraproject.org  Sun Mar 26 13:19:48 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 26 Mar 2006 18:49:48 +0530
Subject: pup uncheck all
In-Reply-To: <4425A502.2090903@gmail.com>
References: <4425A502.2090903@gmail.com>
Message-ID: <1143379188.3802.313.camel@sundaram.pnq.redhat.com>

On Sat, 2006-03-25 at 15:16 -0500, Eric Mesa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Pup sorely needs an uncheck-all button.  Right now I have a few
> packages that keep messing the whole process up since they depend on
> Xorg6 (since the packagers haven't updated the specs yet) so it's
> quite tedious to uncheck every single box that won't work.

Use http://bugzilla.redhat.com to file a RFE.

Rahul



From billcrawford1970 at gmail.com  Sun Mar 26 14:20:41 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Sun, 26 Mar 2006 14:20:41 +0000
Subject: FC5: first impressions
In-Reply-To: <1b2301c64f94$b7a473c0$b6491b31@td612671>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
Message-ID: <200603261520.43696.billcrawford1970@googlemail.com>

On Friday 24 March 2006 22:45, Dimi Paun wrote:

> What means "disabled by default"? I hope we get the old behaviour
> by default :)

 I'd like to see "open underneath" disappear, but I really do not want the old 
behaviour back in full - "focus stealing" is really, really necessary. 
However much people say they don't need / want it, you don't want to end up 
typing your root password into e.g. an IM window that suddenly pops up in 
front of you.

 Likewise if I open something from a command line, I often do want in fact to 
run some other command there afterwards (even if it's just because I want to 
open several gui apps). Having to focus the app you're going to use isn't 
that much of a problem if it's opened on top; it's the opened-underneath 
that's making it difficult to focus it (I have to go to the taskbar at the 
bottom of the screen, for example). I'd rather see it open on top, but NOT 
take focus by default.

> <offtopic flamewar="false" excuse="friday">
> Anyway, I think these are the kind of changes that irk people a
> lot as far as GNOME approach to usability goes: experimental
> behavior that is highly subjective, which is being forced onto
> the masses with no way of opting out.

 True enough, but the focus stealing prevention is something that's been 
needed for a long time. The problem is the wrong solution, not that it's 
experimental or whatever. If they'd got it completely right, you wouldn't be 
saying "this is great, but how dare you foist it on me" would you? ;)

 That said, the GNOME attitude does suck. :D



From billcrawford1970 at gmail.com  Sun Mar 26 14:28:37 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Sun, 26 Mar 2006 14:28:37 +0000
Subject: FC5: first impressions
In-Reply-To: <1b7901c64fa0$7bab8dc0$b6491b31@td612671>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143242499.3802.260.camel@sundaram.pnq.redhat.com>
	<1b7901c64fa0$7bab8dc0$b6491b31@td612671>
Message-ID: <200603261528.38034.billcrawford1970@googlemail.com>

On Saturday 25 March 2006 00:10, Dimi Paun wrote:

> Great. This makes me very happy. Even using Eclipse is a pain
> with this "feature". Every time you check stuff in, Eclipse
> opens a dialog for the changelog. Well, this dialog doesn't
> have the focus, requiring me to do yet another action to bring
> in focus before I can type! Nothing to do with terminals BTW.

 If the main app is already focussed, the focussing a dialog is fine. However 
in the past the behaviour has been for dialogs popping up to get focus 
always, and seriously, having typed most of a root password into a popup (and 
fortunately stopped before hitting RETURN) ... I have to say that that sucks 
and should not happen.

 Again, it's something that probably seems irrelevant UNTIL IT HAPPENS TO YOU.

> Well, yeah. But his motivation is mainly that apps are slow to load.
> The fix is to make them faster, not allow people to do something for
> 6 more secs until they start. It's just the wrong fix. And besides,
> what can you do meaningfully in a few secs? This actually _extends_
> the time significantly as it will take you a few seconds to manually
> regain focus.

 And if you *do* want to open more than one thing from a terminal it takes 
even longer.

 If you're using the One True Focus Method (sloppy mouse) all you have to do 
is move the mouse over the app when it appears (or alt-tab).

 If the app that appears is a gui one, you're likely to be using the mouse 
anyway, so having to move it over the app isn't really an issue, is it?

 Again, please let me stress that I primarily agree with you - popunder is 
even more annoying.



From dimi at lattica.com  Sun Mar 26 14:43:53 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 26 Mar 2006 09:43:53 -0500
Subject: FC5: first impressions
In-Reply-To: <200603261520.43696.billcrawford1970@googlemail.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
Message-ID: <1143384233.15323.16.camel@dimi>

On Sun, 2006-03-26 at 14:20 +0000, Bill Crawford wrote:
>  True enough, but the focus stealing prevention is something that's
> been needed for a long time. 

Not for me, it hasn't. I know for sure I don't want it.
The typing-the-root-password-in-the-newly-opened-im-client
scenario doesn't keep me up at night. In fact, it's a 
non-issue for me.

But more importantly, I don't understand why people are
harping on the terminal use case. My particular complaint
applies to the entire desktop -- when I start any app (say
from the GNOME menu), it does not get the focus! It is
started in the background with a flashing button in the
task bar.

This behavior simply does the wrong thing for me in more than
90% of the time. In fact, I can't remember the last time
that I wanted to "continue my work" between when I clicked
on an icon, and the app started. This seems to be a dorky
fix for some apps taking to long to start. Let's make them
start faster, that what people want anyway.

To add insult to injury, this behavior is making life a lot
worse for people (like me) that try to avoid (as much as
possible) the use of the mouse.

If I start an app, it means that I want to use it _now_.
Don't make me ask for it 2-3 times. In the unlikely case
when I don't, a quick Alt-TAB solves the problem. If this
is still not obvious to people, here's a quick comparison:
  Focus Stealing:
    -- >90% of time it does the right thing
    -- <10% the fix is a sub-second Alt-TAB, no mouse
  Manual Focus
    -- >90% you have to use >1sec to gain the focus with the mouse
    -- <10% you don't have to do anything

If you still prefer the manual focus, all power to you, but
that shouldn't be the default behavior. Let's just stick to
the principle of least surprise here folks, we would make a
lot of people happy.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From nicolas.mailhot at laposte.net  Sun Mar 26 14:55:48 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 26 Mar 2006 16:55:48 +0200
Subject: FC5: first impressions
In-Reply-To: <1143384233.15323.16.camel@dimi>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
Message-ID: <1143384948.2816.3.camel@rousalka.dyndns.org>

Le dimanche 26 mars 2006 ? 09:43 -0500, Dimi Paun a ?crit :
> On Sun, 2006-03-26 at 14:20 +0000, Bill Crawford wrote:
> >  True enough, but the focus stealing prevention is something that's
> > been needed for a long time. 
> 
> Not for me, it hasn't. I know for sure I don't want it.
> The typing-the-root-password-in-the-newly-opened-im-client
> scenario doesn't keep me up at night. In fact, it's a 
> non-issue for me.

Has anyone ever tried something like "if current window has been
receiving keypresses in the last x ms do not steal focus from it?"

The main problem seems to be the race between the system showing up a
new window and the user realising the new window has stealed the focus,
so why not just refrain from taking the focus if something is being done
in the current window ?

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

From wrrhdev at riede.org  Sun Mar 26 15:06:42 2006
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 26 Mar 2006 10:06:42 -0500
Subject: FC5: first impressions
In-Reply-To: <1143384233.15323.16.camel@dimi> (from dimi@lattica.com on Sun
	Mar 26 09:43:53 2006)
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
Message-ID: <1143385602l.19620l.3l@athena.riede.org>

On 03/26/2006 09:43:53 AM, Dimi Paun wrote:
> On Sun, 2006-03-26 at 14:20 +0000, Bill Crawford wrote:
> >  True enough, but the focus stealing prevention is something that's
> > been needed for a long time.
> Not for me, it hasn't. I know for sure I don't want it.
> The typing-the-root-password-in-the-newly-opened-im-client
> scenario doesn't keep me up at night. In fact, it's anon-issue for me.
> 
> But more importantly, I don't understand why people are
> harping on the terminal use case. My particular complaint
> applies to the entire desktop -- when I start any app (say
> from the GNOME menu), it does not get the focus! It is
> started in the background with a flashing button in the
> task bar.
> 
> This behavior simply does the wrong thing for me in more than
> 90% of the time. In fact, I can't remember the last time
> that I wanted to "continue my work" between when I clicked
> on an icon, and the app started. This seems to be a dorky
> fix for some apps taking to long to start. Let's make them
> start faster, that what people want anyway.
> 
> To add insult to injury, this behavior is making life a lot
> worse for people (like me) that try to avoid (as much as
> possible) the use of the mouse.
> 
> If I start an app, it means that I want to use it _now_.

Well, that's just your opinion. Mine is different. Sometimes I see a link in a  
mail that I want to follow up on later. I don't need firefox jumping in my  
face. Or a mail has an attachment I need to read - eventually. I'll open it  
with openoffice so I don't forget. But I don't want its splash screen nor  
window visible now.

So there are different use cases, and at least an option will allow people to  
select the behavior that best fits them. FWIW I'm not convinced the ideal  
algorithm has been discovered, or is even possible, as if you ask me to define  
when I want a new window to come up with focus and when not, the answer is  
"that depends on what I want to do with it"...

Regards, Willem Riede.



From jon.nettleton at gmail.com  Sun Mar 26 15:21:08 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Sun, 26 Mar 2006 10:21:08 -0500
Subject: FC5: first impressions
In-Reply-To: <1143384948.2816.3.camel@rousalka.dyndns.org>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143384948.2816.3.camel@rousalka.dyndns.org>
Message-ID: <1143386468.12912.17.camel@averatec>

On Sun, 2006-03-26 at 16:55 +0200, Nicolas Mailhot wrote:
> Le dimanche 26 mars 2006 ? 09:43 -0500, Dimi Paun a ?crit :
> > On Sun, 2006-03-26 at 14:20 +0000, Bill Crawford wrote:
> > >  True enough, but the focus stealing prevention is something that's
> > > been needed for a long time. 
> > 
> > Not for me, it hasn't. I know for sure I don't want it.
> > The typing-the-root-password-in-the-newly-opened-im-client
> > scenario doesn't keep me up at night. In fact, it's a 
> > non-issue for me.
> 
> Has anyone ever tried something like "if current window has been
> receiving keypresses in the last x ms do not steal focus from it?"
> 
> The main problem seems to be the race between the system showing up a
> new window and the user realising the new window has stealed the focus,
> so why not just refrain from taking the focus if something is being done
> in the current window ?
> 
I brought up using that behavior some time after Test 3 was released.
It was met with the typical, "Having inconsistent window focus will just
confuse the users more".  I know that when I launch an application I
automatically expect it to show up in the background.  

I think the check for keypresses/mouse clinks between application launch
and it being drawn on screen makes a much more logical interaction with
the desktop.  If you ask your secretary to get you a file, and then you
start working on something else, she doesn't just come over and drop it
right in front of you.  If you ask your secretary to get you a file, and
then you sit there twiddling your fingers, she will probably hand it
right to you so you can start working on it.

Metacity already has an algorithm that somewhat tries to implement this
with the intervening_user_event_occurred function.  I don't think that
this is working quite right.  I spent some initial time working on it,
but then got side tracked.  I would be more than happy to pick this back
up if there is any interest in people testing this behavior and seeing
if it is natural, or too confusing.

Jon



From jspaleta at gmail.com  Sun Mar 26 15:52:04 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 26 Mar 2006 10:52:04 -0500
Subject: FC5: first impressions
In-Reply-To: <1143386468.12912.17.camel@averatec>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143384948.2816.3.camel@rousalka.dyndns.org>
	<1143386468.12912.17.camel@averatec>
Message-ID: <604aa7910603260752ic0e3ec9s2dbddef1849fa222@mail.gmail.com>

On 3/26/06, Jon Nettleton <jon.nettleton at gmail.com> wrote:
>  I know that when I launch an application I
> automatically expect it to show up in the background.

yes launching mplayer in fullscreen mode from a terminal... its
inconceivable why anyone would want mplayer to actuall go fullscreen.
It makes so much more sense for the mplayer window, which was
deliberately requested to be in fullscreen with a cmdline argument to
load behind my terminal and the gnome-panels as well.  It's so simple
and intuitive to have to click on that fullscreen requested mplayer
window, not once.. but twice (to bring it above the terminal and the
gnome-panel objects) to have it in the foreground like it would when
called from pretty much anything other than gnome-terminal.

What I really really love.. is when the entire window for the
application you just lauched is covered by the lauching terminal. 
Even better when that completely obscured window is a dialog with a
timer action. I wonder, are any of those new fangled keyboard focus
stealing password dialogs affected by the pop-under behavior? Wouldn't
that be funny... a password dialog that you can't see which forcibly
steals keyboard focus for security reasons.. sitting under your
terminal window which forcibly causes new windows to pop-under for
usability reasons.. Does that count as ironic.. or is it just tragic?

-jef"of course with hardware accelerated bling with true transparency
in the terminal and the panel... I guess I'd never notice if the
mplayer window was behind those objects and I could watch my pr0n
without having to lift a finger once it started"spaleta



From nicolas.mailhot at laposte.net  Sun Mar 26 16:05:46 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 26 Mar 2006 18:05:46 +0200
Subject: GUI controls for instrumentation
In-Reply-To: <4425324F.9070903@yahoo.co.uk>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
	<442529EB.2040004@yahoo.co.uk>
	<1143287487.8838.4.camel@rousalka.dyndns.org>
	<4425324F.9070903@yahoo.co.uk>
Message-ID: <1143389147.2816.6.camel@rousalka.dyndns.org>

Le samedi 25 mars 2006 ? 12:06 +0000, Dariusz J. Garbowski a ?crit :
> .
> But I can see that in some environments Java on the desktop may be a 
> support issue.

Java is only write-once, run everywhere if you define everywhere as a
very specific static OS image :(

If you have 100% control of the systems and can deploy a single
controlled jvm everywhere, yes java-on-desktop is doable

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

From fedora at camperquake.de  Sun Mar 26 16:15:57 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 26 Mar 2006 18:15:57 +0200
Subject: GUI controls for instrumentation
In-Reply-To: <1143389147.2816.6.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
	<442529EB.2040004@yahoo.co.uk>
	<1143287487.8838.4.camel@rousalka.dyndns.org>
	<4425324F.9070903@yahoo.co.uk>
	<1143389147.2816.6.camel@rousalka.dyndns.org>
Message-ID: <20060326181557.68fcfc46@lain>

Hi.

On Sun, 26 Mar 2006 18:05:46 +0200, Nicolas Mailhot wrote

> If you have 100% control of the systems and can deploy a single
> controlled jvm everywhere, yes java-on-desktop is doable

If you have 100% control of the systems _every_ language is
write-once-run-anywhere. Even BASIC.



From jon.nettleton at gmail.com  Sun Mar 26 16:28:14 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Sun, 26 Mar 2006 11:28:14 -0500
Subject: FC5: first impressions
In-Reply-To: <604aa7910603260752ic0e3ec9s2dbddef1849fa222@mail.gmail.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143384948.2816.3.camel@rousalka.dyndns.org>
	<1143386468.12912.17.camel@averatec>
	<604aa7910603260752ic0e3ec9s2dbddef1849fa222@mail.gmail.com>
Message-ID: <1143390495.12912.21.camel@averatec>

On Sun, 2006-03-26 at 10:52 -0500, Jeff Spaleta wrote:
> On 3/26/06, Jon Nettleton <jon.nettleton at gmail.com> wrote:
> >  I know that when I launch an application I
> > automatically expect it to show up in the background.
> 
> yes launching mplayer in fullscreen mode from a terminal... its
> inconceivable why anyone would want mplayer to actuall go fullscreen.
> It makes so much more sense for the mplayer window, which was
> deliberately requested to be in fullscreen with a cmdline argument to
> load behind my terminal and the gnome-panels as well.  It's so simple
> and intuitive to have to click on that fullscreen requested mplayer
> window, not once.. but twice (to bring it above the terminal and the
> gnome-panel objects) to have it in the foreground like it would when
> called from pretty much anything other than gnome-terminal.
> 
> What I really really love.. is when the entire window for the
> application you just lauched is covered by the lauching terminal. 
> Even better when that completely obscured window is a dialog with a
> timer action. I wonder, are any of those new fangled keyboard focus
> stealing password dialogs affected by the pop-under behavior? Wouldn't
> that be funny... a password dialog that you can't see which forcibly
> steals keyboard focus for security reasons.. sitting under your
> terminal window which forcibly causes new windows to pop-under for
> usability reasons.. Does that count as ironic.. or is it just tragic?
> 
> -jef"of course with hardware accelerated bling with true transparency
> in the terminal and the panel... I guess I'd never notice if the
> mplayer window was behind those objects and I could watch my pr0n
> without having to lift a finger once it started"spaleta

Now that is thinking outside the box.  When you launch an application it
opens behind your existing window, however the windows in front of it go
semi-transparent.  bwahahahaha 



From dimi at lattica.com  Sun Mar 26 16:34:57 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 26 Mar 2006 11:34:57 -0500 (EST)
Subject: FC5: first impressions
In-Reply-To: <1143385602l.19620l.3l@athena.riede.org>
References: <1a2301c64f86$283ce810$b6491b31@td612671><1143239418.3802.233.camel@sundaram.pnq.redhat.com><1b2301c64f94$b7a473c0$b6491b31@td612671><200603261520.43696.billcrawford1970@googlemail.com><1143384233.15323.16.camel@dimi>
	<1143385602l.19620l.3l@athena.riede.org>
Message-ID: <1767.69.194.157.31.1143390897.squirrel@lattica.com>


On Sun, March 26, 2006 10:06 am, Willem Riede said:
> So there are different use cases, and at least an option will allow people
> to select the behavior that best fits them. FWIW I'm not convinced the
ideal
> algorithm has been discovered, or is even possible, as if you ask me to
> define when I want a new window to come up with focus and when not, the
> answer is "that depends on what I want to do with it"...

This is the crux of the issue: this problem does not have an obvious
correct solution. A normal approach would be "do no evil". That is,
there should be a hysteresis against changing well known behavior that
is tried, tested, and true. Experimental stuff like this should be
introduced gradually, with default to off, and only when it has been
proven in the field we may turn it on by default.

<offtopic>
Don't people find it funny that we, as a community, know all about
incremental improvements when it comes to patch management, but we behave
like righteous a--holes when it comes to imposing what we believe to be
the Right Way (TM) onto others? And hey, since we can now invoke the
Usability Principle, we are in the right to remove any way for the
luser to opt-out of our One True Way.

But I digress, we are not the target audience...
</offtopic>

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From jspaleta at gmail.com  Sun Mar 26 16:43:21 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 26 Mar 2006 11:43:21 -0500
Subject: FC5: first impressions
In-Reply-To: <1143390495.12912.21.camel@averatec>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143384948.2816.3.camel@rousalka.dyndns.org>
	<1143386468.12912.17.camel@averatec>
	<604aa7910603260752ic0e3ec9s2dbddef1849fa222@mail.gmail.com>
	<1143390495.12912.21.camel@averatec>
Message-ID: <604aa7910603260843r107976c2of2dccc72813400a6@mail.gmail.com>

On 3/26/06, Jon Nettleton <jon.nettleton at gmail.com> wrote:
> Now that is thinking outside the box.  When you launch an application it
> opens behind your existing window, however the windows in front of it go
> semi-transparent.  bwahahahaha

That's pretty much the only good workflow reason i've seen to have
that sort of transparency in a desktop. If window pop unders are going
to be encouraged.. there needs to be a visibly obvious way to annouce
that the window exists and is indeed under an existing window. Having
the window on top go just transparent enough for some reasonable
amount of time to make you aware that a new window has appeared would
definitely address my most salient of concerns without regard to
window pop unders.  The window list on the panel simply does not
suffice: windows can be groups in the list making difficult to notice
that a new window in that group has been created and the panel can be
hidden so that you are not actually seeing the window list applet.

-jef



From seanlkml at sympatico.ca  Sun Mar 26 16:48:13 2006
From: seanlkml at sympatico.ca (sean)
Date: Sun, 26 Mar 2006 11:48:13 -0500
Subject: FC5: first impressions
In-Reply-To: <1767.69.194.157.31.1143390897.squirrel@lattica.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143385602l.19620l.3l@athena.riede.org>
	<1767.69.194.157.31.1143390897.squirrel@lattica.com>
Message-ID: <BAYC1-PASMTP11BFC1FC3A776F59D68C13AEDD0@CEZ.ICE>

On Sun, 26 Mar 2006 11:34:57 -0500 (EST)
"Dimi Paun" <dimi at lattica.com> wrote:

> This is the crux of the issue: this problem does not have an obvious
> correct solution. A normal approach would be "do no evil". That is,
> there should be a hysteresis against changing well known behavior that
> is tried, tested, and true. Experimental stuff like this should be
> introduced gradually, with default to off, and only when it has been
> proven in the field we may turn it on by default.

Assuming that the developers believed they did have the correct 
solution they followed a reasonable course.   Well, there should
have been an easy way to turn it off, but otherwise it was fine.

> <offtopic>
> Don't people find it funny that we, as a community, know all about
> incremental improvements when it comes to patch management, but we behave
> like righteous a--holes when it comes to imposing what we believe to be
> the Right Way (TM) onto others? And hey, since we can now invoke the
> Usability Principle, we are in the right to remove any way for the
> luser to opt-out of our One True Way.
> 
> But I digress, we are not the target audience...
> </offtopic>

The more experimental kernel trees (eg. -mm) often ship wildly 
speculative features forced on just to get wider testing.   It is
easy to argue that Fedora is similiar in spirit in the distro space.

That said, I hate this feature and am willing to participate in any
public lynching of those who foisted it on us.

Sean

P.S.  By the way, I only see this behavior from gnome-terminal, not the
      menu or xterm like you seem to be seeing.



From seanlkml at sympatico.ca  Sun Mar 26 16:52:29 2006
From: seanlkml at sympatico.ca (sean)
Date: Sun, 26 Mar 2006 11:52:29 -0500
Subject: FC5: first impressions
In-Reply-To: <604aa7910603260843r107976c2of2dccc72813400a6@mail.gmail.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143384948.2816.3.camel@rousalka.dyndns.org>
	<1143386468.12912.17.camel@averatec>
	<604aa7910603260752ic0e3ec9s2dbddef1849fa222@mail.gmail.com>
	<1143390495.12912.21.camel@averatec>
	<604aa7910603260843r107976c2of2dccc72813400a6@mail.gmail.com>
Message-ID: <BAYC1-PASMTP082C78C6FBBE7FEAEF1D5EAEDD0@CEZ.ICE>

On Sun, 26 Mar 2006 11:43:21 -0500
"Jeff Spaleta" <jspaleta at gmail.com> wrote:

> That's pretty much the only good workflow reason i've seen to have
> that sort of transparency in a desktop. If window pop unders are going
> to be encouraged.. there needs to be a visibly obvious way to annouce
> that the window exists and is indeed under an existing window. Having
> the window on top go just transparent enough for some reasonable
> amount of time to make you aware that a new window has appeared would
> definitely address my most salient of concerns without regard to
> window pop unders.  The window list on the panel simply does not
> suffice: windows can be groups in the list making difficult to notice
> that a new window in that group has been created and the panel can be
> hidden so that you are not actually seeing the window list applet.
> 

Well you make a good point and it could really be extended to the 
general case of causing enough transparency for the user to observe
any important notification or event on an obscured window.  

For example if your mail client is obscured and a new inbox item arrives
it would be handy to catch a quick glimpse of the senders name.   The
obscuring windows could become transparent for a moment and then 
return to full opacity.

Sean



From thuforuk at yahoo.co.uk  Sun Mar 26 16:58:39 2006
From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski)
Date: Sun, 26 Mar 2006 17:58:39 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <1143389147.2816.6.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>	<200603242033.03945.lamont@gurulabs.com>	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>	<1143281498.4018.6.camel@rousalka.dyndns.org>	<44251FC4.3070207@yahoo.co.uk>	<1143284362.4018.14.camel@rousalka.dyndns.org>	<442529EB.2040004@yahoo.co.uk>	<1143287487.8838.4.camel@rousalka.dyndns.org>	<4425324F.9070903@yahoo.co.uk>
	<1143389147.2816.6.camel@rousalka.dyndns.org>
Message-ID: <4426C83F.5060300@yahoo.co.uk>

On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
> Le samedi 25 mars 2006 ? 12:06 +0000, Dariusz J. Garbowski a ?crit :
>> .
>> But I can see that in some environments Java on the desktop may be a 
>> support issue.
> 
> Java is only write-once, run everywhere if you define everywhere as a
> very specific static OS image :(

Come to think of that... Any multi-platform, multi-os or even 
multi-distro (where w95/w98/w2k/wxp can be called "distro" for the 
purpose of this argument) will suffer from mentioned support issues:

- different libraries available
- differnt environment
- etc...

This is why commercial applications are most of the time officially 
supported only on limited number of platforms, be it w2k/2xp and not 
w95/w98, be it Red Hat Enterprise and SuSE but not Debian and Mandrake, 
etc. :( There comes community help :-)

Regards,
Dariusz

	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com



From seg at haxxed.com  Sun Mar 26 17:22:51 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 26 Mar 2006 11:22:51 -0600
Subject: FC5: first impressions
In-Reply-To: <200603261520.43696.billcrawford1970@googlemail.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
Message-ID: <1143393771.10632.9.camel@localhost>

On Sun, 2006-03-26 at 14:20 +0000, Bill Crawford wrote:
>  I'd like to see "open underneath" disappear, but I really do not want the old 
> behaviour back in full - "focus stealing" is really, really necessary. 
> However much people say they don't need / want it, you don't want to end up 
> typing your root password into e.g. an IM window that suddenly pops up in 
> front of you.

I could have sworn this all got fixed and worked great in FC4. What
happened?

Yes, I *have* typed passwords into IM windows back before FC4...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060326/a342361a/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Sun Mar 26 17:18:51 2006
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sun, 26 Mar 2006 19:18:51 +0200
Subject: Anaconda: good work!
In-Reply-To: <20060322154706.GA16944@jadzia.bu.edu> (Matthew Miller's message
	of "Wed, 22 Mar 2006 10:47:06 -0500")
References: <131501c64dc2$fe1522b0$b6491b31@td612671>
	<20060322154706.GA16944@jadzia.bu.edu>
Message-ID: <8764m115vo.fsf@kosh.bigo.ensc.de>

mattdm at mattdm.org (Matthew Miller) writes:

>>   * External links in Release Notes are confusing
>>     These can't possibly work, it would be nice if we
>>     can disable them to avoid confusion.
>
> Why can't they possibly work?

afaik, proxy setup (which is required for external links) will be done
_after_ installation.



Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 478 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060326/67cfdb13/attachment.sig>

From jdesbonnet at gmail.com  Sun Mar 26 17:19:02 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sun, 26 Mar 2006 18:19:02 +0100
Subject: Hardware detection problems on laptops -- how to file a report?
Message-ID: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>

Am I right in saying there has been substantial changes to the way in
which hardware  detected works in FC5? (I see from the release notes 
PCMCIA handling has changed and kudzu has been deprecated).  I have
prepared a report of my (not good) experience with a Thinkpad T41p,
but right now there is very little hard data in there which can be
used for debugging.

Any advice how to file a useful report about hardware that did work
with FC4 and does not work with FC5?

Also: I was thinking about the testing of the install install process
prior to the final release. Since many people cannot afford the space
to have a spare partition for test releases (especially on laptops)
and it is not possible to install to a USB drive, it would be useful
to have some sort bootable live-CD with just enough software to test
the hardware detection.  Eg something like the Windows Device Explorer
program. If I had something like that during the test phase I would
have caught all these problems a long time ago. (I did all my testing
in a virtual VMWare environment -- and it works great there!).

Joe.



From nicolas.mailhot at laposte.net  Sun Mar 26 17:27:20 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 26 Mar 2006 19:27:20 +0200
Subject: GUI controls for instrumentation
In-Reply-To: <4426C83F.5060300@yahoo.co.uk>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
	<442529EB.2040004@yahoo.co.uk>
	<1143287487.8838.4.camel@rousalka.dyndns.org>
	<4425324F.9070903@yahoo.co.uk>
	<1143389147.2816.6.camel@rousalka.dyndns.org>
	<4426C83F.5060300@yahoo.co.uk>
Message-ID: <1143394041.2816.10.camel@rousalka.dyndns.org>

Le dimanche 26 mars 2006 ? 17:58 +0100, Dariusz J. Garbowski a ?crit :
> On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
> > Le samedi 25 mars 2006 ? 12:06 +0000, Dariusz J. Garbowski a ?crit :
> >> .
> >> But I can see that in some environments Java on the desktop may be a 
> >> support issue.
> > 
> > Java is only write-once, run everywhere if you define everywhere as a
> > very specific static OS image :(
> 
> Come to think of that... Any multi-platform, multi-os or even 
> multi-distro (where w95/w98/w2k/wxp can be called "distro" for the 
> purpose of this argument) will suffer from mentioned support issues

Sure, but other software communities recognize the problem and try to
create tools to ease the pain. Sun java is unfortunately often in denial
and lala-lala land when you try to tell them there is a wide margin
between write once and run everywhere in the actual world

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

From jspaleta at gmail.com  Sun Mar 26 18:05:24 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 26 Mar 2006 13:05:24 -0500
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
Message-ID: <604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>

On 3/26/06, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
> Am I right in saying there has been substantial changes to the way in
> which hardware  detected works in FC5? (I see from the release notes
> PCMCIA handling has changed and kudzu has been deprecated).  I have
> prepared a report of my (not good) experience with a Thinkpad T41p,
> but right now there is very little hard data in there which can be
> used for debugging.

What specifically are you talking about... general comments about
"hardware not working" are difficult to respond to.

>
> Any advice how to file a useful report about hardware that did work
> with FC4 and does not work with FC5?

First be specific as to which hardware you are concerned about and
what specific funtionality you want other people to attempt to confirm
on this list.

-jef



From dcbw at redhat.com  Sun Mar 26 18:29:42 2006
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 26 Mar 2006 13:29:42 -0500
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
Message-ID: <1143397783.10857.6.camel@localhost.localdomain>

On Sun, 2006-03-26 at 18:19 +0100, Joe Desbonnet wrote:
> Am I right in saying there has been substantial changes to the way in
> which hardware  detected works in FC5? (I see from the release notes 
> PCMCIA handling has changed and kudzu has been deprecated).  I have
> prepared a report of my (not good) experience with a Thinkpad T41p,
> but right now there is very little hard data in there which can be
> used for debugging.
> 
> Any advice how to file a useful report about hardware that did work
> with FC4 and does not work with FC5?

For PCMCIA cards that don't appear to work, be _sure_ to include the
output of 'pccardctl info' and 'pccardctl ident'.  2.6.15 and 2.6.16
changed the way that PCMCIA drivers get bound to particular hardware
instances, which may be what you're running into.  The output of those
commands can help determine what driver should be binding to your cards.

Also, if you happen to remember the driver that got bound to the card in
previous FC versions, that's helpful as well.  Stick all this into the
bug report.

Dan




From jdesbonnet at gmail.com  Sun Mar 26 18:37:23 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sun, 26 Mar 2006 19:37:23 +0100
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
Message-ID: <1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>

Thanks Jeff,

Perhaps the /etc/sysconfig/hwconf of the working FC4 vs the
non-working FC5 installation might be useful? Anyhow here is a list of
what I encountered installing FC5-i386 on a Thinkpad T41p:

1. During install and after install I no longer had use of my 3Com
3CRWE737A 802.11b PC Card (this worked with FC4,3,2,1). This card is
handled by the orinoco dirver. Even force loading the driver did not
bring this card to life. I do not think it is a kernel issue -- a grep
of  "3CRWE737A" on orinoco_cs.ko demonstrates that support for this
card is still in the kernel.
The /etc/sysconfig/hwconf entry from FC4 reads:
class: NETWORK
bus: PCMCIA
detached: 0
device: eth2
driver: orinoco_cs
desc: "3Com 3CRWE737A AirConnect Wireless LAN PC Card"
vendorId: 0101
deviceId: 0001
function: 0
slot: 0

2. After FC5 install I no longer have use of my built in bluetooth device.

3. After a few reboots I lose things like battery gauge
(/proc/acpi/battery directory gone!). This seems to correspond to
kudzu related errors on boot. I'm sorry -- I didn't capture the exact
text of the error at the time. I encountered this type of problem
before where kudzu failed at boot time and made a mess things. I can
reinstall FC5 and get that error message if it is going to be useful.

4. Suspend does not work (no surprise there). Blank flickering LCD
screen on restore. This never worked, so I'm not too concerned about
it.

5. Not a Thinkpad issue per se: When installing FC5Test3 on VMWare 
the BusLogic module had to be manually loaded. This was not required
during the FC4 install -- it was autodetected there. At the time I
thought that was a VMWare issue, now I suspect otherwise...

Joe.



From billcrawford1970 at gmail.com  Sun Mar 26 19:24:22 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Sun, 26 Mar 2006 19:24:22 +0000
Subject: FC5: first impressions
In-Reply-To: <1143384233.15323.16.camel@dimi>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
Message-ID: <200603262024.24201.billcrawford1970@googlemail.com>

On Sunday 26 March 2006 15:43, Dimi Paun wrote:

> But more importantly, I don't understand why people are
> harping on the terminal use case. My particular complaint
> applies to the entire desktop -- when I start any app (say
> from the GNOME menu), it does not get the focus! It is
> started in the background with a flashing button in the
> task bar.

 I did try to explain I'm totally with you on this one :)

 The popunder behaviour is not a useful universal solution. Not that there 
ever are any truly *universal* solutions, but ...

> If I start an app, it means that I want to use it _now_.
> Don't make me ask for it 2-3 times. In the unlikely case
> when I don't, a quick Alt-TAB solves the problem. If this
> is still not obvious to people, here's a quick comparison:
>   Focus Stealing:
>     -- >90% of time it does the right thing
>     -- <10% the fix is a sub-second Alt-TAB, no mouse
>   Manual Focus
>     -- >90% you have to use >1sec to gain the focus with the mouse
>     -- <10% you don't have to do anything
>
> If you still prefer the manual focus, all power to you, but
> that shouldn't be the default behavior. Let's just stick to
> the principle of least surprise here folks, we would make a
> lot of people happy.

 Principle of least surprise -> I don't end up hitting return and finding I've 
dismissed a dialogue box in the moment that it appeared, after which I may be 
unable to discover even what the box *was*.

 I totally agree with most of your comments, I just wanted to get across that 
the "root password in your im window" and "sh**, what was that dialogue?" are 
real problems in the real world for some people; and more's to the point, 
ones that those people won't even be aware of *until it happens to them" - 
now, it would be entirely fair (but a little mean) to make the default be the 
old behaviour, and make them select "focus stealing prevention" after they 
discover the problem. But taking away that option on the grounds it's "a non 
issue" to you is like saying lifebuoys are unnecessary because you've never 
drowned.

 Should seat belts be optional?



From billcrawford1970 at gmail.com  Sun Mar 26 19:26:59 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Sun, 26 Mar 2006 19:26:59 +0000
Subject: FC5: first impressions
In-Reply-To: <1143386468.12912.17.camel@averatec>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143384948.2816.3.camel@rousalka.dyndns.org>
	<1143386468.12912.17.camel@averatec>
Message-ID: <200603262027.00294.billcrawford1970@googlemail.com>

On Sunday 26 March 2006 16:21, Jon Nettleton wrote:

> I think the check for keypresses/mouse clinks between application launch
> and it being drawn on screen makes a much more logical interaction with
> the desktop.  If you ask your secretary to get you a file, and then you
> start working on something else, she doesn't just come over and drop it
> right in front of you.  If you ask your secretary to get you a file, and
> then you sit there twiddling your fingers, she will probably hand it
> right to you so you can start working on it.

 And if you had your hands full, and she just dropped it on your desk while 
you were writing something, and got ink on the nice new file, wouldn't you be 
surprised?

> Metacity already has an algorithm that somewhat tries to implement this
> with the intervening_user_event_occurred function.  I don't think that
> this is working quite right.  I spent some initial time working on it,
> but then got side tracked.  I would be more than happy to pick this back
> up if there is any interest in people testing this behavior and seeing
> if it is natural, or too confusing.

 I'd love to see a *better* solution. This sounds like a promising start - 
kudos to you and anyone else working on a solution.



From billcrawford1970 at gmail.com  Sun Mar 26 19:30:11 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Sun, 26 Mar 2006 19:30:11 +0000
Subject: FC5: first impressions
In-Reply-To: <604aa7910603260752ic0e3ec9s2dbddef1849fa222@mail.gmail.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143386468.12912.17.camel@averatec>
	<604aa7910603260752ic0e3ec9s2dbddef1849fa222@mail.gmail.com>
Message-ID: <200603262030.12019.billcrawford1970@googlemail.com>

On Sunday 26 March 2006 16:52, Jeff Spaleta wrote:

> yes launching mplayer in fullscreen mode from a terminal... its
> inconceivable why anyone would want mplayer to actuall go fullscreen.
> It makes so much more sense for the mplayer window, which was
> deliberately requested to be in fullscreen with a cmdline argument to
> load behind my terminal and the gnome-panels as well.  It's so simple
> and intuitive to have to click on that fullscreen requested mplayer
> window, not once.. but twice (to bring it above the terminal and the
> gnome-panel objects) to have it in the foreground like it would when
> called from pretty much anything other than gnome-terminal.

 For the record, I also totally agree with the point you are making.

> What I really really love.. is when the entire window for the
> application you just lauched is covered by the lauching terminal.
> Even better when that completely obscured window is a dialog with a
> timer action. I wonder, are any of those new fangled keyboard focus
> stealing password dialogs affected by the pop-under behavior? Wouldn't
> that be funny... a password dialog that you can't see which forcibly
> steals keyboard focus for security reasons.. sitting under your
> terminal window which forcibly causes new windows to pop-under for
> usability reasons.. Does that count as ironic.. or is it just tragic?

 This is why I think the current solution is not "the" "right" one.

Bill"just because I disagree with the current solution doesn't actually mean I 
really mean oh we should have the horrible nonoptimal solution and that 
people should keep replying to me defending the old behaviour"Crawford.



From billcrawford1970 at gmail.com  Sun Mar 26 19:34:54 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Sun, 26 Mar 2006 19:34:54 +0000
Subject: FC5: first impressions
In-Reply-To: <1767.69.194.157.31.1143390897.squirrel@lattica.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143385602l.19620l.3l@athena.riede.org>
	<1767.69.194.157.31.1143390897.squirrel@lattica.com>
Message-ID: <200603262034.54611.billcrawford1970@googlemail.com>

On Sunday 26 March 2006 17:34, Dimi Paun wrote:

> This is the crux of the issue: this problem does not have an obvious
> correct solution. A normal approach would be "do no evil". That is,
> there should be a hysteresis against changing well known behavior that
> is tried, tested, and true. Experimental stuff like this should be
> introduced gradually, with default to off, and only when it has been
> proven in the field we may turn it on by default.

 Now we are in violent agreement :)

> <offtopic>
> Don't people find it funny that we, as a community, know all about
> incremental improvements when it comes to patch management, but we behave
> like righteous a--holes when it comes to imposing what we believe to be
> the Right Way (TM) onto others? And hey, since we can now invoke the
> Usability Principle, we are in the right to remove any way for the
> luser to opt-out of our One True Way.

 Yup.

 I'm trying (I hope) to avoid this; as a long time self righteous arsehole, I 
reserve the right to self-deprecate at the drop of a hat. Otherwise I'm happy 
to defer ..

> But I digress, we are not the target audience...
> </offtopic>

 It's not off topic; we're trying to find a solution to a problem in Fedora 
(and in GNOME, KDE and other desktops, in the process).

 FWIW, you've made some damn good points, and I would like to thank you for 
your time rather than criticise.

 Thanks,
Bill.



From rhallyx at mindspring.com  Sun Mar 26 20:33:15 2006
From: rhallyx at mindspring.com (Richard Hally)
Date: Sun, 26 Mar 2006 15:33:15 -0500
Subject: fedora-release rawhide
Message-ID: <4426FA8B.6040802@mindspring.com>

How does one update the fedora-release to rawhide?
Below is the output I get from yum:
[root at LinuxNew2 ~]# yum list fedora-release
Loading "installonlyn" plugin
Setting up repositories
development                                                          [1/1]
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Installed Packages
fedora-release.noarch                    5-5                   installed
Available Packages
fedora-release.noarch                    5-rawhide           development
[root at LinuxNew2 ~]# yum update fedora-release
Loading "installonlyn" plugin
Setting up Update Process
Setting up repositories
development                                                          [1/1]
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Could not find update match for fedora-release
No Packages marked for Update/Obsoletion

thanks,
Richard



From billcrawford1970 at gmail.com  Sun Mar 26 21:06:15 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Sun, 26 Mar 2006 21:06:15 +0000
Subject: fedora-release rawhide
In-Reply-To: <4426FA8B.6040802@mindspring.com>
References: <4426FA8B.6040802@mindspring.com>
Message-ID: <200603262206.15927.billcrawford1970@googlemail.com>

On Sunday 26 March 2006 21:33, Richard Hally wrote:
> How does one update the fedora-release to rawhide?

rpm -Uvh --force 
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm



From rhallyx at mindspring.com  Sun Mar 26 21:37:38 2006
From: rhallyx at mindspring.com (Richard Hally)
Date: Sun, 26 Mar 2006 16:37:38 -0500
Subject: fedora-release rawhide
In-Reply-To: <200603262206.15927.billcrawford1970@googlemail.com>
References: <4426FA8B.6040802@mindspring.com>
	<200603262206.15927.billcrawford1970@googlemail.com>
Message-ID: <442709A2.7080405@mindspring.com>

Bill Crawford wrote:
> On Sunday 26 March 2006 21:33, Richard Hally wrote:
>> How does one update the fedora-release to rawhide?
> 
> rpm -Uvh --force 
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
> 
> 
nope, nice try though.

  [root at LinuxNew2 richard]# rpm -Uvh --force 
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
  Retrieving 
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
  Retrieving http://www.w3.org/TR/html4/strict.dtd>
  error: open of <!DOCTYPE failed: No such file or directory
  error: open of HTML failed: No such file or directory
  error: open of PUBLIC failed: No such file or directory

hangs at this point. Takes a CTRL-c.

Richard



From sdl.web at gmail.com  Sun Mar 26 21:41:38 2006
From: sdl.web at gmail.com (Leon)
Date: Sun, 26 Mar 2006 22:41:38 +0100
Subject: fedora-release rawhide
References: <4426FA8B.6040802@mindspring.com>
	<200603262206.15927.billcrawford1970@googlemail.com>
	<442709A2.7080405@mindspring.com>
Message-ID: <m2psk8nast.fsf@sl392.st-edmunds.cam.ac.uk>

Richard Hally <rhallyx at mindspring.com> writes:

> Bill Crawford wrote:
>> On Sunday 26 March 2006 21:33, Richard Hally wrote:
>>> How does one update the fedora-release to rawhide?
>> rpm -Uvh --force
>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>> 
> nope, nice try though.
>
>  [root at LinuxNew2 richard]# rpm -Uvh --force
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>  Retrieving
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>  Retrieving http://www.w3.org/TR/html4/strict.dtd>
>  error: open of <!DOCTYPE failed: No such file or directory
>  error: open of HTML failed: No such file or directory
>  error: open of PUBLIC failed: No such file or directory
>
> hangs at this point. Takes a CTRL-c.
>
> Richard
You could find a mirror and download the rpm to your local machine
then install it.

-- 
Leon



From nutello at sweetness.com  Sun Mar 26 21:43:21 2006
From: nutello at sweetness.com (Rudi Chiarito)
Date: Sun, 26 Mar 2006 23:43:21 +0200
Subject: fedora-release rawhide
In-Reply-To: <442709A2.7080405@mindspring.com>
References: <4426FA8B.6040802@mindspring.com>
	<200603262206.15927.billcrawford1970@googlemail.com>
	<442709A2.7080405@mindspring.com>
Message-ID: <20060326214321.GA25319@plain.rackshack.net>

On Sun, Mar 26, 2006 at 04:37:38PM -0500, Richard Hally wrote:
> nope, nice try though.

Just use a real HTTP client like wget to download the package to disk,
then install that. The smallest sign of trouble with the HTTP
transaction is enough to confuse the rpm command beyond repair. It
can't even handle redirects where the new URL contains a tilde
character (and who knows what else).

-- 
Rudi



From seanlkml at sympatico.ca  Sun Mar 26 21:46:11 2006
From: seanlkml at sympatico.ca (sean)
Date: Sun, 26 Mar 2006 16:46:11 -0500
Subject: fedora-release rawhide
In-Reply-To: <442709A2.7080405@mindspring.com>
References: <4426FA8B.6040802@mindspring.com>
	<200603262206.15927.billcrawford1970@googlemail.com>
	<442709A2.7080405@mindspring.com>
Message-ID: <BAYC1-PASMTP1278EB661429AF3AA814ACAEDD0@CEZ.ICE>

On Sun, 26 Mar 2006 16:37:38 -0500
Richard Hally <rhallyx at mindspring.com> wrote:

> Bill Crawford wrote:
> > On Sunday 26 March 2006 21:33, Richard Hally wrote:
> >> How does one update the fedora-release to rawhide?
> > 
> > rpm -Uvh --force 
> > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
> > 
> nope, nice try though.
> 
>   [root at LinuxNew2 richard]# rpm -Uvh --force 
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>   Retrieving 
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>   Retrieving http://www.w3.org/TR/html4/strict.dtd>
>   error: open of <!DOCTYPE failed: No such file or directory
>   error: open of HTML failed: No such file or directory
>   error: open of PUBLIC failed: No such file or directory
> 
> hangs at this point. Takes a CTRL-c.
> 

Bill gave you the correct idea and it shouldn't be that tough to spot the typo, use:

http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm


Sean



From gmaxwell at gmail.com  Sun Mar 26 21:50:48 2006
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Sun, 26 Mar 2006 16:50:48 -0500
Subject: FC5: first impressions
In-Reply-To: <1767.69.194.157.31.1143390897.squirrel@lattica.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143385602l.19620l.3l@athena.riede.org>
	<1767.69.194.157.31.1143390897.squirrel@lattica.com>
Message-ID: <e692861c0603261350n10a51a3dwbdd567d047df4a88@mail.gmail.com>

On 3/26/06, Dimi Paun <dimi at lattica.com> wrote:
> This is the crux of the issue: this problem does not have an obvious
> correct solution. A normal approach would be "do no evil". That is,
> there should be a hysteresis against changing well known behavior that
> is tried, tested, and true. Experimental stuff like this should be
> introduced gradually, with default to off, and only when it has been
> proven in the field we may turn it on by default.

This would involve providing configurable options to uses and, as far
as I can tell, it would appear that the primary goal of the Gnome
project is to deny users all forms of choice.

> <offtopic>
> Don't people find it funny that we, as a community, know all about
> incremental improvements when it comes to patch management, but we behave
> like righteous a--holes when it comes to imposing what we believe to be
> the Right Way (TM) onto others? And hey, since we can now invoke the
> Usability Principle, we are in the right to remove any way for the
> luser to opt-out of our One True Way.
>
> But I digress, we are not the target audience...
> </offtopic>

We? Hardly. This crazed position that we shouldn't even provide users
with choices is an illness which is mostly limited to Gnome.

If I may be so bold, I'd suggest you switch to using KDE. KDE is most
refreshing after spending a while stuck with gnome.



From rhally at mindspring.com  Sun Mar 26 22:05:05 2006
From: rhally at mindspring.com (Richard Hally)
Date: Sun, 26 Mar 2006 17:05:05 -0500
Subject: fedora-release rawhide
In-Reply-To: <BAYC1-PASMTP1278EB661429AF3AA814ACAEDD0@CEZ.ICE>
References: <4426FA8B.6040802@mindspring.com>	<200603262206.15927.billcrawford1970@googlemail.com>	<442709A2.7080405@mindspring.com>
	<BAYC1-PASMTP1278EB661429AF3AA814ACAEDD0@CEZ.ICE>
Message-ID: <44271011.7070107@mindspring.com>

sean wrote:
> On Sun, 26 Mar 2006 16:37:38 -0500
> Richard Hally <rhallyx at mindspring.com> wrote:
> 
>> Bill Crawford wrote:
>>> On Sunday 26 March 2006 21:33, Richard Hally wrote:
>>>> How does one update the fedora-release to rawhide?
>>> rpm -Uvh --force 
>>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>>>
>> nope, nice try though.
>>
>>   [root at LinuxNew2 richard]# rpm -Uvh --force 
>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>>   Retrieving 
>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>>   Retrieving http://www.w3.org/TR/html4/strict.dtd>
>>   error: open of <!DOCTYPE failed: No such file or directory
>>   error: open of HTML failed: No such file or directory
>>   error: open of PUBLIC failed: No such file or directory
>>
>> hangs at this point. Takes a CTRL-c.
>>
> 
> Bill gave you the correct idea and it shouldn't be that tough to spot the typo, use:
> 
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
> 
> 
> Sean
> 
Got it! Thanks to all  8-)



From walovaton at yahoo.com.mx  Sun Mar 26 22:34:46 2006
From: walovaton at yahoo.com.mx (William Lovaton)
Date: Sun, 26 Mar 2006 16:34:46 -0600 (CST)
Subject: Fedora core for the Itanium
In-Reply-To: <20060324220802.GG8721@devserv.devel.redhat.com>
Message-ID: <20060326223446.14019.qmail@web60720.mail.yahoo.com>

No?? that's a shame.

We have a big HP Itanium box at the company I work for
but we have a lot of problems with it, specially with
the OS (HPUX).

We have lots of production servers with Fedora Core 3
x86-32 with great results and we are very interesting
in getting RHEL.

But I'd like to test the ia64 box with a LiveCD or
something like that but I can't find one for this
arch.  Ubuntu says AMD64 but I guess that won't work
on Itanium, isn't it?  and FC5 doesn't have ia64
support on installable media.  How can I install FC5
on this itanium box?

Besides, I was wondering what is the status of Oracle
support in RHEL4 for ia64.  Red Hat site says this
arch is supported so I guess Oracle works fine there:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as-itanium/

Cheers,


-William


 --- Bill Nottingham <notting at redhat.com> escribi?:

> Jason Connor (jason.connor at gmail.com) said: 
> > Are there any plans for doing stable releases of
> fedora core for ia64?
> 
> No.
> 
> > I've seen the rawhide tree for the platform, but
> with the recent
> > pledges from intel, hp, and others to put more
> money into the
> > platform, I think it might be time to release
> fedora for end users on
> > it.
> 
> There has not been sufficient community interest to
> warrant it; there
> isn't even anything on the scale of CentOS for
> Alpha, or Aurora Linux.
> 
> Bill
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 



	
	
		
___________________________________________________________ 
Do You Yahoo!? 
La mejor conexi?n a Internet y <b >2GB</b> extra a tu correo por $100 al mes. http://net.yahoo.com.mx 



From rhally at mindspring.com  Sun Mar 26 21:49:56 2006
From: rhally at mindspring.com (Richard Hally)
Date: Sun, 26 Mar 2006 16:49:56 -0500
Subject: fedora-release rawhide
In-Reply-To: <m2psk8nast.fsf@sl392.st-edmunds.cam.ac.uk>
References: <4426FA8B.6040802@mindspring.com>	<200603262206.15927.billcrawford1970@googlemail.com>	<442709A2.7080405@mindspring.com>
	<m2psk8nast.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <44270C84.9000607@mindspring.com>

Leon wrote:
> Richard Hally <rhallyx at mindspring.com> writes:
> 
>> Bill Crawford wrote:
>>> On Sunday 26 March 2006 21:33, Richard Hally wrote:
>>>> How does one update the fedora-release to rawhide?
>>> rpm -Uvh --force
>>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>>>
>> nope, nice try though.
>>
>>  [root at LinuxNew2 richard]# rpm -Uvh --force
>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>>  Retrieving
>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>>  Retrieving http://www.w3.org/TR/html4/strict.dtd>
>>  error: open of <!DOCTYPE failed: No such file or directory
>>  error: open of HTML failed: No such file or directory
>>  error: open of PUBLIC failed: No such file or directory
>>
>> hangs at this point. Takes a CTRL-c.
>>
>> Richard
> You could find a mirror and download the rpm to your local machine
> then install it.
> 

tried that first, exact same result (I like to keep copies of the rpms I 
install)

Richard



From jarod at wilsonet.com  Sun Mar 26 23:12:16 2006
From: jarod at wilsonet.com (Jarod Wilson)
Date: Sun, 26 Mar 2006 15:12:16 -0800
Subject: FC5 weird raid issues
In-Reply-To: <4426643E.10405@feuerpokemon.de>
References: <442423F7.7060100@feuerpokemon.de>
	<1143370131.5480.0.camel@gilboa-work-dev>
	<4426643E.10405@feuerpokemon.de>
Message-ID: <200603261512.20516.jarod@wilsonet.com>

On Sunday 26 March 2006 01:51, dragoran wrote:
> Gilboa Davara wrote:
> > On Fri, 2006-03-24 at 17:53 +0100, dragoran wrote:
> >> I have tryed to upgrade from FC4 -> FC5 using anaconda but it did not
> >> detect my FC4 installation which is installed on /dev/md0.
> >> It tryes to add a non raid partition to the array and ignores the raid
> >> partition. This causes the initalisation of md0 to fail.
> >> Is this a kernel or anaconda bug?
> >> Bug report:
> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312
> >> (no reply ...)
> >> So I backuped my data dan tryed a reinstall and it detected the md0
> >> array in diskdruid but showed "foreign" as filesystem..
> >> did edit and set mount point to / and filesystem ext3
> >> but it failed formating it with a messages saying that it failed and
> >> that I should press enter to reboot the system.
> >> What happend? How could such things happen with a *final* release? Raid
> >> support seems broken and nobody has noticed.
> >> I always updated my system from RH9->FC1->FC2->FC3->FC4 (then
> >> reinstalled FC4 because of i386->x86_64) but it seems that upgrade is no
> >> more possible to FC5 :(
> >
> > I'd suggest you switch to console once Anaconda loads and mount the MD0
> > by hand.
> > It should give you a way to circumvent the bug.
> >
> > Gilboa
>
> I just deleted the raid and recreated it and now it seems to work fine.
> (running FC5 with md raid now).
> But the bug still needs to be fixed.
> But I don't like to reinstall FC6 when its out upgrade from raid should
> work as it did before FC5.

I assure you upgrades from FC4 to FC5 on systems with md software raids were 
tested and all worked without issue. It isn't that raid support is broken and 
nobody noticed. Not sure why the failure in your particular case, but I've 
done several upgrades myself without incident. Without being able to 
reproduce the problem, fixing whatever went wrong on your system may prove 
difficult, if not impossible.

-- 
Jarod Wilson
jarod at wilsonet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060326/4b3c4e5d/attachment.sig>

From sundaram at fedoraproject.org  Mon Mar 27 00:01:08 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 27 Mar 2006 05:31:08 +0530
Subject: fedora-release rawhide
In-Reply-To: <200603262206.15927.billcrawford1970@googlemail.com>
References: <4426FA8B.6040802@mindspring.com>
	<200603262206.15927.billcrawford1970@googlemail.com>
Message-ID: <1143417668.3802.336.camel@sundaram.pnq.redhat.com>

On Sun, 2006-03-26 at 21:06 +0000, Bill Crawford wrote:
> On Sunday 26 March 2006 21:33, Richard Hally wrote:
> > How does one update the fedora-release to rawhide?
> 
> rpm -Uvh --force 
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
> 

Why do you need to use --force there?

Rahul



From Axel.Thimm at ATrpms.net  Mon Mar 27 00:24:59 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Mon, 27 Mar 2006 02:24:59 +0200
Subject: fedora-release rawhide
In-Reply-To: <1143417668.3802.336.camel@sundaram.pnq.redhat.com>
References: <4426FA8B.6040802@mindspring.com>
	<200603262206.15927.billcrawford1970@googlemail.com>
	<1143417668.3802.336.camel@sundaram.pnq.redhat.com>
Message-ID: <20060327002459.GC10041@neu.nirvana>

On Mon, Mar 27, 2006 at 05:31:08AM +0530, Rahul Sundaram wrote:
> On Sun, 2006-03-26 at 21:06 +0000, Bill Crawford wrote:
> > On Sunday 26 March 2006 21:33, Richard Hally wrote:
> > > How does one update the fedora-release to rawhide?
> > 
> > rpm -Uvh --force 
> > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
> > 
> 
> Why do you need to use --force there?

Because "rawhide" < "5" in rpm ordering.

A better way to deal with this would be to give the rawhide package a
_version_ between

	  5 < version < 5.90

The rationale is that 5.90 will be the first test release of FC6 so
the version string should stay below this one. Maybe 5.5 would be a
good indicator of where the user is when using rawhide.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/22f7f84b/attachment.sig>

From rhally at mindspring.com  Mon Mar 27 00:52:36 2006
From: rhally at mindspring.com (Richard Hally)
Date: Sun, 26 Mar 2006 19:52:36 -0500
Subject: fedora-release rawhide
In-Reply-To: <20060327002459.GC10041@neu.nirvana>
References: <4426FA8B.6040802@mindspring.com>	<200603262206.15927.billcrawford1970@googlemail.com>	<1143417668.3802.336.camel@sundaram.pnq.redhat.com>
	<20060327002459.GC10041@neu.nirvana>
Message-ID: <44273754.7020900@mindspring.com>

Axel Thimm wrote:
> On Mon, Mar 27, 2006 at 05:31:08AM +0530, Rahul Sundaram wrote:
>> On Sun, 2006-03-26 at 21:06 +0000, Bill Crawford wrote:
>>> On Sunday 26 March 2006 21:33, Richard Hally wrote:
>>>> How does one update the fedora-release to rawhide?
>>> rpm -Uvh --force 
>>> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/fedora-release-5-rawhide.noarch.rpm
>>>
>> Why do you need to use --force there?
> 
> Because "rawhide" < "5" in rpm ordering.
> 
> A better way to deal with this would be to give the rawhide package a
> _version_ between
> 
> 	  5 < version < 5.90
> 
> The rationale is that 5.90 will be the first test release of FC6 so
> the version string should stay below this one. Maybe 5.5 would be a
> good indicator of where the user is when using rawhide.
> 
Perhaps we could treat it like other packages in /development. That is, 
make it 5.90 until FC6 test 1 goes out then bump it to 5.91 until test2 
is out, etc... and within the package have /etc/fedora-release actually 
  contain "Fedora Core test 1 of release 6 (rawhide)"
Just an idea.
Richard



From sundaram at fedoraproject.org  Mon Mar 27 01:01:44 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 27 Mar 2006 06:31:44 +0530
Subject: Fedora Core 5 common issues and bugs
Message-ID: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>

Hi


Just to avoid the repeated bug reports and questions on it. Check out
this page which is periodically updated. If there are other common
issues to add, let me know. 

http://fedoraproject.org/wiki/Bugs/FC5Common

Rahul



From rhally at mindspring.com  Mon Mar 27 01:24:29 2006
From: rhally at mindspring.com (Richard Hally)
Date: Sun, 26 Mar 2006 20:24:29 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
Message-ID: <44273ECD.8010606@mindspring.com>

Rahul Sundaram wrote:
> Hi
> 
> 
> Just to avoid the repeated bug reports and questions on it. Check out
> this page which is periodically updated. If there are other common
> issues to add, let me know. 
> 
> http://fedoraproject.org/wiki/Bugs/FC5Common
> 
> Rahul
> 
Below are two older buggs about CD problems that are worked around by 
using "linux ide=nodma" to start an install. I needed to use this to 
install FC5 test3 on one of my boxes. It apparently is a kernel problem 
that has been hanging around for quite a while.

Would this be appropriate for that Common Bugs page?

Richard

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



From wtogami at redhat.com  Mon Mar 27 01:43:08 2006
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 26 Mar 2006 20:43:08 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <44273ECD.8010606@mindspring.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
Message-ID: <4427432C.2010706@redhat.com>

Richard Hally wrote:
> Rahul Sundaram wrote:
>> Hi
>>
>>
>> Just to avoid the repeated bug reports and questions on it. Check out
>> this page which is periodically updated. If there are other common
>> issues to add, let me know.
>> http://fedoraproject.org/wiki/Bugs/FC5Common
>>
>> Rahul
>>
> Below are two older buggs about CD problems that are worked around by 
> using "linux ide=nodma" to start an install. I needed to use this to 
> install FC5 test3 on one of my boxes. It apparently is a kernel problem 
> that has been hanging around for quite a while.
> 
> Would this be appropriate for that Common Bugs page?
> 
> Richard
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150186
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135795
> 


IMHO, no.  Long standing bugs like yours are hardware specific and do 
not affect most people.  I believe this page should be focused on 
short-term bugs that effect most people and their workarounds.

Warren Togami
wtogami at redhat.com



From sundaram at fedoraproject.org  Mon Mar 27 01:47:29 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 27 Mar 2006 07:17:29 +0530
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <44273ECD.8010606@mindspring.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
Message-ID: <1143424049.3802.356.camel@sundaram.pnq.redhat.com>

On Sun, 2006-03-26 at 20:24 -0500, Richard Hally wrote:
> Rahul Sundaram wrote:
> > Hi
> > 
> > 
> > Just to avoid the repeated bug reports and questions on it. Check out
> > this page which is periodically updated. If there are other common
> > issues to add, let me know. 
> > 
> > http://fedoraproject.org/wiki/Bugs/FC5Common
> > 
> > Rahul
> > 
> Below are two older buggs about CD problems that are worked around by 
> using "linux ide=nodma" to start an install. I needed to use this to 
> install FC5 test3 on one of my boxes. It apparently is a kernel problem 
> that has been hanging around for quite a while.
> 
> Would this be appropriate for that Common Bugs page?
> 
> Richard
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150186
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135795
> 

I dont want to list all the bugs on that page. Just the common ones. I
havent seen the above discussed anywhere in the lists or forums for FC5.
So I think these arent common. Besides onne of these is filed against
RHEL 4 and other one is closed as CANTFIX. I am not going to list these
unless they are tracked under FC5. 


Rahul



From dimi at lattica.com  Mon Mar 27 01:53:23 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 26 Mar 2006 20:53:23 -0500
Subject: Open-link misbehavior
Message-ID: <1143424403.15323.31.camel@dimi>

Hi folks,

One more note in the focus handling saga. Right now, if one clicks
on a link in Evolution, it is opened in the most recent Firefox
window, as a new tab.

This is fine, except when you have Firefox windows on different
desktops. You click on a link in Evo, and then you start hunting
on the various desktops completely blind trying to find it!
(Unless you were lucky and the last used Firefox window was on 
the same desktop as your Evolution).

Now, I can see why this behavior would be advantageous, as long
as a _new_ window was opened in cases where the link would open
on a tab on a different desktop. But as it stands, it is very 
confusing. I can see that technically the "right thing" would be 
hard to implement (it probably requires interaction between 
Firefox and the WM).

So until we get this right, the default behavior should be to
open a new Firefox window. Advanced user can select this other
behavior knowing full well what they are getting into.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From tburke at redhat.com  Mon Mar 27 02:15:24 2006
From: tburke at redhat.com (Tim Burke)
Date: Sun, 26 Mar 2006 21:15:24 -0500
Subject: Fedora core for the Itanium
In-Reply-To: <20060326223446.14019.qmail@web60720.mail.yahoo.com>
References: <20060326223446.14019.qmail@web60720.mail.yahoo.com>
Message-ID: <44274ABC.5050208@redhat.com>

William Lovaton wrote:
> But I'd like to test the ia64 box with a LiveCD or
> something like that but I can't find one for this
> arch.  Ubuntu says AMD64 but I guess that won't work
> on Itanium, isn't it?  
Correct.  AMD64 (x86-64) bits do not worn on itanium.
> and FC5 doesn't have ia64
> support on installable media.  How can I install FC5
> on this itanium box?
>   
You can't.
> Besides, I was wondering what is the status of Oracle
> support in RHEL4 for ia64.  Red Hat site says this
> arch is supported so I guess Oracle works fine there:
> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as-itanium/
>
>   
Oracle is supported on RHEL4 Itanium distro.



From ianburrell at gmail.com  Mon Mar 27 02:26:44 2006
From: ianburrell at gmail.com (Ian Burrell)
Date: Sun, 26 Mar 2006 18:26:44 -0800
Subject: Open-link misbehavior
In-Reply-To: <1143424403.15323.31.camel@dimi>
References: <1143424403.15323.31.camel@dimi>
Message-ID: <d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>

On 3/26/06, Dimi Paun <dimi at lattica.com> wrote:
>
> One more note in the focus handling saga. Right now, if one clicks
> on a link in Evolution, it is opened in the most recent Firefox
> window, as a new tab.
>
> This is fine, except when you have Firefox windows on different
> desktops. You click on a link in Evo, and then you start hunting
> on the various desktops completely blind trying to find it!
> (Unless you were lucky and the last used Firefox window was on
> the same desktop as your Evolution).
>
> Now, I can see why this behavior would be advantageous, as long
> as a _new_ window was opened in cases where the link would open
> on a tab on a different desktop. But as it stands, it is very
> confusing. I can see that technically the "right thing" would be
> hard to implement (it probably requires interaction between
> Firefox and the WM).
>
> So until we get this right, the default behavior should be to
> open a new Firefox window. Advanced user can select this other
> behavior knowing full well what they are getting into.
>

This is controlled by a Firefox preference and affects opening any
external link.  The default is "a new tab in the most recent window". 
The other options are in "a new window", or in "the most recent
tab/window".

Personally, I think we should follow the upstream default and not try
to patch Firefox to behave differently.

 - Ian



From dimi at lattica.com  Mon Mar 27 02:35:12 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 26 Mar 2006 21:35:12 -0500
Subject: Open-link misbehavior
In-Reply-To: <d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
Message-ID: <1143426912.15323.43.camel@dimi>

On Sun, 2006-03-26 at 18:26 -0800, Ian Burrell wrote:
> This is controlled by a Firefox preference and affects opening any
> external link.  The default is "a new tab in the most recent window". 
> The other options are in "a new window", or in "the most recent
> tab/window".

I know this, however this does not work correctly in a multi-desktop
setup without some cooperation between Firefox and Metacity. This
is clearly (at least at this point) a distro issue, simply because
the Mozilla people can't do anything about it given the large variation
out there in the field (tens of WMs, etc).

In fact, when a link is opened in a new tab on same desktop, the app
button in the taskbar flashes. This is not a Firefox behavior, it is
the desktop. There's nothing Firefox-ish about it. When it opens in a
_different_ desktop however, you get nothing! No indication, sign, etc.
You are left to hunt through the various desktops like an idiot.

I hope people don't consider this acceptable.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dax at gurulabs.com  Mon Mar 27 02:35:30 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Sun, 26 Mar 2006 19:35:30 -0700
Subject: FC5 weird raid issues
In-Reply-To: <4426643E.10405@feuerpokemon.de>
References: <442423F7.7060100@feuerpokemon.de>
	<1143370131.5480.0.camel@gilboa-work-dev>
	<4426643E.10405@feuerpokemon.de>
Message-ID: <5255-SnapperMsg827D11E1C04D0008@[68.27.157.67]>

...... Original Message .......
On Sun, 26 Mar 2006 11:51:58 +0200 "dragoran" <dragoran at feuerpokemon.de> 
wrote:
>I just deleted the raid and recreated it and now it seems to work fine.
>(running FC5 with md raid now).
>But the bug still needs to be fixed.
>But I don't like to reinstall FC6 when its out upgrade from raid should 
>work as it did before FC5.

Are you using or have you ever used 'motherboard RAID' on the hard drive 
you are installing to? 

The reason I ask is because, new with FC5, if fake motherboard RAID 
metadata is detected then dmraid is automatically activated and the 
underlying physical partitions are 'hidden' so as to (properly) prevent 
accidental direct writes to part of the RAID.
 
___
Dax Kelson
Sent with my Treo



From n0dalus+redhat at gmail.com  Mon Mar 27 02:41:24 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Mon, 27 Mar 2006 13:11:24 +1030
Subject: Open-link misbehavior
In-Reply-To: <1143426912.15323.43.camel@dimi>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
Message-ID: <6280325c0603261841u4adb77d4q3672925058ce3710@mail.gmail.com>

On 3/27/06, Dimi Paun <dimi at lattica.com> wrote:
>
> In fact, when a link is opened in a new tab on same desktop, the app
> button in the taskbar flashes. This is not a Firefox behavior, it is
> the desktop. There's nothing Firefox-ish about it. When it opens in a
> _different_ desktop however, you get nothing! No indication, sign, etc.
> You are left to hunt through the various desktops like an idiot.
>

Ideally, Gnome should provide some notification of 'flashing' windows
in the workspace switcher.

n0dalus.



From sundaram at fedoraproject.org  Mon Mar 27 02:55:24 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 27 Mar 2006 08:25:24 +0530
Subject: Open-link misbehavior
In-Reply-To: <1143426912.15323.43.camel@dimi>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
Message-ID: <1143428124.3802.378.camel@sundaram.pnq.redhat.com>

On Sun, 2006-03-26 at 21:35 -0500, Dimi Paun wrote:
> On Sun, 2006-03-26 at 18:26 -0800, Ian Burrell wrote:
> > This is controlled by a Firefox preference and affects opening any
> > external link.  The default is "a new tab in the most recent window". 
> > The other options are in "a new window", or in "the most recent
> > tab/window".
> 
> I know this, however this does not work correctly in a multi-desktop
> setup without some cooperation between Firefox and Metacity. This
> is clearly (at least at this point) a distro issue, simply because
> the Mozilla people can't do anything about it given the large variation
> out there in the field (tens of WMs, etc).

This is non distribution specific window manager issue. If it requires a
common specification, then you can post to
http://mail.gnome.org/archives/wm-spec-list/. If it's metacity specific,
you can use http://bugzilla.gnome.org

Rahul



From wrrhdev at riede.org  Mon Mar 27 03:05:56 2006
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 26 Mar 2006 22:05:56 -0500
Subject: Open-link misbehavior
In-Reply-To: <1143426912.15323.43.camel@dimi> (from dimi@lattica.com on Sun
	Mar 26 21:35:12 2006)
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
Message-ID: <1143428756l.26064l.0l@athena.riede.org>

On 03/26/2006 09:35:12 PM, Dimi Paun wrote:
> On Sun, 2006-03-26 at 18:26 -0800, Ian Burrell wrote:
> > This is controlled by a Firefox preference and affects opening any
> > external link.  The default is "a new tab in the most recent window". 
> > The other options are in "a new window", or in "the most recent
> > tab/window".
> 
> I know this, however this does not work correctly in a multi-desktop
> setup without some cooperation between Firefox and Metacity. This
> is clearly (at least at this point) a distro issue, simply because
> the Mozilla people can't do anything about it given the large variation
> out there in the field (tens of WMs, etc).
> 
> In fact, when a link is opened in a new tab on same desktop, the app
> button in the taskbar flashes. This is not a Firefox behavior, it is
> the desktop. There's nothing Firefox-ish about it. When it opens in a
> _different_ desktop however, you get nothing! No indication, sign, etc.
> You are left to hunt through the various desktops like an idiot.
> 
> I hope people don't consider this acceptable.

I have to disappoint you. I positively love, love love this behavior.
Please do not assume everybody thinks like you do.

Regards, Willem Riede.




From dimi at lattica.com  Mon Mar 27 03:23:35 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 26 Mar 2006 22:23:35 -0500
Subject: Open-link misbehavior
In-Reply-To: <1143428124.3802.378.camel@sundaram.pnq.redhat.com>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
	<1143428124.3802.378.camel@sundaram.pnq.redhat.com>
Message-ID: <1143429815.15323.50.camel@dimi>

On Mon, 2006-03-27 at 08:25 +0530, Rahul Sundaram wrote:
> This is non distribution specific window manager issue. If it requires
> a common specification, then you can post to
> http://mail.gnome.org/archives/wm-spec-list/. If it's metacity
> specific, you can use http://bugzilla.gnome.org 

Rahul,

I'm not sure what sort of problem this is -- from a user's
perspective, this is a distribution problem. You can not expect every
user to have deep knowledge about ICCCM or other such obscure
protocols :)

I am posting here in the hope that others more knowledgeable than
me can point me in the right direction. I also assume (maybe
incorrectly) that some of the 'heavyweights' that help define this
behavior in GNOME actually work for Red Hat and read this list. 

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dimi at lattica.com  Mon Mar 27 03:30:21 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 26 Mar 2006 22:30:21 -0500
Subject: Open-link misbehavior
In-Reply-To: <1143428756l.26064l.0l@athena.riede.org>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
	<1143428756l.26064l.0l@athena.riede.org>
Message-ID: <1143430221.15323.55.camel@dimi>

On Sun, 2006-03-26 at 22:05 -0500, Willem Riede wrote:
> I have to disappoint you. I positively love, love love this behavior.
> Please do not assume everybody thinks like you do.

Willem, I have clearly explained twice the problem. You didn't
seem to have paid attention in both cases :) I did not complain
about the opening of the link in a tab. This is a cool feature, 
I agree. 

I did complain about the fact that when the Firefox window is on a
different desktop than Evolution (or any other app that tries to open a
link for that matter), there is no feedback whatsoever about where it
was opened! Is _this_ lack of feedback that you "positively love"?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sundaram at fedoraproject.org  Mon Mar 27 03:36:14 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 27 Mar 2006 09:06:14 +0530
Subject: Open-link misbehavior
In-Reply-To: <1143429815.15323.50.camel@dimi>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
	<1143428124.3802.378.camel@sundaram.pnq.redhat.com>
	<1143429815.15323.50.camel@dimi>
Message-ID: <1143430574.3802.407.camel@sundaram.pnq.redhat.com>

On Sun, 2006-03-26 at 22:23 -0500, Dimi Paun wrote:
> On Mon, 2006-03-27 at 08:25 +0530, Rahul Sundaram wrote:
> > This is non distribution specific window manager issue. If it requires
> > a common specification, then you can post to
> > http://mail.gnome.org/archives/wm-spec-list/. If it's metacity
> > specific, you can use http://bugzilla.gnome.org 
> 
> Rahul,
> 
> I'm not sure what sort of problem this is -- from a user's
> perspective, this is a distribution problem. You can not expect every
> user to have deep knowledge about ICCCM or other such obscure
> protocols :)
> 
> I am posting here in the hope that others more knowledgeable than
> me can point me in the right direction. I also assume (maybe
> incorrectly) that some of the 'heavyweights' that help define this
> behavior in GNOME actually work for Red Hat and read this list. 

Maybe, but we shouldnt be the bunch of people relying on heavyweights to
move things. If we do, we have already failed to see open development.
It's always useful to report this issue where it has a much better
traction. For metacity, thats the GNOME bugzilla. For a typical user,
this is a distribution specific issue. As a more technically inclined
user who is discussing issues in a development list, I would like you to
step up a bit more than that. 


Rahul



From dimi at lattica.com  Mon Mar 27 03:44:08 2006
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 26 Mar 2006 22:44:08 -0500
Subject: Open-link misbehavior
In-Reply-To: <1143430574.3802.407.camel@sundaram.pnq.redhat.com>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
	<1143428124.3802.378.camel@sundaram.pnq.redhat.com>
	<1143429815.15323.50.camel@dimi>
	<1143430574.3802.407.camel@sundaram.pnq.redhat.com>
Message-ID: <1143431048.15323.58.camel@dimi>

On Mon, 2006-03-27 at 09:06 +0530, Rahul Sundaram wrote:
> For a typical user, this is a distribution specific issue. As a more
> technically inclined user who is discussing issues in a development
> list, I would like you to step up a bit more than that.  

Point taken:
    http://bugzilla.gnome.org/show_bug.cgi?id=336142

Hope this is the right bugzilla for this bug.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sopwith at redhat.com  Mon Mar 27 03:54:14 2006
From: sopwith at redhat.com (Elliot Lee)
Date: Sun, 26 Mar 2006 22:54:14 -0500 (EST)
Subject: CVS system migration done
Message-ID: <Pine.LNX.4.58.0603262248120.11932@devserv.devel.redhat.com>

Hi all,

cvs.fedoraproject.org (aka cvs.fedora.redhat.com) has been migrated to a
new system. Please let me know if there are any problems that need
fixing...

Best,
-- Elliot



From ianburrell at gmail.com  Mon Mar 27 04:46:44 2006
From: ianburrell at gmail.com (Ian Burrell)
Date: Sun, 26 Mar 2006 20:46:44 -0800
Subject: Open-link misbehavior
In-Reply-To: <1143426912.15323.43.camel@dimi>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
Message-ID: <d91f09cd0603262046s40b2acf3nc45dbdc95d54c00a@mail.gmail.com>

On 3/26/06, Dimi Paun <dimi at lattica.com> wrote:
>
> I know this, however this does not work correctly in a multi-desktop
> setup without some cooperation between Firefox and Metacity. This
> is clearly (at least at this point) a distro issue, simply because
> the Mozilla people can't do anything about it given the large variation
> out there in the field (tens of WMs, etc).
>
> In fact, when a link is opened in a new tab on same desktop, the app
> button in the taskbar flashes. This is not a Firefox behavior, it is
> the desktop. There's nothing Firefox-ish about it. When it opens in a
> _different_ desktop however, you get nothing! No indication, sign, etc.
> You are left to hunt through the various desktops like an idiot.
>

The window manager and window list applet definitely have the ability
to flash the icons when the app tells them to (gaim does this).  The
other day, I saw an icon in the taskbar show up for an app on another
desktop. When I clicked on the taskbar, it switched to the other
desktop and selected the window asking for attention. I think this is
new behavior since I hadn't noticed the cross-desktop behavior before.

Since the desktop support the behavior, then the place this needs to
be changed is in Firefox.  Firefox would need to demand attention
(flash the taskbar) when a new tab is opened from an external link.  I
did a quick search of bugzilla.mozilla.org and didn't find anything.

 - Ian



From tibbs at math.uh.edu  Mon Mar 27 05:04:05 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Sun, 26 Mar 2006 23:04:05 -0600
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <20060324202627.GD2725@redhat.com> (Dave Jones's message of
	"Fri, 24 Mar 2006 15:26:27 -0500")
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060324202627.GD2725@redhat.com>
Message-ID: <ufapsk8h41m.fsf@epithumia.math.uh.edu>

>>>>> "DJ" == Dave Jones <davej at redhat.com> writes:

DJ> really ? I was under the impression that all the SMP capable C3's
DJ> were Nehemiah cores, which are 686 capable.

Well:

> cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 10
cpu MHz         : 997.370
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 apic mtrr pge cmov pat
mmx fxsr sse rng rng_en ace ace_en
bogomips        : 1998.41

(plus another identical CPU)

FC5 doesn't install a SMP kernel on this machine, and installing the
shipped SMP kernel results in something that spews a few thousand
identical messages about unhandled interrupts and then reboots.  I'll
be happy to provide more info if there's any data you'd like for me to
collect.

I built 2.6.16-1.2070_FC5 with a custom i586-smp kernel that sets
CONFIG_MVIAC3_2 and it runs fine.

DJ> that should be it, unless I've forgotten something.

Yep, that worked.  (I eventually figured it out during the mailing
list delay.)  Is there any possibility of getting some of these
alternate kernels into the base SRPM?  It might be useful to have them
built for extras.

 - J<



From naoki at valuecommerce.com  Mon Mar 27 05:27:41 2006
From: naoki at valuecommerce.com (Naoki)
Date: Mon, 27 Mar 2006 14:27:41 +0900
Subject: firstboot system maintenance task
In-Reply-To: <1143226822.2415.23.camel@dhcp-198.home.local>
References: <1143226822.2415.23.camel@dhcp-198.home.local>
Message-ID: <1143437261.26079.66.camel@dragon.valuecommerce.ne.jp>

One idea, might not work in your case. We have a mirror of the FC tree,
then roll our updates into the core repository and remove older
packages, then run createrepo over it.
Means each new system we build has all the latest packages/updates.  Of
course you can do this to build ISO images as well. Saves time on
running "yum -y update" on everything and downloading all the RPMs
again.  Especially after 3-4 months when the updates tree becomes huge.


On Fri, 2006-03-24 at 11:00 -0800, Florin Andrei wrote:
> After installing Fedora on any system, when the system boots up for the
> first time I always log in as root immediately, in a text-mode console
> (not via X), then run this sequence:
> 
> killall anacron
> yum -y update
> yum clean packages
> anacron -nd
> sync
> reboot
> 
> I just type everything in then I walk away and let the system do it
> since there should be no user interaction. Perhaps a better idea would
> be to run everything inside a typescript session, just to catch all the
> output for further analysis - hmmm, that actually does sound good, I
> should add that to my first boot ritual from now on. :-)
> 
> Anyway, even before Fedora, I was pretty much doing the same thing, but
> translated in Red Hat Linux terms.
> Even before that, 10 years ago when I was using Slackware Linux :-) I
> was doing things that were functionally equivalent, albeit a lot more
> manual and hugely more cumbersome.
> 
> I just think it's a good idea and it's the best and shortest way to
> build a clean and up to date system out of a fresh install.
> 
> So I was thinking - perhaps it, or something equivalent - could be added
> as the last step to firstboot. Perhaps as a popup, informing the user
> that the system will apply all available updates, perform some
> maintenance tasks then reboot, and asking the user to either accept or
> reject it.
> 
> The only snag that I can think of is Internet access - firstboot should
> test HTTP access and perhaps ask the user to configure proxy settings
> first (and skip this whole thing if there seems to be no way to enable
> Internet access at this point).
> Also, perhaps anacron should not even be started the very first time the
> system comes up after install, but instead wait for this maintenance
> task to be either accepted by the user (then the system will reboot and
> anacron will launch normally next time) or rejected (then perhaps
> anacron should be launched by firstboot).
> 
> This might also help a lot of newbies since I noticed that some people
> running Linux for the first time are not aware of the necessity to apply
> updates and patches and do not even know how to do it.
> For the advanced users it would be just a convenient way to bring a
> fresh install up to date before actually pounding on it with real
> workload.
> 
> Thoughts?
> 
> -- 
> Florin Andrei
> 
> http://florin.myip.org/
> 





From pmatilai at laiskiainen.org  Mon Mar 27 05:48:20 2006
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sun, 26 Mar 2006 21:48:20 -0800 (PST)
Subject: FC5: first impressions
In-Reply-To: <1143385602l.19620l.3l@athena.riede.org>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143385602l.19620l.3l@athena.riede.org>
Message-ID: <Pine.LNX.4.62.0603262131490.3987@gotcha.dreamhost.com>

On Sun, 26 Mar 2006, Willem Riede wrote:
>
> Well, that's just your opinion. Mine is different. Sometimes I see a link in 
> a mail that I want to follow up on later. I don't need firefox jumping in my 
> face. Or a mail has an attachment I need to read - eventually. I'll open it 
> with openoffice so I don't forget. But I don't want its splash screen nor 
> window visible now.
>
> So there are different use cases, and at least an option will allow people to 
> select the behavior that best fits them. FWIW I'm not convinced the ideal 
> algorithm has been discovered, or is even possible, as if you ask me to 
> define when I want a new window to come up with focus and when not, the 
> answer is "that depends on what I want to do with it"...

Amen. Whether you want something to start focused or not depends 100% on 
what you want to do with it *at that moment*. With browsers this is easy:
just open up stuff in new tabs as you encounter interesting links, and 
then process the tabs eventually. The computer could never, ever know 
whether I want to read that link immediately or later so the decision has 
to be mine. Simple enough, left-click or middle-click.

Maybe this is just a crack idea from a caffeine deprived mind but what if 
left click meaned start with focus and middle click start without focus? 
It's kinda similar to the open in new tab-case from browsers and I think 
that concept has already shown it works and isn't beyond the grasp of the 
so called "average use" either ;)

 	- Panu -



From dragoran at feuerpokemon.de  Mon Mar 27 05:56:53 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 27 Mar 2006 07:56:53 +0200
Subject: FC5 weird raid issues
In-Reply-To: <5255-SnapperMsg827D11E1C04D0008@[68.27.157.67]>
References: <442423F7.7060100@feuerpokemon.de>	<1143370131.5480.0.camel@gilboa-work-dev>	<4426643E.10405@feuerpokemon.de>
	<5255-SnapperMsg827D11E1C04D0008@[68.27.157.67]>
Message-ID: <44277EA5.2030100@feuerpokemon.de>

Dax Kelson wrote:
> ...... Original Message .......
> On Sun, 26 Mar 2006 11:51:58 +0200 "dragoran" <dragoran at feuerpokemon.de> 
> wrote:
>   
>> I just deleted the raid and recreated it and now it seems to work fine.
>> (running FC5 with md raid now).
>> But the bug still needs to be fixed.
>> But I don't like to reinstall FC6 when its out upgrade from raid should 
>> work as it did before FC5.
>>     
>
> Are you using or have you ever used 'motherboard RAID' on the hard drive 
> you are installing to? 
>
> The reason I ask is because, new with FC5, if fake motherboard RAID 
> metadata is detected then dmraid is automatically activated and the 
> underlying physical partitions are 'hidden' so as to (properly) prevent 
> accidental direct writes to part of the RAID.
>  
> ___
> Dax Kelson
> Sent with my Treo
>
>   
no I never used bios raid on this mobo.



From dragoran at feuerpokemon.de  Mon Mar 27 05:58:11 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 27 Mar 2006 07:58:11 +0200
Subject: FC5 weird raid issues
In-Reply-To: <200603261512.20516.jarod@wilsonet.com>
References: <442423F7.7060100@feuerpokemon.de>	<1143370131.5480.0.camel@gilboa-work-dev>	<4426643E.10405@feuerpokemon.de>
	<200603261512.20516.jarod@wilsonet.com>
Message-ID: <44277EF3.904@feuerpokemon.de>

Jarod Wilson wrote:
> On Sunday 26 March 2006 01:51, dragoran wrote:
>   
>> Gilboa Davara wrote:
>>     
>>> On Fri, 2006-03-24 at 17:53 +0100, dragoran wrote:
>>>       
>>>> I have tryed to upgrade from FC4 -> FC5 using anaconda but it did not
>>>> detect my FC4 installation which is installed on /dev/md0.
>>>> It tryes to add a non raid partition to the array and ignores the raid
>>>> partition. This causes the initalisation of md0 to fail.
>>>> Is this a kernel or anaconda bug?
>>>> Bug report:
>>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312
>>>> (no reply ...)
>>>> So I backuped my data dan tryed a reinstall and it detected the md0
>>>> array in diskdruid but showed "foreign" as filesystem..
>>>> did edit and set mount point to / and filesystem ext3
>>>> but it failed formating it with a messages saying that it failed and
>>>> that I should press enter to reboot the system.
>>>> What happend? How could such things happen with a *final* release? Raid
>>>> support seems broken and nobody has noticed.
>>>> I always updated my system from RH9->FC1->FC2->FC3->FC4 (then
>>>> reinstalled FC4 because of i386->x86_64) but it seems that upgrade is no
>>>> more possible to FC5 :(
>>>>         
>>> I'd suggest you switch to console once Anaconda loads and mount the MD0
>>> by hand.
>>> It should give you a way to circumvent the bug.
>>>
>>> Gilboa
>>>       
>> I just deleted the raid and recreated it and now it seems to work fine.
>> (running FC5 with md raid now).
>> But the bug still needs to be fixed.
>> But I don't like to reinstall FC6 when its out upgrade from raid should
>> work as it did before FC5.
>>     
>
> I assure you upgrades from FC4 to FC5 on systems with md software raids were 
> tested and all worked without issue. It isn't that raid support is broken and 
> nobody noticed. Not sure why the failure in your particular case, but I've 
> done several upgrades myself without incident. Without being able to 
> reproduce the problem, fixing whatever went wrong on your system may prove 
> difficult, if not impossible.
>
>   
At least I have provided any possible infos that might help fixing the bug.



From jspaleta at gmail.com  Mon Mar 27 06:24:17 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 27 Mar 2006 01:24:17 -0500
Subject: FC5: first impressions
In-Reply-To: <Pine.LNX.4.62.0603262131490.3987@gotcha.dreamhost.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143385602l.19620l.3l@athena.riede.org>
	<Pine.LNX.4.62.0603262131490.3987@gotcha.dreamhost.com>
Message-ID: <604aa7910603262224t1de9660ck3e1ebb3fec768685@mail.gmail.com>

On 3/27/06, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> Maybe this is just a crack idea from a caffeine deprived mind but what if
> left click meaned start with focus and middle click start without focus?
> It's kinda similar to the open in new tab-case from browsers and I think
> that concept has already shown it works and isn't beyond the grasp of the
> so called "average use" either ;)

I'm personally holding out for the direct neural interface that I can jack into.

-jef"off to the tatoo parlor to get my 'google inside' forehead tatoo"spaleta



From rhally at mindspring.com  Mon Mar 27 07:49:41 2006
From: rhally at mindspring.com (Richard Hally)
Date: Mon, 27 Mar 2006 02:49:41 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143424049.3802.356.camel@sundaram.pnq.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>	
	<44273ECD.8010606@mindspring.com>
	<1143424049.3802.356.camel@sundaram.pnq.redhat.com>
Message-ID: <44279915.1040500@mindspring.com>

Rahul Sundaram wrote:
> On Sun, 2006-03-26 at 20:24 -0500, Richard Hally wrote:
>> Rahul Sundaram wrote:
>>> Hi
>>>
>>>
>>> Just to avoid the repeated bug reports and questions on it. Check out
>>> this page which is periodically updated. If there are other common
>>> issues to add, let me know. 
>>>
>>> http://fedoraproject.org/wiki/Bugs/FC5Common
>>>
>>> Rahul
>>>
>> Below are two older buggs about CD problems that are worked around by 
>> using "linux ide=nodma" to start an install. I needed to use this to 
>> install FC5 test3 on one of my boxes. It apparently is a kernel problem 
>> that has been hanging around for quite a while.
>>
>> Would this be appropriate for that Common Bugs page?
>>
>> Richard
>>
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150186
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135795
>>
> 
> I dont want to list all the bugs on that page. Just the common ones. I
> havent seen the above discussed anywhere in the lists or forums for FC5.
> So I think these arent common. Besides onne of these is filed against
> RHEL 4 and other one is closed as CANTFIX. I am not going to list these
> unless they are tracked under FC5. 
> 
> 
> Rahul
> 
> 
> 
see also bugs:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186512 FC5
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106685#c26 FC5
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177526#c3 FC5

and maybe this one from ESR
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186655

and this interesting bit from Alan Cox:
http://marc.theaimsgroup.com/?l=fedora-test-list&m=113299606007855&w=2

HTH
Richard



From buildsys at redhat.com  Mon Mar 27 08:08:22 2006
From: buildsys at redhat.com (Build System)
Date: Mon, 27 Mar 2006 03:08:22 -0500
Subject: rawhide report: 20060327 changes
Message-ID: <200603270808.k2R88MZG006960@porkchop.devel.redhat.com>

 

 
Updated Packages:

mgetty-1.1.33-7.FC5.3
---------------------
* Mon Mar 27 2006 Miloslav Trmac <mitr at redhat.com> - 1.1.33-7.FC5.3
- Change BuildPrereq from texinfo to texinfo-tex

texinfo-4.8-11
--------------
* Sat Mar 25 2006 Miloslav Trmac <mitr at redhat.com> - 4.8-11
- Split texinfo-tex from the texinfo package (#178406)
- Ship COPYING, don't ship INSTALL

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From redhat at olen.net  Mon Mar 27 08:22:31 2006
From: redhat at olen.net (Ola Thoresen)
Date: Mon, 27 Mar 2006 08:22:31 +0000 (UTC)
Subject: Open-link misbehavior
References: <1143424403.15323.31.camel@dimi> <1143430221.15323.55.camel@dimi>
Message-ID: <slrne2f867.23v.olen@lupus.olen.net>

2006-03-27 Dimi Paun <dimi at lattica.com> wrote
> On Sun, 2006-03-26 at 22:05 -0500, Willem Riede wrote:
>> I have to disappoint you. I positively love, love love this behavior.
>> Please do not assume everybody thinks like you do.
>
> Willem, I have clearly explained twice the problem. You didn't
> seem to have paid attention in both cases :) I did not complain
> about the opening of the link in a tab. This is a cool feature, 
> I agree. 
>
> I did complain about the fact that when the Firefox window is on a
> different desktop than Evolution (or any other app that tries to open a
> link for that matter), there is no feedback whatsoever about where it
> was opened! Is _this_ lack of feedback that you "positively love"?

Well, at least _I_ do.
I have one (and only one) Firefox _window_ open, with a lot of tabs -
and it is _always_ on desktop 3.  That way I don't have to "hunt" for
the most recent firefox window, because I always know where it is.  

This is a setting _I_ have chosen, and that _I_ feel make _me_ the most
productive, as all links opened from other applications are truly opened
in the background, and does not interfere with what I am currently
reading. And I can easily switch to desktop 3 whenever I am ready to
read the pages I opened.  (Usually, when I click on a link in I.E.
Evolutions, I want to finish reading the mail I was currently reading
before jumping to the webpage that was referenced - maybe I even want to
read a few more emails in the same thread.  So opening a new browser
window on top of the Evolution window (I will not engage in the debate
about opening new windows behind the current app here) would be quite
disturbing for _me_.

This woks for _me_ as I say, you might feel different about it, but it
is only an example showing that the behaviour is "right" for some people
- like myself.

Rgds.

Ola Thoresen



From Nigel.Metheringham at dev.intechnology.co.uk  Mon Mar 27 08:24:24 2006
From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham)
Date: Mon, 27 Mar 2006 09:24:24 +0100
Subject: Open-link misbehavior
In-Reply-To: <1143430221.15323.55.camel@dimi>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
	<1143428756l.26064l.0l@athena.riede.org>
	<1143430221.15323.55.camel@dimi>
Message-ID: <1143447864.2430.8.camel@angua.localnet>

On Sun, 2006-03-26 at 22:30 -0500, Dimi Paun wrote:
> On Sun, 2006-03-26 at 22:05 -0500, Willem Riede wrote:
> > I have to disappoint you. I positively love, love love this behavior.
> > Please do not assume everybody thinks like you do.
...
> I did complain about the fact that when the Firefox window is on a
> different desktop than Evolution (or any other app that tries to open a
> link for that matter), there is no feedback whatsoever about where it
> was opened! Is _this_ lack of feedback that you "positively love"?

The window list button flashes for me (but I do have the "Show all
workspaces..." preference set and a large vertical window list.  I
definitely do *not* want a new firefox window opening, or the current
one pulling to this workspace by default since my habit is to read mail
and stack up any urls to look at later rather than switch from one to
the other and back.

So I *am* happy with the current behaviour.   Except on the very rare
occasions when I'm not - and thats likely to last until the direct
neural hookup and DWIM interface is in place.

	Nigel.

-- 
[ Nigel Metheringham           Nigel.Metheringham at InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]



From benny+usenet at amorsen.dk  Mon Mar 27 08:48:53 2006
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: 27 Mar 2006 10:48:53 +0200
Subject: FC5: first impressions
References: <200603261214.k2QCE1ON018688@tiffany.internal.tigress.co.uk>
Message-ID: <m3fyl46znu.fsf@ursa.amorsen.dk>

>>>>> "RY" == Ron Yorston <rmy at tigress.co.uk> writes:

RY> The experimental strict focus approximation mode tries to prevent
RY> windows started from a hardcoded list of terminals from getting
RY> focus. In part it does this by putting the new window underneath
RY> the terminal, which lots of people find objectionable.

Focus and layering should be completely decoupled, then we could get
the window on top without giving it focus. Perhaps we could even get
rid of click-to-front at the same time.


/Benny




From gilboad at gmail.com  Mon Mar 27 10:21:43 2006
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 27 Mar 2006 12:21:43 +0200
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
Message-ID: <1143454903.773.4.camel@gilboa-work-dev>

On Mon, 2006-03-27 at 06:31 +0530, Rahul Sundaram wrote:
> Hi
> 
> 
> Just to avoid the repeated bug reports and questions on it. Check out
> this page which is periodically updated. If there are other common
> issues to add, let me know. 
> 
> http://fedoraproject.org/wiki/Bugs/FC5Common
> 
> Rahul
> 

Rahul,

I'd suggest you add broken gnome-pilot under GNOME desktop issues.
It'll save the next 15,000 bug-reports. (Last time I counted, there were
~20 open bugs about it on FC4 and FC5)

Gilboa



From Lam at Lam.pl  Mon Mar 27 10:22:52 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Mon, 27 Mar 2006 12:22:52 +0200
Subject: Open-link misbehavior
In-Reply-To: <1143431048.15323.58.camel@dimi>
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
	<1143428124.3802.378.camel@sundaram.pnq.redhat.com>
	<1143429815.15323.50.camel@dimi>
	<1143430574.3802.407.camel@sundaram.pnq.redhat.com>
	<1143431048.15323.58.camel@dimi>
Message-ID: <1143454972.2869.9.camel@pensja.lam.pl>

Dnia 26-03-2006, nie o godzinie 22:44 -0500, Dimi Paun napisa?(a):
> Point taken:
>     http://bugzilla.gnome.org/show_bug.cgi?id=336142
I even answered and provided some info, because your description is
slightly wrong if I'm right - please try to reproduce with your Firefox.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/d3c5ee79/attachment.sig>

From kzak at redhat.com  Mon Mar 27 10:39:34 2006
From: kzak at redhat.com (Karel Zak)
Date: Mon, 27 Mar 2006 12:39:34 +0200
Subject: smbfs not in the FC5 kernel?
In-Reply-To: <1143293039.5197.15.camel@localhost.localdomain>
References: <20060325134455.7167e6e7.j.rink@freenet.de>
	<1143291241.3802.297.camel@sundaram.pnq.redhat.com>
	<1143293039.5197.15.camel@localhost.localdomain>
Message-ID: <20060327103934.GC3037@petra.dvoda.cz>

On Sat, Mar 25, 2006 at 02:23:58PM +0100, Thorsten Leemhuis wrote:
> Am Samstag, den 25.03.2006, 18:24 +0530 schrieb Rahul Sundaram:
> > On Sat, 2006-03-25 at 13:44 +0100, J?rn Rink wrote:
> > > my old method to mount a smbfs filesystem does not work, further
> > > investigation shows, that the smbfs kernel module does not exist in the
> > > actual FC5 kernel.
> > > 
> > > Has the method changed? In fedora core 3 there was such a kernel module.
> > smbfs has been deprecated by CIFS. Try using that. 
> 
> Exactly.
> 
> <criticism mode> But why the heck are the Core developers simply closing
> #179451, #185363 and #186427 instead of reassigning the bug to
> util-linux? I suppose the maintainers of mount should be able to patch
> it somehow so it uses cifs automatically instead of the old smbmnt
> (which will fail due to missing smbfs support in the kernel). That would
> avoid a lot of confusion.</criticism mode>

 I know about this problem. The heuristic which map //server to 'cifs' (there
 is 'smbfs' now) will be available in the next util-linux update.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From camilo at mesias.co.uk  Mon Mar 27 11:17:48 2006
From: camilo at mesias.co.uk (Cam)
Date: Mon, 27 Mar 2006 12:17:48 +0100
Subject: Assignment of internet keys / media buttons
Message-ID: <4427C9DC.5020708@mesias.co.uk>

Hi,

I'd like to know where to report problems with key mappings.

On my hardware (Dell Inspiron 6000) there are 'media buttons' (mute, 
vol+/-, play, next, prev, stop) which are detected as keypresses with an 
unmapped keycode.

I can find the keycodes using xev, then I can map them to something 
useful using xmodmap, then compatible applications (eg. rhythmbox) do 
the right thing when the buttons are pressed.

The first problem is that the keys are initially unmapped; a secondary 
problem is that some controls (eg. volume popup) don't respond to the 
volume keys when they probably should.

So, where can I tell someone about this mapping? Which package needs 
some extra config? I should be able to provide a patch.

-Cam

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



From tla-ml at rasmil.dk  Mon Mar 27 10:43:39 2006
From: tla-ml at rasmil.dk (Tim Lauridsen)
Date: Mon, 27 Mar 2006 12:43:39 +0200
Subject: pup uncheck all
In-Reply-To: <4425A502.2090903@gmail.com>
References: <4425A502.2090903@gmail.com>
Message-ID: <4427C1DB.1080901@rasmil.dk>

Eric Mesa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pup sorely needs an uncheck-all button.  Right now I have a few
> packages that keep messing the whole process up since they depend on
> Xorg6 (since the packagers haven't updated the specs yet) so it's
> quite tedious to uncheck every single box that won't work.
>
> Thanks,
>
> - --
> Eric Mesa
> ericsbinaryworld at gmail.com
> http://www.ericsbinaryworld.com
> Note:  All emails from this address should have a GPG signature.  If
> you have the proper setup you can use this to confirm my identity and
> that the email was not changed in transit.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD4DBQFEJaUBPvU+8ApmWXIRAn4JAJ9L24Z+O4wvfK4C4fSuZY3hIDxwUQCYjLHs
> uC++RLpQXzGflJVSi5cgOw==
> =pdCe
> -----END PGP SIGNATURE-----
>
>   
You can use Yum Extender (yumex) it has this feature.

http://yumex.python-hosting.com

Tim Lauridsen



From mattdm at mattdm.org  Mon Mar 27 12:21:37 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 27 Mar 2006 07:21:37 -0500
Subject: CVS system migration done
In-Reply-To: <Pine.LNX.4.58.0603262248120.11932@devserv.devel.redhat.com>
References: <Pine.LNX.4.58.0603262248120.11932@devserv.devel.redhat.com>
Message-ID: <20060327122137.GA27091@jadzia.bu.edu>

On Sun, Mar 26, 2006 at 10:54:14PM -0500, Elliot Lee wrote:
> cvs.fedoraproject.org (aka cvs.fedora.redhat.com) has been migrated to a
> new system. Please let me know if there are any problems that need
> fixing...

$ make new-sources FILES="wxGTK-2.6.3.tar.bz2"

Checking : wxGTK-2.6.3.tar.bz2 on
https://cvs.fedora.redhat.com/repo/extras/upload.cgi...
ERROR: could not check remote file status
make: *** [new-sources] Error 255

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



From walovaton at yahoo.com.mx  Mon Mar 27 12:38:30 2006
From: walovaton at yahoo.com.mx (William Lovaton)
Date: Mon, 27 Mar 2006 06:38:30 -0600 (CST)
Subject: Fedora core for the Itanium
In-Reply-To: <44274ABC.5050208@redhat.com>
Message-ID: <20060327123830.45129.qmail@web60712.mail.yahoo.com>


 --- Tim Burke <tburke at redhat.com> escribi?:

> William Lovaton wrote:
> > But I'd like to test the ia64 box with a LiveCD or
> > something like that but I can't find one for this
> > arch.  Ubuntu says AMD64 but I guess that won't
> work
> > on Itanium, isn't it?  
> Correct.  AMD64 (x86-64) bits do not worn on
> itanium.
> > and FC5 doesn't have ia64
> > support on installable media.  How can I install
> FC5
> > on this itanium box?
> >   
> You can't.

How can I get test releases of RHEL 5 for testing
purposes?  When are the test releases planned? Is
there any relevant mailing list?

Now that I know there is Oracle support in Itanium I
can see the light at the end of the tunnel.  The funny
thing is that RHEL has Itanium support while Fedora
doesn't.  Shouldn't that be the other way around?

By the way, the server I am talking about is an HP
Integrity rx8620

Thanks for the answer,


-William



	
	
		
___________________________________________________________ 
Do You Yahoo!? 
La mejor conexi?n a Internet y <b >2GB</b> extra a tu correo por $100 al mes. http://net.yahoo.com.mx 



From Lam at Lam.pl  Mon Mar 27 12:44:18 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Mon, 27 Mar 2006 14:44:18 +0200
Subject: Assignment of internet keys / media buttons
In-Reply-To: <4427C9DC.5020708@mesias.co.uk>
References: <4427C9DC.5020708@mesias.co.uk>
Message-ID: <1143463458.2869.21.camel@pensja.lam.pl>

Dnia 27-03-2006, pon o godzinie 12:17 +0100, Cam napisa?(a):
> The first problem is that the keys are initially unmapped; a secondary 
> problem is that some controls (eg. volume popup) don't respond to the 
> volume keys when they probably should.
1. Write your modmaps to /etc/X11/Xmodmap. I use
add mod4 = Super_L
add mod4 = Super_R
because Super behavior is broken in Xorg since several years now (it was
long before XFree86 split), pity. I haven't found a way to do it via
GUI. The gnome-keyboard-properties dialog make it work if I go there and
click the option every time I log in. My CLI way is superior and I
recommend it.

2. Maybe offtopic, but I had a problem with volume controls not
responding because of bug in system-config-sound (there's a bug in
bugzilla for it). It breaks the default device in /etc/asound.conf under
some circumstances. If you have two sound cards, maybe that's the
cause :)

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/8f80cd59/attachment.sig>

From alan at redhat.com  Mon Mar 27 13:07:49 2006
From: alan at redhat.com (Alan Cox)
Date: Mon, 27 Mar 2006 08:07:49 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <44273ECD.8010606@mindspring.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
Message-ID: <20060327130749.GB24971@devserv.devel.redhat.com>

On Sun, Mar 26, 2006 at 08:24:29PM -0500, Richard Hally wrote:
> Below are two older buggs about CD problems that are worked around by 
> using "linux ide=nodma" to start an install. I needed to use this to 

It is random whether ide=nodma helps for disk checks. The only current solution
and one I've recommended since FC1 is to remove that feature from the 
distribution entirely.

> install FC5 test3 on one of my boxes. It apparently is a kernel problem 
> that has been hanging around for quite a while.

2004, but nobody cares. If you want to fix it go ahead. If not my guess is
that someone will have to fix it for the next Red Hat Enterprise Linux

> Would this be appropriate for that Common Bugs page?

Yes but the recommendation should be "never use the disk check feature"

Alan



From tburke at redhat.com  Mon Mar 27 13:20:32 2006
From: tburke at redhat.com (Tim Burke)
Date: Mon, 27 Mar 2006 08:20:32 -0500
Subject: Fedora core for the Itanium
In-Reply-To: <20060327123830.45129.qmail@web60712.mail.yahoo.com>
References: <20060327123830.45129.qmail@web60712.mail.yahoo.com>
Message-ID: <4427E6A0.9050403@redhat.com>

William Lovaton wrote:
>  
> How can I get test releases of RHEL 5 for testing
> purposes?  When are the test releases planned? 
Test releases for RHEL5 are not yet available.  They should be available 
in the summer.
> Is
> there any relevant mailing list?
>   
We'll post an invitation here.
> Now that I know there is Oracle support in Itanium I
> can see the light at the end of the tunnel.  The funny
> thing is that RHEL has Itanium support while Fedora
> doesn't.  Shouldn't that be the other way around?
>   
Fedora releases are driven by community interest and participation. 
Whereas RHEL releases are driven by business.  It is a lot of work to 
keep any release operational on a different architecture.  To date there 
hasn't been enough community interest and active involvement in order to 
get the job done.



From mattdm at mattdm.org  Mon Mar 27 15:16:48 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 27 Mar 2006 10:16:48 -0500
Subject: firstboot system maintenance task
In-Reply-To: <1143226822.2415.23.camel@dhcp-198.home.local>
References: <1143226822.2415.23.camel@dhcp-198.home.local>
Message-ID: <20060327151648.GA364@jadzia.bu.edu>

On Fri, Mar 24, 2006 at 11:00:21AM -0800, Florin Andrei wrote:
> After installing Fedora on any system, when the system boots up for the
> first time I always log in as root immediately, in a text-mode console
> (not via X), then run this sequence:
> killall anacron
> yum -y update

Just a side note -- you probably want 'yum -y upgrade' instead of update, in
case any of the updates has new Obsoletes. (Happens occasionally.)


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



From mattdm at mattdm.org  Mon Mar 27 15:18:40 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 27 Mar 2006 10:18:40 -0500
Subject: firstboot system maintenance task
In-Reply-To: <1143226822.2415.23.camel@dhcp-198.home.local>
References: <1143226822.2415.23.camel@dhcp-198.home.local>
Message-ID: <20060327151840.GB364@jadzia.bu.edu>

On Fri, Mar 24, 2006 at 11:00:21AM -0800, Florin Andrei wrote:
> After installing Fedora on any system, when the system boots up for the
> first time I always log in as root immediately, in a text-mode console
> (not via X), then run this sequence:
> killall anacron
> yum -y update
[...]

Oh, and also ---

> I just think it's a good idea and it's the best and shortest way to
> build a clean and up to date system out of a fresh install.
> 
> So I was thinking - perhaps it, or something equivalent - could be added
> as the last step to firstboot. Perhaps as a popup, informing the user
> that the system will apply all available updates, perform some
> maintenance tasks then reboot, and asking the user to either accept or
> reject it.

The plan is for Future Anaconda (maybe as soon as FC6?) to be able to
actually look at the updates repo in addition to the main repo while doing a
network install, making this unnecessary.

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



From dragoran at feuerpokemon.de  Mon Mar 27 15:35:25 2006
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 27 Mar 2006 17:35:25 +0200
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060327130749.GB24971@devserv.devel.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
Message-ID: <4428063D.1050109@feuerpokemon.de>

Alan Cox wrote:
> On Sun, Mar 26, 2006 at 08:24:29PM -0500, Richard Hally wrote:
>   
>> Below are two older buggs about CD problems that are worked around by 
>> using "linux ide=nodma" to start an install. I needed to use this to 
>>     
>
> It is random whether ide=nodma helps for disk checks. The only current solution
> and one I've recommended since FC1 is to remove that feature from the 
> distribution entirely.
>
>   
is this some kind of joke?
whe have a bug in progamm x... how should we fix it?
just drop the feature o.O ???
>> install FC5 test3 on one of my boxes. It apparently is a kernel problem 
>> that has been hanging around for quite a while.
>>     
>
> 2004, but nobody cares. If you want to fix it go ahead. If not my guess is
> that someone will have to fix it for the next Red Hat Enterprise Linux
>
>   
>> Would this be appropriate for that Common Bugs page?
>>     
>
> Yes but the recommendation should be "never use the disk check feature"
>   
see above...
> Alan
>
>   



From alan at redhat.com  Mon Mar 27 15:46:09 2006
From: alan at redhat.com (Alan Cox)
Date: Mon, 27 Mar 2006 10:46:09 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <4428063D.1050109@feuerpokemon.de>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<4428063D.1050109@feuerpokemon.de>
Message-ID: <20060327154609.GB5226@devserv.devel.redhat.com>

On Mon, Mar 27, 2006 at 05:35:25PM +0200, dragoran wrote:
> >It is random whether ide=nodma helps for disk checks. The only current 
> >solution
> >and one I've recommended since FC1 is to remove that feature from the 
> >distribution entirely.
> >
> is this some kind of joke?
> whe have a bug in progamm x... how should we fix it?

You rewrite the error handling and error propogation layer for the Linux
kernel VM. Contributiosn welcomed.



From dwalsh at redhat.com  Mon Mar 27 16:03:49 2006
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Mon, 27 Mar 2006 11:03:49 -0500
Subject: selinux-policy-targeted-2.2.26-1 update failed
In-Reply-To: <1143321367.14370.3.camel@localhost.localdomain>
References: <1143316951.4425a1d750bff@www.jouy.inra.fr>	<4425A30E.4020300@mindspring.com>	<1143319749.4425acc59c729@www.jouy.inra.fr>
	<1143321367.14370.3.camel@localhost.localdomain>
Message-ID: <44280CE5.8010802@redhat.com>

David Nielsen wrote:
> l?r, 25 03 2006 kl. 21:49 +0100, skrev ?meric Maschino:
>   
>> Hi Richard,
>>
>>     
>>> check to make sure you have libselinux installed.
>>> After todays update from rawhide, I have libselinux-1.30-1.
>>> HTH
>>>       
>> Where did you get this package? After today update, I have libselinux-1.12.2-1
>> and selinux-policy-*-2.2.26-1. This is on an Itanium workstation (Fedora ia64
>> flavour).
>>
>> Thanks for your advice anyway.
>>
>>    ?meric
>>
>> PS: As a workaround, I ran in permissive mode, so that all the packages are
>> updated correctly. But now, there are a lot of AVCs in /var/log/messages and
>> /var/log/audit/audit.log
>>     
>
> Yep, something about todays SELinux update seems to have made
> Development live up to it's baby eating reputation.
>
> - David
>   
YES todays Rawhide is very broken.  We are investigating the problem.  I 
would avoid updating to rawhide, if you have not yet.




From katzj at redhat.com  Mon Mar 27 16:49:40 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 27 Mar 2006 11:49:40 -0500
Subject: Bootsplash?
In-Reply-To: <1143248242.28002.21.camel@localhost>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<1143248242.28002.21.camel@localhost>
Message-ID: <1143478181.4785.51.camel@orodruin.boston.redhat.com>

On Fri, 2006-03-24 at 18:57 -0600, Callum Lerwick wrote:
> loop bug I hit...) If you boot with a mismatching kernel, suspend2 will
> warn you and ask you before it blows away your suspend image, giving you
> a chance to restart with the right kernel.

We could conceivably do something like this with what we have now -- the
problem is that you can't (sanely) do it in the user's native language
or keyboard layout :-/

Jeremy



From katzj at redhat.com  Mon Mar 27 17:00:05 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 27 Mar 2006 12:00:05 -0500
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
	<1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
Message-ID: <1143478805.4785.54.camel@orodruin.boston.redhat.com>

On Sun, 2006-03-26 at 19:37 +0100, Joe Desbonnet wrote:
> 2. After FC5 install I no longer have use of my built in bluetooth device.

The updates-testing selinux policy should be happier for bluetooth
devices.

> 3. After a few reboots I lose things like battery gauge
> (/proc/acpi/battery directory gone!). This seems to correspond to
> kudzu related errors on boot. I'm sorry -- I didn't capture the exact
> text of the error at the time. I encountered this type of problem
> before where kudzu failed at boot time and made a mess things. I can
> reinstall FC5 and get that error message if it is going to be useful.

That's ... interesting.  Definitely haven't seen anything like that.

> 4. Suspend does not work (no surprise there). Blank flickering LCD
> screen on restore. This never worked, so I'm not too concerned about
> it.

You might find that acpi_sleep=s3_bios on the kernel command line might
fix this.

> 5. Not a Thinkpad issue per se: When installing FC5Test3 on VMWare 
> the BusLogic module had to be manually loaded. This was not required
> during the FC4 install -- it was autodetected there. At the time I
> thought that was a VMWare issue, now I suspect otherwise...

The BusLogic module doesn't export PCI ids it supports and is pretty
much unmaintained upstream.  VMWare can also be configured to have a
virtual mptfusion scsi instead, which will work much better.

Jeremy



From katzj at redhat.com  Mon Mar 27 17:05:28 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 27 Mar 2006 12:05:28 -0500
Subject: firstboot system maintenance task
In-Reply-To: <20060327151648.GA364@jadzia.bu.edu>
References: <1143226822.2415.23.camel@dhcp-198.home.local>
	<20060327151648.GA364@jadzia.bu.edu>
Message-ID: <1143479129.4785.58.camel@orodruin.boston.redhat.com>

On Mon, 2006-03-27 at 10:16 -0500, Matthew Miller wrote:
> On Fri, Mar 24, 2006 at 11:00:21AM -0800, Florin Andrei wrote:
> > After installing Fedora on any system, when the system boots up for the
> > first time I always log in as root immediately, in a text-mode console
> > (not via X), then run this sequence:
> > killall anacron
> > yum -y update
> 
> Just a side note -- you probably want 'yum -y upgrade' instead of update, in
> case any of the updates has new Obsoletes. (Happens occasionally.)

The difference is moot since we set obsoletes=1 in /etc/yum.conf :)

Jeremy



From billcrawford1970 at gmail.com  Mon Mar 27 17:18:04 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Mon, 27 Mar 2006 17:18:04 +0000
Subject: FC5: first impressions
In-Reply-To: <Pine.LNX.4.62.0603262131490.3987@gotcha.dreamhost.com>
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143385602l.19620l.3l@athena.riede.org>
	<Pine.LNX.4.62.0603262131490.3987@gotcha.dreamhost.com>
Message-ID: <200603271818.06369.billcrawford1970@googlemail.com>

On Monday 27 March 2006 06:48, Panu Matilainen wrote:

> Maybe this is just a crack idea from a caffeine deprived mind but what if
> left click meaned start with focus and middle click start without focus?
> It's kinda similar to the open in new tab-case from browsers and I think
> that concept has already shown it works and isn't beyond the grasp of the
> so called "average use" either ;)

 No, that's the exact same caffeine-fueled crazy idea I had :)

 That's a good suggestion.



From jarod at wilsonet.com  Mon Mar 27 17:17:49 2006
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 27 Mar 2006 09:17:49 -0800
Subject: FC5 weird raid issues
In-Reply-To: <5255-SnapperMsg827D11E1C04D0008@[68.27.157.67]>
References: <442423F7.7060100@feuerpokemon.de> <4426643E.10405@feuerpokemon.de>
	<5255-SnapperMsg827D11E1C04D0008@[68.27.157.67]>
Message-ID: <200603270917.53027.jarod@wilsonet.com>

On Sunday 26 March 2006 18:35, Dax Kelson wrote:
> On Sun, 26 Mar 2006 11:51:58 +0200 "dragoran" wrote:
> >I just deleted the raid and recreated it and now it seems to work fine.
> >(running FC5 with md raid now).
> >But the bug still needs to be fixed.
> >But I don't like to reinstall FC6 when its out upgrade from raid should
> >work as it did before FC5.
>
> Are you using or have you ever used 'motherboard RAID' on the hard drive
> you are installing to?
>
> The reason I ask is because, new with FC5, if fake motherboard RAID
> metadata is detected then dmraid is automatically activated and the
> underlying physical partitions are 'hidden' so as to (properly) prevent
> accidental direct writes to part of the RAID.

And this gets REALLY fun if you have a drive or two that you forgot was at one 
time used as part of a fake raid on one board with one type of controller, 
then try to set it up as part of a fake raid on a different board with a 
different type of controller, since there doesn't seem to be any easy way to 
get the metadata out of there, short of putting the drive(s) back on the old 
controller to destroy the raid.

Otherwise, you wind up with multiple fake raid metadata formats on the drive, 
and dmraid doesn't know which one to use (in my case, I wound up with both 
nvidia and sil metadata on some drives, and the kernel kept trying to use the 
wrong metadata).

Not to mention that fake raid10 doesn't quite work yet... :)

Ah yes, and if you want the metadata to be ignored altogether at install time, 
just pass 'nodmraid' as a boot option. Certainly better to get the fake raid 
metadata off though, if possible.

-- 
Jarod Wilson
jarod at wilsonet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/c1d0a12c/attachment.sig>

From overholt at redhat.com  Mon Mar 27 17:23:16 2006
From: overholt at redhat.com (Andrew Overholt)
Date: Mon, 27 Mar 2006 12:23:16 -0500
Subject: GUI controls for instrumentation
In-Reply-To: <1143281498.4018.6.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
Message-ID: <20060327172315.GE19155@redhat.com>

* Nicolas Mailhot <nicolas.mailhot at laposte.net> [2006-03-25 05:12]:
> On the client part it's a shockingly bad idea (and I include applets
> there). Googling will find you boatloads of apps that choose java for
> portability and still can not run on anything else than windows, because
> just deploying the right JVM on all the systems you may target is a
> major problem (and I'm not even counting the free stacks there).
> 
> If it where that easy, we'd have the latest eclipse version in Fedora
> with all the major plugins instead of the current situation.

Perhaps I'm missing context here, but I sense an implication that something
is wrong with "the current situation".  Am I correct?

Andrew



From jarod at wilsonet.com  Mon Mar 27 17:29:42 2006
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 27 Mar 2006 09:29:42 -0800
Subject: FC5 weird raid issues
In-Reply-To: <44277EF3.904@feuerpokemon.de>
References: <442423F7.7060100@feuerpokemon.de>
	<200603261512.20516.jarod@wilsonet.com>
	<44277EF3.904@feuerpokemon.de>
Message-ID: <200603270929.45727.jarod@wilsonet.com>

On Sunday 26 March 2006 21:58, dragoran wrote:
[...]
> >> I just deleted the raid and recreated it and now it seems to work fine.
> >> (running FC5 with md raid now).
> >> But the bug still needs to be fixed.
> >> But I don't like to reinstall FC6 when its out upgrade from raid should
> >> work as it did before FC5.
> >
> > I assure you upgrades from FC4 to FC5 on systems with md software raids
> > were tested and all worked without issue. It isn't that raid support is
> > broken and nobody noticed. Not sure why the failure in your particular
> > case, but I've done several upgrades myself without incident. Without
> > being able to reproduce the problem, fixing whatever went wrong on your
> > system may prove difficult, if not impossible.
>
> At least I have provided any possible infos that might help fixing the bug.

True. I'm merely trying to convey that this isn't something where software 
raid was shipped utterly broken, this was an apparent edge case, and thus it 
may prove difficult to track down or even test a fix.

-- 
Jarod Wilson
jarod at wilsonet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/a6c2d99b/attachment.sig>

From shiva at sewingwitch.com  Mon Mar 27 17:46:45 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Mon, 27 Mar 2006 09:46:45 -0800
Subject: GUI controls for instrumentation
In-Reply-To: <200603242033.03945.lamont@gurulabs.com>
References: <132A9F5E12B8828DA6ED8E85@[10.169.6.226]>
	<200603242033.03945.lamont@gurulabs.com>
Message-ID: <341C0E6AB66D9D5604ABDF9A@[10.0.0.14]>

--On Friday, March 24, 2006 8:33 PM -0700 "Lamont R. Peterson" 
<lamont at gurulabs.com> wrote:

> Trust me, I've written enough code in various languages and using various
> frameworks and toolkits to know that when you want stable, simple,
> reliable  cross-platform code, Qt is excellent.

I was looking at Qt. The developer license is pricey but probably doable. 
What does it provide for the kinds of controls I mentioned? Do you know of 
any demo apps I can look at that illustrate how well they function?

As an example of the kind of app I'm thinking of, consider a model train 
control panel which can control the speeds of various locomotives and 
report track conditions in real time (eg. graphing the impedance of the 
tracks).

For an example of the kinds of controls I'm looking for, National 
Instruments' Measurement Studio is an instrumentation GUI control library:

<http://www.ni.com/mstudio/>

And as you can see, there's no Linux port.




From denis at poolshark.org  Mon Mar 27 17:49:59 2006
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 27 Mar 2006 09:49:59 -0800
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
Message-ID: <442825C7.4020608@poolshark.org>

Rahul Sundaram wrote:
> Hi
> 
> 
> Just to avoid the repeated bug reports and questions on it. Check out
> this page which is periodically updated. If there are other common
> issues to add, let me know. 

A major issue for me was the very poor Xorg support for radeon-based
Thinkpads (in our case, T30s and T40s). Dual-head support, or even
external monitor support at a higher resolution, which both worked fine
in FC3 and FC4, stopped working for FC5 which leaves a bitter taste
about the so-called improvements of the Xorg project (though i'm hoping
it's just a system-config-display bug). Several bugs already exists in
bugzilla, including one with a work-around :

https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=126415

-denis




From dimi at lattica.com  Mon Mar 27 17:51:18 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 27 Mar 2006 12:51:18 -0500
Subject: GUI controls for instrumentation
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226><200603242033.03945.lamont@gurulabs.com><1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com><1143281498.4018.6.camel@rousalka.dyndns.org>
	<20060327172315.GE19155@redhat.com>
Message-ID: <010501c651c7$0e9d7620$b6491b31@td612671>

From: "Andrew Overholt" <overholt at redhat.com>
> Perhaps I'm missing context here, but I sense an implication that
something
> is wrong with "the current situation".  Am I correct?

Well, now that you mention it... :)
If I point the native Eclipse to one of my workspaces
that I created (and worked in) with the Java Eclipse,
it doesn't recognize it as a workspace at all, and
gives me the Welcome screen.

Trying to "Switch workspace" from the File menu has
the same effect. What gives?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From overholt at redhat.com  Mon Mar 27 17:53:53 2006
From: overholt at redhat.com (Andrew Overholt)
Date: Mon, 27 Mar 2006 12:53:53 -0500
Subject: GUI controls for instrumentation
In-Reply-To: <010501c651c7$0e9d7620$b6491b31@td612671>
References: <20060327172315.GE19155@redhat.com>
	<010501c651c7$0e9d7620$b6491b31@td612671>
Message-ID: <20060327175353.GH19155@redhat.com>

* Dimi Paun <dimi at lattica.com> [2006-03-27 12:51]:
> From: "Andrew Overholt" <overholt at redhat.com>
> > Perhaps I'm missing context here, but I sense an implication that
> > something is wrong with "the current situation".  Am I correct?
> 
> Well, now that you mention it... :)
> If I point the native Eclipse to one of my workspaces that I created (and
> worked in) with the Java Eclipse, it doesn't recognize it as a workspace
> at all, and gives me the Welcome screen.

That's odd.  I've never seen this behaviour before.  Please file a bug.

Andrew



From dimi at lattica.com  Mon Mar 27 18:16:29 2006
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 27 Mar 2006 13:16:29 -0500
Subject: GUI controls for instrumentation
References: <20060327172315.GE19155@redhat.com>
	<010501c651c7$0e9d7620$b6491b31@td612671>
	<20060327175353.GH19155@redhat.com>
Message-ID: <015701c651ca$924f6c00$b6491b31@td612671>

From: "Andrew Overholt" <overholt at redhat.com>
> That's odd.  I've never seen this behaviour before.  Please file a bug.

Here you go:
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186958

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From florin at andrei.myip.org  Mon Mar 27 18:18:13 2006
From: florin at andrei.myip.org (Florin Andrei)
Date: Mon, 27 Mar 2006 10:18:13 -0800
Subject: firstboot system maintenance task
In-Reply-To: <20060327151840.GB364@jadzia.bu.edu>
References: <1143226822.2415.23.camel@dhcp-198.home.local>
	<20060327151840.GB364@jadzia.bu.edu>
Message-ID: <1143483493.2480.11.camel@rivendell.home.local>

On Mon, 2006-03-27 at 10:18 -0500, Matthew Miller wrote:

> The plan is for Future Anaconda (maybe as soon as FC6?) to be able to
> actually look at the updates repo in addition to the main repo while doing a
> network install, making this unnecessary.

That's very nice and it covers a large portion of my request. Thanks.

-- 
Florin Andrei

http://florin.myip.org/



From davej at redhat.com  Mon Mar 27 18:23:23 2006
From: davej at redhat.com (Dave Jones)
Date: Mon, 27 Mar 2006 13:23:23 -0500
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <ufapsk8h41m.fsf@epithumia.math.uh.edu>
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060324202627.GD2725@redhat.com>
	<ufapsk8h41m.fsf@epithumia.math.uh.edu>
Message-ID: <20060327182323.GB16210@redhat.com>

On Sun, Mar 26, 2006 at 11:04:05PM -0600, Jason L Tibbitts III wrote:
 > >>>>> "DJ" == Dave Jones <davej at redhat.com> writes:
 > 
 > DJ> really ? I was under the impression that all the SMP capable C3's
 > DJ> were Nehemiah cores, which are 686 capable.
 > 
 > Well:
 > 
 > > cat /proc/cpuinfo
 > processor       : 0
 > vendor_id       : CentaurHauls
 > cpu family      : 6
 > model           : 9
 > model name      : VIA Nehemiah
 > stepping        : 10
 > cpu MHz         : 997.370
 > cache size      : 64 KB
 > fdiv_bug        : no
 > hlt_bug         : no
 > f00f_bug        : no
 > coma_bug        : no
 > fpu             : yes
 > fpu_exception   : yes
 > cpuid level     : 1
 > wp              : yes
 > flags           : fpu vme de pse tsc msr cx8 apic mtrr pge cmov pat
 > mmx fxsr sse rng rng_en ace ace_en
 > bogomips        : 1998.41
 > 
 > (plus another identical CPU)

ok, that's definitly 686 class (complete with the optional cmov extension).

 > FC5 doesn't install a SMP kernel on this machine

sounds like an installer bug.

 > , and installing the
 > shipped SMP kernel results in something that spews a few thousand
 > identical messages about unhandled interrupts and then reboots.

that'll be a kernel bug ;)

 > I'll be happy to provide more info if there's any data you'd like for me to
 > collect.
 > 
 > I built 2.6.16-1.2070_FC5 with a custom i586-smp kernel that sets
 > CONFIG_MVIAC3_2 and it runs fine.

I'll see if I can figure out what could be causing the difference
(and try and get hold of a similar system to reproduce on)

 > DJ> that should be it, unless I've forgotten something.
 > Yep, that worked.  (I eventually figured it out during the mailing
 > list delay.)  Is there any possibility of getting some of these
 > alternate kernels into the base SRPM?  It might be useful to have them
 > built for extras.

I'd rather the 686-smp kernel 'just worked'.

		Dave

-- 
http://www.codemonkey.org.uk



From jdesbonnet at gmail.com  Mon Mar 27 18:52:16 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Mon, 27 Mar 2006 19:52:16 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <341C0E6AB66D9D5604ABDF9A@10.0.0.14>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<341C0E6AB66D9D5604ABDF9A@10.0.0.14>
Message-ID: <1cef3e950603271052n5c967395g56e88b5f523a9309@mail.gmail.com>

If your application needs an update rate of less than 1Hz (ie one
second or more between updates) consider SVG:

Take a look at these real time instrumentation demos from WPS Energy:
http://www.wpsenergy.com/JayNick/default.asp

Also:
http://www.anomaly.org/wade/projects/instruments/Instruments.svg

Advantage of SVG is that it's a thin client solution: ie you just need
IE + SVG Plugin or just Firefox 1.5+

Joe.


On 3/27/06, Kenneth Porter <shiva at sewingwitch.com> wrote:
> --On Friday, March 24, 2006 8:33 PM -0700 "Lamont R. Peterson"
> <lamont at gurulabs.com> wrote:
>
> > Trust me, I've written enough code in various languages and using various
> > frameworks and toolkits to know that when you want stable, simple,
> > reliable  cross-platform code, Qt is excellent.
>
> I was looking at Qt. The developer license is pricey but probably doable.
> What does it provide for the kinds of controls I mentioned? Do you know of
> any demo apps I can look at that illustrate how well they function?
>
> As an example of the kind of app I'm thinking of, consider a model train
> control panel which can control the speeds of various locomotives and
> report track conditions in real time (eg. graphing the impedance of the
> tracks).
>
> For an example of the kinds of controls I'm looking for, National
> Instruments' Measurement Studio is an instrumentation GUI control library:
>
> <http://www.ni.com/mstudio/>
>
> And as you can see, there's no Linux port.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From shiva at sewingwitch.com  Mon Mar 27 19:03:15 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Mon, 27 Mar 2006 11:03:15 -0800
Subject: GUI controls for instrumentation
In-Reply-To: <1cef3e950603271052n5c967395g56e88b5f523a9309@mail.gmail.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<341C0E6AB66D9D5604ABDF9A@10.0.0.14>
	<1cef3e950603271052n5c967395g56e88b5f523a9309@mail.gmail.com>
Message-ID: <979326941D773AD2030E0B97@[10.169.6.226]>

On Monday, March 27, 2006 7:52 PM +0100 Joe Desbonnet 
<jdesbonnet at gmail.com> wrote:

> Advantage of SVG is that it's a thin client solution: ie you just need
> IE + SVG Plugin or just Firefox 1.5+

Does SVG do 3D? I tried a few of the examples and they all looked flat. 
That's not a problem for me personally, but the PHB's love the pretty 
gizmos, and that's who I'm shopping for. (I'm the guy who looks closely at 
the screenshots in reviews to see what's actually happening, instead of 
which has the prettier control set. For my own use, I buy for 
functionality, not looks. Even in games.)



From nicolas.mailhot at laposte.net  Mon Mar 27 19:11:24 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 27 Mar 2006 21:11:24 +0200
Subject: GUI controls for instrumentation
In-Reply-To: <20060327172315.GE19155@redhat.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<20060327172315.GE19155@redhat.com>
Message-ID: <1143486684.19856.4.camel@rousalka.dyndns.org>

Le lundi 27 mars 2006 ? 12:23 -0500, Andrew Overholt a ?crit :
> * Nicolas Mailhot <nicolas.mailhot at laposte.net> [2006-03-25 05:12]:
> > On the client part it's a shockingly bad idea (and I include applets
> > there). Googling will find you boatloads of apps that choose java for
> > portability and still can not run on anything else than windows, because
> > just deploying the right JVM on all the systems you may target is a
> > major problem (and I'm not even counting the free stacks there).
> > 
> > If it where that easy, we'd have the latest eclipse version in Fedora
> > with all the major plugins instead of the current situation.
> 
> Perhaps I'm missing context here, but I sense an implication that something
> is wrong with "the current situation".  Am I correct?

The current situation is good but could be better. Lots of Eclipse stuff
is not packaged right now (WTP...). Though it's no fault of the
packagers, just that's there is a wide gap between writing and deploying
sanely java code on the desktop.

The Fedora java project is doing great stuff, given what they have as
input.

Regards,

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

From jdesbonnet at gmail.com  Mon Mar 27 19:11:24 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Mon, 27 Mar 2006 20:11:24 +0100
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <442825C7.4020608@poolshark.org>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
Message-ID: <1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>

The Thinkpad seems to be cropping up alot in bug reports... after a
lot of sweat and tears I have regained most of my Thinkpad's
functionality since the upgrade (actually a fresh install repeated
several times). However I am partly to blame: I should have tried to
install the test releases and filed the bug reports early.

Laptops are the most problematic hardware but they are probably the
least tested because installing test releases can be very awkward:
Laptops tend to have small disks. That is further reduced by that
partition for the  "Other" operating system which we were forced to
buy. So there isn't much left for a third experimental operating
system.

One solution I can think of: facilitate installation on a USB disk.

Another solution which will probably take too much work: make some
sort of LiveCD with sufficient functionality to test all the hardware
compatibility.

Joe.


On 3/27/06, Denis Leroy <denis at poolshark.org> wrote:
> Rahul Sundaram wrote:
> > Hi
> >
> >
> > Just to avoid the repeated bug reports and questions on it. Check out
> > this page which is periodically updated. If there are other common
> > issues to add, let me know.
>
> A major issue for me was the very poor Xorg support for radeon-based
> Thinkpads (in our case, T30s and T40s). Dual-head support, or even
> external monitor support at a higher resolution, which both worked fine
> in FC3 and FC4, stopped working for FC5 which leaves a bitter taste
> about the so-called improvements of the Xorg project (though i'm hoping
> it's just a system-config-display bug). Several bugs already exists in
> bugzilla, including one with a work-around :
>
> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=126415
>
> -denis
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From notting at redhat.com  Mon Mar 27 19:24:27 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 27 Mar 2006 14:24:27 -0500
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
	<1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
Message-ID: <20060327192426.GC7363@devserv.devel.redhat.com>

Joe Desbonnet (jdesbonnet at gmail.com) said: 
> 1. During install and after install I no longer had use of my 3Com
> 3CRWE737A 802.11b PC Card (this worked with FC4,3,2,1). This card is
> handled by the orinoco dirver. Even force loading the driver did not
> bring this card to life. I do not think it is a kernel issue -- a grep
> of  "3CRWE737A" on orinoco_cs.ko demonstrates that support for this
> card is still in the kernel.
> The /etc/sysconfig/hwconf entry from FC4 reads:
> class: NETWORK
> bus: PCMCIA
> detached: 0
> device: eth2
> driver: orinoco_cs
> desc: "3Com 3CRWE737A AirConnect Wireless LAN PC Card"
> vendorId: 0101
> deviceId: 0001
> function: 0
> slot: 0

Try either:

blacklist hostap_cs

or

blacklist orinoco_cs

in /etc/modprobe.d/blacklist.

That may fix things.

> 3. After a few reboots I lose things like battery gauge
> (/proc/acpi/battery directory gone!). This seems to correspond to
> kudzu related errors on boot. I'm sorry -- I didn't capture the exact
> text of the error at the time. I encountered this type of problem
> before where kudzu failed at boot time and made a mess things. I can
> reinstall FC5 and get that error message if it is going to be useful.

That really doesn't make sense... nothing kudzu does would
cause ACPI modules to not get loaded.

Bill



From jdesbonnet at gmail.com  Mon Mar 27 19:27:51 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Mon, 27 Mar 2006 20:27:51 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <979326941D773AD2030E0B97@10.169.6.226>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<341C0E6AB66D9D5604ABDF9A@10.0.0.14>
	<1cef3e950603271052n5c967395g56e88b5f523a9309@mail.gmail.com>
	<979326941D773AD2030E0B97@10.169.6.226>
Message-ID: <1cef3e950603271127v60a19823h89323af0dc150537@mail.gmail.com>

I would image that 3D effects (drop shadows, beveled edges etc) are
possible.  The downside of SVG is that it's all relatively new and
products/libraries are not that common. If you are pitching to a
conservative client (military type people for example) you don't want
to take risks with the technology.

Another thin client option I mentioned in an earlier post is VNC: you
can run the application on the server and just use VNC protocol to
update a VNC display. Ideal if the thin clients are on a high
bandwidth LAN.

If you want a fat client with portability: my personal preferences
would be Java (SWT or Swing). It sounds like your application is going
to be deployed on a controled environment, so I don't think Java would
be a problem. If C++ is your language of choice I would agree with one
of the previous posters -- you will not go wrong with Qt.

Joe.

On 3/27/06, Kenneth Porter <shiva at sewingwitch.com> wrote:
> On Monday, March 27, 2006 7:52 PM +0100 Joe Desbonnet
> <jdesbonnet at gmail.com> wrote:
>
> > Advantage of SVG is that it's a thin client solution: ie you just need
> > IE + SVG Plugin or just Firefox 1.5+
>
> Does SVG do 3D? I tried a few of the examples and they all looked flat.
> That's not a problem for me personally, but the PHB's love the pretty
> gizmos, and that's who I'm shopping for. (I'm the guy who looks closely at
> the screenshots in reviews to see what's actually happening, instead of
> which has the prettier control set. For my own use, I buy for
> functionality, not looks. Even in games.)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From tromey at redhat.com  Mon Mar 27 19:23:58 2006
From: tromey at redhat.com (Tom Tromey)
Date: 27 Mar 2006 12:23:58 -0700
Subject: GUI controls for instrumentation
In-Reply-To: <1143486684.19856.4.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<20060327172315.GE19155@redhat.com>
	<1143486684.19856.4.camel@rousalka.dyndns.org>
Message-ID: <m34q1jzo6o.fsf@localhost.localdomain>

>>>>> "Nicolas" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:

Nicolas> The current situation is good but could be better. Lots of
Nicolas> Eclipse stuff is not packaged right now (WTP...). Though it's
Nicolas> no fault of the packagers, just that's there is a wide gap
Nicolas> between writing and deploying sanely java code on the
Nicolas> desktop.

Eclipse plugins are particularly a pain to build, I think more than
ordinary java programs.

I end up installing some plugins I like via the update sites.  This is
not super convenient, since it means I have another few hoops to jump
through after installing FC, but it isn't terrible.

Nicolas> The Fedora java project is doing great stuff, given what they have as
Nicolas> input.

Thanks :-)

Tom



From jdesbonnet at gmail.com  Mon Mar 27 19:34:03 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Mon, 27 Mar 2006 20:34:03 +0100
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <20060327192426.GC7363@devserv.devel.redhat.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
	<1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
	<20060327192426.GC7363@devserv.devel.redhat.com>
Message-ID: <1cef3e950603271134t692cd762p7acd9436bb3caa3c@mail.gmail.com>

I haven't tracked this down fully, but the kudzu error seems related to
/lib/modules/(kernel-version)/modules.dep being reduced to a zero byte
file (I don't know that caused that).

With the zero byte modules.dep file kudzu segfaults.

Joe.


> > 3. After a few reboots I lose things like battery gauge
> > (/proc/acpi/battery directory gone!). This seems to correspond to
> > kudzu related errors on boot. I'm sorry -- I didn't capture the exact
> > text of the error at the time. I encountered this type of problem
> > before where kudzu failed at boot time and made a mess things. I can
> > reinstall FC5 and get that error message if it is going to be useful.
>
> That really doesn't make sense... nothing kudzu does would
> cause ACPI modules to not get loaded.
>
> Bill
>



From notting at redhat.com  Mon Mar 27 19:38:57 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 27 Mar 2006 14:38:57 -0500
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <1cef3e950603271134t692cd762p7acd9436bb3caa3c@mail.gmail.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
	<1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
	<20060327192426.GC7363@devserv.devel.redhat.com>
	<1cef3e950603271134t692cd762p7acd9436bb3caa3c@mail.gmail.com>
Message-ID: <20060327193857.GH7363@devserv.devel.redhat.com>

Joe Desbonnet (jdesbonnet at gmail.com) said: 
> I haven't tracked this down fully, but the kudzu error seems related to
> /lib/modules/(kernel-version)/modules.dep being reduced to a zero byte
> file (I don't know that caused that).
> 
> With the zero byte modules.dep file kudzu segfaults.

Hm, ok, will look at fixing that. That would also break
modprobe of many things, but that's unrelated to kudzu
breaking.

Bill



From notting at redhat.com  Mon Mar 27 19:43:22 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 27 Mar 2006 14:43:22 -0500
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <20060327193857.GH7363@devserv.devel.redhat.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
	<1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
	<20060327192426.GC7363@devserv.devel.redhat.com>
	<1cef3e950603271134t692cd762p7acd9436bb3caa3c@mail.gmail.com>
	<20060327193857.GH7363@devserv.devel.redhat.com>
Message-ID: <20060327194322.GI7363@devserv.devel.redhat.com>

Bill Nottingham (notting at redhat.com) said: 
> Joe Desbonnet (jdesbonnet at gmail.com) said: 
> > I haven't tracked this down fully, but the kudzu error seems related to
> > /lib/modules/(kernel-version)/modules.dep being reduced to a zero byte
> > file (I don't know that caused that).
> > 
> > With the zero byte modules.dep file kudzu segfaults.
> 
> Hm, ok, will look at fixing that.

Fixed in CVS. Won't help modprobe, though.

Bill



From esr at thyrsus.com  Mon Mar 27 20:24:57 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 27 Mar 2006 15:24:57 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
Message-ID: <20060327202457.GA15056@thyrsus.com>

Joe Desbonnet <jdesbonnet at gmail.com>:
> The Thinkpad seems to be cropping up alot in bug reports...

No surprise there.  It's the elite laptop, and has been since it
displaced the Sony VAIOs some time back.  I don't think I've met a
Linux hacker in the last five years who carried anything else for
reasons other than costs-too-much.

>                                                     after a
> lot of sweat and tears I have regained most of my Thinkpad's
> functionality since the upgrade (actually a fresh install repeated
> several times).

Have you managed to get suspend/resume to work reliably?  On my X40
the situation is bad...

> Another solution which will probably take too much work: make some
> sort of LiveCD with sufficient functionality to test all the hardware
> compatibility.

If anyone out there does this, I'm willing to test it and send in prompt
and detailed bug reports.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From notting at redhat.com  Mon Mar 27 20:26:19 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 27 Mar 2006 15:26:19 -0500
Subject: stateless linux, and read-only root
Message-ID: <20060327202619.GA28946@devserv.devel.redhat.com>

For FC6 we're looking at bringing forward and integrating some of the
Stateless Linux work. More detail will be up at:

 http://fedoraproject.org/wiki/StatelessLinux

although probably not for a couple of days.

One of the main tenets of this is that the system filesystems should
be able to run read-only; there's no reason for apps to be writing
to the system filesystem in general use. However, tracking this
can be difficult; you don't want to force everyone to run read-only
just to get data on their workloads.

So, what we've worked on is a way to simply log what apps are writing
to (or trying to write to) the system filesystems. This is now
available at:

  http://people.redhat.com/notting/rolo/

A readme for this is attached. Basically, we're interested in getting
logs from a variety of workloads, ranging from basic desktop to server;
with this information, we can make sure that a readonly root scenario
works for the majority of use cases that someone might want.

Right now, reports can go to this list, in this thread or similar.
If we need to set up a separate mechanism for recieving them, we
can.

Bill
-------------- next part --------------
rolo - logging of apps for read-only root
-----------------------------------------

The idea of rolo is to log applications that try to write to the system
filesystems; these are applications that may fail if they attempt to
run on a system with read-only root.

REQUIREMENTS

rolo uses either the audit layer or systemtap.

  audit requirements: audit, audit daemon service (auditd) enabled

  systemtap requirements: systemtap, kernel-devel, kernel-debuginfo

The method that rolo uses is configurable via /etc/sysconfig/rolo.

HOW TO USE

Install the rolo packages, and the prerequisites for your backend
of choice.

  /sbin/rolo start
      Starts logging
  
  /sbin/rolo stop
      Stops logging
      
  /sbin/rolo report
      Reports what has currently been logged.

  /sbin/rolo build
      Builds the module for systemtap usage. 'start' will attempt
      to do this automatically if it's required.

  You can also boot with 'init=/sbin/rolo-init' to start the logging
  on bootup.

EXCEPTIONS

rolo comes with a list of paths to ignore attempts to write to (such
as /tmp, or /proc). This list is configurable via /etc/rolo/exceptions.


NOTES

To avoid excess noise, rolo should be stopped before running package
update tools, such as pup, pirut, or yum.

 SystemTap specific:

   SystemTap buffers events before writing them; you may need to run
   'rolo stop' before running 'rolo report' to get a full report.
   
   The SystemTap backend filters while running as well as when
   reporting; if you remove exceptions, you will need to rebuild
   the module with 'rolo build'.
   
   The SystemTap backend logs to a tmpfs file; this will use
   memory as time goes on.
   
 Audit specific:

   To use the audit backend on bootup (via rolo-init), you will need
   to remove the '-D' rule from /etc/audit.rules.

   The audit backend logs every usage of the open() syscall; this will
   cause the audit logs to become fairly large.


From shane at geeklords.org  Mon Mar 27 20:33:50 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 27 Mar 2006 12:33:50 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
Message-ID: <Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>

I find it hard to believe no one else sees the current 
complexity of system/application configuration as undesirable?  Is 
this problem too big to be addressed?  Is there too much historical 
precedence involved?  Or is there a solid technical reason for not having 
a standardized configuration file format?

Linux is perceived to be "difficult" to configure and managed by many, 
this is not because we lack guis and wizards, rather because one must 
discover the process each subsystem and application uses to 
accept configure directives from its users.

I see no reason why it would not be possible and desirable to have a 
plain text compatible configuration file standard that is universal 
between subsystems, services and applications (besides it being a lot of 
work).  It seems to me that the complexities of existing configuration 
tools (authconfig, system-config-samba etc...) are largely due to this 
same fundamental issue.

Cheers,
Shane

On Sat, 25 Mar 2006, Shane Stixrud wrote:

> Greetings,
>
> This message to the Fedora Development Community is an attempt to start a 
> useful discussion on where Fedora/RHEL is today and where it is going in the 
> future, on the subject of OS management. My apologies in advance for the long 
> message.
>
> OS management is a very broad topic, in specific I will focus on the elements 
> that I consider foundational weaknesses (compared to what it could be).  This 
> is not to imply these perceived "weaknesses" out weigh its strengths or that 
> other OS's are overall superior in this regard.
>
> A bit of background to put my technical comments in perspective:
>
> I remember when I was first introduced to Unix (1992) and then later Linux 
> (1993) compared to what I was used to at the time they combined a 
> flexibility, functionality and a form of simplicity (in design) that when 
> combined made all other operating systems seem hallow.  For the most part I 
> still feel this way today, but over the years having worked in enterprise 
> environments where Linux is the up and coming challenger to entrenched 
> non-unix platforms (VMS, Windows, zOS, etc...) I have come to better 
> appreciate some of the elements involved in limiting Linux's adoption.
>
> I was recently tasked with standardizing/documenting our Linux server 
> build/configuration process and as part of this process began training some 
> of our Windows/Novell administrators to be able to carry out some of these 
> basic tasks.  It was this second part of helping train people that caused me 
> to examine and re-examine the processes I used for this standardization.
>
> My goal was simple in theory, I would use pxe+kickstart and enforce standard 
> configurations and policies via a series of post scripts while attempting to 
> keep readability, simplicity and supportability from a "non-unix guru" 
> perspective as my guiding light (A wise man once said: Make it as simple as 
> possible but no simpler).  For those interested an example of what I came up 
> with it can be obtained here: http://geeklords.org/~shane/kickstart
>
> The process turned out to be not quite as simple as the theory but very 
> educational none the less.  To start with I had a number of ways I could 
> manipulate my fresh Linux install.
>
> 1) I could create a custom RPM that had all of the changes imbedded in config 
> files and rpm scripts that merely overwrote the pre-existing ones. Problem 
> being this approach hides the complexity of what all was being changed and 
> why.
>
> 2) Use cfengine after the kickstart install.  This of course has some 
> advantages over the rpm method but it also hides the same complexity and adds 
> some of its own.
>
> 3) Document on paper all of the steps required and how to perform them from 
> the console, taking advantage of the guis when available or command line when 
> required.  I felt that was not only a big waste of time but left far too much 
> to human error.
>
>
> 4) Create a series of simple scripts using basic OS applications/tools (sed, 
> echo, cp, mv, authtool, postconf etc...) to perform all of the required 
> modifications, documenting what and why along the way.
>
>
> I choose method 4.
>
> My conclusion having completed this process is that the number of variables, 
> complexity and dependencies that must be understood and taken into account 
> when modifying configuration files is much higher than it needs to be. I 
> think this should be clear when reading the example scripts mentioned above.
>
> Some things I learned:
>
> Sed is a wonderful tool, but it is highly limited by the fact its user must 
> take into account whole file(s) for each expression, this is further 
> complicated when one must consider the file may change over time.  The 
> complexity and readability of regular expression tools is much higher than 
> should be required to change OS/application variables.
>
> Creating new files or appending to the end of existing files with "echo" only 
> takes one so far.  This also tends to have the cost of hurting readability as 
> it is often the case you would prefer putting data somewhere else in the file 
> (i.e. sed).
>
> The nature of flat configuration files where each application has its own 
> format is such where recovery and/or applying changes only if they have not 
> been already applied is too complex and hurts readability far to much to be 
> attempted in a simple shell script.
>
> Many applications have their own command line driven configuration utilities. 
> However each has their own oddities and complexities (authtool, gconftool-2, 
> postconf etc...) Oddly enough out of all of the command line configuration 
> tools I have used, I find gconftool-2 to be closest to The Right Way (TM), 
> which is odd as it is by far one of the most complex syntax's to use (God 
> help anyone who tries to make major edits to gnome xml files using sed) 
> example:
>
> "gconftool-2 --direct --config-source 
> xml:readwrite:/etc/gconf/gconf.xml.mandator
> y --type float --set /desktop/gnome/peripherals/mouse/motion_acceleration 1"
>
> Even a complex (yet powerful) tool can meet the golden rule of "Make it as 
> simple as possible but no simpler" when compared against a bunch of tools 
> that are less powerful (and perhaps less complex when viewed in isolation).
>
> It is my opinion that we as a community need to find a Better Way (tm) to 
> manage configuration changes for Linux subsystems and applications. 
> Everything should be a file, but that does not mean every configuration file 
> needs to be formatted and managed differently.
>
> In closing, a change this fundamental must be designed by the best minds and 
> must have a strong champion for it to have a chance to succeed.  The Fedora 
> community is likely the only Linux entity with the brain power and influence 
> to address this issue.
>
> Cheers,
> Shane
>
>



From notting at redhat.com  Mon Mar 27 20:38:06 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 27 Mar 2006 15:38:06 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
Message-ID: <20060327203806.GB28946@devserv.devel.redhat.com>

Shane Stixrud (shane at geeklords.org) said: 
> I see no reason why it would not be possible and desirable to have a 
> plain text compatible configuration file standard that is universal 
> between subsystems, services and applications (besides it being a lot of 
> work).  It seems to me that the complexities of existing configuration 
> tools (authconfig, system-config-samba etc...) are largely due to this 
> same fundamental issue.

Basically, the problem arises in trying to move the inertia of 50 upstream
applications to move to a "new, better" format versus the pain of
trying to consistently maintain such patches for 50 applications outside
of upstream.

Bill



From smooge at gmail.com  Mon Mar 27 20:41:18 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Mon, 27 Mar 2006 13:41:18 -0700
Subject: stateless linux, and read-only root
In-Reply-To: <20060327202619.GA28946@devserv.devel.redhat.com>
References: <20060327202619.GA28946@devserv.devel.redhat.com>
Message-ID: <80d7e4090603271241q895b7f9g925a68ed2a0c5021@mail.gmail.com>

On 3/27/06, Bill Nottingham <notting at redhat.com> wrote:
> For FC6 we're looking at bringing forward and integrating some of the
> Stateless Linux work. More detail will be up at:
>
>  http://fedoraproject.org/wiki/StatelessLinux
>
> although probably not for a couple of days.
>

Will there be a dedicated mailling list or just talk over the main
lists. I am mostly needing this for NFS diskless clients. Most of the
data needs to be RO, but some stuff should be RW (utmp and such :))


> One of the main tenets of this is that the system filesystems should
> be able to run read-only; there's no reason for apps to be writing
> to the system filesystem in general use. However, tracking this
> can be difficult; you don't want to force everyone to run read-only
> just to get data on their workloads.
>
> So, what we've worked on is a way to simply log what apps are writing
> to (or trying to write to) the system filesystems. This is now
> available at:
>


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From seanlkml at sympatico.ca  Mon Mar 27 20:39:33 2006
From: seanlkml at sympatico.ca (sean)
Date: Mon, 27 Mar 2006 15:39:33 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
Message-ID: <BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>

On Mon, 27 Mar 2006 12:33:50 -0800 (PST)
Shane Stixrud <shane at geeklords.org> wrote:

> I find it hard to believe no one else sees the current 
> complexity of system/application configuration as undesirable?  Is 
> this problem too big to be addressed?  Is there too much historical 
> precedence involved?  Or is there a solid technical reason for not having 
> a standardized configuration file format?
> 
> Linux is perceived to be "difficult" to configure and managed by many, 
> this is not because we lack guis and wizards, rather because one must 
> discover the process each subsystem and application uses to 
> accept configure directives from its users.
> 
> I see no reason why it would not be possible and desirable to have a 
> plain text compatible configuration file standard that is universal 
> between subsystems, services and applications (besides it being a lot of 
> work).  It seems to me that the complexities of existing configuration 
> tools (authconfig, system-config-samba etc...) are largely due to this 
> same fundamental issue.

GUI users don't want to be hunting through text files anyway, they
want nice settings windows and wizards.   Anyone hand editing config
files better know what's going on anyway; the current situation isn't too
bad there.

gconf already provides a reasonable way to change settings from the
command line and via GUI tools.   What would you change?

No matter what you come up with though, it will be many years before
you see wide spread adoption.   If anything, you might consider a 
project to create a system-wide config editor that knows all 
the different formats etc and provides a consistent CLI/GUI 
interface.

Sean



From notting at redhat.com  Mon Mar 27 20:43:14 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 27 Mar 2006 15:43:14 -0500
Subject: stateless linux, and read-only root
In-Reply-To: <80d7e4090603271241q895b7f9g925a68ed2a0c5021@mail.gmail.com>
References: <20060327202619.GA28946@devserv.devel.redhat.com>
	<80d7e4090603271241q895b7f9g925a68ed2a0c5021@mail.gmail.com>
Message-ID: <20060327204313.GC28946@devserv.devel.redhat.com>

Stephen J. Smoogen (smooge at gmail.com) said: 
> On 3/27/06, Bill Nottingham <notting at redhat.com> wrote:
> > For FC6 we're looking at bringing forward and integrating some of the
> > Stateless Linux work. More detail will be up at:
> >
> >  http://fedoraproject.org/wiki/StatelessLinux
> >
> > although probably not for a couple of days.
> >
> 
> Will there be a dedicated mailling list or just talk over the main
> lists. I am mostly needing this for NFS diskless clients. Most of the
> data needs to be RO, but some stuff should be RW (utmp and such :))

Here for now, something dedicated if needed.

Bill



From jon.nettleton at gmail.com  Mon Mar 27 20:54:51 2006
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Mon, 27 Mar 2006 15:54:51 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060327153933.47f5dc33.seanlkml@sympatico.ca>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<20060327153933.47f5dc33.seanlkml@sympatico.ca>
Message-ID: <1143492891.8482.9.camel@averatec>

On Mon, 2006-03-27 at 15:39 -0500, sean wrote:
> On Mon, 27 Mar 2006 12:33:50 -0800 (PST)
> Shane Stixrud <shane at geeklords.org> wrote:
> 
> > I find it hard to believe no one else sees the current 
> > complexity of system/application configuration as undesirable?  Is 
> > this problem too big to be addressed?  Is there too much historical 
> > precedence involved?  Or is there a solid technical reason for not having 
> > a standardized configuration file format?
> > 
> > Linux is perceived to be "difficult" to configure and managed by many, 
> > this is not because we lack guis and wizards, rather because one must 
> > discover the process each subsystem and application uses to 
> > accept configure directives from its users.
> > 
> > I see no reason why it would not be possible and desirable to have a 
> > plain text compatible configuration file standard that is universal 
> > between subsystems, services and applications (besides it being a lot of 
> > work).  It seems to me that the complexities of existing configuration 
> > tools (authconfig, system-config-samba etc...) are largely due to this 
> > same fundamental issue.
> 
> GUI users don't want to be hunting through text files anyway, they
> want nice settings windows and wizards.   Anyone hand editing config
> files better know what's going on anyway; the current situation isn't too
> bad there.
> 
> gconf already provides a reasonable way to change settings from the
> command line and via GUI tools.   What would you change?
> 
> No matter what you come up with though, it will be many years before
> you see wide spread adoption.   If anything, you might consider a 
> project to create a system-wide config editor that knows all 
> the different formats etc and provides a consistent CLI/GUI 
> interface.
> 
I started designing this type of system.  A gui config editor/manager
with it's own config languages, that used translator plugins for all the
different config file formats out in the opensource community.  It is
really an ugly massive project, that is useless until you get all the
translators written.  The scariest problem that forced me to give it up
was not just maintaining the translator plugins, but maintaining the
translation rules for the different versions of config files for the
same app.

Just thought I would chime in.

Jon



From shane at geeklords.org  Mon Mar 27 21:08:57 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 27 Mar 2006 13:08:57 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
Message-ID: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>

On Mon, 27 Mar 2006, sean wrote:

> GUI users don't want to be hunting through text files anyway, they
> want nice settings windows and wizards.   Anyone hand editing config
> files better know what's going on anyway; the current situation isn't too
> bad there.

This is not a gui issue, nor is it just an "end user issue".  This 
attitude of "anyone hand editing config files better know what's going on 
anyways" becomes largely invalid when a standard methodology exists.

>
> gconf already provides a reasonable way to change settings from the
> command line and via GUI tools.   What would you change?

Gconf shows the gnome people realized early on having a standard 
method for storing and modifying configuration data is important, to the 
gnome platform... We are not talking about JUST the gnome platform and my 
guess is gconf would not meet the needs of Fedora as a whole.

>
> No matter what you come up with though, it will be many years before
> you see wide spread adoption.   If anything, you might consider a
> project to create a system-wide config editor that knows all
> the different formats etc and provides a consistent CLI/GUI
> interface.

Projects already exist http://www.libelektra.org/Main_Page for example. 
The problem is not that code doesn't exist, the problem is one of getting 
everyone to:
a) agree its desirable
b) Agreeing/creating an implementation
c) having a plan for getting where we want to be "many years" later.

I don't see how a few people can make this happen, it is going to take 
some serious influence to make any real world progress.



From selinux at gmail.com  Mon Mar 27 21:08:14 2006
From: selinux at gmail.com (Tom London)
Date: Mon, 27 Mar 2006 13:08:14 -0800
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060327202457.GA15056@thyrsus.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
Message-ID: <4c4ba1530603271308n434c5481g7f426424af5526a9@mail.gmail.com>

On 3/27/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> Joe Desbonnet <jdesbonnet at gmail.com>:
> > The Thinkpad seems to be cropping up alot in bug reports...
>
> No surprise there.  It's the elite laptop, and has been since it
> displaced the Sony VAIOs some time back.  I don't think I've met a
> Linux hacker in the last five years who carried anything else for
> reasons other than costs-too-much.
>
> >                                                     after a
> > lot of sweat and tears I have regained most of my Thinkpad's
> > functionality since the upgrade (actually a fresh install repeated
> > several times).
>
> Have you managed to get suspend/resume to work reliably?  On my X40
> the situation is bad...
>
> > Another solution which will probably take too much work: make some
> > sort of LiveCD with sufficient functionality to test all the hardware
> > compatibility.
>
> If anyone out there does this, I'm willing to test it and send in prompt
> and detailed bug reports.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
I've gotten suspend/resume working on my X4.

See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184033
for some details.

tom
--
Tom London



From selinux at gmail.com  Mon Mar 27 21:09:15 2006
From: selinux at gmail.com (Tom London)
Date: Mon, 27 Mar 2006 13:09:15 -0800
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <4c4ba1530603271308n434c5481g7f426424af5526a9@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<4c4ba1530603271308n434c5481g7f426424af5526a9@mail.gmail.com>
Message-ID: <4c4ba1530603271309x6ee2d091wb86a30861bab68ba@mail.gmail.com>

On 3/27/06, Tom London <selinux at gmail.com> wrote:
> On 3/27/06, Eric S. Raymond <esr at thyrsus.com> wrote:
>
> I've gotten suspend/resume working on my X4.

Sorry, thats a  X41.

>
> See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184033
> for some details.
>
> tom
> --
> Tom London
>


--
Tom London



From alan at redhat.com  Mon Mar 27 21:18:50 2006
From: alan at redhat.com (Alan Cox)
Date: Mon, 27 Mar 2006 16:18:50 -0500
Subject: GUI controls for instrumentation
In-Reply-To: <341C0E6AB66D9D5604ABDF9A@[10.0.0.14]>
References: <132A9F5E12B8828DA6ED8E85@[10.169.6.226]>
	<200603242033.03945.lamont@gurulabs.com>
	<341C0E6AB66D9D5604ABDF9A@[10.0.0.14]>
Message-ID: <20060327211850.GA18308@devserv.devel.redhat.com>

On Mon, Mar 27, 2006 at 09:46:45AM -0800, Kenneth Porter wrote:
> I was looking at Qt. The developer license is pricey but probably doable. 

Its free for free software

> As an example of the kind of app I'm thinking of, consider a model train 
> control panel which can control the speeds of various locomotives and 
> report track conditions in real time (eg. graphing the impedance of the 
> tracks).

I take it you know about jmri, although its java not C and doesn't seem to 
like gcj yet

Alan
--
	"We didn't have the money so we had to think harder"
			- Colin Pillinger



From Lam at Lam.pl  Mon Mar 27 21:18:54 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Mon, 27 Mar 2006 23:18:54 +0200
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
Message-ID: <1143494334.2869.32.camel@pensja.lam.pl>

Dnia 27-03-2006, pon o godzinie 13:08 -0800, Shane Stixrud napisa?(a):
> > No matter what you come up with though, it will be many years before
> > you see wide spread adoption.   If anything, you might consider a
> > project to create a system-wide config editor that knows all
> > the different formats etc and provides a consistent CLI/GUI
> > interface.
> Projects already exist http://www.libelektra.org/Main_Page for example. 
No, this concentrates on creating a single API for many programs to
store their configs. Parent meant something understanding currently
existent configuration formats. Something like that exists, too:
http://www.solucorp.qc.ca/linuxconf/

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/66cd86d3/attachment.sig>

From seanlkml at sympatico.ca  Mon Mar 27 21:20:32 2006
From: seanlkml at sympatico.ca (sean)
Date: Mon, 27 Mar 2006 16:20:32 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
Message-ID: <BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>

On Mon, 27 Mar 2006 13:08:57 -0800 (PST)
Shane Stixrud <shane at geeklords.org> wrote:

> This is not a gui issue, nor is it just an "end user issue".  This 
> attitude of "anyone hand editing config files better know what's going on 
> anyways" becomes largely invalid when a standard methodology exists.

I actually don't buy that.   You don't change anything when you go 
to a standard config file format.   Anyone editing at the file/gconf/
registry level had better know what the heck they're doing.

Everyone else wants a nice GUI that is logically consistent with 
the problem space they're interested in and provides wizards etc
to explain the configuration process. 
 
> Gconf shows the gnome people realized early on having a standard 
> method for storing and modifying configuration data is important, to the 
> gnome platform... We are not talking about JUST the gnome platform and my 
> guess is gconf would not meet the needs of Fedora as a whole.

And that's really the problem isn't it, how do you get KDE, Gnome,
every CLI program, and every other window manager etc to all agree
on one format.   The way it will happen is gradually everyone will
see that someone is winning the fight to provide a backend config
system and will use it.   This might be a good project for
freedesktop.org.

> Projects already exist http://www.libelektra.org/Main_Page for example. 
> The problem is not that code doesn't exist, the problem is one of getting 
> everyone to:
> a) agree its desirable
> b) Agreeing/creating an implementation
> c) having a plan for getting where we want to be "many years" later.

But gconf and gconf-2 and others existed before the package you cite.
Perhaps this one is the end all and be all of config backends.  Dunno.
 
> I don't see how a few people can make this happen, it is going to take 
> some serious influence to make any real world progress.

It might help if the Fedora project "blessed" one particular backend 
config system, but I suspect even getting that decision made would be
a big challenge.

Sean



From jspaleta at gmail.com  Mon Mar 27 21:26:03 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 27 Mar 2006 16:26:03 -0500
Subject: stateless linux, and read-only root
In-Reply-To: <20060327202619.GA28946@devserv.devel.redhat.com>
References: <20060327202619.GA28946@devserv.devel.redhat.com>
Message-ID: <604aa7910603271326w77d5806h1d4406bc3cb9d8b1@mail.gmail.com>

On 3/27/06, Bill Nottingham <notting at redhat.com> wrote:
> Right now, reports can go to this list, in this thread or similar.
> If we need to set up a separate mechanism for recieving them, we
> can.

what sort of timescale do you want the reports to cover before being
shipped off for review?

-jef



From shane at geeklords.org  Mon Mar 27 21:33:17 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 27 Mar 2006 13:33:17 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143494334.2869.32.camel@pensja.lam.pl>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143494334.2869.32.camel@pensja.lam.pl>
Message-ID: <Pine.LNX.4.63.0603271330400.24389@master.geeklords.org>

On Mon, 27 Mar 2006, Leszek Matok wrote:

> Dnia 27-03-2006, pon o godzinie 13:08 -0800, Shane Stixrud napisa??(a):
>>> No matter what you come up with though, it will be many years before
>>> you see wide spread adoption.   If anything, you might consider a
>>> project to create a system-wide config editor that knows all
>>> the different formats etc and provides a consistent CLI/GUI
>>> interface.
>> Projects already exist http://www.libelektra.org/Main_Page for example.
>
> No, this concentrates on creating a single API for many programs to
> store their configs. Parent meant something understanding currently
> existent configuration formats. Something like that exists, too:
> http://www.solucorp.qc.ca/linuxconf/
>

The above project has the concept of "backends" that can be made to 
understand specific configuration formats.  There is an example where 
Xorg.conf can be imported and exported on demand.

http://www.libelektra.org/Backends


From denis at poolshark.org  Mon Mar 27 21:33:22 2006
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 27 Mar 2006 13:33:22 -0800
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
Message-ID: <44285A22.70004@poolshark.org>

Joe Desbonnet wrote:
> Another solution which will probably take too much work: make some
> sort of LiveCD with sufficient functionality to test all the hardware
> compatibility.

I like this idea a lot. Even if there's barely enough memory left to do 
anything, the goal here is just hardware compatibility testing. But does 
that mean creating a LiveCD-that-supports-everything, or can we somehow 
run this through Anaconda first...



From notting at redhat.com  Mon Mar 27 21:37:45 2006
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 27 Mar 2006 16:37:45 -0500
Subject: stateless linux, and read-only root
In-Reply-To: <604aa7910603271326w77d5806h1d4406bc3cb9d8b1@mail.gmail.com>
References: <20060327202619.GA28946@devserv.devel.redhat.com>
	<604aa7910603271326w77d5806h1d4406bc3cb9d8b1@mail.gmail.com>
Message-ID: <20060327213744.GA31274@devserv.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> On 3/27/06, Bill Nottingham <notting at redhat.com> wrote:
> > Right now, reports can go to this list, in this thread or similar.
> > If we need to set up a separate mechanism for recieving them, we
> > can.
> 
> what sort of timescale do you want the reports to cover before being
> shipped off for review?

More than five minutes, less than three months. The systemtap backend
loses all state between reboots, so that's one delimiter.

Bill



From shane at geeklords.org  Mon Mar 27 21:43:38 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 27 Mar 2006 13:43:38 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
Message-ID: <Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>

On Mon, 27 Mar 2006, sean wrote:

>> This is not a gui issue, nor is it just an "end user issue".  This
>> attitude of "anyone hand editing config files better know what's going on
>> anyways" becomes largely invalid when a standard methodology exists.
>
> I actually don't buy that.   You don't change anything when you go
> to a standard config file format.   Anyone editing at the file/gconf/
> registry level had better know what the heck they're doing.

I do not see it this cut and dry.  There is no line between those people 
who "know what they are doing" and those who do not.

> Everyone else wants a nice GUI that is logically consistent with
> the problem space they're interested in and provides wizards etc
> to explain the configuration process.

I am not saying wizards and interfaces that present multiple change values 
via am interrogated interface is not valuable.  I am saying their value is 
greatly amplified by the needless complexities at the lower layers.  I am 
also saying providing these wizards and interfaces are much more difficult 
to build pragmatically due to these same complexities.

>> Projects already exist http://www.libelektra.org/Main_Page for example.
>> The problem is not that code doesn't exist, the problem is one of getting
>
> But gconf and gconf-2 and others existed before the package you cite.
> Perhaps this one is the end all and be all of config backends.  Dunno.

A package designed to take into account other systems can help with the 
transition, Elektra appears to do this for gconf and I think kde's backend 
is in the works.  I am not saying Elektra is or isn't the solution, only 
that a solution like it is desirable.



From seanlkml at sympatico.ca  Mon Mar 27 21:40:22 2006
From: seanlkml at sympatico.ca (sean)
Date: Mon, 27 Mar 2006 16:40:22 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271330400.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143494334.2869.32.camel@pensja.lam.pl>
	<Pine.LNX.4.63.0603271330400.24389@master.geeklords.org>
Message-ID: <BAYC1-PASMTP11A208FFF6F65A23304C26AED20@CEZ.ICE>

On Mon, 27 Mar 2006 13:33:17 -0800 (PST)
Shane Stixrud <shane at geeklords.org> wrote:

> The above project has the concept of "backends" that can be made to 
> understand specific configuration formats.  There is an example where 
> Xorg.conf can be imported and exported on demand.
> 
> http://www.libelektra.org/Backends
> 

If you think this package is going to be the long term answer, why not
start by packaging it up for extras?

Sean



From shane at geeklords.org  Mon Mar 27 21:50:17 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 27 Mar 2006 13:50:17 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060327203806.GB28946@devserv.devel.redhat.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<20060327203806.GB28946@devserv.devel.redhat.com>
Message-ID: <Pine.LNX.4.63.0603271344220.24389@master.geeklords.org>

On Mon, 27 Mar 2006, Bill Nottingham wrote:

> Basically, the problem arises in trying to move the inertia of 50 upstream
> applications to move to a "new, better" format versus the pain of
> trying to consistently maintain such patches for 50 applications outside
> of upstream.

I understand that.  So the equation seems to be is the effort worth the 
long term benefits?  I can tell you from the meetings and hall way 
conversations I have been involved in, this issue is a large part of 
the equation when an enterprise is comparing Windows vs Linux for x86 
desktop and server deployments.  It is not the command line that turns 
Netware / Windows administrators off (even if they think it is) it is the 
lack of consistency and thus the increased complexity involved in 
configuration the system.

Shane



From seanlkml at sympatico.ca  Mon Mar 27 21:51:51 2006
From: seanlkml at sympatico.ca (sean)
Date: Mon, 27 Mar 2006 16:51:51 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
Message-ID: <BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>

On Mon, 27 Mar 2006 13:43:38 -0800 (PST)
Shane Stixrud <shane at geeklords.org> wrote:

> I do not see it this cut and dry.  There is no line between those people 
> who "know what they are doing" and those who do not.

Well the line is somewhere around the area of those who can look
at a config file and figure it out in a minute or two, and those who
can't.   Anyone who can't deal with today's config files, isn't
going to be any better off with a nice gui version of that
same process.

Another way of saying this is, it's not the config file format
that is the barrier to people configuring their system today.  It's
the contents of those files and understanding what all those options
do and why you might want to use one or the other.

That's why even with Windows where you have a registry you still
need configuration screens and wizards etc.

> I am not saying wizards and interfaces that present multiple change values 
> via am interrogated interface is not valuable.  I am saying their value is 
> greatly amplified by the needless complexities at the lower layers.  I am 
> also saying providing these wizards and interfaces are much more difficult 
> to build pragmatically due to these same complexities.

Well you're right that it would be one less thing a developer would have
to worry about if their was a common library for dealing with any and 
all config files.

> A package designed to take into account other systems can help with the 
> transition, Elektra appears to do this for gconf and I think kde's backend 
> is in the works.  I am not saying Elektra is or isn't the solution, only 
> that a solution like it is desirable.
> 

I hadn't heard of Elektra before you mentioned it and yeah, it looks pretty
good.

Sean



From shane at geeklords.org  Mon Mar 27 21:56:03 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 27 Mar 2006 13:56:03 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <BAYC1-PASMTP11A208FFF6F65A23304C26AED20@CEZ.ICE>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143494334.2869.32.camel@pensja.lam.pl>
	<Pine.LNX.4.63.0603271330400.24389@master.geeklords.org>
	<BAYC1-PASMTP11A208FFF6F65A23304C26AED20@CEZ.ICE>
Message-ID: <Pine.LNX.4.63.0603271350380.24389@master.geeklords.org>

On Mon, 27 Mar 2006, sean wrote:

> On Mon, 27 Mar 2006 13:33:17 -0800 (PST)
> Shane Stixrud <shane at geeklords.org> wrote:
>
>> The above project has the concept of "backends" that can be made to
>> understand specific configuration formats.  There is an example where
>> Xorg.conf can be imported and exported on demand.
>>
>> http://www.libelektra.org/Backends
>>
>
> If you think this package is going to be the long term answer, why not
> start by packaging it up for extras?

I have not said that.  I am interested in the right solution and on 
something this important and massive I can't see it working without rough 
community agreement on what that thing would look like. If the 
community felt elektra was a good direction then I would be more than 
happy to package it up, although I am sure the authors would beat me too 
it.

Shane



From jdesbonnet at gmail.com  Mon Mar 27 22:20:37 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Mon, 27 Mar 2006 23:20:37 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
Message-ID: <1cef3e950603271420x8c543ffk3755703bba2d76ac@mail.gmail.com>

I think the only way this will happen is for a consortium of interests
in the Linux (and similar OSes) world to come up with a formal
standard (file format, best practices and API bindings for common
languages). Then cast it in concrete by submitting it to a standards
body eg EMCA.

If the standard is good then I believe people will use it. Parsing
config files is tedious and error prone. Often developers forget about
things like international characters and have to change the format
after a few releases.

At it's simplest this standard could be a simple name-value pair text
file. But it should also cater for complex configurations and allow a
schema to define and describe the file (and perhaps the GUI used to
edit it).

To ease migration, adapter modules could be written to dynamically
translate existing config files to/from the new format.

This would be a huge step forward for Linux. Right now the /etc
directory is littered with different formats. Many are not documented
outside of the source coded used to read them.

Joe.


On 3/27/06, Shane Stixrud <shane at geeklords.org> wrote:
> On Mon, 27 Mar 2006, sean wrote:
>
> > GUI users don't want to be hunting through text files anyway, they
> > want nice settings windows and wizards.   Anyone hand editing config
> > files better know what's going on anyway; the current situation isn't too
> > bad there.
>
> This is not a gui issue, nor is it just an "end user issue".  This
> attitude of "anyone hand editing config files better know what's going on
> anyways" becomes largely invalid when a standard methodology exists.
>
> >
> > gconf already provides a reasonable way to change settings from the
> > command line and via GUI tools.   What would you change?
>
> Gconf shows the gnome people realized early on having a standard
> method for storing and modifying configuration data is important, to the
> gnome platform... We are not talking about JUST the gnome platform and my
> guess is gconf would not meet the needs of Fedora as a whole.
>
> >
> > No matter what you come up with though, it will be many years before
> > you see wide spread adoption.   If anything, you might consider a
> > project to create a system-wide config editor that knows all
> > the different formats etc and provides a consistent CLI/GUI
> > interface.
>
> Projects already exist http://www.libelektra.org/Main_Page for example.
> The problem is not that code doesn't exist, the problem is one of getting
> everyone to:
> a) agree its desirable
> b) Agreeing/creating an implementation
> c) having a plan for getting where we want to be "many years" later.
>
> I don't see how a few people can make this happen, it is going to take
> some serious influence to make any real world progress.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From dax at gurulabs.com  Mon Mar 27 22:29:19 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Mon, 27 Mar 2006 15:29:19 -0700
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060327202457.GA15056@thyrsus.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
Message-ID: <1143498560.11720.8.camel@mentorng.gurulabs.com>

On Mon, 2006-03-27 at 15:24 -0500, Eric S. Raymond wrote:
> Joe Desbonnet <jdesbonnet at gmail.com>:
> > The Thinkpad seems to be cropping up alot in bug reports...
> 
> No surprise there.  It's the elite laptop, and has been since it
> displaced the Sony VAIOs some time back.  I don't think I've met a
> Linux hacker in the last five years who carried anything else for
> reasons other than costs-too-much.
> 
> >                                                     after a
> > lot of sweat and tears I have regained most of my Thinkpad's
> > functionality since the upgrade (actually a fresh install repeated
> > several times).
> 
> Have you managed to get suspend/resume to work reliably?  On my X40
> the situation is bad...

With FC5, my Thinkpad T42p does suspend/resume reliably after adding the
kernel parameter "acpi_sleep=s3_bios" to my grub.conf. No other tweaks
were needed (1).

Did you check out the information on the ThinkWiki (that is a *awesome*
resource for Linux using ThinkPad owners)?

In particular:

http://www.thinkwiki.org/wiki/How_to_make_ACPI_work

Dax Kelson
Guru Labs

(1) I may have spotted a problem using the burner after a suspend/resume
cycle. I think I remember reading something about that -- DMA not being
re-enabled but that a fix was available.



From seanlkml at sympatico.ca  Mon Mar 27 22:30:44 2006
From: seanlkml at sympatico.ca (sean)
Date: Mon, 27 Mar 2006 17:30:44 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1cef3e950603271420x8c543ffk3755703bba2d76ac@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1cef3e950603271420x8c543ffk3755703bba2d76ac@mail.gmail.com>
Message-ID: <BAYC1-PASMTP1067D9622A8D2159BDE204AED20@CEZ.ICE>

On Mon, 27 Mar 2006 23:20:37 +0100
"Joe Desbonnet" <jdesbonnet at gmail.com> wrote:

> I think the only way this will happen is for a consortium of interests
> in the Linux (and similar OSes) world to come up with a formal
> standard (file format, best practices and API bindings for common
> languages). Then cast it in concrete by submitting it to a standards
> body eg EMCA.

Sure, or freedesktop.org, freestandards.org etc..   But really all 
that is needed is a defacto standard based on a prevalent solution.  
So talking about it and trying to form a committee etc. is likely
the long way to a solution.

> If the standard is good then I believe people will use it. Parsing
> config files is tedious and error prone. Often developers forget about
> things like international characters and have to change the format
> after a few releases.

No doubt.
 
> At it's simplest this standard could be a simple name-value pair text
> file. But it should also cater for complex configurations and allow a
> schema to define and describe the file (and perhaps the GUI used to
> edit it).

The backend used to store the configuration database isn't really
all that important once you have a standard API which can be used
by applications and CLI/GUI config editors.
 
> To ease migration, adapter modules could be written to dynamically
> translate existing config files to/from the new format.

Yup, and the package Shane mentioned (Elektra) has this.
 
> This would be a huge step forward for Linux. Right now the /etc
> directory is littered with different formats. Many are not documented
> outside of the source coded used to read them.

I don't think this will actually be a huge step forward or make the
difference to anyone deciding whether to embrace Linux or not.  But
there's no doubt it would be at least nice incremental improvement.

Sean



From shane at geeklords.org  Mon Mar 27 22:36:11 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 27 Mar 2006 14:36:11 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
Message-ID: <Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>

On Mon, 27 Mar 2006, sean wrote:

> Well the line is somewhere around the area of those who can look
> at a config file and figure it out in a minute or two, and those who
> can't.   Anyone who can't deal with today's config files, isn't
> going to be any better off with a nice gui version of that
> same process.

I would be insulted if I didn't know you were just making a generalized 
statement :).  Who here hasn't spent more than 2 minutes trying to figure 
a missing period in a named conf file, or more than two minutes setting up 
ldap for the first time, or more than two minutes figuring out where to 
find a specific option and value for /etc/modules.conf etc...  The 
problem is each time you touch something you haven't touched in the 
past one must spend significant time figuring out how to make the change 
even if they already know what they want to change.  This is not true for 
all configuration files, but it is for many.  The amount of neurons I have 
dedicated to configuration syntax and where the lists of values and 
their descriptions are stored is many more than I would like.

The "non-initiated" see this as complex and on this specific issue I 
agree, it is more complex than it needs to be.. I am just used to it and 
shrug it off.

If for every "key": its default, possible values (on, off string, float 
etc..) is readily accessible and for every key there is a simple 
description much of this complexity is eliminated.



From jdesbonnet at gmail.com  Mon Mar 27 22:46:17 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Mon, 27 Mar 2006 23:46:17 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
Message-ID: <1cef3e950603271446la81d600l8fc28c895143ce40@mail.gmail.com>

On 3/27/06, Shane Stixrud <shane at geeklords.org> wrote:
>
> If for every "key": its default, possible values (on, off string, float
> etc..) is readily accessible and for every key there is a simple
> description much of this complexity is eliminated.
>

Yes, I think this is what's missing: if for each config file there was
a schema things would be better. For example I've pasted below a clip
from a  schema of a web microsite generator I'm working on. This not
only describes the data, it allows me to make a web based editor on
the fly, by specifying the appropriate widget to edit an item an and
help text.

Joe.

 <global-schema>
                <field id="theme" datatype="enum" name="Theme">
                        <option id="autumn" name="Autumn" />
                        <option id="spring" name="Spring" />
                        <option id="winter" name="Winter" />
                        <option id="test" name="Test" />
                </field>
                <field id="title" datatype="string" name="Title"
                        helptext="The title of the website. It is used
in the header of very page." />
                <field id="slogan" datatype="string" name="Slogan"
                        helptext="A slogan or strap line which appears
under the site title on every page."/>

                <field id="left_image" datatype="image" name="Left block image."
                        helptext="The left block image. 300x200 pixels." />

                <field id="custom_css" datatype="string" name="Custom CSS"
                        widget="widget:textarea;rows:8;cols:60"
                        helptext="Custom CSS" />

        </global-sc



From seanlkml at sympatico.ca  Mon Mar 27 22:47:30 2006
From: seanlkml at sympatico.ca (sean)
Date: Mon, 27 Mar 2006 17:47:30 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
Message-ID: <BAYC1-PASMTP087C9920AA0631B56D0DE0AED20@CEZ.ICE>

On Mon, 27 Mar 2006 14:36:11 -0800 (PST)
Shane Stixrud <shane at geeklords.org> wrote:


> I would be insulted if I didn't know you were just making a generalized 
> statement :).  Who here hasn't spent more than 2 minutes trying to figure 
> a missing period in a named conf file, or more than two minutes setting up 
> ldap for the first time, or more than two minutes figuring out where to 
> find a specific option and value for /etc/modules.conf etc...  The 
> problem is each time you touch something you haven't touched in the 
> past one must spend significant time figuring out how to make the change 
> even if they already know what they want to change.  This is not true for 
> all configuration files, but it is for many.  The amount of neurons I have 
> dedicated to configuration syntax and where the lists of values and 
> their descriptions are stored is many more than I would like.

lol, naw i think you mistook my meaning.  I'm not saying that all
config editing can be handled in under two minutes.   What i am saying
though is that no more time than that is needed to comprehend the
config file format.   Once you've seen one config file, you've seen
em all; more or less.

A standard config file format isn't going to lessen the burden if 
understanding what all those config options etc mean.   Even if 
that config file is presented in a pretty gui gconf-editor like tool.

> The "non-initiated" see this as complex and on this specific issue I 
> agree, it is more complex than it needs to be.. I am just used to it and 
> shrug it off.
> 
> If for every "key": its default, possible values (on, off string, float 
> etc..) is readily accessible and for every key there is a simple 
> description much of this complexity is eliminated.

I just don't think this is really the significant part of what makes
configuring a system difficult.   Happy to be proved wrong.

Sean



From esr at thyrsus.com  Mon Mar 27 22:59:28 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 27 Mar 2006 17:59:28 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143498560.11720.8.camel@mentorng.gurulabs.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
Message-ID: <20060327225928.GA16219@thyrsus.com>

Dax Kelson <dax at gurulabs.com>:
> With FC5, my Thinkpad T42p does suspend/resume reliably after adding the
> kernel parameter "acpi_sleep=s3_bios" to my grub.conf.  

Hah!   Works on an X40 as well. I'll add this workaround to the bug I entered;
also at my HOWTO, <http://www.catb.org/esr/faqs/Fedora-Core-on-Thinkpad-X40/>.
 
> Did you check out the information on the ThinkWiki (that is a *awesome*
> resource for Linux using ThinkPad owners)?
> 
> In particular:
> 
> http://www.thinkwiki.org/wiki/How_to_make_ACPI_work

Yes, that's how I developed the recipe I used to publish in my HOWTO for FC4.
The recipe didn't work for FC5, however, apparently because with the 
in-kernel support the suspend/resume events no longer go through acpid.

How did you make lid close do a suspend as it should?  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From wrrhdev at riede.org  Mon Mar 27 23:02:12 2006
From: wrrhdev at riede.org (Willem Riede)
Date: Mon, 27 Mar 2006 18:02:12 -0500
Subject: Open-link misbehavior
In-Reply-To: <1143430221.15323.55.camel@dimi> (from dimi@lattica.com on Sun
	Mar 26 22:30:21 2006)
References: <1143424403.15323.31.camel@dimi>
	<d91f09cd0603261826q5884001fs9ba735ac40e04290@mail.gmail.com>
	<1143426912.15323.43.camel@dimi>
	<1143428756l.26064l.0l@athena.riede.org>
	<1143430221.15323.55.camel@dimi>
Message-ID: <1143500532l.26064l.1l@athena.riede.org>

On 03/26/2006 10:30:21 PM, Dimi Paun wrote:
> On Sun, 2006-03-26 at 22:05 -0500, Willem Riede wrote:
> > I have to disappoint you. I positively love, love love this behavior.
> > Please do not assume everybody thinks like you do.
> 
> Willem, I have clearly explained twice the problem. You didn't
> seem to have paid attention in both cases :) I did not complain
> about the opening of the link in a tab. This is a cool feature,I agree.
> I did complain about the fact that when the Firefox window is on a
> different desktop than Evolution (or any other app that tries to open a
> link for that matter), there is no feedback whatsoever about where it
> was opened! Is _this_ lack of feedback that you "positively love"?

Oh, I heard you allright :-) And yes, as a matter of fact I do love it that it  
quietly goes away until I get around to it. And if that takes too long, it  
will let me know in the task bar that it needs attention...

Regards, Willem Riede.



From wrrhdev at riede.org  Mon Mar 27 23:21:46 2006
From: wrrhdev at riede.org (Willem Riede)
Date: Mon, 27 Mar 2006 18:21:46 -0500
Subject: FC5: first impressions
In-Reply-To: <Pine.LNX.4.62.0603262131490.3987@gotcha.dreamhost.com> (from
	pmatilai@laiskiainen.org on Mon Mar 27 00:48:20 2006)
References: <1a2301c64f86$283ce810$b6491b31@td612671>
	<1143239418.3802.233.camel@sundaram.pnq.redhat.com>
	<1b2301c64f94$b7a473c0$b6491b31@td612671>
	<200603261520.43696.billcrawford1970@googlemail.com>
	<1143384233.15323.16.camel@dimi>
	<1143385602l.19620l.3l@athena.riede.org>
	<Pine.LNX.4.62.0603262131490.3987@gotcha.dreamhost.com>
Message-ID: <1143501706l.26064l.2l@athena.riede.org>

On 03/27/2006 12:48:20 AM, Panu Matilainen wrote:
> On Sun, 26 Mar 2006, Willem Riede wrote:
> >
> > So there are different use cases, and at least an option will allow people to 
> > select the behavior that best fits them. FWIW I'm not convinced the ideal 
> > algorithm has been discovered, or is even possible, as if you ask me to 
> > define when I want a new window to come up with focus and when not, the 
> > answer is "that depends on what I want to do with it"...
> 
> Amen. Whether you want something to start focused or not depends 100% on 
> what you want to do with it *at that moment*. With browsers this is easy:
> just open up stuff in new tabs as you encounter interesting links, and 
> then process the tabs eventually. The computer could never, ever know 
> whether I want to read that link immediately or later so the decision has 
> to be mine. Simple enough, left-click or middle-click.
> 
> Maybe this is just a crack idea from a caffeine deprived mind but what if 
> left click meaned start with focus and middle click start without focus? 
> It's kinda similar to the open in new tab-case from browsers and I think 
> that concept has already shown it works and isn't beyond the grasp of the 
> so called "average use" either ;)

I like it. But it doesn't cover the case of guis started from a terminal.
Perhaps there if I type "application" it gets focus and if I type "application &" 
(which implies I want to be able to do other things in the terminal) it doesn't?

Regards, Willem Riede.



From Curtis at GreenKey.net  Mon Mar 27 23:23:24 2006
From: Curtis at GreenKey.net (Curtis Doty)
Date: Mon, 27 Mar 2006 15:23:24 -0800
Subject: CVS system migration done
In-Reply-To: <Pine.LNX.4.58.0603262248120.11932@devserv.devel.redhat.com>
References: <Pine.LNX.4.58.0603262248120.11932@devserv.devel.redhat.com>
Message-ID: <442873EC.1050702@GreenKey.net>

Elliot Lee wrote:
> Hi all,
>
> cvs.fedoraproject.org (aka cvs.fedora.redhat.com) has been migrated to a
> new system. Please let me know if there are any problems that need
> fixing...
>   
404 http://cvs.fedora.redhat.com/webfiles/

That was awhile ago. Right this instant I'm getting timeouts, though.

../C



From sdl.web at gmail.com  Mon Mar 27 23:44:00 2006
From: sdl.web at gmail.com (Leon)
Date: Tue, 28 Mar 2006 00:44:00 +0100
Subject: suspend/hibernate in the command line
Message-ID: <ur74n1min.fsf@gmail.com>

Hi all,

I can't find a simple command to suspend/hibernate the
computer. Sometimes I leave the computer on with music and want it to
go to suspenstion after a certain time. It would be even better if the
command doesn't need root privilege. Many thanks.

Regards,
Leon



From dax at gurulabs.com  Mon Mar 27 23:49:33 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Mon, 27 Mar 2006 16:49:33 -0700
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060327225928.GA16219@thyrsus.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
Message-ID: <1143503374.11720.12.camel@mentorng.gurulabs.com>

On Mon, 2006-03-27 at 17:59 -0500, Eric S. Raymond wrote:

> How did you make lid close do a suspend as it should?  

"as it should"

I don't like that behavior, so I turned off the setting in my BIOS and
in gnome-power-manager.

I don't know if there was an issue before.

Dax Kelson
Guru Labs



From docs-list at fedoralinks.org  Mon Mar 27 23:57:02 2006
From: docs-list at fedoralinks.org (Robert 'Bob' Jensen)
Date: Mon, 27 Mar 2006 17:57:02 -0600
Subject: [ANN] Release Notes Errata - Wiki Freeze
Message-ID: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>

Hello Docs, Devel and Marketing,

I would like to take a snapshot of the Release Notes Beats on the Wiki
to be used as an errata release for the web on Tuesday, April 4, 2006 at
23:59 UTC, we will clean up and push to translation on Thursday, April
6, 2006 giving translation a week to get as many languages available to
us over the following week. 

One question I have for Development is can we then roll these new
updated release notes and translations in to a package update for our
users?

The web and maybe package errata would be available on Friday, April 15,
2006. 

-- 
Robert 'Bob' Jensen <docs-list at fedoralinks.org>
Fedora Documentation Projects
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/b77b36b7/attachment.sig>

From jdesbonnet at gmail.com  Tue Mar 28 00:04:21 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 28 Mar 2006 01:04:21 +0100
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143503374.11720.12.camel@mentorng.gurulabs.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
Message-ID: <1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>

My model is a Thinkpad T41p: The best I can do with FC5 is what I was
able to achieve with FC4:

Suspend seems to go smoothly and seems to restore ok,  *BUT* after a
few seconds I get hard disk errors all over the place:

ide: failed opcode was: unknown
hda: task_out_intr: status=0x51 {DriveReady SeekComplete Error}
hda: task_out_intr: error=0x10 {SectorIdNotFound}, LBAsect=110365705,
sector=110365705

This error is repeated very rapidly and a disk check is needed on reboot.

I've tried acpi_sleep=s3_bios. This seems to help with screen
recovery, but the disk errors occur anyway.

Joe.






On 3/28/06, Dax Kelson <dax at gurulabs.com> wrote:
> On Mon, 2006-03-27 at 17:59 -0500, Eric S. Raymond wrote:
>
> > How did you make lid close do a suspend as it should?
>
> "as it should"
>
> I don't like that behavior, so I turned off the setting in my BIOS and
> in gnome-power-manager.
>
> I don't know if there was an issue before.
>
> Dax Kelson
> Guru Labs
>
>



From michael.favia at insitesinc.com  Tue Mar 28 00:08:08 2006
From: michael.favia at insitesinc.com (Michael Favia)
Date: Mon, 27 Mar 2006 18:08:08 -0600
Subject: GUI controls for instrumentation
In-Reply-To: <010501c651c7$0e9d7620$b6491b31@td612671>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226><200603242033.03945.lamont@gurulabs.com><1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com><1143281498.4018.6.camel@rousalka.dyndns.org>	<20060327172315.GE19155@redhat.com>
	<010501c651c7$0e9d7620$b6491b31@td612671>
Message-ID: <44287E68.7020605@insitesinc.com>

Dimi Paun wrote:
> From: "Andrew Overholt" <overholt at redhat.com>
>> Perhaps I'm missing context here, but I sense an implication that
> something
>> is wrong with "the current situation".  Am I correct?
> 
> Well, now that you mention it... :)
> If I point the native Eclipse to one of my workspaces
> that I created (and worked in) with the Java Eclipse,
> it doesn't recognize it as a workspace at all, and
> gives me the Welcome screen.
> 
> Trying to "Switch workspace" from the File menu has
> the same effect. What gives?
> 
wfm. no reproduce.

-- 
Michael Favia          michael.favia at insitesinc.com
Insites Incorporated  http://michael.insitesinc.com



From esr at thyrsus.com  Tue Mar 28 00:09:16 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 27 Mar 2006 19:09:16 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
Message-ID: <20060328000916.GA16973@thyrsus.com>

Joe Desbonnet <jdesbonnet at gmail.com>:
> My model is a Thinkpad T41p: The best I can do with FC5 is what I was
> able to achieve with FC4:
> 
> Suspend seems to go smoothly and seems to restore ok,  *BUT* after a
> few seconds I get hard disk errors all over the place:
> 
> ide: failed opcode was: unknown
> hda: task_out_intr: status=0x51 {DriveReady SeekComplete Error}
> hda: task_out_intr: error=0x10 {SectorIdNotFound}, LBAsect=110365705,
> sector=110365705
> 
> This error is repeated very rapidly and a disk check is needed on reboot.
> 
> I've tried acpi_sleep=s3_bios. This seems to help with screen
> recovery, but the disk errors occur anyway.

That's wacky.  Doesn't happen on an X40, thank goodness.  Which is interesting,
because several of my sources claim the T40 and X40 are electronically 
identical, with X40 just being skrunched into a smaller form factor.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From david at fubar.dk  Tue Mar 28 00:36:23 2006
From: david at fubar.dk (David Zeuthen)
Date: Mon, 27 Mar 2006 19:36:23 -0500
Subject: suspend/hibernate in the command line
In-Reply-To: <ur74n1min.fsf@gmail.com>
References: <ur74n1min.fsf@gmail.com>
Message-ID: <1143506183.5625.6.camel@daxter.boston.redhat.com>

On Tue, 2006-03-28 at 00:44 +0100, Leon wrote:
> Hi all,
> 
> I can't find a simple command to suspend/hibernate the
> computer. Sometimes I leave the computer on with music and want it to
> go to suspenstion after a certain time. It would be even better if the
> command doesn't need root privilege. Many thanks.

If you run gnome-power-manager just pressing the "sleep" button on your
computer or your keyboard should suffice. Otherwise use the
System->Suspend menu option in GNOME. See

 http://www.gnome.org/projects/gnome-power-manager/

for details. I believe you can even run this from KDE or other desktops
that support the freedesktop.org notification area spec.

For command line use 'pm-suspend'; it doesn't require root if (and only
if) you are logged in at the console.

    David




From tibbs at math.uh.edu  Tue Mar 28 01:32:25 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Mon, 27 Mar 2006 19:32:25 -0600
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <20060327182323.GB16210@redhat.com> (Dave Jones's message of
	"Mon, 27 Mar 2006 13:23:23 -0500")
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060324202627.GD2725@redhat.com>
	<ufapsk8h41m.fsf@epithumia.math.uh.edu>
	<20060327182323.GB16210@redhat.com>
Message-ID: <ufawtefe4ly.fsf@epithumia.math.uh.edu>

>>>>> "DJ" == Dave Jones <davej at redhat.com> writes:

>> FC5 doesn't install a SMP kernel on this machine

DJ> sounds like an installer bug.

The default install is kind of bizarre:

title Fedora Core (2.6.15-1.2054_FC5)
        root (hd0,0)
        kernel /vmlinuz-2.6.15-1.2054_FC5 ro root=/dev/vg0/root vga=6
        initrd /initrd-2.6.15-1.2054_FC5.img
title Fedora Core-up (2.6.15-1.2054_FC5)
        root (hd0,0)
        kernel /vmlinuz-2.6.15-1.2054_FC5 ro root=/dev/vg0/root vga=6
        initrd /initrd-2.6.15-1.2054_FC5.img

I'm not sure why it decided to include two identical stanzas with
"-up" appended to one.  The one kernel that's installed is the i586 UP
one.  I installed the i686 UP kernel, and it does start to boot but
panics around the time it should mount the real root filesystem.  This
might just be an initrd thing; can you install both the i586 and i686
kernels at the same time?

I'm on a bit of a vacation but I will try to get some information you
can actually use (i.e. actual error messages) when I'm back in the
office.

 - J<



From jarod at wilsonet.com  Tue Mar 28 02:10:42 2006
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 27 Mar 2006 18:10:42 -0800
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <ufawtefe4ly.fsf@epithumia.math.uh.edu>
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060327182323.GB16210@redhat.com>
	<ufawtefe4ly.fsf@epithumia.math.uh.edu>
Message-ID: <200603271810.45568.jarod@wilsonet.com>

On Monday 27 March 2006 17:32, Jason L Tibbitts III wrote:
> >>>>> "DJ" == Dave Jones <davej at redhat.com> writes:
> >>
> >> FC5 doesn't install a SMP kernel on this machine
>
> DJ> sounds like an installer bug.
>
> The default install is kind of bizarre:
>
> title Fedora Core (2.6.15-1.2054_FC5)
>         root (hd0,0)
>         kernel /vmlinuz-2.6.15-1.2054_FC5 ro root=/dev/vg0/root vga=6
>         initrd /initrd-2.6.15-1.2054_FC5.img
> title Fedora Core-up (2.6.15-1.2054_FC5)
>         root (hd0,0)
>         kernel /vmlinuz-2.6.15-1.2054_FC5 ro root=/dev/vg0/root vga=6
>         initrd /initrd-2.6.15-1.2054_FC5.img
>
> I'm not sure why it decided to include two identical stanzas with
> "-up" appended to one.  The one kernel that's installed is the i586 UP
> one.  I installed the i686 UP kernel, and it does start to boot but
> panics around the time it should mount the real root filesystem.  This
> might just be an initrd thing; can you install both the i586 and i686
> kernels at the same time?

I'd wager that if the installer only gave you an i586 kernel, it didn't give 
you the i686 glibc either. I wonder if that could be inducing some of the 
problems you're seeing w/i686 kernels... I'd check your glibc version...

rpm -q --qf='%{name}-%{version}-%{release}.%{arch}\n' glibc

...and maybe try slapping the i686 one in there for giggles.

(Note to self, maybe its time to see what an FC5 install does on my own 
EPIA...)

-- 
Jarod Wilson
jarod at wilsonet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/7a540d98/attachment.sig>

From pjones at redhat.com  Mon Mar 27 18:15:04 2006
From: pjones at redhat.com (Peter Jones)
Date: Mon, 27 Mar 2006 13:15:04 -0500
Subject: FC5 weird raid issues
In-Reply-To: <200603270917.53027.jarod@wilsonet.com>
References: <442423F7.7060100@feuerpokemon.de> <4426643E.10405@feuerpokemon.de>
	<5255-SnapperMsg827D11E1C04D0008@[68.27.157.67]>
	<200603270917.53027.jarod@wilsonet.com>
Message-ID: <1143483304.20578.21.camel@vroomfondel.internal.datastacks.com>

On Mon, 2006-03-27 at 09:17 -0800, Jarod Wilson wrote:

> Not to mention that fake raid10 doesn't quite work yet... :)

That depends on which controller you have.  It seems to work for me with
SiL.

-- 
  Peter



From sdl.web at gmail.com  Tue Mar 28 02:48:59 2006
From: sdl.web at gmail.com (Leon)
Date: Tue, 28 Mar 2006 03:48:59 +0100
Subject: suspend/hibernate in the command line
References: <ur74n1min.fsf@gmail.com>
	<1143506183.5625.6.camel@daxter.boston.redhat.com>
Message-ID: <m2psk7p9lw.fsf@sl392.st-edmunds.cam.ac.uk>

David Zeuthen <david at fubar.dk> writes:

> On Tue, 2006-03-28 at 00:44 +0100, Leon wrote:
>> Hi all,
>> 
>> I can't find a simple command to suspend/hibernate the
>> computer. Sometimes I leave the computer on with music and want it to
>> go to suspenstion after a certain time. It would be even better if the
>> command doesn't need root privilege. Many thanks.
>
> If you run gnome-power-manager just pressing the "sleep" button on your
> computer or your keyboard should suffice. Otherwise use the
> System->Suspend menu option in GNOME. See
>
>  http://www.gnome.org/projects/gnome-power-manager/
>
> for details. I believe you can even run this from KDE or other desktops
> that support the freedesktop.org notification area spec.
>
> For command line use 'pm-suspend'; it doesn't require root if (and only
> if) you are logged in at the console.
>
>     David

Thanks a lot, David.

-- 
Leon



From tibbs at math.uh.edu  Tue Mar 28 02:59:01 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Mon, 27 Mar 2006 20:59:01 -0600
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <200603271810.45568.jarod@wilsonet.com> (Jarod Wilson's message
	of "Mon, 27 Mar 2006 18:10:42 -0800")
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060327182323.GB16210@redhat.com>
	<ufawtefe4ly.fsf@epithumia.math.uh.edu>
	<200603271810.45568.jarod@wilsonet.com>
Message-ID: <ufaodzre0lm.fsf@epithumia.math.uh.edu>

>>>>> "JW" == Jarod Wilson <jarod at wilsonet.com> writes:

JW> I'd wager that if the installer only gave you an i586 kernel, it
JW> didn't give you the i686 glibc either.

Oddly enough, it did give me the i686 glibc:

> rpm -q --qf '%{ARCH}\n' glibc
i686

 - J<



From pjones at redhat.com  Tue Mar 28 03:15:41 2006
From: pjones at redhat.com (Peter Jones)
Date: Mon, 27 Mar 2006 22:15:41 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
Message-ID: <1143515743.6910.5.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 01:04 +0100, Joe Desbonnet wrote:
> My model is a Thinkpad T41p: The best I can do with FC5 is what I was
> able to achieve with FC4:
> 
> Suspend seems to go smoothly and seems to restore ok,  *BUT* after a
> few seconds I get hard disk errors all over the place:
> 
> ide: failed opcode was: unknown
> hda: task_out_intr: status=0x51 {DriveReady SeekComplete Error}
> hda: task_out_intr: error=0x10 {SectorIdNotFound}, LBAsect=110365705,
> sector=110365705
> 
> This error is repeated very rapidly and a disk check is needed on reboot.

So, when you're booting up you probably see some text that's something
like:

hda: Host Protected Area detected.
        current capacity is 110194034 sectors (56419 MB)
        native  capacity is 117210240 sectors (60011 MB)
hda: Host Protected Area disabled.
hda: 117210240 sectors (60011 MB) w/7877KiB Cache, CHS=65535/16/63, UDMA(100)

This is a rather unfortunate bug.  When the disk starts up, it claims to
have 110194034 (on mine, yours may vary some) sectors accessible, but
117210240 total.  We then issue a SET MAX ADDRESS EXT command to the
drive to make all of the sectors available.  When you suspend, the drive
powers down.  When you resume, it comes back, but we don't issue that
command again.

I've got a fix that puts this into the control of the userland, but it's
not quite 100% just yet; hopefully it'll be working tomorrow.

The workaround right now is to reinstall, manually partition and be
absolutely sure not to use more than 56419345408 bytes (110194034 * 512,
again the number for your machine may vary) of the disk.

-- 
  Peter



From katzj at redhat.com  Tue Mar 28 03:28:35 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 27 Mar 2006 22:28:35 -0500
Subject: [ANN] Release Notes Errata - Wiki Freeze
In-Reply-To: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
Message-ID: <1143516515.3140.1.camel@aglarond.local>

On Mon, 2006-03-27 at 17:57 -0600, Robert 'Bob' Jensen wrote:
> One question I have for Development is can we then roll these new
> updated release notes and translations in to a package update for our
> users?

Traditionally, we haven't done updates to the fedora-release package to
avoid some potential confusion/snafus.  It's something we could consider
doing I guess.

Jeremy



From z at canteiros.org  Tue Mar 28 05:09:29 2006
From: z at canteiros.org (Z)
Date: Mon, 27 Mar 2006 21:09:29 -0800
Subject: frequent lockups with i686 kernel dual opteron
In-Reply-To: <1143515743.6910.5.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>	<442825C7.4020608@poolshark.org>	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>	<20060327202457.GA15056@thyrsus.com>	<1143498560.11720.8.camel@mentorng.gurulabs.com>	<20060327225928.GA16219@thyrsus.com>	<1143503374.11720.12.camel@mentorng.gurulabs.com>	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<1143515743.6910.5.camel@vroomfondel.internal.datastacks.com>
Message-ID: <4428C509.8020906@canteiros.org>

I managed to get a fully stable kernel with a custom kernel:

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

Whatever it is, it seems related to heavy disk use. I disabled speedstep 
and a bunch of experimental features. I'll try reenabling the options 
until I get the bad one.


Z



From jarod at wilsonet.com  Tue Mar 28 06:37:54 2006
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 27 Mar 2006 22:37:54 -0800
Subject: FC5 weird raid issues
In-Reply-To: <1143483304.20578.21.camel@vroomfondel.internal.datastacks.com>
References: <442423F7.7060100@feuerpokemon.de>
	<200603270917.53027.jarod@wilsonet.com>
	<1143483304.20578.21.camel@vroomfondel.internal.datastacks.com>
Message-ID: <200603272237.57927.jarod@wilsonet.com>

On Monday 27 March 2006 10:15, Peter Jones wrote:
> On Mon, 2006-03-27 at 09:17 -0800, Jarod Wilson wrote:
> > Not to mention that fake raid10 doesn't quite work yet... :)
>
> That depends on which controller you have.  It seems to work for me with
> SiL.

Is that with the FC5 installer alone, or with an updated libdmraid? I never 
did get around to trying that. Neither a sil or nvidia dmraid10 worked for 
me.

-- 
Jarod Wilson
jarod at wilsonet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060327/b997e706/attachment.sig>

From n0dalus+redhat at gmail.com  Tue Mar 28 06:49:22 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Tue, 28 Mar 2006 17:19:22 +1030
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
Message-ID: <6280325c0603272249g49765da9sa2fdc4fea8de6bf@mail.gmail.com>

On 3/26/06, Shane Stixrud <shane at geeklords.org> wrote:
>
> Sed is a wonderful tool, but it is highly limited by the fact its user
> must take into account whole file(s) for each expression, this is further
> complicated when one must consider the file may change over time.  The
> complexity and readability of regular expression tools is much higher than
> should be required to change OS/application variables.
>
> Creating new files or appending to the end of existing files with "echo"
> only takes one so far.  This also tends to have the cost of hurting
> readability as it is often the case you would prefer putting data
> somewhere else in the file (i.e. sed).
>
> The nature of flat configuration files where each application has its own
> format is such where recovery and/or applying changes only if they have
> not been already applied is too complex and hurts readability far to much
> to be attempted in a simple shell script.
>

One tool I did not see you list is `patch`. A context diff can still
work even when the file has changed significantly, and the format is
extremely readable (just + or -.) Maintaining a collection of diffs is
going to be significantly easier to manage than dealing with a large
number of cp/mv/echo/sed commands in shell files. There are also a
variety of tools made to deal with diffs and can show them in
graphical, friendly ways.

There might be a good reason not to use diff/patch for doing what you
want, but I think that it could save a few headaches.

n0dalus.



From che666 at gmail.com  Tue Mar 28 07:47:24 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 28 Mar 2006 09:47:24 +0200
Subject: Bootsplash?
In-Reply-To: <1143326561.10632.5.camel@localhost>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143211193.3802.120.camel@sundaram.pnq.redhat.com>
	<1143267968.2247.3.camel@price.stavtrup-st.dk>
	<1143289811.2261.10.camel@localhost.localdomain>
	<1143294595.2428.4.camel@price.stavtrup-st.dk>
	<1143298491.2297.2.camel@localhost.localdomain>
	<1143326561.10632.5.camel@localhost>
Message-ID: <e99d27470603272347i1b997674m3c5060c93e6694e2@mail.gmail.com>

2006/3/26, Callum Lerwick <seg at haxxed.com>:
> On Sat, 2006-03-25 at 14:54 +0000, Richard Hughes wrote:
> > Whats wrong with doing something with the framebuffer (like this) before
> > we do the hibernate:
>
> Well, one major problem is the fact that fbcon and X do not get along on
> some hardware. In particular, using rivafb and native X nv together is a
> guaranteed system lockup on all nVidia hardware I've ever tried it on.
>
> Can't really use framebuffer for anything until this is worked out.
>
> Seems to me you could just stick to good old VGA though. (svgalib...) Or
> maybe just do graphics in textmode... (hint: change the font...)
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQBEJcdgI3BVKRcrX7cRAjk8AKDCrreDM3GXKsBWXJZp5J4sfzaE0gCZAS1r
> YCAHmGldC1m2rrWAgq47WKc=
> =kzsw
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>

same with nvidiafb btw. if you got a newer card nvidiafb works quite
better than the old rivafb.



From nicolas.mailhot at laposte.net  Tue Mar 28 07:52:47 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Mar 2006 09:52:47 +0200 (CEST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060327153933.47f5dc33.seanlkml@sympatico.ca>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<20060327153933.47f5dc33.seanlkml@sympatico.ca>
Message-ID: <15188.192.54.193.25.1143532367.squirrel@rousalka.dyndns.org>


Le Lun 27 mars 2006 22:39, sean a ?crit :

> No matter what you come up with though, it will be many years before
> you see wide spread adoption.   If anything, you might consider a
> project to create a system-wide config editor that knows all
> the different formats etc and provides a consistent CLI/GUI
> interface.

Yay, return of the linuxconf

It will break for the same reason that linuxconf failed - even a GUI needs
some config file consistency to work. It will fail like the current
printer setup fails. If you want it to work conf syntax and GUI/CLI tools
must be carefuly thought of and aligned, or you'll only produce brittle
GUI tools which eat  conf files at the first opportunity.

*If* a core set of apps could be moved to a modern consistent format then
one could try to evangelize it later. This is something the gconf people
botched big time by focusing on the GUI and generating files no one could
sanely modify in a text editor (and no xml is not the reason. Serializing
stuff without thinking is the reason. Abusing human-unfriendly UUIDs is
the reason)

My suggesting if you want this to happen is :

1. create a new gconf backend with files people can actually change in vi
of emacs
2. once you've proved you've a solid candidate both GUI and CLi cand work
with, try to sell it to everyone else

But if you're not able to switch gnome (which has a single point of entry
- gconf) you've got zip chances to get rid of the others legacy formats

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Mar 28 07:56:07 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Mar 2006 09:56:07 +0200 (CEST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060327165151.6cc02f1f.seanlkml@sympatico.ca>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<20060327165151.6cc02f1f.seanlkml@sympatico.ca>
Message-ID: <23495.192.54.193.25.1143532567.squirrel@rousalka.dyndns.org>

Also do remember some configuration settings are used by
security-sensitive apps, so your parser code had better be auditable and
clean before they even consider switching


-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Mar 28 07:59:16 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Mar 2006 09:59:16 +0200 (CEST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
Message-ID: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>


Le Mar 28 mars 2006 00:36, Shane Stixrud a ?crit :
> On Mon, 27 Mar 2006, sean wrote:
>
>> Well the line is somewhere around the area of those who can look
>> at a config file and figure it out in a minute or two, and those who
>> can't.   Anyone who can't deal with today's config files, isn't
>> going to be any better off with a nice gui version of that
>> same process.
>
> I would be insulted if I didn't know you were just making a generalized
> statement :).  Who here hasn't spent more than 2 minutes trying to figure
> a missing period in a named conf file, or more than two minutes setting up
> ldap for the first time, or more than two minutes figuring out where to
> find a specific option and value for /etc/modules.conf etc...

The difference between a traditional conf file and a gconf file is not so
much the XML syntax. Rather traditional conf files authors try very hard
to find key names which are easy to understand and key values which can be
entered by a human, while gconf authors dump garbage in their files since
they expect it to be hidden from users and kept "private"

-- 
Nicolas Mailhot



From lamont at gurulabs.com  Tue Mar 28 08:03:36 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 28 Mar 2006 01:03:36 -0700
Subject: GUI controls for instrumentation
In-Reply-To: <20060326181557.68fcfc46@lain>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<1143389147.2816.6.camel@rousalka.dyndns.org>
	<20060326181557.68fcfc46@lain>
Message-ID: <200603280103.40598.lamont@gurulabs.com>

On Sunday 26 March 2006 09:15am, Ralf Ertzinger wrote:
> Hi.
>
> On Sun, 26 Mar 2006 18:05:46 +0200, Nicolas Mailhot wrote
>
> > If you have 100% control of the systems and can deploy a single
> > controlled jvm everywhere, yes java-on-desktop is doable
>
> If you have 100% control of the systems _every_ language is
> write-once-run-anywhere. Even BASIC.

Which is basically why Java doesn't buy you anything in the portability arena.  
There are some applications for which Java is an ideal choice (like dealing 
with lots of XML).

For an instrumentation application, Java would be a HUGE mistake.

For an instrumentation application, C++ is a very sane choice.  There are lots 
of benefits and lots and lots of libraries for all sorts of I/O, control & 
input cards/systems out there.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/9e44de39/attachment.sig>

From lamont at gurulabs.com  Tue Mar 28 08:06:33 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 28 Mar 2006 01:06:33 -0700
Subject: GUI controls for instrumentation
In-Reply-To: <1143394041.2816.10.camel@rousalka.dyndns.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<4426C83F.5060300@yahoo.co.uk>
	<1143394041.2816.10.camel@rousalka.dyndns.org>
Message-ID: <200603280106.33638.lamont@gurulabs.com>

On Sunday 26 March 2006 10:27am, Nicolas Mailhot wrote:
> Le dimanche 26 mars 2006 ? 17:58 +0100, Dariusz J. Garbowski a ?crit :
> > On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
> > > Le samedi 25 mars 2006 ? 12:06 +0000, Dariusz J. Garbowski a ?crit :
> > >> .
> > >> But I can see that in some environments Java on the desktop may be a
> > >> support issue.
> > >
> > > Java is only write-once, run everywhere if you define everywhere as a
> > > very specific static OS image :(
> >
> > Come to think of that... Any multi-platform, multi-os or even
> > multi-distro (where w95/w98/w2k/wxp can be called "distro" for the
> > purpose of this argument) will suffer from mentioned support issues
>
> Sure, but other software communities recognize the problem and try to
> create tools to ease the pain. Sun java is unfortunately often in denial
> and lala-lala land when you try to tell them there is a wide margin
> between write once and run everywhere in the actual world

I have yet to write Qt code on one platform that required any tweaking (except 
to add Windows Registry use when the "need" arose) to compile on all other 
platforms for which Qt is available and to which I have access.

Qt is great write once, compile many places portability.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/919b32b2/attachment.sig>

From buildsys at redhat.com  Tue Mar 28 08:37:14 2006
From: buildsys at redhat.com (Build System)
Date: Tue, 28 Mar 2006 03:37:14 -0500
Subject: rawhide report: 20060328 changes
Message-ID: <200603280837.k2S8bEZR024955@porkchop.devel.redhat.com>

 

 
Updated Packages:

checkpolicy-1.30.1-2
--------------------
* Mon Mar 27 2006 Dan Walsh <dwalsh at redhat.com> - 1.30.1-2
- Rebuild with new libsepol

cups-1:1.2-0.2.rc1.1
--------------------
* Mon Mar 27 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.2.rc1.1
- Ship a printers.conf file, and a client.conf file.  That way, they get
  their SELinux file contexts set correctly.

* Mon Mar 27 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.2.rc1.0
- 1.2rc1.

fribidi-0.10.7-1
----------------
* Mon Mar 27 2006 Caolan McNamara <caolanm at redhat.com> 0.10.7-1
- latest version

g-wrap-1.9.6-3
--------------
* Mon Mar 27 2006 Bill Nottingham <notting at redhat.com> 1.9.6-3
- build against glib2

gnucash-1.9.3-1
---------------
* Mon Mar 27 2006 Bill Nottingham <notting at redhat.com> - 1.9.3-1
- update to 1.9.x

inn-2.4.3-1
-----------
* Mon Mar 27 2006 Martin Stransky <stransky at redhat.com> 2.4.3-1
- new upstream

iproute-2.6.16-1
----------------
* Sun Mar 26 2006 Radek Vok??l <rvokal at redhat.com> - 2.6.16-1
- upgrade to 2.6.16-060323
- don't hardcode /usr/lib in tc (#186607)

kbd-1.12-14
-----------
* Mon Mar 27 2006 Miloslav Trmac <mitr at redhat.com> - 1.12-14
- Don't install resizecons.8 on non-x86 (#186877, patch by Keiichi Mori
  <kmori at redhat.com>)

kernel-2.6.16-1.2097_FC6
------------------------
* Mon Mar 27 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git13

* Sat Mar 25 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git10

* Fri Mar 24 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git9

liboil-0.3.8-2
--------------
* Mon Mar 27 2006 Ray Strode <rstrode at redhat.com> 0.3.8-2
- Update to 0.3.8 (bug 186930)

* Tue Mar 21 2006 Matthias Saou <http://freshrpms.net/> 0.3.7.1-1
- Update to today's CVS code which should fix the PPC build issue.
- Include new oil-bugreport tool in the devel package.

* Mon Mar 06 2006 Matthias Saou <http://freshrpms.net/> 0.3.7-3
- FC5 rebuild (well, try at least since PPC fixes are required).

libsepol-1.12.3-1
-----------------
* Mon Mar 27 2006 Dan Walsh <dwalsh at redhat.com> 1.12.3-1
- Upgrade to latest from NSA
	* Fixed attr_convert_callback and expand_convert_type_set
	  typemap bug.

logwatch-7.3-1
--------------
* Mon Mar 27 2006 Ivana Varekova <varekova@ redhat.com> 7.3-1
- update to 7.3
- added samba, up2date

mod_authz_ldap-0.26-7
---------------------
* Mon Mar 27 2006 Joe Orton <jorton at redhat.com> 0.26-7
- don't package INSTALL
- define -DLDAP_DEPRECATED=1 in CPPFLAGS

mysql-5.0.18-4
--------------
* Mon Mar 27 2006 Tom Lane <tgl at redhat.com> 5.0.18-4
- Modify multilib header hack to not break non-RH arches, per bug #181335
- Remove logrotate script, per bug #180639.
- Add a new mysql-test RPM to carry the regression test files;
  hack up test scripts as needed to make them run in /usr/share/mysql-test.

mysql-connector-odbc-3.51.12-2
------------------------------
* Mon Mar 27 2006 Tom Lane <tgl at redhat.com> 3.51.12-2
- Remove DLL-unload cleanup call from connection shutdown (bz#185343)

postgresql-8.1.3-2
------------------
* Mon Mar 27 2006 Tom Lane <tgl at redhat.com> 8.1.3-2
- Remove JDBC from this build; we will package it as separate SRPM

* Mon Feb 13 2006 Jesse Keating <jkeating at redhat.com> - 8.1.3-1.1
- rebump for build order issues during double-long bump

pykickstart-0.25-1
------------------
* Mon Mar 27 2006 Chris Lumens <clumens at redhat.com> 0.25-1
- Add support for the logging command.

* Mon Mar 27 2006 Chris Lumens <clumens at redhat.com> 0.24-1 
- Don't write out a blank xconfig line.
- Reorder output handlers to group like commands together.
- Mark strings for translation.

selinux-policy-2.2.25-2
-----------------------
* Wed Mar 22 2006 Dan Walsh <dwalsh at redhat.com> 2.2.25-2
- Fix pam_console handling of usb_device
- dontaudit logwatch reading /mnt dir

* Fri Mar 17 2006 Dan Walsh <dwalsh at redhat.com> 2.2.24-1
- Update to upstream

* Wed Mar 15 2006 Dan Walsh <dwalsh at redhat.com> 2.2.23-19
- Get transition rules to create policy.20 at SystemHigh

spamassassin-3.1.1-1.fc6
------------------------
* Sat Mar 11 2006 Warren Togami <wtogami at redhat.com> - 3.1.1-1
- 3.1.1

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 3.1.0-5
- bump again for double-long bug on ppc(64)

* Tue Feb 07 2006 Jesse Keating <jkeating at redhat.com> - 3.1.0-5
- rebuilt for new gcc4.1 snapshot and glibc changes

system-config-kickstart-2.6.8-1
-------------------------------
* Mon Mar 27 2006 Chris Lumens <clumens at redhat.com> 2.6.8-1 
- Fix loading kickstart files (#186944).

* Mon Mar 27 2006 Chris Lumens <clumens at redhat.com> 2.6.7-1 
- Fix support for --generate (#186635).

tix-1:8.4.0-5
-------------
* Mon Mar 27 2006 David Cantrell <dcantrell at redhat.com> - 1:8.4.0-5
- Make sure libTix8.4.so is in /usr/lib/Tix8.4

unixODBC-2.2.11-7
-----------------
* Mon Mar 27 2006 Tom Lane <tgl at redhat.com> 2.2.11-7
- Fix minor problems in desktop files (bug #185764)

wpa_supplicant-1:0.4.8-6.fc6
----------------------------
* Mon Mar 27 2006 Dan Williams <dcbw at redhat.com> - 0.4.8-6
- Add patch to make orinoco happy with WEP keys
- Enable Prism54-specific driver
- Disable ipw-specific driver; ipw2x00 should be using WEXT instead

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From pemboa at gmail.com  Tue Mar 28 08:43:27 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 28 Mar 2006 02:43:27 -0600
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
Message-ID: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>

Seems to me, that someone with the drive and IQ needs to develop a system so
flexible and easy to use (eg. having prebuilt modules for diff. languages)
that many developers with decide to use it instead of rolling their own. I
would not advocate XML for this however.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/f3e3bb44/attachment.htm>

From seanlkml at sympatico.ca  Tue Mar 28 08:52:17 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 03:52:17 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <15188.192.54.193.25.1143532367.squirrel@rousalka.dyndns.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<20060327153933.47f5dc33.seanlkml@sympatico.ca>
	<15188.192.54.193.25.1143532367.squirrel@rousalka.dyndns.org>
Message-ID: <BAYC1-PASMTP1005B933FA9B1ECF1D380AAED30@CEZ.ICE>

On Tue, 28 Mar 2006 09:52:47 +0200 (CEST)
"Nicolas Mailhot" <nicolas.mailhot at laposte.net> wrote:

> Le Lun 27 mars 2006 22:39, sean a ?crit :
> 
> > No matter what you come up with though, it will be many years before
> > you see wide spread adoption.   If anything, you might consider a
> > project to create a system-wide config editor that knows all
> > the different formats etc and provides a consistent CLI/GUI
> > interface.
> 
> Yay, return of the linuxconf
> 
> It will break for the same reason that linuxconf failed - even a GUI needs
> some config file consistency to work. It will fail like the current
> printer setup fails. If you want it to work conf syntax and GUI/CLI tools
> must be carefuly thought of and aligned, or you'll only produce brittle
> GUI tools which eat  conf files at the first opportunity.

Well, I think the conversation moved past this point rather quickly for
good reasons.  But what I was actually thinking of when I mentioned it was
something much simpler than linuxconf.

The original post by Shane mentioned the limitations of sed when trying to
modify config files.  My notion was of something slightly smarter than
sed that would have no idea of valid key names or values.  Just something,
that could parse a config file and spit out a slightly modified version.   

This might help a bit in his original scenario of trying to create 
installation scripts that need to modify the system config automatically.   
For that, it would at least be slightly less brittle than sed and
provide a standard syntax for modifying any config it knew about.  If
a programmer set out with enough lack of ambition, it shouldn't fall
into the same trap as linuxconf.

Sean



From seanlkml at sympatico.ca  Tue Mar 28 09:09:53 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 04:09:53 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
Message-ID: <BAYC1-PASMTP113DF5A162CE9051B98C5BAED30@CEZ.ICE>

On Tue, 28 Mar 2006 02:43:27 -0600
"Arthur Pemberton" <pemboa at gmail.com> wrote:

> Seems to me, that someone with the drive and IQ needs to develop a system so
> flexible and easy to use (eg. having prebuilt modules for diff. languages)
> that many developers with decide to use it instead of rolling their own. I
> would not advocate XML for this however.

Think you've actually hit the nail on the head Arthur; if a good 
solution exists developers will use it.   Although it might help a bit
to get some exposure for the solution on freedesktop.org or other
developer sites.

As for XML, with a proper API there's no reason to worry much about the 
format of the configuration data files.   The applications would never
look directly inside any config file anyway.   Some people might
want to use a central SQL server for config files, someone else
might want to use traditional /etc flat files etc..

Sean



From che666 at gmail.com  Tue Mar 28 09:31:59 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 28 Mar 2006 11:31:59 +0200
Subject: GUI controls for instrumentation
In-Reply-To: <442529EB.2040004@yahoo.co.uk>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
	<442529EB.2040004@yahoo.co.uk>
Message-ID: <e99d27470603280131o7b790f4oe90cd722999c8aff@mail.gmail.com>

2006/3/25, Dariusz J. Garbowski <thuforuk at yahoo.co.uk>:
> On 03/25/2006 10:59 AM, Nicolas Mailhot wrote:
> > Le samedi 25 mars 2006 ? 10:47 +0000, Dariusz J. Garbowski a ?crit :
> >
> >>> If it where that easy, we'd have the latest eclipse version in Fedora
> >>> with all the major plugins instead of the current situation.
> >> Heh, it *is* that easy -- get Sun's Java stack, install, download your
> >> app of choice, install and run!
> >
> > It's not, I'm sorry. You require lots of end-user work to make it
> > anything like work. That's why a stupid app like the logitech remote
> > controler (which has very simple fontionnality) is still not available
> > for linux even if it was written in java to be cross-platform.
>
> There's nothing in the applications themselves to stop working on Linux.
> Work user has to put comes from the fact that distributions tend to make
> user's life more difficult by not making it trivial to have e.g. Sun's
> JRE installed (I don't want to blame distro developers here, Sun is
> probably the most guilty by not allowing to repackage and redistribute
> JRE). Yet situation is IMHO similar to proprietary NVidia drivers: users
> just have it easier thanks to the work of Livna developers (at least on
> Fedora). And, hey!, users still manage to install proprietary nvidia
> drivers from NVidia rather than Livna, with all the hassle it makes!
> Users are not stupid, they are ready and able to do quite a few things
> when they have clear instructions.
>
> Let's say we have "Livna JRE" to install using yum. What's missing to
> make running Java apps trivial is making sure that there is at least a
> simple shell script to run it from command line. Say, user opens up "Run
> Command" dialog and types "jmeter" and it just starts. Of course the
> script would need to line on $PATH. Other "use case" is user opens up
> application's directory and double clicks the script. Application
> starts. Many applications already do provide it: NetBeans, Eclipse,
> JMeter...
>
> Then a step further is packaging applications for distro, like each
> other native application.
>
>
> > For a developper java is easy. As soon as you need an average end-user
> > to make it work and are paying the support costs it suddenly is no
> > longer anywhere near a good choice.
>
> Nothing to do with Java applications, it's all about packaging. If your
> application is packaged for Linux, it will be easy to run! Vice versa it
> can be difficult for Windows if it's not packaged for Windows. Where's
> Java fault here?
>
>
> > And I'm not even talking about the differences between jvm behaviour (if
> > you think you can go sun-only just compare the arches sun, ibm and bea
> > support)
>
> You asked about *easy* way -- the easiest, least troublesome is to use
> Sun's JRE. You are free to try other solutions too. You have this
> freedom. It's good. Don't want problems? Try Sun first. If you really
> need to run on more exotic hardware, you are likely to hit other issues,
> yet it's a particular JRE's issue. Bug IBM/Sun/BEA to fix it :-)
>
> Same with free stack. Everybody knows it's not quite there yet to run
> all Java software. And yes there's a few Java apps out there using sun.*
> packages -- not a Java issue either. Bug application developer to fix it
> so it's ready for free stack.
>
> Want to avoid as much issues as you can? Get Sun's JRE and make sure
> it's on your PATH before free stack is.
>
> Regards,
> Dariusz
>
>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

theres gcj... why would a linux user make his source dependendant on
non free things?

regards,
rudolf  kastl



From che666 at gmail.com  Tue Mar 28 09:33:54 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 28 Mar 2006 11:33:54 +0200
Subject: GUI controls for instrumentation
In-Reply-To: <e99d27470603280131o7b790f4oe90cd722999c8aff@mail.gmail.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>
	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
	<442529EB.2040004@yahoo.co.uk>
	<e99d27470603280131o7b790f4oe90cd722999c8aff@mail.gmail.com>
Message-ID: <e99d27470603280133g526585f1yfda4323ad64dbf56@mail.gmail.com>

2006/3/28, Rudolf Kastl <che666 at gmail.com>:
> 2006/3/25, Dariusz J. Garbowski <thuforuk at yahoo.co.uk>:
> > On 03/25/2006 10:59 AM, Nicolas Mailhot wrote:
> > > Le samedi 25 mars 2006 ? 10:47 +0000, Dariusz J. Garbowski a ?crit :
> > >
> > >>> If it where that easy, we'd have the latest eclipse version in Fedora
> > >>> with all the major plugins instead of the current situation.
> > >> Heh, it *is* that easy -- get Sun's Java stack, install, download your
> > >> app of choice, install and run!
> > >
> > > It's not, I'm sorry. You require lots of end-user work to make it
> > > anything like work. That's why a stupid app like the logitech remote
> > > controler (which has very simple fontionnality) is still not available
> > > for linux even if it was written in java to be cross-platform.
> >
> > There's nothing in the applications themselves to stop working on Linux.
> > Work user has to put comes from the fact that distributions tend to make
> > user's life more difficult by not making it trivial to have e.g. Sun's
> > JRE installed (I don't want to blame distro developers here, Sun is
> > probably the most guilty by not allowing to repackage and redistribute
> > JRE). Yet situation is IMHO similar to proprietary NVidia drivers: users
> > just have it easier thanks to the work of Livna developers (at least on
> > Fedora). And, hey!, users still manage to install proprietary nvidia
> > drivers from NVidia rather than Livna, with all the hassle it makes!
> > Users are not stupid, they are ready and able to do quite a few things
> > when they have clear instructions.
> >
> > Let's say we have "Livna JRE" to install using yum. What's missing to
> > make running Java apps trivial is making sure that there is at least a
> > simple shell script to run it from command line. Say, user opens up "Run
> > Command" dialog and types "jmeter" and it just starts. Of course the
> > script would need to line on $PATH. Other "use case" is user opens up
> > application's directory and double clicks the script. Application
> > starts. Many applications already do provide it: NetBeans, Eclipse,
> > JMeter...
> >
> > Then a step further is packaging applications for distro, like each
> > other native application.
> >
> >
> > > For a developper java is easy. As soon as you need an average end-user
> > > to make it work and are paying the support costs it suddenly is no
> > > longer anywhere near a good choice.
> >
> > Nothing to do with Java applications, it's all about packaging. If your
> > application is packaged for Linux, it will be easy to run! Vice versa it
> > can be difficult for Windows if it's not packaged for Windows. Where's
> > Java fault here?
> >
> >
> > > And I'm not even talking about the differences between jvm behaviour (if
> > > you think you can go sun-only just compare the arches sun, ibm and bea
> > > support)
> >
> > You asked about *easy* way -- the easiest, least troublesome is to use
> > Sun's JRE. You are free to try other solutions too. You have this
> > freedom. It's good. Don't want problems? Try Sun first. If you really
> > need to run on more exotic hardware, you are likely to hit other issues,
> > yet it's a particular JRE's issue. Bug IBM/Sun/BEA to fix it :-)
> >
> > Same with free stack. Everybody knows it's not quite there yet to run
> > all Java software. And yes there's a few Java apps out there using sun.*
> > packages -- not a Java issue either. Bug application developer to fix it
> > so it's ready for free stack.
> >
> > Want to avoid as much issues as you can? Get Sun's JRE and make sure
> > it's on your PATH before free stack is.
> >
> > Regards,
> > Dariusz
> >
> >
> >
> >
> > ___________________________________________________________
> > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>
> theres gcj... why would a linux user make his source dependendant on
> non free things?
>
> regards,
> rudolf  kastl
>

personally i use pygtk and python ... pretty easy to rad develop good
looking and fast (compare swing lol) gui applications. Pretty trivial
to build the gui in  glade/gazpacho and then just autoattach the
signals.  theres also the zope application server actually.

regards,
Rudolf Kastl



From jdesbonnet at gmail.com  Tue Mar 28 09:47:55 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 28 Mar 2006 10:47:55 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <200603280106.33638.lamont@gurulabs.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<4426C83F.5060300@yahoo.co.uk>
	<1143394041.2816.10.camel@rousalka.dyndns.org>
	<200603280106.33638.lamont@gurulabs.com>
Message-ID: <1cef3e950603280147u48c881ei717a930893726cc2@mail.gmail.com>

Qt is a widget library / GUI framework. In most projects I've been
involved with our preferred language and platform determined the
choice of widget library, not the other way around.

Qt would be a great option if your are committed to C++. However it
would be a mistake to be forced to use C++ just to use Qt.

BTW: from experience Java is very portable across Windows / Linux for
server side and client side applications. Of course you need to test
as you develop on both platforms -- that applies to perl, python etc
also.  Outside of Linux/Windows you do have to work a little harder to
maintain portability with Java.

Getting a bit OT and religious for fedora I think...

Joe.




On 3/28/06, Lamont R. Peterson <lamont at gurulabs.com> wrote:
> On Sunday 26 March 2006 10:27am, Nicolas Mailhot wrote:
> > Le dimanche 26 mars 2006 ? 17:58 +0100, Dariusz J. Garbowski a ?crit :
> > > On 03/26/2006 05:05 PM, Nicolas Mailhot wrote:
> > > > Le samedi 25 mars 2006 ? 12:06 +0000, Dariusz J. Garbowski a ?crit :
> > > >> .
> > > >> But I can see that in some environments Java on the desktop may be a
> > > >> support issue.
> > > >
> > > > Java is only write-once, run everywhere if you define everywhere as a
> > > > very specific static OS image :(
> > >
> > > Come to think of that... Any multi-platform, multi-os or even
> > > multi-distro (where w95/w98/w2k/wxp can be called "distro" for the
> > > purpose of this argument) will suffer from mentioned support issues
> >
> > Sure, but other software communities recognize the problem and try to
> > create tools to ease the pain. Sun java is unfortunately often in denial
> > and lala-lala land when you try to tell them there is a wide margin
> > between write once and run everywhere in the actual world
>
> I have yet to write Qt code on one platform that required any tweaking (except
> to add Windows Registry use when the "need" arose) to compile on all other
> platforms for which Qt is available and to which I have access.
>
> Qt is great write once, compile many places portability.
> --
> Lamont R. Peterson <lamont at gurulabs.com>
> Senior Instructor
> Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
> GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>



From andreas.bierfert at lowlatency.de  Tue Mar 28 09:48:18 2006
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Tue, 28 Mar 2006 11:48:18 +0200
Subject: Bootsplash?
In-Reply-To: <1143302775.2605.41.camel@dimi>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost> <1143302775.2605.41.camel@dimi>
Message-ID: <20060328114818.4024f4c6@alkaid.a.lan>

On Sat, 25 Mar 2006 11:06:15 -0500
Dimi Paun <dimi at lattica.com> wrote:

> On Fri, 2006-03-24 at 09:17 -0800, Toshio Kuratomi wrote:
> > http://splashy.alioth.debian.org/wiki/doku.php
> > 
> > Hmm..  No kernel patches and no X...  If you submit it you'll get
> > interest from me at least :-)
> 
> Same here, I'd be really interested in a packaged version.

Ok, here it goes:
http://fedora.lowlatency.de/review/splashy/

This is _known_ to have bugs like possibly not switching to X. Consider this the
first real build packages ;) I know that the spec is still ugly and not
checked for BR and such, this will be cleaned up of course but it at least gives
you an impression about splashy :) Please let me know if it works and maybe on
what hardware it does work/not work so we can add a README.Fedora later on.

I hope I can fix some of the major bugs (trying an upgrade to svn version atm
to see what is resolved an what not) 

To get it to work your framebuffer needs to be activated (vga=0x317).

Don't try to build your own package as directfb is blocking this from being
build correctly (see #186521).

- Andreas
-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/90bb57bb/attachment.sig>

From esr at thyrsus.com  Tue Mar 28 09:50:52 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 04:50:52 -0500
Subject: Fedora's way forward
Message-ID: <200603280950.k2S9oqre022074@snark.thyrsus.com>

I've had a few days now to get through the expected upgrade teething
troubles, use FC5 for my normal tasks, and watch my non-techie wife
Cathy use FC5 for *her* normal tasks.  I've been a Red Hat/Fedora user
and contributor for more than a decade now, since before 2.0 and
*well* before I became famous enough to show up in Red Hat's corporate
timeline :-).  I've taken some time to reflect on FC5 and the trends
of the last decade, and where I think Fedora and Red Hat need to go in
the future to achieve the dreams they were founded on.

Let me start with some good things.  I thought Fedora was in
desperately bad shape in the FC3/FC4 period, and as some of you know I
raised hell about it, threatening to jump very publicly to another
distribution and orphan several Fedora-related HOWTOs in the process.
I'm delighted to be able to report that much of what pushed me very
near to giving up on Fedora has been fixed.

Good thing the first: Maintainence of the core repositories is no
longer a disgraceful, poorly-documented shambles. Because of this, yum
is at last fulfilling the promise of (almost) friction-free upgrading
over the net.  Such problems as I've encountered with FC5 upgrades
have been due to upstream bugs, not egregious fuckups in the Fedora
infrastructure.  This had...ahem...not previously always been the case.

Good thing the second: this time around, I can ignore RPMForge.  While
those guys have done excellent work and performed a valuable function
by keeping Fedora on its toes, one of the things I really, *really*
wanted as a sysadmin was to be able to point my yum at official Fedora
repos plus one (1) repo for Damned Things like proprietary codecs, and
be done.  In FC5, core plus extras plus livna does as good a job as
core plus half-a-dozen RPMForge repos used to.

Good thing the third: it's clear from the devel-list traffic that the
submission pathway for new packages has got most if not all of the
process issues shaken out of it.  I had meant to get more directly
involved in that, there are four or five things I want to package and
submit myself, but higher-priority tasks ate my bandwidth.  One of my
resolutions for 2006 is to make time for those submissions.

Good thing the fourth: A combination of increased polish in various
distro components and significant upstream developments (one biggie
being OpenOffice 2.0) has, to my observation, inched FC across an
important functional threshold.  My wife can use it with as little
pain as Windows now, rather than merely tolerating the crap because
she believes in what the Linux community is trying to do.  This is
significant, because she's *not a geek*; she's a lawyer.  She is,
in fact, perfectly representative of the kind of forward-looking
professional in non-technology fields that we must have on our
side if we're to take Linux all the places we want it to go.

Take a moment to savor these good things.  Because the news is by no
means all good.  We've come a long, long way, baby -- but having got
past some of the serious blocking issues, we now get to face a new set
of them. And at least one old issue everyone has been ducking...

First, a relatively minor issue that is nevertheless quite annoying.
It's the Fedora distribution art, the images in Anaconda and the
Fedora-customized graphics in the admin tools and elsewhere.  It has
never been much better than mediocre, and in FC5 it hits a new low
with backgrounds that look like a Teletubby hocked loogies into a
dish full of soap scum.  And whose bright idea, I have to wonder, was
it to abandon the attractive and recognizable Fedora icon for
something that's...not a fedora?

Cripes.  By comparison, even the original BlueCurve was superior.  And
original BlueCurve wasn't much to cheer about compared to the
decorative art on a Windows or (especially) a Mac -- acceptable, but
not a competitive plus, not something that would actually attract
users.  The FedoraBubbles stuff is bland and tacky goo that I expect
will repel them.

Now that we've gotten past some of the key blockers on the functional
level, it's time to worry more about fit-and-finish issues like these.
Mediocre art, workmanlike images that convey information without
being ugly, is good enough for a niche product aimed at techies.  If
we want Fedora -- and for that matter Linux in general -- to break out
of that niche, we have to make it *look* like we want it to.

That means high-quality art, art that makes people actually *want* to
look at the screen because it's a significant aesthetic experience.
Which, right now, we ain't got.

But the art problem pales compared to the issue that everyone has been
ducking, which is Fedora's support for DVDs and proprietary audio and
video and web-streaming formats and Java applets. That is to say, its
crummy-to-nonexistent-to-actually-toxic support.  The tools in FC5
weren't better than they were in FC3/FC4; after installing the
critical bits from livna, they were *worse*. Totem tossed its cookies
with a cryptic pop-up error; xine white-screened under one card and
actually crashed my X under another!

It's 2006, people.  The Web is fifteen years old.  Even non-techies
have had a decade to form expectations about what constitutes a base
level of functionality.  We don't have a prayer -- not a hope, not a
snowball's chance in a supernova -- of becoming competitive for
home and business-desktop use without delivering to those
expectations.  

Those expectations include, without any doubt, multimedia playback,
web streaming, and never seeing the broken-puzzle-piece icon in
Firefox more than once per media type (if that often). When those
expectations are violated, it's not the content provider who gets
blamed for shipping a proprietary format.  The customer interprets
that kind of failure as a bug in the client, *and the customer is
right*.  All the idealism in the world about Ogg and Theora and
whatnot will not change this.

Let's start with the basics.  For a consumer OS to be unable to play
MP3s and handle podcasts is just plain not acceptable, not in the
world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
understandable if the Fraunhofer patents blocked decoders, but
Fraunhofer itself has only dunned for royalties on *encoders* -- thus
Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.  

I know at least one fairly influential kernel developer who threw out
Red Hat/Fedora in disgust over this.  When he asked me straight up how
I could defend what he bluntly called 'corporate cowardice', I didn't
feel like I had a good answer.  And I still don't.  In return for all
the free development work they get, it does seem to me that it's part
of Red Hat's job to shoulder risks like these -- and that Red Hat
hasn't held up its end.

AVI.  Quicktime.  ASF.  MPEG.  DVD playback.  Flash.  Java. These are
*not optional* in 2006, any more than the ability to read Microsoft
Word files in a word processor is optional; if we try to treat them
that way, consumers will blow Linux off.  Evangelizing for SVG and Ogg
and Theora may change this someday (I hope it will, anyway), but if
that transition were going to happen soon enough to make supporting
proprietary formats unnecessary *we'd already be past it now*.

So. For each format, we have one of three choices:

1. We can end-run the patent restrictions on the technology (say,
by developing outside the U.S. and distributing through overseas sites
that are wink-wink-nudge-nudge unconnected with Fedora/Red hat).

2. We can put real resources into developing a decoder implementation
the blocking patents don't cover, and accept the risk that the
patent-holders will launch harassment lawsuits anyway as a cost of
doing business.

3. We can buy the rights to the technologies we want as a straight
commercial transaction from the patent-holder.

The community is already pursuing (1) for some formats.  If Red Hat,
which likes to see itself as the market leader and senior commercial
distributor, isn't willing to take a swing at (2) or (3) for the
others, then I have to wonder what the hell having commercial Linux
distributors is actually good for.

If solving the multimedia problem takes having Red Hat sell a
plugins-and-drivers disk for each spin of FC, full of proprietary crap
that it negotiated rights for, that sucks -- but better that than
never getting any traction on the desktop because we got too caught up
in our own idealism to meet actual consumer needs.

And if Red Hat's answer is "we don't want the desktop", then my answer
back is "shame on you for forgetting where you came from!", and it
really would be time for those of us who care about the future of Linux to
find a commercial partner with more ambition and more guts.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"This country, with its institutions, belongs to the people who inhabit it. 
Whenever they shall grow weary of the existing government, they can exercise
their constitutional right of amending it or their revolutionary right to 
dismember it or overthrow it."	-- Abraham Lincoln, 4 April 1861



From alan at redhat.com  Tue Mar 28 10:13:31 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 05:13:31 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060328000916.GA16973@thyrsus.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
Message-ID: <20060328101331.GB12588@devserv.devel.redhat.com>

On Mon, Mar 27, 2006 at 07:09:16PM -0500, Eric S. Raymond wrote:
> That's wacky.  Doesn't happen on an X40, thank goodness.  Which is interesting,
> because several of my sources claim the T40 and X40 are electronically 
> identical, with X40 just being skrunched into a smaller form factor.

The old IDE layer does not support suspend/resume. The failure in this case
is just an example of that, in this case cause by corruption of the HPA
limits



From n0dalus+redhat at gmail.com  Tue Mar 28 10:27:28 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Tue, 28 Mar 2006 20:57:28 +1030
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <6280325c0603280227m30b41e8kdf78f3a7acf4e53b@mail.gmail.com>

On 3/28/06, Eric S. Raymond <esr at thyrsus.com> wrote:
>
> First, a relatively minor issue that is nevertheless quite annoying.
> It's the Fedora distribution art, the images in Anaconda and the
> Fedora-customized graphics in the admin tools and elsewhere.  It has
> never been much better than mediocre, and in FC5 it hits a new low
> with backgrounds that look like a Teletubby hocked loogies into a
> dish full of soap scum.  And whose bright idea, I have to wonder, was
> it to abandon the attractive and recognizable Fedora icon for
> something that's...not a fedora?

I know there are others that agree with this and while I don't mind a
new look for this release, I would like to see some more
"professional" artwork for FC6.

> But the art problem pales compared to the issue that everyone has been
> ducking, which is Fedora's support for DVDs and proprietary audio and
> video and web-streaming formats and Java applets. That is to say, its
> crummy-to-nonexistent-to-actually-toxic support.  The tools in FC5
> weren't better than they were in FC3/FC4; after installing the
> critical bits from livna, they were *worse*. Totem tossed its cookies
> with a cryptic pop-up error; xine white-screened under one card and
> actually crashed my X under another!

Most of livna's packages and packages in extras, to my knowledge, have
just been recompiled for FC5, but a lot of functionality broken in the
transition hasn't been fixed. Once the maintainers for these packages
can spend some time ironing out any new bugs, everything will run at
least as well as it did on FC4.

Maybe I'm missing the Fedora Project's goals, but I felt the goal was
to provide a system of completely free* software -- not to make an
operating system that suits everyone and makes everyone want to use
Fedora instead.

* Free in the senses of price, license, source and non-trademark-issue
redistribution rights

I personally hope that MPEG (2,3,4,etc) and other proprietary formats
will remain out of Fedora until there are no patent/IP issues with it.
I am still concerned that Fedora decided, without any justification to
the community that I've seen, to include wine and mono.

> Those expectations include, without any doubt, multimedia playback,
> web streaming, and never seeing the broken-puzzle-piece icon in
> Firefox more than once per media type (if that often). When those
> expectations are violated, it's not the content provider who gets
> blamed for shipping a proprietary format.  The customer interprets
> that kind of failure as a bug in the client, *and the customer is
> right*.  All the idealism in the world about Ogg and Theora and
> whatnot will not change this.

Fedora needs to explain to people better why they don't include these
things. When a page with an unsupported media type is loaded in
FireFox, it should say something about the goals of the Fedora project
and why we think that these things are not right ethically/morally. If
people still want these things they can get them at livna or one of
the other repositories.

> Let's start with the basics.  For a consumer OS to be unable to play
> MP3s and handle podcasts is just plain not acceptable, not in the
> world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
> understandable if the Fraunhofer patents blocked decoders, but
> Fraunhofer itself has only dunned for royalties on *encoders* -- thus
> Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.

Fedora is doing the right thing. If Red Hat wants to pay royalties in
order to include support for these things in RHEL, then they should do
that. However, currently, until these things are a legal non-issue, I
think the Fedora Foundation should be bound not to include it.

> So. For each format, we have one of three choices:
>
> 1. We can end-run the patent restrictions on the technology (say,
> by developing outside the U.S. and distributing through overseas sites
> that are wink-wink-nudge-nudge unconnected with Fedora/Red hat).

Against the goals of Fedora. If you don't like it, change distros.

> 2. We can put real resources into developing a decoder implementation
> the blocking patents don't cover, and accept the risk that the
> patent-holders will launch harassment lawsuits anyway as a cost of
> doing business.

This is really the only option, and even then is legally questionable.
However I don't personally have a problem with this approach.

> 3. We can buy the rights to the technologies we want as a straight
> commercial transaction from the patent-holder.

If you can find a patent-holder that will allow us to distribute a
freely redistributable decoder, then tell me where I can send my
money. Unfortunately, patent holders don't do this because it means
they essentially just handed over the patent.

> The community is already pursuing (1) for some formats.  If Red Hat,
> which likes to see itself as the market leader and senior commercial
> distributor, isn't willing to take a swing at (2) or (3) for the
> others, then I have to wonder what the hell having commercial Linux
> distributors is actually good for.

Red Hat sells RHEL. Fedora is controlled or will be controlled by the
Fedora Foundation which doesn't have the same commercial market leader
goal.

Some things in Fedora need to be fixed. Others are already fixed and
you are trying to break them. Keep Fedora free in all senses of the
word.

n0dalus.



From seanlkml at sympatico.ca  Tue Mar 28 10:24:59 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 05:24:59 -0500
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <BAYC1-PASMTP0748D6BF65DF57D8002D5BAED30@CEZ.ICE>

On Tue, 28 Mar 2006 04:50:52 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Let's start with the basics.  For a consumer OS to be unable to play
> MP3s and handle podcasts is just plain not acceptable, not in the
> world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
> understandable if the Fraunhofer patents blocked decoders, but
> Fraunhofer itself has only dunned for royalties on *encoders* -- thus
> Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.  

Hmmm, well that's interesting.   So it should be possible to include
an open source mp3 decoder like Underbit's MAD. [1]

> I know at least one fairly influential kernel developer who threw out
> Red Hat/Fedora in disgust over this.  When he asked me straight up how
> I could defend what he bluntly called 'corporate cowardice', I didn't
> feel like I had a good answer.  And I still don't.  In return for all
> the free development work they get, it does seem to me that it's part
> of Red Hat's job to shoulder risks like these -- and that Red Hat
> hasn't held up its end.

Well the justification is rather simple.  We're not trying to develop
a system to take over the world, we're trying to develop the best
_open-source_ system possible.   It's not a religious issue or 
idealism, it's simply the goal of the Fedora project.  Of course, 
some people don't care a whit about open source in which case, why 
the hell would they be using Fedora?

Sean

[1] http://www.underbit.com/products/mad



From paul at all-the-johnsons.co.uk  Tue Mar 28 10:34:55 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Tue, 28 Mar 2006 11:34:55 +0100
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <1143542096.23433.53.camel@mrwibble.mrwobble>

Hi,

> Let me start with some good things.  I thought Fedora was in
> desperately bad shape in the FC3/FC4 period, 

FC3 wasn't *that* bad IMHO. FC4 was a bit on the disappointing side.

> First, a relatively minor issue that is nevertheless quite annoying.
> It's the Fedora distribution art

This, and fonts, are the two areas where just about every Linux distro
falls behind Mac and Windows boxes as both companies invested a massive
amount to get professional font and graphics people to generate the
graphics for them and unfortunately, it seems eye candy is everything.

> I know at least one fairly influential kernel developer who threw out
> Red Hat/Fedora in disgust over this.  When he asked me straight up how
> I could defend what he bluntly called 'corporate cowardice', I didn't
> feel like I had a good answer.  And I still don't.  In return for all
> the free development work they get, it does seem to me that it's part
> of Red Hat's job to shoulder risks like these -- and that Red Hat
> hasn't held up its end.
> 
> AVI.  Quicktime.  ASF.  MPEG.  DVD playback.  Flash.  Java. These are
> *not optional* in 2006, any more than the ability to read Microsoft
> Word files in a word processor is optional; if we try to treat them
> that way, consumers will blow Linux off.  

Eric, I couldn't agree with you more. While I can accept the DVD
playback argument over CSS, I can't over the others especially as there
is a GNU Flash package in development, libQuicktime has been around for
yonks and from what I can see from the licence, there shouldn't be a
problem shipping a Java plugin with FC. There is even a "clean" mp3
module out there. I enjoy Linux as I don't have to play "hunt the
driver" as I do when installing a Windows box (which I have to do as
part of my job), however, it's a pain in the backside having to go to
freshrpms or livna to grab Xine/mplayer/xmms-mp3 or having to mess
around to get the Java plugin to work.

> 1. We can end-run the patent restrictions on the technology (say,
> by developing outside the U.S. and distributing through overseas sites
> that are wink-wink-nudge-nudge unconnected with Fedora/Red hat).

I think that's been suggested, I'm almost certain it was on the test
list (or on here) to have Mono included

> 3. We can buy the rights to the technologies we want as a straight
> commercial transaction from the patent-holder.

It looks like this is what happened (more or less) with Mono.

> If solving the multimedia problem takes having Red Hat sell a
> plugins-and-drivers disk for each spin of FC, full of proprietary crap
> that it negotiated rights for, that sucks -- but better that than
> never getting any traction on the desktop because we got too caught up
> in our own idealism to meet actual consumer needs.

It would be very much the same way as Linspire works.

TTFN

Paul
(who had the pleasure of sitting to a meal with Eric at the 2004 ACCU
conference with Jutta, Niko, Allan and someone else who's name escapes
me for the moment)
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From nicolas.mailhot at laposte.net  Tue Mar 28 10:35:34 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Mar 2006 12:35:34 +0200 (CEST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060328035217.19cdb86c.seanlkml@sympatico.ca>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<20060327153933.47f5dc33.seanlkml@sympatico.ca>
	<15188.192.54.193.25.1143532367.squirrel@rousalka.dyndns.org>
	<20060328035217.19cdb86c.seanlkml@sympatico.ca>
Message-ID: <62224.192.54.193.25.1143542134.squirrel@rousalka.dyndns.org>


Le Mar 28 mars 2006 10:52, sean a ?crit :

> The original post by Shane mentioned the limitations of sed when trying to
> modify config files.  My notion was of something slightly smarter than
> sed that would have no idea of valid key names or values.  Just something,
> that could parse a config file and spit out a slightly modified version.

You already have a boatload of XML tools which can do this sanely and safely.
The problem is not in the infrastructure, but people taking time to lay
out a human-friendly XML schema (as fontconfig did)

-- 
Nicolas Mailhot



From hughsient at gmail.com  Tue Mar 28 10:40:44 2006
From: hughsient at gmail.com (Richard Hughes)
Date: Tue, 28 Mar 2006 11:40:44 +0100
Subject: suspend/hibernate in the command line
In-Reply-To: <m2psk7p9lw.fsf@sl392.st-edmunds.cam.ac.uk>
References: <ur74n1min.fsf@gmail.com>
	<1143506183.5625.6.camel@daxter.boston.redhat.com>
	<m2psk7p9lw.fsf@sl392.st-edmunds.cam.ac.uk>
Message-ID: <1143542444.5280.5.camel@localhost.localdomain>

On Tue, 2006-03-28 at 03:48 +0100, Leon wrote:
> > For command line use 'pm-suspend'; it doesn't require root if (and only
> > if) you are logged in at the console.
> >
> >     David
> 
> Thanks a lot, David.

If you are in a session, and want gnome-power-manager do do fancy things
for you (like disconnect and reconnect NetworkManager, and lock the
screen, etc) you can do:

dbus-send --session \
	  --dest=org.gnome.PowerManager \
	  --type=method_call \
	  --print-reply \
	  --reply-timeout=2000 \
	  /org/gnome/PowerManager \
	  org.gnome.PowerManager.Suspend

But maybe pm-suspend will do everything you need to do.

Richard.



From paul at all-the-johnsons.co.uk  Tue Mar 28 10:41:54 2006
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Tue, 28 Mar 2006 11:41:54 +0100
Subject: Fedora's way forward
In-Reply-To: <6280325c0603280227m30b41e8kdf78f3a7acf4e53b@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<6280325c0603280227m30b41e8kdf78f3a7acf4e53b@mail.gmail.com>
Message-ID: <1143542514.23433.59.camel@mrwibble.mrwobble>

Hi,

> > Those expectations include, without any doubt, multimedia playback,
> > web streaming, and never seeing the broken-puzzle-piece icon in
> > Firefox more than once per media type (if that often). When those
> > expectations are violated, it's not the content provider who gets
> > blamed for shipping a proprietary format.  The customer interprets
> > that kind of failure as a bug in the client, *and the customer is
> > right*.  All the idealism in the world about Ogg and Theora and
> > whatnot will not change this.
> 
> Fedora needs to explain to people better why they don't include these
> things. 

But with an alternative out there which provides these "out of the box",
who is going to listen? Look, Joe Public gets a machine without anything
on it. He decides to bung in FC5, install is happy, he's pleased there
is no "hunt the driver" issue and all goes well. But then he can't play
his MP3s, the DVD isn't showing the latest movie, his massive collection
of DVs won't play as there isn't any AVI support and worse than that,
his hardware isn't supported by Macromedia flash (he's on say an x86_64)
and despite downloading it, RealPlayer 10 doesn't work (as compat-libc
++-32 isn't installed).

Sure, it looks nice, but it's not functional. What does he do? Will he
carry on with FC5 or ditch it for that dodgy copy of XP he has in his
top drawer. Answers on a postcard.

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From alan at redhat.com  Tue Mar 28 10:46:59 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 05:46:59 -0500
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <20060328104659.GI12588@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 04:50:52AM -0500, Eric S. Raymond wrote:
> ducking, which is Fedora's support for DVDs and proprietary audio and
> video and web-streaming formats and Java applets. That is to say, its
> crummy-to-nonexistent-to-actually-toxic support.  The tools in FC5
> weren't better than they were in FC3/FC4; after installing the
> critical bits from livna, they were *worse*. Totem tossed its cookies
> with a cryptic pop-up error; xine white-screened under one card and
> actually crashed my X under another!

You need to discuss that with Livna, except for the X crash which goes in
bugzilla. Red Hat is unable to assist you with Livna material or even give
the URL to livna in the USSA. 

> understandable if the Fraunhofer patents blocked decoders, but
> Fraunhofer itself has only dunned for royalties on *encoders* -- thus
> Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.  

I suggest you consult lawyers. Frauenhofer have claimed player royalties
and quite actively.

> If solving the multimedia problem takes having Red Hat sell a
> plugins-and-drivers disk for each spin of FC, full of proprietary crap
> that it negotiated rights for, that sucks -- but better that than
> never getting any traction on the desktop because we got too caught up
> in our own idealism to meet actual consumer needs.

Fedora is specifically a free software project. If you wish to create
a project based on Fedora that is full of proprietary products then
providing you follow the licenses and laws you are free to do so, thats
the beauty of free software. Hell if you want to buy a GPL license for MP3
for the community go ahead, I wish you luck.

If you'd like additional proprietary third party material such as real player 
and IBM Java nobody is stopping you.

Alan



From seanlkml at sympatico.ca  Tue Mar 28 10:45:48 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 05:45:48 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <62224.192.54.193.25.1143542134.squirrel@rousalka.dyndns.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<20060327153933.47f5dc33.seanlkml@sympatico.ca>
	<15188.192.54.193.25.1143532367.squirrel@rousalka.dyndns.org>
	<20060328035217.19cdb86c.seanlkml@sympatico.ca>
	<62224.192.54.193.25.1143542134.squirrel@rousalka.dyndns.org>
Message-ID: <BAYC1-PASMTP0245F9C3477FF661F6D666AED30@CEZ.ICE>

On Tue, 28 Mar 2006 12:35:34 +0200 (CEST)
"Nicolas Mailhot" <nicolas.mailhot at laposte.net> wrote:

> Le Mar 28 mars 2006 10:52, sean a ?crit :
> 
> > The original post by Shane mentioned the limitations of sed when trying to
> > modify config files.  My notion was of something slightly smarter than
> > sed that would have no idea of valid key names or values.  Just something,
> > that could parse a config file and spit out a slightly modified version.
> 
> You already have a boatload of XML tools which can do this sanely and safely.
> The problem is not in the infrastructure, but people taking time to lay
> out a human-friendly XML schema (as fontconfig did)
> 

That's just one implementation method of what i was talking about, there are
other ways to get the job done too.   Although i'd be surprised to learn that
XML could handle most of today's config files, given their loose format.

Sean



From andy at warmcat.com  Tue Mar 28 10:48:52 2006
From: andy at warmcat.com (Andy Green)
Date: Tue, 28 Mar 2006 11:48:52 +0100
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <44291494.2070003@warmcat.com>

Eric S. Raymond wrote:

> First, a relatively minor issue that is nevertheless quite annoying.
> It's the Fedora distribution art, the images in Anaconda and the
> Fedora-customized graphics in the admin tools and elsewhere.  It has
> never been much better than mediocre, and in FC5 it hits a new low

Quality of art is simply subjective, looks okay to me.

> But the art problem pales compared to the issue that everyone has been
> ducking, which is Fedora's support for DVDs and proprietary audio and
> video and web-streaming formats and Java applets. That is to say, its
...
> It's 2006, people.  The Web is fifteen years old.  Even non-techies
> have had a decade to form expectations about what constitutes a base

Supporting Flash seems to soak up most of the problem that can be 
solved, eg, youtube, Google Video, and if you have 32-bit firefox you 
can have it.  Seems the only answer for Quicktime and such is the 
corporate mantrap that is Mplayer, it makes no sense for Redhat to 
invite attack on their cash by playing that game.  There is no limit to 
the number of dangerous proprietary formats that one could address by 
that logic.

> Let's start with the basics.  For a consumer OS to be unable to play
> MP3s and handle podcasts is just plain not acceptable, not in the
> world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
> understandable if the Fraunhofer patents blocked decoders, but
> Fraunhofer itself has only dunned for royalties on *encoders* -- thus
> Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.  

I don't know about it, it would be lovely if Fedora had MP3 out of the 
box.  However again the caution is commendable, because having mp3 out 
of the box for a while followed by RHAT getting nuked for many millions 
of damages and unable to continue with its very widespread contributions 
to many projects would not be a good trade.

> AVI.  Quicktime.  ASF.  MPEG.  DVD playback.  Flash.  Java. These are

Well Java seems to be coming along via gcc.  Flash exists in a non-free 
form.  AVI is just a container format, the problem is more the varied 
codecs that can be used on the data inside it.  IIRC you can buy a 
licensed Linux DVD decoder app somewhere.

> *not optional* in 2006, any more than the ability to read Microsoft
> Word files in a word processor is optional; if we try to treat them
> that way, consumers will blow Linux off.  Evangelizing for SVG and Ogg

> 3. We can buy the rights to the technologies we want as a straight
> commercial transaction from the patent-holder.

Let me imagine the negative case.  RHAT and the community are drained 
and pummelled by a limitless number of patent attacks they are forced to 
defend once they get into that game of either entering the grey zone or 
getting their wallet out.  Even JPEG is a danger area.  Unless the 
strategy includes turning off the patent attack tap somehow it seems an 
unlikely "way forward".

> really would be time for those of us who care about the future of Linux to
> find a commercial partner with more ambition and more guts.

Why not do that anyway if they are so easily found.

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

From denis at poolshark.org  Tue Mar 28 10:46:57 2006
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 28 Mar 2006 02:46:57 -0800
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <44291421.8050502@poolshark.org>

Eric S. Raymond wrote:
> But the art problem pales compared to the issue that everyone has been
> ducking, which is Fedora's support for DVDs and proprietary audio and
> video and web-streaming formats and Java applets.

On the java note, I think it's worth pointing that FC5 Extras shipping
with a fully working libgcj-happy Azureus app is, i think, a remarkable
achievement.



From paul at city-fan.org  Tue Mar 28 10:51:12 2006
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 28 Mar 2006 11:51:12 +0100
Subject: Fedora's way forward
In-Reply-To: <6280325c0603280227m30b41e8kdf78f3a7acf4e53b@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<6280325c0603280227m30b41e8kdf78f3a7acf4e53b@mail.gmail.com>
Message-ID: <44291520.7070303@city-fan.org>

n0dalus wrote:
> I personally hope that MPEG (2,3,4,etc) and other proprietary formats
> will remain out of Fedora until there are no patent/IP issues with it.
> I am still concerned that Fedora decided, without any justification to
> the community that I've seen, to include wine and mono.

More on Mono:
http://gregdek.livejournal.com/4008.html

Paul.



From camilo at mesias.co.uk  Tue Mar 28 11:30:12 2006
From: camilo at mesias.co.uk (Cam)
Date: Tue, 28 Mar 2006 12:30:12 +0100
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <44291E44.3080000@mesias.co.uk>

Eric

If art is all you have to complain about then that shows just how far we 
have come. I'd rather see art relegated to the sidelines so people can 
choose a distro on real tangible features. Or would you rather people 
chose Ubuntu for it's brownness, Fedora for it's blueness or Suse/Novell 
for it's greenness?

The point about handling modern media is more interesting for me. As a 
geek user I'm *this* close to re-ripping my entire collection as ogg. 
The main motivator is because it's more open than mp3. Fedora has been a 
strong influence in this. At work I can imagine Fedora being used on the 
desktop and the lack of multimedia support would not be a big issue.

I think it's clear that there are distros with more seamless support for 
media out there, and it's never been that much of an impediment for 
Fedora. Notwithstanding that, a separate commercial addons disk might 
help bring more users to Fedora. I don't think anyone would stand in the 
way of a third party doing this - so if you really believe it, put your 
money where your mouth is... I can't speak for RH but I imagine they are 
more focused on keeping the developers happy than users, and developers 
get by with livna et al.

-Cam

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



From benjy.grogan at gmail.com  Tue Mar 28 11:39:03 2006
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Tue, 28 Mar 2006 06:39:03 -0500
Subject: Fedora's way forward
In-Reply-To: <44291520.7070303@city-fan.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<6280325c0603280227m30b41e8kdf78f3a7acf4e53b@mail.gmail.com>
	<44291520.7070303@city-fan.org>
Message-ID: <d82d6db50603280339o1d054251l529f433452861365@mail.gmail.com>

On 3/28/06, Paul Howarth <paul at city-fan.org> wrote:
> n0dalus wrote:
> > I personally hope that MPEG (2,3,4,etc) and other proprietary formats
> > will remain out of Fedora until there are no patent/IP issues with it.
> > I am still concerned that Fedora decided, without any justification to
> > the community that I've seen, to include wine and mono.
>
> More on Mono:
> http://gregdek.livejournal.com/4008.html

Awesome.  OIN is a step in the right direction.

I think the lawyers at Red Hat have to come up with a solution for
those who want to use Fedora as their OS, and pay a small price if
that must be to have all the necessary codecs on their system.

It seems like the war is being won by the software developers but it's
the lawyers who are failing.  Linux needs better lawyers.

Benji



From fedora at camperquake.de  Tue Mar 28 11:40:53 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 28 Mar 2006 13:40:53 +0200
Subject: Fedora's way forward
In-Reply-To: <1143542096.23433.53.camel@mrwibble.mrwobble>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143542096.23433.53.camel@mrwibble.mrwobble>
Message-ID: <20060328134053.37c0e28e@soran.addix.net>

Moin.

On Tue, 28 Mar 2006 11:34:55 +0100, Paul F. Johnson wrote:

> there is a GNU Flash package in development, libQuicktime has been
> around for yonks

Quicktime is just a container format, as is avi. Being able to demux
.mov does not buy you anything.



From camilo at mesias.co.uk  Tue Mar 28 11:45:28 2006
From: camilo at mesias.co.uk (Cam)
Date: Tue, 28 Mar 2006 12:45:28 +0100
Subject: Assignment of internet keys / media buttons
In-Reply-To: <1143463458.2869.21.camel@pensja.lam.pl>
References: <4427C9DC.5020708@mesias.co.uk>
	<1143463458.2869.21.camel@pensja.lam.pl>
Message-ID: <442921D8.2060504@mesias.co.uk>

Leszek

>> The first problem is that the keys are initially unmapped; a secondary 
>> problem is that some controls (eg. volume popup) don't respond to the 
>> volume keys when they probably should.
> 1. Write your modmaps to /etc/X11/Xmodmap. I use

Thanks for the reply - yes I can write to xmodmap but should every user 
do this?

Couldn't I add a new keyboard type to the system which already includes 
the mappings, maybe even have anaconda detect the keyboard?

-Cam

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



From che666 at gmail.com  Tue Mar 28 11:46:08 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 28 Mar 2006 13:46:08 +0200
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <44291494.2070003@warmcat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
Message-ID: <e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>

2006/3/28, Andy Green <andy at warmcat.com>:
> Eric S. Raymond wrote:
>
> > First, a relatively minor issue that is nevertheless quite annoying.
> > It's the Fedora distribution art, the images in Anaconda and the
> > Fedora-customized graphics in the admin tools and elsewhere.  It has
> > never been much better than mediocre, and in FC5 it hits a new low
>
> Quality of art is simply subjective, looks okay to me.
>
> > But the art problem pales compared to the issue that everyone has been
> > ducking, which is Fedora's support for DVDs and proprietary audio and
> > video and web-streaming formats and Java applets. That is to say, its
> ...
> > It's 2006, people.  The Web is fifteen years old.  Even non-techies
> > have had a decade to form expectations about what constitutes a base
>
> Supporting Flash seems to soak up most of the problem that can be
> solved, eg, youtube, Google Video, and if you have 32-bit firefox you
> can have it.  Seems the only answer for Quicktime and such is the
> corporate mantrap that is Mplayer, it makes no sense for Redhat to
> invite attack on their cash by playing that game.  There is no limit to
> the number of dangerous proprietary formats that one could address by
> that logic.

flash isnt a standard... how about creating a new better technology
and obsolete it? flash requires mp3 for sound playback... so even if a
gpl implementation exists it wont be going into extras... id just
forget about flash and look "forward". personally i wont run a 32 bit
browser on my 64 bit system just to get the closed source garbage
working. only real use case for flash would be watching some funny
movies... as far as regular webpages go... i am not a flash fan at
all, but thats just me...


>
> > Let's start with the basics.  For a consumer OS to be unable to play
> > MP3s and handle podcasts is just plain not acceptable, not in the
> > world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
> > understandable if the Fraunhofer patents blocked decoders, but
> > Fraunhofer itself has only dunned for royalties on *encoders* -- thus
> > Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.
>
> I don't know about it, it would be lovely if Fedora had MP3 out of the
> box.  However again the caution is commendable, because having mp3 out
> of the box for a while followed by RHAT getting nuked for many millions
> of damages and unable to continue with its very widespread contributions
> to many projects would not be a good trade.
>
> > AVI.  Quicktime.  ASF.  MPEG.  DVD playback.  Flash.  Java. These are
>
> Well Java seems to be coming along via gcc.  Flash exists in a non-free
> form.  AVI is just a container format, the problem is more the varied
> codecs that can be used on the data inside it.  IIRC you can buy a
> licensed Linux DVD decoder app somewhere.

theres the webgcjplugin for browsers aswell... someone fix the
security stuff up and we got a solution.

>
> > *not optional* in 2006, any more than the ability to read Microsoft
> > Word files in a word processor is optional; if we try to treat them
> > that way, consumers will blow Linux off.  Evangelizing for SVG and O
gg


Consumers mostly just dont know that they are using worse legacy
formats like mp3 when they have superior formats such as ogg
available... i think thats a plain educational problem.

>
> > 3. We can buy the rights to the technologies we want as a straight
> > commercial transaction from the patent-holder.

you wanna feed the patent dinosaurs? sure... we pay for patents...
companys are then with the money getting more patents.... we pay for
more patents... -> not a solution especially not in my eyes when its
about legacy formats.

>
> Let me imagine the negative case.  RHAT and the community are drained
> and pummelled by a limitless number of patent attacks they are forced to
> defend once they get into that game of either entering the grey zone or
> getting their wallet out.  Even JPEG is a danger area.  Unless the
> strategy includes turning off the patent attack tap somehow it seems an
> unlikely "way forward".
>
> > really would be time for those of us who care about the future of Linux to
> > find a commercial partner with more ambition and more guts.

I am rather hoping that more education will make the "problems" vanish.

>
> Why not do that anyway if they are so easily found.
>
> -Andy
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>



From alan at redhat.com  Tue Mar 28 11:49:48 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 06:49:48 -0500
Subject: Fedora's way forward
In-Reply-To: <d82d6db50603280339o1d054251l529f433452861365@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<6280325c0603280227m30b41e8kdf78f3a7acf4e53b@mail.gmail.com>
	<44291520.7070303@city-fan.org>
	<d82d6db50603280339o1d054251l529f433452861365@mail.gmail.com>
Message-ID: <20060328114948.GB944@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 06:39:03AM -0500, Benjy Grogan wrote:
> I think the lawyers at Red Hat have to come up with a solution for
> those who want to use Fedora as their OS, and pay a small price if
> that must be to have all the necessary codecs on their system.

Fedora does have such a system. Its very simple. You can go buy
any software you want to run on your system just like with any
other OS. We do free software, we don't do proprietary software.

You can get a whole collection of things at differing rates from
various vendors.

Alan



From bojan at rexursive.com  Tue Mar 28 11:51:30 2006
From: bojan at rexursive.com (Bojan Smojver)
Date: Tue, 28 Mar 2006 22:51:30 +1100
Subject: Fedora's way forward
Message-ID: <1143546690.1978.31.camel@coyote.rexursive.com>

First off, thanks to Fedora and upstream developers for delivering the
best Fedora so far: FC5!

Please stay the course and keep Fedora free (in all senses of the word)
and fast paced. At least I like having an up to date and complete (or as
complete as possible) OS that doesn't depend on a whim of proprietary
software makers of the day, be that Adobe, NVidia, ATi, Sun, Citrix,
VMware, Cisco or someone else. Once we venture down that road, we'll
just get ourselves in trouble, IMHO. Third party proprietary software
that works with Fedora should be a temporary bonus (until the next
kernel/X/<insert you component> here source breakage in the upstream
release), not a given.

People that want operating systems that include/fully support
proprietary stuff should not run Fedora - they should run Red Hat
Enterprise Linux or something similar.

PS. Personally, I like the new Fedora logo and theme.

-- 
Bojan



From P at draigBrady.com  Tue Mar 28 11:52:47 2006
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Tue, 28 Mar 2006 12:52:47 +0100
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <4429238F.4050200@draigBrady.com>

Eric S. Raymond wrote:
> [It's getting better]
> [I don't like the art work]
> [We really need it to work in the real world]

Everyone I know that uses fedora for work applies:
http://home.gagme.com/greg/linux/fc5-tips.php

So from my point of view, fedora is unusable out of the box,
but I think they've made the right decisions in what to include.
It's quite easy to apply the "fixups" documented above,
and it's a small price to pay for a completely opensource
and patent unencumbered distro.

P?draig.



From rkwasny at aurox.org  Tue Mar 28 11:56:17 2006
From: rkwasny at aurox.org (=?iso-8859-2?q?Rafa=B3_Kwa=B6ny?=)
Date: Tue, 28 Mar 2006 12:56:17 +0100
Subject: Package names in FC5
Message-ID: <200603281356.17155.rkwasny@aurox.org>

Hi,
I wonder why some packages are named like:

cman-1.0.5-0.FC5.1.i386.rpm
(with capital FC5)

some are named like:
compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm

but most of them don't have any fc5 tag
Is there any pattern in this?

-- 
Rafal Kwasny
rkwasny at aurox.org



From jos at xos.nl  Tue Mar 28 12:07:27 2006
From: jos at xos.nl (Jos Vos)
Date: Tue, 28 Mar 2006 14:07:27 +0200
Subject: Package names in FC5
In-Reply-To: <200603281356.17155.rkwasny@aurox.org>;
	from rkwasny@aurox.org on Tue, Mar 28, 2006 at 12:56:17PM +0100
References: <200603281356.17155.rkwasny@aurox.org>
Message-ID: <20060328140727.B29121@xos037.xos.nl>

On Tue, Mar 28, 2006 at 12:56:17PM +0100, Rafa? Kwa?ny wrote:

> I wonder why some packages are named like:
> 
> cman-1.0.5-0.FC5.1.i386.rpm
> (with capital FC5)
> 
> some are named like:
> compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm
> 
> but most of them don't have any fc5 tag
> Is there any pattern in this?

Note that you're not asking about package names, but about the
release numbering scheme.

Good question, anyway, as this looks pretty *packager*-dependent,
which it should not be, IMHO.

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



From sundaram at fedoraproject.org  Tue Mar 28 12:18:23 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 28 Mar 2006 17:48:23 +0530
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060327202457.GA15056@thyrsus.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
Message-ID: <1143548303.3802.474.camel@sundaram.pnq.redhat.com>

On Mon, 2006-03-27 at 15:24 -0500, Eric S. Raymond wrote:
> Joe Desbonnet <jdesbonnet at gmail.com>:
> > The Thinkpad seems to be cropping up alot in bug reports...
> 
> No surprise there.  It's the elite laptop, and has been since it
> displaced the Sony VAIOs some time back.  I don't think I've met a
> Linux hacker in the last five years who carried anything else for
> reasons other than costs-too-much.
> 
> >                                                     after a
> > lot of sweat and tears I have regained most of my Thinkpad's
> > functionality since the upgrade (actually a fresh install repeated
> > several times).
> 
> Have you managed to get suspend/resume to work reliably?  On my X40
> the situation is bad...
> 
> > Another solution which will probably take too much work: make some
> > sort of LiveCD with sufficient functionality to test all the hardware
> > compatibility.
> 
> If anyone out there does this, I'm willing to test it and send in prompt
> and detailed bug reports.
> -- 

We have a live CD creation tool called Kadischi and some live CD's
floating around in fedora-livecd list. Details at
http://fedoraproject.org/wiki/Kadischi/.

We also have a project http://pootypedia.sourceforge.net/ which got
sponsored by Fedora as part of Google's SOC. Unfortunately pootypedia is
based on Kudzu while we are moving to HAL instead. Someone needs to
combine these efforts and we need more developers to take this forward.


Rahul



From mattdm at mattdm.org  Tue Mar 28 12:23:03 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 28 Mar 2006 07:23:03 -0500
Subject: [ANN] Release Notes Errata - Wiki Freeze
In-Reply-To: <1143516515.3140.1.camel@aglarond.local>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
Message-ID: <20060328122303.GA19783@jadzia.bu.edu>

On Mon, Mar 27, 2006 at 10:28:35PM -0500, Jeremy Katz wrote:
> > One question I have for Development is can we then roll these new
> > updated release notes and translations in to a package update for our
> > users?
> Traditionally, we haven't done updates to the fedora-release package to
> avoid some potential confusion/snafus.  It's something we could consider
> doing I guess.

Maybe a good idea to break the release notes out of the fedora-release
package?

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



From richard at rsk.demon.co.uk  Tue Mar 28 12:34:12 2006
From: richard at rsk.demon.co.uk (Richard Kennedy)
Date: Tue, 28 Mar 2006 13:34:12 +0100
Subject: prism2_usb wlan does not get initialised in FC5
Message-ID: <1143549253.2616.13.camel@castor.rsk.org>

Hi,

I use the out of kernel driver for the prism2 usb wlan card --
http://www.linux-wlan.com/linux-wlan/ built from source. 

It works correctly on FC4 but since upgrading to FC5 it no longer gets
initialised. The driver uses custom hotplug events to run userspace apps
that load the card firmware and configuration, start a scan etc.

But since /sbin/hotplug no longer exists, the card won't start up.
Can anyone suggest the best way to get this card to work with
udev?

Can I get a udev rule to run after the card is completely loaded and the
device node exists, and then start the firmware download?

I've tried a simple udev rule, but the device doesn't seem to be created
so the user space app that downloads the firmware can't find /dev/wlan0
so doesn't work.

rule: ACTION=="add", BUS=="usb", DRIVER="prism2_usb", RUN
+="/etc/wlan/wlan-udev.sh %k"

Can any suggest how to get this to work or what I might need to change
in the driver to work with udev? 

Or is there a way to send custom actions from the driver to udev to
replace the hotplug ones?

Any ideas or suggestions?


TIA

cheers
Richard



From billcrawford1970 at gmail.com  Tue Mar 28 12:37:21 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Tue, 28 Mar 2006 12:37:21 +0000
Subject: selinux-policy-targeted-2.2.26-1 update failed
In-Reply-To: <44280CE5.8010802@redhat.com>
References: <1143316951.4425a1d750bff@www.jouy.inra.fr>
	<1143321367.14370.3.camel@localhost.localdomain>
	<44280CE5.8010802@redhat.com>
Message-ID: <200603281337.22271.billcrawford1970@googlemail.com>

On Monday 27 March 2006 17:03, Daniel J Walsh wrote:

> > Yep, something about todays SELinux update seems to have made
> > Development live up to it's baby eating reputation.
> >
> > - David
>
> YES todays Rawhide is very broken.  We are investigating the problem.  I
> would avoid updating to rawhide, if you have not yet.

 Time for that coloured "Rawhide Air Quality" alert page somewhere? Perhaps an 
applet that checks status and changes colour, and allows automatic reporting 
of crashes?

-- 
Bill"dreaming of a white Christmas"Crawford



From Lam at Lam.pl  Tue Mar 28 12:41:45 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Tue, 28 Mar 2006 14:41:45 +0200
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
Message-ID: <1143549705.4097.30.camel@pensja.lam.pl>

Dnia 28-03-2006, wto o godzinie 13:46 +0200, Rudolf Kastl napisa?(a):
> Consumers mostly just dont know that they are using worse legacy
> formats like mp3 when they have superior formats such as ogg
> available... i think thats a plain educational problem.
Oh yes they know. It's not a matter of education, but marketing. I'll
give you an example: I would convert my father to Ogg Vorbis if only his
brand new DVD player could play it, but it can't. So instead he's now
switching from MP3 to the "overly superior" WMA format which he can play
everywhere he wants (really). Why oh why doesn't a simple player go with
oggs? Maybe because there are people paying to tide customers to the new
proprietary format without giving them an option?

Think about it once again - I can't make my DVD player, nor my portable
MP3 player, nor my car MP3 player (and so on...) to play Ogg Vorbis. In
the same time I CAN make my Fedora to play and even encode MP3, WMA and
other formats. I even HAVE TO use my computer to rip my new CD and
encode to MP3 in order to load it to my MP3 player. That's one of the
tasks people use any OS for nowadays. (I don't possess any MP3 player in
reality, but know many people who do)

Besides, I may be totally wrong, so please don't yell at me, but one of
the reasons there are so many multimedia players lacking support for
open formats may be the GPL licensing of decoders.

So even if there are good free (speech+beer) formats, encoders and
decoders, even if I do use Ogg Vorbis and Musepack (I've heard it's free
now) on my computer, other people simply can't unless other multimedia
hardware adopts the free formats. Until then many people have no real
option. You may be lucky, I may be lucky, but others are less lucky and
there's not much words can do ("education").

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/f5bb4eaa/attachment.sig>

From fedora at wir-sind-cool.org  Tue Mar 28 12:42:18 2006
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Tue, 28 Mar 2006 14:42:18 +0200
Subject: Package names in FC5
In-Reply-To: <200603281356.17155.rkwasny@aurox.org>
References: <200603281356.17155.rkwasny@aurox.org>
Message-ID: <20060328144218.92792ab4.fedora@wir-sind-cool.org>

On Tue, 28 Mar 2006 12:56:17 +0100, Rafa? Kwa?ny wrote:

> Hi,
> I wonder why some packages are named like:
> 
> cman-1.0.5-0.FC5.1.i386.rpm
> (with capital FC5)
> 
> some are named like:
> compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm
> 
> but most of them don't have any fc5 tag
> Is there any pattern in this?

No pattern. Core package developers can do what they want, and some of
them still don't seem to care that .fc3 is "newer than" .FC5 in RPM
version comparison.

In Fedora Extras, the distribution tag in the "Release" version number is
optional. But when used (through a macro in the package spec file), it is
inserted as lower-case .fc5 by the build-system.



From gemi at bluewin.ch  Tue Mar 28 12:44:27 2006
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Tue, 28 Mar 2006 14:44:27 +0200
Subject: Fedora's way forward
In-Reply-To: <4429238F.4050200@draigBrady.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<4429238F.4050200@draigBrady.com>
Message-ID: <1143549867.8791.2.camel@scriabin.tannenrauch.ch>

On Tue, 2006-03-28 at 12:52 +0100, P?draig Brady wrote:
> Eric S. Raymond wrote:
> > [It's getting better]
> > [I don't like the art work]
> > [We really need it to work in the real world]
> 
> Everyone I know that uses fedora for work applies:
> http://home.gagme.com/greg/linux/fc5-tips.php
I think, that people that emphasize "the ANNOYING
behavior of spatial nautilus" ANNOYING.
(from the linked to text)
-- 
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich



From benjy.grogan at gmail.com  Tue Mar 28 12:49:18 2006
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Tue, 28 Mar 2006 07:49:18 -0500
Subject: Fedora's way forward
In-Reply-To: <1143549867.8791.2.camel@scriabin.tannenrauch.ch>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<4429238F.4050200@draigBrady.com>
	<1143549867.8791.2.camel@scriabin.tannenrauch.ch>
Message-ID: <d82d6db50603280449k37ba70d3ndb028da8369ad2a7@mail.gmail.com>

On 3/28/06, G?rard Milmeister <gemi at bluewin.ch> wrote:
> On Tue, 2006-03-28 at 12:52 +0100, P?draig Brady wrote:
> > Eric S. Raymond wrote:
> > > [It's getting better]
> > > [I don't like the art work]
> > > [We really need it to work in the real world]
> >
> > Everyone I know that uses fedora for work applies:
> > http://home.gagme.com/greg/linux/fc5-tips.php
> I think, that people that emphasize "the ANNOYING
> behavior of spatial nautilus" ANNOYING.
> (from the linked to text)

Exactly.  I like containers and find all that unnecessary baggage that
comes with the  browser window annoying.

Benjy



From fedora at adslpipe.co.uk  Tue Mar 28 12:57:31 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Tue, 28 Mar 2006 13:57:31 +0100
Subject: Fedora's way forward
In-Reply-To: <20060328104659.GI12588@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
Message-ID: <442932BB.7060108@adslpipe.co.uk>

Alan Cox wrote:

> You need to discuss that with Livna, except for the X crash which goes in
> bugzilla. 

xine occasionally kills my Xorg too, I've already logged a bug, if 
Eric's crash seems similar ...

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




From casimiro.barreto at gmail.com  Tue Mar 28 12:56:26 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 28 Mar 2006 09:56:26 -0300
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <44291494.2070003@warmcat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
Message-ID: <4429327A.2060401@gmail.com>

Andy Green escreveu:
> Eric S. Raymond wrote:
>
> (...)
>> But the art problem pales compared to the issue that everyone has been
>> ducking, which is Fedora's support for DVDs and proprietary audio and
>> video and web-streaming formats and Java applets. That is to say, its
> ...
>> It's 2006, people.  The Web is fifteen years old.  Even non-techies
>> have had a decade to form expectations about what constitutes a base
>
> Supporting Flash seems to soak up most of the problem that can be 
> solved, eg, youtube, Google Video, and if you have 32-bit firefox you 
> can have it.  Seems the only answer for Quicktime and such is the 
> corporate mantrap that is Mplayer, it makes no sense for Redhat to 
> invite attack on their cash by playing that game.  There is no limit 
> to the number of dangerous proprietary formats that one could address 
> by that logic.
>
This kind of argument only shows 2 things:

   1. RedHat/Fedora people are absolutelly unable to deal with major
      manufacturers (Adobe for Instance) and have good versions of
      Flash/Shockwave and (Apple) Quicktime. Curious thing is that  my
      Apple Mini (a real wonder) runs OS X Tiger (that is a *NIX system)
      and has no problems with flash, shockwave or PDF files... as well
      as don't have problems with device drivers.
   2. RedHat wants, in the mid-range/long term to have a "commercial
      product" where those "facilities" and other "utilities" are sold
      at a price...

>> Let's start with the basics.  For a consumer OS to be unable to play
>> MP3s and handle podcasts is just plain not acceptable, not in the
>> world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
>> understandable if the Fraunhofer patents blocked decoders, but
>> Fraunhofer itself has only dunned for royalties on *encoders* -- thus
>> Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.  
>
> I don't know about it, it would be lovely if Fedora had MP3 out of the 
> box.  However again the caution is commendable, because having mp3 out 
> of the box for a while followed by RHAT getting nuked for many 
> millions of damages and unable to continue with its very widespread 
> contributions to many projects would not be a good trade.

Well, you Fedora/RHAT people can make the World believe that OGG/THEORA 
is the word... just like IBM tried to convince that OS2 was the word... 
but then you had to purchase a set of compilers at US$800,00... or face 
the hell trying to run gcc... Consequence: a 10000 feet pit-fall... Who 
dares with OS2 nowadays?
>
>> AVI.  Quicktime.  ASF.  MPEG.  DVD playback.  Flash.  Java. These are
>
> Well Java seems to be coming along via gcc.  Flash exists in a 
> non-free form.  AVI is just a container format, the problem is more 
> the varied codecs that can be used on the data inside it.  IIRC you 
> can buy a licensed Linux DVD decoder app somewhere.

The java that comes along with GCC runs only about 10-20% of Java 
Applications in market. Want examples: try to access any Brazilian bank 
using "Fedora standard Java". You'll get stuck... But why would people 
try to access his bank acount from his own computer? A little walk is 
healthy... So each loving soul under the Sun have to download Sun JRE 
(at least) or the complete JDK. Flash for Linux literally sucks... it is 
slow, and again there is no support for shockwave. People says that's 
due to the needs of using ActiveX for ShockWave run... I'd say that the 
status of Java within GCC is the same status of wine... an unfullfilled 
promise.
>
>
>> *not optional* in 2006, any more than the ability to read Microsoft
>> Word files in a word processor is optional; if we try to treat them
>> that way, consumers will blow Linux off.  Evangelizing for SVG and Ogg
>
>> 3. We can buy the rights to the technologies we want as a straight
>> commercial transaction from the patent-holder.
>
> Let me imagine the negative case.  RHAT and the community are drained 
> and pummelled by a limitless number of patent attacks they are forced 
> to defend once they get into that game of either entering the grey 
> zone or getting their wallet out.  Even JPEG is a danger area.  Unless 
> the strategy includes turning off the patent attack tap somehow it 
> seems an unlikely "way forward".
>
Even being alive is in a danger area: you can die at any moment. Recent 
events show that you even can die because a B-737 piloted by an insane 
freako crashes against your building... So law issues are a joke. Want 
to get rid of them... simply open a subsidiary in a country that does 
not sign international patents laws and release the job from there... 
But if dangers are to be listed, Fedora should be stripped from 
X-Windows (issued by Xerox and disputed by HP), and most other things... 
like disk access drivers (patents by IBM), tape access drives (some 
patents from IBM and others from several companies), video-device access 
methods (NVIDIA and others), diskette support (IBM), ISA/EISA support 
(IBM), etc... etc... etc...

In software market everything is gray zone. You issue MySql and AFAIK it 
is not really "open source", but them you stripe it (so RHEL can have 
the full flavour and the others don't). And you take care of compiling 
everything in non standard directories, so if you want to download the 
"real thing" from MySQL you have to completelly uninstall what comes 
along with Fedora distribution and take care of all dependencies. And 
NEVER EVER use yum again... under the risk of uploading a module that 
will screw everything.

You may not know, but what was done to PHP in FC-5 is a shame. There is 
no f_ck_g way to make international encoding to work well. 
setlocale(LCC_ALL,'pt_BR') stopped working as well as any other 
setlocale. Modules previously present in RC4 "disapeared" just with a 
simple yum update. They were removed from system without any question of 
the kind: "The f_ck_g module will be removed, you agree? <yes> <no> 
<info>". Result: I upgraded a server in 20 minutes and everything stoped 
to work... that meant 20+ hours of straight work of coding and recoding 
(man, I had to code calendar months and other stupid things) to have the 
basics running back. By the way, I got sick cause of that, so I am able 
to issue RedHat (rs rs rs). Traditional programs as phpBB and phpCA just 
don't show Portuguese characters if I define encoding as iso-8859-1 in 
/etc/php.ini but if I define it as utf8 some other things wont work 
either... They say that's a bad combination between PHP and MySQL 
(typical), but code WAS working earlier. That's a hell of life... Not to 
mention /var/log/messages /var/log/httpd/errror_log getting bigger and 
bigger with standard programs... with things like... php: $_SERVER[...] 
not defined... 'HTTP_ALL' for instance...

Other anoyance is that, after upgraded to FC5 some problem with sensors 
code started a stupid window saying that my processor was overheating 
and frequency was being downed. Not once... but a message per second 
until server stops... Obviously I don't work in a morgue, but 
temperature is controlled around 20C... and besides that hardware checks 
showed no problem with the box ... Solution: get the kernel source, 
recompile it, reinstall it and start everything back. "Just a little 
work", but if you're not a systems analist or programer or anything like 
that (I mean, if you just receive a box to do a specific work) you will 
have bad times...

USB behaviour is poor. I have an OV511 device that sometimes is 
initialized and sometimes not. At this exact moment, the system is not 
identifying my camera... but if I do something like: modprobe OV511 I 
get a turrent of videodev errors... Standard procedure: use M$ method: 
shut down, power off, power on... Oh... why in the hell I didn't fill a 
bugzilla??? (rs rs rs). The same happens with flash memories (pen 
drives) and even a f_ck_g printer (EPSON STYLUS CX3500). In this case we 
don't even have the correct drivers in the system. We have to make the 
box "imagine" that it is working with a CX3200. Don't have cartridge 
monitoring and anything like that... And system zeroes cartridge 
counters as fast as I type this e-mail... and that sucks to disconect 
the printer, connect to a M$ box, run SSCSERVER (yeah, russians really 
do great jobs), zero the cartridges and bring the printer back...

Other anoyance is that every time you issue a complaint, you people 
treat us as assholes... just like if we don't know anything of what we 
are complaining about. The case for RAID1 is typical... Now it seems 
more people are complaining about and it is impossible to say that 
thousands of flies are wrong... We send all the reports the system gives 
us and most of time the answer is that there is just not enought 
information to do anything... Seems that you've learned with M$ what a 
customer support is... By the way, with RAID1 and LINEAR, the system 
dies without registering a single line anywere... just get stuck. 
Obviously I can instrument the drivers to see what is going on... but I 
do much doubt that any correction will be included in main-stream code, 
just cause I'm not "Fedora partner", the "code is not tested" or "is 
uncomplaint with other things" or... because in the future you can be 
issued by using my GPL code...


>> really would be time for those of us who care about the future of 
>> Linux to
>> find a commercial partner with more ambition and more guts.
>
> Why not do that anyway if they are so easily found.
>
> -Andy
Casimiro
Really pissed off...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/ce88a7f5/attachment.htm>

From seanlkml at sympatico.ca  Tue Mar 28 12:56:46 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 07:56:46 -0500
Subject: Assignment of internet keys / media buttons
In-Reply-To: <442921D8.2060504@mesias.co.uk>
References: <4427C9DC.5020708@mesias.co.uk>
	<1143463458.2869.21.camel@pensja.lam.pl>
	<442921D8.2060504@mesias.co.uk>
Message-ID: <BAYC1-PASMTP036AC254DD0F80BC16BB37AED30@CEZ.ICE>

On Tue, 28 Mar 2006 12:45:28 +0100
Cam <camilo at mesias.co.uk> wrote:


> >> The first problem is that the keys are initially unmapped; a secondary 
> >> problem is that some controls (eg. volume popup) don't respond to the 
> >> volume keys when they probably should.
> > 1. Write your modmaps to /etc/X11/Xmodmap. I use
> 
> Thanks for the reply - yes I can write to xmodmap but should every user 
> do this?
> 
> Couldn't I add a new keyboard type to the system which already includes 
> the mappings, maybe even have anaconda detect the keyboard?
> 

Don't know if this has been mentioned before in the conversation but many
keyboards already have full mappings provided which the user can
select by running gnome-keyboard-properties.   Adding additional types
for selection would be helpful.

Sean



From casimiro.barreto at gmail.com  Tue Mar 28 13:06:00 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 28 Mar 2006 10:06:00 -0300
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
Message-ID: <442934B8.6080703@gmail.com>

Rudolf Kastl escreveu:
> (...)
>> Supporting Flash seems to soak up most of the problem that can be
>> solved, eg, youtube, Google Video, and if you have 32-bit firefox you
>> can have it.  Seems the only answer for Quicktime and such is the
>> corporate mantrap that is Mplayer, it makes no sense for Redhat to
>> invite attack on their cash by playing that game.  There is no limit to
>> the number of dangerous proprietary formats that one could address by
>> that logic.
>>     
>
> flash isnt a standard... how about creating a new better technology
> and obsolete it? flash requires mp3 for sound playback... so even if a
> gpl implementation exists it wont be going into extras... id just
> forget about flash and look "forward". personally i wont run a 32 bit
> browser on my 64 bit system just to get the closed source garbage
> working. only real use case for flash would be watching some funny
> movies... as far as regular webpages go... i am not a flash fan at
> all, but thats just me...
>
>
>   
Yeah... but the thousand flies that like SoundClick, PureVolume, 
15megsoffame, etc... etc... etc... not to mention the Internet radios 
and other multimedia sites fell like compelled to use M$ or Apple OS X ???

>
>   
>>> *not optional* in 2006, any more than the ability to read Microsoft
>>> Word files in a word processor is optional; if we try to treat them
>>> that way, consumers will blow Linux off.  Evangelizing for SVG and O
>>>       
> gg
>
>
> Consumers mostly just dont know that they are using worse legacy
> formats like mp3 when they have superior formats such as ogg
> available... i think thats a plain educational problem.
>   
Just as OS2 was superior of NT4.0... Hey... that's nonsense... most 
portable players just play MP3, WMA, WMV, MPG and AVI. The others are 
rare, expensive and have exotic interfaces... Not to talk about the 
digital sound systems that we have at home, at our cars, etc... Try to 
play OGG/Theora in your DVD player at home... Try to play OGG/Theora on 
your PS2... That's not educational problem that's practical problem...
>   

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

From che666 at gmail.com  Tue Mar 28 13:02:58 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 28 Mar 2006 15:02:58 +0200
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143549705.4097.30.camel@pensja.lam.pl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<1143549705.4097.30.camel@pensja.lam.pl>
Message-ID: <e99d27470603280502vd655b77ve9c3cb981f52d7c1@mail.gmail.com>

2006/3/28, Leszek Matok <Lam at lam.pl>:
> Dnia 28-03-2006, wto o godzinie 13:46 +0200, Rudolf Kastl napisa?(a):
> > Consumers mostly just dont know that they are using worse legacy
> > formats like mp3 when they have superior formats such as ogg
> > available... i think thats a plain educational problem.
> Oh yes they know. It's not a matter of education, but marketing. I'll
> give you an example: I would convert my father to Ogg Vorbis if only his
> brand new DVD player could play it, but it can't.

Well if the consumer would be properly educated hed been looking for a
ogg/flac/theora supporting device and demand from the industry to
provide such means... do you eat everything that goes on the table?
:=) i dont.

 So instead he's now
> switching from MP3 to the "overly superior" WMA format which he can play
> everywhere he wants (really). Why oh why doesn't a simple player go with
> oggs? Maybe because there are people paying to tide customers to the new
> proprietary format without giving them an option?

Well if customers are stupid enough to eat whats on the table... they
need more education. Politics and marketing have something in
common... both dont tell ya the truth and both have goals they want to
achieve.

I think as long as "marketing" as it exists today can still be
successful there will be more demand for education of people.

>
> Think about it once again - I can't make my DVD player, nor my portable
> MP3 player, nor my car MP3 player (and so on...) to play Ogg Vorbis. In
> the same time I CAN make my Fedora to play and even encode MP3, WMA and
> other formats.

When i buy hardware i make sure that it does what i want. if it
doesent i wont spend money on it. we can play through the "chicken and
egg" problem over and over.. The only starting point i see is if users
explicitely demand support for superior formats of those embedded
devices you talk about or not buy it at all while letting the industry
know, because then theres a business case... .


> I even HAVE TO use my computer to rip my new CD and
> encode to MP3 in order to load it to my MP3 player. That's one of the
> tasks people use any OS for nowadays. (I don't possess any MP3 player in
> reality, but know many people who do)

Well you can still with livna supplied addon packages but yeah you
cant with plain fedora... its plain forbiddenitems.

>
> Besides, I may be totally wrong, so please don't yell at me, but one of
> the reasons there are so many multimedia players lacking support for
> open formats may be the GPL licensing of decoders.

You can use videolan client just fine on windows. and it comes with
above support plus support for alot other codecs. Non free software is
in my eyes not even worth talking about in that context, but again...
thats just me...

>
> So even if there are good free (speech+beer) formats, encoders and
> decoders, even if I do use Ogg Vorbis and Musepack (I've heard it's free
> now) on my computer, other people simply can't unless other multimedia
> hardware adopts the free formats. Until then many people have no real
> option. You may be lucky, I may be lucky, but others are less lucky and
> there's not much words can do ("education").

Thats what i see completly different... you state above that its a
"marketing issue" you arent completly wrong with that in my eyes...
marketing in this case does nothing but educate the user in a wrong
way though...

Again i see parallels to politics... where the Marketing people (of
the industry) and the Politicians try to tell us that we exist to
"serve them" instead of vice versa most of above mentioned can really
be happy that most people dont know better.

The question there in my eyes is rhetorical: "Who is the customer?" or
rather "Where do you (as producer) get your money from in the end?".

Change does only happen with enough demand... so lets start demanding :)

regards,
Rudolf Kastl

>
> Lam
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQBEKS8JGU+CzS/wSzYRAsteAJ4zik1QJ0UnvP6eRQPXgaXDNxbyeACgpIEL
> vxKD9o/CbaUU5z3863S+T3g=
> =nDNa
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From seanlkml at sympatico.ca  Tue Mar 28 13:01:04 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 08:01:04 -0500
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143549705.4097.30.camel@pensja.lam.pl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<1143549705.4097.30.camel@pensja.lam.pl>
Message-ID: <BAYC1-PASMTP107B2E626C5863743F9E43AED30@CEZ.ICE>

On Tue, 28 Mar 2006 14:41:45 +0200
Leszek Matok <Lam at Lam.pl> wrote:

> So even if there are good free (speech+beer) formats, encoders and
> decoders, even if I do use Ogg Vorbis and Musepack (I've heard it's free
> now) on my computer, other people simply can't unless other multimedia
> hardware adopts the free formats. Until then many people have no real
> option. You may be lucky, I may be lucky, but others are less lucky and
> there's not much words can do ("education").

Naw.. you can buy really good portable ogg players today.. check out the 
selection from iriver for example.   

We should be concentrating on how to provide viable alternatives to 
proprietary lockin.   There are _lots_ of other options if you don't 
care about open source, including other linux distributions; use 
one of them if you want mp3 out of the box [1].

On the other hand if you do care, then Fedora is a nice home for you
to collaborate with others of like mind.

Cheers,
Sean


[1]  Unless Eric is right and we can include an open source mp3 player
     without legal troubles.



From sundaram at fedoraproject.org  Tue Mar 28 13:05:14 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 28 Mar 2006 18:35:14 +0530
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <4429327A.2060401@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>  <4429327A.2060401@gmail.com>
Message-ID: <1143551114.3802.482.camel@sundaram.pnq.redhat.com>

On Tue, 2006-03-28 at 09:56 -0300, Casimiro de Almeida Barreto wrote:
> Andy Green escreveu: 
> > Eric S. Raymond wrote: 
> > 
> > (...)
> > > But the art problem pales compared to the issue that everyone has
> > > been 
> > > ducking, which is Fedora's support for DVDs and proprietary audio
> > > and 
> > > video and web-streaming formats and Java applets. That is to say,
> > > its 
> > ... 
> > > It's 2006, people.  The Web is fifteen years old.  Even non-
> > > techies 
> > > have had a decade to form expectations about what constitutes a
> > > base 
> > 
> > Supporting Flash seems to soak up most of the problem that can be
> > solved, eg, youtube, Google Video, and if you have 32-bit firefox
> > you can have it.  Seems the only answer for Quicktime and such is
> > the corporate mantrap that is Mplayer, it makes no sense for Redhat
> > to invite attack on their cash by playing that game.  There is no
> > limit to the number of dangerous proprietary formats that one could
> > address by that logic. 
> > 
> This kind of argument only shows 2 things:
> 
>      1. RedHat/Fedora people are absolutelly unable to deal with major
>         manufacturers (Adobe for Instance) and have good versions of
>         Flash/Shockwave and (Apple) Quicktime. Curious thing is that
>         my Apple Mini (a real wonder) runs OS X Tiger (that is a *NIX
>         system) and has no problems with flash, shockwave or PDF
>         files... as well as don't have problems with device drivers.
>      2. RedHat wants, in the mid-range/long term to have a "commercial
>         product" where those "facilities" and other "utilities" are
>         sold at a price...

or 3. We actually want Fedora to be a entirely Free and open source
system like stated explicitly. Funny how that works.

> In software market everything is gray zone. You issue MySql and AFAIK
> it is not really "open source", but them you stripe it (so RHEL can
> have the full flavour and the others don't). 


MySQL is not open source. That's news to me. Why doesn't it qualify?

> You may not know, but what was done to PHP in FC-5 is a shame. There
> is no f_ck_g way to make international encoding to work well.

Did you file a bug report? That would be a first step for all confirmed
bugs. 


Rahul



From seanlkml at sympatico.ca  Tue Mar 28 13:05:27 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 08:05:27 -0500
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <442934B8.6080703@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<442934B8.6080703@gmail.com>
Message-ID: <BAYC1-PASMTP096F077FA02B748AD7F284AED30@CEZ.ICE>

On Tue, 28 Mar 2006 10:06:00 -0300
Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> wrote:

> Yeah... but the thousand flies that like SoundClick, PureVolume, 
> 15megsoffame, etc... etc... etc... not to mention the Internet radios 
> and other multimedia sites fell like compelled to use M$ or Apple OS X ???

We're trying to provide viable open source solutions to those that
care.   If you're life is so wrapped up in proprietary formats that
you can't extricate yourself then Fedora isn't for you.   But if some
day you get tired of proprietary lockin, Fedora will be happily making
the open source alternative better and better!

> Just as OS2 was superior of NT4.0... Hey... that's nonsense... most 
> portable players just play MP3, WMA, WMV, MPG and AVI. The others are 
> rare, expensive and have exotic interfaces... Not to talk about the 
> digital sound systems that we have at home, at our cars, etc... Try to 
> play OGG/Theora in your DVD player at home... Try to play OGG/Theora on 
> your PS2... That's not educational problem that's practical problem...

For people that feel the need to do those things, then Fedora isn't 
for them.   Personally, I've never felt the need to play my music on a 
PS2 or on my DVD player.

Sean



From benjy.grogan at gmail.com  Tue Mar 28 13:13:52 2006
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Tue, 28 Mar 2006 08:13:52 -0500
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143551114.3802.482.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com> <4429327A.2060401@gmail.com>
	<1143551114.3802.482.camel@sundaram.pnq.redhat.com>
Message-ID: <d82d6db50603280513t4a087d5en19de73a11ca6dd34@mail.gmail.com>

On 3/28/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> On Tue, 2006-03-28 at 09:56 -0300, Casimiro de Almeida Barreto wrote:
> > Andy Green escreveu:
> > > Eric S. Raymond wrote:
> > >
> > > (...)
> > > > But the art problem pales compared to the issue that everyone has
> > > > been
> > > > ducking, which is Fedora's support for DVDs and proprietary audio
> > > > and
> > > > video and web-streaming formats and Java applets. That is to say,
> > > > its
> > > ...
> > > > It's 2006, people.  The Web is fifteen years old.  Even non-
> > > > techies
> > > > have had a decade to form expectations about what constitutes a
> > > > base
> > >
> > > Supporting Flash seems to soak up most of the problem that can be
> > > solved, eg, youtube, Google Video, and if you have 32-bit firefox
> > > you can have it.  Seems the only answer for Quicktime and such is
> > > the corporate mantrap that is Mplayer, it makes no sense for Redhat
> > > to invite attack on their cash by playing that game.  There is no
> > > limit to the number of dangerous proprietary formats that one could
> > > address by that logic.
> > >
> > This kind of argument only shows 2 things:
> >
> >      1. RedHat/Fedora people are absolutelly unable to deal with major
> >         manufacturers (Adobe for Instance) and have good versions of
> >         Flash/Shockwave and (Apple) Quicktime. Curious thing is that
> >         my Apple Mini (a real wonder) runs OS X Tiger (that is a *NIX
> >         system) and has no problems with flash, shockwave or PDF
> >         files... as well as don't have problems with device drivers.
> >      2. RedHat wants, in the mid-range/long term to have a "commercial
> >         product" where those "facilities" and other "utilities" are
> >         sold at a price...
>
> or 3. We actually want Fedora to be a entirely Free and open source
> system like stated explicitly. Funny how that works.

I think more official agreements like the one for Macromedia Flash
that Warren Togami somehow got would be useful.  These companies that
do provide linux versions of their software should be interested in
getting their software out to all the distributions.  I'm very happy
with the fact that all flash plugin updates will automatically be
taken care of.

Benji



From fedora at adslpipe.co.uk  Tue Mar 28 13:17:04 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Tue, 28 Mar 2006 14:17:04 +0100
Subject: Fedora's way forward
In-Reply-To: <44291421.8050502@poolshark.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291421.8050502@poolshark.org>
Message-ID: <44293750.10804@adslpipe.co.uk>

Denis Leroy wrote:

> I think it's worth pointing that FC5 Extras shipping
> with a fully working libgcj-happy Azureus app is, i think, a remarkable
> achievement.

Indeed it is, I'm pleased to see it there, performance can be a little 
variable though, sometimes it barrels along at my full 1Mb/s ADSL rate, 
but usually it "falls off" to zero a few bytes per second (up and down)

I realise that speed can be one of the vagaries of bittorrent, so I've 
done most(all?) the usual checks (throttled upload to below my ADSL 
uplink speed, open firewall ports for TCP and UDP, keep seeding after 
having downloaded, use ports other than 688X in case of packet shaping 
by my or my peers' ISP)

I often find that when it is stalled like this I need to exit azureus 
(which often fails to close cleanly and then has to check the files 
again) and then restart, it will be fine for another hour or so.

I literally only finished downloading the FC5 i386 and x886_64 DVD .ISOs 
last night because of this, having started as soon as the official 
torrents went up, I wasn't in a rush as I already had the "final" 
rawhide up to date.

I've been considering logging a bugzilla entry for azureus (Anthony 
Green was very helpful during the FC5T1/2/3 period) but held off because 
I wasn't sure if it was "just me" as obviously there are more factors 
involved than the code.

Talking of code, If I turn on console logging I do see more than a few 
runtime errors about array bounds and exceptions in the 
readControllerLoop which could be having an impact.

So the point of this long ramble is to ask if anyone else has similar 
problems achieving sustained high throughputs on "good" torrents, or if 
there might be an issue worth investigating?





From che666 at gmail.com  Tue Mar 28 13:18:16 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 28 Mar 2006 15:18:16 +0200
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <442934B8.6080703@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<442934B8.6080703@gmail.com>
Message-ID: <e99d27470603280518s60102854r438e9a499831e833@mail.gmail.com>

2006/3/28, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com>:
> Rudolf Kastl escreveu:
> (...)
> Supporting Flash seems to soak up most of the problem that can be
solved,
> eg, youtube, Google Video, and if you have 32-bit firefox you
can have it.
> Seems the only answer for Quicktime and such is the
corporate mantrap that
> is Mplayer, it makes no sense for Redhat to
invite attack on their cash by
> playing that game. There is no limit to
the number of dangerous proprietary
> formats that one could address by
that logic.

> flash isnt a standard... how about creating a new better technology
and
> obsolete it? flash requires mp3 for sound playback... so even if a
gpl
> implementation exists it wont be going into extras... id just
forget about
> flash and look "forward". personally i wont run a 32 bit
browser on my 64
> bit system just to get the closed source garbage
working. only real use case
> for flash would be watching some funny
movies... as far as regular webpages
> go... i am not a flash fan at
all, but thats just me...



>
> Yeah... but the thousand flies that like SoundClick, PureVolume,
> 15megsoffame, etc... etc... etc... not to mention the Internet radios and
> other multimedia sites fell like compelled to use M$ or Apple OS X ???
>
>
>

>
> *not optional* in 2006, any more than the ability to read Microsoft
Word
> files in a word processor is optional; if we try to treat them
that way,
> consumers will blow Linux off. Evangelizing for SVG and O

> gg


Consumers mostly just dont know that they are using worse
> legacy
formats like mp3 when they have superior formats such as
> ogg
available... i think thats a plain educational problem.

>
> Just as OS2 was superior of NT4.0... Hey... that's nonsense... most portable
> players just play MP3, WMA, WMV, MPG and AVI. The others are rare, expensive
> and have exotic interfaces... Not to talk about the digital sound systems
> that we have at home, at our cars, etc... Try to play OGG/Theora in your DVD
> player at home... Try to play OGG/Theora on your PS2... That's not
> educational problem that's practical problem...

Or just as amiga was better than atari st... or was it atari st that
was better than amiga? ;)) (throwing a small flame bait j/k).

The practical solution is to demand proper devices with proper support
for the best available means to encode/decode sound and video. Get
linux on your ps/2 btw... problem solved.

>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From cmadams at hiwaay.net  Tue Mar 28 13:19:58 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 28 Mar 2006 07:19:58 -0600
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <4429327A.2060401@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com> <4429327A.2060401@gmail.com>
Message-ID: <20060328131958.GD1241870@hiwaay.net>

Once upon a time, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> said:
>   1. RedHat/Fedora people are absolutelly unable to deal with major
>      manufacturers (Adobe for Instance) and have good versions of
>      Flash/Shockwave and (Apple) Quicktime. Curious thing is that  my
>      Apple Mini (a real wonder) runs OS X Tiger (that is a *NIX system)
>      and has no problems with flash, shockwave or PDF files... as well
>      as don't have problems with device drivers.

First of all, there are multiple PDF readers (and creators) included in
Fedora Core.

Guess what: the commercial Red Hat Enterprise Linux includes Adobe
Acrobat Reader, RealPlayer, Flash, and Java (from IBM and BEA).  Red Hat
is perfectly able to "deal" with those companies for commercial
redistribution licenses.

However, a primary goal of the Fedora Core distrobution is to create a
free, Open Source OS that is also freely redistributable.  None of the
above software falls into that category.  Part of the reason the Red Hat
Linux distro was changed to Fedora was that even Red Hat Linux wasn't
fully freely redistributable (due to Red Hat's trademarks).

Anyone can download Fedora Core DVD images, burn (or master) them, and
sell them (for a profit if they like).  If you put an MP3 decoder in
there, that will no longer be the case (at least in the US).

> The java that comes along with GCC runs only about 10-20% of Java 
> Applications in market. Want examples: try to access any Brazilian bank 
> using "Fedora standard Java". You'll get stuck... But why would people 
> try to access his bank acount from his own computer? A little walk is 
> healthy... So each loving soul under the Sun have to download Sun JRE 
> (at least) or the complete JDK.

I don't think you are going to access any Java web site with Fedora (out
of the box) at the moment as the gcj plugin is not yet included.  For
other Java apps, Bugzilla reports are welcome.

Fedora cannot include Sun's JDK due to Sun's license terms.  If you want
that changed, I suggest you complain to Sun, not Fedora.

> Flash for Linux literally sucks... it is 
> slow, and again there is no support for shockwave.

Fedora cannot include Flash due to Macromedia's license terms.  If you
want that changed, I suggest you complain to Macromedia.  Macromedia
hasn't even written Shockwave support for Linux, so you'll need to
complain to Macromedia about that (Fedora definately cannot include
software that has not been written).

> In software market everything is gray zone. You issue MySql and AFAIK it 
> is not really "open source", but them you stripe it (so RHEL can have 
> the full flavour and the others don't).

Wrong.  MySQL is released under the GPL (that's about as Open Source as
you can get).

> Result: I upgraded a server in 20 minutes and everything stoped 
> to work... that meant 20+ hours of straight work of coding and recoding 
> (man, I had to code calendar months and other stupid things) to have the 
> basics running back.

What kind of idiot upgrades a production server without any testing in
advance?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From fedora at adslpipe.co.uk  Tue Mar 28 13:21:38 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Tue, 28 Mar 2006 14:21:38 +0100
Subject: Fedora's way forward
In-Reply-To: <d82d6db50603280449k37ba70d3ndb028da8369ad2a7@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com><4429238F.4050200@draigBrady.com><1143549867.8791.2.camel@scriabin.tannenrauch.ch>
	<d82d6db50603280449k37ba70d3ndb028da8369ad2a7@mail.gmail.com>
Message-ID: <44293862.1050803@adslpipe.co.uk>

Benjy Grogan wrote:

> On 3/28/06, G?rard Milmeister <gemi at bluewin.ch> wrote:
>>
>> I think, that people that emphasize "the ANNOYING
>> behavior of spatial nautilus" ANNOYING.
>> (from the linked to text)
> 
> Exactly.  I like containers and find all that unnecessary baggage that
> comes with the  browser window annoying.

The spatial window v.s explorer window thing is practically a religious 
argument, I always hated Win9x for opening cascades of windows by 
default, I didn't see it as a good then when nautilus adopted it, but at 
least I can turn it off ...



From sundaram at fedoraproject.org  Tue Mar 28 13:23:12 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 28 Mar 2006 18:53:12 +0530
Subject: Fedora IBM Pseries support
Message-ID: <1143552192.3802.487.camel@sundaram.pnq.redhat.com>

Hi

Can someone add the information request so that we get the information
into the release notes errata

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


Rahul



From seanlkml at sympatico.ca  Tue Mar 28 13:20:36 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 08:20:36 -0500
Subject: Fedora's way forward
In-Reply-To: <44293750.10804@adslpipe.co.uk>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291421.8050502@poolshark.org> <44293750.10804@adslpipe.co.uk>
Message-ID: <BAYC1-PASMTP04DC3F333E5821008F949DAED30@CEZ.ICE>

On Tue, 28 Mar 2006 14:17:04 +0100
Andy Burns <fedora at adslpipe.co.uk> wrote:

> So the point of this long ramble is to ask if anyone else has similar 
> problems achieving sustained high throughputs on "good" torrents, or if 
> there might be an issue worth investigating?

I saw the exact same thing with the Fedora downloads.   Interestingly if
you let it sit, it would eventually shut down cleanly; although sometimes
it would take an hour.   While the fact that it runs at all is a great
achievement, it still needs a few kinks worked out.  After switching to 
the bittorrent client things sailed along fine.   

Sean



From green at redhat.com  Tue Mar 28 14:06:07 2006
From: green at redhat.com (Anthony Green)
Date: Tue, 28 Mar 2006 06:06:07 -0800
Subject: Fedora's way forward
In-Reply-To: <20060328082036.76a6d9a4.seanlkml@sympatico.ca>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291421.8050502@poolshark.org> <44293750.10804@adslpipe.co.uk>
	<20060328082036.76a6d9a4.seanlkml@sympatico.ca>
Message-ID: <1143554768.3970.13.camel@localhost.localdomain>

On Tue, 2006-03-28 at 08:20 -0500, sean wrote:
> 
> I saw the exact same thing with the Fedora downloads.   Interestingly
> if
> you let it sit, it would eventually shut down cleanly; although
> sometimes
> it would take an hour.   While the fact that it runs at all is a great
> achievement, it still needs a few kinks worked out. 

Thanks.  Please file bug reports.  I will likely update FE to a cvs
snapshot of 2.4.0.3 today, but I think that most of the problems are
with GNU Classpath and not azureus.  I'm hopeful these can be cleaned up
quickly once once we characterize the report the Classpath bugs.

AG




From avi at argo.co.il  Tue Mar 28 14:08:17 2006
From: avi at argo.co.il (Avi Kivity)
Date: Tue, 28 Mar 2006 16:08:17 +0200
Subject: FC5 missing support for ISA NICs
Message-ID: <44294351.1080300@argo.co.il>

FC5 was released without support for ne2000 and other ISA NICs. I ended 
up running the FC4 kernel.

This is too late for the installation media, but can some kind soul turn 
on ISA NIC support?

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

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From tibbs at math.uh.edu  Tue Mar 28 14:15:33 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Tue, 28 Mar 2006 08:15:33 -0600
Subject: [ANN] Release Notes Errata - Wiki Freeze
In-Reply-To: <20060328122303.GA19783@jadzia.bu.edu> (Matthew Miller's
	message of "Tue, 28 Mar 2006 07:23:03 -0500")
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
Message-ID: <ufahd5ihcze.fsf@epithumia.math.uh.edu>

>>>>> "MM" == Matthew Miller <mattdm at mattdm.org> writes:

MM> Maybe a good idea to break the release notes out of the
MM> fedora-release package?

If fedora-release is getting love, I wonder if it would be possible to
remove the repositories from it as well.  They just cause problems for
those of us with local mirrors.

 - J<



From sundaram at fedoraproject.org  Tue Mar 28 14:18:31 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 28 Mar 2006 19:48:31 +0530
Subject: [ANN] Release Notes Errata - Wiki Freeze
In-Reply-To: <ufahd5ihcze.fsf@epithumia.math.uh.edu>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
Message-ID: <1143555512.3802.508.camel@sundaram.pnq.redhat.com>

On Tue, 2006-03-28 at 08:15 -0600, Jason L Tibbitts III wrote:
> >>>>> "MM" == Matthew Miller <mattdm at mattdm.org> writes:
> 
> MM> Maybe a good idea to break the release notes out of the
> MM> fedora-release package?
> 
> If fedora-release is getting love, I wonder if it would be possible to
> remove the repositories from it as well.  They just cause problems for
> those of us with local mirrors.

Which repositories? Can you provide more details?

Rahul



From chapmam2 at ocps.net  Tue Mar 28 14:18:42 2006
From: chapmam2 at ocps.net (Matt Chapman)
Date: Tue, 28 Mar 2006 09:18:42 -0500
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <20060328131958.GD1241870@hiwaay.net>
Message-ID: <C04EAFF2.BBC3%chapmam2@ocps.net>

Two things that have always bugged me.  One we are getting to a good point
in ?using - viewing? content like Flash, movies, and audio created by others
on mostly other operating systems but Linux still has a ways to go in
?creating? that rich web content.  My example is easy Flash, Shockwave, and
Quicktime movies. And two:  If I want to take a machine that is running
Fedora and ?upgrade? it to Red Hat Enterprise I can?t with a simply CD/DVD
insert and go method.

My 2 cents.

Matthew Chapman


On 3/28/06 8:19 AM, "Chris Adams" <cmadams at hiwaay.net> wrote:

> Once upon a time, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com>
> said:
>> >   1. RedHat/Fedora people are absolutelly unable to deal with major
>> >      manufacturers (Adobe for Instance) and have good versions of
>> >      Flash/Shockwave and (Apple) Quicktime. Curious thing is that  my
>> >      Apple Mini (a real wonder) runs OS X Tiger (that is a *NIX system)
>> >      and has no problems with flash, shockwave or PDF files... as well
>> >      as don't have problems with device drivers.
> 
> First of all, there are multiple PDF readers (and creators) included in
> Fedora Core.
> 
> Guess what: the commercial Red Hat Enterprise Linux includes Adobe
> Acrobat Reader, RealPlayer, Flash, and Java (from IBM and BEA).  Red Hat
> is perfectly able to "deal" with those companies for commercial
> redistribution licenses.
> 
> However, a primary goal of the Fedora Core distrobution is to create a
> free, Open Source OS that is also freely redistributable.  None of the
> above software falls into that category.  Part of the reason the Red Hat
> Linux distro was changed to Fedora was that even Red Hat Linux wasn't
> fully freely redistributable (due to Red Hat's trademarks).
> 
> Anyone can download Fedora Core DVD images, burn (or master) them, and
> sell them (for a profit if they like).  If you put an MP3 decoder in
> there, that will no longer be the case (at least in the US).
> 
>> > The java that comes along with GCC runs only about 10-20% of Java
>> > Applications in market. Want examples: try to access any Brazilian bank
>> > using "Fedora standard Java". You'll get stuck... But why would people
>> > try to access his bank acount from his own computer? A little walk is
>> > healthy... So each loving soul under the Sun have to download Sun JRE
>> > (at least) or the complete JDK.
> 
> I don't think you are going to access any Java web site with Fedora (out
> of the box) at the moment as the gcj plugin is not yet included.  For
> other Java apps, Bugzilla reports are welcome.
> 
> Fedora cannot include Sun's JDK due to Sun's license terms.  If you want
> that changed, I suggest you complain to Sun, not Fedora.
> 
>> > Flash for Linux literally sucks... it is
>> > slow, and again there is no support for shockwave.
> 
> Fedora cannot include Flash due to Macromedia's license terms.  If you
> want that changed, I suggest you complain to Macromedia.  Macromedia
> hasn't even written Shockwave support for Linux, so you'll need to
> complain to Macromedia about that (Fedora definately cannot include
> software that has not been written).
> 
>> > In software market everything is gray zone. You issue MySql and AFAIK it
>> > is not really "open source", but them you stripe it (so RHEL can have
>> > the full flavour and the others don't).
> 
> Wrong.  MySQL is released under the GPL (that's about as Open Source as
> you can get).
> 
>> > Result: I upgraded a server in 20 minutes and everything stoped
>> > to work... that meant 20+ hours of straight work of coding and recoding
>> > (man, I had to code calendar months and other stupid things) to have the
>> > basics running back.
> 
> What kind of idiot upgrades a production server without any testing in
> advance?
> 
> --
> 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.
> 
> --
> 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/20060328/bb5a2478/attachment.htm>

From tibbs at math.uh.edu  Tue Mar 28 14:35:36 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Tue, 28 Mar 2006 08:35:36 -0600
Subject: [ANN] Release Notes Errata - Wiki Freeze
In-Reply-To: <1143555512.3802.508.camel@sundaram.pnq.redhat.com> (Rahul
	Sundaram's message of "Tue, 28 Mar 2006 19:48:31 +0530")
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
	<1143555512.3802.508.camel@sundaram.pnq.redhat.com>
Message-ID: <ufad5g6hc1z.fsf@epithumia.math.uh.edu>

>>>>> "RS" == Rahul Sundaram <sundaram at fedoraproject.org> writes:

RS> Which repositories? Can you provide more details?

Everything in /etc/yum.repos.d.  Since people with local mirrors won't
want to use the default repos, we have to rebuild fedora-release,
respin the base distro and do something like bump the epoch so that an
updated package from Red Hat doesn't screw us.

Centos is kind enough to put these in a centos-yumconf package, which
my local repository RPM can provide.

 - J<



From sundaram at fedoraproject.org  Tue Mar 28 14:38:07 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 28 Mar 2006 20:08:07 +0530
Subject: [ANN] Release Notes Errata - Wiki Freeze
In-Reply-To: <ufad5g6hc1z.fsf@epithumia.math.uh.edu>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
	<1143555512.3802.508.camel@sundaram.pnq.redhat.com>
	<ufad5g6hc1z.fsf@epithumia.math.uh.edu>
Message-ID: <1143556687.3802.517.camel@sundaram.pnq.redhat.com>

On Tue, 2006-03-28 at 08:35 -0600, Jason L Tibbitts III wrote:
> >>>>> "RS" == Rahul Sundaram <sundaram at fedoraproject.org> writes:
> 
> RS> Which repositories? Can you provide more details?
> 
> Everything in /etc/yum.repos.d.  Since people with local mirrors won't
> want to use the default repos, we have to rebuild fedora-release,
> respin the base distro and do something like bump the epoch so that an
> updated package from Red Hat doesn't screw us.
> 
> Centos is kind enough to put these in a centos-yumconf package, which
> my local repository RPM can provide.

So you want them to be in a separate package instead of within the
fedora-release package. That makes more sense I guess.


Rahul



From shiva at sewingwitch.com  Tue Mar 28 14:44:13 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 28 Mar 2006 06:44:13 -0800
Subject: GUI controls for instrumentation
In-Reply-To: <200603280103.40598.lamont@gurulabs.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<1143389147.2816.6.camel@rousalka.dyndns.org>	<20060326181557.68fcfc46@lain>
	<200603280103.40598.lamont@gurulabs.com>
Message-ID: <A5FD712AD9D181D45F2D61FB@[10.0.0.14]>

--On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R. Peterson" 
<lamont at gurulabs.com> wrote:

> For an instrumentation application, Java would be a HUGE mistake.
>
> For an instrumentation application, C++ is a very sane choice.  There are
> lots  of benefits and lots and lots of libraries for all sorts of I/O,
> control &  input cards/systems out there.

You seem to presume that one must code the whole thing in one language as a 
monolithic application. I don't expect some of my deployments to have a 
display. It might be a little "brick" computer buried in a rack or inside 
some OEM factory equipment.

I expect to code the "back end" that talks to the hardware in C++, because 
my vendors' expose their API's either as C++ or C, and because I will be 
exposing an API to my customers. But the front end is going to be separate 
and may be attached either as a linked application (ie. exe/dll or 
executable/so) or via TCP/IP, possibly local. There may even be multiple 
"heads", with some acting as remote monitors while others act as control 
panels.

One reason I don't want a monolithic application is because it gives me the 
freedom to try different front-ends based on platform support for control 
libraries. I might have a web front-end using SVG, a local one with Qt, or 
perhaps something using Java for either.

I expect any control library will give me the common stuff like windows and 
radio buttons. It's the more esoteric stuff like oscopes, gauges, and knobs 
that I'm trying to nail down.



From jdesbonnet at gmail.com  Tue Mar 28 14:46:44 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 28 Mar 2006 15:46:44 +0100
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143548303.3802.474.camel@sundaram.pnq.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143548303.3802.474.camel@sundaram.pnq.redhat.com>
Message-ID: <1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>

Thanks -- the live cd tool could be very useful for testing coming up
to the next release. Perhaps we can compile a list of volunteers with
various makes of laptops to run some sort of live cd tests at the
test2 or test3 phase. I would be glad to to use my Thinkpad T41p for
testing -- as long as I'm back to a usable computer by pressing the
reset button.  Is a "fedora-laptop-list" warranted?

I had a quick look at Ubuntu 5.04 yesterday evening. There are a few
things there I think we could use:

1. They have a hardware test program which can be used to compile a
report which can be sent back to the development team, along your
comments on each of the tests.
2. There is a hardware browser (do we have something like that? I
can't find it if we do). This would be a *VERY* useful tool.

Joe.


On 3/28/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>
>
> We have a live CD creation tool called Kadischi and some live CD's
> floating around in fedora-livecd list. Details at
> http://fedoraproject.org/wiki/Kadischi/.
>
> We also have a project http://pootypedia.sourceforge.net/ which got
> sponsored by Fedora as part of Google's SOC. Unfortunately pootypedia is
> based on Kudzu while we are moving to HAL instead. Someone needs to
> combine these efforts and we need more developers to take this forward.
>
>
> Rahul
>
>



From sundaram at fedoraproject.org  Tue Mar 28 14:54:05 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 28 Mar 2006 20:24:05 +0530
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143548303.3802.474.camel@sundaram.pnq.redhat.com>
	<1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
Message-ID: <1143557645.3802.525.camel@sundaram.pnq.redhat.com>

On Tue, 2006-03-28 at 15:46 +0100, Joe Desbonnet wrote:
> Thanks -- the live cd tool could be very useful for testing coming up
> to the next release. Perhaps we can compile a list of volunteers with
> various makes of laptops to run some sort of live cd tests at the
> test2 or test3 phase. I would be glad to to use my Thinkpad T41p for
> testing -- as long as I'm back to a usable computer by pressing the
> reset button.  Is a "fedora-laptop-list" warranted?

Ya. That I think is a good idea. Can you request this against Fedora
infrastructure in http://bugzilla.redhat.com ?

> 
> I had a quick look at Ubuntu 5.04 yesterday evening. There are a few
> things there I think we could use:
> 
> 1. They have a hardware test program which can be used to compile a
> report which can be sent back to the development team, along your
> comments on each of the tests.

You can look at the tool and see if it can be ported to Fedora easily.
We can do something similar in the next release if we get it we get the
client side packaged in Fedora Core and have someone handle the server
side in fedoraproject.org 

> 2. There is a hardware browser (do we have something like that? I
> can't find it if we do). This would be a *VERY* useful tool.

hal-device-manager (which unfortunately doesnt show up on the menus )
and hwbrowser 

Rahul



From katzj at redhat.com  Tue Mar 28 15:00:13 2006
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 28 Mar 2006 10:00:13 -0500
Subject: [ANN] Release Notes Errata - Wiki Freeze
In-Reply-To: <ufahd5ihcze.fsf@epithumia.math.uh.edu>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
Message-ID: <1143558013.3140.15.camel@aglarond.local>

On Tue, 2006-03-28 at 08:15 -0600, Jason L Tibbitts III wrote:
> >>>>> "MM" == Matthew Miller <mattdm at mattdm.org> writes:
> MM> Maybe a good idea to break the release notes out of the
> MM> fedora-release package?
> 
> If fedora-release is getting love, I wonder if it would be possible to
> remove the repositories from it as well.  They just cause problems for
> those of us with local mirrors.

The entire point of fedora-release is basically to contain this stuff
which ends up having to change at the last minute so that we can contain
the number of changes which are needed when we're trying to build final
trees.  Also, it means one stop shopping for changing from, say, Fedora
to JoeBob's Distro :)

Jeremy



From jspaleta at gmail.com  Tue Mar 28 15:03:49 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 10:03:49 -0500
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <C04EAFF2.BBC3%chapmam2@ocps.net>
References: <20060328131958.GD1241870@hiwaay.net>
	<C04EAFF2.BBC3%chapmam2@ocps.net>
Message-ID: <604aa7910603280703o7b02b0yd3a2348bd9ff6620@mail.gmail.com>

On 3/28/06, Matt Chapman <chapmam2 at ocps.net> wrote:

> And two:  If I want to take a machine that is running
> Fedora and "upgrade" it to Red Hat Enterprise I can't with a simply CD/DVD
> insert and go method.

As a paying customer for RHEL, I belive there are established
mechanisms outside of the fedora space for you to make feature
requests which will impact the features implemented in RHEL releases.
If multiple paying customers of RHEL want to see this as a supported
upgrade path make a request for that feature in RHEL in the
appropriate places then the probability of that feature being
implemented will go up. I doubt this is the appropriate place to make
requests of RHEL behavior.

-jef



From davej at redhat.com  Tue Mar 28 15:06:48 2006
From: davej at redhat.com (Dave Jones)
Date: Tue, 28 Mar 2006 10:06:48 -0500
Subject: FC5 missing support for ISA NICs
In-Reply-To: <44294351.1080300@argo.co.il>
References: <44294351.1080300@argo.co.il>
Message-ID: <20060328150648.GD7916@redhat.com>

On Tue, Mar 28, 2006 at 04:08:17PM +0200, Avi Kivity wrote:
 > FC5 was released without support for ne2000 and other ISA NICs. I ended 
 > up running the FC4 kernel.
 > 
 > This is too late for the installation media, but can some kind soul turn 
 > on ISA NIC support?

Fixed in cvs and latest build, which goes live today.

		Dave

-- 
http://www.codemonkey.org.uk



From avi at argo.co.il  Tue Mar 28 15:17:58 2006
From: avi at argo.co.il (Avi Kivity)
Date: Tue, 28 Mar 2006 17:17:58 +0200
Subject: FC5 missing support for ISA NICs
In-Reply-To: <20060328150648.GD7916@redhat.com>
References: <44294351.1080300@argo.co.il> <20060328150648.GD7916@redhat.com>
Message-ID: <442953A6.4090304@argo.co.il>

Dave Jones wrote:
> On Tue, Mar 28, 2006 at 04:08:17PM +0200, Avi Kivity wrote:
>  > FC5 was released without support for ne2000 and other ISA NICs. I ended 
>  > up running the FC4 kernel.
>  > 
>  > This is too late for the installation media, but can some kind soul turn 
>  > on ISA NIC support?
>
> Fixed in cvs and latest build, which goes live today.
>   
Thanks. There was no activity on the report so I assumed it was lost in 
the noise.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From dwalsh at redhat.com  Tue Mar 28 15:28:23 2006
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 28 Mar 2006 10:28:23 -0500
Subject: selinux-policy-targeted-2.2.26-1 policy was bad.
In-Reply-To: <200603281337.22271.billcrawford1970@googlemail.com>
References: <1143316951.4425a1d750bff@www.jouy.inra.fr>
	<1143321367.14370.3.camel@localhost.localdomain>
	<44280CE5.8010802@redhat.com>
	<200603281337.22271.billcrawford1970@googlemail.com>
Message-ID: <44295617.2070405@redhat.com>

I have pulled it out of rawhide.  If you have updated and want to get 
your machine working again with SELinux
you need to install selinux-policy-targeted-2.2.25-* you can do this 
with the following command

rpm -Uhv --oldpackage selinux-policy-targeted-2.2.25-2

This will report an error but the correct files will have been placed on 
disk.

Now if you execute

semodule -n -b /usr/share/selinux/targeted/base.pp; touch /.autorelabel; 
reboot

When this finishes your system should be back and running with selinux 
enabled. 

Policy was broken by a change to the policy tool chain that we are 
working to fix.

Sorry about the problems this has caused.

Dan



From jspaleta at gmail.com  Tue Mar 28 15:38:48 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 10:38:48 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328104659.GI12588@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
Message-ID: <604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>

On 3/28/06, Alan Cox <alan at redhat.com> wrote:
> I suggest you consult lawyers. Frauenhofer have claimed player royalties
> and quite actively.

Other than to talk to a lawyer, which is always the authorative action
to take on any issues involving questions of legal risk.... is there
any instructive references that could be cited in layperson oriented
documentation as to why mp3 playback support isn't included? I ask
because the argument about playback being without risk comes up from
misinformed laypeople in the userbase with some frequency. It would be
useful to have a specific reference for further reading which could be
used to help misinformed people to start re-evaluating their personal
view or at least doubting the information the read elsewhere on this
matter.

-jef



From shiva at sewingwitch.com  Tue Mar 28 15:46:49 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 28 Mar 2006 07:46:49 -0800
Subject: GUI controls for instrumentation
In-Reply-To: <e99d27470603280131o7b790f4oe90cd722999c8aff@mail.gmail.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603242033.03945.lamont@gurulabs.com>
	<1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com>
	<1143281498.4018.6.camel@rousalka.dyndns.org>	<44251FC4.3070207@yahoo.co.uk>
	<1143284362.4018.14.camel@rousalka.dyndns.org>
	<442529EB.2040004@yahoo.co.uk>
	<e99d27470603280131o7b790f4oe90cd722999c8aff@mail.gmail.com>
Message-ID: <EC11B603AF3E22EC36593FC5@[10.0.0.14]>

--On Tuesday, March 28, 2006 11:31 AM +0200 Rudolf Kastl <che666 at gmail.com> 
wrote:

> why would a linux user make his source dependendant on
> non free things?

Sometimes the functionality you need isn't available for free.




From esr at thyrsus.com  Tue Mar 28 15:53:14 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 10:53:14 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143548303.3802.474.camel@sundaram.pnq.redhat.com>
	<1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
Message-ID: <20060328155314.GA25098@thyrsus.com>

Joe Desbonnet <jdesbonnet at gmail.com>:
> Thanks -- the live cd tool could be very useful for testing coming up
> to the next release. Perhaps we can compile a list of volunteers with
> various makes of laptops to run some sort of live cd tests at the
> test2 or test3 phase.

Count me and my X40 in on this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From fedora at adslpipe.co.uk  Tue Mar 28 15:53:58 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Tue, 28 Mar 2006 16:53:58 +0100
Subject: Fedora's way forward
In-Reply-To: <1143554768.3970.13.camel@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com><44291421.8050502@poolshark.org>
	<44293750.10804@adslpipe.co.uk><20060328082036.76a6d9a4.seanlkml@sympatico.ca>
	<1143554768.3970.13.camel@localhost.localdomain>
Message-ID: <44295C16.40304@adslpipe.co.uk>

Anthony Green wrote:

> Please file bug reports.  

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

> I will likely update FE to a cvs snapshot of 2.4.0.3 today, 

Will that go to extras or extras-development?

> I think that most of the problems are
> with GNU Classpath and not azureus.  I'm hopeful these can be cleaned up
> quickly once once we characterize the report the Classpath bugs.

I hope so, pleased with azureus, but limewire would be nice too :-P



From esr at thyrsus.com  Tue Mar 28 15:54:39 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 10:54:39 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143557645.3802.525.camel@sundaram.pnq.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143548303.3802.474.camel@sundaram.pnq.redhat.com>
	<1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
	<1143557645.3802.525.camel@sundaram.pnq.redhat.com>
Message-ID: <20060328155439.GB25098@thyrsus.com>

Rahul Sundaram <sundaram at fedoraproject.org>:
> On Tue, 2006-03-28 at 15:46 +0100, Joe Desbonnet wrote:
> > Thanks -- the live cd tool could be very useful for testing coming up
> > to the next release. Perhaps we can compile a list of volunteers with
> > various makes of laptops to run some sort of live cd tests at the
> > test2 or test3 phase. I would be glad to to use my Thinkpad T41p for
> > testing -- as long as I'm back to a usable computer by pressing the
> > reset button.  Is a "fedora-laptop-list" warranted?
> 
> Ya. That I think is a good idea. Can you request this against Fedora
> infrastructure in http://bugzilla.redhat.com ?

And post the bug number here sio I and others can add comments signing up and 
registering our Thinkpad types.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Tue Mar 28 15:57:40 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 10:57:40 -0500
Subject: Fedora's way forward
In-Reply-To: <604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
Message-ID: <20060328155740.GC25098@thyrsus.com>

Jeff Spaleta <jspaleta at gmail.com>:
> On 3/28/06, Alan Cox <alan at redhat.com> wrote:
> > I suggest you consult lawyers. Frauenhofer have claimed player royalties
> > and quite actively.
> 
> Other than to talk to a lawyer, which is always the authorative action
> to take on any issues involving questions of legal risk.... is there
> any instructive references that could be cited in layperson oriented
> documentation as to why mp3 playback support isn't included?

Yes, I'd like to see an authoritative source for Alan's assertion.

I did quite a bit of web research before making my statement.  If
Fraunhofer has made claims on decoders, this fact is unknown (or not
disclosed) by any of the major decoder implementors.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jdesbonnet at gmail.com  Tue Mar 28 15:58:56 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 28 Mar 2006 16:58:56 +0100
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060328155439.GB25098@thyrsus.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143548303.3802.474.camel@sundaram.pnq.redhat.com>
	<1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
	<1143557645.3802.525.camel@sundaram.pnq.redhat.com>
	<20060328155439.GB25098@thyrsus.com>
Message-ID: <1cef3e950603280758n142d0bf6n654ce8dfc4ac72c6@mail.gmail.com>

Bugzilla item for creation of laptop list:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187107

On 3/28/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> And post the bug number here sio I and others can add comments signing up and
> registering our Thinkpad types.



From seanlkml at sympatico.ca  Tue Mar 28 15:59:12 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 10:59:12 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328155740.GC25098@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
Message-ID: <BAYC1-PASMTP10AD480FC47A576429D92DAED30@CEZ.ICE>

On Tue, 28 Mar 2006 10:57:40 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:
> 
> Yes, I'd like to see an authoritative source for Alan's assertion.
> 
> I did quite a bit of web research before making my statement.  If
> Fraunhofer has made claims on decoders, this fact is unknown (or not
> disclosed) by any of the major decoder implementors.


Well, Fraunhofer has this page:

http://www.iis.fraunhofer.de/amm/licensing/index.html

Which links to :

http://www.mp3licensing.com/

Which definitely shows royalty fees for decoders.

Sean



From lamont at gurulabs.com  Tue Mar 28 16:06:21 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 28 Mar 2006 09:06:21 -0700
Subject: GUI controls for instrumentation
In-Reply-To: <A5FD712AD9D181D45F2D61FB@[10.0.0.14]>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603280103.40598.lamont@gurulabs.com>
	<A5FD712AD9D181D45F2D61FB@[10.0.0.14]>
Message-ID: <200603280906.21172.lamont@gurulabs.com>

On Tuesday 28 March 2006 07:44am, Kenneth Porter wrote:
> --On Tuesday, March 28, 2006 1:03 AM -0700 "Lamont R. Peterson"
>
> <lamont at gurulabs.com> wrote:
> > For an instrumentation application, Java would be a HUGE mistake.
> >
> > For an instrumentation application, C++ is a very sane choice.  There are
> > lots  of benefits and lots and lots of libraries for all sorts of I/O,
> > control &  input cards/systems out there.
>
> You seem to presume that one must code the whole thing in one language as a
> monolithic application. I don't expect some of my deployments to have a
> display. It might be a little "brick" computer buried in a rack or inside
> some OEM factory equipment.

No, I don't make that assumption, though I see why it would appear that way.  
Thanks for catching it.

However, most times I have seen Instrumentation apps, they are coded in one 
language plus an embedded scripting language is included for automating or 
"linking" of controls, inputs & outputs.  At least, that's the way the 
commercial toolkits usually did things.

Of course, this might no longer be the case, as I really haven't seen or done 
anything with instrumentation packages in about 5 years or so.  Then again, 
in this kind of area, I'm sure most people are sticking with what works.  
It's a pretty well established field.

> I expect to code the "back end" that talks to the hardware in C++, because
> my vendors' expose their API's either as C++ or C, and because I will be
> exposing an API to my customers. But the front end is going to be separate
> and may be attached either as a linked application (ie. exe/dll or
> executable/so) or via TCP/IP, possibly local. There may even be multiple
> "heads", with some acting as remote monitors while others act as control
> panels.

Yes.  That was part of what I was thinking/trying to say.  Most such libraries 
are C++ or (less commonly over time) C.  That's another one of the reasons I 
recommended Qt.  The main reason being that the OP asked about portability.

> One reason I don't want a monolithic application is because it gives me the
> freedom to try different front-ends based on platform support for control
> libraries. I might have a web front-end using SVG, a local one with Qt, or
> perhaps something using Java for either.

Yup.   Keeping flexibility in the design is a good idea.

> I expect any control library will give me the common stuff like windows and
> radio buttons. It's the more esoteric stuff like oscopes, gauges, and knobs
> that I'm trying to nail down.

Ah.  Well, there are plenty of libraries out there.  I haven't looked, lately 
(like I said) at such widget sets, but I have seen (at least some of) them 
for Qt, too.

Thanks.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/936c7084/attachment.sig>

From alan at redhat.com  Tue Mar 28 16:11:18 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 11:11:18 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328155740.GC25098@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
Message-ID: <20060328161118.GA6597@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 10:57:40AM -0500, Eric S. Raymond wrote:
> Yes, I'd like to see an authoritative source for Alan's assertion.

US patent law would be a good start

> I did quite a bit of web research before making my statement.  If
> Fraunhofer has made claims on decoders, this fact is unknown (or not
> disclosed) by any of the major decoder implementors.

Patents don't work like trademarks. Unless permission is given if a patent
covers the right to use that feature in the USSA then the patent owner can
decide to enforce the patent whenver they like.  They might lose the ability
to get injunctions for it but given the curren use of patent law is to allow
small legal firms to steal from innovators and producers they normally just
want the cash.

So either you invalidate the patent or you get written documentation from
the patent owner giving you permission.

Alan



From cmadams at hiwaay.net  Tue Mar 28 16:13:47 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 28 Mar 2006 10:13:47 -0600
Subject: Fedora's way forward
In-Reply-To: <20060328155740.GC25098@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
Message-ID: <20060328161347.GH1241870@hiwaay.net>

Once upon a time, Eric S. Raymond <esr at thyrsus.com> said:
> I did quite a bit of web research before making my statement.  If
> Fraunhofer has made claims on decoders, this fact is unknown (or not
> disclosed) by any of the major decoder implementors.

20 seconds and Wikipedia found:

http://en.wikipedia.org/wiki/Mp3#Licensing_and_patent_issues

and

http://www.mp3licensing.com/royalty/index.html

Under "PC Software Applications":
  mp3 - Decoder - US $0.75 per unit or US $50000 - US $60000 one-time paid up

-- 
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 paul at cypherpunks.ca  Tue Mar 28 16:19:01 2006
From: paul at cypherpunks.ca (Paul Wouters)
Date: Tue, 28 Mar 2006 18:19:01 +0200 (CEST)
Subject: Fedora's way forward
In-Reply-To: <20060328161118.GA6597@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328161118.GA6597@devserv.devel.redhat.com>
Message-ID: <Pine.LNX.4.63.0603281817340.28178@tla.xelerance.com>

On Tue, 28 Mar 2006, Alan Cox wrote:

> So either you invalidate the patent or you get written documentation from
> the patent owner giving you permission.

Or you make sure the whole of DC is using your patent-violating device,
so that they will tell the Patent Office to review and reject the patent
you are violating :)

Paul



From esr at thyrsus.com  Tue Mar 28 16:32:15 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 11:32:15 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328105912.29cad8e0.seanlkml@sympatico.ca>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
Message-ID: <20060328163215.GA25428@thyrsus.com>

sean <seanlkml at sympatico.ca>:
> Well, Fraunhofer has this page:
> 
> http://www.iis.fraunhofer.de/amm/licensing/index.html
> 
> Which links to :
> 
> http://www.mp3licensing.com/
> 
> Which definitely shows royalty fees for decoders.

It does.  I stand corrected.  

The page says $50K one time flat fee for a decoder.  Is there any good
reason Red Hat shouldn't simply buy that license for some outfit with
a track record, like the lame developers?  MP3 problem solved,
relatively cheaply (e.g., less than half the annual cost ofjust one
additional full-time coder).

Yes, I know feeding patent parasites is unpleasant.  But we come back to
the central question here: do we want ideological purity at the expense of 
victory, or do we want actual victory so that *we* get to effectively set
the terms of software development in the future?

I know which side of that question *I* come down on...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From Lam at Lam.pl  Tue Mar 28 16:44:02 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Tue, 28 Mar 2006 18:44:02 +0200
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <1143564243.4097.35.camel@pensja.lam.pl>

Dnia 28-03-2006, wto o godzinie 11:32 -0500, Eric S. Raymond napisa?(a):
> The page says $50K one time flat fee for a decoder.  Is there any good
> reason Red Hat shouldn't simply buy that license for some outfit with
> a track record, like the lame developers?  MP3 problem solved,
IIRC, the license wouldn't allow free redistribution (which is the main
goal of Fedora). That way getting Fedora straight from Red Hat would be
legal, but making my own respins and giving away/selling wouldn't.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/f4b8cb2a/attachment.sig>

From dcantrell at redhat.com  Tue Mar 28 16:45:19 2006
From: dcantrell at redhat.com (David Cantrell)
Date: Tue, 28 Mar 2006 11:45:19 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <20060328164519.GA18879@mortise.boston.redhat.com>

Eric S. Raymond wrote:
> sean <seanlkml at sympatico.ca>:
> > Well, Fraunhofer has this page:
> > 
> > http://www.iis.fraunhofer.de/amm/licensing/index.html
> > 
> > Which links to :
> > 
> > http://www.mp3licensing.com/
> > 
> > Which definitely shows royalty fees for decoders.
> 
> It does.  I stand corrected.  
> 
> The page says $50K one time flat fee for a decoder.  Is there any good
> reason Red Hat shouldn't simply buy that license for some outfit with
> a track record, like the lame developers?  MP3 problem solved,
> relatively cheaply (e.g., less than half the annual cost ofjust one
> additional full-time coder).
> 
> Yes, I know feeding patent parasites is unpleasant.  But we come back to
> the central question here: do we want ideological purity at the expense of 
> victory, or do we want actual victory so that *we* get to effectively set
> the terms of software development in the future?
> 
> I know which side of that question *I* come down on...

Ease up on the asterisks...

IANAL, but I see the one time royalty fee as something that wouldn't
work for a project like lame or any other MP3 software project.  The fee
isn't even stated, they just give a range of $50K to $60K USD.  And it's
listed for PC software applications.  What does that mean?  Use their
software/library/sdk?  Could the project continue to release MP3
decoding and encoding code?  Does it mean link in an object file that
Fraunhoffer provides?  What happens if lame is incorporated in to a
Fedora-derived distribution that then runs on the iPod?

Dangerous grounds.

-- 
David Cantrell
Red Hat / Westford, MA



From jkeating at j2solutions.net  Tue Mar 28 16:45:06 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 08:45:06 -0800
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <1143564306.3752.60.camel@yoda.loki.me>

On Tue, 2006-03-28 at 11:32 -0500, Eric S. Raymond wrote:
> The page says $50K one time flat fee for a decoder.  Is there any good
> reason Red Hat shouldn't simply buy that license for some outfit with
> a track record, like the lame developers?  MP3 problem solved,
> relatively cheaply (e.g., less than half the annual cost ofjust one
> additional full-time coder).

That makes it distributable by lame, but not REdistributable by Fedora
and any Fedora derivitives.  Redistributable is the key.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/d5890f29/attachment.sig>

From casimiro.barreto at gmail.com  Tue Mar 28 16:53:37 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 28 Mar 2006 13:53:37 -0300
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <e99d27470603280502vd655b77ve9c3cb981f52d7c1@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<44291494.2070003@warmcat.com>	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>	<1143549705.4097.30.camel@pensja.lam.pl>
	<e99d27470603280502vd655b77ve9c3cb981f52d7c1@mail.gmail.com>
Message-ID: <44296A11.2090803@gmail.com>

Rudolf Kastl escreveu:
> (...)
>
>   
>> Think about it once again - I can't make my DVD player, nor my portable
>> MP3 player, nor my car MP3 player (and so on...) to play Ogg Vorbis. In
>> the same time I CAN make my Fedora to play and even encode MP3, WMA and
>> other formats.
>>     
>
> When i buy hardware i make sure that it does what i want. if it
> doesent i wont spend money on it. we can play through the "chicken and
> egg" problem over and over.. The only starting point i see is if users
> explicitely demand support for superior formats of those embedded
> devices you talk about or not buy it at all while letting the industry
> know, because then theres a business case... .
>
>
>   

    When I buy "hardware" (like DVD players, music players, screens, TVs
    and other commodity stuff, I look for _avaiability_ and _price_. A
    chinese MP3 player costs about 50 bucks (US$) in Brazil, but if I
    want a player that plays ogg and other formats it will cost much
    more. I'll have to look for it (spend my time). It will be virtually
    impossible to find a theora decoding video player (DVD). I'll have
    to trust that it will have maintenance (replaceable bateries for
    instance) and so on, so forth... To give you an idea, an iPod Nano
    is sold, in Brazil, at R$1149,00 (US$638).

> (...)
>
> Thats what i see completly different... you state above that its a
> "marketing issue" you arent completly wrong with that in my eyes...
> marketing in this case does nothing but educate the user in a wrong
> way though...
>
>   

    Unfortunatelly we live in a real world. In  a real world, a program
    can cost $0,99 if sells millions of copies or $1.000 if one or two
    is the case... Besides, I don't think  consumers are stupid or
    uneducated. They just want confort.  Industry supplies them with
    both confort and reasonable prices (sometimes not). But if addopting
    OGG is the case, them converters must be easily avaiable. GPL
    players must be easily avaiable and not only for Linux (most people
    - I mean 99,99%) uses M$. So someone must supply - at reasonable
    prices and confort - players, codecs and converters. Finally, music
    and video are, generally, intelectual property of someone and the
    form of encoding does not relly on wishfull thinking of programmers
    that want to educate the world. And as you are so carefull about
    "intelectual rights", many times, if the author does not release its
    work under "Creative Commons" or a similar license scheme, you
    cannot just convert from MP3 to OGG or from MP4 or WMV to AVI
    without explicit consent and rights payment and the assurance that
    the sound and video won't be altered by the conversion process. It
    is not an easy issue.

> Again i see parallels to politics... where the Marketing people (of
> the industry) and the Politicians try to tell us that we exist to
> "serve them" instead of vice versa most of above mentioned can really
> be happy that most people dont know better.
>
> The question there in my eyes is rhetorical: "Who is the customer?" or
> rather "Where do you (as producer) get your money from in the end?".
>   

    I agree, so we must start to demand that our preferred artists
    unsign from record companies and start to issue their works under
    Creative Commons and that their work must be supplied using free
    sites like SoundClick, PureVolume, 15megsoffame in both MP3 and OGG
    formats... In my point of view, its an easy way of gettin killed or
    sent an institution for the mentally disabled...


> Change does only happen with enough demand... so lets start demanding :)
>
> regards,
> Rudolf Kastl
>
>   
>> Lam
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2.2 (GNU/Linux)
>>
>> iD8DBQBEKS8JGU+CzS/wSzYRAsteAJ4zik1QJ0UnvP6eRQPXgaXDNxbyeACgpIEL
>> vxKD9o/CbaUU5z3863S+T3g=
>> =nDNa
>> -----END PGP SIGNATURE-----
>>
>>
>> --
>> 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/20060328/18351d30/attachment.htm>

From fedora at adslpipe.co.uk  Tue Mar 28 16:49:09 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Tue, 28 Mar 2006 17:49:09 +0100
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com><20060328104659.GI12588@devserv.devel.redhat.com><604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com><20060328155740.GC25098@thyrsus.com><20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <44296905.70900@adslpipe.co.uk>

Eric S. Raymond wrote:

> The page says $50K one time flat fee for a decoder.

And an ?15K minimum annual royalty? Presumably they won't allow  source 
distribution, Fedora/RedHat might just as well point people to Fluendo's 
paid up binary only MP3 plugin https://shop.fluendo.com/




From esr at thyrsus.com  Tue Mar 28 16:50:05 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 11:50:05 -0500
Subject: Fedora's way forward
In-Reply-To: <1143564306.3752.60.camel@yoda.loki.me>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
Message-ID: <20060328165005.GB25693@thyrsus.com>

Jesse Keating <jkeating at j2solutions.net>:
> That makes it distributable by lame, but not REdistributable by Fedora
> and any Fedora derivitives.  Redistributable is the key.

Nah, this part's easy.  Lame brings up a yum repository, with mirrors, 
all legal and proper.  Fedora carries it in the stock yum.repos.d files.  
Post-installation instructions say "push this button to collect MP3
support".
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Tue Mar 28 16:52:13 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 11:52:13 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328164519.GA18879@mortise.boston.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
Message-ID: <20060328165213.GC25693@thyrsus.com>

David Cantrell <dcantrell at redhat.com>:
> IANAL, but I see the one time royalty fee as something that wouldn't
> work for a project like lame or any other MP3 software project.  The fee
> isn't even stated, they just give a range of $50K to $60K USD.  And it's
> listed for PC software applications.  What does that mean?  Use their
> software/library/sdk?  Could the project continue to release MP3
> decoding and encoding code?  Does it mean link in an object file that
> Fraunhoffer provides?  What happens if lame is incorporated in to a
> Fedora-derived distribution that then runs on the iPod?
> 
> Dangerous grounds.

Maybe.  But suppose we actually asked these questions rather than simply
speculating? 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Tue Mar 28 16:54:43 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 11:54:43 -0500
Subject: Fedora's way forward
In-Reply-To: <44296905.70900@adslpipe.co.uk>
References: <20060328163215.GA25428@thyrsus.com>
	<44296905.70900@adslpipe.co.uk>
Message-ID: <20060328165443.GD25693@thyrsus.com>

Andy Burns <fedora at adslpipe.co.uk>:
> Eric S. Raymond wrote:
> 
> >The page says $50K one time flat fee for a decoder.
> 
> And an ?15K minimum annual royalty?

I don't see that.

>                      Presumably they won't allow  source 
> distribution, Fedora/RedHat might just as well point people to Fluendo's 
> paid up binary only MP3 plugin https://shop.fluendo.com/

No, there's a crucial distinction.  Consumers think they should get this 
capability bundled with their OS, not have to pay extra after the sale.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From camilo at mesias.co.uk  Tue Mar 28 16:56:19 2006
From: camilo at mesias.co.uk (Cam)
Date: Tue, 28 Mar 2006 17:56:19 +0100
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<20060328104659.GI12588@devserv.devel.redhat.com>	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>	<20060328155740.GC25098@thyrsus.com>	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <44296AB3.50806@mesias.co.uk>

Eric

> Yes, I know feeding patent parasites is unpleasant.  But we come back to
> the central question here: do we want ideological purity at the expense of 
> victory, or do we want actual victory so that *we* get to effectively set
> the terms of software development in the future?
> 
> I know which side of that question *I* come down on...

It's a hollow and short lived victory if your payment ends up funding 
lawsuits against other open source software providers. Or if you set a 
precedent which pressures others to pay up too.

Really, given Fedora's stance on non-free software I'm not sure what 
you're trying to achieve here. If anyone thinks that buying a license 
for lame is the way forward, let them pass their hat around; I doubt it 
will be a fedora.

-Cam

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



From seanlkml at sympatico.ca  Tue Mar 28 16:54:08 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 11:54:08 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <BAYC1-PASMTP097DFBEC611D40C41EA04CAED30@CEZ.ICE>

On Tue, 28 Mar 2006 11:32:15 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> The page says $50K one time flat fee for a decoder.  Is there any good
> reason Red Hat shouldn't simply buy that license for some outfit with
> a track record, like the lame developers?  MP3 problem solved,
> relatively cheaply (e.g., less than half the annual cost ofjust one
> additional full-time coder).
> 
> Yes, I know feeding patent parasites is unpleasant.  But we come back to
> the central question here: do we want ideological purity at the expense of 
> victory, or do we want actual victory so that *we* get to effectively set
> the terms of software development in the future?
> 
> I know which side of that question *I* come down on...

Well if you believe Wikipedia, the patents expire in 2010 so if we 
can just keep this debate up for four years or so....

BTW, Wikipedia also says:

"Additionally, patent holders declined to enforce license fees on 
open source decoders, allowing many free MP3 decoders to develop."

But gives no references and i've been unable to find any myself.

Sean



From jkeating at j2solutions.net  Tue Mar 28 17:00:40 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 09:00:40 -0800
Subject: Fedora's way forward
In-Reply-To: <20060328165005.GB25693@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
Message-ID: <1143565240.3752.67.camel@yoda.loki.me>

On Tue, 2006-03-28 at 11:50 -0500, Eric S. Raymond wrote:
> Nah, this part's easy.  Lame brings up a yum repository, with mirrors, 
> all legal and proper.  Fedora carries it in the stock yum.repos.d files.  
> Post-installation instructions say "push this button to collect MP3
> support".

Ah, but then it isn't IN Fedora at all.  Fedora is just configured to be
able to obtain it.  Something different.  Fluendo has a distributable
mp3 plugin for gstreamer, however you do have to register for it, so no
pointing yum at it.  I can't say whether or not registration is part in
parcel w/ the paid license to distribute mp3 decoders, but if so, no
automated installations will be possible w/out the interaction of
registering.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/bfc975e4/attachment.sig>

From jdesbonnet at gmail.com  Tue Mar 28 17:00:53 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 28 Mar 2006 18:00:53 +0100
Subject: Fedora's way forward
In-Reply-To: <20060328165443.GD25693@thyrsus.com>
References: <20060328163215.GA25428@thyrsus.com>
	<44296905.70900@adslpipe.co.uk> <20060328165443.GD25693@thyrsus.com>
Message-ID: <1cef3e950603280900l639a35f1p47658dadab00ea1@mail.gmail.com>

Have Redhat lawyers approached Fraunhofer about this? I can't see any
financial down side for them -- it would be another licence sale.

On 3/28/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> Andy Burns <fedora at adslpipe.co.uk>:
> > Eric S. Raymond wrote:
> >
> > >The page says $50K one time flat fee for a decoder.
> >
> > And an ?15K minimum annual royalty?
>
> I don't see that.
>
> >                      Presumably they won't allow  source
> > distribution, Fedora/RedHat might just as well point people to Fluendo's
> > paid up binary only MP3 plugin https://shop.fluendo.com/
>
> No, there's a crucial distinction.  Consumers think they should get this
> capability bundled with their OS, not have to pay extra after the sale.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From dcantrell at redhat.com  Tue Mar 28 17:03:30 2006
From: dcantrell at redhat.com (David Cantrell)
Date: Tue, 28 Mar 2006 12:03:30 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328165213.GC25693@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
Message-ID: <20060328170330.GB18879@mortise.boston.redhat.com>

Eric S. Raymond wrote:
> David Cantrell <dcantrell at redhat.com>:
> > IANAL, but I see the one time royalty fee as something that wouldn't
> > work for a project like lame or any other MP3 software project.  The fee
> > isn't even stated, they just give a range of $50K to $60K USD.  And it's
> > listed for PC software applications.  What does that mean?  Use their
> > software/library/sdk?  Could the project continue to release MP3
> > decoding and encoding code?  Does it mean link in an object file that
> > Fraunhoffer provides?  What happens if lame is incorporated in to a
> > Fedora-derived distribution that then runs on the iPod?
> > 
> > Dangerous grounds.
> 
> Maybe.  But suppose we actually asked these questions rather than simply
> speculating? 

Because the software would still be in opposition to the goals of the
Fedora Project.  MP3 support isn't just on the ForbiddenItems list to
annoy people.  Like many others have stated, the project aims to produce
a free and open source Linux distribution that is redistributable by
all.  Having a paid-up royalty for a proprietary technology just so we
can include it in the distribution defeats the main goal.

-- 
David Cantrell
Red Hat / Westford, MA



From jspaleta at gmail.com  Tue Mar 28 17:06:10 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 12:06:10 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <604aa7910603280906x4aa2458fge8db8526122e8c3@mail.gmail.com>

On 3/28/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> The page says $50K one time flat fee for a decoder.
Is that for the codebase or per distributor of binaries?

Considering that
http://www.mp3licensing.com/royalty/software.html
delibrately states that you need to pay royalities even if you
licensed the the code from a third-party, I do not believe the "paid
up" option would cover everyone using the codebase from a single open
source project as you would suggest it would. In fact it seems to me
the royalty is meant to be paid per distributing entity of the binary
format. Feel free to contact the licensing entity which controls the
patent royalty licensing terms and clear that up. What exactly is
"paid up"? If the lame project "paid up" would anyone be allowed to
re-distribute binaries using the lame project source code without
paying additional royalties? Would people be allowed to make modified
versions of lame source code and redistribute binaries based on that
modified source without having to pay additional royalties?

Exactly what is covered by the "paid up" language could even impact
the ability of 3rd party vendors who create verbatim copies of the
fedora installation media and update packages.. if the patent holder
determines that someone like cheapbytes counts a new distributing
entity. For all we know the "paid up" terms cover only public
distribution from locations controled by the "paid up" entity. Without
specific language covering the terms which outline "paid up" status,
parsed by a lawyer, we can't even assume that public mirrors on
servers outside the control of Red Hat could carry this material.

I think you have read too much into the phrase "paid up" and have
given the patent holder too much benefit of the doubt as to their
intent with that phrase. We should all  refrain from making too many
assumptions that support our specific goals with regard to being able
to provide as much mp3 decoding support as is reasonable.

Since you seem to think there are yet to be discovered options in this
area for the community to "pay up" for a codebase, please contact the
patent holds for more information regarding the specific terms and
conditions detailing "paid up" status... especially with regard to
conditions as to coverage afforded to third parties who of
redistribute source code, binaries and modifications of both. I look
forward to your detailed analysis as to what options that we as
upstanding members of the foss community have after you have had a
chance to contact the appropriate patent holds and have reviewed the
specific terms and conditions of the "paid up" licensing option.


-jef



From shiva at sewingwitch.com  Tue Mar 28 17:10:01 2006
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 28 Mar 2006 09:10:01 -0800
Subject: GUI controls for instrumentation
In-Reply-To: <200603280906.21172.lamont@gurulabs.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603280103.40598.lamont@gurulabs.com>
	<A5FD712AD9D181D45F2D61FB@[10.0.0.14]>
	<200603280906.21172.lamont@gurulabs.com>
Message-ID: <A320B67AF9DD7C63D43130F9@[10.0.0.14]>

--On Tuesday, March 28, 2006 9:06 AM -0700 "Lamont R. Peterson" 
<lamont at gurulabs.com> wrote:

> No, I don't make that assumption, though I see why it would appear that
> way.   Thanks for catching it.

Sorry for misreading you.

> However, most times I have seen Instrumentation apps, they are coded in
> one  language plus an embedded scripting language is included for
> automating or  "linking" of controls, inputs & outputs.  At least, that's
> the way the  commercial toolkits usually did things.

I've been thinking about incorporating either Perl or Tcl as my scripting 
language. Any other choices I should consider?

> Yes.  That was part of what I was thinking/trying to say.  Most such
> libraries  are C++ or (less commonly over time) C.  That's another one of
> the reasons I  recommended Qt.  The main reason being that the OP asked
> about portability.

That was me. ;)

> Ah.  Well, there are plenty of libraries out there.  I haven't looked,
> lately  (like I said) at such widget sets, but I have seen (at least some
> of) them  for Qt, too.

Yep, that's what I'm really looking for, what goes on top of the more 
generic stuff. I know of NI's Measurement Studio but want to explore 
alternatives. Source access is very important to me. With commercial stuff, 
that means I can continue to maintain it if the vendor goes belly-up or 
discontinues the product.

Qt does look like a good foundation. Has anyone here experience with 
wxWidgets? I looked into it a few years ago and it used the "sizer" meme 
for window control placement, which I prefer to the fixed placement of the 
Windows-based tools I've seen. At the time I looked at it, it had a basic 
dialog editor that understood sizers, and a commercial dialog editor was 
available.



From fedora at adslpipe.co.uk  Tue Mar 28 17:11:40 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Tue, 28 Mar 2006 18:11:40 +0100
Subject: Fedora's way forward
In-Reply-To: <20060328165443.GD25693@thyrsus.com>
References: <20060328163215.GA25428@thyrsus.com>
	<44296905.70900@adslpipe.co.uk>
	<20060328165443.GD25693@thyrsus.com>
Message-ID: <44296E4C.5030808@adslpipe.co.uk>

Eric S. Raymond wrote:

> I don't see that.

At the bottom of http://www.mp3licensing.com/royalty/software.html
it's not clear if the minimum royalty is only applicable when paying 
"per unit" or not.

> No, there's a crucial distinction.  Consumers think they should get this 
> capability bundled with their OS, not have to pay extra after the sale.

But the price from Fluendo's shop is ?0.00 per plugin, ithough t would 
be better if it were able to be distributed as part of the O/S



From tromey at redhat.com  Tue Mar 28 17:05:58 2006
From: tromey at redhat.com (Tom Tromey)
Date: 28 Mar 2006 10:05:58 -0700
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <m3wteev6rt.fsf@localhost.localdomain>

>>>>> "Eric" == Eric S Raymond <esr at thyrsus.com> writes:

Eric> But the art problem pales compared to the issue that everyone has been
Eric> ducking, which is Fedora's support for DVDs and proprietary audio and
Eric> video and web-streaming formats and Java applets.

We're hard at work solving the applet problem.

Things are looking good on the library (GNU Classpath) front this
year, we've got gcjwebplugin, and we're working on the security
infrastructure in libgcj.  The latter in particular is a pretty big
job, but important -- I wouldn't consider shipping gcjwebplugin
without it.

Tom



From nicolas.mailhot at laposte.net  Tue Mar 28 17:12:57 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Mar 2006 19:12:57 +0200
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060328040953.17819ad1.seanlkml@sympatico.ca>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
Message-ID: <1143565978.2523.3.camel@rousalka.dyndns.org>

Le mardi 28 mars 2006 ? 04:09 -0500, sean a ?crit :

> As for XML, with a proper API there's no reason to worry much about the 
> format of the configuration data files.   The applications would never
> look directly inside any config file anyway. 

That's what gconf authors obviously thought and look where it got them.
Thinking about file format may be a PITA, but if you skim on it you
won't ever have widespread adoption.

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

From esr at thyrsus.com  Tue Mar 28 17:15:50 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 12:15:50 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328115408.59006c8e.seanlkml@sympatico.ca>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328115408.59006c8e.seanlkml@sympatico.ca>
Message-ID: <20060328171550.GA26011@thyrsus.com>

sean <seanlkml at sympatico.ca>:
> "Additionally, patent holders declined to enforce license fees on 
> open source decoders, allowing many free MP3 decoders to develop."

Yes, that's one of the statements I *did* find.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Tue Mar 28 17:17:33 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 12:17:33 -0500
Subject: Fedora's way forward
In-Reply-To: <1143565240.3752.67.camel@yoda.loki.me>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<1143565240.3752.67.camel@yoda.loki.me>
Message-ID: <20060328171733.GB26011@thyrsus.com>

Jesse Keating <jkeating at j2solutions.net>:
> On Tue, 2006-03-28 at 11:50 -0500, Eric S. Raymond wrote:
> > Nah, this part's easy.  Lame brings up a yum repository, with mirrors, 
> > all legal and proper.  Fedora carries it in the stock yum.repos.d files.  
> > Post-installation instructions say "push this button to collect MP3
> > support".
> 
> Ah, but then it isn't IN Fedora at all.  Fedora is just configured to be
> able to obtain it.  Something different.

Yes.  This is where yum helps us win big.  The consumer doesn't care
if his overhead is as low as pushing a button.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From casimiro.barreto at gmail.com  Tue Mar 28 17:22:43 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Tue, 28 Mar 2006 14:22:43 -0300
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <20060328131958.GD1241870@hiwaay.net>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<44291494.2070003@warmcat.com>
	<4429327A.2060401@gmail.com> <20060328131958.GD1241870@hiwaay.net>
Message-ID: <442970E3.9040307@gmail.com>


    I got your point, Fedora is a "teaser" and RHEL is the "real thing",
    so purchase RHEL. If you test enought in Fedora and find a feature
    that is "cool", hey don't forget to tell us, so it can be
    incorporated in the next RHEL...

    But the final quote is magnificent... M$ and Mr. Gates would love
    it... for the embeded idea that, in Linux community, UPGRADE/UPDATE
    is not really an improvement and addiction of qualities and
    functionalities but may also imply in killing/changing functionality
    without asking the user if he/she agrees or not with it. And it is
    real easy to get lost... just what you have to do is a yum update.
    And the programs that used to work no more will behave the same
    way... very basic things like character encoding in PHP and so on
    and so forth...

    BTW, FHEL does not sell well in Brazil. Know why? Don't??? So send
    an idependent audit company to try to understand the situation... To
    see what the representatives do. You'll find resellers installing
    pirate copies in customers servers and practices like that. Support
    nears zero, sometimes you have to be the "teacher" and is $$$$$ and
    you are treated with the same f_ck_g adjective you used in the last
    paragraph.

Casimiro

Chris Adams escreveu:
> Once upon a time, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> said:
>   
>>  (...)
>> In software market everything is gray zone. You issue MySql and AFAIK it 
>> is not really "open source", but them you stripe it (so RHEL can have 
>> the full flavour and the others don't).
>>     
>
> Wrong.  MySQL is released under the GPL (that's about as Open Source as
> you can get).
>
>   
Wrong. Parts of MySQL are GPL and parts are not. From the MySQL site you 
can download everything, but it is really trick to compile to fit what 
is included in Fedora distribution. PHP is distributed from Zend 
Corporation and I really haven't seen if it is or is not GPL, but they 
distribute it from free out of their site. But again, if I want to use 
it I have to do a lot of tricks to have it running properly under Fedora.
>> Result: I upgraded a server in 20 minutes and everything stoped 
>> to work... that meant 20+ hours of straight work of coding and recoding 
>> (man, I had to code calendar months and other stupid things) to have the 
>> basics running back.
>>     
>
> What kind of idiot upgrades a production server without any testing in
> advance?
>   
The kind of idiot that follows Fedora's site instructions and do a yum 
update...


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

From esr at thyrsus.com  Tue Mar 28 17:19:09 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 12:19:09 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328170330.GB18879@mortise.boston.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
Message-ID: <20060328171909.GC26011@thyrsus.com>

David Cantrell <dcantrell at redhat.com>:
> Because the software would still be in opposition to the goals of the
> Fedora Project.  MP3 support isn't just on the ForbiddenItems list to
> annoy people.  Like many others have stated, the project aims to produce
> a free and open source Linux distribution that is redistributable by
> all.  Having a paid-up royalty for a proprietary technology just so we
> can include it in the distribution defeats the main goal.

See my suggestion about a pointer to a (hypothetical) lame-hosted yum 
repository.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Tue Mar 28 17:20:07 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 12:20:07 -0500
Subject: Fedora's way forward
In-Reply-To: <604aa7910603280906x4aa2458fge8db8526122e8c3@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<604aa7910603280906x4aa2458fge8db8526122e8c3@mail.gmail.com>
Message-ID: <20060328172007.GD26011@thyrsus.com>

Jeff Spaleta <jspaleta at gmail.com>:
> Since you seem to think there are yet to be discovered options in this
> area for the community to "pay up" for a codebase, please contact the
> patent holds for more information regarding the specific terms and
> conditions detailing "paid up" status... especially with regard to
> conditions as to coverage afforded to third parties who of
> redistribute source code, binaries and modifications of both. I look
> forward to your detailed analysis as to what options that we as
> upstanding members of the foss community have after you have had a
> chance to contact the appropriate patent holds and have reviewed the
> specific terms and conditions of the "paid up" licensing option.

I'd be willing.  But this really needs to be done by a lawyer.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Tue Mar 28 17:21:14 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 12:21:14 -0500
Subject: Fedora's way forward
In-Reply-To: <m3wteev6rt.fsf@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<m3wteev6rt.fsf@localhost.localdomain>
Message-ID: <20060328172114.GE26011@thyrsus.com>

Tom Tromey <tromey at redhat.com>:
> We're hard at work solving the applet problem.

That's good news, thanks.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From sundaram at fedoraproject.org  Tue Mar 28 17:23:05 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 28 Mar 2006 22:53:05 +0530
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <442970E3.9040307@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com> <4429327A.2060401@gmail.com>
	<20060328131958.GD1241870@hiwaay.net>  <442970E3.9040307@gmail.com>
Message-ID: <1143566586.3802.563.camel@sundaram.pnq.redhat.com>

On Tue, 2006-03-28 at 14:22 -0300, Casimiro de Almeida Barreto wrote:

[kindly avoid top posting]


> 
> 
> Chris Adams escreveu: 
> > Once upon a time, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> said:
> >   
> > >  (...)
> > > In software market everything is gray zone. You issue MySql and AFAIK it 
> > > is not really "open source", but them you stripe it (so RHEL can have 
> > > the full flavour and the others don't).
> > >     
> > 
> > Wrong.  MySQL is released under the GPL (that's about as Open Source as
> > you can get).
> > 
> >   
> Wrong. Parts of MySQL are GPL and parts are not.

Are you claiming that Fedora is distributing proprietary parts of MySQL
if any. If not this discussion is moot.


> > What kind of idiot upgrades a production server without any testing in
> > advance?
> >   
> The kind of idiot that follows Fedora's site instructions and do a yum
> update...
> 

Can you show me that link? We dont advise doing an yum update to upgrade
a distribution anywhere as far as I know.


Rahul




From seanlkml at sympatico.ca  Tue Mar 28 17:30:43 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 12:30:43 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143565978.2523.3.camel@rousalka.dyndns.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<BAYC1-PASMTP08C71BEC30C48235EEB824AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
Message-ID: <BAYC1-PASMTP020174B730F2C9B1ED23F1AED30@CEZ.ICE>

On Tue, 28 Mar 2006 19:12:57 +0200
Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

> Le mardi 28 mars 2006 ? 04:09 -0500, sean a ?crit :
> 
> > As for XML, with a proper API there's no reason to worry much about the 
> > format of the configuration data files.   The applications would never
> > look directly inside any config file anyway. 
> 
> That's what gconf authors obviously thought and look where it got them.
> Thinking about file format may be a PITA, but if you skim on it you
> won't ever have widespread adoption.
> 

gconf isn't limited because of its file format.   It's limited because
it's tied so closely to the Gnome WM.   Really, once you have a standard
API the backend file format doesn't matter anymore.   In fact it gives
you a lot of flexibility, you can store the data in a SQL server, or in
XML, or in flat files and every application can use it transparently.

This also provides a very nice transition path because you can make
a backend that handles the current config file format which should
ease transition.   

In fact this is the very path that the Elektra developers took.  You 
can write a portable app that works with the Windows registry, Gnome
gconf, or flat files all without recompiling your app. 

Really, the format of the file doesn't matter, the API is what matters.
It gives you great flexibility to change the format to suit your needs.

Sean



From seg at haxxed.com  Tue Mar 28 17:42:39 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Mar 2006 11:42:39 -0600
Subject: Fedora's way forward
In-Reply-To: <20060328165005.GB25693@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
Message-ID: <1143567760.10632.33.camel@localhost>

On Tue, 2006-03-28 at 11:50 -0500, Eric S. Raymond wrote:
> Jesse Keating <jkeating at j2solutions.net>:
> > That makes it distributable by lame, but not REdistributable by Fedora
> > and any Fedora derivitives.  Redistributable is the key.
> 
> Nah, this part's easy.  Lame brings up a yum repository, with mirrors, 
> all legal and proper.  Fedora carries it in the stock yum.repos.d files.  
> Post-installation instructions say "push this button to collect MP3
> support".

Isn't this exactly what Livna is for? (Except for the shipping in the
distribution part...)

Perhaps Livna should have some kind of "Make everything work"
meta-package. Include the macromedia repo in its release package too.

I've had good success telling people in #fedora how to get nvidia's
drivers with just two commands. Its simply not that hard. The problem is
education. And of course Red Hat forbids itself from even mentioning
Livna...

(I see http://home.gagme.com/greg/linux/fc5-tips.php handles this pretty
well. Something like this should be on Livna's site, and be the top hit
for "Fedora MP3 DVD AVI playback"...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/de20d7bb/attachment.sig>

From jkeating at j2solutions.net  Tue Mar 28 17:41:44 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 09:41:44 -0800
Subject: Fedora's way forward
In-Reply-To: <20060328171909.GC26011@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
Message-ID: <1143567704.3752.79.camel@yoda.loki.me>

On Tue, 2006-03-28 at 12:19 -0500, Eric S. Raymond wrote:
> See my suggestion about a pointer to a (hypothetical) lame-hosted yum 
> repository.

This doesn't change the fact that mp3 technology isn't free by the terms
of Fedora.  We don't want to promote its use.  We promote the use of ogg
and other FREE encodings.  This is our stand.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/fda198fb/attachment.sig>

From jkeating at j2solutions.net  Tue Mar 28 17:43:55 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 09:43:55 -0800
Subject: Fedora's way forward
In-Reply-To: <1143567760.10632.33.camel@localhost>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<1143567760.10632.33.camel@localhost>
Message-ID: <1143567835.3752.82.camel@yoda.loki.me>

On Tue, 2006-03-28 at 11:42 -0600, Callum Lerwick wrote:
> Isn't this exactly what Livna is for? (Except for the shipping in the
> distribution part...)
> 
> Perhaps Livna should have some kind of "Make everything work"
> meta-package. Include the macromedia repo in its release package too.
> 
> I've had good success telling people in #fedora how to get nvidia's
> drivers with just two commands. Its simply not that hard. The problem is
> education. And of course Red Hat forbids itself from even mentioning
> Livna...

Livna provides things which are legal in the country that Livna resides
in.  If it is illegal in the country that Livna exists in, Livna will
not ship it.  So the entire 'make it work' stack may not be hostable by
Livna.

Fedora by design wants to make it work using FOSS, free and opensource
software.  Anything beyond that is beyond the stated goals of the Fedora
Project.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/5c65209d/attachment.sig>

From nicolas.mailhot at laposte.net  Tue Mar 28 17:48:22 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Mar 2006 19:48:22 +0200
Subject: Fedora's way forward
In-Reply-To: <1143542096.23433.53.camel@mrwibble.mrwobble>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143542096.23433.53.camel@mrwibble.mrwobble>
Message-ID: <1143568103.2523.7.camel@rousalka.dyndns.org>

Le mardi 28 mars 2006 ? 11:34 +0100, Paul F. Johnson a ?crit :
> Hi,
> 
> > Let me start with some good things.  I thought Fedora was in
> > desperately bad shape in the FC3/FC4 period, 
> 
> FC3 wasn't *that* bad IMHO. FC4 was a bit on the disappointing side.
> 
> > First, a relatively minor issue that is nevertheless quite annoying.
> > It's the Fedora distribution art
> 
> This, and fonts, are the two areas where just about every Linux distro
> falls behind Mac and Windows boxes as both companies invested a massive
> amount to get professional font and graphics people to generate the
> graphics for them and unfortunately, it seems eye candy is everything.

Amazingly the font situation got much better in the last year thanks to
all the Vera forks and in particular dejavu.

To the point the pango people have complained recently the dejavu team
draws too many glyphs, and the infrastructure is not able to display
them sanely (hint add BASE OpenType support to fontforge and
freetype/fontconfig/pango/whatever)

Regards,

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

From tibbs at math.uh.edu  Tue Mar 28 17:55:59 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Tue, 28 Mar 2006 11:55:59 -0600
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <20060327182323.GB16210@redhat.com> (Dave Jones's message of
	"Mon, 27 Mar 2006 13:23:23 -0500")
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060324202627.GD2725@redhat.com>
	<ufapsk8h41m.fsf@epithumia.math.uh.edu>
	<20060327182323.GB16210@redhat.com>
Message-ID: <ufaodzqe9n4.fsf@epithumia.math.uh.edu>

Just FYI, the exact error message when booting the shipping FC5 i686
SMP kernel is:

Unknown interrupt or fault at EIP 00000060 c0100295 00000294

this repeats quickly for a few seconds, at which point the machine
reboots.  I can tell that there is some short message displayed before
this, but I can't see it.

I will open a bugzilla ticket.

 - J<



From alan at redhat.com  Tue Mar 28 17:56:08 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 12:56:08 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328163215.GA25428@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
Message-ID: <20060328175608.GA24725@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 11:32:15AM -0500, Eric S. Raymond wrote:
> The page says $50K one time flat fee for a decoder.  Is there any good
> reason Red Hat shouldn't simply buy that license for some outfit with
> a track record, like the lame developers?  MP3 problem solved,
> relatively cheaply (e.g., less than half the annual cost ofjust one
> additional full-time coder).

Because that license only covers a single seller of decoders selling a single
product in a proprietary manner. The GPL sensibly prohibits such sellouts. The
price they want for an 'all GPL use' license will probably be a little bit
higher probably hundreds of times higher

> the central question here: do we want ideological purity at the expense of 
> victory, or do we want actual victory so that *we* get to effectively set
> the terms of software development in the future?

Learn from history Eric. Unless you are careful to keep your beliefs and
ethics intact you become what you fight, whether its the USA versus the USSR
or free software versus proprietary.

Alan



From cmadams at hiwaay.net  Tue Mar 28 17:58:28 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 28 Mar 2006 11:58:28 -0600
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <442970E3.9040307@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com> <4429327A.2060401@gmail.com>
	<20060328131958.GD1241870@hiwaay.net> <442970E3.9040307@gmail.com>
Message-ID: <20060328175827.GB1421034@hiwaay.net>

Once upon a time, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> said:
>    I got your point, Fedora is a "teaser" and RHEL is the "real thing",
>    so purchase RHEL. If you test enought in Fedora and find a feature
>    that is "cool", hey don't forget to tell us, so it can be
>    incorporated in the next RHEL...

No, my point was that since RHEL is a commercial distribution, they can
include things that a freely redistributable distribution like Fedora
cannot.  You can compare RHEL to Fedora, SUSE to Debain, etc. and the
comparison still stands.

>    But the final quote is magnificent... M$ and Mr. Gates would love
>    it... for the embeded idea that, in Linux community, UPGRADE/UPDATE
>    is not really an improvement and addiction of qualities and
>    functionalities but may also imply in killing/changing functionality
>    without asking the user if he/she agrees or not with it. And it is
>    real easy to get lost... just what you have to do is a yum update.
>    And the programs that used to work no more will behave the same
>    way... very basic things like character encoding in PHP and so on
>    and so forth...

Read a Microsoft book and you'll see the same sentiment.  You do not
upgrade production servers from one major release to another (which is
more than just "yum update") without prior testing.  Sure, people do it,
and when they get bit by it, they hopefully learn an important lesson.
Microsoft OS resource kits typically have large sections on how to roll
out version upgrades, telling you what might break and how to handle it.

> Wrong. Parts of MySQL are GPL and parts are not.

Wrong.  MySQL is released under the GPL.  MySQL _also_ offers the same
code under a non-GPL license for closed source development (which they
can do since they own the code).  There is also a license exception for
the client libraries that allows Open Source software under certain
non-GPL compatible licenses to link against the MySQL libraries.

> From the MySQL site you 
> can download everything, but it is really trick to compile to fit what 
> is included in Fedora distribution.

Not really, read the Fedora spec file and you can see exactly how to
download bits and build it how Fedora builds it.

> PHP is distributed from Zend 
> Corporation and I really haven't seen if it is or is not GPL, but they 
> distribute it from free out of their site.

PHP is under a different license; see /usr/share/doc/php-[45]*/LICENSE.
It is an Open Source license however.

> The kind of idiot that follows Fedora's site instructions and do a yum 
> update...

"yum update" does not upgrade a system from one major release to
another.

When I plan to upgrade a production system from one version to another,
I test my upgrade path first (and have backout plans ready, also
pre-tested).  It doesn't matter if the server is running Linux, Solaris,
Windows, or anything else.

-- 
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 esr at thyrsus.com  Tue Mar 28 17:58:22 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 12:58:22 -0500
Subject: Fedora's way forward
In-Reply-To: <1143567704.3752.79.camel@yoda.loki.me>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
Message-ID: <20060328175822.GA26482@thyrsus.com>

Jesse Keating <jkeating at j2solutions.net>:
> This doesn't change the fact that mp3 technology isn't free by the terms
> of Fedora.  We don't want to promote its use.  We promote the use of ogg
> and other FREE encodings.  This is our stand.

So promote them already.  Promote the hell out of them. I'll help;
in fact, I already have.

But don't let the perfect be the enemy of the good.  If we don't meet what
people actually want to do with their computers, we'll lose.  And we'll
*deserve* to lose.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From alan at redhat.com  Tue Mar 28 18:00:10 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 13:00:10 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328165005.GB25693@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
Message-ID: <20060328180010.GB24725@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 11:50:05AM -0500, Eric S. Raymond wrote:
> all legal and proper.  Fedora carries it in the stock yum.repos.d files.  
> Post-installation instructions say "push this button to collect MP3
> support".

So if we carry one vendor how do we decide which of a thousand rival vendors
get into the default yum.conf.d and how do we then audit them. Shall we
sell icons on the desktop like a certain other vendor did ?

What will you pay to have the fetchmail yum repository in by default..?

See thats not the way to go for Fedora. It might be a brief, interesting, and
maybe profitable racket. With no non-free vendor in the default yum.conf
the problem doesn't occur. They can all compete freely using market forces
for your clicks and your money.

What would be useful (free or nonfree) is an xml/yum-repository type format
that could be hooked into firefox and friends so you can 

	"Click here to subscribe to fetchmail-pro"

etc



From esr at thyrsus.com  Tue Mar 28 18:01:06 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 13:01:06 -0500
Subject: Fedora's way forward
In-Reply-To: <1143567760.10632.33.camel@localhost>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<1143567760.10632.33.camel@localhost>
Message-ID: <20060328180106.GB26482@thyrsus.com>

Callum Lerwick <seg at haxxed.com>:
> On Tue, 2006-03-28 at 11:50 -0500, Eric S. Raymond wrote:
> > Jesse Keating <jkeating at j2solutions.net>:
> > > That makes it distributable by lame, but not REdistributable by Fedora
> > > and any Fedora derivitives.  Redistributable is the key.
> > 
> > Nah, this part's easy.  Lame brings up a yum repository, with mirrors, 
> > all legal and proper.  Fedora carries it in the stock yum.repos.d files.  
> > Post-installation instructions say "push this button to collect MP3
> > support".
> 
> Isn't this exactly what Livna is for? (Except for the shipping in the
> distribution part...)

Couldn't be livna; that's going to carry stuff we genuinely can't go near.

> Perhaps Livna should have some kind of "Make everything work"
> meta-package. Include the macromedia repo in its release package too.

See, now that's thinking along the right lines.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From alan at redhat.com  Tue Mar 28 18:05:31 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 13:05:31 -0500
Subject: GUI controls for instrumentation
In-Reply-To: <A320B67AF9DD7C63D43130F9@[10.0.0.14]>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603280103.40598.lamont@gurulabs.com>
	<A5FD712AD9D181D45F2D61FB@[10.0.0.14]>
	<200603280906.21172.lamont@gurulabs.com>
	<A320B67AF9DD7C63D43130F9@[10.0.0.14]>
Message-ID: <20060328180531.GD24725@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 09:10:01AM -0800, Kenneth Porter wrote:
> I've been thinking about incorporating either Perl or Tcl as my scripting 
> language. Any other choices I should consider?

Certainly python has some good bindings to gtk and kde. It's structured, its
very stable between versions and it looks like source code unlike perl. A lot
of the Fedora system config tools use python.



From seg at haxxed.com  Tue Mar 28 18:12:37 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Mar 2006 12:12:37 -0600
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143549705.4097.30.camel@pensja.lam.pl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<1143549705.4097.30.camel@pensja.lam.pl>
Message-ID: <1143569558.10632.41.camel@localhost>

On Tue, 2006-03-28 at 14:41 +0200, Leszek Matok wrote:
> Besides, I may be totally wrong, so please don't yell at me, but one of
> the reasons there are so many multimedia players lacking support for
> open formats may be the GPL licensing of decoders.

Tremor, a BSD licensed ogg vorbis reference decoder has been available
for some time. GPL licensing is not the problem. Besides, the goal of
Xiph is not source code, its free and open standards, so that anyone can
freely implement their own codecs under whatever license they want.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/b913a589/attachment.sig>

From jkeating at j2solutions.net  Tue Mar 28 18:06:35 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 10:06:35 -0800
Subject: Fedora's way forward
In-Reply-To: <20060328175822.GA26482@thyrsus.com>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com>
Message-ID: <1143569195.3752.100.camel@yoda.loki.me>

On Tue, 2006-03-28 at 12:58 -0500, Eric S. Raymond wrote:
> So promote them already.  Promote the hell out of them. I'll help;
> in fact, I already have.
> 
> But don't let the perfect be the enemy of the good.  If we don't meet what
> people actually want to do with their computers, we'll lose.  And we'll
> *deserve* to lose.

And if we don't take a stand, we lose.  And we'll deserve to lose.  We
can't promote a free solution while at the same time saying "ok, well
here is this if you don't REALLY want to use FOSS".  Users will take the
path of least resistance.  We're trying to make it so that FOSS is that
path, but if !FOSS becomes an easier path, thats where users will go,
and we've lost the battle.  I'm surprised that you of all people don't
see this.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/49356511/attachment.sig>

From seanlkml at sympatico.ca  Tue Mar 28 18:04:11 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 13:04:11 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328180010.GB24725@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<20060328180010.GB24725@devserv.devel.redhat.com>
Message-ID: <BAYC1-PASMTP0134AC7A9AB5004513F90CAED30@CEZ.ICE>

On Tue, 28 Mar 2006 13:00:10 -0500
Alan Cox <alan at redhat.com> wrote:

> On Tue, Mar 28, 2006 at 11:50:05AM -0500, Eric S. Raymond wrote:
> > all legal and proper.  Fedora carries it in the stock yum.repos.d files.  
> > Post-installation instructions say "push this button to collect MP3
> > support".
> 
> So if we carry one vendor how do we decide which of a thousand rival vendors
> get into the default yum.conf.d and how do we then audit them. Shall we
> sell icons on the desktop like a certain other vendor did ?
> 
> What will you pay to have the fetchmail yum repository in by default..?
> 
> See thats not the way to go for Fedora. It might be a brief, interesting, and
> maybe profitable racket. With no non-free vendor in the default yum.conf
> the problem doesn't occur. They can all compete freely using market forces
> for your clicks and your money.
> 
> What would be useful (free or nonfree) is an xml/yum-repository type format
> that could be hooked into firefox and friends so you can 
> 
> 	"Click here to subscribe to fetchmail-pro"
> 

Already possible.  Repository maintainer publishes a link on their 
website to a rpm that installs a repo file.   Click on the link,
click "Install RPM" when prompted and Bob's your uncle.

Sean



From nicolas.mailhot at laposte.net  Tue Mar 28 18:07:41 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 28 Mar 2006 20:07:41 +0200
Subject: Fedora's way forward
In-Reply-To: <20060328172007.GD26011@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<604aa7910603280906x4aa2458fge8db8526122e8c3@mail.gmail.com>
	<20060328172007.GD26011@thyrsus.com>
Message-ID: <1143569262.2523.18.camel@rousalka.dyndns.org>

Le mardi 28 mars 2006 ? 12:20 -0500, Eric S. Raymond a ?crit :
> Jeff Spaleta <jspaleta at gmail.com>:
> > Since you seem to think there are yet to be discovered options in this
> > area for the community to "pay up" for a codebase, please contact the
> > patent holds for more information regarding the specific terms and
> > conditions detailing "paid up" status... especially with regard to
> > conditions as to coverage afforded to third parties who of
> > redistribute source code, binaries and modifications of both. I look
> > forward to your detailed analysis as to what options that we as
> > upstanding members of the foss community have after you have had a
> > chance to contact the appropriate patent holds and have reviewed the
> > specific terms and conditions of the "paid up" licensing option.
> 
> I'd be willing.  But this really needs to be done by a lawyer.

You may like to know the fluendo people bought their own mp3 patent
license, and due to the license conditions :
1. they had to rewrite their own mp3 code, the major codebases being
GPLed which is not compatible with the patent licensing terms
2. you have to get the mp3 binary directly from them as the patent
license is to them only
3. the patent license covers one binary, they give you the code but if
you rebuild it the result is not allowed

I sure hope Red Hat spends their money in more productive areas

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

From alan at redhat.com  Tue Mar 28 18:08:38 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 13:08:38 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060328123043.3d40cdf3.seanlkml@sympatico.ca>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
Message-ID: <20060328180838.GE24725@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 12:30:43PM -0500, sean wrote:
> gconf isn't limited because of its file format.   It's limited because
> it's tied so closely to the Gnome WM.   Really, once you have a standard

Gconf doesn't need gnome. The reverse is true however. The XML format also lets
you work with prefences using styles and XML XSLT and the like which is very
powerful when working with a large number of systems. Really nobody has
scratched the surface of what it can do.

You don't have to care about the XML either, one of the crazier gconf demos
from a long time ago was an email interface to gconf settings



From alan at redhat.com  Tue Mar 28 18:13:39 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 13:13:39 -0500
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <ufaodzqe9n4.fsf@epithumia.math.uh.edu>
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060324202627.GD2725@redhat.com>
	<ufapsk8h41m.fsf@epithumia.math.uh.edu>
	<20060327182323.GB16210@redhat.com>
	<ufaodzqe9n4.fsf@epithumia.math.uh.edu>
Message-ID: <20060328181339.GF24725@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 11:55:59AM -0600, Jason L Tibbitts III wrote:
> Just FYI, the exact error message when booting the shipping FC5 i686
> SMP kernel is:
> 
> Unknown interrupt or fault at EIP 00000060 c0100295 00000294

The VIA C3 should use the i586 kernels. While the processor is an i686 
compatible the gcc people screwed up way back when and assumed "cmov" was
required for 686. Now as it turns out the only useful reason for having an
i686 architecture is (was now we have P4) "cmov" so the slightly 
differing "686" meaning persists.

The installer should have chosen a 586 kernel and apps however unless you have
a later Nemeiah variant which has full CMOV




From andy at warmcat.com  Tue Mar 28 18:15:56 2006
From: andy at warmcat.com (Andy Green)
Date: Tue, 28 Mar 2006 19:15:56 +0100
Subject: Fedora's way forward
In-Reply-To: <20060328175822.GA26482@thyrsus.com>
References: <20060328104659.GI12588@devserv.devel.redhat.com>	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>	<20060328155740.GC25098@thyrsus.com>	<20060328105912.29cad8e0.seanlkml@sympatico.ca>	<20060328163215.GA25428@thyrsus.com>	<20060328164519.GA18879@mortise.boston.redhat.com>	<20060328165213.GC25693@thyrsus.com>	<20060328170330.GB18879@mortise.boston.redhat.com>	<20060328171909.GC26011@thyrsus.com>	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com>
Message-ID: <44297D5C.90504@warmcat.com>

Eric S. Raymond wrote:

> But don't let the perfect be the enemy of the good.  If we don't meet what
> people actually want to do with their computers, we'll lose.  And we'll
> *deserve* to lose.

This thinking is worse than the purist/zealot thinking you were 
complaining about, since it has a fuzzy idea of what losing and winning 
actually mean, yet it makes the only goal to 'win'.  Even if, say, mp3 
and quicktime are compromised into the OS, are you still 'losing' if 
some users can't have their HDTV WMV9 and complain loudly about it? 
There's no end to it down that path.

 > But don't let the perfect be the enemy of the good.

Ain't that exactly what you are doing right now?  Fedora under the 
current definition really is pretty good.

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

From seg at haxxed.com  Tue Mar 28 18:28:20 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Mar 2006 12:28:20 -0600
Subject: Fedora's way forward
In-Reply-To: <20060328130411.5af8c93b.seanlkml@sympatico.ca>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<20060328180010.GB24725@devserv.devel.redhat.com>
	<20060328130411.5af8c93b.seanlkml@sympatico.ca>
Message-ID: <1143570502.10632.49.camel@localhost>

On Tue, 2006-03-28 at 13:04 -0500, sean wrote:
> On Tue, 28 Mar 2006 13:00:10 -0500
> Alan Cox <alan at redhat.com> wrote:
> > What would be useful (free or nonfree) is an xml/yum-repository type format
> > that could be hooked into firefox and friends so you can 
> > 
> > 	"Click here to subscribe to fetchmail-pro"
> > 
> 
> Already possible.  Repository maintainer publishes a link on their 
> website to a rpm that installs a repo file.   Click on the link,
> click "Install RPM" when prompted and Bob's your uncle.

I just tried this. I clicked on the freshrpms-release RPM in Galeon, it
just prompts me to save it. However once saved, opening it in Nautilus
starts up system-install-packages and allows me to install it. Neat.

Nice to see this functionality return. Now if you could get it to go
direct from the browser to installing packages, you'd really have
something. (A vector for malware if you're not careful. Check those GPG
sigs...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/f1a4165a/attachment.sig>

From esr at thyrsus.com  Tue Mar 28 18:22:43 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 13:22:43 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328175608.GA24725@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
Message-ID: <20060328182243.GC26482@thyrsus.com>

Alan Cox <alan at redhat.com>:
> Learn from history Eric. Unless you are careful to keep your beliefs and
> ethics intact you become what you fight, whether its the USA versus the USSR
> or free software versus proprietary.

Oh, I have learned from history all right.  You might recall that I
learned enough to do some of the heaviest work at busting us out of
our comfortable techie ghetto.

A lot of what I learned during that process is that the zealots for a
cause are frequently its worst enemies in the end.  Yes, hold hard to
your ethics -- until the point where your preconceptions prevent you
from engaging with *reality*, at which point they've become useless as
a guide to achieving your original lofty goals.

The reality, in this case, is that ordinary computer users simply
don't give a shit about anything but "does it do what I want at a
price I'm willing to pay"?  If we don't meet those expectations, all
the nobility of soul in the universe won't make us any more than
another failed cabal of crackpot idealists.

On the level of goals, I'm just as hard-core an idealist and visionary
as you or anyone else here.  But I never forget Santayana's definition
of a fanatic: "One who redoubles his efforts after he has forgotten
his aim".  Feeling virtuous and self-justified must not be the end
goal, *successfully changing the world for the better* must be.

If that means making tactical compromises in the present so we can
capture the mass market and wind up in a position to bring
overwhelming pressure on hardware manufacturers and stiff-arm would-be
IP predators in the future, then hell yes.  I'm for it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jkeating at j2solutions.net  Tue Mar 28 18:24:25 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 10:24:25 -0800
Subject: Fedora's way forward
In-Reply-To: <1143570502.10632.49.camel@localhost>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<20060328180010.GB24725@devserv.devel.redhat.com>
	<20060328130411.5af8c93b.seanlkml@sympatico.ca>
	<1143570502.10632.49.camel@localhost>
Message-ID: <1143570265.3752.102.camel@yoda.loki.me>

On Tue, 2006-03-28 at 12:28 -0600, Callum Lerwick wrote:
> Nice to see this functionality return. Now if you could get it to go
> direct from the browser to installing packages, you'd really have
> something. (A vector for malware if you're not careful. Check those GPG
> sigs...)

And a webserver configured to not provide .rpm files as Real Media.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/aef3c4b4/attachment.sig>

From seg at haxxed.com  Tue Mar 28 18:35:50 2006
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 28 Mar 2006 12:35:50 -0600
Subject: Fedora's way forward
In-Reply-To: <44297D5C.90504@warmcat.com>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com>  <44297D5C.90504@warmcat.com>
Message-ID: <1143570951.10632.55.camel@localhost>

And the argument devolves into the age old idealist vs realist conflict.

Personally, I believe Linux has been so successful exactly because of
Linus's "Best is the enemy of the good" philosophy. But that's just me,
a realist.

All useful discussion in the thread has ended. Move along, nothing to
see here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/4a90302e/attachment.sig>

From seanlkml at sympatico.ca  Tue Mar 28 18:26:07 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 13:26:07 -0500
Subject: Fedora's way forward
In-Reply-To: <1143570502.10632.49.camel@localhost>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<20060328180010.GB24725@devserv.devel.redhat.com>
	<20060328130411.5af8c93b.seanlkml@sympatico.ca>
	<1143570502.10632.49.camel@localhost>
Message-ID: <BAYC1-PASMTP05B5877297263944F003D0AED30@CEZ.ICE>

On Tue, 28 Mar 2006 12:28:20 -0600
Callum Lerwick <seg at haxxed.com> wrote:

> On Tue, 2006-03-28 at 13:04 -0500, sean wrote:
> > On Tue, 28 Mar 2006 13:00:10 -0500
> > Alan Cox <alan at redhat.com> wrote:
> > > What would be useful (free or nonfree) is an xml/yum-repository type format
> > > that could be hooked into firefox and friends so you can 
> > > 
> > > 	"Click here to subscribe to fetchmail-pro"
> > > 
> > 
> > Already possible.  Repository maintainer publishes a link on their 
> > website to a rpm that installs a repo file.   Click on the link,
> > click "Install RPM" when prompted and Bob's your uncle.
> 
> I just tried this. I clicked on the freshrpms-release RPM in Galeon, it
> just prompts me to save it. However once saved, opening it in Nautilus
> starts up system-install-packages and allows me to install it. Neat.
> 
> Nice to see this functionality return. Now if you could get it to go
> direct from the browser to installing packages, you'd really have
> something. (A vector for malware if you're not careful. Check those GPG
> sigs...)
> 

Hmmm, strange.   I hadn't tried in a long time, but I just tried again 
and I got an option to "Open with Install Software" which allowed
direct installation.

Sean



From esr at thyrsus.com  Tue Mar 28 18:30:25 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 13:30:25 -0500
Subject: Fedora's way forward
In-Reply-To: <1143569195.3752.100.camel@yoda.loki.me>
References: <20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com>
	<1143569195.3752.100.camel@yoda.loki.me>
Message-ID: <20060328183025.GD26482@thyrsus.com>

Jesse Keating <jkeating at j2solutions.net>:
>                                          Users will take the
> path of least resistance.

Correct. And right now, their path of least resistance is Windows or a Mac.

>               We're trying to make it so that FOSS is that
> path, but if !FOSS becomes an easier path, thats where users will go,
> and we've lost the battle.  I'm surprised that you of all people don't
> see this.

What I see is that !FOSS is already the easier path.  We can't change that
by refusing to support MP3. All we can do with that choice is make the road to 
open source unattractive because *it doesn't meet their needs*.

Trying to tell them "well, you shouldn't want what you want" is just nuts.  
It's denial.  They'll write us off as kooks, and with good reason.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From davej at redhat.com  Tue Mar 28 18:31:04 2006
From: davej at redhat.com (Dave Jones)
Date: Tue, 28 Mar 2006 13:31:04 -0500
Subject: Kernel for SMP VIA C3 machines
In-Reply-To: <20060328181339.GF24725@devserv.devel.redhat.com>
References: <ufafyl92bci.fsf@epithumia.math.uh.edu>
	<20060324202627.GD2725@redhat.com>
	<ufapsk8h41m.fsf@epithumia.math.uh.edu>
	<20060327182323.GB16210@redhat.com>
	<ufaodzqe9n4.fsf@epithumia.math.uh.edu>
	<20060328181339.GF24725@devserv.devel.redhat.com>
Message-ID: <20060328183104.GA16196@redhat.com>

On Tue, Mar 28, 2006 at 01:13:39PM -0500, Alan Cox wrote:
 > On Tue, Mar 28, 2006 at 11:55:59AM -0600, Jason L Tibbitts III wrote:
 > > Just FYI, the exact error message when booting the shipping FC5 i686
 > > SMP kernel is:
 > > 
 > > Unknown interrupt or fault at EIP 00000060 c0100295 00000294
 >
 > The installer should have chosen a 586 kernel and apps however unless you have
 > a later Nemeiah variant which has full CMOV

Further up this thread, he pointed out this was a Nehemiah.
(All the SMP C3's are at least Nehemiah).

		Dave

-- 
http://www.codemonkey.org.uk



From i.pilcher at comcast.net  Tue Mar 28 18:29:25 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Tue, 28 Mar 2006 12:29:25 -0600
Subject: Bootsplash?
In-Reply-To: <20060328114818.4024f4c6@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>	<1143042269.23468.6.camel@orodruin.boston.redhat.com>	<1143059186.28627.6.camel@localhost.localdomain>	<20060324012515.66d801f4@alkaid.a.lan>	<1143220662.3500.1.camel@localhost>
	<1143302775.2605.41.camel@dimi>
	<20060328114818.4024f4c6@alkaid.a.lan>
Message-ID: <e0bva5$er8$1@sea.gmane.org>

Andreas Bierfert wrote:
> 
> Ok, here it goes:
> http://fedora.lowlatency.de/review/splashy/
> 

/usr/sbin/splashy: error while loading shared libraries:
libdirectfb_fbdev.so: cannot open shared object file: No such file or
directory

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From esr at thyrsus.com  Tue Mar 28 18:33:36 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 13:33:36 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328180010.GB24725@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<1143564306.3752.60.camel@yoda.loki.me>
	<20060328165005.GB25693@thyrsus.com>
	<20060328180010.GB24725@devserv.devel.redhat.com>
Message-ID: <20060328183336.GE26482@thyrsus.com>

Alan Cox <alan at redhat.com>:
> So if we carry one vendor how do we decide which of a thousand rival vendors
> get into the default yum.conf.d and how do we then audit them. Shall we
> sell icons on the desktop like a certain other vendor did ?

You see a problem, I see a way to please users and capture a revenue stream
at the same time.  What's not to like?
 
> What will you pay to have the fetchmail yum repository in by default..?

Nothing.  Fetchmail isn't proprietary.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jdesbonnet at gmail.com  Tue Mar 28 18:34:09 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 28 Mar 2006 19:34:09 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <A320B67AF9DD7C63D43130F9@10.0.0.14>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603280103.40598.lamont@gurulabs.com>
	<A5FD712AD9D181D45F2D61FB@10.0.0.14>
	<200603280906.21172.lamont@gurulabs.com>
	<A320B67AF9DD7C63D43130F9@10.0.0.14>
Message-ID: <1cef3e950603281034i32dc96b6r425a9bf3a2981826@mail.gmail.com>

Tcl is designed as an embeddable scripting language, and it's simple
and easy to use. I've seen it embedded in several network
infrastructure devices. Perl ... emm... yech (just an opinion -- 
please don't flame me). If you use Java, BeanShell is nice. Also check
Ruby. I don't know anything about it yet, but is supposed to be the
best thing since sliced pan if you believe its advocates.

Joe.

On 3/28/06, Kenneth Porter <shiva at sewingwitch.com> wrote:
> I've been thinking about incorporating either Perl or Tcl as my scripting
> language. Any other choices I should consider?



From seanlkml at sympatico.ca  Tue Mar 28 18:36:20 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 13:36:20 -0500
Subject: Fedora's way forward
In-Reply-To: <1143570951.10632.55.camel@localhost>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com> <44297D5C.90504@warmcat.com>
	<1143570951.10632.55.camel@localhost>
Message-ID: <BAYC1-PASMTP045CEF8CE9626A1D712681AED30@CEZ.ICE>

On Tue, 28 Mar 2006 12:35:50 -0600
Callum Lerwick <seg at haxxed.com> wrote:

> And the argument devolves into the age old idealist vs realist conflict.

I'm so tired of the proprietary voices claiming themselves as the voices 
of realism.

It is REALISTIC to think that we can be a distribution focused
on providing open source solutions.   It's realistic to know that means
we won't appeal to everyone or service everyones needs.   It's realistic
to know that it doesn't matter a tinkers damn because that's not
what we're interested in.

People who are passionate about developing open source solutions
can be very realistic and bloody well reject proprietary solutions
at the same time.

> Personally, I believe Linux has been so successful exactly because of
> Linus's "Best is the enemy of the good" philosophy. But that's just me,
> a realist. 

Exactly.  Listening to all the proprietary zealots demands to
have the very best proprietary formats may very well be the 
enemy of having good open source alternatives.

Why the hell does everyone think we have to take over the world?
We're just a little open source distribution trying to make
open source solutions.  Why the fuck is that so hard to understand
without caling someone an idealist?

Sean



From alan at redhat.com  Tue Mar 28 18:39:33 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 13:39:33 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328182243.GC26482@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
Message-ID: <20060328183933.GA14374@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 01:22:43PM -0500, Eric S. Raymond wrote:
> Oh, I have learned from history all right.  You might recall that I
> learned enough to do some of the heaviest work at busting us out of
> our comfortable techie ghetto.

Perhaps, or maybe you were just like Canute only you were saying that
the tide would come in....

> The reality, in this case, is that ordinary computer users simply
> don't give a shit about anything but "does it do what I want at a
> price I'm willing to pay"?  If we don't meet those expectations, all

That sounds more like Ubuntu's goals than Fedora. Fedora is intended to be
a testing ground for doing cool and exciting things with free software. In
the Ubuntu case you are making some interesting arguments, but Fedora isn't
intended to be Mum's new desktop, cool if it works out that way but its
not the design spec.

Alan



From jkeating at j2solutions.net  Tue Mar 28 18:43:01 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 10:43:01 -0800
Subject: Fedora's way forward
In-Reply-To: <20060328183025.GD26482@thyrsus.com>
References: <20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com>
	<1143569195.3752.100.camel@yoda.loki.me>
	<20060328183025.GD26482@thyrsus.com>
Message-ID: <1143571381.3752.115.camel@yoda.loki.me>

On Tue, 2006-03-28 at 13:30 -0500, Eric S. Raymond wrote:
> Correct. And right now, their path of least resistance is Windows or a Mac.

And this hasn't changed in a long time.

> >               We're trying to make it so that FOSS is that
> > path, but if !FOSS becomes an easier path, thats where users will go,
> > and we've lost the battle.  I'm surprised that you of all people don't
> > see this.
> 
> What I see is that !FOSS is already the easier path.  We can't change that
> by refusing to support MP3. All we can do with that choice is make the road to 
> open source unattractive because *it doesn't meet their needs*.

We make FOSS the easier path by improving the software built around FOSS
technology, not by compromising our integrity by stooping to the
non-free market place.  Total global domination isn't our goal, and if
it is your goal for a distro, perhaps you need to find a new distro.
Our goal is the promotion of FOSS and FOSS technologies though a damned
fine distribution built from FOSS.

> Trying to tell them "well, you shouldn't want what you want" is just nuts.  
> It's denial.  They'll write us off as kooks, and with good reason.

No, we say Here, look at this better technology and software.  Isn't
this nice to use?  It's already installed and ready for use.

Ever wonder how MSFT won the last browser war?  IE was pre-installed,
path of least resistance.  It wasn't BETTER than Netscape (at the time),
but it was far easier to use.  Same with their media players.  THIS is a
page we can take out of their book, make our software that is
preinstalled a nicer avenue and an easier avenue.

And by-gum, if a user has to go install an mp3 plugin from somewhere !
Fedora, well thats not the end of the world.  I do recall having to do
that with Windows not too long ago.  Ditto DVD playback.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/c4c74bf4/attachment.sig>

From abraxis at telkomsa.net  Tue Mar 28 19:21:08 2006
From: abraxis at telkomsa.net (Neil Thompson)
Date: Tue, 28 Mar 2006 21:21:08 +0200
Subject: Fedora's way forward
In-Reply-To: <20060328182243.GC26482@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
Message-ID: <20060328192108.GH15924@eeyore.32.boerneef.vornavalley>

On Tue, Mar 28, 2006 at 01:22:43PM -0500, Eric S. Raymond wrote:
> Alan Cox <alan at redhat.com>:
> > Learn from history Eric. Unless you are careful to keep your beliefs and
> > ethics intact you become what you fight, whether its the USA versus the USSR
> > or free software versus proprietary.
> 
> Oh, I have learned from history all right.  You might recall that I
> learned enough to do some of the heaviest work at busting us out of
> our comfortable techie ghetto.

As far as I'm concerned, the only thing you did the "heaviest work" on was perverting
the Free Software movement into the bletcherous abomination that is "Open Source".

I think T.S. Eliot said it best -

    Now is my way clear, now is the meaning plain:
    Temptation shall not come in this kind again.
    The last temptation is the greatest treason:
    To do the right deed for the wrong reason.

Although I am pretty sure that your way is not even the "right deed".


-- 
Cheers! (Relax...have a homebrew)

Neil

THEOREM: VI is perfect.
PROOF: VI in roman numerals is 6.  The natural numbers < 6 which divide 6 are
1, 2, and 3. 1+2+3 = 6.  So 6 is a perfect number.  Therefore, VI is perfect.
QED
                                                    -- Arthur Tateishi



From Lam at Lam.pl  Tue Mar 28 19:22:39 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Tue, 28 Mar 2006 21:22:39 +0200
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143569558.10632.41.camel@localhost>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<1143549705.4097.30.camel@pensja.lam.pl>
	<1143569558.10632.41.camel@localhost>
Message-ID: <1143573760.4097.59.camel@pensja.lam.pl>

Dnia 28-03-2006, wto o godzinie 12:12 -0600, Callum Lerwick napisa?(a):
> Tremor, a BSD licensed ogg vorbis reference decoder has been available
> for some time.
Thanks for correction. Maybe there's only laziness factor involved then,
or maybe the decoder relies on floating point operations which cheap
units doesn't do, I can't tell then. I can tell though that cheap
portable music players read MP3 and don't read Ogg Vorbis files (after
all these years of education!) This stinks.

> GPL licensing is not the problem. Besides, the goal of
> Xiph is not source code, its free and open standards, so that anyone can
> freely implement their own codecs under whatever license they want.
This doesn't help if someone wants to make a decoding device with no
additional cost over what they consider a must. Makers of the $20 MP3
players/$50 DVD players won't afford it :) Too bad they don't include
support even though they have a ready-to-use BSD-licensed decoder.

I guess we agree and can end this offtopic discussion :)

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/9025f075/attachment.sig>

From andreas.bierfert at lowlatency.de  Tue Mar 28 19:44:17 2006
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Tue, 28 Mar 2006 21:44:17 +0200
Subject: Bootsplash?
In-Reply-To: <e0bva5$er8$1@sea.gmane.org>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost> <1143302775.2605.41.camel@dimi>
	<20060328114818.4024f4c6@alkaid.a.lan> <e0bva5$er8$1@sea.gmane.org>
Message-ID: <20060328214417.730ccc2d@alkaid.a.lan>

On Tue, 28 Mar 2006 12:29:25 -0600
Ian Pilcher <i.pilcher at comcast.net> wrote:

> /usr/sbin/splashy: error while loading shared libraries:
> libdirectfb_fbdev.so: cannot open shared object file: No such file or
> directory
> 

Hu yes :) that is related to the directfb bug... wait I will upload a fixed
directfb version to the same location...

- Andreas
-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/c25e8d11/attachment.sig>

From pjones at redhat.com  Tue Mar 28 19:54:17 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 14:54:17 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060328101331.GB12588@devserv.devel.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
	<20060328101331.GB12588@devserv.devel.redhat.com>
Message-ID: <1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 05:13 -0500, Alan Cox wrote:
> On Mon, Mar 27, 2006 at 07:09:16PM -0500, Eric S. Raymond wrote:
> > That's wacky.  Doesn't happen on an X40, thank goodness.  Which is interesting,
> > because several of my sources claim the T40 and X40 are electronically 
> > identical, with X40 just being skrunched into a smaller form factor.
> 
> The old IDE layer does not support suspend/resume. The failure in this case
> is just an example of that, in this case cause by corruption of the HPA
> limits

Speaking of which, I've got a patch that duplicates our current startup
breakage in the resume path.  Which is to say, since we've already
screwed up the data that's in the protected area, this just disables it
again during resume, so you don't get IO errors.

http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa-resume.patch

Also, http://people.redhat.com/pjones/hpa/ is a yum repo with the
2.6.16-1.2080 kernel from cvs rebuilt for i686 with this patch.  I hope
this was a good kernel to test with, or davej will surely come make fun
of me ;)  I haven't tested it yet, but just as soon as I finish this
email I'll try it on my laptop.  I'll put x86_64 packages up when they
finish building.

I've got another patch that's hopefully mostly right and provides full
control of an IDE drive's HPA features via sysfs at:

http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa.patch

The two patches are mutually exclusive.  The biggest issue I have right
now with the second one is that we seem to be caching BIO errors, so if
you enable HPA, do an I/O to the disabled parts of the disk, and then
turn HPA off again, you get errors on further IOs when you try to read
that part of the disk.  What code should I be looking at to figure this
part out?  There may also be a lingering off-by-one bug in the second
patch... it needs some more thorough testing, and I've written a small
test suite, but it's hard to count on the answers when getting bogus IO
errors from the kernel.

(obviously, this needs to be done for libata as well)

-- 
  Peter



From andreas.bierfert at lowlatency.de  Tue Mar 28 19:55:52 2006
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Tue, 28 Mar 2006 21:55:52 +0200
Subject: Bootsplash?
In-Reply-To: <e0bva5$er8$1@sea.gmane.org>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost> <1143302775.2605.41.camel@dimi>
	<20060328114818.4024f4c6@alkaid.a.lan> <e0bva5$er8$1@sea.gmane.org>
Message-ID: <20060328215552.7b69fda8@alkaid.a.lan>

On Tue, 28 Mar 2006 12:29:25 -0600
Ian Pilcher <i.pilcher at comcast.net> wrote:
> /usr/sbin/splashy: error while loading shared libraries:
> libdirectfb_fbdev.so: cannot open shared object file: No such file or
> directory

Ok i386/x86_64 versions of the fixed directfb package can be found at the same
url now.

- Andreas
-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/ce1fdc1d/attachment.sig>

From jspaleta at gmail.com  Tue Mar 28 19:56:23 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 14:56:23 -0500
Subject: Fedora's way forward
In-Reply-To: <604aa7910603281156k3e319546qbb8670685e809c79@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<604aa7910603280906x4aa2458fge8db8526122e8c3@mail.gmail.com>
	<20060328172007.GD26011@thyrsus.com>
	<604aa7910603281156k3e319546qbb8670685e809c79@mail.gmail.com>
Message-ID: <604aa7910603281156r49943a1ew727317f0e0259b0@mail.gmail.com>

On 3/28/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> I'd be willing.  But this really needs to be done by a lawyer.

Yes indeed it does which makes the fact that you have brought this
up.. on  a list dedicated to discussing technical issues particularly
bemusing. So are you comments about it seeming to be reasonable path
for RedHat contrary to the current policy stance RedHat has taken.
How exactly do we as laypeople even begin to discuss with you the
feasibility of this idea ... if you don't even know what the terms of
the license being offered are?  While a lawyer's review will be needed
before a serious effort at implementation can be done. Certaintly
knowing with specificity the exact language of the offered terms from
the patent holder can only help produce informed discussion. I fully
expect there to be conditions which will broadly be understood as
problematic to solve some of the issues you have with how things are
done now.

If you think there is a shred of hope for community members to have an
option to buy in towards a "pay up" for an open source project that is
actually worth buying into.. please be so kind as to do the necessary
inquiries with the patent holder about the available license terms and
conditions before making that suggestion public. Right now you are
taking about a 3 million mile view on the issue.. and everything that
matters in this discussion are details in the licensing terms, which
you don't know. Please refrain from speculation until you are in a
position to at least state clearly what the offered terms and
conditions are. We can't even have a well intentioned layperson
discussion as to what is or is not allowed without specific terms.

However I think its a waste of everyones valuable time to discuss the
pros and cons of implementation details like "pointing yum to a 3rd
party location by default" until you can present us with the terms of
the licensing that is being offered and there is informed opinion
about what is allow,what is not allow, and what is uncertaintly
allowed by the language of the terms that you are suggesting the
community spend resources in securing.

-jef



From pjones at redhat.com  Tue Mar 28 20:10:13 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 15:10:13 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143548303.3802.474.camel@sundaram.pnq.redhat.com>
	<1cef3e950603280646n71457c2cme37517c546ed4793@mail.gmail.com>
Message-ID: <1143576613.26465.70.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 15:46 +0100, Joe Desbonnet wrote:

> Is a "fedora-laptop-list" warranted?

I doubt it -- a very large percentage of FC5 installs will be laptops,
and the trend is that they'll be gaining more and more ground.  Moving
laptop discussion to another list just means we have one more
development list.

More broadly, there seems to be a widely held belief that we can treat
laptops, desktops, and servers as three unrelated things, or
alternatively as two related things and then a third thing that's
completely unrelated.

It's a bad misconception.  There's already concern about power (and
heat) management regarding servers, and that's one of the biggest ways
in which servers and laptops differ.  They're really much more similar
than different.

We need to be thinking about it as facets of the same problem, not
moving the discussion of them apart.

-- 
  Peter



From pjones at redhat.com  Tue Mar 28 20:27:07 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 15:27:07 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
	<20060328101331.GB12588@devserv.devel.redhat.com>
	<1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
Message-ID: <1143577628.3095.0.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 14:54 -0500, Peter Jones wrote:
> On Tue, 2006-03-28 at 05:13 -0500, Alan Cox wrote:
> > On Mon, Mar 27, 2006 at 07:09:16PM -0500, Eric S. Raymond wrote:
> > > That's wacky.  Doesn't happen on an X40, thank goodness.  Which is interesting,
> > > because several of my sources claim the T40 and X40 are electronically 
> > > identical, with X40 just being skrunched into a smaller form factor.
> > 
> > The old IDE layer does not support suspend/resume. The failure in this case
> > is just an example of that, in this case cause by corruption of the HPA
> > limits
> 
> Speaking of which, I've got a patch that duplicates our current startup
> breakage in the resume path.  Which is to say, since we've already
> screwed up the data that's in the protected area, this just disables it
> again during resume, so you don't get IO errors.
> 
> http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa-resume.patch
> 
> Also, http://people.redhat.com/pjones/hpa/ is a yum repo with the
> 2.6.16-1.2080 kernel from cvs rebuilt for i686 with this patch.  I hope
> this was a good kernel to test with, or davej will surely come make fun
> of me ;)  I haven't tested it yet, but just as soon as I finish this
> email I'll try it on my laptop.  I'll put x86_64 packages up when they
> finish building.

OK, the x86_64 packages are there too, now, and I've also tested this
kernel on my laptop.  Seems to work, and suspend/resume does the right
thing.

-- 
  Peter



From emeric.maschino at jouy.inra.fr  Tue Mar 28 20:27:19 2006
From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino)
Date: Tue, 28 Mar 2006 22:27:19 +0200
Subject: kernel 2.6.16-1.2097_FC6 unbootable on Itanium
Message-ID: <1143577639.44299c27b9026@www.jouy.inra.fr>

Hi,

There's something wrong with kernel 2.6.16-1.2097_FC6. The last displayed
message is "Freeing unused kernel memory: 400kB freed" and then nothing.
kernel-2.6.16-1.2088_FC6 runs fine.

Cheers,

   ?meric



From pjones at redhat.com  Tue Mar 28 20:37:02 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 15:37:02 -0500
Subject: suspend/hibernate in the command line
In-Reply-To: <1143542444.5280.5.camel@localhost.localdomain>
References: <ur74n1min.fsf@gmail.com>
	<1143506183.5625.6.camel@daxter.boston.redhat.com>
	<m2psk7p9lw.fsf@sl392.st-edmunds.cam.ac.uk>
	<1143542444.5280.5.camel@localhost.localdomain>
Message-ID: <1143578223.3095.3.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 11:40 +0100, Richard Hughes wrote:
> On Tue, 2006-03-28 at 03:48 +0100, Leon wrote:
> > > For command line use 'pm-suspend'; it doesn't require root if (and only
> > > if) you are logged in at the console.
> > >
> > >     David
> > 
> > Thanks a lot, David.
> 
> If you are in a session, and want gnome-power-manager do do fancy things
> for you (like disconnect and reconnect NetworkManager, and lock the
> screen, etc) you can do:
[...]
> But maybe pm-suspend will do everything you need to do.

gnome-power-manager calls pm-suspend or pm-hibernate (depending on what
you ask it to do), which already has code to notify NM and such.

Look around in /etc/pm/hooks for details.

-- 
  Peter



From amitkarpe at vsnl.net  Mon Mar 27 12:38:59 2006
From: amitkarpe at vsnl.net (Amit Karpe)
Date: Mon, 27 Mar 2006 18:08:59 +0530
Subject: speed up FC 5
Message-ID: <20060327124326.13BEA6DF30@ak.kimaya>

Hi all,
	How we can speed up FC 5 ?
As we ( in India ) normally have 128 MB RAM and 1GHz to 2 GHz processor .
So any Fedora Core Linux  will get slow down on this configuration of m/c .
So how can we twik it to speed up FC 5 .

Thanks.

Amit.
______________________________________________________
param vaibhavam netum etat swaraashtram
? samrthaa bhavatwaashishaa tebhrusham

? ? ? ? ? ?|| Bharat Maata Ki Jay ||



From amitkarpe at vsnl.net  Tue Mar 28 20:55:52 2006
From: amitkarpe at vsnl.net (Amit Karpe)
Date: Wed, 29 Mar 2006 02:25:52 +0530
Subject: Call for Developers for the CSLinux project
Message-ID: <200603290225.53660.amitkarpe@vsnl.net>

Dear Linux hackers,

? ? As you may be aware, we, the Computer Science
Linux User's Group, are attempting to make our own
re-branded distribution of Linux based on Fedora Core
5.

? ?This distribution is aimed at having a customised
set of packages that we need in our BCS/MCS/BE/ME/MCA/Diploma
syllabus so that one set of three or four CDs can be
moved around without carring peripheral CDs for Java,
plugins, multimedia, etc.

? ? Moreover, we were mailed regularly by people that
they had trouble setting up Postgres, PHP, tomcat,
Perl, JDBC, etc. during their time of critical needs.
It is definately not fair to expect people to learn
how to configure these things at the last moment when
practicals are declared within a week.

? ? Even if someone is capable of configuring these,
it is likely that they may forget at the last moment
and also likely that people wont want to spend time
configuring stuff on the day previous to the exam at
the cost of studying.

? ? For this purpose, we also aim to provide
pre-configured RPMs and configuration scripts that can
achieve this task within a few minutes. In fact,
CSLinux version 1 released last year allowed even 
first year students to set up many things that TYs
were having trouble with.

? ? ?This version will be aimed at pushing this
simplicity and ease-of-use to the next level. With
GUIs, web-based tools for remote management of nodes
in labs, configuration replication scripts for
applying common settings to multiple laboratory nodes,
user management scripts for handling the thousads of
users on college servers, etc.

? ? ?For more information on what's been going on in
regard to CSLinux, you are encouraged to join the
CSLUG group 
http://groups.yahoo.com/group/cslug
and go through the archives
http://groups.yahoo.com/group/cslug/message
. We have also started a Wiki 
seedwiki.com/wiki/computer_science_linux_users_group/
for simplifying this effort and the
link to it can be found in he CSLUG archives.

? ? ?We request your participation, support and
encouragement in this effort. Please do spread the
word around.

? ? ?We need all sorts of people to help us out. We
need graphics designers to design the themes, logos,
images, wallpapers, bootscreens, etc. for CSLinux. We
require people to modify the installer Anaconda. We
need people to modify RPM files and change the default
configuration in them. We need people to make and
build binary RPMs out of source tarballs for packages
whose RPMs that may not already be available or when
i686 RPMs may not be available.

? ? ?We also need developers to develop the
configuration scripts, the small tools that we will
provide with CSLinux and changing initscripts.

? ? ?Finally and most importantly, we also require the
BCS/MCS/BE/ME/MCA/Diploma community to contribute their academic
projects to be put up on CSLinux. This is to encourage
students to make professional-grade real-life
applicable projects by providing them a large exposure
within the peer community.

? ? ?Also, we need people to search for sponsors. For
example, we may approach coaching classes to sponsor
the project in return for putting up their ads/banners
on our default wallpaper, the GNOME/KDE splash
screens, the default gdm login logo, and the CD covers
and the prints on the CD themselves.

? ? Absolutely any help will be appreciated a lot. We
would like CSLinux to become a living example of an
open source project that is self-sustaining, started
off by students on their own, and a successful
business model within Pune (although it will be
strictly not-for-profit).

? ? ?If you feel that you have completed any
assignment from BCS/MCS/BE/ME/MCA/Diploma to perfection and would like
the community to see it, then we will also be
including such assignments for reference on the
distribution. This is a very highly-demanded feature
by many.

? ? ? Your contribution on recommendations to what
tools, packages and documents that should be included
in CSL would be highly appreciated.

? ? ? ?We thank you for all your support in this
matter.

For more information you may contact the following:

Amit Karpe: amitkarpe at vsnl.net, 9226745408
Archis Gore: archisgore at yahoo.com, 9371058022

It would be preferred if you could post your
suggesstions, ideas and contributions onto the list.

Thank you,
Yours sincerely,
The CSL Team

P.S. Please forward this mail to as many mailing lists
and people that may be interested.

E-mail: archisgore at yahoo.com
Homepage: http://www.geocities.com/archisgore
-- 
Amit.
______________________________________________________
param vaibhavam netum etat swaraashtram
? samrthaa bhavatwaashishaa tebhrusham

? ? ? ? ? ?|| Bharat Maata Ki Jay ||



From pjones at redhat.com  Tue Mar 28 20:54:32 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 15:54:32 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328052459.4f159c2e.seanlkml@sympatico.ca>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328052459.4f159c2e.seanlkml@sympatico.ca>
Message-ID: <1143579272.3095.13.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 05:24 -0500, sean wrote:
> On Tue, 28 Mar 2006 04:50:52 -0500
> "Eric S. Raymond" <esr at thyrsus.com> wrote:
> 
> > Let's start with the basics.  For a consumer OS to be unable to play
> > MP3s and handle podcasts is just plain not acceptable, not in the
> > world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
> > understandable if the Fraunhofer patents blocked decoders, but
> > Fraunhofer itself has only dunned for royalties on *encoders* -- thus
> > Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.  
> 
> Hmmm, well that's interesting.   So it should be possible to include
> an open source mp3 decoder like Underbit's MAD. [1]

Unfortunately, this info is about 5 years out of date.  Fraunhofer
licensed the rights to Thomson Multimedia, who then made a big fuss
about players.  They have a published rate of $0.75US per unit for mp3
decoding software, which would have to be paid by whoever distributes
the software.

Obviously this model is incompatible with Fedora Core and Extras.

-- 
  Peter



From pjones at redhat.com  Tue Mar 28 21:10:36 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 16:10:36 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328155740.GC25098@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
Message-ID: <1143580236.3095.26.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 10:57 -0500, Eric S. Raymond wrote:
> Jeff Spaleta <jspaleta at gmail.com>:
> > On 3/28/06, Alan Cox <alan at redhat.com> wrote:
> > > I suggest you consult lawyers. Frauenhofer have claimed player royalties
> > > and quite actively.
> > 
> > Other than to talk to a lawyer, which is always the authorative action
> > to take on any issues involving questions of legal risk.... is there
> > any instructive references that could be cited in layperson oriented
> > documentation as to why mp3 playback support isn't included?
> 
> Yes, I'd like to see an authoritative source for Alan's assertion.

They're not exactly keeping it a big secret.  Which is to say that sent
a lot of nice little legal letters several years ago, sued some people,
and put up a website about how to pay for licenses.

> I did quite a bit of web research before making my statement.  If
> Fraunhofer has made claims on decoders, this fact is unknown (or not
> disclosed) by any of the major decoder implementors.

Amazingly, if you google for "mp3 licensing", the first hit is:

mp3licensing.com - Home
Details of the MP3 licensing programs for Thomson Multimedia and Fraunhofer IIS-A.
www.mp3licensing.com/ - 7k - Cached - Similar pages

Even more shocking, this page has license terms and price quotes for
both encoders and decoders.

The reason the authors of decoders don't mention it is because they
don't have much money.  It sounds cynical, but that's really how things
are.  The licensing writes for mp3 are controlled by Thomson Multimedia.
Thomson's no spring chicken, they're big business.  You've heard of
their brand names -- Technicolor, RCA, and others.  They're in it for
the money, and the money is not in suing individuals who happened to
write a codec illegally.  The money is in vendors who actually have
large amounts of money with which to pay damages.

-- 
  Peter



From pemboa at gmail.com  Tue Mar 28 21:12:44 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 28 Mar 2006 15:12:44 -0600
Subject: speed up FC 5
In-Reply-To: <20060327124326.13BEA6DF30@ak.kimaya>
References: <20060327124326.13BEA6DF30@ak.kimaya>
Message-ID: <16de708d0603281312q1de2d9b4t9074252f568ebffc@mail.gmail.com>

On 3/27/06, Amit Karpe <amitkarpe at vsnl.net> wrote:
>
> Hi all,
>         How we can speed up FC 5 ?
> As we ( in India ) normally have 128 MB RAM and 1GHz to 2 GHz processor .
> So any Fedora Core Linux  will get slow down on this configuration of m/c
> .
> So how can we twik it to speed up FC 5 .
>
> Thanks.


I would suggesting bringing back XFCE into core. But that is just my
somewhat ignorant opinion.

I dare say that your bottleneck seems to be memory.

Amit.
> ______________________________________________________
> param vaibhavam netum etat swaraashtram
> samrthaa bhavatwaashishaa tebhrusham
>
>   || Bharat Maata Ki Jay ||
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/acf437d8/attachment.htm>

From pjones at redhat.com  Tue Mar 28 21:12:33 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 16:12:33 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328171909.GC26011@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
Message-ID: <1143580354.3095.27.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 12:19 -0500, Eric S. Raymond wrote:
> David Cantrell <dcantrell at redhat.com>:
> > Because the software would still be in opposition to the goals of the
> > Fedora Project.  MP3 support isn't just on the ForbiddenItems list to
> > annoy people.  Like many others have stated, the project aims to produce
> > a free and open source Linux distribution that is redistributable by
> > all.  Having a paid-up royalty for a proprietary technology just so we
> > can include it in the distribution defeats the main goal.
> 
> See my suggestion about a pointer to a (hypothetical) lame-hosted yum 
> repository.

Ask your wife about "contributory infringement".

-- 
  Peter



From shane at geeklords.org  Tue Mar 28 21:14:12 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 13:14:12 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060328180838.GE24725@devserv.devel.redhat.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
Message-ID: <Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>

On Tue, 28 Mar 2006, Alan Cox wrote:

> Gconf doesn't need gnome. The reverse is true however. The XML format also lets
> you work with prefences using styles and XML XSLT and the like which is very
> powerful when working with a large number of systems. Really nobody has
> scratched the surface of what it can do.


http://www.libelektra.org/GConf has a whole list of reasons why they feel 
gconf would be a bad choice (at least in its current form) for the system 
configuration api.  A few example it has a lot more library dependencies, 
was not designed with a global namespace in mind, "GConf storage backend 
uses XML files, which are big, take long time and system resources to 
parse or update.", Eletkra has the concepts of "backends" of which gconf 
is one.

I dunno if Elektra is the right solution, but they seem to have some good 
arguments.

Shane



From shane at geeklords.org  Tue Mar 28 21:27:30 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 13:27:30 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <BAYC1-PASMTP1005B933FA9B1ECF1D380AAED30@CEZ.ICE>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
	<20060327153933.47f5dc33.seanlkml@sympatico.ca>
	<15188.192.54.193.25.1143532367.squirrel@rousalka.dyndns.org>
	<BAYC1-PASMTP1005B933FA9B1ECF1D380AAED30@CEZ.ICE>
Message-ID: <Pine.LNX.4.63.0603281324350.27793@master.geeklords.org>

On Tue, 28 Mar 2006, sean wrote:

> The original post by Shane mentioned the limitations of sed when trying to
> modify config files.  My notion was of something slightly smarter than
> sed that would have no idea of valid key names or values.  Just something,
> that could parse a config file and spit out a slightly modified version.

My post was not targeting the limitations of SED per say rather the 
limitions any tool will have modifying a plain text file that has no 
predefined structure.  The only improvement I can think of that would make 
sed easier to use is the ability to use "string of chars" for expressions 
instead of terminiating each metacharecter with a \

Shane



From alan at redhat.com  Tue Mar 28 21:29:59 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 16:29:59 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
References: <442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
	<20060328101331.GB12588@devserv.devel.redhat.com>
	<1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060328212959.GA30334@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 02:54:17PM -0500, Peter Jones wrote:
> Speaking of which, I've got a patch that duplicates our current startup
> breakage in the resume path.  Which is to say, since we've already
> screwed up the data that's in the protected area, this just disables it
> again during resume, so you don't get IO errors.

Its not breakage its quite intentional. For 99% of cases HPA is set because
it is being used fo BIOS clipping

> http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa-resume.patch

Looks basically sane. You have to run the ACPI taskfiles from the BIOS first
however or you are out of spec and anything can happen (although fortunately
it ususally doesnt)

Problems in the patch aside from that

#1:	HPA support and active state are in the identify data so you should
	consult that (which is boot time cached).

#2:	You can't assume LBA48 read_native_max_address_ext is supported just
	because LBA48 is, some maxtors don't. (dont copy the base kernel HPA
	code that is broken too but fails fairly safe with just message spew)

#3:	The proper way to decide to issue a set max is to check if the
	HPA is active but the size check is fine too I think

#4:	You need to tell the block layer about any size changes.

> (obviously, this needs to be done for libata as well)

At the moment libata doesn't do HPA. Some ideas have been kicked around for
how to handle it neatly but no conclusions AFAIK reached. Lobby Jeff,
especially if you have a smart idea.

Alan




From jspaleta at gmail.com  Tue Mar 28 21:35:34 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 16:35:34 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
Message-ID: <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>

On 3/28/06, Shane Stixrud <shane at geeklords.org> wrote:
> I dunno if Elektra is the right solution, but they seem to have some good
> arguments.

whether or not elektra is the right solution will be decided by
whether or not individual upstream software projects start working
towards integrating support for elektra as their default configuration
scheme.  This sort of technology revolution is not going to be
crowbarred into applications by Fedora or any sane distributor that
needs to worry about keeping in sync with upstream project
developements.  If you can't convince upstream developers to build in
support, a think its pretty ludicrious to be having a discussion about
it at the distributor level with any expectation a distributor like
fedora to do all the work downstream to integrate electra specific
patches.   The elektra developers might believe they've got the best
idea for a technology since sliced bread... but what existing projects
with an active codebase are actually attempting to integrate support
for this concept into their application?

And why are they bothering with SysVinit at all... when there are a
chorus of voices whoaare calling for SysVinit to be shot in the head. 
If electra were smart they'd be in communication with developers of a
few of the up and coming SysVinit replacements... cough initng
cough... and get elektra support buried deep into the guts of those
projects so elektra gets dragged in because it would take too much
work to remove.

-jef"can someone point me to the upstream xorg discussion where the
elektra people have submitted their patches for inclusion into the
mainline xorg codebase?"spaleta



From pjones at redhat.com  Tue Mar 28 21:47:50 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 16:47:50 -0500
Subject: Package names in FC5
In-Reply-To: <20060328144218.92792ab4.fedora@wir-sind-cool.org>
References: <200603281356.17155.rkwasny@aurox.org>
	<20060328144218.92792ab4.fedora@wir-sind-cool.org>
Message-ID: <1143582471.3095.33.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 14:42 +0200, Michael Schwendt wrote:

> No pattern. Core package developers can do what they want, and some of
> them still don't seem to care that .fc3 is "newer than" .FC5 in RPM
> version comparison.

That's a bit of an exaggeration.  It's not that we don't care, it's that
it doesn't matter unless you're doing something *else* really dumb at
the same time as *switching* between those two nomenclatures.

*yawn*.

-- 
  Peter



From pjones at redhat.com  Tue Mar 28 21:57:34 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 16:57:34 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060327130749.GB24971@devserv.devel.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
Message-ID: <1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>

On Mon, 2006-03-27 at 08:07 -0500, Alan Cox wrote:

> > Would this be appropriate for that Common Bugs page?
> 
> Yes but the recommendation should be "never use the disk check feature"

It isn't actually *that* dire of a situation.  Most of the time, for
most people, it works as intended.

For the other people, they get a failure that may, depending on things
such as which packages they select, appear be a false positive.  But
it's also, at least to some degree, correct.  Linux didn't read the disk
right.  Sometimes it might read the disk right, but you can bet failure
will happen again, too.

-- 
  Peter



From rodd at clarkson.id.au  Tue Mar 28 22:03:53 2006
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 29 Mar 2006 09:03:53 +1100
Subject: rawhide report: 20060328 changes
In-Reply-To: <200603280837.k2S8bEZR024955@porkchop.devel.redhat.com>
References: <200603280837.k2S8bEZR024955@porkchop.devel.redhat.com>
Message-ID: <1143583434.3595.5.camel@localhost.localdomain>

On Tue, 2006-03-28 at 03:37 -0500, Build System wrote:
> gnucash-1.9.3-1
> ---------------
> * Mon Mar 27 2006 Bill Nottingham <notting at redhat.com> - 1.9.3-1
> - update to 1.9.x
> 
the old gnucash had a whole stack of dependencies to gtk1 stuff.  Can
this now be removed from core?


R.
> 
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jspaleta at gmail.com  Tue Mar 28 22:04:40 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 17:04:40 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
Message-ID: <604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>

On 3/28/06, Peter Jones <pjones at redhat.com> wrote:
> For the other people, they get a failure that may, depending on things
> such as which packages they select, appear be a false positive.  But
> it's also, at least to some degree, correct.  Linux didn't read the disk
> right.  Sometimes it might read the disk right, but you can bet failure
> will happen again, too.

Or to ask it another way... if you use ide=nodma  and mediacheck
succeeds when before it failed.. does that mean that you should then
use ide=nodma  when doing the actual install on that system?

-jef



From jreiser at BitWagon.com  Tue Mar 28 22:08:21 2006
From: jreiser at BitWagon.com (John Reiser)
Date: Tue, 28 Mar 2006 14:08:21 -0800
Subject: speed up FC 5
In-Reply-To: <20060327124326.13BEA6DF30@ak.kimaya>
References: <20060327124326.13BEA6DF30@ak.kimaya>
Message-ID: <4429B3D5.3030207@BitWagon.com>

> 	How we can speed up FC 5 ?
> As we ( in India ) normally have 128 MB RAM and 1GHz to 2 GHz processor .

http://www.rule-project.org
     About the best you can tune Fedora Core for low-resource boxes.

http://www.ltsp.org
    Take 4 such machines, put the 512MB RAM into one of them, and run it as
    the Linux Terminal Server Project server supporting many clients.

-- 



From alan at redhat.com  Tue Mar 28 22:13:03 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 17:13:03 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
Message-ID: <20060328221303.GA29073@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 05:04:40PM -0500, Jeff Spaleta wrote:
> Or to ask it another way... if you use ide=nodma  and mediacheck
> succeeds when before it failed.. does that mean that you should then
> use ide=nodma  when doing the actual install on that system?

Nope. The problem is a CD-R track looks something like this:

<track>
[ISO fs]
[0-150K or so of undefined]
<end of track>

and the catalogue (track listing) contains various bits of magic, your drive
serial number and start/end of each track. But that is imprecise.

On the other hand the mounted isofs image has a known size so the isofs itself
won't try and read or prefetch outside it.




From alan at redhat.com  Tue Mar 28 22:18:21 2006
From: alan at redhat.com (Alan Cox)
Date: Tue, 28 Mar 2006 17:18:21 -0500
Subject: speed up FC 5
In-Reply-To: <4429B3D5.3030207@BitWagon.com>
References: <20060327124326.13BEA6DF30@ak.kimaya>
	<4429B3D5.3030207@BitWagon.com>
Message-ID: <20060328221821.GB29073@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 02:08:21PM -0800, John Reiser wrote:
> > As we ( in India ) normally have 128 MB RAM and 1GHz to 2 GHz processor .
> 
> http://www.rule-project.org
>      About the best you can tune Fedora Core for low-resource boxes.

128MB RAM doesn't really require some of this stuff. For 128MB I would suggest
the following is probably sufficient

1.	Offer a kernel with no audit/selinux support. Saves a lot of RAM but
	you want SELInux if you've got room IMHO so its beat an option

2.	Get rid of GNOME and ship Xfce. 		(big win)
	Get rid of Evolution and ship Sylpheed		(big win)
	Get rid of OpenOffice.org and ship Abiword	(huge win)

3.	Make sure you use the CFQ disk scheduler. That'll give
	the best responsiveness under swap load.	(small win)

That gets the main end user apps back to a sensible size. Web browser is
a trickier one and you may find it best to just keep firefox.

XFCe makes a huge difference. XFCe + Sylpheed + Abiword are snappy on a 
128MB box

Alan



From pjones at redhat.com  Tue Mar 28 22:20:40 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 17:20:40 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060328212959.GA30334@devserv.devel.redhat.com>
References: <442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
	<20060328101331.GB12588@devserv.devel.redhat.com>
	<1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
	<20060328212959.GA30334@devserv.devel.redhat.com>
Message-ID: <1143584440.3095.58.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 16:29 -0500, Alan Cox wrote:
> On Tue, Mar 28, 2006 at 02:54:17PM -0500, Peter Jones wrote:
> > Speaking of which, I've got a patch that duplicates our current startup
> > breakage in the resume path.  Which is to say, since we've already
> > screwed up the data that's in the protected area, this just disables it
> > again during resume, so you don't get IO errors.
> 
> Its not breakage its quite intentional. For 99% of cases HPA is set because
> it is being used fo BIOS clipping

For all thinkpads that have this turned on it's for BIOS backup/restore
features, a and other related features that the user (at least
theoretically) paid for and may still want.  Right now we're trashing
them.

I think ThinkPads make up more than 1% of cases, but I've got no real
data to prove it with.

> 
> > http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa-resume.patch
> 
> Looks basically sane. You have to run the ACPI taskfiles from the BIOS first
> however or you are out of spec and anything can happen (although fortunately
> it ususally doesnt)

Ugh.  Ok, I've got some reading to do before I get this in.  Thanks for
the info.

> Problems in the patch aside from that
> 
> #1:	HPA support and active state are in the identify data so you should
> 	consult that (which is boot time cached).

drive->capacity64 comes from one of id->lba_capacity_2,
id->lba_capacity, or CHS .  Is there something else you mean I should be
consulting the identify data for?

> #2:	You can't assume LBA48 read_native_max_address_ext is supported just
> 	because LBA48 is, some maxtors don't. (dont copy the base kernel HPA
> 	code that is broken too but fails fairly safe with just message spew)

Oh, you're absolutely right here, there's should be a check for the hpa
featureset present there.  Thanks, I'll update that.

> #3:	The proper way to decide to issue a set max is to check if the
> 	HPA is active but the size check is fine too I think
>
> #4:	You need to tell the block layer about any size changes.

Well, currently that's not a problem -- in the second patch I have the
set_capacity() calls.  But in this patch it's not needed, because we
always disable HPA no matter what before the gendisk is initialized at
all, so the block layer has never known about the smaller size.

> > (obviously, this needs to be done for libata as well)
> 
> At the moment libata doesn't do HPA. Some ideas have been kicked around for
> how to handle it neatly but no conclusions AFAIK reached. Lobby Jeff,
> especially if you have a smart idea.

I was thinking something almost exactly like the interface that's in the
second patch I posted.  We've already shipped 2 releases that just
disable it entirely for IDE, which means if we ever want to do anything
other than just disable it, we need control to be somewhere that can
examine the system to see what we've done.  Sadly, that probably means
userland.

-- 
  Peter



From shane at geeklords.org  Tue Mar 28 22:24:12 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 14:24:12 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>

On Tue, 28 Mar 2006, Jeff Spaleta wrote:

> whether or not elektra is the right solution will be decided by
> whether or not individual upstream software projects start working
> towards integrating support for elektra as their default configuration
> scheme.

This reasoning is flawed and I think it illustrates an example of where 
our Darwinist Meritocracy has difficultly dealing with problems that are 
global and counter to our evolutionary path.  Tell me, what motivators 
exist for any project or even groups of projects to adapt a 
non-standard 3rd parties configuration schema??  None, in fact I am 
sure there are plenty of reasons NOT to adapt such a thing. When 
looking at this issue from within a specific microcosms perspective it 
makes perfect sense why UNIX and Linux have failed to create this standard 
API after 40+ years of evolution.

It is when you look at GNU/LINUX as a whole that this problem becomes 
obvious and it is for this reason I think Fedora/freedesktop/LSB/FHS 
or some other entity with ties to the system as a whole will have to 
champion this standard. A global configuration scheme has little benefit 
until a large portion of the system is using it, until that threshold is 
meet it is but another configuration format adding to the systems 
complexity.

> And why are they bothering with SysVinit at all...

My guess is because at the time they did the patches this debate was not 
hot.  It seems they treated sysvinit as a proof of concept that 
libelektra is usable even at the earliest stages of os initialization.




From toshio at tiki-lounge.com  Tue Mar 28 22:29:30 2006
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Tue, 28 Mar 2006 14:29:30 -0800
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
Message-ID: <1143584970.30123.19.camel@localhost>

On Tue, 2006-03-28 at 13:14 -0800, Shane Stixrud wrote:
> On Tue, 28 Mar 2006, Alan Cox wrote:
> 
> > Gconf doesn't need gnome. The reverse is true however. The XML format also lets
> > you work with prefences using styles and XML XSLT and the like which is very
> > powerful when working with a large number of systems. Really nobody has
> > scratched the surface of what it can do.
> 
> 
> http://www.libelektra.org/GConf has a whole list of reasons why they feel 
> gconf would be a bad choice (at least in its current form) for the system 
> configuration api.  

If you look through the following, monster thread you'll find that
elektra is a bad choice for the desktop configuration api.  System and
desktop configuration requirements are different.  Also, the author of
that GConf comparison doesn't seem to understand the problems GConf is
attempting to solve which doesn't bode well for it ever displacing
GConf.

http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01392.html
http://www.redhat.com/archives/fedora-devel-list/2004-August/msg00024.html
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00039.html

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

From 777tahder at schlaegel.com  Tue Mar 28 22:31:19 2006
From: 777tahder at schlaegel.com (Schlaegel)
Date: Tue, 28 Mar 2006 14:31:19 -0800
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060328221303.GA29073@devserv.devel.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
Message-ID: <4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>

On 3/28/06, Alan Cox <alan at redhat.com> wrote:
> On Tue, Mar 28, 2006 at 05:04:40PM -0500, Jeff Spaleta wrote:
> > Or to ask it another way... if you use ide=nodma  and mediacheck
> > succeeds when before it failed.. does that mean that you should then
> > use ide=nodma  when doing the actual install on that system?
>
> Nope. The problem is a CD-R track looks something like this:
...
> On the other hand the mounted isofs image has a known size so the isofs itself
> won't try and read or prefetch outside it.

This presents the obvious question: why don't we just check the iso on
the media instead of the media itself, and thus remove this long
standing problem.



From jspaleta at gmail.com  Tue Mar 28 22:34:57 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 17:34:57 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
Message-ID: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>

On 3/28/06, Shane Stixrud <shane at geeklords.org> wrote:
> My guess is because at the time they did the patches this debate was not
> hot.  It seems they treated sysvinit as a proof of concept that
> libelektra is usable even at the earliest stages of os initialization.

everything with regard to elektra is proof of concept at the moment.
Is there any upstream project new or old that is attempting to use
elektra? Just point me to an upstream discussion for any codebase with
a seperate set of lead developers who are working on integrating
elektra even as an option for configuration.   Is anyone who is
responsibly for the mainline development of any application that has
configuration files to deal with looking to pick up this technology
and run with it?  Fedora should not be crowbaring any technological
leap which is meant to be a "standard" into old codebases if there
isn't even obvious momentum yet with regard to new codebase adoption.

I don't see any upstream project reaching for a solution to what
elektra is attempting. At the very least that a very big marketing
problem that the elektra project has. Billing yourself as the end all
be all of configuration systems.. and you can't get any upstream
project developers to see your point? Either you are overblowing the
problem or your implementation has some serious flaws or you aren't
making an effort to market your technology to the right people. I'm
giving elektra the benefit of the doubt when I say their problem is a
matter of focusing on the wrong audience. Upstream! Upstream!
Upstream!
Continuing to bring it up at the distribution level is a good way to
never gain traction. Getting an up and coming application to bite the
bullet and use your technology moves your project from "proof of
concept" to "in use in the wild"

-jef



From kzak at redhat.com  Tue Mar 28 22:36:20 2006
From: kzak at redhat.com (Karel Zak)
Date: Wed, 29 Mar 2006 00:36:20 +0200
Subject: suspend/hibernate in the command line
In-Reply-To: <1143506183.5625.6.camel@daxter.boston.redhat.com>
References: <ur74n1min.fsf@gmail.com>
	<1143506183.5625.6.camel@daxter.boston.redhat.com>
Message-ID: <20060328223620.GA7838@petra.dvoda.cz>

On Po, b?e 27, 2006 at 07:36:23 -0500, David Zeuthen wrote:
> For command line use 'pm-suspend'; it doesn't require root if (and only

 This is really nice command. There is not man page and 
 
    pm-suspend --help
    
 has extremely useful behaviour...


    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From shane at geeklords.org  Tue Mar 28 22:37:34 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 14:37:34 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143584970.30123.19.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
Message-ID: <Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>

On Tue, 28 Mar 2006, Toshio Kuratomi wrote:

>
> If you look through the following, monster thread you'll find that
> elektra is a bad choice for the desktop configuration api.  System and
> desktop configuration requirements are different.  Also, the author of
> that GConf comparison doesn't seem to understand the problems GConf is
> attempting to solve which doesn't bode well for it ever displacing
> GConf.

If I am not mistaken since that time elektra has developed its backends so 
that they can import/modify/export data from other systems like gconf so 
that gnome can continue to depend on gconf while users/admins can have a 
single method of modifying data.

In either case Elektra may very well not be the correct solution, but a 
technical solution does exist, it may just not of been found/developed 
yet.  There is a problem to be solved here, I haven't heard anyone argue 
seriously to the contrary and this is by no means a new problem.  The 
purpose of my original post was to start discussion on how that should 
would look and how we are going to get there in a realistic and reasonable 
way.

Shane.



From toshio at tiki-lounge.com  Tue Mar 28 22:41:32 2006
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Tue, 28 Mar 2006 14:41:32 -0800
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
Message-ID: <1143585692.30123.28.camel@localhost>

On Tue, 2006-03-28 at 14:24 -0800, Shane Stixrud wrote:
> On Tue, 28 Mar 2006, Jeff Spaleta wrote:
> 
> > whether or not elektra is the right solution will be decided by
> > whether or not individual upstream software projects start working
> > towards integrating support for elektra as their default configuration
> > scheme.
> 
> This reasoning is flawed and I think it illustrates an example of where 
> our Darwinist Meritocracy has difficultly dealing with problems that are 
> global and counter to our evolutionary path.  Tell me, what motivators 
> exist for any project or even groups of projects to adapt a 
> non-standard 3rd parties configuration schema??

Writing configuration files and configuration file parsers is boring,
frustrating, error-prone work.  If elektra is the right solution we
should see new projects embracing it.  After that happens, you'll start
seeing buyin from the established projects.

How to get more new projects to use it?  More language bindings would
definitely help....

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

From jspaleta at gmail.com  Tue Mar 28 22:42:29 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 17:42:29 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
Message-ID: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>

On 3/28/06, Shane Stixrud <shane at geeklords.org> wrote:
> In either case Elektra may very well not be the correct solution, but a
> technical solution does exist, it may just not of been found/developed
> yet.  There is a problem to be solved here, I haven't heard anyone argue
> seriously to the contrary and this is by no means a new problem.  The
> purpose of my original post was to start discussion on how that should
> would look and how we are going to get there in a realistic and reasonable
> way.

By working with upstream project developers and convincing them its
worth the effort to solve. What you do not do, if your goal is to
actual solve it, is to have this discussion in the scope of a single
distributor.

-jef



From shane at geeklords.org  Tue Mar 28 22:43:27 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 14:43:27 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>

On Tue, 28 Mar 2006, Jeff Spaleta wrote:

> Continuing to bring it up at the distribution level is a good way to
> never gain traction. Getting an up and coming application to bite the
> bullet and use your technology moves your project from "proof of
> concept" to "in use in the wild"

Please don't imply I give one wit if elektra is the correct solution or 
not, because I don't.  My only interest is in discovering why this problem 
hasn't already been solved and if anyone has a clue as to what the correct 
solution would look like.

The simple fact is GNU/Linux could do much better on this front and 
it appears we have no real plan or general consensus on how to proceed to 
in address this issue on a global scale.

Shane



From shane at geeklords.org  Tue Mar 28 22:45:57 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 14:45:57 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>

On Tue, 28 Mar 2006, Jeff Spaleta wrote:

>
> By working with upstream project developers and convincing them its
> worth the effort to solve. What you do not do, if your goal is to
> actual solve it, is to have this discussion in the scope of a single
> distributor.

A serious question for you Jeff, would XML exist in any applications today 
if it were developed by a few people in some basement and the authors went 
around trying to convince upstream projects to use it?  Let's get real.

Cheers,
Shane



From pjones at redhat.com  Tue Mar 28 22:49:46 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 17:49:46 -0500
Subject: FC5 weird raid issues
In-Reply-To: <200603272237.57927.jarod@wilsonet.com>
References: <442423F7.7060100@feuerpokemon.de>
	<200603270917.53027.jarod@wilsonet.com>
	<1143483304.20578.21.camel@vroomfondel.internal.datastacks.com>
	<200603272237.57927.jarod@wilsonet.com>
Message-ID: <1143586187.3095.68.camel@vroomfondel.internal.datastacks.com>

On Mon, 2006-03-27 at 22:37 -0800, Jarod Wilson wrote:
> On Monday 27 March 2006 10:15, Peter Jones wrote:
> > On Mon, 2006-03-27 at 09:17 -0800, Jarod Wilson wrote:
> > > Not to mention that fake raid10 doesn't quite work yet... :)
> >
> > That depends on which controller you have.  It seems to work for me with
> > SiL.
> 
> Is that with the FC5 installer alone, or with an updated libdmraid?

I fixed libdmraid support for SiL's implementation well before test 1,
and tested anaconda's support before FC5 went Gold.  Unless they've got
more than one metadata format for this, it should work.

> I never 
> did get around to trying that. Neither a sil or nvidia dmraid10 worked for 
> me.

Haven't tried invidia raid10.

-- 
  Peter



From jdesbonnet at gmail.com  Tue Mar 28 22:52:27 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 28 Mar 2006 23:52:27 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
Message-ID: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com>

Leave aside implementation for the moment...  a best practices
document (hell, just a Wiki page) on configuration file format would
go along way. Just a list of recommendations. Things like how to best
handle international characters. A list of common pit falls. A a few 
config file styles that are considered good, and a few that are
examples of how not to do it.

Joe.


On 3/28/06, Shane Stixrud <shane at geeklords.org> wrote:
> On Tue, 28 Mar 2006, Jeff Spaleta wrote:
>
> >
> > By working with upstream project developers and convincing them its
> > worth the effort to solve. What you do not do, if your goal is to
> > actual solve it, is to have this discussion in the scope of a single
> > distributor.
>
> A serious question for you Jeff, would XML exist in any applications today
> if it were developed by a few people in some basement and the authors went
> around trying to convince upstream projects to use it?  Let's get real.
>
> Cheers,
> Shane
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From mark.a.allyn at intel.com  Tue Mar 28 22:29:38 2006
From: mark.a.allyn at intel.com (Allyn, Mark A)
Date: Tue, 28 Mar 2006 14:29:38 -0800
Subject: Where is the kernel source package for FC5 GA?
Message-ID: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>


Hello:

I am trying to build kernel modules on a standard install
of Fedora Core 5 GA. I did select the development block
of packages.

However there do not seem to be any kernel sources available
to build kernel modules.

I tried yum and did a yum look for kernel-source and it came
up with nothing.

Where do I get enough of the kernel source to do compiles
of kernel driver modules?

Thank you

Mark Allyn



From shane at geeklords.org  Tue Mar 28 22:56:38 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 14:56:38 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143585692.30123.28.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
Message-ID: <Pine.LNX.4.63.0603281451370.27793@master.geeklords.org>

>
> Writing configuration files and configuration file parsers is boring,
> frustrating, error-prone work.  If elektra is the right solution we
> should see new projects embracing it.  After that happens, you'll start
> seeing buyin from the established projects.
>
> How to get more new projects to use it?  More language bindings would
> definitely help....

That may be the case, but for some applications say named, dhcp or ldap 
does it not seem reasonable that a generic configuration format may 
require a balance between putting less logic in the config structure 
requiring more of the application?  If so I can see how this would be a 
turn off for some applications even though it may be an overall win for 
the system as a whole.

Cheers,
Shane



From toshio at tiki-lounge.com  Tue Mar 28 22:59:48 2006
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Tue, 28 Mar 2006 14:59:48 -0800
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
Message-ID: <1143586789.30123.44.camel@localhost>

On Tue, 2006-03-28 at 14:37 -0800, Shane Stixrud wrote:
> On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
> 
> >
> > If you look through the following, monster thread you'll find that
> > elektra is a bad choice for the desktop configuration api.  System and
> > desktop configuration requirements are different.  Also, the author of
> > that GConf comparison doesn't seem to understand the problems GConf is
> > attempting to solve which doesn't bode well for it ever displacing
> > GConf.
> 
> If I am not mistaken since that time elektra has developed its backends so 
> that they can import/modify/export data from other systems like gconf so 
> that gnome can continue to depend on gconf while users/admins can have a 
> single method of modifying data.
> 
Hmm... but what is really the goal of the project?  To have a unified
on-disk format?  Or to have a unified API?  Reading through the myriad
posts and Documentation leaves me with the feeling that which one it is
depends on which suits them at the time.  Elektra using a Gconf backend
would give you a unified API -- but if the GConf API is more suitable
for the desktop than Elektra then what are you gaining?

OTOH, if the on-disk-format is what's important (so the system admin can
edit the text files consistently) then Elektra would have to be the
backend for GConf (which is possible, contrary to the implication on 
http://www.libelektra.org/GConf )

> In either case Elektra may very well not be the correct solution, but a 
> technical solution does exist, it may just not of been found/developed 
> yet.  There is a problem to be solved here, I haven't heard anyone argue 
> seriously to the contrary

I think Nicholas Mailhot had an extremely valid point:  The
configuration format (key = value; <key>value</key>; etc) is not a major
stumbling block for a system admin.  It's what the application
developers choose as the name for key and what they fill value with that
make configuration files easy or hard to understand.  Elektra and the
like are seeking to solve a problem that will only marginally aid a
system administrator in editing a config file from a text editor.

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

From jspaleta at gmail.com  Tue Mar 28 23:06:03 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 18:06:03 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
	<1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com>
Message-ID: <604aa7910603281506o685a8b79yd401ff92efea6a05@mail.gmail.com>

On 3/28/06, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
> Leave aside implementation for the moment...  a best practices
> document (hell, just a Wiki page) on configuration file format would
> go along way. Just a list of recommendations. Things like how to best
> handle international characters. A list of common pit falls. A a few
> config file styles that are considered good, and a few that are
> examples of how not to do it.

Again this is not a discussion that should be happening inside the
scope of fedora.

Hint: google for configuration specification discussions that have
occured already in distribution and application neutral forums.
Hint 2: freedesktop and related mailinglists
Hint 3: D-Conf

-jef



From pjones at redhat.com  Tue Mar 28 23:10:57 2006
From: pjones at redhat.com (Peter Jones)
Date: Tue, 28 Mar 2006 18:10:57 -0500
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
	<1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
Message-ID: <1143587457.3095.78.camel@vroomfondel.internal.datastacks.com>

On Sun, 2006-03-26 at 19:37 +0100, Joe Desbonnet wrote:

> 2. After FC5 install I no longer have use of my built in bluetooth device.

If the selinux policy update Jeremy suggested doesn't fix it, make sure
it's actually enabled in acpi.  There are a couple of things to check:
the "status" value in /proc/acpi/ibm/bluetooth and the output of lsusb
would be good places to start.

-- 
  Peter



From jspaleta at gmail.com  Tue Mar 28 23:12:32 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 28 Mar 2006 18:12:32 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
Message-ID: <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com>

On 3/28/06, Shane Stixrud <shane at geeklords.org> wrote:
> A serious question for you Jeff, would XML exist in any applications today
> if it were developed by a few people in some basement and the authors went
> around trying to convince upstream projects to use it?  Let's get real.

I said i was giving Elektra the benefit of the doubt. It could very
well be that their implementation is in fact not a useful
implementation and its not a compelling thing to use by either new
projects nor established projects... but I was trying to be nice.
Being nice is not my strong suit and everytime I attempt to be nice
miscommunication happens. Sorry about that. Let me try a style of
communication that I'm more comfortable with using the subtle nuances
of.

The discussion of this issue on the fedora lists is a waste of
everyone's time. Discussion of how to solve similar problems have
already happened in the context of freedesktop. If you spent a little
more time doing research instead of blowing hot air into this list you
would have discovered the D-Conf spec and related discussion and
followed up on it to see how its impacting upstream GConf development.
 All of which happens outside the scope of fedora.

-jef



From jdesbonnet at gmail.com  Tue Mar 28 23:16:17 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Wed, 29 Mar 2006 00:16:17 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143586789.30123.44.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
Message-ID: <1cef3e950603281516r11a6e5dcm6d22c80044ee811d@mail.gmail.com>

Just fantasising here ... the ideal configuration system IMHO would
fulfil the following criteria:

1. For simple configurations it should reduce to a simple key-value
pair text file, except that parsing rules will be very well defined.
2. At the other end of the scale it should handle the most complex applications
3. An optional schema definition can define the schema of the file
4. That schema can optionally provide enough information to enable a
configuration file editor to automatically generate a UI to enable
someone who is not intimate with the application to make changes (help
text, widget hints etc)
5. I18N proof
6. Optional modification history and roll back facility. If the
modification was made programatically, the audit trail should record
what make the modification.
7. Always have the option to edit with a text editor (ie it should be
easy for a human to read it and edit it)
8. API bindings for common languages (C, C++, Python, Java, Perl, bash?)

Joe.

On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> On Tue, 2006-03-28 at 14:37 -0800, Shane Stixrud wrote:
> > On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
> >
> > >
> > > If you look through the following, monster thread you'll find that
> > > elektra is a bad choice for the desktop configuration api.  System and
> > > desktop configuration requirements are different.  Also, the author of
> > > that GConf comparison doesn't seem to understand the problems GConf is
> > > attempting to solve which doesn't bode well for it ever displacing
> > > GConf.
> >
> > If I am not mistaken since that time elektra has developed its backends so
> > that they can import/modify/export data from other systems like gconf so
> > that gnome can continue to depend on gconf while users/admins can have a
> > single method of modifying data.
> >
> Hmm... but what is really the goal of the project?  To have a unified
> on-disk format?  Or to have a unified API?  Reading through the myriad
> posts and Documentation leaves me with the feeling that which one it is
> depends on which suits them at the time.  Elektra using a Gconf backend
> would give you a unified API -- but if the GConf API is more suitable
> for the desktop than Elektra then what are you gaining?
>
> OTOH, if the on-disk-format is what's important (so the system admin can
> edit the text files consistently) then Elektra would have to be the
> backend for GConf (which is possible, contrary to the implication on
> http://www.libelektra.org/GConf )
>
> > In either case Elektra may very well not be the correct solution, but a
> > technical solution does exist, it may just not of been found/developed
> > yet.  There is a problem to be solved here, I haven't heard anyone argue
> > seriously to the contrary
>
> I think Nicholas Mailhot had an extremely valid point:  The
> configuration format (key = value; <key>value</key>; etc) is not a major
> stumbling block for a system admin.  It's what the application
> developers choose as the name for key and what they fill value with that
> make configuration files easy or hard to understand.  Elektra and the
> like are seeking to solve a problem that will only marginally aid a
> system administrator in editing a config file from a text editor.
>
> -Toshio
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQBEKb/iX6yAic2E7kgRApBAAJ9ZecfzBkoDI6RlUtNmDoImkSwjzwCfWSwr
> KLRWkDMJ2mCemySz5XQ95L0=
> =gvoY
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From shane at geeklords.org  Tue Mar 28 23:20:30 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 15:20:30 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
	<604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603281517360.27793@master.geeklords.org>

On Tue, 28 Mar 2006, Jeff Spaleta wrote:

> would have discovered the D-Conf spec and related discussion and
> followed up on it to see how its impacting upstream GConf development.
> All of which happens outside the scope of fedora.

"D-Conf generated a long discussion on FreeDesktop.org's XDG mailling 
list. Its objective is to standarize configuration across desktop 
frameworks like Gnome and KDE, so no focus is being devoted to global 
non-desktop system configurations.

It was very difficult to find the D-Conf website (not found in the end), 
and seems that all is available is that XDG discussion, and a wiki page 
containing analisys of what is required, and development directions. 
Nothing else.

Conclusion: D-Conf is vaporware. "

source: http://www.libelektra.org/D-Conf

I hope you are right and D-conf is making a difference, that seems to be 
debatable however.  Btw by all means do not be nice on my account, I enjoy 
raw personality :).

Cheers,
Shane



From shane at geeklords.org  Tue Mar 28 23:27:10 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 15:27:10 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1cef3e950603281516r11a6e5dcm6d22c80044ee811d@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
	<1cef3e950603281516r11a6e5dcm6d22c80044ee811d@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603281521180.27793@master.geeklords.org>

On Wed, 29 Mar 2006, Joe Desbonnet wrote:

> Just fantasising here ... the ideal configuration system IMHO would
> fulfil the following criteria:
>
> 1. For simple configurations it should reduce to a simple key-value
> pair text file, except that parsing rules will be very well defined.
> 2. At the other end of the scale it should handle the most complex applications
> 3. An optional schema definition can define the schema of the file
> 4. That schema can optionally provide enough information to enable a
> configuration file editor to automatically generate a UI to enable
> someone who is not intimate with the application to make changes (help
> text, widget hints etc)
> 5. I18N proof
> 6. Optional modification history and roll back facility. If the
> modification was made programatically, the audit trail should record
> what make the modification.
> 7. Always have the option to edit with a text editor (ie it should be
> easy for a human to read it and edit it)
> 8. API bindings for common languages (C, C++, Python, Java, Perl, bash?)

Add to that list:
designed to to be minimal enough to be desirable for system 
initialization, fstab, modules.conf etc..

A name space that is designed to account for and scale from fstab to web 
apps.

And most importantly every key should be required to have at least a short 
description that is I18N compatible.

Shane



From ncherry at comcast.net  Tue Mar 28 23:27:24 2006
From: ncherry at comcast.net (Neil Cherry)
Date: Tue, 28 Mar 2006 18:27:24 -0500
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
Message-ID: <4429C65C.3070600@comcast.net>

Allyn, Mark A wrote:
> Hello:
> 
> I am trying to build kernel modules on a standard install
> of Fedora Core 5 GA. I did select the development block
> of packages.
> 
> However there do not seem to be any kernel sources available
> to build kernel modules.
> 
> I tried yum and did a yum look for kernel-source and it came
> up with nothing.
> 
> Where do I get enough of the kernel source to do compiles
> of kernel driver modules?

I think it's called kernel-devel.xxxx Try:

yum search kernel-devel

-- 
Linux Home Automation         Neil Cherry       ncherry at linuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
http://home.comcast.net/~ncherry/               Backup site



From seanlkml at sympatico.ca  Tue Mar 28 23:26:08 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 18:26:08 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143586789.30123.44.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
Message-ID: <BAYC1-PASMTP01CBB6843A1D12904CBA81AED30@CEZ.ICE>

On Tue, 28 Mar 2006 14:59:48 -0800
Toshio Kuratomi <toshio at tiki-lounge.com> wrote:

> I think Nicholas Mailhot had an extremely valid point:  The
> configuration format (key = value; <key>value</key>; etc) is not a major
> stumbling block for a system admin.  It's what the application
> developers choose as the name for key and what they fill value with that
> make configuration files easy or hard to understand.  Elektra and the
> like are seeking to solve a problem that will only marginally aid a
> system administrator in editing a config file from a text editor.


System administration of say dhcp or dns or any other service on Windows
isn't easier because of a unified key/value system.   And clearly
it has nothing to do with an ability to read well-named registry keys
(what a nightmare).  It's easier because of better and more functionally 
complete GUI administration tools.   The same strategy should make
Linux easier to administor for those looking to make the jump.  And it
has the upside of not requiring a grand unified plan.

As i've said in quite a few posts I agree with your conclusion, 
a common configuration registry will only improve things marginally.

Sean



From jdesbonnet at gmail.com  Tue Mar 28 23:30:28 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Wed, 29 Mar 2006 00:30:28 +0100
Subject: Hardware detection problems on laptops -- how to file a report?
In-Reply-To: <1143587457.3095.78.camel@vroomfondel.internal.datastacks.com>
References: <1cef3e950603260919n73301b79v354bd7997ff3c0b7@mail.gmail.com>
	<604aa7910603261005m133469d5p2075825f2261daf1@mail.gmail.com>
	<1cef3e950603261037q76362de2jeea06a8f9aa8cf9f@mail.gmail.com>
	<1143587457.3095.78.camel@vroomfondel.internal.datastacks.com>
Message-ID: <1cef3e950603281530wbad5784o215f13f7845c7efb@mail.gmail.com>

Thanks for the help -- it appears to be a SELinux thing alright. It
works when SELinux is disabled. I am starting to see lots of light at
the end of this FC5 upgrade tunnel now.
Joe.


On 3/29/06, Peter Jones <pjones at redhat.com> wrote:
> On Sun, 2006-03-26 at 19:37 +0100, Joe Desbonnet wrote:
>
> > 2. After FC5 install I no longer have use of my built in bluetooth device.
>
> If the selinux policy update Jeremy suggested doesn't fix it, make sure
> it's actually enabled in acpi.  There are a couple of things to check:
> the "status" value in /proc/acpi/ibm/bluetooth and the output of lsusb
> would be good places to start.
>
> --
>   Peter
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From toshio at tiki-lounge.com  Tue Mar 28 23:32:18 2006
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Tue, 28 Mar 2006 15:32:18 -0800
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281451370.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
	<Pine.LNX.4.63.0603281451370.27793@master.geeklords.org>
Message-ID: <1143588739.30123.70.camel@localhost>

On Tue, 2006-03-28 at 14:56 -0800, Shane Stixrud wrote:
> >
> > Writing configuration files and configuration file parsers is boring,
> > frustrating, error-prone work.  If elektra is the right solution we
> > should see new projects embracing it.  After that happens, you'll start
> > seeing buyin from the established projects.
> >
> > How to get more new projects to use it?  More language bindings would
> > definitely help....
> 
> That may be the case, but for some applications say named, dhcp or ldap 
> does it not seem reasonable that a generic configuration format may 
> require a balance between putting less logic in the config structure 
> requiring more of the application?  If so I can see how this would be a 
> turn off for some applications even though it may be an overall win for 
> the system as a whole.
> 
dhcp snippet (dhcp is not on here so hopefully this snippet is valid):
default-lease-time           21600;
subnet 10.202.46.0 netmask 255.255.255.0 {
    use-host-decl-names      on;
    option log-servers       10.202.46.2;
    host ws001 {
        hardware ethernet    00:11:22:33:44:55;
        fixed-address        192.168.0.1;
        default-lease-time   10000
        filename             "/lts/vmlinuz-2.4.26-ltsp-1";
    }
}

Here's the same thing in .ini style:
[global]
default-lease-time 21600

[10.202.46.0]
netmask 255.255.255.0
use-host-decl-names on
log-servers 10.202.46.2

[ws001]
subnet 10.202.46.0
hardware-ethernet 00:11:22:33:44:55
fixed-address 192.168.0.1
default-lease-time 10000
filename "/lts/vmlinuz-2.4.26-ltsp-1"

I'd argue that as the number of subnets and special case workstations
goes up, the ability of a system administrator to read and understand
the flat file is going to be markedly harder than for the admin to read
the custom-crafted dhcp-config syntax.

So if the end-goal is to keep the system-administrator's poor brain from
exploding while manually editing the files, I'd say custom-crafted
config files can be a win versus the generic one-size-fits-all approach.

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

From shane at geeklords.org  Tue Mar 28 23:59:07 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 15:59:07 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143588739.30123.70.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
	<Pine.LNX.4.63.0603281451370.27793@master.geeklords.org>
	<1143588739.30123.70.camel@localhost>
Message-ID: <Pine.LNX.4.63.0603281541570.27793@master.geeklords.org>

On Tue, 28 Mar 2006, Toshio Kuratomi wrote:

> dhcp snippet (dhcp is not on here so hopefully this snippet is valid):
> default-lease-time           21600;
> subnet 10.202.46.0 netmask 255.255.255.0 {
>    use-host-decl-names      on;
>    option log-servers       10.202.46.2;
>    host ws001 {
>        hardware ethernet    00:11:22:33:44:55;
>        fixed-address        192.168.0.1;
>        default-lease-time   10000
>        filename             "/lts/vmlinuz-2.4.26-ltsp-1";
>    }
> }
>
> Here's the same thing in .ini style:
[snip]
> I'd argue that as the number of subnets and special case workstations
> goes up, the ability of a system administrator to read and understand
> the flat file is going to be markedly harder than for the admin to read
> the custom-crafted dhcp-config syntax.

And I would agree for the .ini format.  But things change considerably 
when instead we deal with all configuration elements as keys and their 
values in a filesystem like structure.  I can now do:
"cfg_prog -export .ini/dhcpd/xml/etc.. /system/dhcpd/subnet 10.202.*"

where my default editor may be emacs, vim, gedit or a super config editor.

Shane.



From lamont at gurulabs.com  Wed Mar 29 00:09:34 2006
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 28 Mar 2006 17:09:34 -0700
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <4429C65C.3070600@comcast.net>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
	<4429C65C.3070600@comcast.net>
Message-ID: <200603281709.38816.lamont@gurulabs.com>

On Tuesday 28 March 2006 04:27pm, Neil Cherry wrote:
> Allyn, Mark A wrote:
> > Hello:
> >
> > I am trying to build kernel modules on a standard install
> > of Fedora Core 5 GA. I did select the development block
> > of packages.
> >
> > However there do not seem to be any kernel sources available
> > to build kernel modules.
> >
> > I tried yum and did a yum look for kernel-source and it came
> > up with nothing.
> >
> > Where do I get enough of the kernel source to do compiles
> > of kernel driver modules?
>
> I think it's called kernel-devel.xxxx Try:
>
> yum search kernel-devel

Yup.  It is kernel-devel.

If you want to build modules (i.e. external modules) for Red Hat distros, 
install kernel-devel.  If you want to build patched, custom kernels, get the 
SRPM.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/37a8100d/attachment.sig>

From ncherry at comcast.net  Wed Mar 29 00:25:35 2006
From: ncherry at comcast.net (Neil Cherry)
Date: Tue, 28 Mar 2006 19:25:35 -0500
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <200603281709.38816.lamont@gurulabs.com>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>	<4429C65C.3070600@comcast.net>
	<200603281709.38816.lamont@gurulabs.com>
Message-ID: <4429D3FF.4050904@comcast.net>

Lamont R. Peterson wrote:
> On Tuesday 28 March 2006 04:27pm, Neil Cherry wrote:
>> Allyn, Mark A wrote:
>>> Hello:
>>>
>>> I am trying to build kernel modules on a standard install
>>> of Fedora Core 5 GA. I did select the development block
>>> of packages.
>>>
>>> However there do not seem to be any kernel sources available
>>> to build kernel modules.
>>>
>>> I tried yum and did a yum look for kernel-source and it came
>>> up with nothing.
>>>
>>> Where do I get enough of the kernel source to do compiles
>>> of kernel driver modules?
>> I think it's called kernel-devel.xxxx Try:
>>
>> yum search kernel-devel
> 
> Yup.  It is kernel-devel.
> 
> If you want to build modules (i.e. external modules) for Red Hat distros, 
> install kernel-devel.  If you want to build patched, custom kernels, get the 
> SRPM.
> 

Ah, so that's the difference. That was driving me totally nuts. I
couldn't figure out why I couldn't compile the kernel with the
devel package but I'm very successful (when I don't remove too
much) with the kernel sources.

-- 
Linux Home Automation         Neil Cherry       ncherry at linuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
http://home.comcast.net/~ncherry/               Backup site



From sundaram at fedoraproject.org  Wed Mar 29 00:33:03 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 06:03:03 +0530
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <4429D3FF.4050904@comcast.net>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
	<4429C65C.3070600@comcast.net> <200603281709.38816.lamont@gurulabs.com>
	<4429D3FF.4050904@comcast.net>
Message-ID: <1143592383.3802.578.camel@sundaram.pnq.redhat.com>

On Tue, 2006-03-28 at 19:25 -0500, Neil Cherry wrote:
> Lamont R. Peterson wrote:
> > On Tuesday 28 March 2006 04:27pm, Neil Cherry wrote:
> >> Allyn, Mark A wrote:
> >>> Hello:
> >>>
> >>> I am trying to build kernel modules on a standard install
> >>> of Fedora Core 5 GA. I did select the development block
> >>> of packages.
> >>>
> >>> However there do not seem to be any kernel sources available
> >>> to build kernel modules.
> >>>
> >>> I tried yum and did a yum look for kernel-source and it came
> >>> up with nothing.
> >>>
> >>> Where do I get enough of the kernel source to do compiles
> >>> of kernel driver modules?
> >> I think it's called kernel-devel.xxxx Try:
> >>
> >> yum search kernel-devel
> > 
> > Yup.  It is kernel-devel.
> > 
> > If you want to build modules (i.e. external modules) for Red Hat distros, 
> > install kernel-devel.  If you want to build patched, custom kernels, get the 
> > SRPM.
> > 
> 
> Ah, so that's the difference. That was driving me totally nuts. I
> couldn't figure out why I couldn't compile the kernel with the
> devel package but I'm very successful (when I don't remove too
> much) with the kernel sources.

We have all this information in the release notes which we spend many
many hours writing. So you might as well as read it.
http://fedora.redhat.com/docs/release-notes/fc5/#sn-Kernel

Rahul



From smooge at gmail.com  Wed Mar 29 00:48:47 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Tue, 28 Mar 2006 17:48:47 -0700
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143548303.3802.474.camel@sundaram.pnq.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<442825C7.4020608@poolshark.org>
	<1cef3e950603271111ha79a6fet8851c7541d7d0021@mail.gmail.com>
	<20060327202457.GA15056@thyrsus.com>
	<1143548303.3802.474.camel@sundaram.pnq.redhat.com>
Message-ID: <80d7e4090603281648y2b22da4fmb7ffb59cc916a37c@mail.gmail.com>

On 3/28/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> On Mon, 2006-03-27 at 15:24 -0500, Eric S. Raymond wrote:
> > Joe Desbonnet <jdesbonnet at gmail.com>:
> > > The Thinkpad seems to be cropping up alot in bug reports...
> >
> > No surprise there.  It's the elite laptop, and has been since it
> > displaced the Sony VAIOs some time back.  I don't think I've met a
> > Linux hacker in the last five years who carried anything else for
> > reasons other than costs-too-much.
> >
> > >                                                     after a
> > > lot of sweat and tears I have regained most of my Thinkpad's
> > > functionality since the upgrade (actually a fresh install repeated
> > > several times).
> >
> > Have you managed to get suspend/resume to work reliably?  On my X40
> > the situation is bad...
> >
> > > Another solution which will probably take too much work: make some
> > > sort of LiveCD with sufficient functionality to test all the hardware
> > > compatibility.
> >
> > If anyone out there does this, I'm willing to test it and send in prompt
> > and detailed bug reports.
> > --
>
> We have a live CD creation tool called Kadischi and some live CD's
> floating around in fedora-livecd list. Details at
> http://fedoraproject.org/wiki/Kadischi/.
>
> We also have a project http://pootypedia.sourceforge.net/ which got
> sponsored by Fedora as part of Google's SOC. Unfortunately pootypedia is
> based on Kudzu while we are moving to HAL instead. Someone needs to
> combine these efforts and we need more developers to take this forward.
>
>

I am not much of a developer.. but I am going to look at this.


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From ncherry at comcast.net  Wed Mar 29 00:58:11 2006
From: ncherry at comcast.net (Neil Cherry)
Date: Tue, 28 Mar 2006 19:58:11 -0500
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <1143592383.3802.578.camel@sundaram.pnq.redhat.com>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>	<4429C65C.3070600@comcast.net>
	<200603281709.38816.lamont@gurulabs.com>	<4429D3FF.4050904@comcast.net>
	<1143592383.3802.578.camel@sundaram.pnq.redhat.com>
Message-ID: <4429DBA3.1020605@comcast.net>

Rahul Sundaram wrote:
> On Tue, 2006-03-28 at 19:25 -0500, Neil Cherry wrote:
>> Lamont R. Peterson wrote:
>>> On Tuesday 28 March 2006 04:27pm, Neil Cherry wrote:
>>>> Allyn, Mark A wrote:
>>>>> Hello:
>>>>>
>>>>> I am trying to build kernel modules on a standard install
>>>>> of Fedora Core 5 GA. I did select the development block
>>>>> of packages.
>>>>>
>>>>> However there do not seem to be any kernel sources available
>>>>> to build kernel modules.
>>>>>
>>>>> I tried yum and did a yum look for kernel-source and it came
>>>>> up with nothing.
>>>>>
>>>>> Where do I get enough of the kernel source to do compiles
>>>>> of kernel driver modules?
>>>> I think it's called kernel-devel.xxxx Try:
>>>>
>>>> yum search kernel-devel
>>> Yup.  It is kernel-devel.
>>>
>>> If you want to build modules (i.e. external modules) for Red Hat distros, 
>>> install kernel-devel.  If you want to build patched, custom kernels, get the 
>>> SRPM.
>>>
>> Ah, so that's the difference. That was driving me totally nuts. I
>> couldn't figure out why I couldn't compile the kernel with the
>> devel package but I'm very successful (when I don't remove too
>> much) with the kernel sources.
> 
> We have all this information in the release notes which we spend many
> many hours writing. So you might as well as read it.
> http://fedora.redhat.com/docs/release-notes/fc5/#sn-Kernel

Thanks Rahul, I only found out about the release notes yesterday
when someone else mentioned them. I now know where they are and
will go visit them as I have a lot of questions. The kernel issue
has plagued me since FC2(? the first 2.6 kernel).

-- 
Linux Home Automation         Neil Cherry       ncherry at linuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
http://home.comcast.net/~ncherry/               Backup site



From sundaram at fedoraproject.org  Wed Mar 29 01:02:29 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 06:32:29 +0530
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <4429DBA3.1020605@comcast.net>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
	<4429C65C.3070600@comcast.net> <200603281709.38816.lamont@gurulabs.com>
	<4429D3FF.4050904@comcast.net>
	<1143592383.3802.578.camel@sundaram.pnq.redhat.com>
	<4429DBA3.1020605@comcast.net>
Message-ID: <1143594150.3802.582.camel@sundaram.pnq.redhat.com>

On Tue, 2006-03-28 at 19:58 -0500, Neil Cherry wrote:

> >> Ah, so that's the difference. That was driving me totally nuts. I
> >> couldn't figure out why I couldn't compile the kernel with the
> >> devel package but I'm very successful (when I don't remove too
> >> much) with the kernel sources.
> > 
> > We have all this information in the release notes which we spend many
> > many hours writing. So you might as well as read it.
> > http://fedora.redhat.com/docs/release-notes/fc5/#sn-Kernel
> 
> Thanks Rahul, I only found out about the release notes yesterday
> when someone else mentioned them. 

I am curious. How did you manage to *miss it* ?. It has a rather
prominent button in the installer, default page for the browser,
mentioned usually in the release announcements etc. 

Rahul



From dlutter at redhat.com  Wed Mar 29 01:51:14 2006
From: dlutter at redhat.com (David Lutterkort)
Date: Tue, 28 Mar 2006 17:51:14 -0800
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
Message-ID: <1143597074.3608.44.camel@currant.watzmann.net>

On Sat, 2006-03-25 at 15:37 -0800, Shane Stixrud wrote:
> 1) I could create a custom RPM that had all of the changes imbedded in 
> config files and rpm scripts that merely overwrote the pre-existing ones. 
> Problem being this approach hides the complexity of what all was being 
> changed and why.
> 
> 2) Use cfengine after the kickstart install.  This of course has some 
> advantages over the rpm method but it also hides the same complexity and 
> adds some of its own.
> 
> 3) Document on paper all of the steps required and how to perform them 
> from the console, taking advantage of the guis when available or command 
> line when required.  I felt that was not only a big waste of time but left 
> far too much to human error.
> 
> 
> 4) Create a series of simple scripts using basic OS applications/tools 
> (sed, echo, cp, mv, authtool, postconf etc...) to perform all of the 
> required modifications, documenting what and why along the way.

The problem with (4) is that you mix describing what you want to be done
with how it is done, which has a number of disadvantages. One of the
goals of config mgmt systems like cfengine is to separate these two
concerns. You are right though that cfengine is not entirely trivial to
use. I have been using another config mgmt system, puppet,
(http://reductivelabs.com/projects/puppet) I wrote up an example of how
a config mgmt tool could help in solving the kind of problem you are
looking at: http://people.redhat.com/dlutter/puppet-app.html

> My conclusion having completed this process is that the number of 
> variables, complexity and dependencies that must be understood and taken 
> into account when modifying configuration files is much higher than it 
> needs to be. I think this should be clear when reading the example scripts 
> mentioned above.

One of the reasons to separate the what from the how: there are
complexities in both areas, and using a declarative approach to this
problem lets you separate these two kinds of cpmplexities nicely.

> It is my opinion that we as a community need to find a Better Way (tm) to 
> manage configuration changes for Linux subsystems and applications. 

I completely agree.

> Everything should be a file, but that does not mean every configuration 
> file needs to be formatted and managed differently.

While I agree in theory, the reality of config files with different
formats makes it extremely hard to get there. One approach that is being
pushed by a number of players to achieve uniform management of configs
is CIM/WBEM, an enormous standard that IMHO too much tool-specific
knowledge to see wide adoption.

A lighter-weight approach seems more promising: encapsulate most of the
config-file specific knowledge in simple script wrappers that can be
controlled by a declarative description of the configuration you want to
achieve and the logical interdependencies between them. This is what
puppet does, and why I find it very attractive.

David



From mark.a.allyn at intel.com  Wed Mar 29 01:54:57 2006
From: mark.a.allyn at intel.com (Allyn, Mark A)
Date: Tue, 28 Mar 2006 17:54:57 -0800
Subject: Compiling alsa 1.0.11rc4 on FC5 and kernel wierdness
Message-ID: <75EC4D5486CAC247B84AAAA6F96AA5580705A1FF@orsmsx402.amr.corp.intel.com>

Hello:

First of all, thanks for helping me find the kernel sources. I did find
them.

Now, I have another interesting problem. 

I am trying to compile the alsa driver from alsa 1.0.11rc4 and I am
having lots of compiler errors.

I have done some tracing and I have seemed to come to a conclusion that
there are some kernel 2.6.16 features (such as structures) in FC5's
kernel,
yet that kernel is 2.6.15**. This is breaking some conditionals in the 
source code where it is looking for kernel version 2.6.15 or earlier.

Are any of you aware of changes that have been put into the 2.6.15
kernel
that FC5 has that are actually from the 2.6.16 stock kernel?

For that matter, have any of you been able to successfully compile the
alsa
version 1.0.11rc4 driver under the FC5 kernel?

Thank you

Mark Allyn



From steve at silug.org  Wed Mar 29 02:11:05 2006
From: steve at silug.org (Steven Pritchard)
Date: Tue, 28 Mar 2006 20:11:05 -0600
Subject: Compiling alsa 1.0.11rc4 on FC5 and kernel wierdness
In-Reply-To: <75EC4D5486CAC247B84AAAA6F96AA5580705A1FF@orsmsx402.amr.corp.intel.com>
References: <75EC4D5486CAC247B84AAAA6F96AA5580705A1FF@orsmsx402.amr.corp.intel.com>
Message-ID: <20060329021105.GA26237@osiris.silug.org>

http://fedoraproject.org/wiki/PostIsOffTopic

On Tue, Mar 28, 2006 at 05:54:57PM -0800, Allyn, Mark A wrote:
> I have done some tracing and I have seemed to come to a conclusion that
> there are some kernel 2.6.16 features (such as structures) in FC5's
> kernel,
> yet that kernel is 2.6.15**. This is breaking some conditionals in the 
> source code where it is looking for kernel version 2.6.15 or earlier.
[...]

  $ rpm -q kernel-smp-2.6.15-1.2054_FC5 --changelog
  * Tue Mar 14 2006 Dave Jones <davej at redhat.com>
  - 2.6.16-rc6-git3
  [...]

Maybe you should leave kernel compiling to people who take the time to
read documentation?

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve at kspei.com             http://www.kspei.com/
Phone: (618)398-3000               Mobile: (618)567-7320



From mrsam at courier-mta.com  Wed Mar 29 02:14:49 2006
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Tue, 28 Mar 2006 21:14:49 -0500
Subject: Compiling alsa 1.0.11rc4 on FC5 and kernel wierdness
References: <75EC4D5486CAC247B84AAAA6F96AA5580705A1FF@orsmsx402.amr.corp.intel.com>
Message-ID: <cone.1143598489.315343.26263.500@commodore.email-scan.com>

Allyn, Mark A writes:

> I am trying to compile the alsa driver from alsa 1.0.11rc4 and I am
> having lots of compiler errors.
> 
> I have done some tracing and I have seemed to come to a conclusion that
> there are some kernel 2.6.16 features (such as structures) in FC5's
> kernel,
> yet that kernel is 2.6.15**. This is breaking some conditionals in the 
> source code where it is looking for kernel version 2.6.15 or earlier.

Do you have the appropriate kernel-devel RPM installed?

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

From mike at miketc.com  Wed Mar 29 02:25:35 2006
From: mike at miketc.com (Mike Chambers)
Date: Tue, 28 Mar 2006 20:25:35 -0600
Subject: Bootsplash?
In-Reply-To: <20060328214417.730ccc2d@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost>
	<1143302775.2605.41.camel@dimi> <20060328114818.4024f4c6@alkaid.a.lan>
	<e0bva5$er8$1@sea.gmane.org>  <20060328214417.730ccc2d@alkaid.a.lan>
Message-ID: <1143599135.2192.1.camel@scrappy.miketc.com>

On Tue, 2006-03-28 at 21:44 +0200, Andreas Bierfert wrote:
> On Tue, 28 Mar 2006 12:29:25 -0600
> Ian Pilcher <i.pilcher at comcast.net> wrote:
> 
> > /usr/sbin/splashy: error while loading shared libraries:
> > libdirectfb_fbdev.so: cannot open shared object file: No such file or
> > directory
> > 
> 
> Hu yes :) that is related to the directfb bug... wait I will upload a fixed
> directfb version to the same location...

This is the latest error I get when trying to run splashy...

[root at scrappy init.d]# splashy test
[root at scrappy init.d]# FATAL: video.c <440>:
        (#) DirectFBError [DirectFBCreate (&video->dfb)]: General I/O
error!

[root at scrappy init.d]# rpm -qa | grep splashy
splashy-0.1.6-1
[root at scrappy init.d]# rpm -qa | grep direct
directfb-0.9.24-6
directfb-devel-0.9.24-6

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt, then it's hilarious!"



From seanlkml at sympatico.ca  Wed Mar 29 02:29:21 2006
From: seanlkml at sympatico.ca (sean)
Date: Tue, 28 Mar 2006 21:29:21 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143597074.3608.44.camel@currant.watzmann.net>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
Message-ID: <BAYC1-PASMTP0170D468BE6629598015D5AED00@CEZ.ICE>

On Tue, 28 Mar 2006 17:51:14 -0800
David Lutterkort <dlutter at redhat.com> wrote:

> While I agree in theory, the reality of config files with different
> formats makes it extremely hard to get there. One approach that is being
> pushed by a number of players to achieve uniform management of configs
> is CIM/WBEM, an enormous standard that IMHO too much tool-specific
> knowledge to see wide adoption.
> 
> A lighter-weight approach seems more promising: encapsulate most of the
> config-file specific knowledge in simple script wrappers that can be
> controlled by a declarative description of the configuration you want to
> achieve and the logical interdependencies between them. This is what
> puppet does, and why I find it very attractive.

Okay, so your script wrappers do all the config-file specific work etc.  
We talked about making a tool earlier in this conversation that would 
know how to handle all the different config file formats, so i'm with 
you up to there.

But what is the advantage of building an entire new config language 
around these wrappers?  Couldn't they be manipulated just as easily 
with shell or python?    Can the administrator make simple ad-hoc 
command line config file changes?

Sean



From esr at thyrsus.com  Wed Mar 29 02:44:30 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 21:44:30 -0500
Subject: Fedora's way forward
In-Reply-To: <1143580354.3095.27.camel@vroomfondel.internal.datastacks.com>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143580354.3095.27.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060329024430.GA5093@thyrsus.com>

Peter Jones <pjones at redhat.com>:
> Ask your wife about "contributory infringement".

Quite familiar with the concept, thanks.  Whether it would apply here would
depend totally on the negotiated wording of the license.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From seandarcy2 at gmail.com  Wed Mar 29 02:55:50 2006
From: seandarcy2 at gmail.com (sean)
Date: Tue, 28 Mar 2006 21:55:50 -0500
Subject: rawhide->fc5; X won't start
Message-ID: <e0ct33$mrt$1@sea.gmane.org>

I was running rawhide updated to March 10. Went on vacation, yesterday 
did a full upgrade to fc5. Used yum to get  updates released.  Now X 
won't start. I think it's some sort of  xfs problem.

with gnome, I get the fedora bubble logo, then a black screen, alt-f1 
gets me the console, which shows:

waiting for X server to shut down FreeFontPath: FPE "unix/7100" refcount 
is 2, should be 1, fixing

syslog shows:

gnome_segv2[3263]: segfault at 0000000000xxxxxxxx .........

kde also won't start. The console shows:

xset: bad font path element (#76), .......

and syslog shows kded, ksplash, kcminit, and ksmserver segfaulting.

I've restarted xfs ( no errors in syslog ). I've rebooted.

Do I need to do some mkfontdir voodoo in each font directory? What did 
the upgrade change? I've seen no similar problems posted, so I assume 
it's a rawhide->fc5 issue.

puzzled.

sean
sean



From esr at thyrsus.com  Wed Mar 29 01:02:35 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 28 Mar 2006 20:02:35 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328183933.GA14374@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
Message-ID: <20060329010235.GA3395@thyrsus.com>

Alan Cox <alan at redhat.com>:
> Perhaps, or maybe you were just like Canute only you were saying that
> the tide would come in....

Yes, I think that's arguably true about my original work identifying
the many-eyeballs effect and so forth.  Richard Gabriel came within an
angstrom of getting all that ten years before I did in his "Worse is
Better" paper, and I've been saying for years that somebody else would have
between 1994-2000 if I hadn't.

The evangelism to the suits, though?  Not so much.  I went out on a hell 
of a limb those first couple of years.  We have the luxury of forgetting that
nowadays because the crazy/nutty things I was saying then turned into
conventional wisdom.  Someday it will probably grow dim even in *my* mind
how much sweat it took for me to accomplish that.  But it hasn't yet.

> That sounds more like Ubuntu's goals than Fedora. Fedora is intended to be
> a testing ground for doing cool and exciting things with free software. In
> the Ubuntu case you are making some interesting arguments, but Fedora isn't
> intended to be Mum's new desktop, cool if it works out that way but its
> not the design spec.

OK.  So the next question is, do *Red Hat's* goals no longer include
world desktop domination?  Because if that's true, I need to find a distro
that hasn't ... er ... lost its idealism.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From shane at geeklords.org  Wed Mar 29 03:20:01 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 19:20:01 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143597074.3608.44.camel@currant.watzmann.net>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
Message-ID: <Pine.LNX.4.63.0603281825400.28495@master.geeklords.org>

On Tue, 28 Mar 2006, David Lutterkort wrote:

> The problem with (4) is that you mix describing what you want to be done
> with how it is done, which has a number of disadvantages.

I agree, the biggest disadvantages with 4) IMO are:

1) Overhead of keeping the build scripts up to date
2) Determining what should be scripted vs done manually
3) Roll back / change revision is very difficult.
4) This approach can easily cause confusion on "objective" vs 
"implementation" for a 3rd party.

It is my opinion that in an ideal world the OS/configuration engine would 
be able to largely eliminate these disadvantages by tracking the history 
of all configuration changes from inital system build to current state, 
independent of how the change was made (scripted, distributed, manually at 
the console, etc...).  It seems to me this would be trivial if every 
configuration element was easily identifiable by path (filesystem), 
key name (filename) and it's value (content). Obviously there are 
practical considerations that make this difficult, performance, number of 
files, what should be a directory vs a file vs content etc...

> I have been using another config mgmt system, puppet,
> (http://reductivelabs.com/projects/puppet) I wrote up an example of how
> a config mgmt tool could help in solving the kind of problem you are
> looking at: http://people.redhat.com/dlutter/puppet-app.html

Puppet looks like a very promising centralized change distribution system. 
As you mentioned this separates the "how" changes are applied from the 
"what" is actually changing.  If you combine the change re-visioning 
concept mentioned above with a puppet like centralized distribution system 
that can detect client changes we now have something quite impressive.  In 
fact it resembles very much what I have with my Cisco equipment + 
management software.

> A lighter-weight approach seems more promising: encapsulate most of the
> config-file specific knowledge in simple script wrappers that can be
> controlled by a declarative description of the configuration you want to
> achieve and the logical interdependencies between them. This is what
> puppet does, and why I find it very attractive.

I mostly agree, although very elegant compared to what exists today I 
would still classify it as a work-around.

Cheers,
Shane



From bojan at rexursive.com  Wed Mar 29 03:25:28 2006
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 29 Mar 2006 14:25:28 +1100
Subject: FC5 kernels in updates/testing
Message-ID: <20060329142528.0sg7pvhy40swc0kc@www.rexursive.com>

Just out of curiosity, is 2069 testing kernel going to be replaced  
with 2080, now that 2.6.16.1 is out?

-- 
Bojan



From davej at redhat.com  Wed Mar 29 03:26:55 2006
From: davej at redhat.com (Dave Jones)
Date: Tue, 28 Mar 2006 22:26:55 -0500
Subject: FC5 kernels in updates/testing
In-Reply-To: <20060329142528.0sg7pvhy40swc0kc@www.rexursive.com>
References: <20060329142528.0sg7pvhy40swc0kc@www.rexursive.com>
Message-ID: <20060329032655.GB3572@redhat.com>

On Wed, Mar 29, 2006 at 02:25:28PM +1100, Bojan Smojver wrote:
 > Just out of curiosity, is 2069 testing kernel going to be replaced  
 > with 2080, now that 2.6.16.1 is out?

Yes, pretend 2069 never happened.
I was hoping that 2080 would go out today, but it seems to be stuck
in the errata system waiting for someone to pull a lever somewhere.

		Dave

-- 
http://www.codemonkey.org.uk



From rhally at mindspring.com  Wed Mar 29 03:29:50 2006
From: rhally at mindspring.com (Richard Hally)
Date: Tue, 28 Mar 2006 22:29:50 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>	<44273ECD.8010606@mindspring.com>	<20060327130749.GB24971@devserv.devel.redhat.com>	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
Message-ID: <4429FF2E.6010302@mindspring.com>

Jeff Spaleta wrote:
> On 3/28/06, Peter Jones <pjones at redhat.com> wrote:
>> For the other people, they get a failure that may, depending on things
>> such as which packages they select, appear be a false positive.  But
>> it's also, at least to some degree, correct.  Linux didn't read the disk
>> right.  Sometimes it might read the disk right, but you can bet failure
>> will happen again, too.
> 
> Or to ask it another way... if you use ide=nodma  and mediacheck
> succeeds when before it failed.. does that mean that you should then
> use ide=nodma  when doing the actual install on that system?
> 
> -jef
> 
When I ran into this problem I had already checked the CDs on another 
system(they passed) so I didn't check them again. I needed the ide=nodma 
to get the install to actually read the disk that it had just read to boot.
Richard



From bojan at rexursive.com  Wed Mar 29 03:33:00 2006
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 29 Mar 2006 14:33:00 +1100
Subject: FC5 kernels in updates/testing
Message-ID: <20060329143300.1a0ovyhn8k44goss@www.rexursive.com>

> Yes, pretend 2069 never happened.

What 2069? ;-)

Seriously, thanks for the update. Looking forward to ACPI CPU  
frequency stuff...

-- 
Bojan



From billcrawford1970 at gmail.com  Wed Mar 29 03:33:47 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 29 Mar 2006 04:33:47 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
Message-ID: <200603290433.51839.billcrawford1970@googlemail.com>

On Tuesday 28 March 2006 23:24, Shane Stixrud wrote:

> This reasoning is flawed and I think it illustrates an example of where
> our Darwinist Meritocracy has difficultly dealing with problems that are
> global and counter to our evolutionary path.

 It's not flawed reasoning, it's a statement.

 There are plenty of reasons why it hasn't happened, among which are a number 
of experiments with various forms of "registry" ...

 The reason most applications use individual config files instead of a central 
repository is because that makes it much, *much* easier to:

1. Design a domain-specific config language. XML does *NOT* solve this 
problem; it is a *lexical* (meta)language. The structure goes on top.

2. Point to a different config file when you start a program.

3. Copy config files, rename them, reuse them, move them into chroot() 
environments, and generally be *free* to do so.

4. There is no step 4.

> Tell me, what motivators 
> exist for any project or even groups of projects to adapt a
> non-standard 3rd parties configuration schema??  None, in fact I am
> sure there are plenty of reasons NOT to adapt such a thing. When
> looking at this issue from within a specific microcosms perspective it
> makes perfect sense why UNIX and Linux have failed to create this standard
> API after 40+ years of evolution.

 So what are you saying?

 In fairness I won't attack the straw man. It looks like you are holding one, 
though.

> It is when you look at GNU/LINUX as a whole that this problem becomes
> obvious and it is for this reason I think Fedora/freedesktop/LSB/FHS
> or some other entity with ties to the system as a whole will have to
> champion this standard. A global configuration scheme has little benefit
> until a large portion of the system is using it, until that threshold is
> meet it is but another configuration format adding to the systems
> complexity.

 Ah. The "it must all be integrated" straw man. (sigh)

> > And why are they bothering with SysVinit at all...
>
> My guess is because at the time they did the patches this debate was not
> hot.  It seems they treated sysvinit as a proof of concept that
> libelektra is usable even at the earliest stages of os initialization.

 Why are we all so intent on picking a sysvinit replacement before we have one 
that's fully useful and does all that the current system does?



From billcrawford1970 at gmail.com  Wed Mar 29 03:40:47 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 29 Mar 2006 04:40:47 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
Message-ID: <200603290440.48796.billcrawford1970@googlemail.com>

On Tuesday 28 March 2006 23:45, Shane Stixrud wrote:

> A serious question for you Jeff, would XML exist in any applications today
> if it were developed by a few people in some basement and the authors went
> around trying to convince upstream projects to use it?  Let's get real.

 And ... that's not an argument in favour of elektra, or anything else.

 Ad hominem arguments aren't, generally. Although a generally useful one is to 
actually pick on a real weakness.



From billcrawford1970 at gmail.com  Wed Mar 29 03:44:17 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 29 Mar 2006 04:44:17 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
	<1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com>
Message-ID: <200603290444.20942.billcrawford1970@googlemail.com>

On Tuesday 28 March 2006 23:52, Joe Desbonnet wrote:

> Things like how to best 
> handle international characters.

 utf-8

> A list of common pit falls.

 Trying to create a "one size fits all" configuration language for all 
applications.

 Trying to shoehorn a popular data-encoding method (xml) into all niches you 
can think of.

> A a few  
> config file styles that are considered good, and a few that are
> examples of how not to do it.

 Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic 
ideas are similar, the directory structure allowing split files is a big 
improvement over the single .conf file).

 Bad: almost anything using .ini ;) *please note the ALMOST* if the data set 
basically only has one or two dimensions, .ini will work fine. It will limit 
you in the future, maybe.



From billcrawford1970 at gmail.com  Wed Mar 29 03:37:58 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 29 Mar 2006 04:37:58 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281541570.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143588739.30123.70.camel@localhost>
	<Pine.LNX.4.63.0603281541570.27793@master.geeklords.org>
Message-ID: <200603290438.03209.billcrawford1970@googlemail.com>

On Wednesday 29 March 2006 00:59, Shane Stixrud wrote:
> On Tue, 28 Mar 2006, Toshio Kuratomi wrote:
> > dhcp snippet (dhcp is not on here so hopefully this snippet is valid):
> > default-lease-time           21600;
> > subnet 10.202.46.0 netmask 255.255.255.0 {
> >    use-host-decl-names      on;
> >    option log-servers       10.202.46.2;
> >    host ws001 {
> >        hardware ethernet    00:11:22:33:44:55;
> >        fixed-address        192.168.0.1;
> >        default-lease-time   10000
> >        filename             "/lts/vmlinuz-2.4.26-ltsp-1";
> >    }
> > }
> >
> > Here's the same thing in .ini style:
>
> [snip]
>
> > I'd argue that as the number of subnets and special case workstations
> > goes up, the ability of a system administrator to read and understand
> > the flat file is going to be markedly harder than for the admin to read
> > the custom-crafted dhcp-config syntax.
>
> And I would agree for the .ini format.

 Really?

 How does .ini format give you containers beyond the first level? By numbering 
the keys? ugh.

 The dhcp config file format is a much better match for a) the way people 
think if they know the problem domain b) allows *hierarchy*. XML at least 
gets that right (and I *don't* think xml is the answer).

> But things change considerably 
> when instead we deal with all configuration elements as keys and their
> values in a filesystem like structure.

 And this is the issue. Look at the mess that is SNMP MIBs. Can you read 
those? Can you?

> I can now do: 
> "cfg_prog -export .ini/dhcpd/xml/etc.. /system/dhcpd/subnet 10.202.*"
> where my default editor may be emacs, vim, gedit or a super config editor.

 Word.

 That's the first actual argument I've seen on the opposing side ;)

> Shane.



From matt at 0xf00d.com  Wed Mar 29 03:54:33 2006
From: matt at 0xf00d.com (Matthew Swasey)
Date: Tue, 28 Mar 2006 22:54:33 -0500
Subject: Fedora's way forward
In-Reply-To: <20060328133620.31f0f5c0.seanlkml@sympatico.ca>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com> <44297D5C.90504@warmcat.com>
	<1143570951.10632.55.camel@localhost>
	<20060328133620.31f0f5c0.seanlkml@sympatico.ca>
Message-ID: <1143604473.13153.13.camel@urashima.dclam.com>

On Tue, 2006-03-28 at 13:36 -0500, sean wrote:

> Why the hell does everyone think we have to take over the world?
> We're just a little open source distribution trying to make
> open source solutions.  Why the fuck is that so hard to understand
> without caling someone an idealist?
> 
> Sean
> 

That's what I want to know.  Why is everyone so hell bent on world
domination?  This attitude has been around since I first got into Linux
(1995) and I did not understand it then.  I use Fedora (and other disros
and BSD) because I like it, I don't care one bit what my friends run on
their computers as long as they are at least somewhat content.  

I like what Theo de Raadt (who I've always thought was a little pompous)
had to say in a recent interview about OpenBSD [1]:

"NewsForge: Why should someone use OpenBSD instead of another operating
system, besides security?"

"TdR: I don't really take any position of advocacy. People should use
what they want to, and I am not the right person to say anyone "should"
do anything. But hey, if someone is adventurous, check it out."

I agree with him completely.

-Matt

[1]: http://os.newsforge.com/os/06/03/20/2050223.shtml?tid=8





From shane at geeklords.org  Wed Mar 29 03:58:28 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 19:58:28 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <200603290433.51839.billcrawford1970@googlemail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<200603290433.51839.billcrawford1970@googlemail.com>
Message-ID: <Pine.LNX.4.63.0603281948430.28688@master.geeklords.org>

On Wed, 29 Mar 2006, Bill Crawford wrote:

> There are plenty of reasons why it hasn't happened, among which are a number
> of experiments with various forms of "registry" ...

Please let's avoid biases centered around an unnamed company implementation. 
To be simple I am an advocate of ANY on disk, plain text enabled, 
configuration standard that is designed and modeled after a traditional
unix file system.

>
> The reason most applications use individual config files instead of a central
> repository is because that makes it much, *much* easier to:
>
> 1. Design a domain-specific config language. XML does *NOT* solve this
> problem; it is a *lexical* (meta)language. The structure goes on top.
>
> 2. Point to a different config file when you start a program.
>
> 3. Copy config files, rename them, reuse them, move them into chroot()
> environments, and generally be *free* to do so.
>

I fail to see how any of the above important considerations are limited in 
any way.

>
> Ah. The "it must all be integrated" straw man. (sigh)

There is no straw man, real advantages and features become available when 
configuration data is unified.

Shane.



From shane at geeklords.org  Wed Mar 29 04:03:36 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Tue, 28 Mar 2006 20:03:36 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <200603290438.03209.billcrawford1970@googlemail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143588739.30123.70.camel@localhost>
	<Pine.LNX.4.63.0603281541570.27793@master.geeklords.org>
	<200603290438.03209.billcrawford1970@googlemail.com>
Message-ID: <Pine.LNX.4.63.0603281959110.28688@master.geeklords.org>

On Wed, 29 Mar 2006, Bill Crawford wrote:

>>> I'd argue that as the number of subnets and special case workstations
>>> goes up, the ability of a system administrator to read and understand
>>> the flat file is going to be markedly harder than for the admin to read
>>> the custom-crafted dhcp-config syntax.
>>
>> And I would agree for the .ini format.
>
> Really?
>
> How does .ini format give you containers beyond the first level? By numbering
> the keys? ugh.
>
> The dhcp config file format is a much better match for a) the way people
> think if they know the problem domain b) allows *hierarchy*. XML at least
> gets that right (and I *don't* think xml is the answer).

I think you misunderstand.  I did not bring up xml or ini files.  I was 
agreeing that a large dhcp config file converted to an .ini file would be 
a mess.

>> But things change considerably
>> when instead we deal with all configuration elements as keys and their
>> values in a filesystem like structure.
>
> And this is the issue. Look at the mess that is SNMP MIBs. Can you read
> those? Can you?

I fail to see the relationship.  We are not talking about the windows 
registry here... in which case the above statement would make sense...

Cheers,
Shane



From matt at 0xf00d.com  Wed Mar 29 04:17:09 2006
From: matt at 0xf00d.com (Matthew Swasey)
Date: Tue, 28 Mar 2006 23:17:09 -0500
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <1143605830.13153.34.camel@urashima.dclam.com>

On Tue, 2006-03-28 at 04:50 -0500, Eric S. Raymond wrote:

> First, a relatively minor issue that is nevertheless quite annoying.
> It's the Fedora distribution art, the images in Anaconda and the
> Fedora-customized graphics in the admin tools and elsewhere.  It has
> never been much better than mediocre, and in FC5 it hits a new low
> with backgrounds that look like a Teletubby hocked loogies into a
> dish full of soap scum.  And whose bright idea, I have to wonder, was
> it to abandon the attractive and recognizable Fedora icon for
> something that's...not a fedora?
> 
> Cripes.  By comparison, even the original BlueCurve was superior.  And
> original BlueCurve wasn't much to cheer about compared to the
> decorative art on a Windows or (especially) a Mac -- acceptable, but
> not a competitive plus, not something that would actually attract
> users.  The FedoraBubbles stuff is bland and tacky goo that I expect
> will repel them.

Sorry to bring the topic back so far, I know it has gone in a totally
different direction now.  I just wanted to say something about this
because I hear a lot of Bluecurve bashing lately.

Like someone said earlier, art is always a matter of ones own taste.  No
matter what the default are is, there will be many people who find it
displeasing.  I happen to find Ubuntu and SuSE's default art horrific,
however, many people seem to love the new "Human" theme.

Tango is making some nice icons at the moment, but honestly, I still
prefer the Bluecurve icon set.  I've yet to find a set of icons that has
the balance of functionality and attractiveness that the Bluecurve icons
have.  While I find many of the Tango icons very attractive, such as the
recycle bin, a lot of them need more thought.  Such as the main computer
icon, which has a screen that is angled, giving the whole monitor a
rhombus shape to it.  I don't get that at all, who has a monitor that
looks like that?  Nevertheless, many people are falling in love with the
Tango set.  Jakub Steiner is working on, what looks like, a new set of
default gnome icons[1], using the Tango look and feel.  I encourage
everyone to check them out, they look amazing.

The bottom line, is that I want someone out there to know, that there
are people that like Bluecurve.  I love Bluecurve, and if the Fedora
default ever changes to something like Tango, I will revert to
Bluecurve.  I am not trying to start a debate, just wanted to defend
Fedora art for a moment.

-Matt

[1]: http://jimmac.musichall.cz/i.php?i=git2





From stanfinley at comcast.net  Wed Mar 29 05:11:26 2006
From: stanfinley at comcast.net (Stanton Finley)
Date: Tue, 28 Mar 2006 22:11:26 -0700
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>

On Tue, 2006-03-28 at 04:50 -0500, Eric S. Raymond wrote:
> I've had a few days now to get through the expected upgrade teething
> troubles, use FC5 for my normal tasks, and watch my non-techie wife
> Cathy use FC5 for *her* normal tasks.  I've been a Red Hat/Fedora user
> and contributor for more than a decade now, since before 2.0 and
> *well* before I became famous enough to show up in Red Hat's corporate
> timeline :-).  I've taken some time to reflect on FC5 and the trends
> of the last decade, and where I think Fedora and Red Hat need to go in
> the future to achieve the dreams they were founded on.
> 
> Let me start with some good things.  I thought Fedora was in
> desperately bad shape in the FC3/FC4 period, and as some of you know I
> raised hell about it, threatening to jump very publicly to another
> distribution and orphan several Fedora-related HOWTOs in the process.
> I'm delighted to be able to report that much of what pushed me very
> near to giving up on Fedora has been fixed.
> 
> Good thing the first: Maintainence of the core repositories is no
> longer a disgraceful, poorly-documented shambles. Because of this, yum
> is at last fulfilling the promise of (almost) friction-free upgrading
> over the net.  Such problems as I've encountered with FC5 upgrades
> have been due to upstream bugs, not egregious fuckups in the Fedora
> infrastructure.  This had...ahem...not previously always been the case.
> 
> Good thing the second: this time around, I can ignore RPMForge.  While
> those guys have done excellent work and performed a valuable function
> by keeping Fedora on its toes, one of the things I really, *really*
> wanted as a sysadmin was to be able to point my yum at official Fedora
> repos plus one (1) repo for Damned Things like proprietary codecs, and
> be done.  In FC5, core plus extras plus livna does as good a job as
> core plus half-a-dozen RPMForge repos used to.
> 
> Good thing the third: it's clear from the devel-list traffic that the
> submission pathway for new packages has got most if not all of the
> process issues shaken out of it.  I had meant to get more directly
> involved in that, there are four or five things I want to package and
> submit myself, but higher-priority tasks ate my bandwidth.  One of my
> resolutions for 2006 is to make time for those submissions.
> 
> Good thing the fourth: A combination of increased polish in various
> distro components and significant upstream developments (one biggie
> being OpenOffice 2.0) has, to my observation, inched FC across an
> important functional threshold.  My wife can use it with as little
> pain as Windows now, rather than merely tolerating the crap because
> she believes in what the Linux community is trying to do.  This is
> significant, because she's *not a geek*; she's a lawyer.  She is,
> in fact, perfectly representative of the kind of forward-looking
> professional in non-technology fields that we must have on our
> side if we're to take Linux all the places we want it to go.
> 
> Take a moment to savor these good things.  Because the news is by no
> means all good.  We've come a long, long way, baby -- but having got
> past some of the serious blocking issues, we now get to face a new set
> of them. And at least one old issue everyone has been ducking...
> 
> First, a relatively minor issue that is nevertheless quite annoying.
> It's the Fedora distribution art, the images in Anaconda and the
> Fedora-customized graphics in the admin tools and elsewhere.  It has
> never been much better than mediocre, and in FC5 it hits a new low
> with backgrounds that look like a Teletubby hocked loogies into a
> dish full of soap scum.  And whose bright idea, I have to wonder, was
> it to abandon the attractive and recognizable Fedora icon for
> something that's...not a fedora?
> 
> Cripes.  By comparison, even the original BlueCurve was superior.  And
> original BlueCurve wasn't much to cheer about compared to the
> decorative art on a Windows or (especially) a Mac -- acceptable, but
> not a competitive plus, not something that would actually attract
> users.  The FedoraBubbles stuff is bland and tacky goo that I expect
> will repel them.
> 
> Now that we've gotten past some of the key blockers on the functional
> level, it's time to worry more about fit-and-finish issues like these.
> Mediocre art, workmanlike images that convey information without
> being ugly, is good enough for a niche product aimed at techies.  If
> we want Fedora -- and for that matter Linux in general -- to break out
> of that niche, we have to make it *look* like we want it to.
> 
> That means high-quality art, art that makes people actually *want* to
> look at the screen because it's a significant aesthetic experience.
> Which, right now, we ain't got.
> 
> But the art problem pales compared to the issue that everyone has been
> ducking, which is Fedora's support for DVDs and proprietary audio and
> video and web-streaming formats and Java applets. That is to say, its
> crummy-to-nonexistent-to-actually-toxic support.  The tools in FC5
> weren't better than they were in FC3/FC4; after installing the
> critical bits from livna, they were *worse*. Totem tossed its cookies
> with a cryptic pop-up error; xine white-screened under one card and
> actually crashed my X under another!
> 
> It's 2006, people.  The Web is fifteen years old.  Even non-techies
> have had a decade to form expectations about what constitutes a base
> level of functionality.  We don't have a prayer -- not a hope, not a
> snowball's chance in a supernova -- of becoming competitive for
> home and business-desktop use without delivering to those
> expectations.  
> 
> Those expectations include, without any doubt, multimedia playback,
> web streaming, and never seeing the broken-puzzle-piece icon in
> Firefox more than once per media type (if that often). When those
> expectations are violated, it's not the content provider who gets
> blamed for shipping a proprietary format.  The customer interprets
> that kind of failure as a bug in the client, *and the customer is
> right*.  All the idealism in the world about Ogg and Theora and
> whatnot will not change this.
> 
> Let's start with the basics.  For a consumer OS to be unable to play
> MP3s and handle podcasts is just plain not acceptable, not in the
> world after iTunes.  Red Hat/Fedora's duck-and-cover on this would be
> understandable if the Fraunhofer patents blocked decoders, but
> Fraunhofer itself has only dunned for royalties on *encoders* -- thus
> Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.  
> 
> I know at least one fairly influential kernel developer who threw out
> Red Hat/Fedora in disgust over this.  When he asked me straight up how
> I could defend what he bluntly called 'corporate cowardice', I didn't
> feel like I had a good answer.  And I still don't.  In return for all
> the free development work they get, it does seem to me that it's part
> of Red Hat's job to shoulder risks like these -- and that Red Hat
> hasn't held up its end.
> 
> AVI.  Quicktime.  ASF.  MPEG.  DVD playback.  Flash.  Java. These are
> *not optional* in 2006, any more than the ability to read Microsoft
> Word files in a word processor is optional; if we try to treat them
> that way, consumers will blow Linux off.  Evangelizing for SVG and Ogg
> and Theora may change this someday (I hope it will, anyway), but if
> that transition were going to happen soon enough to make supporting
> proprietary formats unnecessary *we'd already be past it now*.
> 
> So. For each format, we have one of three choices:
> 
> 1. We can end-run the patent restrictions on the technology (say,
> by developing outside the U.S. and distributing through overseas sites
> that are wink-wink-nudge-nudge unconnected with Fedora/Red hat).
> 
> 2. We can put real resources into developing a decoder implementation
> the blocking patents don't cover, and accept the risk that the
> patent-holders will launch harassment lawsuits anyway as a cost of
> doing business.
> 
> 3. We can buy the rights to the technologies we want as a straight
> commercial transaction from the patent-holder.
> 
> The community is already pursuing (1) for some formats.  If Red Hat,
> which likes to see itself as the market leader and senior commercial
> distributor, isn't willing to take a swing at (2) or (3) for the
> others, then I have to wonder what the hell having commercial Linux
> distributors is actually good for.
> 
> If solving the multimedia problem takes having Red Hat sell a
> plugins-and-drivers disk for each spin of FC, full of proprietary crap
> that it negotiated rights for, that sucks -- but better that than
> never getting any traction on the desktop because we got too caught up
> in our own idealism to meet actual consumer needs.
> 
> And if Red Hat's answer is "we don't want the desktop", then my answer
> back is "shame on you for forgetting where you came from!", and it
> really would be time for those of us who care about the future of Linux to
> find a commercial partner with more ambition and more guts.
> -- 
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> 
> "This country, with its institutions, belongs to the people who inhabit it. 
> Whenever they shall grow weary of the existing government, they can exercise
> their constitutional right of amending it or their revolutionary right to 
> dismember it or overthrow it."	-- Abraham Lincoln, 4 April 1861
> 

Right on the money Eric.

I love Fedora Core. In the world of Linux it is The Class Act. However I
would like to see it's core philosophical paradigm expanded to
accommodate the pragmatic reality of what the average user really wants
and what he actually installs on his Fedora machine in practice. Until
this occurs Fedora cannot hope to attract even a small fraction of its
potential user base.
-- 
Stanton Finley
http://stanton-finley.net/



From sundaram at fedoraproject.org  Wed Mar 29 05:16:09 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 10:46:09 +0530
Subject: Fedora's way forward
In-Reply-To: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
Message-ID: <1143609370.3802.598.camel@sundaram.pnq.redhat.com>


[Please quote more appropriately rather than including the entire mail
while replying to it]

> Right on the money Eric.
> 
> I love Fedora Core. In the world of Linux it is The Class Act. However I
> would like to see it's core philosophical paradigm expanded to
> accommodate the pragmatic reality of what the average user really wants
> and what he actually installs on his Fedora machine in practice.

You mean to say that Fedora should give up its support towards Free and
open source software and adopt proprietary formats and software in the
name of pragmatism. Not a good idea IMO. There are already other
distributions out there which does this if this is really the only thing
you want. 


Rahul



From perbj at sbcglobal.net  Wed Mar 29 05:26:48 2006
From: perbj at sbcglobal.net (Per Bjornsson)
Date: Tue, 28 Mar 2006 21:26:48 -0800
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143573760.4097.59.camel@pensja.lam.pl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<1143549705.4097.30.camel@pensja.lam.pl>
	<1143569558.10632.41.camel@localhost>
	<1143573760.4097.59.camel@pensja.lam.pl>
Message-ID: <1143610008.2249.5.camel@localhost.localdomain>

On Tue, 2006-03-28 at 21:22 +0200, Leszek Matok wrote:
> Dnia 28-03-2006, wto o godzinie 12:12 -0600, Callum Lerwick napisa?(a):
> > Tremor, a BSD licensed ogg vorbis reference decoder has been available
> > for some time.
> Thanks for correction. Maybe there's only laziness factor involved then,
> or maybe the decoder relies on floating point operations which cheap
> units doesn't do, I can't tell then.

Tremor is the now BSD-licensed _fixed-point_ Ogg Vorbis decoder,
specifically geared toward processors which don't have any
floating-point capabilities. The units that do play Ogg Vorbis are not
necessarily any more powerful than the others, but of course they need
enough memory for firmware. (This actually appears to be a problem for
some units, e.g. some iRiver players have two firmware versions, one
which plays Ogg Vorbis and one which plays WMA.)

/Per




From rowan at stasis.org  Wed Mar 29 05:27:42 2006
From: rowan at stasis.org (Rowan Kerr)
Date: Wed, 29 Mar 2006 00:27:42 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329010235.GA3395@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<20060328104659.GI12588@devserv.devel.redhat.com>	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>	<20060328155740.GC25098@thyrsus.com>	<20060328105912.29cad8e0.seanlkml@sympatico.ca>	<20060328163215.GA25428@thyrsus.com>	<20060328175608.GA24725@devserv.devel.redhat.com>	<20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
Message-ID: <442A1ACE.6050901@stasis.org>

Eric S. Raymond wrote:
> OK.  So the next question is, do *Red Hat's* goals no longer include
> world desktop domination?  Because if that's true, I need to find a distro
> that hasn't ... er ... lost its idealism.

This is what I have been concerned about for a while now. It looks like 
the next commercial version of Suse will have all kinds of media support 
through RealPlayer instead of the FOSS-only HelixPlayer. What will the 
next version of RHEL provide?

Of course, shelling out for a RHEL license doesn't make sense to me, 
because I don't need the support but I would be willing to purchase RPMs 
  to give me legal media support on Fedora. (MP3, MPEG2/DVD, MPEG4).

-Rowan




From sundaram at fedoraproject.org  Wed Mar 29 05:45:58 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 11:15:58 +0530
Subject: Fedora's way forward
In-Reply-To: <442A1ACE.6050901@stasis.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>  <442A1ACE.6050901@stasis.org>
Message-ID: <1143611158.3802.605.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-29 at 00:27 -0500, Rowan Kerr wrote:
> Eric S. Raymond wrote:
> > OK.  So the next question is, do *Red Hat's* goals no longer include
> > world desktop domination?  Because if that's true, I need to find a distro
> > that hasn't ... er ... lost its idealism.

Now when does including mp3 decoders in Fedora equate to world desktop
domination by Red Hat or idealism?  You have every reason to stutter
there being a open source evangelist - perceived or otherwise. 

> 
> This is what I have been concerned about for a while now. It looks like 
> the next commercial version of Suse will have all kinds of media support 
> through RealPlayer instead of the FOSS-only HelixPlayer. What will the 
> next version of RHEL provide?

Thats a irrelevant discussion for Fedora-devel list really.


Rahul



From perbj at sbcglobal.net  Wed Mar 29 05:49:05 2006
From: perbj at sbcglobal.net (Per Bjornsson)
Date: Tue, 28 Mar 2006 21:49:05 -0800
Subject: Fedora's way forward
In-Reply-To: <442A1ACE.6050901@stasis.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>  <442A1ACE.6050901@stasis.org>
Message-ID: <1143611346.2249.9.camel@localhost.localdomain>

On Wed, 2006-03-29 at 00:27 -0500, Rowan Kerr wrote:
> This is what I have been concerned about for a while now. It looks like 
> the next commercial version of Suse will have all kinds of media support 
> through RealPlayer instead of the FOSS-only HelixPlayer. What will the 
> next version of RHEL provide?

Likely RealPlayer, on a separate
proprietary-apps-not-really-in-the-distro disk, as they have done
before.

> Of course, shelling out for a RHEL license doesn't make sense to me, 
> because I don't need the support but I would be willing to purchase RPMs 
>   to give me legal media support on Fedora. (MP3, MPEG2/DVD, MPEG4).

Well, nothing prevents you from installing RealPlayer if that's what you
want, you can download it from Real...
/Per




From esr at thyrsus.com  Wed Mar 29 06:18:12 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 29 Mar 2006 01:18:12 -0500
Subject: Fedora's way forward
In-Reply-To: <1143604473.13153.13.camel@urashima.dclam.com>
References: <20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com> <44297D5C.90504@warmcat.com>
	<1143570951.10632.55.camel@localhost>
	<20060328133620.31f0f5c0.seanlkml@sympatico.ca>
	<1143604473.13153.13.camel@urashima.dclam.com>
Message-ID: <20060329061812.GA6131@thyrsus.com>

Matthew Swasey <matt at 0xf00d.com>:
> That's what I want to know.  Why is everyone so hell bent on world
> domination? 

Basically because we have to be.  The problem is that we have
adversaries with which "peaceful coexistence" would be chronically
unstable, not from our side but from theirs.

Microsoft is the most obvious example, but the problem extends to other
monopolies dependent on IP lockdown, such as the DVDCCA's.  The existence
of open source is intrinsically threatening to these people.  Our choices
come down to either defeating them or having our culture and our projects 
EULAd and DRMed to death.

I could now emit pious waffle about how in a better world we'd just
play in our corner and they'd play in theirs, but to be honest I enjoy
poking evil empires in the eye far too much to really mean it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From rowan at stasis.org  Wed Mar 29 06:21:53 2006
From: rowan at stasis.org (Rowan Kerr)
Date: Wed, 29 Mar 2006 01:21:53 -0500
Subject: Fedora's way forward
In-Reply-To: <1143611346.2249.9.camel@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<20060328104659.GI12588@devserv.devel.redhat.com>	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>	<20060328155740.GC25098@thyrsus.com>	<20060328105912.29cad8e0.seanlkml@sympatico.ca>	<20060328163215.GA25428@thyrsus.com>	<20060328175608.GA24725@devserv.devel.redhat.com>	<20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>	<20060329010235.GA3395@thyrsus.com>
	<442A1ACE.6050901@stasis.org>
	<1143611346.2249.9.camel@localhost.localdomain>
Message-ID: <442A2781.4030501@stasis.org>

Per Bjornsson wrote:
> Well, nothing prevents you from installing RealPlayer if that's what you
> want, you can download it from Real

True, although I'd prefer something that plugged in to gstreamer.

But as Rahul mentioned, this is pretty OT for the Fedora list and really 
an issue that should be put to the commercial distro vendors. :)

For the record, I think Fedora's policy is the correct one, although it 
can be frustrating at times.



From jkeating at j2solutions.net  Wed Mar 29 06:25:26 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 22:25:26 -0800
Subject: Fedora's way forward
In-Reply-To: <442A2781.4030501@stasis.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com> <442A1ACE.6050901@stasis.org>
	<1143611346.2249.9.camel@localhost.localdomain>
	<442A2781.4030501@stasis.org>
Message-ID: <1143613526.3752.139.camel@yoda.loki.me>

On Wed, 2006-03-29 at 01:21 -0500, Rowan Kerr wrote:
> True, although I'd prefer something that plugged in to gstreamer.

Look at Fluendo.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/9d657f63/attachment.sig>

From jkeating at j2solutions.net  Wed Mar 29 06:26:41 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 22:26:41 -0800
Subject: Fedora's way forward
In-Reply-To: <20060329061812.GA6131@thyrsus.com>
References: <20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com> <44297D5C.90504@warmcat.com>
	<1143570951.10632.55.camel@localhost>
	<20060328133620.31f0f5c0.seanlkml@sympatico.ca>
	<1143604473.13153.13.camel@urashima.dclam.com>
	<20060329061812.GA6131@thyrsus.com>
Message-ID: <1143613601.3752.141.camel@yoda.loki.me>

On Wed, 2006-03-29 at 01:18 -0500, Eric S. Raymond wrote:
> projects 
> EULAd and DRMed to death.

Er, but if we start including some of these !FOSS things like mp3
decoders and graphics drivers, wouldn't we then have to add to our EULAs
and such?  

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/fc9fbe7f/attachment.sig>

From esr at thyrsus.com  Wed Mar 29 06:33:45 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 29 Mar 2006 01:33:45 -0500
Subject: Fedora's way forward
In-Reply-To: <1143609370.3802.598.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
Message-ID: <20060329063345.GB6131@thyrsus.com>

Rahul Sundaram <sundaram at fedoraproject.org>:
> You mean to say that Fedora should give up its support towards Free and
> open source software and adopt proprietary formats and software in the
> name of pragmatism.

Rahul, you're being tendentious.  Nobody -- least of all me -- is
arguing that Fedora should "give up its support towards Free and open
source software".

I'm just arguing that we should treat ordinary users as though they matter.
That's how we'll get the market share and the clout to do what we 
really want.  Be honest, now -- do you realy suppose ODF would have even a
*prayer* of widespread adoption if Oo didn't also read Microsoft Word files?

Take audio as an example.  Yes, Ogg Vorbis is a better format.  I rip
all my CDs to Ogg Vorbis, and I'm totally behind the idea that we
should encourage everyone to do likewise.  That's our ODF.  But the
reality is that J. Random User wants to listen to podcasts, and the
podcasts are in MP3.  That's our Microsoft Word.

If we say to J. Random "No, we won't support MP3, shut up it's bad
for you", it's just as if we tried to sell him on an ODF-only word
processor by saying "no, you really don't want to touch all those
cruddy old Word documents".

That's not how you win hearts and minds.  It's how you get dismissed as
as a gang of useless wankers.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Wed Mar 29 06:36:40 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 29 Mar 2006 01:36:40 -0500
Subject: Fedora's way forward
In-Reply-To: <1143613601.3752.141.camel@yoda.loki.me>
References: <20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com> <44297D5C.90504@warmcat.com>
	<1143570951.10632.55.camel@localhost>
	<20060328133620.31f0f5c0.seanlkml@sympatico.ca>
	<1143604473.13153.13.camel@urashima.dclam.com>
	<20060329061812.GA6131@thyrsus.com>
	<1143613601.3752.141.camel@yoda.loki.me>
Message-ID: <20060329063640.GC6131@thyrsus.com>

Jesse Keating <jkeating at j2solutions.net>:
> On Wed, 2006-03-29 at 01:18 -0500, Eric S. Raymond wrote:
> > projects 
> > EULAd and DRMed to death.
> 
> Er, but if we start including some of these !FOSS things like mp3
> decoders and graphics drivers, wouldn't we then have to add to our EULAs
> and such?  

A different and lesser issue. And I think you know it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jkeating at j2solutions.net  Wed Mar 29 06:40:55 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 28 Mar 2006 22:40:55 -0800
Subject: Fedora's way forward
In-Reply-To: <20060329063640.GC6131@thyrsus.com>
References: <20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com> <44297D5C.90504@warmcat.com>
	<1143570951.10632.55.camel@localhost>
	<20060328133620.31f0f5c0.seanlkml@sympatico.ca>
	<1143604473.13153.13.camel@urashima.dclam.com>
	<20060329061812.GA6131@thyrsus.com>
	<1143613601.3752.141.camel@yoda.loki.me>
	<20060329063640.GC6131@thyrsus.com>
Message-ID: <1143614455.3752.145.camel@yoda.loki.me>

On Wed, 2006-03-29 at 01:36 -0500, Eric S. Raymond wrote:
> A different and lesser issue. And I think you know it.

I think not.  As the owner of the technology, mp3 owners could take
their ball and go home at a later date, rendering us in a very bad
situation.  It really is best to just avoid things like this from the
get go.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060328/08975c30/attachment.sig>

From jspaleta at gmail.com  Wed Mar 29 06:40:47 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Mar 2006 01:40:47 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329063345.GB6131@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
Message-ID: <604aa7910603282240i3b5fbaa3p3dbfc8b9652cb87b@mail.gmail.com>

On 3/29/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> Take audio as an example.  Yes, Ogg Vorbis is a better format.  I rip
> all my CDs to Ogg Vorbis, and I'm totally behind the idea that we
> should encourage everyone to do likewise.  That's our ODF.  But the
> reality is that J. Random User wants to listen to podcasts, and the
> podcasts are in MP3.  That's our Microsoft Word.

The Word format is patented encumbered? I didn't know that, thanks for
clearing that up by drawing a direct parallel between mp3 and word
document format.

Please, can you please please stop throwing around poorly constructed
analogies when you know there is more than simple reverse-engineering
of a closed format that's invovled. Why do you persist with muddying
the waters when you have already admitted that when you wrote the
original post you were working under the wrong assumptions with regard
to the mp3 paten situations. Please stop contributing to the problme
of misinformation by drawing parallels to other reverse-engineering
efforts which you know very well are don't exist in the same legal
contex. This isn't constructive.

-jef



From sundaram at fedoraproject.org  Wed Mar 29 06:46:06 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 12:16:06 +0530
Subject: Fedora's way forward
In-Reply-To: <20060329063345.GB6131@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
Message-ID: <1143614766.3802.621.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-29 at 01:33 -0500, Eric S. Raymond wrote:
> Rahul Sundaram <sundaram at fedoraproject.org>:
> > You mean to say that Fedora should give up its support towards Free and
> > open source software and adopt proprietary formats and software in the
> > name of pragmatism.
> 
> Rahul, you're being tendentious. 

You arent? The claim that mp3 wasnt patented followed up statements that
Red Hat should pay up a patent license for half a million dollars surely
looked like controversial to me from a open source advocate.


>  Nobody -- least of all me -- is
> arguing that Fedora should "give up its support towards Free and open
> source software".

Thats exactly what would happen. You can talk about all you want about
support open formats but if you dont actually build up volume nobody is
going to use it. If mp3 was supported out of the box in Fedora, why
would there be any incentive left for anyone to use ogg codecs?


> 
> I'm just arguing that we should treat ordinary users as though they matter.
> That's how we'll get the market share and the clout to do what we 
> really want.  Be honest, now -- do you realy suppose ODF would have even a
> *prayer* of widespread adoption if Oo didn't also read Microsoft Word files?

Different kind of usages and the analogy doesnt as much fit. Is
Goverment information and other critical data stored in mp3?.  Is word
formats patented? Where does it stop. Today suppose if we sign up all
kind of agreements and ship essentially proprietary software in Fedora.
What about WMV? Flash? Sun Java? We have over seventy downstream
derivative distributions of Fedora and many many more modifying and
redistributing it. Those are Fedora users too. Should we abandon them?

Produce more useful content in open formats. Build up momentum for it.
That is a better long term strategy just like we reached were we were
despite the naysayers because we produced good Free and open source
software. Giving up now is weaseling out. 


Rahul



From veillard at redhat.com  Wed Mar 29 07:44:53 2006
From: veillard at redhat.com (Daniel Veillard)
Date: Wed, 29 Mar 2006 02:44:53 -0500
Subject: speed up FC 5
In-Reply-To: <20060328221821.GB29073@devserv.devel.redhat.com>
References: <20060327124326.13BEA6DF30@ak.kimaya>
	<4429B3D5.3030207@BitWagon.com>
	<20060328221821.GB29073@devserv.devel.redhat.com>
Message-ID: <20060329074453.GA14102@redhat.com>

On Tue, Mar 28, 2006 at 05:18:21PM -0500, Alan Cox wrote:
> That gets the main end user apps back to a sensible size. Web browser is
> a trickier one and you may find it best to just keep firefox.

  Disabling the memory cache of Firefox makes a significant difference in
term of memory use by Firefox for me, even on a 1G machine, it's generally
slower but doesn't lead to swap (so far).

Daniel

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



From pmatilai at laiskiainen.org  Wed Mar 29 08:20:07 2006
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 29 Mar 2006 00:20:07 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<BAYC1-PASMTP0182E33A1A6A5120983177AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271334060.24389@master.geeklords.org>
	<BAYC1-PASMTP010FAE686E668C0C0A4AB0AED20@CEZ.ICE>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
Message-ID: <Pine.LNX.4.62.0603290011270.29184@gotcha.dreamhost.com>

On Tue, 28 Mar 2006, Shane Stixrud wrote:

> On Tue, 28 Mar 2006, Alan Cox wrote:
>
>> Gconf doesn't need gnome. The reverse is true however. The XML format also 
>> lets
>> you work with prefences using styles and XML XSLT and the like which is 
>> very
>> powerful when working with a large number of systems. Really nobody has
>> scratched the surface of what it can do.
>
>
> http://www.libelektra.org/GConf has a whole list of reasons why they feel 
> gconf would be a bad choice (at least in its current form) for the system 
> configuration api.  A few example it has a lot more library dependencies, was 
> not designed with a global namespace in mind, "GConf storage backend uses XML 
> files, which are big, take long time and system resources to parse or 
> update.", Eletkra has the concepts of "backends" of which gconf is one.

Um, GConf supports several backends as well. Can't argue about the 
dependencies.. just had a look at rpm -q --requires GConf2 - oh puke.
Building another layer on top of that gunk isn't going to help cutting 
down the dependencies though :)

 	- Panu -



From buildsys at redhat.com  Wed Mar 29 08:25:45 2006
From: buildsys at redhat.com (Build System)
Date: Wed, 29 Mar 2006 03:25:45 -0500
Subject: rawhide report: 20060329 changes
Message-ID: <200603290825.k2T8PjSM006543@porkchop.devel.redhat.com>

 

 
Updated Packages:

anaconda-11.1.0.2-1
-------------------
* Tue Mar 28 2006 Chris Lumens <clumens at redhat.com> 11.1.0.2-1
- Remove reference to pythondeps.

* Tue Mar 28 2006 Chris Lumens <clumens at redhat.com> 11.1.0.1-1
- Prompt for reformatting ancient swap partitions (dcantrel, #122101)
- Fix lots of deprecation warnings (dcantrel)
- Check for suspend signatures in swap (dcantrel, #186018)
- Support logging command in kickstart
- Clean up URLs we try to fetch in the loader
- Fix SELinux conditional inclusion (pjones)
- Remove customClass
- Always ignore disks listed in ignoredisks (#186438)
- Fix loader segmentation fault (#186210)
- Reiser fs label avoidance (dcantrel, #183183)
- Remove traceonly mode
- Add rhpl to minstg2.img (#185840)
- Remove lots of unneeded code in isys, iutil, and elsewhere
  (clumens, dcantrel, pnasrat)

arts-8:1.5.2-1
--------------
* Tue Mar 21 2006 Than Ngo <than at redhat.com> 8:1.5.2-1
- update to 1.5.2

checkpolicy-1.30.3-1
--------------------
* Tue Mar 28 2006 Dan Walsh <dwalsh at redhat.com> - 1.30.3-1
- Latest upgrade from NSA
	* Fixed checkmodule to call link_modules prior to expand_module
	  to handle optionals.
	* Fixed require_class to avoid shadowing permissions already defined
	  in an inherited common definition.

cpio-2.6-17
-----------
* Tue Mar 28 2006 Peter Vrabec <pvrabec at redhat.com> 2.6-17
- rebuild

* Sat Mar 25 2006 Peter Vrabec <pvrabec at redhat.com> 2.6-15
- fix (#186339) on ppc and s390

* Thu Mar 23 2006 Peter Vrabec <pvrabec at redhat.com> 2.6-14
- init struct  file_hdr (#186339)

cups-1:1.2-0.2.rc1.2
--------------------
* Tue Mar 28 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.2.rc1.2
- Fix lpq -h (STR#1515, bug #186686).

gconf-editor-2.14.0-2
---------------------
* Tue Mar 28 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-2
- Use gconf_value_free instead of g_free (bug 186479)

glibc-2.4-5
-----------
* Tue Mar 28 2006 Jakub Jelinek <jakub at redhat.com> 2.4-5
- update from CVS
  - pshared robust mutex support
  - fix btowc and bwtoc in C++ (#186410)
  - fix NIS+ (#186592)
  - don't declare __wcsto*l_internal for non-GCC or if not -O1+ (#185667)
- don't mention nscd failures on 2.0 kernels (#185335)

gnome-applets-1:2.14.0-3
------------------------
* Tue Mar 28 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-3
- apply patch

 * Tue Mar 28 2006 Ray Strode <rstrode at redhat.com> - 2.14.0-2
- export symbols in gswitchit applet so applet plugins 
  work (bug 187168)

hal-cups-utils-0.5.5-2
----------------------
* Tue Mar 28 2006 John (J5) Palmieri <johnp at redhat.com> - 0.5.5-2
- Make sure backends install into /usr/lib and not /usr/lib64

hplip-0.9.10-3
--------------
* Tue Mar 28 2006 Tim Waugh <twaugh at redhat.com> 0.9.10-3
- Always use /usr/lib/cups/backend.

* Tue Mar 28 2006 Tim Waugh <twaugh at redhat.com> 0.9.10-2
- 0.9.10.
- Ship PPDs.

kdebase-6:3.5.2-1
-----------------
* Sun Mar 26 2006 Than Ngo <than at redhat.com> 6:3.5.2-1
- update to 3.5.2
- update dbus patch
- drop kdebase-3.5.1-kwin-systray.patch, kdebase-3.5.1-keyboardlayout.patch,
  included in new upstream

kdelibs-6:3.5.2-1
-----------------
* Tue Mar 21 2006 Than Ngo <than at redhat.com> 6:3.5.2-1
- update to 3.5.2

kernel-2.6.16-1.2102_FC6
------------------------
* Tue Mar 28 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git14 & git15
- reenable sky2.

mc-1:4.6.1a-12
--------------
* Tue Mar 28 2006 Jindrich Novy <jnovy at redhat.com> 4.6.1a-12
- apply more robust version of FISH upload patch,
  thanks to Dmitry Butskoy (#186456)

policycoreutils-1.30.1-3
------------------------
* Tue Mar 21 2006 Dan Walsh <dwalsh at redhat.com> 1.30.1-3
- Add IN_MOVED_TO to catch renames

tcpdump-14:3.9.4-3
------------------
* Tue Mar 28 2006 Martin Stransky <stransky at redhat.com> - 14:3.9.4-3
- updated ethernet codes (#186633)

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5





From uraeus at gnome.org  Wed Mar 29 09:59:41 2006
From: uraeus at gnome.org (Christian Fredrik Kalager Schaller)
Date: Wed, 29 Mar 2006 11:59:41 +0200
Subject: Fedora's way forward
In-Reply-To: <44296E4C.5030808@adslpipe.co.uk>
References: <20060328163215.GA25428@thyrsus.com>
	<44296905.70900@adslpipe.co.uk> <20060328165443.GD25693@thyrsus.com>
	<44296E4C.5030808@adslpipe.co.uk>
Message-ID: <1143626381.2277.43.camel@localhost.localdomain>

On Tue, 2006-03-28 at 18:11 +0100, Andy Burns wrote:
> Eric S. Raymond wrote:
> 
> > I don't see that.
> 
> At the bottom of http://www.mp3licensing.com/royalty/software.html
> it's not clear if the minimum royalty is only applicable when paying 
> "per unit" or not.
> 
> > No, there's a crucial distinction.  Consumers think they should get this 
> > capability bundled with their OS, not have to pay extra after the sale.
> 
> But the price from Fluendo's shop is ?0.00 per plugin, ithough t would 
> be better if it were able to be distributed as part of the O/S

It is, we are offering distributors a no-cost redistribution contract
for our plugin. The problem is that even if the source code is available
under a MIT license the resulting binary is not GPL compatible, and
arguably not free software no matter what license the underlaying code
has. Due to this distributions with a clear free software stance, like
Fedora, has opted to not include it so far.

Be also aware that the cost of including non-free codecs in the
distribution is that any GPL application able to use them will have 
to go out. This means that as soon as this codec goes in, any
open-source KDE multimedia playback application goes out, and on the
GNOME side only Totem, Banshee and Jamboree is currently licensed in a
way that allows them to stay. (Applications not able to use the non-free
codec can stay of course, but I assume that if proprietary codec support
is included you want to steer users in the direction of the apps having
this support by only including such by default). 

Be also aware that mp3 is the only patented codec which is available
under terms that make a setup like this even feasible in some form. So
even if mp3 support was included I doubt it would provide Eric will full
satisfaction. No other major codec patents is available under a pay-once
license instead they are available under licenses which quickly take
them up to around 1 million USD a year (per codec). Also in regards to
mp3 the pay-once license, it only covers desktop decoding usage. It do
not cover use on any form of embedded device or encoding (both with
costs 2.50 per unit with no annual price cap). Due to these limitations
the implementation can not be under the LGPL or the GPL (which takes
Eric's lame example out of the picture).

So to answer Eric, at Fluendo we are working with distributions trying
to figure out how to package/distribute codecs in a way that make it as
transparent as possible for the user. But this is a hard process both in
technical terms and legal sense as all these codec patents are available
under different terms including API restrictions, branding requirements,
platform allowed supported, use case limitations and so on. Finding a
way that allows combining these with free software without abandoning
the principles of trying to keep as much or even all the software open
source is hard and takes time both to sort through the legal barriers,
but also implementing systems that are able to solve the technical
problems arising due to the legal restrictions.

I think it is unfair to the major distributions to claim they are not
caring about this issue. They are and they know very well that it is an
issue causing pain for their users. But I think they deserve credit for
trying to approach the issue in a manner that the eventual introduction
of such codecs etc., will be one where it also serves as a pathway to
help migrate more people over to free codecs. 

Red Hat for instance recently hired Monty from the Xiph.org project to
help improve the performance and quality of the xiph.org codecs and also
move general multimedia support in Red Hat and Fedora forward. And
Novell has been writing Banshee under the MIT license among other things
in order to be able to provide a music player that can be bundled with
non-free codecs. So things are happening and we just have to accept that
Rome wasn't built in a day. 

Christian





From alan at redhat.com  Wed Mar 29 10:14:59 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Mar 2006 05:14:59 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143584440.3095.58.camel@vroomfondel.internal.datastacks.com>
References: <20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
	<20060328101331.GB12588@devserv.devel.redhat.com>
	<1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
	<20060328212959.GA30334@devserv.devel.redhat.com>
	<1143584440.3095.58.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060329101459.GA11828@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 05:20:40PM -0500, Peter Jones wrote:
> For all thinkpads that have this turned on it's for BIOS backup/restore
> features, a and other related features that the user (at least
> theoretically) paid for and may still want.  Right now we're trashing
> them.
> 
> I think ThinkPads make up more than 1% of cases, but I've got no real
> data to prove it with.

This is one of the problems. On a thinkpad the HPA is used to hide stuff,
and on many boxes its used in a way we want to undo. In theory its just a case
of installers doing partitioning right and maybe snooping the DMI tables to
see if its a thinkpad... in theory 8)

> > Looks basically sane. You have to run the ACPI taskfiles from the BIOS first
> > however or you are out of spec and anything can happen (although fortunately
> > it ususally doesnt)
> 
> Ugh.  Ok, I've got some reading to do before I get this in.  Thanks for
> the info.

The ACPI taskfile stuff is cooking already and should be mainstream soon. I
would suggest not worrying about it for the moment. You will need to sort the
HPA out after the ACPI stuff runs once it is in as on the thinkpad it also
edits the HPA settings when those run

> > Problems in the patch aside from that
> > 
> > #1:	HPA support and active state are in the identify data so you should
> > 	consult that (which is boot time cached).
> 
> drive->capacity64 comes from one of id->lba_capacity_2,
> id->lba_capacity, or CHS .  Is there something else you mean I should be
> consulting the identify data for?

Word 85 bit 10, HPA is enabled
Word 82 bit 10, HPA is supported

if I remember the bit rightly. 

> Well, currently that's not a problem -- in the second patch I have the
> set_capacity() calls.  But in this patch it's not needed, because we
> always disable HPA no matter what before the gendisk is initialized at
> all, so the block layer has never known about the smaller size.

Thats fine then

> disable it entirely for IDE, which means if we ever want to do anything
> other than just disable it, we need control to be somewhere that can
> examine the system to see what we've done.  Sadly, that probably means
> userland.

I've not dug into the thinkpad far enough but I would guess that something 
like

	read partition table
	work out last sector used
	if ( beyond hpa)
		disable hpa
	else
		honour hpa

will give the right answer for almost all cases, if not all. Not sure what you
do if the drive has no partition table. In the MS world this gets dealt with by
the user installing 'disk manager' type software so the user doesn't end up
directly answering questions about the HPA but answers them indirectly.




From fedora at camperquake.de  Wed Mar 29 10:20:36 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 29 Mar 2006 12:20:36 +0200
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143610008.2249.5.camel@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<1143549705.4097.30.camel@pensja.lam.pl>
	<1143569558.10632.41.camel@localhost>
	<1143573760.4097.59.camel@pensja.lam.pl>
	<1143610008.2249.5.camel@localhost.localdomain>
Message-ID: <20060329122036.5dd38abc@soran.addix.net>

Hi.

On Tue, 28 Mar 2006 21:26:48 -0800, Per Bjornsson wrote:

> Tremor is the now BSD-licensed _fixed-point_ Ogg Vorbis decoder,
> specifically geared toward processors which don't have any
> floating-point capabilities. The units that do play Ogg Vorbis are not
> necessarily any more powerful than the others

>From what I've read decoding Vorbis takes more power than MP3. Maybe
not much, but there usually are no cycles to spare in a player.

And, of course, you can buy cheap MP3 decoder chips, which do all the
heavy lifting for you, so your main CPU can be quite flimsy. I do not
know whether there are commercially available ogg decoder chips.



From alan at redhat.com  Wed Mar 29 10:24:29 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Mar 2006 05:24:29 -0500
Subject: Fedora's way forward
In-Reply-To: <1143604473.13153.13.camel@urashima.dclam.com>
References: <20060328164519.GA18879@mortise.boston.redhat.com>
	<20060328165213.GC25693@thyrsus.com>
	<20060328170330.GB18879@mortise.boston.redhat.com>
	<20060328171909.GC26011@thyrsus.com>
	<1143567704.3752.79.camel@yoda.loki.me>
	<20060328175822.GA26482@thyrsus.com> <44297D5C.90504@warmcat.com>
	<1143570951.10632.55.camel@localhost>
	<20060328133620.31f0f5c0.seanlkml@sympatico.ca>
	<1143604473.13153.13.camel@urashima.dclam.com>
Message-ID: <20060329102429.GB11828@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 10:54:33PM -0500, Matthew Swasey wrote:
> That's what I want to know.  Why is everyone so hell bent on world
> domination?  This attitude has been around since I first got into Linux
> (1995) and I did not understand it then.  I use Fedora (and other disros

Linus finger entry way back when Linux started and where you went to check
the status of the kernel (this is way before blogs and other such things)
always had a joking Plan of "world domination". Unfortunately while Linus and
most of the Linux people take it as a joke some folks get a bit carried away
and have forgotten the origin.




From fedora at camperquake.de  Wed Mar 29 10:29:34 2006
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 29 Mar 2006 12:29:34 +0200
Subject: Fedora's way forward
In-Reply-To: <1143614766.3802.621.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
Message-ID: <20060329122934.42a82da3@soran.addix.net>

Hi.

On Wed, 29 Mar 2006 12:16:06 +0530, Rahul Sundaram wrote:

> Fedora. What about WMV? Flash? Sun Java? We have over seventy
> downstream derivative distributions of Fedora

Uh, we have? Can you name some, please? It's the first time I've
heard of that :)



From sundaram at fedoraproject.org  Wed Mar 29 10:39:23 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 16:09:23 +0530
Subject: Fedora's way forward
In-Reply-To: <20060329122934.42a82da3@soran.addix.net>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329122934.42a82da3@soran.addix.net>
Message-ID: <1143628763.3802.623.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-29 at 12:29 +0200, Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 29 Mar 2006 12:16:06 +0530, Rahul Sundaram wrote:
> 
> > Fedora. What about WMV? Flash? Sun Java? We have over seventy
> > downstream derivative distributions of Fedora
> 
> Uh, we have? Can you name some, please? It's the first time I've
> heard of that :)

http://fedoraproject.org/wiki/DerivedDistributions

Rahul



From fedora at adslpipe.co.uk  Wed Mar 29 10:44:08 2006
From: fedora at adslpipe.co.uk (Andy Burns)
Date: Wed, 29 Mar 2006 11:44:08 +0100
Subject: Gutenprint core or extras
Message-ID: <442A64F8.1060700@adslpipe.co.uk>

Does anyone know (or have views on) whether Gutenprint 5.x is likely to 
directy "upgrade" gimp-print 4.x in FC6, or will it go through Extras first?



From alan at redhat.com  Wed Mar 29 10:49:13 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Mar 2006 05:49:13 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
Message-ID: <20060329104913.GD11828@devserv.devel.redhat.com>

On Tue, Mar 28, 2006 at 02:31:19PM -0800, Schlaegel wrote:
> This presents the obvious question: why don't we just check the iso on
> the media instead of the media itself, and thus remove this long
> standing problem.

If we wanted to do that we would need to do it by walking the mounted iso
file system. The moment we deal with the raw device the kernel starts treating
it as a device not a file system so we get readehead into the twilight zone.

However I'm glad you asked because you've made me realise we may have the bits
to deal with this as of FC4/5. Specifically we could use the device mapper to
create an ISO sized mapping of the relevant chunk of the CD and check that...

That might just work

Alan



From seanlkml at sympatico.ca  Wed Mar 29 10:58:32 2006
From: seanlkml at sympatico.ca (sean)
Date: Wed, 29 Mar 2006 05:58:32 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329063345.GB6131@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
Message-ID: <BAYC1-PASMTP024B82B931B10FF13BE95AAED00@CEZ.ICE>

On Wed, 29 Mar 2006 01:33:45 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> If we say to J. Random "No, we won't support MP3, shut up it's bad
> for you", it's just as if we tried to sell him on an ODF-only word
> processor by saying "no, you really don't want to touch all those
> cruddy old Word documents".

Nope, that's not what we're saying.   

We're saying our unenecumbered open source distribution can not 
provide MP3 support because of reasons beyond our control.   We 
wish that we could, but the political/economic realities prohibit it
without giving up on our primary objectives which are very clearly 
laid out.

Therefore, we are continuing to work on providing better and better
open source solutions so that we can encompass the pragmatic needs of
more and more average users with open source solutions.   

We're not working on proprietary solutions, and we are not interested 
in them.   But if you are, there are other distributions more suited to 
your priorities than Fedora.   Every distribution need not be targeting
the same audience.

Sean



From jdesbonnet at gmail.com  Wed Mar 29 11:35:58 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Wed, 29 Mar 2006 12:35:58 +0100
Subject: Fedora's way forward
In-Reply-To: <1143611158.3802.605.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com> <442A1ACE.6050901@stasis.org>
	<1143611158.3802.605.camel@sundaram.pnq.redhat.com>
Message-ID: <1cef3e950603290335s58b4b6dfp21cab300f8c247dc@mail.gmail.com>

This is not indended as a practical solution or idea (the thought
occured to me after a morning espresso fix):

Imagine a small computing device (USB powered memory stick form
factor), containing a processor and memory just powerful enough to
transcode proprietary, patent encumbered media formats into non-patent
encumbered format (note: often transcoding does not require the CPU
resources of a complete decode). The device contains proprietary (but
flashable) firmware with technology licenced from the various rights
holders. From a licencing standpoint it's just like a consumer DVD
player but without all the hardware -- the patent encumbered firmware
is confined to the smallest possible computing space.  </fantasy> :-)
Joe.


On 3/29/06, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> On Wed, 2006-03-29 at 00:27 -0500, Rowan Kerr wrote:
> > Eric S. Raymond wrote:
> > > OK.  So the next question is, do *Red Hat's* goals no longer include
> > > world desktop domination?  Because if that's true, I need to find a distro
> > > that hasn't ... er ... lost its idealism.
>
> Now when does including mp3 decoders in Fedora equate to world desktop
> domination by Red Hat or idealism?  You have every reason to stutter
> there being a open source evangelist - perceived or otherwise.
>
> >
> > This is what I have been concerned about for a while now. It looks like
> > the next commercial version of Suse will have all kinds of media support
> > through RealPlayer instead of the FOSS-only HelixPlayer. What will the
> > next version of RHEL provide?
>
> Thats a irrelevant discussion for Fedora-devel list really.
>
>
> Rahul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From laroche at redhat.com  Wed Mar 29 13:00:44 2006
From: laroche at redhat.com (Florian La Roche)
Date: Wed, 29 Mar 2006 15:00:44 +0200
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
	<Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
Message-ID: <20060329130044.GB3411@dudweiler.stuttgart.redhat.com>

> The simple fact is GNU/Linux could do much better on this front and 
> it appears we have no real plan or general consensus on how to proceed to 
> in address this issue on a global scale.

A full ack on this, we would solve a lot of items if we could move
forward to have a standard lib for all this. But it will be very
hard to have agreement on how to solve it and even more to make
projects move over from their current ways.

regards,

Florian La Roche



From skadz1 at gmail.com  Wed Mar 29 13:26:46 2006
From: skadz1 at gmail.com (Ryan Skadberg)
Date: Wed, 29 Mar 2006 08:26:46 -0500
Subject: Mirrorlist Issues
Message-ID: <8719b8230603290526o1af6087rab798c008e862f6a@mail.gmail.com>

It seems that with FC5, the rawhide mirror list has changed to being
just one round-robin DNS name.  This is fine, except that it causes
yum to not be able to retry things on other mirrors, since it just
sees one mirror on the mirror list, so I am constantly getting:

---> Downloading header for gnome-applets-debuginfo to pack into
transaction set.
http://download.fedoraproject.org/pub/fedora/linux/core/development/i386/debug/gnome-applets-debuginfo-2.14.0-3.i386.rpm:
[Errno 14] HTTP Error 404: Date: Wed, 29 Mar 2006 13:23:01 GMT
Server: Apache/2.0.46 (Red Hat)
Content-Length: 392
Connection: close
Content-Type: text/html; charset=iso-8859-1
Trying other mirror.
Error: failure: debug/gnome-applets-debuginfo-2.14.0-3.i386.rpm from
development: [Errno 256] No more mirrors to try.

And since there is just the one host on the mirror list, yum dies.  If
there were multiple mirrors on the list, it could then try again on
other sites.  Since there is only one, it fails once and dies.  I get
this CONSTANTLY when trying to update rawhide and usually have to
restart yum 5 to 10 times before I can get all the headers downloaded
and then have to do it another 5-10 times to get the packages
downloaded.

Any chance we can change the mirror list back to being a real list of
mirrors so this problem goes away?

Thanks!
Skadz



From fedora at wir-sind-cool.org  Wed Mar 29 13:37:48 2006
From: fedora at wir-sind-cool.org (Michael Schwendt)
Date: Wed, 29 Mar 2006 15:37:48 +0200
Subject: Package names in FC5
In-Reply-To: <1143582471.3095.33.camel@vroomfondel.internal.datastacks.com>
References: <200603281356.17155.rkwasny@aurox.org>
	<20060328144218.92792ab4.fedora@wir-sind-cool.org>
	<1143582471.3095.33.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060329153748.3ef7bab3.fedora@wir-sind-cool.org>

On Tue, 28 Mar 2006 16:47:50 -0500, Peter Jones wrote:

> > No pattern. Core package developers can do what they want, and some of
> > them still don't seem to care that .fc3 is "newer than" .FC5 in RPM
> > version comparison.
> 
> That's a bit of an exaggeration.  It's not that we don't care, it's that
> it doesn't matter unless you're doing something *else* really dumb at
> the same time as *switching* between those two nomenclatures.
> 
> *yawn*.

No need to yawn. :) It has happened before that a package from Core was
moved to Extras or vice versa, and then you get the "switching" in updates
unless the different packagers agree on a common way.



From prarit at sgi.com  Wed Mar 29 13:59:49 2006
From: prarit at sgi.com (Prarit Bhargava)
Date: Wed, 29 Mar 2006 08:59:49 -0500
Subject: [Fedora-ia64-list] kernel 2.6.16-1.2097_FC6 unbootable on
	Itanium
In-Reply-To: <1143577639.44299c27b9026@www.jouy.inra.fr>
References: <1143577639.44299c27b9026@www.jouy.inra.fr>
Message-ID: <442A92D5.10402@sgi.com>

?meric Maschino wrote:
> Hi,
> 
> There's something wrong with kernel 2.6.16-1.2097_FC6. The last displayed
> message is "Freeing unused kernel memory: 400kB freed" and then nothing.
> kernel-2.6.16-1.2088_FC6 runs fine.
> 

I saw an error spit out while the RPM install was assembling the initrd. 
  I'll look into it.

P.



From cmadams at hiwaay.net  Wed Mar 29 14:23:38 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 29 Mar 2006 08:23:38 -0600
Subject: Fedora's way forward
In-Reply-To: <442A1ACE.6050901@stasis.org>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com> <442A1ACE.6050901@stasis.org>
Message-ID: <20060329142338.GA1376783@hiwaay.net>

Once upon a time, Rowan Kerr <rowan at stasis.org> said:
> This is what I have been concerned about for a while now. It looks like 
> the next commercial version of Suse will have all kinds of media support 
> through RealPlayer instead of the FOSS-only HelixPlayer. What will the 
> next version of RHEL provide?

I don't know what the next version of RHEL will provide, but as I
already said, the most recent version (and IIRC the version before that)
included RealPlayer, Acrobat Reader, Flash, and Java.  Even the old
boxed Red Hat Linux included many of those things; they just weren't
included in the download version (due to licensing restrictions).

-- 
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  Wed Mar 29 14:26:59 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 29 Mar 2006 08:26:59 -0600
Subject: Fedora's way forward
In-Reply-To: <20060329010235.GA3395@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
Message-ID: <20060329142659.GB1376783@hiwaay.net>

Once upon a time, Eric S. Raymond <esr at thyrsus.com> said:
> OK.  So the next question is, do *Red Hat's* goals no longer include
> world desktop domination?  Because if that's true, I need to find a distro
> that hasn't ... er ... lost its idealism.

If they'd "lost [their] idealism", they might include some of the things
you are complaining about.  You want it both ways, and you can't have
that.

If you think MP3, Flash, and Java are the missing "killer apps" to make
Fedora Core the desktop for world domination, why don't you take Fedora
Core, and those bits (getting licenses as needed), and release your own
"Raymond Linux" distribution?  Since everything in Fedora Core is fully
redistributable, you are free to do that.

-- 
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 tibbs at math.uh.edu  Wed Mar 29 14:48:50 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Wed, 29 Mar 2006 08:48:50 -0600
Subject: Anonymous CVS server not being updated?
Message-ID: <ufa4q1hb92l.fsf@epithumia.math.uh.edu>

I'm seeing plenty of commits on the fedora-cvs-commits list but those
changes aren't being reflected on the anonymous CVS server.  Was
something busted in the shift to the new server?

 - J<



From esr at thyrsus.com  Wed Mar 29 14:53:50 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 29 Mar 2006 09:53:50 -0500
Subject: Fedora's way forward
In-Reply-To: <1143614766.3802.621.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
Message-ID: <20060329145350.GA10714@thyrsus.com>

Rahul Sundaram <sundaram at fedoraproject.org>:
> You arent? The claim that mp3 wasnt patented followed up statements that
> Red Hat should pay up a patent license for half a million dollars surely
> looked like controversial to me from a open source advocate.

I never claimed MP3 wasn't patented, and $50K is not half a million.
Keep your facts straight, at least.  

> Thats exactly what would happen. You can talk about all you want about
> support open formats but if you dont actually build up volume nobody is
> going to use it. If mp3 was supported out of the box in Fedora, why
> would there be any incentive left for anyone to use ogg codecs?

Um...because Ogg is a better format?

> Those are Fedora users too. Should we abandon them?

Zealots drive me crazy.  Poke one in the wrong place and his brain
just shuts down entirely.

Read my lips: nobody is talking about 'abandoning' any user, distribution,
or format.  Adding support for what users actually want is not abandonment.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Wed Mar 29 14:55:24 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 29 Mar 2006 09:55:24 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329142659.GB1376783@hiwaay.net>
References: <20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
	<20060329142659.GB1376783@hiwaay.net>
Message-ID: <20060329145524.GB10714@thyrsus.com>

Chris Adams <cmadams at hiwaay.net>:
> If you think MP3, Flash, and Java are the missing "killer apps" to make
> Fedora Core the desktop for world domination, why don't you take Fedora
> Core, and those bits (getting licenses as needed), and release your own
> "Raymond Linux" distribution?  Since everything in Fedora Core is fully
> redistributable, you are free to do that.

I don't have the money or the lawyers to pull it off.  This sort of thing
is why we have commercial partners with office buidings.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From Axel.Thimm at ATrpms.net  Wed Mar 29 15:02:26 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 29 Mar 2006 17:02:26 +0200
Subject: Split-off package config from release note packages (was: Release
	Notes Errata - Wiki Freeze)
In-Reply-To: <1143558013.3140.15.camel@aglarond.local>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
	<1143558013.3140.15.camel@aglarond.local>
Message-ID: <20060329150226.GC13953@neu.nirvana>

On Tue, Mar 28, 2006 at 10:00:13AM -0500, Jeremy Katz wrote:
> On Tue, 2006-03-28 at 08:15 -0600, Jason L Tibbitts III wrote:
> > >>>>> "MM" == Matthew Miller <mattdm at mattdm.org> writes:
> > MM> Maybe a good idea to break the release notes out of the
> > MM> fedora-release package?
> > 
> > If fedora-release is getting love, I wonder if it would be possible to
> > remove the repositories from it as well.  They just cause problems for
> > those of us with local mirrors.

I would do it the other way, split out the package configuration into
a fedora-package-config subpackage.

> The entire point of fedora-release is basically to contain this stuff
> which ends up having to change at the last minute so that we can contain
> the number of changes which are needed when we're trying to build final
> trees.  Also, it means one stop shopping for changing from, say, Fedora
> to JoeBob's Distro :)

But then hell breaks loose and people accuse JoeBob of forking fedora,
when all he wanted to do is either provide decent mirrors (local or
not) for his users or additional repos. Having to replace
fedora-release to do that results in for example:

http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning

Please check out the package split that ATrpms has been providing for
FC3 and FC4:

http://atrpms.net/name/fedora-release/

contents are the same as for the monolithic fedora-release package,
users only get the freedom to replace package configuration with their
own liking.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/280647ce/attachment.sig>

From sundaram at fedoraproject.org  Wed Mar 29 15:06:14 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 20:36:14 +0530
Subject: Fedora's way forward
In-Reply-To: <20060329145350.GA10714@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
Message-ID: <1143644774.3802.634.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-29 at 09:53 -0500, Eric S. Raymond wrote:
> Rahul Sundaram <sundaram at fedoraproject.org>:
> > You arent? The claim that mp3 wasnt patented followed up statements that
> > Red Hat should pay up a patent license for half a million dollars surely
> > looked like controversial to me from a open source advocate.
> 
> I never claimed MP3 wasn't patented,

You claimed that mp3 patent doesnt affect decoders. 

>  and $50K is not half a million.
> Keep your facts straight, at least.  

Your calculations on $50 K for a patent license is already shown to be
wrong especially for a license that would be compatible with open source
licenses. 

> 
> > Thats exactly what would happen. You can talk about all you want about
> > support open formats but if you dont actually build up volume nobody is
> > going to use it. If mp3 was supported out of the box in Fedora, why
> > would there be any incentive left for anyone to use ogg codecs?
> 
> Um...because Ogg is a better format?

We already support the better format very well. Adding support for
patent restricted formats in Fedora is just against the primary goals of
the project IMO. 


> 
> > Those are Fedora users too. Should we abandon them?
> 
> Zealots drive me crazy.  Poke one in the wrong place and his brain
> just shuts down entirely.
> 
> Read my lips: nobody is talking about 'abandoning' any user, distribution,
> or format.  Adding support for what users actually want is not abandonment.

How do you add propose that we add support for mp3 formats in Fedora
without abandoning the rights for derivative distributions to make
modifications and redistribute all the code included in Fedora? Again
its not merely proprietary but also shackled by patents. Are you happy
with just adding support for mp3 or would WMA support follow up on that
next?


Rahul




From clydekunkel7734 at cox.net  Wed Mar 29 15:15:00 2006
From: clydekunkel7734 at cox.net (Clyde E. Kunkel)
Date: Wed, 29 Mar 2006 10:15:00 -0500
Subject: Fedora's way forward
In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
Message-ID: <442AA474.2040002@cox.net>

Eric S. Raymond wrote:
<snip>

> It's 2006, people.  The Web is fifteen years old.  Even non-techies
> have had a decade to form expectations about what constitutes a base
> level of functionality.  We don't have a prayer -- not a hope, not a
> snowball's chance in a supernova -- of becoming competitive for
> home and business-desktop use without delivering to those
> expectations.  
> 
> <snip>

Maybe its all in the dress code:

http://linux.slashdot.org/linux/06/03/28/1956211.shtml


-- 
Regards,

Old Fart
(my reply-to address is "munged" to defeat spambots)



From seanlkml at sympatico.ca  Wed Mar 29 15:16:50 2006
From: seanlkml at sympatico.ca (sean)
Date: Wed, 29 Mar 2006 10:16:50 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329145350.GA10714@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
Message-ID: <BAYC1-PASMTP1289109D1E86994A1A45F1AED00@CEZ.ICE>

On Wed, 29 Mar 2006 09:53:50 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:


> > Those are Fedora users too. Should we abandon them?
> 
> Zealots drive me crazy.  Poke one in the wrong place and his brain
> just shuts down entirely.
> 
> Read my lips: nobody is talking about 'abandoning' any user, distribution,
> or format.  Adding support for what users actually want is not abandonment.

Eric, you're getting stupid now.

There are other distributions which cater to your needs.  Are you so lost 
in your world domination zealotry that you just can't process that fact?

Fedora is an open source unencumbered distribution and is meant for open 
source developers and enthusiasts who just aren't interested in proprietary 
solutions.   Why can't you just accept that?   There are real people
who want just that.   Fedora meets their needs.

If you can take a break from your world domination zealotry you'll
see that there is no point trying to convince us of your view.  
You have your priorities and we have ours, you've made it clear
our views don't satisfy you.

We're not trying to convince you of anything, you're free to go about 
your business, using Linux in a way that meets your needs.  Please extend 
to us the same courtesy so everyone can get on with it.  You can use a 
distribution that is more to your liking, and we can have some peace 
from your pointless evangelicalism.

Sean



From rdieter at math.unl.edu  Wed Mar 29 15:21:54 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 29 Mar 2006 09:21:54 -0600
Subject: Anonymous CVS server not being updated?
In-Reply-To: <ufa4q1hb92l.fsf@epithumia.math.uh.edu>
References: <ufa4q1hb92l.fsf@epithumia.math.uh.edu>
Message-ID: <442AA612.6050409@math.unl.edu>

Jason L Tibbitts III wrote:
> I'm seeing plenty of commits on the fedora-cvs-commits list but those
> changes aren't being reflected on the anonymous CVS server.

I've been seeing similar that for awhile now... stuff (mostly kde bits, 
admittedly) appearing in devel/rawhide buildreports, but taking 1-2 days 
before fetchable via cvs.

-- Rex



From peter at thecodergeek.com  Wed Mar 29 15:35:37 2006
From: peter at thecodergeek.com (Peter Gordon)
Date: Wed, 29 Mar 2006 07:35:37 -0800 (PST)
Subject: Fedora's way forward
In-Reply-To: <20060329145350.GA10714@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
Message-ID: <43336.127.0.0.1.1143646537.squirrel@www.thecodergeek.com>

Eric S. Raymond said:
>> Thats exactly what would happen. You can talk about all you want about
>> support open formats but if you dont actually build up volume nobody is
>> going to use it. If mp3 was supported out of the box in Fedora, why
>> would there be any incentive left for anyone to use ogg codecs?
>
> Um...because Ogg is a better format?

I'd wager that a great many people who simply "use" their computers do not
really care about the technical aspects of the format in which their music is
stored, so long as they can easily listen to it, and copy it it to their
portable music player, or burn audio CDs from it, et al.

On a side note, Ogg is merely a container format. The actual audio codec used
in most cases is Vorbis; though it can hold other codec streams such as FLAC,
too.
-- 
Peter Gordon (codergeek42)
This message was sent through a webmail
    interface, and thus not signed.



From Axel.Thimm at ATrpms.net  Wed Mar 29 15:40:04 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Wed, 29 Mar 2006 17:40:04 +0200
Subject: Split-off package config from release note packages (was:
	Release Notes Errata - Wiki Freeze)
In-Reply-To: <20060329150226.GC13953@neu.nirvana>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
	<1143558013.3140.15.camel@aglarond.local>
	<20060329150226.GC13953@neu.nirvana>
Message-ID: <20060329154004.GD13953@neu.nirvana>

On Wed, Mar 29, 2006 at 05:02:26PM +0200, Axel Thimm wrote:
> On Tue, Mar 28, 2006 at 10:00:13AM -0500, Jeremy Katz wrote:
> > On Tue, 2006-03-28 at 08:15 -0600, Jason L Tibbitts III wrote:
> > > >>>>> "MM" == Matthew Miller <mattdm at mattdm.org> writes:
> > > MM> Maybe a good idea to break the release notes out of the
> > > MM> fedora-release package?
> > > 
> > > If fedora-release is getting love, I wonder if it would be possible to
> > > remove the repositories from it as well.  They just cause problems for
> > > those of us with local mirrors.
> 
> I would do it the other way, split out the package configuration into
> a fedora-package-config subpackage.
> 
> > The entire point of fedora-release is basically to contain this stuff
> > which ends up having to change at the last minute so that we can contain
> > the number of changes which are needed when we're trying to build final
> > trees.  Also, it means one stop shopping for changing from, say, Fedora
> > to JoeBob's Distro :)
> 
> But then hell breaks loose and people accuse JoeBob of forking fedora,
> when all he wanted to do is either provide decent mirrors (local or
> not) for his users or additional repos. Having to replace
> fedora-release to do that results in for example:
> 
> http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning
> 
> Please check out the package split that ATrpms has been providing for
> FC3 and FC4:
> 
> http://atrpms.net/name/fedora-release/
> 
> contents are the same as for the monolithic fedora-release package,
> users only get the freedom to replace package configuration with their
> own liking.

Bugzilla'd as

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

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/70cea117/attachment.sig>

From ivg2 at cornell.edu  Wed Mar 29 15:47:10 2006
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Wed, 29 Mar 2006 10:47:10 -0500
Subject: Fedora's way forward
In-Reply-To: <BAYC1-PASMTP1289109D1E86994A1A45F1AED00@CEZ.ICE>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<20060329063345.GB6131@thyrsus.com>	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>	<20060329145350.GA10714@thyrsus.com>
	<BAYC1-PASMTP1289109D1E86994A1A45F1AED00@CEZ.ICE>
Message-ID: <442AABFE.8080901@cornell.edu>


>
> We're not trying to convince you of anything, you're free to go about 
> your business, using Linux in a way that meets your needs.  Please extend 
> to us the same courtesy so everyone can get on with it.  
>   
While I agree with your overall point that keeping Fedora open is a a 
good thing, kindly use singular instead of plural, or qualify which 
group of people you're representing on a community list.

I certainly see "world domination" as a worthy goal, and "open source 
solutions" as a means/strategy to achieving that goal in the long run. A 
"solution" addresses the problem of as many people as possible, 
otherwise it's not particularly useful. I think you'd agree that we [ 
fedora developers ] are designing software with the end user in mind, 
and not as a goal in itself. Eric's questions certainly seems important 
to answer - there's no reason to be hostile.





From che666 at gmail.com  Wed Mar 29 15:49:40 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Wed, 29 Mar 2006 17:49:40 +0200
Subject: Bootsplash?
In-Reply-To: <1143599135.2192.1.camel@scrappy.miketc.com>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost> <1143302775.2605.41.camel@dimi>
	<20060328114818.4024f4c6@alkaid.a.lan> <e0bva5$er8$1@sea.gmane.org>
	<20060328214417.730ccc2d@alkaid.a.lan>
	<1143599135.2192.1.camel@scrappy.miketc.com>
Message-ID: <e99d27470603290749q44bb16a2o37ebfc08f9eed2c@mail.gmail.com>

2006/3/29, Mike Chambers <mike at miketc.com>:
> On Tue, 2006-03-28 at 21:44 +0200, Andreas Bierfert wrote:
> > On Tue, 28 Mar 2006 12:29:25 -0600
> > Ian Pilcher <i.pilcher at comcast.net> wrote:
> >
> > > /usr/sbin/splashy: error while loading shared libraries:
> > > libdirectfb_fbdev.so: cannot open shared object file: No such file or
> > > directory
> > >
> >
> > Hu yes :) that is related to the directfb bug... wait I will upload a fixed
> > directfb version to the same location...
>
> This is the latest error I get when trying to run splashy...
>
> [root at scrappy init.d]# splashy test
> [root at scrappy init.d]# FATAL: video.c <440>:
>        (#) DirectFBError [DirectFBCreate (&video->dfb)]: General I/O
> error!
>
> [root at scrappy init.d]# rpm -qa | grep splashy
> splashy-0.1.6-1
> [root at scrappy init.d]# rpm -qa | grep direct
> directfb-0.9.24-6
> directfb-devel-0.9.24-6
>
> --
> Mike Chambers
> Madisonville, KY
>
> "It's only funny until someone gets hurt, then it's hilarious!"
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

same problem here



From andy at warmcat.com  Wed Mar 29 16:02:40 2006
From: andy at warmcat.com (Andy Green)
Date: Wed, 29 Mar 2006 17:02:40 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060329145524.GB10714@thyrsus.com>
References: <20060328104659.GI12588@devserv.devel.redhat.com>	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>	<20060328155740.GC25098@thyrsus.com>	<20060328105912.29cad8e0.seanlkml@sympatico.ca>	<20060328163215.GA25428@thyrsus.com>	<20060328175608.GA24725@devserv.devel.redhat.com>	<20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>	<20060329010235.GA3395@thyrsus.com>	<20060329142659.GB1376783@hiwaay.net>
	<20060329145524.GB10714@thyrsus.com>
Message-ID: <442AAFA0.1010608@warmcat.com>

Eric S. Raymond wrote:

>> If you think MP3, Flash, and Java are the missing "killer apps" to make
>> Fedora Core the desktop for world domination, why don't you take Fedora
>> Core, and those bits (getting licenses as needed), and release your own
>> "Raymond Linux" distribution?  Since everything in Fedora Core is fully
>> redistributable, you are free to do that.
> 
> I don't have the money or the lawyers to pull it off.  This sort of thing
> is why we have commercial partners with office buidings.

If you look a bit further in that direction you'll see you're asking 
RHAT shareholders to take risks you aren't willing to take yourself.

This stuff is Free software, "we" don't have "commercial partners" as if 
it was proprietary and owned by "us" and it is a strategic decision for 
some big boss to make.  Unless the license forbids it companies are 
welcome the same as individuals to use and copy around the code. 
Thereby nobody, no matter who, is able to stand beside a big switch that 
decides if "commercial partners" are to be allowed today or not.  Only 
the individuals choosing their project license can control it.

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

From sundaram at fedoraproject.org  Wed Mar 29 16:07:04 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 29 Mar 2006 21:37:04 +0530
Subject: Fedora's way forward
In-Reply-To: <442AABFE.8080901@cornell.edu>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
	<BAYC1-PASMTP1289109D1E86994A1A45F1AED00@CEZ.ICE>
	<442AABFE.8080901@cornell.edu>
Message-ID: <1143648425.3802.650.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-29 at 10:47 -0500, Ivan Gyurdiev wrote:
> >
> > We're not trying to convince you of anything, you're free to go about 
> > your business, using Linux in a way that meets your needs.  Please extend 
> > to us the same courtesy so everyone can get on with it.  
> >   
> While I agree with your overall point that keeping Fedora open is a a 
> good thing, kindly use singular instead of plural, or qualify which 
> group of people you're representing on a community list.
> 
> I certainly see "world domination" as a worthy goal, and "open source 
> solutions" as a means/strategy to achieving that goal in the long run. 

I wouldnt consider buying a mp3 patent license a "open source
solution". 


> A 
> "solution" addresses the problem of as many people as possible, 
> otherwise it's not particularly useful. I think you'd agree that we [ 
> fedora developers ] are designing software with the end user in mind, 
> and not as a goal in itself. Eric's questions certainly seems important 
> to answer - there's no reason to be hostile

If the questions are "smart" then yes. Before you ask, try finding the
answer in the web (Mp3 patents are not just for encoders and $50 K
wouldnt get a patent license for lame) . Try reading the manual
(http://fedora.redhat.com/About)  Try reading the FAQ
(http://fedoraproject.org/wiki/FAQ). Try to find an answer by asking a
skilled friend (might be a lawyer wife) 

Be courteous ( That means dont call people corporate cowards or zealots
for example). Google is your friend (search for mp3 patent license) . In
fact, it's a very good idea to do a keyword search for words relating to
your problem on the newsgroup or mailing list archives before you post.
There are very useful tips from http://www.catb.org/~esr/faqs/smart-
questions.html. 


Rahul



From seanlkml at sympatico.ca  Wed Mar 29 16:07:23 2006
From: seanlkml at sympatico.ca (sean)
Date: Wed, 29 Mar 2006 11:07:23 -0500
Subject: Fedora's way forward
In-Reply-To: <442AABFE.8080901@cornell.edu>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
	<BAYC1-PASMTP1289109D1E86994A1A45F1AED00@CEZ.ICE>
	<442AABFE.8080901@cornell.edu>
Message-ID: <BAYC1-PASMTP081041397F9A0BE6B59593AED00@CEZ.ICE>

On Wed, 29 Mar 2006 10:47:10 -0500
Ivan Gyurdiev <ivg2 at cornell.edu> wrote:

> > We're not trying to convince you of anything, you're free to go about 
> > your business, using Linux in a way that meets your needs.  Please extend 
> > to us the same courtesy so everyone can get on with it.  
> >   
> While I agree with your overall point that keeping Fedora open is a a 
> good thing, kindly use singular instead of plural, or qualify which 
> group of people you're representing on a community list.

Point taken.   However, the Fedora goals are clearly laid out.  You either 
subscribe to them or you're not going to be very satisfied.

> I certainly see "world domination" as a worthy goal, and "open source 
> solutions" as a means/strategy to achieving that goal in the long run. A 
> "solution" addresses the problem of as many people as possible, 
> otherwise it's not particularly useful. I think you'd agree that we [ 
> fedora developers ] are designing software with the end user in mind, 
> and not as a goal in itself. Eric's questions certainly seems important 
> to answer - there's no reason to be hostile.

Sure, the point was really to drive home that it's easy to call someone a 
zealot, as Eric had just done to Rahul in the post I was responding to
and in a way that was no more or less hostile.

Eric's questions have already been answered many times over and he's 
not adding anything new.  It's just a distraction and inappropriate
for this list considering the core Fedora objectives.

Take a look at the Fedora objectives, it's not about designing _any_ kind 
of software with the end user in mind, it's about designing open source 
and unencumbered software with the end user in mind.


Sean



From jkeating at redhat.com  Wed Mar 29 16:33:59 2006
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 29 Mar 2006 08:33:59 -0800
Subject: Mirrorlist Issues
In-Reply-To: <8719b8230603290526o1af6087rab798c008e862f6a@mail.gmail.com>
References: <8719b8230603290526o1af6087rab798c008e862f6a@mail.gmail.com>
Message-ID: <1143650039.3752.150.camel@yoda.loki.me>

On Wed, 2006-03-29 at 08:26 -0500, Ryan Skadberg wrote:
> Any chance we can change the mirror list back to being a real list of
> mirrors so this problem goes away?
> 

We're in the process of moving them back.  CVS issues right now prevent
any changes.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/48b21ff3/attachment.sig>

From pemboa at gmail.com  Wed Mar 29 16:36:06 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 29 Mar 2006 10:36:06 -0600
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060329130044.GB3411@dudweiler.stuttgart.redhat.com>
References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
	<Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
	<20060329130044.GB3411@dudweiler.stuttgart.redhat.com>
Message-ID: <16de708d0603290836s6d580f44v2e652255a824827e@mail.gmail.com>

On 3/29/06, Florian La Roche <laroche at redhat.com> wrote:
>
> > The simple fact is GNU/Linux could do much better on this front and
> > it appears we have no real plan or general consensus on how to proceed
> to
> > in address this issue on a global scale.
>
> A full ack on this, we would solve a lot of items if we could move
> forward to have a standard lib for all this. But it will be very
> hard to have agreement on how to solve it and even more to make
> projects move over from their current ways.
>
> regards,
>
> Florian La Roche
>
> I think the process of getting other projects to use this "standard" would
be to put some though into the design and mark multiple backends and
multiple interfaces part of the design. If there are libs, modules,
languages binds, etc with as little dependancy hell as possible, I think
projects will eventually gravitate to this solution. I know I wouldn't roll
my own config parser if there is a perfectly good one already included on my
system , or which can easily be added to any system.

Arthur

--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/6075f205/attachment.htm>

From dwmw2 at infradead.org  Wed Mar 29 16:54:53 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 29 Mar 2006 17:54:53 +0100
Subject: Fedora's way forward
In-Reply-To: <20060328104659.GI12588@devserv.devel.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
Message-ID: <1143651293.5600.228.camel@pmac.infradead.org>

On Tue, 2006-03-28 at 05:46 -0500, Alan Cox wrote:
> If you'd like additional proprietary third party material such as real
> player and IBM Java nobody is stopping you.

Those are two examples where Fedora really _could_ catch up. We should
really concentrate on getting gcjwebplugin and swfdec (or gnash)
shippable by FC6.

-- 
dwmw2



From db-fedora at 3di.it  Wed Mar 29 16:57:38 2006
From: db-fedora at 3di.it (Davide Bolcioni)
Date: Wed, 29 Mar 2006 18:57:38 +0200
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<Pine.LNX.4.63.0603271037030.24007@master.geeklords.org>
Message-ID: <442ABC82.3000107@3di.it>

Shane Stixrud wrote:
> I find it hard to believe no one else sees the current complexity of 
> system/application configuration as undesirable? 

Just my $0.02, since this is a question which I often hear from Unix
newcomers, especially from Windows ... the current complexity is more
apparent than real, it still undesiderable, but not to the point that
just any apparent solution to said complexity would be adopted
willy-nilly. The problem is not that the current situation is optimal,
but that all proposed alternatives are subpar. At least as far as I
can tell from my personal experience thus far, YMMV.

> Is this problem too 
> big to be addressed?  Is there too much historical precedence involved?  
> Or is there a solid technical reason for not having a standardized 
> configuration file format?

There isn't, because the problem is not with the technical approach IMHO
but in the users, developers and administrators using the system, so the
current approach is best *social* compromise for an enviroment where
none of the involved parties is able to dictate policy.

Developers don't want to devote resources to configuration file
handling, because they force the use of configuration to paper over
deficiencies in their code in the first place; administrators don't want
to risk a system which they cannot control and fix; users don't want to
learn configuration files at all. So users change as little as necessary
in textual files which the administrators trust they can fix over a 9600
baud cellphone ssh session in a format the developer never bothered to
design in the first place.

Thank you for your consideration,
Davide Bolcioni



From alan at clueserver.org  Wed Mar 29 16:58:38 2006
From: alan at clueserver.org (alan)
Date: Wed, 29 Mar 2006 08:58:38 -0800 (PST)
Subject: Fedora's way forward
In-Reply-To: <1143651293.5600.228.camel@pmac.infradead.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
Message-ID: <Pine.LNX.4.64.0603290856100.3081@blackbox.fnordora.org>

On Wed, 29 Mar 2006, David Woodhouse wrote:

> On Tue, 2006-03-28 at 05:46 -0500, Alan Cox wrote:
>> If you'd like additional proprietary third party material such as real
>> player and IBM Java nobody is stopping you.
>
> Those are two examples where Fedora really _could_ catch up. We should
> really concentrate on getting gcjwebplugin and swfdec (or gnash)
> shippable by FC6.

I have not had good luck with swfdec.  It eats CPU on my AMD64 3700+. 
Gnash is supposed to concentrate on a later version of Flash, but I have 
not tried it.

Having flash and java "just work" for AMD64 users would be a big plus.

-- 
"Remember there is a big difference between kneeling down and bending over." - Frank Zappa



From tibbs at math.uh.edu  Wed Mar 29 17:06:19 2006
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Wed, 29 Mar 2006 11:06:19 -0600
Subject: Fedora's way forward
In-Reply-To: <1143651293.5600.228.camel@pmac.infradead.org> (David
	Woodhouse's message of "Wed, 29 Mar 2006 17:54:53 +0100")
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
Message-ID: <ufahd5h9o50.fsf@epithumia.math.uh.edu>

>>>>> "DW" == David Woodhouse <dwmw2 at infradead.org> writes:

DW> Those are two examples where Fedora really _could_ catch up. We
DW> should really concentrate on getting gcjwebplugin and swfdec (or
DW> gnash) shippable by FC6.

As I understand things, Red Hat has someone dedicated to
gcjwebplugin.  It's nontrivial; first, all of classpath needs an audit
and then the security manager has to be written.

Hopefully gcjwebplugin will be folded into classpath in the near
future and development will accelerate.

The last estimate I saw for a usable gcjwebplugin was six months.

 - J<



From dimi at lattica.com  Wed Mar 29 17:12:54 2006
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 29 Mar 2006 12:12:54 -0500
Subject: Fedora's way forward
References: <200603280950.k2S9oqre022074@snark.thyrsus.com><20060328104659.GI12588@devserv.devel.redhat.com><1143651293.5600.228.camel@pmac.infradead.org>
	<ufahd5h9o50.fsf@epithumia.math.uh.edu>
Message-ID: <08ef01c65354$0529c6a0$b6491b31@td612671>

From: "Jason L Tibbitts III" <tibbs at math.uh.edu>
> As I understand things, Red Hat has someone dedicated to
> gcjwebplugin.  It's nontrivial; first, all of classpath needs an audit
> and then the security manager has to be written.

While it's great that Red Hat does this, I don't think this is a
big deal from a consumer perspective. Java has been dead as disco
on the web for some time, there are precious few sites that use it.

It sucks so badly (in Linux or Windows, it doesn't really matter)
that I refuse to even visit sites that use it. I can not fathom
what would posses someone to still use it on the internet in this
day and age.

It may be useful in intranets, which is why it makes sense for Red Hat
to have a working solution to this problem. But that's not a consumer
level problem.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From pjones at redhat.com  Wed Mar 29 17:37:40 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 29 Mar 2006 12:37:40 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060328221303.GA29073@devserv.devel.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
Message-ID: <1143653861.18075.8.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 17:13 -0500, Alan Cox wrote:
> On Tue, Mar 28, 2006 at 05:04:40PM -0500, Jeff Spaleta wrote:
> > Or to ask it another way... if you use ide=nodma  and mediacheck
> > succeeds when before it failed.. does that mean that you should then
> > use ide=nodma  when doing the actual install on that system?
> 
> Nope. The problem is a CD-R track looks something like this:
> 
> <track>
> [ISO fs]
> [0-150K or so of undefined]
> <end of track>
> 
> and the catalogue (track listing) contains various bits of magic, your drive
> serial number and start/end of each track. But that is imprecise.

mediacheck reads isofs, not just the table of contents.  At no time does
it perform a read(2), nor any other operation, which would result in an
access of any block after the end of the isofs.

> On the other hand the mounted isofs image has a known size so the isofs itself
> won't try and read or prefetch outside it.

I don't think that adequately explains what's going on here.  In
mediacheck, we never try to read the lead-out, much less the possibly
non-de-iced part of the disk.  At all.  Also, we see the same errors on
pressed CDs and DVDs, which IIRC do not have the less well defined
tracks that CD-Rs do.

The block layer (or below) does the bogus prefetch.  What inhibits this
behavior when you're accessing through a filesystem driver?

I think we have exactly the same problem there, and people have
witnessed accesses through the FS fail near the end of the disk with our
install media.  To me, it looks like the same behavior.

-- 
  Peter



From tromey at redhat.com  Wed Mar 29 17:31:58 2006
From: tromey at redhat.com (Tom Tromey)
Date: 29 Mar 2006 10:31:58 -0700
Subject: Fedora's way forward
In-Reply-To: <ufahd5h9o50.fsf@epithumia.math.uh.edu>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<ufahd5h9o50.fsf@epithumia.math.uh.edu>
Message-ID: <m38xqtrwc1.fsf@localhost.localdomain>

>>>>> "Jason" == Jason L Tibbitts <tibbs at math.uh.edu> writes:

Jason> As I understand things, Red Hat has someone dedicated to
Jason> gcjwebplugin.

Yes, that's true.  Gary is working on the security audit, starting
with writing test cases and fixing all places in the class library
which require a call into the security manager.  (There are other
tasks after this one...)

Jason> Hopefully gcjwebplugin will be folded into classpath in the near
Jason> future and development will accelerate.

Yeah, that's the plan.  I think Michael Koch wanted one
browser-crashing bug to be fixed before merging it all into Classpath.
gcj imports classpath on a fairly regular basis.  I'd expect the web
plugin code to be in GCC 4.2, though whether it is enabled depends on
the security situation.

Jason> The last estimate I saw for a usable gcjwebplugin was six
Jason> months.

Perhaps a bit of a stretch goal.  This is a very important application
for us, but we're trying to do a lot this year: 1.5 language and
library, improvements in performance and memory use, finish Swing,
etc.

Tom



From pjones at redhat.com  Wed Mar 29 17:40:09 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 29 Mar 2006 12:40:09 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060329104913.GD11828@devserv.devel.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
	<20060329104913.GD11828@devserv.devel.redhat.com>
Message-ID: <1143654010.18075.12.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-29 at 05:49 -0500, Alan Cox wrote:
> On Tue, Mar 28, 2006 at 02:31:19PM -0800, Schlaegel wrote:
> > This presents the obvious question: why don't we just check the iso on
> > the media instead of the media itself, and thus remove this long
> > standing problem.
> 
> If we wanted to do that we would need to do it by walking the mounted iso
> file system. The moment we deal with the raw device the kernel starts treating
> it as a device not a file system so we get readehead into the twilight zone.
> 
> However I'm glad you asked because you've made me realise we may have the bits
> to deal with this as of FC4/5. Specifically we could use the device mapper to
> create an ISO sized mapping of the relevant chunk of the CD and check that...
> 
> That might just work

I'm certainly willing to try this...

... but we still have a lingering problem with dm where *it* tries to
read off the end of its underlying devices.

But seriously, somebody tell me a drive make and model, media
manufacturer, cdrecord (or other tool) command line, and FC5 disc number
that reliably has this failure, and I'll be happy to try this or any
other idea people have to fix it.

-- 
  Peter



From pjones at redhat.com  Wed Mar 29 17:42:38 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 29 Mar 2006 12:42:38 -0500
Subject: suspend/hibernate in the command line
In-Reply-To: <20060328223620.GA7838@petra.dvoda.cz>
References: <ur74n1min.fsf@gmail.com>
	<1143506183.5625.6.camel@daxter.boston.redhat.com>
	<20060328223620.GA7838@petra.dvoda.cz>
Message-ID: <1143654158.18075.15.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-29 at 00:36 +0200, Karel Zak wrote:
> On Po, b?e 27, 2006 at 07:36:23 -0500, David Zeuthen wrote:
> > For command line use 'pm-suspend'; it doesn't require root if (and only
> 
>  This is really nice command. There is not man page and 
>  
>     pm-suspend --help
>     
>  has extremely useful behaviour...

FWIW, "less /usr/sbin/pm-suspend".

It's just a shell script.  /etc/pm/functions* have most of the guts, and
the scripts in /etc/pm/hooks are where most of the magic happens.

-- 
  Peter



From robn at berrymount.nl  Wed Mar 29 17:51:07 2006
From: robn at berrymount.nl (Rob van Nieuwkerk)
Date: Wed, 29 Mar 2006 19:51:07 +0200
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060329104913.GD11828@devserv.devel.redhat.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
	<20060329104913.GD11828@devserv.devel.redhat.com>
Message-ID: <20060329195107.baa44e9a.robn@berrymount.nl>

On Wed, 29 Mar 2006 05:49:13 -0500
Alan Cox <alan at redhat.com> wrote:

Hi,

> On Tue, Mar 28, 2006 at 02:31:19PM -0800, Schlaegel wrote:
> > This presents the obvious question: why don't we just check the iso on
> > the media instead of the media itself, and thus remove this long
> > standing problem.
> 
> If we wanted to do that we would need to do it by walking the mounted iso
> file system. The moment we deal with the raw device the kernel starts treating
> it as a device not a file system so we get readehead into the twilight zone.
> 
> However I'm glad you asked because you've made me realise we may have the bits
> to deal with this as of FC4/5. Specifically we could use the device mapper to
> create an ISO sized mapping of the relevant chunk of the CD and check that...
> 
> That might just work

Sure.  Or something like this:

	dd conv=idirect if=/dev/cdrom count=right_number | sha1sum

And if the dd used on the FC ISO does not support the O_DIRECT feature,
just add it.  Or write a completely trivial 10 line C program that
does the same.

I really never understood why there never has been any trivial
work-around on the FC images for this very annoying problem.
This has been going on for many releases now .. :-(

	greetings,
	Rob van Nieuwkerk



From fitzsim at redhat.com  Wed Mar 29 18:03:18 2006
From: fitzsim at redhat.com (Thomas Fitzsimmons)
Date: Wed, 29 Mar 2006 13:03:18 -0500
Subject: Fedora's way forward
In-Reply-To: <m38xqtrwc1.fsf@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<ufahd5h9o50.fsf@epithumia.math.uh.edu>
	<m38xqtrwc1.fsf@localhost.localdomain>
Message-ID: <1143655398.2678.37.camel@tortoise.toronto.redhat.com>

On Wed, 2006-03-29 at 10:31 -0700, Tom Tromey wrote:
> >>>>> "Jason" == Jason L Tibbitts <tibbs at math.uh.edu> writes:
> 
> Jason> As I understand things, Red Hat has someone dedicated to
> Jason> gcjwebplugin.
> 
> Yes, that's true.  Gary is working on the security audit, starting
> with writing test cases and fixing all places in the class library
> which require a call into the security manager.  (There are other
> tasks after this one...)
> 
> Jason> Hopefully gcjwebplugin will be folded into classpath in the near
> Jason> future and development will accelerate.
> 
> Yeah, that's the plan.  I think Michael Koch wanted one
> browser-crashing bug to be fixed before merging it all into Classpath.

Yes, and I fixed it yesterday.  I expect gcjwebplugin to be merged into
GNU Classpath within a few weeks.

> gcj imports classpath on a fairly regular basis.  I'd expect the web
> plugin code to be in GCC 4.2, though whether it is enabled depends on
> the security situation.
> 
> Jason> The last estimate I saw for a usable gcjwebplugin was six
> Jason> months.

Yes, we're aiming to have gcjwebplugin in Fedora Core 6.

Tom




From j.w.r.degoede at hhs.nl  Wed Mar 29 18:04:31 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Mar 2006 20:04:31 +0200
Subject: Fedora's way forward
In-Reply-To: <1143655398.2678.37.camel@tortoise.toronto.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<20060328104659.GI12588@devserv.devel.redhat.com>	<1143651293.5600.228.camel@pmac.infradead.org>	<ufahd5h9o50.fsf@epithumia.math.uh.edu>	<m38xqtrwc1.fsf@localhost.localdomain>
	<1143655398.2678.37.camel@tortoise.toronto.redhat.com>
Message-ID: <442ACC2F.90306@hhs.nl>



Thomas Fitzsimmons wrote:
> On Wed, 2006-03-29 at 10:31 -0700, Tom Tromey wrote:
>> Jason> The last estimate I saw for a usable gcjwebplugin was six
>> Jason> months.
> 
> Yes, we're aiming to have gcjwebplugin in Fedora Core 6.
> 
> Tom
> 

Now that would be really cool, what can I* do to help this?

Regards,

Hans


* I'am a (highly?!) skilled C developer, with some descent C++
   experience and limited java experience, with a strong computerscience
   background.



From nicolas.mailhot at laposte.net  Wed Mar 29 18:19:29 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 29 Mar 2006 20:19:29 +0200
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <200603290444.20942.billcrawford1970@googlemail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
	<1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com>
	<200603290444.20942.billcrawford1970@googlemail.com>
Message-ID: <1143656372.2792.16.camel@rousalka.dyndns.org>

Le mercredi 29 mars 2006 ? 04:44 +0100, Bill Crawford a ?crit :

> > A list of common pit falls.

Pitfall #1 : creating the perfect general serialization API so
developers can save whatever data they feel like to without thinking 5s
how other people will interact with it. This is what I call
software-oriented junk

Pitfall #2 : creating handcrafted file format no standard tools can
interact sanely with. This is human-oriented junk

People tend to dismiss XML because a lot of its proponents have fallen
in pitfall #1. Usually they jump in pitfall #2 as a result.

A popular way to combine pitfall #1 and #2 is to create configuration
tools which use a private data backend with pitfall #1, and convert it
at save time in the actual handcrafted app conf file with pitfall #2.

Good projects start by choosing general syntax rules that make software
happy (usually XML) then fine-tune them with humans in mind (what if the
whole file had to be written by a human in a text editor and you had to
write the associated manual) See for example fontconfig, apache ant
syntax, etc

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

From rhally at mindspring.com  Wed Mar 29 18:21:52 2006
From: rhally at mindspring.com (Richard Hally)
Date: Wed, 29 Mar 2006 13:21:52 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143654010.18075.12.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>	<44273ECD.8010606@mindspring.com>	<20060327130749.GB24971@devserv.devel.redhat.com>	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>	<20060328221303.GA29073@devserv.devel.redhat.com>	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>	<20060329104913.GD11828@devserv.devel.redhat.com>
	<1143654010.18075.12.camel@vroomfondel.internal.datastacks.com>
Message-ID: <442AD040.5090408@mindspring.com>

Peter Jones wrote:
> On Wed, 2006-03-29 at 05:49 -0500, Alan Cox wrote:
>> On Tue, Mar 28, 2006 at 02:31:19PM -0800, Schlaegel wrote:
>>> This presents the obvious question: why don't we just check the iso on
>>> the media instead of the media itself, and thus remove this long
>>> standing problem.
>> If we wanted to do that we would need to do it by walking the mounted iso
>> file system. The moment we deal with the raw device the kernel starts treating
>> it as a device not a file system so we get readehead into the twilight zone.
>>
>> However I'm glad you asked because you've made me realise we may have the bits
>> to deal with this as of FC4/5. Specifically we could use the device mapper to
>> create an ISO sized mapping of the relevant chunk of the CD and check that...
>>
>> That might just work
> 
> I'm certainly willing to try this...
> 
> ... but we still have a lingering problem with dm where *it* tries to
> read off the end of its underlying devices.
> 
> But seriously, somebody tell me a drive make and model, media
> manufacturer, cdrecord (or other tool) command line, and FC5 disc number
> that reliably has this failure, and I'll be happy to try this or any
> other idea people have to fix it.
> 
This may or may not be related but it has the same(ide=nodma) workaround:

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

entered last night. The h/w is pretty generic. If you need more details 
of the h/w, let me know. the media is Memorex CD-RW 700MB.

Richard



From david at fubar.dk  Wed Mar 29 18:34:38 2006
From: david at fubar.dk (David Zeuthen)
Date: Wed, 29 Mar 2006 13:34:38 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329063345.GB6131@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
Message-ID: <1143657279.25616.11.camel@daxter.boston.redhat.com>

On Wed, 2006-03-29 at 01:33 -0500, Eric S. Raymond wrote:
> But the
> reality is that J. Random User wants to listen to podcasts, and the
> podcasts are in MP3.  

Please explain why it is difficult for the user to grab 

 gstreamer-plugins-bad
 gstreamer-ffmpeg
 gstreamer-plugins-ugly

etc. from a 3rd party repository. 

Sure, now you can enumerate tons of practical reasons such as
discoverability and I would even agree with you. I bet a lot of other
people would too. I like this to be easy.

Tell me.. why you don't start a project aiming for better integration of
3rd party repositories outside Fedora Core and Extras? I'm sure it can
be as simple as Alan outlined with the user just having to click a link
in his web browser and, badebing-badebum, all the stuff is installed.

I encourage you to take this task upon you. I think it would be great!

    David




From nicolas.mailhot at laposte.net  Wed Mar 29 18:42:14 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 29 Mar 2006 20:42:14 +0200
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <4429327A.2060401@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>  <4429327A.2060401@gmail.com>
Message-ID: <1143657740.2792.25.camel@rousalka.dyndns.org>

Le mardi 28 mars 2006 ? 09:56 -0300, Casimiro de Almeida Barreto a
?crit :

> > Let me imagine the negative case.  RHAT and the community are
> > drained and pummelled by a limitless number of patent attacks they
> > are forced to defend once they get into that game of either entering
> > the grey zone or getting their wallet out.  Even JPEG is a danger
> > area.  Unless the strategy includes turning off the patent attack
> > tap somehow it seems an unlikely "way forward". 
> > 
> Even being alive is in a danger area: you can die at any moment.
> Recent events show that you even can die because a B-737 piloted by an
> insane freako crashes against your building... So law issues are a
> joke.

I hear there is an entreprise-oriented distribution which does not shy
from proprietary code accommodations to make its user-experience great.
Not like this Red Hat sissies. It's named Caldera Linux. I'm sure with
such progressive management it'll own the Linux market in a few years.
They even bought Unix, which is a serious operating system not some
communist-oriented unconstitutional mashup.

Why don't you try them ?

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

From stickster at gmail.com  Wed Mar 29 16:51:13 2006
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 29 Mar 2006 11:51:13 -0500
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <1143594150.3802.582.camel@sundaram.pnq.redhat.com>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
	<4429C65C.3070600@comcast.net> <200603281709.38816.lamont@gurulabs.com>
	<4429D3FF.4050904@comcast.net>
	<1143592383.3802.578.camel@sundaram.pnq.redhat.com>
	<4429DBA3.1020605@comcast.net>
	<1143594150.3802.582.camel@sundaram.pnq.redhat.com>
Message-ID: <1143651074.5136.5.camel@localhost.localdomain>

On Wed, 2006-03-29 at 06:32 +0530, Rahul Sundaram wrote:
> On Tue, 2006-03-28 at 19:58 -0500, Neil Cherry wrote:
> 
> > >> Ah, so that's the difference. That was driving me totally nuts. I
> > >> couldn't figure out why I couldn't compile the kernel with the
> > >> devel package but I'm very successful (when I don't remove too
> > >> much) with the kernel sources.
> > > 
> > > We have all this information in the release notes which we spend many
> > > many hours writing. So you might as well as read it.
> > > http://fedora.redhat.com/docs/release-notes/fc5/#sn-Kernel
> > 
> > Thanks Rahul, I only found out about the release notes yesterday
> > when someone else mentioned them. 
> 
> I am curious. How did you manage to *miss it* ?. It has a rather
> prominent button in the installer, default page for the browser,
> mentioned usually in the release announcements etc. 

Don't be silly, Rahul, everybody knows we Americans can't read. :-)

In all seriousness, I'm betting your question is rhetorical and stems
from the frustration of putting so much work into the process only to
see endless questions like this.  (Your work is very much appreciated,
by the way.)  In case it's not rhetorical, perhaps we could put a big
modal dialog at the opening of Anaconda saying something like,

"Hidden in the release notes is a secret key to enabling MP3, DVD, and
Shockwave in your new Fedora system.  To find it, you'll have to read
them to find the secret.  Click 'OK' to open the Release Notes window."

/me dons abestos and jumps into bunker


-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/54aa69f2/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Mar 29 18:53:16 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 29 Mar 2006 20:53:16 +0200
Subject: Fedora's way forward
In-Reply-To: <20060329010235.GA3395@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
Message-ID: <1143658399.2792.31.camel@rousalka.dyndns.org>

Le mardi 28 mars 2006 ? 20:02 -0500, Eric S. Raymond a ?crit :
> Alan Cox <alan at redhat.com>:

> > That sounds more like Ubuntu's goals than Fedora. Fedora is intended to be
> > a testing ground for doing cool and exciting things with free software. In
> > the Ubuntu case you are making some interesting arguments, but Fedora isn't
> > intended to be Mum's new desktop, cool if it works out that way but its
> > not the design spec.
> 
> OK.  So the next question is, do *Red Hat's* goals no longer include
> world desktop domination?  Because if that's true, I need to find a distro
> that hasn't ... er ... lost its idealism.

The Fedora way is to create the best FOSS-only system, in the hope that
one day (soon) the advantages of not bundling closed code (no EULAs,
DRMs, constants adds and other annoyware, unified package system, fully
tweakable and vendor-independent OS) outweight the problems of not
including closed code.

Given that most closed systems spend their time playing with their users
goodwill limits, it's not as far-fetched a goal as it may seem.

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

From pjones at redhat.com  Wed Mar 29 19:05:04 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 29 Mar 2006 14:05:04 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329010235.GA3395@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<604aa7910603280738r2578fcb3hc8d01d9c217a379b@mail.gmail.com>
	<20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
Message-ID: <1143659104.18075.24.camel@vroomfondel.internal.datastacks.com>

On Tue, 2006-03-28 at 20:02 -0500, Eric S. Raymond wrote:

> OK.  So the next question is, do *Red Hat's* goals no longer include
> world desktop domination?  Because if that's true, I need to find a distro
> that hasn't ... er ... lost its idealism.

I don't think "world domination" has ever been our strategy or goal.  We
usually go for attainable goals like "make $FOO work", "be better at
$FEATURE than $COMPETITOR" and "make our users' lives less painful than
they were with the last release".

If the desire for world domination is your criteria, then you're right,
Fedora is not the distro you're looking for.  Have fun searching for a
new distro of which the developers share that mindset.

-- 
  Peter



From pjones at redhat.com  Wed Mar 29 19:26:26 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 29 Mar 2006 14:26:26 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060329195107.baa44e9a.robn@berrymount.nl>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
	<20060329104913.GD11828@devserv.devel.redhat.com>
	<20060329195107.baa44e9a.robn@berrymount.nl>
Message-ID: <1143660386.18075.32.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-29 at 19:51 +0200, Rob van Nieuwkerk wrote:

> Sure.  Or something like this:
> 
> 	dd conv=idirect if=/dev/cdrom count=right_number | sha1sum
> 
> And if the dd used on the FC ISO does not support the O_DIRECT feature,
> just add it.  Or write a completely trivial 10 line C program that
> does the same.

This will almost always get you the wrong result.  At the very least,
you need 'bs=2048 count="$(($(isosize /dev/cdrom) / 2048))"' with that,
or you wind up doing md5sum on completely bogus data with some media.

But as it turns out, that fails the exact same way that mediacheck does.

> I really never understood why there never has been any trivial
> work-around on the FC images for this very annoying problem.

dd does read(2) just like mediacheck does.  There isn't some spooky
magic here.  It fails in exactly the same ways for exactly the same
reasons.

-- 
  Peter



From mike at flyn.org  Wed Mar 29 19:29:17 2006
From: mike at flyn.org (W. Michael Petullo)
Date: Wed, 29 Mar 2006 13:29:17 -0600 (CST)
Subject: Fedora's way forward
In-Reply-To: <1143651293.5600.228.camel@pmac.infradead.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
Message-ID: <39585.140.153.231.84.1143660557.squirrel@zero.voxel.net>

>> If you'd like additional proprietary third party material such as real
>> player and IBM Java nobody is stopping you.

> Those are two examples where Fedora really _could_ catch up. We should
> really concentrate on getting gcjwebplugin and swfdec (or gnash)
> shippable by FC6.

Please see also:

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

--
Mike Petullo



From jkeating at j2solutions.net  Wed Mar 29 19:29:57 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 29 Mar 2006 11:29:57 -0800
Subject: Mirrorlist Issues
In-Reply-To: <8719b8230603290526o1af6087rab798c008e862f6a@mail.gmail.com>
References: <8719b8230603290526o1af6087rab798c008e862f6a@mail.gmail.com>
Message-ID: <1143660597.19611.5.camel@yoda.loki.me>

On Wed, 2006-03-29 at 08:26 -0500, Ryan Skadberg wrote:
> Any chance we can change the mirror list back to being a real list of
> mirrors so this problem goes away?

Actually, this one we pointed directly at our site, because we weren't
sure if any of the mirrors were carrying debuginfo and source packages.
Thats a task for the fedora mirror admins to find out if any mirrors are
carrying that content, and in FC6(test) we can repoint this at a mirror
file.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/56b83cb8/attachment.sig>

From pjones at redhat.com  Wed Mar 29 19:30:41 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 29 Mar 2006 14:30:41 -0500
Subject: Package names in FC5
In-Reply-To: <20060329153748.3ef7bab3.fedora@wir-sind-cool.org>
References: <200603281356.17155.rkwasny@aurox.org>
	<20060328144218.92792ab4.fedora@wir-sind-cool.org>
	<1143582471.3095.33.camel@vroomfondel.internal.datastacks.com>
	<20060329153748.3ef7bab3.fedora@wir-sind-cool.org>
Message-ID: <1143660641.18075.35.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-29 at 15:37 +0200, Michael Schwendt wrote:
> On Tue, 28 Mar 2006 16:47:50 -0500, Peter Jones wrote:
> 
> > > No pattern. Core package developers can do what they want, and some of
> > > them still don't seem to care that .fc3 is "newer than" .FC5 in RPM
> > > version comparison.
> > 
> > That's a bit of an exaggeration.  It's not that we don't care, it's that
> > it doesn't matter unless you're doing something *else* really dumb at
> > the same time as *switching* between those two nomenclatures.
> > 
> > *yawn*.
> 
> No need to yawn. :) It has happened before that a package from Core was
> moved to Extras or vice versa, and then you get the "switching" in updates
> unless the different packagers agree on a common way.

Ok, but there's a more serious problem there.  If you're moving the
package from core to extras or vice versa, start with the same spec file
and only change the parts you actually have to.

If our naming policy for extras says we have to use one particular
capitalization for a "release" field, then we should fix it.  That's
just a rule for the sake of having more rules.  It doesn't buy us
anything.

-- 
  Peter



From michael at knox.net.nz  Wed Mar 29 19:40:08 2006
From: michael at knox.net.nz (Michael J Knox)
Date: Thu, 30 Mar 2006 07:40:08 +1200
Subject: Fedora's way forward
In-Reply-To: <1143609370.3802.598.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
Message-ID: <442AE298.9090300@knox.net.nz>

Rahul Sundaram wrote:
> [Please quote more appropriately rather than including the entire mail
> while replying to it]
> 
>> Right on the money Eric.
>>
>> I love Fedora Core. In the world of Linux it is The Class Act. However I
>> would like to see it's core philosophical paradigm expanded to
>> accommodate the pragmatic reality of what the average user really wants
>> and what he actually installs on his Fedora machine in practice.
> 
> You mean to say that Fedora should give up its support towards Free and
> open source software and adopt proprietary formats and software in the
> name of pragmatism. Not a good idea IMO. There are already other
> distributions out there which does this if this is really the only thing
> you want. 

Rahul,

I don't see where he said give up on free and open source formats and 
software. In fact, he said *expanded* not "give up on". I suggest not 
putting words in peoples mouths (or emails as it is).

Nor do I think telling someone "There are already other distributions 
out there which does this if this is really the only thing you want" is 
the correct way to tackle, what is, a real world issue.

Michael



From shane at geeklords.org  Wed Mar 29 19:40:43 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Wed, 29 Mar 2006 11:40:43 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <16de708d0603290836s6d580f44v2e652255a824827e@mail.gmail.com>
References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
	<Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
	<20060329130044.GB3411@dudweiler.stuttgart.redhat.com>
	<16de708d0603290836s6d580f44v2e652255a824827e@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603291135060.30613@master.geeklords.org>

On Wed, 29 Mar 2006, Arthur Pemberton wrote:

>> A full ack on this, we would solve a lot of items if we could move
>> forward to have a standard lib for all this. But it will be very
>> hard to have agreement on how to solve it and even more to make
>> projects move over from their current ways.
>
> I think the process of getting other projects to use this "standard" would
> be to put some though into the design and mark multiple backends and
> multiple interfaces part of the design. If there are libs, modules,
> languages binds, etc with as little dependancy hell as possible, I think
> projects will eventually gravitate to this solution. I know I wouldn't roll
> my own config parser if there is a perfectly good one already included on my
> system , or which can easily be added to any system.

I agree design is key here.  However our community generally wants no part 
of discussing requirements and then writing specifications in English. 
They want actual code... Is there a good case here for gathering 
requirements and perhaps writing a specification, getting feedback from 
the major players prior to code being written?

Cheers,
Shane



From pjones at redhat.com  Wed Mar 29 19:48:04 2006
From: pjones at redhat.com (Peter Jones)
Date: Wed, 29 Mar 2006 14:48:04 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <20060329101459.GA11828@devserv.devel.redhat.com>
References: <20060327202457.GA15056@thyrsus.com>
	<1143498560.11720.8.camel@mentorng.gurulabs.com>
	<20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
	<20060328101331.GB12588@devserv.devel.redhat.com>
	<1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
	<20060328212959.GA30334@devserv.devel.redhat.com>
	<1143584440.3095.58.camel@vroomfondel.internal.datastacks.com>
	<20060329101459.GA11828@devserv.devel.redhat.com>
Message-ID: <1143661684.18075.49.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-29 at 05:14 -0500, Alan Cox wrote:
> On Tue, Mar 28, 2006 at 05:20:40PM -0500, Peter Jones wrote:
> > For all thinkpads that have this turned on it's for BIOS backup/restore
> > features, a and other related features that the user (at least
> > theoretically) paid for and may still want.  Right now we're trashing
> > them.
> > 
> > I think ThinkPads make up more than 1% of cases, but I've got no real
> > data to prove it with.
> 
> This is one of the problems. On a thinkpad the HPA is used to hide stuff,
> and on many boxes its used in a way we want to undo. In theory its just a case
> of installers doing partitioning right and maybe snooping the DMI tables to
> see if its a thinkpad... in theory 8)

Yeah.  But right now the installer doesn't have any data available about
HPA at all, so it can't do the partitioning right if we're disabling HPA
(which we are).

Which means for FC6, we have to disable HPA by default, and
conditionally re-enable it if there's no partition table entry that
points above the top.

Tangentally, I might add that if Fibre Channel, iSCSI, or similar ever
invent a function like this, we better not screw it up as much as we
have this time, because changing the geometry of another machine's disk
is seriously not fun to recover from.  Just my introspective thought for
the day.

> > > Looks basically sane. You have to run the ACPI taskfiles from the BIOS first
> > > however or you are out of spec and anything can happen (although fortunately
> > > it ususally doesnt)
> > 
> > Ugh.  Ok, I've got some reading to do before I get this in.  Thanks for
> > the info.
> 
> The ACPI taskfile stuff is cooking already and should be mainstream soon. I
> would suggest not worrying about it for the moment. You will need to sort the
> HPA out after the ACPI stuff runs once it is in as on the thinkpad it also
> edits the HPA settings when those run

OK... is there a patch floating around for the _GTF stuff already?  URL?

Also, are (whoever's doing it) doing _GTM/_STM work as well?

> > disable it entirely for IDE, which means if we ever want to do anything
> > other than just disable it, we need control to be somewhere that can
> > examine the system to see what we've done.  Sadly, that probably means
> > userland.
> 
> I've not dug into the thinkpad far enough but I would guess that something 
> like
> 
> 	read partition table
> 	work out last sector used
> 	if ( beyond hpa)
> 		disable hpa
> 	else
> 		honour hpa
> 
> will give the right answer for almost all cases, if not all.

Yep, I already have this code.

>  Not sure what you
> do if the drive has no partition table.

Well, one thing to try would be to look at the first sector of the
protected area and see what *it* has in it.  On most thinkpads IIRC the
first thing there is a bootable floppy image.

And of course there's always the DMI option, but that's a bit of a blunt
hammer -- especially since newer thinkpads have stopped using HPA.

-- 
  Peter



From nicolas.mailhot at laposte.net  Wed Mar 29 19:48:34 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 29 Mar 2006 21:48:34 +0200
Subject: speed up FC 5
In-Reply-To: <20060329074453.GA14102@redhat.com>
References: <20060327124326.13BEA6DF30@ak.kimaya>
	<4429B3D5.3030207@BitWagon.com>
	<20060328221821.GB29073@devserv.devel.redhat.com>
	<20060329074453.GA14102@redhat.com>
Message-ID: <1143661717.2562.8.camel@rousalka.dyndns.org>

Le mercredi 29 mars 2006 ? 02:44 -0500, Daniel Veillard a ?crit :
> On Tue, Mar 28, 2006 at 05:18:21PM -0500, Alan Cox wrote:
> > That gets the main end user apps back to a sensible size. Web browser is
> > a trickier one and you may find it best to just keep firefox.
> 
>   Disabling the memory cache of Firefox makes a significant difference in
> term of memory use by Firefox for me, even on a 1G machine, it's generally
> slower but doesn't lead to swap (so far).

Some pages do not display when I turn the cache off. For example
http://eucd.info/ (this may be some interaction with the extensions I
have installed)

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

From j.w.r.degoede at hhs.nl  Wed Mar 29 19:49:51 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Mar 2006 21:49:51 +0200
Subject: Fedora's way forward
In-Reply-To: <442AE298.9090300@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
Message-ID: <442AE4DF.700@hhs.nl>



Michael J Knox wrote:
> Rahul Sundaram wrote:
>> [Please quote more appropriately rather than including the entire mail
>> while replying to it]
>>
>>> Right on the money Eric.
>>>
>>> I love Fedora Core. In the world of Linux it is The Class Act. However I
>>> would like to see it's core philosophical paradigm expanded to
>>> accommodate the pragmatic reality of what the average user really wants
>>> and what he actually installs on his Fedora machine in practice.
>>
>> You mean to say that Fedora should give up its support towards Free and
>> open source software and adopt proprietary formats and software in the
>> name of pragmatism. Not a good idea IMO. There are already other
>> distributions out there which does this if this is really the only thing
>> you want. 
> 
> Rahul,
> 
> I don't see where he said give up on free and open source formats and 
> software. In fact, he said *expanded* not "give up on". I suggest not 
> putting words in peoples mouths (or emails as it is).
> 
> Nor do I think telling someone "There are already other distributions 
> out there which does this if this is really the only thing you want" is 
> the correct way to tackle, what is, a real world issue.
> 

How about a fake gstreamer-mp3-plugin, which in turn then will ask to 
user if its ok to download the real thing from fluendo, and if this is 
nescesarry first show the license screen.

I think that the way to tackle this is to create a system where Fedora 
can download codecs for users and will ask users if its ok to download 
the nescesarry coded, show the license first, etc. This way we could 
include realmedia support too, I'm sure real will be willing to offer 
their codec for download in a suitable format.

I see 3 problems with my own suggestion:
-its pragmatic and doesn't meet our ideals 100%, I for one
  am divided on this issue
-GPL apps will not be allowed to use these codecs, unless they come
  with a license acception. I believe we can find a way to handle this,
  like adding the capability to gstreamer (or another framework) to allow
  the app to specify additonal codec search paths and / or if it want
  proprietary codecs in general.
-not all codecs will be available for all platforms we want to support,
  this will either have to be accepted or we could use something like
  qemu to work around this.

If enough people believe this is a good idea I'm willing to sync some 
time into this.

Regards,

Hans



From jspaleta at gmail.com  Wed Mar 29 20:01:21 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 29 Mar 2006 15:01:21 -0500
Subject: Fedora's way forward
In-Reply-To: <442AE298.9090300@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
Message-ID: <604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>

On 3/29/06, Michael J Knox <michael at knox.net.nz> wrote:
> Nor do I think telling someone "There are already other distributions
> out there which does this if this is really the only thing you want" is
> the correct way to tackle, what is, a real world issue.

Nor is conveniently ignoring the fact that the underlying issue is the
very thorny messy nature as to software patents and how software
patents interact to restrict the freedoms and or rights typically
granted in FOSS software.. freedoms that are essential to how foss
development is done. To continue to try to discussion the issues
surrounding supporting mp3 and other similar media technologies like
they are just another piece of proprietary software code that can
re-developed from scratch to fill a compatibility need is an egregious
effort at miscommunication as to where the problems actually lie.

Software patents very much constrain how collaborative development in
an open source model can be done and I am very confident that certain
people in this discussion of aware of that constrain and I continue to
find it bemusing at the stance they are taking about trying to
incorporate patent encumbered technologies into a software project
which  relies on the very freedoms and rights embodied in FOSS
copyright licensing to enable the massively collaborative development
effort that makes this project possible at all.

This whole discussion is unconstructive and was intiated by a post,
while well intentioned, was in fact using the wrong assumptions with
regard to the patent situations.
Once ESR recognized that the patent situation was more complicated
than he had assumed this conversation should have been tabled until he
made a personal effort to become more informed as to the patent issue.
Instead he's chosen to continue in a discussion predicated on
misinformation which he himself brought to this discussion. Quite
frankly I'm very disappointed in his continued participation in this
discussion because he continues to mislead people into believing that
this is a simple matter of open source reverse engineering of a
proprietary format..which it is not.  I can not stress enough that the
issue of software patents is vitally important and its impact on the
freedoms and rights afforded to the community under FOSS copyright
licensing  can not be ignored when making arguments about weight
pragmatic access to functionality against idealist views towards FOSS
software distribution.

In my personal opinion, the original post from  ESR was less informed
than most OSNews editorials I read, and that is a particularly low bar
to meet.

-jef



From jkeating at j2solutions.net  Wed Mar 29 20:06:44 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 29 Mar 2006 12:06:44 -0800
Subject: Fedora's way forward
In-Reply-To: <442AE4DF.700@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>  <442AE4DF.700@hhs.nl>
Message-ID: <1143662804.19611.6.camel@yoda.loki.me>

On Wed, 2006-03-29 at 21:49 +0200, Hans de Goede wrote:
> I think that the way to tackle this is to create a system where Fedora 
> can download codecs for users and will ask users if its ok to download 
> the nescesarry coded, show the license first, etc. This way we could 
> include realmedia support too, I'm sure real will be willing to offer 
> their codec for download in a suitable format.

Contributory infringement.  You lose.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/005a9ddc/attachment.sig>

From jcliburn at gmail.com  Wed Mar 29 17:24:38 2006
From: jcliburn at gmail.com (J. K. Cliburn)
Date: Wed, 29 Mar 2006 11:24:38 -0600
Subject: Fedora's way forward
In-Reply-To: <08ef01c65354$0529c6a0$b6491b31@td612671>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<ufahd5h9o50.fsf@epithumia.math.uh.edu>
	<08ef01c65354$0529c6a0$b6491b31@td612671>
Message-ID: <3400f2f60603290924y6e452f0av2986cc10911b2d9@mail.gmail.com>

On 3/29/06, Dimi Paun <dimi at lattica.com> wrote:

> While it's great that Red Hat does this, I don't think this is a
> big deal from a consumer perspective. Java has been dead as disco
> on the web for some time, there are precious few sites that use it.

Java, dead?  Hardly.  Go to pogo.com at any moment of any given day
and behold a quarter million souls, each one playing a java-based
game, many paying about US$30 per year for the privilege to do so.

Jay



From michael at knox.net.nz  Wed Mar 29 20:12:03 2006
From: michael at knox.net.nz (Michael J Knox)
Date: Thu, 30 Mar 2006 08:12:03 +1200
Subject: Fedora's way forward
In-Reply-To: <604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>
Message-ID: <442AEA13.8060606@knox.net.nz>

Jeff Spaleta wrote:
> On 3/29/06, Michael J Knox <michael at knox.net.nz> wrote:
>> Nor do I think telling someone "There are already other distributions
>> out there which does this if this is really the only thing you want" is
>> the correct way to tackle, what is, a real world issue.
> 
> Nor is conveniently ignoring the fact that the underlying issue is the
> very thorny messy nature as to software patents and how software
> patents interact to restrict the freedoms and or rights typically
> granted in FOSS software.. freedoms that are essential to how foss
> development is done. To continue to try to discussion the issues
> surrounding supporting mp3 and other similar media technologies like
> they are just another piece of proprietary software code that can
> re-developed from scratch to fill a compatibility need is an egregious
> effort at miscommunication as to where the problems actually lie.
> 
> Software patents very much constrain how collaborative development in
> an open source model can be done and I am very confident that certain
> people in this discussion of aware of that constrain and I continue to
> find it bemusing at the stance they are taking about trying to
> incorporate patent encumbered technologies into a software project
> which  relies on the very freedoms and rights embodied in FOSS
> copyright licensing to enable the massively collaborative development
> effort that makes this project possible at all.
> 
> This whole discussion is unconstructive and was intiated by a post,
> while well intentioned, was in fact using the wrong assumptions with
> regard to the patent situations.
> Once ESR recognized that the patent situation was more complicated
> than he had assumed this conversation should have been tabled until he
> made a personal effort to become more informed as to the patent issue.
> Instead he's chosen to continue in a discussion predicated on
> misinformation which he himself brought to this discussion. Quite
> frankly I'm very disappointed in his continued participation in this
> discussion because he continues to mislead people into believing that
> this is a simple matter of open source reverse engineering of a
> proprietary format..which it is not.  I can not stress enough that the
> issue of software patents is vitally important and its impact on the
> freedoms and rights afforded to the community under FOSS copyright
> licensing  can not be ignored when making arguments about weight
> pragmatic access to functionality against idealist views towards FOSS
> software distribution.
> 
> In my personal opinion, the original post from  ESR was less informed
> than most OSNews editorials I read, and that is a particularly low bar
> to meet.
> 
> -jef
> 


Jef,

I am not ignoring nor am I misunderstanding the issue. Pretending it 
doesn't exist is not the answer, nor is mis-representing what people 
say. I am also well aware of the issues surrounding patent emcumbered 
software.

Me personally? I use the gstreamer mp3 plugin (thanks Fluendo) for the 
very little mp3 use I need (like mp3's from record label websites and 
the odd pod cast)

Michael





From seanlkml at sympatico.ca  Wed Mar 29 20:10:06 2006
From: seanlkml at sympatico.ca (sean)
Date: Wed, 29 Mar 2006 15:10:06 -0500
Subject: Fedora's way forward
In-Reply-To: <442AE298.9090300@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
Message-ID: <BAYC1-PASMTP01173F3F9EA6157B91BB29AED00@CEZ.ICE>

On Thu, 30 Mar 2006 07:40:08 +1200
Michael J Knox <michael at knox.net.nz> wrote:

> Nor do I think telling someone "There are already other distributions 
> out there which does this if this is really the only thing you want" is 
> the correct way to tackle, what is, a real world issue.

Why not?

In the real world no one project can service the needs of everyone.

Fedora is designed to meet the needs of a very specific group of 
users, ie. people who want their distribution of choice to steer
well clear of proprietary entanglements. 

Other distributions service other groups of people.  If someone got 
on one of their mailing lists and demanded that they ship only open 
source software, hopefully that person would be encouraged to join 
Fedora which is specificially designed for his or her needs.

Sean



From seanlkml at sympatico.ca  Wed Mar 29 20:19:08 2006
From: seanlkml at sympatico.ca (sean)
Date: Wed, 29 Mar 2006 15:19:08 -0500
Subject: Fedora's way forward
In-Reply-To: <442AEA13.8060606@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
	<604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>
	<442AEA13.8060606@knox.net.nz>
Message-ID: <BAYC1-PASMTP10856574A5997D36813B72AED00@CEZ.ICE>

On Thu, 30 Mar 2006 08:12:03 +1200
Michael J Knox <michael at knox.net.nz> wrote:

> I am not ignoring nor am I misunderstanding the issue. Pretending it 
> doesn't exist is not the answer, nor is mis-representing what people 
> say. I am also well aware of the issues surrounding patent emcumbered 
> software.

Nobody is pretending it doesn't exist; just stating emphatically that 
the Fedora project isn't at all designed to do anything about it.   Period.  

> Me personally? I use the gstreamer mp3 plugin (thanks Fluendo) for the 
> very little mp3 use I need (like mp3's from record label websites and 
> the odd pod cast)

Your choice of course, it just doesn't have anything to do with the
core Fedora project. 

Sean

P.S.  I don't think Rahul was mis-representing anything Eric said; rather
      I think he was giving his characterization of the net-effect of
      Eric's request.   You can debate his characterization, but I don't
      think his intent was to deceive.



From j.w.r.degoede at hhs.nl  Wed Mar 29 20:30:20 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 29 Mar 2006 22:30:20 +0200
Subject: Fedora's way forward
In-Reply-To: <1143662804.19611.6.camel@yoda.loki.me>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<442AE4DF.700@hhs.nl> <1143662804.19611.6.camel@yoda.loki.me>
Message-ID: <442AEE5C.5050501@hhs.nl>



Jesse Keating wrote:
> On Wed, 2006-03-29 at 21:49 +0200, Hans de Goede wrote:
>> I think that the way to tackle this is to create a system where Fedora 
>> can download codecs for users and will ask users if its ok to download 
>> the nescesarry coded, show the license first, etc. This way we could 
>> include realmedia support too, I'm sure real will be willing to offer 
>> their codec for download in a suitable format.
> 
> Contributory infringement.  You lose.
> 

I was talking about fluendo, so this tool would help users to download 
legitimate plugins, I also suggested that maybe we could convince real 
to make real codecs available for such a semi automated install, so
there is no infringement here. Please read my post again, and next time 
read before shooting a default answer from the hip.

Regards,

Hans



From dax at gurulabs.com  Wed Mar 29 20:50:40 2006
From: dax at gurulabs.com (Dax Kelson)
Date: Wed, 29 Mar 2006 13:50:40 -0700
Subject: FC5 kernels in updates/testing
In-Reply-To: <20060329032655.GB3572@redhat.com>
References: <20060329142528.0sg7pvhy40swc0kc@www.rexursive.com> 
	<20060329032655.GB3572@redhat.com>
Message-ID: <6056-SnapperMsg827D11E1C050A3AD@[68.27.149.163]>

...... Original Message .......
On Tue, 28 Mar 2006 22:26:55 -0500 "Dave Jones" <davej at redhat.com> wrote:
>On Wed, Mar 29, 2006 at 02:25:28PM +1100, Bojan Smojver wrote:
> > Just out of curiosity, is 2069 testing kernel going to be replaced  
> > with 2080, now that 2.6.16.1 is out?
>
>Yes, pretend 2069 never happened.
>I was hoping that 2080 would go out today, but it seems to be stuck
>in the errata system waiting for someone to pull a lever somewhere.
>

Someone, please pull the lever.
___
Dax Kelson
Sent with my Treo



From davej at redhat.com  Wed Mar 29 20:55:14 2006
From: davej at redhat.com (Dave Jones)
Date: Wed, 29 Mar 2006 15:55:14 -0500
Subject: FC5 kernels in updates/testing
In-Reply-To: <6056-SnapperMsg827D11E1C050A3AD@[68.27.149.163]>
References: <20060329142528.0sg7pvhy40swc0kc@www.rexursive.com>
	<20060329032655.GB3572@redhat.com>
	<6056-SnapperMsg827D11E1C050A3AD@[68.27.149.163]>
Message-ID: <20060329205514.GC21871@redhat.com>

On Wed, Mar 29, 2006 at 01:50:40PM -0700, Dax Kelson wrote:
 > ...... Original Message .......
 > On Tue, 28 Mar 2006 22:26:55 -0500 "Dave Jones" <davej at redhat.com> wrote:
 > >On Wed, Mar 29, 2006 at 02:25:28PM +1100, Bojan Smojver wrote:
 > > > Just out of curiosity, is 2069 testing kernel going to be replaced  
 > > > with 2080, now that 2.6.16.1 is out?
 > >
 > >Yes, pretend 2069 never happened.
 > >I was hoping that 2080 would go out today, but it seems to be stuck
 > >in the errata system waiting for someone to pull a lever somewhere.
 > >
 > 
 > Someone, please pull the lever.

Jesse pulled it about an hour ago.
It's trickling out to the mirrors.

		Dave

-- 
http://www.codemonkey.org.uk



From dimi at lattica.com  Wed Mar 29 20:59:05 2006
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 29 Mar 2006 15:59:05 -0500
Subject: Fedora's way forward
References: <200603280950.k2S9oqre022074@snark.thyrsus.com><20060328104659.GI12588@devserv.devel.redhat.com><1143651293.5600.228.camel@pmac.infradead.org><ufahd5h9o50.fsf@epithumia.math.uh.edu><08ef01c65354$0529c6a0$b6491b31@td612671>
	<3400f2f60603290924y6e452f0av2986cc10911b2d9@mail.gmail.com>
Message-ID: <09c901c65373$9eafe5b0$b6491b31@td612671>

From: "J. K. Cliburn" <jcliburn at gmail.com>
> Java, dead?  Hardly. 

Not on server, I agree. It struggles on desktop. It's dead in the browser.

> Go to pogo.com at any moment of any given day
> and behold a quarter million souls, each one playing a java-based
> game, many paying about US$30 per year for the privilege to do so.

Not exactly mainstream, or at least nothing close to what it was meant
to be. Flash is more common by many orders of magnitude.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From veillard at redhat.com  Wed Mar 29 21:02:38 2006
From: veillard at redhat.com (Daniel Veillard)
Date: Wed, 29 Mar 2006 16:02:38 -0500
Subject: speed up FC 5
In-Reply-To: <1143661717.2562.8.camel@rousalka.dyndns.org>
References: <20060327124326.13BEA6DF30@ak.kimaya>
	<4429B3D5.3030207@BitWagon.com>
	<20060328221821.GB29073@devserv.devel.redhat.com>
	<20060329074453.GA14102@redhat.com>
	<1143661717.2562.8.camel@rousalka.dyndns.org>
Message-ID: <20060329210237.GH14102@redhat.com>

On Wed, Mar 29, 2006 at 09:48:34PM +0200, Nicolas Mailhot wrote:
> Le mercredi 29 mars 2006 ? 02:44 -0500, Daniel Veillard a ?crit :
> > On Tue, Mar 28, 2006 at 05:18:21PM -0500, Alan Cox wrote:
> > > That gets the main end user apps back to a sensible size. Web browser is
> > > a trickier one and you may find it best to just keep firefox.
> > 
> >   Disabling the memory cache of Firefox makes a significant difference in
> > term of memory use by Firefox for me, even on a 1G machine, it's generally
> > slower but doesn't lead to swap (so far).
> 
> Some pages do not display when I turn the cache off. For example
> http://eucd.info/ (this may be some interaction with the extensions I
> have installed)

  Seems to work for me...

Daniel

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



From jkeating at j2solutions.net  Wed Mar 29 21:10:27 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 29 Mar 2006 13:10:27 -0800
Subject: Fedora's way forward
In-Reply-To: <442AEE5C.5050501@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<1143662804.19611.6.camel@yoda.loki.me>  <442AEE5C.5050501@hhs.nl>
Message-ID: <1143666627.19611.10.camel@yoda.loki.me>

On Wed, 2006-03-29 at 22:30 +0200, Hans de Goede wrote:
> I was talking about fluendo, so this tool would help users to download 
> legitimate plugins, I also suggested that maybe we could convince real 
> to make real codecs available for such a semi automated install, so
> there is no infringement here. Please read my post again, and next time 
> read before shooting a default answer from the hip.

From what I gather, our Legal team did not see it as possible to even do
this, if we had wanted to.  We don't WANT to encourage the use of these
non-free codecs.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/447613db/attachment.sig>

From jkeating at j2solutions.net  Wed Mar 29 21:12:47 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 29 Mar 2006 13:12:47 -0800
Subject: Fedora's way forward
In-Reply-To: <3400f2f60603290924y6e452f0av2986cc10911b2d9@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<ufahd5h9o50.fsf@epithumia.math.uh.edu>
	<08ef01c65354$0529c6a0$b6491b31@td612671>
	<3400f2f60603290924y6e452f0av2986cc10911b2d9@mail.gmail.com>
Message-ID: <1143666767.19611.13.camel@yoda.loki.me>

On Wed, 2006-03-29 at 11:24 -0600, J. K. Cliburn wrote:
> 
> Java, dead?  Hardly.  Go to pogo.com at any moment of any given day
> and behold a quarter million souls, each one playing a java-based
> game, many paying about US$30 per year for the privilege to do so.

The same amount of people would be playing those games if they were
coded in flash as well.  End users like that could give a flying leap
what code was used to produce their game.  Just as long as it is
extremely easy to get whatever is needed to play them.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/d8941211/attachment.sig>

From camilo at mesias.co.uk  Wed Mar 29 21:14:42 2006
From: camilo at mesias.co.uk (Cam)
Date: Wed, 29 Mar 2006 22:14:42 +0100
Subject: Assignment of internet keys / media buttons
In-Reply-To: <BAYC1-PASMTP036AC254DD0F80BC16BB37AED30@CEZ.ICE>
References: <4427C9DC.5020708@mesias.co.uk>	<1143463458.2869.21.camel@pensja.lam.pl>	<442921D8.2060504@mesias.co.uk>
	<BAYC1-PASMTP036AC254DD0F80BC16BB37AED30@CEZ.ICE>
Message-ID: <442AF8C2.9060406@mesias.co.uk>

sean

> Don't know if this has been mentioned before in the conversation but many
> keyboards already have full mappings provided which the user can
> select by running gnome-keyboard-properties.   Adding additional types
> for selection would be helpful.

Now I'm amazed. I stuggled to find the right mappings and put them into 
an xmodmap file - only to find that there was a perfectly good 'keyboard 
model' hidden in gnome-keyboard-properties. (Thanks Sean!)

I think there are two problems here.

1. the name wasn't intuitive enough: "Laptop/notebook Dell Inspiron 
6xxx/8xxx". I might have had a chance if the list was presented as a 
hierarchy, or if it was under Dell or Inspiron.

2. it's too easy to choose a working (but incorrect) key model when 
installing.

Is this deserving of a bugzilla entry?

-Cam

-- 

                                                                      <--
camilo at mesias.co.uk



From rms at 1407.org  Wed Mar 29 20:43:42 2006
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Wed, 29 Mar 2006 21:43:42 +0100
Subject: Fedora's way forward
In-Reply-To: <20060329145350.GA10714@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
Message-ID: <1143665023.6294.4.camel@localhost.localdomain>

On Wed, 2006-03-29 at 09:53 -0500, Eric S. Raymond wrote:
> Rahul Sundaram <sundaram at fedoraproject.org>:
> > Thats exactly what would happen. You can talk about all you want about
> > support open formats but if you dont actually build up volume nobody is
> > going to use it. If mp3 was supported out of the box in Fedora, why
> > would there be any incentive left for anyone to use ogg codecs?
> 
> Um...because Ogg is a better format?

Right, and Beta Max was a better format than VHS (or so some would say,
I wouldn't know since at that time I not even had a vcr yet). Where's
Beta now?

Better doesn't mean it will be chosen. If that were so, I can't see how
we'd be fighting such huge monopolies :)

> > Those are Fedora users too. Should we abandon them?
> 
> Zealots drive me crazy.  Poke one in the wrong place and his brain
> just shuts down entirely.
> 
> Read my lips: nobody is talking about 'abandoning' any user, distribution,
> or format.  Adding support for what users actually want is not abandonment.

Zealots complaining of zealots is a lot of fun, indeed.

If Red Hat is closed down because of illegal distribution of software
covered under patent rights (a TRIPs violation IMHO), or because it
incentivates user's violation by not forbidding it at all by not
preventing copying... 

What "support" is that? Most desired media formats can only be played if
you distribute illegally copies of DLLs.

Rant where you must: at those detaining the rights that harm us.

Do not bark at the wrong door, you might get shot rather than a nice
steak :)

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

From seanlkml at sympatico.ca  Wed Mar 29 21:30:03 2006
From: seanlkml at sympatico.ca (sean)
Date: Wed, 29 Mar 2006 16:30:03 -0500
Subject: Assignment of internet keys / media buttons
In-Reply-To: <442AF8C2.9060406@mesias.co.uk>
References: <4427C9DC.5020708@mesias.co.uk>
	<1143463458.2869.21.camel@pensja.lam.pl>
	<442921D8.2060504@mesias.co.uk>
	<BAYC1-PASMTP036AC254DD0F80BC16BB37AED30@CEZ.ICE>
	<442AF8C2.9060406@mesias.co.uk>
Message-ID: <BAYC1-PASMTP104DC52F4D6F0BD07D06C6AED00@CEZ.ICE>

On Wed, 29 Mar 2006 22:14:42 +0100
Cam <camilo at mesias.co.uk> wrote:

> Now I'm amazed. I stuggled to find the right mappings and put them into 
> an xmodmap file - only to find that there was a perfectly good 'keyboard 
> model' hidden in gnome-keyboard-properties. (Thanks Sean!)
> 
> I think there are two problems here.
> 
> 1. the name wasn't intuitive enough: "Laptop/notebook Dell Inspiron 
> 6xxx/8xxx". I might have had a chance if the list was presented as a 
> hierarchy, or if it was under Dell or Inspiron.
>
> 2. it's too easy to choose a working (but incorrect) key model when 
> installing.
> 
> Is this deserving of a bugzilla entry?

An RFE maybe, although maybe it is more appropriate upstream?   I honestly
don't know.

I have run into the problem as well, not knowing which of 10 models actually 
matched the keyboard in front of me.   Not sure how to make it easier unless
each and every keyboard model can be listed explicitly somehow.   

The cat's meow would be to have pictures of each keyboard too; would that 
be legal? 

Sean



From Lam at Lam.pl  Wed Mar 29 21:36:00 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Wed, 29 Mar 2006 23:36:00 +0200
Subject: Fedora's way forward
In-Reply-To: <1143666627.19611.10.camel@yoda.loki.me>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<1143662804.19611.6.camel@yoda.loki.me>  <442AEE5C.5050501@hhs.nl>
	<1143666627.19611.10.camel@yoda.loki.me>
Message-ID: <1143668160.4136.12.camel@pensja.lam.pl>

Dnia 29-03-2006, ?ro o godzinie 13:10 -0800, Jesse Keating napisa?(a):
> We don't WANT to encourage the use of these non-free codecs.
Allowing MP3 != encouraging MP3.

Forcing Ogg Vorbis != encouraging Ogg Vorbis.

I don't speak english very well, so please tell me, can one encourage
anything when there's no other choice?

Remember we're only speaking about pointing users at Fluendo, which is
legal.

And, as I don't own any MP3 player myself, will stick to Ogg Vorbis for
my music, so don't think I'm against you or Fedora or "free" or
anything.

Also remember MP3 is the "free" standard of the future - by 2010 it
becomes public domain, so there'll be no "proprietary" argument
involved. Right now, if someone already paid Thomson their fee, the best
thing to do is using it as much as we can, to make the their per-user
income lesser :) I know, it's stupid :)

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/d9e94c34/attachment.sig>

From jkeating at j2solutions.net  Wed Mar 29 21:45:50 2006
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 29 Mar 2006 13:45:50 -0800
Subject: Fedora's way forward
In-Reply-To: <1143668160.4136.12.camel@pensja.lam.pl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<1143662804.19611.6.camel@yoda.loki.me>  <442AEE5C.5050501@hhs.nl>
	<1143666627.19611.10.camel@yoda.loki.me>
	<1143668160.4136.12.camel@pensja.lam.pl>
Message-ID: <1143668750.3242.55.camel@ender>

On Wed, 2006-03-29 at 23:36 +0200, Leszek Matok wrote:
> I don't speak english very well, so please tell me, can one encourage
> anything when there's no other choice? 

Allowing MP3 != encouraging ogg.

At the end of the day, it doesn't really matter, as MP3 technology as it
currently stands is not acceptable within Fedora, nor linked to by
Fedora.  End of discussion.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/51e61788/attachment.sig>

From mknepher at bluethingy.com  Wed Mar 29 21:50:00 2006
From: mknepher at bluethingy.com (Michael Knepher)
Date: Wed, 29 Mar 2006 13:50:00 -0800
Subject: Fedora's way forward
In-Reply-To: <1143666627.19611.10.camel@yoda.loki.me>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<1143662804.19611.6.camel@yoda.loki.me>  <442AEE5C.5050501@hhs.nl>
	<1143666627.19611.10.camel@yoda.loki.me>
Message-ID: <1143669000.30290.13.camel@lionel-hutz.darnell.group>

On Wed, 2006-03-29 at 13:10 -0800, Jesse Keating wrote:
> On Wed, 2006-03-29 at 22:30 +0200, Hans de Goede wrote:
> > I was talking about fluendo, so this tool would help users to download 
> > legitimate plugins, I also suggested that maybe we could convince real 
> > to make real codecs available for such a semi automated install, so
> > there is no infringement here. Please read my post again, and next time 
> > read before shooting a default answer from the hip.
> 
> From what I gather, our Legal team did not see it as possible to even do
> this, if we had wanted to.  We don't WANT to encourage the use of these
> non-free codecs.
> 

While I don't think Fedora should be providing any *nudge, nudge, wink,
wink* "semi-automated" mechanisms for installing non-free codecs, what
are the possibilities/ramifications of including a mention of the
fluendo mp3 codec in either the release notes or the forbidden items
FAQ? I rip all my CDs in ogg, and even bought an iriver player to use
them, but taking the stance that by choosing Fedora I should lock up all
of the mp3s I bought from emusic.com seems a bit extreme.

> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From pemboa at gmail.com  Wed Mar 29 21:50:28 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 29 Mar 2006 15:50:28 -0600
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603291135060.30613@master.geeklords.org>
References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
	<Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
	<20060329130044.GB3411@dudweiler.stuttgart.redhat.com>
	<16de708d0603290836s6d580f44v2e652255a824827e@mail.gmail.com>
	<Pine.LNX.4.63.0603291135060.30613@master.geeklords.org>
Message-ID: <16de708d0603291350t5868baa2qf1893ce7930ade32@mail.gmail.com>

On 3/29/06, Shane Stixrud <shane at geeklords.org> wrote:
>
> On Wed, 29 Mar 2006, Arthur Pemberton wrote:
>
> >> A full ack on this, we would solve a lot of items if we could move
> >> forward to have a standard lib for all this. But it will be very
> >> hard to have agreement on how to solve it and even more to make
> >> projects move over from their current ways.
> >
> > I think the process of getting other projects to use this "standard"
> would
> > be to put some though into the design and mark multiple backends and
> > multiple interfaces part of the design. If there are libs, modules,
> > languages binds, etc with as little dependancy hell as possible, I think
> > projects will eventually gravitate to this solution. I know I wouldn't
> roll
> > my own config parser if there is a perfectly good one already included
> on my
> > system , or which can easily be added to any system.
>
> I agree design is key here.  However our community generally wants no part
> of discussing requirements and then writing specifications in English.
> They want actual code... Is there a good case here for gathering
> requirements and perhaps writing a specification, getting feedback from
> the major players prior to code being written?
>
> Cheers,
> Shane
>
> Only case I see here is individual desire. People passioate enough about
this need to solve the problem. I and apperently many others simply do not
see this as a big enough problem. I am actually suprised by the length of
this thread. Don't get me wrong, I see the problem, and I think I understand
it. It just isn't a hurdle I run into often. Now, if we were talking about
the sendmail conf files....
--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/ae625fb1/attachment.htm>

From zaitcev at redhat.com  Wed Mar 29 22:00:09 2006
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 29 Mar 2006 14:00:09 -0800
Subject: Fedora's way forward
In-Reply-To: <1143657279.25616.11.camel@daxter.boston.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
Message-ID: <20060329140009.5b55cf3b.zaitcev@redhat.com>

On Wed, 29 Mar 2006 13:34:38 -0500, David Zeuthen <david at fubar.dk> wrote:

> Please explain why it is difficult for the user to grab 
> 
>  gstreamer-plugins-bad
>  gstreamer-ffmpeg
>  gstreamer-plugins-ugly

> Sure, now you can enumerate tons of practical reasons such as
> discoverability and I would even agree with you.

How about a discoverability of the package name of the month?
Gstreamer people seem to receive sadistic pleasure from renaming
packages.

-- Pete



From shane at geeklords.org  Wed Mar 29 22:01:27 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Wed, 29 Mar 2006 14:01:27 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <16de708d0603291350t5868baa2qf1893ce7930ade32@mail.gmail.com>
References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
	<Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
	<20060329130044.GB3411@dudweiler.stuttgart.redhat.com>
	<16de708d0603290836s6d580f44v2e652255a824827e@mail.gmail.com>
	<Pine.LNX.4.63.0603291135060.30613@master.geeklords.org>
	<16de708d0603291350t5868baa2qf1893ce7930ade32@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603291358100.30945@master.geeklords.org>

On Wed, 29 Mar 2006, Arthur Pemberton wrote:

> Only case I see here is individual desire. People passioate enough about
> this need to solve the problem. I and apperently many others simply do not
> see this as a big enough problem. I am actually suprised by the length of
> this thread. Don't get me wrong, I see the problem, and I think I understand
> it. It just isn't a hurdle I run into often. Now, if we were talking about
> the sendmail conf files....

I don't really agree.  I think the reason you see a number of RedHat 
employees agreeing that this is important is because there are real 
issues their enterprise customers want addressed that is either directly 
or indirectly negatively affected by this more fundamental issue.

Cheers,
Shane



From pemboa at gmail.com  Wed Mar 29 22:30:51 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 29 Mar 2006 16:30:51 -0600
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603291358100.30945@master.geeklords.org>
References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
	<Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
	<20060329130044.GB3411@dudweiler.stuttgart.redhat.com>
	<16de708d0603290836s6d580f44v2e652255a824827e@mail.gmail.com>
	<Pine.LNX.4.63.0603291135060.30613@master.geeklords.org>
	<16de708d0603291350t5868baa2qf1893ce7930ade32@mail.gmail.com>
	<Pine.LNX.4.63.0603291358100.30945@master.geeklords.org>
Message-ID: <16de708d0603291430v73d59c24ha71ccf9c414b851d@mail.gmail.com>

On 3/29/06, Shane Stixrud <shane at geeklords.org> wrote:
>
> On Wed, 29 Mar 2006, Arthur Pemberton wrote:
>
> > Only case I see here is individual desire. People passioate enough about
> > this need to solve the problem. I and apperently many others simply do
> not
> > see this as a big enough problem. I am actually suprised by the length
> of
> > this thread. Don't get me wrong, I see the problem, and I think I
> understand
> > it. It just isn't a hurdle I run into often. Now, if we were talking
> about
> > the sendmail conf files....
>
> I don't really agree.  I think the reason you see a number of RedHat
> employees agreeing that this is important is because there are real
> issues their enterprise customers want addressed that is either directly
> or indirectly negatively affected by this more fundamental issue.
>
> Cheers,
> Shane
>
> Ah. Well that is understandable. They certainly have a point of view which
I have not yet had the honor of.

Might I make a suggestion to anyone considerinf "fixing" this. I would
suggest the use of virtual files. So for example, program-foo which uses
program-foo.conf could attempt to read/parse/saveto program-foo.conf which
could be actually a virtual file serving as a front end to a system which
handles everything else.


--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/ca9a37e8/attachment.htm>

From chasd at silveroaks.com  Wed Mar 29 22:37:42 2006
From: chasd at silveroaks.com (chasd at silveroaks.com)
Date: Wed, 29 Mar 2006 16:37:42 -0600
Subject: Fedora's way forward
In-Reply-To: <20060328104906.2463673150@hormel.redhat.com>
References: <20060328104906.2463673150@hormel.redhat.com>
Message-ID: <c4ec28741d94c150957de99d2470a2c9@silveroaks.com>

I know I'm late jumping into this thread.
I also realize I am a lurker for the most part, but I felt I should 
respond.

On 3/28/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> Good thing the fourth: A combination of increased polish in various
> distro components and significant upstream developments (one biggie
> being OpenOffice 2.0) has, to my observation, inched FC across an
> important functional threshold.  My wife can use it with as little
> pain as Windows now, rather than merely tolerating the crap because
> she believes in what the Linux community is trying to do.

For some users this happened in the FC3/FC4 timeframe.

> First, a relatively minor issue that is nevertheless quite annoying.
> It's the Fedora distribution art, the images in Anaconda and the
> Fedora-customized graphics in the admin tools and elsewhere.  It has
> never been much better than mediocre, and in FC5 it hits a new low
> with backgrounds that look like a Teletubby hocked loogies into a
> dish full of soap scum.

Constructive criticism would do more.
What kind of imagery would be better, considering the same goals and 
parameters the designers were given ? Without _constructive_ criticism, 
the comments seem like something from Simon Cowell.

> And whose bright idea, I have to wonder, was
> it to abandon the attractive and recognizable Fedora icon for
> something that's...not a fedora?

The Fedora project does need to come out from the shadow of Red Hat. 
Establishing a new visual identity is an important part of that. 
Whether the new identity is hitting its goals is a different question, 
but the change needed to happen.

> And
> original BlueCurve wasn't much to cheer about compared to the
> decorative art on a Windows or (especially) a Mac -- acceptable, but
> not a competitive plus,

Personally I have a negative reaction to the Windows XP interface 
graphics, I think the FC5 interface at least as appealing. With the 
different themes available. our users are happy they have a choice to 
configure the interface, which a stock Windows install has less 
latitude and is harder to find for our users.

> That means high-quality art, art that makes people actually *want* to
> look at the screen because it's a significant aesthetic experience.

Graphics are not art. Graphics are the prostitution of art concepts and 
techniques to get a specific desired reaction for the benefit of the 
party paying for the graphics.

Successful graphics need to have goals established and the success of 
the graphics is measured against those goals. Many times looking 
"pretty" is a low priority goal for graphics. "Pretty" graphics can be 
a pleasant side benefit of successful graphics.  When considering the 
goals for graphics, it is possible for _one_ of those goals to be 
visual appeal.

> But the art problem pales compared to the issue that everyone has been
> ducking, which is Fedora's support for DVDs and proprietary audio and
> video and web-streaming formats and Java applets.

> AVI.  Quicktime.  ASF.  MPEG.  DVD playback.  Flash.  Java. These are
> *not optional* in 2006

Flash is available for x86 Linux with the same licensing terms for the 
other OS's Adobe supports. That says Adobe treats Linux on equal 
footing to other OS's, or what I could call a level playing field. Why 
should Linux get special treatment ? A stock install of Windows does 
not include Flash, although it may be bundled by an OEM hardware 
manufacturer.

Sun's JRE is available for x86 with the same licensing as other OS's. 
Again Linux is treated the same as other OS's, not as a special 
stepchild. A stock install of Windows does not include a JRE, or if one 
is included it is Microsoft's crusty old thing that is much worse than 
the free stack provided with Fedora.

A stock install of Windows does not include DVD,  MPEG2, or MPEG4 
playback. These are provided by bundles of third party software the 
hardware manufacturer includes on top of the OS. Remember, a WMV file 
that uses a MPEG4 codec is not a standard MPEG4 file. A file that 
adheres to the MPEG4 standard is not playable with WMP as shipped by 
MS.

Even on commercial operating systems, video playback is a crapshoot. As 
a graphics professional, determining the best digital video format to 
use is a project-by-project set of trade-offs. I really don't expect it 
to be any easier with Linux. Several of our clients now lean to Flash 
video because a player exists for Linux in addition to the other big 
two commercial OS's.

<rant>
If I was Michael Dell, I wouldn't be complaining about how many 
different Linux distributions there are, I would be putting money into 
developing applications that provide this "last mile" media 
functionality to Linux, and providing an OS bundle that matches the 
functionality provided by the Windows bundles they offer. It is needed, 
and there is a business opportunity to provide an out-of-the-box 
experience for Linux similar to Windows. It is my opinion that it is 
the hardware manufacturer that is to provide the solution to that gap 
<emphasis> as it does with other operating systems </emphasis> not the 
OS vendor.
</rant>

To look at the media playback "deficiency" from _my_ perspective, I 
consider the absence of media players to be an advantage.

Yes, an advantage.

For the same reasons I remove the games installed by default on 
Windows, I do not want media players on company systems. I do not want 
employee time wasted viewing streaming video or audio. I don't want 
employees to watch the telly at work, and I don't want them consuming 
other media via the computer in front of them at work either. It is an 
unnecessary distraction. I also don't want the liability of digital 
media files of unknown source residing on company systems. Those 
problems are solved by removing or not providing media players.

In the home environment, that is different, however I don't care what 
someone does in their own home. It is possible that Fedora is not 
suitable for some home users who require media playback without their 
hardware OEM providing it for them in a bundle, like what happens with 
commercial OS's. It _is_ suitable in a business environment in its 
present form _because_ this media functionality is not present.


Charles Dostale
System Admin - Silver Oaks Communications
http://www.silveroaks.com/



From dlutter at redhat.com  Wed Mar 29 23:13:25 2006
From: dlutter at redhat.com (David Lutterkort)
Date: Wed, 29 Mar 2006 15:13:25 -0800
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060328212921.5342f91f.seanlkml@sympatico.ca>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<20060328212921.5342f91f.seanlkml@sympatico.ca>
Message-ID: <1143674006.3608.123.camel@currant.watzmann.net>

On Tue, 2006-03-28 at 21:29 -0500, sean wrote:
> On Tue, 28 Mar 2006 17:51:14 -0800
> David Lutterkort <dlutter at redhat.com> wrote:
> 
> > While I agree in theory, the reality of config files with different
> > formats makes it extremely hard to get there. One approach that is being
> > pushed by a number of players to achieve uniform management of configs
> > is CIM/WBEM, an enormous standard that IMHO too much tool-specific
> > knowledge to see wide adoption.
> > 
> > A lighter-weight approach seems more promising: encapsulate most of the
> > config-file specific knowledge in simple script wrappers that can be
> > controlled by a declarative description of the configuration you want to
> > achieve and the logical interdependencies between them. This is what
> > puppet does, and why I find it very attractive.
> 
> Okay, so your script wrappers do all the config-file specific work etc.  
> We talked about making a tool earlier in this conversation that would 
> know how to handle all the different config file formats, so i'm with 
> you up to there.

The pain of parsing different config file formats is only part of the
problem: the bigger problem are the semantics of all the config entries,
which the user still needs to understand.

> But what is the advantage of building an entire new config language 
> around these wrappers?  Couldn't they be manipulated just as easily 
> with shell or python?

There are lots of advantages of a domain specific language over doing
this with basic scripts:
      * It's easy to provide infrastructure for common tasks (like
        logging or notification if changes are detected)
      * The user expresses what they want to achieve rather than how to
        achieve it
      * The description represents the config in metadata and can be
        processed by other tools. For comparison: since kickstart has a
        well-defined file format, it's possible to write UI tools to
        manipulate them, which wouldn't be possible if a kickstart file
        was a shell script with some supporting utility scripts
      * Some things that are hairy to express in scripts can be clearly
        expressed in the language, e.g., dependencies between components
        (put a custom httpd.conf into place before starting httpd; when
        httpd.conf changes, httpd needs to be restarted) and logical
        grouping of components for reuse (this is what I mean when I say
        'webserver' or 'mailserver')

>  Can the administrator make simple ad-hoc command line config file changes?

If you allow ad-hoc changes, you allow systems to deviate from the
predefined configuration; that may or may not be what you want. If it is
what you want, you should use the config mgmt tool only for the initial
setup, and then do your changes as you always would, without using the
tool. But if you are interested in keeping the config of several
machines in sync, you are better off making the changes in the config
mgmt tool's description.

David



From alan at redhat.com  Wed Mar 29 23:24:08 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Mar 2006 18:24:08 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329145350.GA10714@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
Message-ID: <20060329232408.GA26863@devserv.devel.redhat.com>

On Wed, Mar 29, 2006 at 09:53:50AM -0500, Eric S. Raymond wrote:
> Zealots drive me crazy.  Poke one in the wrong place and his brain
> just shuts down entirely.
> 
> Read my lips: nobody is talking about 'abandoning' any user, distribution,
> or format.  Adding support for what users actually want is not abandonment.

Better idea, read the Fedora documentation and goals of the Fedora project.



From dlutter at redhat.com  Wed Mar 29 23:24:19 2006
From: dlutter at redhat.com (David Lutterkort)
Date: Wed, 29 Mar 2006 15:24:19 -0800
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281825400.28495@master.geeklords.org>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<Pine.LNX.4.63.0603281825400.28495@master.geeklords.org>
Message-ID: <1143674659.3608.129.camel@currant.watzmann.net>

On Tue, 2006-03-28 at 19:20 -0800, Shane Stixrud wrote:
> > I have been using another config mgmt system, puppet,
> > (http://reductivelabs.com/projects/puppet) I wrote up an example of how
> > a config mgmt tool could help in solving the kind of problem you are
> > looking at: http://people.redhat.com/dlutter/puppet-app.html
> 
> Puppet looks like a very promising centralized change distribution system. 
> As you mentioned this separates the "how" changes are applied from the 
> "what" is actually changing.  If you combine the change re-visioning 
> concept mentioned above with a puppet like centralized distribution system 
> that can detect client changes we now have something quite impressive.

Yes, one of the things I am very interested in is combining puppet with
a distributed SCM like mercurial, both for distribution of canned
configs, and for tracking changes to those configs over time. Puppet
right now logs what changes it applied to each machine, but that should
probably be expanded to produce a more focused history.

> In fact it resembles very much what I have with my Cisco equipment + 
> management software.

Interesting. Any pointers where I can look at docs ?

David




From camilo at mesias.co.uk  Wed Mar 29 23:31:08 2006
From: camilo at mesias.co.uk (Cam)
Date: Thu, 30 Mar 2006 00:31:08 +0100
Subject: Assignment of internet keys / media buttons
In-Reply-To: <BAYC1-PASMTP104DC52F4D6F0BD07D06C6AED00@CEZ.ICE>
References: <4427C9DC.5020708@mesias.co.uk>	<1143463458.2869.21.camel@pensja.lam.pl>	<442921D8.2060504@mesias.co.uk>	<BAYC1-PASMTP036AC254DD0F80BC16BB37AED30@CEZ.ICE>	<442AF8C2.9060406@mesias.co.uk>
	<BAYC1-PASMTP104DC52F4D6F0BD07D06C6AED00@CEZ.ICE>
Message-ID: <442B18BC.4020003@mesias.co.uk>

sean

> The cat's meow would be to have pictures of each keyboard too; would that 
> be legal? 

Or... maybe gnome-keyboard-properties would detect that you are running 
with a basic keyboard, and ask if you have any media keys... Then asked 
you to press 'Play', and as many more keys as it takes to match the 
hardware to a map...

-Cam

-- 

                                                                      <--
camilo at mesias.co.uk



From alan at redhat.com  Wed Mar 29 23:31:21 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Mar 2006 18:31:21 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143653861.18075.8.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<1143653861.18075.8.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060329233121.GB26863@devserv.devel.redhat.com>

On Wed, Mar 29, 2006 at 12:37:40PM -0500, Peter Jones wrote:
> The block layer (or below) does the bogus prefetch.  What inhibits this
> behavior when you're accessing through a filesystem driver?

The file system does the prefetch and it prefetches blocks on a per filebasis

(ie /dev/foo asks for "n, n+1, n+2, n+3
   /isofs/frob.rpm asks for "n, next block of frob, next but one of frob..."

> I think we have exactly the same problem there, and people have
> witnessed accesses through the FS fail near the end of the disk with our
> install media.  To me, it looks like the same behavior.

Any specific bugzilla #'s ?



From alan at redhat.com  Wed Mar 29 23:32:28 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Mar 2006 18:32:28 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143654010.18075.12.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
	<20060329104913.GD11828@devserv.devel.redhat.com>
	<1143654010.18075.12.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060329233228.GC26863@devserv.devel.redhat.com>

On Wed, Mar 29, 2006 at 12:40:09PM -0500, Peter Jones wrote:
> I'm certainly willing to try this...
> 
> ... but we still have a lingering problem with dm where *it* tries to
> read off the end of its underlying devices.

If as I'm pretty sure it tries to read into the end fuzzy zone then since
the dm mapping is smaller the dm instance won't read further because it has
a known end (the one you yanked from the isofs)



From alan at redhat.com  Wed Mar 29 23:45:02 2006
From: alan at redhat.com (Alan Cox)
Date: Wed, 29 Mar 2006 18:45:02 -0500
Subject: Thinkpad, Thinkpad, Thinkpad
In-Reply-To: <1143661684.18075.49.camel@vroomfondel.internal.datastacks.com>
References: <20060327225928.GA16219@thyrsus.com>
	<1143503374.11720.12.camel@mentorng.gurulabs.com>
	<1cef3e950603271604s707ba7c7v2b140dd28a3251d5@mail.gmail.com>
	<20060328000916.GA16973@thyrsus.com>
	<20060328101331.GB12588@devserv.devel.redhat.com>
	<1143575657.26465.62.camel@vroomfondel.internal.datastacks.com>
	<20060328212959.GA30334@devserv.devel.redhat.com>
	<1143584440.3095.58.camel@vroomfondel.internal.datastacks.com>
	<20060329101459.GA11828@devserv.devel.redhat.com>
	<1143661684.18075.49.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060329234502.GF26863@devserv.devel.redhat.com>

On Wed, Mar 29, 2006 at 02:48:04PM -0500, Peter Jones wrote:
> Yeah.  But right now the installer doesn't have any data available about
> HPA at all, so it can't do the partitioning right if we're disabling HPA
> (which we are).

Right because it was disabled too early for the installer to check

> Which means for FC6, we have to disable HPA by default, and
> conditionally re-enable it if there's no partition table entry that
> points above the top.

You never need to re-enable it. The partition table and partition sizes
define the size of hda1 and fs etc.

> Tangentally, I might add that if Fibre Channel, iSCSI, or similar ever
> invent a function like this, we better not screw it up as much as we
> have this time, because changing the geometry of another machine's disk
> is seriously not fun to recover from.  Just my introspective thought for
> the day.

If you want real fun try mixing EFI firmware, GPT and HPA. So I really hope HPA
goes away. Its like drive passwords, a fine example of why storage device 
designers should be allowed to invent things that are OS matters 8)

> > HPA out after the ACPI stuff runs once it is in as on the thinkpad it also
> > edits the HPA settings when those run
> 
> OK... is there a patch floating around for the _GTF stuff already?  URL?
> Also, are (whoever's doing it) doing _GTM/_STM work as well?

The stuff done so far went to l/k and is a work in progress.



From robn at berrymount.nl  Wed Mar 29 23:50:17 2006
From: robn at berrymount.nl (Rob van Nieuwkerk)
Date: Thu, 30 Mar 2006 01:50:17 +0200
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143660386.18075.32.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
	<20060329104913.GD11828@devserv.devel.redhat.com>
	<20060329195107.baa44e9a.robn@berrymount.nl>
	<1143660386.18075.32.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060330015017.f75cb8b1.robn@berrymount.nl>

On Wed, 29 Mar 2006 14:26:26 -0500
Peter Jones <pjones at redhat.com> wrote:

> On Wed, 2006-03-29 at 19:51 +0200, Rob van Nieuwkerk wrote:
> 
> > Sure.  Or something like this:
> > 
> > 	dd conv=idirect if=/dev/cdrom count=right_number | sha1sum
> > 
> > And if the dd used on the FC ISO does not support the O_DIRECT feature,
> > just add it.  Or write a completely trivial 10 line C program that
> > does the same.
> 
> This will almost always get you the wrong result.  At the very least,
> you need 'bs=2048 count="$(($(isosize /dev/cdrom) / 2048))"' with that,
> or you wind up doing md5sum on completely bogus data with some media.
> 
> But as it turns out, that fails the exact same way that mediacheck does.
> 
> > I really never understood why there never has been any trivial
> > work-around on the FC images for this very annoying problem.
> 
> dd does read(2) just like mediacheck does.  There isn't some spooky
> magic here.  It fails in exactly the same ways for exactly the same
> reasons.

Hi Peter,

Did you miss the O_DIRECT part ?

A read(2) on an fd opened with O_DIRECT should never lead to any readahead
by the kernel.  On the device level *only* the blocks requested by the
userspace read() are read.  Nothing more.

	greetings,
	Rob van Nieuwkerk



From camilo at mesias.co.uk  Wed Mar 29 23:57:44 2006
From: camilo at mesias.co.uk (Cam)
Date: Thu, 30 Mar 2006 00:57:44 +0100
Subject: Fedora's way forward
In-Reply-To: <1143666767.19611.13.camel@yoda.loki.me>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<20060328104659.GI12588@devserv.devel.redhat.com>	<1143651293.5600.228.camel@pmac.infradead.org>	<ufahd5h9o50.fsf@epithumia.math.uh.edu>	<08ef01c65354$0529c6a0$b6491b31@td612671>	<3400f2f60603290924y6e452f0av2986cc10911b2d9@mail.gmail.com>
	<1143666767.19611.13.camel@yoda.loki.me>
Message-ID: <442B1EF8.503@mesias.co.uk>

Jesse

> The same amount of people would be playing those games if they were
> coded in flash as well.  End users like that could give a flying leap
> what code was used to produce their game.  Just as long as it is
> extremely easy to get whatever is needed to play them.

What about multiplayer / 3d games (eg. www.runescape.com). You could 
argue that Java can do more than Flash. I don't think we can write off 
Java in the browser yet (not without seriously disappointing my sons 
anyway!).

-Cam
-- 

                                                                      <--
camilo at mesias.co.uk



From chasd at silveroaks.com  Thu Mar 30 00:01:46 2006
From: chasd at silveroaks.com (chasd at silveroaks.com)
Date: Wed, 29 Mar 2006 18:01:46 -0600
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <20060328130826.552AE7332A@hormel.redhat.com>
References: <20060328130826.552AE7332A@hormel.redhat.com>
Message-ID: <80f29a56369bed7174d43e7814d0a1b7@silveroaks.com>


On Mar 28, 2006, at 7:08 AM, Casimiro de Almeida Barreto wrote:

> Flash for Linux literally sucks... it is slow

As someone that has spent a good deal of time benchmarking Flash 
performance, this is not true. On the exact same hardware, the Linux 
Flash Player 7 plug-in plays as fast as the version 7 plug-in on 
Windows.

However, the Flash Player ActiveX control is more highly optimized than 
the plug-in, so if you compare Flash performance on Windows in IE to 
Flash performance on Linux with Firefox, Windows is faster in that 
case. If you use Firefox as the browser on both platforms, the 
performance is as close as my measurements could show. Since the 
current Flash Player for Windows is version 8, that throws another 
issue into the mix. My tests show version 8 to be up to 15% faster than 
version 7 using the same configuration. If you compare Flash 
performance using a Windows version 8 ActiveX control to a Linux 
version 7 plug-in, you are indeed comparing apples and oranges.

> and again there is no support for shockwave. People says that's
> due to the needs of using ActiveX for ShockWave run

Shockwave is available as both an ActiveX control and a plug-in on 
Windows. Unlike Flash, both versions have the same performance ( a 
plug-in is available for Macintosh too). The Shockwave group within 
Adobe is completely separate from the Flash development group. The 
usage base and defined goals of the Shockwave group must indicate 
little need for a Linux player. I of course disagree with that, but I'm 
not the Shockwave development manager ;)

For those hoping for a 64-bit Flash Player for Linux, the indications 
for the upcoming Flash Player 8.5 show no support planned for x86_64 on 
Windows, so I doubt it will appear on Linux.

Flash users on Linux should be aware that there is no plan for a 
version 8 Linux Player. The Flash group is working instead on a version 
8.5 Player. This effects Linux users because Adobe recommends upgrading 
to the most recent version 8 ( 8.0.24 ) to resolve several security 
issues. With the most recent issue ( CVE-2006-0024 ), Adobe is 
releasing fixes back-ported to version 7 players for depreciated 
platforms ( Win 95, Win NT, Mac OS < X ). Not included is Linux, which 
is not a depreciated platform ( which is good ). That means the Linux 
Flash Player version 7 has the above vulnerability, and a fix will not 
be available until Player 8.5 is available for Linux.

I know many of you won't touch Flash with a ten meter pole, but for 
those who do, be careful out there.


Charles Dostale
System Admin - Silver Oaks Communications
http://www.silveroaks.com/



From dan_young at mesd.k12.or.us  Thu Mar 30 00:17:51 2006
From: dan_young at mesd.k12.or.us (Dan Young)
Date: Wed, 29 Mar 2006 16:17:51 -0800
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <80f29a56369bed7174d43e7814d0a1b7@silveroaks.com>
References: <20060328130826.552AE7332A@hormel.redhat.com>
	<80f29a56369bed7174d43e7814d0a1b7@silveroaks.com>
Message-ID: <442B23AF.1060200@mesd.k12.or.us>

chasd at silveroaks.com wrote:
> 
> Flash users on Linux should be aware that there is no plan for a version
> 8 Linux Player. The Flash group is working instead on a version 8.5
> Player. This effects Linux users because Adobe recommends upgrading to
> the most recent version 8 ( 8.0.24 ) to resolve several security issues.
> With the most recent issue ( CVE-2006-0024 ), Adobe is releasing fixes
> back-ported to version 7 players for depreciated platforms ( Win 95, Win
> NT, Mac OS < X ). Not included is Linux, which is not a depreciated
                                                          ^^^^^^^^^^^
depreciate v. t.
   To lessen in price or estimated value; to lower the worth of;
   to represent as of little value or claim to esteem; to undervalue.

deprecated adj.
   Said of a program or feature that is considered obsolescent and in
   the process of being phased out, usually in favor of a specified
   replacement.

> platform ( which is good ). That means the Linux Flash Player version 7
> has the above vulnerability, and a fix will not be available until
> Player 8.5 is available for Linux.

Thankfully, no.

http://www.macromedia.com/devnet/security/security_zone/apsb06-03.html

It's been backported to Flash Player v7.0.63, which is available for
Linux, including in a nicely packaged form here:

http://macromedia.mplug.org/site_uh.html

-- 
Dan Young <dan_young at mesd.k12.or.us>
Multnomah ESD - Technology Services
503-257-1562



From david at fubar.dk  Thu Mar 30 00:22:17 2006
From: david at fubar.dk (David Zeuthen)
Date: Wed, 29 Mar 2006 19:22:17 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329140009.5b55cf3b.zaitcev@redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060329140009.5b55cf3b.zaitcev@redhat.com>
Message-ID: <1143678137.27889.14.camel@daxter.boston.redhat.com>

On Wed, 2006-03-29 at 14:00 -0800, Pete Zaitcev wrote:
> On Wed, 29 Mar 2006 13:34:38 -0500, David Zeuthen <david at fubar.dk> wrote:
> 
> > Please explain why it is difficult for the user to grab 
> > 
> >  gstreamer-plugins-bad
> >  gstreamer-ffmpeg
> >  gstreamer-plugins-ugly
> 
> > Sure, now you can enumerate tons of practical reasons such as
> > discoverability and I would even agree with you.
> 
> How about a discoverability of the package name of the month?
> Gstreamer people seem to receive sadistic pleasure from renaming
> packages.

How about just going to a web page, click on a link, press OK on some
dialogs and all this stuff just get installed along with .repo files for
updates? Personally, I've been using one of the 3rd party repos that
even have a tree for Rawhide. And.. the days of such repos overwriting
Core packages seems to have passed; works for me.

I just fail to see why we can't solve this with 3rd party repositories;
in fact my personal view is that Fedora should embrace such repos and
make it almost trivial for them to provide packages and keep in sync
with the various Fedora distributions (at this point, FC4, FC5, Rawhide)
insofar that e.g. 3rd party kernel modules RPM's get rebuilt when davej
et. al. pushes a new kernel. So if I'm an IHV like e.g. NVidia I just
provide a link on my webpage and the magic happens.

Of course it would be wonderful if everything was in Core/Extras, but,
really, this will never be the case especially not for hardware drivers
as it simply takes time to push things into the upstream kernel and then
into Fedora Core.

So.. if something cares enough.. and maybe someday someone will.. they
will do the work to enable ISV's, IHV's and 3rd party repos to easily
set this up. I cannot speak for Red Hat on this, but I cannot see why we
wouldn't take patches to simplify integration. 

Heck, in the future there may even be a viable business model for some
3rd party commercial entity to provide such a service to ISV's and IHV's
at a charge.

If someone does this I predict handling out-of-distro software
(including drivers) will provide the user with a superior experience to
what you get on Windows and the Mac today.

Someone just needs to do the work. Whether the package stems from Core,
Extras or some 3rd party repo should only make a difference on whether
you need to click a link on a web page or insert a CD from the
software/hardware vendor. And discussing whether the one-time pain of
clicking a link or inserting a CD is too much work for the user is just,
IMHO, ridiculous.

    David




From avi at unix.sh  Thu Mar 30 00:24:58 2006
From: avi at unix.sh (Avi Alkalay)
Date: Wed, 29 Mar 2006 21:24:58 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <200603290433.51839.billcrawford1970@googlemail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<200603290433.51839.billcrawford1970@googlemail.com>
Message-ID: <ed0efd310603291624w79595fb1m36a49e8bf983c9d7@mail.gmail.com>

On 3/29/06, Bill Crawford <billcrawford1970 at gmail.com> wrote:

> There are plenty of reasons why it hasn't happened, among which are a
> number
> of experiments with various forms of "registry" ...


It never happend because of the "bazar" nature of the OSS development model.
One of its big drawbacks is that there is no central architecture, no
central desing directions, no central decisions. So we see A LOT of code
rewriting, programs being developed in A LOT of different languages, and A
LOT of different configuration files formats.

As we all know, OSS model also have good advantages too.




> The reason most applications use individual config files instead of a
> central
> repository is because that makes it much, *much* easier to:
>
> 1. Design a domain-specific config language. XML does *NOT* solve this
> problem; it is a *lexical* (meta)language. The structure goes on top.


I see this as a disadvantage, since all, ALL config files are not more then
an hierarchical structure of key/value pairs. All lexical stuff you are
saying are fat to make it more human readable.




> 2. Point to a different config file when you start a program.


You can also point your program to a different root tree of keys. So using
Elektra terminology:

$ httpd -c system/tmp/mytest/mysite.com





> 3. Copy config files, rename them, reuse them, move them into chroot()
> environments, and generally be *free* to do so.


You can do the same with configuration trees. Elektra lets you even export
some tree to XML, take the file to another machine, and import it into a
different root tree. Check http://www.libelektra.org/presentation/img22.html

Avi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/625ac04b/attachment.htm>

From avi at unix.sh  Thu Mar 30 00:29:30 2006
From: avi at unix.sh (Avi Alkalay)
Date: Wed, 29 Mar 2006 21:29:30 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603281517360.27793@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<Pine.LNX.4.63.0603281444260.27793@master.geeklords.org>
	<604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com>
	<Pine.LNX.4.63.0603281517360.27793@master.geeklords.org>
Message-ID: <ed0efd310603291629v7cff3e77m2efdcfe8211ada6b@mail.gmail.com>

In addition to the words bellow, the "D" on D-Conf comes from the "Desktop"
word, which means D-Conf is a desktop-oriented wannabe-project. You won?t be
able to standarize configuration for say named, dhcpd, resolver, sysctl,
modprobe, /sbin/init, network configurations, etc etc etc with it.

On 3/28/06, Shane Stixrud <shane at geeklords.org> wrote:

> On Tue, 28 Mar 2006, Jeff Spaleta wrote:
>
> > would have discovered the D-Conf spec and related discussion and
> > followed up on it to see how its impacting upstream GConf development.
> > All of which happens outside the scope of fedora.
>
> "D-Conf generated a long discussion on FreeDesktop.org's XDG mailling
> list. Its objective is to standarize configuration across desktop
> frameworks like Gnome and KDE, so no focus is being devoted to global
> non-desktop system configurations.
>
> It was very difficult to find the D-Conf website (not found in the end),
> and seems that all is available is that XDG discussion, and a wiki page
> containing analisys of what is required, and development directions.
> Nothing else.
>
> Conclusion: D-Conf is vaporware. "
>
> source: http://www.libelektra.org/D-Conf
>
> I hope you are right and D-conf is making a difference, that seems to be
> debatable however.  Btw by all means do not be nice on my account, I enjoy
> raw personality :).
>
> Cheers,
> Shane
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060329/99ece8da/attachment.htm>

From shane at geeklords.org  Thu Mar 30 01:40:32 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Wed, 29 Mar 2006 17:40:32 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143674659.3608.129.camel@currant.watzmann.net>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<Pine.LNX.4.63.0603281825400.28495@master.geeklords.org>
	<1143674659.3608.129.camel@currant.watzmann.net>
Message-ID: <Pine.LNX.4.63.0603291551150.31197@master.geeklords.org>

On Wed, 29 Mar 2006, David Lutterkort wrote:

>> In fact it resembles very much what I have with my Cisco equipment +
>> management software.
>
> Interesting. Any pointers where I can look at docs ?

Well not comprehensive docs per say, but I can outline how it works.

Here is an example of an active config state on a cisco device:

http://geeklords.org/~shane/cisco.cfg

It is important to note from a admin perspective the configuration 
directives in the above file IS equal to the function that device has been 
instructed to perform.

Now I am not proposing this type of configuration interface would work 
for Linux, Cisco has much less to consider and even so there are 
things about their configuration process I think could be improved.  But 
their semi-standardized plain text directives allows their 
management software (cisco resource manager) to easily track system 
changes, apply system changes and revert system changes across multiple 
platforms using the same "command directives" that the end user would 
manually enter.

Being able to easily do the following on Linux would be very nice.

1) Show all configuration directives that are not at their default values 
i.e.:

cfg_report -keys -nondefaults /system/dhcpd

system/dhcpd/option/domain-name/
system/dhcpd/option/domain-name-servers/
system/dhcpd/subnet/172.20.0.0 netmask 255.255.255.0/
system/dhcpd/subnet/172.20.64.0 netmask 255.255.254.0/
etc...


2) Save/restore keys and values

cfg_mgr -export .ini,xml,tar -nodefaults / >/root/changes.tar
cfg_mgr -import /root/changes.tar /

cfg_mgr -export file / >/root/hostname.cfg (very large path/key/value text 
file)

cfg_mgr -import /root/dhcpd.tar /system/dhcpd

3) Display and edit all ntpd's configuration keys/values a standard editor

cfg_edit -export plaintext -editor <editor> /system/ntpd

*note* this would include /etc/ntp/keys /etc/ntp/step-tickers etc..

4) revert dhcpd to a specific date/time

cfg_mgr -revert 03/05/2006 /system/dhcpd


If/when the above is possible centralized config policy management 
becomes a no brainer.  We just create a cron job where we can optionally 
sync changed keys/values prior to downloading the devices new/active 
directives.

cfg_mgr -push -pull -server host.domain.top

Cheers,
Shane



From ianburrell at gmail.com  Thu Mar 30 03:08:24 2006
From: ianburrell at gmail.com (Ian Burrell)
Date: Wed, 29 Mar 2006 19:08:24 -0800
Subject: Fedora's way forward
In-Reply-To: <1143678137.27889.14.camel@daxter.boston.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060329140009.5b55cf3b.zaitcev@redhat.com>
	<1143678137.27889.14.camel@daxter.boston.redhat.com>
Message-ID: <d91f09cd0603291908h77e33dfas6106c36fa55cc09e@mail.gmail.com>

On 3/29/06, David Zeuthen <david at fubar.dk> wrote:
>
> Someone just needs to do the work. Whether the package stems from Core,
> Extras or some 3rd party repo should only make a difference on whether
> you need to click a link on a web page or insert a CD from the
> software/hardware vendor. And discussing whether the one-time pain of
> clicking a link or inserting a CD is too much work for the user is just,
> IMHO, ridiculous.
>

We are getting there.  Pirut is now the handler for .rpm files.  Which
means that they can run like installers and pirut will install the rpm
and its dependencies.  This could even work for enabling repositories
since many of them have packages which include the .repo files.  They
can downloaded and installed.

It would be nicer if there was a GUI repository manager.  This could
be the handler for .repo files so downloading or running a .repo file
would work and setup the repository.

It would also be helpful to have some meta-packages.  Something that
says to get Adobe Reader working you need to download these packages
from over there.  Or to install MP3 support you need to enable that
repo and install these packages.

 - Ian



From esr at thyrsus.com  Wed Mar 29 18:41:19 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 29 Mar 2006 13:41:19 -0500
Subject: Fedora's way forward
In-Reply-To: <1143644774.3802.634.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
	<1143644774.3802.634.camel@sundaram.pnq.redhat.com>
Message-ID: <20060329184119.GA3656@thyrsus.com>

Rahul Sundaram <sundaram at fedoraproject.org>:
> How do you add propose that we add support for mp3 formats in Fedora
> without abandoning the rights for derivative distributions to make
> modifications and redistribute all the code included in Fedora?

See my suggestion about a dedicated yum repository with a button in
Fedora that says "Push this to download MP3 support".  Users of Fedora
and all derivatives could use such a mechanism.

>                                                                  Again
> its not merely proprietary but also shackled by patents. Are you happy
> with just adding support for mp3 or would WMA support follow up on that
> next?

Since you mention it, yes.  If we can support what users want to do, we should.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From seandarcy2 at gmail.com  Thu Mar 30 03:29:18 2006
From: seandarcy2 at gmail.com (sean)
Date: Wed, 29 Mar 2006 22:29:18 -0500
Subject: rawhide->fc5; X won't start
In-Reply-To: <e0ct33$mrt$1@sea.gmane.org>
References: <e0ct33$mrt$1@sea.gmane.org>
Message-ID: <e0fje2$otq$1@sea.gmane.org>

sean wrote:
> I was running rawhide updated to March 10. Went on vacation, yesterday 
> did a full upgrade to fc5. Used yum to get  updates released.  Now X 
> won't start. I think it's some sort of  xfs problem.
> 
> with gnome, I get the fedora bubble logo, then a black screen, alt-f1 
> gets me the console, which shows:
> 
> waiting for X server to shut down FreeFontPath: FPE "unix/7100" refcount 
> is 2, should be 1, fixing
> 
> syslog shows:
> 
> gnome_segv2[3263]: segfault at 0000000000xxxxxxxx .........
> 
> kde also won't start. The console shows:
> 
> xset: bad font path element (#76), .......
> 
> and syslog shows kded, ksplash, kcminit, and ksmserver segfaulting.
> 
> I've restarted xfs ( no errors in syslog ). I've rebooted.
> 
> Do I need to do some mkfontdir voodoo in each font directory? What did 
> the upgrade change? I've seen no similar problems posted, so I assume 
> it's a rawhide->fc5 issue.
> 
> puzzled.
> 
> sean
> sean
> 

OK, so no one else sees this.

Any suggestions as to how to diagnose this? Any way to get more verbose 
or clearer error messages?

sean



From avi at unix.sh  Thu Mar 30 03:42:53 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 00:42:53 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <200603290433.51839.billcrawford1970@googlemail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<200603290433.51839.billcrawford1970@googlemail.com>
Message-ID: <ed0efd310603291942h3b5b1fcerf0705f087adbc13b@mail.gmail.com>

On 3/29/06, Bill Crawford <billcrawford1970 at gmail.com> wrote:

> There are plenty of reasons why it hasn't happened, among which are a
> number
> of experiments with various forms of "registry" ...


It never happend because of the "bazar" nature of the OSS development model.
One of its big drawbacks is that there is no central architecture, no
central desing directions, no central decisions. So we see A LOT of code
rewriting, programs being developed in A LOT of different languages, and A
LOT of different configuration files formats.

As we all know, OSS model also have good advantages too.




> The reason most applications use individual config files instead of a
> central
> repository is because that makes it much, *much* easier to:
>
> 1. Design a domain-specific config language. XML does *NOT* solve this
> problem; it is a *lexical* (meta)language. The structure goes on top.


I see this as a disadvantage, since all, ALL config files are not more then
an hierarchical structure of key/value pairs. All lexical stuff you are
saying are fat to make it more human readable.




> 2. Point to a different config file when you start a program.


You can also point your program to a different root tree of keys. So using
Elektra terminology:

$ httpd -c system/tmp/mytest/mysite.com





> 3. Copy config files, rename them, reuse them, move them into chroot()
> environments, and generally be *free* to do so.


You can do the same with configuration trees. Elektra lets you even export

These points are not good enough to deny some sort of standarization.

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

From avi at unix.sh  Thu Mar 30 03:47:55 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 00:47:55 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143585692.30123.28.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
Message-ID: <ed0efd310603291947u26184d54u1b44136029cb3b46@mail.gmail.com>

On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
>
> If elektra is the right solution we
> should see new projects embracing it.  After that happens, you'll start
> seeing buyin from the established projects.
>
> How to get more new projects to use it?  More language bindings would
> definitely help....
>

You know, this is a chicken-and-egg problem.
Will be easier to new projects to embrace it if Elektra is automatically
present in regular distros, and regular distros will only include Elektra if
higher level software starts using it.

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

From avi at unix.sh  Thu Mar 30 03:53:36 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 00:53:36 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143597074.3608.44.camel@currant.watzmann.net>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
Message-ID: <ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>

On 3/28/06, David Lutterkort <dlutter at redhat.com> wrote:
>
> A lighter-weight approach seems more promising: encapsulate most of the
> config-file specific knowledge in simple script wrappers that can be
> controlled by a declarative description of the configuration you want to
> achieve and the logical interdependencies between them. This is what
> puppet does, and why I find it very attractive.
>

Hummm, never heard about puppet. Seems interesting.
The problem I see with this approach is the additional layer that manages
the configuration files syntax. And again: ALL configuration files can be
represented by an hierarchy of key/value pairs. They are different because
they received a considerable amount of syntax fat to make them look nicer to
your human eyes. And what puppet seems to do is try to work with this fat.

Elektra completely removes that fat and reduces the configuration parameters
to what they really are: key/value pairs.

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

From avi at unix.sh  Thu Mar 30 03:58:24 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 00:58:24 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <BAYC1-PASMTP0170D468BE6629598015D5AED00@CEZ.ICE>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<BAYC1-PASMTP0170D468BE6629598015D5AED00@CEZ.ICE>
Message-ID: <ed0efd310603291958o13688b17teb33a23dd75b63e@mail.gmail.com>

On 3/28/06, sean <seanlkml at sympatico.ca> wrote:
>
> But what is the advantage of building an entire new config language
> around these wrappers?  Couldn't they be manipulated just as easily
> with shell or python?    Can the administrator make simple ad-hoc
> command line config file changes?


Experience shows that is more difficult and less effective to write a lot of
different configuration parsers, then patching the original softwares to
make them read configuration atoms from other sources and formats.

Avi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060330/72583e51/attachment.htm>

From mitr at volny.cz  Thu Mar 30 04:17:56 2006
From: mitr at volny.cz (Miloslav Trmac)
Date: Thu, 30 Mar 2006 06:17:56 +0200
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
Message-ID: <442B5BF4.70408@volny.cz>

Avi Alkalay napsal(a):
> And again: ALL configuration
> files can be represented by an hierarchy of key/value pairs.
Sure, any finite object can be represented by one long bit string :)

Can all configuration files be _usefully_ represented by a hierarchy?
The natural format (= format prefered for human editing) for some
applications uses m4 (sendmail, SELinux policy) or even arbitrary
PHP/perl code.
	Mirek



From avi at unix.sh  Thu Mar 30 04:30:11 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 01:30:11 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <200603290438.03209.billcrawford1970@googlemail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143588739.30123.70.camel@localhost>
	<Pine.LNX.4.63.0603281541570.27793@master.geeklords.org>
	<200603290438.03209.billcrawford1970@googlemail.com>
Message-ID: <ed0efd310603292030t2e9feb12m49e281784d4b4c2@mail.gmail.com>

On 3/29/06, Bill Crawford <billcrawford1970 at gmail.com> wrote:
>
> How does .ini format give you containers beyond the first level? By
> numbering
> the keys? ugh.


The ini format was a bad example because you get 2 dimensions only.
On Elektra you'll have something like this:

> > default-lease-time           21600;
> > subnet 10.202.46.0 netmask 255.255.255.0 {
> >    use-host-decl-names      on;
> >    option log-servers       10.202.46.2;
> >    host ws001 {
> >        hardware ethernet    00:11:22:33:44:55;
> >        fixed-address        192.168.0.1;
> >        default-lease-time   10000
> >        filename             "/lts/vmlinuz-2.4.26-ltsp-1";
> >    }
> > }

system/sw/dhcpd/default-lease-time = 21600
system/sw/dhcpd/subnets/10.202.46.0-24/use-host-decl-names = on
system/sw/dhcpd/subnets/10.202.46.0-24/options/log-servers = 10.202.46.2
system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/fixed-address =
192.168.0.1
system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/default-lease-time =
10000
system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/filename = /lts/vmlinuz-
2.4.26-ltsp-1
system/sw/dhcpd/subnets/10.202.46.0-24/hosts/ws001/hw =
ethernet:00:11:22:33:44:55


The dhcp config file format is a much better match for a) the way people
> think if they know the problem domain b) allows *hierarchy*. XML at least
> gets that right (and I *don't* think xml is the answer).


Anyway, Elektra also provides standard ways for you to represent this
hierarchy in an XML format, useful for exporting and importing.


> But things change considerably
> > when instead we deal with all configuration elements as keys and their
> > values in a filesystem like structure.
>
> And this is the issue. Look at the mess that is SNMP MIBs. Can you read
> those? Can you?


Again, the point is not you (a human being) to read them, but make them
accessible in an atomic way to any other (non-human) program.


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

From avi at unix.sh  Thu Mar 30 04:40:04 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 01:40:04 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143584970.30123.19.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<Pine.LNX.4.63.0603271358470.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
Message-ID: <ed0efd310603292040l2c7ce2ecidba5cf11dcd1b991@mail.gmail.com>

On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
>
> If you look through the following, monster thread you'll find that
> elektra is a bad choice for the desktop configuration api.  System and
> desktop configuration requirements are different.  Also, the author of
> that GConf comparison doesn't seem to understand the problems GConf is
> attempting to solve which doesn't bode well for it ever displacing
> GConf.
>
> http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01392.html
> http://www.redhat.com/archives/fedora-devel-list/2004-August/msg00024.html
>
> http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00039.html


Makes me laugh because I discussed in all those threads :-)

Elektra doesn't want to displace GConf. It actualy can't.
GConf provides way more benefits for desktop applications. But.... KDE
programs can't access Gnome properties and vice-versa. So here comes
Elektra.

Being smaller, simpler, more generic, it fits perfectly as a backend for
GConf and a backend for KConfig (KDE's configuration API) at the same time.
This way each framework will keep on using its own API and naming
conventions, but Gnome apps will be able to access KDE's configuration
atoms, and vice-versa. So we can have only one place to store global desktop
things like proxy, background, default font, etc. More than that: KDE and
Gnome will be able to use their own APIs to access Samba's, X.org's, DHCP,
Apache, etc configurations as those softwares were plain KDE or Gnome apps
:-)


Avi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060330/511da42c/attachment.htm>

From avi at unix.sh  Thu Mar 30 04:48:13 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 01:48:13 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143586789.30123.44.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
Message-ID: <ed0efd310603292048o3e605ac4i478a5cc433ffaa38@mail.gmail.com>

On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
>
> I think Nicholas Mailhot had an extremely valid point:  The
> configuration format (key = value; <key>value</key>; etc) is not a major
> stumbling block for a system admin.  It's what the application
> developers choose as the name for key and what they fill value with that
> make configuration files easy or hard to understand.  Elektra and the
> like are seeking to solve a problem that will only marginally aid a
> system administrator in editing a config file from a text editor.



Yeah, thats because Elektra main goal is not to help sysadmins, but to help
unrelated programs to colaborate automaticaly. this way, helping the
sysadmin is an inevitable consequence.

How many times you see regular non-sysadmin Windows users dealing with low
level configurations? The answer is exactly "never", because the
applications can do this task for themselves instead of asking the user to
edit this and that configurations to make all work correctly.

Of course Elektra adds a considerable amount of security and filesystem-like
access permissions, compared to what Microsoft did with the their registry.


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

From perbj at sbcglobal.net  Thu Mar 30 04:50:24 2006
From: perbj at sbcglobal.net (Per Bjornsson)
Date: Wed, 29 Mar 2006 20:50:24 -0800
Subject: Fedora's way forward
In-Reply-To: <1143651293.5600.228.camel@pmac.infradead.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
Message-ID: <1143694224.2250.5.camel@localhost.localdomain>

On Wed, 2006-03-29 at 17:54 +0100, David Woodhouse wrote:
> On Tue, 2006-03-28 at 05:46 -0500, Alan Cox wrote:
> > If you'd like additional proprietary third party material such as real
> > player and IBM Java nobody is stopping you.
> 
> Those are two examples where Fedora really _could_ catch up. We should
> really concentrate on getting gcjwebplugin and swfdec (or gnash)
> shippable by FC6.

Unfortunately it's probably not that easy to do something legal about
Flash - at least if you want it to make sound... Doesn't Flash use MP3
for audio? And what is the video format used in recent Flash versions?

Swfdec may be able to do an end-run around this by using gstreamer, in
that case all the parts legally possible can be shipped by Fedora, and
other stuff can get plugged in by users by means of plug-ins.

/Per




From avi at unix.sh  Thu Mar 30 05:00:24 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 02:00:24 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603292052r738b5dc6uf8df2a77fe282dc3@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<ed0efd310603292052r738b5dc6uf8df2a77fe282dc3@mail.gmail.com>
Message-ID: <ed0efd310603292100k35010ddbp294a28bb633c6d77@mail.gmail.com>

Alan Cox wrote:
> Gconf doesn't need gnome. The reverse is true however. The XML format also lets

Thats true. But the problem is GConf is too many dependencies, and a
design oriented to the desktop only. So the idea is to keep GConf, but
attach to it a backend capable of doing global configurations, as
Elektra.


> you work with prefences using styles and XML XSLT and the like which is very
> powerful when working with a large number of systems. Really nobody has
> scratched the surface of what it can do.

XML is good for external representation of data, but not for storage.
XML storage makes GConf damn slow.

Avi



From avi at unix.sh  Thu Mar 30 05:03:25 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 02:03:25 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603292100k35010ddbp294a28bb633c6d77@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<ed0efd310603292052r738b5dc6uf8df2a77fe282dc3@mail.gmail.com>
	<ed0efd310603292100k35010ddbp294a28bb633c6d77@mail.gmail.com>
Message-ID: <ed0efd310603292103s4982bc5ap753288a4e3abab5f@mail.gmail.com>

Florian La Roche <laroche at redhat com> wrote:
> A full ack on this, we would solve a lot of items if we could move
> forward to have a standard lib for all this. But it will be very
> hard to have agreement on how to solve it and even more to make
> projects move over from their current ways.

One thing that can help on this agreement is to include such global
configuration system in a mainstream distro as Fedora. This way major
projects can start using it as a core system library.

Avi



From shane at geeklords.org  Thu Mar 30 05:17:07 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Wed, 29 Mar 2006 21:17:07 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603292048o3e605ac4i478a5cc433ffaa38@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
	<ed0efd310603292048o3e605ac4i478a5cc433ffaa38@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0603292052150.31740@master.geeklords.org>

On Thu, 30 Mar 2006, Avi Alkalay wrote:

> Yeah, thats because Elektra main goal is not to help sysadmins, but to help
> unrelated programs to colaborate automaticaly. this way, helping the
> sysadmin is an inevitable consequence.

It seems to me configuration data in an Elektra like format DOES help 
sysadmins with managing system configuration even without fancy 
applications.  The sysadmin just needs to begin treating 
configuration data as a series of "command directives" instead big bang 
application/subsystem file edits.

With the right type of command line viewer / editor 
read-ability of raw config actually improves IMO.

example:

cfg_mgr -interactive

display /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*

    use-host-decl-names = on
    options/log-servers = 10.202.46.2
    hosts/ws001/fixed-address = 192.168.0.1
    hosts/ws001/default-lease-time = 10000
    hosts/ws001/filename = /lts/vmlinuz-2.4.26-ltsp-1
    hosts/ws001/hw = ethernet:00:11:22:33:44:55

edit -format (ini,xml,text etc...) /dhcp/sw/dhcpd/subnets/10.202.46.0-24/

vi/emacs etc.. starts up with the the above information in the specified 
format (xml, ini, plain text) and the admin may now change values, add new 
hosts, options etc... as though it was a file.


The above functionality would just as easily be accessible via the 
command prompt with the right -switches.

Cheers,
Shane



From shane at geeklords.org  Thu Mar 30 05:56:41 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Wed, 29 Mar 2006 21:56:41 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603292052150.31740@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
	<ed0efd310603292048o3e605ac4i478a5cc433ffaa38@mail.gmail.com>
	<Pine.LNX.4.63.0603292052150.31740@master.geeklords.org>
Message-ID: <Pine.LNX.4.63.0603292150230.31780@master.geeklords.org>

On Wed, 29 Mar 2006, Shane Stixrud wrote:

> On Thu, 30 Mar 2006, Avi Alkalay wrote:
>
>> Yeah, thats because Elektra main goal is not to help sysadmins, but to help
>> unrelated programs to colaborate automaticaly. this way, helping the
>> sysadmin is an inevitable consequence.
>
> It seems to me configuration data in an Elektra like format DOES help 
> sysadmins with managing system configuration even without fancy applications. 
> The sysadmin just needs to begin treating configuration data as a series of 
> "command directives" instead big bang application/subsystem file edits.
>
> example:

[snip]

Or even better the following is very readable and easy to edit with a 
standard text editor IMO.

cfg_mgr --interactive

display -detail /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*

/use-host-decl-names:
    ; Key description
    # User comments go here
    on

/options/log-servers:
    ; Key description
    # User comments go here
    10.202.46.2, 10.202.46.3

/hosts/ws001/fixed-address:
    ; Key description
    # User comments go here
    192.168.0.1

/hosts/ws001/default-lease-time:
    ; Key description
    # User comments go here
    10000

/hosts/ws001/filename:
    ; Key description
    # User comments go here
    /lts/vmlinuz-2.4.26-ltsp-1

/hosts/ws001/hw:
    ; Key description
    # User comments go here
    ethernet:00:11:22:33:44:55



From rstrode at redhat.com  Thu Mar 30 06:13:45 2006
From: rstrode at redhat.com (Ray Strode)
Date: Thu, 30 Mar 2006 01:13:45 -0500
Subject: rawhide->fc5; X won't start
In-Reply-To: <e0fje2$otq$1@sea.gmane.org>
References: <e0ct33$mrt$1@sea.gmane.org>  <e0fje2$otq$1@sea.gmane.org>
Message-ID: <1143699226.8963.1.camel@halflap>

Hi, 

> OK, so no one else sees this.
> 
> Any suggestions as to how to diagnose this? Any way to get more verbose 
> or clearer error messages?
If you run fc-cache -f from your user account does your problem go away?

--Ray



From stransky at redhat.com  Thu Mar 30 07:22:29 2006
From: stransky at redhat.com (Martin Stransky)
Date: Thu, 30 Mar 2006 09:22:29 +0200
Subject: Compiling alsa 1.0.11rc4 on FC5 and kernel wierdness
In-Reply-To: <75EC4D5486CAC247B84AAAA6F96AA5580705A1FF@orsmsx402.amr.corp.intel.com>
References: <75EC4D5486CAC247B84AAAA6F96AA5580705A1FF@orsmsx402.amr.corp.intel.com>
Message-ID: <442B8735.808@redhat.com>

check my page - http://people.redhat.com/stransky/alsa

Allyn, Mark A wrote:
> Hello:
> 
> First of all, thanks for helping me find the kernel sources. I did find
> them.
> 
> Now, I have another interesting problem. 
> 
> I am trying to compile the alsa driver from alsa 1.0.11rc4 and I am
> having lots of compiler errors.
> 
> I have done some tracing and I have seemed to come to a conclusion that
> there are some kernel 2.6.16 features (such as structures) in FC5's
> kernel,
> yet that kernel is 2.6.15**. This is breaking some conditionals in the 
> source code where it is looking for kernel version 2.6.15 or earlier.
> 
> Are any of you aware of changes that have been put into the 2.6.15
> kernel
> that FC5 has that are actually from the 2.6.16 stock kernel?
> 
> For that matter, have any of you been able to successfully compile the
> alsa
> version 1.0.11rc4 driver under the FC5 kernel?
> 
> Thank you
> 
> Mark Allyn
> 



From seanlkml at sympatico.ca  Thu Mar 30 07:39:40 2006
From: seanlkml at sympatico.ca (sean)
Date: Thu, 30 Mar 2006 02:39:40 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329184119.GA3656@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
	<1143644774.3802.634.camel@sundaram.pnq.redhat.com>
	<20060329184119.GA3656@thyrsus.com>
Message-ID: <BAYC1-PASMTP024ABE3EF0E7B50306FD17AED10@CEZ.ICE>

On Wed, 29 Mar 2006 13:41:19 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> See my suggestion about a dedicated yum repository with a button in
> Fedora that says "Push this to download MP3 support".  Users of Fedora
> and all derivatives could use such a mechanism.

It's already easy to add third party repositories.   No need for
anything more.
                                                                Again
> > its not merely proprietary but also shackled by patents. Are you happy
> > with just adding support for mp3 or would WMA support follow up on that
> > next?
> 
> Since you mention it, yes.  If we can support what users want to do, we should.

Sorry, you're wrong.  Unfortunately for the users that want that feature, 
Fedora is made for users that don't want it. 

Sean



From uraeus at gnome.org  Thu Mar 30 08:08:03 2006
From: uraeus at gnome.org (Christian Fredrik Kalager Schaller)
Date: Thu, 30 Mar 2006 10:08:03 +0200
Subject: Fedora's way forward
In-Reply-To: <20060329140009.5b55cf3b.zaitcev@redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060329140009.5b55cf3b.zaitcev@redhat.com>
Message-ID: <1143706083.2282.4.camel@localhost.localdomain>

On Wed, 2006-03-29 at 14:00 -0800, Pete Zaitcev wrote:

> How about a discoverability of the package name of the month?
> Gstreamer people seem to receive sadistic pleasure from renaming
> packages.

What? For 4 years there was one plugin package called -plugins
plus one package called gst-ffmpeg.

For 0.10 we split the -plugins package into four as it was becoming
unmaintainable. Since that split we kept those 4 packages around with
the same names (base, good, ugly and bad).

How does that translate into 'package name of the month' ?

Christian



From seanlkml at sympatico.ca  Thu Mar 30 08:37:56 2006
From: seanlkml at sympatico.ca (sean)
Date: Thu, 30 Mar 2006 03:37:56 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603291947u26184d54u1b44136029cb3b46@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
	<ed0efd310603291947u26184d54u1b44136029cb3b46@mail.gmail.com>
Message-ID: <BAYC1-PASMTP046B4FA5050E734F5002EBAED10@CEZ.ICE>

On Thu, 30 Mar 2006 00:47:55 -0300
"Avi Alkalay" <avi at unix.sh> wrote:

> You know, this is a chicken-and-egg problem.
> Will be easier to new projects to embrace it if Elektra is automatically
> present in regular distros, and regular distros will only include Elektra if
> higher level software starts using it.

The Elektra folks should backport some common applications themselves to 
show developers how easy it is.  Say, submitting patches to the upstream 
Apache project making Elektra a compile time option.   Also, getting it
in Extras would also help start the ball rolling.

Sean



From andreas.bierfert at lowlatency.de  Thu Mar 30 08:55:25 2006
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Thu, 30 Mar 2006 10:55:25 +0200
Subject: Bootsplash?
In-Reply-To: <e99d27470603290749q44bb16a2o37ebfc08f9eed2c@mail.gmail.com>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost> <1143302775.2605.41.camel@dimi>
	<20060328114818.4024f4c6@alkaid.a.lan> <e0bva5$er8$1@sea.gmane.org>
	<20060328214417.730ccc2d@alkaid.a.lan>
	<1143599135.2192.1.camel@scrappy.miketc.com>
	<e99d27470603290749q44bb16a2o37ebfc08f9eed2c@mail.gmail.com>
Message-ID: <20060330105525.42e65b9e@alkaid.a.lan>

On Wed, 29 Mar 2006 17:49:40 +0200
"Rudolf Kastl" <che666 at gmail.com> wrote:
> same problem here

Hm, thats strange... so I never tried that... does it work during bootup?

I think tomorrow after my exam I will package up latest svn to see where we
go... seems like lots of work has already been put in since this release.

- Andreas

-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060330/e742e0af/attachment.sig>

From che666 at gmail.com  Thu Mar 30 08:57:57 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Thu, 30 Mar 2006 10:57:57 +0200
Subject: Bootsplash?
In-Reply-To: <20060330105525.42e65b9e@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost> <1143302775.2605.41.camel@dimi>
	<20060328114818.4024f4c6@alkaid.a.lan> <e0bva5$er8$1@sea.gmane.org>
	<20060328214417.730ccc2d@alkaid.a.lan>
	<1143599135.2192.1.camel@scrappy.miketc.com>
	<e99d27470603290749q44bb16a2o37ebfc08f9eed2c@mail.gmail.com>
	<20060330105525.42e65b9e@alkaid.a.lan>
Message-ID: <e99d27470603300057i22f33f39t749fe62e0a9261f1@mail.gmail.com>

2006/3/30, Andreas Bierfert <andreas.bierfert at lowlatency.de>:
> On Wed, 29 Mar 2006 17:49:40 +0200
> "Rudolf Kastl" <che666 at gmail.com> wrote:
> > same problem here
>
> Hm, thats strange... so I never tried that... does it work during bootup?

negative on that houston :)

>
> I think tomorrow after my exam I will package up latest svn to see where we
> go... seems like lots of work has already been put in since this release.
>
> - Andreas
>
> --
> Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
> andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
> phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
>



From benjy.grogan at gmail.com  Thu Mar 30 09:28:00 2006
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Thu, 30 Mar 2006 04:28:00 -0500
Subject: Fedora Looks Fresh and Functions Well
Message-ID: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>

Hello,

I'm really enjoying using FC5.  Tomboy is a great tool for jotting
down ideas.  I actually put together this email using a few tomboy
notes.  I have a few suggestions -- that you can take or leave -- that
I wanted to share to help out with 'Fedora's way forward'. :)  Here
they are:


1) A welcome to Fedora (or RHEL) tutorial for new accounts and even
maybe a tips section everytime you log in.  DAC would be a really good
topic for new users.

2) Have a place in Preferences set up for the two or three available
Javas (Sun's and the OSS ones).  Then when you have installed Sun's
Java you have a place to switch back to the old one, and vice versa. 
(Question: Is a compiled Azureus the same if it's based on Sun or
GCJ?)

3) I have a question on codecs.  Is it possible to get all OSS codecs
these days based on the GStreamer plugin system?  I think the whole
audio/video codec problem would go away if there was a GStreamer Codec
management system where OSS codecs would be there by default and then
the user would go out and get all the proprietary GStreamer codecs
he/she is missing.  It should be simple to look at a Fedora system,
and say "alright, got those ones, but missing these ones (like
mp3/avi).  And I can figure out where to get them."  And this
presupposes a future where there are only Gstreamer codecs.

4) Since Firefox is one of the most important pieces of the Linux OS
these days, it would be great to have all of the alphas, betas and RCs
available in update-testing.  That would allow some users to test
Firefox for bugs over an extended period of time before 2.0 or 3.0
comes out.  Obviously, under some guidance from Fedora with all the
patches they put into it.

5) An updating system (maybe using deltarpms or smartrpms) that could
compete with the updating system available on Windows XP and OS/X. 
Smaller updates are really needed.

That's all!  Back to testing out FC5.  And Thanks!

Benjy



From alan at redhat.com  Thu Mar 30 10:03:31 2006
From: alan at redhat.com (Alan Cox)
Date: Thu, 30 Mar 2006 05:03:31 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603292100k35010ddbp294a28bb633c6d77@mail.gmail.com>
References: <20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com>
	<ed0efd310603292052r738b5dc6uf8df2a77fe282dc3@mail.gmail.com>
	<ed0efd310603292100k35010ddbp294a28bb633c6d77@mail.gmail.com>
Message-ID: <20060330100331.GB1364@devserv.devel.redhat.com>

On Thu, Mar 30, 2006 at 02:00:24AM -0300, Avi Alkalay wrote:
> > powerful when working with a large number of systems. Really nobody has
> > scratched the surface of what it can do.
> 
> XML is good for external representation of data, but not for storage.
> XML storage makes GConf damn slow.

Not really. What made gconf slow was dumb ideas like storing one value per
file. XML is relatively efficient compared to the damage that did. The storage
is jut a backend however. Gconf as a system could use punched cards for its
data storage too if you really wanted



From mike at miketc.com  Thu Mar 30 10:08:50 2006
From: mike at miketc.com (Mike Chambers)
Date: Thu, 30 Mar 2006 04:08:50 -0600
Subject: Bootsplash?
In-Reply-To: <20060330105525.42e65b9e@alkaid.a.lan>
References: <1143030630.2327.10.camel@localhost.localdomain>
	<1143042269.23468.6.camel@orodruin.boston.redhat.com>
	<1143059186.28627.6.camel@localhost.localdomain>
	<20060324012515.66d801f4@alkaid.a.lan>
	<1143220662.3500.1.camel@localhost>
	<1143302775.2605.41.camel@dimi> <20060328114818.4024f4c6@alkaid.a.lan>
	<e0bva5$er8$1@sea.gmane.org> <20060328214417.730ccc2d@alkaid.a.lan>
	<1143599135.2192.1.camel@scrappy.miketc.com>
	<e99d27470603290749q44bb16a2o37ebfc08f9eed2c@mail.gmail.com>
	<20060330105525.42e65b9e@alkaid.a.lan>
Message-ID: <1143713330.2967.0.camel@scrappy.miketc.com>

On Thu, 2006-03-30 at 10:55 +0200, Andreas Bierfert wrote:

> Hm, thats strange... so I never tried that... does it work during bootup?
> 
> I think tomorrow after my exam I will package up latest svn to see where we
> go... seems like lots of work has already been put in since this release.

Nope, doesn't work on boot neither.

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt, then it's hilarious!"



From seanlkml at sympatico.ca  Thu Mar 30 10:35:22 2006
From: seanlkml at sympatico.ca (sean)
Date: Thu, 30 Mar 2006 05:35:22 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603292150230.31780@master.geeklords.org>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
	<ed0efd310603292048o3e605ac4i478a5cc433ffaa38@mail.gmail.com>
	<Pine.LNX.4.63.0603292052150.31740@master.geeklords.org>
	<Pine.LNX.4.63.0603292150230.31780@master.geeklords.org>
Message-ID: <BAYC1-PASMTP05383F7CB0BB67663DC425AED10@CEZ.ICE>

On Wed, 29 Mar 2006 21:56:41 -0800 (PST)
Shane Stixrud <shane at geeklords.org> wrote:

> 
> Or even better the following is very readable and easy to edit with a 
> standard text editor IMO.
> 
> cfg_mgr --interactive
> 
> display -detail /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*
> 
> /use-host-decl-names:
>     ; Key description
>     # User comments go here
>     on
> 
> /options/log-servers:
>     ; Key description
>     # User comments go here
>     10.202.46.2, 10.202.46.3
> 
> /hosts/ws001/fixed-address:
>     ; Key description
>     # User comments go here
>     192.168.0.1
> 
> /hosts/ws001/default-lease-time:
>     ; Key description
>     # User comments go here
>     10000
> 
> /hosts/ws001/filename:
>     ; Key description
>     # User comments go here
>     /lts/vmlinuz-2.4.26-ltsp-1
> 
> /hosts/ws001/hw:
>     ; Key description
>     # User comments go here
>     ethernet:00:11:22:33:44:55
> 

For ad-hoc interactive usage that looks worse than what we have today;
call up a config file and page through it to see the information you want.
However something like that might be useful for scripting.

But the difficult issue isn't really what tools might be possible after
a unified config system is in place.   Rather, it's how to get enough
apps to use the config system in the first place.   My own view is that
concentrating on the needs of _developers_ not users and sysadmins
is the way to success.   The user and admin tools are the easy part.

Sean



From n0dalus+redhat at gmail.com  Thu Mar 30 10:39:05 2006
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Thu, 30 Mar 2006 21:09:05 +1030
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
Message-ID: <6280325c0603300239v4001a778xf4b775a0680a0f0b@mail.gmail.com>

On 3/30/06, Avi Alkalay <avi at unix.sh> wrote:
>
> Hummm, never heard about puppet. Seems interesting.
> The problem I see with this approach is the additional layer that manages
> the configuration files syntax. And again: ALL configuration files can be
> represented by an hierarchy of key/value pairs. They are different because
> they received a considerable amount of syntax fat to make them look nicer to
> your human eyes. And what puppet seems to do is try to work with this fat.
>

What would be really cool is to have a file-system based configuration
system, where a config file is mounted into a user space or kernel
file-system driver. Then programs could use whatever config file
format they like, and as long as there is a translation module for it,
people can change/view things with simple echo/cat commands. Like
/proc/sys/.
Eg: cat 80 > /conf/httpd/Listen

Probably just madness,
n0dalus.



From sundaram at fedoraproject.org  Thu Mar 30 10:49:56 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Mar 2006 16:19:56 +0530
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <1143651074.5136.5.camel@localhost.localdomain>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
	<4429C65C.3070600@comcast.net> <200603281709.38816.lamont@gurulabs.com>
	<4429D3FF.4050904@comcast.net>
	<1143592383.3802.578.camel@sundaram.pnq.redhat.com>
	<4429DBA3.1020605@comcast.net>
	<1143594150.3802.582.camel@sundaram.pnq.redhat.com>
	<1143651074.5136.5.camel@localhost.localdomain>
Message-ID: <1143715796.3802.659.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-29 at 11:51 -0500, Paul W. Frields wrote:
> On Wed, 2006-03-29 at 06:32 +0530, Rahul Sundaram wrote:
> > On Tue, 2006-03-28 at 19:58 -0500, Neil Cherry wrote:
> > 
> > > >> Ah, so that's the difference. That was driving me totally nuts. I
> > > >> couldn't figure out why I couldn't compile the kernel with the
> > > >> devel package but I'm very successful (when I don't remove too
> > > >> much) with the kernel sources.
> > > > 
> > > > We have all this information in the release notes which we spend many
> > > > many hours writing. So you might as well as read it.
> > > > http://fedora.redhat.com/docs/release-notes/fc5/#sn-Kernel
> > > 
> > > Thanks Rahul, I only found out about the release notes yesterday
> > > when someone else mentioned them. 
> > 
> > I am curious. How did you manage to *miss it* ?. It has a rather
> > prominent button in the installer, default page for the browser,
> > mentioned usually in the release announcements etc. 
> 
> Don't be silly, Rahul, everybody knows we Americans can't read. :-)
> 
> In all seriousness, I'm betting your question is rhetorical and stems
> from the frustration of putting so much work into the process only to
> see endless questions like this.  (Your work is very much appreciated,
> by the way.)  

I am looking at it to see whether there are other avenues where we can
highlight such important documents.

Rahul



From sundaram at fedoraproject.org  Thu Mar 30 10:53:11 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Mar 2006 16:23:11 +0530
Subject: Fedora's way forward
In-Reply-To: <442AE298.9090300@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
Message-ID: <1143715991.3802.662.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-30 at 07:40 +1200, Michael J Knox wrote:
> Rahul Sundaram wrote:
> > [Please quote more appropriately rather than including the entire mail
> > while replying to it]
> > 
> >> Right on the money Eric.
> >>
> >> I love Fedora Core. In the world of Linux it is The Class Act. However I
> >> would like to see it's core philosophical paradigm expanded to
> >> accommodate the pragmatic reality of what the average user really wants
> >> and what he actually installs on his Fedora machine in practice.
> > 
> > You mean to say that Fedora should give up its support towards Free and
> > open source software and adopt proprietary formats and software in the
> > name of pragmatism. Not a good idea IMO. There are already other
> > distributions out there which does this if this is really the only thing
> > you want. 
> 
> Rahul,
> 
> I don't see where he said give up on free and open source formats and 
> software. 

Adding support for proprietary formats would heavily reduce the
incentive for people to use Free formats. Thats my take on it.

Rahul



From nicu_fedora at nicubunu.ro  Thu Mar 30 11:03:03 2006
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 30 Mar 2006 14:03:03 +0300
Subject: Fedora Looks Fresh and Functions Well
In-Reply-To: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>
References: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>
Message-ID: <442BBAE7.6030706@nicubunu.ro>

Benjy Grogan wrote:
> 
> 3) I have a question on codecs.  Is it possible to get all OSS codecs
> these days based on the GStreamer plugin system?

I think it is called "gstreamer universe" ask Google and be lucky

-- 
nicu
now with more bubbles than ever: 
http://fedora.nicubunu.ro/banners/images/fedora_bubbles.gif



From sundaram at fedoraproject.org  Thu Mar 30 11:12:21 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Mar 2006 16:42:21 +0530
Subject: Fedora Looks Fresh and Functions Well
In-Reply-To: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>
References: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>
Message-ID: <1143717142.3802.673.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-30 at 04:28 -0500, Benjy Grogan wrote:
> Hello,
> 
> I'm really enjoying using FC5.  Tomboy is a great tool for jotting
> down ideas.  I actually put together this email using a few tomboy
> notes.  I have a few suggestions -- that you can take or leave -- that
> I wanted to share to help out with 'Fedora's way forward'. :)  Here
> they are:
> 
> 
> 1) A welcome to Fedora (or RHEL) tutorial for new accounts and even
> maybe a tips section everytime you log in.  DAC would be a really good
> topic for new users.

Do you want to help with that? . Docs project has a number of people who
introduce themselves but then dont contribute. So the actual
contributors are extremely low now.

http://fedoraproject.org/wiki/DocsProject


> 
> 2) Have a place in Preferences set up for the two or three available
> Javas (Sun's and the OSS ones).  Then when you have installed Sun's
> Java you have a place to switch back to the old one, and vice versa. 
> (Question: Is a compiled Azureus the same if it's based on Sun or
> GCJ?)
> 

Fedora wouldnt ship Sun Java. Azureus is GCJ compiled.

http://fedora.redhat.com/docs/release-notes/fc5/#sn-Java

The alternatives mechanism already allows you to switch between any
implementation of Java as long as it is appropriately packaged. Check
out the third question in  

http://www.redhat.com/magazine/001nov04/departments/tips_tricks/



> 3) I have a question on codecs.  Is it possible to get all OSS codecs
> these days based on the GStreamer plugin system?  I think the whole
> audio/video codec problem would go away if there was a GStreamer Codec
> management system where OSS codecs would be there by default and then
> the user would go out and get all the proprietary GStreamer codecs
> he/she is missing.  It should be simple to look at a Fedora system,
> and say "alright, got those ones, but missing these ones (like
> mp3/avi).  And I can figure out where to get them."  And this
> presupposes a future where there are only Gstreamer codecs.

Thats exactly how it is supposed to be working. We are almost there at
this point. 

> 
> 4) Since Firefox is one of the most important pieces of the Linux OS
> these days, it would be great to have all of the alphas, betas and RCs
> available in update-testing.  That would allow some users to test
> Firefox for bugs over an extended period of time before 2.0 or 3.0
> comes out.  Obviously, under some guidance from Fedora with all the
> patches they put into it.

fedora updates-testing repository is just for testing updates that would
almost always be later pushed out as actual updates. Having a
experimental repository might be a good idea but the current usage of
updates-testing repository is low enough to not deviate into that.


> 
> 5) An updating system (maybe using deltarpms or smartrpms) that could
> compete with the updating system available on Windows XP and OS/X. 
> Smaller updates are really needed.


This has been discussed many times. Check the archives. Deltarpms add
complexity to the updates infrastructure and we dont want to force
mirrors to store anything more than the actual packages.

Rahul



From j.w.r.degoede at hhs.nl  Thu Mar 30 12:28:01 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 30 Mar 2006 14:28:01 +0200
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <6280325c0603300239v4001a778xf4b775a0680a0f0b@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>	<1143597074.3608.44.camel@currant.watzmann.net>	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<6280325c0603300239v4001a778xf4b775a0680a0f0b@mail.gmail.com>
Message-ID: <442BCED1.4030400@hhs.nl>

n0dalus wrote:
> On 3/30/06, Avi Alkalay <avi at unix.sh> wrote:
>> Hummm, never heard about puppet. Seems interesting.
>> The problem I see with this approach is the additional layer that manages
>> the configuration files syntax. And again: ALL configuration files can be
>> represented by an hierarchy of key/value pairs. They are different because
>> they received a considerable amount of syntax fat to make them look nicer to
>> your human eyes. And what puppet seems to do is try to work with this fat.
>>
> 
> What would be really cool is to have a file-system based configuration
> system, where a config file is mounted into a user space or kernel
> file-system driver. Then programs could use whatever config file
> format they like, and as long as there is a translation module for it,
> people can change/view things with simple echo/cat commands. Like
> /proc/sys/.
> Eg: cat 80 > /conf/httpd/Listen
> 

Actually this is a (great) idea, with fuse (userspace filesystems) this 
should be doable, I think fuse <-> gconf bridge would be a nice start 
for this.

What do others think? This feels very much like the unix way. (Yeah yet 
another filesystem, howmany can we get / do we need?

Regards,

Hans




From sundaram at fedoraproject.org  Thu Mar 30 12:31:06 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 30 Mar 2006 18:01:06 +0530
Subject: Fedora's way forward
In-Reply-To: <20060329184119.GA3656@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
	<1143644774.3802.634.camel@sundaram.pnq.redhat.com>
	<20060329184119.GA3656@thyrsus.com>
Message-ID: <1143721866.3802.688.camel@sundaram.pnq.redhat.com>

On Wed, 2006-03-29 at 13:41 -0500, Eric S. Raymond wrote:
> Rahul Sundaram <sundaram at fedoraproject.org>:
> > How do you add propose that we add support for mp3 formats in Fedora
> > without abandoning the rights for derivative distributions to make
> > modifications and redistribute all the code included in Fedora?
> 
> See my suggestion about a dedicated yum repository with a button in
> Fedora that says "Push this to download MP3 support".  Users of Fedora
> and all derivatives could use such a mechanism.

Thats quite possible but it doesnt require the project to support this.
Just a easy method to add repositories. See David Zeuthen's mails. 

> 
> >                                                                  Again
> > its not merely proprietary but also shackled by patents. Are you happy
> > with just adding support for mp3 or would WMA support follow up on that
> > next?
> 
> Since you mention it, yes.  If we can support what users want to do, we should.

Everytime we make a change,there are some users who complain about it.
If we drive the project purely by hearing every user's opinion, we
wouldnt be able to progress at all. I rather not have Fedora end up as a
just another proprietary system. 


Rahul



From che666 at gmail.com  Thu Mar 30 12:53:30 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Thu, 30 Mar 2006 14:53:30 +0200
Subject: Fedora Looks Fresh and Functions Well
In-Reply-To: <1143717142.3802.673.camel@sundaram.pnq.redhat.com>
References: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>
	<1143717142.3802.673.camel@sundaram.pnq.redhat.com>
Message-ID: <e99d27470603300453k3510a716pdf512ea5bce69f08@mail.gmail.com>

2006/3/30, Rahul Sundaram <sundaram at fedoraproject.org>:
> On Thu, 2006-03-30 at 04:28 -0500, Benjy Grogan wrote:
> > Hello,
> >
> > I'm really enjoying using FC5.  Tomboy is a great tool for jotting
> > down ideas.  I actually put together this email using a few tomboy
> > notes.  I have a few suggestions -- that you can take or leave -- that
> > I wanted to share to help out with 'Fedora's way forward'. :)  Here
> > they are:
> >
> >
> > 1) A welcome to Fedora (or RHEL) tutorial for new accounts and even
> > maybe a tips section everytime you log in.  DAC would be a really good
> > topic for new users.
>
> Do you want to help with that? . Docs project has a number of people who
> introduce themselves but then dont contribute. So the actual
> contributors are extremely low now.
>
> http://fedoraproject.org/wiki/DocsProject
>
>
> >
> > 2) Have a place in Preferences set up for the two or three available
> > Javas (Sun's and the OSS ones).  Then when you have installed Sun's
> > Java you have a place to switch back to the old one, and vice versa.
> > (Question: Is a compiled Azureus the same if it's based on Sun or
> > GCJ?)
> >
>
> Fedora wouldnt ship Sun Java. Azureus is GCJ compiled.
>
> http://fedora.redhat.com/docs/release-notes/fc5/#sn-Java
>
> The alternatives mechanism already allows you to switch between any
> implementation of Java as long as it is appropriately packaged. Check
> out the third question in
>
> http://www.redhat.com/magazine/001nov04/departments/tips_tricks/
>
>
>
> > 3) I have a question on codecs.  Is it possible to get all OSS codecs
> > these days based on the GStreamer plugin system?  I think the whole
> > audio/video codec problem would go away if there was a GStreamer Codec
> > management system where OSS codecs would be there by default and then
> > the user would go out and get all the proprietary GStreamer codecs
> > he/she is missing.  It should be simple to look at a Fedora system,
> > and say "alright, got those ones, but missing these ones (like
> > mp3/avi).  And I can figure out where to get them."  And this
> > presupposes a future where there are only Gstreamer codecs.
>
> Thats exactly how it is supposed to be working. We are almost there at
> this point.
>
> >
> > 4) Since Firefox is one of the most important pieces of the Linux OS
> > these days, it would be great to have all of the alphas, betas and RCs
> > available in update-testing.  That would allow some users to test
> > Firefox for bugs over an extended period of time before 2.0 or 3.0
> > comes out.  Obviously, under some guidance from Fedora with all the
> > patches they put into it.
>
> fedora updates-testing repository is just for testing updates that would
> almost always be later pushed out as actual updates. Having a
> experimental repository might be a good idea but the current usage of
> updates-testing repository is low enough to not deviate into that.

That wouldnt fit though into the definition of the experimental
repository proposal i am still working on unless the experimental ff
is packaged in a way to coexist with current stable releases (wouldnt
even be bad for regression testing then.). i will add it to the
argumentation chain.

regards,
Rudolf Kastl


>
>
> >
> > 5) An updating system (maybe using deltarpms or smartrpms) that could
> > compete with the updating system available on Windows XP and OS/X.
> > Smaller updates are really needed.
>
>
> This has been discussed many times. Check the archives. Deltarpms add
> complexity to the updates infrastructure and we dont want to force
> mirrors to store anything more than the actual packages.
>
> Rahul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jfontain at free.fr  Thu Mar 30 13:44:51 2006
From: jfontain at free.fr (jfontain at free.fr)
Date: Thu, 30 Mar 2006 15:44:51 +0200
Subject: just upgraded from FC4 to FC5: kernel panic
Message-ID: <1143726291.442be0d34ec2e@imp3-g19.free.fr>

After installation and reboot, I get (on my IBM X40):
...
mount: could not find filesystem '/dev/root'
...

and then errors mount /proc, /sys, and finally a kernel panic.

I am using kernel-2.6.16-1.2080_FC5.i686

Please help me: I would like to avoid reinstalling...

Many thanks in advance,

--
Jean-Luc



From gary at mlbassoc.com  Thu Mar 30 13:49:00 2006
From: gary at mlbassoc.com (Gary Thomas)
Date: Thu, 30 Mar 2006 06:49:00 -0700
Subject: just upgraded from FC4 to FC5: kernel panic
In-Reply-To: <1143726291.442be0d34ec2e@imp3-g19.free.fr>
References: <1143726291.442be0d34ec2e@imp3-g19.free.fr>
Message-ID: <1143726541.14486.34.camel@hermes>

On Thu, 2006-03-30 at 15:44 +0200, jfontain at free.fr wrote:
> After installation and reboot, I get (on my IBM X40):
> ...
> mount: could not find filesystem '/dev/root'
> ...
> 
> and then errors mount /proc, /sys, and finally a kernel panic.
> 
> I am using kernel-2.6.16-1.2080_FC5.i686
> 
> Please help me: I would like to avoid reinstalling...

Make sure your boot line (GRUB, etc) includes "root=/dev/XXX"
that matches your installation.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



From jfontain at free.fr  Thu Mar 30 14:01:49 2006
From: jfontain at free.fr (jfontain at free.fr)
Date: Thu, 30 Mar 2006 16:01:49 +0200
Subject: just upgraded from FC4 to FC5: kernel panic
In-Reply-To: <1143726541.14486.34.camel@hermes>
References: <1143726291.442be0d34ec2e@imp3-g19.free.fr>
	<1143726541.14486.34.camel@hermes>
Message-ID: <1143727309.442be4cd5b529@imp3-g19.free.fr>

Quoting Gary Thomas <gary at mlbassoc.com>:

> On Thu, 2006-03-30 at 15:44 +0200, jfontain at free.fr wrote:
> > After installation and reboot, I get (on my IBM X40):
> > ...
> > mount: could not find filesystem '/dev/root'
> > ...
> >
> > and then errors mount /proc, /sys, and finally a kernel panic.
> >
> > I am using kernel-2.6.16-1.2080_FC5.i686
> >
> > Please help me: I would like to avoid reinstalling...
>
> Make sure your boot line (GRUB, etc) includes "root=/dev/XXX"
> that matches your installation.

Thanks! Thanks! Thanks! That was it. What can I do to thank you for helping so
quickly?


--
Jean-Luc



From rowan at stasis.org  Thu Mar 30 14:40:06 2006
From: rowan at stasis.org (Rowan Kerr)
Date: Thu, 30 Mar 2006 09:40:06 -0500
Subject: Fedora's way forward
In-Reply-To: <1143694224.2250.5.camel@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<20060328104659.GI12588@devserv.devel.redhat.com>	<1143651293.5600.228.camel@pmac.infradead.org>
	<1143694224.2250.5.camel@localhost.localdomain>
Message-ID: <442BEDC6.6080200@stasis.org>

Per Bjornsson wrote:
> Unfortunately it's probably not that easy to do something legal about
> Flash - at least if you want it to make sound... Doesn't Flash use MP3
> for audio? And what is the video format used in recent Flash versions?

Flash, as far as version 8 is MP3 audio.
The video codec in Flash < 6/7 is by Sorensen,
for Flash 8 they added ON2's VP6 codec.



From buildsys at redhat.com  Thu Mar 30 15:13:02 2006
From: buildsys at redhat.com (Build System)
Date: Thu, 30 Mar 2006 10:13:02 -0500
Subject: rawhide report: 20060330 changes
Message-ID: <200603301513.k2UFD2Hp006793@porkchop.devel.redhat.com>

New package xorg-x11-drv-vmmouse
	Xorg X11 vmmouse input driver


 
Updated Packages:

bind-30:9.3.2-14.FC6
--------------------
* Wed Mar 29 2006 Jason Vsa Dias <jvdias at redhat.com> - 30:9.3.2-14
- fix bug 186577: remove -L/usr/lib from libbind.pc and more .spec file cleanup
- add '%doc' sample configuration files in /usr/share/doc/bind*/sample
- rebuild with new gcc and glibc

ethereal-0.10.14-4.svn.1
------------------------
* Wed Mar 29 2006 Radek Vok??l <rvokal at redhat.com> 0.10.14-4.svn.1
- update to latest svn version
- dumpcap

fedora-release-5.89-rawhide
---------------------------

gcc-4.1.0-4
-----------
* Tue Mar 28 2006 Jakub Jelinek <jakub at redhat.com> 4.1.0-4
- update from gcc-4_1-branch (-r111697:112431)
  - PRs ada/25885, c/26004, fortran/17298, fortran/20935, fortran/20938,
	fortran/23092, fortran/24519, fortran/24557, fortran/25045,
	fortran/25054, fortran/25075, fortran/25089, fortran/25378,
	fortran/25395, fortran/26041, fortran/26054, fortran/26064,
	fortran/26107, fortran/26277, fortran/26393, fortran/26716,
	fortran/26741, libfortran/21303, libfortran/24903, libgcj/24461,
	libgcj/25713, libgcj/26103, libgcj/26688, libgcj/26706,
	libgfortran/26499, libgfortran/26509, libgfortran/26554,
	libgfortran/26661, libgfortran/26880, libstdc++/26132,
	middle-end/18859, middle-end/19543, middle-end/26557,
	middle-end/26630, other/26489, target/25917, target/26347,
	target/26459, target/26532, target/26607, tree-optimization/26524,
	tree-optimization/26587, tree-optimization/26672
  - fix visibility and builtins interaction (Jason Merrill,
    PR middle-end/20297, #175442)
- merge gomp changes from trunk (-r112022:112023, -r112250:112251,
  -r112252:112253, -r112350:112351 and -r112282:112283)
  - PRs c++/26691, middle-end/26084, middle-end/26611, c++/26690,
	middle-end/25989
- support visibility attribute on namespaces (Jason Merrill, PR c++/21764,
  PR c++/19238)
- use hidden visibility for anonymous namespaces by default (Jason Merrill,
  PR c++/21581)

gnome-pilot-2.0.13-8
--------------------
* Wed Mar 29 2006 Than Ngo <than at redhat.com> 2.0.13-8 
- rebuilt against pilot-link-0.11.8

gnome-pilot-conduits-2.0.13-4
-----------------------------
* Wed Mar 29 2006 Than Ngo <than at redhat.com> 2.0.13-4 
- rebuilt against pilot-link-0.11.8
- don't apply gnome-pilot-conduits-2.0.13-port-to-pilot-link-0.12.patch

iputils-20020927-37
-------------------
* Wed Mar 29 2006 Radek Vok??l <rvokal at redhat.com> - 20020927-37
- fix ifenslave, shows interface addresses
- add RPM_OPT_FLAGS to ifenslave

* Sun Mar 12 2006 Radek Vok??l <rvokal at redhat.com> - 20020927-36
- fix ifenslave man page (#185223)

jpilot-0.99.8-4
---------------
* Wed Mar 29 2006 Than Ngo <than at redhat.com> 0.99.8-4 
- rebuilt against pilot-link-0.11.8

kernel-2.6.16-1.2104_FC6
------------------------
* Wed Mar 29 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git16 & git17

libsepol-1.12.4-1
-----------------
* Wed Mar 29 2006 Dan Walsh <dwalsh at redhat.com> 1.12.4-1
- Upgrade to latest from NSA
	* Generalize test for bitmap overflow in ebitmap_set_bit.

logrotate-3.7.3-3
-----------------
* Tue Mar 28 2006 Peter Vrabec <pvrabec at redhat.com> 3.7.3-3
- correct man page "extension" option description  (#185318)

ncpfs-2.2.6-2
-------------
* Wed Mar 29 2006 Martin Stransky <stransky at redhat.com> 2.2.6-2
- removed opt flags (#186683)

openoffice.org-1:2.0.2-5.7.3
----------------------------
* Wed Mar 29 2006 Caolan McNamara <caolanm at redhat.com> - 1:2.0.2-5.7
- rh#186747# TTF conts converted to Type 1 in print to file ps

* Tue Mar 28 2006 Caolan McNamara <caolanm at redhat.com> - 1:2.0.2-5.6
- more rh#186215#/ooo#63583# accessibility fixes
- better fallback to english if help is missing

pam_krb5-2.2.8-1
----------------
* Wed Mar 29 2006 Nalin Dahyabhai <nalin at redhat.com> - 2.2.8-1
- don't try to validate creds in a password-changing situation, because the
  attempt will always fail unless the matching key is in the keytab, which
  should never be the case for the password-changing service (#187303, rbasch)
- if v4 has been disabled completely, go ahead and try to set 2b tokens
  because we're going to end up having to do that anyway (#182378)

* Fri Mar 10 2006 Nalin Dahyabhai <nalin at redhat.com> - 2.2.7-2
- fixup man page conflicts in %install

* Wed Mar 08 2006 Bill Nottingham <notting at redhat.com> - 2.2.6-2.2
- don't use paths in man pages - avoids multilib conflicts

pilot-link-2:0.11.8-14
----------------------
* Wed Mar 29 2006 Than Ngo <than at redhat.com> 2:0.11.8-14 
- rebuild to get rid of libpisock.so.9

* Wed Mar 29 2006 Than Ngo <than at redhat.com> 2:0.11.8-13
- downgrade to stable release 0.11.8

policycoreutils-1.30.4-1
------------------------
* Wed Mar 29 2006 Dan Walsh <dwalsh at redhat.com> 1.30.4-1
- Update from upstream
	* Merged audit2allow fixes for refpolicy from Dan Walsh.
	* Merged fixfiles patch from Dan Walsh.
	* Merged restorecond daemon from Dan Walsh.
	* Merged semanage non-MLS fixes from Chris PeBenito.
	* Merged semanage and semodule man page examples from Thomas Bleher.

* Tue Mar 28 2006 Dan Walsh <dwalsh at redhat.com> 1.30.1-4
- Clean up reference policy generation in audit2allow

scim-1.4.4-9.1.fc5
------------------
* Wed Mar 29 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-9.1.fc5
- make scim-libs prereq libstdc++so7 to avoid update-gtk-immodules error when
  installing on i386 (#186365)
- setup xinput.d for some more locale (as_IN, or_IN, si_LK, vi_VN, and zh_HK)

* Thu Mar 02 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-9
- make scim-libs prereq gtk2 > 2.8 to avoid update-gtk-immodules error
  when upgrading from FC4 (#183636)

* Wed Mar 01 2006 Jens Petersen <petersen at redhat.com> - 1.4.4-8
- add scim-system-default-config.patch
  - add Zenkaku_Hankaku as trigger hotkey for Japanese users
  - use static XIM event flow so deadkeys work under XIM in off state (#169975)
- add alternatives as prereq for %post and %postun (pknirsch, #182853)

scim-hangul-0.2.2-1.fc6
-----------------------
* Thu Mar 30 2006 Akira TAGOH <tagoh at redhat.com> - 0.2.2-1
- New upstream release.

selinux-policy-2.2.28-1
-----------------------
* Mon Mar 27 2006 Dan Walsh <dwalsh at redhat.com> 2.2.28-1
- Update to upstream

* Wed Mar 22 2006 Dan Walsh <dwalsh at redhat.com> 2.2.27-1
- Update to upstream

* Wed Mar 22 2006 Dan Walsh <dwalsh at redhat.com> 2.2.25-3
- Fix policyhelp

squid-7:2.5.STABLE13-3
----------------------
* Wed Mar 29 2006 Martin Stransky <stransky at redhat.com> - 7:2.5.STABLE13-3
- improved pre script (#187217) - added group switch

sysreport-1.4.3-5
-----------------
* Tue Mar 28 2006 Than Ngo <than at redhat.com> 1.4.3-5
- use LANG=C

* Tue Mar 14 2006 Than Ngo <than at redhat.com> 1.4.3-4
- add the correct option to collect iptables information (mangle) #181299
- collect shared memory Segments info #181681

system-config-samba-1.2.35-1
----------------------------
* Wed Mar 29 2006 Nils Philippsen <nphilipp at redhat.com> - 1.2.35
- don't require gnome module (#187200)
- don't wrap text in About dialog

xscreensaver-1:4.24-2
---------------------
* Fri Mar 24 2006 Ray Strode <rstrode at redhat.com> - 1:4.24-2
- add patch from jwz to reap zombie processes (bug 185833)

xterm-211-4.FC6
---------------
* Wed Mar 29 2006 Jason Vas Dias <jvdias at redhat.com> - 211-4
- fix bug 186935: cursor GCs must be freed with XtReleaseGC

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	evolution - 2.6.0-1.i386 requires libpisock.so.9
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	kdepim - 6:3.5.1-1.2.i386 requires libpisock.so.9



Broken deps for ia64
----------------------------------------------------------
	evolution - 2.6.0-1.ia64 requires libpisock.so.9()(64bit)
	kdepim - 6:3.5.1-1.2.ia64 requires libpisock.so.9()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	evolution - 2.6.0-1.ppc requires libpisock.so.9
	kdepim - 6:3.5.1-1.2.ppc requires libpisock.so.9



Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	evolution - 2.6.0-1.ppc64 requires libpisock.so.9()(64bit)
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	kdepim - 6:3.5.1-1.2.ppc64 requires libpisock.so.9()(64bit)
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	evolution - 2.6.0-1.x86_64 requires libpisock.so.9()(64bit)
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	kdepim - 6:3.5.1-1.2.x86_64 requires libpisock.so.9()(64bit)








From dwmw2 at infradead.org  Thu Mar 30 15:26:00 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 30 Mar 2006 16:26:00 +0100
Subject: Fedora's way forward
In-Reply-To: <1143694224.2250.5.camel@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<1143694224.2250.5.camel@localhost.localdomain>
Message-ID: <1143732360.5600.412.camel@pmac.infradead.org>

On Wed, 2006-03-29 at 20:50 -0800, Per Bjornsson wrote:
> Unfortunately it's probably not that easy to do something legal about
> Flash - at least if you want it to make sound... Doesn't Flash use MP3
> for audio? And what is the video format used in recent Flash versions?

Any sane flash player will use gstreamer for audio, surely?

> Swfdec may be able to do an end-run around this by using gstreamer, in
> that case all the parts legally possible can be shipped by Fedora, and
> other stuff can get plugged in by users by means of plug-ins.

Right.

-- 
dwmw2



From chasd at silveroaks.com  Thu Mar 30 15:34:38 2006
From: chasd at silveroaks.com (chasd at silveroaks.com)
Date: Thu, 30 Mar 2006 09:34:38 -0600
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <20060330001810.CAEDC73678@hormel.redhat.com>
References: <20060330001810.CAEDC73678@hormel.redhat.com>
Message-ID: <90eabaecd1337282b5e5f363d9485e04@silveroaks.com>


On Mar 29, 2006, at 6:18 PM, fedora-devel-list-request at redhat.com wrote:
>>
>> NT, Mac OS < X ). Not included is Linux, which is not a depreciated
>                                                           ^^^^^^^^^^^
> depreciate v. t.
>    To lessen in price or estimated value; to lower the worth of;
>    to represent as of little value or claim to esteem; to undervalue.
>
> deprecated adj.
>    Said of a program or feature that is considered obsolescent and in
>    the process of being phased out, usually in favor of a specified
>    replacement.

Thanks for correcting me.

>> platform ( which is good ). That means the Linux Flash Player version 
>> 7
>> has the above vulnerability, and a fix will not be available until
>> Player 8.5 is available for Linux.
>
> Thankfully, no.

Our company has a distribution license, so I get installers from a 
different URL.
I had looked only at the date in the read me file of the Linux 
installer ( January 2006 ) and not specifically at the version number.

Again I stand corrected, thank you.


Charles Dostale
System Admin - Silver Oaks Communications



From billcrawford1970 at gmail.com  Thu Mar 30 15:50:08 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 30 Mar 2006 16:50:08 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
Message-ID: <200603301650.10065.billcrawford1970@googlemail.com>

On Thursday 30 March 2006 04:53, Avi Alkalay wrote:

> Hummm, never heard about puppet. Seems interesting.
> The problem I see with this approach is the additional layer that manages
> the configuration files syntax. And again: ALL configuration files can be
> represented by an hierarchy of key/value pairs. They are different because
> they received a considerable amount of syntax fat to make them look nicer
> to your human eyes. And what puppet seems to do is try to work with this
> fat.
>
> Elektra completely removes that fat and reduces the configuration
> parameters to what they really are: key/value pairs.

Dunno where you got this obsession, but just because you can represent data as 
"key/value pairs" doesn't mean that's always the best layout.

There's a reason why programs aren't written for the old Turing Machine, and 
that's that however well it might be able to represent any possible program, 
it's incredibly verbose.

The examples which have appeared in this thread have all made things *less* 
clear afaics.

Bill"somewhat sick of this thread but suspecting if people don't reply the 
lunatics will end up running the asylum"Crawford.



From pjones at redhat.com  Thu Mar 30 16:11:28 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 30 Mar 2006 11:11:28 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <20060330015017.f75cb8b1.robn@berrymount.nl>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<44273ECD.8010606@mindspring.com>
	<20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
	<20060329104913.GD11828@devserv.devel.redhat.com>
	<20060329195107.baa44e9a.robn@berrymount.nl>
	<1143660386.18075.32.camel@vroomfondel.internal.datastacks.com>
	<20060330015017.f75cb8b1.robn@berrymount.nl>
Message-ID: <1143735088.26084.16.camel@vroomfondel.internal.datastacks.com>

On Thu, 2006-03-30 at 01:50 +0200, Rob van Nieuwkerk wrote:
> On Wed, 29 Mar 2006 14:26:26 -0500
> Peter Jones <pjones at redhat.com> wrote:
> 
> > On Wed, 2006-03-29 at 19:51 +0200, Rob van Nieuwkerk wrote:
> > 
> > > Sure.  Or something like this:
> > > 
> > > 	dd conv=idirect if=/dev/cdrom count=right_number | sha1sum
> > > 
> > > And if the dd used on the FC ISO does not support the O_DIRECT feature,
> > > just add it.  Or write a completely trivial 10 line C program that
> > > does the same.
> > 
> > This will almost always get you the wrong result.  At the very least,
> > you need 'bs=2048 count="$(($(isosize /dev/cdrom) / 2048))"' with that,
> > or you wind up doing md5sum on completely bogus data with some media.
> > 
> > But as it turns out, that fails the exact same way that mediacheck does.
> > 
> > > I really never understood why there never has been any trivial
> > > work-around on the FC images for this very annoying problem.
> > 
> > dd does read(2) just like mediacheck does.  There isn't some spooky
> > magic here.  It fails in exactly the same ways for exactly the same
> > reasons.
> 
> Hi Peter,
> 
> Did you miss the O_DIRECT part ?
> 
> A read(2) on an fd opened with O_DIRECT should never lead to any readahead
> by the kernel.  On the device level *only* the blocks requested by the
> userspace read() are read.  Nothing more.

I'm not going say you're wrong.  As far as I can tell from staring at
the code, O_DIRECT would eliminate that failure from mediacheck.  But
AFAICS there's no way to make the same effective change to the block
layer's behavior for accesses through a filesystem.

So what I am saying is that this is a bad idea.  It creates a case where
mediacheck succeeds but installations may fail anyway.

That's worse than the current situation.

Even if we could affect the same change on the mounted case, it'd mean
slower installs and everybody would complain about it.  What's needed is
for readahead to be fixed so that you don't get an error (or bogus data)
unless you actually ask for a sector that should result in error.  What
you're saying is to disable readahead entirely.

-- 
  Peter



From alan at redhat.com  Thu Mar 30 16:28:08 2006
From: alan at redhat.com (Alan Cox)
Date: Thu, 30 Mar 2006 11:28:08 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143735088.26084.16.camel@vroomfondel.internal.datastacks.com>
References: <20060327130749.GB24971@devserv.devel.redhat.com>
	<1143583054.3095.36.camel@vroomfondel.internal.datastacks.com>
	<604aa7910603281404n5a465ab0y9b071784abd4e4e7@mail.gmail.com>
	<20060328221303.GA29073@devserv.devel.redhat.com>
	<4e1f5c1a0603281431n38811d8ubf39c216bb812c2a@mail.gmail.com>
	<20060329104913.GD11828@devserv.devel.redhat.com>
	<20060329195107.baa44e9a.robn@berrymount.nl>
	<1143660386.18075.32.camel@vroomfondel.internal.datastacks.com>
	<20060330015017.f75cb8b1.robn@berrymount.nl>
	<1143735088.26084.16.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060330162808.GA15135@devserv.devel.redhat.com>

On Thu, Mar 30, 2006 at 11:11:28AM -0500, Peter Jones wrote:
> Even if we could affect the same change on the mounted case, it'd mean
> slower installs and everybody would complain about it.  What's needed is
> for readahead to be fixed so that you don't get an error (or bogus data)
> unless you actually ask for a sector that should result in error.  What
> you're saying is to disable readahead entirely.

Its long fixed and Pavel's testing yesterday confirms that if you use
ide-scsi or libata it appears it all works fine. I've asked Pavel if he
wants to test the patches we have (and dropped) that fixed it earlier in 2.6
and verify they do likewise/clean them up.




From billcrawford1970 at gmail.com  Thu Mar 30 16:35:45 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 30 Mar 2006 17:35:45 +0100
Subject: Fedora's way forward
In-Reply-To: <442AABFE.8080901@cornell.edu>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<BAYC1-PASMTP1289109D1E86994A1A45F1AED00@CEZ.ICE>
	<442AABFE.8080901@cornell.edu>
Message-ID: <200603301735.46074.billcrawford1970@googlemail.com>

On Wednesday 29 March 2006 16:47, Ivan Gyurdiev wrote:
[quoting sean <seanlkml at sympatico.ca>]
> > We're not trying to convince you of anything, you're free to go about
> > your business, using Linux in a way that meets your needs.  Please extend
> > to us the same courtesy so everyone can get on with it.
>
> While I agree with your overall point that keeping Fedora open is a a
> good thing, kindly use singular instead of plural, or qualify which
> group of people you're representing on a community list.

 Kindly learn to read context. It was a reply to Eric's mail, and this remark 
appears to have been addressed to Eric. This would have been more obvious had 
you actually attributed the quote too :)

 Or should we all start using French, Latin or German which have distinct 
singular and plural pronouns in almost all contexts?



From stanfinley at comcast.net  Thu Mar 30 16:51:22 2006
From: stanfinley at comcast.net (Stanton Finley)
Date: Thu, 30 Mar 2006 09:51:22 -0700
Subject: Fedora's way forward
In-Reply-To: <1143715991.3802.662.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
	<1143715991.3802.662.camel@sundaram.pnq.redhat.com>
Message-ID: <1143737483.2925.8.camel@c-67-164-203-75.hsd1.ut.comcast.net>

On Thu, 2006-03-30 at 16:23 +0530, Rahul Sundaram wrote:
> Adding support for proprietary formats would heavily reduce the
> incentive for people to use Free formats. Thats my take on it.
> 
> Rahul
> 
Rahul, do you use any proprietary applications on your computers at all,
including proprietary graphics acceleration driver such as nVidia or
ATI? I ask this because in this day and age much serious computer work
is seriously hobbled without at least some of them, depending on what
you do with your computer of course. Reading and replying to emails is
one thing. 3D rendering work is quite another. See what I'm getting at?
-- 
Stanton Finley
http://stanton-finley.net/



From seanlkml at sympatico.ca  Thu Mar 30 17:40:54 2006
From: seanlkml at sympatico.ca (sean)
Date: Thu, 30 Mar 2006 12:40:54 -0500
Subject: Fedora's way forward
In-Reply-To: <1143737483.2925.8.camel@c-67-164-203-75.hsd1.ut.comcast.net>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
	<1143715991.3802.662.camel@sundaram.pnq.redhat.com>
	<1143737483.2925.8.camel@c-67-164-203-75.hsd1.ut.comcast.net>
Message-ID: <BAYC1-PASMTP10209433CC0726A1AE4EFAAED10@CEZ.ICE>

On Thu, 30 Mar 2006 09:51:22 -0700
Stanton Finley <stanfinley at comcast.net> wrote:

> Rahul, do you use any proprietary applications on your computers at all,
> including proprietary graphics acceleration driver such as nVidia or
> ATI? I ask this because in this day and age much serious computer work
> is seriously hobbled without at least some of them, depending on what
> you do with your computer of course. Reading and replying to emails is
> one thing. 3D rendering work is quite another. See what I'm getting at?

Are Rahul's needs really a relevant topic?

You're right though, many people are in situations today where they are 
more or less forced to use proprietary solutions; we have more work to do.  
However, people honestly needing 3D rendering to get their work done today, 
are in the minority.   

Anyway, nobody is saying that open source solutions can meet the needs of 
100% of users today.  But there are people that do have all their computing 
needs met by open source today and who don't want any proprietary baggage.  
This group of users has every right to have a distribution designed 
specifically for their needs as anyone else.   Luckily, they have Fedora.

Sean



From tim at mmto.org  Thu Mar 30 19:26:53 2006
From: tim at mmto.org (T. E. Pickering)
Date: Thu, 30 Mar 2006 12:26:53 -0700
Subject: GUI controls for instrumentation
In-Reply-To: <20060328180531.GD24725@devserv.devel.redhat.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603280103.40598.lamont@gurulabs.com>
	<A5FD712AD9D181D45F2D61FB@[10.0.0.14]>
	<200603280906.21172.lamont@gurulabs.com>
	<A320B67AF9DD7C63D43130F9@[10.0.0.14]>
	<20060328180531.GD24725@devserv.devel.redhat.com>
Message-ID: <20060330192653.GA7197@mmto.org>

we do a lot of instrument interfacing here at the MMT under fedora and
use a variety of things.  most of the code to support our wide-field
instruments is tcl/tk.  we use critcl to pull in dll/.so files to
access C/C++/vendor code from them.  the adaptive optics people use a
combination of tcl/tk, C, and IDL.  the facility spectrographs use
ruby-gnome.  we inflict a wide variety of guis on the telescope
operators.  we still have some left-over perl-tk guis, several systems
are using ruby-gnome, the guiders are largely tcl-tk with a sprinkle
of labview, the wavefront sensor interface is a mix of tcl-tk/blt and
ruby-gnome, and the mirror cell guis are raw X via windx running under
vxworks (bleah!).

i really like ruby-gnome and found it better and easier to use for
very interactive guis than the python or perl bindings.  we need
information to continually update in our windows while maintaining
continuous interactivity.  i find that ruby threads are an easier,
more straightforward way of doing this than managing a bunch of gtk
timeouts or idles.  when i first started using ruby-gnome a few years
ago there was no easy/safe way of using python's threads with its gtk
bindings.  i haven't looked recently to see how that's changed.  it's
too bad ruby's gtk/gnome bindings haven't yet found their way into
fedora extras.  i may have to join up and do it myself....

that said, interface stuff i'm currently working on is utilizing AJAX
techniques to interface with php and ruby back-ends.  so far i'm
finding this a lot more flexible in many ways than using some widget
set thanks to the extreme mutability of DHTML.  i also like the fact
that you can write one piece of software rather than two.  the back-end
generates its own interface.  for other things there's a degree of
clumsiness when dealing with the browser sandbox and trying to get it
to interact with other things on the system.  javascript can't do
system calls while system calls from php/cgi run as user apache.  this
is a deal-breaker for some of our stuff, but not an issue for many
other things.

tim

-- 
+--------------------------------------------------------------------+
|  T. E. Pickering, Ph.D.            |              MMT Observatory  |
|  Assoc. Staff Scientist            |           933 N. Cherry Ave.  |
|  tim at mmto.org  (520) 626-3755      |             Tucson, AZ 85721  |
+--------------------------------------------------------------------+
> Ok, I see you know what you're doing :-)

Either that or I've gotten pretty good at faking it.



From seandarcy2 at gmail.com  Thu Mar 30 19:48:10 2006
From: seandarcy2 at gmail.com (sean)
Date: Thu, 30 Mar 2006 14:48:10 -0500
Subject: rawhide->fc5; X won't start
In-Reply-To: <1143699226.8963.1.camel@halflap>
References: <e0ct33$mrt$1@sea.gmane.org> <e0fje2$otq$1@sea.gmane.org>
	<1143699226.8963.1.camel@halflap>
Message-ID: <e0hclq$u0m$1@sea.gmane.org>

Ray Strode wrote:
> Hi, 
> 
>> OK, so no one else sees this.
>>
>> Any suggestions as to how to diagnose this? Any way to get more verbose 
>> or clearer error messages?
> If you run fc-cache -f from your user account does your problem go away?
> 
> --Ray
> 

Thanks for the suggestion, but...(:

Here's the console message from trying kde.

> (==) Using config file: "/etc/X11/xorg.conf"
> xset:  bad font path element (#76), possible causes are:
>     Directory does not exist or has wrong permissions
>     Directory missing fonts.dir
>     Incorrect font server address or syntax
> startkde: Starting up...
> DCOP aborting call from 'anonymous-2482' to 'kded'
> startkde: Shutting down...
> klauncher: Exiting on signal 1
> 

All the /etc/X11/fs/config directories exist. I'm not sure what 
permissions they should have, but I've tried starting X as root, same 
problem.

[ could this be some selinux issue. It should be off.]

Here's the xorg.conf font server address:
> 
> Section "Files"
> 
> 
> 	FontPath     "unix/:7100"
> EndSection

I've restarted xfs ( and rebooted), with no error messages.

I've run fc-cache -f

And all this ran fine under rawhide of March 10.

Any help realllly appreciated.

sean



From shane at geeklords.org  Thu Mar 30 19:58:22 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Thu, 30 Mar 2006 11:58:22 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <BAYC1-PASMTP05383F7CB0BB67663DC425AED10@CEZ.ICE>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<1143584970.30123.19.camel@localhost>
	<Pine.LNX.4.63.0603281433270.27793@master.geeklords.org>
	<1143586789.30123.44.camel@localhost>
	<ed0efd310603292048o3e605ac4i478a5cc433ffaa38@mail.gmail.com>
	<Pine.LNX.4.63.0603292052150.31740@master.geeklords.org>
	<Pine.LNX.4.63.0603292150230.31780@master.geeklords.org>
	<BAYC1-PASMTP05383F7CB0BB67663DC425AED10@CEZ.ICE>
Message-ID: <Pine.LNX.4.63.0603300848450.799@master.geeklords.org>

On Thu, 30 Mar 2006, sean wrote:

> For ad-hoc interactive usage that looks worse than what we have today;
> call up a config file and page through it to see the information you want.

It is but one possible example.  My point is how the keys and values are 
formated is flexible, the hierarchical key/value pair storage medium contains 
all of information required to recreate the dhcpd.conf file in its 
entirety.  The key descriptions and user comments can be stored as "files" 
associated with these same directories/keys and then compiled+arranged on 
demand for user consumption.

Perhaps this example is more to your liking?:

cfg_mgr --interactive

display -embed -nodesc -comments /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*

10.202.46.0-24 {
    # User comments go here
    use-host-decl-names = on
    }

    options {
       # User comments go here
       log-servers = 10.202.46.2, 10.202.46.3
       }

    hosts {
       ws001 {
          # User comments go here
          fixed-address = 192.168.0.1
          # User comments go here
          default-lease-time = 10000
 	 # User comments go here
          filename = /lts/vmlinuz-2.4.26-ltsp-1
 	 # User comments go here
 	 hw = ethernet:00:11:22:33:44:55
        }
    }
}

> But the difficult issue isn't really what tools might be possible after
> a unified config system is in place.   Rather, it's how to get enough
> apps to use the config system in the first place.   My own view is that
> concentrating on the needs of _developers_ not users and sysadmins
> is the way to success.   The user and admin tools are the easy part.

I agree the tools shouldn't be the focus, my point though is the with the 
right storage design / medium existing tools would be usable.

Cheers,
Shane



From jdesbonnet at gmail.com  Thu Mar 30 20:09:05 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Thu, 30 Mar 2006 21:09:05 +0100
Subject: GUI controls for instrumentation
In-Reply-To: <20060330192653.GA7197@mmto.org>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603280103.40598.lamont@gurulabs.com>
	<A5FD712AD9D181D45F2D61FB@10.0.0.14>
	<200603280906.21172.lamont@gurulabs.com>
	<A320B67AF9DD7C63D43130F9@10.0.0.14>
	<20060328180531.GD24725@devserv.devel.redhat.com>
	<20060330192653.GA7197@mmto.org>
Message-ID: <1cef3e950603301209h6e800571o8246915b56258535@mail.gmail.com>

I would love to see the DHTML/AJAX stuff in action, if it's convenient
to make available as a demo page.
Thanks,
Joe.

On 3/30/06, T. E. Pickering <tim at mmto.org> wrote:

> that said, interface stuff i'm currently working on is utilizing AJAX
> techniques to interface with php and ruby back-ends.  so far i'm
> finding this a lot more flexible in many ways than using some widget
> set thanks to the extreme mutability of DHTML.  i also like the fact
> that you can write one piece of software rather than two.  the back-end
> generates its own interface.  for other things there's a degree of
> clumsiness when dealing with the browser sandbox and trying to get it
> to interact with other things on the system.  javascript can't do
> system calls while system calls from php/cgi run as user apache.  this
> is a deal-breaker for some of our stuff, but not an issue for many
> other things.
>
> tim
>
> --
> +--------------------------------------------------------------------+
> |  T. E. Pickering, Ph.D.            |              MMT Observatory  |
> |  Assoc. Staff Scientist            |           933 N. Cherry Ave.  |
> |  tim at mmto.org  (520) 626-3755      |             Tucson, AZ 85721  |
> +--------------------------------------------------------------------+
> > Ok, I see you know what you're doing :-)
>
> Either that or I've gotten pretty good at faking it.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From sundaram at fedoraproject.org  Thu Mar 30 20:21:00 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Mar 2006 01:51:00 +0530
Subject: Fedora's way forward
In-Reply-To: <1143737483.2925.8.camel@c-67-164-203-75.hsd1.ut.comcast.net>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
	<1143715991.3802.662.camel@sundaram.pnq.redhat.com>
	<1143737483.2925.8.camel@c-67-164-203-75.hsd1.ut.comcast.net>
Message-ID: <1143750061.3802.721.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-30 at 09:51 -0700, Stanton Finley wrote:
> On Thu, 2006-03-30 at 16:23 +0530, Rahul Sundaram wrote:
> > Adding support for proprietary formats would heavily reduce the
> > incentive for people to use Free formats. Thats my take on it.
> > 
> > Rahul
> > 
> Rahul, do you use any proprietary applications on your computers at all,
> including proprietary graphics acceleration driver such as nVidia or
> ATI? 

On the machine that I run on a regular basis, I dont and certainly no
proprietary drivers but thats irrelevant since its my system. On
occasions where I had to use proprietary applications, I installed it on
my own and didnt complain that Fedora didn't provide it by default since
I know that it doesnt fit into the Fedora model. I certainly dont
provide expect that all my computing needs to be served out of the box
for me in Fedora. 

> I ask this because in this day and age much serious computer work
> is seriously hobbled without at least some of them, depending on what
> you do with your computer of course. Reading and replying to emails is
> one thing. 3D rendering work is quite another. See what I'm getting at?

If your 3D rendering work requires proprietary drivers get it post
installation. We are making it more and more easier to install
applications from a repository in pretty much every release. Earlier you
had to fiddle with yum repository configuration files. Now you just
install a repository release package. In next release you might be able
to point to a repository and get packages during installation itself.
Maybe add the functionality that lets you lets you click and install
packages from repositories using Pirut and a firefox plugin. 


Alternatively there are efforts to produce good 3D drivers and open
hardware. Invest your development skills, other efforts or money in such
things.  Buy hardware that plays open formats and tell those other
companies that you went with the competition because they didnt support
open formats. Build demand and volume for that. Yes, thats harder than
installing proprietary drivers but nobody said that developing a
completely Free and open source system was going to be easy and thats
exactly what Fedora's goals are right from the start and it has very
explicit. We have enough problems to tackle in other places in Fedora
without spending time discussing for the umpteenth time why Fedora
doesnt support the patent and proprietary mp3 codec. Please be more
constructive. 


Rahul



From rstrode at redhat.com  Thu Mar 30 20:32:38 2006
From: rstrode at redhat.com (Ray Strode)
Date: Thu, 30 Mar 2006 15:32:38 -0500
Subject: rawhide->fc5; X won't start
In-Reply-To: <e0hclq$u0m$1@sea.gmane.org>
References: <e0ct33$mrt$1@sea.gmane.org> <e0fje2$otq$1@sea.gmane.org>
	<1143699226.8963.1.camel@halflap>  <e0hclq$u0m$1@sea.gmane.org>
Message-ID: <1143750758.3589.1.camel@halflap>

Hi,

> Ray Strode wrote:
> > Hi, 
> > 
> >> OK, so no one else sees this.
> >>
> >> Any suggestions as to how to diagnose this? Any way to get more verbose 
> >> or clearer error messages?
> > If you run fc-cache -f from your user account does your problem go away?
> > 
> > --Ray
> > 
> 
> Thanks for the suggestion, but...(:
> 
> Here's the console message from trying kde.
> 
> > (==) Using config file: "/etc/X11/xorg.conf"
> > xset:  bad font path element (#76), possible causes are:
> >     Directory does not exist or has wrong permissions
> >     Directory missing fonts.dir
> >     Incorrect font server address or syntax
> > startkde: Starting up...
> > DCOP aborting call from 'anonymous-2482' to 'kded'
> > startkde: Shutting down...
> > klauncher: Exiting on signal 1
> >
What if you manually add some font paths to your Xorg.conf
Try adding some of the ones in 
/usr/share/X11/fonts/
and /usr/share/fonts

--Ray



From jdesbonnet at gmail.com  Thu Mar 30 20:33:33 2006
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Thu, 30 Mar 2006 21:33:33 +0100
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <Pine.LNX.4.63.0603291135060.30613@master.geeklords.org>
References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com>
	<Pine.LNX.4.63.0603281438360.27793@master.geeklords.org>
	<20060329130044.GB3411@dudweiler.stuttgart.redhat.com>
	<16de708d0603290836s6d580f44v2e652255a824827e@mail.gmail.com>
	<Pine.LNX.4.63.0603291135060.30613@master.geeklords.org>
Message-ID: <1cef3e950603301233x29ff9852p3eeb9208112009c9@mail.gmail.com>

On 3/29/06, Shane Stixrud <shane at geeklords.org> wrote:
> They want actual code... Is there a good case here for gathering
> requirements and perhaps writing a specification, getting feedback from
> the major players prior to code being written?

I agree 100% with that. We need to figure out what we want,  not how
to do it right now. If we can get relative consensus on the features
and requirements of a perfect config system then I'm sure someone will
step up and get a prototype up and running soon afterward. How best to
do that? Wiki page? dunno...



From kzak at redhat.com  Thu Mar 30 21:04:55 2006
From: kzak at redhat.com (Karel Zak)
Date: Thu, 30 Mar 2006 23:04:55 +0200
Subject: suspend/hibernate in the command line
In-Reply-To: <1143654158.18075.15.camel@vroomfondel.internal.datastacks.com>
References: <ur74n1min.fsf@gmail.com>
	<1143506183.5625.6.camel@daxter.boston.redhat.com>
	<20060328223620.GA7838@petra.dvoda.cz>
	<1143654158.18075.15.camel@vroomfondel.internal.datastacks.com>
Message-ID: <20060330210455.GC4408@petra.dvoda.cz>

On Wed, Mar 29, 2006 at 12:42:38PM -0500, Peter Jones wrote:
> On Wed, 2006-03-29 at 00:36 +0200, Karel Zak wrote:
> > On Po, b?e 27, 2006 at 07:36:23 -0500, David Zeuthen wrote:
> > > For command line use 'pm-suspend'; it doesn't require root if (and only
> > 
> >  This is really nice command. There is not man page and 
> >  
> >     pm-suspend --help
> >     
> >  has extremely useful behaviour...
> 
> FWIW, "less /usr/sbin/pm-suspend".

 I've read that of course...

> It's just a shell script.

 I think at least basic docs and support for basic options shouldn't
 be problem for arbitrary executable. The current pm-suspend behaviour
 is dirty (IMHO).

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From mc-al34luc at sbcglobal.net  Thu Mar 30 21:02:10 2006
From: mc-al34luc at sbcglobal.net (Mike Carney)
Date: Thu, 30 Mar 2006 13:02:10 -0800
Subject: 2.6.16-1.2069_FC4smp, i82860_edac module compiled debug?
Message-ID: <e0hh20$c5o$1@sea.gmane.org>

Hi there,

I just upgraded to 2.6.16-1.2069_FC4smp, and noticed the i82860_edac module
appears to be compiled to output debug messages:

messages:Mar 30 12:06:02 lucy kernel: i82860 init one
messages:Mar 30 12:06:02 lucy kernel: EDAC MC0: Giving out device to
"i82860_edac" i82860: PCI 0000:00:00.0

The ring buffer rapidly fills up with:

MC0: drivers/edac/i82860_edac.c: i82860_check()

messages. Bugzilla search showed no bugs. Shall I submit one?

Thanks.






From tbrinkman at sbcglobal.net  Thu Mar 30 21:13:45 2006
From: tbrinkman at sbcglobal.net (Tom Brinkman)
Date: Thu, 30 Mar 2006 16:13:45 -0500
Subject: Fedora Core 5 common issues and bugs
In-Reply-To: <1143660386.18075.32.camel@vroomfondel.internal.datastacks.com>
References: <1143421304.3802.351.camel@sundaram.pnq.redhat.com>
	<20060329195107.baa44e9a.robn@berrymount.nl>
	<1143660386.18075.32.camel@vroomfondel.internal.datastacks.com>
Message-ID: <200603301613.45911.tbrinkman@sbcglobal.net>

On Wednesday 29 March 2006 14:26, Peter Jones wrote:
> On Wed, 2006-03-29 at 19:51 +0200, Rob van Nieuwkerk wrote:
> > Sure.  Or something like this:
> >
> > 	dd conv=idirect if=/dev/cdrom count=right_number | sha1sum
> >
> > And if the dd used on the FC ISO does not support the O_DIRECT
> > feature, just add it.  Or write a completely trivial 10 line C
> > program that does the same.
>
> This will almost always get you the wrong result.  At the very
> least, you need 'bs=2048 count="$(($(isosize /dev/cdrom) / 2048))"'
> with that, or you wind up doing md5sum on completely bogus data
> with some media.

   sha1sum /dev/hdc    works every time here.... if the CD was burned 
with -dao

-- 
	Tom Brinkman		      Corpus Christi, Texas



From tim at mmto.org  Thu Mar 30 21:26:51 2006
From: tim at mmto.org (T. E. Pickering)
Date: Thu, 30 Mar 2006 14:26:51 -0700
Subject: GUI controls for instrumentation
In-Reply-To: <1cef3e950603301209h6e800571o8246915b56258535@mail.gmail.com>
References: <132A9F5E12B8828DA6ED8E85@10.169.6.226>
	<200603280103.40598.lamont@gurulabs.com>
	<A5FD712AD9D181D45F2D61FB@10.0.0.14>
	<200603280906.21172.lamont@gurulabs.com>
	<A320B67AF9DD7C63D43130F9@10.0.0.14>
	<20060328180531.GD24725@devserv.devel.redhat.com>
	<20060330192653.GA7197@mmto.org>
	<1cef3e950603301209h6e800571o8246915b56258535@mail.gmail.com>
Message-ID: <20060330212651.GA26522@mmto.org>

> I would love to see the DHTML/AJAX stuff in action, if it's convenient
> to make available as a demo page.

a publicly available one is at http://mmto.org/weather/.  that was
kinda my first hack at AJAX stuff to try it out.  other stuff is in
the pipeline, but either for internal use only or not quite ready. 

tim

-- 
+--------------------------------------------------------------------+
|  T. E. Pickering, Ph.D.            |              MMT Observatory  |
|  Assoc. Staff Scientist            |           933 N. Cherry Ave.  |
|  tim at mmto.org  (520) 626-3755      |             Tucson, AZ 85721  |
+--------------------------------------------------------------------+
When you are about to do an objective and scientific piece of investigation
of a topic, it is well to gave the answer firmly in hand, so that you can
proceed forthrightly, without being deflected or swayed, directly to the goal.
		-- Amrom Katz



From esr at thyrsus.com  Thu Mar 30 21:30:42 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 30 Mar 2006 16:30:42 -0500
Subject: Fedora's way forward
In-Reply-To: <1143657279.25616.11.camel@daxter.boston.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
Message-ID: <20060330213042.GB14444@thyrsus.com>

David Zeuthen <david at fubar.dk>:
> Tell me.. why you don't start a project aiming for better integration of
> 3rd party repositories outside Fedora Core and Extras? I'm sure it can
> be as simple as Alan outlined with the user just having to click a link
> in his web browser and, badebing-badebum, all the stuff is installed.
> 
> I encourage you to take this task upon you. I think it would be great!

Would Fedora carry a script or application intended to make easy access
to such third-party repositories available, even on the premise that they
carry proprietary software?

If the answer is "yes", then I would in fact be willing to work on this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From pjones at redhat.com  Thu Mar 30 21:32:23 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 30 Mar 2006 16:32:23 -0500
Subject: suspend/hibernate in the command line
In-Reply-To: <20060330210455.GC4408@petra.dvoda.cz>
References: <ur74n1min.fsf@gmail.com>
	<1143506183.5625.6.camel@daxter.boston.redhat.com>
	<20060328223620.GA7838@petra.dvoda.cz>
	<1143654158.18075.15.camel@vroomfondel.internal.datastacks.com>
	<20060330210455.GC4408@petra.dvoda.cz>
Message-ID: <1143754343.26084.86.camel@vroomfondel.internal.datastacks.com>

On Thu, 2006-03-30 at 23:04 +0200, Karel Zak wrote:

>  I think at least basic docs and support for basic options shouldn't
>  be problem for arbitrary executable.

We're taking patches.

>  The current pm-suspend behaviour is dirty (IMHO).

How so?

-- 
  Peter



From jjneely at pams.ncsu.edu  Thu Mar 30 21:33:59 2006
From: jjneely at pams.ncsu.edu (Jack Neely)
Date: Thu, 30 Mar 2006 16:33:59 -0500
Subject: Adding overrides/child menus with gnome-menus
Message-ID: <20060330213359.GD18204@anduril.pams.ncsu.edu>

Folks,

I'm attempting to add child menus to the default menus in gnome.  I can
edit /etc/xdg/menus/applications.menu but would rather not for obvious
reasons.  In RHEL 4 I'm able to put a .menu file into
/etc/xdg/menus/applications-merged per:

    http://standards.freedesktop.org/menu-spec/menu-spec-0.9.html

and that works quite well.  However, with current versions of
gnome-menus (2.13.5 and 2.12.0 I've tested) this method does not work.
The applications.menu file in FC5 references a applications.d directory.
However /etc/xdg/menus/applications.d does not work either.

Does anyone have any insight on how I can get this to work as described?

Jack Neely
-- 
Jack Neely <jjneely at ncsu.edu>
Campus Linux Services Project Lead
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89



From esr at thyrsus.com  Thu Mar 30 21:35:38 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 30 Mar 2006 16:35:38 -0500
Subject: Fedora's way forward
In-Reply-To: <442AE4DF.700@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
Message-ID: <20060330213538.GC14444@thyrsus.com>

Hans de Goede <j.w.r.degoede at hhs.nl>:
> I think that the way to tackle this is to create a system where Fedora 
> can download codecs for users and will ask users if its ok to download 
> the nescesarry coded, show the license first, etc. This way we could 
> include realmedia support too, I'm sure real will be willing to offer 
> their codec for download in a suitable format.

See, this is the kind of pragmatic approach I've been arguing for since
the beginning of this thread.
 
> If enough people believe this is a good idea I'm willing to sync some 
> time into this.

So am I, as I said upthread.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From pjones at redhat.com  Thu Mar 30 21:42:10 2006
From: pjones at redhat.com (Peter Jones)
Date: Thu, 30 Mar 2006 16:42:10 -0500
Subject: Fedora's way forward
In-Reply-To: <20060329184119.GA3656@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143614766.3802.621.camel@sundaram.pnq.redhat.com>
	<20060329145350.GA10714@thyrsus.com>
	<1143644774.3802.634.camel@sundaram.pnq.redhat.com>
	<20060329184119.GA3656@thyrsus.com>
Message-ID: <1143754930.26084.98.camel@vroomfondel.internal.datastacks.com>

On Wed, 2006-03-29 at 13:41 -0500, Eric S. Raymond wrote:

> > Are you happy with just adding support for mp3 or would WMA
> > support follow up on that next?
> Since you mention it, yes.  If we can support what users want to do,
> we should.

No, no, no.  In exactly the same way that the customer is clearly not
always right, users' desires are not always good ideas.  We must listen
to our users, but doing everything they want exactly as they want is
*not* the way to get the best distro possible.

Please, quit chasing after this senseless holy grail.  Or at least quit
posting about it.

-- 
  Peter



From rstrode at redhat.com  Thu Mar 30 21:50:26 2006
From: rstrode at redhat.com (Ray Strode)
Date: Thu, 30 Mar 2006 16:50:26 -0500
Subject: Adding overrides/child menus with gnome-menus
In-Reply-To: <20060330213359.GD18204@anduril.pams.ncsu.edu>
References: <20060330213359.GD18204@anduril.pams.ncsu.edu>
Message-ID: <1143755426.3589.3.camel@halflap>

Hi,

> Folks,
> 
> I'm attempting to add child menus to the default menus in gnome.  I can
> edit /etc/xdg/menus/applications.menu but would rather not for obvious
> reasons.  In RHEL 4 I'm able to put a .menu file into
> /etc/xdg/menus/applications-merged per:
> 
>     http://standards.freedesktop.org/menu-spec/menu-spec-0.9.html
> 
> and that works quite well.  However, with current versions of
> gnome-menus (2.13.5 and 2.12.0 I've tested) this method does not work.
> The applications.menu file in FC5 references a applications.d directory.
> However /etc/xdg/menus/applications.d does not work either.
> 
> Does anyone have any insight on how I can get this to work as described?
It looks like you may have found a bug in gnome-menus. Can you file a
bug report?

--Ray



From seanlkml at sympatico.ca  Thu Mar 30 21:53:18 2006
From: seanlkml at sympatico.ca (sean)
Date: Thu, 30 Mar 2006 16:53:18 -0500
Subject: Fedora's way forward
In-Reply-To: <20060330213538.GC14444@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
Message-ID: <BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>

On Thu, 30 Mar 2006 16:35:38 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> See, this is the kind of pragmatic approach I've been arguing for since
> the beginning of this thread.  

If you learn to respect the goals of the Fedora project without calling
its maintainers zealots, you'll find Fedora is quite open to pragmatic
decisions.  This is evidenced by how many people are using it quite
productively.

Please don't think you need to swoop in to save Fedora from itself, it's
already happily accomplishing its objectives.  For example, it is doing quite 
well without containing pointers to third party repositories in the core 
distribution.   Don't expect that to change, the core will remain 
unblemished by proprietary products or reference links.   If you can find
a way to work happily within those constraints, happy hunting.

Sean



From esr at thyrsus.com  Thu Mar 30 21:56:48 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 30 Mar 2006 16:56:48 -0500
Subject: Fedora's way forward
In-Reply-To: <604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
	<604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>
Message-ID: <20060330215648.GD14444@thyrsus.com>

Jeff Spaleta <jspaleta at gmail.com>:
> Once ESR recognized that the patent situation was more complicated
> than he had assumed this conversation should have been tabled until he
> made a personal effort to become more informed as to the patent issue.
> Instead he's chosen to continue in a discussion predicated on
> misinformation which he himself brought to this discussion.

You are misreading what I have been writing.

The general issue I'm trying to raise here cannot be answered by saying
"but getting legal access to format X is hard" or "harder than you think".
What we'd have to pay to get legal access to any given format is not
the point.

The point is this: 

1. We are not addressing what desktop users actually want and expect
   from their machines in the way of support for multimedia.

2. As long as we continue to fail to address that, our chances of 
   achieving significant desktop market share are nil.

3. Actually addressing it requires support for proprietary codecs so
   that Linux users can listen to podcasts, watch QuickTime trailers,
   et cetera.

Therefore:

4. If we want significant desktop market share, we must find a way to support 
   proprietary codecs.

Which implies:

5. World domination or 100% doctrinal purity.  *Choose any one.*

I choose world domination, because I think that's the only way we'll
get enough politico-economic leverage to *wreck the software-patent
system and the MPAA and DVDCCA and monopolists and Microsoft for good
and all*.  Make no mistake -- my dreams are as radical as those of
anyone here, it's just that I am ruthlessly pragmatic about the 
path by which we get there.

I don't care how we implement the codec support; whether it's through
shipping proprietary code until the patents run out, or pointing users
at third-party repositories that have made deals with the likes of the
Fraunhofer Institute...whatever.  That's a *detail*.

The question I'm raising is more basic: are we willing to try?  Do we
want the desktop enough to raise money, mobilize lawyers, and do all
the non-politically-correct things we'll have to?

Some DFedor people have said no.  Some have said "whoa -- the naysayers
don't have the right to speak for me".  I haven't heard an answer from
Red Hat.

What's it going to be?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From sundaram at fedoraproject.org  Thu Mar 30 21:59:19 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Mar 2006 03:29:19 +0530
Subject: Fedora's way forward
In-Reply-To: <20060330213042.GB14444@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060330213042.GB14444@thyrsus.com>
Message-ID: <1143755959.3802.724.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-30 at 16:30 -0500, Eric S. Raymond wrote:
> David Zeuthen <david at fubar.dk>:
> > Tell me.. why you don't start a project aiming for better integration of
> > 3rd party repositories outside Fedora Core and Extras? I'm sure it can
> > be as simple as Alan outlined with the user just having to click a link
> > in his web browser and, badebing-badebum, all the stuff is installed.
> > 
> > I encourage you to take this task upon you. I think it would be great!
> 
> Would Fedora carry a script or application intended to make easy access
> to such third-party repositories available, even on the premise that they
> carry proprietary software?
> 
> If the answer is "yes", then I would in fact be willing to work on this.

Well if its generic enough to work for any repository then its a very
much a nice feature to have. Wouldnt it be better to add this capability
to Pirut though?

Rahul



From esr at thyrsus.com  Thu Mar 30 21:59:34 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 30 Mar 2006 16:59:34 -0500
Subject: 'Commercial Partners'
In-Reply-To: <442AAFA0.1010608@warmcat.com>
References: <20060328155740.GC25098@thyrsus.com>
	<20060328105912.29cad8e0.seanlkml@sympatico.ca>
	<20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
	<20060329142659.GB1376783@hiwaay.net>
	<20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
Message-ID: <20060330215934.GE14444@thyrsus.com>

Andy Green <andy at warmcat.com>:
> >I don't have the money or the lawyers to pull it off.  This sort of thing
> >is why we have commercial partners with office buidings.
> 
> If you look a bit further in that direction you'll see you're asking 
> RHAT shareholders to take risks you aren't willing to take yourself.

Yes, I am.  It's a business decision. Do they want significant desktop market
share?  If so, they have to do this thing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From mattdm at mattdm.org  Thu Mar 30 22:01:15 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 30 Mar 2006 17:01:15 -0500
Subject: fc4 ghost md5sums: a tale of woe
Message-ID: <20060330220115.GA14571@jadzia.bu.edu>

I realize that FC4 is unexciting these days, so this may not generate much
enthusiasm, but: how in the _world_ are you RH folks building updates for
Fedora Core 4?

The story:

We need to make some local modifications to some of the files in the 'setup'
package here at BU, and we were chasing ourselves in circles over making it
not conflict with /var/log/lastlog also owned by util-linux.

Both of these packages have that file as a %ghost file, and last September,
they were updated to have permissions of 0644. Specifically, there's

  %ghost %attr(0644,root,root) %verify(not md5 size mtime) /var/log/lastlog

in both files.

Okay, fine, that should work. And the packages in the FC4 updates area
indeed both install without conflict.

But then, when we went to install our package, bam:

  file /var/log/lastlog from install of setup-2.5.44-1.1bu46.1 conflicts
  with file from package util-linux-2.12p-9.14

Eh? But the entries are the same. After much trying-things-to-no-avail, I
tried just plain rebuilding the setup package with no changes.

  file /var/log/lastlog from install of setup-2.5.44-1.1 conflicts
  with file from package util-linux-2.12p-9.14

Hey! It's not anything we're changing -- rebuilding the unmodified package
doesn't work either.

Diagnosing this was a bit complicated by the fact that ghost files don't
show up in rpm -ql, but eventually with a bit of python, I dumped the
md5sums of /var/log/lastlog stored in each RPM. Ah-ha -- that's the problem.
The package I build comes out with nothing. (Either 0 or "" -- not precisely
sure which and it doesn't really matter...) The RPM built by RH in the FC4
update tree has "d41d8cd98f00b204e9800998ecf8427e" -- the md5sum of an empty
file.

Well, that's weird, I thought. Maybe it's because we're using the updated
version of RPM -- rpm-4.4.1-22 -- instead of the one that shipped with FC4
originally.

No, that's not it -- that version also results in 0 md5sums for ghost files.
I can't find exactly where this is in the RPM changelog, but I had to go
back to the FC2 version of rpm to build a package with the empty-file
checksum as in the FC4 update.

So, what th' heck? Does your FC4 build system use rpmbuild from FC2, or
what? :)

We're working around this by rebuilding util-linux too, which works,
but the whole thing was a headache and I don't like how this could happen
with other packages.....


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



From fitzsim at redhat.com  Thu Mar 30 22:08:13 2006
From: fitzsim at redhat.com (Thomas Fitzsimmons)
Date: Thu, 30 Mar 2006 17:08:13 -0500
Subject: Fedora's way forward
In-Reply-To: <442ACC2F.90306@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<ufahd5h9o50.fsf@epithumia.math.uh.edu>
	<m38xqtrwc1.fsf@localhost.localdomain>
	<1143655398.2678.37.camel@tortoise.toronto.redhat.com>
	<442ACC2F.90306@hhs.nl>
Message-ID: <1143756493.3595.6.camel@tortoise.toronto.redhat.com>

On Wed, 2006-03-29 at 20:04 +0200, Hans de Goede wrote:
> 
> Thomas Fitzsimmons wrote:
> > On Wed, 2006-03-29 at 10:31 -0700, Tom Tromey wrote:
> >> Jason> The last estimate I saw for a usable gcjwebplugin was six
> >> Jason> months.
> > 
> > Yes, we're aiming to have gcjwebplugin in Fedora Core 6.
> > 
> > Tom
> > 
> 
> Now that would be really cool, what can I* do to help this?

You could profile gcjappletviewer (linked against libgcj) running this
applet:

http://www.plunk.org/~hatch/HyperbolicApplet/?size=513

to see why it runs so slowly, then file a bug at:

http://gcc.gnu.org/bugzilla/

with your results.

Tom




From david at fubar.dk  Thu Mar 30 22:08:20 2006
From: david at fubar.dk (David Zeuthen)
Date: Thu, 30 Mar 2006 17:08:20 -0500
Subject: Fedora's way forward
In-Reply-To: <20060330213042.GB14444@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060330213042.GB14444@thyrsus.com>
Message-ID: <1143756500.1617.58.camel@daxter.boston.redhat.com>

On Thu, 2006-03-30 at 16:30 -0500, Eric S. Raymond wrote:
> David Zeuthen <david at fubar.dk>:
> > Tell me.. why you don't start a project aiming for better integration of
> > 3rd party repositories outside Fedora Core and Extras? I'm sure it can
> > be as simple as Alan outlined with the user just having to click a link
> > in his web browser and, badebing-badebum, all the stuff is installed.
> > 
> > I encourage you to take this task upon you. I think it would be great!
> 
> Would Fedora carry a script or application intended to make easy access
> to such third-party repositories available, even on the premise that they
> carry proprietary software?

I'm obviously not a lawyer but I think including scripts, links or
applications to do this in the OS would constitute "contributory
infringement". I may be wrong, IANAL.

The thinking was that the user, upon post-installation, goes to a web
page, clicks on a single link, OK's some dialogs, and everything is set
up correctly. One time pain, long time gain.

I cannot see why the Fedora developers would be opposed to this?  I
mean, it's not like it's possible to get by in the world with certain
pieces of software. At least not for me and without saying too much, I
think other Fedora developers share the same point of view. I could be
wrong though.

> If the answer is "yes", then I would in fact be willing to work on this.

If the answer above is satisfactory to you, I think this could be really
great and help move the free desktop forward. 

I bet it involves some cooperation with the 3rd party repositories and
the Pirut software installation manager. It would be smashing to have
this in FC6.

Thanks!

    David



From sundaram at fedoraproject.org  Thu Mar 30 22:16:46 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Mar 2006 03:46:46 +0530
Subject: Fedora's way forward
In-Reply-To: <20060330215648.GD14444@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
	<604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>
	<20060330215648.GD14444@thyrsus.com>
Message-ID: <1143757006.3802.737.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-30 at 16:56 -0500, Eric S. Raymond wrote:
>  Make no mistake -- my dreams are as radical as those of
> anyone here, it's just that I am ruthlessly pragmatic about the 
> path by which we get there.

I would say that idea that we can produce a useful operating system and
a great end user experience purely using Free and open source software
is way more radical than people who believe they must co mingle
proprietary software to achieve that goal. Too many people have already
done that and some of them are successful with that approach too. 


> 
> I don't care how we implement the codec support; whether it's through
> shipping proprietary code until the patents run out, or pointing users
> at third-party repositories that have made deals with the likes of the
> Fraunhofer Institute...whatever.  That's a *detail*.

Yes in the grand scheme of things it might be a trivial implementation
detail but it's a very important detail from the project perspective. If
you are talking about implementing better support for helping the user
add additional repositories, great. I am all for it. If you are talking
about making it easier to access for people to access any software,
again that's  cool. If you are talking about shipping proprietary
software within Fedora then I dont agree with that goal. Make your
improvements generic enough to serve all software and not just the
proprietary ones and Fedora should be able to ship that improvement
quite easily. Thanks in advance.


Rahul



From stickster at gmail.com  Thu Mar 30 22:21:56 2006
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 30 Mar 2006 17:21:56 -0500
Subject: Where is the kernel source package for FC5 GA?
In-Reply-To: <1143715796.3802.659.camel@sundaram.pnq.redhat.com>
References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com>
	<4429C65C.3070600@comcast.net> <200603281709.38816.lamont@gurulabs.com>
	<4429D3FF.4050904@comcast.net>
	<1143592383.3802.578.camel@sundaram.pnq.redhat.com>
	<4429DBA3.1020605@comcast.net>
	<1143594150.3802.582.camel@sundaram.pnq.redhat.com>
	<1143651074.5136.5.camel@localhost.localdomain>
	<1143715796.3802.659.camel@sundaram.pnq.redhat.com>
Message-ID: <1143757316.2532.1.camel@localhost.localdomain>

On Thu, 2006-03-30 at 16:19 +0530, Rahul Sundaram wrote:
> On Wed, 2006-03-29 at 11:51 -0500, Paul W. Frields wrote:
> > On Wed, 2006-03-29 at 06:32 +0530, Rahul Sundaram wrote:
> > > On Tue, 2006-03-28 at 19:58 -0500, Neil Cherry wrote:
> > > 
> > > > >> Ah, so that's the difference. That was driving me totally nuts. I
> > > > >> couldn't figure out why I couldn't compile the kernel with the
> > > > >> devel package but I'm very successful (when I don't remove too
> > > > >> much) with the kernel sources.
> > > > > 
> > > > > We have all this information in the release notes which we spend many
> > > > > many hours writing. So you might as well as read it.
> > > > > http://fedora.redhat.com/docs/release-notes/fc5/#sn-Kernel
> > > > 
> > > > Thanks Rahul, I only found out about the release notes yesterday
> > > > when someone else mentioned them. 
> > > 
> > > I am curious. How did you manage to *miss it* ?. It has a rather
> > > prominent button in the installer, default page for the browser,
> > > mentioned usually in the release announcements etc. 
> > 
> > Don't be silly, Rahul, everybody knows we Americans can't read. :-)
> > 
> > In all seriousness, I'm betting your question is rhetorical and stems
> > from the frustration of putting so much work into the process only to
> > see endless questions like this.  (Your work is very much appreciated,
> > by the way.)  
> 
> I am looking at it to see whether there are other avenues where we can
> highlight such important documents.

I knew this, but apparently my sarcasm didn't make it over the wire
intact. :-)  Yes, we want to make sure everyone alive knows about the
release notes, especially after all the work that went into them by so
many folks.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060330/b7892408/attachment.sig>

From j.w.r.degoede at hhs.nl  Thu Mar 30 22:20:25 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 31 Mar 2006 00:20:25 +0200
Subject: Fedora's way forward
In-Reply-To: <BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
Message-ID: <442C59A9.1010507@hhs.nl>



sean wrote:
> On Thu, 30 Mar 2006 16:35:38 -0500
> "Eric S. Raymond" <esr at thyrsus.com> wrote:
> 
>> See, this is the kind of pragmatic approach I've been arguing for since
>> the beginning of this thread.  
> 
> If you learn to respect the goals of the Fedora project without calling
> its maintainers zealots, you'll find Fedora is quite open to pragmatic
> decisions.  This is evidenced by how many people are using it quite
> productively.
> 
> Please don't think you need to swoop in to save Fedora from itself, it's
> already happily accomplishing its objectives.  For example, it is doing quite 
> well without containing pointers to third party repositories in the core 
> distribution.   Don't expect that to change, the core will remain 
> unblemished by proprietary products or reference links.   If you can find
> a way to work happily within those constraints, happy hunting.
> 

Please speak for yourself and not on behalve of the entire Fedora 
Community. Which Sean are you anyway? I can't find much on you and 
Fedora, I otoh maintain many FE packages and use my full name.

I for one wouldn't mind pointers and even install help to (100% legally 
ok) proprietary software if this will significantly boost the end user 
experience.

With this said I do believe that we should be carefull with this, if 
there is a free tool which does 95% of the job, then we should not 
include links to proprietary alternatives. There is however no free tool 
which will allow people to access all those mp3 files from for example 
www.magnatune.com.

Regards,

Hans



From seanlkml at sympatico.ca  Thu Mar 30 22:28:40 2006
From: seanlkml at sympatico.ca (sean)
Date: Thu, 30 Mar 2006 17:28:40 -0500
Subject: Fedora's way forward
In-Reply-To: <442C59A9.1010507@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
Message-ID: <BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>

On Fri, 31 Mar 2006 00:20:25 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> Please speak for yourself and not on behalve of the entire Fedora 
> Community. Which Sean are you anyway? I can't find much on you and 
> Fedora, I otoh maintain many FE packages and use my full name.
> 
> I for one wouldn't mind pointers and even install help to (100% legally 
> ok) proprietary software if this will significantly boost the end user 
> experience.
>
> With this said I do believe that we should be carefull with this, if 
> there is a free tool which does 95% of the job, then we should not 
> include links to proprietary alternatives. There is however no free tool 
> which will allow people to access all those mp3 files from for example 
> www.magnatune.com.

Even if you wouldn't mind it, it's against the stated goals of the 
project.   Everyone has a perference one way or the other, some wouldn't
mind, some would.   That's why the objectives of the project were
very carefully laid out.  Please see Rahul's recent post if you think my 
interpretation of the basic premise of the Fedora project is wrong.

Besides, adding third party repositories is already easy and getting 
easier all the time.

Sean



From michael at knox.net.nz  Thu Mar 30 22:45:53 2006
From: michael at knox.net.nz (Michael J Knox)
Date: Fri, 31 Mar 2006 10:45:53 +1200
Subject: Fedora's way forward
In-Reply-To: <BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
Message-ID: <442C5FA1.5050506@knox.net.nz>

sean wrote:
> On Fri, 31 Mar 2006 00:20:25 +0200
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> Please speak for yourself and not on behalve of the entire Fedora 
>> Community. Which Sean are you anyway? I can't find much on you and 
>> Fedora, I otoh maintain many FE packages and use my full name.
>>
>> I for one wouldn't mind pointers and even install help to (100% legally 
>> ok) proprietary software if this will significantly boost the end user 
>> experience.
>>
>> With this said I do believe that we should be carefull with this, if 
>> there is a free tool which does 95% of the job, then we should not 
>> include links to proprietary alternatives. There is however no free tool 
>> which will allow people to access all those mp3 files from for example 
>> www.magnatune.com.
> 
> Even if you wouldn't mind it, it's against the stated goals of the 
> project.   Everyone has a perference one way or the other, some wouldn't
> mind, some would.   That's why the objectives of the project were
> very carefully laid out.  Please see Rahul's recent post if you think my 
> interpretation of the basic premise of the Fedora project is wrong.
> 
> Besides, adding third party repositories is already easy and getting 
> easier all the time.
> 

Since it is pretty clear that Fedora Core will not accommodate 3rd party 
closed source applications, why don't those that would have like to have 
this get together and make a solution?

http://easylinux.info/wiki/Fedora_fc5

The above link is a prime example of how this subject could be 
approached (its still very rough, but a good start). Add in some support 
from the pre existing 3rd party repo guys and you could have a winning 
solution.

There is obviously no single silver bullet for this issue, but instead 
of theorizing about what Fedora should/shouldn't/can/won't/etc do, why 
don't those that have a common interest stand up to the plate and work 
on the issue outside of Fedora Core?

Perhaps Fedora can meet the effort by providing a link or something like 
that to the project.

Just a thought.

Michael



From smooge at gmail.com  Thu Mar 30 22:49:34 2006
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Thu, 30 Mar 2006 15:49:34 -0700
Subject: Fedora's way forward
In-Reply-To: <20060330215648.GD14444@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz>
	<604aa7910603291201q746f0eafjc631a7fa79f13aae@mail.gmail.com>
	<20060330215648.GD14444@thyrsus.com>
Message-ID: <80d7e4090603301449w495394afgf700990177416a7d@mail.gmail.com>

On 3/30/06, Eric S. Raymond <esr at thyrsus.com> wrote:

> Some DFedor people have said no.  Some have said "whoa -- the naysayers
> don't have the right to speak for me".  I haven't heard an answer from
> Red Hat.
>
> What's it going to be?


Eric, I doubt you are going to hear an official Red Hat answer on this
list because this is a Fedora list and Red Hat seems to really trying
to make the seperation between the two more solid in the last 6
months. I also doubt you are going to get an anwer you will like.. to
quote Steve Jobs from 1996

"""
"If I were running Apple, I would milk the Macintosh for all it's
worth -- and get busy on the next great thing. The PC wars are over.
Done. Microsoft won a long time ago."
-- Fortune, Feb. 19, 1996
"""

I don't think that Red Hat, IBM, or even Google would say differently.
Microsoft is the 800 pound gorilla.. the best Red Hat can hope for is
to be the Chimp who gets beaten up for his bananas. Apple seems to be
re-inventing itself to be a music/movie company. Google looks to be
actually fullfilling the old Netscape mantra of the Web is the thing.
IBM is into servers and backend services. I don't know what Red Hat is
into anymore.. but personally I wouldnt go into the desktop market
with anything less than what Apple offers in 'cool' features for even
a hope of doing battle with the windmills of Patents, Microsoft, etc.


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From sundaram at fedoraproject.org  Thu Mar 30 22:52:18 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Mar 2006 04:22:18 +0530
Subject: Fedora's way forward
In-Reply-To: <442C5FA1.5050506@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
Message-ID: <1143759138.3802.743.camel@sundaram.pnq.redhat.com>

On Fri, 2006-03-31 at 10:45 +1200, Michael J Knox wrote:

> Perhaps Fedora can meet the effort by providing a link or something like 
> that to the project.

Already linked from http://fedoraproject.org/wiki/CommunityWebsites
which is linked from the FAQ at http://fedoraproject.org/wiki/FAQ which
is linked from http://redhat.com/fedora which you can access through a
link as well as a big banner from http://redhat.com

Rahul



From michael at knox.net.nz  Thu Mar 30 22:59:43 2006
From: michael at knox.net.nz (Michael J Knox)
Date: Fri, 31 Mar 2006 10:59:43 +1200
Subject: Fedora's way forward
In-Reply-To: <1143759138.3802.743.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
Message-ID: <442C62DF.7010800@knox.net.nz>

Rahul Sundaram wrote:

>On Fri, 2006-03-31 at 10:45 +1200, Michael J Knox wrote:
>
>  
>
>>Perhaps Fedora can meet the effort by providing a link or something like 
>>that to the project.
>>    
>>
>
>Already linked from http://fedoraproject.org/wiki/CommunityWebsites
>which is linked from the FAQ at http://fedoraproject.org/wiki/FAQ which
>is linked from http://redhat.com/fedora which you can access through a
>link as well as a big banner from http://redhat.com
>
>Rahul
>
>  
>
So I can assume from that, Fedora would like to the project?

So how about the rest of you?

Michael



From mike at miketc.com  Thu Mar 30 23:15:41 2006
From: mike at miketc.com (Mike Chambers)
Date: Thu, 30 Mar 2006 17:15:41 -0600
Subject: Fedora's way forward
In-Reply-To: <442C62DF.7010800@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
Message-ID: <1143760541.2157.2.camel@scrappy.miketc.com>

On Fri, 2006-03-31 at 10:59 +1200, Michael J Knox wrote:
> Rahul Sundaram wrote:
> 
> >On Fri, 2006-03-31 at 10:45 +1200, Michael J Knox wrote:
> >
> >  
> >
> >>Perhaps Fedora can meet the effort by providing a link or something like 
> >>that to the project.
> >>    
> >>
> >
> >Already linked from http://fedoraproject.org/wiki/CommunityWebsites
> >which is linked from the FAQ at http://fedoraproject.org/wiki/FAQ which
> >is linked from http://redhat.com/fedora which you can access through a
> >link as well as a big banner from http://redhat.com
> >
> >Rahul
> >
> >  
> >
> So I can assume from that, Fedora would like to the project?
> 
> So how about the rest of you?

Unless there is already a site out there that can represent all
repositories (whether it be by link, providing .repo files, etc..),
someone could create such as site, and then build upon it.  And if it's
legal/OK to point to it, or whatever links/sites upon it, then Fedora
can point to it/whatever and provide the 3rd party initial contact for
the users?

http://www.linuxrepos.com (THIS SITE DOES NOT EXIST, yet..)????

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt, then it's hilarious!"



From sundaram at fedoraproject.org  Thu Mar 30 23:21:16 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Mar 2006 04:51:16 +0530
Subject: Fedora's way forward
In-Reply-To: <1143760541.2157.2.camel@scrappy.miketc.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
Message-ID: <1143760877.3802.757.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-30 at 17:15 -0600, Mike Chambers wrote:

> 
> Unless there is already a site out there that can represent all
> repositories (whether it be by link, providing .repo files, etc..),
> someone could create such as site, and then build upon it.  And if it's
> legal/OK to point to it, or whatever links/sites upon it, then Fedora
> can point to it/whatever and provide the 3rd party initial contact for
> the users?

What I believe, legal told us is that what we can point to third party
websites that dont contain any software by themselves as long as we dont
tell them what to look for in that websites.

Rahul



From mike at miketc.com  Thu Mar 30 23:27:54 2006
From: mike at miketc.com (Mike Chambers)
Date: Thu, 30 Mar 2006 17:27:54 -0600
Subject: Fedora's way forward
In-Reply-To: <1143760877.3802.757.camel@sundaram.pnq.redhat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
Message-ID: <1143761274.2157.9.camel@scrappy.miketc.com>

On Fri, 2006-03-31 at 04:51 +0530, Rahul Sundaram wrote:

> What I believe, legal told us is that what we can point to third party
> websites that dont contain any software by themselves as long as we dont
> tell them what to look for in that websites.

So what could happen (and I hope everyone is listening/looking at this),
so everyone understands at this point for legal reason and such is
this..

1 - Fedora includes link/bookmark in the default bookmarks of whatever
web browsers (or in the release notes or whatever) that points to
www.some3rdpartyrepo.com site.  And the properties or name of this link
is maybe 3rd Party Programs, but no one individual program is mentioned.

2 - This web site can have all the .repo/apt/whatever files that link to
all the different repos.  Or it can have it's own one little .repo/apt
file that has all the repos already in it, or whatever.

3 - This site would also already have whatever permissions it needs (if
any at all) to link to all these sites and whatever else.

Would that satisfy most users for the time being until such time as
patents, permissions, or whatever are done/used/can be used/whatever?

-- 
Mike Chambers
Madisonville, KY

"It's only funny until someone gets hurt, then it's hilarious!"



From esr at thyrsus.com  Thu Mar 30 23:34:51 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 30 Mar 2006 18:34:51 -0500
Subject: Fedora's way forward
In-Reply-To: <1143760877.3802.757.camel@sundaram.pnq.redhat.com>
References: <442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
Message-ID: <20060330233451.GB15963@thyrsus.com>

Rahul Sundaram <sundaram at fedoraproject.org>:
> What I believe, legal told us is that what we can point to third party
> websites that dont contain any software by themselves as long as we dont
> tell them what to look for in that websites.

That's helpful.  I wonder if "Don't tell them what to look for excludes
saying "Useful proprietary software (including multimedis codecs) is here".
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From sundaram at fedoraproject.org  Thu Mar 30 23:38:16 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Mar 2006 05:08:16 +0530
Subject: Fedora's way forward
In-Reply-To: <20060330233451.GB15963@thyrsus.com>
References: <442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
	<20060330233451.GB15963@thyrsus.com>
Message-ID: <1143761896.3802.761.camel@sundaram.pnq.redhat.com>

On Thu, 2006-03-30 at 18:34 -0500, Eric S. Raymond wrote:
> Rahul Sundaram <sundaram at fedoraproject.org>:
> > What I believe, legal told us is that what we can point to third party
> > websites that dont contain any software by themselves as long as we dont
> > tell them what to look for in that websites.
> 
> That's helpful.  I wonder if "Don't tell them what to look for excludes
> saying "Useful proprietary software (including multimedis codecs) is here".

Dont know. Forwarded to legal.

Rahul



From michael at knox.net.nz  Thu Mar 30 23:42:05 2006
From: michael at knox.net.nz (Michael J Knox)
Date: Fri, 31 Mar 2006 11:42:05 +1200
Subject: Fedora's way forward
In-Reply-To: <20060330233451.GB15963@thyrsus.com>
References: <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>	<442C62DF.7010800@knox.net.nz>	<1143760541.2157.2.camel@scrappy.miketc.com>	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
	<20060330233451.GB15963@thyrsus.com>
Message-ID: <442C6CCD.9050404@knox.net.nz>

Eric S. Raymond wrote:
> Rahul Sundaram <sundaram at fedoraproject.org>:
>> What I believe, legal told us is that what we can point to third party
>> websites that dont contain any software by themselves as long as we dont
>> tell them what to look for in that websites.
> 
> That's helpful.  I wonder if "Don't tell them what to look for excludes
> saying "Useful proprietary software (including multimedis codecs) is here".

It doesn't have to be worded like that.

"Useful 3rd party software collection" is obvious and (to me atleast) 
less likely to dance on the line of RH's legal concerns.

Michael



From esr at thyrsus.com  Thu Mar 30 23:57:53 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 30 Mar 2006 18:57:53 -0500
Subject: Fedora's way forward
In-Reply-To: <1143761274.2157.9.camel@scrappy.miketc.com>
References: <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
	<1143761274.2157.9.camel@scrappy.miketc.com>
Message-ID: <20060330235753.GC15963@thyrsus.com>

Mike Chambers <mike at miketc.com>:
> 1 - Fedora includes link/bookmark in the default bookmarks of whatever
> web browsers (or in the release notes or whatever) that points to
> www.some3rdpartyrepo.com site.  And the properties or name of this link
> is maybe 3rd Party Programs, but no one individual program is mentioned.
> 
> 2 - This web site can have all the .repo/apt/whatever files that link to
> all the different repos.  Or it can have it's own one little .repo/apt
> file that has all the repos already in it, or whatever.

Or it can work like livna, where you download an RPM that installs
repo files.

> 3 - This site would also already have whatever permissions it needs (if
> any at all) to link to all these sites and whatever else.
> 
> Would that satisfy most users for the time being until such time as
> patents, permissions, or whatever are done/used/can be used/whatever?

If we can set this up so the users are only two clicks away from the
proprietary codecs they need (one to get to www.some3rdpartyrepo.com,
one to start a meta-package download from there), then I think this 
would be good enough.

Fedora will need to make some minor changes to make this work really
smoothly, though.  RPM downloads indirecting to pirut is a good one.

The technology isn't the hard part.  The hard part is accepting that
100% free software dogmatism is not good enough as a guide to action,
because all dogma does is shut your brain down.  And that what
ordinary users want to do with their computers actually matters.

If we can get our brains that far along the path, the tech and the
money and the lawyers are all solvable problems.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From alan at clueserver.org  Fri Mar 31 00:00:08 2006
From: alan at clueserver.org (alan)
Date: Thu, 30 Mar 2006 16:00:08 -0800 (PST)
Subject: Fedora's way forward
In-Reply-To: <20060330233451.GB15963@thyrsus.com>
References: <442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
	<20060330233451.GB15963@thyrsus.com>
Message-ID: <Pine.LNX.4.64.0603301557590.19896@blackbox.fnordora.org>

On Thu, 30 Mar 2006, Eric S. Raymond wrote:

> Rahul Sundaram <sundaram at fedoraproject.org>:
>> What I believe, legal told us is that what we can point to third party
>> websites that dont contain any software by themselves as long as we dont
>> tell them what to look for in that websites.
>
> That's helpful.  I wonder if "Don't tell them what to look for excludes
> saying "Useful proprietary software (including multimedis codecs) is here".

Sounds like the old "wine brick" ruse.  "Don't click on this link and 
install the software you find there or you will be violating the law."

-- 
"Remember there is a big difference between kneeling down and bending over." - Frank Zappa



From alan at clueserver.org  Fri Mar 31 00:05:25 2006
From: alan at clueserver.org (alan)
Date: Thu, 30 Mar 2006 16:05:25 -0800 (PST)
Subject: Fedora's way forward
In-Reply-To: <20060330235753.GC15963@thyrsus.com>
References: <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
	<1143761274.2157.9.camel@scrappy.miketc.com>
	<20060330235753.GC15963@thyrsus.com>
Message-ID: <Pine.LNX.4.64.0603301601000.19896@blackbox.fnordora.org>

On Thu, 30 Mar 2006, Eric S. Raymond wrote:

> The technology isn't the hard part.  The hard part is accepting that
> 100% free software dogmatism is not good enough as a guide to action,
> because all dogma does is shut your brain down.  And that what
> ordinary users want to do with their computers actually matters.
>
> If we can get our brains that far along the path, the tech and the
> money and the lawyers are all solvable problems.

Torrent-based repositories? (Using on-yum routing?)


"The life of a repo-man is always intense." - some repository manager

-- 
"Remember there is a big difference between kneeling down and bending over." - Frank Zappa



From seanlkml at sympatico.ca  Fri Mar 31 00:22:43 2006
From: seanlkml at sympatico.ca (sean)
Date: Thu, 30 Mar 2006 19:22:43 -0500
Subject: Fedora's way forward
In-Reply-To: <20060330235753.GC15963@thyrsus.com>
References: <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
	<1143761274.2157.9.camel@scrappy.miketc.com>
	<20060330235753.GC15963@thyrsus.com>
Message-ID: <BAYC1-PASMTP0599CCE7A0CDAD49C9EDC4AED60@CEZ.ICE>

On Thu, 30 Mar 2006 18:57:53 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> The technology isn't the hard part.  The hard part is accepting that
> 100% free software dogmatism is not good enough as a guide to action,
> because all dogma does is shut your brain down.  And that what
> ordinary users want to do with their computers actually matters.
> 
> If we can get our brains that far along the path, the tech and the
> money and the lawyers are all solvable problems.

Being able to have your needs met by open source software alone 
isn't dogmatism, it's a reality for many people.  They have every
right to a distribution specifically designed for their needs; just
as Fedora is.

People who want to add proprietary repositories on top of Fedora 
already  do so without much trouble.   Your desire to step over that
last inch isn't based on pragmatism but rather your dogmatism
about the proper way to world domination.

Your dream that Linux is just a few binary modules away from world 
domination is such a pipe dream it just isn't worth tarnishing the 
premier open source distribution over.

If you can get your brain that far a long, it would be nice.

Sean



From avi at unix.sh  Fri Mar 31 02:57:49 2006
From: avi at unix.sh (Avi Alkalay)
Date: Thu, 30 Mar 2006 23:57:49 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
Message-ID: <ed0efd310603301857j16907b40qc2525c89a6b6f856@mail.gmail.com>

Miloslav Trmac <mitr volny cz> wrote:
> Can all configuration files be _usefully_ represented by a hierarchy?
> The natural format (= format prefered for human editing) for some
> applications uses m4 (sendmail, SELinux policy) or even arbitrary
> PHP/perl code.

Those ones you cited are the perfect examples of how badly designed
these configurations are, because they allow mixing of configuration
elements with pure business logic.

Although this is powerful, the business logic should not be mixed with
configuration elements. Just to cite an example, Unix filesystem
(a.k.a. FHS) is designed with this separation in mind: logic,
configuration, data, logs.

We are getting too philosophic here...

Avi



From michael at knox.net.nz  Fri Mar 31 03:03:49 2006
From: michael at knox.net.nz (Michael J Knox)
Date: Fri, 31 Mar 2006 15:03:49 +1200
Subject: Fedora's way forward
In-Reply-To: <442C5FA1.5050506@knox.net.nz>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
Message-ID: <442C9C15.1090601@knox.net.nz>

Michael J Knox wrote:
> sean wrote:
>> On Fri, 31 Mar 2006 00:20:25 +0200
>> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>>
>>> Please speak for yourself and not on behalve of the entire Fedora 
>>> Community. Which Sean are you anyway? I can't find much on you and 
>>> Fedora, I otoh maintain many FE packages and use my full name.
>>>
>>> I for one wouldn't mind pointers and even install help to (100% 
>>> legally ok) proprietary software if this will significantly boost the 
>>> end user experience.
>>>
>>> With this said I do believe that we should be carefull with this, if 
>>> there is a free tool which does 95% of the job, then we should not 
>>> include links to proprietary alternatives. There is however no free 
>>> tool which will allow people to access all those mp3 files from for 
>>> example www.magnatune.com.
>>
>> Even if you wouldn't mind it, it's against the stated goals of the 
>> project.   Everyone has a perference one way or the other, some wouldn't
>> mind, some would.   That's why the objectives of the project were
>> very carefully laid out.  Please see Rahul's recent post if you think 
>> my interpretation of the basic premise of the Fedora project is wrong.
>>
>> Besides, adding third party repositories is already easy and getting 
>> easier all the time.
>>
> 
> Since it is pretty clear that Fedora Core will not accommodate 3rd party 
> closed source applications, why don't those that would have like to have 
> this get together and make a solution?
> 
> http://easylinux.info/wiki/Fedora_fc5
> 
> The above link is a prime example of how this subject could be 
> approached (its still very rough, but a good start). Add in some support 
> from the pre existing 3rd party repo guys and you could have a winning 
> solution.
> 
> There is obviously no single silver bullet for this issue, but instead 
> of theorizing about what Fedora should/shouldn't/can/won't/etc do, why 
> don't those that have a common interest stand up to the plate and work 
> on the issue outside of Fedora Core?
> 
> Perhaps Fedora can meet the effort by providing a link or something like 
> that to the project.
> 
> Just a thought.
> 
> Michael
> 

After looking at the link I gave closer, I noticed this:

http://easylinux.info/wiki/Fedora_frog

This is a script that installs and sets up a lot of the things people 
are looking for.

How about we work on/from/with that? Its certainly a start.

Michael



From esr at thyrsus.com  Fri Mar 31 04:45:20 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 30 Mar 2006 23:45:20 -0500
Subject: Fedora's way forward
In-Reply-To: <442C9C15.1090601@knox.net.nz>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
Message-ID: <20060331044520.GA18191@thyrsus.com>

Michael J Knox <michael at knox.net.nz>:
> After looking at the link I gave closer, I noticed this:
> 
> http://easylinux.info/wiki/Fedora_frog
> 
> This is a script that installs and sets up a lot of the things people 
> are looking for.
> 
> How about we work on/from/with that? Its certainly a start.

Agreed.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From andy at warmcat.com  Fri Mar 31 06:39:03 2006
From: andy at warmcat.com (Andy Green)
Date: Fri, 31 Mar 2006 07:39:03 +0100
Subject: Fedora's contraband
In-Reply-To: <442C59A9.1010507@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
Message-ID: <442CCE87.1000908@warmcat.com>

Hans de Goede wrote:

> which will allow people to access all those mp3 files from for example 
> www.magnatune.com.

Magnatune has some liberally licensed music, but so does Jamendo:

http://www.jamendo.com

Here we see for each artist and track, eg

http://www.jamendo.com/uk/album/94/

the option to stream and download in OGG as well as MP3.  My point is 
not that therefore it is not painful to lack MP3, but that a solution 
can come from either end.

I get annoyed when I see people elsewhere wave their hands about DRM and 
exclaim that it's on no consequence because some teenager will crack it. 
  What they're really saying is they are happy to have unknown young 
people risk their liberty and their (or their parents' house) so they 
can continue to have the content they want on the terms they want.  It 
seems to me we discuss something of the same here, it's okay if Livna or 
some other people will provide dangerous contraband so long as no risk 
comes back on the people that want to consume it.

Whoever is getting put in the position of providing these things in a 
tacitly-official way may face much more risk of getting hit by 
chair-throwing monkeys because of that small change, it seems to the 
pile of dagger-words on the thread like 'zealot' we should add 'ethical'.

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

From perbj at sbcglobal.net  Fri Mar 31 07:01:56 2006
From: perbj at sbcglobal.net (Per Bjornsson)
Date: Thu, 30 Mar 2006 23:01:56 -0800
Subject: Fedora's way forward
In-Reply-To: <1143732360.5600.412.camel@pmac.infradead.org>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<1143694224.2250.5.camel@localhost.localdomain>
	<1143732360.5600.412.camel@pmac.infradead.org>
Message-ID: <1143788517.14311.3.camel@localhost.localdomain>

On Thu, 2006-03-30 at 16:26 +0100, David Woodhouse wrote:
> On Wed, 2006-03-29 at 20:50 -0800, Per Bjornsson wrote:
> > Unfortunately it's probably not that easy to do something legal about
> > Flash - at least if you want it to make sound... Doesn't Flash use MP3
> > for audio? And what is the video format used in recent Flash versions?
> 
> Any sane flash player will use gstreamer for audio, surely?

Heh. Maybe you'd think so. Or perhaps Gnash isn't all that sane...
http://www.gnu.org/software/gnash/manual/gnash.html#codedepend doesn't
make it sound like Gnash does anything like that. IMHO, that's pretty
much why swfdec is a much more promising solution than Gnash.

/Per




From j.w.r.degoede at hhs.nl  Fri Mar 31 07:01:25 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 31 Mar 2006 09:01:25 +0200
Subject: Fedora's way forward
In-Reply-To: <BAYC1-PASMTP0599CCE7A0CDAD49C9EDC4AED60@CEZ.ICE>
References: <20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>	<442C62DF.7010800@knox.net.nz>	<1143760541.2157.2.camel@scrappy.miketc.com>	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>	<1143761274.2157.9.camel@scrappy.miketc.com>	<20060330235753.GC15963@thyrsus.com>
	<BAYC1-PASMTP0599CCE7A0CDAD49C9EDC4AED60@CEZ.ICE>
Message-ID: <442CD3C5.1030500@hhs.nl>



sean wrote:
> On Thu, 30 Mar 2006 18:57:53 -0500
> "Eric S. Raymond" <esr at thyrsus.com> wrote:
> 
>> The technology isn't the hard part.  The hard part is accepting that
>> 100% free software dogmatism is not good enough as a guide to action,
>> because all dogma does is shut your brain down.  And that what
>> ordinary users want to do with their computers actually matters.
>>
>> If we can get our brains that far along the path, the tech and the
>> money and the lawyers are all solvable problems.
> 
> Being able to have your needs met by open source software alone 
> isn't dogmatism, it's a reality for many people.  They have every
> right to a distribution specifically designed for their needs; just
> as Fedora is.
> 
> People who want to add proprietary repositories on top of Fedora 
> already  do so without much trouble.   Your desire to step over that
> last inch isn't based on pragmatism but rather your dogmatism
> about the proper way to world domination.
> 
> Your dream that Linux is just a few binary modules away from world 
> domination is such a pipe dream it just isn't worth tarnishing the 
> premier open source distribution over.
> 
> If you can get your brain that far a long, it would be nice.
> 
> Sean
> 

Sean,

Speaking only for myself: I'm getting rather tired of your zealot stance 
in this discussion, especially since your contribution to Fedora seems 
to consist of only hot air aka noise in discussions like this. When a 
fellow active contributer takes a stance like this I tend to listen 
seriously, contributers are the ones that make Fedora, so they should be 
the ones who decide what go in. Legal issues of course take precedence, 
but you opinion does not and yes I know there are active contributers 
who side with you, but those are perfectly capable of speaking for 
themselves.

Now if you really want to help Fedora start contributing Documentation, 
Translations, Fedora Extra Packages, etc.

Regards,

Hans



From j.w.r.degoede at hhs.nl  Fri Mar 31 07:03:24 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 31 Mar 2006 09:03:24 +0200
Subject: Fedora's way forward
In-Reply-To: <1143788517.14311.3.camel@localhost.localdomain>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>	<20060328104659.GI12588@devserv.devel.redhat.com>	<1143651293.5600.228.camel@pmac.infradead.org>	<1143694224.2250.5.camel@localhost.localdomain>	<1143732360.5600.412.camel@pmac.infradead.org>
	<1143788517.14311.3.camel@localhost.localdomain>
Message-ID: <442CD43C.7010903@hhs.nl>



Per Bjornsson wrote:
> On Thu, 2006-03-30 at 16:26 +0100, David Woodhouse wrote:
>> On Wed, 2006-03-29 at 20:50 -0800, Per Bjornsson wrote:
>>> Unfortunately it's probably not that easy to do something legal about
>>> Flash - at least if you want it to make sound... Doesn't Flash use MP3
>>> for audio? And what is the video format used in recent Flash versions?
>> Any sane flash player will use gstreamer for audio, surely?
> 
> Heh. Maybe you'd think so. Or perhaps Gnash isn't all that sane...
> http://www.gnu.org/software/gnash/manual/gnash.html#codedepend doesn't
> make it sound like Gnash does anything like that. IMHO, that's pretty
> much why swfdec is a much more promising solution than Gnash.
> 

Actually gnash does use gstreamer, I guess that page is out of date. 
Also gnash gets a lot of active development and they are almost ready 
for the first plugin release, so my money is on gnash :)


Regards,

Hans



From j.w.r.degoede at hhs.nl  Fri Mar 31 07:15:32 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 31 Mar 2006 09:15:32 +0200
Subject: Fedora's way forward
In-Reply-To: <20060331044520.GA18191@thyrsus.com>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>
	<442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com>
Message-ID: <442CD714.2030504@hhs.nl>



Eric S. Raymond wrote:
> Michael J Knox <michael at knox.net.nz>:
>> After looking at the link I gave closer, I noticed this:
>>
>> http://easylinux.info/wiki/Fedora_frog
>>
>> This is a script that installs and sets up a lot of the things people 
>> are looking for.
>>
>> How about we work on/from/with that? Its certainly a start.
> 
> Agreed.

No this is way wrong:
-it drags in mscorefont which is atleast a legal gray area
-it enables all repos under the sun causing repo conflict nightmare,
  I've had to help many new Linux users fix their systems after following
  great advise like this.
-and does all kind of other evil


Lets get back on track here, the problem ESR brought up was: Fedora 
lacks good multimedia playback. The reaction was a mix of:
-unfortunatly we can't provide that
-we can't provide that and we don't want to unless we can in a 100% open
  way
-we can provide that out of the box, and legally we can't ever provide
  it 100% open (livna is not legal in the states), but we could come some
  way using gratis propietary stuff which can be downloaded

My stance is:
-yes better multimedia support would be good
-yes Fedora must stay 100% opensource and redistributable etc
-Fedore should not encourage use of propietary formats but it shouldn't
  make it impossble either.


My Conclusion:

We should provide a mechanism where if a user tries to play an 
unsupported format, we look up the format in an ondisk (no phoning home 
please) tabel and see if there is a gratis and legal (even in the 
states!) downloadable codec in the tabel, if there is such a beast, then 
_help_ the user install it.

Notting more and notting less, so we wont be telling them to use mp3, 
nor will we be claiming support, but if a users tries it we help him, 
now how can helping a user accomplish what he is trying todo ever be bad?

Another take on this, I'm a big fan of free software because of the 
freedom it gives me, thats what this is all about isn't it, freedom!
Doesn't that include the freedom to use proprietary software when I want 
to? It seems that there are people here who would like to even forbid 
the use of proprietary software if they could and since then can't they 
atleast want to make it as hard to use as possible, this is BAD as it 
hurts other peoples freedom!

Regards,

Hans



From perbj at sbcglobal.net  Fri Mar 31 07:20:14 2006
From: perbj at sbcglobal.net (Per Bjornsson)
Date: Thu, 30 Mar 2006 23:20:14 -0800
Subject: Fedora's way forward
In-Reply-To: <442CD43C.7010903@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<1143694224.2250.5.camel@localhost.localdomain>
	<1143732360.5600.412.camel@pmac.infradead.org>
	<1143788517.14311.3.camel@localhost.localdomain>
	<442CD43C.7010903@hhs.nl>
Message-ID: <1143789614.14311.8.camel@localhost.localdomain>

On Fri, 2006-03-31 at 09:03 +0200, Hans de Goede wrote:

> Actually gnash does use gstreamer, I guess that page is out of date. 
> Also gnash gets a lot of active development and they are almost ready 
> for the first plugin release, so my money is on gnash :)

Oh, that's awesome! My apologies for spreading misinformation... Good to
hear that the developers realized that a direct dependency on MAD isn't
such a hot idea.

/Per




From sundaram at fedoraproject.org  Fri Mar 31 07:26:43 2006
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 31 Mar 2006 12:56:43 +0530
Subject: Fedora's way forward
In-Reply-To: <442CD714.2030504@hhs.nl>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com>  <442CD714.2030504@hhs.nl>
Message-ID: <1143790003.3802.769.camel@sundaram.pnq.redhat.com>

On Fri, 2006-03-31 at 09:15 +0200, Hans de Goede wrote:
>  It seems that there are people here who would like to even forbid 
> the use of proprietary software if they could and since then can't they 
> atleast want to make it as hard to use as possible, this is BAD as it 
> hurts other peoples freedom!


Since you refer to people here, Can you point me to where you infer that
from? You are arguing (unnecessarily) about things nobody is disagreeing
with as far as I can see. 


Rahul



From michael at knox.net.nz  Fri Mar 31 07:25:52 2006
From: michael at knox.net.nz (Michael J Knox)
Date: Fri, 31 Mar 2006 19:25:52 +1200
Subject: Fedora's way forward
In-Reply-To: <442CD714.2030504@hhs.nl>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>	<442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
Message-ID: <442CD980.4040800@knox.net.nz>

Hans de Goede wrote:

>
>
> Eric S. Raymond wrote:
>
>> Michael J Knox <michael at knox.net.nz>:
>>
>>> After looking at the link I gave closer, I noticed this:
>>>
>>> http://easylinux.info/wiki/Fedora_frog
>>>
>>> This is a script that installs and sets up a lot of the things 
>>> people are looking for.
>>>
>>> How about we work on/from/with that? Its certainly a start.
>>
>>
>> Agreed.
>
>
> No this is way wrong:
> -it drags in mscorefont which is atleast a legal gray area
> -it enables all repos under the sun causing repo conflict nightmare,
>  I've had to help many new Linux users fix their systems after following
>  great advise like this.
> -and does all kind of other evil
>
>
> Lets get back on track here, the problem ESR brought up was: Fedora 
> lacks good multimedia playback. The reaction was a mix of:
> -unfortunatly we can't provide that
> -we can't provide that and we don't want to unless we can in a 100% open
>  way
> -we can provide that out of the box, and legally we can't ever provide
>  it 100% open (livna is not legal in the states), but we could come some
>  way using gratis propietary stuff which can be downloaded
>
> My stance is:
> -yes better multimedia support would be good
> -yes Fedora must stay 100% opensource and redistributable etc
> -Fedore should not encourage use of propietary formats but it shouldn't
>  make it impossble either.
>
>
> My Conclusion:
>
> We should provide a mechanism where if a user tries to play an 
> unsupported format, we look up the format in an ondisk (no phoning 
> home please) tabel and see if there is a gratis and legal (even in the 
> states!) downloadable codec in the tabel, if there is such a beast, 
> then _help_ the user install it.
>
> Notting more and notting less, so we wont be telling them to use mp3, 
> nor will we be claiming support, but if a users tries it we help him, 
> now how can helping a user accomplish what he is trying todo ever be bad?
>
> Another take on this, I'm a big fan of free software because of the 
> freedom it gives me, thats what this is all about isn't it, freedom!
> Doesn't that include the freedom to use proprietary software when I 
> want to? It seems that there are people here who would like to even 
> forbid the use of proprietary software if they could and since then 
> can't they atleast want to make it as hard to use as possible, this is 
> BAD as it hurts other peoples freedom!
>
> Regards,
>
> Hans
>
I didn't say this was "it", I said it was a _start_ , its an _example_ 
of what someone is _already_ doing instead of endless bitching.

The point was for people with a common interest work together on 
something that provided a solution that will make people happy.

Plenty of Fedora/RedHat folks have clearly stated that they will not be 
adding _any_ mechanisms to Fedora Core to enable closed source apps to 
be installed.

So, step back, look at my suggestion and treat is as an _idea_ not a 
_literal_

Michael



From esr at thyrsus.com  Fri Mar 31 07:30:04 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 02:30:04 -0500
Subject: Fedora's way forward
In-Reply-To: <442CD714.2030504@hhs.nl>
References: <442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
Message-ID: <20060331073004.GA19415@thyrsus.com>

Hans de Goede <j.w.r.degoede at hhs.nl>:
> Another take on this, I'm a big fan of free software because of the 
> freedom it gives me, thats what this is all about isn't it, freedom!
> Doesn't that include the freedom to use proprietary software when I want 
> to?

I think so.  I defend other peoples' right to make the choices they wish,
as long as those choices don't involve force or fraud.  Even when I
disagree with the choice.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jspaleta at gmail.com  Fri Mar 31 07:56:52 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 31 Mar 2006 02:56:52 -0500
Subject: Fedora's way forward
In-Reply-To: <442CD714.2030504@hhs.nl>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
Message-ID: <604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>

On 3/31/06, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> We should provide a mechanism where if a user tries to play an
> unsupported format, we look up the format in an ondisk (no phoning home
> please) tabel and see if there is a gratis and legal (even in the
> states!) downloadable codec in the tabel, if there is such a beast, then
> _help_ the user install it.

Why should media formts be singled out for this special treatment? Why
not build a table of potentially every conceivable piece of
functionality that someone might ever have a need to install a closed
source software solution for?

> Another take on this, I'm a big fan of free software because of the
> freedom it gives me, thats what this is all about isn't it, freedom!
>Doesn't that include the freedom to use proprietary software when I want
> to?

Sure... go ahead and google for whatever proprietary software you want
and install what you find.  I really don't see why proprietary media
formasts should get special treatment of the vast space of proprietary
software you have the freedom to attempt to install and use. What's
next? You are going to be asking for fedora to provide as simplified
solution to find and install proprietary crap that runs under wine?
There's a hell of alot of freeware junk out there that probably runs
under wine. shall we make it as simple to find all that crap from
inside fedora like you want to do with media formats?  Hell.. maybe we
can contract with download.com and incude download.com's entire
searchable database of freeware/demoware inside fedora so people can
find stuff to run inside wine.

> It seems that there are people here who would like to even forbid
> the use of proprietary software if they could and since then can't they
> atleast want to make it as hard to use as possible, this is BAD as it
> hurts other peoples freedom!

Cut the hyperbole. There is a big difference between actively making
it harder and not spending time on it because there is other more
worthwhile things to do which actually feedback into open development.


-jef"fedora core 8: now with google!"spaleta



From j.w.r.degoede at hhs.nl  Fri Mar 31 08:10:39 2006
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 31 Mar 2006 10:10:39 +0200
Subject: Fedora's way forward
In-Reply-To: <604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>
	<442C9C15.1090601@knox.net.nz>	<20060331044520.GA18191@thyrsus.com>
	<442CD714.2030504@hhs.nl>
	<604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
Message-ID: <442CE3FF.8010308@hhs.nl>



Jeff Spaleta wrote:
> On 3/31/06, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>> We should provide a mechanism where if a user tries to play an
>> unsupported format, we look up the format in an ondisk (no phoning home
>> please) tabel and see if there is a gratis and legal (even in the
>> states!) downloadable codec in the tabel, if there is such a beast, then
>> _help_ the user install it.
> 
> Why should media formts be singled out for this special treatment?

Because we cannot offer _free_ replacements like we do for most other 
application wishes people might have because of the patent mess!

>> Another take on this, I'm a big fan of free software because of the
>> freedom it gives me, thats what this is all about isn't it, freedom!
>> Doesn't that include the freedom to use proprietary software when I want
>> to?
> 
> Sure... go ahead and google for whatever proprietary software you want
> and install what you find.  I really don't see why proprietary media
> formasts should get special treatment of the vast space of proprietary
> software you have the freedom to attempt to install and use.

See above.

>> It seems that there are people here who would like to even forbid
>> the use of proprietary software if they could and since then can't they
>> atleast want to make it as hard to use as possible, this is BAD as it
>> hurts other peoples freedom!
> 
> Cut the hyperbole. There is a big difference between actively making
> it harder and not spending time on it because there is other more
> worthwhile things to do which actually feedback into open development.

Nobody is asking anybody to spend time on it there are some people (Me, 
ESR) who are willing to spend time on this (for patent encumbered widely 
used media formats, see above). The problem is that before I start 
spending time on this I want to have a certain amount of assurance that 
if I come up with a nice and legal and 100% _free_ auto codec downloader 
for this it has a descent chance of getting included into Fedora. Heck 
even this discussion is taking way to much time, time I'd rather spent 
fixing dia and unorphaning it.

Regards,

Hans



From andy at warmcat.com  Fri Mar 31 08:20:57 2006
From: andy at warmcat.com (Andy Green)
Date: Fri, 31 Mar 2006 09:20:57 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060330215934.GE14444@thyrsus.com>
References: <20060328155740.GC25098@thyrsus.com>	<20060328105912.29cad8e0.seanlkml@sympatico.ca>	<20060328163215.GA25428@thyrsus.com>	<20060328175608.GA24725@devserv.devel.redhat.com>	<20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>	<20060329010235.GA3395@thyrsus.com>	<20060329142659.GB1376783@hiwaay.net>	<20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com> <20060330215934.GE14444@thyrsus.com>
Message-ID: <442CE669.2020107@warmcat.com>

Eric S. Raymond wrote:
> Andy Green <andy at warmcat.com>:
>>> I don't have the money or the lawyers to pull it off.  This sort of thing
>>> is why we have commercial partners with office buidings.
>> If you look a bit further in that direction you'll see you're asking 
>> RHAT shareholders to take risks you aren't willing to take yourself.
> 
> Yes, I am.  It's a business decision. Do they want significant desktop market
> share?  If so, they have to do this thing.

$THIS_THING is a moving target.  Shortly movie download stores with 
encrypted HDTV files that require a signed Windows driver stack backed 
by TPM will set the bar for you if you define what is needed as 
"whatever Windows can do".  And then if you go there you'll find patent 
attacks and various ugly laws paid for by the movie studios to really 
cream you.

Then there's this:

http://www.no-lobbyists-as-such.com/florian-mueller-blog/ballmer-linux/

For Ballmer Linux is synonymous with RHAT and NOVL.  I think what to do 
about these proprietary and encumbered formats is indeed a 'business 
decision' for RHAT and they seem to be on top of it.

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

From buildsys at redhat.com  Fri Mar 31 08:22:25 2006
From: buildsys at redhat.com (Build System)
Date: Fri, 31 Mar 2006 03:22:25 -0500
Subject: rawhide report: 20060331 changes
Message-ID: <200603310822.k2V8MPqh004149@porkchop.devel.redhat.com>

New package hesinfo
	Command-line Hesiod client.


 
Updated Packages:

NetworkManager-0.6.2-1.fc6
--------------------------
* Thu Mar 30 2006 Dan Williams <dcbw at redhat.com> - 0.6.2-1
- Update to 0.6.2:
    * Fix various WPA-related bugs
    * Clean up leaks
    * Increased DHCP timeout to account for slow DHCP servers, or STP-enabled
        switches
    * Allow applet to reconnect on dbus restarts
    * Add "Dynamic WEP" support
    * Allow hiding of password/key entry text
    * More responsive connection switching

bind-30:9.3.2-16.FC6
--------------------
* Thu Mar 30 2006 Jason Vas Dias <jvdias at redhat.com> - 30:9.3.2-16
- fix bug 187286: 
     prevent host(1) printing duplicate 'is an alias for' messages
     for the default AAAA and MX lookups as well as for the A lookup
     (it now uses the CNAME returned for the A lookup for the AAAA and MX lookups).
     This is upstream bug #15702 fixed in the unreleased bind-9.3.3
- fix bug 187333: fix SOURCE24 and SOURCE25 transposition

* Wed Mar 29 2006 Jason Vas Dias <jvdias at redhat.com> - 30:9.3.2-14
- fix bug 186577: remove -L/usr/lib from libbind.pc and more .spec file cleanup
- add '%doc' sample configuration files in /usr/share/doc/bind*/sample
- rebuild with new gcc and glibc

* Wed Mar 22 2006 Jason Vas Dias <jvdias at redhat.com> - 30:9.3.2-12
- fix typo in initscript
- fix Requires(post): policycoreutils in sub-packages

cups-1:1.2-0.2.rc1.3
--------------------
* Wed Mar 29 2006 Tim Waugh <twaugh at redhat.com> 1:1.2-0.2.rc1.3
- Fix group list of non-root backends (STR #1521, bug #186954).

evolution-2.6.0-2
-----------------
* Thu Mar 30 2006 Caolan McNamara <caolanm at redhat.com> - 2.6.0-2
- rebuild against reverted pilot-link
- disable evolution-2.5.4-fix-conduits.patch for reversion to pilot-link 0.11.8

hesiod-3.1.0-3
--------------
* Thu Mar 30 2006 Nalin Dahyabhai <nalin at redhat.com> - 3.1.0-3
- no, we really did need that patch

* Thu Mar 30 2006 Nalin Dahyabhai <nalin at redhat.com> - 3.1.0-2
- drop a no-longer-needed patch for detecting libresolv properly

* Thu Mar 30 2006 Nalin Dahyabhai <nalin at redhat.com> - 3.1.0-1
- update to 3.1.0 (#187372)

kernel-2.6.16-1.2106_FC6
------------------------
* Thu Mar 30 2006 Dave Jones <davej at redhat.com>
- 2.6.16-git18

libdrm-2.0.1-1
--------------
* Thu Mar 30 2006 Adam Jackson <ajackson at redhat.com> - 2.0.1-1
- Bump to libdrm 2.0.1 from upstream.

mc-1:4.6.1a-13
--------------
* Thu Mar 30 2006 Jindrich Novy <jnovy at redhat.com> 4.6.1a-13
- comment fallback to use only dd in FISH upload patch
- drop .promptfix patch so that prompt is displayed only
  once while in panels

mkinitrd-5.0.33-1
-----------------
* Thu Mar 30 2006 Peter Jones <pjones at redhat.com> - 5.0.33-1
- fix unbalanced pushd in mkinitrd (patch from Pete Zaitcev, bz# 185822)
- add "cond" command for simple conditionals (bz# 182938)
- add "status" command to see/set the exit status for testing
- add "--remove-args" and "--update" args for new-kernel-pkg (patch from
  Don Zickus, bz# 183917)

module-init-tools-3.2.2-1
-------------------------
* Thu Mar 30 2006 Harald Hoyer <harald at redhat.com> 3.2.2-1
- version 3.2.2

net-tools-1.60-65
-----------------
* Thu Mar 30 2006 Radek Vok??l <rvokal at redhat.com> - 1.60-65
- add note to ifconfig(8) about supported format for IPv4 addresses (#176661)

* Thu Mar 16 2006 Radek Vok??l <rvokal at redhat.com> - 1.60-64
- remove duplicate arp entries (#185604)

* Thu Feb 23 2006 Radek Vok??l <rvokal at redhat.com> - 1.60-63
- show inodes in netstat (#180974)

nkf-2.06-1.fc6
--------------
* Thu Mar 30 2006 Akira TAGOH <tagoh at redhat.com> - 2.06-1
- New upstream release.

procmail-3.22-17
----------------
* Thu Mar 30 2006 Peter Vrabec <pvrabec at redhat.com> 3.22-17
- fix truncation of mailbox when running into a disk quota or a
  full partition. Patch from Solar Designer.

samba-0:3.0.22-2
----------------

scim-anthy-1.0.0-1.fc6
----------------------
* Thu Mar 30 2006 Akira TAGOH <tagoh at redhat.com> - 1.0.0-1
- New upstream release.
  - can input numerals when the candidate window doesn't appear. (#185934)
- scim-anthy-symbol-style.patch: removed.
- add Requires: gettext-devel
- run aclocal and autoconf as well to regenerate Makefile properly.

* Fri Mar 17 2006 Akira TAGOH <tagoh at redhat.com> - 0.9.0-3
- scim-anthy-symbol-style.patch: applied a backport patch from upstream CVS to
  add an UI for the symbol style. (#178400)

* Fri Feb 10 2006 Jesse Keating <jkeating at redhat.com> - 0.9.0-2.fc5.1
- bump again for double-long bug on ppc(64)

selinux-policy-2.2.28-3
-----------------------
* Thu Mar 30 2006 Dan Walsh <dwalsh at redhat.com> 2.2.28-3
- Allow automount and dbus to read cert files

* Thu Mar 30 2006 Dan Walsh <dwalsh at redhat.com> 2.2.28-2
- Fix ftp policy
- Fix secadm running of auditctl

swig-1.3.29-0
-------------
* Tue Mar 28 2006 Jitka Kudrnacova <jkudrnac at redhat.com> - 1.3.29-0
- update to swig-1.2.29-0

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
	gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
	gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
	kdepim - 6:3.5.1-1.2.i386 requires libpisock.so.9



Broken deps for ia64
----------------------------------------------------------
	kdepim - 6:3.5.1-1.2.ia64 requires libpisock.so.9()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	kdepim - 6:3.5.1-1.2.ppc requires libpisock.so.9



Broken deps for ppc64
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	kdepim - 6:3.5.1-1.2.ppc64 requires libpisock.so.9()(64bit)
	struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5



Broken deps for s390
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
	rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
	rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
	struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
	xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5



Broken deps for s390x
----------------------------------------------------------
	avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
	castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
	geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
	hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
	jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
	jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
	rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
	rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
	struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
	struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
	velocity - 1.4-3jpp_4fc.noarch requires servletapi5
	xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
	gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
	kdepim - 6:3.5.1-1.2.x86_64 requires libpisock.so.9()(64bit)








From jspaleta at gmail.com  Fri Mar 31 08:36:12 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 31 Mar 2006 03:36:12 -0500
Subject: Fedora's way forward
In-Reply-To: <442CE3FF.8010308@hhs.nl>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
	<604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
	<442CE3FF.8010308@hhs.nl>
Message-ID: <604aa7910603310036o2f9cce85n224cc33aecdeba6c@mail.gmail.com>

On 3/31/06, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> Because we cannot offer _free_ replacements like we do for most other
> application wishes people might have because of the patent mess!

Are you suggesting that media codecs are the only examples of patent
encumbered functionally useful software? You're just going to leave
all those poor people who want ntfs filesystem out in the cold without
helping them out too?

-jef



From esr at thyrsus.com  Fri Mar 31 08:41:10 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 03:41:10 -0500
Subject: Fedora's way forward
In-Reply-To: <604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
References: <442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
	<604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
Message-ID: <20060331084110.GA19993@thyrsus.com>

Jeff Spaleta <jspaleta at gmail.com>:
> Why should media formts be singled out for this special treatment?

Because they're especially important for boosting our rate of adoption
among nontechnical users.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From esr at thyrsus.com  Fri Mar 31 08:51:30 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 03:51:30 -0500
Subject: 'Commercial Partners'
In-Reply-To: <442CE669.2020107@warmcat.com>
References: <20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
	<20060329142659.GB1376783@hiwaay.net>
	<20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
Message-ID: <20060331085130.GB19993@thyrsus.com>

Andy Green <andy at warmcat.com>:
> >Yes, I am.  It's a business decision. Do they want significant desktop 
> >market share?  If so, they have to do this thing.
> 
> $THIS_THING is a moving target. 

Yes. it certainly is.  In a few years, once we solve this problem, I
expect to be back here trying to kick certain people out of their
dogmatic slumbers with respect to the *next* market-share blocker.

>                                 Shortly movie download stores with 
> encrypted HDTV files that require a signed Windows driver stack backed 
> by TPM will set the bar for you if you define what is needed as 
> "whatever Windows can do".

No, I define it as "what nontechnical users will consider us useless
wankers if we don't do".  

Which doesn't include TPM, because users haven't accepted that devil's
bargain yet.  If the history of DivX and other similar efforts is a
guide, they won't.

In truth, I think we can get away with not supporting WMA.  But no MP3
is a complete laugh-at-those-idiots showstopper.  QuickTime is
somewhere in the middle.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From jspaleta at gmail.com  Fri Mar 31 09:03:32 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 31 Mar 2006 04:03:32 -0500
Subject: Fedora's way forward
In-Reply-To: <20060331084110.GA19993@thyrsus.com>
References: <442AE4DF.700@hhs.nl>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
	<604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
	<20060331084110.GA19993@thyrsus.com>
Message-ID: <604aa7910603310103g6f13aae7t1cc5527a7c0cf9fc@mail.gmail.com>

On 3/31/06, Eric S. Raymond <esr at thyrsus.com> wrote:
> Jeff Spaleta <jspaleta at gmail.com>:
> > Why should media formts be singled out for this special treatment?
>
> Because they're especially important for boosting our rate of adoption
> among nontechnical users.

He was making a "freedom" argument. He wasn't arguing "adoption rate".
 It would help if you made an effort to keep the arguments other
people are making compartmentalized from your own thoughts. I'd
suggest using tomboy and making notes as to how the discussion is
organized.

If you want to keep plugging away at the adoption rate argument
mantra... be my guest.  I've no agenda as to achievable adoption
rates...since we have no adoption metrics for any release of fedora to
inform decision making.  It is in fact quite silly to be making
adoption rate arguments for any feature decision because such
decisions can't actually be tested to see how they impact adoption
rates.  But hey don't let silly thinks like metrics keep you from
feeling this is the most important thing for you to spend time on.


-jef"that's right ntfs is absolutely not something non-technical users
will desire as an enhancement, since the most assuredly don't have a
pre-existing ntfs partiion..which is holding the wma media that they
want to play. Nope I never ever see people trying to deal what that
specific problem...ever...never ever"spaleta



From andy at warmcat.com  Fri Mar 31 09:25:15 2006
From: andy at warmcat.com (Andy Green)
Date: Fri, 31 Mar 2006 10:25:15 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060331085130.GB19993@thyrsus.com>
References: <20060328163215.GA25428@thyrsus.com>	<20060328175608.GA24725@devserv.devel.redhat.com>	<20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>	<20060329010235.GA3395@thyrsus.com>	<20060329142659.GB1376783@hiwaay.net>	<20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com>
Message-ID: <442CF57B.9000001@warmcat.com>

Eric S. Raymond wrote:
> Andy Green <andy at warmcat.com>:
>>> Yes, I am.  It's a business decision. Do they want significant desktop 
>>> market share?  If so, they have to do this thing.
>> $THIS_THING is a moving target. 
> 
> Yes. it certainly is.  In a few years, once we solve this problem, I
> expect to be back here trying to kick certain people out of their
> dogmatic slumbers with respect to the *next* market-share blocker.

To be fair, you seem to want to replace the existing "Free and safe" 
dogma with "do whatever it takes not to look like a useless wanker" 
dogma.  The existing one seems to have better metrics for assessing 
compliance, less danger and greater longer-term stability.

>>                                 Shortly movie download stores with 
>> encrypted HDTV files that require a signed Windows driver stack backed 
>> by TPM will set the bar for you if you define what is needed as 
>> "whatever Windows can do".
> 
> No, I define it as "what nontechnical users will consider us useless
> wankers if we don't do".  

They will want their encrypted Blu-ray and HD-DVD.  They already want 
their DVD now and that has to come by a dangerous contraband.

> Which doesn't include TPM, because users haven't accepted that devil's
> bargain yet.  If the history of DivX and other similar efforts is a
> guide, they won't.

DivX (sans ;-) ) added nothing over a regular DVD.  The wave of HD media 
will I believe see regular Joes accepting serious compromises to have 
it, because it is viscerally compelling.

> In truth, I think we can get away with not supporting WMA.  But no MP3
> is a complete laugh-at-those-idiots showstopper.  

MP3 decode and Flash look like they are safely (ie, no patent attack 
invited) possible with an end-user download.  On WMA, a lot of low-cost 
music stores are selling only encrypted WMA, eg

http://www.tescodownloads.com/

''You will need
Windows 98 Second Edition or above

Windows Media Player 9 or above

If using a digital music player, one that supports Windows Media files 
with Digital Rights Management encryption (DRM 9 or above)

Note
This service is not compatible with Apple iPod''

so lacking WMA is a dealbreaker for such folks.

> QuickTime is somewhere in the middle.

For people who got to trailers.apple.com Quicktime is a dealbreaker, not 
in the middle.

This just illustrates how fuzzy it is to define the distro on a "wanker 
perception" scale rather than objective criteria.  Just like real life, 
someone somewhere will always think you are a useless wanker.  Better to 
live your life according to your own principles than attempt to please 
everybody and end up miserable.

FWIW Linux is creeping in at the bottom end despite its supposed lacks. 
  This is a relatively new phenomena:

http://www.ebuyer.com/customer/products/index.html?action=c2hvd19wcm9kdWN0X292ZXJ2aWV3&product_uid=89079

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

From pemboa at gmail.com  Fri Mar 31 09:34:31 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 31 Mar 2006 03:34:31 -0600
Subject: Semi-OT: Suggested practices for documenting Python code
Message-ID: <16de708d0603310134w37e8e15exbea1bcea8d5178da@mail.gmail.com>

I would like suggestions from developers here on best practices for properly
documenting python code. Examples of suggested syntax or links would be
nice.

Thank you.

Arthur

--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060331/8c7726b6/attachment.htm>

From ivazquez at ivazquez.net  Fri Mar 31 09:53:30 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Fri, 31 Mar 2006 04:53:30 -0500
Subject: Semi-OT: Suggested practices for documenting Python code
In-Reply-To: <16de708d0603310134w37e8e15exbea1bcea8d5178da@mail.gmail.com>
References: <16de708d0603310134w37e8e15exbea1bcea8d5178da@mail.gmail.com>
Message-ID: <1143798810.1420.12.camel@ignacio.lan>

On Fri, 2006-03-31 at 03:34 -0600, Arthur Pemberton wrote:
> I would like suggestions from developers here on best practices for
> properly documenting python code. Examples of suggested syntax or
> links would be nice.

http://www.python.org/dev/peps/pep-0287/

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060331/8d3b223c/attachment.sig>

From alan at redhat.com  Fri Mar 31 10:23:39 2006
From: alan at redhat.com (Alan Cox)
Date: Fri, 31 Mar 2006 05:23:39 -0500
Subject: Fedora's contraband
In-Reply-To: <442CCE87.1000908@warmcat.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl>
	<20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl> <442CCE87.1000908@warmcat.com>
Message-ID: <20060331102339.GA19731@devserv.devel.redhat.com>

On Fri, Mar 31, 2006 at 07:39:03AM +0100, Andy Green wrote:
> Hans de Goede wrote:
> 
> >which will allow people to access all those mp3 files from for example 
> >www.magnatune.com.
> 
> Magnatune has some liberally licensed music, but so does Jamendo:

Magnatune carries ogg too (and for bought albums even FLAC and WAV)



From kloczek at zie.pg.gda.pl  Fri Mar 31 10:27:30 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Fri, 31 Mar 2006 12:27:30 +0200
Subject: rawhide report: 20060331 changes
In-Reply-To: <200603310822.k2V8MPqh004149@porkchop.devel.redhat.com>
References: <200603310822.k2V8MPqh004149@porkchop.devel.redhat.com>
Message-ID: <1143800850.16424.48.camel@kloczek01.pracownicy.zie>

Dnia 31-03-2006, pi? o godzinie 03:22 -0500, Build System napisa?(a):
[..]
> NetworkManager-0.6.2-1.fc6
> --------------------------
> * Thu Mar 30 2006 Dan Williams <dcbw at redhat.com> - 0.6.2-1
> - Update to 0.6.2:
>     * Fix various WPA-related bugs
>     * Clean up leaks
>     * Increased DHCP timeout to account for slow DHCP servers, or
> STP-enabled
>         switches
>     * Allow applet to reconnect on dbus restarts
>     * Add "Dynamic WEP" support
>     * Allow hiding of password/key entry text
>     * More responsive connection switching 

Still this package is broken.
glib subpackage icorectly requires main package.

Index: NetworkManager.spec
===================================================================
RCS file: /cvs/dist/devel/NetworkManager/NetworkManager.spec,v
retrieving revision 1.102
diff -u -r1.102 NetworkManager.spec
--- NetworkManager.spec 17 Mar 2006 04:43:36 -0000      1.102
+++ NetworkManager.spec 31 Mar 2006 10:13:16 -0000
@@ -94,7 +94,6 @@
 %package glib
 Summary: Libraries for adding NetworkManager support to applications
that use glib.
 Group: Development/Libraries
-Requires: %{name} = %{version}-%{release}
 Requires: dbus >= %{dbus_version}
 Requires: dbus-glib >= %{dbus_version}

If glib realy requires manin package generate separated glib and
glib-devel subpackage is useless (better will be merge glib to main and
glib-devel to devel).
Also instead waste of time in %build for generate static libraries and
remove them in %installe better will be add --disable-static to
configure switches (this kind waste of time can be fixed in *MANY*
Fedora spec files).

Index: NetworkManager.spec
===================================================================
RCS file: /cvs/dist/devel/NetworkManager/NetworkManager.spec,v
retrieving revision 1.102
diff -u -r1.102 NetworkManager.spec
--- NetworkManager.spec 17 Mar 2006 04:43:36 -0000      1.102
+++ NetworkManager.spec 31 Mar 2006 10:16:53 -0000
@@ -121,7 +120,12 @@
 %patch2 -p1 -b .device-up

 %build
-%configure --with-named=/usr/sbin/named --with-named-dir=/var/named/data --with-named-user=named --enable-notify=yes
+%configure \
+       --with-named=/usr/sbin/named \
+       --with-named-dir=/var/named/data \
+       --with-named-user=named \
+       --enable-notify=yes \
+       --disable-static
 make


@@ -130,10 +134,7 @@
 make install DESTDIR=$RPM_BUILD_ROOT
 %find_lang %{name}
 %{__rm} -f $RPM_BUILD_ROOT%{_bindir}/NMLoadModules
-%{__rm} -f $RPM_BUILD_ROOT%{_libdir}/libnm_glib.la
-%{__rm} -f $RPM_BUILD_ROOT%{_libdir}/libnm_glib.a
-%{__rm} -f $RPM_BUILD_ROOT%{_libdir}/libnm-util.la
-%{__rm} -f $RPM_BUILD_ROOT%{_libdir}/libnm-util.a
+%{__rm} -f $RPM_BUILD_ROOT%{_libdir}/*.la
 %{__cp} test/nm-tool $RPM_BUILD_ROOT%{_bindir}/

 %clean

kloczek



From esr at thyrsus.com  Fri Mar 31 10:35:36 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 05:35:36 -0500
Subject: 'Commercial Partners'
In-Reply-To: <442CF57B.9000001@warmcat.com>
References: <20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
	<20060329142659.GB1376783@hiwaay.net>
	<20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
Message-ID: <20060331103536.GA21302@thyrsus.com>

Andy Green <andy at warmcat.com>:
> The existing one seems to have better metrics for assessing 
> compliance, less danger and greater longer-term stability.

Well, maybe.  Unless the consequence is that we never reach the mass
market at all, in which case Very Bad Things are likely to happen down
the road.  Like, no video cards we can actually use at above VESA
resolution.

> They will want their encrypted Blu-ray and HD-DVD. 

We don't know that yet.  A ruinous format war that turns consumers 
off both still looks like a fairly likely outcome.

>                                    They already want 
> their DVD now and that has to come by a dangerous contraband.

True.  I don't know how to solve that problem.
 
> MP3 decode and Flash look like they are safely (ie, no patent attack 
> invited) possible with an end-user download.

Yes.

> so lacking WMA is a dealbreaker for such folks.

How many of them do you think there are, as percentage
of the population?
 
> >QuickTime is somewhere in the middle.
> 
> For people who got to trailers.apple.com Quicktime is a dealbreaker, not 
> in the middle.

There can't be a lot of those, as Windows doesn't do QuickTime (at 
least it didn't last I checked).  That holds the damage down to 5% or so.

> This just illustrates how fuzzy it is to define the distro on a "wanker 
> perception" scale rather than objective criteria.

Still, the consequences of failure to do so would be a serious problem
in the middle- to long term.  If we can at least hold the number of
nontechie users who find Linux useless down to 1 in 10 or so we can
avoid this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From kloczek at zie.pg.gda.pl  Fri Mar 31 10:41:03 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Fri, 31 Mar 2006 12:41:03 +0200
Subject: rawhide report: 20060331 changes
In-Reply-To: <1143800850.16424.48.camel@kloczek01.pracownicy.zie>
References: <200603310822.k2V8MPqh004149@porkchop.devel.redhat.com>
	<1143800850.16424.48.camel@kloczek01.pracownicy.zie>
Message-ID: <1143801663.16424.52.camel@kloczek01.pracownicy.zie>

Dnia 31-03-2006, pi? o godzinie 12:27 +0200, Tomasz K?oczko napisa?(a):
[..]
> --- NetworkManager.spec 17 Mar 2006 04:43:36 -0000      1.102
> +++ NetworkManager.spec 31 Mar 2006 10:13:16 -0000
> @@ -94,7 +94,6 @@
>  %package glib
>  Summary: Libraries for adding NetworkManager support to applications
> that use glib.
>  Group: Development/Libraries
> -Requires: %{name} = %{version}-%{release}
>  Requires: dbus >= %{dbus_version}
>  Requires: dbus-glib >= %{dbus_version}

I see next thing whuich can be fixed in above.
dbus-glib have "Requires: %name = %{version}-%{release}" rule.
So in above "Requires: dbus >= %{dbus_version}" line is redundant (also
can be removed).

kloczek




From paul at city-fan.org  Fri Mar 31 10:43:47 2006
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 31 Mar 2006 11:43:47 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060331103536.GA21302@thyrsus.com>
References: <20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>	<20060329010235.GA3395@thyrsus.com>	<20060329142659.GB1376783@hiwaay.net>	<20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
Message-ID: <442D07E3.9040404@city-fan.org>

Eric S. Raymond wrote:
>>> QuickTime is somewhere in the middle.
>> For people who got to trailers.apple.com Quicktime is a dealbreaker, not 
>> in the middle.
> 
> There can't be a lot of those, as Windows doesn't do QuickTime (at 
> least it didn't last I checked).  That holds the damage down to 5% or so.

Windows has done QuickTime for as long as I can remember (many, many years):

http://www.apple.com/quicktime/download/win.html

Paul.



From andy at warmcat.com  Fri Mar 31 11:17:10 2006
From: andy at warmcat.com (Andy Green)
Date: Fri, 31 Mar 2006 12:17:10 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060331103536.GA21302@thyrsus.com>
References: <20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>	<20060329010235.GA3395@thyrsus.com>	<20060329142659.GB1376783@hiwaay.net>	<20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
Message-ID: <442D0FB6.3080600@warmcat.com>

Eric S. Raymond wrote:
> Andy Green <andy at warmcat.com>:
>> The existing one seems to have better metrics for assessing 
>> compliance, less danger and greater longer-term stability.
> 
> Well, maybe.  Unless the consequence is that we never reach the mass
> market at all, in which case Very Bad Things are likely to happen down
> the road.  Like, no video cards we can actually use at above VESA
> resolution.

I don't see any evidence for this for 2D.  The problems all seem to be 
to do with 3D acceleration hardware in the past, present, and presumably 
in the future.  And that in turn, like everything this thread touches, 
seems to come down in the end to patents.

>> They will want their encrypted Blu-ray and HD-DVD. 
> 
> We don't know that yet.  A ruinous format war that turns consumers 
> off both still looks like a fairly likely outcome.

IMO it is too sexy to die, but who knows.

>>                                    They already want 
>> their DVD now and that has to come by a dangerous contraband.
> 
> True.  I don't know how to solve that problem.

There is a licensed player for Linux that can be purchased, but this is 
just another sign of what I refer to below.

>> so lacking WMA is a dealbreaker for such folks.
> 
> How many of them do you think there are, as percentage
> of the population?

Fair and increasing amount.  Both iTunes and the other licensed 
traditional digital music download sites are sending out ONLY locked-up 
content that demands ownership of a Windows or AAPL OS and a portable 
playback device that was created by AAPL or pays license fees to MSFT. 
Every time you hear about a digital download, like the 1 Billion sent 
out from iTunes you're hearing about something that can't be played 
under Linux without being cracked and potentially violating laws in the 
US and Europe.  (They are cracked, it is not a technical problem.)  The 
problem is that having invested in these bogodownloads they act as an 
anchor to the existing OS, assuming the French can't save us.

>>> QuickTime is somewhere in the middle.
>> For people who got to trailers.apple.com Quicktime is a dealbreaker, not 
>> in the middle.
> 
> There can't be a lot of those, as Windows doesn't do QuickTime (at 
> least it didn't last I checked).  That holds the damage down to 5% or so.

As somebody else pointed out it does, but in case you meant 'out of the 
box', then this serves as an illustration of the lure of content, since 
stuff like HDTV res trailers at trailers.apple.com means Quicktime has 
quite good penetration on Windows boxes, I found this perhaps slightly 
dogdy breakdown for 2004

Macromedia?s Flash - 98%
Viewpoint Media Player - 64.3%.  (<-- possible dodginess)
Shockwave - 58.1%
Windows Media Player 9 - 57.5%
RealNetworks RealPlayer - 46.5%
Apple?s QuickTime - 43.1%

http://www.danavan.net/weblog/archives/bye_bye_quicktime.html

People who want that hot content like HDTV new movie trailers (and DVD 
playback) won't be told they shouldn't have it for the reasons you 
earlier deployed against telling people they shouldn't have mp3 -- and 
we can't provide it due to patent licensing.  This is why I said there 
is no end to that path of trying to make everyone happy, and that by 
defining winning as doing that, you can never win.

The basic schism is that you can't have a Free OS under liberal license 
that includes fundamentally proprietary, patent-protected technologies 
in a freely redistributable form unless the patentholders allow it. 
Patentholders like MSFT and AAPL have no motive to allow it, quite the 
opposite.  Patentholders like the DVD consortium are actively monetizing 
their patents in the form of licenses and will call Security if you 
suggest you get one for free that anyone can distribute and copy.  RHAT 
react to this fact by retrenching just behind the red line (as best they 
can assess it) beyond the range of attack and grow the OS outside of 
such patentholder influence as far as possible.

>> This just illustrates how fuzzy it is to define the distro on a "wanker 
>> perception" scale rather than objective criteria.
> 
> Still, the consequences of failure to do so would be a serious problem
> in the middle- to long term.  If we can at least hold the number of
> nontechie users who find Linux useless down to 1 in 10 or so we can
> avoid this.

The is little chance of achieving a 90% proportion of really nontechie 
users who even heard of Linux, let alone regard it as useful.  Quite 
possible 90% of such folks do not quite know what "windows" is. 
However... Linux is hidden away in PVRs and so on that a lot of people 
are using already.  Nokia 770 is another example, I guess many users are 
unaware they use Linux.  Maybe one day soon 90% of people will be using 
Linux daily just outside of the desktop-based paradigm, but they won't 
know it or of it.

-Andy

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

From seanlkml at sympatico.ca  Fri Mar 31 11:14:40 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 06:14:40 -0500
Subject: Fedora's way forward
In-Reply-To: <442CD3C5.1030500@hhs.nl>
References: <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz>
	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>
	<442C62DF.7010800@knox.net.nz>
	<1143760541.2157.2.camel@scrappy.miketc.com>
	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>
	<1143761274.2157.9.camel@scrappy.miketc.com>
	<20060330235753.GC15963@thyrsus.com>
	<BAYC1-PASMTP0599CCE7A0CDAD49C9EDC4AED60@CEZ.ICE>
	<442CD3C5.1030500@hhs.nl>
Message-ID: <BAYC1-PASMTP11D9ECC3C2A05AFB7CE12CAED60@CEZ.ICE>

On Fri, 31 Mar 2006 09:01:25 +0200
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:


> Speaking only for myself: I'm getting rather tired of your zealot stance 
> in this discussion, especially since your contribution to Fedora seems 
> to consist of only hot air aka noise in discussions like this. When a 
> fellow active contributer takes a stance like this I tend to listen 
> seriously, contributers are the ones that make Fedora, so they should be 
> the ones who decide what go in. Legal issues of course take precedence, 
> but you opinion does not and yes I know there are active contributers 
> who side with you, but those are perfectly capable of speaking for 
> themselves.
> 
> Now if you really want to help Fedora start contributing Documentation, 
> Translations, Fedora Extra Packages, etc.

Hans, I have to disagree with most of what you said above.   Perhaps 
you could try to separate the argument from the person making it, even
if you happen to disagree?   If there are specific points you'd like
to debate it would be more useful than trying to dismiss them all
with a single ad hominem attack.  Besides, you seem to have misinterpreted 
the points i've made a bit.  Anyway, if you could try to stick to  the topic 
at hand I think it would be a further contribution from you to Fedora.

Cheers,
Sean



From che666 at gmail.com  Fri Mar 31 11:33:24 2006
From: che666 at gmail.com (Rudolf Kastl)
Date: Fri, 31 Mar 2006 13:33:24 +0200
Subject: Package names in FC5
In-Reply-To: <1143660641.18075.35.camel@vroomfondel.internal.datastacks.com>
References: <200603281356.17155.rkwasny@aurox.org>
	<20060328144218.92792ab4.fedora@wir-sind-cool.org>
	<1143582471.3095.33.camel@vroomfondel.internal.datastacks.com>
	<20060329153748.3ef7bab3.fedora@wir-sind-cool.org>
	<1143660641.18075.35.camel@vroomfondel.internal.datastacks.com>
Message-ID: <e99d27470603310333v77a00590s3a05ff18ff940156@mail.gmail.com>

2006/3/29, Peter Jones <pjones at redhat.com>:
> On Wed, 2006-03-29 at 15:37 +0200, Michael Schwendt wrote:
> > On Tue, 28 Mar 2006 16:47:50 -0500, Peter Jones wrote:
> >
> > > > No pattern. Core package developers can do what they want, and some of
> > > > them still don't seem to care that .fc3 is "newer than" .FC5 in RPM
> > > > version comparison.
> > >
> > > That's a bit of an exaggeration.  It's not that we don't care, it's that
> > > it doesn't matter unless you're doing something *else* really dumb at
> > > the same time as *switching* between those two nomenclatures.
> > >
> > > *yawn*.
> >
> > No need to yawn. :) It has happened before that a package from Core was
> > moved to Extras or vice versa, and then you get the "switching" in updates
> > unless the different packagers agree on a common way.
>
> Ok, but there's a more serious problem there.  If you're moving the
> package from core to extras or vice versa, start with the same spec file
> and only change the parts you actually have to.
>
> If our naming policy for extras says we have to use one particular
> capitalization for a "release" field, then we should fix it.  That's
> just a rule for the sake of having more rules.  It doesn't buy us
> anything.
>
> --
>   Peter
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

well actually while i am also a fan of practicable solutions... either
there are packaging guidelines... or there arent...

if only half of fedora packages are done according to the guidelines i
ask myself why the other half is forced wasting time with doing it.

I see only one particular solution there... either drop the rules in
general... or have the rules apply everywhere.

regards,
Rudolf Kastl



From seanlkml at sympatico.ca  Fri Mar 31 11:35:11 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 06:35:11 -0500
Subject: 'Commercial Partners'
In-Reply-To: <20060331085130.GB19993@thyrsus.com>
References: <20060328163215.GA25428@thyrsus.com>
	<20060328175608.GA24725@devserv.devel.redhat.com>
	<20060328182243.GC26482@thyrsus.com>
	<20060328183933.GA14374@devserv.devel.redhat.com>
	<20060329010235.GA3395@thyrsus.com>
	<20060329142659.GB1376783@hiwaay.net>
	<20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com>
Message-ID: <BAYC1-PASMTP081E1FB4A31E02E98B890EAED60@CEZ.ICE>

On Fri, 31 Mar 2006 03:51:30 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:


> > $THIS_THING is a moving target. 
> 
> Yes. it certainly is.  In a few years, once we solve this problem, I
> expect to be back here trying to kick certain people out of their
> dogmatic slumbers with respect to the *next* market-share blocker.

Don't see any evidence of dogmatic slumbering within Fedora.  Just
a realistic appraisal of what can be provided and what is appropriate
to provide under the very clear objectives of the project.   You seem
to think your goals should be those of the project, but have given
nothing more than a world domination pipe dream as a reason.

There's a worthwhile and valuable group being served well by Fedora.
Those that want or need proprietary solutions aren't stopped from 
getting them, they're a simple download the same as is required
on Windows in many cases.   

There is simply no need to start the Fedora core project down that 
slippery slope of providing or encouraging proprietary solutions.

Sean



From kloczek at zie.pg.gda.pl  Fri Mar 31 11:43:13 2006
From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=)
Date: Fri, 31 Mar 2006 13:43:13 +0200
Subject: Double dare ya, Fedora! And your art sucks!
In-Reply-To: <1143573760.4097.59.camel@pensja.lam.pl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com>
	<e99d27470603280346i7080f31i141f7cefa6adaa17@mail.gmail.com>
	<1143549705.4097.30.camel@pensja.lam.pl>
	<1143569558.10632.41.camel@localhost>
	<1143573760.4097.59.camel@pensja.lam.pl>
Message-ID: <1143805393.16424.62.camel@kloczek01.pracownicy.zie>

Dnia 28-03-2006, wto o godzinie 21:22 +0200, Leszek Matok napisa?(a):
[..]
> This doesn't help if someone wants to make a decoding device with no
> additional cost over what they consider a must. Makers of the $20 MP3
> players/$50 DVD players won't afford it :) Too bad they don't include
> support even though they have a ready-to-use BSD-licensed decoder.

You probably know some widely known OSS sentence:
"Documentation is like sex. When it is good it is very very good. If it
is bad, it is better than nothing."

Use above with s/Documentation/MP3 support in applications/

kloczek




From nicolas.mailhot at laposte.net  Fri Mar 31 11:44:53 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 31 Mar 2006 13:44:53 +0200 (CEST)
Subject: 'Commercial Partners'
In-Reply-To: <442D0FB6.3080600@warmcat.com>
References: <20060328182243.GC26482@thyrsus.com>	<20060328183933.GA14374@devserv.devel.redhat.com>	<20060329010235.GA3395@thyrsus.com>	<20060329142659.GB1376783@hiwaay.net>	<20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com>
Message-ID: <46625.192.54.193.25.1143805493.squirrel@rousalka.dyndns.org>


Le Ven 31 mars 2006 13:17, Andy Green a ?crit :
> Eric S. Raymond wrote:
>> Andy Green <andy at warmcat.com>:
>>> The existing one seems to have better metrics for assessing
>>> compliance, less danger and greater longer-term stability.
>>
>> Well, maybe.  Unless the consequence is that we never reach the mass
>> market at all, in which case Very Bad Things are likely to happen down
>> the road.  Like, no video cards we can actually use at above VESA
>> resolution.
>
> I don't see any evidence for this for 2D.  The problems all seem to be
> to do with 3D acceleration hardware in the past, present, and presumably
> in the future.  And that in turn, like everything this thread touches,
> seems to come down in the end to patents.

No they aren't all related to 3D.
Right now the second DVI head of a radeon card (consumer, not pro card) is
a paperweight, for 3D or 2D. That is, if you stick to open drivers (like
me)

So if you've got a desktop system with two TMDSes, you're out of luck.

-- 
Nicolas Mailhot



From esr at thyrsus.com  Fri Mar 31 11:46:43 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 06:46:43 -0500
Subject: 'Commercial Partners'
In-Reply-To: <442D0FB6.3080600@warmcat.com>
References: <20060329010235.GA3395@thyrsus.com>
	<20060329142659.GB1376783@hiwaay.net>
	<20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
Message-ID: <20060331114643.GA22130@thyrsus.com>

Andy Green <andy at warmcat.com>:
> I don't see any evidence for this for 2D.  The problems all seem to be 
> to do with 3D acceleration hardware in the past, present, and presumably 
> in the future. 

If true, that would still a problem.  The one guy I know who's a serious
graphics maven says that the wave of the future is 3D texture maps for
everything, including individual font glyphs.

>          And that in turn, like everything this thread touches, 
> seems to come down in the end to patents.

My graphics guy says that's true, but not in the way you might
expect.  He thinks the reason the graphics vendors are all doing locked 
firmware is because they're all violating *each others'* patents
and don't want to get found out...

> Macromedia?s Flash - 98%
> Viewpoint Media Player - 64.3%.  (<-- possible dodginess)
> Shockwave - 58.1%
> Windows Media Player 9 - 57.5%
> RealNetworks RealPlayer - 46.5%
> Apple?s QuickTime - 43.1%

RealNetworks we've got.  Flash and shockwave we can get.  I dunno
what "Viewpoint Media Player" is.  That leaves WMP9 (hopeless) 
and QuickTime (possible).  57% of users locked out because of one format
would be bad, but way better than where we are now.

>                       This is why I said there 
> is no end to that path of trying to make everyone happy, and that by 
> defining winning as doing that, you can never win.

Not absolutely, but once you know the percentages and costs you can
pick a minimax.  The goal of the game here isn't perfection, it's
maximizing adoption rate.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From aph12 at littlepinkcloud.com  Fri Mar 31 11:58:30 2006
From: aph12 at littlepinkcloud.com (Andrew Haley)
Date: Fri, 31 Mar 2006 12:58:30 +0100
Subject: 'Commercial Partners'
Message-ID: <17453.6502.844492.390146@zapata.pink>

sean writes:
 > On Fri, 31 Mar 2006 03:51:30 -0500
 > "Eric S. Raymond" <esr at thyrsus.com> wrote:
 > 
 > 
 > > > $THIS_THING is a moving target. 
 > > 
 > > Yes. it certainly is.  In a few years, once we solve this problem, I
 > > expect to be back here trying to kick certain people out of their
 > > dogmatic slumbers with respect to the *next* market-share blocker.
 > 
 > Don't see any evidence of dogmatic slumbering within Fedora.  Just
 > a realistic appraisal of what can be provided and what is appropriate
 > to provide under the very clear objectives of the project.   You seem
 > to think your goals should be those of the project, but have given
 > nothing more than a world domination pipe dream as a reason.
 > 
 > There's a worthwhile and valuable group being served well by Fedora.
 > Those that want or need proprietary solutions aren't stopped from 
 > getting them, they're a simple download the same as is required
 > on Windows in many cases.   
 > 
 > There is simply no need to start the Fedora core project down that 
 > slippery slope of providing or encouraging proprietary solutions.

You're precisely right.

Those who would give up Essential Freedom to purchase a little
Temporary Market Share, deserve neither Freedom nor Market Share.

(Couldn't resist!)

Andrew.



From nicolas.mailhot at laposte.net  Fri Mar 31 12:14:43 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 31 Mar 2006 14:14:43 +0200 (CEST)
Subject: Fedora's way forward
In-Reply-To: <442CD3C5.1030500@hhs.nl>
References: <20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>	<1143759138.3802.743.camel@sundaram.pnq.redhat.com>	<442C62DF.7010800@knox.net.nz>	<1143760541.2157.2.camel@scrappy.miketc.com>	<1143760877.3802.757.camel@sundaram.pnq.redhat.com>	<1143761274.2157.9.camel@scrappy.miketc.com>	<20060330235753.GC15963@thyrsus.com>
	<BAYC1-PASMTP0599CCE7A0CDAD49C9EDC4AED60@CEZ.ICE>
	<442CD3C5.1030500@hhs.nl>
Message-ID: <44163.192.54.193.25.1143807283.squirrel@rousalka.dyndns.org>


Le Ven 31 mars 2006 09:01, Hans de Goede a ?crit :

> Speaking only for myself: I'm getting rather tired of your zealot stance
> in this discussion, especially since your contribution to Fedora seems
> to consist of only hot air aka noise in discussions like this.

Hans,

I can't speak for Sean.
But speaking as a fedora.us then Fedora Extra maintainer, and as someone
who made some years ago major contributions to a third-party repository
which mixed FOSS and non-FOSS software (some packages of which have since
found their way in FC and FE), I can assure you I am deeply attached to
the FOSS-only nature of Fedora.

You want non FOSS software fine setup your own repo. If you're good and
some stuff gets freed over time it will end up in Fedora proper. If you're
bad everyone will ignore you as they should.

And yes that's a lot more work and abuse than pushing stuff directly to FC
or FE but that's real life for you. Go complain to the closed source
writers or fork Fedora like Mandrake forked RHL if you don't like it.

To all the pragmatist zealots : you can fork Fedora at any time. If you
don't think the value of a forked Fedora is sufficient to justify the
forking efforts and legal risks that would entail for you, you have no
case.

ie it's not sufficient to say life would be better with all the closed
software stuff, you have to balance the costs (money, legal, packaging) of
getting this stuff in with the expected benefits.

Gold doesn't corrode. My life would be easier with a gold bath-tub I
wouldn't have to protect from corrosion with paint. That does not mean
paying for a gold bath-tub is a resonable proposition.

Right now I'm far too cheap to go through the hassle closed software entails.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Fri Mar 31 12:25:05 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 31 Mar 2006 14:25:05 +0200 (CEST)
Subject: Fedora's way forward
In-Reply-To: <604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com>
	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>
	<442C59A9.1010507@hhs.nl>
	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>
	<442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
	<604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
Message-ID: <2141.192.54.193.25.1143807905.squirrel@rousalka.dyndns.org>


Le Ven 31 mars 2006 09:56, Jeff Spaleta a ?crit :

> Sure... go ahead and google for whatever proprietary software you want
> and install what you find.  I really don't see why proprietary media
> formasts should get special treatment of the vast space of proprietary
> software you have the freedom to attempt to install and use. What's
> next? You are going to be asking for fedora to provide as simplified
> solution to find and install proprietary crap that runs under wine?
> There's a hell of alot of freeware junk out there that probably runs
> under wine.

Also what most people seem for forget is closed stuff is hell to package.
It's not designed to be installed sanely. It's designed to work "like
under windows" ie :

1. either it's pre-installed on the system (which Fedora can not do for
obvious reasons)

2. or you have to go through tedious ever-changing download and install
procedures to get it (and it wants to own the system so it will almost
always wonflict with something else)

Even if the software itself is not junk the installation procedures almost
always are. Good luck trying to automate them.

-- 
Nicolas Mailhot



From jdieter99 at gmx.net  Fri Mar 31 12:47:59 2006
From: jdieter99 at gmx.net (Jonathan Dieter)
Date: Fri, 31 Mar 2006 15:47:59 +0300
Subject: r300 driver in extras?
Message-ID: <442D24FF.3060403@gmx.net>

Mike, I've been following the fedora-devel mailing list, and I 
understand why you removed r300 support in Mesa and the kernel.  I was 
working through a bug where OpenGL didn't work at all (even in indirect 
mode), and, in the process, rebuilt both Mesa and the kernel after 
removing your fixes.  Apparently, I'm one of the lucky ones whose Radeon 
9600 works with the experimental driver because it all started working.  
I'm now thinking of putting together a package (similar to the 
proprietary one in livna) that would give accelerated 3D to any Radeon 
users willing to take the risk.

It seems that the only difference in Mesa when the r300 is enabled is 
that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and 
that the only difference in the kernel is the drm module is patched to 
not recognize the r300 PCI ids.  It seems that the Mesa problem could be 
easily fixed, but what is the easiest way to fix the kernel (aside from 
providing my own (un)patched kernel)?  Will X even try to load the DRM 
module if Mesa doesn't provide r300_dri.so but the kernel does provide 
the PCI id's?  If it doesn't, could we re-enable the r300 PCI ids in the 
kernel and just ship Mesa without the r300 driver?  If it does, is there 
any other possible solution to the kernel that I'm missing?

I've been using the fglrx driver in earlier version of Fedora for years 
now and would love to take this chance to move off of it and helping 
others move off in the process is a bonus.

Thanks,
Jonathan Dieter



From rdieter at math.unl.edu  Fri Mar 31 12:48:08 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 31 Mar 2006 06:48:08 -0600
Subject: fc4 ghost md5sums: a tale of woe
In-Reply-To: <20060330220115.GA14571@jadzia.bu.edu>
References: <20060330220115.GA14571@jadzia.bu.edu>
Message-ID: <442D2508.9030807@math.unl.edu>

Matthew Miller wrote:
> I realize that FC4 is unexciting these days, so this may not generate much
> enthusiasm, but: how in the _world_ are you RH folks building updates for
> Fedora Core 4?
> 
> The story:
> 
> We need to make some local modifications to some of the files in the 'setup'
> package here at BU, and we were chasing ourselves in circles over making it
> not conflict with /var/log/lastlog also owned by util-linux.
> 
> Both of these packages have that file as a %ghost file, and last September,
> they were updated to have permissions of 0644. Specifically, there's
> 
>   %ghost %attr(0644,root,root) %verify(not md5 size mtime) /var/log/lastlog
> 
> in both files.
> 
> Okay, fine, that should work. And the packages in the FC4 updates area
> indeed both install without conflict.

In my experience, that does *not* work.  Sharing of files (whether their 
%ghost'd or not) *only* works if the original contents are *exactly* the 
same (timestamp, ownership, permissions, contents, md5sum, etc...).

-- Rex



From andy at warmcat.com  Fri Mar 31 13:19:45 2006
From: andy at warmcat.com (Andy Green)
Date: Fri, 31 Mar 2006 14:19:45 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060331114643.GA22130@thyrsus.com>
References: <20060329010235.GA3395@thyrsus.com>	<20060329142659.GB1376783@hiwaay.net>	<20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com>	<20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com>
Message-ID: <442D2C71.7070809@warmcat.com>

Eric S. Raymond wrote:
> Andy Green <andy at warmcat.com>:
>> I don't see any evidence for this for 2D.  The problems all seem to be 
>> to do with 3D acceleration hardware in the past, present, and presumably 
>> in the future. 
> 
> If true, that would still a problem.  The one guy I know who's a serious
> graphics maven says that the wave of the future is 3D texture maps for
> everything, including individual font glyphs.

As Nicholas says, all is not completely rosy in the 2D garden.  But the 
proposal I replied to was that for future graphics card we will be 
unable to use resolutions greater than 'VESA', whatever that means since 
you can get 1600x1200 in Vesa, in fact I think the table comes out of 
the card's video BIOS and can support anything.  It seems for normal 2D 
the open source drivers are able to do a decent job but advanced stuff 
can be a different matter.

>>          And that in turn, like everything this thread touches, 
>> seems to come down in the end to patents.
> 
> My graphics guy says that's true, but not in the way you might
> expect.  He thinks the reason the graphics vendors are all doing locked 
> firmware is because they're all violating *each others'* patents
> and don't want to get found out...

That is what I was referring to.  Eric Blossom from Gnu Radio told me 
this as a possible explanation for wlan driver secrecy as well.

>> Macromedia?s Flash - 98%
>> Viewpoint Media Player - 64.3%.  (<-- possible dodginess)
>> Shockwave - 58.1%
>> Windows Media Player 9 - 57.5%
>> RealNetworks RealPlayer - 46.5%
>> Apple?s QuickTime - 43.1%
> 
> RealNetworks we've got.  Flash and shockwave we can get.  I dunno
> what "Viewpoint Media Player" is.  

It seems they may have funded the original survey :-)  Hence the disclaimer.

> That leaves WMP9 (hopeless) 
> and QuickTime (possible).  

Well let's not conflate the player app with the codecs.  Quicktime for 
example contains Sorensen and 30-odd other codecs:

http://www.simnet.is/klipklap/quicktime/

Each of these will have its own patent story and people looking to get 
their hands on RHAT's cash if RHAT give them the chance.  WMP is just a 
relatively lightweight pretty usermode app on top of a similar list of 
codecs that come with it and Windows.  You see mplayer go on unmolested 
because it will not repay the attack as they are mainly individuals in 
Eastern Europe AIUI.  RHAT though have a large amount of cash, if they 
step wrong an attack has a chance of a fat cash reward.  Further, if 
RHAT folks are not seen to protect their assets with due diligence, they 
face a shareholder suit.  Their care is very pragmatic indeed.

 > The goal of the game here isn't perfection, it's
 > maximizing adoption rate.

I don't believe I saw that in the Fedora manifesto.  Much as I loathe 
MSFT personally, for some users they are the right answer as things 
stand and Fedora is not.  But things are slowly shifting and RHAT is one 
of the engines inching things around.

> Not absolutely, but once you know the percentages and costs you can
> pick a minimax.  

Well then you need to amend your earlier clarion call to arms to 
'looking as least like a useless wanker as we can given the reality for 
some usage cases (MSFT or AAPL codecs, DVDs, HDTV media, Digital music 
downloads in WMA or FairPlay) we are inescapably actually useless 
wankers'.  OR you can just not get into that game if you see you can't 
win, and take the initiative by raising a different standard for people 
to rally around and providing an alternative way: "If it ain't Free, 
keep it".

-Andy

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

From david at fubar.dk  Fri Mar 31 13:51:54 2006
From: david at fubar.dk (David Zeuthen)
Date: Fri, 31 Mar 2006 08:51:54 -0500
Subject: Fedora's way forward
In-Reply-To: <442CD714.2030504@hhs.nl>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>
	<442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
Message-ID: <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk>


On Mar 31, 2006, at 2:15 AM, Hans de Goede wrote:
>
>
> Eric S. Raymond wrote:
>> Michael J Knox <michael at knox.net.nz>:
>>> After looking at the link I gave closer, I noticed this:
>>>
>>> http://easylinux.info/wiki/Fedora_frog
>>>
>>> This is a script that installs and sets up a lot of the things  
>>> people are looking for.
>>>
>>> How about we work on/from/with that? Its certainly a start.
>> Agreed.
>
> No this is way wrong:
> -it drags in mscorefont which is atleast a legal gray area
> -it enables all repos under the sun causing repo conflict nightmare,
>  I've had to help many new Linux users fix their systems after  
> following
>  great advise like this.
> -and does all kind of other evil

Strong agreement, please don't base this on a hackish script.  
Ideally, the solution should just, upon the user pressing the link in  
the Web Browser do the following

  - Serve an RPM file with the right mime type (e.g. not Realaudio)
  - User opens RPM with Pirut (because Pirut is the default handler  
for RPM files)
  - RPM contains .repo file and have Deps on the packages you want to  
install
  - Please be conservative in what packages you pull in; suggest just  
to provide the gstreamer plug-ins initially
  - Done

Suggestions

  - Avoid pulling in more than one repository as 3rd party repos do  
tend to provide same packages and it gets muddy if you get pkg Foo  
from repo A and then repo B provides an upgrade => stick to a single  
3rd party repo

  - Though it is tempting, please avoid installing proprietary  
software for which we already got an excellent, better or good-enough  
free replacement
   - e.g. for movies we got Totem, e.g. we don't need mplayer (if  
Totem can't play a specific stream the user should file bugs)
  - for document viewing we got Evince (if the user needs a11y make  
the Evince authors fix it, don't install adobe reader)
  - Ditto for Ekiga vs. Skype

  - Initially avoid pulling in kernel module packages until automatic  
rebuild of said packages works... otherwise you get users unable to  
update their kernel..

  - Don't use hackish scripts to reconfigure other parts of the users  
system; if you need default configuration for one or more packages  
changed then file a bug in bugzilla and solve it in Fedora

So the bottom line is... keep it simple, transparent and easy to  
understand... if you start providing a script like  that Fedora Frog  
thing you are bound to get ignored by package maintainers in Core and  
Extras. Suggest to just start with media codecs. Once the project is  
a success think about pulling in more stuff.. but the mantra must be  
that clicking this link should never ever fail...

Another suggestion, if you want the mindshare of the developers and  
package maintainers in Core/Extras (and you do because if you get  
them to use this they sure as hell will do their part to make sure  
upgrades works with the 3rd party packages you pull in) make sure you  
enable this solution on Rawhide too... yes, this includes making sure  
that 3rd party repos rebuild for Rawhide everyday or whenever  
necessary. Getting 3rd repo to buy into this might be the biggest  
hurdle though ICBW.

HTH,
David



From david at fubar.dk  Fri Mar 31 14:02:24 2006
From: david at fubar.dk (David Zeuthen)
Date: Fri, 31 Mar 2006 09:02:24 -0500
Subject: Fedora's way forward
In-Reply-To: <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>	<442AE298.9090300@knox.net.nz>
	<442AE4DF.700@hhs.nl>	<20060330213538.GC14444@thyrsus.com>	<BAYC1-PASMTP045FE12CC14DDF99C9386DAED10@CEZ.ICE>	<442C59A9.1010507@hhs.nl>	<BAYC1-PASMTP091F41E07CBB1F99EA57ECAED10@CEZ.ICE>	<442C5FA1.5050506@knox.net.nz>
	<442C9C15.1090601@knox.net.nz>
	<20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl>
	<6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk>
Message-ID: <0B3DE86C-AA74-4BD7-8710-98C3CE20FCA6@fubar.dk>


On Mar 31, 2006, at 8:51 AM, David Zeuthen wrote:
>  - Though it is tempting, please avoid installing proprietary  
> software for which we already got an excellent, better or good- 
> enough free replacement
>   - e.g. for movies we got Totem, e.g. we don't need mplayer (if  
> Totem can't play a specific stream the user should file bugs)
>  - for document viewing we got Evince (if the user needs a11y make  
> the Evince authors fix it, don't install adobe reader)
>  - Ditto for Ekiga vs. Skype

OK, so I perfectly know mplayer is open source, sorry about that. I  
guess I was trying to say that the solution should never pull in  
software that changes the defaults on Fedora like installing a whole  
new media player stack (mplayer vs. Totem) or a new communications  
stack (Skype vs. Ekiga).

The solution should simple install plug-ins (e.g. codecs) that  
extends our default applications. If you do anything more than this I  
predict the solution to be less than successful. Isn't it great that  
we have frameworks like e.g. gstreamer or Mozilla plug-ins that  
actually alow this know?

Hope this clarifies. And good luck with this project - personally I'm  
looking forward to having stuff like this for Fedora!

      David




From green at redhat.com  Fri Mar 31 02:04:11 2006
From: green at redhat.com (Anthony Green)
Date: Thu, 30 Mar 2006 18:04:11 -0800
Subject: Fedora Looks Fresh and Functions Well
In-Reply-To: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>
References: <d82d6db50603300128q673283cfw7d2a0bd69cdbb739@mail.gmail.com>
Message-ID: <1143770652.2552.36.camel@localhost.localdomain>

On Thu, 2006-03-30 at 04:28 -0500, Benjy Grogan wrote:
> (Question: Is a compiled Azureus the same if it's based on Sun or
> GCJ?)

It's supposed to be, although somebody recently filed a bug about
running azureus on Sun Java.  I hope to look into it very soon.

AG




From overholt at redhat.com  Fri Mar 31 15:15:02 2006
From: overholt at redhat.com (Andrew Overholt)
Date: Fri, 31 Mar 2006 10:15:02 -0500
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <4429327A.2060401@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com> <4429327A.2060401@gmail.com>
Message-ID: <20060331151502.GC13677@redhat.com>

* Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> [2006-03-28 07:59]:
> 
> The java that comes along with GCC runs only about 10-20% of Java Applications
> in market. Want examples: try to access any Brazilian bank using "Fedora
> standard Java".

Can you give concrete examples?  Preferably as bugs?

Andrew



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Fri Mar 31 15:23:06 2006
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Fri, 31 Mar 2006 17:23:06 +0200
Subject: Fedora's way forward
In-Reply-To: <20060330213042.GB14444@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060330213042.GB14444@thyrsus.com>
Message-ID: <20060331172306.753d187a@python2>

Eric S. Raymond wrote :

> David Zeuthen <david at fubar.dk>:
> > Tell me.. why you don't start a project aiming for better integration of
> > 3rd party repositories outside Fedora Core and Extras? I'm sure it can
> > be as simple as Alan outlined with the user just having to click a link
> > in his web browser and, badebing-badebum, all the stuff is installed.
> > 
> > I encourage you to take this task upon you. I think it would be great!
> 
> Would Fedora carry a script or application intended to make easy access
> to such third-party repositories available, even on the premise that they
> carry proprietary software?
> 
> If the answer is "yes", then I would in fact be willing to work on this.

I think it's already all pretty simple... here's an example :

1) Go to http://freshrpms.net/ with firefox on FC5 (the default)
2) Click on "click here"
3) Enter your root password when prompted
4) Run "Add/Remove Software" from the menu

That's pretty much it.
If you search for "mp3" you'll get somewhere...

What bugs me the most is that although things are trivial for broadband
users, it's simply impossible for dialup users (or users with no Internet
connection at all) to achieve the same, unlike in FC4 where I had made a
"Freshrpms CD" that let you install MPlayer, VLC, Xine, dvd::rip, XMMS
plugins etc.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2080_FC5
Load : 1.05 0.90 0.75



From webmaster at margo.bijoux.nom.br  Fri Mar 31 15:41:13 2006
From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo)
Date: Fri, 31 Mar 2006 12:41:13 -0300
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <20060331151502.GC13677@redhat.com>
References: <20060331151502.GC13677@redhat.com>
Message-ID: <20060331154113.9493.qmail@hm196.locaweb.com.br>

On Fri, 31 Mar 2006 10:15:02 -0500, Andrew Overholt <overholt at redhat.com> escreveu:
> * Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> [2006-03-28 07:59]:
> > 
> > The java that comes along with GCC runs only about 10-20% of Java Applications
> > in market. Want examples: try to access any Brazilian bank using "Fedora
> > standard Java".
> 
> Can you give concrete examples?  Preferably as bugs?

The banks that he mentions require a java plugin, so he will have to wait for the work on the plugin.
As for the applications, I dont have any examples of well known applications, except the bug report I just filled (bug 187513), about a JFileChooser that shows no files in the directory and throws an exception if you click on area where the files should be. 

--
Pedro Macedo



From mattdm at mattdm.org  Fri Mar 31 16:22:37 2006
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 31 Mar 2006 11:22:37 -0500
Subject: fc4 ghost md5sums: a tale of woe
In-Reply-To: <442D2508.9030807@math.unl.edu>
References: <20060330220115.GA14571@jadzia.bu.edu>
	<442D2508.9030807@math.unl.edu>
Message-ID: <20060331162237.GA23103@jadzia.bu.edu>

On Fri, Mar 31, 2006 at 06:48:08AM -0600, Rex Dieter wrote:
> >  %ghost %attr(0644,root,root) %verify(not md5 size mtime) /var/log/lastlog
> >in both files.
> >Okay, fine, that should work. And the packages in the FC4 updates area
> >indeed both install without conflict.
> In my experience, that does *not* work.  Sharing of files (whether their 
> %ghost'd or not) *only* works if the original contents are *exactly* the 
> same (timestamp, ownership, permissions, contents, md5sum, etc...).


You got util-linux and setup installed on your system? It's working. :)
Timestamps can be different, but yeah, everything else should be the same.

In the case of the problem described, the files _are_ the same -- they're
zero length files. But, as far as I can tell, FC4's RPM stores the md5sum of
ghosted files differently from whatever version of RPM Red Hat is using to
actually build the FC4 packages they release.

In an RPM built on FC3 and above, the package contains _nothing_ for the
md5sum. In packages built on FC2, and to my surprise, the FC4 packages in
the updates repository, the ghosted files have their "correct" checksum --
that of an empty file.

That's fine as long as you don't try to rebuild any of those packages
locally, but if you do, you'll run into this issue.

I assume the change was made so that ghosted files _don't_ have to start
identically, which makes sense, but it causes weirdness when the official
packages aren't built that way.

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



From avi at unix.sh  Fri Mar 31 16:30:12 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 13:30:12 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603301922u5fa00c22j14f912320467186c@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
	<ed0efd310603301857j16907b40qc2525c89a6b6f856@mail.gmail.com>
	<ed0efd310603301922u5fa00c22j14f912320467186c@mail.gmail.com>
Message-ID: <ed0efd310603310830s3c71a547h4b59ce6920b2c85d@mail.gmail.com>

Bill Crawford <billcrawford1970 gmail com> wrote:
> Dunno where you got this obsession, but just because you can represent data as
> "key/value pairs" doesn't mean that's always the best layout.

Maybe not for your or my eyes. The best layout is the one accessible
by the broadest range of ways. Currently, human-readable files are
accessible by human-beings only, or by configuration file "compilers",
that are difficult, unique, that nobody wants to write or maintain
except for the original software writer (e.g. the Samba developer with
the smb.conf file).

The proposed layout is accessible to you by simple reformatting (as
with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or
by GUIs (as kdbedit,
http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any
software that uses a simple API as libelektra.


> There's a reason why programs aren't written for the old Turing Machine, and
> that's that however well it might be able to represent any possible program,
> it's incredibly verbose.

The only reason I can see is historical. Since there is now projects
integration efforts in the OSS world, everybody uses its own format.
So you may think there is a reason, lost in time, but there is
actually no reason why BIND named.conf file look that way, which is
different from /etc/passwd, which is different from smb.conf, which is
different from httpd.conf. Well, the real reason I can see is selfish
developers that enjoy rewriting config file parsing code and invent
configuration file layouts that seems best suited for their apps. But
when you strip the syntax fat, they all are not more than key and
value pairs on a hierarchy.

So to make the discussion productive, please enlighten us with the
reasons you think exists somewhere, or please don't speculate.



> The examples which have appeared in this thread have all made things *less*
> clear afaics.

Again, maybe for our human eyes, but are 100% clear for software. And
the end-goal is leverage better software integration between
themselves, so we, human-beings, will have to look at configuration
element everyday less.

Anyway, for human eyes, I think this is pretty pleasant to see:
http://www.libelektra.org/Screenshots_and_Key_Examples

> Bill"somewhat sick of this thread but suspecting if people don't reply the
> lunatics will end up running the asylum"Crawford.

Or maybe the lunatics are already running it and some people are
trying to take the control back :-)

Avi



From avi at unix.sh  Fri Mar 31 16:31:25 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 13:31:25 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603291611w7f0c2ff2g254fce8c58437bf@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<Pine.LNX.4.62.0603290011270.29184@gotcha.dreamhost.com>
	<ed0efd310603291611w7f0c2ff2g254fce8c58437bf@mail.gmail.com>
Message-ID: <ed0efd310603310831g89d37f6veae2d9141e4dbf9a@mail.gmail.com>

On 3/29/06, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> Um, GConf supports several backends as well. Can't argue about the
> dependencies.. just had a look at rpm -q --requires GConf2 - oh puke.
> Building another layer on top of that gunk isn't going to help cutting
> down the dependencies though :)



The idea actually is to have GConf use Elektra as its backend.
The GConf backend for Elektra (the inverse of the previous phrase) was
a test, just to make GConf exporting easy.

Avi



From avi at unix.sh  Fri Mar 31 16:32:12 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 13:32:12 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
Message-ID: <ed0efd310603310832m2cc9d3h96fe06809720c301@mail.gmail.com>

Alan Cox wrote:
> Not really. What made gconf slow was dumb ideas like storing one value per
> file. XML is relatively efficient compared to the damage that did. The storage
> is jut a backend however. Gconf as a system could use punched cards for its
> data storage too if you really wanted

Yes, implementation details. But GConf still has the drawback of
having tons of dependencies and was not designed for system wide use,
nor it has a global namespace.

Regarding speed, Elektra now has a new Berkeley DB backend, very very fast.

Avi



From avi at unix.sh  Fri Mar 31 16:33:06 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 13:33:06 -0300
Subject: Fwd: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603292020k6efb2800r18f6e89475059eb4@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
	<Pine.LNX.4.63.0603281451370.27793@master.geeklords.org>
	<1143588739.30123.70.camel@localhost>
	<ed0efd310603292020k6efb2800r18f6e89475059eb4@mail.gmail.com>
Message-ID: <ed0efd310603310833n3cd1ed6cuc0b47ed1bac5a5ad@mail.gmail.com>

On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> I'd argue that as the number of subnets and special case workstations
> goes up, the ability of a system administrator to read and understand
> the flat file is going to be markedly harder than for the admin to read
> the custom-crafted dhcp-config syntax.
>
> So if the end-goal is to keep the system-administrator's poor brain from
> exploding while manually editing the files, I'd say custom-crafted
> config files can be a win versus the generic one-size-fits-all approach.



Thats not the end-goal.

See, the end goal is to standarize configurations in such a way that
one program with proper permissions can directly interact with another
program's configurations. So in your DHCP server problem, an LDAP
helper can easily change DHCP's configuration to add/remove/change
some host's fixed IP address, for example, without having to ask the
sysadmin (a human being) to edit it manualy, and without having to
regenerate the entire config file again.

Another more easy to understand problem that a global standarized
configuration standard solves is the ability for you to buy a
commodity video card, install it on your system, and the vendor
scripts will safely, automatically, and precisely change your X.org
standarized configuration to inject itself there. Currently they have
to ask you to use vi plus your human brain and human eyes to make the
xorg.conf changes by yourself, because it is too hard for them write
an xorg.conf "compiler". Actualy, we know that what really happens is
a simple "Linux is not suported" statement from these vendors.

Avi



From avi at unix.sh  Fri Mar 31 16:34:02 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 13:34:02 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603291611w7f0c2ff2g254fce8c58437bf@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<Pine.LNX.4.62.0603290011270.29184@gotcha.dreamhost.com>
	<ed0efd310603291611w7f0c2ff2g254fce8c58437bf@mail.gmail.com>
Message-ID: <ed0efd310603310834q1c8fd862t100869e0ca7f0589@mail.gmail.com>

On 3/29/06, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> Um, GConf supports several backends as well. Can't argue about the
> dependencies.. just had a look at rpm -q --requires GConf2 - oh puke.
> Building another layer on top of that gunk isn't going to help cutting
> down the dependencies though :)



The idea actually is to have GConf use Elektra as its backend.
The GConf backend for Elektra (the inverse of the previous phrase) was
a test, just to make GConf exporting easy.

Avi



From avi at unix.sh  Fri Mar 31 16:34:56 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 13:34:56 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603291605p58e8f2fdj41a9e3c47ebb2f67@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org>
	<16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com>
	<20060328040953.17819ad1.seanlkml@sympatico.ca>
	<1143565978.2523.3.camel@rousalka.dyndns.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<ed0efd310603291605p58e8f2fdj41a9e3c47ebb2f67@mail.gmail.com>
Message-ID: <ed0efd310603310834u260c2604ibbf8f5d348fed967@mail.gmail.com>

On 3/28/06, Jeff Spaleta <jspaleta at gmail.com> wrote:
> developements.  If you can't convince upstream developers to build in
> support, a think its pretty ludicrious to be having a discussion about
> it at the distributor level with any expectation a distributor like
> fedora to do all the work downstream to integrate electra specific
> patches.




It would help if Elektra could be simply included in a distro, so
developers could start using it.

Avi



From toshio at tiki-lounge.com  Fri Mar 31 17:20:57 2006
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Fri, 31 Mar 2006 09:20:57 -0800
Subject: Fwd: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603310833n3cd1ed6cuc0b47ed1bac5a5ad@mail.gmail.com>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<20060328123043.3d40cdf3.seanlkml@sympatico.ca>
	<20060328180838.GE24725@devserv.devel.redhat.com>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
	<Pine.LNX.4.63.0603281451370.27793@master.geeklords.org>
	<1143588739.30123.70.camel@localhost>
	<ed0efd310603292020k6efb2800r18f6e89475059eb4@mail.gmail.com>
	<ed0efd310603310833n3cd1ed6cuc0b47ed1bac5a5ad@mail.gmail.com>
Message-ID: <1143825659.3157.7.camel@localhost>

On Fri, 2006-03-31 at 13:33 -0300, Avi Alkalay wrote:
> On 3/28/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> > I'd argue that as the number of subnets and special case workstations
> > goes up, the ability of a system administrator to read and understand
> > the flat file is going to be markedly harder than for the admin to read
> > the custom-crafted dhcp-config syntax.
> >
> > So if the end-goal is to keep the system-administrator's poor brain from
> > exploding while manually editing the files, I'd say custom-crafted
> > config files can be a win versus the generic one-size-fits-all approach.
> 
> 
> 
> Thats not the end-goal.
> 
You came into the thread late.  It's not Elektra's end-goal, it is the
end goal of some of the posters to whom I was replying.

> See, the end goal is to standarize configurations in such a way that
> one program with proper permissions can directly interact with another
> program's configurations. So in your DHCP server problem, an LDAP
> helper can easily change DHCP's configuration to add/remove/change
> some host's fixed IP address, for example, without having to ask the
> sysadmin (a human being) to edit it manualy, and without having to
> regenerate the entire config file again.
> 
So Elektra's end goal is a common on-disk format?  And libelektra is a
"reference implementation" providing an API that the developers think is
sane?  Which clears up the following areas:

* GConf as a backend was not a real long term direction for the
software.
* Making Elektra a backend to GConf/KConfig/etc is providing an
additional API rather than the canonical one.  It doesn't compromise the
core goal of a common on-disk format.

Please further clarify if necessary.

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

From esr at thyrsus.com  Fri Mar 31 17:30:30 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 12:30:30 -0500
Subject: 'Commercial Partners'
In-Reply-To: <442D2C71.7070809@warmcat.com>
References: <20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
Message-ID: <20060331173030.GB24571@thyrsus.com>

Andy Green <andy at warmcat.com>:
> That is what I was referring to.  Eric Blossom from Gnu Radio told me 
> this as a possible explanation for wlan driver secrecy as well.

Well, there's a larger issue with variable driver wattage there...
 
> Well let's not conflate the player app with the codecs.  Quicktime for 
> example contains Sorensen and 30-odd other codecs:
> 
> http://www.simnet.is/klipklap/quicktime/

Yeah, I know.  But in practice "Quicktime" support pretty much reduces 
to "Sorensen video codec support".
 
> Each of these will have its own patent story and people looking to get 
> their hands on RHAT's cash if RHAT give them the chance.

This is no different than any normal negotiating situtation.  Other OS
vendors deal with it all the time.

> > The goal of the game here isn't perfection, it's
> > maximizing adoption rate.
> 
> I don't believe I saw that in the Fedora manifesto. 

No, you didn't.  That mean I'm somehow not allowed to argue that 
the manifesto should change?

I'm not doing this for my health, Andy.  Linux is in a fluid competitive
situation with a lot of powerful enemies.  It's grow or die.  I'm trying
to avoid "die".
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From dwmw2 at infradead.org  Fri Mar 31 17:32:44 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 31 Mar 2006 18:32:44 +0100
Subject: r300 driver in extras?
In-Reply-To: <442D24FF.3060403@gmx.net>
References: <442D24FF.3060403@gmx.net>
Message-ID: <1143826364.19590.130.camel@pmac.infradead.org>

On Fri, 2006-03-31 at 15:47 +0300, Jonathan Dieter wrote:
> It seems that the only difference in Mesa when the r300 is enabled is 
> that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and 
> that the only difference in the kernel is the drm module is patched to 
> not recognize the r300 PCI ids.  It seems that the Mesa problem could be 
> easily fixed, but what is the easiest way to fix the kernel (aside from 
> providing my own (un)patched kernel)?

We could make the crippling of R300 _optional_, by doing it with the
patch below instead of just by ripping the relevant PCI IDs out.

DaveJ?

--- linux-2.6.16.ppc/drivers/char/drm/radeon_cp.c~	2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.16.ppc/drivers/char/drm/radeon_cp.c	2006-03-31 18:26:00.000000000 +0100
@@ -34,6 +34,11 @@
 #include "radeon_drv.h"
 #include "r300_reg.h"
 
+int radeon_allow_r300;
+
+MODULE_PARM_DESC(allow_r300, "Allow DRI on Radeon R300 and later cards");
+module_param_named(allow_r300, radeon_allow_r300, int, 0444);
+
 #define RADEON_FIFO_DEBUG	0
 
 static int radeon_do_cleanup_cp(drm_device_t * dev);
@@ -2104,6 +2109,11 @@ int radeon_driver_load(struct drm_device
 	drm_radeon_private_t *dev_priv;
 	int ret = 0;
 
+	if (!radeon_allow_r300 && (flags & CHIP_FAMILY_MASK) >= CHIP_R300) {
+		printk(KERN_NOTICE "Avoiding DRI on Radeon R300+. Use 'allow_r300=1' module option to override\n");
+		return DRM_ERR(ENXIO);
+	}
+
 	dev_priv = drm_alloc(sizeof(drm_radeon_private_t), DRM_MEM_DRIVER);
 	if (dev_priv == NULL)
 		return DRM_ERR(ENOMEM);

-- 
dwmw2



From dnjinc at wowway.com  Fri Mar 31 17:34:56 2006
From: dnjinc at wowway.com (Demond James)
Date: Fri, 31 Mar 2006 12:34:56 -0500
Subject: Split-off package config from release note packages
In-Reply-To: <20060329150226.GC13953@neu.nirvana>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>	<1143516515.3140.1.camel@aglarond.local>	<20060328122303.GA19783@jadzia.bu.edu>	<ufahd5ihcze.fsf@epithumia.math.uh.edu>	<1143558013.3140.15.camel@aglarond.local>
	<20060329150226.GC13953@neu.nirvana>
Message-ID: <442D6840.2020600@wowway.com>

Axel Thimm wrote:
> But then hell breaks loose and people accuse JoeBob of forking fedora,
> when all he wanted to do is either provide decent mirrors (local or
> not) for his users or additional repos. Having to replace
> fedora-release to do that results in for example:
>
> http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning
>
>   
What would help stop the propaganda Axel is descriptions of the changes 
that were made to these core packages.  As it stands now I do not want 
to replace the core packages with your packages simply because I don't 
now what changes you made.  Let me decided if I want that added 
feature.  Other than that great job and great repo.   Thank you!

Demond



From esr at thyrsus.com  Fri Mar 31 17:36:33 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 12:36:33 -0500
Subject: Fedora's way forward
In-Reply-To: <20060331172306.753d187a@python2>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060330213042.GB14444@thyrsus.com>
	<20060331172306.753d187a@python2>
Message-ID: <20060331173633.GC24571@thyrsus.com>

Matthias Saou:
> I think it's already all pretty simple... here's an example :
> 
> 1) Go to http://freshrpms.net/ with firefox on FC5 (the default)
> 2) Click on "click here"
> 3) Enter your root password when prompted
> 4) Run "Add/Remove Software" from the menu
> 
> That's pretty much it.

Remember, we're talking nontechnical users here.  If it's potentially 
this simple, good -- but finding the right stuff to install has to be
even simpler.

The user needs a button to push and a simple menu, and and interface
that *requires effectively no thought or decisions*.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From fedora at leemhuis.info  Fri Mar 31 17:51:28 2006
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 31 Mar 2006 19:51:28 +0200
Subject: Fedora's way forward
In-Reply-To: <20060331173633.GC24571@thyrsus.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<1143609370.3802.598.camel@sundaram.pnq.redhat.com>
	<20060329063345.GB6131@thyrsus.com>
	<1143657279.25616.11.camel@daxter.boston.redhat.com>
	<20060330213042.GB14444@thyrsus.com> <20060331172306.753d187a@python2>
	<20060331173633.GC24571@thyrsus.com>
Message-ID: <1143827488.2327.12.camel@localhost.localdomain>

Am Freitag, den 31.03.2006, 12:36 -0500 schrieb Eric S. Raymond:
> Matthias Saou:
> > I think it's already all pretty simple... here's an example :
> > 
> > 1) Go to http://freshrpms.net/ with firefox on FC5 (the default)
> > 2) Click on "click here"
> > 3) Enter your root password when prompted
> > 4) Run "Add/Remove Software" from the menu
> > 
> > That's pretty much it.
> 
> Remember, we're talking nontechnical users here.  If it's potentially 
> this simple, good -- but finding the right stuff to install has to be
> even simpler.

And the user should not be confused with to many 3rd party repos that
are incompatible (yes, I know that's some people disagree with the
"incompatible" in the last sentence). 

freshrpms and livna are not that different in politics. There are a lot
of packages present in both, but still some packages only exist in
freshrpms and some others only in lvina. merging those two (or at least
working closely together) seems like a good idea to me.
-- 
Thorsten Leemhuis <fedora at leemhuis.info>



From tromey at redhat.com  Fri Mar 31 17:47:58 2006
From: tromey at redhat.com (Tom Tromey)
Date: 31 Mar 2006 10:47:58 -0700
Subject: Fedora's way forward
In-Reply-To: <442ACC2F.90306@hhs.nl>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<20060328104659.GI12588@devserv.devel.redhat.com>
	<1143651293.5600.228.camel@pmac.infradead.org>
	<ufahd5h9o50.fsf@epithumia.math.uh.edu>
	<m38xqtrwc1.fsf@localhost.localdomain>
	<1143655398.2678.37.camel@tortoise.toronto.redhat.com>
	<442ACC2F.90306@hhs.nl>
Message-ID: <m3zmj6jyk1.fsf@localhost.localdomain>

>>>>> "Hans" == Hans de Goede <j.w.r.degoede at hhs.nl> writes:

>> Yes, we're aiming to have gcjwebplugin in Fedora Core 6.

Hans> Now that would be really cool, what can I* do to help this?

In addition to what Tom Fitzsimmons said, there are plenty more useful
things to do.

The simplest thing is to build gcjwebplugin, try applets, and report
the bugs you find.  (Best to report them to the Classpath bugzilla
BTW.)

The next step would be to fix the bugs :-)

If you are more interested in writing tests, we can use all kinds of
java security tests.

If you're more interested in development, this is the meta-bug for
tracking the security to-do list:

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13603

Tom



From casimiro.barreto at gmail.com  Fri Mar 31 17:58:48 2006
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Fri, 31 Mar 2006 14:58:48 -0300
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <20060331154113.9493.qmail@hm196.locaweb.com.br>
References: <20060331151502.GC13677@redhat.com>
	<20060331154113.9493.qmail@hm196.locaweb.com.br>
Message-ID: <442D6DD8.9070200@gmail.com>

Excuses for all..

    Yeah... there are concrete problems with the lack of the java plug
    in. But besides that I had problems with some applications (class
    this and class that not found... and lots of other errors and
    messages, but I'm not St. Claire - Santa Clara - to give light to
    blind people, nor I'm under contract to point out again and again
    where inconsistencies appear). BTW, try to run Gentleware SW
    Poseidon for UML without Sun Java... Try to develop sw for portables
    using Waba/Super-Waba or the likes without Sun Java... anyways, I
    think that at the moment the discussion turned quite "religious" and
    around "dogma" so I'll pretend everything is ok and stop posting,
    pretending that if nobody complains, then there are no problems at all.

    I wrote consistently in past around problems with SATA RAID (RAID1)
    and computer locking without leaving a single trace message for you
    to work with and try to discover what happened. Last week another
    guy started the same "via crucis"... Perhaps next week someone else
    will engage the line and post the same question... My advice to the
    poor boys... convince your boss to purchase external SCSI raid. But
    before, see if it is compatible... avoid the risk of get it even not
    recognized by Operating System.

    I warned about USB system not recognizing OV-511 devices. Well it is
    not true: if you turn your computer off and them turn it on... it
    recognizes it... but don't unplug from main power lines... just turn
    off and on...

    The current kernel (2.8.16-1.2083_FC6) issues a message that the
    processor of my box is overheating, so speed is going down... That's
    not true and I sent an e-mail... The answer was: not enough data,
    but that was all the data recorded... BTW, I'm not working in a
    morgue, but temperatures are around 20C... Solution? Easy: download
    kernel source (not available by default), fix it, recompile it...
    re-install it. And now I work without the annoyance of "clock speed
    throttling down and" until the computer gets stuck... BTW, if
    someone cares, heat sensors get crazy whenever FPU is required like
    with setiathome (BOINC). Processor: Pentium 4 @ 2.8GHz (not that
    Ferrari). All coolers and fans working properly...

    NVIDIA is a "recurrent" issue... and official position is that
    people don't need NVIDA official drivers... because if you want to
    play a game you will use a M$ box or a PS2 box... They forgot people
    who, by any chance, may be interested in using CAD software that
    creates 3D real time animations (no problem... you save your
    animation and see it later like a mpeg4 movie... eeepss... like avi
    movie... eeepsss... like theora movie). Or you download everything
    you need (step by step) from livna, DAG or other places... And so on
    and so forth... (even if you're not systems manager, even if you
    have a schedule to deliver the work ...). But perhaps I should
    became an evangelist and start going to the CAD and Game and
    Sound/Music/Video companies convincing them that ogg/theora is the
    holly word. Until it is not.

    Hey, I'm in the "business" from early 80's... remember: OSI network
    with it's 7 layer architecture would be the future of networking...
    the heated discussion about field-bus and other architectures... and
    why ethernet would never be used inside a factory or production
    platform... The needs for the complicated OSI management (nowadays
    everybody uses SNMP) and why ASN-2 would be the word in terms of
    data description (nowadays everybody uses XML).

    I watched heated discussions around Lotos/Estelle and other "formal
    protocol description languages"... None became standard or evolved
    to important commercial product. You know some? Please, name it to me...

    The "big promise for the 90's", the Ethernet-V6 is still a promise
    in the 2000's... address and QoS issues are being asserted in
    Ethernet-V4...

    Then came ISDN for "fast SOHO and home use"... ISDN (64kbps) became
    Fast ISDN (128kbps) and now both are deeeeaaaad. Now we talk about
    2mbps ADSL/Cable connections... And, naturally, 2Mbps wireless...

    I was just present when heated discussions about the advantages of
    ATM and why "megabit ethernet" would never launch. Saw every type of
    simulations... Now we are discussing Gigabit Ethernet and I have
    seem very few people working around ATM.

    In short: dogma sucks...

    Now I don't use NVIDIA anymore (thanks to Fedora) and use SiS...

    Then, at some point someone inside said that the responsibility of
    "Fedora People" is with "RedHat share holders". Then it (the
    discussion) got really crazy: not to "cause trouble" to the company,
    lets make it less functional and competitive... Then, when I say
    what happens in the biggest market of LA (not Mexico), they "kindly
    remove the top of the message"... But if the responsibility is with
    the share holders, them they must know why sales are bleak... Not
    that I really care about that... I am not a RedHat share holder...

    I just happened to see the movie "Supersize-me" from mr. Spurlock in
    the HBO2 channel. McDonalds behavior just make me think about the
    meaning of this conversation. With the complication that at no point
    mr. Spurlock was called by any official from McDonalds of being
    "stupid". Neither he had to hear "if you're not satisfied with
    McDonalds, why don't you eat at Burger King, just next block"...


Bye and Godspeed


Pedro Fernandes Macedo escreveu:
> On Fri, 31 Mar 2006 10:15:02 -0500, Andrew Overholt <overholt at redhat.com> escreveu:
>   
>> * Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> [2006-03-28 07:59]:
>>     
>>> The java that comes along with GCC runs only about 10-20% of Java Applications
>>> in market. Want examples: try to access any Brazilian bank using "Fedora
>>> standard Java".
>>>       
>> Can you give concrete examples?  Preferably as bugs?
>>     
>
> The banks that he mentions require a java plugin, so he will have to wait for the work on the plugin.
> As for the applications, I dont have any examples of well known applications, except the bug report I just filled (bug 187513), about a JFileChooser that shows no files in the directory and throws an exception if you click on area where the files should be. 
>
> --
> Pedro Macedo
>
>   

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

From seanlkml at sympatico.ca  Fri Mar 31 17:53:03 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 12:53:03 -0500
Subject: 'Commercial Partners'
In-Reply-To: <20060331173030.GB24571@thyrsus.com>
References: <20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331173030.GB24571@thyrsus.com>
Message-ID: <BAYC1-PASMTP05EBB34A641C77B685A375AED60@CEZ.ICE>

On Fri, 31 Mar 2006 12:30:30 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:


> > I don't believe I saw that in the Fedora manifesto. 
> 
> No, you didn't.  That mean I'm somehow not allowed to argue that 
> the manifesto should change?
> 
> I'm not doing this for my health, Andy.  Linux is in a fluid competitive
> situation with a lot of powerful enemies.  It's grow or die.  I'm trying
> to avoid "die".

But you're making some rather unsupportable assumptions about whether
the changes you desire will really lead to the outcome you hope for.
You've also made grand statements about world domination, or desktop
market share that you must know yourself are laughable at best.

You've refused to acknowledge that there are other alternatives
in the Linux landscape already doing the exact same thing you want
Fedora to do.  And you've refused to articulate why every 
distribution must follow this same course of action.

Linux already has healthy choice for everyone. You're trying to
take choice away from people.   You're trying to take the choice
of having an open source only distribution away from the people that
would choose it.   Please just go promote one of the other
distributions that already embraces your vision, there is no
reason to try to convert Fedora.

Sean



From Axel.Thimm at ATrpms.net  Fri Mar 31 17:59:13 2006
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 31 Mar 2006 19:59:13 +0200
Subject: Split-off package config from release note packages
In-Reply-To: <442D6840.2020600@wowway.com>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
	<1143558013.3140.15.camel@aglarond.local>
	<20060329150226.GC13953@neu.nirvana> <442D6840.2020600@wowway.com>
Message-ID: <20060331175913.GC5242@neu.nirvana>

On Fri, Mar 31, 2006 at 12:34:56PM -0500, Demond James wrote:
> Axel Thimm wrote:
> >But then hell breaks loose and people accuse JoeBob of forking fedora,
> >when all he wanted to do is either provide decent mirrors (local or
> >not) for his users or additional repos. Having to replace
> >fedora-release to do that results in for example:
> >
> >http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning
> >
> >  
> What would help stop the propaganda Axel is descriptions of the changes 
> that were made to these core packages.  As it stands now I do not want 
> to replace the core packages with your packages simply because I don't 
> now what changes you made.  Let me decided if I want that added 
> feature.  Other than that great job and great repo.   Thank you!

you can use

rpm -qp --changelog package.rpm | less

I think there may even be some tool that can pull changelogs from
the repo w/o having you to download the whole package.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060331/9940860a/attachment.sig>

From tromey at redhat.com  Fri Mar 31 17:55:23 2006
From: tromey at redhat.com (Tom Tromey)
Date: 31 Mar 2006 10:55:23 -0700
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <20060331154113.9493.qmail@hm196.locaweb.com.br>
References: <20060331151502.GC13677@redhat.com>
	<20060331154113.9493.qmail@hm196.locaweb.com.br>
Message-ID: <m3vetujy7o.fsf@localhost.localdomain>

>>>>> "Pedro" == Pedro Fernandes Macedo <webmaster at margo.bijoux.nom.br> writes:

Pedro> The banks that he mentions require a java plugin, so he will
Pedro> have to wait for the work on the plugin.

If you're motivated you can try the standalone applet viewer.  It is
pretty simple to build gcjwebplugin.  And I use the applet viewer
every day to do chess puzzles :-)

Pedro> As for the applications, I dont have any examples of well known
Pedro> applications, except the bug report I just filled (bug 187513),
Pedro> about a JFileChooser that shows no files in the directory and
Pedro> throws an exception if you click on area where the files should
Pedro> be.

Thanks.  Usually it is quicker if you file the reports upstream... I
wonder if there is an easy way we could push reports from the RH
bugzilla to the GCC/Classpath bugzilla.  That would be handy.

Tom



From tromey at redhat.com  Fri Mar 31 18:03:31 2006
From: tromey at redhat.com (Tom Tromey)
Date: 31 Mar 2006 11:03:31 -0700
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <4429327A.2060401@gmail.com>
References: <200603280950.k2S9oqre022074@snark.thyrsus.com>
	<44291494.2070003@warmcat.com> <4429327A.2060401@gmail.com>
Message-ID: <m3r74ijxu4.fsf@localhost.localdomain>

>>>>> "Casimiro" == Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> writes:

Casimiro> The java that comes along with GCC runs only about 10-20% of
Casimiro> Java Applications in market.

Casimiro> I'd say that the status of Java within GCC is the
Casimiro> same status of wine... an unfullfilled promise.

At FOSDEM this year there was a nice talk about the status of Swing in
GNU Classpath.  The core message was, a year ago (Nov 2004 to be
exact), Classpath's Swing implementation was essentially useless.
Classes existed but even basic functionality didn't work; according to
the talk we had about 74% of the methods in place -- but about a
quarter of those were just stubs.

The situation is completely different today.  Most of the Swing
patches I see are either for the text widgets (which are the last
incomplete piece) or bug fixes to make applications work.

So, please be a little patient.  We've put a lot of effort into the
basics, and these are pretty solid now.  We are very near having the
needed critical mass, where suddenly many more applications will work.

Tom



From avi at unix.sh  Fri Mar 31 18:23:51 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 15:23:51 -0300
Subject: Fwd: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <1143825659.3157.7.camel@localhost>
References: <Pine.LNX.4.63.0603271255330.24389@master.geeklords.org>
	<Pine.LNX.4.63.0603281301550.27793@master.geeklords.org>
	<604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com>
	<Pine.LNX.4.63.0603281402440.27793@master.geeklords.org>
	<1143585692.30123.28.camel@localhost>
	<Pine.LNX.4.63.0603281451370.27793@master.geeklords.org>
	<1143588739.30123.70.camel@localhost>
	<ed0efd310603292020k6efb2800r18f6e89475059eb4@mail.gmail.com>
	<ed0efd310603310833n3cd1ed6cuc0b47ed1bac5a5ad@mail.gmail.com>
	<1143825659.3157.7.camel@localhost>
Message-ID: <ed0efd310603311023o4b6c3877t45091460740342f3@mail.gmail.com>

On 3/31/06, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> So Elektra's end goal is a common on-disk format?  And libelektra is a
> "reference implementation" providing an API that the developers think is
> sane?  Which clears up the following areas:

It can be on-disk, or remote. It depends on the backend you'll use.
Currently we only have local on-disk backends as filesys and the
superfast Berkeley DB.

The initiative has 3 focus areas:

1. Definition of a standard key/value pair hierarchy, namespace and
semantics. Se some written standards-by-example here:
http://www.germane-software.com/repositories/elektra/trunk/doc/specs/

2. API implementation to access the key/value pairs namespace

3. Produce quality patches for popular softwares as X.org, Samba,
KDE's KConfig XT and Gnome's GConf

While thightly integrated to focus 1, focus 2 can be redone without
compromising the work made on focus 1 because this last is 100%
conceptual.


> * GConf as a backend was not a real long term direction for the
> software.

Yes. Was just a test. GConf is higher level compared to Elektra, so
doesn't make sense to put Elektra on top of GConf. What we'll have in
near future is GConf and KConfig XT on top of Elektra, so all G- and
K-apps will be automatically elektrified, without changing a comma in
their source. And more: G-apps will be able to access K-apps configs
and vice-versa. Even more: we finaly will be able to have one single
place for general things like proxy configuration, desktop background,
etc (althought Elektra is more than just desktop configuration).


> * Making Elektra a backend to GConf/KConfig/etc is providing an
> additional API rather than the canonical one.  It doesn't compromise the
> core goal of a common on-disk format.

I'm not sure if I understand this due to my english limitations. But I
think an answer is in my previous paragraph.

There is a very graphical and easy to understand OOo presentation
about Elektra, updated this morning, at
http://www.germane-software.com/repositories/elektra/trunk/doc/elektra.odp

I delivered an old version of it on KDE's Akademy event few years ago
in Germany. And will be probably delivered again this year in Desktop
Symposium in Ottawa.

Regards,
Avi



From esr at thyrsus.com  Fri Mar 31 18:31:57 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 13:31:57 -0500
Subject: 'Commercial Partners'
In-Reply-To: <20060331125303.270bef0f.seanlkml@sympatico.ca>
References: <20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331173030.GB24571@thyrsus.com>
	<20060331125303.270bef0f.seanlkml@sympatico.ca>
Message-ID: <20060331183157.GA25177@thyrsus.com>

sean <seanlkml at sympatico.ca>:
> But you're making some rather unsupportable assumptions about whether
> the changes you desire will really lead to the outcome you hope for.

Read up on the distinction between "necessary" and "sufficient" sometime.
I'm advocating necessary changes, I have not represented that they
will be *sufficient*.

> You've refused to acknowledge that there are other alternatives
> in the Linux landscape already doing the exact same thing you want
> Fedora to do. 

And that would be who, exactly?

>            And you've refused to articulate why every 
> distribution must follow this same course of action.

No, just the ones that want market share among non-technical users.
Or, taking a larger view, Linux fans who actually want to do something
to stem the tide of creeping DRM and locked-down video card and the
like.  To prevent that, we need to be the 800-pound gorilla, not
a niche product appealing to techies only.

>  You're trying to take choice away from people.  

OK, you've devolved into sputtering ga-ga incoherence now, Go take a
tranquilizer.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From linville at redhat.com  Fri Mar 31 18:40:19 2006
From: linville at redhat.com (John W. Linville)
Date: Fri, 31 Mar 2006 13:40:19 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603310830s3c71a547h4b59ce6920b2c85d@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
	<ed0efd310603301857j16907b40qc2525c89a6b6f856@mail.gmail.com>
	<ed0efd310603301922u5fa00c22j14f912320467186c@mail.gmail.com>
	<ed0efd310603310830s3c71a547h4b59ce6920b2c85d@mail.gmail.com>
Message-ID: <20060331184014.GI24833@redhat.com>

On Fri, Mar 31, 2006 at 01:30:12PM -0300, Avi Alkalay wrote:
> So you may think there is a reason, lost in time, but there is
> actually no reason why BIND named.conf file look that way, which is
> different from /etc/passwd, which is different from smb.conf, which is
> different from httpd.conf.

...except that configuring a name server is a differnt problem domain
than configuring user accounts, than configuring a file server,
than configuring a web server, etc.

Please, this topic comes-up again and again.  How long this time
before someone suggests we all use the windows registry?

Migrating thousands of Unix-oriented applications to XML-based
(or similar) configurations schemes, only so that you then have to
develop new tools for each application to turn the XML config file into
something appropriate for the given application, just makes no sense.

Perhaps you could move-on to actually writing some code to solve a
real problem, instead of re-hashing this pipe dream?

Thanks,

John
-- 
John W. Linville
linville at redhat.com



From rdieter at math.unl.edu  Fri Mar 31 18:39:40 2006
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 31 Mar 2006 12:39:40 -0600
Subject: Split-off package config from release note packages
In-Reply-To: <20060329150226.GC13953@neu.nirvana>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>	<1143516515.3140.1.camel@aglarond.local>	<20060328122303.GA19783@jadzia.bu.edu>	<ufahd5ihcze.fsf@epithumia.math.uh.edu>	<1143558013.3140.15.camel@aglarond.local>
	<20060329150226.GC13953@neu.nirvana>
Message-ID: <442D776C.5090303@math.unl.edu>

Axel Thimm wrote:

> But then hell breaks loose and people accuse JoeBob of forking fedora,
...
> http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning

My $0.02:  I think flamebait, err, personal opinion stuff like that has 
no place in fedoraproject's wiki.  It should be removed.

-- Rex



From avi at unix.sh  Fri Mar 31 18:52:10 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 15:52:10 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060331184014.GI24833@redhat.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
	<ed0efd310603301857j16907b40qc2525c89a6b6f856@mail.gmail.com>
	<ed0efd310603301922u5fa00c22j14f912320467186c@mail.gmail.com>
	<ed0efd310603310830s3c71a547h4b59ce6920b2c85d@mail.gmail.com>
	<20060331184014.GI24833@redhat.com>
Message-ID: <ed0efd310603311052y5352855bn6369c3829907a3f7@mail.gmail.com>

On 3/31/06, John W. Linville <linville at redhat.com> wrote:
> On Fri, Mar 31, 2006 at 01:30:12PM -0300, Avi Alkalay wrote:
> > So you may think there is a reason, lost in time, but there is
> > actually no reason why BIND named.conf file look that way, which is
> > different from /etc/passwd, which is different from smb.conf, which is
> > different from httpd.conf.
>
> ...except that configuring a name server is a differnt problem domain
> than configuring user accounts, than configuring a file server,
> than configuring a web server, etc.

I thought we were talking about the syntax, and not semantics.


> Migrating thousands of Unix-oriented applications to XML-based
> (or similar) configurations schemes, only so that you then have to
> develop new tools for each application to turn the XML config file into
> something appropriate for the given application, just makes no sense.

Yeah, this really makes no sense. Thank God we are clever enough to
not walk in the path your imagination just described.
But it would help if people understand what we are trying to do first,
and after that make public criticisms that make more sense than your
based-on-nothing statement.

Thank you
Avi



From webmaster at margo.bijoux.nom.br  Fri Mar 31 18:55:38 2006
From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo)
Date: Fri, 31 Mar 2006 15:55:38 -0300
Subject: Double dare ya, Fedora!  And your art sucks!
In-Reply-To: <442D6DD8.9070200@gmail.com>
References: <442D6DD8.9070200@gmail.com>
Message-ID: <20060331185538.17942.qmail@hm196.locaweb.com.br>

On Fri, 31 Mar 2006 14:58:48 -0300, Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> escreveu:
> 
>     Yeah... there are concrete problems with the lack of the java plug
>     in. But besides that I had problems with some applications (class
>     this and class that not found... and lots of other errors and
>     messages, but I'm not St. Claire - Santa Clara - to give light to
>     blind people, nor I'm under contract to point out again and again
>     where inconsistencies appear). BTW, try to run Gentleware SW
>     Poseidon for UML without Sun Java... Try to develop sw for portables
>     using Waba/Super-Waba or the likes without Sun Java... 

Casimiro, you're trying to compare a proprietary JVM that had began its development in 1992 (according to wikipedia) with a project that began recently. Compare the money and human resources available, multiply by the life time each project has and you'll see that the Sun VM has a lot more developer hours invested than the gcj (even though the gcj team has done an impressive work in so little time). If you really need java right now, feel free to use any of the other VMs if gcj doesnt work for you, but please report the problems you had, so the gcj team will know what needs to be fixed/improved. And if the problem is in classes that are outside of the Classpath, try convincing your vendor that you need the software to work on a VM that follows only standards.

>     The current kernel (2.8.16-1.2083_FC6) issues a message that the
>     processor of my box is overheating, so speed is going down... That's
>     not true and I sent an e-mail... The answer was: not enough data,
>     but that was all the data recorded... 

All your software/hardware issues described have one point in common: not much data to find out what exactly is going on. Debugging a program is a complicated task when the program in question does its work only in the software land, but when it touches the HW, you can get very weird errors that are hard to trigger without the right hardware (or even without the same solar conditions... Ever heard of Single Event Upset on Cisco hardware, for example?).  OK, closing your reports with "not enough data" is not a good solution. Maybe the person who closed the report (that is, if you created a bugzilla report) should had told you how to collect more usefull data to help solve the issue, but the biggest issue is that this is not a religious war.  From all my contact with FOSS developers (specially the guys who work at Red Hat), I can say that usually the developer will do his/her best to fix the issue if there's enough data to find out the cause.

>     Now I don't use NVIDIA anymore (thanks to Fedora) and use SiS...
You dont need to give up Nvidia just because Fedora doesnt support it out of the box, specially if you need 3D acceleration. But if you want to file a bug related to kernel/X, please remove the driver and try to reproduce the bug without the proprietary driver (please see Mike Harris' post on how to ensure that the driver isnt installed anymore to ensure valid bug reports). After all, who knows what those proprietary modules do when they are loaded? They may even be worse than the infamous sony rootkit...

>     Then, at some point someone inside said that the responsibility of
>     "Fedora People" is with "RedHat share holders". Then it (the
>     discussion) got really crazy: not to "cause trouble" to the company,
>     lets make it less functional and competitive... Then, when I say
>     what happens in the biggest market of LA (not Mexico), they "kindly
>     remove the top of the message"... But if the responsibility is with
>     the share holders, them they must know why sales are bleak... Not
>     that I really care about that... I am not a RedHat share holder...
> 
IMHO, what the RH guys want is protect their jobs (of course, since they're [supposedly] sane) and the company that contributes so much to the development of FOSS. What other company you know that buys stuff like GFS and FDS for a large sum of money and releases the sources?? I am one of the people that want companies like RH (and the other members of the OIN) to survive , so they can continue their good work.

>     I just happened to see the movie "Supersize-me" from mr. Spurlock in
>     the HBO2 channel. McDonalds behavior just make me think about the
>     meaning of this conversation. With the complication that at no point
>     mr. Spurlock was called by any official from McDonalds of being
>     "stupid". Neither he had to hear "if you're not satisfied with
>     McDonalds, why don't you eat at Burger King, just next block"...

I guess you forgot some parts of the movie. Mr Spurlock tried to contact the PR staff from Mcdonalds several times and never got an answer. In your case, you're getting an answer, but you dont like what you hear.  
IMHO  every linux distribution comes a whole set of ideas and sometimes you may not agree with some them. So the best way to choose a linux distribution is looking for one that has the same ideals as you.  

--
Pedro Macedo (who is currently looking for a bunker ;D )



From davej at redhat.com  Fri Mar 31 18:58:06 2006
From: davej at redhat.com (Dave Jones)
Date: Fri, 31 Mar 2006 13:58:06 -0500
Subject: r300 driver in extras?
In-Reply-To: <1143826364.19590.130.camel@pmac.infradead.org>
References: <442D24FF.3060403@gmx.net>
	<1143826364.19590.130.camel@pmac.infradead.org>
Message-ID: <20060331185806.GA4133@redhat.com>

On Fri, Mar 31, 2006 at 06:32:44PM +0100, David Woodhouse wrote:
 > On Fri, 2006-03-31 at 15:47 +0300, Jonathan Dieter wrote:
 > > It seems that the only difference in Mesa when the r300 is enabled is 
 > > that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and 
 > > that the only difference in the kernel is the drm module is patched to 
 > > not recognize the r300 PCI ids.  It seems that the Mesa problem could be 
 > > easily fixed, but what is the easiest way to fix the kernel (aside from 
 > > providing my own (un)patched kernel)?
 > 
 > We could make the crippling of R300 _optional_, by doing it with the
 > patch below instead of just by ripping the relevant PCI IDs out.
 > 
 > DaveJ?

something got merged yesterday (not yet in the fedora kernel until
I rebase), that changed a lot of this.

============================================
commit f3dd5c37382472a8b245ad791ed768771594e60c
tree 38c9d13de6187f0b67154d7ab643dbaed55280c2
parent 6e5fca53c72c95da92c092411c7ec81e926af632
author Dave Airlie <airlied at linux.ie> Sat, 25 Mar 2006 18:09:46 +1100
committer Dave Airlie <airlied at linux.ie> Sat, 25 Mar 2006 18:09:46 +1100

drm: add new radeon PCI ids..

This adds all the r300 and r400 PCI ids from DRM CVS, it also
makes these cards only initialise when the new xorg driver is
used, as otherwise the DRM can cause lockups.
============================================

relevant bit being..

+       /* if we require new memory map but we don't have it fail */
+       if ((dev_priv->flags & CHIP_NEW_MEMMAP) && !dev_priv->new_memmap)
+       {
+               DRM_ERROR("Cannot initialise DRM on this card\nThis card
+requires a new X.org DDX\n");
+               radeon_do_cleanup_cp(dev);
+               return DRM_ERR(EINVAL);
+       }

I'll drop the cripple-radeon patch today, and we'll see what happens.

		Dave

-- 
http://www.codemonkey.org.uk



From andy at warmcat.com  Fri Mar 31 19:19:13 2006
From: andy at warmcat.com (Andy Green)
Date: Fri, 31 Mar 2006 20:19:13 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060331173030.GB24571@thyrsus.com>
References: <20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com>	<20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com>	<20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com>
Message-ID: <442D80B1.20902@warmcat.com>

Eric S. Raymond wrote:
> Andy Green <andy at warmcat.com>:
>> That is what I was referring to.  Eric Blossom from Gnu Radio told me 
>> this as a possible explanation for wlan driver secrecy as well.
> 
> Well, there's a larger issue with variable driver wattage there...

This is OT but I believe that is simply a figleaf.  The other figleaf is 
that the PLL registers would be exposed to allow it to function at 
disallowed frequencies.  If true and is truly a problem then this is a 
flaw in the hardware design, since any kernel code can poke these 
registers.  Simply design the hardware to have strapped pins to define 
the legal power and frequency range for the region and the problem is gone.

> Yeah, I know.  But in practice "Quicktime" support pretty much reduces 
> to "Sorensen video codec support".

Not so, eg,

http://www.apple.com/quicktime/technologies/h264/faq.html

Also the necessary audio codecs.

>> Each of these will have its own patent story and people looking to get 
>> their hands on RHAT's cash if RHAT give them the chance.
> 
> This is no different than any normal negotiating situtation.  Other OS
> vendors deal with it all the time.

"Other OS vendors" have a revenue stream to give a cut of in the form of 
a patent license royalty.  Not quite sure what you are expecting RHAT to 
do about that wrt Fedora.

>>> The goal of the game here isn't perfection, it's
>>> maximizing adoption rate.
>> I don't believe I saw that in the Fedora manifesto. 
> 
> No, you didn't.  That mean I'm somehow not allowed to argue that 
> the manifesto should change?

Misrepresenting the actual goals of the project with your personal 
preference as to what they should be is not arguing for change, it is 
trying to bamboozle people.

> I'm not doing this for my health, Andy.  Linux is in a fluid competitive
> situation with a lot of powerful enemies.  It's grow or die.  I'm trying
> to avoid "die".

I don't see a single reason to accept your dramatic characterizations as 
accurate.

Have a nice evening.

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

From jspaleta at gmail.com  Fri Mar 31 19:20:24 2006
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 31 Mar 2006 14:20:24 -0500
Subject: Split-off package config from release note packages
In-Reply-To: <442D776C.5090303@math.unl.edu>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<1143516515.3140.1.camel@aglarond.local>
	<20060328122303.GA19783@jadzia.bu.edu>
	<ufahd5ihcze.fsf@epithumia.math.uh.edu>
	<1143558013.3140.15.camel@aglarond.local>
	<20060329150226.GC13953@neu.nirvana> <442D776C.5090303@math.unl.edu>
Message-ID: <604aa7910603311120r561fe88dg227095e5ea84c0fd@mail.gmail.com>

On 3/31/06, Rex Dieter <rdieter at math.unl.edu> wrote:
> Axel Thimm wrote:
>
> > But then hell breaks loose and people accuse JoeBob of forking fedora,
> ...
> > http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning
>
> My $0.02:  I think flamebait, err, personal opinion stuff like that has
> no place in fedoraproject's wiki.  It should be removed.


Aren't there master wiki admins who can are tasked with policing the
wiki content and dealing with people who have stepped over the line?

Just a little history about this page... this author of that page
originally had it as a top level page and not under his namespace. I
suggested that he move it to inside his accountname space to make it
clear that that page was in fact was personal opinion and not policy.
Without clear guidelines as to what is allowable content I wasn't
going to fight over whether or not the wiki can be used for opinion or
editorial content at the time i found out that page existed.  I
totally forgot to follow up and open a discussion on -extras-list as
to whether or not opinion pieces were allowed.

-jef



From dwmw2 at infradead.org  Fri Mar 31 19:29:35 2006
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 31 Mar 2006 20:29:35 +0100
Subject: r300 driver in extras?
In-Reply-To: <20060331185806.GA4133@redhat.com>
References: <442D24FF.3060403@gmx.net>
	<1143826364.19590.130.camel@pmac.infradead.org>
	<20060331185806.GA4133@redhat.com>
Message-ID: <1143833376.2600.1.camel@localhost.localdomain>

On Fri, 2006-03-31 at 13:58 -0500, Dave Jones wrote:
> something got merged yesterday (not yet in the fedora kernel until
> I rebase), that changed a lot of this.

Yeah, I saw that -- but it doesn't disable _everything_ that the old
patch disabled. I didn't think it was worth suggesting for FC-5.

-- 
dwmw2



From avi at unix.sh  Fri Mar 31 19:32:04 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 16:32:04 -0300
Subject: 'Commercial Partners'
In-Reply-To: <442D80B1.20902@warmcat.com>
References: <20060329145524.GB10714@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com>
Message-ID: <ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>

On 3/31/06, Andy Green <andy at warmcat.com> wrote:
> Eric S. Raymond wrote:
> > I'm not doing this for my health, Andy.  Linux is in a fluid competitive
> > situation with a lot of powerful enemies.  It's grow or die.  I'm trying
> > to avoid "die".
>
> I don't see a single reason to accept your dramatic characterizations as
> accurate.

To help Eric fine tune his accuracy, I have to say that I work in a
global well known IT company, on Linux solutions sales. We fight
everyday for Linux not to die in the commercial world, because of this
annoying "missing packages". On the commercial desktop space this is
specially annoying.

This is so ridiculous that you still can find Linux sales people
making Linux presentations on Linux events using MS PowerPoint. Just
because to use Linux isn't that straight forward as Andy may think.

I believe that too much religion in our OSS world doesn't help much.
Exactly as real religions, it makes its followers a bit blind to see
whats really happening out there.

So I think Eric is pretty accurate in its statement.

Thank you,
Avi



From billcrawford1970 at gmail.com  Fri Mar 31 19:43:35 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Fri, 31 Mar 2006 20:43:35 +0100
Subject: 'Commercial Partners'
In-Reply-To: <20060331085130.GB19993@thyrsus.com>
References: <20060328163215.GA25428@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com>
Message-ID: <200603312043.36178.billcrawford1970@googlemail.com>

On Friday 31 March 2006 09:51, Eric S. Raymond wrote:

> In truth, I think we can get away with not supporting WMA.  But no MP3
> is a complete laugh-at-those-idiots showstopper.  QuickTime is
> somewhere in the middle.

 I'd actually like to disagree. Most of my friends (who are very nontechnical 
on the whole, though "edjicated") use WMA for download onto memory sticks and 
mp3 players; and I can only easily listen if I have wma support.

 The positive point to make is this: a friend came over last weekend with a 1G 
mp3 player in hand. I was able to stick it in an unused USB port (on the back 
of the machine alas; I'm sooo behind the times) and access the tracks in 
about 3 seconds using amaroK. Simple as that. She was able to quite happily 
navigate track lists and play songs without a whimper. Not once was there a 
single comment about the "odd" desktop.

 So, "Linux" (in this case: KDE + X.org + GNU + LInux kernel) *is* now usable 
and functional. I consider it better, for most use, than the last Windows 
desktop I tried. I believe that issue - the "not ready for prime time" can be 
finally buried.

 That said: agreed on the MP3 support. But it is unlikely to go in FC before 
the patent runs out.



From esr at thyrsus.com  Fri Mar 31 19:43:59 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 14:43:59 -0500
Subject: 'Commercial Partners'
In-Reply-To: <442D80B1.20902@warmcat.com>
References: <20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com>
Message-ID: <20060331194359.GB25535@thyrsus.com>

Andy Green <andy at warmcat.com>:
> "Other OS vendors" have a revenue stream to give a cut of in the form of 
> a patent license royalty.  Not quite sure what you are expecting RHAT to 
> do about that wrt Fedora.

You're telling me RHEL isn't making money?
 
> Misrepresenting the actual goals of the project with your personal 
> preference as to what they should be is not arguing for change, it is 
> trying to bamboozle people.

No misrepresentation here.  I've laid out the logic very clearly -- 
Red Hat has a business decision to make about whether it (still)
wants the desktop and what it's prepared to do to get it.  It ties
into a larger issue about what the Linux community needs to do to
thrive under competitive pressure, which *is* a question for Fedora.
 
> I don't see a single reason to accept your dramatic characterizations as 
> accurate.

Well, I've been right about this sort of thing before, and I've
continued to pay attention.  You're living in an industry
significantly shaped by the fact that I got some key market analysis
right and then addressed the implied problem, and a lot of VCs and
CEOs and investment bankers listen *very* respectfully when I talk.

This doesn't make me infallible, of course, but it does mean betting
that I'm wrong this time is not something to do casually.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From seanlkml at sympatico.ca  Fri Mar 31 19:42:04 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 14:42:04 -0500
Subject: 'Commercial Partners'
In-Reply-To: <ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
References: <20060329145524.GB10714@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com>
	<ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
Message-ID: <BAYC1-PASMTP05B58E1CD65CA299CB231BAED60@CEZ.ICE>

On Fri, 31 Mar 2006 16:32:04 -0300
"Avi Alkalay" <avi at unix.sh> wrote:

> To help Eric fine tune his accuracy, I have to say that I work in a
> global well known IT company, on Linux solutions sales. We fight
> everyday for Linux not to die in the commercial world, because of this
> annoying "missing packages". On the commercial desktop space this is
> specially annoying.

For sure, but Linux is not defined by Fedora.   And Fedora is not tasked
with the goal of the commercial desktop space.   

Red Hat has a product designed for the commercial desktop space for 
instance, as do several other major vendors.
 
> This is so ridiculous that you still can find Linux sales people
> making Linux presentations on Linux events using MS PowerPoint. Just

lol, sad.

> because to use Linux isn't that straight forward as Andy may think.

Can't speak for Andy, but i haven't heard anyone say that this is 
all straight forward in the larger sense of Linux as a whole.

> I believe that too much religion in our OSS world doesn't help much.
> Exactly as real religions, it makes its followers a bit blind to see
> whats really happening out there.

Most people in this debate on the FOSS side have taken great pains to 
stear clear of the usual religious arguments.   For instance, nobody
is arguing that everyone should use FOSS come hell or highwater.   Nor
has anyone tried to say that nobody should use the proprietary repositories
on top of Fedora Core.

Just that as well as respecting the needs of those users, we should ALSO
respect the needs of the FOSS users.

> So I think Eric is pretty accurate in its statement.

The fundamental flaw in Eric's arguments come from equating Fedora with
all of the Linux landscape and then following that up with the notion
that therefore Fedora must do whatever is necessary to solve the problems
he sees with Linux overall.

Sean



From cmadams at hiwaay.net  Fri Mar 31 19:47:56 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 31 Mar 2006 13:47:56 -0600
Subject: 'Commercial Partners'
In-Reply-To: <20060331194359.GB25535@thyrsus.com>
References: <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com>
	<442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com>
Message-ID: <20060331194756.GC720325@hiwaay.net>

Once upon a time, Eric S. Raymond <esr at thyrsus.com> said:
> Andy Green <andy at warmcat.com>:
> > "Other OS vendors" have a revenue stream to give a cut of in the form of 
> > a patent license royalty.  Not quite sure what you are expecting RHAT to 
> > do about that wrt Fedora.
> 
> You're telling me RHEL isn't making money?

RHEL != Fedora.  If you wish to talk about RHEL, I suggest you move over
to a more appropriate list, such as nahant-list (or talk to a RHEL sales
rep).  As previously noted, RHEL includes Acrobat Reader, Flash, Java,
and RealPlayer.
-- 
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  Fri Mar 31 19:50:21 2006
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 31 Mar 2006 13:50:21 -0600
Subject: 'Commercial Partners'
In-Reply-To: <ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
References: <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com>
	<442D80B1.20902@warmcat.com>
	<ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
Message-ID: <20060331195021.GD720325@hiwaay.net>

Once upon a time, Avi Alkalay <avi at unix.sh> said:
> To help Eric fine tune his accuracy, I have to say that I work in a
> global well known IT company, on Linux solutions sales. We fight
> everyday for Linux not to die in the commercial world, because of this
> annoying "missing packages". On the commercial desktop space this is
> specially annoying.

In the commercial desktop space, I would expect you would be using a
commercially supported distribution.  RHEL includes Acrobat, Flash,
Java, and RealPlayer.  Any other things you find missing should be noted
with your sales rep.

Alternately, if you are supporting Fedora as a commercial desktop, you
must already be doing a significant amount of long-term support (since
the Fedora "lifetime" is only 8-12 months).  In that case, you can add
the "missing packages" to your own custom distribution.
-- 
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 seanlkml at sympatico.ca  Fri Mar 31 19:48:02 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 14:48:02 -0500
Subject: 'Commercial Partners'
In-Reply-To: <20060331194359.GB25535@thyrsus.com>
References: <20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com>
	<20060331194359.GB25535@thyrsus.com>
Message-ID: <BAYC1-PASMTP106B8D42472DF2AB0DF940AED60@CEZ.ICE>

On Fri, 31 Mar 2006 14:43:59 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> You're telling me RHEL isn't making money?

Not from Fedora.

> No misrepresentation here.  I've laid out the logic very clearly -- 
> Red Hat has a business decision to make about whether it (still)
> wants the desktop and what it's prepared to do to get it.  It ties
> into a larger issue about what the Linux community needs to do to
> thrive under competitive pressure, which *is* a question for Fedora.

You do know that Red Hat has products designed specifically for
the commercial desktop right?   And Fedora isn't even a product
sold by Red Hat.

> Well, I've been right about this sort of thing before, and I've
> continued to pay attention.  You're living in an industry
> significantly shaped by the fact that I got some key market analysis
> right and then addressed the implied problem, and a lot of VCs and
> CEOs and investment bankers listen *very* respectfully when I talk.
> 
> This doesn't make me infallible, of course, but it does mean betting
> that I'm wrong this time is not something to do casually.

Nobody is betting that you're wrong.   There is absolutely no doubt
you're correct that a pure open source Linux desktop can not compete
directly with Windows.   However, it's also quite likely that
Linux + proprietary drivers and apps still can't compete in that
space.

Anyway, none of that has anything to do with Fedora.

Sean



From esr at thyrsus.com  Fri Mar 31 19:57:30 2006
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 31 Mar 2006 14:57:30 -0500
Subject: 'Commercial Partners'
In-Reply-To: <ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
References: <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com>
	<442D80B1.20902@warmcat.com>
	<ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
Message-ID: <20060331195730.GC25535@thyrsus.com>

Avi Alkalay <avi at unix.sh>:
> To help Eric fine tune his accuracy, I have to say that I work in a
> global well known IT company, on Linux solutions sales. We fight
> everyday for Linux not to die in the commercial world, because of this
> annoying "missing packages". On the commercial desktop space this is
> specially annoying.
> 
> This is so ridiculous that you still can find Linux sales people
> making Linux presentations on Linux events using MS PowerPoint. Just
> because to use Linux isn't that straight forward as Andy may think.
> 
> I believe that too much religion in our OSS world doesn't help much.
> Exactly as real religions, it makes its followers a bit blind to see
> whats really happening out there.
> 
> So I think Eric is pretty accurate in its statement.

If this list weren't 99% populated by techies, you'd see hundreds of
mails like this.  

One of the things I make a special point of doing is keeping in touch
with people who are in the trenches every day doing Linux conversions
for SOHO customers.  And kids, it's a whole 'nother world out there.
Your average Linux developer is just *astonishingly* naive about what
actual customers' priorities are and what drives technology adoption.

I wish I had the luxury of such naivete.  I wish we could fort up in
our technical-specialist back-room niche, worship at the shrine of
100% undiluted free software, and not worry about what very powerful
enemies will do if we don't outgrow their capacity to smother us.

Alas, reality is not that kind.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



From seanlkml at sympatico.ca  Fri Mar 31 20:04:06 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 15:04:06 -0500
Subject: 'Commercial Partners'
In-Reply-To: <20060331195730.GC25535@thyrsus.com>
References: <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com>
	<442D80B1.20902@warmcat.com>
	<ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
	<20060331195730.GC25535@thyrsus.com>
Message-ID: <BAYC1-PASMTP09A5CCE7BAC5B315ABAD2EAED60@CEZ.ICE>

On Fri, 31 Mar 2006 14:57:30 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> If this list weren't 99% populated by techies, you'd see hundreds of
> mails like this.  

You're right.  And they'd hopefully understand the answer they got
better than you're managing to process it. ;o)

> One of the things I make a special point of doing is keeping in touch
> with people who are in the trenches every day doing Linux conversions
> for SOHO customers.  And kids, it's a whole 'nother world out there.
> Your average Linux developer is just *astonishingly* naive about what
> actual customers' priorities are and what drives technology adoption.

I'd assume that many people on this list work in the "trenches" just
as much as you do.   You're trying to say your opinion is more 
informed than the people you're debating; that awfully presumptuous.

> I wish I had the luxury of such naivete.  I wish we could fort up in
> our technical-specialist back-room niche, worship at the shrine of
> 100% undiluted free software, and not worry about what very powerful
> enemies will do if we don't outgrow their capacity to smother us.
> 

The people debating in this thread have given you lots of chances to
notice that they're not disagreeing with you about many of your basic
points.   You're forced to assume their naive because you can't
seem to come to terms with the points you're actually mistaken about.

> Alas, reality is not that kind.

There is plenty of oportunity in _reality_ to work on the issues that
interest you.   Nobody is arguing that your objectives are wrong, just
your implementation.

Sean



From davej at redhat.com  Fri Mar 31 20:17:05 2006
From: davej at redhat.com (Dave Jones)
Date: Fri, 31 Mar 2006 15:17:05 -0500
Subject: 'Commercial Partners'
In-Reply-To: <442D2C71.7070809@warmcat.com>
References: <20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
Message-ID: <20060331201705.GH4133@redhat.com>

On Fri, Mar 31, 2006 at 02:19:45PM +0100, Andy Green wrote:
 > Eric S. Raymond wrote:
 > >Andy Green <andy at warmcat.com>:
 > >>I don't see any evidence for this for 2D.  The problems all seem to be 
 > >>to do with 3D acceleration hardware in the past, present, and presumably 
 > >>in the future. 
 > >
 > >If true, that would still a problem.  The one guy I know who's a serious
 > >graphics maven says that the wave of the future is 3D texture maps for
 > >everything, including individual font glyphs.
 > 
 > As Nicholas says, all is not completely rosy in the 2D garden.

There are a number of other cards, where the situation is worse.
Short of running their binary driver, the Matrox parhelia is
a really expensive way to run the vesa driver for example.
(The mga driver doesn't support anything newer than g550 iirc).

		Dave

-- 
http://www.codemonkey.org.uk



From linville at redhat.com  Fri Mar 31 20:17:47 2006
From: linville at redhat.com (John W. Linville)
Date: Fri, 31 Mar 2006 15:17:47 -0500
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <ed0efd310603311052y5352855bn6369c3829907a3f7@mail.gmail.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
	<ed0efd310603301857j16907b40qc2525c89a6b6f856@mail.gmail.com>
	<ed0efd310603301922u5fa00c22j14f912320467186c@mail.gmail.com>
	<ed0efd310603310830s3c71a547h4b59ce6920b2c85d@mail.gmail.com>
	<20060331184014.GI24833@redhat.com>
	<ed0efd310603311052y5352855bn6369c3829907a3f7@mail.gmail.com>
Message-ID: <20060331201744.GK24833@redhat.com>

On Fri, Mar 31, 2006 at 03:52:10PM -0300, Avi Alkalay wrote:
> On 3/31/06, John W. Linville <linville at redhat.com> wrote:
> > On Fri, Mar 31, 2006 at 01:30:12PM -0300, Avi Alkalay wrote:
> > > So you may think there is a reason, lost in time, but there is
> > > actually no reason why BIND named.conf file look that way, which is
> > > different from /etc/passwd, which is different from smb.conf, which is
> > > different from httpd.conf.
> >
> > ...except that configuring a name server is a differnt problem domain
> > than configuring user accounts, than configuring a file server,
> > than configuring a web server, etc.
> 
> I thought we were talking about the syntax, and not semantics.

Using a syntax that doesn't correspond to the semantics makes things
harder, not easier.

> > Migrating thousands of Unix-oriented applications to XML-based
> > (or similar) configurations schemes, only so that you then have to
> > develop new tools for each application to turn the XML config file into
> > something appropriate for the given application, just makes no sense.
> 
> Yeah, this really makes no sense. Thank God we are clever enough to
> not walk in the path your imagination just described.
> But it would help if people understand what we are trying to do first,
> and after that make public criticisms that make more sense than your
> based-on-nothing statement.

http://www.redhat.com/archives/rhl-devel-list/2006-March/msg01755.html

	The best layout is the one accessible
	by the broadest range of ways. Currently, human-readable files are
	accessible by human-beings only, or by configuration file "compilers",
	that are difficult, unique, that nobody wants to write or maintain
	except for the original software writer (e.g. the Samba developer with
	the smb.conf file).
	
	The proposed layout is accessible to you by simple reformatting (as
	with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or
	by GUIs (as kdbedit,
	http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any
	software that uses a simple API as libelektra.

I don't know how I got the idea that you wanted to change configuration
file formats, then use new tools to make them human readable...

John
-- 
John W. Linville
linville at redhat.com



From i.pilcher at comcast.net  Fri Mar 31 20:47:05 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Fri, 31 Mar 2006 14:47:05 -0600
Subject: 'Commercial Partners'
In-Reply-To: <20060331201705.GH4133@redhat.com>
References: <20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com>	<20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com>	<20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331201705.GH4133@redhat.com>
Message-ID: <e0k4g9$6ea$1@sea.gmane.org>

Dave Jones wrote:
> There are a number of other cards, where the situation is worse.
> Short of running their binary driver, the Matrox parhelia is
> a really expensive way to run the vesa driver for example.
> (The mga driver doesn't support anything newer than g550 iirc).

So why is everybody so hell-bent on making basic desktop functionality
dependent on 3D performance?

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From billcrawford1970 at gmail.com  Fri Mar 31 20:49:17 2006
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Fri, 31 Mar 2006 21:49:17 +0100
Subject: Fedora's way forward
In-Reply-To: <442CE3FF.8010308@hhs.nl>
References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net>
	<604aa7910603302356y1adc0efej2641a1ca639231c8@mail.gmail.com>
	<442CE3FF.8010308@hhs.nl>
Message-ID: <200603312149.18476.billcrawford1970@googlemail.com>

(off list to reduce the noise given the already large thread :))

On Friday 31 March 2006 09:10, Hans de Goede wrote:

> Heck
> even this discussion is taking way to much time, time I'd rather spent
> fixing dia and unorphaning it.

That would be fantastic. It's been rather less than useful for a while, and is 
one of *the* most useful little applications for a lot of unrelated minor 
tasks that are just too damn fiddly to do with a "graphics" package.



From avi at unix.sh  Fri Mar 31 20:50:49 2006
From: avi at unix.sh (Avi Alkalay)
Date: Fri, 31 Mar 2006 17:50:49 -0300
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060331201744.GK24833@redhat.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
	<ed0efd310603301857j16907b40qc2525c89a6b6f856@mail.gmail.com>
	<ed0efd310603301922u5fa00c22j14f912320467186c@mail.gmail.com>
	<ed0efd310603310830s3c71a547h4b59ce6920b2c85d@mail.gmail.com>
	<20060331184014.GI24833@redhat.com>
	<ed0efd310603311052y5352855bn6369c3829907a3f7@mail.gmail.com>
	<20060331201744.GK24833@redhat.com>
Message-ID: <ed0efd310603311250w72d76b9fj9842bd03bf48416e@mail.gmail.com>

On 3/31/06, John W. Linville <linville at redhat.com> wrote:
> > > Migrating thousands of Unix-oriented applications to XML-based
> > > (or similar) configurations schemes, only so that you then have to
> > > develop new tools for each application to turn the XML config file into
> > > something appropriate for the given application, just makes no sense.
> >
> > Yeah, this really makes no sense. Thank God we are clever enough to
> > not walk in the path your imagination just described.
> > But it would help if people understand what we are trying to do first,
> > and after that make public criticisms that make more sense than your
> > based-on-nothing statement.
>
> http://www.redhat.com/archives/rhl-devel-list/2006-March/msg01755.html
>
>         The best layout is the one accessible
>         by the broadest range of ways. Currently, human-readable files are
>         accessible by human-beings only, or by configuration file "compilers",
>         that are difficult, unique, that nobody wants to write or maintain
>         except for the original software writer (e.g. the Samba developer with
>         the smb.conf file).
>
>         The proposed layout is accessible to you by simple reformatting (as
>         with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or
>         by GUIs (as kdbedit,
>         http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any
>         software that uses a simple API as libelektra.
>

This is for exporting, or to make backend independent representation
of configuration elements or for your human eyes to see. But for you
to manage, or to be "something appropriate for the given application"
(to use your words), or for other software to interact with it, direct
access to configuration parameters is what will actually happen. You
don't need to convert it to XML or anything else.

Regards,
Avi



From jburgess at uklinux.net  Fri Mar 31 20:58:44 2006
From: jburgess at uklinux.net (Jon Burgess)
Date: Fri, 31 Mar 2006 21:58:44 +0100
Subject: Split-off package config from release note packages
In-Reply-To: <20060331175913.GC5242@neu.nirvana>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>	<1143516515.3140.1.camel@aglarond.local>	<20060328122303.GA19783@jadzia.bu.edu>	<ufahd5ihcze.fsf@epithumia.math.uh.edu>	<1143558013.3140.15.camel@aglarond.local>	<20060329150226.GC13953@neu.nirvana>
	<442D6840.2020600@wowway.com> <20060331175913.GC5242@neu.nirvana>
Message-ID: <442D9804.6070306@uklinux.net>

Axel Thimm wrote:
> 
> rpm -qp --changelog package.rpm | less
> 
> I think there may even be some tool that can pull changelogs from
> the repo w/o having you to download the whole package.
> 

# yum install yum-utils
...
# repoquery --repoid=updates --changelog kernel | less
* Sun Mar 26 2006 Dave Jones <davej at redhat.com>
- 2.6.16.1
...

	Jon



From nicolas.mailhot at laposte.net  Fri Mar 31 21:10:06 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 31 Mar 2006 23:10:06 +0200
Subject: 'Commercial Partners'
In-Reply-To: <20060331195730.GC25535@thyrsus.com>
References: <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com>
	<ed0efd310603311132o2592c4dfx5001854c560f2d36@mail.gmail.com>
	<20060331195730.GC25535@thyrsus.com>
Message-ID: <1143839413.2561.57.camel@rousalka.dyndns.org>

Le vendredi 31 mars 2006 ? 14:57 -0500, Eric S. Raymond a ?crit :
> Avi Alkalay <avi at unix.sh>:
> > To help Eric fine tune his accuracy, I have to say that I work in a
> > global well known IT company, on Linux solutions sales. We fight
> > everyday for Linux not to die in the commercial world, because of this
> > annoying "missing packages". On the commercial desktop space this is
> > specially annoying.
> > 
> > This is so ridiculous that you still can find Linux sales people
> > making Linux presentations on Linux events using MS PowerPoint. Just
> > because to use Linux isn't that straight forward as Andy may think.
> > 
> > I believe that too much religion in our OSS world doesn't help much.
> > Exactly as real religions, it makes its followers a bit blind to see
> > whats really happening out there.
> > 
> > So I think Eric is pretty accurate in its statement.
> 
> If this list weren't 99% populated by techies, you'd see hundreds of
> mails like this.  

In case you didn't know it a lot of techies work for dilbertian Actual
Users which spend their time asking vehemently for specific features
then changing their mind once the features are delivered.

Filling the feature matrix users ask is nice. It'll get you some initial
sales. And lots of former customers once they discover :
1. they don't really need all that stuff
2. you've spread so thin trying to do everything it all sort of works
but none of it works well (also most of the features are not in your
core competency perimeter so you couldn't have implemented them well
even by focusing your resources)
3. the existing apps on which they based their initial feature request
have been superseded by newer versions (or lost their market share to a
radically different competitors), the latest IT infomercial reviews
they've ingested promotes something else, and you must have
misunderstood their requests the first time you asked.
4. if they had known it would be so bad (believed what you told them in
the first place), they'd rather have it done your way (why don't you
re-do the implementation for free now they've conceded your point?)

User opinion no matter how strongly expressed has to be taken with a big
grain of salt. Usually focusing your efforts on what you're good at is a
better long-term strategy. (As Red Hat proved). Plan for your future,
not your competitor present/past.

FOSS may be bad at realplayer or flash or quicken or whatever, but it's
good at localisation, interoperability, tabbed browsing, thin client
stuff etc. If efforts had been poured in wine or trying to replicate
exactly the windows 95 desktop experience we'd still be nowhere today.
Microsoft is very careful to morph the GUI of its software every few
years, so feature/cloning parity is a loser race. Every other bit of the
windows desktop is irrelevant, as MS kills apps faster than we can
duplicate them (sourceforge is littered with unfinished FOSS clones of
extinct windows apps)

And even if Fedora managed to be as bad as the competition :
1. it's not preinstalled on systems
2. no orchestrated media campaign will happen to brainwash users into
thinking the most stupid misfeature is a brilliant idea (Tim Waugh
declared just does not have the same media weight as Bill Gates thinks
clippy is a brillant feature)
3. software users inertia is such parity means no switching and no new
market share. You want switches you have to be better, and to be better
you can't expend your resources were your competitor excels and you
suck.

If you can bring all you've asked for to Fedora without diverting its
resources or weakening its message fine. Net win, no one will protest.
But anything more costly is like building the steam car customer polls
asks for when your competitors are working on an explosion engines.

Regards,

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

From nicolas.mailhot at laposte.net  Fri Mar 31 21:13:10 2006
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 31 Mar 2006 23:13:10 +0200
Subject: 'Commercial Partners'
In-Reply-To: <e0k4g9$6ea$1@sea.gmane.org>
References: <20060329145524.GB10714@thyrsus.com>
	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>
	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com>	<20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com>	<20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331201705.GH4133@redhat.com>
	<e0k4g9$6ea$1@sea.gmane.org>
Message-ID: <1143839593.2561.60.camel@rousalka.dyndns.org>

Le vendredi 31 mars 2006 ? 14:47 -0600, Ian Pilcher a ?crit :
> Dave Jones wrote:
> > There are a number of other cards, where the situation is worse.
> > Short of running their binary driver, the Matrox parhelia is
> > a really expensive way to run the vesa driver for example.
> > (The mga driver doesn't support anything newer than g550 iirc).
> 
> So why is everybody so hell-bent on making basic desktop functionality
> dependent on 3D performance?

Probably because nowadays using 2D primitives on hardware designed to do
3D is not that much easier and a lot less efficient than doing 3D
directly. At least that's how I understood the 3D people arguments.

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

From emmanuel.seyman at club-internet.fr  Fri Mar 31 21:14:50 2006
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Fri, 31 Mar 2006 23:14:50 +0200
Subject: 'Commercial Partners'
In-Reply-To: <20060331183157.GA25177@thyrsus.com>
References: <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com>
	<442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com>
	<442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com>
	<442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com>
	<20060331125303.270bef0f.seanlkml@sympatico.ca>
	<20060331183157.GA25177@thyrsus.com>
Message-ID: <20060331211450.GA24405@orient.maison.moi>

On Fri, Mar 31, 2006 at 01:31:57PM -0500, Eric S. Raymond wrote:
> 
> > You've refused to acknowledge that there are other alternatives
> > in the Linux landscape already doing the exact same thing you want
> > Fedora to do. 
> 
> And that would be who, exactly?

Suse, Ubuntu and BLAG are the first three that come to mind.

Emmanuel



From i.pilcher at comcast.net  Fri Mar 31 21:30:35 2006
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Fri, 31 Mar 2006 15:30:35 -0600
Subject: 'Commercial Partners'
In-Reply-To: <1143839593.2561.60.camel@rousalka.dyndns.org>
References: <20060329145524.GB10714@thyrsus.com>	<442AAFA0.1010608@warmcat.com>	<20060330215934.GE14444@thyrsus.com>	<442CE669.2020107@warmcat.com>	<20060331085130.GB19993@thyrsus.com>	<442CF57B.9000001@warmcat.com>	<20060331103536.GA21302@thyrsus.com>	<442D0FB6.3080600@warmcat.com>	<20060331114643.GA22130@thyrsus.com>	<442D2C71.7070809@warmcat.com>
	<20060331201705.GH4133@redhat.com>	<e0k4g9$6ea$1@sea.gmane.org>
	<1143839593.2561.60.camel@rousalka.dyndns.org>
Message-ID: <e0k71t$f8a$1@sea.gmane.org>

Nicolas Mailhot wrote:
> Probably because nowadays using 2D primitives on hardware designed to do
> 3D is not that much easier and a lot less efficient than doing 3D
> directly. At least that's how I understood the 3D people arguments.

All of which would be fine and dandy if graphics hardware manufacturers
provided the specs necessary to create Open Source drivers.  As things
stand, we seem to be headed for the day when the type of basic desktop
functionality we take for granted today will absolutely require the use
of binary drivers from ATI or nVIDIA.  I don't understand why people who
claim to care about software freedom seem to working to create this
situation.

Is it 5:00 yet?

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From seanlkml at sympatico.ca  Fri Mar 31 21:32:02 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 16:32:02 -0500
Subject: 'Commercial Partners'
In-Reply-To: <e0k71t$f8a$1@sea.gmane.org>
References: <20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com>
	<20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com>
	<20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com>
	<20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com>
	<20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com>
	<20060331201705.GH4133@redhat.com> <e0k4g9$6ea$1@sea.gmane.org>
	<1143839593.2561.60.camel@rousalka.dyndns.org>
	<e0k71t$f8a$1@sea.gmane.org>
Message-ID: <BAYC1-PASMTP10289A183B5D66E44A3AECAED60@CEZ.ICE>

On Fri, 31 Mar 2006 15:30:35 -0600
Ian Pilcher <i.pilcher at comcast.net> wrote:

> All of which would be fine and dandy if graphics hardware manufacturers
> provided the specs necessary to create Open Source drivers.  As things
> stand, we seem to be headed for the day when the type of basic desktop
> functionality we take for granted today will absolutely require the use
> of binary drivers from ATI or nVIDIA.  

Well that's the doomsday scenario, hopefully it won't come to that.

> I don't understand why people who
> claim to care about software freedom seem to working to create this
> situation.

Right now some great work is going into open source drivers for some
high end ATI hardware.  Not there yet, but coming along nicely.
As well, there is a BeOS open source driver for some pretty recent
nVidia hardware, with a chance that it will be ported over to Linux.

Plus, in the _long_ term the pace of graphcis hardware churn is
going to vastly deminish which will give open source solutions 
a more fixed target to catch up with.
 
> Is it 5:00 yet?

lol, almost.

Sean



From shane at geeklords.org  Fri Mar 31 21:36:45 2006
From: shane at geeklords.org (Shane Stixrud)
Date: Fri, 31 Mar 2006 13:36:45 -0800 (PST)
Subject: The Strengths and Weakness of Fedora/RHEL OS management
In-Reply-To: <20060331201744.GK24833@redhat.com>
References: <Pine.LNX.4.63.0603251530200.8202@master.geeklords.org>
	<1143597074.3608.44.camel@currant.watzmann.net>
	<ed0efd310603291953u93501fdp74d4ac25e93ec4ac@mail.gmail.com>
	<200603301650.10065.billcrawford1970@googlemail.com>
	<ed0efd310603301241sc740fd3x42eac111f5c50422@mail.gmail.com>
	<ed0efd310603301857j16907b40qc2525c89a6b6f856@mail.gmail.com>
	<ed0efd310603301922u5fa00c22j14f912320467186c@mail.gmail.com>
	<ed0efd310603310830s3c71a547h4b59ce6920b2c85d@mail.gmail.com>
	<20060331184014.GI24833@redhat.com>
	<ed0efd310603311052y5352855bn6369c3829907a3f7@mail.gmail.com>
	<20060331201744.GK24833@redhat.com>
Message-ID: <Pine.LNX.4.63.0603311310570.4532@master.geeklords.org>

On Fri, 31 Mar 2006, John W. Linville wrote:

> Using a syntax that doesn't correspond to the semantics makes things
> harder, not easier.

Can you give an example?  Using a filesystem (i.e. directories, files and 
file contents) as the syntax for an applications semantics does not 
affect/decrease the relationship in any of the cases I can think of.

> I don't know how I got the idea that you wanted to change configuration
> file formats, then use new tools to make them human readable...

I think your idea or at least how you are presenting it is 
incorrect.  This thread started with the idea of changing configuration 
file formats so obviously no one here is saying that is not what is being 
discussed.  However I think your comment on human readable is misleading. 
There is nothing nonhuman readable or editable (using vim, sed etc...) 
about directories, files and plain text file content.


Cheers,
Shane



From pemboa at gmail.com  Fri Mar 31 21:41:21 2006
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 31 Mar 2006 15:41:21 -0600
Subject: system-config-boot
Message-ID: <16de708d0603311341v756618e3ne9a4954f34114dfe@mail.gmail.com>

I would like to submit for critique, suggests, etc. this program I have
made. It is the first GUI app I've made in Linux, and I would appreciate
some constructive criticism.

I made this program because system-config-boot as it exists (in FC4 and
FC5Test3 at least) only allows for selecting of a default boot entry and
changing of the timeout. And FC tends to accumulate a large list of boot
entries during its release cycle. Who knows, maybe this can be included in
FC.

I coded it on a machine running FC5Test3 in case that makes any difference.

Peace

Arthur
--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060331/57bb264e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: system-config-boot.tar.gz
Type: application/x-gzip
Size: 24133 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060331/57bb264e/attachment.bin>

From jpmahowald at gmail.com  Fri Mar 31 21:51:23 2006
From: jpmahowald at gmail.com (John Mahowald)
Date: Sat, 1 Apr 2006 15:51:23 +1800
Subject: Recommended way to start numlockx before gdm?
Message-ID: <3ea997540603311351jcb16582ic1f050d91a593e59@mail.gmail.com>

I maintain numlockx in extras. I have recieved requests for it to be
started before gdm, so the keypad works with the numbers while logging
in. [1] Currently it drops a one-liner script into
/etc/X11/xinit/xinitrc.d/numlockx.sh. Is there a way to do it that
earlier in the X startup that isn't too hacky? I'm not an expert on
the X start process by any means. Appending a line to
/etc/X11/xdm/Xsetup_0 has been suggested, is this acceptable?

[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171361



From seanlkml at sympatico.ca  Fri Mar 31 22:06:59 2006
From: seanlkml at sympatico.ca (sean)
Date: Fri, 31 Mar 2006 17:06:59 -0500
Subject: system-config-boot
In-Reply-To: <16de708d0603311341v756618e3ne9a4954f34114dfe@mail.gmail.com>
References: <16de708d0603311341v756618e3ne9a4954f34114dfe@mail.gmail.com>
Message-ID: <BAYC1-PASMTP04044401CD95A4CEBF06A5AED60@CEZ.ICE>

On Fri, 31 Mar 2006 15:41:21 -0600
"Arthur Pemberton" <pemboa at gmail.com> wrote:

> I would like to submit for critique, suggests, etc. this program I have
> made. It is the first GUI app I've made in Linux, and I would appreciate
> some constructive criticism.
> 
> I made this program because system-config-boot as it exists (in FC4 and
> FC5Test3 at least) only allows for selecting of a default boot entry and
> changing of the timeout. And FC tends to accumulate a large list of boot
> entries during its release cycle. Who knows, maybe this can be included in
> FC.
> 
> I coded it on a machine running FC5Test3 in case that makes any difference.
> 

At first blush it looks good, only some minor comments.

It would be nice to have some mouse-hover pop up help or
maybe a full blown help button on the Edit-Boot-Entry screen.
I'm not sure what options like "Make root active" actually do.

Would be nice if only the tab for the boot type (kernel/
chainloader) you select was available.  Or at least the one 
not selected should be dimmed out to make it clear that it's 
not needed.

The default and fallback designators are a little odd.  I realize 
you're supporting all the features of boot.conf by showing them.
It just seems a bit strange changing the menu order and not making
the top one the default.  Probably nothing to do here, just
didn't feel right at first.

Not sure what the modules list on the kernel tab is meant to do.

Sean



From Lam at Lam.pl  Fri Mar 31 22:11:07 2006
From: Lam at Lam.pl (Leszek Matok)
Date: Sat, 01 Apr 2006 00:11:07 +0200
Subject: system-config-boot
In-Reply-To: <16de708d0603311341v756618e3ne9a4954f34114dfe@mail.gmail.com>
References: <16de708d0603311341v756618e3ne9a4954f34114dfe@mail.gmail.com>
Message-ID: <1143843068.5128.0.camel@pensja.lam.pl>

Dnia 31-03-2006, pi? o godzinie 15:41 -0600, Arthur Pemberton
napisa?(a):
> FC tends to accumulate a large list of boot entries during its release
> cycle.
That's what "installonlyn" plugin is for.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: To jest cz??? listu podpisana	cyfrowo
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060401/505e1118/attachment.sig>

From ivazquez at ivazquez.net  Fri Mar 31 22:16:32 2006
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Fri, 31 Mar 2006 17:16:32 -0500
Subject: r300 driver in extras?
In-Reply-To: <20060331185806.GA4133@redhat.com>
References: <442D24FF.3060403@gmx.net>
	<1143826364.19590.130.camel@pmac.infradead.org>
	<20060331185806.GA4133@redhat.com>
Message-ID: <1143843392.1420.16.camel@ignacio.lan>

On Fri, 2006-03-31 at 13:58 -0500, Dave Jones wrote:
> I'll drop the cripple-radeon patch today, and we'll see what happens.

Just in Rawhide, or will this be happening in FC5 as well in a test
update?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060331/0278be3f/attachment.sig>

From nman64 at n-man.com  Fri Mar 31 23:48:29 2006
From: nman64 at n-man.com (Patrick Barnes)
Date: Fri, 31 Mar 2006 17:48:29 -0600
Subject: Split-off package config from release note packages
In-Reply-To: <604aa7910603311120r561fe88dg227095e5ea84c0fd@mail.gmail.com>
References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com>
	<442D776C.5090303@math.unl.edu>
	<604aa7910603311120r561fe88dg227095e5ea84c0fd@mail.gmail.com>
Message-ID: <200603311748.32613.nman64@n-man.com>

On Friday 31 March 2006 13:20, "Jeff Spaleta" <jspaleta at gmail.com> wrote:
> On 3/31/06, Rex Dieter <rdieter at math.unl.edu> wrote:
> > Axel Thimm wrote:
> > > But then hell breaks loose and people accuse JoeBob of forking fedora,
> >
> > ...
> >
> > > http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning
> >
> > My $0.02:  I think flamebait, err, personal opinion stuff like that has
> > no place in fedoraproject's wiki.  It should be removed.
>
> Aren't there master wiki admins who can are tasked with policing the
> wiki content and dealing with people who have stepped over the line?
>
> Just a little history about this page... this author of that page
> originally had it as a top level page and not under his namespace. I
> suggested that he move it to inside his accountname space to make it
> clear that that page was in fact was personal opinion and not policy.
> Without clear guidelines as to what is allowable content I wasn't
> going to fight over whether or not the wiki can be used for opinion or
> editorial content at the time i found out that page existed.  I
> totally forgot to follow up and open a discussion on -extras-list as
> to whether or not opinion pieces were allowed.
>
> -jef

There are a few people, including myself, Thomas Chung, and Rahul Sundaram, 
who watch over the changes on the wiki and follow up when we see a problem.  
In addition to the move, the page now also has an admonition to make it clear 
that it is a single person's opinion.  Other than being an opinion and not an 
official policy, it doesn't do anything to violate our policies.  The wiki 
has a few different pieces that are based upon opinions, and those opinions 
are worth sharing.  As long as they are relevant, appropriately marked, and 
not in an inappropriate context, I don't see a problem with allowing them.  
If anyone feels differently, I welcome discussion.

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

http://www.n-man.com/

Have I been helpful?  Rate my assistance!
http://rate.affero.net/nman64/
-- 

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